Ansible AWX: Kurulum Yaklaşımı ve Merkezi Otomasyon Akışı

AWX ne ekler ve ne zaman gerekir?

Ansible'ı komut satırından kullanmak, birkaç kişilik bir ekip için yeterlidir. Ekip büyüyüp otomasyonu birden çok kişi, ekip ve ortam çalıştırmaya başladığında yeni sorular çıkar: Kim hangi playbook'u hangi sunucuda çalıştırabilir? Parolalar ve SSH anahtarları kimin laptopunda duruyor? Dün gece çalışan işin çıktısı nerede? Zamanlanmış bakımları kim tetikliyor?

AWX, bu sorulara web arayüzü, REST API'si, rol tabanlı erişim ve iş geçmişiyle yanıt verir. Proje tanımına göre AWX, karmaşık çok katmanlı dağıtımları yöneten ekiplere kontrol, bilgi ve yetki devri ekler. Playbook'ların kendisi değişmez; AWX onları merkezi bir yerden, yetkilendirilmiş ve kayıt altına alınmış biçimde çalıştırır. Ansible Tower ve Ansible Automation Platform adları da aynı kullanım alanındaki ticari ürünlere işaret eder.

Kurulum yaklaşımı: AWX Operator

Proje belgelerine göre AWX'i kurmanın tercih edilen yolu AWX Operator'dür; Operator, Kubernetes üzerinde AWX'in kurulumunu ve yaşam döngüsünü yöneten bir bileşendir. Docker ile çalıştırma yöntemi yalnızca geliştirme ve test amaçlıdır ve resmî olarak yayımlanmış bir sürümü yoktur. Eski sürümler farklı kurulum adımları kullandığı için sürümünüzün belgesine bakmak gerekir.

Kurulum akışı genel hatlarıyla şöyledir: • Bir Kubernetes kümesi hazırlanır (yönetilen bir küme ya da test için küçük bir yerel küme) • AWX Operator kümeye kurulur • Bir AWX özel kaynağı (custom resource) tanımlanır; sürüm, kalıcı depolama ve servis erişimi burada belirlenir • Operator, gerekli bileşenleri oluşturur ve yönetici parolasını bir gizli nesne olarak üretir • Web arayüzüne servis ya da giriş (ingress) üzerinden erişilir

Komut ve manifest ayrıntıları sürümle değiştiği için kurulumu AWX Operator belgesindeki güncel yönergelerle yapın. Üretimde kalıcı veritabanı depolamasını ve yedeklemeyi baştan düşünün.

İlk iş akışı: proje, envanter, kimlik bilgisi, şablon

AWX'te bir playbook'u çalıştırmak için şu parçalar tanımlanır: • Proje: playbook'ların bulunduğu sürüm kontrol deposu; AWX kodu buradan çeker • Envanter: hedef makineler; statik olabilir ya da bulut sağlayıcısından dinamik gelebilir • Kimlik bilgisi (credential): makineye bağlanmak için SSH anahtarı ya da parola, bulut API anahtarı gibi gizli bilgiler; kaydedildikten sonra düz metin olarak gösterilmez • İş şablonu (job template): hangi projedeki hangi playbook'un, hangi envanterde, hangi kimlik bilgisiyle çalışacağını birleştiren tanım

İş şablonunu başlattığınızda AWX işi bir çalışma ortamında yürütür, çıktıyı canlı gösterir ve geçmişe kaydeder. Şablona anket (survey) ekleyerek kullanıcıdan çalıştırma anında değişken değer almak da mümkündür; örneğin hedef ortam adı ya da sürüm etiketi.

Yetki, zamanlama ve iş akışları

Rol tabanlı erişim denetimi AWX'in başlıca kazanımıdır. Bir ekibe yalnızca belirli bir envanter ve belirli iş şablonları için çalıştırma yetkisi verirsiniz; geliştirici ekibi test ortamı bakımını başlatabilir ama üretim şablonlarını göremez. Kimlik bilgilerini kullanma izni ayrı verildiği için kullanıcı, parolayı hiç görmeden o parolayla iş çalıştırabilir.

