Phiên bản và mô-đun

Community và Enterprise là cùng một sản phẩm. Điều phân biệt chúng là những gì một máy chủ cài đặt: Community cài bộ gọn nhẹ và để nguyên phần còn lại của ổ đĩa, RAM và các unit, còn Enterprise cài toàn bộ stack. Nhập một giấy phép hợp lệ sẽ nâng cấp máy chủ đang chạy tại chỗ, không động tới một byte dữ liệu khách hàng nào.

Cho đến nay, việc phân chia chỉ là quy tắc hiển thị — mọi dịch vụ được cài trên mọi máy chủ và panel ẩn những tính năng mà Community không được dùng. Vì vậy một máy chủ Community phải trả giá bằng bộ nhớ cho Dovecot, Postfix, rspamd, ClamAV, BIND, PostgreSQL, Varnish và các công cụ tìm kiếm trong khi không thể dùng bất kỳ thứ nào trong số đó.

Sổ đăng ký mô-đun​

Một tệp mô tả mọi mô-đun: configuration/modules.json. Đó là nguồn sự thật duy nhất cho CLI, cả hai panel và trình cài đặt.

{
  "name": "mail",
  "title": "Email hosting",
  "edition": "enterprise",
  "components": ["mail", "rspamd", "clamav"],
  "units": ["postfix", "dovecot", "rspamd", "opendkim"],
  "features": ["emails", "email_aliases", "email_filters", "webmail"],
  "data": ["/etc/hitechcloud/mail", "/home/*/mail"],
  "ram_mb": 420,
  "requires": [],
  "removable": true
}

• edition — community khi máy chủ Community cài nó, enterprise khi chỉ máy chủ có giấy phép mới cài.
• components — các tên mà install đã hiểu, nên sổ đăng ký thêm một chiều thay vì một trình cài đặt thứ hai.
• units — những gì install, uninstall và repair khởi động, dừng và kiểm tra.
• features — các tên trong features.json; mô-đun chưa được cài báo các tính năng của nó là không khả dụng, và panel dựa vào đó để hiển thị.
• data — các đường dẫn chứa dữ liệu khách hàng. Không gì nằm trong data từng bị uninstall xoá. --purge chỉ xoá chúng khi mô-đun không có dữ liệu đang dùng, và nó từ chối thay vì phỏng đoán.
• ram_mb — bộ nhớ thường trú mà các unit của mô-đun thường giữ, để quản trị viên thấy một lần gỡ bỏ lấy lại được bao nhiêu.
• requires — các mô-đun phải được cài trước (webmail yêu cầu mail).

Danh sách đã biên dịch trong internal/core/licence/features.go tiếp tục quyết định tính năng nào Enterprise mở khoá; sổ đăng ký quyết định dịch vụ nào tồn tại. Một bài kiểm thử so sánh cả hai với features.json để ba nguồn không thể lệch nhau.

Lệnh​

hitechcloudcli module list [--json]
hitechcloudcli module status <name> [--json]
hitechcloudcli module install <name>... | --edition enterprise
hitechcloudcli module uninstall <name>... [--purge]
hitechcloudcli module repair <name>...

list in mọi mô-đun kèm phiên bản, việc đã cài hay chưa, máy chủ này có giấy phép cho nó hay không, trạng thái các unit và bộ nhớ của nó. install có tính idempotent — mô-đun đã cài được kiểm tra lại, không cài lại. uninstall dừng và tắt các unit, gỡ các gói chỉ riêng mô-đun đó sở hữu, để nguyên mọi đường dẫn trong data, và cho biết nó đã để lại những gì. repair render lại cấu hình của mô-đun từ các mẫu, bật lại các unit và sửa quyền sở hữu — nút "có gì đó sai, đặt lại như cũ" cho cả hai phiên bản.

Mọi lệnh con đều hỗ trợ --json cho các panel.

Community cài những gì​

Email là mô-đun duy nhất có ở cả hai phiên bản và khác nhau bên trong. Community có máy chủ thư hoạt động được và Roundcube. Enterprise thêm webmail riêng của chúng tôi bên cạnh và các tính năng đi kèm — và việc nâng cấp giữ nguyên Roundcube, vì khách hàng đã lưu dấu trang của nó phải giữ được nó.

Vì vậy bản cài Community là một máy chủ web, PHP, một cơ sở dữ liệu và panel — những thứ mà một máy chủ một website thực sự chạy.

Nhập giấy phép​

hitechcloudcli license --set <key> kiểm tra khoá, và khi máy chủ trở thành Enterprise, nó tự chạy module install --edition enterprise: các mô-đun được thêm, unit của chúng khởi động, danh sách tính năng của panel mở rộng ở yêu cầu tiếp theo. Không có gì được di chuyển, vì không gì đã tồn tại bị thay đổi — việc nâng cấp chỉ thêm vào.

Giấy phép hết hạn không gỡ bỏ gì cả. Các tính năng đóng lại, các dịch vụ vẫn chạy, và người vận hành quyết định có lấy lại bộ nhớ bằng module uninstall hay không. Gỡ dịch vụ khỏi máy chủ đang chạy mà không được yêu cầu là cách dữ liệu bị mất.

Cam kết khi nâng cấp​

Việc nâng cấp Community → Enterprise không được làm mất một byte nào, và đây không chỉ là quy tắc trong tài liệu này — module engine (module, hitechcloudcli/native/module.rs) và lệnh giấy phép (hitechcloudcli/license.rs) được viết sao cho không thể vô tình phá vỡ nó, và cả hai đều có kiểm thử thất bại ngay khi điều đó xảy ra:

