Gitlab Review Apps

Published in

UOL Devs

5 min readSep 7, 2018

TL;DR

GitLab Review Apps umožňují zakomponovat do standardní GitLab CI pipeline možnost deploye pro každou větev zvlášť doslova na kliknutí. Díky tomu může vzniknout tolik review verzí vyvíjené aplikace, kolik máte rozpracovaných větví.

To nevadí, že na tom ještě děláš, hoď to prosím na test, chtěl bych se na to už podívat,..

O co jde

Proč…

U některých projektů v UOL potřebujeme mít živou “live” verzi aplikace, kterou vyvíjíme, pro každou větev zvlášť. To nám umožňuje bavit se o právě vyvíjené feature ještě během vývoje před tím, než budou změny zintegrovány, např. i s kolegy, kteří “nevidí do kódu”, nebo mají na práci lepší věci, než trávit čas rozběháváním si projektu na “lokálu” jen aby se na něco podívali.

Review Apps bereme jako příjemnou součást CI pipeline. Neměla by být chápána jako náhrada test a stage verzí aplikace. Review apps je, co se týká stability, někde mezi lokální rozpracovanou verzí vývojáře a verzí na testu.

Local dev ➡️ Review apps ➡️ Testing ➡️ Staging ➡️ Production

Ve výsledku Review apps podporují princip Continuous Integration a umožňují, aby se na tvorbě software podílelo v počátečních fázích vývoje více členů týmu (např. grafici, PM, …).

Jak…

GitLab obsahuje podporu pro Review apps od verze 8.12 a netají se s tím, že ji okopíroval od Heroku. V jednoduchosti se jedná o funkci, která umožňuje dynamicky vytvářet CI environments svázané s konkrétní větví.

Simply put, a Review App is a mapping of a branch with an environment as there is a 1:1 relation between them.

CI pipeline typicky po předchozích fázích (CI stages) jako jsou např. automatické testy skončí s deployem Review apps environmentu.

Pro použití Review apps je třeba nastavit projekt a CI server (používáme server dedikovaný jen na Review apps). Variant a možností, jak Review apps nastavit a používat, je spousta. Níže je popsáno jedno možné řešení, které používáme my.

Malá case-study Review apps

Popsané řešení je v tuto chvíli používáno na projekty v Ruby on Rails, nicméně by mělo být jen s minimem úprav použitelné na jakýkoli webový projekt.

Nastavení CI serveru

Na serveru je v první řadě třeba nainstalovat Docker a Docker Compose, protože jednotlivé Review apps poběží v Dockeru. Další věcí je instalace a konfigurace GitLab Runner. GitLab Runner je potřeba nastavit na shell executor, protože runner bude na serveru spouštět Bash scripty; přidat runneru tag reviewapps a následně registrovat v GitLab. Tag je použit aby se runner specificky používal pouze pro úlohy Reviewapps (a neběželi na něm třeba testy).

Další věcí, kterou je potřeba vyřešit, je automatické nastavování webového serveru tak, aby podle větve z GitLabu posílal requesty do správného kontejneru. Jelikož se jedná o neveřejnou věc, je také potřeba řešit autentizaci; v našem případě jsme se spokojili s kombinací Basic auth a Let’s encrypt. S trochou konfigurace by nebyl problém tak nastavit například náš oblíbený Nginx. Pro Review apps jsme ale zvolili jiný web server: Traefik.

Traefik funguje tak, že naslouchá Docker events přímo na jeho unix socketu. Jakmile se v Dockeru nastartuje kontejner, který má labels specifické pro Traefik, nastaví podle nich routing requestů do daného kontejneru. Kontejner s aplikací a Traefik musí být ve stejné Docker network, která je externí, toho je docíleno jednoduchým: docker network create reverseproxy .

Na serveru tedy běží instance Traefiku (samozřejmě v Dockeru) s touto konfigurací:

Kromě sítě jsou v docker-compose.yml pro Traefik nastaveny cesty k Docker socketu, vlastnímu konfiguračnímu souboru a souboru acme.json , který je potřebný pro Let’s encrypt. Dále jsou nastaveny labely pro samotný Traefik (Traefik tak bude mít na portu 8080 přístupný informační dashboard).

