Công cụ lưu trữ trên mỗi cấu hình môi trường

Tôi có một yêu cầu lưu trữ thông tin cấu hình trên cơ sở từng môi trường trong một công cụ.

Đây là một công cụ có GUI để thêm / cập nhật các giá trị cấu hình (ví dụ: chuỗi kết nối). Điều này sẽ có một giá trị mặc định và có thể thay đổi điều này dựa trên các môi trường khác nhau.

Cần có một API để truy xuất các giá trị cấu hình này trong quá trình triển khai đến một môi trường cụ thể để thêm vào ứng dụng.

Tôi đã tìm kiếm một lúc và không thể thấy bất kỳ công cụ nào phù hợp với dự luật này. Có bất cứ đề nghị?

Lưu ý : Hiện tại các cài đặt nằm trong các biến TeamCity và việc triển khai là thông qua các tập lệnh PowerShell.

— thời gian
nguồn

Lên cho những thứ được trả tiền? Bạn có bất kỳ hệ thống quản lý cấu hình? Bạn dùng gì để triển khai?

— Tensibai

Tùy chọn trả phí sẽ được cấu hình. Hiện tại các cài đặt nằm trong các biến TeamCity và việc triển khai thông qua các tập lệnh PowerShell.

— tim

Không hoàn toàn là một câu trả lời, do đó, một nhận xét - bạn đã cân nhắc sử dụng Octopus Deployment để triển khai vì điều đó cho phép bạn quản lý Cấu hình Môi trường theo cách rất linh hoạt.

— Richard Slater

Nếu bạn sử dụng hệ thống kiểm soát nguồn nhánh thưa thớt, như ClearCase, bạn có thể chỉ cần phân nhánh các tệp có sửa đổi, bạn có thể xem các chiến lược để xử lý các thay đổi OSD (Hệ điều hành phụ thuộc) trong VCS. Nếu bạn sử dụng git, bạn sẽ cần liên tục khởi động lại các nhánh không mặc định. Một số công cụ cấu hình có cài đặt cho mỗi môi trường thông qua các biến. Trong Ansible tôi có tệp có mặc định thay đổi và lớp phủ cho môi trường không sản xuất. Không lưu trữ bất kỳ cài đặt nào trong các công cụ CI, tất cả chúng đều có trong VCS. Bao gồm các cấu hình TC.

— Jiri Klouda

khuyên bạn nên lưu trữ tất cả các cấu hình với nguồn. chúng tôi có nhiều dịch vụ azure và sử dụng cú pháp chuyển đổi azure cho tất cả các tùy chỉnh môi trường. xem msdn.microsoft.com/en-us/l Library / dd465318 (v = vs.100) .aspx . Và chúng tôi thực sự làm điều này với powershell tại thời điểm triển khai như là một phần của cài đặt. Tùy thuộc vào nơi bạn móc vào đường ống, bạn có thể làm điều này trước khi đặt bit vào hộp hoặc, cho mật khẩu, sau. Chúng tôi sử dụng Azure Key Vault cho các bí mật để chúng không bao giờ xuất hiện trong kiểm soát nguồn.

— Không hoàn lại tiền Không trả lại

Có nhiều công cụ có thể làm một cái gì đó như thế này, bao gồm các công cụ quản lý cấu hình như Chef, Ansible hoặc Puppet; và các công cụ KVS như Lãnh sự và vân vân. Bạn cũng có thể tích hợp nó như một bước xây dựng trong máy chủ CI của mình hoặc khắc phục sự cố bằng cách sử dụng cấu hình trực tiếp trong thời gian chạy so với cửa hàng cấu hình bên ngoài (một lần nữa, một cái gì đó như Consul hoặc etcd hoặc bất kỳ cơ sở dữ liệu nào).

— Adrian
nguồn

Có thể là một repo khác nhau? Một với các nhánh cho QA, UAT, Prod (không hơn). Một repo khác với repos "Code as Code" thông thường của bạn và "Cơ sở hạ tầng như Code".

Nó rất sắc thái. Bao nhiêu cấu hình cho mỗi env. Có phải nó được bật giữa các bản phát hành? Nếu các trạng thái chuyển đổi duy trì trạng thái mặc dù triển khai nhị phân. Bạn duy trì cấu hình cho khách hàng, khách hàng, khách hoặc người dùng nào?

Tôi đã viết một loạt các mục blog (và nguyên mẫu / bản demo) về chủ đề này trong hơn 5 năm - bao gồm các giao diện người dùng cho việc chuyển đổi (nếu bạn cần chúng).

— paul_h
nguồn