1. install không bao giờ xoá gì. Đọc hàm này là bằng chứng — nó gọi trình cài của một thành phần, bật và khởi động unit, và ghi một dấu đánh dấu; không có nhánh mã nào trong đó dừng unit, gỡ gói hay động tới một đường dẫn trong data. uninstall và repair là các hàm riêng, và chỉ khi người vận hành chỉ định một mô-đun cho uninstall mới tới được đoạn mã có thể gỡ nó.
2. module install --edition enterprise trên máy chủ đã có mọi mô-đun Community sẽ giữ tất cả chúng ở trạng thái đã cài, với mọi byte trong data của chúng không bị động tới, bất kể nó thêm gì khác. Được chứng minh bởi upgrading_to_enterprise_leaves_every_already_installed_community_module_installed trong native/module.rs, chạy trên chính modules.json được phát hành, với mọi tên thành phần, unit và gói được thay bằng tên giả để kiểm thử kiểm tra chính các cam kết của engine thay vì một trình cài cụ thể.
3. Giấy phép hết hạn không gỡ gì. a_lapsed_licence_uninstalls_nothing của license.rs đọc chính xác danh sách lệnh mà đường xoá chạy và thất bại nếu nó từng chứa thao tác gỡ bỏ; a_module_stays_installed_after_its_licence_lapses của module.rs chứng minh sự thật đi kèm rằng is_installed không bao giờ tham chiếu giấy phép, nên mô-đun mà máy chủ đã cài khi có giấy phép vẫn báo đã cài sau khi giấy phép đóng các tính năng của nó.
4. Mọi đường dẫn liệt kê trong data của bất kỳ mô-đun nào đều tồn tại sau một lần uninstall thông thường. every_modules_data_survives_an_ordinary_uninstall_of_everything_removable gỡ cùng lúc mọi mô-đun có thể gỡ trong sổ đăng ký được phát hành — phạm vi rộng nhất mà một lệnh của người vận hành có thể chạm tới — và khẳng định mọi đường dẫn data vẫn còn sau đó, từng byte một. --purge là cánh cửa duy nhất để xoá data, và chỉ khi mô-đun báo không có gì đang được dùng.

Riêng về webmail: hai webmail cùng tồn tại​

Community cài Postfix, Dovecot, OpenDKIM và rspamd (mô-đun mail) và cung cấp Roundcube (mô-đun webmail-roundcube) làm webmail. Enterprise thêm webmail riêng của chúng tôi, HiTechCloud Webmail (mô-đun webmail), bên cạnh. Nâng cấp máy chủ có webmail-roundcube sẽ cài webmail mà không động tới Roundcube: Roundcube vẫn được cài, được bật, truy cập được trên vhost riêng, với cơ sở dữ liệu và thiết lập của mọi người dùng y như trước — khách hàng đã lưu dấu trang vẫn dùng được. Cả hai mô-đun đều mang tính năng webmail, và một tính năng khả dụng khi bất kỳ mô-đun nào mang nó được cài, nên máy chủ Community cung cấp webmail chỉ qua Roundcube, còn máy chủ có giấy phép cung cấp qua cả hai.

Hai webmail không phải hai máy chủ thư: webmail-roundcube và webmail đều require: ["mail"] thay vì đóng gói Postfix/Dovecot riêng, nên theo cấu trúc chúng đọc cùng các hộp thư. data của mô-đun này không chồng lên của mô-đun kia, và không mô-đun nào sở hữu một mục units mà mô-đun kia cũng sở hữu, nên gỡ một mô-đun không bao giờ dừng hay gỡ mô-đun kia — webmail_and_roundcube_cannot_collide_on_units_or_data trong native/module.rs giữ sổ đăng ký tuân theo điều này. Cấu hình dùng chung của Dovecot (tệp drop-in tắt xác thực hệ thống để dùng cơ sở dữ liệu hộp thư ảo) được ghi bởi chính bản cài của mail, trước khi thêm bất kỳ webmail nào, và lại được ghi bởi mọi bản cập nhật theo ngôn ngữ cấu hình của Dovecot đã cài (2.3 hoặc 2.4) — trình cài của cả hai webmail đều không ghi lại nó, và không webmail nào được bắt đầu chiếm một cổng vhost mà webmail kia đang phục vụ.

webmail-roundcube chưa có components — trình cài của nó (native/roundcube.rs) vẫn chưa được viết. Cho đến khi có, module báo đúng trạng thái pending thay vì khẳng định một bản cài chưa từng diễn ra, và các kiểm thử ở trên bỏ qua các khẳng định riêng cho Roundcube kèm thông báo rõ ràng thay vì đạt một cách vô nghĩa; chúng bắt đầu kiểm tra nó ngay khi nó có thành phần để cài.

Các trang​

• Quản trị (2087) có Modules & Services: mọi mô-đun với trạng thái, bộ nhớ, unit và ba thao tác, cùng lượng tài nguyên mà một lần gỡ sẽ giải phóng. Đây là trang người vận hành dùng để tinh gọn máy chủ.
• Người dùng (2083) hiển thị các dịch vụ mà tài khoản thấy được chỉ trên Community. Trên Enterprise, các dịch vụ thuộc về quản trị viên, và panel của tài khoản không cung cấp chúng.

Các quy tắc mà thiết kế này duy trì​

1. Gỡ cài đặt không bao giờ động tới dữ liệu khách hàng.
2. Nâng cấp không bao giờ di chuyển dữ liệu; nó chỉ cài đặt.
3. Mô-đun chưa cài báo các tính năng của nó là không khả dụng thay vì thất bại đúng lúc khách hàng nhấn.
4. Sổ đăng ký, features.json và sự phân chia đã biên dịch được so sánh bởi một kiểm thử.
5. Mọi thao tác là một lệnh CLI mà panel gọi — các panel không bao giờ tự cài gói.