pyinfra — Ajan gerektirmeyen altyapı otomasyonu, saf Python ile

• Sunucu otomasyon işleri Python kodu ile yazılır ve SSH üzerinden paralel çalıştırılarak, ajan olmadan komutlar idempotent şekilde yürütülür
• pyinfra, aynı iş yükünde Ansible'dan 6 kat daha hızlı olduğunu öne çıkarır ve gevent ile SSH tabanlı eşzamanlı yürütme kullanır
• --dry seçeneğiyle uygulama öncesinde ana makine bazında değişiklik diff'leri görülebilir; gerçek çalıştırmada sonuçlar paralel akış halinde gelir
• Hedef ana makinelerde yalnızca shell ve SSH gerekir; daemon, durum dosyası veya control plane yoktur
• Denetim akışını YAML'e kodlamak yerine Python'un döngü ve koşullarını doğrudan kullanan kod merkezli yapılandırma vurgulanır

---

Temel özellikler ve çalışma akışı

• Binlerce sunucunun otomasyonu

  • pyinfra, Python-native, agentless bir otomasyon aracıdır ve komutları SSH ile çalıştırır
  • Komut yürütme; eşzamanlılık, idempotency ve hızı öne çıkarır; aynı iş yükünde Ansible'dan 6 kat daha hızlı olduğunu savunur
  • Kurulum komutu $ uv tool install pyinfra şeklindedir
  • Belirtilen temel özellikler MIT license, Python 3.10+, no agents ve zero config'tir

• Dağıtım kodu örneği

  • apt, files, systemd işlemleri Python kodu içinde çağrılarak paket kurulumu, şablon yerleştirme ve servis yeniden yükleme yapılır
  • Örnek kod nginx ve certbot paketlerini kurar ve templates/nginx.conf.j2 dosyasını /etc/nginx/sites-enabled/api konumuna yerleştirir
  • Son adımda systemd.service("nginx", reloaded=True) ile nginx servisi yeniden yüklenir

  from pyinfra.operations import apt, files, systemd
  
  apt.packages(
      packages=["nginx", "certbot"],
      update=True,
  )
  
  files.template(
      src="templates/nginx.conf.j2",
      dest="/etc/nginx/sites-enabled/api",
  )
  
  systemd.service("nginx", reloaded=True)
  

• Envanter ve çalıştırma sonuçları

  • Envanter örneği, web-01.prod ile web-23.prod arasındaki web ana makineleri ile db-01.prod, db-02.prod veritabanı ana makinelerini içerir
  • $ pyinfra inventory.py deploy.py --limit web komutu, çalıştırmayı yalnızca web hedefleriyle sınırlar
  • Çıktı; envanter yükleme, eşzamanlı fact toplama, deploy.py çalıştırma ve özet sırasıyla ilerler
  • Örnek özet, 23 ana makinede başarı, 18 değişiklik, 0 hata ve toplam 2.1 saniye gösterir

• Değişiklikleri önceden doğrulama

  • --dry, pyinfra'nın yapacağı tüm işlemlerin ana makine bazında diff çıktısını önce göstermesini sağlar
  • Gerçek çalıştırmada sonuçlar paralel olarak akıtılır ve her ana makine için değişiklik sayısı ile çalışma süresi gösterilir
  • Örnek çalıştırma, 24 ana makineden 18'inde değişiklik, 6'sında değişiklik yok, 0 hata ve toplam 2.1 saniye gösterir

Özellikler, Ansible karşılaştırması ve ilkeler

• pyinfra'yı seçmek için altı neden

  • Just Python: YAML ve Jinja-in-YAML yerine gerçek denetim akışı Python ile yazılır
  • Concurrent SSH: gevent ve SSH tabanlı eşzamanlı yürütme kullanır, aynı iş yükünde Ansible'dan 6 kat daha hızlıdır
  • Diff before apply: --dry ile tüm değişiklikler önceden görülür, idempotent işlemler yeniden çalıştırıldığında no-op olur
  • 0 agents: Ana makinelerde yalnızca shell ve SSH gerekir; daemon, durum dosyası veya control plane yoktur
  • Scale-ready: 1 ana makineden 10.000 ana makineye kadar çalışır; paralel yürütme ve gerçek zamanlı akış çıktısını destekler
  • Hackable: 10 satırda özel işlem oluşturulabilir; shell ile iletişim kuran docker, lxc, k8s ortamlarına bağlanabilir

• Ansible ve pyinfra kod karşılaştırması

  • Ansible örneği, playbook.yml içinde 16 satırla nginx kurulumu, şablon render etme ve handler tabanlı servis yeniden yüklemeyi yapılandırır
  • pyinfra örneği, deploy.py içinde 8 satırla aynı akışı Python kodu olarak yazar
  • pyinfra örneğinde files.template sonucundaki cfg.will_change doğru olduğunda systemd.service("nginx", reloaded=True) çalıştırılır

  from pyinfra.operations import apt, files, systemd
  
  apt.packages(["nginx"], update=True)
  
  cfg = files.template(
      src="nginx.conf.j2",
      dest="/etc/nginx/sites-enabled/api",
  )
  if cfg.will_change:
      systemd.service("nginx", reloaded=True)
  

• Bildiri

  • Code > config: Döngüler döngü olarak kalır; denetim akışı YAML'e kodlanmaz
  • Show, then do: Önce diff görülür, sonra uygulanır; böylece beklenmeyen değişikliklerden kaçınılır
  • Stay out of the way: Ajan, durum dosyası veya control plane olmadan doğrudan SSH ile çalışır
  • Read like english: İşlemler apt.packages, files.template, systemd.service gibi isim-fiil biçiminde okunur

