Automatizacija zamjene diska sa Ansibleom

Zdravo svima. Radim kao vodeći sistem administrator u OK i odgovoran sam za stabilan rad portala. Želim da pričam o tome kako smo izgradili proces automatske zamene diska, a zatim kako smo isključili administratora iz ovog procesa i zamenili ga botom.

Ovaj članak je vrsta transliteracije predstave na HighLoad+ 2018

Izgradnja procesa zamjene diska

Prvo nekoliko brojeva

OK je ogromna usluga koju koriste milioni ljudi. Opslužuje ga oko 7 hiljada servera koji se nalaze u 4 različita data centra. Na serverima postoji više od 70 hiljada diskova. Ako ih složite jednu na drugu, dobijate toranj sa visinom većom od 1 km.

Tvrdi diskovi su komponenta servera koja najčešće kvari. Na ovom volumenu moramo mijenjati oko 30 diskova sedmično, a ova procedura je postala ne baš prijatna rutina.

Incidenti

Uveli smo potpuno upravljanje incidentima u našoj kompaniji. Svaki incident snimamo u Jira, a zatim ga rješavamo i analiziramo. Ako je incident uticao na korisnike, onda ćemo se svakako okupiti i razmisliti kako brže reagirati u takvim slučajevima, kako smanjiti učinak i naravno kako spriječiti da se ponovi.

Skladištenje nije izuzetak. Zabbix prati njihov status. Pratimo poruke u Syslogu za greške u pisanju/čitanju, analiziramo status HW/SW raidova, pratimo SMART, izračunavamo trošenje SSD-ova.

Kako su se diskovi mijenjali prije

Kada se okidač aktivira u Zabbixu, u Jira se stvara incident koji se automatski stavlja na odgovarajuće inženjere u podatkovne centre. To radimo sa svim HW incidentima, odnosno onima koji zahtijevaju neku vrstu fizičkog rada na opremi u data centru.
Inženjer data centra je osoba koja rješava probleme vezane za hardver, odgovorna je za instaliranje, održavanje i demontažu servera. Nakon što je dobio kartu, inženjer kreće na posao. Na policama diskova mijenja diskove sam. Ali ako nema pristup željenom uređaju, inženjer se za pomoć obraća dežurnim sistem administratorima. Prije svega, trebate ukloniti disk iz rotacije. Da biste to učinili, potrebno je izvršiti potrebne promjene na serveru, zaustaviti aplikacije, isključiti disk.

Za rad cijelog portala u toku radne smjene odgovoran je dežurni sistem administrator. On istražuje incidente, radi popravke, pomaže programerima u malim zadacima. Ne bavi se samo tvrdim diskovima.

Ranije su inženjeri data centara razgovarali sa administratorom sistema. Inženjeri su slali linkove na Jira tikete, administrator ih je pregledao, vodio dnevnik rada u nekoj bilježnici. Ali za takve zadatke, razgovori su nezgodni: informacije tamo nisu strukturirane i brzo se gube. Da, i administrator se mogao jednostavno udaljiti od računara i neko vrijeme ne odgovarati na zahtjeve, a inženjer je stajao na serveru s paketom diskova i čekao.

Ali najgore je bilo to što administratori nisu vidjeli cijelu sliku: koji disk incidenti postoje, gdje bi potencijalno mogao nastati problem. To je zbog činjenice da sve HW incidente predajemo inženjerima. Da, bilo je moguće prikazati sve incidente na administratorskoj kontrolnoj tabli. Ali ima ih puno, a administrator je bio uključen samo u neke od njih.

Osim toga, inženjer nije mogao ispravno odrediti prioritete, jer ne zna ništa o namjeni određenih servera, o distribuciji informacija među diskovima.

Nova procedura zamene

Prvo što smo uradili je da smo sve incidente na disku premestili u poseban tip “HW disk” i dodali mu polja “naziv bloka bloka”, “veličina” i “tip diska” tako da ove informacije budu sačuvane u tiketu i ne morate stalno ćaskati.

Takođe smo se dogovorili da u okviru jednog incidenta promenimo samo jedan disk. To je uvelike pojednostavilo proces automatizacije, prikupljanje statistike i rad u budućnosti.

