Fórum Root.cz
Hlavní témata => Server => Téma založeno: czechsys 05. 08. 2019, 15:38:39
-
Ahoj,
mam tu prvni pripad, kdy se na jednom serveru potkaji dve sluzby stejneho typu v apache2. Takze konfigurace je asi takto:
#/env/prod/group_vars/project1:
project_uid: "1"
#/env/prod/group_vars/project2:
project_uid: "2"
#/env/prod/hosts
[project1]
fqdn
[project2]
fqdn
Na "fqdn" jsou tedy vhosty projekt1 a projekt2. Kdyz zavolam:
ansible-playbook -i /env/prod/ -l project1 apache2.ymlplaybook se provede spravne. Kdyz ale zavolam
ansible-playbook -i /env/prod/ -l project2 apache2.ymlpromenne jsou stale z group_vars/project1.
Kde je chyba a jak to zmenit, aby to fungovalo samostatne i "sdilene"?
Diky.
-
vidim 2 veci:
1.) apache2.yml ma nadefinovany "hosts: group1"
2.) ujisti se, ze si nekde ty promenny spatne neprepisujes, "-i /env/prod" ti bere default "-i /env/prod/hosts" mozna tam mas jinej soubor jeste
nicmene snad tady najdes odpoved: https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable
-
Dival jsem se na to.
ad 1] je to role, je v ni nadefinovano:
project1.yml
- hosts: project1
project2.yml
- hosts: project2
Takze tady to nebude.
ad 2] Kdyz jsem zakomentoval project1 sekci v /env/prod/hosts, tak to chytlo parametry pro project2. Ty parametry jsou identicke...
Zatim me napada jedine reseni a to, proste presunout ty parametry z group_vars do samostatneho var souboru a ten includovat v tom playbooku...
Ale pockam, zda nekoho napadne, v cem mam chybu.
-
Nebyl by odkaz někam na git kde by se na to dalo kouknout jako na celek?
-
Role neni playbook. Playbook neni inventory.
apache2.yml je playbook a ne role (jasne zalezi co mas vevnitr), ale playbook mit musis v nem definujes na kterou grupu se pusti a z toho to bere promeny.
Jak jsem ti psal si myslim, ze mas nekde nadefinovano v playbooku:
hosts: group1
Neco jako tady: https://github.com/ansible/test-playbooks/blob/master/sleep.yml
kde je hosts: all
snad uz ti to dava smysl. Zmen si v apache2.yml
hosts na group2 a pujde ti to
chces dve sluzby?
v playbooku apache2.yml nadefinuj dve grupy
hosts: grup1
roles: apache2
hosts: grup2
roles: apache2
pak kdyz pustis
ansible-playbook -i myhosts -l grup1 apache2.yml
ansible-playbook -i myhosts -l grup2 apache2.yml
tak to udela to co chces. Prijde mi ze michas jablka s hruskama. Protoze to co ve skutecnosti chces jsou grupy pod playbookem, precti si tu inheritance/var precedense jeste jednou.
-
ETNyx a tripplezero, poslal jsem vam zpravu, kde najdete zdrojaky...
-
Ahoj Czechsys,
poslal jsem ti zpravu zpatky.
pro ostatni
-l project1 je ten problem
-l 'SUBSET', --limit 'SUBSET'
further limit selected hosts to an additional pattern
neboli v hosts:
[project1]
prod-anicka
dev-marenka
--limit prod-*
ale rozhodne ne
--limit project1 jelikoz ten mate definovanej v playbooku project1.yml
hosts: project1
...
..
Ze mi to nedoslo driv ^_^
-
Pomohlo to nebo na to mám taky hodit ještě očko?
-
Pomohlo to nebo na to mám taky hodit ještě očko?
Mam od tripplezero slibeno, ze mi jeste neco ukaze. Kazdopdane, nemyslim si, ze je tohle zrovna spatne nebot bezne pouzivam playbook takto:
project1.yml:
- hosts: project1-db
...
roles:
...
- hosts: project1-web
...
roles:
...
Tak kdybys na to hodil oko, budu rad, zatim jsem se z toho nedostal. Variantu s includovanim vars_file pro dany projekt jiz mam odzkousene, ale udela to pak trochu slozitejsi strukturu, kdyz vars budou jednou v inventory, jednou nekde jinde...
-
Trošku jsem se v tom pošťoural a jestli jsem to pochopil správně, tak moje odpověď bude podobná jako od kolegy tripplezero.
Kauzule limit nefunguje tak jak předpokládáte, pouze vytváří průnik existujících cílů (tj. strojů kde pustit tu magii)
Na daném příkladu
ansible-playbook -i /env/prod/ -l project1 apache2.yml
ansible-playbook -i /env/prod/ -l project2 apache2.yml
-l project1
-l project2vlastně říká všechno co je ve skupine projektX takže v obouch případech fqdn
takže stejnej výsledek dostanete pokud (při těchto jednoduchých skupinách) použijete
-l fqdn
pokud by například v project1 bylo fdqn2 eqivalent by byl
-l fdqn,fdqn2
Z toho by mělo být patrné že --limit neovlivňuje/nepracuje se skupinou a tedy tímto způsobem ji nemůžete definovat. (respektivě skupina pro --limit funguje jako zástupný znak za x-y strojů abych jich po čárce nemusel vypisovat 10-ky nebo 100-ky)
Moje řešení tohoto problému by bylo předělat project1 a 2 na role. Případně za současné konstelace proměné z "group_vars" presunout do "play var" (tj do /apache2.yml respektivě z toho co bylo v PM do v rootu /projekt1.yml)
Odobně mi přijde řešení v rolích lepší neb proměné v "play vars" uz težko budete přepisovat. Snad jsem to pochopil dobře a trošku rozumě předal dal :-)
-
Stale to kazdy vidime jinak (resp. nevidim to jak vy).
project1.yml:
---
- hosts: project1-db
become: yes
become_method: sudo
roles:
- { role: "common", tags: "common" }
- { role: "postgresql", tags: "postgresql" }
- { role: "pgbouncer", tags: "pgbouncer" }
- hosts: project1-web
become: yes
become_method: sudo
roles:
- { role: "common", tags: "common" }
- { role: "tmpfiles", tags: "tmpfiles" }
- { role: "nfs-client", tags: "nfs-client" }
- { role: "createuser", tags: "createuser" }
- { role: "nginx", tags: "nginx" }
- { role: "nginx-vhost", tags: "nginx-vhost" }
- { role: "php", tags: "php" }
- { role: "redis", tags: "redis" }
- { role: "postgresql-client", tags: "postgresql-client" }
env/prod/group_vars/project1:
project_uid="1"
/env/prod/hosts:
[project1:children]
project1-db
project1-web
[project1-db]
fqdn1
[project1-web]
fqdn2
Tohle spusti playbook s rolema pro cely projekt (takze -db a -web):
ansible-playbook -i /env/prod/ project1.yml
Tohle spusti playbook s rolema, ale limituju to na web servery (takze jen -web)
ansible-playbook -i /env/prod/ -l project1-web project1.ymlTakze vytvarim ten prunik stroju, kde spustit. V tom to funguje jak pisete oba.
Pokud teda pustim:
ansible-playbook -i /env/prod/ -l project1-web project1.ymlNacte to parametry z group_vars/project1 - proc? Protoze se to dostane az na uroven [project1:children] a z toho vezme ten group_vars/project1? Proc to pak nefunguje pro project2, kdyz by se to pak melo dostat na [project2:children] a z toho vzit group_vars/project2?
-
Popravdě jak vesměs cpu všechno přes role tak se mi nikdy nepodařilo do toho takhle zamotat ve skupinách :-D takže je to pro mě taky škola.
V podstatě jste si odpověděl, pokud je fdqn součástí dvou skupin tak samozřejmě pro fdqn musí existovat jen jeden project_uid takže na úrovni skupin ansible koukne do první skupiny a přepíše proměnou, koukne do druhý skupiny a přepíše proměnou. Poslední kam koukne vyhrává.
viz: https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable
Ještě když kouknu co říká dokumentace o hosts v playbooku (https://docs.ansible.com/ansible/latest/user_guide/playbooks_intro.html#basics a následně proklik na https://docs.ansible.com/ansible/latest/user_guide/intro_patterns.html).
Pokud si to vykládám správně tak hosts je vlastně obdobou kauzule --limit takže pokud play má hosts:projekt1 tak najde fdqn a o fdqn ví že je ve dvouch skupinách a jsme zase na začátku.
-
Je to mozne. Nakonec jsem to prozatim vyresil tak, ze group_vars jsem presunul do samostatneho var adresare a projektove parametry si pripojim pres vars_file.
Zajimal by me ten Vas role pristup. To delate tak, ze mate definovany server jako playbook a v nem si definujete role? Nebo jak?
-
Dělám to takto, v hosts souboru přiřazuji stroje do skupin a ty definují jaký aplikace na stroji mají běžet
#production/hosts
[xibo]
fdqnplaybook pak obsahuje jednotlivé play, které spouštějí role, zatím používám jeden playbook trošku se bojím, že bych několika playbooky snížil přehlednost a navíc mohl vytvořil stavy, kdy by jeden přepisoval co udělal druhej.
#site.yml
- hosts: xibo
roles:
- xibo
- hosts: wordpress
pre_tasks:
- import_tasks: roles/wordpress/tasks/pre.yml
roles:
- generic/apache
- generic/mariadb
- wordpress
post_tasks:
- import_tasks: roles/wordpress/tasks/post.yml
první příklad s xibo používá pro role dedičnosti, tedy sama role ví že si má použít jiné role (docker, databaze a webserver). V druhým příkladu wordpress s dědičností nepracuje takže musím potřebný role zavolat ručně.
Proměný mají definované role většinou nějaké defaultní, které se pak přepisují nejčastějí v rámci host_vars
#production/host_vars/fdqn
xibo_instances:
- xibo_server_name: admin.fdqn
xibo_path: /opt/xibo/
xibo_version: 2.0.4
xibo_web_port: 127.0.0.1:8080
xibo_xmr_port: 9505
- xibo_server_name: test.fdqn
xibo_path: /opt/xibo_test/
xibo_version: 2.1.0.rc1
xibo_web_port: 127.0.0.1:8081
xibo_xmr_port: 9506
Tady na fdqn mi role připraví dvě instance ty aplikace. Co se týká skupin tak u nich ještě používám group_vars/all.yml a pak skupiny "geolokační" který vesměs slouží k nastavení repozitářů.
Asi největší nevýhoda/výhoda tohodle systému je, že role který jsou "dole" třeba apache musí být dost univerzálně napsaný tak aby je bez problému mohli používat ostatní role. Například když jsem dělal apache tak jsem hodně okoukal a naučil se tady https://github.com/geerlingguy/ansible-role-apache
-
Od toho geerlingguy jsem uvazoval dost prevzit, resp. na galaxy jsem narazil, az kdyz jsem mel dost playbooku napsanych, tak uz jsem to tak nechal. Mam tam totiz nejake speciality, coz je duvod, proc jsem to nebral i z debops.
Takze pokud dobre chapu, delate i aplikacni skupiny napr.:
[wordpress]
fqdn1
fqdn2
To bych sice taky mohl, ale pak bych mel problem s nastavenim skupinovych parametru (napr. sjednoceny uid/gid na X serverech kvuli php/www) - psat to staticky do kazdyho host_vars/fqdn bych se zblaznil - zrovna treba i z vaseho prikladu ta "xibo_server_name", tu mam definovanou skupinove, ale pak staci jeden server bez te url v dane skupine a zase se mi to rozbije...Asi potrebuju nejakou dynamickou variantu inventory jiz...
-
Takze pokud dobre chapu, delate i aplikacni skupiny napr.:
dejme tomu :-) skupinou prostě říkám kde se má jaká "aplikace" nainstalovat nastvením stroje jí dám parametry dle role
napr. sjednoceny uid/gid na X serverech kvuli php/www
(tady se budu odkazovat na čísla z https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable)
proto je tu "přepis" proměných. Nevím jestli se trefím přesně do toho co hledáte ale, dejme tomu ten wodpress dědí z role apache takže jsem na 2. apache ma v roli defaults nastavený uid/guid na 33/33 a protože jsem na začátku tak můžu ve group_vars/wordpress na 44/44 jsem na 6. pokud se mi to u jednoho konkrétního stroje nelíbí tak v host_vars/fdqn (jsem na bodě 9.) nastavím 55/55.
Tedy pokud budu mít jinou aplikaci používající apache tak apache poběží na 33 všechny wordpresy na 44 a jeden jedinej stroj na 55.
s tím wordpressem by to asi šlo udělat v 2. protože první by se měla nastavit default role apache a pak to přepsat default role wodpressu a tím by to bylo pěkně v roli a ne nikde zatoulaný. Samozřejmě můžete přepisovat proměný v jakémkoliv bodě, pokud Vám to vyhovuje.
Bohužel tady zase bude potřeba dát pozor na přepisování v rámci jednoho bodu. Pokud bych ten wordpress měl řešenej první variantou v 6. a dejme tomu amíci zákonem zakázali 33/33 (nebo ja nevim,...) tak mám (já tomu říkám) "geografický" skupiny [czech] a [aws-west] tak bych to mohl nastavit group_vars/aws-west. Jenže teďka bych spadl do stejnýho průseru jako vy :-D ze který skupiny se ta proměná použije? Ty skupiny mam pro nastavení zrcadel je to zase přepis bodu 2. vs 6. v rámci jiný role.