Thực hành tốt nhất cho phiên bản thẻ docker là gì?


11

Gần đây tôi đã nối các máy chủ CI của chúng tôi để xây dựng hình ảnh docker theo cam kết git.

Chúng tôi có khoảng 8 container khác nhau được xây dựng, mỗi container có ngôn ngữ / khung riêng. Một số là nút và có gói.json, số khác là các dịch vụ python không chứa thông tin phiên bản ngữ nghĩa.

Câu hỏi của tôi không phải là về cách tạo thẻ, mà là về việc tạo các giá trị cho thẻ.

Làm cách nào để đảm bảo mỗi thẻ có số phiên bản ngữ nghĩa duy nhất cho các hình ảnh cụ thể? Ai nên là người có thẩm quyền theo dõi / tăng phiên bản xây dựng?


Cách tiếp cận hiện tại của bạn để tạo các thẻ là gì?
030

Nó được nghe để xem những gì bạn đang yêu cầu. Bạn nói "số phiên bản ngữ nghĩa", phải được gán cho con người (AI của chúng ta chưa đủ tiến bộ để quyết định ngữ nghĩa của một cam kết chưa ...). Nhưng sau đó bạn hỏi về "tăng phiên bản xây dựng". Sau đó, những gì bạn thực sự quan tâm? Bạn có chắc chắn rằng các công cụ chỉ "tăng" (như số thay đổi SCN / hệ thống hoặc bất cứ điều gì) không? Hoặc bạn có quan tâm đến nội dung ngữ nghĩa của số phiên bản (nghĩa là nó có thay đổi không tương thích không)?
AnoE

Câu trả lời:


6

Tôi sẽ hướng dẫn bạn đến bài đăng của tôi Ghép nối đăng ký docker và kiểm soát nguồn trong đó dmaze đã trả lời từ các diễn đàn chính thức.docker.com . Cam kết băm và tên chi nhánh hoặc thẻ đủ.

Trong Dockerfile của bạn, sử dụng LABEL để ghi lại nguồn của bản dựng. Điều đó có thể bao gồm hàm băm cam kết từ kiểm soát nguồn phân tán (git, Mercurial), tên chi nhánh nếu có liên quan, bất kỳ thẻ phát hành nào nếu có và có thể là chi tiết như dấu thời gian của cam kết cuối cùng. lịch sử docker và kiểm tra docker sẽ có thể hiển thị những điều này.

Khi bạn docker đẩy hình ảnh của mình, hãy đẩy chúng ít nhất hai lần, với hàm băm cam kết và với tên nhánh là phần Phiên bản của một phần (quay.io/mycorp/imagename:123abc7, quay.io/mycorp/imagename:dmaze-test ). Nếu các thẻ phát hành có sẵn, hệ thống CI cũng sẽ đẩy hình ảnh với các thẻ này.

Chúng tôi hiện đang sử dụng kết hợp tên nhánh / hàm băm. Đối với chúng tôi điều đó dường như là đủ. dấu thời gian trong khi chúng hữu ích IMO chỉ cần thêm lộn xộn vì chúng không cung cấp bất cứ thứ gì mà hàm băm cam kết không có.

Tôi đồng ý với 030 về:

ai sẽ là người có thẩm quyền theo dõi / tăng phiên bản xây dựng

100% là trách nhiệm của CI để duy trì những điều đó, với sự liên lạc đúng đắn giữa các đội khác.


1

Làm cách nào để đảm bảo mỗi thẻ có số phiên bản ngữ nghĩa duy nhất cho các hình ảnh cụ thể?

Người ta có thể tạo một thẻ bao gồm nhiều yếu tố, ví dụ như sự kết hợp của dấu thời gian, git commit hash và phiên bản ngữ nghĩa. Cái sau phải được đặt bằng tay, trong khi hai cái đầu tiên có thể được tự động. Một thẻ như vậy có thể trông như sau:

20171015141729-58617f500f7efe236c7ba6a1dfdf37a478b4c878-0.1.4

Thẻ này chứa ngày xây dựng, cam kết và phiên bản ngữ nghĩa. Nếu một hình ảnh docker chạy trong sản xuất và tìm thấy một lỗi thì người ta sẽ biết phiên bản của sản phẩm, mã bên trong và khi hình ảnh được xây dựng và trong hoàn cảnh nào.

Ai nên là người có thẩm quyền theo dõi / tăng phiên bản xây dựng?

Theo tôi, đây phải là trách nhiệm của CI vì điều này có thể tự động hóa các quy trình và vì việc tạo thẻ có thể được tự động hóa, một công cụ như vậy là công cụ phù hợp cho công việc.


1

Tôi cho rằng bạn sử dụng một trong những công cụ DevOps cho CI / CD như Jenkins, tôi đề xuất cách tiếp cận sau,

Nếu bạn sử dụng một cái gì đó như Jenkins-

  • Bạn có thể định cấu hình công việc của mình sao cho có thể sử dụng biến môi trường Jenkins "BUILD_ID", lấy ra id xây dựng của công việc khi được kích hoạt để gắn thẻ vào hình ảnh của bạn. Bằng cách này, bạn có thể phiên bản kiểm soát hình ảnh docker của bạn. Vui lòng kiểm tra ví dụ dưới đây.

Ví dụ:- sudo docker build -t <image_name>:<BUILD_ID>

Vì vậy, nếu bạn đã có cơ chế giống như thẻ cho SCM của mình, bạn có thể kiểm tra thẻ trong ID bản dựng tương ứng trong các bản dựng dựa trên công việc hoặc trong tệp cấu hình của ID bản dựng trong JENKINS HOME_FOLDER.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.