.war deployment automatizálás

 ( sfeher | 2018. május 30., szerda - 10:57 )

Hello,

A feladat az lenne, hogy az alkalmazásomat több különböző környezetben futó Tomcat-re automatizáltan telepítsem. Egyelőre három ilyen ügyfelem van, de elébe mennék a dolgoknak, ha lehet.
Az O/S linux illetve Win2012 Server vegyesen. Kívülről nem tudok deploy-t indítani a szerverekre, mivel nem érem el őket. Jelenleg kézzel frissítem őket, de ezen jó lenne változtatni.
Jenkins barátunk tudna ilyet, de ott is meg kell tudnom adni a cél szerver adatait.
Valami pull módszer kellene, ami az ügyfél oldalról van elindítva vagy esetleg konténerbe csomagolni az egészet ?
(Az alatta lévő adatbázist érintő módosítások tovább fűszerezik a történetet.)
Mit javasoltok ?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Vagy docker vagy ansible.
Más filozófia, az Ansible-t talán könnyebb felfogni, docker rugalmasabb.

--
Gábriel Ákos

Esetleg az autoDeploy feature nem eleg a feladathoz?
____________________
echo crash > /dev/kmem

"Kívülről nem tudok deploy-t indítani a szerverekre, mivel nem érem el őket. Jelenleg kézzel frissítem őket, de ezen jó lenne változtatni."

Ez kicsit zavaros, kifejtenéd bővebben? :)

Alapvetően intraneten használják a cuccot, internet felől direktben nem érhető el. Szervereket, tűzfalat nem én felügyelem, de be tudok lépni pl. teamviewer-el vagy ssh-val vagy akármivel és kézzel megcsinálom a frissítést.

Ha ssh-val be tudsz lepni, akkor mehet az ansible is.
Amugy tobben javasoltak. Jenkins build docker image + szervereken futtatni a dockercompose-t amikor kell. Na ez az amikor kell a gond, mert valaminek triggerelnie kellene. Mondjuk ha kilatsz a netre belulrol, akkor futhat valami cronjob ami megnezi van e uj verzio. Vagy mittomen. :D

Mit javasoltok ?
Én vanilia-csoki-eper kombót.

Kulcsos scp-vel egy ütemezett task lerántja a war-t a szerveredről.
Lokálisan megnézi a scripted, hogy a hash-e eltér e a telepítettől, és ha igen, akkor beröffenti az újat.
Ha van már bash w2k12-re, akkor csak 1x kell megírnod.
Ha kicsit firnyákos vagy, a frissítő scriptet is is így frissítheted ;)

Na pont ezt a scriptelést oldja meg szépen az ansible.
(kivételkezelés, skálázás, státuszkezelés, felesleges másolások kiszűrése, stb.)

--
Gábriel Ákos

„Kívülről nem tudok deploy-t indítani a szerverekre, mivel nem érem el őket.”
Portforward meg ördögtől való nálunk.

https://docs.ansible.com/ansible/2.4/ansible-pull.html

De azt irta, hogy be tud rajuk lepni ssh-val. Szoval akkor megis elerhetoek ssh-val ami pont eleg az ansible-nek.

Na ja, de ha megnézed az időbélyegeket, ezt az infot már az én első hozzászólásom után írta.

