Bu konuşmanın transkriptidir и .
Bu, kendi kendine yazılmış bir konfigürasyon yönetim sistemi kullanan bir projenin ve Ansible'a geçişin neden 18 ay sürdüğünü anlatıyor.
Gün No. -ХХХ: Başlangıçtan önce
Başlangıçta altyapı, Hyper-V çalıştıran birçok ayrı ana bilgisayardan oluşuyordu. Bir sanal makine oluşturmak birçok adım gerektiriyordu: diskleri doğru yere yerleştirmek, DNS'yi kaydetmek, DHCP'yi ayırmak, VM yapılandırmasını git deposuna koymak. Bu süreç kısmen mekanikleştirildi ancak örneğin VM'ler ana bilgisayarlar arasında elle dağıtıldı. Ancak örneğin geliştiriciler git'teki VM yapılandırmasını düzeltebilir ve VM'yi yeniden başlatarak bunu uygulayabilir.
Özel Konfigürasyon Yönetimi Çözümü
Orijinal fikrin IaC olarak tasarlandığından şüpheleniyorum: yeniden başlatıldığında durumlarını sıfıra sıfırlayan birçok durum bilgisi olmayan VM. VM yapılandırma yönetimi neydi? Şematik olarak basit görünüyor:
- VM için statik bir MAC belirlendi.
- VM'ye CoreOS'lu bir ISO ve bir önyükleme diski bağlandı.
- CoreOS, özelleştirme komut dosyasını IP'sine göre WEB sunucusundan indirerek başlatır.
- Betik, IP adresine dayalı olarak VM yapılandırmasını SCP aracılığıyla indirir.
- Systemd birim dosyalarının taban örtüsü ve bash komut dosyalarının taban örtüsü başlatılır.
Bu çözümün birçok bariz sorunu vardı:
- CoreOS ISO kullanımdan kaldırıldı.
- VM'leri taşırken/oluştururken birçok karmaşık otomatik eylem ve sihir.
- Güncelleme zorluğu ve belirli bir yazılım sürümüne ihtiyaç duyulması. Çekirdek modülleriyle daha da eğlenceli.
- VM'ler veri olmadan bu şekilde elde edilemedi; VM'ler ek kullanıcı verilerinin takılı olduğu bir diskle ortaya çıktı.
- Birisi sürekli olarak sistem birimi bağımlılıklarını bozuyordu ve CoreOS yeniden başlatıldığında donuyordu. CoreOS'taki mevcut araçları kullanarak bunu yakalamak zordu.
- Sırlar yönetimi.
- CM yoktu. CoreOS için bash ve YML yapılandırmaları vardı.
VM yapılandırmasını uygulamak için yeniden başlatmanız gerekir, ancak yeniden başlatılmayabilir. Bu bariz bir sorun gibi görünüyor, ancak kalıcı diskler yok - günlükleri kaydedecek yer yok. Tamam, günlüklerin gönderilmesi için çekirdek yükleme seçeneğini eklemeye çalışalım. Ama hayır, her şey ne kadar karmaşık.
0. Gün: Sorunu tanıyın
Her zamanki geliştirme altyapısıydı: jenkins, test ortamları, izleme, kayıt defteri. CoreOS, k8 kümelerini barındırmak için tasarlandı; sorun CoreOS'un nasıl kullanıldığıydı. İlk adım bir yığın seçmekti. Şuna karar verdik:
- CentOS temel dağılım olarak, çünkü Bu, üretim ortamlarına en yakın dağıtımdır.
- yanıtlayıcı ' konfigürasyon yönetimi için, çünkü üzerinde kapsamlı bir inceleme yapıldı.
- Jenkins mevcut süreçleri otomatikleştirmek için bir çerçeve olarak, çünkü halihazırda geliştirme süreçlerinde aktif olarak kullanılıyor
- Hiper-V sanallaştırma platformu olarak Hikâyenin kapsamını aşan birçok neden var ama kısacası bulutları kullanamıyoruz, kendi donanımlarımızı kullanmalıyız.
30. Gün: Mevcut anlaşmaların düzeltilmesi - Kod Olarak Anlaşmalar
Yığın temizlendiğinde taşınma hazırlıkları başladı. Mevcut anlaşmaların kod şeklinde düzeltilmesi (Kod Olarak Sözleşmeler!). Geçiş el emeği -> makineleşme -> otomasyon.
1. VM'leri yapılandırın
Ansible bu konuda harika bir iş çıkarıyor. Minimum vücut hareketi ile VM yapılandırmalarının kontrolünü ele alabilirsiniz:
- Git deposu oluşturun.
- VM'lerin listesini envantere, yapılandırmaları ise başucu kitaplarına ve rollere koyarız.
- Ansible'ı çalıştırabileceğiniz özel bir jenkins kölesi kuruyoruz.
- Bir iş yaratıyoruz ve Jenkins'i yapılandırıyoruz.
İlk süreç hazır. Anlaşmalar sabittir.
2. Yeni VM oluşturun
Buradaki her şey pek uygun değildi. Linux'tan Hyper-V üzerinde VM oluşturmak pek uygun değil. Bu süreci makineleştirmeye yönelik girişimlerden biri şuydu:
- Ansbile, WinRM aracılığıyla Windows ana bilgisayarına bağlanır.
- Ansible bir powershell betiğini çalıştırır.
- Powershell betiği yeni bir VM oluşturur.
- Hyper-V/ScVMM kullanılarak konuk işletim sisteminde bir VM oluşturulurken ana bilgisayar adı yapılandırılır.
- DHCP kirasını güncellerken VM, ana bilgisayar adını gönderir.
- Etki Alanı Denetleyicisi tarafındaki standart ddns & dhcp entegrasyonu, DNS kaydını yapılandırır.
- Envanterinize bir VM ekleyebilir ve onu Ansible ile yapılandırabilirsiniz.
3. VM şablonu oluşturun
Burada hiçbir şey icat etmediler - bir paketleyici aldılar.
- Paketleyiciyi, kickstart yapılandırmasını git deposuna ekleyin.
- Hyper-v ve Packer ile özel bir jenkins kölesi kurma.
- Bir iş yaratıyoruz ve Jenkins'i yapılandırıyoruz.
Bu bağlantı nasıl çalışır:
- Packer boş bir VM oluşturur ve ISO'yu alır.
- VM önyükleme yapar, Packer, kickstart dosyamızı bir disketten veya http'den kullanmak için önyükleyiciye komutu girer.
- Anaconda yapılandırmamızla başlatılır ve ilk işletim sistemi yapılandırması yapılır.
- Packer, VM'nin kullanılabilir olmasını bekler.
- VM içindeki Packer, yerel modda ansible'ı çalıştırır.
- Ansible, 1. adımda çalıştığı rollerin tamamen aynısını kullanır.
- Packer, VM şablonunu dışa aktarır.
Gün #75: Anlaşmayı bozmadan yeniden düzenleme = Yanıtlayıcıyı test etme + Testkitchen
Koddaki kuralları yakalamak yeterli olmayabilir. Sonuçta, sürecin tüm ayrıntılarında bir şeyi değiştirmek isterseniz, bir şeyi bozabilirsiniz. Dolayısıyla altyapı söz konusu olduğunda tam da bu altyapının test edilmesi ortaya çıkıyor. Ekip içindeki bilgiyi senkronize etmek için Ansible rollerini test etmeye başladık. Derinliğe girmeyeceğim çünkü... o dönemdeki olayları anlatan bir makale var (spoiler bu son versiyon değildi ve daha sonra her şey daha karmaşık hale geldi) ).
Gün #130: Belki CentOS+ansible'a ihtiyaç yoktur? belki açık vites?
Altyapının hayata geçirilmesi sürecinin tek süreç olmadığını ve yan alt projelerin de olduğunu anlamalıyız. Örneğin uygulamamızın openshift olarak devreye alınması yönünde bir talep geldi ve bu da bir haftadan fazla süren araştırmayla sonuçlandı. bu da taşınma sürecini yavaşlattı. Sonuç olarak, açık vardiyanın tüm ihtiyaçları karşılamadığı ortaya çıktı; gerçek donanıma ya da en azından çekirdekle oynama yeteneğine ihtiyacınız var.
Gün #170: Openshift uygun değil, Windows Azure Pack'i deneyelim mi?
Hyper-V pek kullanıcı dostu değil, SCVMM onu pek de iyi yapmıyor. Ancak SCVMM'ye eklenti olan ve Azure'u taklit eden Windows Azure Pack diye bir şey var. Ancak gerçekte ürün terk edilmiş görünüyor: belgelerde kopuk bağlantılar var ve çok seyrek. Ancak bulutumuzun ömrünü basitleştirmeye yönelik seçenekler üzerine yapılan çalışmanın bir parçası olarak ona da baktılar.
Gün #250: Windows Azure Paketi pek iyi değil. SCVMM'de kalıyoruz
Windows Azure Paketi umut verici görünüyordu, ancak gereksiz özellikler uğruna WAP'ın karmaşıklıklarıyla birlikte sisteme getirilmemesine karar verildi ve SCVMM'de kaldı.
Gün #360: Fili parça parça yemek
Sadece bir yıl sonra taşınmanın yapılacağı platform hazırdı ve taşınma süreci başladı. Bu amaçla bir SMART görevi belirlendi. Tüm VM'leri kontrol ettik ve konfigürasyonu tek tek çözmeye, Ansible'da açıklamaya ve testlerle ele almaya başladık.
Gün #450: Nasıl bir sistem aldınız?
Sürecin kendisi ilginç değil. Bu rutin bir durumdur; konfigürasyonların çoğunun nispeten basit veya izomorfik olduğu ve Pareto ilkesine göre VM konfigürasyonlarının %80'inin, zamanın %20'sini gerektirdiği belirtilebilir. Aynı prensibe göre, zamanın %80'i hamleyi hazırlarken, yalnızca %20'si ise hamlenin kendisinde harcanıyordu.
Gün #540: Final
18 ayda ne oldu?
- Anlaşmalar kod haline geldi.
- El emeği -> makinalaştırma -> Otomasyon.
Hızlı Linkler
Kaynak: habr.com