Sziasztok!
Elértük azt a kritikus ügyfélszámot, aminél már az alkalmazásunk új verzióinak egyesével történő telepítése az ügyfeleknél meghaladja a kapacitásunkat.
Létezik erre valami eszköz, amivel egy központi helyről elindítható a telepítési folyamat, deployálja az EAR-t a GlassFish alkalmazásszerverre, megfuttatja az SQL scripteket ami az adatbázis struktúrát frissíti, stb.?
- 261 megtekintés
Hozzászólások
Elmeletileg minden alkalmazaszervernek van cli es/vagy scripting interface-e. En nagyreszt Websphere es Wildfly telepiteseket automatizaltam Python/Jython-al. SQL scriptre Flyway a jo megoldas.
- A hozzászóláshoz be kell jelentkezni
Adatbázis oldalra szerintem is jó megoldás lehet flyway, rögtön hozzátéve, hogy a rollback plan (rollback scriptek megléte, amennyiben lehetséges) és a deploy előtti backup szerintem az automatizálás egyik feltétele. Alkalmazás oldalról a monitoring megléte szintén egy ilyen alapfeltétel.
Ha eszközt kellene mondanom, akkor ansible-t is eltudnák képzelni, megfelelő playbook-kal glassfish, weblogic kezelhető.
- A hozzászóláshoz be kell jelentkezni
Define központi hely. Meg define Glassfish. Van cluster például? Van DAS? A "deploy" az csak egy deploy vagy van egy csomó kézi módosítás még hozzá?
Amúgy megy Puppet, Ansible, Terraform, etc. Megírod a receptet, hogy mit kell csinálni és az összes gép végrehajtja. Mondjuk egy több éves barnamezős dolognál több heti szopás átállni, de ha vannak még új telepítések, akkor legalább azokra legyen valami automatizmus.
Ezen túl meg jöhetnek a konténerek és a többi buzzword is.
- A hozzászóláshoz be kell jelentkezni
Ansible inkább mint puppet :)
docker központi registry, containerek, flyway a kulcsszó amiből indulnék.
De nagyon nem egyszerű téma és fejlesztői oldalon is komoly fegyelmet kíván.
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
Ansible inkább mint puppet :)
Nekem pölö a Puppet jobban bejött, de kinek mi tetszik.
- A hozzászóláshoz be kell jelentkezni
A legnehezebb nem a telepites, hanem a kornyezetfuggo konfiguraciok(adatbazis, service url-ek, stb..). Ezt egyszerusiti a contenerizacio, de ott is vannak kornyezetfuggo parameterek konfiguraciok, csak kevesebb. De egyebkent a vegtelensegig el lehet bonyolitani, az a kerdes megeri-e.
- A hozzászóláshoz be kell jelentkezni
Két alapvető megközelítést alkalmazhatsz, a push és a pull módszert.
A push esetében Te kezdeményezed a "központból" a kliensek felé, hogy legyen frissítés. Ha sok az ügyfél, akkor ezzel sok a szívás, a három leginkább alapvető az, hogy:
0) a logikai probléma - az ügyfél nem akarja, hogy az alkalmazás frissítve lgyen
1) a statikus probléma - hálózatilag nem elérhető az ügyfél (minden cégnél külön a NAT-oló tűzfaluk mögötti cuccot elérni, brrrr... - ahol ilyet csináltunk, ott külön gárda volt kijárni a ~7000 ügyfélhez...)
2) a dinamikus probléma - az ügyfél épp kikapcsolta azt, ami nem elérhető.
Ezeket mindet lehet kezelni, az esetek 90+%-ában elsősorban nem informatikai, hanem menedzsment eszközökkel. Ha ebbe az irányba mentek, akkor készüljetek, hogy nem lesz tool, ami megoldja a problémákat, emberek lesznek, akik megoldják a problémákat.
A pull esetében az ügyfélnél futtatott szoftver kezdeményezi a frissítést, vagy automatikusan, vagy amikor az ügyfél rákattint a frissítés gombra. Ez a menőbb módszer, kevesebb problémával, egyet emelnék ki: az ügyfélet tájékoztatni kell, hogy a szoftvered "haza fog telefonálni".
Ha mindenképpen toolt keresel, akkor a Capistrano, amit nézz meg (esetleg az Ansistrano is lehet jó, de ezzel konkrétan elég meh... tapasztalatokat sikerült szerezni.)
- A hozzászóláshoz be kell jelentkezni