Tôi đề xuất đọc bản sao báo cáo của Alexander Sigachev từ Inventos "Quy trình thử nghiệm và phát triển với Docker + Gitlab CI"
Những người mới bắt đầu thực hiện quy trình phát triển và thử nghiệm dựa trên Docker + Gitlab CI thường hỏi những câu hỏi cơ bản. Nơi để bắt đầu? Làm thế nào để tổ chức? Làm thế nào để kiểm tra?
Báo cáo này rất hay vì nó trình bày một cách có cấu trúc về quá trình phát triển và thử nghiệm bằng cách sử dụng Docker và Gitlab CI. Bản thân báo cáo là từ năm 2017. Tôi nghĩ rằng từ báo cáo này, bạn có thể tìm hiểu những điều cơ bản, phương pháp, ý tưởng, kinh nghiệm sử dụng.
Ai quan tâm, xin vui lòng dưới con mèo.
Tên tôi là Alexander Sigachev. Tôi làm việc cho Inventos. Tôi sẽ kể cho bạn nghe về kinh nghiệm sử dụng Docker của tôi và cách chúng tôi đang dần triển khai nó trên các dự án trong công ty.
Chủ đề thuyết trình: Quy trình phát triển sử dụng Docker và Gitlab CI.
Đây là cuộc nói chuyện thứ hai của tôi về Docker. Tại thời điểm báo cáo đầu tiên, chúng tôi chỉ sử dụng Docker trong Phát triển trên các máy của nhà phát triển. Số lượng nhân viên đã sử dụng Docker khoảng 2-3 người. Dần dần, kinh nghiệm đã có được và chúng tôi tiến xa hơn một chút. liên kết với chúng tôi .
Điều gì sẽ có trong báo cáo này? Chúng tôi sẽ chia sẻ kinh nghiệm của mình về những gì chúng tôi đã thu thập được, những vấn đề chúng tôi đã giải quyết. Không phải nơi nào nó cũng đẹp, nhưng được phép đi tiếp.
Phương châm của chúng tôi là: cập bến mọi thứ chúng tôi có trong tay.
Chúng ta đang giải quyết những vấn đề gì?
Khi có một số nhóm trong một công ty, lập trình viên là một tài nguyên được chia sẻ. Có những giai đoạn khi một lập trình viên bị rút khỏi một dự án và được giao cho một dự án khác trong một thời gian.
Để lập trình viên nhanh chóng hiểu được, anh ta cần tải xuống mã nguồn của dự án và khởi chạy môi trường càng sớm càng tốt, điều này sẽ cho phép anh ta tiếp tục giải quyết các vấn đề của dự án này.
Thông thường, nếu bạn bắt đầu từ đầu, thì có rất ít tài liệu trong dự án. Thông tin về cách thiết lập chỉ dành cho những người lâu năm. Nhân viên tự thiết lập nơi làm việc của họ trong một hoặc hai ngày. Để tăng tốc độ này, chúng tôi đã sử dụng Docker.
Lý do tiếp theo là tiêu chuẩn hóa các cài đặt trong Phát triển. Theo kinh nghiệm của tôi, các nhà phát triển luôn chủ động. Trong mọi trường hợp thứ năm, một miền tùy chỉnh được nhập, chẳng hạn như vasya.dev. Ngồi bên cạnh anh là người hàng xóm Petya, có tên miền là petya.dev. Họ phát triển một trang web hoặc một số thành phần của hệ thống bằng cách sử dụng tên miền này.
Khi hệ thống phát triển và các tên miền này bắt đầu được cấu hình, xung đột môi trường Phát triển sẽ phát sinh và đường dẫn trang được viết lại.
Điều tương tự cũng xảy ra với cài đặt cơ sở dữ liệu. Ai đó không bận tâm đến bảo mật và làm việc với mật khẩu gốc trống. Ở giai đoạn cài đặt, MySQL đã hỏi ai đó mật khẩu và mật khẩu hóa ra là 123. Thường xảy ra trường hợp cấu hình cơ sở dữ liệu thay đổi liên tục tùy thuộc vào cam kết của nhà phát triển. Có người sửa, có người không sửa config. Có những thủ thuật khi chúng tôi lấy ra một số loại cấu hình thử nghiệm trong .gitignore và mỗi nhà phát triển phải cài đặt cơ sở dữ liệu. Điều này làm cho nó khó khăn để bắt đầu. Nó là cần thiết, trong số những thứ khác, để ghi nhớ về cơ sở dữ liệu. Cơ sở dữ liệu phải được khởi tạo, phải nhập mật khẩu, phải đăng ký người dùng, phải tạo bảng, v.v.
Một vấn đề khác là các phiên bản thư viện khác nhau. Việc một nhà phát triển làm việc với các dự án khác nhau thường xảy ra. Có một dự án Di sản đã bắt đầu cách đây 2017 năm (từ 5.5 - ed. note). Tại thời điểm ra mắt, chúng tôi bắt đầu với MySQL 5.7. Ngoài ra còn có các dự án hiện đại nơi chúng tôi cố gắng triển khai các phiên bản MySQL hiện đại hơn, ví dụ: 2017 trở lên (năm XNUMX - ed. note)
Bất kỳ ai làm việc với MySQL đều biết rằng các thư viện này mang theo các phụ thuộc với chúng. Việc chạy 2 cơ sở cùng nhau là một vấn đề khá khó khăn. Ít nhất, các máy khách cũ gặp vấn đề khi kết nối với cơ sở dữ liệu mới. Điều này lần lượt tạo ra một số vấn đề.
Vấn đề tiếp theo là khi nhà phát triển làm việc trên máy cục bộ, anh ta sử dụng tài nguyên cục bộ, tệp cục bộ, RAM cục bộ. Tất cả các tương tác tại thời điểm phát triển giải pháp cho các vấn đề được thực hiện trong khuôn khổ thực tế là nó hoạt động trên một máy. Một ví dụ là khi chúng tôi có máy chủ phụ trợ trong Sản xuất 3 và nhà phát triển lưu tệp vào thư mục gốc và từ đó nginx lấy tệp để đáp ứng yêu cầu. Khi một mã như vậy được đưa vào Sản xuất, hóa ra tệp đó có trên một trong 3 máy chủ.
Hướng của microservices đang phát triển ngay bây giờ. Khi chúng ta chia các ứng dụng lớn của mình thành một số thành phần nhỏ tương tác với nhau. Điều này cho phép bạn chọn công nghệ cho một nhóm tác vụ cụ thể. Nó cũng cho phép bạn chia sẻ công việc và trách nhiệm giữa các nhà phát triển.
Frondend-developer, phát triển trên JS, hầu như không ảnh hưởng gì đến Backend. Ngược lại, nhà phát triển phụ trợ phát triển, trong trường hợp của chúng tôi, Ruby on Rails và không can thiệp vào Frondend. Sự tương tác được thực hiện bằng API.
Ngoài ra, với sự trợ giúp của Docker, chúng tôi có thể tái chế tài nguyên trên Staging. Mỗi dự án, do đặc thù của nó, yêu cầu một số cài đặt nhất định. Về mặt vật lý, cần phải phân bổ máy chủ ảo và định cấu hình chúng một cách riêng biệt hoặc chia sẻ một số loại môi trường biến đổi và các dự án có thể, tùy thuộc vào phiên bản của thư viện, ảnh hưởng lẫn nhau.
Công cụ. Chúng ta sử dụng cái gì?
- Docker chính nó. Dockerfile mô tả các phần phụ thuộc của một ứng dụng.
- Docker-compose là một gói tập hợp một số ứng dụng Docker của chúng tôi.
- Chúng tôi sử dụng GitLab để lưu trữ mã nguồn.
- Chúng tôi sử dụng GitLab-CI để tích hợp hệ thống.
Báo cáo bao gồm hai phần.
Phần đầu tiên sẽ nói về cách Docker được chạy trên máy của các nhà phát triển.
Phần thứ hai sẽ nói về cách tương tác với GitLab, cách chúng tôi chạy thử nghiệm và cách chúng tôi triển khai Giai đoạn.
Docker là một công nghệ cho phép (sử dụng cách tiếp cận khai báo) để mô tả các thành phần cần thiết. Đây là một Dockerfile ví dụ. Ở đây chúng tôi tuyên bố rằng chúng tôi đang kế thừa từ hình ảnh Docker chính thức của Ruby:2.3.0. Nó chứa phiên bản Ruby 2.3 được cài đặt. Chúng tôi cài đặt các thư viện xây dựng cần thiết và NodeJS. Chúng tôi mô tả rằng chúng tôi tạo một thư mục /app. Đặt thư mục ứng dụng làm thư mục làm việc. Trong thư mục này, chúng tôi đặt Gemfile và Gemfile.lock tối thiểu cần thiết. Sau đó, chúng tôi xây dựng các dự án cài đặt hình ảnh phụ thuộc này. Chúng tôi chỉ ra rằng vùng chứa sẽ sẵn sàng lắng nghe trên cổng bên ngoài 3000. Lệnh cuối cùng là lệnh trực tiếp khởi chạy ứng dụng của chúng tôi. Nếu chúng ta thực hiện lệnh bắt đầu dự án, ứng dụng sẽ cố chạy và chạy lệnh đã chỉ định.
Đây là một ví dụ tối thiểu về tệp docker-compose. Trong trường hợp này, chúng tôi chỉ ra rằng có một kết nối giữa hai vùng chứa. Đây là trực tiếp vào dịch vụ cơ sở dữ liệu và dịch vụ web. Các ứng dụng web của chúng tôi trong hầu hết các trường hợp đều yêu cầu một số loại cơ sở dữ liệu làm phụ trợ để lưu trữ dữ liệu. Vì chúng tôi đang sử dụng MySQL, ví dụ là với MySQL - nhưng không có gì ngăn cản chúng tôi sử dụng một số cơ sở dữ liệu khác (PostgreSQL, Redis).
Chúng tôi lấy từ nguồn chính thức từ trung tâm Docker hình ảnh của MySQL 5.7.14 mà không thay đổi. Chúng tôi thu thập hình ảnh chịu trách nhiệm cho ứng dụng web của chúng tôi từ thư mục hiện tại. Nó thu thập một hình ảnh cho chúng tôi trong lần ra mắt đầu tiên. Sau đó, nó chạy lệnh mà chúng tôi đang thực hiện ở đây. Nếu quay lại, chúng ta sẽ thấy lệnh khởi chạy qua Puma đã được xác định. Puma là một dịch vụ được viết bằng Ruby. Trong trường hợp thứ hai, chúng tôi ghi đè. Lệnh này có thể tùy ý tùy theo nhu cầu hoặc nhiệm vụ của chúng ta.
Chúng tôi cũng mô tả rằng chúng tôi cần chuyển tiếp một cổng trên máy chủ của nhà phát triển từ 3000 đến 3000 trên cổng vùng chứa. Điều này được thực hiện tự động bằng cách sử dụng iptables và cơ chế của nó, được nhúng trực tiếp vào Docker.
Nhà phát triển cũng có thể, như trước đây, truy cập bất kỳ địa chỉ IP khả dụng nào, ví dụ: 127.0.0.1 là địa chỉ IP cục bộ hoặc bên ngoài của máy.
Dòng cuối cùng nói rằng bộ chứa web phụ thuộc vào bộ chứa db. Khi chúng tôi gọi phần bắt đầu của bộ chứa web, docker-compose trước tiên sẽ khởi động cơ sở dữ liệu cho chúng tôi. Ngay khi bắt đầu cơ sở dữ liệu (thực tế là sau khi khởi chạy vùng chứa! Điều này không đảm bảo tính sẵn sàng của cơ sở dữ liệu) sẽ khởi chạy ứng dụng, chương trình phụ trợ của chúng tôi.
Điều này tránh lỗi khi cơ sở dữ liệu không được đưa lên và tiết kiệm tài nguyên khi chúng tôi dừng bộ chứa cơ sở dữ liệu, do đó giải phóng tài nguyên cho các dự án khác.
Điều gì mang lại cho chúng tôi việc sử dụng dockerization cơ sở dữ liệu trong dự án. Chúng tôi sửa phiên bản MySQL cho tất cả các nhà phát triển. Điều này tránh được một số lỗi có thể xảy ra khi các phiên bản khác nhau, khi cú pháp, cấu hình, cài đặt mặc định thay đổi. Điều này cho phép bạn chỉ định một tên máy chủ chung cho cơ sở dữ liệu, thông tin đăng nhập, mật khẩu. Chúng tôi đang rời khỏi sở thú về tên và xung đột trong các tệp cấu hình mà chúng tôi đã có trước đó.
Chúng tôi có cơ hội sử dụng cấu hình tối ưu hơn cho môi trường Phát triển, cấu hình này sẽ khác với cấu hình mặc định. MySQL được cấu hình cho các máy yếu theo mặc định và hiệu suất của nó rất kém.
Docker cho phép bạn sử dụng trình thông dịch Python, Ruby, NodeJS, PHP của phiên bản mong muốn. Chúng tôi loại bỏ nhu cầu sử dụng một số loại trình quản lý phiên bản. Trước đây, Ruby đã sử dụng gói vòng/phút cho phép bạn thay đổi phiên bản tùy thuộc vào dự án. Nó cũng cho phép, nhờ bộ chứa Docker, di chuyển mã và phiên bản mã cùng với các phần phụ thuộc một cách trơn tru. Chúng tôi không gặp vấn đề gì khi hiểu phiên bản của cả trình thông dịch và mã. Để cập nhật phiên bản, hãy hạ thấp thùng chứa cũ và nâng thùng chứa mới. Nếu xảy ra sự cố, chúng tôi có thể hạ container mới, nâng container cũ.
Sau khi xây dựng hình ảnh, các thùng chứa trong cả Phát triển và Sản xuất sẽ giống nhau. Điều này đặc biệt đúng đối với các cài đặt lớn.
Trên Frontend, chúng tôi sử dụng JavaScipt và NodeJS.
Bây giờ chúng tôi có dự án cuối cùng trên ReacJS. Nhà phát triển đã chạy mọi thứ trong vùng chứa và phát triển bằng tải lại nóng.
Tiếp theo, tác vụ lắp ráp JavaScipt được khởi chạy và mã được biên dịch thành thống kê được cung cấp thông qua nginx tiết kiệm tài nguyên.
Ở đây tôi đã đưa ra sơ đồ của dự án cuối cùng của chúng tôi.
Những nhiệm vụ đã được giải quyết? Chúng tôi có nhu cầu xây dựng một hệ thống tương tác với các thiết bị di động. Họ nhận được dữ liệu. Một khả năng là gửi thông báo đẩy tới thiết bị này.
Chúng ta đã làm gì cho điều này?
Chúng tôi chia thành các thành phần của ứng dụng như: phần quản trị trên JS, phần phụ trợ, hoạt động thông qua giao diện REST trong Ruby on Rails. Phần phụ trợ tương tác với cơ sở dữ liệu. Kết quả được tạo ra được trao cho khách hàng. Bảng quản trị tương tác với phần phụ trợ và cơ sở dữ liệu thông qua giao diện REST.
Chúng tôi cũng có nhu cầu gửi thông báo đẩy. Trước đó, chúng tôi đã có một dự án triển khai cơ chế chịu trách nhiệm gửi thông báo đến nền tảng di động.
Chúng tôi đã phát triển sơ đồ sau: một nhà điều hành từ trình duyệt tương tác với bảng quản trị, bảng quản trị tương tác với phần phụ trợ, nhiệm vụ là gửi thông báo Đẩy.
Thông báo đẩy tương tác với một thành phần khác được triển khai trong NodeJS.
Hàng đợi được tạo và sau đó thông báo được gửi theo cơ chế của chúng.
Hai cơ sở dữ liệu được vẽ ở đây. Hiện tại, với sự trợ giúp của Docker, chúng tôi sử dụng 2 cơ sở dữ liệu độc lập không liên quan đến nhau theo bất kỳ cách nào. Ngoài ra, chúng có một mạng ảo chung và dữ liệu vật lý được lưu trữ trong các thư mục khác nhau trên máy của nhà phát triển.
Giống nhau nhưng về số lượng. Đây là nơi mà việc sử dụng lại mã là quan trọng.
Nếu trước đó chúng tôi đã nói về việc sử dụng lại mã ở dạng thư viện, thì trong ví dụ này, dịch vụ phản hồi thông báo Đẩy của chúng tôi được sử dụng lại như một máy chủ hoàn chỉnh. Nó cung cấp một API. Và sự phát triển mới của chúng tôi đã tương tác với nó.
Vào thời điểm đó, chúng tôi đang sử dụng phiên bản 4 của NodeJS. Bây giờ (vào năm 2017 - ghi chú biên tập) trong những phát triển gần đây, chúng tôi sử dụng phiên bản 7 của NodeJS. Không có vấn đề gì trong các thành phần mới liên quan đến các phiên bản thư viện mới.
Nếu cần, bạn có thể cấu trúc lại và nâng cấp phiên bản NodeJS từ dịch vụ Thông báo đẩy.
Và nếu chúng tôi có thể duy trì khả năng tương thích API, thì có thể thay thế nó bằng các dự án khác đã được sử dụng trước đó.
Bạn cần thêm Docker gì? Chúng tôi thêm Dockerfile vào kho lưu trữ của mình, nơi mô tả các phụ thuộc cần thiết. Trong ví dụ này, các thành phần được chia nhỏ một cách hợp lý. Đây là yêu cầu tối thiểu của một backend developer.
Khi tạo một dự án mới, chúng tôi tạo một Dockerfile, mô tả hệ sinh thái mong muốn (Python, Ruby, NodeJS). Trong docker-compose, nó mô tả sự phụ thuộc cần thiết - cơ sở dữ liệu. Chúng tôi mô tả rằng chúng tôi cần một cơ sở dữ liệu về phiên bản này và phiên bản kia, lưu trữ dữ liệu ở đó và ở đó.
Chúng tôi sử dụng vùng chứa thứ ba riêng biệt với nginx để phục vụ tĩnh. Có thể tải lên hình ảnh. Phần phụ trợ đặt chúng trong một ổ đĩa được chuẩn bị trước, ổ đĩa này cũng được gắn vào một vùng chứa bằng nginx, cung cấp tĩnh.
Để lưu trữ cấu hình nginx, mysql, chúng tôi đã thêm một thư mục Docker trong đó chúng tôi lưu trữ các cấu hình cần thiết. Khi một nhà phát triển thực hiện một bản sao git của một kho lưu trữ trên máy của mình, anh ta đã có sẵn một dự án để phát triển cục bộ. Không có câu hỏi về cổng hoặc cài đặt nào sẽ áp dụng.
Tiếp theo, chúng tôi có một số thành phần: quản trị viên, thông báo API, thông báo đẩy.
Để bắt đầu tất cả những điều này, chúng tôi đã tạo một kho lưu trữ khác, mà chúng tôi gọi là dockerized-app. Hiện tại, chúng tôi sử dụng một số kho lưu trữ trước mỗi thành phần. Chúng chỉ khác nhau về mặt logic - trong GitLab, nó trông giống như một thư mục, nhưng trên máy của nhà phát triển, một thư mục cho một dự án cụ thể. Xuống một cấp là các thành phần sẽ được kết hợp.
Đây chỉ là một ví dụ về nội dung của dockerized-app. Chúng tôi cũng đưa thư mục Docker vào đây, trong đó chúng tôi điền vào các cấu hình cần thiết cho sự tương tác của tất cả các thành phần. Có một README.md mô tả ngắn gọn cách chạy dự án.
Ở đây chúng tôi đã áp dụng hai tệp docker-compose. Điều này được thực hiện để có thể chạy theo từng bước. Khi một nhà phát triển làm việc với lõi, anh ta không cần thông báo đẩy, anh ta chỉ cần khởi chạy tệp docker-compose và theo đó, tài nguyên được lưu.
Nếu có nhu cầu tích hợp với thông báo đẩy, thì docker-compose.yaml và docker-compose-push.yaml sẽ được khởi chạy.
Vì docker-compose.yaml và docker-compose-push.yaml nằm trong một thư mục nên một mạng ảo duy nhất sẽ tự động được tạo.
Mô tả các thành phần. Đây là một tệp nâng cao hơn chịu trách nhiệm thu thập các thành phần. Điều đáng chú ý ở đây là gì? Ở đây chúng tôi giới thiệu thành phần cân bằng.
Đây là hình ảnh Docker được tạo sẵn để chạy nginx và một ứng dụng lắng nghe trên ổ cắm Docker. Động, khi các vùng chứa được bật và tắt, nó sẽ tạo lại cấu hình nginx. Chúng tôi phân phối việc xử lý các thành phần theo tên miền cấp ba.
Đối với môi trường Phát triển, chúng tôi sử dụng miền .dev - api.informer.dev. Các ứng dụng có miền .dev khả dụng trên máy cục bộ của nhà phát triển.
Hơn nữa, các cấu hình được chuyển đến từng dự án và tất cả các dự án được khởi chạy cùng một lúc.
Về mặt đồ họa, hóa ra ứng dụng khách là trình duyệt của chúng tôi hoặc một số công cụ mà chúng tôi đưa ra yêu cầu đối với bộ cân bằng.
Bộ cân bằng tên miền xác định vùng chứa nào sẽ liên hệ.
Nó có thể là nginx, cung cấp cho quản trị viên JS. Đây có thể là nginx, cung cấp API hoặc các tệp tĩnh, được cung cấp cho nginx dưới dạng tải lên hình ảnh.
Sơ đồ cho thấy các thùng chứa được kết nối bằng một mạng ảo và ẩn đằng sau một proxy.
Trên máy của nhà phát triển, bạn có thể truy cập vùng chứa khi biết IP, nhưng về nguyên tắc, chúng tôi không sử dụng điều này. Thực tế không cần truy cập trực tiếp.
Ví dụ nào để xem xét để cập nhật ứng dụng của bạn? Theo tôi, một ví dụ điển hình là hình ảnh docker chính thức cho MySQL.
Nó khá thách thức. Có nhiều phiên bản. Nhưng chức năng của nó cho phép bạn đáp ứng nhiều nhu cầu có thể phát sinh trong quá trình phát triển hơn nữa. Nếu bạn dành thời gian và tìm hiểu xem tất cả tương tác với nhau như thế nào, thì tôi nghĩ bạn sẽ không gặp vấn đề gì khi tự thực hiện.
Hub.docker.com thường chứa các liên kết đến github.com, nơi chứa dữ liệu thô trực tiếp từ đó bạn có thể tự xây dựng hình ảnh.
Hơn nữa, trong kho lưu trữ này có tập lệnh docker-endpoint.sh chịu trách nhiệm khởi tạo ban đầu và xử lý tiếp tục khởi chạy ứng dụng.
Cũng trong ví dụ này, có khả năng cấu hình bằng các biến môi trường. Bằng cách xác định một biến môi trường khi chạy một vùng chứa hoặc thông qua docker-compose, chúng ta có thể nói rằng chúng ta cần đặt một mật khẩu trống để docker root trên MySQL hoặc bất cứ thứ gì chúng ta muốn.
Có một tùy chọn để tạo một mật khẩu ngẫu nhiên. Chúng tôi nói rằng chúng tôi cần một người dùng, chúng tôi cần đặt mật khẩu cho người dùng và chúng tôi cần tạo một cơ sở dữ liệu.
Trong các dự án của chúng tôi, chúng tôi đã hợp nhất một chút Dockerfile, chịu trách nhiệm khởi tạo. Ở đó, chúng tôi đã sửa nó theo nhu cầu của mình để biến nó thành một phần mở rộng của quyền người dùng mà ứng dụng sử dụng. Điều này cho phép chúng tôi chỉ cần tạo một cơ sở dữ liệu từ bảng điều khiển ứng dụng sau này. Các ứng dụng Ruby có một lệnh để tạo, sửa đổi và xóa cơ sở dữ liệu.
Đây là một ví dụ về phiên bản cụ thể của MySQL trông như thế nào trên github.com. Bạn có thể mở Dockerfile và xem cách cài đặt đang diễn ra ở đó.
docker-endpoint.sh là tập lệnh chịu trách nhiệm về điểm vào. Trong quá trình khởi tạo ban đầu, một số bước chuẩn bị được yêu cầu và tất cả các hành động này được thực hiện ngay trong tập lệnh khởi tạo.
Hãy chuyển sang phần thứ hai.
Để lưu mã nguồn, chúng tôi chuyển sang gitlab. Đây là một hệ thống khá mạnh mẽ có giao diện trực quan.
Một trong những thành phần của Gitlab là Gitlab CI. Nó cho phép bạn mô tả một chuỗi lệnh mà sau này sẽ được sử dụng để tổ chức hệ thống phân phối mã hoặc chạy thử nghiệm tự động.
nói chuyện Gitlab CI 2 - báo cáo từ câu lạc bộ Ruby Russia - khá chi tiết và có lẽ bạn sẽ quan tâm.
Bây giờ chúng ta sẽ xem xét những gì cần thiết để kích hoạt Gitlab CI. Để khởi động Gitlab CI, chúng ta chỉ cần đặt tệp .gitlab-ci.yml vào thư mục gốc của dự án.
Ở đây chúng tôi mô tả rằng chúng tôi muốn thực hiện một chuỗi các trạng thái như thử nghiệm, triển khai.
Chúng tôi thực thi các tập lệnh gọi trực tiếp docker-compose để xây dựng ứng dụng của mình. Đây chỉ là một ví dụ phụ trợ.
Tiếp theo, chúng tôi nói rằng cần phải chạy di chuyển để thay đổi cơ sở dữ liệu và chạy thử nghiệm.
Nếu các tập lệnh được thực thi chính xác và không trả về mã lỗi, thì hệ thống sẽ chuyển sang giai đoạn thứ hai của quá trình triển khai.
Giai đoạn triển khai hiện đang được triển khai để dàn dựng. Chúng tôi đã không tổ chức khởi động lại không thời gian chết.
Chúng tôi buộc phải dập tắt tất cả các thùng chứa, sau đó chúng tôi nâng lại tất cả các thùng chứa, được thu thập ở giai đoạn đầu tiên trong quá trình thử nghiệm.
Chúng tôi đang chạy cho biến môi trường hiện tại di chuyển cơ sở dữ liệu đã được viết bởi các nhà phát triển.
Có một lưu ý rằng điều này chỉ áp dụng cho nhánh chính.
Khi thay đổi các nhánh khác không được thực thi.
Có thể tổ chức triển khai theo chi nhánh.
Để tổ chức hơn nữa, chúng ta cần cài đặt Gitlab Runner.
Tiện ích này được viết bằng Golang. Nó là một tệp duy nhất, như phổ biến trong thế giới Golang, không yêu cầu bất kỳ tệp phụ thuộc nào.
Khi khởi động, chúng tôi đăng ký Gitlab Runner.
Chúng tôi lấy khóa trong giao diện web Gitlab.
Sau đó, chúng tôi gọi lệnh khởi tạo trên dòng lệnh.
Thiết lập tương tác Gitlab Runner (Shell, Docker, VirtualBox, SSH)
Mã trên Gitlab Runner sẽ thực thi trên mọi lần xác nhận, tùy thuộc vào cài đặt .gitlab-ci.yml.
Nó trông như thế nào trong Gitlab trong giao diện web. Sau khi chúng tôi đã kết nối GItlab CI, chúng tôi có một cờ hiển thị trạng thái của bản dựng tại thời điểm này.
Chúng tôi thấy rằng một cam kết đã được thực hiện 4 phút trước, cam kết này đã vượt qua tất cả các bài kiểm tra và không gây ra bất kỳ sự cố nào.
Chúng ta có thể xem xét kỹ hơn các bản dựng. Ở đây chúng ta thấy rằng hai trạng thái đã trôi qua. Trạng thái thử nghiệm và trạng thái triển khai trên dàn.
Nếu chúng ta nhấp vào một bản dựng cụ thể, thì sẽ có đầu ra bảng điều khiển gồm các lệnh được chạy trong quy trình theo .gitlab-ci.yml.
Đây là những gì lịch sử sản phẩm của chúng tôi trông giống như. Chúng tôi thấy rằng đã có những nỗ lực thành công. Khi các bài kiểm tra được gửi, nó không chuyển sang bước tiếp theo và mã dàn không được cập nhật.
Những nhiệm vụ nào chúng tôi đã giải quyết trên dàn dựng khi chúng tôi triển khai docker? Hệ thống của chúng tôi bao gồm các thành phần và chúng tôi cần khởi động lại, chỉ một phần của các thành phần được cập nhật trong kho lưu trữ chứ không phải toàn bộ hệ thống.
Để làm điều này, chúng tôi phải chia mọi thứ thành các thư mục riêng biệt.
Sau khi chúng tôi làm điều này, chúng tôi gặp sự cố với thực tế là Docker-compose tạo không gian mạng riêng cho mỗi cha và không nhìn thấy các thành phần của hàng xóm.
Để di chuyển, chúng tôi đã tạo mạng trong Docker theo cách thủ công. Nó được viết bằng Docker-compose rằng bạn sử dụng một mạng như vậy cho dự án này.
Do đó, mọi thành phần bắt đầu với lưới này sẽ nhìn thấy các thành phần trong các phần khác của hệ thống.
Vấn đề tiếp theo là phân chia giai đoạn trên nhiều dự án.
Vì để tất cả những thứ này trông đẹp mắt và gần với sản xuất nhất có thể, nên sử dụng cổng 80 hoặc 443, được sử dụng ở mọi nơi trên WEB.
Làm thế nào chúng tôi giải quyết nó? Chúng tôi đã chỉ định một Người chạy Gitlab cho tất cả các dự án lớn.
Gitlab cho phép bạn chạy một số Trình chạy Gitlab phân tán, sẽ chỉ nhận lần lượt tất cả các tác vụ một cách hỗn loạn và chạy chúng.
Vì vậy, chúng tôi không có nhà, chúng tôi đã giới hạn nhóm các dự án của mình thành một Người chạy Gitlab, ứng dụng này có thể xử lý mà không gặp vấn đề gì với khối lượng của chúng tôi.
Chúng tôi đã chuyển nginx-proxy thành một tập lệnh khởi động riêng biệt và thêm lưới cho tất cả các dự án trong đó.
Dự án của chúng tôi có một lưới và bộ cân bằng có một số lưới theo tên dự án. Nó có thể ủy quyền thêm bằng tên miền.
Các yêu cầu của chúng tôi đi qua miền trên cổng 80 và được phân giải thành một nhóm vùng chứa phục vụ miền này.
Những vấn đề khác đã có? Đây là những gì tất cả các vùng chứa chạy với quyền root theo mặc định. Đây là root không bằng với máy chủ gốc của hệ thống.
Tuy nhiên, nếu bạn vào vùng chứa, nó sẽ là root và tệp mà chúng ta tạo trong vùng chứa này sẽ có quyền root.
Nếu nhà phát triển đã vào vùng chứa và thực hiện một số lệnh ở đó để tạo tệp, sau đó rời khỏi vùng chứa, thì anh ta có một tệp trong thư mục làm việc mà anh ta không có quyền truy cập.
Làm thế nào nó có thể được giải quyết? Bạn có thể thêm người dùng sẽ ở trong vùng chứa.
Vấn đề gì phát sinh khi chúng tôi thêm người dùng?
Khi tạo người dùng, chúng ta thường không có ID nhóm (UID) và ID người dùng (GID) giống nhau.
Để giải quyết vấn đề này trong vùng chứa, chúng tôi sử dụng người dùng có ID 1000.
Trong trường hợp của chúng tôi, điều này trùng hợp với thực tế là hầu hết tất cả các nhà phát triển đều sử dụng hệ điều hành Ubuntu. Và trên Ubuntu, người dùng đầu tiên có ID là 1000.
Chúng ta có kế hoạch không?
Đọc tài liệu Docker. Dự án đang tích cực phát triển, tài liệu đang thay đổi. Dữ liệu đã nhận được hai hoặc ba tháng trước đang dần trở nên lỗi thời.
Một số vấn đề mà chúng tôi đã giải quyết hoàn toàn có thể đã được giải quyết bằng các phương tiện tiêu chuẩn.
Vì vậy, tôi muốn đi xa hơn để đi trực tiếp đến dàn nhạc.
Một ví dụ là cơ chế tích hợp sẵn của Docker được gọi là Docker Swarm, có sẵn. Tôi muốn chạy thứ gì đó trong quá trình sản xuất dựa trên công nghệ Docker Swarm.
Các thùng chứa sinh sản khiến việc làm việc với nhật ký trở nên bất tiện. Bây giờ các bản ghi được cô lập. Chúng nằm rải rác trên các thùng chứa. Một trong những nhiệm vụ là tạo quyền truy cập thuận tiện vào nhật ký thông qua giao diện web.
Nguồn: www.habr.com