BT ortamları giderek daha karmaşık hale geliyor. Bu şartlarda BT otomasyon sisteminin ağda bulunan ve işleme konu olan düğümler hakkında güncel bilgiye sahip olması kritik öneme sahiptir. Red Hat Ansible Otomasyon Platformunda bu sorun envanter () – yönetilen düğümlerin listeleri.
En basit haliyle envanter statik bir dosyadır. Ansible ile çalışmaya başladığınızda bu idealdir ancak otomasyon arttıkça yetersiz hale gelir.
Ve işte neden:
- İşler sürekli değişirken, iş yükleri ve ardından üzerinde çalıştıkları düğümler gelip gittiğinde, izlenen düğümlerin tam listesini nasıl günceller ve korursunuz?
- Belirli bir otomasyonu uygulamak için özel olarak düğümleri seçmek amacıyla BT altyapısının bileşenleri nasıl sınıflandırılır?
Dinamik envanter bu soruların her ikisine de yanıt sağlar () – gerçeğin kaynağına atıfta bulunarak otomatikleştirilecek düğümleri arayan bir komut dosyası veya eklenti. Ayrıca dinamik envanter, düğümleri otomatik olarak gruplar halinde sınıflandırır, böylece belirli Ansible otomasyonunu gerçekleştirmek için hedef sistemleri daha doğru bir şekilde seçebilirsiniz.
Ansible kullanıcısına, hedef düğümleri dinamik olarak aramak için harici platformlara erişme ve bir envanter oluştururken bu platformları bir doğruluk kaynağı olarak kullanma yeteneği verin. Ansible'daki standart kaynak listesi AWS EC2, Google GCP ve Microsoft Azure bulut platformlarını içerir ve Ansible için başka birçok envanter eklentisi de vardır.
Ansible Tower bir dizi özellik ile birlikte gelir Kutudan çıktığı gibi çalışan ve yukarıda listelenen bulut platformlarına ek olarak VMware vCenter, Red Hat OpenStack Platformu ve Red Hat Satellite ile entegrasyon sağlayan. Bu eklentiler için hedef platforma bağlanmak için kimlik bilgileri sağlamanız yeterlidir; ardından bunlar Ansible Tower'da envanter verileri kaynağı olarak kullanılabilir.
Ansible Tower'da bulunan standart eklentilere ek olarak Ansible topluluğu tarafından desteklenen başka envanter eklentileri de vardır. Geçiş ile bu eklentiler ilgili koleksiyonlara dahil edilmeye başlandı.
Bu yazıda, müşterilerin genellikle tüm cihazları hakkındaki bilgileri CMDB'de sakladığı popüler bir BT hizmet yönetimi platformu olan ServiceNow için envanter eklentisiyle çalışmanın bir örneğini ele alacağız. Ayrıca CMDB, sunucu sahipleri, hizmet düzeyleri (üretim/üretim dışı), yüklü güncellemeler ve bakım pencereleri hakkında bilgiler gibi otomasyon için yararlı olan bağlamları da içerebilir. Ansible envanter eklentisi ServiceNow CMDB ile çalışabilir ve koleksiyonun bir parçasıdır portalda .
Git deposu
Ansible Tower'daki bir koleksiyondaki envanter eklentisini kullanmak için bunun proje kaynağı olarak ayarlanması gerekir. Ansible Tower'da proje, yalnızca otomasyon oyun kitaplarını değil aynı zamanda değişkenleri ve envanter listelerini de senkronize etmek için kullanılabilen, git deposu gibi bir tür sürüm kontrol sistemi ile entegrasyondur.
Depomuz aslında çok basit:
├── collections
│ └── requirements.yml
└── servicenow.yml
servicenow.yml dosyası eklenti envanterine ilişkin ayrıntıları içerir. Bizim durumumuzda, kullanmak istediğimiz tabloyu ServiceNow CMDB'de belirtmemiz yeterlidir. Ayrıca düğüm değişkenleri olarak eklenecek alanları ve oluşturmak istediğimiz gruplara ilişkin belirli bilgileri de belirliyoruz.
$ cat servicenow.yml
plugin: servicenow.servicenow.now
table: cmdb_ci_linux_server
fields: [ip_address,fqdn,host_name,sys_class_name,name,os]
keyed_groups:
- key: sn_sys_class_name | lower
prefix: ''
separator: ''
- key: sn_os | lower
prefix: ''
separator: ''
Bunun hiçbir şekilde bağlanacağımız ServiceNow örneğini belirtmediğini ve bağlantı için herhangi bir kimlik bilgisi belirtmediğini lütfen unutmayın. Tüm bunları daha sonra Ansible Tower'da yapılandıracağız.
Ansible Tower'ın gerekli koleksiyonu indirebilmesi ve böylece gerekli envanter eklentisini alabilmesi için gereklidir. Aksi takdirde, bu koleksiyonu tüm Ansible Tower düğümlerimize manuel olarak kurmamız ve bakımını yapmamız gerekirdi.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Bu konfigürasyonu sürüm kontrolüne aktardıktan sonra Ansible Tower'da ilgili depoya referans veren bir proje oluşturabiliriz. Aşağıdaki örnek Ansible Tower'ı github depomuza bağlar. SCM URL'sine dikkat edin: özel bir depoya bağlanmak için bir hesap kaydetmenize ve ayrıca belirli bir şube, etiket veya ödeme taahhüdünde bulunmanıza olanak tanır.
ServiceNow için kimlik bilgileri oluşturma
Belirtildiği gibi havuzumuzdaki konfigürasyon ServiceNow'a bağlanmak için kimlik bilgileri içermiyor ve iletişim kuracağımız ServiceNow örneğini belirtmiyor. Bu nedenle bu verileri ayarlamak için Ansible Tower'da kimlik bilgileri oluşturacağız. Buna göre bağlantı parametrelerini ayarlayacağımız bir dizi ortam değişkeni vardır, örneğin:
= username
The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by SN_TABLE
set_via:
env:
- name: SN_USERNAME
Bu durumda SN_USERNAME ortam değişkeni ayarlanmışsa envanter eklentisi bunu ServiceNow'a bağlanmak için bir hesap olarak kullanacaktır.
Ayrıca SN_INSTANCE ve SN_PASSWORD değişkenlerini de ayarlamamız gerekiyor.
Ancak Ansible Tower'da ServiceNow için bu verileri belirtebileceğiniz bu türde kimlik bilgileri yoktur. Ancak Ansible Tower şunları tanımlamamıza olanak tanıyor: Bu konuda daha fazla bilgiyi makalede okuyabilirsiniz .
Bizim durumumuzda ServiceNow için özel kimlik bilgilerinin giriş yapılandırması şöyle görünür:
fields:
- id: SN_USERNAME
type: string
label: Username
- id: SN_PASSWORD
type: string
label: Password
secret: true
- id: SN_INSTANCE
type: string
label: Snow Instance
required:
- SN_USERNAME
- SN_PASSWORD
- SN_INSTANCE
Bu kimlik bilgileri aynı ada sahip ortam değişkenleri olarak gösterilecektir. Bu, enjektör konfigürasyonunda açıklanmaktadır:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Böylece ihtiyacımız olan kimlik bilgisi türünü tanımladık, artık bir ServiceNow hesabı ekleyebilir ve örneği, kullanıcı adını ve şifreyi şu şekilde ayarlayabiliriz:
Envanter oluşturuyoruz
Artık hepimiz Ansible Tower'da bir envanter oluşturmaya hazırız. Buna ServiceNow adını verelim:
Envanteri oluşturduktan sonra ona bir veri kaynağı ekleyebiliriz. Burada daha önce oluşturduğumuz projeyi belirtiyoruz ve kaynak kontrol deposundaki YAML envanter dosyamızın yolunu giriyoruz, bizim durumumuzda proje kökündeki servicenow.yml'dir. Ayrıca ServiceNow hesabınızı bağlamanız gerekir.
Her şeyin nasıl çalıştığını kontrol etmek için "Tümünü senkronize et" düğmesini tıklayarak veri kaynağıyla senkronizasyon yapmayı deneyelim. Her şey doğru yapılandırılmışsa düğümlerin envanterimize aktarılması gerekir:
Lütfen ihtiyacımız olan grupların da oluşturulduğunu unutmayın.
Sonuç
Bu yazıda, örnek olarak ServiceNow eklentisini kullanarak Ansible Tower'daki koleksiyonlardaki envanter eklentilerinin nasıl kullanılacağına baktık. ServiceNow örneğimize bağlanmak için kimlik bilgilerini de güvenli bir şekilde kaydettik. Bir projedeki envanter eklentisini bağlamak yalnızca üçüncü taraf veya özel eklentilerle çalışmakla kalmaz, aynı zamanda bazı standart envanterlerin çalışmasını değiştirmek için de kullanılabilir. Bu, Ansible Automation Platform'un giderek daha karmaşık hale gelen BT ortamlarını otomatikleştirirken mevcut araçlarla entegrasyonunu kolay ve sorunsuz hale getirir.
Bu yazıda tartışılan konuların yanı sıra Ansible kullanımının diğer yönleri hakkında daha fazla bilgiyi burada bulabilirsiniz:
- Blog yazan: .
- .
- Otomasyon Merkezi web sitesindeki Red Hat destekli koleksiyonların listesi ().
- .
*Red Hat burada yer alan kodun doğru olduğunu garanti etmez. Aksi açıkça belirtilmediği sürece tüm materyaller onay alınmadan sağlanmaktadır.
Kaynak: habr.com