Konfigurační soubor traefik.toml vypadá takto:

Traefik naslouchá na portech 80 a 443. Dotazy na HTTP se přesměrují na HTTPS ekvivalent. Na portu 8080 Traefik zpřístupňuje svůj dashboard s přehledem napojených kontejnerů a jejich vlastností. Dále je nastaven Basic auth s výčtem uživatelů a hesel oprávněných přistupovat k Review apps. Na konci je konfigurace Let’s encrypt.

Poslední věcí, kterou je potřeba na serveru nastavit, je spouštění kontejnerů z GitLab runneru. Pro tento účel používáme tyto Bash scripty, které v principu nakopírují projekt do připraveného adresáře a spustí nad ním docker-compose up nebo docker-compose down . Scripty mají jednoduché rozhraní, které se volá následujícím způsobem:

reviewapps up <name_of_my_project> <some_branch> <path_to_source>

reviewapps down <name_of_my_project> <some_branch>

Níže je ukázka části scriptu, který se volá při startování reviewapps:

Po provedení různých kontrol se vypne a smaže předchozí instance Review app (například, když se do stejné větve znovu pushne). Poté se Review app znovu načisto nastartuje pomocí dvou docker-compose.yml; jednoho, který je obecný (obsahuje instrukce k sestavení kontejnerů) a druhého, který je specifický pro Review apps (viz Nastavení projektu). Nakonec se kontroluje, jestli aplikace nastartuje a je přístupná. Pokud se to nepodaří (vyprší timeout), review_apps job se v GitLab zobrazí jako neúspěšný.

Kromě toho scripty například kontrolují dostatek paměti na serveru. V případě, že by na serveru nezbývalo dostatek paměti pro nastartování další Review app, script další Review app nevytvoří a napíše, ať nejdříve nějaké jiné Review apps vypnete.

Nastavení projektu

Jelikož se de facto jedná o plně automatizované nasazení aplikace, je nutné, aby pro to byl projekt přizpůsoben. V našem případě je projekt závislý na spoustě dalších služeb (Postgres, Redis, Sidekiq, …); z toho důvodu používáme Docker Compose. Konfigurace pro Review apps je v odděleném souboru:

Všechny kontejnery spolu komunikují sítí internal; pouze kontejner web (ve kterém je samotná Ruby on Rails aplikace) je připojen také na síť proxy, která je externí, tj. nespravuje ji docker compose, ale musí být vytvořená ještě před spuštěním compose (viz Nastavení CI serveru).

Další věcí jsou Docker labels, kterými se na jednotlivé kontejnery “navěsí” informace pro Traefik. Kontejnery, o které se Traefik nemá zajímat jsou označeny traefik.enable=false. U kontejneru web řekneme Traefiku, že se o něj má zajímat; nastavíme síť přes kterou má Traefik s kontejnerem komunikovat; nastavíme doménu, pod kterou má Traefik web zveřejnit.

Úplně posledním krokem je nastavení samotného GitLab CI, které spočívá v přidání dvou jobs. Jednoho pro nastartování, druhého pro vypnutí Review app:

Oba joby jsou otagovány jako reviewapps, díky čemuž jsou spouštěny na správném runneru. Oba joby jsou spouštěny manuálně (tlačítko v GitLab) a navzájem jsou propojeny díky review_apps.environment.on_stop: stop_review_apps a stop_review_apps.environment.action: stop .

Za povšimnutí také stojí proměnná $CI_COMMIT_REF_SLUG která je podobná jako $CI_COMMIT_REF_NAME ; místo názvu větve ale obsahuje název větve vhodný pro použití v URL: urbanekm/691-fix_the_bug ➡️ urbanekm-691-fix-the-bug . Díky tomu vypadá výsledná URL Review app pro mou větev takto:

https://urbanekm-691-fix-the-bug.fantozzi.reviewapps.uol.cz

(Poznámka: odkaz vám fungovat nebude, kromě Basic auth máme Review apps povolené jen z některých IP adres a navíc nám běží pod jinou doménou než jsem uvedl v článku :-)