Sunucu yapılandırma dosyaları için revizyon kontrolü kullanımına izin vermek için hangi çözümler var? [kapalı]

Birden fazla sistem yöneticisine sahip bir ortamda, sunucu yapılandırma dosyalarını revizyon kontrol sistemine eklemenin birkaç avantajı görüyorum. En dikkat çeken, değişiklikleri yapan ve bunları yapan ve elbette bilinen çalışma yapılandırmalarına geri dönme yeteneğidir.

Genel olarak Unix / Linux çözümleriyle ilgileniyorum, ancak Windows uygulamalarını da merak ediyorum.

Bunu bir süredir evde (~ 3 ana bilgisayar) test ettim, farklı scms'ler (RCS, Subversion, git). Şu anda benim için mükemmel bir şekilde çalışan kurulum, setgitpermskancayla birlikte.

Düşünmeniz gereken şeyler:

Dosya izinlerinin ve sahipliğinin ele alınması

• RCS: Bunu yerel olarak yapar
• Subversion: En son denedim, bunu svnyapmak için etrafta bir sarmalayıcıya ihtiyacınız vardı.
• git: setgitpermskanca bunu şeffaf bir şekilde ele alır ( post-checkoutyine de kancaların desteğiyle birlikte git'in oldukça yeni bir sürümüne ihtiyaç vardır )

Ayrıca, /etcsürüm kontrolü altındakilerinizin tümünü istemiyorsanız , ancak yalnızca gerçekten değiştirdiğiniz dosyaları (benim gibi) istiyorsanız, bu tür bir kullanımı destekleyen bir scm'ye ihtiyacınız olacaktır.

• RCS: Yine de sadece tek dosyalarda çalışıyor.
• Subversion: Bunu zor buldum.
• git: sorun yok *, üst düzey .gitignoredosyaya " " koy ve sadece kullanmak istediğin dosyaları eklegit add --force

Son olarak, altında bazı sorunlu dizinleri vardır /etcsonra bazı program veya cini (tarafından okunur paketler yapılandırma parçacıkları damla nerede /etc/cron.d, /etc/modprobe.dvs.). Bu programlardan bazıları, RCS dosyalarını görmezden gelebilecek kadar akıllıdır (örn. Cron), bazıları değildir (örneğin modprobe). .svn Dizinler ile aynı şey . Yine git için büyük bir artı (sadece bir üst seviye .git dizin oluşturur).

Bunu gayri resmi olarak git ile yaptım ama daha tamamlayıcı ve ayrıntılı bir uygulama olan etckeeper projesi de var.

Başka bir seçenek de sunucu yapılandırmalarınızı bildirimsel bir dilde kodlamak için Puppet veya Cfengine gibi otomatik bir sunucu yapılandırma aracı kullanmaktır .

Ön uçta ekstra bir iş, ancak Puppet gibi bir yardımcı program kullanmak, çok az insan müdahalesi ile bir sunucuyu otomatik olarak yeniden yapılandırmanızı ve yapılandırmanızı sağlar.

Oldukça işe yaramış görünen etckeeper ile denemeler yaptım . Bazı durumlarda önemli olabilecek merkezi bir sunucuya ihtiyacım yok. Birkaç farklı DVCS arka ucu kullanabilir, böylece en aşina olduğunuz birini seçebilirsiniz. Benim için çok iyi çalışıyor gibi görünüyor, ancak henüz kullanmaya başlamak için çalıştığım diğer teknisyenleri almaya çalışmıyorum.

Ben içine bakarak edilmiştir Chef son zamanlarda. Sürüm kontrolünde yalnızca temporable (.erb) yapılandırmaları saklamakla kalmaz , aynı zamanda eylemleri gerçekleştirmenize de izin verir ( yapılandırmaları düğüme yükledikten sonra bir hizmeti yeniden başlatmak gibi ). Chef, paket yönetimine yardımcı olur, böylece arabirim kurduğunuz herhangi bir düğüme olan bağımlılıkları doğrulayabilirsiniz (yani sudo paketinin kurulu olması gerekir). Chef, Ruby'de kolayca genişletilebilir gibi görünüyor, bu yüzden herhangi bir özel işleminiz varsa, bunu sağlanan çerçeve içinde yazabilirsiniz.

Ancak yine de denemedim ve Ruby'yi istemciye ve sunucuya uygun taşlar ile yüklemelisiniz (bu gerçekten zor değil). Genel olarak birçok sunucuyu bir kerede yönetmek gerçekten kolay görünüyor.

Altyapımıza Kukla uygulama süreci içindeyim ve verilerini sürüm kontrolünde tutmak çok elverişli.

Gizli dizinlerde depolanan bazı meta verileri içeren (yönetmesi kolay, anlaşılması kolay, kullanımı kolay) yalnızca bir dosya koleksiyonundan dolayı Mercurial'ı tercih ediyorum.

Kukla dosyalarım / usr / local / etc / kukla / (FreeBSD 7.1) 'de. Mercurial'ı eklemek için gereken her şey:

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

Tüm değişiklikler basit bir "hg taahhüdü" ile yapılır. Bir değişiklik bir şey hortumlarsa, her bir sunucuyu tek bir komutla dosyanın belirli bir sürümüne (diyelim) geri alabilirim.

Mercurial'a büyük giriş

Subversion'u yönettiğim sunucularda kullanıyorum. İyi çalışıyor. Bir Trac örneği de ayarladım , böylece bir zaman çizelgesi görünümümüz, bilet sistemimiz, tarama vb.

Sembolik linkler, cron ve subversion kullanarak, her Linux sunucusunun svn updatescriptleri (örn. Firewall scriptleri) kullanarak bir depoyu güncellediği subversion deposuna dayalı otomatik konfigürasyon dağılımı kurdum .

İşte gerçek hayattaki bir kullanım durumu: 4 farklı sunucudaki yapılandırma dosyalarını yönetmek için Subversion kullanıldı. Yapılandırma dosyaları için sürüm kontrolünü, kodla kullanmanızla aynı nedenle kullanmanızı öneririm - hepsi bir arada bir yedekleme ve geri alma düğmesidir. Çok daha fazla sayıda sunucuyu yönetiyor olsaydım ve konfigürasyon açısından daha yakınımda olsaydı, berberich'in cevabında detaylı olarak kukla gibi bir şey kullanıyor olurdum.

Buradaki fikir, sunuculardaki belirli klasörleri (örn. / Var / named /) kontrol edebileceğiniz bir havuza sahip olabileceğinizdir, böylece hem tarihim hem de konfigürasyon dosyalarının yedeğini alacağım (hata yaparsanız yedek bir bonusdur). Elinizi düzenleyen ekleri silecek bir GUI yapılandırma uygulaması kullanma Mac OS X Server öksürük Server Admin öksürük ). Bunu bir test sunucusunda test etmek ve ardından üretim sunucusunu, dosyaları el ile kopyalamaksızın çalışan dosyalar ile güncellemek kolaydır.

