Ansible container setup

Linux-haladó

Van egy proxmox, ansible.

Ansible playbook-kal tudok konténert csinálni, oké.
Tudok megadott konténerbe mondjuk apache-ot installálni, oké.

Az lenne a feladat hogy csináljon egy új konténert majd ebbe az új konténerbe dobja bele az apache-ot.

Ezt egyelőre nem látom át, tudna valaki segíteni?

( Zsugabubus | 2017. 11. 07., k – 15:21 )


Ansible playbook-kal tudok konténert csinálni, oké.
Tudok megadott konténerbe mondjuk apache-ot installálni, oké.

Futtasd egymás után őket :)
Ha az új konténer kéne a proxmoxtól, használj proxmox dynamic inventoryt.

Tehát:

- megcsinálom az új konténert
- majd berakok egy listenert ami elkap egy eventet hogy a konténer már meg van csinálva
- aztán rámegyek a konténerre

Más:

- a dynamic inventory-ból megkapom az összes gépet, szuper.
Mondjuk naming convention alapján szedem szét őket role-okra?
Tehát mondjuk web1...web9 a webserver, app1...app9 az alkalmazás, db1...db9 az adatbázis?
Erre van valami okosabb megoldás?

Vagy ennyire nem érdemes túlszofisztikálni?

--
Gábriel Ákos

" általában rolet a legegyszerűbb egy groupra rátenni (hosts: group_name a playbookban)"

ezt nem értem.
a playbookban ez a sor azt adja meg szerintem, hogy az alatta levő taskokat melyik role-al rendelkező hostok hajtsák végre.
a hostokat groupokba az inventory file-ban rendeled.

vagy arra gondolsz hogy web* -ot írok be a playbookba és úgy is hívom a gépet?
de akkor az a baj h egy géphez csak egy role (és az all) rendelhető.

--
Gábriel Ákos

( sj | 2017. 11. 07., k – 18:38 )

miert nem Dockerfile-lal oldod meg?

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Nem nagyon ismerem a dockert, de eddigi ismereteim alapján az inkább development környezetekhez alkalmas.
Nem is látom benne azt a kód-újrahasznosítást mint az ansible-ban.

Ja és meglevő gépeket ansible -vel be lehet húzni automatizálás alá, a dockerizálás az komplett újrahúzást is jelent.
--
Gábriel Ákos

valoban jo development kornyezethez is, de azert elesben is hasznaljak, ld. a felettem levo kommentet is.

Nem is látom benne azt a kód-újrahasznosítást mint az ansible-ban.

ez nem csoda, mert a dockerfile nem kod (meg ha tehetsz bele shell magick-et is), inkabb egy leiro, hogy a docker hogyan rakja ossze az image-et. A komplett ujrahuzas, felteve, hogy valoban kb. a 0-rol tortenik, sem kene, hogy showstopper legyen...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

( Rt711 v | 2017. 11. 07., k – 21:40 )

Lehet félreértem, de az Ansible arra kell hogy a konténerekbe felepakolj cuccokat miután online vannak? Az úgy nem oké.
Ha már egyszer elindult a konténer akkor oda file-t nem teszünk, hiszen ha újraindul akkor az már nem lesz ott.

Ha konténerezni akarsz akkor a következők kellenek:
Terv (application architecture diagram)
Cluster (Docker Swarm/Kubernetes), olvasd el a doksikat aztán döntsd el hogy melyik kell.
Megépíted a konténer image-t Dockerfile-val, majd push a registrybe. Ez természetesen host-role alapon működik, mindegyikből csinálsz egyet.
Cluster policy: X gépen ez és ez fusson (affinity-vel), Y gépen meg amaz.

-

Kicsivel lejjebb 9 apache és ugyanannyi DB server van említve, itt azért már el kell gondolkodni azon hogy ezek az erőforrások hogyan lesznek megfelelően kezelve (nyilván nem 100 vagy 1000 host, de elméletileg lehetne).
Lehet jó lenne a compose, de ha kiveszünk egy hostot aztán meg hozzáadunk mondjuk ötöt (mondjuk templateből, meg mert épp olyanunk van) akkor kicsit kacifántosabb rendezni a helyzetet.

Kubernetest azért javasoltam mert van szép dashboardja és ez segíthet megérteni a dolgokat (vagy épp összekuszálni).
Docker Swarm-ot meg azért mert konkrétan 2 parancs kiadásával indulásra kész, aztán már csak a hálózattal kell "hülyéskedni", hogy az jó is legyen.

Bár igaz hogy az eredeti felvetésben nem volt szó monitoringról, de azért javallott elgondolkodni azon hogy ez milyen megoldással lesz összehozva. Nyilván annak is valamiféle konténerben kellene futnia ha már minden ott van.

-

eegen és itt jön a dolog financiális/infra adottságok oldala.
lehetne ugyanezt a feladatot kubernetes-sel megoldani, de akkor két utat látok:

- beteszünk mindent a google-ba és fizetünk mint a köles
- veszünk plusz hardvert, felépítjük azon a saját kubernetes infránkat és futtatunk ott

