Solusi apa yang ada untuk memungkinkan penggunaan kontrol revisi untuk file konfigurasi server? [Tutup]

Dalam lingkungan dengan beberapa administrator sistem, saya melihat beberapa keuntungan untuk menambahkan file konfigurasi server ke sistem kontrol revisi. Yang paling menonjol adalah kemampuan untuk melacak perubahan, siapa yang membuatnya, dan tentu saja bisa kembali ke konfigurasi kerja yang dikenal.

Saya terutama tertarik pada solusi Unix / Linux, tetapi akan penasaran dengan implementasi Windows juga.

Saya telah menguji ini di rumah (~ 3 host) untuk beberapa waktu sekarang, mencoba berbagai scms (RCS, Subversion, git). Setup yang berfungsi sempurna untuk saya saat ini adalah git dengan setgitpermshook.

Hal-hal yang perlu Anda pertimbangkan:

Menangani izin dan kepemilikan file

• RCS: apakah ini secara asli
• Subversi: terakhir saya mencoba, Anda membutuhkan pembungkus svnuntuk melakukan ini
• git: setgitpermshook menangani ini secara transparan (membutuhkan versi git yang cukup baru dengan dukungan untuk post-checkouthooks)

Juga, jika Anda tidak ingin semua /etckontrol versi di bawah Anda , tetapi hanya file yang benar-benar Anda modifikasi (seperti saya), Anda akan memerlukan scm yang mendukung penggunaan semacam ini.

• RCS: hanya berfungsi pada file tunggal.
• Subversi: Saya menemukan ini rumit.
• git: tanpa masalah, letakkan " *" di .gitignorefile tingkat atas dan tambahkan hanya file yang ingin Anda gunakangit add --force

Akhirnya, ada beberapa direktori bermasalah di bawah /etcmana paket bisa drop config potongan yang kemudian dibaca oleh beberapa program atau daemon ( /etc/cron.d, /etc/modprobe.d, dll). Beberapa dari program ini cukup pintar untuk mengabaikan file RCS (misalnya cron), beberapa tidak (misalnya modprobe). Hal yang sama dengan .svn direktori. Lagi-lagi nilai tambah besar untuk git (hanya membuat satu .git direktori tingkat atas ).

Saya sudah melakukannya secara informal dengan git, tetapi ada juga proyek penjaga etc yang merupakan implementasi yang lebih lengkap dan terperinci.

Opsi lain adalah menggunakan alat konfigurasi server otomatis seperti Puppet atau Cfengine untuk membuat skrip konfigurasi server Anda dalam bahasa deklaratif.

Ini pekerjaan ekstra di front-end, tetapi menggunakan utilitas seperti Puppet memungkinkan Anda untuk secara otomatis membangun kembali dan mengkonfigurasi server dengan sedikit intervensi manusia.

Saya telah bereksperimen dengan penjaga etc yang tampaknya bekerja dengan cukup baik. Saya tidak memerlukan server terpusat, yang mungkin penting dalam beberapa situasi. Anda dapat menggunakan beberapa backend DVCS yang berbeda, sehingga Anda dapat memilih yang paling Anda kenal. Tampaknya bekerja dengan sangat baik untuk saya, tetapi saya belum mencoba mendapatkan teknologi lain tempat saya bekerja untuk mulai menggunakannya.

Saya telah melihat Chef belakangan ini. Tidak hanya menjaga konfigurasi templates (.erb) di kontrol versi, tetapi juga memungkinkan Anda untuk melakukan tindakan (seperti memulai kembali layanan setelah Anda mengunggah konfigurasi ke node). Chef membantu pengelolaan paket sehingga Anda dapat memverifikasi dependensi dengan simpul apa pun yang berinteraksi dengan Anda (mis. Harus menginstal paket sudo). Chef tampaknya mudah diperluas di Ruby, jadi jika Anda memiliki proses kustom apa pun, Anda bisa skrip saja dalam kerangka yang disediakan.

Tetapi masih belum mencobanya dan Anda harus menginstal Ruby pada klien dan server dengan permata yang sesuai (ini sebenarnya tidak terlalu sulit). Secara keseluruhan terlihat sangat mudah untuk mengelola banyak server sekaligus.