Dodatno, dodato je polje "odgovorni administrator". Tu se automatski zamjenjuje dežurni sistem administrator. Ovo je vrlo zgodno, jer sada inženjer uvijek vidi ko je odgovoran. Nema potrebe da idete u kalendar i gledate. Upravo je ovo polje omogućilo prikazivanje tiketa na administratorskoj kontrolnoj tabli, u čemu bi mogla biti potrebna njegova pomoć.

Kako bi svi učesnici imali maksimalnu korist od inovacija, kreirali smo filtere i kontrolne table i momcima ispričali o njima. Kada ljudi shvate promjenu, ne distanciraju se od nje kao od nečeg nepotrebnog. Važno je da inženjer zna broj stalka na kojem se server nalazi, veličinu i tip diska. Administrator treba, prije svega, da shvati o kakvoj se grupi servera radi, kakav učinak može imati pri zamjeni diska.

Prisustvo polja i njihov prikaz je zgodno, ali to nas nije spasilo potrebe za korištenjem chatova. Da bismo to uradili, morali smo da promenimo tok posla.

Nekada je bilo ovako:

Danas inženjeri na ovaj način nastavljaju da rade kada im nije potrebna pomoć administratora.

Prvo što smo uradili je uvođenje novog statusa Istražite. Karta je u ovom statusu kada inženjer još nije odlučio da li će mu trebati administrator ili ne. Preko ovog statusa, inženjer može prenijeti kartu administratoru. Osim toga, označavamo tikete ovim statusom kada je potrebna zamjena diska, ali sam disk nije na licu mjesta. Ovo se dešava u slučaju CDN-a i udaljenih lokacija.

Dodali smo i status spreman. Karta se na njega prenosi nakon zamjene diska. Odnosno, sve je već urađeno, ali je HW/SW RAID sinhronizovan na serveru. Ovo može potrajati dosta dugo.

Ako je administrator uključen u rad, shema postaje malo složenija.

Van statusa otvoreno Ulaznicu mogu prevesti i administrator sistema i inženjer. u statusu U toku administrator uklanja disk iz rotacije tako da ga inženjer može jednostavno izvući: uključuje pozadinsko osvjetljenje, demontira disk, zaustavlja aplikacije, ovisno o specifičnoj grupi servera.

Karta se zatim prevodi na Spreman za promjenu: Ovo je signal inženjeru da se disk može izvući. Sva polja u Jira su već popunjena, inženjer zna koji tip i veličinu diska. Ovi podaci se unose ili na prethodni status automatski ili od strane administratora.

Nakon zamjene diska, tiket se prenosi u status promijenjen. Provjerava se da li je umetnut ispravan disk, izvršeno je particioniranje, pokreće se aplikacija i pokreću se neki zadaci oporavka podataka. Takođe, karta se može prebaciti u status spreman, u ovom slučaju administrator ostaje odgovoran, jer je pokrenuo disk u rotaciji. Kompletna šema izgleda ovako.

Dodavanje novih polja nam je znatno olakšalo život. Momci su počeli raditi sa strukturiranim informacijama, postalo je jasno šta treba učiniti i u kojoj fazi. Prioriteti su postali mnogo relevantniji, jer ih sada postavlja administrator.

Nema potrebe za razgovorima. Naravno, administrator može napisati inženjeru „ovdje trebate zamijeniti brže“, ili „već je veče, hoćete li imati vremena da ga zamijenite?“. Ali više ne komuniciramo svakodnevno u razgovorima o ovim pitanjima.

Diskovi su se počeli mijenjati u serijama. Ako je administrator došao na posao malo ranije, ima slobodnog vremena, a ništa se još nije dogodilo, može pripremiti brojne servere za zamjenu: popuniti polja, ukloniti diskove iz rotacije i prebaciti zadatak inženjeru. Nešto kasnije dolazi inženjer u data centar, vidi zadatak, uzima potrebne diskove iz skladišta i odmah ih mijenja. Kao rezultat toga, povećana je stopa zamjene.

Naučeno iskustvo prilikom izgradnje Workflow-a

• Kada gradite proceduru, morate prikupiti informacije iz različitih izvora.
  Neki od naših administratora nisu znali da inženjer sam mijenja diskove. Neki su mislili da su inženjeri sinhronizovali MD RAID, iako mu neki od njih nisu ni imali pristup. Neki vodeći inženjeri su to radili, ali ne uvijek, jer proces nije nigdje opisan.
