Muộn còn hơn không. Hoặc làm thế nào chúng tôi gần như đã mắc một sai lầm nghiêm trọng khi không hỗ trợ Dockerfiles thông thường để xây dựng hình ảnh ứng dụng.
Nó sẽ về - Tiện ích GitOps tích hợp với bất kỳ hệ thống CI / CD nào và cung cấp khả năng quản lý toàn bộ vòng đời của ứng dụng, cho phép bạn:
- thu thập và xuất bản hình ảnh,
- triển khai các ứng dụng lên Kubernetes,
- xóa các hình ảnh không sử dụng bằng các chính sách đặc biệt.
Triết lý của dự án là tập hợp các công cụ cấp thấp thành một hệ thống thống nhất duy nhất cho phép các kỹ sư DevOps kiểm soát các ứng dụng. Nếu có thể, nên sử dụng các tiện ích hiện có (như Helm và Docker). Nếu không có giải pháp cho một số vấn đề, chúng ta có thể tạo và duy trì mọi thứ cần thiết cho việc này.
Bối cảnh: bộ sưu tập hình ảnh của riêng bạn
Đây là điều đã xảy ra với trình tạo hình ảnh trong werf: chúng tôi thiếu Dockerfile thông thường. Nếu bạn nhanh chóng đi sâu vào lịch sử của dự án, thì vấn đề này đã xuất hiện trong các phiên bản đầu tiên của werf (sau đó ).
Trong khi tạo một công cụ để xây dựng ứng dụng thành hình ảnh Docker, chúng tôi nhanh chóng nhận ra rằng Dockerfile không phù hợp với chúng tôi đối với một số tác vụ rất cụ thể:
- Nhu cầu lắp ráp các ứng dụng web nhỏ điển hình theo sơ đồ tiêu chuẩn sau:
- cài đặt các phụ thuộc trên toàn hệ thống của ứng dụng,
- cài đặt một gói thư viện phụ thuộc ứng dụng,
- thu thập tài sản,
- và quan trọng nhất là cập nhật code trong ảnh một cách nhanh chóng và hiệu quả.
- Khi các thay đổi được thực hiện đối với các tệp dự án, người xây dựng phải nhanh chóng tạo một lớp mới bằng cách vá các tệp đã thay đổi.
- Nếu một số tệp nhất định đã thay đổi, thì giai đoạn phụ thuộc tương ứng phải được xây dựng lại.
Ngày nay, có nhiều khả năng khác trong vòi của chúng tôi, nhưng những mong muốn và thôi thúc ban đầu là như sau.
Nói chung, không cần suy nghĩ kỹ, chúng tôi đã trang bị cho mình ngôn ngữ lập trình được sử dụng (xem bên dưới) và lên đường - để thực hiện DSL riêng! Theo các nhiệm vụ đã đặt, nó nhằm mô tả quá trình xây dựng theo từng giai đoạn và xác định sự phụ thuộc của các giai đoạn này vào các tệp. Và bổ sung nó vòi riêng, đã biến DSL thành mục tiêu cuối cùng - hình ảnh được lắp ráp. Lúc đầu, DSL có trong Ruby, nhưng khi - cấu hình của trình thu thập của chúng tôi bắt đầu được mô tả trong tệp YAML.
Cấu hình cũ cho dapp trong Ruby
Cấu hình thực tế cho werf trên YAML
Cơ chế của bộ sưu tập cũng thay đổi theo thời gian. Lúc đầu, chúng tôi chỉ đơn giản là tạo một số Dockerfile tạm thời từ cấu hình của mình một cách nhanh chóng, sau đó chúng tôi bắt đầu chạy các hướng dẫn xây dựng trong các vùng chứa tạm thời và thực hiện một cam kết.
NB: Hiện tại, trình tạo của chúng tôi, hoạt động với cấu hình riêng (trong YAML) và được gọi là trình tạo Stapel, đã phát triển thành một công cụ khá mạnh. Mô tả chi tiết của nó xứng đáng có các bài báo riêng biệt và các chi tiết chính có thể được tìm thấy trong .
Nhận thức về vấn đề
Nhưng chúng tôi nhận ra, và không phải ngay lập tức, rằng chúng tôi đã phạm một sai lầm: chúng tôi đã không bổ sung khả năng xây dựng hình ảnh thông qua Dockerfile tiêu chuẩn và tích hợp chúng vào cùng một cơ sở hạ tầng quản lý ứng dụng đầu cuối (tức là thu thập hình ảnh, triển khai và làm sạch chúng). Làm cách nào bạn có thể tạo một công cụ triển khai trong Kubernetes và không triển khai hỗ trợ Dockerfile, tức là một cách tiêu chuẩn để mô tả hình ảnh cho hầu hết các dự án?..
Thay vì trả lời một câu hỏi như vậy, chúng tôi đưa ra giải pháp của nó. Điều gì sẽ xảy ra nếu bạn đã có Dockerfile (hoặc một bộ Dockerfile) và muốn sử dụng werf?
NB: Nhân tiện, tại sao bạn lại muốn sử dụng werf? Các tính năng chính tóm tắt như sau:
- chu trình quản lý ứng dụng đầy đủ bao gồm làm sạch hình ảnh;
- khả năng quản lý việc lắp ráp nhiều hình ảnh cùng một lúc từ một cấu hình duy nhất;
- cải tiến quy trình triển khai cho các biểu đồ tương thích với Helm.
Một danh sách đầy đủ hơn có thể được tìm thấy tại .
Vì vậy, nếu trước đây chúng tôi khuyên bạn nên viết lại Dockerfile vào cấu hình của mình, thì bây giờ chúng tôi rất vui khi nói: “Hãy để chúng tôi xây dựng Dockerfiles của bạn!”
Cách sử dụng?
Việc triển khai đầy đủ tính năng này đã xuất hiện trong bản phát hành . Nguyên tắc chung rất đơn giản: người dùng chỉ định đường dẫn đến Dockerfile hiện có trong cấu hình werf, sau đó chạy lệnh werf build... và thế là xong - werf sẽ xây dựng hình ảnh. Hãy xem xét một ví dụ trừu tượng.
Hãy thông báo tiếp theo Dockerfile ở gốc của dự án:
FROM ubuntu:18.04
RUN echo Building ...
Và chúng tôi sẽ thông báo werf.yamlsử dụng cái này Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Tất cả! Bên trái chạy werf build:
Ngoài ra, bạn có thể khai báo như sau werf.yaml để xây dựng một số hình ảnh cùng một lúc từ các Dockerfile khác nhau:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Cuối cùng, việc chuyển các tham số bản dựng bổ sung cũng được hỗ trợ - chẳng hạn như --build-arg и --add-host - thông qua cấu hình werf. Mô tả đầy đủ về cấu hình hình ảnh Dockerfile có sẵn tại .
Nó hoạt động như thế nào?
Trong quá trình xây dựng, bộ đệm tiêu chuẩn của các lớp cục bộ trong các hàm Docker. Tuy nhiên, quan trọng là, người sói cũng tích hợp cấu hình Dockerfile vào cơ sở hạ tầng của nó. Điều đó có nghĩa là gì?
- Mỗi hình ảnh được tạo từ Dockerfile bao gồm một giai đoạn duy nhất được gọi là
dockerfile(thêm về các giai đoạn trong werf, bạn có thể đọc ). - cho sân khấu
dockerfilewerf tính toán chữ ký phụ thuộc vào nội dung của cấu hình Dockerfile. Thay đổi cấu hình Dockerfile sẽ thay đổi chữ ký giai đoạndockerfilevà werf sẽ bắt đầu xây dựng lại giai đoạn đó với cấu hình Dockerfile mới. Nếu chữ ký không thay đổi, thì werf sẽ lấy hình ảnh từ bộ đệm (thêm về việc sử dụng chữ ký trong werf đã được mô tả trong ). - Hơn nữa, các hình ảnh được thu thập có thể được xuất bản bằng lệnh
werf publish(hoặcwerf build-and-publish) và sử dụng nó để triển khai lên Kubernetes. Các hình ảnh đã xuất bản trong Docker Registry sẽ được làm sạch bằng các công cụ dọn dẹp werf tiêu chuẩn, tức là. sẽ có quá trình dọn dẹp tự động các hình ảnh cũ (cũ hơn N ngày), hình ảnh được liên kết với các nhánh Git không tồn tại và các chính sách khác.
Thông tin chi tiết về các điểm được mô tả ở đây có thể được tìm thấy trong tài liệu:
- ;
- ;
- .
Lưu ý và biện pháp phòng ngừa
1. URL bên ngoài trong ADD không được hỗ trợ
Việc sử dụng một URL bên ngoài trong một lệnh hiện không được hỗ trợ. ADD. Werf sẽ không kích hoạt quá trình xây dựng lại khi tài nguyên tại URL đã chỉ định thay đổi. Tính năng này dự kiến sẽ sớm được bổ sung.
2. Bạn không thể thêm .git vào hình ảnh
Nói chung, thêm một thư mục .git vào một hình ảnh là một thực tế tồi tệ và đây là lý do:
- Nếu
.gitvẫn còn trong hình ảnh cuối cùng, điều này vi phạm các nguyên tắc : vì hình ảnh kết quả phải được liên kết với một lần xác nhận, nên không thể thực hiện đượcgit checkoutcam kết tùy ý. -
.gittăng kích thước của hình ảnh (kho lưu trữ có thể lớn do thực tế là các tệp lớn đã từng được thêm vào và sau đó bị xóa). Kích thước của cây công việc chỉ được liên kết với một cam kết cụ thể sẽ không phụ thuộc vào lịch sử hoạt động trong Git. Trong trường hợp này, việc bổ sung và loại bỏ tiếp theo.gittừ hình ảnh cuối cùng sẽ không hoạt động: hình ảnh vẫn sẽ có thêm một lớp - đây là cách Docker hoạt động. - Docker có thể kích hoạt quá trình xây dựng lại không cần thiết ngay cả khi cùng một cam kết đang được xây dựng từ các cây công việc khác nhau. Ví dụ: GitLab tạo các thư mục nhân bản riêng biệt trong
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectvới kích hoạt lắp ráp song song. Việc xây dựng lại thêm sẽ là do thư mục.gitkhác nhau trong các phiên bản nhân bản khác nhau của cùng một kho lưu trữ, ngay cả khi cùng một cam kết được xây dựng.
Điểm cuối cùng cũng có hậu quả khi sử dụng werf. Werf yêu cầu phải có bộ đệm được xây dựng khi chạy một số lệnh (ví dụ: werf deploy). Trong quá trình thực hiện các lệnh như vậy, werf tính toán các dấu hiệu giai đoạn cho các hình ảnh được chỉ định trong werf.yamlvà chúng phải nằm trong bộ đệm bản dựng, nếu không lệnh sẽ không thể tiếp tục. Nếu chữ ký của các giai đoạn phụ thuộc vào nội dung .git, sau đó chúng tôi nhận được một bộ đệm không ổn định trước những thay đổi trong các tệp không liên quan và werf sẽ không thể tha thứ cho sự giám sát như vậy (để biết thêm chi tiết, xem ).
Nói chung, chỉ thêm một số tệp cần thiết thông qua hướng dẫn ADD trong mọi trường hợp làm tăng hiệu quả và độ tin cậy của văn bản Dockerfile, đồng thời cải thiện tính ổn định của bộ nhớ đệm do ứng dụng này thu thập Dockerfile, với những thay đổi không liên quan trong Git.
Tổng
Con đường ban đầu của chúng tôi với việc viết trình xây dựng của riêng mình cho các nhu cầu cụ thể rất khó khăn, trung thực và đơn giản: thay vì sử dụng nạng trên Dockerfile tiêu chuẩn, chúng tôi đã viết giải pháp của riêng mình bằng cú pháp tùy chỉnh. Và điều này đã mang lại lợi thế cho nó: bộ sưu tập Stapel thực hiện công việc của nó một cách hoàn hảo.
Tuy nhiên, trong quá trình viết trình xây dựng của riêng mình, chúng tôi đã đánh mất sự hỗ trợ cho các Dockerfile hiện có. Hiện tại, thiếu sót này đã được khắc phục và trong tương lai, chúng tôi dự định phát triển hỗ trợ Dockerfile cùng với trình tạo Stapel tùy chỉnh của chúng tôi cho các bản dựng phân tán và để xây dựng bằng Kubernetes (tức là xây dựng trên các trình chạy bên trong Kubernetes, như đã thực hiện trong kaniko).
Vì vậy, nếu bạn đột nhiên có một vài Dockerfile nằm xung quanh ... cố gắng !
PS Danh sách tài liệu về chủ đề
- ;
- ;
- ;
- ;
- ;
- ;
- .
Đọc thêm trên blog của chúng tôi:'.
Nguồn: www.habr.com