Những giải pháp nào tồn tại để cho phép sử dụng kiểm soát sửa đổi cho các tệp cấu hình máy chủ? [đóng cửa]


85

Trong một môi trường có nhiều quản trị viên hệ thống, tôi thấy một vài lợi thế khi thêm các tệp cấu hình máy chủ vào hệ thống kiểm soát sửa đổi. Đáng chú ý nhất là khả năng theo dõi các thay đổi, những người đã thực hiện chúng, và tất nhiên có thể quay trở lại các cấu hình làm việc đã biết.

Tôi chủ yếu quan tâm đến các giải pháp Unix / Linux, nhưng cũng sẽ tò mò về việc triển khai Windows.


Có vẻ trùng lặp hoặc rất liên quan đến câu hỏi này serverfault.com/questions/3852/iêu
Zoredache

Câu trả lời:


52

Tôi đã thử nghiệm điều này ở nhà (~ 3 máy chủ) một thời gian rồi, thử các scms khác nhau (RCS, Subversion, git). Thiết lập hoạt động hoàn hảo cho tôi ngay bây giờ là git với setgitpermshook.

Những điều bạn cần phải xem xét:

Xử lý quyền và quyền sở hữu tệp

  • RCS: thực hiện điều này nguyên bản
  • Subversion: lần cuối tôi đã thử, bạn cần một trình bao bọc svnđể làm điều này
  • git: setgitpermshook xử lý trong suốt này ( post-checkoutmặc dù cần một phiên bản git khá gần đây có hỗ trợ cho hook)

Ngoài ra, nếu bạn không muốn tất cả các /etcđiều khiển dưới phiên bản của mình , nhưng chỉ các tệp mà bạn thực sự sửa đổi (như tôi), bạn sẽ cần một scm hỗ trợ loại sử dụng này.

  • RCS: dù sao chỉ hoạt động trên các tệp duy nhất.
  • Subversion: Tôi thấy điều này là khó khăn.
  • git: không có probem, đặt " *" vào .gitignoretệp cấp cao nhất và chỉ thêm những tệp bạn muốn sử dụnggit add --force

Cuối cùng, có một số thư mục có vấn đề dưới /etcnơi gói có thể thả các đoạn cấu hình mà sau đó được đọc bởi một số chương trình hoặc daemon ( /etc/cron.d, /etc/modprobe.d, vv). Một số chương trình này đủ thông minh để bỏ qua các tệp RCS (ví dụ: cron), một số chương trình thì không (ví dụ: modprobe). Điều tương tự với các .svn thư mục. Lại một điểm cộng lớn cho git (chỉ tạo một .git thư mục cấp cao nhất ).


1
Subversion cần asvn svn.collab.net/repose/svn/trunk/contrib/client-side/asvn . Lưu trữ SVN (asvn) sẽ cho phép ghi các loại tệp thường không được xử lý bởi svn. Hiện tại điều này bao gồm các thiết bị, liên kết tượng trưng và quyền sở hữu / quyền truy cập tệp.
Cristian Ciupitu

Bạn có viết lên bất cứ nơi nào chỉ ra cách thiết lập các hook bạn đã sử dụng không, ect.?
grufftech

Một bài viết ngắn ở đây: jottit.com/jg8h7
8

Đây là một bài viết về việc thiết lập một cái gì đó như thế này trong Arch Linux ARM, nên áp dụng tốt như vậy ở đây. zduck.com/2012/storing-your-raspberry-pi-config-in-git
im lặng mặc dù

28

Tôi đã thực hiện nó một cách không chính thức với git, nhưng cũng có dự án etckeeper , một triển khai chi tiết và đầy đủ hơn.


4
v.v. Cũng có tích hợp vào APT để mỗi khi bạn thực hiện thao tác apt-get, kho lưu trữ / etc được cam kết và thực hiện các cam kết qua đêm. Tôi đã sử dụng điều này trong một thời gian và nói chung, nó tốt hơn nhiều so với việc sử dụng một VCS vanilla, nếu chỉ cho tính năng cấp phép.
RichVel

23

Một tùy chọn khác là sử dụng một công cụ cấu hình máy chủ tự động như Puppet hoặc Cfengine để kịch bản cấu hình máy chủ của bạn bằng ngôn ngữ khai báo.

Đó là công việc bổ sung ở mặt trước, nhưng sử dụng tiện ích như Puppet cho phép bạn tự động xây dựng lại và định cấu hình máy chủ với rất ít sự can thiệp của con người.


5
Có, nhưng bạn cũng nên điều chỉnh lại các cấu hình Puppet / CFengine của mình. Tôi cũng là một fan hâm mộ của revision-kiểm soát đầu ra để bạn có thể trả lời câu hỏi "cái gì đã cấu hình vào ngày x?" cũng như "cấu hình nên theo con rối là gì?" và tương quan đầu vào với đầu ra để khắc phục sự cố hệ thống quản lý cấu hình.
Rob Chanter

10

Tôi đã thử nghiệm với etckeeper có vẻ hoạt động khá tốt. Tôi không yêu cầu một máy chủ tập trung, có thể quan trọng trong một số tình huống. Bạn có thể sử dụng một số phụ trợ DVCS khác nhau, vì vậy bạn có thể chọn một phụ kiện quen thuộc nhất. Nó dường như hoạt động rất tốt đối với tôi, nhưng tôi chưa thử sử dụng các công nghệ khác nơi tôi làm việc để bắt đầu sử dụng nó.


6