ezért maradtunk a proxmox lxc konténereknél és az ansible-nél
a monitoring is egy szép, megoldandó feladat, zabbix-szal szerintem meg fogom tudni csinálni

--
Gábriel Ákos

Nem, semmi ilyen nincs benne. Ugy tunt, hogy a kerdezo nincs eppen a topon a temaban, javasoltam neki, hogy viszonylag kevesebb tudassal mivel tudna elorebb lepni.

Ha mar kerdesek, ha valamire kivancsi vagy, felteheted a kerdesed mindenfele negativ fennhang nelkul is. Ha eleve megkerdojelezed mas tanacsat ugy hogy tudnal a hattererol, akkor szinten negativ hangnemben fog folyni a tovabbi kommunikacio. Meg amugy is, minek kell az ilyen?

Ha így kezdődik egy kérdés:

Van egy proxmox, ansible.

És erre valaki bevág egy teljesen más dolgot, semmi konkrét javaslattal, hogy ez hogyan is oldaná meg a problémáját, akkor csak azt feltételeztem, hogy write-only módban van. Kevesebb tudással Kubernetest telepíteni, majd teljesen átalakítani az eddigi rendszerét, azt azért megnézném. És itt ugye a hol tárolja a DB a fájljait is erős megfontolást igényel.
Mintha valaki kérdezne a síelésről, erre a válasz az lenne, hogy a snowboardot javaslom.

( akoscomp | 2017. 11. 07., k – 21:53 )

Ez engem is nagyon érdekelne. Ha sikerül összehozni kitehetnél a playbookokat.
Még nem jutottam oda, hogy elkezdjem a munkát, de pár hónapon belül ansible-el meg kellene oldjam LXD konténerek telepítését és telepítés után a belső szolgáltatások menedzsmentjét.
Ez kb ugyanaz amit te is csinálsz, csak te lxc konténerekkel dolgozol.

Sajnos ez így senkinek sem működik szerintem, mivel létrejön egy sima konténer, amiben semmi nincs beállítva.
Az ansible a szokásos módon próbál a konténerbe belépni (ssh), de ahhoz kellene hálózat és publikus kulcs.

Tehát valahogy úgy kellene telepíteni a konténert, hogy ez a két alapdolog be legyen rajta állítva.

Ezt a config paraméterrel valahogy meg lehet csinálni, de még nem jutottam el odáig, hogy rájöjjek, hogy.

Valahogy a témanyitónak is így kell eljárnia.
Ha tudsz konténert csinálni, akkor úgy kell megcsináld, hogy legyen benne hálózat és publikus kulcs, és utána beletehetsz akármit.

Valahogy így képzelem el:

# An example for creating a Ubuntu container and install apache2
- hosts: valami
tasks:
- name: Create a started container
lxc_container:
name: mycontainer
state: started
template: ubuntu
template_options: --release xenial
container_config:

- name: check apache2 is installed in container
delegate_to: mycontainer
raw: dpkg -s apache2
register: apache2_install_check
failed_when: apache2_install_check.rc not in [0, 1]
changed_when: false

- name: install apache2 in container
delegate_to: mycontainer
raw: apt-get install -y apache2
when: apache2_install_check.rc == 1

Összevágtam az LXD és LXC ansible fájlokat, pár elírás benne maradhatott.

"Sajnos ez így senkinek sem működik szerintem, mivel létrejön egy sima konténer, amiben semmi nincs beállítva."

Ez nem probléma, mert ennyire alap dolgokat bele tudok varrni a telepítő targizibe.
(ansible, ssh csomag install, ssh kulcsok telepítése)

Akár úgy is bele lehet hákolni, hogy a konténer indító scriptjébe belerakod a 2-3 megfelelő shell parancsot - amit a proxmox az új konténer indításakor futtat.

--
Gábriel Ákos

Ez már meg is van: https://gist.github.com/gabrielke/e675138ed71510cfce31ab3768fb1ae5
Egyetlen "híja" van a történetnek, de ez ansible sajátosság, a konténer létrejötte után az első alkalommal be kell gyűjteni az új konténer publikus kulcsát az ansible host számára. Ezt is körbe lehetne varrni scripttel vagy ki lehet kapcsolni a host_key_check -et ansible oldalon, de most inkább haladok tovább.

--
Gábriel Ákos

Szerintem a delegate_to kell neked. 


- hosts: foo
  gather_facts: no
  tasks:
    - name: create container
      delegate_to: hostb
      lxd_container:
        name: '{{inventory_hostname}}'
        state: started
        source: ...

A hostb a remote LXD/LXC host.
A foo a kontener, amit letrehozol.

Azaz definialod foo host-ot, a delegate_to-val a hostb-n futtatod addig a parancsokat, amig nem tudsz mar foo-ra is csatlakozni es utana mar azon futtatod.

Innen szedve:

https://github.com/ansible/ansible-modules-extras/issues/3660

Ha LXD-d lenne, lenne alternativa is, de az LXD remote lehetosege szerintem igy eleg nagy kalap szar a legtobb esetben.