ინვენტარის დანამატების გამოყენება Ansible კონტენტის კოლექციებიდან Ansible Tower-ში

IT გარემო სულ უფრო და უფრო რთული ხდება. ამ პირობებში, IT ავტომატიზაციის სისტემისთვის მნიშვნელოვანია განახლებული ინფორმაცია ქსელში არსებული და დამუშავების დაქვემდებარებული კვანძების შესახებ. Red Hat Ansible Automation Platform-ში ეს საკითხი წყდება ე.წ.ინვენტარი) – მართული კვანძების სიები.

უმარტივესი ფორმით, ინვენტარი არის სტატიკური ფაილი. ეს იდეალურია, როდესაც იწყებთ მუშაობას Ansible-თან, მაგრამ რაც უფრო იზრდება ავტომატიზაცია, ის არასაკმარისი ხდება.

და აქედან გამომდინარე:

1. როგორ განაახლოთ და შეინახოთ მონიტორინგის ქვეშ მყოფი კვანძების სრული სია, როდესაც ყველაფერი მუდმივად იცვლება, როდესაც დატვირთვები და შემდგომში კვანძები, რომლებზეც ისინი მუშაობენ, მოდის და მიდის?
2. როგორ დავახარისხოთ IT ინფრასტრუქტურის კომპონენტები, რათა კონკრეტულად შევარჩიოთ კვანძები კონკრეტული ავტომატიზაციის გამოსაყენებლად?

დინამიური ინვენტარი იძლევა პასუხებს ორივე კითხვაზე (დინამიური ინვენტარი) – სკრიპტი ან დანამატი, რომელიც ეძებს ავტომატიზირებულ კვანძებს, მიუთითებს სიმართლის წყაროზე. გარდა ამისა, დინამიური ინვენტარი ავტომატურად ანაწილებს კვანძებს ჯგუფებად, რათა უფრო ზუსტად შეარჩიოთ სამიზნე სისტემები კონკრეტული Ansible ავტომატიზაციის შესასრულებლად.

ინვენტარის დანამატები მიეცით Ansible მომხმარებელს გარე პლატფორმებზე წვდომის შესაძლებლობა, რათა დინამიურად მოძებნოს სამიზნე კვანძები და გამოიყენოს ეს პლატფორმები, როგორც სიმართლის წყარო ინვენტარის შექმნისას. წყაროების სტანდარტული სია Ansible-ში მოიცავს ღრუბლოვან პლატფორმებს AWS EC2, Google GCP და Microsoft Azure, და ასევე არის მრავალი სხვა ინვენტარის დანამატი Ansible-ისთვის.

Ansible Tower მოყვება რამდენიმე ინვენტარის დანამატები, რომლებიც მუშაობენ უპრობლემოდ და, გარდა ზემოთ ჩამოთვლილი ღრუბლოვანი პლატფორმებისა, უზრუნველყოფენ ინტეგრაციას VMware vCenter-თან, Red Hat OpenStack Platform-თან და Red Hat Satellite-თან. ამ დანამატებისთვის, თქვენ უბრალოდ უნდა მიაწოდოთ რწმუნებათა სიგელები სამიზნე პლატფორმასთან დასაკავშირებლად, რის შემდეგაც ისინი შეიძლება გამოყენებულ იქნას, როგორც ინვენტარის მონაცემების წყარო Ansible Tower-ში.

გარდა სტანდარტული დანამატებისა, რომლებიც შედის Ansible Tower-ში, არის სხვა ინვენტარის დანამატები, რომლებსაც მხარს უჭერს Ansible საზოგადოება. გადასვლით Red Hat Ansible კონტენტის კოლექციები ამ დანამატებმა დაიწყეს შესაბამის კოლექციებში ჩართვა.

ამ პოსტში ჩვენ ავიღებთ მაგალითს ServiceNow-ის ინვენტარიზაციის დანამატთან მუშაობის მაგალითს, IT სერვისების მართვის პოპულარულ პლატფორმას, რომელშიც მომხმარებლები ხშირად ინახავენ ინფორმაციას ყველა მათი მოწყობილობის შესახებ CMDB-ში. გარდა ამისა, CMDB შეიძლება შეიცავდეს კონტექსტს, რომელიც სასარგებლოა ავტომატიზაციისთვის, როგორიცაა ინფორმაცია სერვერის მფლობელების, მომსახურების დონის (წარმოების/არაწარმოების), დაინსტალირებული განახლებებისა და ტექნიკური ფანჯრების შესახებ. Ansible ინვენტარის დანამატს შეუძლია იმუშაოს ServiceNow CMDB-თან და არის კოლექციის ნაწილი სერვისენოვი პორტალზე galaxy.ansible.com.

