Làm cách nào để cấu trúc mã và cấu hình liên quan đến DevOps trong kho lưu trữ mã?


10

Chúng tôi đã phát triển như một công ty, các sản phẩm của chúng tôi đang mở rộng và các hoạt động và nỗ lực liên quan đến DevOps của chúng tôi cũng đang phát triển - chúng tôi đã chuyển từ Tre sang Jenkins linh hoạt hơn và có thể định cấu hình hơn, sử dụng các đường ống triển khai và các plugin khác; chuyển sang Ansible và bắt đầu sử dụng Docker tại đây và bên trong.

Tất cả những điều này đòi hỏi một số mức độ mã hóa hoặc cấu hình - Các tập lệnh và cấu hình Ansible, tập lệnh Groovy Jenkins, Dockerfiles và cấu hình YAML.

Còn bây giờ, chúng tôi đã tạo một riêng "ops" kho với thư mục cấp cao cho jenkins, ansible, dockerother(đó là một tên khủng khiếp, nhưng bây giờ tất cả mọi thứ DevOps "khác" tự động hóa đang có).

Cách tiếp cận của chúng tôi không cảm thấy đúng và có thể không mở rộng, nhưng các thực tiễn và khuyến nghị tốt nhất để giữ mã liên quan đến DevOps trong kho lưu trữ hoặc kho lưu trữ mã là gì?


6
Tôi sử dụng phương pháp "mỗi phần là một ứng dụng, một repo cho mỗi ứng dụng", trong đầu bếp có nghĩa là 1 repo cho mỗi sách nấu ăn.
Tensibai

@Tensibai đúng, tôi sợ rằng một repo "ops" duy nhất sẽ nhanh chóng trở nên không thực tế. Cảm ơn.
alecxe

1
Đó là hình thức quản lý sách dạy nấu ăn trong đầu bếp, 1 repo với tất cả sách dạy nấu ăn và đã chứng minh một khẩu súng ngắn trong hầu hết các trường hợp do đó thay đổi, nhưng tôi không thoải mái khi nói rằng nó cũng phù hợp với các đường ống của Jenkins (nếu v2) và Các tệp tin docker phải phù hợp với dự án mà họ xử lý IMO và tôi không biết bạn đặt cái gì khác nên tôi thực sự không thể đưa ra bất kỳ lời khuyên nào ở đây
Tensibai

@Tensibai hiểu rồi! Khác bao gồm hầu hết các tiện ích bash và python hoặc tập lệnh được thực thi định kỳ cho nhiều công cụ nội bộ..họ không thực sự phù hợp ở bất cứ đâu và chúng tôi không thể nghĩ ra nơi nào tốt hơn "khác" .. Tôi sẽ xem liệu tôi có thể đăng nội dung không của các thư mục vào câu hỏi là tốt. Cảm ơn.
alecxe

1
Tôi đã chia chúng thành nhiều repo theo 'mối quan hệ' công việc, các tập lệnh hoạt động trên ứng dụng X cùng nhau, bạn có thể có một tập lệnh được sử dụng trên hai ứng dụng, nhưng nếu ứng dụng Thay đổi cách xử lý tập lệnh mà ứng dụng nói đến , tốt hơn là nên có hai phiên bản riêng biệt, vì vậy ATEOTD tôi sẽ lưu trữ chúng với ứng dụng mà chúng liên quan hoặc nếu chúng mở rộng nhiều ứng dụng trong một kho lưu trữ cụ thể cho mỗi tác vụ, vì vậy bạn luôn có phiên bản phù hợp với các ứng dụng đã triển khai và bạn không Không cần phải gắn thẻ một tập lệnh không liên quan cùng một lúc.
Tensibai

Câu trả lời:


3

Tổ chức hiện tại của mã và cấu hình mà bạn mô tả được cấu trúc bởi các giải pháp kỹ thuật liên quan. Đây là một thiết kế tồi sẽ thêm rất nhiều chi phí trong hoạt động bảo trì của chúng tôi và cũng sẽ thêm rất nhiều bẫy theo cách của chúng tôi. Thay vào đó, tổ chức đó nên được cấu trúc xung quanh các đồ tạo tác chúng tôi đang triển khai.

Lý do cho điều này là vì chúng tôi muốn xem xét các đồ tạo tác ( ví dụ hình ảnh docker hoặc gói phần mềm) làm đối tượng của các động từ sau:

  • xây dựng
  • kiểm tra
  • triển khai

để xem xét một tập hợp tối thiểu các tác vụ tự động mà chúng tôi muốn thực hiện. Nếu chúng ta muốn thay đổi điều gì đó về cách triển khai động từ kiểm tra, bạn có thể dễ dàng truy cập thư mục tương ứng với vật phẩm đó trong kho lưu trữ thích hợp và sau đó khám phá các mục tự động hóa cụ thể của jenkins cần được cập nhật. Thay vào đó, nếu các công thức tự động hóa được cấu trúc xung quanh các giải pháp kỹ thuật, thì chúng ta cần tìm ra màu xanh mà jenkins có liên quan đến các quy trình thử nghiệm và tìm thấy ở đó các vật phẩm tự động hóa liên quan. Trong các tình huống phức tạp, tổ chức xung quanh các giải pháp kỹ thuật thực hiện cập nhật rất khó khăn, bởi vì chúng tôi phải biết một tiên nghiệm tất cả các giải pháp kỹ thuật liên quan đến một số dịch vụ để cập nhật chúng cho phù hợp.

Ví dụ, một kho lưu trữ chứa mã cho một trang web và một dịch vụ vi mô có thể có các thư mục con sau đây dành riêng cho các hoạt động:

./ops/website
./ops/micro-service-a

từng có ba kịch bản gọi là build, testdeploy. Bây giờ, việc tổ chức các mục tự động hóa bằng cách nào đó đã được làm rõ, chúng ta hãy chú ý đến cấu hình.

Các điều kiện và yêu cầu chính về tổ chức cấu hình được đặt bởi deployđộng từ khi được áp dụng trên một vật phẩm giống như dịch vụ. Các deployđộng từ phải có các thông số sau:

  • phiên bản của vật phẩm để triển khai,
  • mục tiêu triển khai của vật phẩm, mô tả môi trường cụ thể nơi vật phẩm được triển khai sẽ chạy ( ví dụ: một cụm và các điểm cuối cần nói chuyện)
  • thông tin đăng nhập cần sử dụng để kết nối với các điểm cuối khác ( ví dụ: cơ sở dữ liệu)
  • cấu hình thời gian chạy của (như thời gian lưu bộ nhớ cache sẽ tồn tại, v.v.)

Từ góc độ hoạt động, sự cố này của tham số hóa phù hợp với mức độ tự do tự nhiên của vấn đề triển khai - ngoài các thông tin có thể đi kèm với cấu hình thời gian chạy, nhưng tốt hơn là nên tách chúng ra để tránh lây lan chúng một cách bất cẩn.


5

Tôi có thể trả lời bout docker, một trong những cách tốt nhất để sử dụng docker là giữ tệp docker và soạn các tệp trong cùng một kho lưu trữ của dự án, vì vậy, bất cứ khi nào bạn sao chép dự án, bạn có thể xây dựng hình ảnh docker, và thật tốt khi giữ nhiều phiên bản của docker soạn các tệp chẳng hạn (prod, staging, dev) để bạn có thể xây dựng hình ảnh và chạy container với tùy chọn cụ thể cho từng env, ví dụ cho máy dev, bạn có thể sử dụng mạng cụ thể và chạy thêm container phụ thuộc hoặc bất cứ thứ gì.


4

Mã của mỗi công cụ đi vào repo riêng của nó. ví dụ

  1. Jenkins Groovy mẫu vào một repo Jenkins
  2. Playbook Ansible YAML trong repo riêng của mình (với các vai trò, nhiệm vụ, thư mục phụ hàng tồn kho
  3. Các mẫu Cloudform / Terrform trong repo của chính nó
  4. Docker tập tin của riêng mình 5 .. Và như vậy

Điều này sẽ giúp bạn mở rộng quy mô tốt hơn về quy trình phối hợp và duy trì các nhánh khác nhau cho từng môi trường

Điều này sẽ cung cấp cho bạn quyền kiểm soát chi tiết hơn và giảm tải tất cả chi phí phiên bản của bạn cho các hệ thống kiểm soát phiên bản. Đồng thời tạo các nhánh riêng cho từng môi trường và gắn thẻ mã cho mỗi bản phát hành sản xuất (như chúng tôi làm cho cơ sở mã ứng dụng). Hãy suy nghĩ Infra và xử lý về mặt mã. (Mọi thay đổi trong quy trình phải được mã hóa và gửi đến QA, SIT, UAT và sau đó tới SẢN PHẨM) tương tự như ứng dụng.

Ví dụ: bạn có thể có V2.1 Ansible đang chạy trong Sản xuất (nhánh chính) nhưng V2.0 của các container docker chạy trong Prod (nhánh chính)

Tương tự giữ các tập lệnh DB / bash script của bạn trong kho riêng của chúng và có thể bạn có thể cấu hình tệp kiểm tra sức khỏe (JSON / YAML) để hiển thị các phiên bản của tất cả các công cụ / bộ phận trong mỗi URL được triển khai để theo dõi và tự động hóa. (Để webhooks của bạn đọc URL và tự động triển khai)


2
Cạm bẫy của phương pháp này là, v2.1 nằm trong qa và không được xác thực và bạn phải vá sản xuất khẩn cấp, bạn không thể sửa đổi v2.0 và nếu bạn tạo phiên bản v2.2 cho bản vá này có nguy cơ cao về nó bị mất hoặc bị ghi đè khi v2.1 đi vào sản xuất, nhân với số lượng mã riêng biệt trong một repo và bạn sẽ sớm gặp ác mộng về backport (nó hoạt động, nhưng tôi phải thêm từ chối trách nhiệm này :))
Tensibai

3
Sử dụng các nhánh để theo dõi thông tin cụ thể về môi trường / triển khai trông giống như một mô hình đối với tôi: nếu chúng ta có 20 môi trường, điều này có nghĩa là chúng ta có 20 nhánh để đồng bộ hóa một nguồn có thể có lỗi và nhầm lẫn. Bạn có thể giải thích lý do tại sao bạn không sử dụng các tệp cấu hình để theo dõi thông tin cụ thể về môi trường / triển khai và quy trình làm việc của bạn làm việc với các chi nhánh này là gì? Đây không phải là những vấn đề tầm thường!
Michael Le Barbier Grünewald

3

Phân biệt giữa Ops, Dev và DevOps thúc đẩy sự cô lập và thực thi một tư duy "ném nó lên tường". Để tăng cường hợp tác giữa các đội, người ta nên đặt mọi thứ vào một kho lưu trữ được yêu cầu để xây dựng và triển khai dự án.

Có nói rằng, câu trả lời cho câu hỏi:

Làm cách nào để cấu trúc mã và cấu hình liên quan đến DevOps trong kho lưu trữ mã?

là nếu cấu hình được yêu cầu để chạy dự án thì người ta nên đặt nó trong cùng một thư mục.

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.