Otomatik Linux güncellemeleri için en iyi uygulama

RHEL / RHEL tabanlı sunucularımız için otomatik güncellemeler yapmanın bir yolu üzerinde çalışıyoruz.

İlk fikir: Kukla kullanarak varsayılan depoları devre dışı bırakır ve kendimize ait olanı gösteririz. Ardından, ensure => latestotomatik olarak güncellemek istediğimiz paketler için kullanıyoruz .

Sorun: Bazı servislerin güncelleme sonrasında yeniden başlatıldığını görüyoruz (duh).

Soru: Linux güncellemelerinin ve hizmetlerin otomatik olarak yeniden başlatılmasının azaltılmasına yönelik stratejilerin nasıl daha iyi otomatikleştirileceği konusunda herhangi bir tavsiyesi var mı? Kukla içeren bir çözümü tercih ederdik, ancak başka bir hizmet kullanmamız gerekirse, bu bir anlaşma kırıcı değildir.

Düzenle

Olası çözüm: @ voretaq7 ve @ewwhite tarafından önerilenlerin çoğunu uygulayan bir çözüm sundum. Şimdilik gideceğim yol bu gibi görünüyor. Başka önerileriniz varsa, lütfen yorum yapın veya bir yanıt gönderin.

Genel güncelleme stratejiniz sağlam: Yerel bir repo var (dev bir ortamda test yaptığınızı varsayıyorum) ve her şeyi buna göre güncellersiniz (bilinen iyi olduğunu düşünüyorum).

Hizmeti yeniden başlatma işlemi kaçınılmazdır: Temel alınan kod değiştiyse, bu değişikliğin etkili olması için hizmeti yeniden başlatmanız gerekir. Bunu yapmamak daha kötü sonuçlara yol açabilir (uygulamanın çökmesine neden olan paylaşılan bir kitaplıkla kodun senkronize olmaması).
Çevremde, üç aylık yama pencerelerinin üç ayda bir "TÜM ŞEYLERİ YENİDEN BAŞLAT!" pencereleri de. Böyle bir politika avantajı olduğunu biliyoruz senin sunucuları yeniden başlatma sonrasında yukarı geri gelecek ve siz biliyor düzgün çalışılacaktır (sen düzenli olarak test çünkü).

Size en iyi tavsiyem, yazılım sürümlerini planlamaktır (belki de bu, kukla ile "manuel olarak" tetiklemeniz gerektiği anlamına gelir) ve kullanıcılarınıza planlanan bakım / kesinti süresi hakkında tavsiyelerde bulunmanızdır.
Alternatif olarak (veya bunun bir parçası olarak), ortamınızda yedeklemeyi yapılandırabilir, böylece birkaç makinenin veya hizmetin yeniden başlatılmasını ve son kullanıcılara hizmet vermesini sağlayabilirsiniz. Bu, herhangi bir kesintiyi tamamen ortadan kaldırmayabilir, ancak bunları en aza indirmeye yardımcı olabilir.

Eklenen artıklık, yeterince uzun bir zaman ölçeğinde kaçınılmaz olan donanım arızalarında da sizi korur.

Paket güncellemesinden sonra bir hizmeti yeniden başlatmayla ilgili bir sorun mu var? Herhangi bir sorun olup olmadığını görmek için konuşlandırmadan önce küçük ölçekte test edin. Geçenlerde bir Öncelikle rpmforge paketi ile çirkin bir sorunu vardı DenyHosts . Aslında bir yum güncellemesinden revizyonlar arasında yapılandırmasının ve çalışma dizinlerinin yerini değiştirdi. Bu tamamen istenmeyen bir davranış. Tipik olarak, RHEL'in aynı revizyonunda, çok fazla sorun yoktur, ancak etkileri yakından test etmeden ve izlemeden asla emin olamazsınız.

Başka bir seçenek de hizmetleri seçici olarak güncellemektir. Örneğin her zaman en son paketlere mi ihtiyacınız var? Bu, güncellemeleri çalıştırma nedenlerinizi anlamaya geri döner. Gerçek hedef nedir?

Kendi repo'nuzu yönetmenin avantajı, sürümleri veya sunumları sahne alabilmeniz ve programı yönetebilmenizdir. RHEL 5.6 gerektiren ve 5.7'nin altına düşecek bir donanım çevre birimi veya yazılım satıcınız varsa ne olur? Bu, kendi paketlerinizi yönetmenin avantajlarından biridir.

@ErkekTerimleri

Basitleştirme, kukla başlatmak / durdurmak için döngü araçları için ssh kullanma ihtiyacını ortadan kaldıracaktır.

Her şeyden önce, manifestolarınızı, değeri ENC'den alınan "noop" adlı bir değişkeni içerecek şekilde değiştirmeniz gerekecektir.

Yani bir sınıfta şöyle bir şey olurdu:

noop => $noop_status

ENC'nizde nerede noop_statusayarlanır? Eğer değerini ayarladığınızda noop_statusiçin true, apaçık noop modunda sadece çalışır.

100 veya 1000 ana makineniz varsa, "Ana Bilgisayar Grubu" veya "Alan Adı" düzeyinde devralınarak birçok ana bilgisayar için parametreleri toplu olarak değiştirmenize olanak tanıyan Gösterge Tablosu veya Foreman gibi bir ENC kullanabilirsiniz. Daha sonra az sayıda test ana bilgisayarı için değeri "false" değerine ayarlayarak Hostgroup değerini geçersiz kılabilirsiniz.

Bununla, tüm değişiklikler yalnızca seçilen ana bilgisayarlara uygulanır.

Merkezi bir konumda bir parametrenin değiştirilmesi, döngü araçları için ssh ile kukla açmaya / kapatmaya gerek kalmadan çok sayıda ana bilgisayarı etkileyebilir. Güvenlik / yönetim için ana bilgisayarlarınızı birden fazla gruba bölebilirsiniz.

Ayrıca, manifestlerde Paket sürüm numaralarını sabit kodlamak yerine, bunları ENC'ye koyabileceğinizi unutmayın. Ve tıpkı yukarıdaki gibi, değişiklikleri seçerek uygulayabilir ve sunumları yönetebilirsiniz.

Daha fazla ayrıntı düzeyi (ve karmaşıklık) istiyorsanız, benzeri her bir sınıf parametresine bile sahip olabilirsiniz noop_status_apacheClass.

includeBaşka sınıflarda ders verirseniz bunu yönetmek daha zor olabilir .

@ Voretaq7'nin cevabına dayanan olası çözüm:

1. puppetManifestlerdeki paketlerin sabit kod sürüm numaraları ve paketleri kendi havuzumuzda saklar.

2. Bir paketin yeni bir sürümüne sunduğumuz bir şeye ihtiyacımız olduğunda (örneğin, güvenlik geliştirmeleri, müşterilerimiz tarafından istenen özellikler, vb.), Paketi depoya indiririz.

3. Güncellenmiş paketi bir test sunucusunda test edin.

4. Güncelleme test edildikten sonra , etkilenen düğümlerdeki aracıyı kapatmak için funcveya gibi bir şey kullanın .psshpuppet

5. puppetPaketin yeni sürümünün etkilenen düğümlere yüklendiğinden emin olmak için bildirimleri güncelleyin .

6. Son olarak, veya puppet agent --onetime && rebootkullanarak sunucuda çalıştırınfuncpssh

Bu çözümdeki herhangi bir eksikliği veya basitleştirilebilecek herhangi bir şeyi tespit ederseniz lütfen yorum yapın ve bize bildirin.