Gần đây tôi đã nhìn vào Chef . Nó không chỉ giữ cấu hình templizable (.erb) trong kiểm soát phiên bản, mà còn cho phép bạn thực hiện các hành động (như khởi động lại dịch vụ sau khi bạn tải cấu hình lên nút). Chef giúp quản lý gói để bạn có thể xác minh các phụ thuộc với bất kỳ nút nào mà bạn giao diện (nghĩa là phải cài đặt gói sudo). Đầu bếp dường như có thể dễ dàng mở rộng trong Ruby, vì vậy nếu bạn có bất kỳ quy trình tùy chỉnh nào, bạn có thể chỉ cần viết kịch bản ra trong khuôn khổ được cung cấp.

Nhưng vẫn chưa thử nó và bạn phải cài đặt Ruby trên máy khách và máy chủ với các loại đá quý phù hợp (điều này thực sự không khó lắm). Nhìn chung, thực sự dễ dàng để quản lý nhiều máy chủ cùng một lúc.


Chúng tôi sử dụng Chef rất nhiều (hơn 60 máy chủ) khá thành công. Tất cả các công thức nấu ăn và tập tin cấu hình được kiểm tra vào Subversion.
Organicveggie

3

Tôi đang trong quá trình triển khai Puppet trên cơ sở hạ tầng của chúng tôi và rất thuận lợi để giữ dữ liệu của nó trong kiểm soát phiên bản.

Tôi thích Mercurial vì nó chỉ là một tập hợp các tệp với một số siêu dữ liệu được lưu trữ trong các thư mục ẩn (dễ quản lý, dễ hiểu, dễ sử dụng).

Các tập tin rối của tôi nằm ở / usr / local / etc / Puppet / (FreeBSD 7.1). Tất cả chỉ cần thêm Mercurial vào nó:

> cd /usr/local/etc/puppet
> hg init

Tất cả các thay đổi được cam kết với một "cam kết hg" đơn giản. Nếu một thay đổi làm hỏng một cái gì đó, tôi có thể khôi phục mọi máy chủ đơn lẻ vào một phiên bản nhất định của tệp (giả sử, sudoers) bằng một lệnh duy nhất.

Giới thiệu tuyệt vời về Mercurial


3

Tôi đã sử dụng Subversion trên các máy chủ mà tôi quản lý. Hoạt động tốt. Tôi cũng đã thiết lập một ví dụ Trac , vì vậy chúng tôi có chế độ xem dòng thời gian, hệ thống bán vé, duyệt, v.v.

Sử dụng symlink, cron và subversion Tôi cũng đã thiết lập phân phối cấu hình tự động dựa trên kho lưu trữ lật đổ, trong đó mọi máy chủ Linux cập nhật kho lưu trữ bằng svn updatecác tập lệnh (ví dụ: tập lệnh tường lửa).


2

Đây là trường hợp sử dụng ngoài đời thực: Subversion được sử dụng để quản lý các tệp cấu hình trên 4 máy chủ khác nhau. Tôi khuyên bạn nên sử dụng kiểm soát phiên bản cho các tệp cấu hình với cùng lý do bạn sẽ sử dụng chúng với mã - đó là bản sao lưu và nút hoàn tác tất cả trong một. Nếu tôi đang quản lý một lượng lớn máy chủ hơn và chúng gần gũi hơn nhiều về cấu hình thì tôi sẽ sử dụng một cái gì đó như Puppet như chi tiết trong câu trả lời của berberich.

Ý tưởng là bạn có thể có một kho lưu trữ mà bạn có thể kiểm tra các thư mục cụ thể trên các máy chủ (ví dụ: / var / tên /) để tôi có lịch sử và sao lưu các tệp cấu hình (bản sao lưu là phần thưởng nếu bạn mắc lỗi về việc sử dụng một ứng dụng cấu hình GUI giúp bạn chỉnh sửa bổ sung ho Quản trị máy chủ trong Mac OS X Server ho ). Sau đó, thật dễ dàng để kiểm tra nó trên máy chủ thử nghiệm và sau đó cập nhật máy chủ sản xuất với các tệp hoạt động mà không cần sao chép tệp thủ công.


1

Tôi đã tạo một dự án vài năm trước để làm chính xác điều này: Savon

Nó sử dụng subversion để lưu trữ các tệp và có một số tính năng bổ sung, như theo dõi quyền sở hữu, quyền và bối cảnh SELinux. Nó cũng cho phép bạn phân chia hợp lý các thay đổi hệ thống tệp của bạn theo từng lớp, do đó, ví dụ bạn có thể theo dõi các thay đổi sẽ đi đến tất cả các máy chủ web của mình.



0

Hầu hết các thay đổi của chúng tôi được quản lý với hệ thống Bàn trợ giúp của chúng tôi, ngay cả đối với các công cụ loại bảo trì định kỳ. Chúng tôi đã dần dần chuyển tài liệu của mình vào wiki để sử dụng riêng và những gì chúng tôi xuất bản cho người dùng cuối. Đăng các thay đổi cấu hình và thảo luận đằng sau nó, thật tuyệt khi mở trên mạng nội bộ của chúng tôi.


0

Trong nhiều năm, tôi đã sử dụng rcs cho các tệp mà tôi đã bắt đầu sửa đổi, nhưng một vài năm trước tôi đã bắt đầu đặt toàn bộ / etc dưới sự kiểm soát của git. Nó đòi hỏi một số công việc để kiểm tra các tệp trong các khối nhỏ (đôi khi tôi dùng đến một bản kiểm tra "cập nhật khác nhau" khổng lồ) và tôi đã viết một số tập lệnh để trợ giúp việc này, nhưng v.v.

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.