'Tek sunucu çoklu yöneticileri' için yapılandırma yönetimi

Küçük bir ilişkilendirme için altyapıyı çalıştıran bir sunucu kurduk. Şimdiye kadar, yapılandırmayı Ansible ile yönetmeye çalıştık, ancak bu büyük bir başarı olmadı. Belki de yanlış yapıyoruz.

Prensip olarak, bu sunucu çoğu zaman bir kişi mavi ay içinde bir şeyler ekleyerek veya değiştirerek yalnız kalacak. Bu, sistemde sık sık yönetici olmayan kişiler genel olarak bilgi kaybetmek zorunda kaldıklarından (ayrıntıları hatırlayalım), sunucuda yapılandırılan ve çalışan her şeyin iyi belgelendirilmiş ve açık olmasını çok önemli hale getirir. Ayrıca, zaman içinde, bu sunucuyu yönetecek kişi grubunun yapısı değişecektir (insanlar ayrıldıkça ve 'komiteye' katıldıkça).

Temiz bir kurulumla başladık, bir şey ayarlamak istediğimizde (nginx, phpfpm, postfix, güvenlik duvarı, sftp, munin, ..) her zaman ansible rolleri ekledik. Belki de deneyimsizliğimizden dolayı, elbette bir dizi ansible görevi tam olarak bir seferde ihtiyacımız olan şekilde yazamıyoruz, çünkü yapılandırma biraz deneme ve hata süreci. Bu, pratikte, öncelikle sunucuda çalıştırmak istediğimiz hizmeti yapılandırır ve sonra da sorumlu görevlere çeviririz anlamına gelir. Bunun nereye gittiğini görebilirsiniz. İnsanlar daha sonra görevi test etmeyi unuturlar ya da bir şeyleri kırma riski altındayken ya da daha kötüsü yapmaktan korkarlar: şeyleri ansiblea eklemeyi unutur ya da ihmal ederiz.

Bugün, kabul edilebilir yapılandırmanın aslında sunucuda yapılandırılanları yansıttığına çok az güveniyoruz.

Şu anda üç ana sorun görüyorum:

Bir şeyleri kırma riski olmadan sorumlu görevleri test etmek (okumak için iyi bir yolumuz yoktur) zordur.
Öncelikle istenen yapılandırmayı ve ardından bunu sorumlu görevlere nasıl çevireceğinizi anlamak için ekstra iş ekler.
(İdeal olarak,) bunu aşinalık ve rutin oluşturmak için yeterince sık kullanmıyoruz.

Burada önemli bir nokta, ne yaparsak yapalım, yeni gelenlerin bir ton pratik yapmadan ipleri öğrenmelerinin kolay olması gerektiğidir .

Hala bir masterşeyler yapılandıran ve yaptıklarınızı yazmanın sağlayamadığı bazı garantiler ve kontroller (Ansible dosyalarını bazılarıyla birleştirmekle karşılaştırılabilir) sağlayan uygun bir alternatif var mı ?

EDIT: /etcGit gitmeyi taahhüt ettik . Sırları (özel anahtarlar, vb.) Bu şekilde korumanın makul bir yolu var mı, ancak yine de yapılandırma havuzu sunucu dışında bir şekilde kullanılabilir mi?

ansible configuration-management

— Joost
kaynak

Yanıtlar:

Değişikliklerinizi doğrulamak için kullanabileceğiniz bir test / hazırlama VM'sini döndürmeniz yeterlidir. Mevcut değişiklikleri manuel olarak gerçekleştirme yönteminiz önce umutsuzca kırılmış ve başarısızlığa mahkumdur. Siz ve ekibiniz CM'yi doğru kullanmayı taahhüt etmelisiniz ve bunun bir kısmı bir test sistemine sahip. Sadece yerel bir vagrant VM bile yeterli olacaktır.

Bu sadece yeni değişikliklerin test edilmesine yardımcı olmakla kalmayacak, aynı zamanda yeni çalışanlar (veya sistemi bir süredir kullanmayan daha yaşlı çalışanlar) için kabul edilebilir kurulumunuzu tanımak için bir test yatağı olarak hizmet edecektir.

/ Etc / 'in git: no ile ilgili olarak, bunu yapma. Bu dizin, ansibleın değişen şeyin sadece küçük bir kısmıdır ve git yerine sahip olmak, insanları yalnızca yerel değişiklikler yapmaya teşvik edecektir.

Ansible playbook'larınızı git'de tutun. Canlı sunucuya yalnızca kabul edilebilir değişiklikler uygulayabilmeniz için izinleri kısıtlamayı düşünün. Diğerleri, değişiklikleriyle çekme istekleri gönderebilir, bu da uygunsa gözden geçirip master ile birleştirebilirsiniz.

— EEAA
kaynak

