Så förenklar du Atlassian Server med Docker

Ibland blir vi ombedda att hjälpa till att uppgradera en instans av en Atlassian-applikation, och de här instanserna är ofta flera år gamla.

Typiskt för det här användningsfallet är att personerna som installerade instansen inte längre finns tillgängliga. Det saknas kunskap om hur den installerades och konfigurerades, så ingen vet hur den ska uppgraderas.

Ofta har allt gjorts manuellt, med många olika roller involverade i uppsättningen. Det kan ha funnits ett infrastrukturteam för hårdvaran, ett databasteam för databasen och ett applikationsteam för en proxy, och så vidare. Det kan kännas överväldigande, och uppgraderingen kan bli tidskrävande och besvärlig. Något som borde vara relativt smärtfritt kan ta timmar eller till och med dagar.

Konsekvenserna av den här typen av situation är ganska lätta att förutse. Det kan uppstå säkerhetsproblem, besvärliga uppgraderingsprocesser och en oförmåga att dra nytta av nya funktioner och förbättringar. Dessutom tillkommer oron. Vad händer vid den kommande revisionen? Och så finns den extra kostnaden för att ta in experter som Eficode.

Som företag går det bra för oss att hjälpa kunder i den här typen av situationer. Men vi är också ett DevOps-företag. Vi ryser inför sådana här scenarier och uppskattar inte besvärliga uppgraderingar mer än du gör. 

Lösning

Målet är att använda teknik för att förenkla installationer, uppgraderingar och migreringar. 

• Installationen ska vara enkel och kräva lite kunskap.

• Uppgraderingar ska vara enkla och ta så lite tid att de görs regelbundet.

• Migrering till en ny värd ska vara relativt smärtfri.

• Så få personer som möjligt ska vara involverade för att minska samordningsarbetet.

• Det ska vara reproducerbart och motståndskraftigt mot kunskapsbortfall.

Teknikval

Jag har valt att använda Docker och docker-compose för att driftsätta och hantera applikationsinstansen. De gör det möjligt att hantera applikationen som kod, paketera direkta beroenden tillsammans, orkestrera driftsättningen av de olika delarna och göra allt reproducerbart.

Atlassians Bitbucket Server är Atlassian-applikationen i den här demon. 

Atlassians Bitbucket Docker image kommer att användas. Vi vill göra hanteringen och underhållet av instansen så smidigt som möjligt, och det är inte särskilt meningsfullt att bygga egna images.

Den officiella PostgreSQL image kommer att användas för databasen. PostgreSQL är kostnadsfritt, stöds officiellt av Atlassian och har mycket bra prestanda. Så vitt jag vet använder Atlassian själva den här databasen, så det är ett mycket bra val.

Slutligen kommer jag att använda Traefik som proxy. Det är kostnadsfritt, mycket enkelt, har bra prestanda och stöder HTTP/HTTPS samt TCP. Vi behöver en proxy som stöder TCP för SSH-funktionalitet. Dessutom integreras det i princip direkt med LetsEncrypt och de stora DNS-leverantörerna som har stöd för ACME protocol.

Arkitektur och infrastruktur

Alla huvudkomponenter ska driftsättas på en virtuell maskin (VM) och orkestreras av docker-compose. Säkerhetskopiering kan göras med nattliga snapshots av den virtuella maskinen eller med skript. Du kan också låta en CI-server köra säkerhetskopieringsskript och lagra säkerhetskopiorna på distans. Det finns många möjligheter.

Motiveringen till att ha alla delar på en och samma virtuella maskin är enkel. Idén här är enkelhet. Ett litet repository som hanterar allt som behövs för att tillhandahålla applikationen. En virtuell maskin som gör driftsättning och säkerhetskopiering så enkla som möjligt. 

Med Bitbucket finns dessutom en nära koppling mellan filsystemet och databasen. Metadata som refererar till hashar som lagras i filsystemet sparas till exempel i databasen. Därför kräver en korrekt säkerhetskopiering att både databasen och applikationen säkerhetskopieras tillsammans.

Arkitektoniskt behövs bara tre delar: Traefik som proxy, Bitbucket och PostgreSQL-databasen. 

Jag har också skapat en domän på AWS så att jag kan konfigurera Traefik att hantera SSL-certifikaten åt mig via route53. Traefik kan göra hanteringen av SSL-certifikat mycket enkel.

Repositoryt

Hur svårt är det här? Inte särskilt svårt. Du kan se ett demorepository här.

Det finns bara fyra viktiga filer.

• Filen .env för att ange några miljövariabler. 39 rader.

• Skriptet backup-restore.sh. 153 rader.

• Backup-restore-compose.yml. 30 rader. 

• docker-compose.yml. 88 rader.

Den enda egentliga komplexiteten finns i skriptet backup-restore.sh. Resten är bara YAML och variabeltilldelningar.

I demorepositoryt använder vi Amazons Route53 tillsammans med LetsEncrypt för att hantera våra SSL-certifikat, så vi behöver en AWS Access key, motsvarande secret och tillhörande e-postadress. Du kan montera dina egna certifikat i Traefik-containern, men det är skönt att slippa tänka på certifikathantering.

Jag har också registrerat domänen thedukedk.net på Route53. 

I följande avsnitt finns några skärminspelningar som visar hur du använder lösningen.

Installation

Det enda du egentligen behöver göra är att fylla i variablerna i filen .env. Om du inte redan har en DNS-post som pekar mot värden lägger du till SERVER_PROXY_NAME i din hosts-fil. 

