Đầu tiên, một chút lý thuyết. Chuyện gì đã xảy ra vậy ?
Nói một cách đơn giản, tài liệu này được thiết kế để đơn giản hóa việc phát triển các ứng dụng SaaS, hỗ trợ bằng cách thông báo cho các nhà phát triển và kỹ sư DevOps về các vấn đề và thực tiễn thường gặp nhất trong quá trình phát triển các ứng dụng hiện đại.
Tài liệu này được tạo bởi các nhà phát triển nền tảng Heroku.
Ứng dụng Mười hai yếu tố có thể được áp dụng cho các ứng dụng được viết bằng bất kỳ ngôn ngữ lập trình nào và sử dụng bất kỳ sự kết hợp nào của các dịch vụ hỗ trợ (cơ sở dữ liệu, hàng đợi tin nhắn, bộ đệm, v.v.).
Nói ngắn gọn về các yếu tố làm cơ sở cho phương pháp này:
- Cơ sở mã – Một cơ sở mã được theo dõi trong kiểm soát phiên bản – nhiều triển khai
- Sự phụ thuộc – Khai báo rõ ràng và tách biệt các phụ thuộc
- Cấu hình – Lưu cấu hình trong thời gian chạy
- Dịch vụ hỗ trợ – Xem xét các dịch vụ hỗ trợ như các tài nguyên bổ trợ
- Xây dựng, phát hành, chạy – Tách biệt chặt chẽ khâu lắp ráp và thi công
- Процессы – Chạy ứng dụng dưới dạng một hoặc nhiều tiến trình không trạng thái
- Ràng buộc cổng – Xuất dịch vụ qua cổng ràng buộc
- Song song – Mở rộng quy mô ứng dụng của bạn bằng cách sử dụng các quy trình
- Khả năng dùng một lần – Tối đa hóa độ tin cậy với khả năng khởi động nhanh và tắt sạch
- Phát triển ứng dụng/hoạt động tương đương – Giữ môi trường phát triển, dàn dựng và sản xuất của bạn giống nhau nhất có thể
- Ghi nhật ký – Xem nhật ký dưới dạng luồng sự kiện
- Nhiệm vụ quản trị – Thực hiện các nhiệm vụ quản trị/quản lý bằng các quy trình đặc biệt
Bạn có thể tìm thêm thông tin về 12 yếu tố từ các nguồn sau:
- - phải đọc
- - bản dịch chính thức
- - một cái nhìn mới mẻ về 12 yếu tố với mục đích cải thiện chúng.
Triển khai Blue-Green là gì?
Triển khai Blue-Green là một phương pháp cung cấp ứng dụng tới sản xuất theo cách mà khách hàng cuối không thấy bất kỳ thay đổi nào từ phía mình. Nói cách khác, việc triển khai một ứng dụng không có thời gian chết.
Sơ đồ triển khai BG cổ điển trông giống như sơ đồ được hiển thị trong hình bên dưới.
- Khi bắt đầu có 2 máy chủ vật lý có mã, ứng dụng, dự án hoàn toàn giống nhau và có một bộ định tuyến (bộ cân bằng).
- Bộ định tuyến ban đầu hướng tất cả các yêu cầu đến một trong các máy chủ (xanh).
- Tại thời điểm bạn cần phát hành lại, toàn bộ dự án sẽ được cập nhật trên một máy chủ khác (màu lam), hiện không xử lý bất kỳ yêu cầu nào.
- Sau khi mã được bật màu xanh da trời máy chủ được cập nhật hoàn toàn, bộ định tuyến sẽ nhận được lệnh chuyển từ màu xanh lục trên màu lam máy chủ.
- Bây giờ tất cả khách hàng đều thấy kết quả của mã đang chạy với màu lam người phục vụ.
- Trong một thời gian, xanh máy chủ phục vụ như một bản sao lưu trong trường hợp triển khai không thành công tới màu lam máy chủ và trong trường hợp có lỗi và lỗi, bộ định tuyến sẽ chuyển luồng người dùng quay lại xanh server với phiên bản ổn định cũ và mã mới được gửi để sửa đổi và thử nghiệm.
- Và khi kết thúc quá trình, nó được cập nhật theo cách tương tự xanh máy chủ. Và sau khi cập nhật nó, bộ định tuyến sẽ chuyển luồng yêu cầu trở lại xanh máy chủ.
Tất cả đều trông rất tốt và thoạt nhìn sẽ không có vấn đề gì với nó.
Nhưng vì chúng ta đang sống trong thế giới hiện đại, nên lựa chọn chuyển đổi vật lý như được chỉ ra trong sơ đồ cổ điển không phù hợp với chúng ta. Hãy ghi lại thông tin ngay bây giờ, chúng tôi sẽ quay lại sau.
Lời khuyên xấu và tốt
Từ chối trách nhiệm: Các ví dụ bên dưới hiển thị các tiện ích/phương pháp mà tôi sử dụng, bạn hoàn toàn có thể sử dụng bất kỳ lựa chọn thay thế nào có chức năng tương tự.
Hầu hết các ví dụ theo cách này hay cách khác sẽ giao thoa với việc phát triển web (điều này thật bất ngờ), với PHP và Docker.
Các đoạn bên dưới cung cấp mô tả thực tế đơn giản về việc sử dụng các yếu tố bằng cách sử dụng các ví dụ cụ thể; nếu bạn muốn hiểu thêm lý thuyết về chủ đề này, hãy theo các liên kết ở trên để đến nguồn ban đầu.
1. Cơ sở mã
Sử dụng FTP và FileZilla để tải từng tệp lên máy chủ, không lưu trữ mã ở bất kỳ nơi nào khác ngoài máy chủ sản xuất.
Dự án phải luôn có một cơ sở mã duy nhất, nghĩa là tất cả mã đều xuất phát từ một đi kho. Các máy chủ (sản xuất, chạy thử, test1, test2...) sử dụng mã từ các nhánh của một kho lưu trữ chung. Bằng cách này, chúng tôi đạt được tính nhất quán của mã.
2. Sự phụ thuộc
Tải trực tiếp tất cả thư viện trong các thư mục về thư mục gốc của dự án. Thực hiện cập nhật đơn giản bằng cách chuyển mã mới vào thư mục chứa phiên bản hiện tại của thư viện. Cài đặt trực tiếp tất cả các tiện ích cần thiết trên máy chủ lưu trữ nơi có thêm 20 dịch vụ đang chạy.
Một dự án phải luôn có một danh sách rõ ràng và dễ hiểu về các phần phụ thuộc (theo phần phụ thuộc, tôi cũng muốn nói đến môi trường). Tất cả các phụ thuộc phải được xác định và tách biệt rõ ràng.
Hãy lấy làm ví dụ sáng tác и phu bến tàu.
sáng tác — trình quản lý gói cho phép bạn cài đặt các thư viện bằng PHP. Trình soạn thảo cho phép bạn chỉ định các phiên bản một cách chặt chẽ hoặc lỏng lẻo và xác định chúng một cách rõ ràng. Có thể có 20 dự án khác nhau trên máy chủ và mỗi dự án sẽ có một danh sách các gói và thư viện riêng độc lập với nhau.
phu bến tàu — một tiện ích cho phép bạn xác định và tách biệt môi trường mà ứng dụng sẽ chạy. Theo đó, cũng giống như với trình soạn thảo, nhưng kỹ lưỡng hơn, chúng ta có thể xác định ứng dụng hoạt động với cái gì. Chọn một phiên bản PHP cụ thể, chỉ cài đặt các gói cần thiết để dự án hoạt động mà không cần thêm bất kỳ thứ gì. Và quan trọng nhất là không can thiệp vào các gói và môi trường của máy chủ cũng như các dự án khác. Nghĩa là, tất cả các dự án trên máy chủ chạy qua Docker hoàn toàn có thể sử dụng bất kỳ bộ gói nào và một môi trường hoàn toàn khác.
3. Cấu hình
Lưu trữ cấu hình dưới dạng hằng số trực tiếp trong mã. Các hằng số riêng cho máy chủ thử nghiệm, riêng cho sản xuất. Gắn trực tiếp hoạt động của ứng dụng tùy thuộc vào môi trường vào logic nghiệp vụ của dự án bằng cách sử dụng cấu trúc if else.
Cấu hình - đây là cách duy nhất mà việc triển khai dự án sẽ khác nhau. Lý tưởng nhất là các cấu hình nên được chuyển qua các biến môi trường (env vars).
Nghĩa là, ngay cả khi bạn lưu trữ một số tệp cấu hình .config.prod .config.local và đổi tên chúng tại thời điểm triển khai thành .config (cấu hình chính mà ứng dụng đọc dữ liệu) - đây sẽ không phải là cách tiếp cận phù hợp, vì trong trường hợp này, thông tin từ cấu hình sẽ được cung cấp công khai cho tất cả các nhà phát triển ứng dụng và dữ liệu từ máy chủ sản xuất sẽ bị xâm phạm. Tất cả các cấu hình phải được lưu trữ trực tiếp trong hệ thống triển khai (CI/CD) và được tạo cho các môi trường khác nhau với các giá trị khác nhau cần thiết cho một môi trường cụ thể tại thời điểm triển khai.
4. Dịch vụ của bên thứ ba
Hãy gắn chặt với môi trường, sử dụng các kết nối khác nhau cho cùng một dịch vụ trong một số môi trường nhất định.
Trên thực tế, điểm này trùng lặp nhiều với quan điểm về cấu hình, vì nếu không có điểm này, dữ liệu cấu hình thông thường sẽ không thể được thực hiện và nói chung, khả năng cấu hình sẽ giảm xuống mức không có gì.
Tất cả các kết nối đến các dịch vụ bên ngoài, chẳng hạn như máy chủ xếp hàng, cơ sở dữ liệu, dịch vụ bộ nhớ đệm, phải giống nhau đối với cả môi trường cục bộ và môi trường sản xuất/bên thứ ba. Nói cách khác, bất cứ lúc nào, bằng cách thay đổi chuỗi kết nối, tôi có thể thay thế các cuộc gọi đến cơ sở số 1 bằng cơ sở số 2 mà không cần thay đổi mã ứng dụng. Hoặc, nhìn về phía trước, chẳng hạn, khi mở rộng dịch vụ, bạn sẽ không phải chỉ định kết nối theo bất kỳ cách đặc biệt nào cho máy chủ bộ đệm bổ sung.
5. Xây dựng, phát hành, thực thi
Chỉ có phiên bản cuối cùng của mã trên máy chủ và không có cơ hội khôi phục bản phát hành. Không cần phải lấp đầy không gian đĩa. Bất cứ ai nghĩ rằng họ có thể đưa mã vào sản xuất mà gặp lỗi đều là một lập trình viên tồi!
Tất cả các giai đoạn triển khai phải được tách biệt với nhau.
Có cơ hội quay lại. Tạo các bản phát hành với các bản sao cũ của ứng dụng (đã được lắp ráp và sẵn sàng cho trận chiến) được lưu trong truy cập nhanh, để trong trường hợp có lỗi, bạn có thể khôi phục phiên bản cũ. Tức là có điều kiện phải có một thư mục phát hành và thư mục hiện hànhvà sau khi triển khai và lắp ráp thành công thư mục hiện hành được liên kết bằng một liên kết tượng trưng tới bản phát hành mới nằm bên trong phát hành với tên thông thường của số phát hành.
Đây là nơi chúng tôi ghi nhớ việc triển khai Blue-Green, cho phép bạn không chỉ chuyển đổi giữa các mã mà còn chuyển đổi giữa tất cả các tài nguyên và thậm chí cả môi trường với khả năng khôi phục mọi thứ.
6. Quy trình
Lưu trữ dữ liệu trạng thái ứng dụng trực tiếp trong chính ứng dụng đó. Sử dụng các phiên trong RAM của ứng dụng. Sử dụng càng nhiều sự chia sẻ giữa các dịch vụ của bên thứ ba càng tốt. Dựa vào thực tế là ứng dụng chỉ có thể có một quy trình và không cho phép mở rộng quy mô.
Về phiên, chỉ lưu trữ dữ liệu trong bộ đệm được kiểm soát bởi các dịch vụ của bên thứ ba (memcached, redis), vì vậy ngay cả khi bạn có 20 quy trình ứng dụng đang chạy, bất kỳ quy trình nào trong số đó, sau khi truy cập bộ đệm, sẽ có thể tiếp tục làm việc với máy khách trong cùng trạng thái mà người dùng đang làm việc với ứng dụng trong một quy trình khác. Với cách tiếp cận này, hóa ra cho dù bạn sử dụng bao nhiêu bản sao dịch vụ của bên thứ ba thì mọi thứ vẫn hoạt động bình thường và không gặp vấn đề gì với việc truy cập dữ liệu.
7. Ràng buộc cổng
Chỉ máy chủ web mới biết cách làm việc với các dịch vụ của bên thứ ba. Hoặc tốt hơn nữa là cài đặt dịch vụ của bên thứ ba trực tiếp bên trong máy chủ web. Ví dụ: dưới dạng mô-đun PHP trong Apache.
Tất cả các dịch vụ của bạn phải có thể truy cập được lẫn nhau thông qua quyền truy cập vào một số địa chỉ và cổng (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), nghĩa là, từ nginx tôi có thể truy cập cả php-fpm và postgres, và từ php-fpm đến postgres và nginx và thực tế từ mỗi dịch vụ tôi có thể truy cập dịch vụ khác. Bằng cách này, khả năng tồn tại của một dịch vụ không bị ràng buộc với khả năng tồn tại của dịch vụ khác.
8. Tính song song
Làm việc với một quy trình, nếu không, một số quy trình sẽ không thể hòa hợp với nhau!
Chừa chỗ cho việc mở rộng quy mô. Docker bầy đàn là tuyệt vời cho việc này.
Docker Swarm là một công cụ để tạo và quản lý các cụm container giữa các máy khác nhau và một loạt container trên cùng một máy.
Bằng cách sử dụng bầy đàn, tôi có thể xác định số lượng tài nguyên tôi sẽ phân bổ cho mỗi quy trình và số lượng quy trình của cùng một dịch vụ mà tôi sẽ khởi chạy, đồng thời bộ cân bằng nội bộ, nhận dữ liệu trên một cổng nhất định, sẽ tự động ủy quyền nó cho các quy trình. Do đó, thấy tải trên máy chủ đã tăng lên, tôi có thể thêm nhiều quy trình hơn, từ đó giảm tải cho một số quy trình nhất định.
9. Khả năng dùng một lần
Không sử dụng hàng đợi để làm việc với các quy trình và dữ liệu. Việc giết một tiến trình sẽ ảnh hưởng đến toàn bộ ứng dụng. Nếu một dịch vụ ngừng hoạt động, mọi thứ sẽ ngừng hoạt động.
Mỗi quy trình và dịch vụ có thể bị tắt bất kỳ lúc nào và điều này sẽ không ảnh hưởng đến các dịch vụ khác (tất nhiên, điều này không có nghĩa là dịch vụ đó sẽ không khả dụng cho dịch vụ khác, nhưng dịch vụ khác sẽ không tắt sau dịch vụ này). Tất cả các quy trình phải được kết thúc một cách khéo léo để khi chúng kết thúc, không có dữ liệu nào bị hỏng và hệ thống sẽ hoạt động chính xác vào lần tiếp theo bạn bật nó. Nghĩa là, ngay cả trong trường hợp chấm dứt khẩn cấp, dữ liệu sẽ không bị hỏng (cơ chế giao dịch phù hợp ở đây, các truy vấn trong cơ sở dữ liệu chỉ hoạt động theo nhóm và nếu ít nhất một truy vấn trong nhóm không thành công hoặc được thực thi với lệnh thì trên thực tế không có truy vấn nào khác trong nhóm bị lỗi).
10. Phát triển/vận hành ứng dụng tương đương
Phiên bản sản xuất, dàn dựng và địa phương của ứng dụng phải khác nhau. Trong quá trình sản xuất, chúng tôi sử dụng khung Yii Lite và Yii cục bộ để nó hoạt động nhanh hơn trong quá trình sản xuất!
Trên thực tế, tất cả quá trình triển khai và làm việc với mã phải ở trong một môi trường gần như giống hệt nhau (chúng ta không nói về phần cứng vật lý). Ngoài ra, bất kỳ nhân viên phát triển nào cũng có thể triển khai mã vào sản xuất nếu cần thiết chứ không phải một số bộ phận dành cho nhà phát triển được đào tạo đặc biệt, chỉ nhờ sức mạnh đặc biệt mới có thể đưa ứng dụng vào sản xuất.
Docker cũng giúp chúng tôi việc này. Nếu tất cả các điểm trước đó được tuân thủ, việc sử dụng docker sẽ đưa quá trình triển khai môi trường cả trên sản xuất và trên máy cục bộ vào một hoặc hai lệnh.
11. Nhật ký
Chúng tôi viết nhật ký vào tập tin và cơ sở dữ liệu! Chúng tôi không xóa các tệp và cơ sở dữ liệu khỏi nhật ký. Hãy mua một ổ cứng có dung lượng 9000 Peta byte là được.
Tất cả nhật ký phải được coi là một luồng sự kiện. Bản thân ứng dụng không được tham gia vào quá trình xử lý nhật ký. Nhật ký phải được xuất ra thiết bị xuất chuẩn hoặc được gửi qua giao thức như udp, để việc làm việc với nhật ký không tạo ra bất kỳ vấn đề nào cho ứng dụng. Graylog tốt cho việc này. Graylog nhận tất cả nhật ký qua udp (giao thức này không yêu cầu chờ phản hồi về việc nhận gói thành công) không can thiệp vào ứng dụng dưới bất kỳ hình thức nào và chỉ xử lý cấu trúc và xử lý nhật ký. Logic ứng dụng không thay đổi để hoạt động với các phương pháp như vậy.
12. Nhiệm vụ quản trị
Để cập nhật dữ liệu, cơ sở dữ liệu, v.v., hãy sử dụng điểm cuối được tạo riêng trong API, việc thực thi điểm cuối này 2 lần liên tiếp sẽ khiến mọi thứ bị trùng lặp. Nhưng bạn không ngu ngốc, bạn sẽ không nhấp chuột hai lần và chúng tôi không cần di chuyển.
Tất cả các tác vụ quản trị phải được thực hiện trong cùng môi trường với tất cả mã, ở cấp độ phát hành. Nghĩa là, nếu chúng ta cần thay đổi cấu trúc của cơ sở dữ liệu thì chúng ta sẽ không thực hiện thủ công bằng cách thay đổi tên các cột và thêm cột mới thông qua một số công cụ quản lý cơ sở dữ liệu trực quan. Đối với những việc như vậy, chúng tôi tạo các tập lệnh riêng biệt - di chuyển, được thực thi ở mọi nơi và trong mọi môi trường theo cùng một cách với kết quả chung và dễ hiểu. Đối với tất cả các nhiệm vụ khác, chẳng hạn như điền dữ liệu vào dự án, nên sử dụng các phương pháp tương tự.
Ví dụ triển khai trong PHP, Laravel, Laradock, Docker-Compose
PS Tất cả các ví dụ được thực hiện trên MacOS. Hầu hết chúng cũng phù hợp với Linux. Người dùng Windows, hãy tha thứ cho tôi, nhưng tôi đã không làm việc với Windows trong một thời gian dài.
Hãy tưởng tượng một tình huống mà chúng ta không cài đặt bất kỳ phiên bản PHP nào trên PC của mình và không có gì cả.
Cài đặt phiên bản mới nhất của docker và docker-compose. (điều này có thể được tìm thấy trên Internet)
docker -v &&
docker-compose -v
1. Chúng tôi đặt
git clone https://github.com/Laradock/laradock.git &&
ls
Về Laradock, tôi sẽ nói rằng đó là một thứ rất hay, chứa rất nhiều thùng chứa và những thứ phụ trợ. Nhưng tôi không khuyên bạn nên sử dụng Laradock như vậy mà không sửa đổi trong quá trình sản xuất vì tính dư thừa của nó. Tốt hơn hết bạn nên tạo các vùng chứa của riêng mình dựa trên các ví dụ trong Laradock, điều này sẽ được tối ưu hóa hơn nhiều vì không ai cần mọi thứ ở đó cùng một lúc.
2. Cấu hình Laradock để chạy ứng dụng của chúng ta.
cd laradock &&
cp env-example .env
2.1. Mở thư mục habr (thư mục mẹ mà laradock được sao chép vào) trong một số trình soạn thảo. (Trong trường hợp PHPStorm của tôi)
Ở giai đoạn này, chúng tôi chỉ đặt tên cho dự án.
2.2. Khởi chạy hình ảnh không gian làm việc. (Trong trường hợp của bạn, hình ảnh sẽ mất một thời gian để xây dựng)
Không gian làm việc là hình ảnh được chuẩn bị đặc biệt để làm việc với khung thay mặt cho nhà phát triển.
Chúng tôi đi vào bên trong container bằng cách sử dụng
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Cài đặt Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Sau khi cài đặt, chúng tôi kiểm tra xem thư mục chứa dự án đã được tạo chưa và hủy soạn thảo.
ls
exit
docker-compose down
2.5. Hãy quay lại PHPStorm và đặt đường dẫn chính xác đến ứng dụng laravel của chúng ta trong tệp .env.
3. Thêm tất cả mã vào Git.
Để làm điều này, chúng tôi sẽ tạo một kho lưu trữ trên Github (hoặc bất kỳ nơi nào khác). Hãy vào thư mục habr trong terminal và thực thi đoạn mã sau.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status
Hãy kiểm tra xem mọi thứ có theo thứ tự không.
Để thuận tiện, tôi khuyên bạn nên sử dụng một số giao diện trực quan cho Git, trong trường hợp của tôi là . (đây là link giới thiệu)
4. Hãy khởi động!
Trước khi bắt đầu, hãy đảm bảo rằng không có gì treo trên cổng 80 và 443.
docker-compose up -d nginx php-fpm
Vì vậy, dự án của chúng tôi bao gồm 3 dịch vụ riêng biệt:
- nginx - máy chủ web
- php-fpm - php để nhận yêu cầu từ máy chủ web
- không gian làm việc - php dành cho nhà phát triển
Hiện tại, chúng tôi đã đạt được mục tiêu là đã tạo ra một ứng dụng đáp ứng 4 điểm trên 12, cụ thể là:
1. Cơ sở mã — tất cả mã đều nằm trong một kho lưu trữ (lưu ý nhỏ: việc thêm docker vào bên trong dự án laravel có thể đúng, nhưng điều này không quan trọng).
2. Sự phụ thuộc — Tất cả các phần phụ thuộc của chúng tôi đều được viết rõ ràng trong application/composer.json và trong mỗi Dockerfile của mỗi vùng chứa.
3. Dịch vụ hỗ trợ — Mỗi dịch vụ (php-fom, nignx, không gian làm việc) có hoạt động riêng và được kết nối từ bên ngoài và khi làm việc với một dịch vụ, dịch vụ kia sẽ không bị ảnh hưởng.
4. Процессы - mỗi dịch vụ là một quy trình. Mỗi dịch vụ không duy trì trạng thái nội bộ.
5. Ràng buộc cổng
docker ps
Như chúng ta có thể thấy, mỗi dịch vụ chạy trên cổng riêng và có thể truy cập được vào tất cả các dịch vụ khác.
6. Song song
Docker cho phép chúng tôi tạo ra nhiều quy trình của cùng một dịch vụ với tính năng cân bằng tải tự động giữa chúng.
Hãy dừng các container và chạy chúng qua cờ --tỉ lệ
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Như chúng ta có thể thấy, các bản sao đã được tạo của vùng chứa php-fpm. Chúng ta không cần thay đổi bất cứ điều gì khi làm việc với vùng chứa này. Chúng tôi cũng tiếp tục truy cập nó trên cổng 9000 và Docker điều chỉnh tải giữa các vùng chứa cho chúng tôi.
7. Khả năng dùng một lần - mỗi container có thể bị giết mà không gây hại cho nhau. Việc dừng hoặc khởi động lại vùng chứa sẽ không ảnh hưởng đến hoạt động của ứng dụng trong những lần khởi chạy tiếp theo. Mỗi container cũng có thể được nâng lên bất cứ lúc nào.
8. Phát triển ứng dụng/hoạt động tương đương - tất cả môi trường của chúng ta đều giống nhau. Bằng cách chạy hệ thống trên máy chủ trong quá trình sản xuất, bạn sẽ không phải thay đổi bất kỳ điều gì trong lệnh của mình. Mọi thứ sẽ dựa trên Docker theo cùng một cách.
9. Ghi nhật ký — tất cả nhật ký trong các vùng chứa này đều được phát trực tuyến và hiển thị trong bảng điều khiển Docker. (trên thực tế, trong trường hợp này, với các hộp đựng tự chế khác, điều này có thể không xảy ra nếu bạn không chăm sóc nó)
docker-compose logs -f
Nhưng có một nhược điểm là các giá trị Mặc định trong PHP và Nginx cũng ghi nhật ký vào một tệp. Để đáp ứng được 12 yếu tố đó thì cần thiết vô hiệu hóa ghi nhật ký vào một tệp trong cấu hình của từng vùng chứa riêng biệt.
Docker cũng cung cấp khả năng gửi nhật ký không chỉ tới thiết bị xuất chuẩn mà còn tới những thứ như Graylog mà tôi đã đề cập ở trên. Và bên trong Graylog, chúng tôi có thể vận hành nhật ký theo ý muốn và ứng dụng của chúng tôi sẽ không nhận thấy điều này theo bất kỳ cách nào.
10. Nhiệm vụ quản trị — tất cả các nhiệm vụ quản trị đều được giải quyết bằng laravel nhờ vào công cụ thủ công chính xác như những gì người tạo ra ứng dụng 12 yếu tố mong muốn.
Để làm ví dụ, tôi sẽ chỉ ra cách thực hiện một số lệnh.
Chúng tôi đi vào container.
docker-compose exec workspace bash
php artisan list
Bây giờ chúng ta có thể sử dụng bất kỳ lệnh nào. (xin lưu ý rằng chúng tôi không định cấu hình cơ sở dữ liệu và bộ đệm, vì vậy một nửa số lệnh sẽ không được thực thi chính xác vì chúng được thiết kế để hoạt động với bộ đệm và cơ sở dữ liệu).
11. Cấu hình và 12. Xây dựng, phát hành, chạy
Tôi muốn dành phần này cho Triển khai Xanh-Xanh, nhưng hóa ra nó lại quá rộng cho bài viết này. Tôi sẽ viết một bài riêng về việc này.
Tóm lại, khái niệm này dựa trên các hệ thống CI/CD như Jenkins и CI Gitlab. Trong cả hai, bạn có thể đặt các biến môi trường được liên kết với một môi trường cụ thể. Theo đó, trong trường hợp này sẽ thỏa mãn điểm c Cấu hình.
Và vấn đề về Xây dựng, phát hành, chạy được giải quyết bằng các hàm dựng sẵn có tên Pipeline.
Pipeline cho phép bạn chia quá trình triển khai thành nhiều giai đoạn, trong đó nổi bật là giai đoạn lắp ráp, phát hành và thực thi. Cũng trong Pipeline, bạn có thể tạo bản sao lưu và thực sự là bất cứ thứ gì. Đây là một công cụ có tiềm năng vô hạn.
Mã ứng dụng có tại .
Đừng quên khởi tạo mô hình con khi sao chép kho lưu trữ này.
Tái bút: Tất cả các phương pháp này có thể được sử dụng với bất kỳ tiện ích và ngôn ngữ lập trình nào khác. Điều chính là bản chất không khác nhau.
Nguồn: www.habr.com