RED HAT ANSIBLE AUTOMATION PLATFORM 2.7

Red Hat Ansible Automation Platform 2.7

Red Hat Ansible Automation Platform 2.7’yi doğru değerlendirebilmek için öncelikle platformun yalnızca bir otomasyon aracı olarak değil, kurum genelinde otomasyonu merkezi, güvenli, izlenebilir ve tekrar kullanılabilir hale getiren bütünleşik bir çözüm olarak ele alınması gerekir. Çünkü AAP; playbook çalıştırmanın ötesinde, otomasyon içeriklerinin yönetilmesi, yetkilendirme, standart çalışma ortamlarının oluşturulması, event bazlı aksiyonların alınması, self-service kullanımın sağlanması ve yapay zekâ destekli otomasyon geliştirme gibi birçok bileşeni bir araya getirir. Bu nedenle 2.7 sürümüyle gelen yenilikleri sağlıklı anlayabilmek için önce platformun temel mimarisini, her bileşenin ne işe yaradığını ve gerçek hayatta hangi ihtiyaca karşılık geldiğini netleştirmek önemlidir.

Red Hat Ansible Automation Platform’u bir kurumsal otomasyon fabrikası gibi düşünebiliriz.

Bir kurumda yüzlerce iş olabilir: Sunucu patch’leme, kullanıcı açma, firewall kuralı ekleme, OpenShift namespace oluşturma, VM provision etme, backup kontrolü, log alarmına otomatik aksiyon alma, sertifika yenileme, servis restart etme, network cihaz konfigürasyonu değiştirme gibi.

AAP’nin amacı bu işleri kişilerin kendi bilgisayarından, kontrolsüz script’lerle yapması yerine; merkezi, yetkili, izlenebilir, tekrar kullanılabilir ve güvenli hale getirmektir.

Yani basitçe şunları yapar: Bir işi kim çalıştırabilir, hangi sistemlerde çalıştırabilir, hangi kodu kullanır, hangi credential ile gider, nerede çalışır, çıktısı ne oldu, hata olduysa kim görecek?
Bunların tamamını AAP yönetir.

Somut bir örnek: Windows Server patch otomasyonu

Diyelim ki müşterinin 500 adet Windows Server’ı var. Her ay patch uygulanıyor. Manuel süreçte şu problemler olur: Patch listesi elle hazırlanır. Hangi sunuculara işlem yapılacağı Excel’den takip edilir. Admin kişi RDP ile tek tek bağlanır. Hata olursa loglar dağınıktır. İşlem sonunda yönetime rapor üretmek zordur. Aynı iş her ay tekrarlandığı halde standart değildir.

AAP ile bu iş şöyle tasarlanır:

Bu örneği akılda tutarsak şimdi anlatacağımız bileşenler çok daha anlaşılır olur.
Temel bileşenler
Platform Gateway: “Ana kapı / merkezi giriş noktası”
Ne işe yarar?
Platform Gateway’i AAP’nin ana kapısı gibi düşünebiliriz. Kullanıcı, API çağrısı, entegrasyon veya UI erişimi platforma geldiğinde artık doğrudan her bileşenin kendi kapısından girmek yerine daha merkezi bir giriş modeli kullanılır. Automation execution, Automation content ve Automation decisions bileşenleri platform gateway tarafından birleştiriliyor. Platform gateway aynı zamanda organizasyon, kullanıcı ve service cluster gibi kaynaklarda yapılan değişiklikleri “activity stream” ile izler.
Somut bir örnek: Eski yaklaşımda bir entegrasyon doğrudan automation controller API’sine, başka bir entegrasyon automation hub API’sine, başka biri EDA API’sine gidiyor olabilir. Bu da güvenlik ve yönetim açısından dağınıklık yaratır. AAP 2.7’de mantık şuna yaklaşıyor: Herkes ana kapıdan girsin, kimlik doğrulama ve erişim daha merkezi yönetilsin.
AAP 2.7’de neden kritik?
AAP 2.7 release notes’a göre automation controller, Automation Hub ve EDA tarafında basic authentication ve personal access token kullanımı devre dışı bırakılıyor; ayrıca eski direct API/script kullanımını tespit etmek için aap-detect-direct-component-access aracı geliyor. Yani, 2.7 ile Red Hat, platformu daha birleşik, daha kontrollü ve güvenli bir erişim modeline taşıyor. Bu nedenle eski doğrudan API entegrasyonları upgrade öncesinde mutlaka analiz edilmeli.
Automation Execution / Automation Controller: “İşi çalıştıran merkez”
Ne işe yarar?
Automation Execution, otomasyonların çalıştırıldığı ana merkezdir. Red Hat, bu bileşeni playbook çalıştırma, job activity izleme, merkezi loglama ve job template oluşturma alanı olarak tanımlar.
Somut bir örnek: “Windows patch uygula” diye bir işimiz olsun.
Automation Controller içinde şunlar olur:

Yani controller, “ne çalışacak, nerede çalışacak, kim çalıştırabilir, hangi credential kullanılacak, sonuç ne oldu?” sorularını yönetir. Automation Controller bir operasyon müdürü gibidir. İş emrini alır, doğru kişiye/veriye/ortama yönlendirir, sonucu kaydeder.
Inventory: “Hangi sistemlere işlem yapılacak?”
Ne işe yarar?
Inventory, otomasyonun hedef sistemlerini tutar. Red Hat inventory’yi; host ve grupların yer aldığı, Ansible komutları ve playbook’larla işlem yapılacak sistemleri tanımlayan INI veya YAML formatında dosya olarak açıklar.
Somut bir örnek:

windows:
hosts:
win-app-01:
win-app-02:
win-db-01:
linux:
hosts:
rhel-app-01:
rhel-db-01:

Burada patch playbook’u sadece windows grubuna çalıştırılabilir. Başka bir playbook sadece linux grubuna çalışabilir. Yani, Inventory, otomasyonun adres defteridir. Hangi sistemlere dokunulacağını merkezi olarak belirler.
Playbook: “Yapılacak işin tarifi”
Ne işe yarar?
Playbook, yapılacak işin YAML formatındaki tarifidir. Red Hat playbook’ları hedef sistemlerde çalıştırılan, tekrar kullanılabilir, insan tarafından okunabilir talimat setleri olarak tanımlar.
Somut bir örnek:
Bir Linux sunucuda Apache kurmak için playbook şöyle olabilir:

– name: Apache kurulumu
hosts: webservers
tasks:
– name: httpd paketini kur
ansible.builtin.dnf:
name: httpd
state: present
– name: httpd servisini başlat
ansible.builtin.service:
name: httpd
state: started
enabled: true

Bu playbook manuel yapılan şu işi standartlaştırır: SSH ile bağlan. Paket kur. Servisi başlat. Boot sonrası otomatik başlasın. Sonucu kaydet. Playbook bir yemek tarifi gibidir. Malzemeler, sıralama ve yapılacak adımlar bellidir.
Job Template: “Playbook’un kontrollü çalıştırılabilir hale gelmiş formu”
Ne işe yarar?
Playbook tek başına bir YAML dosyasıdır. Job Template ise bu playbook’un AAP içinde çalıştırılabilir, yetkilendirilebilir, schedule edilebilir, parametre alabilir hale gelmiş versiyonudur.
Somut bir örnek:
patch_windows.yml playbook’unu herkes çalıştırmamalı. Sadece Windows operasyon ekibi çalıştırmalı. Ayrıca kullanıcı çalıştırırken hangi ortamı seçeceğini belirtmeli: Prod, Test, DR, Sadece Belirli Uygulama Grubu
Bunun için Job Template kullanılır.
Örnek job template:

Job Template, playbook’u kurumsal servis haline getirir.
Automation Content / Automation Hub: “Otomasyon kütüphanesi”
Ne işe yarar?
Automation Hub, AAP içeriğinin merkezi lokasyonudur. Burada content collection’lar bulunur, indirilebilir, entegre edilebilir ve kurum kendi içeriğini de upload ederek kullanıcılarına dağıtabilir. Ayrıca Red Hat iki tür içerik belirtir: Certified Content Collections ve Validated Content Collections.
Somut bir örnek: Bir kurum VMware, F5, Cisco, Microsoft, Red Hat, ServiceNow, AWS ve Azure sistemlerini otomasyona dahil etmek istiyor. Her entegrasyon için sıfırdan modül yazmak yerine ilgili collection’lar kullanılır:

