Po více než 20 letech v IT už vás málo co překvapí. Zrovna tak vás nepřekvapí, když někam přijdete a vidíte, že mají hromadu služeb zastaralou, neudržovanou, bez dokumentace, původní team, co se o něco staral, dávno odešel a „stále to nějak udržují při životě“.
Tento článek by vám proto mohl pomoci s tím, že když už nějaký starý gitlab v Dockeru máte, tak jak to snadno upgradovat na nejnovější verzi, jak zjistit na jaké verze máte přeskakovat, abyste nepřekročili žádný kritický upgrade a jak to zkrátka udělat tak, aby se to nezměnilo v debugovací peklo následující odpoledne?
Musí to jít přes několik meziverzí a má to jasný postup!
Většinu Juniorů obvykle napadne, že prostě přepíšou verzi kontejner image na nejnovější a „ono to nějak dopadne“. Nedopadne, Gitlab vám v takovém případě často už nenaběhne a dopadne to tak, že budete v logu procházet hlášky, že máte moc nový gitlab a že musíte projít nějakou starší verzí, než se dostanete na nejnovější verzi.
Naštěstí tu existuje tento web, ve kterém si nalevo nakliknete, jestli upgradujete community edition, nebo enterprise, jestli to je instalované balíčkem, nebo dockerem, jaká je stávající verze a jaká je cílová verze.
No a výsledek stojí za to, dole už vidíme jakými verzemi musíte projít. Jenže to není vše, u každém upgradu musíte provést nejen zálohu, ale dát gitlabu třeba 20 – 30 minut času, než proběhnou všechny tzv. Background migrations. Až všechny doběhnou, můžete pokračovat na další verze. Nedá se verze přeskakovat, musíte jednu po druhé a ano, bude to trvat. V některých firmách „skáčou“ jednu verzi za večer. Někde mohou skákat 1 verzi týdně, aby dostali prostor všichni otestovat, jestli něco někde nepřestalo fungovat (a většinou po upgradu vše jede, jak má). Jinde si vezmou víkendovou směnu a proskáčou za víkend všemi verzemi až na tu nejnovější.
Náš příklad – v16.9.1 -> 18.10.3-ce.0
Web zobrazil tento postup:
docker run gitlab/gitlab-ce:16.11.10-ce.0
docker run gitlab/gitlab-ce:17.1.8-ce.0
docker run gitlab/gitlab-ce:17.3.7-ce.0
docker run gitlab/gitlab-ce:17.5.5-ce.0
docker run gitlab/gitlab-ce:17.8.7-ce.0
docker run gitlab/gitlab-ce:17.11.7-ce.0
docker run gitlab/gitlab-ce:18.2.8-ce.0
docker run gitlab/gitlab-ce:18.5.5-ce.0
docker run gitlab/gitlab-ce:18.8.9-ce.0
docker run gitlab/gitlab-ce:18.10.3-ce.0
V podstatě vám stačí, podívat se na váš docker-compose.yaml soubor a upravit tam:
services:
web:
image: ‚gitlab/gitlab-ce:16.11.10-ce.0‚
restart: always
A potom si vytvořte soubor upgrade.sh a do jeho obsahu vložte:
docker exec -t gitlab-ce gitlab-backup create
docker image prune -a -f
docker compose pull
docker compose up
docker logs -f gitlab-cechmod 755 ./upgrade.sh && ./upgrade.sh
A běžte si dát třeba kafe ke kávovaru, nebo běžte na 5 až 10 minut dělat něco jiného. Proběhne záloha, natáhne se novější image gitlabu (máme na příkladu 16.9.1, takže se stáhne hned ta první v seznamu 16.11.10-ce.0):
Na starším železe může upgrade jednoho gitlabu trvat i 40 minut, na nějakých starších strojích, či VM s omezenými zdroji to může trvat i déle. Proto buďte trpěliví. dokud vidíte hodně ukecaný výstup, tak jste v pohodě. Nechte to doběhnout a až to budete mít hotovo, přihlašte se na gitlab (potom, co opětovně naběhne) a dostaňte se do svého repozitáře a můžete pracovat na opravách. 😉
Upozornění
Nikdy neprovádějte upgrade na další verzi, dokud nedoběhly všechny Background Migrations (migrace na pozadí).
Upgrade z 16.11.10-ce.0 na 17.1.8-ce.0
Přemýšlel jsem, jestli by šlo kompletní upgrade plně zautomatizovat od nejstarší verze, po tu nejnovější. Já jsem přesvědčen, že by to šlo, ale protože se jedná o jednorázovou záležitost, která se ve většině případů už nebude opakovat a každý upgrade může způsobit nějaké potíže, které nemusí odchytit automatizovaný skript, bylo by to pravděpodobně riskantnější. Další co má negativní vliv na automatizovaný upgrade je rychlost hardwaru, na kterém to běží a velikost samotného gitlabu. Někomu by proto po upgradu trvaly všechny background rutiny 20 – 40 minut, na jiném gitlabu, který má stovky gigabajtů, by mohla stejná operace trvat i celou noc, nebo několik hodin minimálně. Šlo by to i tak zautomatizovat? Asi šlo, ale skript by se musel doptávat API gitlabu (které napříč verzemi prodělalo určité změny), jestli už všechny background migrations doběhly do konce a teprve pak iniciovat výměnu image v docker-compose.yaml a provést upgrade znovu.
U docker-compose provedeme následující příkaz:
sed -i "s|image: 'gitlab/gitlab-ce:16.11.10-ce.0'|image: 'gitlab/gitlab-ce:17.1.8-ce.0'|g" docker-compose.yamlPustíme ./upgrade.sh a necháme vše pracovat.
17.1.8-ce.0 -> 17.3.7-ce.0
Následující příkaz upraví verzi 17.1.8-ce.0 na 17.3.7-ce.0
sed -i "s|image: 'gitlab/gitlab-ce:17.1.8-ce.0'|image: 'gitlab/gitlab-ce:17.3.7-ce.0'|g" docker-compose.yaml./upgrade.sh
Jednu důležitou věc jsem zapomněl zmínit. Pokud máte starší Debian nebo ubuntu-server, můžete tam mít starší balíček, používající docker-compose místo docker compose. Proto přikládám skript pro tyto starší verze linuxů se staršími balíčky pro ty z vás, které čeká v dohledné době upgrade i těchto balíčků.
./upgrade.sh
#!/bin/bash
docker exec -t gitlab-ce gitlab-backup create
docker image prune -a -f
docker-compose pull
docker-compose up
docker logs -f gitlab-ce
17.3.7-ce.0 -> 17.5.5-ce.0
Následujícím příkazem vyměníme v docker-compose.yaml souboru verzi ze 17.3.7-ce.0 na 17.5.5-ce.0.
sed -i "s|image: 'gitlab/gitlab-ce:17.3.7-ce.0'|image: 'gitlab/gitlab-ce:17.5.5-ce.0'|g" docker-compose.yamlPřed upgradem se ubezpečíme, že všechny background migrations doběhly.
Ověříme před spuštěním ./upgrade.sh verzi v docker-compose.yaml
grep gitlab-ce: docker-compose.yaml
image: 'gitlab/gitlab-ce:17.5.5-ce.0'
A můžeme upgradovat dál.
17.5.5-ce.0 -> 17.8.7-ce.0
sed -i "s|image: 'gitlab/gitlab-ce:17.5.5-ce.0'|image: 'gitlab/gitlab-ce:17.8.7-ce.0'|g" docker-compose.yaml
Ověříme:
grep gitlab-ce: docker-compose.yaml
image: 'gitlab/gitlab-ce:17.8.7-ce.0'pustíme ./upgrade.sh
17.8.7-ce.0 – 17.11.7-ce.0
Zbytek už je rutina. Příkaz na výměnu verze.
sed -i "s|image: 'gitlab/gitlab-ce:17.8.7-ce.0'|image: 'gitlab/gitlab-ce:17.11.7-ce.0'|g" docker-compose.yamlZkontrolujeme, že doběhly background migrations.
spustíme ./upgrade.sh a čekáme.
Sleduji, jestli jsou tyto background migrations náročné na procesor, či na paměť a nevšímám si nějaké významné zátěže.
V docker ps vidím, že gitlab běžel cca 23 minut než doběhly všechny background migrace.
17.11.7-ce.0 -> 18.2.8-ce.0
Děláme významný upgrade na verzi 18.2. Ověřili jsme si, že background migrations doběhly, provádíme další příkaz na úpravu v docker-compose.yaml a můžem následně spustit ./upgrade.sh skript.
sed -i "s|image: 'gitlab/gitlab-ce:17.11.7-ce.0'|image: 'gitlab/gitlab-ce:18.2.8-ce.0'|g" docker-compose.yaml
18.2.8-ce.0 -> 18.5.5-ce.0
dál
sed -i "s|image: 'gitlab/gitlab-ce:18.2.8-ce.0'|image: 'gitlab/gitlab-ce:18.5.5-ce.0'|g" docker-compose.yamlověříme:
grep gitlab-ce: docker-compose.yaml
image: 'gitlab/gitlab-ce:18.5.5-ce.0'
./upgrade.sh
18.5.5-ce.0 ->18.8.9-ce.0
Předposlední upgrade:
sed -i "s|image: 'gitlab/gitlab-ce:18.5.5-ce.0'|image: 'gitlab/gitlab-ce:18.8.9-ce.0'|g" docker-compose.yamlověříme:
grep gitlab-ce: docker-compose.yaml
image: 'gitlab/gitlab-ce:18.8.9-ce.0'
18.8.9-ce.0 -> 18.10.3-ce.0
sed -i "s|image: 'gitlab/gitlab-ce:18.8.9-ce.0'|image: 'gitlab/gitlab-ce:18.10.3-ce.0'|g" docker-compose.yaml
./upgrade.sh