Git საცავი

იმისათვის, რომ გამოიყენოთ ინვენტარის დანამატი კოლექციიდან Ansible Tower-ში, ის უნდა იყოს დაყენებული, როგორც პროექტის წყარო. Ansible Tower-ში პროექტი არის ინტეგრაცია ვერსიების კონტროლის სისტემასთან, როგორიცაა git საცავი, რომელიც შეიძლება გამოყენებულ იქნას არა მხოლოდ ავტომატიზაციის სათამაშო წიგნების, არამედ ცვლადების და ინვენტარის სიების სინქრონიზაციისთვის.

ჩვენი საცავი სინამდვილეში ძალიან მარტივია:

├── collections
│   └── requirements.yml
└── servicenow.yml

servicenow.yml ფაილი შეიცავს დეტალებს დანამატის ინვენტარისთვის. ჩვენს შემთხვევაში, ჩვენ უბრალოდ ვაზუსტებთ ცხრილს ServiceNow CMDB-ში, რომელიც გვინდა გამოვიყენოთ. ჩვენ ასევე დავაყენეთ ველები, რომლებიც დაემატება როგორც კვანძის ცვლადები, ასევე გარკვეული ინფორმაცია ჯგუფების შესახებ, რომელთა შექმნაც გვინდა.

$ 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: ''

გთხოვთ, გაითვალისწინოთ, რომ ეს არ აკონკრეტებს ServiceNow-ის მაგალითს, რომელსაც ჩვენ რაიმე გზით დავუკავშირდებით და არ აკონკრეტებს რაიმე სერთიფიკატს კავშირისთვის. ჩვენ ამ ყველაფერს მოგვიანებით დავაკონფიგურირებთ Ansible Tower-ში.

ფაილების კოლექცია/მოთხოვნილებები.yml საჭიროა იმისათვის, რომ Ansible Tower-მა შეძლოს საჭირო კოლექციის ჩამოტვირთვა და ამით საჭირო ინვენტარის მოდულის მიღება. წინააღმდეგ შემთხვევაში, ჩვენ მოგვიწევდა ამ კოლექციის ხელით დაყენება და შენარჩუნება ყველა ჩვენს Ansible Tower კვანძზე.

$ cat collections/requirements.yml
---
collections:

- name: servicenow.servicenow

მას შემდეგ რაც ამ კონფიგურაციას გადავიყვანთ ვერსიის კონტროლზე, ჩვენ შეგვიძლია შევქმნათ პროექტი Ansible Tower-ში, რომელიც მიუთითებს შესაბამის საცავზე. ქვემოთ მოყვანილი მაგალითი აკავშირებს Ansible Tower-ს ჩვენს github საცავთან. ყურადღება მიაქციეთ SCM URL-ს: ის საშუალებას გაძლევთ დაარეგისტრიროთ ანგარიში პირად საცავთან დასაკავშირებლად, ასევე მიუთითოთ კონკრეტული ფილიალი, ტეგი ან შეკვეთის ვალდებულება.

სერთიფიკატების შექმნა ServiceNow-ისთვის

როგორც აღვნიშნეთ, კონფიგურაცია ჩვენს საცავში არ შეიცავს სერთიფიკატებს ServiceNow-თან დასაკავშირებლად და არ აკონკრეტებს ServiceNow-ის მაგალითს, რომელთანაც ჩვენ დავუკავშირდებით. ამიტომ, ამ მონაცემების დასაყენებლად, ჩვენ შევქმნით რწმუნებათა სიგელებს Ansible Tower-ში. Მიხედვით ServiceNow ინვენტარის მოდულის დოკუმენტაცია, არის მრავალი გარემოს ცვლადი, რომლითაც ჩვენ დავაყენებთ კავშირის პარამეტრებს, მაგალითად, ასე:

= 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

ამ შემთხვევაში, თუ SN_USERNAME გარემოს ცვლადი დაყენებულია, ინვენტარის დანამატი გამოიყენებს მას, როგორც ანგარიშს ServiceNow-თან დასაკავშირებლად.

ჩვენ ასევე უნდა დავაყენოთ SN_INSTANCE და SN_PASSWORD ცვლადები.

