GitOps ile iki cluster’lı Ansible Automation Platform mimarisi

Red Hat, Ansible Automation Platform’u iki ayrı cluster üzerinde federated olarak çalıştırıp GitHub Actions ile yöneten bir referans mimari ve proof-of-concept repository yayımladı. Main branch’e yapılan push platform yapılandırmasını iki gateway’e birden uyguluyor, deploy branch’i ise iş yüklerini hedef değişkene göre ya da round-robin ile cluster’lara dağıtıyor. Mimari, değişiklik onayı için ServiceNow ve merkezi log için Splunk ile bütünleşiyor.

Ansible Automation Platform nedir, ne işe yarar?

Ansible Automation Platform, Red Hat’in Ansible üzerine kurduğu kurumsal otomasyon platformudur. Playbook’ları merkezi bir controller üzerinden çalıştırmak, job zamanlamak, yetkilendirme ve kimlik bilgilerini yönetmek, execution environment adı verilen container image’larıyla tutarlı çalışma ortamı kurmak için kullanılır. Büyük kurumların altyapı ve ağ ekipleri tercih eder. Açık kaynak upstream karşılığı AWX projesidir.

Tek controller neden yetmiyor?

Ansible Automation Platform CI/CD pipeline’larınızın ve otomatik düzeltme işlerinizin ortasında duruyorsa controller kesintisi bütün zinciri durdurur. Bu yazıdaki fikir basit: platformu iki bağımsız cluster’a bölmek ve ikisini de aynı Git repository’den beslemek. Cluster’lardan biri bakımdayken ya da çöktüğünde işler diğerine kayıyor.

Yaklaşımın özü şöyle:

• Main branch’e push, playbooks/configure_aap.yml playbook’unu tetikliyor ve ansible.controller modülleriyle iki gateway’i (AAP-Platform-DC1 ve AAP-Platform-DC2) aynı duruma getiriyor.
• SSH anahtarları Ansible Vault ile şifreli secret olarak tutuluyor.
• Inventory grupları dc1, dc2, production ve non-production ayrımıyla kuruluyor; template’lerde ask_limit_on_launch: true açık.
• Deploy branch’inde dispatch_round_robin.yml, deploy_job.yml içindeki target_aap değerine göre cluster seçiyor; auto değeri işleri GitHub index’ine göre sırayla dağıtıyor.

Ansible Automation Platform’u ikiye bölmenin bedeli

İki cluster, iki ayrı yönetim yüzeyi demek. Yapılandırma Git’ten geliyor ama job geçmişi, çalışma anındaki durum ve elle yapılan değişiklikler her cluster’da ayrı kalır. Arayüzden tek bir template’i elle düzeltirseniz o cluster Git’ten sapar. Bu yüzden UI üzerinden değişikliği kapatmak ya da yalnızca okuma yetkisine indirmek bu modelin ön koşulu sayılmalı.

Merkezi log tarafı da süs değil. Bir job’un hangi cluster’da koştuğunu bulmak için Splunk ya da benzeri bir yerde iki cluster’ın olaylarını tek ekranda görmeniz gerekir. Aksi halde arıza anında iki arayüz arasında gidip gelirsiniz.

Round-robin dağıtımın sınırı

auto modunda dağıtım GitHub index’ine dayanan basit bir sıra. Kaynakta cluster sağlığını kontrol eden bir adımdan söz edilmiyor. Yani dc1 yanıt vermiyorsa işlerin bir kısmı yine oraya gidebilir. Kaynak da üretim için F5 gibi ayrı bir load balancer (yük dengeleyici) önerdiğini belirtiyor. Lab dışına çıkarken ya health check yapan bir load balancer koyun ya da dispatch playbook’una gateway erişim kontrolü ekleyin.

Planlı bakımda yol daha net. dc1 node’larında işletim sistemi yükseltmesi yapacaksanız önce target_aap değerini dc2’ye çekin, dc1’deki çalışan job’ların bitmesini bekleyin, sonra bakımı başlatın. Bakım bitince değeri auto‘ya döndürmek de bir commit, yani denetim izi kendiliğinden oluşuyor.

Execution environment image’ına dikkat

Örnek workflow quay.io/jopaik/aap-runner:jp1 image’ı içinde çalışıyor. Bu, kişisel bir namespace ve sabit olmayan bir tag. PoC için sorun değil ama üretimde tedarik zinciri riski taşır. Image’ı inceleyip kendi registry’nizde yeniden build edin ve digest ile sabitleyin:

podman pull quay.io/jopaik/aap-runner:jp1
podman image inspect quay.io/jopaik/aap-runner:jp1 --format '{{.Digest}}'

GitHub Actions runner’ının iki gateway’e de ağ erişimi olmalı. Vault parolası ve gateway kimlik bilgileri repository secret’larında duracağı için deploy branch’ine kimin push edebileceğini branch koruma kurallarıyla daraltın.

Sürüm geçişinde nereden başlanır?

Mimari, iki cluster’da farklı Ansible Automation Platform sürümlerini yan yana çalıştırıp iş yüklerini aşamalı taşımayı da hedefliyor. Burada aynı configure_aap.yml iki farklı sürüme karşı koşacak. Kullandığınız ansible.controller collection sürümünün iki platform sürümüyle de uyumlu olduğunu önce non-production inventory’de doğrulayın. Taşımayı target_aap ile ortam ortam yapın: önce non-production, sonra dc bazında production.

ServiceNow bağlantısı onaylı change request’ten pipeline tetiklemek için anlamlı. Ama change onayına bağlı bir deploy branch’i acil düzeltmeleri yavaşlatır; acil durum için ayrı ve kayıtlı bir yol tanımlayın.