Bu makale “Ağ Altyapınızın Kontrolünü Nasıl Ele Geçirirsiniz?” serisinin altıncı makalesidir. Serideki tüm yazıların içeriğine ve bağlantılara ulaşabilirsiniz .
Birçok konuyu geride bırakıp yeni bir bölüme başlamaya karar verdim.
Biraz sonra güvenliğe döneceğim. Burada, şu ya da bu şekilde birçok kişiye faydalı olabileceğinden emin olduğum basit ama etkili bir yaklaşımı tartışmak istiyorum. Bu daha çok otomasyonun bir mühendisin hayatını nasıl değiştirebileceğine dair kısa bir hikaye. Şablonların kullanımı hakkında konuşacağız. Sonunda burada açıklanan her şeyin nasıl çalıştığını görebileceğiniz projelerimin bir listesi var.
Ağ için DevOps
Bir komut dosyasıyla yapılandırma oluşturma, BT altyapısındaki değişiklikleri kontrol etmek için GIT'i kullanma, uzaktan "yükleme" - DevOps yaklaşımının teknik uygulamasını düşündüğünüzde bu fikirler ilk önce gelir. Avantajları açıktır. Ama maalesef dezavantajları da var.
5 yıldan fazla bir süre önce geliştiricilerimiz ağ oluşturucular olarak bize bu tekliflerle geldiğinde pek memnun kalmamıştık.
Yaklaşık 10 farklı tedarikçinin ekipmanlarından oluşan, oldukça karışık bir ağ devraldığımızı söylemeliyim. Bazı şeyleri favori cli'miz aracılığıyla yapılandırmak uygundu, ancak diğerlerinde GUI'yi kullanmayı tercih ettik. Ayrıca "canlı" ekipmanlar üzerinde uzun çalışmamız bize gerçek zamanlı kontrolü öğretti. Örneğin, değişiklik yaparken doğrudan cli üzerinden çalışırken kendimi çok daha rahat hissediyorum. Bu şekilde bir şeylerin ters gittiğini hızlı bir şekilde görebilir ve değişiklikleri geri alabilirim. Bütün bunlar onların fikirleriyle çelişiyordu.
Başka sorular da ortaya çıkıyor; örneğin arayüz, yazılımın sürümünden sürümüne biraz değişebilir. Bu, sonunda betiğinizin yanlış "config" oluşturmasına neden olacaktır. Üretimi “koşmak” için kullanmak istemem.
Veya konfigürasyon komutlarının doğru uygulandığını ve hata durumunda ne yapılacağını nasıl anlayacağız?
Bütün bu sorunların çözülemez olduğunu söylemek istemiyorum. Yalnızca "A" demek muhtemelen "B" demek de mantıklı olacaktır ve değişiklik kontrolü için geliştirmede olduğu gibi aynı süreçleri kullanmak istiyorsanız üretimin yanı sıra geliştirme ve hazırlama ortamlarına da sahip olmanız gerekir. O zaman bu yaklaşım tamamlanmış görünüyor. Ama maliyeti ne kadar olacak?
Ancak dezavantajların pratik olarak dengelendiği ve yalnızca avantajların kaldığı bir durum vardır. Tasarım çalışmalarından bahsediyorum.
Proje
Son iki yıldır büyük bir sağlayıcı için veri merkezi kurma projesine katılıyorum. Bu projede F5 ve Palo Alto'dan sorumluyum. Cisco'nun bakış açısına göre bu “3. taraf ekipmanıdır”.
Şahsen benim için bu projenin iki ayrı aşaması var.
İlk aşama
İlk yıl sonsuz meşguldüm, geceleri ve hafta sonları çalıştım. Başımı kaldıramadım. Yönetimin ve müşterinin baskısı güçlü ve sürekliydi. Sürekli bir rutin içinde süreci optimize etmeye bile çalışamadım. Tasarım belgelerinin hazırlanması kadar, sadece ekipmanın konfigürasyonu da değildi.
İlk testler başladı ve ne kadar çok küçük hata ve yanlışlığın yapıldığına şaşırdım. Elbette her şey işe yaradı ama isimde eksik bir harf vardı, komutta eksik bir satır vardı... Testler devam etti ve ben zaten günlük olarak hatalar, testler ve dokümantasyonla sürekli bir mücadele içindeydim. .
Bu bir yıl boyunca devam etti. Anladığım kadarıyla proje herkes için kolay değildi, ancak müşteri giderek daha fazla memnun kaldı ve bu, rutinin bir kısmını kendileri üstlenebilecek ek mühendislerin işe alınmasını mümkün kıldı.
Artık biraz etrafa bakabiliriz.
Ve bu ikinci aşamanın başlangıcıydı.
İkinci aşama
Süreci otomatikleştirmeye karar verdim.
O dönemde geliştiricilerle olan iletişimimden anladığım şey (ve saygılarımızı sunmalıyız, güçlü bir ekibimiz vardı), ilk bakışta DOS işletim sistemi dünyasından bir şey gibi görünse de metin formatının bir dizi numarası var. değerli mülklerden.
Yani örneğin GIT ve onun tüm türevlerinden tam olarak yararlanmak istiyorsanız metin formatı faydalı olacaktır. Ben de istedim.
Görünüşe göre bir konfigürasyonu veya komut listesini kolayca saklayabilirsiniz, ancak değişiklik yapmak oldukça zahmetlidir. Ayrıca tasarım sırasında önemli bir görev daha vardır. Tasarımınızı bir bütün olarak (Düşük Düzey Tasarım) ve özel uygulamayı (Ağ Uygulama Planı) açıklayan belgelere sahip olmalısınız. Ve bu durumda şablonların kullanımı çok uygun bir seçenek gibi görünüyor.
Dolayısıyla, YAML ve Jinja2 kullanıldığında, IP adresleri, BGP AS numaraları gibi yapılandırma parametrelerine sahip bir YAML dosyası, NIP rolünü mükemmel bir şekilde yerine getirirken, Jinja2 şablonları tasarıma karşılık gelen sözdizimini içerir, yani esasen bir LLD'nin yansıması.
YAML ve Jinja2'yi öğrenmek iki gün sürdü. Bunun nasıl çalıştığını anlamak için birkaç iyi örnek yeterlidir. Daha sonra tasarımımıza uygun tüm şablonları oluşturmak yaklaşık iki hafta sürdü: Palo Alto için bir hafta ve F5 için bir hafta daha. Bütün bunlar kurumsal githab'ta yayınlandı.
Artık değişim süreci şöyle görünüyordu:
- YAML dosyasını değiştirdi
- şablon kullanarak bir yapılandırma dosyası oluşturdu (Jinja2)
- uzak bir depoya kaydedildi
- oluşturulan konfigürasyonu ekipmana yükledi
- Bir hata gördüm
- YAML dosyasını veya Jinja2 şablonunu değiştirdi
- şablon kullanarak bir yapılandırma dosyası oluşturdu (Jinja2)
- ...
İlk başta düzenlemelere çok fazla zaman harcandığı açık, ancak bir veya iki hafta sonra bu oldukça nadir hale geldi.
İyi bir test ve her şeyin hatalarını ayıklama fırsatı, müşterinin adlandırma kuralını değiştirme isteğiydi. F5 ile çalışanlar durumun ciddiyetini anlıyor. Ama benim için her şey oldukça basitti. YAML dosyasındaki isimleri değiştirdim, tüm konfigürasyonu ekipmandan sildim, yenisini oluşturup yükledim. Hata düzeltmeleri dahil her şey 4 gün sürdü; her teknoloji için iki gün. Bundan sonra bir sonraki aşama olan DEV ve Staging veri merkezlerinin oluşturulmasına hazırdım.
Geliştirme ve Hazırlama
Aşamalama aslında üretimi tamamen kopyalar. Dev, esas olarak sanal donanım üzerine inşa edilmiş, oldukça basitleştirilmiş bir kopyadır. Yeni bir yaklaşım için ideal bir durum. Harcadığım zamanı sürecin genelinden ayırırsam işin 2 haftadan fazla sürmediğini düşünüyorum. Esas olan karşı tarafı beklemek ve sorunları birlikte aramaktır. 3. tarafın uygulanması başkaları tarafından neredeyse fark edilmedi. Hatta bir şeyler öğrenip Habré hakkında birkaç makale yazmaya bile zamanım oldu :)
özetlemek gerekirse
Peki sonuç olarak elimde ne var?
- Yapılandırmayı değiştirmek için tek yapmam gereken, yapılandırma parametreleriyle birlikte basit, anlaşılır biçimde yapılandırılmış bir YAML dosyasını değiştirmek. Python betiğini asla değiştirmem ve çok nadiren (yalnızca bir hata varsa) Jinja2'nin ısıtma süresini değiştiririm
- Dokümantasyon açısından bakıldığında bu neredeyse ideal bir durumdur. Belgeleri değiştirirsiniz (YAML dosyaları NIP görevi görür) ve bu konfigürasyonu ekipmana yüklersiniz. Bu şekilde belgeleriniz her zaman güncel olur
Bütün bunlar şu gerçeği ortaya çıkardı:
- hata oranı neredeyse 0'a düştü
- Rutinin yüzde 90'ı gitti
- uygulama hızı önemli ölçüde arttı
ÖDEME, F5Y, ACY
Nasıl çalıştığını anlamak için birkaç örnek yeterlidir dedim.
İşte çalışmalarım sırasında yaratılanların kısa (ve elbette değiştirilmiş) bir versiyonu.
= dağıtım Palo Aitibaren Yaml = Yaml'den Palo Alto
= dağıtım F5 itibaren Yaml = F5 itibaren Yaml (çok yakında)
= dağıtım ACben Yaml = F5 itibaren Yaml
ACY hakkında birkaç kelime ekleyeceğim (ACI ile karıştırılmamalıdır).
ACI ile çalışmış olanlar bu mucizenin (ve iyi anlamda da) kesinlikle networkerlar tarafından yaratılmadığını biliyorlar :). Ağ hakkında bildiğiniz her şeyi unutun; işinize yaramayacaktır!
Biraz abartılı ama kabaca son 3 yıldır ACI ile çalışırken sürekli yaşadığım duyguyu yansıtıyor.
Ve bu durumda, ACY yalnızca bir değişiklik kontrol süreci oluşturmak için bir fırsat olmakla kalmaz (bu, ACI durumunda özellikle önemlidir, çünkü bunun veri merkezinizin merkezi ve en kritik parçası olması gerekir), aynı zamanda size konfigürasyon oluşturmak için kullanıcı dostu bir arayüz.
Bu projedeki mühendisler, tamamen aynı amaçlar doğrultusunda YAML yerine ACI'yi yapılandırmak için Excel'i kullanıyor. Elbette Excel kullanmanın avantajları vardır:
- NIP'niz tek dosyada
- müşterinin bakması hoş olan güzel işaretler
- bazı excel araçlarını kullanabilirsiniz
Ama bir eksisi var ve bence artılarından daha ağır basıyor. Değişiklikleri kontrol etmek ve ekip çalışmasını koordine etmek çok daha zor hale geliyor.
ACY aslında 3. tarafın ACI'yı yapılandırması için kullandığım yaklaşımların aynısının bir uygulamasıdır.
Kaynak: habr.com