Chúng tôi sẽ bắt đầu blog của mình với các ấn phẩm dựa trên các bài phát biểu mới nhất của giám đốc kỹ thuật của chúng tôi (Dmitry Stolyarov). Tất cả đều diễn ra vào năm 2016 tại nhiều sự kiện chuyên nghiệp khác nhau và dành riêng cho chủ đề DevOps và Docker. Một video từ cuộc họp của Docker Moscow tại văn phòng Badoo, chúng tôi đã Trực tuyến. Những cái mới sẽ đi kèm với những bài viết truyền tải được bản chất của báo cáo. Vì thế…
Ngày 31 tháng XNUMX tại hội nghị , được tổ chức như một phần của lễ hội “Công nghệ Internet Nga” (RIT++ 2016), phần “Triển khai và triển khai liên tục” được mở đầu bằng báo cáo “Các phương pháp thực hành tốt nhất về phân phối liên tục với Docker”. Nó tóm tắt và hệ thống hóa các phương pháp hay nhất để xây dựng quy trình Phân phối liên tục (CD) bằng Docker và các sản phẩm Nguồn mở khác. Chúng tôi làm việc với những giải pháp này trong sản xuất, điều này cho phép chúng tôi dựa vào kinh nghiệm thực tế.
Nếu bạn có cơ hội dành một giờ , chúng tôi khuyên bạn nên xem đầy đủ. Nếu không, dưới đây là bản tóm tắt chính ở dạng văn bản.
Giao hàng liên tục với Docker
ở dưới Giao hàng liên tục chúng tôi hiểu chuỗi sự kiện do đó mã ứng dụng từ kho lưu trữ Git lần đầu tiên được đưa vào sản xuất và sau đó kết thúc trong kho lưu trữ. Cô ấy trông như thế này: Git → Xây dựng → Kiểm tra → Phát hành → Vận hành.
Hầu hết báo cáo được dành cho giai đoạn xây dựng (tập hợp ứng dụng) và việc phát hành và vận hành các chủ đề sẽ được đề cập ngắn gọn. Chúng ta sẽ nói về các vấn đề và mẫu cho phép bạn giải quyết chúng và cách triển khai cụ thể của các mẫu này có thể khác nhau.
Tại sao lại cần Docker ở đây? Không phải vô cớ mà chúng tôi quyết định nói về các phương pháp Phân phối liên tục trong bối cảnh của công cụ Nguồn mở này. Mặc dù toàn bộ báo cáo được dành cho việc sử dụng nó nhưng nhiều lý do được tiết lộ khi xem xét mô hình triển khai mã ứng dụng chính.
Mô hình triển khai chính
Vì vậy, khi chúng tôi tung ra các phiên bản mới của ứng dụng, chúng tôi chắc chắn phải đối mặt với vấn đề thời gian chết, được tạo trong quá trình chuyển đổi máy chủ sản xuất. Lưu lượng truy cập từ phiên bản cũ của ứng dụng sang phiên bản mới không thể chuyển đổi ngay lập tức: trước tiên, chúng tôi phải đảm bảo rằng phiên bản mới không chỉ được tải xuống thành công mà còn được “khởi động” (tức là hoàn toàn sẵn sàng phục vụ các yêu cầu).
Do đó, trong một thời gian, cả hai phiên bản ứng dụng (cũ và mới) sẽ hoạt động đồng thời. Điều này tự động dẫn đến xung đột tài nguyên được chia sẻ: mạng, hệ thống tập tin, IPC, v.v. Với Docker, vấn đề này có thể được giải quyết dễ dàng bằng cách chạy các phiên bản khác nhau của ứng dụng trong các vùng chứa riêng biệt, đảm bảo sự cách ly tài nguyên trong cùng một máy chủ (máy chủ/máy ảo). Tất nhiên, bạn có thể thực hiện bằng một số thủ thuật mà không cần cách nhiệt chút nào, nhưng nếu có một công cụ làm sẵn và tiện lợi thì sẽ có lý do ngược lại - đừng bỏ bê nó.
Việc container hóa mang lại nhiều lợi ích khác khi được triển khai. Bất kỳ ứng dụng nào đều phụ thuộc vào phiên bản cụ thể (hoặc phạm vi phiên bản) thông dịch viên, tính khả dụng của các mô-đun/tiện ích mở rộng, v.v., cũng như các phiên bản của chúng. Và điều này không chỉ áp dụng cho môi trường thực thi ngay lập tức mà còn cho toàn bộ môi trường, bao gồm cả phần mềm hệ thống và phiên bản của nó (tùy theo bản phân phối Linux được sử dụng). Do các thùng chứa không chỉ chứa mã ứng dụng mà còn chứa hệ thống và phần mềm ứng dụng được cài đặt sẵn của các phiên bản bắt buộc, nên bạn có thể quên đi các vấn đề với phần phụ thuộc.
Hãy khái quát hóa mô hình triển khai chính phiên bản mới có tính đến các yếu tố sau:
- Lúc đầu, phiên bản cũ của ứng dụng chạy trong vùng chứa đầu tiên.
- Phiên bản mới sau đó sẽ được tung ra và “hâm nóng” trong thùng chứa thứ hai. Đáng chú ý là bản thân phiên bản mới này không chỉ có mã ứng dụng được cập nhật mà còn có bất kỳ phần phụ thuộc nào của nó, cũng như các thành phần hệ thống (ví dụ: phiên bản OpenSSL mới hoặc toàn bộ bản phân phối).
- Khi phiên bản mới hoàn toàn sẵn sàng phục vụ các yêu cầu, lưu lượng truy cập sẽ chuyển từ vùng chứa đầu tiên sang vùng chứa thứ hai.
- Phiên bản cũ bây giờ có thể được dừng lại.
Cách tiếp cận triển khai các phiên bản khác nhau của ứng dụng trong các vùng chứa riêng biệt mang lại sự tiện lợi khác - quay lại nhanh sang phiên bản cũ (xét cho cùng, chỉ cần chuyển lưu lượng truy cập sang vùng chứa mong muốn là đủ).
Khuyến nghị đầu tiên cuối cùng nghe có vẻ giống như một điều mà ngay cả Thuyền trưởng cũng không thể tìm ra lỗi: “[khi tổ chức Giao hàng liên tục với Docker] Sử dụng Docker [và hiểu những gì nó mang lại]" Hãy nhớ rằng, đây không phải là viên đạn bạc có thể giải quyết mọi vấn đề mà là một công cụ cung cấp nền tảng tuyệt vời.
Khả năng tái lập
Khi nói đến “khả năng tái tạo”, chúng tôi muốn nói đến một tập hợp tổng quát các vấn đề gặp phải khi vận hành các ứng dụng. Chúng ta đang nói về những trường hợp như vậy:
- Kịch bản được bộ phận chất lượng kiểm tra dàn dựng phải được sao chép chính xác khi sản xuất.
- Các ứng dụng được xuất bản trên các máy chủ có thể nhận các gói từ các máy nhân bản kho lưu trữ khác nhau (theo thời gian, chúng được cập nhật và cùng với đó là các phiên bản của ứng dụng đã cài đặt).
- “Mọi thứ đều phù hợp với tôi tại địa phương!” (...và các nhà phát triển không được phép sản xuất.)
- Bạn cần kiểm tra nội dung nào đó trong phiên bản cũ (đã lưu trữ).
- ...
Bản chất chung của chúng tập trung vào thực tế là cần phải tuân thủ đầy đủ các môi trường được sử dụng (cũng như không có yếu tố con người). Làm thế nào chúng ta có thể đảm bảo khả năng tái sản xuất? Tạo hình ảnh Docker dựa trên mã từ Git, sau đó sử dụng chúng cho bất kỳ tác vụ nào: trên địa điểm thử nghiệm, trong sản xuất, trên máy cục bộ của lập trình viên... Đồng thời, điều quan trọng là giảm thiểu các hành động được thực hiện sau khi lắp ráp hình ảnh: càng đơn giản thì càng ít xảy ra lỗi.
Cơ sở hạ tầng là mã
Nếu các yêu cầu về cơ sở hạ tầng (tính sẵn có của phần mềm máy chủ, phiên bản của nó, v.v.) không được chính thức hóa và “lập trình” thì việc triển khai bất kỳ bản cập nhật ứng dụng nào có thể dẫn đến hậu quả tai hại. Ví dụ: trong quá trình chạy thử, bạn đã chuyển sang PHP 7.0 và viết lại mã cho phù hợp - khi đó sự xuất hiện của nó trong quá trình sản xuất với một số PHP (5.5) cũ chắc chắn sẽ khiến ai đó ngạc nhiên. Bạn có thể không quên một thay đổi lớn trong phiên bản trình thông dịch, nhưng “ma quỷ nằm ở chi tiết”: điều bất ngờ có thể nằm ở một bản cập nhật nhỏ của bất kỳ phần phụ thuộc nào.
Một cách tiếp cận để giải quyết vấn đề này được gọi là IaC (Cơ sở hạ tầng dưới dạng mã, “cơ sở hạ tầng dưới dạng mã”) và liên quan đến việc lưu trữ các yêu cầu cơ sở hạ tầng cùng với mã ứng dụng. Khi sử dụng nó, các nhà phát triển và chuyên gia DevOps có thể làm việc với cùng một kho lưu trữ ứng dụng Git, nhưng trên các phần khác nhau của kho lưu trữ đó. Từ mã này, một hình ảnh Docker được tạo trong Git, trong đó ứng dụng được triển khai có tính đến tất cả các chi tiết cụ thể của cơ sở hạ tầng. Nói một cách đơn giản, các tập lệnh (quy tắc) để tập hợp hình ảnh phải nằm trong cùng một kho lưu trữ với mã nguồn và được hợp nhất với nhau.
Trong trường hợp kiến trúc ứng dụng nhiều lớp - ví dụ: có nginx, đứng trước một ứng dụng đang chạy bên trong bộ chứa Docker - Hình ảnh Docker phải được tạo từ mã trong Git cho mỗi lớp. Sau đó, hình ảnh đầu tiên sẽ chứa một ứng dụng có trình thông dịch và các phần phụ thuộc “đóng” khác và hình ảnh thứ hai sẽ chứa nginx ngược dòng.
Hình ảnh Docker, giao tiếp với Git
Chúng tôi chia tất cả Docker image được thu thập từ Git thành hai loại: tạm thời và phát hành. Hình ảnh tạm thời được gắn thẻ theo tên của nhánh trong Git, có thể được ghi đè bằng lần xác nhận tiếp theo và chỉ được triển khai để xem trước (không phải để sản xuất). Đây là điểm khác biệt chính của chúng so với các bản phát hành: bạn không bao giờ biết cam kết cụ thể nào có trong đó.
Sẽ rất hợp lý khi thu thập thành các hình ảnh tạm thời: nhánh chính (bạn có thể tự động triển khai nó đến một trang web riêng để liên tục xem phiên bản chính hiện tại), các nhánh có bản phát hành, nhánh có những cải tiến cụ thể.
Sau khi xem trước các hình ảnh tạm thời đến nhu cầu dịch sang sản xuất, các nhà phát triển đã đặt một thẻ nhất định. Tự động thu thập theo thẻ phát hành hình ảnh (thẻ của nó tương ứng với thẻ từ Git) và được triển khai để dàn dựng. Nếu được bộ phận chất lượng xác nhận thành công thì sẽ được đưa vào sản xuất.
dapp
Mọi thứ được mô tả (triển khai, lắp ráp hình ảnh, bảo trì tiếp theo) có thể được triển khai độc lập bằng cách sử dụng tập lệnh Bash và các công cụ “ngẫu hứng” khác. Nhưng nếu bạn làm điều này, thì đến một lúc nào đó việc triển khai sẽ dẫn đến sự phức tạp lớn và khả năng kiểm soát kém. Hiểu được điều này, chúng tôi đã tạo ra tiện ích Workflow chuyên dụng của riêng mình để xây dựng CI/CD - dapp.
Mã nguồn của nó được viết bằng Ruby, mã nguồn mở và được xuất bản trên . Thật không may, tài liệu hiện là điểm yếu nhất của công cụ này nhưng chúng tôi đang nỗ lực khắc phục nó. Và chúng ta sẽ viết và nói về dapp nhiều lần, bởi vì... Chúng tôi thực sự nóng lòng muốn chia sẻ khả năng của nó với toàn bộ cộng đồng quan tâm, nhưng trong thời gian chờ đợi, hãy gửi các vấn đề của bạn và kéo yêu cầu và/hoặc theo dõi quá trình phát triển của dự án trên GitHub.
Cập nhật ngày 13 tháng 2019 năm XNUMX: hiện tại là một dự án dapp đổi tên thành , mã của nó đã được viết lại hoàn toàn trong Go và tài liệu của nó đã được cải thiện đáng kể.
Kubernetes
Một công cụ Nguồn mở làm sẵn khác đã nhận được sự công nhận đáng kể trong môi trường chuyên nghiệp là Kubernetes, một cụm quản lý Docker. Chủ đề về việc sử dụng nó trong hoạt động của các dự án được xây dựng trên Docker nằm ngoài phạm vi của báo cáo, vì vậy phần trình bày chỉ giới hạn ở phần tổng quan về một số tính năng thú vị.
Để triển khai, Kubernetes cung cấp:
- thăm dò mức độ sẵn sàng - kiểm tra tính sẵn sàng của phiên bản mới của ứng dụng (để chuyển lưu lượng truy cập sang phiên bản đó);
- cập nhật luân phiên - cập nhật hình ảnh tuần tự trong một cụm container (tắt máy, cập nhật, chuẩn bị khởi chạy, chuyển đổi lưu lượng);
- cập nhật đồng bộ - cập nhật hình ảnh trong một cụm với cách tiếp cận khác: đầu tiên là trên một nửa số vùng chứa, sau đó là trên phần còn lại;
- phát hành canary - khởi chạy một hình ảnh mới trên một số lượng giới hạn (nhỏ) vùng chứa để theo dõi những điểm bất thường.
Vì Phân phối liên tục không chỉ là phát hành phiên bản mới, Kubernetes còn có một số khả năng để bảo trì cơ sở hạ tầng tiếp theo: giám sát và ghi nhật ký tích hợp cho tất cả các vùng chứa, tự động mở rộng quy mô, v.v. Tất cả điều này đã hoạt động và chỉ chờ thời điểm thích hợp triển khai trong các quy trình của bạn.
Khuyến nghị cuối cùng
- Sử dụng Docker.
- Tạo hình ảnh Docker của các ứng dụng cho mọi nhu cầu của bạn.
- Tuân theo nguyên tắc “Cơ sở hạ tầng là mã”.
- Liên kết Git với Docker.
- Quy định thứ tự triển khai.
- Sử dụng nền tảng làm sẵn (Kubernetes hoặc nền tảng khác).
Video và slide
Video buổi biểu diễn (khoảng một giờ) (báo cáo bắt đầu từ phút thứ 5 - hãy theo liên kết để phát từ thời điểm này).
Trình bày báo cáo:
PS
Các báo cáo khác về chủ đề này trên blog của chúng tôi:
- «» (Dmitry Stolyarov; ngày 27 tháng 2019 năm XNUMX tại DevOpsConf);
- «» (Dmitry Stolyarov; ngày 8 tháng 2018 năm XNUMX trên HighLoad++);
- «» (Dmitry Stolyarov; ngày 7 tháng 2017 năm XNUMX trên HighLoad++);
- «» (Dmitry Stolyarov; ngày 6 tháng 2017 năm XNUMX tại RootConf).
Nguồn: www.habr.com