Doğru, bu ideal senaryo. Anladım. Mesele şu ki, biz bir şirket değiliz ve bu tam zamanlı çalışan insanımız yok. Belki de bu ölçeği yeterince netleştirmedim .. Her ek parça (bir vagrantfile gibi) geçirilmesi gereken karmaşıklık ekler ve iki konfigürasyon çalıştırır (yani düzenek otomasyonu gibi şeylerin alay edilmesi gereken bir test sistemi) basitlik yardım değil.

— Joost

Sorunlarınızı nasıl çözeceğinizi sordunuz ve ben de cevabımı verdim. Yukarıdakiler, şirketimde işleri tam olarak nasıl yaptığımızdır ve çok iyi çalışır. Evet, sunucu alanı ve test etmek için gereken zaman açısından ek maliyet vardır, ancak bunlar buna değer, çünkü birkaç dakika içinde gerektiğinde sunucularımızdan herhangi birini yeniden oluşturabileceğimize dair çok yüksek bir güvencemiz var.

— EEAA

Özünde, bu teknik bir sorun değil, gerçekten kültürel ve kaynaksal bir sorundur. Yapılandırma yönetimini kullanmayı taahhüt etmediniz. Şirket olup olmamanız önemsizdir. İşleri düzgün bir şekilde nasıl yapacağınız konusunda yardım istiyorsunuz ve bir hazırlama ortamına sahip olmak da bunun bir parçası.

— EEAA

IMHO, evet, taahhüt etmelisin. Yine de meslektaşlarınızı ikna edip edemeyeceğiniz başka bir soru. Bunu yapmanın, sunucuyu yönetenlerden bir miktar kasıtlılık gerektirmeyen hafif bir yolu yoktur. Modern CM sistemlerinden ansible, hızlanmak için açık ara en kolay olanıdır. Sen do zamanla sunucu değişikliklerini izlemek istiyoruz. Bunu güvenilir bir şekilde yapmanın tek yolu CM kullanmaktır.

— EEAA

@ThomWiggers "Biz" kullandığınızdan beri ikinizin aynı ekipte olduğunu varsayacağım. Tamam, bunu nasıl düzgün bir şekilde yapılacağını sordun. Bir cevap verdim. Ya doğru bir şekilde yapmak istersiniz ya da yapmazsınız. CM'yi doğru yapmak zaman, para ve niyet gerektirir. LE aracılığıyla cer satın alma ve dağıtma gibi gereksinimleriniz varsa, Digital Ocean ile ayda 5US $ 'lık bir sanal makine açın ve bunu test için kullanın. Heck, değişiklikleri test etmek ve daha sonra öldürmek istediğinizde talep üzerine dağıtabilirsiniz.

— EEAA

Belki de deneyimsizliğimizden dolayı, elbette bir dizi ansible görevi tam olarak bir seferde ihtiyacımız olan şekilde yazamıyoruz, çünkü yapılandırma biraz deneme ve hata süreci. Bu, pratikte, öncelikle sunucuda çalıştırmak istediğimiz hizmeti yapılandırırız ve daha sonra ansible görevlere çeviririz anlamına gelir.

(Bir test ortamı olmaması gibi) başka sorunlar olsa da, yaparak değil büyük bir gelişme olabilir bu .

Biri yanıtlayıcı 'temel tasarım hedefleri olmaktır İdempotent , hangi taktik kitabı birden çok kez çalıştıran herhangi bir değişiklik gerektiğini araçlar (Eğer oyun değiştirdik sürece). Bu nedenle, yeni bir yazılım yapılandırırken adımlarım:

Ansible görevlerinde değişiklik yapın.
Başucu kitabını çalıştırın.
Sistemi inceleyin ve doğru değilse 1. adıma dönün.
Değişikliklerimi yap.

Eğer doğru şeyi yanıtlayıcı 'ilk kez yazacağım düşünüyorum yoksa, neyse yazmak o tıpkı diğer kodu gibi haklı kadar içinde ve tekrarlayın. Bu, yaptığınız bazı değişiklikleri Ansiblize etmeyi unutma şansınızı büyük ölçüde azaltır, çünkü yaptığınız her değişiklik, geliştirme süreciniz sırasında bir noktada Ansible'daydı.

— Xiong Chiamiov
kaynak

Evet, bu harika bir tavsiye. Bunu yapmak ve sunucunuzu her zaman bilinen iyi bir duruma geri getirebilmenizi sağlamak çok serbesttir - işler güneye giderse, sunucuyu nuke edin ve yeniden konuşlandırın.

— EEAA

Doğru, bunun şu anda olduğumuz yer ile olması gereken yer arasında çok sağlam bir orta yol olduğunu kabul ediyorum. Tabii ki böyle başladık. Sanırım şu anda bulunduğumuz yere sürüklenmemizin asıl nedeni, 2. adımın tüm döngünün çok uzun sürmesi oldu. Oyun kitaplarını yanlış yapıyor olabilirdik. Şimdi Ansible görevlerini yazarken biraz daha bilgili olduğumuza rağmen, tekrar denemeye değer olabilir. Deneyiminize göre, tam bir döngü ne kadar sürer ve ne sıklıkta tekrarlanır? Ben herhangi bir sayı her türlü varsayımlara dayalı olacağını biliyoruz ..

