Ulusal Çevresel Uydu Veri Bilgi Hizmeti (NESDIS), Puppet Enterprise'dan Ansible Tower'a geçiş yaparak Red Hat Enterprise Linux (RHEL) için yapılandırma yönetimi maliyetlerini %35 azalttı. Bu "bunu nasıl yaptık" videosunda sistem mühendisi Michael Rau, bir SCM'den diğerine geçişten öğrenilen faydalı ipuçlarını ve dersleri paylaşarak bu geçişin durumunu açıklıyor.
Bu videoda şunları öğreneceksiniz:
- Puppet Enterprise'dan Ansible Tower'a geçişin fizibilitesinin yönetime nasıl gerekçelendirileceği;
- geçişi mümkün olduğunca sorunsuz hale getirmek için hangi stratejilerin kullanılması gerektiği;
- PE bildirimlerini Ansible Playbook'a dönüştürmek için ipuçları;
- Ansible Tower'ın optimum kurulumu için öneriler.
Herkese merhaba, adım Michael Rau, Ulusal Okyanus ve Atmosfer İdaresi (NOAA) NESDIS hizmeti için çalışan ActioNet'te Kıdemli Sistem Mühendisiyim. Bugün ip kesme hakkında konuşacağız - Puppet Enterprise'dan Ansible Tower'a geçiş deneyimim. Bu sunumun teması, yılın başında bu geçişi yaptıktan sonra kalan “yaralarıma bir bakmak”. Bu süreçte öğrendiklerimi paylaşmak istiyorum. Yani böyle bir işi üstlendiğinizde benim deneyimimi kullanarak ekstra bir çalışma yapmadan geçişi gerçekleştirebilirsiniz.
Ansible Fest'te her sunumun başında buna benzer slaytlar görüyorsunuz. Bu slayt şirketimin otomasyonunun geçmişini özetlemektedir. Bu konuda yeni değilim çünkü 2007'den beri Puppet/Puppet Enterprise'ı kullanıyorum. 2016 yılında Ansible ile çalışmaya başladım ve bu ürünün diğer birçok kullanıcısı gibi ben de komut satırını ve basit komut dosyalarını (başucu kitapları) kullanarak "hileler" yapma olasılığından etkilendim. 2017 yılının sonunda Ansible Tower'a taşınmamın güçlü nedenleri hakkında yönetimime başvurdum. Birazdan beni bu adımı atmaya iten nedenleri anlatacağım. Yönetimin onayını aldıktan sonra planın tamamlanması birkaç ay daha sürdü ve geçişi bu yılın Ocak-Şubat aylarında gerçekleştirdim. Yani Puppet'ı tamamen bırakıp Ansible'ı tercih ettik ve bu harika bir şey.
Ansible'da bana en çok çekici gelen şey, rolleri ve başucu kitaplarını yazma ve kullanma becerisidir. Roller, farklı ancak ilişkili görevler oluşturmak ve bu görevlerle ilgili tüm verileri tek bir yere koymak için mükemmeldir. Playbook, bir veya daha fazla ana bilgisayarın eylemlerini açıklayan bir YAML sözdizimi, komut dosyasıdır. Bu özellikleri başta yazılım geliştiriciler olmak üzere kullanıcılara anlatıyorum. Ansible Tower size "hayır, kabuk erişiminiz yok, ancak size tüm Tower süreçlerini çalıştırma ve ihtiyaç duyduğunuzda hizmeti yeniden başlatma yeteneği veriyorum" deme yeteneğini veriyor. Size çalışma ortamını ve kullandığımız ekipmanları anlatacağım.
Bu federal bir LAN, bulut MPLS aracılığıyla bağlanan 7 fiziksel site, %140'u sanal olan 99 RHEL sunucusu (vSphere), SuperMicro donanımı, NexentaStore ağ depolaması, bir dizi Cisco, Arista ve Cumulus anahtarı ve Fortinet UTM birleşik tehdit yönetimidir. Her sitedeki araçlar.
Federal ağ, yasaların sağladığı tüm bilgi güvenliği önlemlerini kullanmam gerektiği anlamına geliyor. Puppet Enterprise'ın kullandığımız donanımların çoğunu desteklemediğini unutmayın. Devlet kurumlarının bu gider kalemini finanse etmekte sıkıntı yaşaması nedeniyle bütçe donanımlarını kullanmak zorunda kalıyoruz. Bu nedenle SuperMicro donanımı satın alıyoruz ve ekipmanımızı, bakımı devlet sözleşmeleriyle garanti edilen ayrı parçalardan monte ediyoruz. Linux kullanıyoruz ve Ansible'a geçmemizin önemli nedenlerinden biri de bu.
Puppet ile geçmişimiz şu şekildedir.
2007 yılında Puppet'ı konuşlandırdığımız 20-25 düğümden oluşan küçük bir ağımız vardı. Temel olarak bu düğümler yalnızca RedHat “kutularıydı”. 2010 yılında Puppet Dashboard web arayüzünü 45 düğüm için kullanmaya başladık. Ağ genişlemeye devam ettikçe 2014 yılında PE 3.3'e geçtik ve 75 düğüm için bildirimin yeniden yazılmasıyla tam bir geçiş yaptık. Bunun yapılması gerekiyordu çünkü Puppet oyunun kurallarını değiştirmeyi seviyordu ve bu durumda dili tamamen değiştirdiler. Bir yıl sonra Puppet Enterprise'ın 3. sürümüne yönelik destek sona erdiğinde PE 2015.2'ye geçmek zorunda kaldık. O zamanlar sadece 100 düğümümüz olmasına rağmen, yeni sunucular için manifestoyu yeniden yazmak ve 85 düğüm rezervli bir lisans satın almak zorunda kaldık.
Yalnızca 2 yıl geçti ve yeni PE 2016.4 sürümüne geçmek için yine çok çalışmamız gerekti. Yalnızca 300 düğüme sahip 130 düğüm için bir lisans satın aldık. Dilin yeni sürümünün 2015 sürümünün dilinden farklı bir sözdizimine sahip olması nedeniyle manifestte yine büyük değişiklikler yapmak zorunda kaldık. Sonuç olarak SCM'miz SVN sürüm kontrolünden Bitbucket'e (Git) geçti. Puppet'la olan “ilişkimiz” buydu.
Bu nedenle, aşağıdaki argümanları kullanarak neden farklı bir SCM'ye geçmemiz gerektiğini yönetime açıklamam gerekiyordu. Birincisi, hizmetin yüksek fiyatıdır. RedHat'taki adamlarla konuştum ve Ansible Tower ile 300 düğümlü bir ağ çalıştırmanın maliyetinin Puppet Enterprise'ın maliyetinin yarısı kadar olduğunu söylediler. Ansible Engine'i de satın alırsanız maliyet hemen hemen aynı olacaktır ancak PE'den çok daha fazla özelliğe sahip olacaksınız. Federal bütçeden finanse edilen devlete ait bir şirket olduğumuz için bu oldukça güçlü bir argüman.
İkinci argüman çok yönlülüktür. Puppet yalnızca Puppet aracısına sahip donanımı destekler. Bu, tüm anahtarlara bir aracının yüklenmesi gerektiği ve bunun en son sürüm olması gerektiği anlamına gelir. Anahtarlarınızdan bazıları bir sürümü destekliyorsa ve bazıları başka bir sürümü destekliyorsa, hepsinin aynı SCM sisteminde çalışabilmesi için onlara PE aracısının yeni bir sürümünü yüklemeniz gerekecektir.
Ansible Tower sistemi herhangi bir aracıya sahip olmadığından farklı çalışır ancak Cisco anahtarlarını ve diğer tüm anahtarları destekleyen modüllere sahiptir. Bu SCM, Qubes OS, Linux ve 4.NET UTM'yi destekler. Ansible Tower ayrıca açık kaynaklı Unix tabanlı bir işletim sistemi olan Illumos çekirdeğini temel alan NexentaStore ağ depolama denetleyicilerini de destekler. Bu çok az bir destek ama Ansible Tower yine de bunu yapıyor.
Hem benim hem de yönetimimiz açısından çok önemli olan üçüncü argüman ise kullanım kolaylığıdır. Puppet modülleri ve bildirim kodu konusunda uzmanlaşmak için 10 yılımı harcadım, ancak Ansible'ı bir hafta içinde öğrendim çünkü bu SCM ile çalışmak çok daha kolay. Yürütülebilir dosyaları çalıştırırsanız, tabii ki gereksiz bir şekilde yapmadığınız sürece, akıllı ve duyarlı işleyiciler bunlarla çalışır. YAML tabanlı taktik kitaplarının öğrenilmesi kolay ve kullanımı hızlıdır. YAML'ı daha önce duymamış olanlar sadece scriptleri okuyup nasıl çalıştığını kolaylıkla anlayabilirler.
Dürüst olmak gerekirse Puppet, geliştirici olarak işinizi çok daha zorlaştırıyor çünkü Puppet Master'ı kullanmaya dayanıyor. Puppet ajanlarıyla iletişim kurmasına izin verilen tek makinedir. Bildiride herhangi bir değişiklik yaptıysanız ve kodunuzu test etmek istiyorsanız, Puppet Master kodunu yeniden yazmanız, yani Puppet Master /etc/hosts dosyasını tüm istemcilere bağlanacak ve Puppet Server hizmetini başlatacak şekilde yapılandırmanız gerekir. Ancak bundan sonra ağ ekipmanının çalışmasını bir ana bilgisayarda test edebileceksiniz. Bu oldukça acı verici bir işlemdir.
Ansible'da her şey çok daha basit. Tek yapmanız gereken, test edilen ana bilgisayarla SSH aracılığıyla iletişim kurabilen bir makine için kod geliştirmektir. Bununla çalışmak çok daha kolaydır.
Ansible Tower'ın bir sonraki büyük avantajı, mevcut destek sisteminizden yararlanma ve mevcut donanım yapılandırmanızı koruma yeteneğidir. Bu SCM, herhangi bir ek adım olmadan altyapınız ve donanımınız, sanal makineleriniz, sunucularınız vb. hakkındaki mevcut tüm bilgileri kullanır. Varsa RH Satellite sunucularınızla konuşabilir ve size Puppet ile asla elde edemeyeceğiniz entegrasyonlar sunar.
Bir diğer önemli husus ise detaylı kontroldür. Puppet'in modüler bir sistem olduğunu, bir istemci-sunucu uygulaması olduğunu biliyorsunuz, bu nedenle tüm makinelerinizin mevcut yönlerini tek bir uzun bildirimde tanımlamanız gerekir. Bu durumda, sistemin her bir elemanının durumu her yarım saatte bir test edilmelidir; bu, varsayılan dönemdir. Kukla bu şekilde çalışır.
Tower sizi bundan kurtarır. Çeşitli ekipmanlar üzerinde çeşitli işlemleri kısıtlama olmadan çalıştırabilirsiniz; temel işleri yapabilir, diğer önemli işlemleri yürütebilir, bir güvenlik sistemi kurabilir ve veritabanlarıyla çalışabilirsiniz. Puppet Enterprise'da zor olan her şeyi yapabilirsiniz. Dolayısıyla, eğer onu bir ana bilgisayarda yapılandırdıysanız, değişikliklerin geri kalan ana makinelerde etkili olması zaman alacaktır. Ansible'da tüm değişiklikler aynı anda etkili olur.
Son olarak güvenlik modülüne bakalım. Ansible Tower bunu inanılmaz bir hassasiyet ve özenle, şaşırtıcı bir şekilde uyguluyor. Kullanıcılara belirli hizmetlere veya belirli ana bilgisayarlara erişim izni verebilirsiniz. Bunu Windows üzerinde çalışmaya alışkın olan çalışanlarımla Linux kabuğuna erişimlerini sınırlandırarak yapıyorum. Yalnızca kendileriyle ilgili işi yapabilmeleri ve hizmetleri yürütebilmeleri için Tower'a erişimlerinin olmasını sağlıyorum.
Ansible Tower'a geçişinizi kolaylaştırmak için önceden yapmanız gerekenlere bir bakalım. Öncelikle ekipmanınızı hazırlamanız gerekiyor. Altyapınızın bazı unsurları halihazırda veritabanında bulunmuyorsa, bunları oraya eklemeniz gerekir. Özelliğini değiştirmeyen ve dolayısıyla Puppet veritabanında bulunmayan sistemler var ancak bunları Tower'a taşınmadan önce oraya eklemezseniz bir takım avantajları kaybedersiniz. Bu "kirli" bir ön veri tabanı olabilir, ancak sahip olduğunuz tüm ekipmanlar hakkında bilgi içermelidir. Bu nedenle, tüm altyapı değişikliklerini otomatik olarak veritabanına aktaracak dinamik bir donanım komut dosyası yazmalısınız, ardından Ansible yeni sistemde hangi ana bilgisayarların bulunması gerektiğini bilecektir. Hangi ana bilgisayarları eklediğinizi ve hangi ana bilgisayarların artık mevcut olmadığını SCM'ye söylemenize gerek kalmayacak çünkü o tüm bunları otomatik olarak bilecek. Veritabanında ne kadar çok veri varsa Ansible o kadar kullanışlı ve esnek olacaktır. Sanki bir veritabanından donanım durumu barkodunu okuyormuş gibi çalışır.
Ansible'daki komut satırını tanımak için biraz zaman ayırın. Donanım komut dosyasını test etmek için bazı özel komutlar çalıştırın, bazı basit ama kullanışlı oyun kitabı komut dosyaları yazın ve çalıştırın, uygun olduğunda Jinja2 şablonlarını kullanın. Yaygın olarak karşılaşılan bir donanım yapılandırmasını kullanarak karmaşık, çok adımlı bir süreç için bir rol ve komut dosyası yazmayı deneyin. Bunlarla oynayın, nasıl çalıştığını test edin. Bu şekilde Tower'da kullanılan kitaplık oluşturma araçlarını nasıl kullanacağınızı öğreneceksiniz. Geçişe hazırlanmamın yaklaşık 3 ay sürdüğünü daha önce söylemiştim. Deneyimlerime dayanarak bunu daha hızlı yapabileceğinizi düşünüyorum. Bu zamanı boşa harcamayın çünkü daha sonra yapılan işin tüm faydalarını deneyimleyeceksiniz.
Daha sonra Ansible Tower'dan ne beklediğinize, bu sistemin sizin için tam olarak ne yapması gerektiğine karar vermeniz gerekiyor.
Sistemi çıplak donanıma, çıplak sanal makinelere dağıtmanız mı gerekiyor? Yoksa mevcut ekipmanın orijinal çalışma koşullarını ve ayarlarını korumak mı istiyorsunuz? Bu, halka açık şirketler için çok önemli bir husustur, bu nedenle Ansible'ı mevcut yapılandırmanıza taşıyabileceğinizden ve dağıtabileceğinizden emin olmanız gerekir. Otomatikleştirmek istediğiniz rutin idari süreçleri tanımlayın. Yeni sistemde belirli uygulamaları ve hizmetleri dağıtmanız gerekip gerekmediğini öğrenin. Yapmak istediklerinizin bir listesini yapın ve önceliklendirin.
Ardından tamamlamayı planladığınız görevleri mümkün kılacak komut dosyası kodunu ve rollerini yazmaya başlayın. Bunları, ilgili oyun kitaplarından oluşan mantıksal bir koleksiyon olan Projelerde birleştirin. Her Proje, kullandığınız kod yöneticisine bağlı olarak ayrı bir Git deposuna veya farklı bir depoya ait olacaktır. Başucu kitabı komut dosyalarını ve başucu kitabı dizinlerini Tower sunucusundaki Proje Tabanı Yolu'na manuel olarak yerleştirerek veya başucu kitabını Git, Subversion, Mercurial ve Red Hat dahil olmak üzere Tower tarafından desteklenen herhangi bir kaynak kodu yönetimi (SCM) sistemine yerleştirerek yönetebilirsiniz. Analizler. Bir Projeye istediğiniz kadar komut dosyası yerleştirebilirsiniz. Örneğin, RedHat çekirdek öğeleri için bir komut dosyası, Linux çekirdeği için bir komut dosyası ve temellerin geri kalanı için komut dosyaları yerleştirdiğim bir temel Proje oluşturdum. Dolayısıyla bir projede, tek bir Git deposundan yönetilen çeşitli roller ve senaryolar vardı.
Tüm bunları komut satırı üzerinden çalıştırmak, bunların işlevselliğini test etmenin iyi bir yoludur. Bu sizi Tower kurulumuna hazırlayacaktır.
Biraz Puppet manifestosunun kodunun dönüştürülmesinden bahsedelim, çünkü gerçekte ne yapılması gerektiğini anlayana kadar bunun üzerinde çok zaman harcadım.
Daha önce de söylediğim gibi Puppet tüm ayarları ve donanım seçeneklerini tek bir uzun manifestte saklıyor ve bu manifesto da bu SCM'nin yapması gereken her şeyi saklıyor. Geçiş yaparken tüm görevlerinizi tek bir listeye sıkıştırmanıza gerek yok; bunun yerine yeni sistemin yapısını düşünün: roller, komut dosyaları, etiketler, gruplar ve oraya nelerin gitmesi gerektiği. Otonom ağ öğelerinden bazıları, komut dosyalarının oluşturulabileceği gruplar halinde gruplandırılmalıdır. Bağımsız sınıflar da dahil olmak üzere çok sayıda kaynak içeren daha karmaşık altyapı öğeleri roller halinde birleştirilebilir. Taşınmadan önce buna karar vermeniz gerekir. Tek ekrana sığmayan büyük roller veya senaryolar oluşturuyorsanız altyapının belirli bölümlerini yakalayabilmek için etiketleri kullanmalısınız.
18:00
Bazı reklamlar 🙂
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com