Hoe bouw je een hoog beschikbare Atlassian-stack op Kubernetes?

De opzet van onze Atlassian-stack

Onze Atlassian stack bestaat uit de volgende producten:

• Amazon EKS
• Amazon EFS
• Atlassian Jira Data Center
• Atlassian Confluence gegevenscentrum
• Amazon EBS
• Atlassian Bitbucket datacenter
• Amazon RDS

Zoals je kunt zien, gebruiken we AWS als cloud provider voor onze Kubernetes setup. We maken alle resources aan met Terraform. We hebben een aparte blogpost geschreven over hoe onze Kubernetes setup er precies uitziet. Je kunt het hier lezen! De afbeelding hieronder zou je een algemeen idee moeten geven.

Het volgende diagram geeft je een idee van de opzet van ons Atlassian Data Center.

Hoewel er een paar verschillen zijn tussen de producten en de opstellingen, blijft de kern hetzelfde.

• De applicatie wordt gestart als een of meer pods die worden beschreven door een StatefulSet. De pods worden node-0 en node-1 genoemd in het bovenstaande diagram.
• Het eerste verzoek wordt naar de load balancer gestuurd en wordt doorgestuurd naar de node-0 pod of de node-1 pod. Verkeer is sticky, dus al het volgende verkeer van die gebruiker wordt naar node-1 gestuurd.
• Zowel pod-0 als pod-1 hebben persistente opslag nodig die gebruikt wordt voor de plugin cache en indexen. Op elk van de pods wordt een ander Amazon EBS volume gemount.
• De meeste gegevens zoals je JIRA issues, Confluence ruimtes, ... worden opgeslagen in een database. De database wordt gedeeld, node-0 en node-1 maken beide verbinding met dezelfde database. We gebruiken meestal PostgreSQL op Amazon RDS.
• De node-0 en node-1 pod moeten ook grote bestanden delen die we niet in een database willen opslaan, bijvoorbeeld bijlagen. Hetzelfde Amazon EFS volume wordt op beide pods gemount. Wanneer er wijzigingen worden aangebracht, bijvoorbeeld een bijlage wordt geüpload naar een issue, is de bijlage onmiddellijk beschikbaar op beide pods.
• We gebruiken CloudFront (CDN) om statische assets te cachen en de responstijden op het web te verbeteren.

De voordelen van deze opzet

Door deze opzet te gebruiken, kunnen we gebruikmaken van de voordelen van Docker en Kubernetes en de datacenterversies van de Atlassian-tooling. Er zijn veel voordelen verbonden aan deze manier van werken, maar we hebben de belangrijkste voordelen hieronder opgesomd.

• Het is een zelfherstellend platform: containers en worker nodes vervangen zichzelf automatisch als er een storing optreedt. In de meeste gevallen hoeven we niets te doen en zorgt de stack voor zichzelf. Natuurlijk is het nog steeds belangrijk om storingen te onderzoeken, zodat je ze in de toekomst kunt voorkomen.
• Precies nul downtime implementaties: wanneer we de eerste node binnen het cluster upgraden naar een nieuwe versie, kunnen we de oude versie nog steeds aan onze klanten serveren op de tweede. Zodra de upgrade is voltooid, wordt de nieuwe versie geserveerd vanaf het eerste knooppunt en kunnen we het tweede knooppunt upgraden. Op deze manier blijft de applicatie beschikbaar, zelfs tijdens upgrades.
• Deployments zijn voorspelbaar: we gebruiken dezelfde Docker-container voor ontwikkeling, staging en productie. Daarom hebben we er vertrouwen in dat de container in onze productieomgeving kan starten na een succesvolle deploy naar staging.
• Applicaties met hoge beschikbaarheid: als er een storing optreedt op een van de nodes, kan het verkeer worden omgeleid naar de andere node. Op deze manier heb je de tijd om het probleem te onderzoeken en de kapotte node te repareren terwijl de applicatie beschikbaar blijft.
• Het is mogelijk om gegevens van het ene naar het andere knooppunt te synchroniseren. Zo kan het synchroniseren van de index van de ene node naar de andere om een corrupte index te herstellen in slechts enkele seconden gebeuren, terwijl een volledige herindexering veel langer kan duren.
• Je kunt een hoog beveiligingsniveau implementeren op alle lagen (AWS, Kubernetes, applicatie, ...)
  
  • AWS CloudTrail voorkomt ongeautoriseerde toegang op AWS en stuurt een waarschuwing in geval van een afwijking.
  • AWS Config voorkomt wijzigingen in AWS-beveiligingsgroepen. Je kunt meer te weten komen over hoe je je cloud kunt beveiligen met AWS Config in onze blogpost.
  • Terraform zorgt ervoor dat wijzigingen op de AWS-omgeving door het team worden goedgekeurd voordat ze worden uitgerold.
  • Aangezien het upgraden van Kubernetes master en worker nodes weinig tot geen impact heeft, draait de stack altijd op een recente versie met de laatste beveiligingspatches.
  • We gebruiken een combinatie van namespacing en RBAC om ervoor te zorgen dat applicaties en implementaties alleen toegang hebben tot bronnen binnen hun naamruimte metde minste privileges.
  • Netwerkbeleid wordt uitgerold met Calico. We weigeren standaard al het verkeer tussen containers en staan alleen specifiek verkeer toe.
  • We gebruiken recente versies van de applicaties van Atlassian en implementeren beveiligingsberichten wanneer deze door Atlassian worden gepubliceerd.