• Procedura bi trebala biti jednostavna i razumljiva.
  Čovjeku je teško držati mnogo koraka u glavi. Najvažnije susedne statuse u Jira treba postaviti na glavni ekran. Možete ih preimenovati, na primjer, U toku zovemo Ready to change. A ostali statusi se mogu sakriti u padajućem meniju tako da ne bole oči. Ali bolje je ne ograničavati ljude, dati im priliku da naprave tranziciju.
  Objasnite vrijednost inovacije. Kada ljudi shvate, bolje je da prihvate novu proceduru. Bilo nam je jako važno da ljudi ne kliknu kroz cijeli proces, već ga prate. Zatim smo izgradili ovu automatizaciju.
• Sačekaj, analiziraj, shvati.
  Trebalo nam je oko mjesec dana da izgradimo proceduru, tehničku implementaciju, sastanke i rasprave. A za implementaciju - više od tri mjeseca. Vidio sam kako ljudi polako počinju da koriste inovaciju. Bilo je mnogo negativnosti u ranim fazama. Ali to je bilo potpuno nezavisno od same procedure, njene tehničke implementacije. Na primjer, jedan administrator je koristio ne Jira, već Jira dodatak u Confluenceu, a neke stvari mu nisu bile dostupne. Pokazali smo mu Jira, administratora koji je povećao produktivnost i u općim zadacima i u zamjenama diskova.

Automatizacija zamjene diska

Više puta smo pristupali automatizaciji zamjene diskova. Već smo imali razvoje, skripte, ali su svi radili ili u interaktivnom ili ručnom načinu rada, zahtijevali su pokretanje. I tek nakon uvođenja nove procedure, shvatili smo da je to upravo ono što nam treba.

Budući da je sada proces zamjene podijeljen u faze, od kojih svaka ima izvršioca i listu radnji, automatizaciju možemo omogućiti u fazama, a ne sve odjednom. Na primjer, najjednostavnija faza - Ready (provjera RAID/sinhronizacije podataka) može se lako delegirati botu. Kada bot malo nauči, možete mu dati odgovorniji zadatak - rotirati disk itd.

Setup Zoo

Prije nego što pričamo o botu, krenimo u kratak obilazak našeg zoološkog vrta. Prije svega, to je zbog gigantske veličine naše infrastrukture. Drugo, za svaku uslugu pokušavamo odabrati optimalnu konfiguraciju hardvera. Imamo oko 20 modela hardverskog RAID-a, uglavnom LSI i Adaptec, ali postoje i HP i DELL različitih verzija. Svaki RAID kontroler ima svoj vlastiti uslužni program za upravljanje. Skup komandi i njihov izlaz mogu se razlikovati od verzije do verzije za svaki RAID kontroler. Tamo gdje se HW-RAID ne koristi, može postojati mdraid.

Gotovo sve nove instalacije radimo bez redundancije diska. Pokušavamo više da prestanemo da koristimo hardverske i softverske RAID-ove, jer pravimo rezervne kopije naših sistema na nivou data centara, a ne servera. Ali naravno postoji mnogo naslijeđenih servera koje treba održavati.

Negdje se diskovi u RAID kontrolerima bacaju na neobrađene uređaje, negdje se koriste JBOD-ovi. U serveru postoje konfiguracije sa jednim sistemskim diskom, a ako ga treba zamijeniti, onda morate ponovo rolovati server sa instalacijom OS-a i aplikacija, te istim verzijama, zatim dodati konfiguracijske fajlove, pokrenuti aplikacije. Postoji i mnogo grupa servera u kojima se redundantnost ne vrši na nivou podsistema diska, već direktno u samim aplikacijama.

Ukupno imamo preko 400 jedinstvenih grupa servera koje pokreću oko 100 različitih aplikacija. Da bismo pokrili tako veliki broj opcija, bio nam je potreban alat za automatizaciju bogat funkcijama. Po mogućnosti sa jednostavnim DSL-om, da ga ne podržava samo onaj ko ga je napisao.