Csak hogy világos legyen a kínom. A nem érem el a szervereket a következőt jelenti. A székemből ülve nem tudok tömegesen deployt indítani (http://x.x.x.x:8080/manager/text/deploy stb.) ezekre a gépekre. Nem arról van szó, hogy egyesével ne tudnék bejutni pl. vpn-en vagy ssh-n keresztül 25 lépésben, hanem arról, hogy az ügyfél oldaláról nézve ezt hogy lehet jól, kontrollált módon automatizálni. (Pl. scp-vel lehúzza egy script a .war-t és az autodeploy berántja csak félig jó, mivel semmilyen visszacsatolás nincs arról, hogy sikerült e a deploy vagy a tomcat éppen permgen hibával megállt.) A portforward-ot egy ideje ismerem, de nem cél hogy ezek a rendszerek kívülről elérhetőek legyenek.
Köszönöm az eddigi javaslatokat, átgondolom őket!

Amugy az ugyfelnel nincs uzemeltetes, ami meg tudna ezt csinalni?
____________________
echo crash > /dev/kmem

Van, csak az alkalmazást nem ők felügyelik.

Így értettem elsőre is.
Arra figyelj h a deploymentet és a monitoringot ne mosd össze, külön-külön egyszerűbben és szebben meg lehet oldani.
Monitoringra a zabbixot javaslom.
Deploymentre továbbra is jónak tűnik az ansible.
Az ansible playbook tud ellenőrzéseket is végezni (pláne ha felprogramozod) tehát egy deployról frankón kapsz visszajelzést.
Ansible semaphore pedig egy olyan webes felület amin kényelmesen el tudod indítani, nézegetni hogy melyik hol tart és milyen a státusza.
Ha időzítve csinálod, arról is marad history természetesen.
--
Gábriel Ákos

Jobb helyen az üf. dönt, hogy mikor van verzióváltás, és onnan indítják a folyamatot. A fejlesztő az üf. éles rendszereiben változást indítani nem igazán szokott, már ha értelmes és korrekten szabályozott környezetről van szó.

Amit én csinálnék, az üf. oldali eszköz, aminek az ikonjára ott valaki rábök, az lehúzza az általad elérhetővé tett aktuális war-t, integritását ellenőrzi(!), ha rendben találja, akkor szervert leállít, munkakönyvtárból a régit elmenti, munkakönyvtárat pucol, új wart kirak, szerver start, logot felmásol hozzád az adott üf.-hez dedikált könyvtárba. Lehet cifrázni a DB leállításával/snashot-olásával, hogy visszaállás ne legyen fájdalmas, de ez már csak a hab meg a körítés :-)

Van egy másik rendszerünk, ahol az ügyfél dönt az elérhető frissítés telepítéséről. Ott van integritás ellenőrzés meg feedback nekünk, hogy megvolt a verzióváltás + adatbázis frissítése stb.

SaltStack? Ha jól tudom már támogatja az SSH/SCP alapú transzportot is a klasszikus ZeroMQ mellett (már egy ideje nem foglalkoztam salt-tal). Így elvileg akár a jelenlegi környezet változtatása nélkül is meg lehet vele próbálkozni. Legrosszabb esetben használhatod masterless üzemmódban a salt miniont a klienseken, hogy automatizáld a WAR fájlok pl https-en való letöltését és telepítését.

Zavard össze a világot: mosolyogj hétfőn.

"Az alatta lévő adatbázist érintő módosítások tovább fűszerezik a történetet."
Erre való például a LiquiBase vagy a Flyway, és ezeknek a servlet támogatása.
Amint elindul a WAR, egy ServletContextListener elindítja a DB struktúra módosítását.
https://www.liquibase.org/
https://flywaydb.org/

Meg is őrülnék, ha kézzel kéne a DB struktúra változtatásokat telepíteni, azt nyilvántartani, hogy melyik környezeten mi van kint stb. Elvégzi ezt az automatika.

Ezekkel már nekiálltam ismerkedni régebben, de aztán nem tudtam elég időt szánni rá. Okosságok, azt láttam elsőre :).

Az mennyire elvárás, hogy az ügyfélnek legyen lehetősége követni, hogy mikor milyen verzió települt? Esetleg eleve ő tudja kezdeményezni a telepítést?

Ha elvárás, akkor érdemes lehet az ügyfél hálózatán üzemeltetni egy Jenkins-t, ami akár ütemezetten, akár az ügyfél kézi indítására kinéz a Te saját tárhelyedre (ahol akár egy artifactory vagy egyéb repository is futhat), és onnan lehúzza és felteszi az új verziót.
A telepítő job akár neten el is küldhetné neked a saját kimenetét, amiből láthatod ha valahol nem volt sikeres.

A Liquibase-re én is tennék egy plusz szavazatot.

sub