Geïnteresseerd om zelf de kracht van Kubernetes te benutten? Op onze website vind je meer informatie over hoe we je kunnen helpen!

Problemen die we tegenkwamen tijdens de installatie

De migratie naar deze stack was niet alleen maar leuk en aardig. We zijn onderweg zeker een aantal moeilijkheden en uitdagingen tegengekomen. Door ze hier te bespreken, hopen we dat we jouw migratie naar een vergelijkbare setup kunnen vergemakkelijken!

• Sommige plugins (meestal oudere plugins) werkten alleen op de standalone versie van de Atlassian applicatie. We moesten een alternatieve plugin vinden of ondersteuning van een leverancier gebruiken om dezelfde functionaliteit op Atlassian Data Center te krijgen.
• We moesten enkele wijzigingen aanbrengen in onze Docker-containers en netwerkbeleid (bijv. firewallregels) om ervoor te zorgen dat beide nodes van een applicatie met elkaar konden communiceren.
• De meeste applicaties hebben wat extra tools in de container. Bijvoorbeeld Synchrony voor Confluence, ElasticSearch voor BitBucket, EazyBI voor Jira, enzovoort. Deze extra tools moesten allemaal gerefactored worden voor een multi-node opstelling met gedeelde gegevens.
• In onze vorige opstelling draaide elke applicatie op zijn eigen virtuele machine. In een Kubernetes-context zijn de applicaties verspreid over een aantal worker nodes. Daarom kan één worker node meerdere applicaties draaien. Elke node van elke applicatie wordt gepland op een worker node die voldoende resources beschikbaar heeft. We moesten een goed plaatsingsbeleid implementeren zodat elk knooppunt van elke applicatie voldoende geheugen beschikbaar heeft. We moesten er ook voor zorgen dat een applicatie een andere applicatie niet kon beïnvloeden als deze om meer resources vroeg.
• Er waren ook enkele uitdagingen met betrekking tot load balancing. We moesten een aangepast sjabloon maken voor nginx ingress-controller om ervoor te zorgen dat websockets correct werken en dat alle gezondheidscontroles binnen de applicatie een gezonde status rapporteren. Daarnaast hadden we een andere loadbalancer en URL nodig voor ons BitBucket SSH-verkeer in vergelijking met ons webverkeer naar de BitBucket UI.
• Onze vorige installatie bevatte veel gegevens, zowel op het bestandssysteem als in de database. We moesten alle gegevens migreren naar een Amazon EFS-volume en een nieuwe database in een nieuw AWS-account. Het was een uitdaging om een manier te vinden om een consistent synchronisatieproces te hebben dat ook niet te lang duurde, omdat tijdens de migratie alle applicaties down waren om gegevensverlies te voorkomen. Uiteindelijk konden we aan deze criteria voldoen en konden we succesvol migreren.

Onze Atlassian-stack monitoren

We gebruiken de volgende tools om alle resources binnen onze setup te monitoren

• Datadog om alle componenten te monitoren die zijn gemaakt binnen onze stack en om logging van alle componenten te centraliseren. Je kunt meer lezen over het monitoren van je stack met Datadogin onze blogpost hier.
• NewRelic voor APM-monitoring van het Java-proces (Jira, Confluence, Bitbucket) binnen de container.

Als onze monitoring een afwijking detecteert, wordt er een alert aangemaakt binnen OpsGenie. OpsGenie zorgt ervoor dat deze waarschuwing naar het team of de oproepkracht wordt gestuurd die verantwoordelijk is voor het oplossen van het probleem. Als de oproepkracht de waarschuwing niet op tijd bevestigt, wordt de waarschuwing geëscaleerd naar het team dat verantwoordelijk is voor die specifieke waarschuwing.

Conclusie

Kortom, we zijn erg blij dat we zijn overgestapt op deze nieuwe stack. De combinatie van de voordelen van Kubernetes en de Atlassian Data Center versies van Jira, Confluence en BitBucket voelt als een grote stap in de goede richting. We hebben elke dag profijt van de verbeteringen op het gebied van self-healing, deployment en monitoring en het onderhoud is een stuk eenvoudiger geworden.

Geïnteresseerd in je eigen Atlassian Stack? Wil je ook de kracht van Kubernetes benutten? Op onze website vind je meer informatie over hoe we je kunnen helpen!