Izabrali smo Ansible jer je bez agenta: nije bilo potrebe za pripremanjem infrastrukture, brz početak. Osim toga, napisan je na Pythonu, koji je prihvaćen kao standard u timu.

Opšta šema

Pogledajmo opću shemu automatizacije koristeći primjer jednog incidenta. Zabbix otkriva da je sdb disk otkazao, okidač se aktivira i tiket se kreira u Jira. Administrator je to pogledao, shvatio da ovo nije duplikat i da nije lažno pozitivna, odnosno da treba promijeniti disk i prenosi tiket u U tijeku.

Aplikacija DiskoBot, napisana na Pythonu, periodično ispituje Jira za nove karte. Primjećuje da se pojavila nova ulaznica U toku, aktivira se odgovarajuća nit, koja pokreće playbook u Ansibleu (ovo se radi za svaki status u Jira). U ovom slučaju se pokreće Prepare2change.

Ansible ide na host, uklanja disk iz rotacije i prijavljuje status aplikaciji putem povratnih poziva.

Na osnovu rezultata, bot automatski mijenja tiket u Ready to change. Inženjer prima obavijest i odlazi mijenjati disk, nakon čega prenosi tiket na Changed.

Prema gornjoj šemi, tiket se vraća botu, koji pokreće drugi playbook, ide do hosta i stavlja disk u rotaciju. Bot zatvara tiket. Ura!

Hajde sada da pričamo o nekim komponentama sistema.

Diskobot

Ova aplikacija je napisana u Pythonu. Bira karte iz Jira prema JQL-u. U zavisnosti od statusa tiketa, potonji dolazi do odgovarajućeg rukovaoca, koji zauzvrat pokreće Ansible playbook koji odgovara statusu.

JQL i intervali anketiranja su definirani u konfiguracijskoj datoteci aplikacije.

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

Na primjer, među tiketima u statusu U toku, odabrane su samo one sa popunjenim poljima Veličina diska i Ime uređaja. Ime uređaja je ime blok uređaja potrebnog za izvršavanje playbook-a. Veličina diska je potrebna kako bi inženjer znao koja je veličina diska potrebna.

A među tiketima sa statusom Ready, tikete s oznakom dbot_ignore se filtriraju. Inače, Jira oznake koristimo i za takvo filtriranje, i za označavanje duplikata tiketa i prikupljanje statistike.

U slučaju neuspjeha playbook-a, Jira dodjeljuje oznaku dbot_failed tako da se može kasnije riješiti.

Interakcija sa Ansibleom

Aplikacija komunicira sa Ansible-om putem Ansible Python API. U playbook_executor prenosimo ime datoteke i skup varijabli. Ovo vam omogućava da zadržite Ansible projekat u obliku običnih yml datoteka, a ne da ga opisujete u Python kodu.

Takođe, ime blok uređaja, status tiketa, kao i callback_url, u kojem je ključ za izdavanje tvrdo kodiran, prenose se Ansibleu preko *extra_vars* - koristi se za povratni poziv u HTTP-u.

Za svako pokretanje generiše se privremeni inventar koji se sastoji od jednog hosta i grupe kojoj ovaj host pripada, tako da se primenjuju group_vars.

Evo primjera zadatka koji implementira HTTP povratni poziv.

Dobijamo rezultat izvođenja playbook-a koristeći callaback(e). Oni su dva tipa:

• Dodatak za povratni poziv Ansible, pruža podatke o rezultatima izvršenja playbook-a. Opisuje zadatke koji su pokrenuti, uspješno ili neuspješno završeni. Ovaj povratni poziv se poziva kada se playbook završi sa reprodukcijom.
• HTTP povratni poziv za dobijanje informacija dok se playbook reproducira. U Ansible zadatku izvodimo POST / GET zahtjev sa strane naše aplikacije.

Kroz HTTP povratni(e) poziv(e), prosleđuju se varijable koje su definisane tokom izvršavanja playbook-a i koje želimo da sačuvamo i koristimo u narednim izvršavanjima. Ove podatke zapisujemo u sqlitu.

Također putem HTTP povratnog poziva ostavljamo komentare i mijenjamo status tiketa.

HTTP povratni poziv

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

