Tôi nên sử dụng Dockerfiles hoặc cam kết hình ảnh?

Tôi hơi bối rối về hai lựa chọn này. Chúng dường như có liên quan. Tuy nhiên, chúng không thực sự tương thích.

Ví dụ: có vẻ như việc sử dụng Dockerfiles có nghĩa là bạn không thực sự cam kết với hình ảnh, bởi vì bạn thực sự chỉ nên theo dõi Dockerfile trong git và thực hiện các thay đổi đối với điều đó. Sau đó, không có sự mơ hồ về những gì là có thẩm quyền.

Tuy nhiên, hình ảnh cam kết có vẻ thực sự tốt đẹp. Thật tuyệt vời khi bạn có thể sửa đổi trực tiếp vùng chứa và gắn thẻ các thay đổi để tạo một hình ảnh khác. Tôi hiểu rằng bạn thậm chí có thể nhận được một cái gì đó như hệ thống tệp khác với lịch sử cam kết hình ảnh. Tuyệt vời. Nhưng sau đó bạn không nên sử dụng Dockerfiles. Mặt khác, nếu bạn đã thực hiện cam kết hình ảnh, bạn phải quay lại Dockerfile của mình và thực hiện một số thay đổi thể hiện những gì bạn đã làm.

Vì vậy, tôi bị rách. Tôi thích ý tưởng về cam kết hình ảnh: rằng bạn không cần phải đại diện trạng thái hình ảnh của mình trong Dockerfile - bạn có thể theo dõi trực tiếp. Nhưng tôi không thoải mái về việc từ bỏ ý tưởng về một số loại tệp kê khai cung cấp cho bạn cái nhìn tổng quan nhanh về những gì trong một hình ảnh. Thật khó chịu khi thấy hai tính năng trong cùng một gói phần mềm dường như không tương thích.

Có ai có bất cứ suy nghĩ về điều này? Sử dụng cam kết hình ảnh có bị coi là hành vi xấu không? Hay tôi chỉ nên loại bỏ tệp đính kèm của mình với các tệp kê khai từ những ngày Con rối của tôi? Tôi nên làm gì?

Cập nhật :

Đối với tất cả những người nghĩ rằng đây là một câu hỏi dựa trên ý kiến, tôi không chắc lắm. Nó có một số phẩm chất chủ quan, nhưng tôi nghĩ đó chủ yếu là một câu hỏi khách quan. Hơn nữa, tôi tin rằng một cuộc thảo luận tốt về chủ đề này sẽ có nhiều thông tin.

Cuối cùng, tôi hy vọng rằng bất cứ ai đọc bài đăng này sẽ hiểu rõ hơn về cách Dockerfiles và các cam kết hình ảnh có liên quan với nhau.

Cập nhật - 2017/7/18 :

Tôi vừa mới phát hiện ra một cách sử dụng hợp pháp cho cam kết hình ảnh. Chúng tôi vừa thiết lập đường ống CI tại công ty của mình và trong một giai đoạn của quá trình này, các thử nghiệm ứng dụng của chúng tôi được chạy bên trong một vùng chứa. Chúng tôi cần truy xuất các kết quả về phạm vi từ vùng chứa đã thoát sau khi quá trình chạy thử nghiệm đã tạo chúng (trong hệ thống tệp của vùng chứa) và vùng chứa đã ngừng chạy. Chúng tôi sử dụng các cam kết hình ảnh để thực hiện việc này bằng cách cam kết vùng chứa đã dừng để tạo một hình ảnh mới và sau đó chạy các lệnh hiển thị và kết xuất tệp bao phủ sang stdout. Vì vậy, thật tiện lợi khi có cái này. Ngoài trường hợp rất cụ thể này, chúng tôi sử dụng Dockerfiles để xác định môi trường của chúng tôi.

Dockerfiles là một công cụ được sử dụng để tạo hình ảnh.

Kết quả của việc chạy docker build .là một hình ảnh có một cam kết, vì vậy không thể sử dụng Dockerfile mà không tạo một cam kết . Câu hỏi đặt ra là bạn có nên cập nhật hình ảnh bằng tay mỗi khi có bất cứ điều gì thay đổi và như vậy sẽ tự kết liễu mình trước lời nguyền của hình ảnh vàng không?