Saya sedang dalam proses mengimplementasikan Wayang di seluruh infrastruktur kami, dan sangat kondusif untuk menjaga datanya dalam kontrol versi.

Saya lebih suka Mercurial karena itu hanya kumpulan file dengan beberapa metadata yang disimpan dalam direktori tersembunyi (mudah dikelola, mudah dimengerti, mudah digunakan).

File wayang saya ada di / usr / local / etc / puppet / (FreeBSD 7.1). Semua yang diperlukan untuk menambahkan Mercurial ke dalamnya:

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

Semua perubahan dilakukan dengan "hg commit" sederhana. Jika perubahan menyembunyikan sesuatu, saya bisa memutar kembali setiap server ke versi file yang diberikan (katakanlah, sudoers) dengan satu perintah.

Intro yang bagus untuk Mercurial

Saya telah menggunakan Subversion di server yang saya kelola. Bekerja dengan baik. Saya juga telah menyiapkan instance Trac , jadi kami memiliki tampilan timeline, sistem tiket, penelusuran, dll.

Menggunakan symlinks, cron dan subversi saya juga mengatur distribusi konfigurasi otomatis berdasarkan repositori subversi, di mana setiap server Linux memperbarui repositori menggunakan svn updateskrip (misalnya skrip firewall).

Berikut ini adalah kasus penggunaan nyata: Subversi Digunakan untuk mengelola file konfigurasi pada 4 server yang berbeda. Saya akan merekomendasikan menggunakan kontrol versi untuk file konfigurasi untuk alasan yang sama Anda akan menggunakannya dengan kode - ini adalah cadangan dan tombol undo semuanya menjadi satu. Jika saya mengelola jumlah server yang jauh lebih besar dan mereka lebih dekat dalam hal konfigurasi, saya akan menggunakan sesuatu seperti Puppet seperti yang terinci dalam jawaban berberich.

Idenya adalah bahwa Anda dapat memiliki satu repositori yang Anda dapat checkout folder tertentu di server (mis. / Var / bernama /) jadi saya berdua memiliki riwayat dan cadangan file konfigurasi (cadangan adalah bonus jika Anda melakukan kesalahan menggunakan aplikasi konfigurasi GUI yang menyeka tangan diedit penambahan Anda batuk Server Admin di Mac OS X Server batuk ). Maka mudah untuk mengujinya pada server uji dan selanjutnya memperbarui server produksi dengan file yang berfungsi tanpa menyalin file secara manual.

Saya telah membuat sebuah proyek beberapa tahun yang lalu untuk melakukan hal ini: Savon

Ini menggunakan subversi untuk menyimpan file, dan memiliki beberapa fitur tambahan, seperti melacak kepemilikan, izin, dan konteks SELinux. Ini juga memungkinkan Anda untuk secara logis memecah perubahan sistem file Anda menjadi berlapis-lapis, jadi Anda dapat misalnya melacak perubahan yang harus masuk ke semua server web Anda secara terpisah.

Subversi sangat mudah diatur dan digunakan dan ada banyak sumber daya:

Cara Dasar

Buku SVN

Tinjauan Manajemen Dokumen

Sebagian besar perubahan kami dikelola dengan sistem Help Desk kami, bahkan untuk jenis perawatan rutin. Kami telah perlahan memindahkan dokumentasi kami ke wiki untuk kami gunakan sendiri, dan apa yang kami terbitkan kepada pengguna akhir. Memposting perubahan konfigurasi dan diskusi di baliknya, menyenangkan untuk dibuka di intranet kami.

Selama bertahun-tahun saya menggunakan rcs untuk file yang saya mulai modifikasi, tetapi beberapa tahun yang lalu saya mulai meletakkan seluruh / etc di bawah kontrol git. Memerlukan beberapa pekerjaan untuk memeriksa file dalam butiran bulks (beberapa kali saya resor untuk checkin "berbagai pembaruan" besar), dan saya telah menulis beberapa skrip untuk membantu dengan ini, tetapi penjaga toko yang disebutkan tampaknya sangat menarik, saya akan segera mencoba.