Docker Compose élesben: mire figyelj?
A fejlesztői közösségben az elmúlt években azt már sokan elfogadták, hogy a Docker és a konténerek nem csak fejlesztésre, hanem éles üzemeltetésre is alkalmas eszközök.
A Dockert és a Docker-compose-t sokan használják microservice rendszerek fejlesztésére, hisz gyorsan összehuzalozhatók vele a különféle előrecsomagolt, akár Docker Hubról összeollózott szolgáltatások. De mi a teendő, ha a compose-t élesben akarjuk használni? Ha több környezetünk is van (developer, QA, UAT, production)? Hogyan kezeljük a környezetek közötti különbségeket, beleértve a különféle konfigurációkat, titkos kulcsokat, volume-okat? Hogyan érjük el, hogy a rendszerünk a lehető legkisebb leállással frissíthető legyen, figyelembe véve a startup és shutdown dependenciákat is? Hogyan tudunk különféle logging drivereket használni, logokat rotálni? Hogyan monitorozzuk a konténereket? Mi a helyzet, ha egy konténerünk leáll az éjszaka közepén? Hogyan érjük el, hogy egy túlszaladt konténer ne rántsa magával az egész szervert?
Machine recruiting: nem biztos, hogy szeretni fogod
Az AI visszafordíthatatlanul beépült a toborzás folyamatába.
|
Machine recruiting: nem biztos, hogy szeretni fogod
Az AI visszafordíthatatlanul beépült a toborzás folyamatába.
Gémes Tamás, a FintechX CTO-ja a HWSW free! meetup-sorozat 2021. március 30-i, dockeres állomásán elhangzott és alább megtekinthető előadásában bemutatta, hogy nem szükséges mindjárt orkesztrációs technológiában gondolkodni élesen sem (pl. Kubernetes, Swarm). A Docker Compose egy középutas megoldásként rengeteg olyan eszközt ad a kezünkbe, amellyel infrastructure-as-code filozófia mentén egy közepesen bonyolult rendszert a Kubernetes komplexitás magunkra vétele nélkül is üzemeltethetünk. Állítom mindezt úgy, hogy startupunkban mind Kubernetest, mind Docker Ccompose-t használunk éles környezetek üzemeltetésére több éve.
Docker Compose élesben: mire figyelj? - Gémes Tamás (Aggreg8.io)
Még több videó
A Dockert és a Docker-compose-t sokan használják microservice rendszerek fejlesztésére, hisz gyorsan összehuzalozhatók vele a különféle előrecsomagolt, akár Docker Hubról összeollózott szolgáltatások. De mi a teendő, ha a compose-t élesben akarjuk használni? Ha több környezetünk is van (developer, QA, UAT, production)? Hogyan kezeljük a környezetek közötti különbségeket, beleértve a különféle konfigurációkat, titkos kulcsokat, volume-okat? Hogyan érjük el, hogy a rendszerünk a lehető legkisebb leállással frissíthető legyen, figyelembe véve a startup és shutdown dependenciákat is? Hogyan tudunk különféle logging drivereket használni, logokat rotálni? Hogyan monitorozzuk a konténereket? Mi a helyzet, ha egy konténerünk leáll az éjszaka közepén? Hogyan érjük el, hogy egy túlszaladt konténer ne rántsa magával az egész szervert?
Machine recruiting: nem biztos, hogy szeretni fogod
Az AI visszafordíthatatlanul beépült a toborzás folyamatába.Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.
Gémes Tamás, a FintechX CTO-ja a HWSW free! meetup-sorozat 2021. március 30-i, dockeres állomásán elhangzott és alább megtekinthető előadásában bemutatta, hogy nem szükséges mindjárt orkesztrációs technológiában gondolkodni élesen sem (pl. Kubernetes, Swarm). A Docker Compose egy középutas megoldásként rengeteg olyan eszközt ad a kezünkbe, amellyel infrastructure-as-code filozófia mentén egy közepesen bonyolult rendszert a Kubernetes komplexitás magunkra vétele nélkül is üzemeltethetünk. Állítom mindezt úgy, hogy startupunkban mind Kubernetest, mind Docker Ccompose-t használunk éles környezetek üzemeltetésére több éve.
Docker Compose élesben: mire figyelj? - Gémes Tamás (Aggreg8.io)
Még több videó