Lời nguyền của hình ảnh vàng là một lời nguyền khủng khiếp giáng xuống những người phải tiếp tục sống với một hình ảnh cơ sở có lỗ hổng bảo mật đầy lỗi để chạy phần mềm của họ bởi vì người tạo ra nó đã bị người cổ đại nuốt chửng từ lâu (hoặc chuyển sang một công việc mới) và không ai biết họ lấy phiên bản imagemagic ở đâu vào hình ảnh đó. và là thứ duy nhất sẽ liên kết với mô-đun c ++ được cung cấp bởi nhà tư vấn đó mà con trai của ông chủ đã thuê ba năm trước, và dù sao thì điều đó cũng không quan trọng bởi vì ngay cả khi bạn đã tìm ra imagemagic đến từ phiên bản libstdc ++ được sử dụng bởi JNI gọi công cụ hỗ trợ thực tập với mái tóc dài được tạo ra chỉ tồn tại trong phiên bản ubuntu không được hỗ trợ.

Biết cả hai giải pháp thuận lợi và bất tiện là một khởi đầu tốt. Bởi vì sự kết hợp của cả hai có lẽ là một cách hợp lệ để đi.

Con: tránh hình ảnh vàng chết chóc:

Chỉ sử dụng các cam kết là không tốt nếu bạn không biết cách xây dựng lại hình ảnh của mình. Bạn không muốn rơi vào tình trạng không thể xây dựng lại hình ảnh . Trạng thái cuối cùng này ở đây được gọi là hình ảnh vàng vì hình ảnh sẽ là tài liệu tham khảo duy nhất của bạn, điểm bắt đầu và điểm kết thúc ở mỗi giai đoạn. Nếu bạn làm mất nó, bạn sẽ gặp rất nhiều rắc rối vì bạn không thể xây dựng lại nó. Kết thúc chết người là một ngày nào đó bạn sẽ cần phải xây dựng lại một cái mới (vì ví dụ như tất cả hệ thống lib đều đã lỗi thời) và bạn sẽ không biết phải cài đặt cái gì ... kết thúc bằng việc mất nhiều thời gian.

Một lưu ý nhỏ là , có thể việc sử dụng các cam kết thay vì các cam kết sẽ đẹp hơn nếu nhật ký lịch sử có thể dễ dàng sử dụng (tham khảo các điểm khác biệt và lặp lại chúng trên các hình ảnh khác) như trong git: bạn sẽ nhận thấy rằng git không có tiến thoái lưỡng nan này.

Pro: nâng cấp mượt mà để phân phối

Mặt khác, cam kết phân lớp có một số lợi thế đáng kể về mặt nâng cấp phân tán và do đó về băng thông và thời gian triển khai. Nếu bạn bắt đầu xử lý hình ảnh docker khi một thợ làm bánh đang xử lý bánh kếp (chính xác là những gì docker cho phép) hoặc muốn triển khai phiên bản thử nghiệm ngay lập tức, bạn sẽ vui hơn khi chỉ gửi một bản cập nhật nhỏ dưới dạng một cam kết nhỏ thay vì hình ảnh hoàn toàn mới. Đặc biệt khi có tích hợp liên tục cho khách hàng của bạn, nơi sửa lỗi nên được triển khai sớm và thường xuyên.

Cố gắng tận dụng tối đa hai thế giới:

Trong loại tình huống này, có thể bạn sẽ muốn gắn thẻ phiên bản chính của hình ảnh của mình và chúng phải đến từ đâu Dockerfiles. Và bạn có thể cung cấp các phiên bản tích hợp liên tục nhờ các cam kết dựa trên phiên bản được gắn thẻ. Điều này giảm thiểu những ưu điểm và bất tiện của Dockerfiles và kịch bản cam kết phân lớp. Ở đây, điểm mấu chốt là bạn không bao giờ ngừng theo dõi hình ảnh của mình bằng cách giới hạn số lượng cam kết bạn sẽ cho phép thực hiện trên chúng.

Vì vậy, tôi đoán nó phụ thuộc vào kịch bản của bạn, và bạn có thể không nên cố gắng tìm một quy tắc duy nhất. Tuy nhiên, có thể có một số kết thúc thực sự mà bạn thực sự nên tránh (như kết thúc với một kịch bản "hình ảnh vàng") bất kể giải pháp nào.