Globalni WP Hosting – Ansible
Uz na Anycastu pouzivam pro hromadnou spravu Anycast nodu Ansible, takze volba je tady zatim jasna … proc volit neco jinyho kdyz tohle dobre funguje 🙂
Ansible je nastroj ktery umoznuje hromadnou spravu serveru. V nastaveni si definujeme sady serveru (Webservery, DB Servery, ….) a nasledne na tyto sady muzeme posilat jednotlive prikazy, kdy se Ansible postara o spusteni na vsech konkretnich serverech, nebo muzeme vyuzit tkzv. playbooky ve kterych je sestavena cela sada prikazu pro konfiguraci danych serveru. V praxi pak muzeme pripojit novy server, pustime nad nim instalacni ulohu a nemusime se o nic starat – po skonceni ukolu bude server ve stejnem stavu jako vsechny ostatni v dane skupine. Pokud se rozhodneme upravit nejakou konfiguraci, neni nic jednodussiho nez si upravit playbook a pustit Ansible, ktery se postara o to, ze vsechny servery se zaktualizuji podle aktualniho playbooku.
Instalace
Nejsem zastancem rucnich instalaci ze zdrojovych kodu, pokud to opravdu dana situace nevyzaduje, a protoze mam rad Debian, pouzivam tedy balickovaci system APT. Debian je bohuzel ovsem relativne striktni ohledne toho, jakou verzi pusti do produkcni stable vetve, a proto ne vzdy jeho aktualni verze software odpovida realne aktualni verzi – za to ovsem by mela byt vyrazne stabilnejsi a bezpecnejsi. Nicmene, APT umoznuje pridavat ruzne repozitare, takze neni problem si novejsi verzi obstarat a protoze Debian 10.5 obsahuje Ansible aktualne ve verzi 2.7.x, sahnu po repozitarich z Ubuntu Bionic a nainstaluju verzi 2.9.x
echo "deb http://ppa.launchpad.net/ansible/ansible/ubuntu bionic main" | tee -a /etc/apt/sources.list apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367 apt update apt install ansible -y
Pro spravnou funkcnost na jednotlivych serverech ktere budeme ovladat je potreba na ne nakopirovat SSH klic. Jednou moznosti je nakopirovat klic z tohoto manage serveru, ale po mych minulych zkusenostech je to relativne cesta do pekla. Z toho duvodu nakonec pouzivam svuj osobni klic a na manage server se pripojuji s podporou SSH Agenta, ktery mi klic forwarduje pri pripojovani na jednotlivy servery. Tim docilim funkcnosti Ansible aniz bych ohrozil existenci serveru nekdy v budoucnu, pokud by melo dojit k nejakemu utoku na manage server. Samozrejme to ma (pro me, protoze jsem to vic nestudoval) tu nevyhodu, ze nemuzu Ansible nejak vic automatizovat, a budu jej muset poustet rucne – na druhou stranu me zatim neprijde ani moc bezpecny poustet automatizovane operace na serverech bez toho abych kontroloval nejen co dela, ale jak to i dopadlo.
Konfigurace
V souboru /etc/ansible/hosts si vydefinuju skupinu „geo“ a do ni hodim nase jednotlive geoservery. Ja osobne pouziju jen jejich servername, misto celych hostname, protoze to mam definovane v /etc/hosts a je to pro me jednodussi se nevazat na domenu (i pro ucely clanku):
[geo] au1 de1 fr1 jp1 sg1 us1
Test
Jednoduchym testem zjistime, ze nam Ansible funguje.
root@manage:/etc/ansible# ansible -m ping all de1 | SUCCESS => { "changed": false, "ping": "pong" } fr1 | SUCCESS => { "changed": false, "ping": "pong" } sg1 | SUCCESS => { "changed": false, "ping": "pong" } us1 | SUCCESS => { "changed": false, "ping": "pong" } jp1 | SUCCESS => { "changed": false, "ping": "pong" } au1 | SUCCESS => { "changed": false, "ping": "pong" }
Prvni playbook – Aktualizace APT a systemu
Prvni playbook co si pripravim bude aktualizace apt repositaru (apt-get update) a aktualizace systemu (apt-get upgrade) at mame vsechny servery ve stejnem vychozim stavu.
Konfigurace playbooku muze byt ve formatu JSON nebo YAML. Pro lepsi citelnost a rucni spravu pouzivam YAML.
Nejprve vydefinujeme servery pro ktery se dany prikazy tykaji – v nasem pripade „geo“
Nasledne vydefinujem ulohy, ktere se maji provest – v nasem pripade prvni je update APT a druhy je upgrade systemu.
Konfigurace by mela vypadat takto:
- hosts: geo tasks: - name: Update apt-get repo and cache apt: update_cache=yes force_apt_get=yes cache_valid_time=3600 - name: Upgrade all apt packages apt: upgrade=dist force_apt_get=yes
Soubor jsem pojmenoval global.yaml a nechal ho v /etc/ansible
A spustil:
ansible-playbook global.yaml
Po spusteni me vyjel report jak Ansible provadi jednotlive kroky a jejich vysledek:
Ansible si sam doinstaloval pozadovany balicek python-apt a nasledne provedl potrebne ukoly. Jak jsou videt zlute „changed“, na techto serverech dana operace neco provedla – konkretne zde doslo k aktualizaci balicku na posledni verze v ramci distribuce. Pokud prikaz pustim ihned znovu, nemela by se uz zadna zmena stat, a proto vypis vypada takto:
Tim padem mam pripraveny zaklad pro hromadnou spravu jednotlivych serveru a pri dalsim pokracovani se uz nebudu muset na kazdy server prihlasovat samostatne a opakovat neustale stejne ukony.
Pingback:Globalni WP Hosting – Docker – Franta – Občasník malého ajťáka