თუმცა, Ansible Tower-ში ამ ტიპის რწმუნებათა სიგელები არ არის, სადაც შეგიძლიათ მიუთითოთ ეს მონაცემები ServiceNow-ისთვის. მაგრამ Ansible Tower საშუალებას გვაძლევს განვსაზღვროთ მორგებული სერთიფიკატების ტიპები, ამის შესახებ მეტი შეგიძლიათ წაიკითხოთ სტატიაში "Asible Tower Feature Spotlight: Custom Credentials".

ჩვენს შემთხვევაში, ServiceNow-ისთვის მორგებული სერთიფიკატების შეყვანის კონფიგურაცია ასე გამოიყურება:

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

ეს სერთიფიკატები გამოვლინდება როგორც გარემოს ცვლადები იმავე სახელით. ეს აღწერილია ინჟექტორის კონფიგურაციაში:

env:
  SN_INSTANCE: '{{ SN_INSTANCE }}'
  SN_PASSWORD: '{{ SN_PASSWORD }}'
  SN_USERNAME: '{{ SN_USERNAME }}'

ასე რომ, ჩვენ განვსაზღვრეთ ჩვენთვის საჭირო სერთიფიკატის ტიპი, ახლა შეგვიძლია დავამატოთ ServiceNow ანგარიში და დავაყენოთ მაგალითი, მომხმარებლის სახელი და პაროლი, ასე:

ჩვენ ვქმნით ინვენტარს

ასე რომ, ახლა ჩვენ ყველანი მზად ვართ შევქმნათ ინვენტარი Ansible Tower-ში. მოდით ვუწოდოთ მას ServiceNow:

ინვენტარის შექმნის შემდეგ შეგვიძლია მას მონაცემთა წყარო დავურთოთ. აქ ჩვენ ვაზუსტებთ ადრე შექმნილ პროექტს და შევდივართ გზას ჩვენი YAML ინვენტარის ფაილის წყაროს კონტროლის საცავში, ჩვენს შემთხვევაში ეს არის servicenow.yml პროექტის root-ში. გარდა ამისა, თქვენ უნდა დააკავშიროთ თქვენი ServiceNow ანგარიში.

იმის შესამოწმებლად, თუ როგორ მუშაობს ყველაფერი, ვცადოთ სინქრონიზაცია მონაცემთა წყაროსთან ღილაკზე „სინქრონიზაცია ყველა“ დაწკაპუნებით. თუ ყველაფერი სწორად არის კონფიგურირებული, მაშინ კვანძები უნდა იყოს შემოტანილი ჩვენს ინვენტარში:

გთხოვთ გაითვალისწინოთ, რომ ჩვენთვის საჭირო ჯგუფებიც შეიქმნა.

დასკვნა

ამ პოსტში ჩვენ განვიხილეთ, თუ როგორ გამოვიყენოთ ინვენტარიზაციის დანამატები Ansible Tower-ის კოლექციებიდან, მაგალითად ServiceNow მოდულის გამოყენებით. ჩვენ ასევე უსაფრთხოდ დავრეგისტრირდით რწმუნებათა სიგელები ჩვენს ServiceNow მაგალითთან დასაკავშირებლად. ინვენტარის დანამატის დაკავშირება პროექტიდან მუშაობს არა მხოლოდ მესამე მხარის ან მორგებული დანამატებით, არამედ შეიძლება გამოყენებულ იქნას ზოგიერთი სტანდარტული ინვენტარის მუშაობის შესაცვლელად. ეს ხდის Ansible Automation Platform-ს მარტივ და შეუფერხებლად ინტეგრირებას არსებულ ინსტრუმენტებთან, როდესაც ავტომატიზირებულია უფრო რთული IT გარემო.

თქვენ შეგიძლიათ იპოვოთ მეტი ინფორმაცია ამ პოსტში განხილულ თემებზე, ისევე როგორც Ansible-ის გამოყენების სხვა ასპექტებზე, აქ:

• ბლოგის მიერ ServiceNow-ის ავტომატიზაცია Ansible-ის გამოყენებით.
• როგორ შევქმნათ საკუთარი კოლექციები.
• Red Hat მხარდაჭერილი კოლექციების სია Automation Hub ვებსაიტზე (cloud.redhat.com).
• Ansible ავტომატიზაციის პლატფორმის ელექტრონული წიგნები.

*Red Hat არ იძლევა გარანტიას, რომ აქ მოცემული კოდი სწორია. ყველა მასალა მოწოდებულია არადამტკიცების საფუძველზე, თუ სხვა რამ პირდაპირ არ არის მითითებული.

წყარო: www.habr.com