— Joost

Bu yinelemeli işlemde yaşadığım farklı bir sorun, değişiklik yapan bir görev yazdığınızda, değişiklikleri sunucuda yaptığınızda, değişikliklerin yanlış olduğunu keşfettiğinizde, görevinizi güncellediğinizde ve oynatma kitabını yeniden uyguladığınızda oluşur. Şimdi sunucu iki değişiklik kümesinin bir karışımını içerir: görevin ilk yinelemesinden olanlar ve ikincisinden olanlar. Genellikle ikinci yineleme ilkin üzerine yazılır, ancak her zaman değil. Her seferinde temiz kurulumdan başlayarak 1) geri almak için manuel olarak SSH 'yapmak yerine 2)' temizlemek 'için makul bir yol var mı?

— Joost

Ayrıca, sunucunuz nuking genellikle sadece bir tane varsa

— Thom Wiggers

"Deneyiminizde, tam bir döngü ne kadar sürer ve ne sıklıkta yinelenir?" - Ansible'ı Ocak ayında kullanmaya başladım; Haziran ayına gelindiğinde, Ansible'daki tüm süreci çoğu görev için elden daha hızlı yaptığım noktaya geldim . Elbette belirli bir süre, birkaç dakikadan birkaç haftaya kadar projeye bağlıdır (özellikle bazı cantankeöz yazılımlar için). Başucu kitabının çalışmasının sizi yavaşlattığını fark ederseniz , yineleme döngüleriniz sırasında yalnızca bir alt kümeyi çalıştırmak için etiketleri kullanmaya bakmak isteyebilirsiniz .

— Xiong Chiamiov

Ansible'ın önceki üretkenlik seviyenizi aşmadan önce hızlanma süresi vardır, ancak bunu yaptıktan sonra sistem durumunuzu sağlamak kolaydır. Uygulamalarınızın son hedeflerinizle senkronize olmadığı anlaşılıyor. Sağlam mühendislik uygulamalarını sürdürürken bir CM araç seti ile üretken olabilirsiniz, ancak doğru bir şekilde yapılandırılması zaman alır. Kararlılık ve kurumsal ölçeklenebilirlik için temelde işlem verimliliği ve kolay uygulama. Deneyimli bir profesyonel programcı aynı şekilde çirkin hackler yazmaz, sonuçlar her zaman avantajlardan daha ağır basar.

Yeni başlayanlar için, açık mülkiyet olmadan çok fazla aşçınız olabilir, eğer öyleyse müştereklerin bir trajedisini bekliyoruz. Her bir iş önceliği, yaygın olarak kötüye kullanılmadıkça ve geriye kalanlar doğrudan sorumlu mühendise yansımadıkça, sistem mühendisliği endişelerini her seferinde ortadan kaldıracaktır.

Bir CM araç seti yöneticiler tarafından tasarlanamaz, bu sadece farkına vardım. Mevcut işleri yeniden kullanabilirler veya OLASI gibi sağlam bir temele uzanabilirler, ancak o zaman bile külfetli bir uygulama uygulaması gerektirir. Bir Mühendis'in yapabileceği şey, yöneticinin yapabilecekleri DEĞİLDİR. Ansible'daki birçok kavram bir kod tabanındakiyle neredeyse aynıdır, bir Yönetici python'u öğretebilir ve yetkili sonuçlar bekleyebilir misiniz? Hayır, kesinlikle hayır, bir hack işi beklerdim, bu yüzden bir hack işinin katlanılabilir olması için görevi yeterince yapılandırmanız gerekir.

Bu yüzden başarı için bir şeyler ayarlamanız, gereksiz yönetim noktaları için çözümler üretmeniz gerekiyor. Bir yöneticinin başarılı bir şekilde yapabileceği şeyler için düşük düzeyli sistem karmaşıklığıyla ticaret yapın. CM araç seti sizi mimari veya tasarım uyumsuzluklarından KURTARMAZ.

Dolayısıyla düzen değişikliğe tabidir, çünkü uygulama şu anki durumunuz için hangi yolun en az yıkıcı olduğuna bağlıdır.

İşle ilgili iş akışı ile ilgili tüm sistem çalışmalarını özel bir özet haline getirin.
Kutudaki görevleri ayırın, şu anda bir veya iki kutunuz olabilir.
CM'nizi daha yapılandırılmış bir şekilde yeniden uygulayın ve daha iyi anlaşılabilir uygulamaları, işlevleri veya rolleri DEĞİL nesneleri temsil eden oyun kitaplarını takip edin. Her sistem bir oyunda açıklanmalıdır.

— JM Becker
kaynak