Poput mnogih zadataka istog tipa, premjestili smo ga u zasebnu zajedničku datoteku i uključili ako je potrebno, kako se ne bi stalno ponavljao u playbookovima. Ovdje se pojavljuje callback_ url, u kojem su zaštićeni ključ problema i ime hosta. Kada Ansible izvrši ovaj POST zahtjev, bot razumije da je došao kao dio tog i takvog incidenta.

A evo primjera iz playbooka u kojem smo izbacili disk iz MD uređaja:

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

Ovaj zadatak mijenja status Jira karte u "Spreman za promjenu" i dodaje komentar. Varijabla mdam_data također sadrži listu md uređaja sa kojih je disk uklonjen, a parted_info sadrži dump particije iz parted.

Kada inženjer ubaci novi disk, možemo koristiti ove varijable da vratimo dump particije, kao i da prebacimo disk u md uređaje sa kojih je uklonjen.

Ansible način provjere

Uključivanje automatizacije bilo je zastrašujuće. Stoga smo odlučili da pokrenemo sve playbooks u modu
suho trcanje, u kojem Ansible ne izvodi nikakve radnje na serverima, već ih samo emulira.

Takvo pokretanje se pokreće kroz poseban modul povratnog poziva, a rezultat izvršenja playbook-a se čuva u Jira kao komentar.

Prvo, omogućio je validaciju rada bota i playbooks-a. Drugo, povećalo je povjerenje administratora u bot.

Kada smo prošli provjeru valjanosti i shvatili da je moguće pokrenuti Ansible ne samo u suhom načinu rada, napravili smo dugme Pokreni Diskobot u Jira za pokretanje istog playbook-a sa istim varijablama na istom hostu, ali u normalnom načinu rada.

Takođe, dugme se koristi za ponovno pokretanje playbook-a ako se sruši.

Struktura priručnika

Već sam spomenuo da u zavisnosti od statusa Jira tiketa, bot pokreće različite playbookove.

Prvo, mnogo je lakše organizirati ulaz.
Drugo, u nekim slučajevima to je jednostavno neophodno.

Na primjer, prilikom zamjene sistemskog diska, prvo morate otići na sistem za implementaciju, kreirati zadatak, a nakon ispravnog postavljanja server će postati dostupan preko ssh-a i na njega možete roll-ovati aplikaciju. Ako bismo sve ovo uradili u jednom playbooku, onda Ansible to ne bi mogao izvršiti zbog nedostupnosti hosta.

Koristimo Ansible uloge za svaku grupu servera. Ovdje možete vidjeti kako su priručnik(i) organizirani u jednoj od njih.

Ovo je zgodno, jer je odmah jasno gdje se koji zadaci nalaze. U main.yml, koji je ulaz za Ansible ulogu, možemo jednostavno uključiti status tiketa ili opšte zadatke koji su neophodni za svakoga, na primjer, prolazak identifikacije ili dobijanje tokena.

istraga.yml

Pokrenuto za ulaznice u statusima Istraga i Otvoreno. Najvažnija stvar za ovu knjigu je naziv blok uređaja. Ove informacije nisu uvijek dostupne.

Da bismo ga dobili, analiziramo Jira sažetak, posljednju vrijednost iz Zabbix okidača. Može sadržavati naziv blok uređaja - sreća. I može sadržavati tačku montiranja - tada morate otići na server, analizirati i izračunati potreban disk. Također, okidač može poslati scsi adresu ili neke druge informacije. Ali dešava se i da nema tragova, pa morate analizirati.

Nakon što saznamo naziv blok uređaja, prikupljamo informacije o vrsti i veličini diska s njega kako bismo popunili polja u Jira. Također uklanjamo informacije o dobavljaču, modelu, firmveru, ID-u, SMART-u i lijepimo sve ovo u komentar u Jira tiketu. Administrator i inženjer više ne moraju tražiti ove podatke. 🙂

ready2change.yml

Izlaz iz rotacije, priprema za zamjenu. Najteža, odgovorna faza. Ovdje možete zaustaviti aplikaciju kada se ne može zaustaviti. Ili izvući disk kojem su nedostajale replike i time utjecati na korisnike, izgubiti neke podatke. Ovdje imamo najviše provjera i obavještenja u chatu.

U najjednostavnijem slučaju, govorimo o uklanjanju diska iz HW/MD RAID-a.