• Başlangıç komutu

  • Kurulum komutu $ uv tool install pyinfra şeklindedir
  • 5 dakikalık quickstart'ı okuyup ilk ana makineyi dağıtmanız için yönlendirme sunulur

[GN⁺]

Lobste.rs yorumları

• pyinfra, sanki Ansible baştan böyle olmalıymış hissi veriyor. Şablonlarla karışmış YAML üzerine kontrol akışı eklemek yerine, otomasyonu doğrudan Python ile yazabiliyorsunuz
  Ansible’la uzun süre çalıştıktan sonra bu bana taze geldi; üstelik Ansible’dan özellikle nefret eden biri de değildim

  • Tam olarak Python’la yazılmış bir Ansible’dan çok, Python’dan shell’e çeviri yapan bir yorumlayıcıya daha yakın görünüyor ve bunun da kendine özgü sorunları var
    Hedef sunucuda da Python kullanan hibrit bir yaklaşım daha iyi olabilir. Dosya güncellerken tırnak cehennemi azalır ve sed’in regex sınırlamaları gibi şeylerden de kaçınılır

• pyinfra’yı seviyorum ve daha yaygın kullanılmasını isterdim
  Şimdiye kadar çalıştığım tüm şirketler, Terraform kullanılsın ya da kullanılmasın, Ansible kullandı; çalışanların deneyimi olmayan bir araçla mevcut otomasyonun tamamını baştan yazmaya hazır olduğu bir yere hiç rastlamadım
  pyinfra, SysOps’un Python bilmesini gerektiriyor; bence SysOps en azından bir betik dilini bilmeli. Özellikle Ansible’da da modülleri Python’la yazarak YAML karmaşasını azaltabilirsiniz ama en azından Fransa’da bu pek yaygın bir düşünce değil gibi görünüyor

  • Ansible’ı çok kullandım ve bence o da özünde betik dili kılığına girmiş bir şey
    Bu o kadar da hararetli bir tartışma konusu olmayabilir

• Homelab’imde Ansible kullanıyordum ama zamanla iyice bunaltıcı gelmeye başladı. YAML yapılandırması korkunçtu, her şey hack gibi hissettiriyordu ve performansı da üzücüydü. Sırf birkaç shell komutu çalıştırmak için sunucuda python3 gerekmesi de bana mantıklı gelmiyordu
  Google AI Mode sayesinde pyinfrayı öğrendim ve yaklaşık bir aydır kullandığım kadarıyla çok daha ferah hissettirdi. Artıları: Ansible’dan çok daha hızlı, döngüleri ve koşulları Python’la yazabiliyorsunuz, rol ve iç içe dizinler gerektirmiyor ve sunucuda sadece shell olması yetiyor. Çalıştırmadan önce mevcut duruma göre bir plan oluşturuyor ve -y verilmezse onay da istiyor
  Eksileri ise, hazır görevlerin Ansible modüllerine kıyasla çok daha küçük bir alt küme olması, kodun hızlıca spagettiye dönüşebilmesi ve if 'web_server' in hosts.groups gibi kullanımın da pek hoş olmaması. operation(..., filter_group='web_server') daha mı iyi olur, emin değilim
  En kötü yanı ise özel connector yazmanın aşırı can sıkıcı olması. İçinde pyinfraya özel entry point bulunan bir pyproject.toml gerekli gibi görünüyor ve uv kullansanız bile şirket içi connector geliştirmek kâbus gibi. Bunun proje içindeki sıradan bir Python dosyası olarak yapılabilmesi gerekirdi

• Birkaç gündür pyinfra’yı homelab dağıtım aracım için deniyorum; Ansible’la kıyaslayınca şu ana kadar en sevdiğim şey Python söz diziminden çok hızı oldu
  Ansible bana hep dayanılmaz derecede yavaş gelmiştir

  • Bu alan ilginç. Ben de bir dağıtım aracı geliştiriyorum ve ana işimde bunu gerçek dağıtımlarda kullanıyorum
    Çoğu yerde Ansible ve Salt kullanımının yerini almasını istiyorum

• Kod olarak altyapı yaklaşımının tam tur atmış olması komik. Betiklerden YAML’a gittik, sonra tekrar daha sofistike betiklere döndük
  Her yaklaşımın uygun olduğu bir nokta var ve bir Ansible kullanıcısının gözünden pyinfra oldukça iyi görünüyor

  • Sürekli configuration complexity clock etrafında dönüp duruyoruz

• Ansible’ı benimsememizin asıl nedeni dry-run ve diff modu olmuştu. Beklenmedik işler yapmayacağından emin olabiliyorduk
  Ama pyinfra CLI’da böyle bir seçenek yok gibi görünüyor. Tüm seçenekleri alfabetik olarak sıralayan bir referans dokümanı bulamadığım için gözden kaçırmış da olabilirim

  • —dry bayrağı var ve pyinfra’nın ilk ekranında hemen görünüyor

• İlgilenenler için, buna benzer 14 yıllık bir projem de var: https://github.com/sebastien/cuisine/tree/main
  Agentsız, yalnızca SSH kullanıyor ve temel yönetim işlevlerinin üzerine Pythonvari bir API koyuyor ama dry mode desteklemiyor

• Biz OpenStack’te kaynak sağlama için Ansible kullanıyoruz, geri kalan her şeyi ise pyinfra ile yapıyoruz ve son birkaç yıldır gayet iyi çalışıyor
  En büyük dezavantajı, topluluğun küçük olması nedeniyle çözümleri çoğu zaman kendiniz yazmak zorunda kalmanız. Örneğin dağıtım için gereken paylaşılan sırları keyring + privy ile diskte saklıyoruz ve OpenStack compute envanterini hosts verisine dönüştüren birkaç satır kodu da kendimiz yazdık