Velká infrastrukturní revoluce v Ackee
Letošní rok jsme vyhlásili rokem kvality. I přes nemalé časové investice jsme se pokusili posunout námi používané technologie o velký kus dopředu, což v případě naší infrastruktury spíš než poklidný evoluční vývoj připomínalo krvavou revoluci. Náš backend už zkrátka nikdy nebude jako dřív… A to je dobře!
Continuous integration a continuous delivery k Ackee patří již nějaký ten pátek, avšak náš technologický stack se skládal z dost odlišných technologií. Začínali jsme na PHP, které se nasazovalo přes ssh pomocí ručně psaných Jenkins jobů. PHP jsme postupně vyměnili za Node.js, kterému nově používaná architektura mikroslužeb sedí mnohem lépe. Před #rokkvality se všechny backendy nasazovaly na jeden testovací a jeden produkční virtuální server.
Na konci roku 2015 jsme místo monolitického serveru začali využívat platformy IBM Bluemix. Ta pomocí prostředí Cloud Foundry představuje poměrně komfortní nástroj, kde si mohou programátoři za použití manifest souborů a buildpacků nastavovat parametry a výkonnostní požadavky jednotlivých aplikací. Avšak znamenalo to mírné roztříštění, kdy bylo nutné zdrojové kódy nahrávat jak do našeho gitu (např. kvůli testům), tak poté pomocí nástroje cf na IBM Bluemix. K větší integraci s Jenkinsem nikdy nedošlo, protože jsme narazili na limity tohoto řešení.
To spočívalo především v omezení Cloud Foundry na čistě aplikační framework. Jsou sice k dispozici logy, avšak aplikace působí pro programátora (a především správce) jako blackbox. Případné řešení problému (především na produkci) se redukovalo na funguje / nefunguje, nevíme proč.
Rozhodli jsme se tedy místo Cloud Foundry přejít na technologii virtualizace pomocí kontejnerů, konkrétně Docker. Docker nabízí mnohem univerzálnější přístup, kdy je možné pomocí Dockerfiles definovat prostředí virtuálního OS, ve kterém aplikace běží, ale především využívat (dědit) prostředí, již vytvořená komunitou. Jelikož se jedná o řešení postavené nad OS Linux, existuje nespočet oficiálních Docker kontejnerů např. pro databázové stroje. S těmito kontejnery je možné plnohodnotně pracovat jako s jakýmkoliv OS – je možné se za běhu připojit, instalovat další balíky, ladící nástroje atd.
Zde jsme ale narazili na limity IBM Bluemix, jelikož platforma postrádá jakýkoliv rozumný nástroj na orchestraci kontejnerů. Z orchestračních nástrojů jsme zvolili nástroj Kubernetes, který je jak opensource (umožňuje nasazení na vlastním železe, kdyby to bylo nutné), tak je dokonale integrován v Google Compute Engine. A právě kombinaci Kubernetes + GCE jsme zvolili. Další podstatnou výhodou je pricing, kde se u IBM Bluemix platí za jednotlivé kontejnery, což značně demotivuje od důsledné separace aplikací jako samostatné microservices. Naopak v případě GCE se platí za železo clusteru, tj. kolik kontejnerů si uživatel vytvoří, je jen na něm (dokud na to stačí systémové prostředky).
Kubernetes se nám podařilo prointegrovat s Jenkinsem, nasazení aplikací probíhá tedy opět jednotně přes náš git. Místo klasických deploy jobů jsme přešli na novější Jenkinsfiles, které je možné udržovat a verzovat taktéž v gitu. Git se stal tedy opět hlavním nástrojem, odkud je řízeno kam (máme několik clusterů) a s jakými prostředky se daná aplikace nahraje. Veškerou konfiguraci si provádí programátoři pomocí jednoho Jenkinsfile, jednoho Dockerfile a jednoho Kubernetes deployment souboru.
Nyní naše infrastruktura poskytuje jak levné prostředí pro vývoj v době microservices, tak robustní nástroj pro produkční nasazení a správu těch nejnáročnějších aplikací.