U složenijim situacijama (u našim skladišnim sistemima), kada se backup radi na nivou aplikacije, potrebno je preko API-ja otići do aplikacije, prijaviti izbacivanje diska, deaktivirati ga i pokrenuti restauraciju.

Sada masovno migriramo oblak, a ako je server zamućen, onda Diskobot pristupa cloud API-ju, kaže da će raditi sa ovim minijonom - serverom na kojem su kontejneri pokrenuti - i traži "migrira sve kontejnere iz ovog miniona". I istovremeno uključuje pozadinsko osvjetljenje diska, tako da inženjer može odmah vidjeti koji od njih treba izvući.

promijenjeno.yml

Nakon zamjene diska prvo provjeravamo njegovu dostupnost.

Inženjeri ne instaliraju uvijek nove diskove, pa smo dodali provjeru SMART vrijednosti sa kojima smo zadovoljni.

Koje atribute gledamoBroj preraspoređenih sektora (5) < 100
Broj trenutnog sektora na čekanju (107) == 0

Ako pogon ne prođe test, inženjeru se kaže da ga ponovo zamijeni. Ako je sve u redu, pozadinsko osvjetljenje se gasi, postavljaju se oznake i disk se stavlja u rotaciju.

ready.yml

Najjednostavniji slučaj: provjera sinhronizacije HW/SW raida ili završetak sinhronizacije podataka u aplikaciji.

API-ji za aplikacije

Nekoliko puta sam spomenuo da bot često pristupa API-ju aplikacije. Naravno, nisu sve aplikacije imale potrebne metode, pa su se morale doraditi. Evo najvažnijih metoda koje koristimo:

• status. Status klastera ili diska da se vidi da li je moguće raditi s njim;
• start/stop. Aktivacija-deaktivacija diska;
• Migrirajte/vratite. Migracija i oporavak podataka tokom i nakon zamjene.

Renderirano iskustvo od strane Ansiblea

Zaista volim Ansiblea. Ali često, kada pogledam različite projekte otvorenog koda i vidim kako ljudi pišu knjige, malo se uplašim. Složeno logično preplitanje kada/petlje, nedostatak fleksibilnosti i idempotencije zbog česte upotrebe shell/komande.

Odlučili smo da pojednostavimo sve što je više moguće, koristeći prednost Ansible-a - modularnost. Na najvišem nivou su playbooks, može ih napisati svaki administrator, programer treće strane koji zna ponešto o Ansibleu.

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

Ako je neku logiku teško implementirati u playbooks, premeštamo je u Ansible modul ili filter. Skripte se mogu pisati na Pythonu ili bilo kom drugom jeziku.

Lako se i brzo pišu. Na primjer, gore prikazani modul za osvjetljenje diska ima 265 linija.

Na donjem nivou je biblioteka. Za ovaj projekat smo napisali posebnu aplikaciju, svojevrsnu apstrakciju preko hardverskih i softverskih RAID-ova koji izvršavaju odgovarajuće zahtjeve.

Najveće prednosti Ansiblea su njegova jednostavnost i lako razumljivi priručnik. Mislim da ovo treba da koristite i da ne generišete strašne yaml fajlove i ogroman broj uslova, shell koda i petlji.

Ako želite ponoviti naše Ansible API iskustvo, imajte na umu dvije stvari:

• Playbook_executor i playbook općenito se ne može proslijediti timeout. Postoji vremensko ograničenje na ssh sesiji, ali ne i vremensko ograničenje na playbook-u. Ako pokušamo da isključimo disk koji više ne postoji u sistemu, playbook će raditi neograničeno, tako da smo morali da umotamo njegovo pokretanje u poseban omot i da ga ubijemo do isteka vremena.
• Ansible radi na bazi fork procesa, tako da njegov API nije siguran niti. Pokrećemo sve naše priručnike u jednoj niti.

Kao rezultat toga, uspjeli smo automatizirati zamjenu oko 80% diskova. Općenito, stopa zamjene se udvostručila. Danas administrator samo gleda incident i odlučuje da li da promeni disk ili ne, a onda napravi jedan klik.

Ali sada počinjemo da nailazimo na još jedan problem: neki novi administratori ne znaju kako promijeniti diskove. 🙂

izvor: www.habr.com