Birkaç yıl önce tam olarak bunu yapmak için bir proje yarattım: Savon

Dosyaları depolamak için subversion kullanıyor ve sahipliğini, izinlerini ve SELinux bağlamını izleme gibi bazı ek özelliklere sahip. Ayrıca dosya sistemi değişikliklerinizi mantıksal olarak katmanlara ayırmanıza olanak tanır, böylece örneğin tüm web sunucularınıza ayrı olarak gitmesi gereken değişiklikleri izleyebilirsiniz.

Subversion'un kurulumu ve kullanımı çok kolaydır ve çok fazla kaynak vardır:

Temel Nasıl Yapılır

SVN Kitabı

Belge Yönetimine Genel Bakış

Değişikliklerimizin çoğu, rutin bakım türünde malzemeler için bile Yardım Masası sistemimizle yönetilmektedir. Belgelerimizi yavaşça kendi kullanımımız ve son kullanıcılara yayınladıklarımız için bir wikiye taşıyoruz. Yapılandırma değişikliklerini ve arkasındaki tartışmayı göndermek, intranetimize açık olmak güzeldir.

Uzun yıllar boyunca, değiştirmeye başladığım dosyalar için rcs kullandım, ancak birkaç yıl önce / etc'yi git kontrol altına almaya başladım. Öğütülmüş yığınlardaki dosyaları kontrol etmek için bazı çalışmalar gerektirir (bazı zamanlarda büyük bir "çeşitli güncellemeler" için başvuruyorum) ve bu konuda yardımcı olmak için bazı komut dosyaları yazdım, ancak bahsettiğim emici çok ilginç görünüyor, hemen deneyeceğim.