Starta sedan allt genom att köra docker-compose up -d.

Skärminspelningen visar hela processen.

Som du kan se i skärminspelningen tog allt bara några minuter och krävde ett enda kommando.

• Traefik-dashboarden nås på localhost:8080.

• Traefik hanterar HTTPS på port 443 och dirigerar webbtrafiken till tjänsten bitbucket-web.

• Traefik hanterar SSH på port 7999 och dirigerar SSH-trafiken till tjänsten bitbucket-ssh.

• Traefik fungerar tillsammans med LetsEncrypt och Route53 för att generera SSL-certifikatet för HTTPS.

• Du kan använda PostgreSQL-containerns namn, postgres-bitbucket, när du ansluter Bitbucket till databasen. 

För att stoppa hela konfigurationen kör du docker-compose stop.

Du kan också köra docker-compose down för att stoppa och ta bort containrarna. All nödvändig data sparas i Docker-volymer, så inga data går förlorade om containrarna tas bort.

VOLYMNAMN

INNEHÅLL

bitbucket_data

Bitbuckets data(home)-katalog.

bitbucket_db

Postgres-databasfiler.

bitbucket_letsencrypt

Certifikat- och nyckeldata. Sparas i filen acme.json.

Uppgradering

Det mest komplexa uppgraderingsscenariot innebär att uppgradera både databasen och applikationen, så låt oss titta på den processen.

I skärminspelningen kan du se:

• Bitbucket-versionen var 7.0.2 och PostgreSQL-versionen var 9.5.

• Jag stoppade containrarna.

• Jag skapade en backup med skriptet backup-restore.sh.

• Jag tog bort Postgres Docker-volymen och uppgraderade Postgres-versionen i de två compose-filerna.

• Jag startade Postgres-containern med den nya versionen så att den kunde initieras.

• Jag stoppade Postgres-containern och återställde data från SQL-backupfilen.

• Jag uppgraderade Bitbucket-versionen i docker compose-filen och startade sedan containrarna igen.

I skärminspelningen kan du se att hela processen tog omkring fem minuter. En stor del av tiden gick åt till att starta Bitbucket.

Tiden varierar förstås beroende på storleken på Bitbuckets datakatalog som ska säkerhetskopieras. Men även en instans med ett filsystem på omkring 10 GB tar bara några minuter att säkerhetskopiera. Backup och återställning av databasen går något snabbare.

Migrera värd

Om du behöver migrera installationen till en ny värd behöver du bara starta en icke-konfigurerad installation och sedan återställa datakatalogen och databasen från en backup. Processen ser ut så här.

I skärminspelningen kan du se:

• En ny instans av Bitbucket, Traefik och PostgreSQL startades.

• Bitbucket var varken konfigurerat eller anslutet till PostgreSQL.

• Skriptet backup-restore.sh kördes med ett komprimerat tar-arkiv av datakatalogen och en SQL-dump av databasen från den andra värden.

• Skriptet backup-restore.sh startade om containrarna efter återställningsprocessen, och allt är konfigurerat och anslutet.

Migrering till Docker

Om du vill byta till en lösning som denna är det inte så svårt som du kanske tror. Anta att du har en miljö där servern har installerats manuellt på en maskin och databasen finns på en fjärransluten maskin med en annan databastyp, till exempel MSSQL.

Det du vill göra är att återställa applikationen i en container, men ansluta den till en kopia av MSSQL-databasen. Därefter använder du den inbyggda funktionen för databasmigrering för att migrera till den containeriserade PostgreSQL-databasen. 

För att säkerställa att den containeriserade instansen ansluter till kopian av den befintliga databasen måste du redigera filen bitbucket.properties i säkerhetskopians tarball så att den pekar på databaskopian. 

jdbc.url=jdbc:sqlserver://<MSSQL SERVER>:<PORT>;databaseName=<NAME OF DATABASE COPY>;

Processen ser ut så här.

I skärminspelningen kan du se:

• Vi startar en ny instans av alla containrar.

• Vi återställer en komprimerad tarball där filen bitbucket.properties har redigerats för att peka på en kopia av MSSQL-servern och databasen.

• Vi startar alla containrar igen och verifierar att repositories har återställts.

• Vi använder Bitbuckets funktion för databasmigrering för att migrera från MSSQL-servern till PostgreSQL-containern.

Sammanfattning

Att hantera Atlassian-applikationer behöver inte vara svårt. 

Om du precis har börjat använda Atlassian-applikationer bör du verkligen överväga alla tillgängliga alternativ. Min kollega har skrivit ett blogginlägg om vad du bör tänka på när du börjar använda Atlassian-applikationer, och det är väl värt att läsa.

Om du befinner dig i en situation där uppgraderingar eller migreringar är besvärliga, ta dig tid att förändra nu. Annars hamnar du troligen i en ännu mer problematisk situation längre fram. 

Slutligen lite om oss och vad vi gör med Atlassian-applikationer. 

• Vi erbjuder support för allmän användning och konfiguration av Atlassians moln- och servererbjudanden.

• Vi är också en Atlassian training partner och erbjuder praktisk utbildning för våra kunder. 

• För kunder som inte kan använda Atlassians molnerbjudande, men som inte vill hosta och hantera applikationen eller applikationerna själva, erbjuder vi ett helt förvaltat alternativ som en del av Eficode ROOT DevOps-plattformen. 

• Vi hjälper kunder att installera och underhålla Atlassian server- och datacenterlösningar on premise.