vmware.vmware_rest
cisco.ios
redhat.rhel_system_roles
servicenow.itsm
microsoft.*
amazon.aws
azure.azcollection
Automation Hub, otomasyon dünyasının kurumsal marketi/kütüphanesi gibidir. Hazır ve destekli içerikler buradan yönetilir.
2.7 açısından önemli nokta: AAP 2.7’de highlighted content collections içinde hashicorp.vault, microsoft.mecm ve microsoft.scom öne çıkarılıyor. Örneğin microsoft.mecm, Microsoft Endpoint Configuration Manager ile Ansible arasında köprü sağlayan 26 yeni modül ile Red Hat Certified Collection olarak duyuruldu.
Execution Environment: “Playbook’un çalıştığı standart container ortamı”
Ne işe yarar?
Execution Environment, playbook’un çalışması için gereken runtime ortamıdır. İçinde Ansible, collection’lar, Python paketleri, sistem paketleri ve bağımlılıklar bulunabilir.
Somut bir örnek: Bir playbook VMware ortamına bağlanacaksa VMware collection’ına ve bazı Python kütüphanelerine ihtiyaç duyabilir. Başka bir playbook Azure için azure.azcollection, başka biri ServiceNow için ilgili collection ister. Eğer herkes kendi laptop’undan çalıştırırsa şu sorunlar çıkar: Birinde Python paketi eksik olabilir. Birinde collection versiyonu farklı olabilir. Birinde test ortamında çalışan playbook prod’da hata verebilir. Birinde eski dependency kalabilir.
Execution Environment ile bu bağımlılıklar container image içine alınabilir. Playbook yemek tarifi ise Execution Environment mutfaktır. Tarif aynı olsa bile mutfakta malzeme yoksa yemek yapılamaz.
2.7’de önemli yenilik: AAP 2.7’de Execution Environment Builder genel erişime alınmış durumda. Web UI üzerinden collection, Python/system package ve custom build step tanımlanabiliyor; tanımlar GitHub/GitLab’a gönderilebiliyor ve GitHub Actions ile image build tetiklenebiliyor.
Somut bir örnek: Windows patch için bir EE oluşturulduğunda:
İçinde ansible.windows collection var. Gerekli Python bağımlılıkları var. Kurum standardı CA certificate eklenmiş durumda. Internal registry’den pull edilecek şekilde hazırlanmış. Böylece her patch job’u aynı standart ortamda çalışır.
Automation Mesh: “İşin nerede çalışacağını belirleyen dağıtık çalışma yapısı”
Ne işe yarar?
Automation Mesh, otomasyon işlerini farklı execution node’lara dağıtmayı sağlar. Red Hat, automation mesh’i, mevcut bağlantıları kullanarak execution node’lar arasında otomasyon dağıtımını kolaylaştıran overlay network olarak açıklar. Execution node’lar playbook’ların fiilen çalıştığı yerlerdir.
Somut bir örnek: Müşterinin üç lokasyonu olsun: İstanbul veri merkezi, Ankara veri merkezi, İzmir DR merkezi.
Controller İstanbul’da olabilir ama Ankara’daki sunuculara patch işlemini İstanbul’dan göndermek network latency veya firewall nedeniyle sorunlu olabilir. Ankara’ya bir execution node kurulur. Job Ankara sunucularına yakın node üzerinde çalıştırılır. Merkez ofisteki operasyon müdürü işi planlar ama işi sahadaki yerel ekip yapar. Automation Mesh bu saha ekiplerini organize eder. Automation Mesh, merkezi kontrolü korurken otomasyon çalıştırma kapasitesini lokasyonlara dağıtır. Böylece latency, firewall ve ölçek problemleri azaltılır.
Automation Decisions / Event-Driven Ansible: “Olay olunca otomatik karar alma”
Ne işe yarar?
Event-Driven Ansible, sistemlerden gelen event’leri dinler ve belirli kurallara göre aksiyon alır. Red Hat, EDA’yı sistem event stream’ini dinleyen ve belirlenen event’lere hedefli otomasyon görevleriyle cevap veren otomasyon motoru olarak tanımlar. Rulebook’lar ise event source, condition ve action mantığını içerir.
Somut bir örnek: Monitoring sistemi “disk doluluk %90 oldu” alarmını üretti. EDA şunu yapabilir: Alarmı alır. Host bilgisini okur. Eğer ortam test ise otomatik cleanup playbook’u çalıştırır. Eğer ortam prod ise önce ServiceNow ticket açar veya onay bekler. Cleanup sonrası sonucu ticket’a yazar.
Basit rulebook mantığı:
rules:
– name: Disk doluluk alarmı geldiğinde cleanup başlat
condition: event.alert_type == “disk_full”
action:
run_job_template:
name: “Linux Disk Cleanup”
organization: “Default”
Automation Controller “biri butona basınca iş yapan sistemdir.” Event-Driven Ansible ise “alarmı duyunca kendisi aksiyon alan sistemdir.”
2.7’de önemli yenilik: AAP 2.7’de bazı event source ve filter’lar artık ansible-rulebook içinde eda.builtin olarak geliyor. Eski ansible.eda namespace’i geriye dönük uyumluluk için map edilse de artık aktif olarak orada maintain edilmiyor; rulebook’ların eda.builtin namespace’ine güncellenmesi öneriliyor.
Automation Portal / Self-Service Automation: “Son kullanıcı kataloğu”
Ne işe yarar?
Automation Portal, teknik olmayan veya sınırlı yetkili kullanıcıların onaylanmış otomasyonları katalogdan çalıştırmasını sağlar.
Somut bir örnek: Uygulama ekibi normalde Linux admin’e şunları soruyor: “Test ortamında yeni bir kullanıcı açabilir misiniz?”, “Uygulama servisini restart eder misiniz?”, “Log seviyesini debug’a çeker misiniz?”, “Yeni namespace oluşturabilir misiniz?”
Bunlar portalda self-service template olarak sunulabilir. Kullanıcı sadece form doldurur:
Ortam: Test
Uygulama: CRM
İşlem: Restart
Açıklama: Deployment sonrası restart
Arka tarafta AAP ilgili job template’i kontrollü şekilde çalıştırır.
2.7’de önemli yenilikler: AAP 2.7 ile automation portal artık RHEL 9 tabanlı pre-built VM appliance olarak QCOW2 veya VMDK formatında sunuluyor; KVM, OpenShift Virtualization ve VMware vSphere üzerinde çalışabiliyor. Ayrıca cloud-init ile ilk açılışta otomatik konfigürasyon ve atomic upgrade/rollback kabiliyeti geliyor.  Portal self-service tarafında RBAC bazlı navigation menüleri, GitHub Apps authentication, disconnected environment desteği ve excludeLabels ile job template filtreleme de geliyor.  Automation Portal, IT otomasyonlarını kontrollü bir self-service katalog haline getirir. Kullanıcıya yetkili olduğu kadarını gösterir, arkada ise, AAP güvenli şekilde işi çalıştırır.
Red Hat Ansible Lightspeed / AI tarafı: “Otomasyon geliştirmede AI asistanı”
Ne işe yarar?
Red Hat, Ansible Lightspeed’i, doğal dil prompt’ları ve IBM watsonx modelleriyle best-practice code recommendation sağlayan generative AI servisi olarak tanımlar.
Somut bir örnek: Bir otomasyon geliştiricisi şunu yazmak isteyebilir: RHEL sunucularda chrony kur, servisi enable et, NTP server olarak kurum içi adresi kullan. Lightspeed bu isteğe uygun playbook önerisi oluşturabilir. Geliştirici bunu kontrol eder, düzenler ve Git’e gönderir.
2.7’de önemli yenilik: AAP 2.7 release notes’a göre automation coding assistant artık RHEL AI hosted models desteği ekliyor ve WatsonX zorunluluğu kalkıyor.
Automation Intelligent Assistant + BYOK: “Kuruma özel bilgiyle cevap veren asistan”
Ne işe yarar?
BYOK, yani Bring Your Own Knowledge, kurumun kendi dokümanlarını intelligent assistant’ın RAG pipeline’ına eklemesini sağlar.
Somut bir örnek:
Kurumun iç prosedürleri var: “Prod ortamında servis restart için change kaydı zorunludur.”, “Database patch sadece pazar 01:00–04:00 arasında yapılabilir.”, “Firewall kuralı açılırken güvenlik onayı alınmalıdır.”, “OpenShift namespace isim standardı app-env-team formatında olmalıdır.”
BYOK ile intelligent assistant sadece genel Red Hat dokümantasyonuna değil, kurumun kendi standartlarına da bakarak cevap verebilir.
2.7’de önemli yenilik: Release notes’a göre müşteri kendi dokümantasyonunu intelligent assistant RAG pipeline’a enjekte edebiliyor; BYOK RAG image, cevap üretiminde Red Hat Ansible dokümantasyonundan daha öncelikli context olarak kullanılabiliyor. Ayrıca Red Hat, BYOK’un containerized ve OpenShift Operator deployment’ları için tasarlandığını; kurumun custom knowledge image oluşturup AAP ortamına import edebileceğini belirtiyor. AI asistan sadece Red Hat dokümanını değil, müşterinin kendi operasyon prosedürlerini de bilir hale getirilebilir.
AAP’de bir işin uçtan uca akışı: Şimdi tüm parçaları tek bir örnekte birleştirelim.
Senaryo: Monitoring alarmı geldi, Linux disk cleanup otomatik çalışacak
Monitoring sistemi alarm üretir: Örneğin Splunk, Instana veya başka bir monitoring sistemi “disk %90 doldu” der. Event-Driven Ansible alarmı alır: EDA event stream’i dinler. Rulebook içindeki condition alarm tipini kontrol eder. Rulebook karar verir: Eğer alarm disk_full ise Linux Disk Cleanup job template’i çalıştırılır. Automation Controller job’u başlatır: Controller doğru inventory, credential, project ve playbook’u kullanır.
Execution Environment seçilir: Cleanup playbook’u hangi collection ve Python paketlerine ihtiyaç duyuyorsa o EE içinde çalışır. Automation Mesh uygun node’u seçer: Hedef sunucu Ankara’daysa Ankara’daki execution node üzerinden işlem çalışabilir. Playbook hedef sisteme gider: Log dosyalarını temizler, geçici dosyaları siler, disk durumunu tekrar kontrol eder. Sonuç kaydedilir: Controller job output üretir. Gerekirse ServiceNow ticket güncellenir. Portal veya dashboard üzerinden görünür: Operasyon ekibi sonucu görebilir.
Bu akışta bileşenler şöyle çalışır:

2.7 sürümünde gelen en önemli yenilikler şunlar:

Sonuç olarak Red Hat Ansible Automation Platform 2.7, otomasyonun yalnızca teknik ekiplerin kullandığı bir script çalıştırma yaklaşımı olmaktan çıkarılıp, kurum genelinde standart, kontrollü ve ölçeklenebilir bir servis haline getirilmesini hedeflemektedir. Platform Gateway ile merkezi erişim ve güvenlik yaklaşımı güçlenirken, Automation Controller işleri kontrollü şekilde çalıştırır, Automation Hub içeriklerin yönetilmesini sağlar, Execution Environment standart çalışma ortamı sunar, Automation Mesh dağıtık yapılarda ölçeklenebilirlik kazandırır, Event-Driven Ansible olaylara otomatik aksiyon alınmasını mümkün kılar ve Automation Portal self-service kullanım deneyimini geliştirir. 2.7 sürümüyle birlikte özellikle kurulum modelindeki değişiklikler, direct API erişimlerinin dönüşümü, EE Builder’ın genel erişime alınması, EDA namespace değişiklikleri ve AI/BYOK kabiliyetleri müşteriler için dikkatle değerlendirilmesi gereken başlıklar haline gelmiştir. Bu nedenle mevcut AAP ortamlarının 2.7’ye geçişinde yalnızca yeni özelliklere değil, aynı zamanda migration etkilerine, entegrasyonlara, bağımlılıklara ve operasyonel süreçlere de bütünsel olarak bakılması gerekir.

Sarav Asiye Yiğit * 19 Haziran 2026

Kaynakça:

https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/whats_new-new_features_and_enhancements