Cuộc gặp gỡ quản trị viên hệ thống Sysadminka đang diễn ra ở Chelyabinsk và ở buổi gặp mặt cuối cùng, tôi đã đưa ra báo cáo về giải pháp chạy ứng dụng trên 1C-Bitrix trong Kubernetes của chúng tôi.
Bitrix, Kubernetes, Ceph - một sự kết hợp tuyệt vời?
Tôi sẽ cho bạn biết cách chúng tôi đưa ra giải pháp hiệu quả cho tất cả những vấn đề này.
Chúng ta hãy đi!
Cuộc gặp gỡ diễn ra vào ngày 18 tháng XNUMX tại Chelyabinsk. Bạn có thể đọc về cuộc gặp gỡ của chúng tôi tại và nhìn vào .
Nếu bạn muốn đến với chúng tôi để báo cáo hoặc với tư cách là người nghe - xin chào mừng, hãy viết thư cho [email được bảo vệ] và trên Telegram t.me/vadimisakanov.
Báo cáo của tôi
Giải pháp "Bitrix in Kubernetes, phiên bản Southbridge 1.0"
Tôi sẽ nói về giải pháp của chúng tôi ở định dạng “dành cho người giả ở Kubernetes”, như đã được thực hiện tại cuộc gặp mặt. Nhưng tôi cho rằng bạn biết các từ Bitrix, Docker, Kubernetes, Ceph ít nhất là ở cấp độ các bài viết trên Wikipedia.
Những gì đã sẵn sàng về Bitrix trong Kubernetes?
Có rất ít thông tin trên toàn bộ Internet về hoạt động của các ứng dụng Bitrix trong Kubernetes.
Tôi chỉ tìm thấy những tài liệu này:
Báo cáo của Alexander Serbul, 1C-Bitrix và Anton Tuzlukov từ Qsoft:
Tôi khuyên bạn nên nghe nó.
Phát triển giải pháp của riêng bạn từ người dùng .
Tìm thấy nhiều hơn .
Aaand... thực ra chỉ có vậy thôi.
Tôi cảnh báo bạn, chúng tôi chưa kiểm tra chất lượng của các giải pháp trong các liên kết ở trên :)
Nhân tiện, khi chuẩn bị giải pháp của chúng tôi, tôi đã nói chuyện với Alexander Serbul, khi đó báo cáo của anh ấy vẫn chưa xuất hiện, vì vậy trong slide của tôi có một mục “Bitrix không sử dụng Kubernetes”.
Nhưng hiện đã có rất nhiều Docker image được tạo sẵn để chạy Bitrix trong Docker:
Điều này có đủ để tạo ra một giải pháp hoàn chỉnh cho Bitrix trong Kubernetes không?
KHÔNG. Có rất nhiều vấn đề cần được giải quyết.
Các vấn đề với Bitrix trong Kubernetes là gì?
Đầu tiên, image làm sẵn từ Dockerhub không phù hợp với Kubernetes
Nếu muốn xây dựng kiến trúc microservices (và trong Kubernetes chúng ta thường làm), chúng ta cần tách ứng dụng Kubernetes thành các vùng chứa và để mỗi vùng chứa thực hiện một chức năng nhỏ (và thực hiện tốt chức năng đó). Tại sao chỉ có một? Tóm lại, càng đơn giản càng đáng tin cậy.
Để cụ thể hơn mời các bạn xem bài viết và video này:
Hình ảnh Docker trong Dockerhub chủ yếu được xây dựng theo nguyên tắc tất cả trong một, vì vậy chúng tôi vẫn phải tự chế tạo xe đạp và thậm chí tạo hình ảnh từ đầu.
Thứ hai - mã trang web được chỉnh sửa từ bảng quản trị
Chúng tôi đã tạo một phần mới trên trang web - mã đã được cập nhật (một thư mục có tên của phần mới đã được thêm vào).
Nếu bạn thay đổi thuộc tính của một thành phần từ bảng quản trị thì mã sẽ thay đổi.
Kubernetes “theo mặc định” không thể hoạt động với điều này; các container phải ở trạng thái không trạng thái.
Lý do: Mỗi vùng chứa (nhóm) trong cụm chỉ xử lý một phần lưu lượng. Nếu bạn thay đổi mã chỉ trong một vùng chứa (nhóm), thì mã sẽ khác nhau trong các nhóm khác nhau, trang web sẽ hoạt động khác nhau và các phiên bản khác nhau của trang web sẽ được hiển thị cho những người dùng khác nhau. Bạn không thể sống như thế được.
Thứ ba - bạn cần giải quyết vấn đề khi triển khai
Nếu chúng tôi có một máy chủ nguyên khối và một máy chủ “cổ điển”, thì mọi thứ khá đơn giản: chúng tôi triển khai cơ sở mã mới, di chuyển cơ sở dữ liệu, chuyển lưu lượng truy cập sang phiên bản mã mới. Chuyển đổi xảy ra ngay lập tức.
Nếu chúng tôi có một trang web ở Kubernetes, được cắt thành các vi dịch vụ, có rất nhiều vùng chứa có mã - ồ. Bạn cần thu thập các vùng chứa có phiên bản mã mới, triển khai chúng thay vì phiên bản cũ, di chuyển cơ sở dữ liệu một cách chính xác và lý tưởng nhất là thực hiện việc này mà không bị khách truy cập chú ý. May mắn thay, Kubernetes đã giúp chúng ta điều này, hỗ trợ rất nhiều loại hình triển khai khác nhau.
Thứ tư - bạn cần giải quyết vấn đề lưu trữ số liệu thống kê
Nếu trang web của bạn “chỉ” có 10 gigabyte và bạn triển khai nó hoàn toàn trong các vùng chứa, bạn sẽ có 10 gigabyte vùng chứa và phải mất rất nhiều thời gian để triển khai.
Bạn cần lưu trữ những phần “nặng nhất” của trang web bên ngoài vùng chứa và câu hỏi đặt ra là làm thế nào để thực hiện việc này một cách chính xác
Giải pháp của chúng tôi còn thiếu gì?
Toàn bộ mã Bitrix không được chia thành các vi chức năng/vi dịch vụ (do đó việc đăng ký là riêng biệt, mô-đun cửa hàng trực tuyến là riêng biệt, v.v.). Chúng tôi lưu trữ toàn bộ cơ sở mã trong mỗi vùng chứa.
Chúng tôi cũng không lưu trữ cơ sở dữ liệu trong Kubernetes (tôi vẫn triển khai các giải pháp với cơ sở dữ liệu trong Kubernetes cho môi trường phát triển chứ không phải cho môi trường sản xuất).
Quản trị viên trang web vẫn sẽ nhận thấy rằng trang web chạy trên Kubernetes. Chức năng “kiểm tra hệ thống” không hoạt động chính xác, để chỉnh sửa mã trang web từ bảng quản trị, trước tiên bạn phải nhấp vào nút “Tôi muốn chỉnh sửa mã”.
Các vấn đề đã được xác định, nhu cầu triển khai microservice đã được xác định, mục tiêu rõ ràng - có được một hệ thống hoạt động để chạy các ứng dụng trên Bitrix trong Kubernetes, duy trì cả khả năng của Bitrix và các lợi thế của Kubernetes. Hãy bắt đầu thực hiện.
kiến trúc
Có rất nhiều nhóm “đang hoạt động” với một máy chủ web (công nhân).
Một bên dưới có các tác vụ cron (chỉ cần một tác vụ).
Một bản nâng cấp để chỉnh sửa mã trang web từ bảng quản trị (cũng chỉ cần một bản nâng cấp).
Chúng tôi giải quyết các câu hỏi:
- Nơi lưu trữ phiên?
- Nơi lưu trữ bộ đệm?
- Nơi lưu trữ số liệu thống kê, không đặt hàng gigabyte số liệu thống kê vào một loạt các thùng chứa?
- Cơ sở dữ liệu sẽ hoạt động như thế nào?
Hình ảnh docker
Chúng tôi bắt đầu bằng cách xây dựng hình ảnh Docker.
Tùy chọn lý tưởng là chúng ta có một hình ảnh phổ quát, trên cơ sở đó chúng ta có được các nhóm công nhân, các nhóm có Crontask và các nhóm nâng cấp.
.
Nó bao gồm nginx, apache/php-fpm (có thể được chọn trong quá trình xây dựng), msmtp để gửi thư và cron.
Khi lắp ráp hình ảnh, toàn bộ cơ sở mã của trang web sẽ được sao chép vào thư mục /app (ngoại trừ những phần mà chúng tôi sẽ chuyển sang bộ nhớ dùng chung riêng).
Dịch vụ vi mô, dịch vụ
nhóm công nhân:
- Vùng chứa với nginx + vùng chứa apache/php-fpm + msmtp
- Việc chuyển msmtp sang một microservice riêng biệt không thành công, Bitrix bắt đầu phẫn nộ vì không thể gửi thư trực tiếp
- Mỗi vùng chứa có một cơ sở mã hoàn chỉnh.
- Cấm thay đổi mã trong container.
cron dưới:
- vùng chứa với apache, php, cron
- bao gồm cơ sở mã hoàn chỉnh
- cấm thay đổi mã trong container
nâng cấp dưới:
- bộ chứa nginx + bộ chứa apache/php-fpm + msmtp
- Không có lệnh cấm thay đổi mã trong container
lưu trữ phiên
Lưu trữ bộ đệm Bitrix
Một điều quan trọng khác: chúng tôi lưu trữ mật khẩu để kết nối với mọi thứ, từ cơ sở dữ liệu đến thư, trong các bí mật kubernetes. Chúng tôi nhận được phần thưởng: mật khẩu chỉ hiển thị với những người mà chúng tôi cấp quyền truy cập vào các bí mật chứ không phải cho tất cả những người có quyền truy cập vào cơ sở mã của dự án.
Lưu trữ số liệu thống kê
Bạn có thể sử dụng bất cứ thứ gì: ceph, nfs (nhưng chúng tôi không khuyên dùng nfs cho sản xuất), lưu trữ mạng từ các nhà cung cấp đám mây, v.v.
Bộ lưu trữ sẽ cần được kết nối trong các thùng chứa với thư mục /upload/ của trang web và các thư mục khác có nội dung tĩnh.
Cơ sở dữ liệu
Để đơn giản, chúng tôi khuyên bạn nên di chuyển cơ sở dữ liệu ra ngoài Kubernetes. Cơ sở trong Kubernetes là một nhiệm vụ phức tạp riêng biệt; nó sẽ làm cho sơ đồ trở nên phức tạp hơn.
Lưu trữ phiên
Chúng tôi sử dụng memcached :)
Nó xử lý tốt việc lưu trữ phiên, được phân cụm và được hỗ trợ “nguyên bản” dưới dạng session.save_path trong php. Hệ thống như vậy đã được thử nghiệm nhiều lần trong kiến trúc nguyên khối cổ điển, khi chúng tôi xây dựng các cụm có số lượng lớn máy chủ web. Để triển khai, chúng tôi sử dụng helm.
$ helm install stable/memcached --name sessionphp.ini - ở đây hình ảnh chứa các cài đặt để lưu trữ phiên trong memcached
Chúng tôi đã sử dụng Biến môi trường để truyền dữ liệu về máy chủ có memcached .
Điều này cho phép bạn sử dụng cùng một mã trong môi trường phát triển, giai đoạn, thử nghiệm, sản phẩm (tên máy chủ được ghi nhớ trong đó sẽ khác nhau, vì vậy chúng ta cần chuyển một tên máy chủ duy nhất cho các phiên cho từng môi trường).
Lưu trữ bộ đệm Bitrix
Chúng tôi cần bộ lưu trữ có khả năng chịu lỗi mà tất cả các nhóm có thể ghi và đọc từ đó.
Chúng tôi cũng sử dụng memcached.
Giải pháp này được chính Bitrix khuyên dùng.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - ở đây trong Bitrix nó được chỉ định nơi lưu trữ bộ đệm
Chúng tôi cũng sử dụng Biến môi trường.
Krontaski
Có nhiều cách tiếp cận khác nhau để chạy Crontasks trong Kubernetes.
- triển khai riêng biệt với một nhóm để chạy Crontasks
- cronjob để thực thi crontask (nếu đây là ứng dụng web - với wget hoặc kubectl exec bên trong một trong các nhóm công nhân, v.v.)
- và vv
Bạn có thể tranh luận về điều đúng nhất, nhưng trong trường hợp này, chúng tôi đã chọn tùy chọn “triển khai riêng biệt với các nhóm cho Crontasks”
Làm thế nào nó được thực hiện:
- thêm tác vụ cron qua ConfigMap hoặc qua tệp config/addcron
- trong một trường hợp, chúng tôi khởi chạy một vùng chứa giống hệt với nhóm công nhân + cho phép thực thi các nhiệm vụ quan trọng trong đó
- sử dụng cùng một cơ sở mã, nhờ sự thống nhất nên việc lắp ráp container rất đơn giản
Chúng tôi nhận được điều gì tốt:
- chúng tôi có các Crontask đang hoạt động trong một môi trường giống hệt với môi trường của nhà phát triển (docker)
- Crontask không cần phải “viết lại” cho Kubernetes, chúng hoạt động ở dạng và cơ sở mã giống như trước
- Nhiệm vụ cron có thể được thêm bởi tất cả các thành viên trong nhóm có quyền cam kết với nhánh sản xuất, không chỉ quản trị viên
Southbridge K8SDeploy mô-đun và chỉnh sửa mã từ bảng quản trị
Chúng ta đang nói về việc nâng cấp theo?
Làm thế nào để hướng dẫn giao thông ở đó?
Hoan hô, chúng tôi đã viết một mô-đun cho việc này bằng PHP :) Đây là một mô-đun cổ điển nhỏ dành cho Bitrix. Nó chưa được công khai nhưng chúng tôi dự định mở nó.
Mô-đun này được cài đặt giống như mô-đun thông thường trong Bitrix:
Và nó trông như thế này:
Nó cho phép bạn đặt cookie xác định quản trị viên trang web và cho phép Kubernetes gửi lưu lượng truy cập đến nhóm nâng cấp.
Khi thay đổi hoàn tất, bạn cần nhấn git push, code thay đổi sẽ được gửi tới git, sau đó hệ thống sẽ build image với phiên bản code mới và “roll out” nó khắp cluster, thay thế các pod cũ .
Đúng, đó là một chút khó khăn, nhưng đồng thời chúng tôi vẫn duy trì kiến trúc microservice và không tước đi cơ hội yêu thích của người dùng Bitrix để sửa mã từ bảng quản trị. Cuối cùng, đây là một tùy chọn; bạn có thể giải quyết vấn đề chỉnh sửa mã theo một cách khác.
Biểu đồ mũ lái
Để xây dựng ứng dụng trên Kubernetes, chúng tôi thường sử dụng trình quản lý gói Helm.
Đối với giải pháp Bitrix trong Kubernetes, Sergey Bondarev, quản trị viên hệ thống hàng đầu của chúng tôi, đã viết một biểu đồ Helm đặc biệt.
Nó xây dựng các nhóm công nhân, nâng cấp, cron, định cấu hình các phần xâm nhập, dịch vụ và chuyển các biến từ bí mật Kubernetes sang các nhóm.
Chúng tôi lưu trữ mã trong Gitlab và chúng tôi cũng chạy bản dựng Helm từ Gitlab.
Tóm lại thì nó trông như thế này
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm cũng cho phép bạn thực hiện khôi phục "liền mạch" nếu đột nhiên có sự cố xảy ra trong quá trình triển khai. Thật tuyệt khi bạn không hoảng sợ “sửa mã qua ftp vì sản phẩm bị rơi”, nhưng Kubernetes thực hiện việc đó một cách tự động và không có thời gian chết.
Triển khai
Vâng, chúng tôi là người hâm mộ Gitlab & Gitlab CI, chúng tôi sử dụng nó :)
Khi đưa Gitlab vào kho lưu trữ dự án, Gitlab sẽ khởi chạy một quy trình triển khai phiên bản mới của môi trường.
Các giai đoạn:
- build (xây dựng hình ảnh Docker mới)
- kiểm tra (kiểm tra)
- dọn dẹp (loại bỏ môi trường thử nghiệm)
- đẩy (chúng tôi gửi nó đến sổ đăng ký Docker)
- triển khai (chúng tôi triển khai ứng dụng lên Kubernetes thông qua Helm).
Hoan hô, nó đã sẵn sàng, hãy thực hiện nó!
Vâng, hoặc đặt câu hỏi nếu có.
Vậy chúng ta đã làm gì
Từ quan điểm kỹ thuật:
- Bitrix được cập bến;
- “cắt” Bitrix thành các thùng chứa, mỗi thùng thực hiện một số chức năng tối thiểu;
- đạt được trạng thái container không quốc tịch;
- giải quyết vấn đề cập nhật Bitrix trong Kubernetes;
- tất cả các chức năng của Bitrix vẫn tiếp tục hoạt động (gần như tất cả);
- Chúng tôi đã làm việc để triển khai Kubernetes và khôi phục giữa các phiên bản.
Dưới góc độ kinh doanh:
- khả năng chịu lỗi;
- Các công cụ Kubernetes (tích hợp dễ dàng với Gitlab CI, triển khai liền mạch, v.v.);
- mật khẩu bí mật (chỉ hiển thị với những người được cấp quyền truy cập trực tiếp vào mật khẩu);
- Thật thuận tiện khi tạo các môi trường bổ sung (để phát triển, thử nghiệm, v.v.) trong một cơ sở hạ tầng duy nhất.
Nguồn: www.habr.com