Zamanlayıcılar iş şablonlarını belirli aralıklarla çalıştırır; yama ve uyumluluk kontrolleri için sık kullanılır. İş akışı (workflow) şablonları birden çok şablonu ve onay adımlarını sıralar: önce test ortamı, başarılıysa onay, ardından üretim gibi. Bildirimler, işin sonucunu e-posta ya da mesajlaşma araçlarına iletir. Bunlar, tek tek betikler yerine otomasyonu bir süreç olarak işletmek için gereken parçalardır.

Denetim tarafında iş geçmişi önemli bir kazanımdır: her çalıştırmanın kim tarafından, hangi şablonla, hangi envanterde ve hangi çıktıyla yürütüldüğü kayıtlıdır. Bir sunucuda beklenmedik bir değişiklik görüldüğünde, ilgili zamandaki işi bulup tam olarak ne çalıştığına bakmak mümkündür. Bu kayıt, değişiklik yönetimi ve uyumluluk denetimlerinde "kim, ne zaman, neyi değiştirdi" sorusuna belgeli bir yanıt verir. Elle çalıştırılan komut satırı oturumlarında bu bilgi çoğunlukla kişilerin kabuk geçmişinde dağınık kalır.

Sık hatalar ve işletme notları

• Kümeyi kalıcı depolama düşünmeden kurmak; yeniden başlatmada veri kaybı
• Yönetici parolasını ilk girişten sonra kimsenin teslim almaması
• Her şeyi yönetici hesabıyla çalıştırmak; yetki modelini hiç kullanmamak
• Playbook'ları AWX içinde değil de elle düzenlemek; projeyi mutlaka sürüm kontrolüne bağlayın
• Yeni sürüme geçişte yedek almamak
• Kimlik bilgilerini iş şablonu değişkenlerine düz metin yazmak

AWX bir yükseltme politikası gerektirir: yeni sürümlerin sürüm notlarını okuyun, önce test örneğinde deneyin, veritabanı yedeği alın. Ticari Automation Platform ise bu sorumlulukların bir kısmını destek ve sürüm yönetimiyle birlikte sunar; seçim, ekibin işletme kapasitesine ve destek beklentisine bağlıdır.

Geçiş planı yaparken mevcut playbook'larınızı AWX'e taşımadan önce şunları netleştirin: gizli bilgiler şu an nerede duruyor ve hangi kimlik bilgisi türüne dönüşecek, envanter statik mi dinamik mi kalacak, hangi çalıştırmalar elle, hangileri zamanlanmış ya da bir teslimat hattından tetiklenecek. AWX'in REST API'si, bir CI/CD hattının iş şablonunu çağırıp sonucunu beklemesine de izin verir; böylece değişiklik onaylandığında dağıtım merkezi ve kayıtlı bir yoldan yürür. Küçük bir ekiple tek bir iş şablonuyla başlayıp yetki modelini oturttuktan sonra diğer playbook'ları taşımak, hepsini bir anda taşımaktan daha güvenlidir.

Bu beceriyi Mindset programında nerede çalışırsınız

Ansible ile Konfigürasyon Yönetimi eğitiminde AWX ve Ansible Automation Platform ayrı bir modüldür; CI/CD ve GitOps ile Ansible modülü ise playbook'ların bir teslimat hattından tetiklenmesini işler. Ansible Automation Platform (AWX) ile Kurumsal Otomasyon eğitimi de kurumsal ölçekte merkezi otomasyon kurmak isteyen ekipler için ayrı bir seçenektir.

Bu yol, otomasyonu bireysel bir betik alışkanlığından ekip düzeyinde denetlenen bir hizmete taşımak isteyen operasyon, platform ve DevOps ekipleri içindir.