Şirketimiz bir SRE ekibini işe alma sürecindedir. Bütün bu hikayeye geliştirme tarafından girdim. Bu süreçte diğer geliştiricilerle paylaşmak istediğim düşünce ve içgörüleri buldum. Bu yansıma yazısında neler olduğundan, nasıl olduğundan ve herkesin bununla nasıl yaşamaya devam edebileceğinden bahsediyorum.
Şirket içi etkinliğimizde yapılan konuşmalardan yola çıkılarak yazılan yazı dizisinin devamı :
2. Kod olarak altyapı. (Buradasınız)
3. C# modellerini kullanarak TypeScript sözleşmelerinin üretilmesi. (Devam etmekte...)
4. Raft konsensüs algoritmasına giriş. (Devam etmekte...)
...
Fikirleri uygulayan bir SRE ekibi oluşturmaya karar verdik . Kendi geliştiricileri arasından programcıları işe aldılar ve onları birkaç aylığına eğitime gönderdiler.
Ekibin aşağıdaki eğitim görevleri vardı:
- Çoğunlukla Microsoft Azure'da bulunan altyapımızı kod biçiminde (Terraform ve etrafındaki her şey) açıklayın.
- Geliştiricilere altyapıyla nasıl çalışacaklarını öğretin.
- Geliştiricileri göreve hazırlayın.
Altyapı kavramını kod olarak tanıtıyoruz
Dünyanın alışılagelmiş modelinde (klasik yönetim), altyapıya ilişkin bilgi iki yerde bulunur:
- Veya uzmanların kafasındaki bilgi şeklinde.
- Veya bu bilgiler, bazıları uzmanların bildiği bazı daktilolarda bulunmaktadır. Ancak dışarıdan birinin (tüm ekibimizin aniden ölmesi durumunda) neyin işe yaradığını ve nasıl çalıştığını anlayabileceği bir gerçek değil. Bir makine hakkında pek çok bilgi olabilir: aksesuarlar, cronjobs, korkutulmuş (bkz. ) disk ve olabileceklerin sonsuz bir listesi. Gerçekte ne olduğunu anlamak zordur.
Her iki durumda da kendimizi bağımlı olma tuzağına düşmüş halde buluruz:
- ya da ölümlü, hastalığa yatkın, aşık olan, ruh hali değişimleri ve basit işten çıkarmalara maruz kalan bir kişiden;
- ya da düşen, çalınan, sürprizler ve rahatsızlıklar sunan, fiziksel olarak çalışan bir makineden.
İdeal olarak her şeyin insan tarafından okunabilir, bakımı yapılabilir ve iyi yazılmış kodlara çevrilmesi gerektiğini söylemeye gerek yok.
Bu nedenle, kod olarak altyapı (Code olarak Incfastructure - IaC), kod biçimindeki mevcut tüm altyapının yanı sıra onunla çalışmak ve ondan gerçek altyapıyı uygulamak için ilgili araçların bir açıklamasıdır.
Neden her şeyi koda çevirelim?İnsanlar makine değildir. Her şeyi hatırlayamazlar. Bir kişinin ve bir makinenin tepkisi farklıdır. Otomatikleştirilmiş herhangi bir şey potansiyel olarak bir insan tarafından yapılan herhangi bir şeyden daha hızlıdır. En önemli şey gerçeğin tek kaynağıdır.
Yeni SRE mühendisleri nereden geliyor?Bu yüzden yeni SRE mühendislerini işe almaya karar verdik ama onları nereden bulacağız? Doğru cevaplarla rezervasyon yapın () bize şunları söylüyor: geliştiricilerden. Sonuçta kodla çalışırlar ve siz ideal duruma ulaşırsınız.
Şirketimiz dışındaki personel pazarında uzun süre onları çok aradık. Ancak isteklerimize uygun birini bulamadığımızı da itiraf etmeliyiz. Kendi halkım arasında araştırma yapmak zorunda kaldım.
Sorunlar Kod olarak altyapı
Şimdi altyapının koda nasıl kodlanabileceğine dair örneklere bakalım. Kod iyi yazılmış, yüksek kalitede, yorumlar ve girintilerle birlikte.
Terraforma'dan örnek kod.
Ansible'dan örnek kod.
Beyler, keşke bu kadar basit olsaydı! Gerçek dünyadayız ve o sizi şaşırtmaya, sürprizler ve sorunlar sunmaya her zaman hazır. Burada da onlarsız yapamam.
1. İlk sorun çoğu durumda IaC'nin bir tür dsl olmasıdır.
Ve DSL de yapının bir açıklamasıdır. Daha doğrusu, sahip olmanız gerekenler: Json, Yaml, bazı büyük şirketlerin kendi dsl'lerini (HCL terraform'da kullanılır) geliştiren modifikasyonları.
Sorun şu ki, aşağıdaki gibi tanıdık şeyleri kolaylıkla içermeyebilir:
- değişkenler;
- koşullar;
- herhangi bir yerde yorum yoktur, örneğin Json'da varsayılan olarak sağlanmazlar;
- fonksiyonlar;
- ve sınıflar, miras ve benzeri üst düzey şeylerden bahsetmiyorum bile.
2. Bu tür kodlarla ilgili ikinci sorun çoğunlukla heterojen bir ortam olmasıdır.. Genellikle oturup C# ile çalışırsınız; tek dil, tek yığın, tek ekosistem ile. Ve burada çok çeşitli teknolojiler var.
Python ile bash'ın Json'un eklendiği bir işlemi başlatması çok gerçek bir durumdur. Bunu analiz edersiniz, ardından başka bir oluşturucu 30 dosya daha üretir. Tüm bunlar için Go'da yazılmış drone.io eklentisi tarafından bir araya getirilen Azure Key Vault'tan giriş değişkenleri alınır ve bu değişkenler jsonnet şablon motorundan üretim sonucu oluşturulan yaml üzerinden geçer. Bu kadar çeşitli bir ortama sahip olduğunuzda, tam olarak iyi tanımlanmış bir koda sahip olmak oldukça zordur.
Geleneksel gelişim tek bir görev çerçevesinde tek dille birlikte gelir. Burada çok sayıda dille çalışıyoruz.
3. Üçüncü sorun ise ayarlamadır. Bizim için her şeyi yapan editörleri (Bayan Visual Studio, Jetbrains Rider) soğutmaya alışkınız. Aptal olsak bile yanıldığımızı söyleyecekler. Normal ve doğal görünüyor.
Ancak yakınlarda bir yerde, bir şekilde yüklenen, desteklenen veya desteklenmeyen bazı eklentilerin bulunduğu VSCode var. Yeni sürümler çıktı ve desteklenmiyordu. Bir işlevi uygulamaya yönelik banal bir geçiş (var olsa bile) karmaşık ve önemsiz olmayan bir sorun haline gelir. Bir değişkenin basit bir şekilde yeniden adlandırılması, bir düzine dosyanın projesinde tekrar oynatılmasıdır. İhtiyacınız olanı yerleştirirse şanslı olursunuz. Elbette, orada burada arkadan aydınlatma var, otomatik tamamlama var, bir yerde biçimlendirme var (her ne kadar Windows'ta terraformda benim için işe yaramadıysa da).
Bu yazının yazıldığı sırada 0.12 aydır yayınlanmasına rağmen henüz 3 sürümünü destekleyecek şekilde yayınlanmadı.
Artık unutmanın zamanı geldi...
- Hata ayıklama.
- Yeniden düzenleme aracı.
- Otomatik tamamlama.
- Derleme sırasında hataların tespiti.
Komik ama bu aynı zamanda geliştirme süresini de artırıyor ve kaçınılmaz olarak ortaya çıkan hataların sayısını da artırıyor.
En kötüsü, dosyaları nasıl tasarlayacağımızı, klasörler halinde düzenleyeceğimiz, ayrıştıracağımız, kodu bakımı yapılabilir, okunabilir hale getireceğimiz vb. hakkında değil, bu komutu nasıl doğru yazabileceğim hakkında düşünmek zorunda kalmamızdır, çünkü bir şekilde yanlış yazdım .
Yeni başlayan biri olarak dünya biçimlerini öğrenmeye çalışıyorsunuz ve IDE size hiç yardımcı olmuyor. Belgeler olduğunda içeri girin ve bakın. Ama yeni bir programlama diline giriyorsanız IDE size böyle bir türün olduğunu ancak böyle bir şeyin olmadığını söylerdi. En azından int veya string düzeyinde. Bu genellikle faydalıdır.
Peki ya testler?
Siz soruyorsunuz: "Peki ya testler beyler programcılar?" Ciddi adamlar üretimdeki her şeyi test eder ve bu zordur. Web sitesinden bir terraform modülü için birim testine bir örnek: .
İyi belgelere sahipler. Microsoft'u dokümantasyon ve eğitim konusundaki yaklaşımı nedeniyle her zaman sevdim. Ancak bunun mükemmel bir kod olmadığını anlamak için Bob Amca olmanıza gerek yok. Sağdaki doğrulamaya dikkat edin.
Birim testiyle ilgili sorun, sizin ve benim Json çıktısının doğruluğunu kontrol edebilmemizdir. 5 parametre girdim ve bana 2000 satırlık bir Json ayak örtüsü verildi. Burada neler olup bittiğini analiz edebilirim, test sonucunu doğrulayabilirim...
Json'u Go'da ayrıştırmak zordur. Ve Go'da yazmanız gerekiyor çünkü Go'daki terraform, yazdığınız dilde test yapmak için iyi bir uygulamadır. Kodun organizasyonu çok zayıf. Aynı zamanda test için en iyi kütüphanedir.
Microsoft, modüllerini kendisi yazıyor ve bu şekilde test ediyor. Tabii ki Açık Kaynak. Bahsettiğim her şeyi gelip düzeltebilirsin. Oturup bir hafta içinde her şeyi düzeltebilirim, açık kaynaklı VS kodu eklentileri, terraformlar, sürücü için bir eklenti yapabilirim. Belki birkaç analizör yazabilir, linter ekleyebilir, test için bir kütüphaneye katkıda bulunabiliriz. Her şeyi yapabilirim. Ama yapmam gereken bu değil.
En iyi uygulamalar Kod olarak altyapı
Hadi devam edelim. IaC'de test yoksa, IDE ve ayarlama kötüyse, o zaman en azından en iyi uygulamalar olmalıdır. Az önce Google Analytics'e gittim ve iki arama sorgusunu karşılaştırdım: Terraform'un en iyi uygulamaları ve C#'ın en iyi uygulamaları.
Ne görüyoruz? Acımasız istatistikler lehimize değil. Malzeme miktarı aynıdır. C# geliştirmede, materyallerle doluyuz, en iyi uygulamalara sahibiz, uzmanlar tarafından yazılan kitaplar var ve ayrıca bu kitapları eleştiren diğer uzmanlar tarafından kitaplar üzerine yazılan kitaplar var. Çok sayıda resmi belge, makale, eğitim kursu ve şimdi de açık kaynak geliştirme.
IaC talebine gelince: burada yüksek yükten veya HashiConf raporlarından, resmi belgelerden ve Github'daki sayısız sorundan parça parça bilgi toplamaya çalışıyorsunuz. Bu modüller genel olarak nasıl dağıtılır, onlarla ne yapılır? Görünüşe göre bu gerçek bir sorun... Bir topluluk var beyler, burada herhangi bir soru için Github'da 10 yorum alacaksınız. Ama tam olarak öyle değil.
Maalesef bu noktada uzmanlar ortaya çıkmaya başlıyor. Şu ana kadar bunlardan çok az sayıda var. Ve topluluğun kendisi de ilkel düzeyde takılıyor.
Bütün bunlar nereye gidiyor ve ne yapmalı?
Her şeyi bırakıp C#'a, sürücünün dünyasına geri dönebilirsiniz. Ama hayır. Eğer bir çözüm bulamıyorsanız neden bunu yapmaya zahmet edesiniz ki? Aşağıda subjektif sonuçlarımı sunuyorum. Yorumlarda benimle tartışabilirsiniz, ilginç olacak.
Şahsen ben birkaç şeye bahse giriyorum:
- Bu alandaki gelişmeler çok hızlı gerçekleşiyor. DevOps isteklerinin bir çizelgesini burada bulabilirsiniz.
Konu abartılı olabilir ancak alanın büyüdüğü gerçeği biraz umut veriyor.Bir şey bu kadar hızlı büyürse, o zaman size ne yapacağınızı ve ne yapmamanız gerektiğini söyleyecek akıllı insanlar kesinlikle ortaya çıkacaktır. Popülaritenin artması, belki birisinin nihayet vscode için jsonnet'e bir eklenti eklemek için zamanı olabileceği gerçeğine yol açar; bu, ctrl+shift+f ile aramak yerine işlevi uygulamaya devam etmenize olanak tanır. İşler geliştikçe daha fazla malzeme ortaya çıkıyor. Google'ın SRE ile ilgili bir kitabın yayınlanması bunun mükemmel bir örneğidir.
- Geleneksel geliştirmede burada başarıyla uygulayabileceğimiz gelişmiş teknikler ve uygulamalar var. Evet, test etme ve heterojen bir ortam, yetersiz araç kullanımı ile ilgili nüanslar var, ancak faydalı ve yardımcı olabilecek çok sayıda uygulama birikmiştir.
Önemsiz bir örnek: eşli programlama yoluyla işbirliği. Bunu anlamak çok yardımcı olur. Yakınınızda bir şeyi anlamaya çalışan bir komşunuz olduğunda birlikte daha iyi anlayacaksınız.
Yeniden düzenlemenin nasıl yapıldığını anlamak, böyle bir durumda bile bunu gerçekleştirmeye yardımcı olur. Yani her şeyi bir anda değiştiremezsiniz ama adını değiştirin, sonra konumu değiştirin, sonra bir kısmı vurgulayabilirsiniz, ah, ama burada yeterli yorum yok.
Sonuç
Mantığım karamsar görünse de geleceğe umutla bakıyorum ve bizim (ve sizin için) her şeyin yoluna gireceğini içtenlikle umuyorum.
Makalenin ikinci kısmı bundan sonra hazırlanıyor. Burada öğrenme sürecimizi geliştirmek ve altyapıyla çalışmak için çevik geliştirme uygulamalarını nasıl kullanmaya çalıştığımızdan bahsedeceğim.
Kaynak: habr.com