Overslaan naar hoofdinhoud

Voordat je misverstanden maakt over kops door het lezen van de titel, laat me je daar stoppen! Dit is niet de vergelijking van deze 2 geweldige stukken software, Kops en EKS Fargate, gebaseerd op hun technische mogelijkheden. Ik wil ons kleine verhaal bij Vervotech delen voor een van de belangrijke stappen in elke DevOps reis, namelijk geautomatiseerde infrastructuur provisioning voor onze producten en enterprise services implementaties.

Weinig over DevOps bij Vervotech

Automatisering is één van de belangrijkste componenten van de DevOps beweging als we het bekijken vanuit het CAMS model perspectief. De CAMS staat voor Cultuur, Automatisering, Meting, en Delen. U kunt hier meer lezen over het CAMS model.

Hoewel er veel verschillende opvattingen en uitvoeringsmodellen rond DevOps zijn,

We geloven sterk in het CAMS model voor DevOps bij Vervotech.

Dus, om meer en meer automatisering te bereiken, wordt het automatiseren van een van de belangrijke gebieden, d.w.z. infrastructuur en alle activiteiten vanaf het definiëren, implementeren, onderhouden en vernietigen van infrastructuur zeer belangrijk. En dat alles kan bereikt worden door "Infrastructuur als Code" (IaC) te gebruiken.

IaC vereist het gebruik van veel tooling in meerdere stadia/gebieden van de infrastructuurautomatisering. En gelukkig is er een verbazingwekkende reeks gereedschappen om deze verschillende stadia aan te pakken. Hier is een zeer korte samenvatting van die stadia en bekende tools,

  • Voor het beheer van serverconfiguratie kunnen we hulpmiddelen gebruiken als Chef, Puppet, Ansible, SaltStack.
  • De tools zoals Vagrant, Packer, Docker zijn voor de server templating.
  • Voor orkestratiedoeleinden kunnen we Kubernetes, Docker Swarm, Nomad, Mesos, enz. gebruiken.
  • En tenslotte, voor infrastructuur provisioning, kunnen we Terraform, Cloud Formation, Google Deployment Manager, Azure Resource Manager gebruiken. Weinig van deze provisioning tools werken specifiek op slechts één cloud provider.

Dus, waarom hebben we eerder besloten om kops op AWS te gebruiken?

Het antwoord is dat AWS $144 per maand rekent voor het gebruik van EKS managed service. Ja, u leest het goed, dit was de reden waarom wij geen gebruik hebben gemaakt van EKS!

Ook was het EKS toen nog niet volgroeid, met de mogelijkheid het alleen voor het handjevol AWS-regio's te gebruiken.

Ja, we hadden de optie van Google Kubernetes Engine(GKE), die geen kosten in rekening brengt voor managed Kubernetes service (exclusief worker nodes), maar we hadden een aantal organisatorische beperkingen rond technologiestrategie op dat moment.

We hebben zelfs een ander product, Vervotech Mappings, dat momenteel op GCP GKE draait.

Waarom zochten we dan naar een verandering?

De setup werkte prima gedurende een jaar. Maar naarmate het verkeer groeide, zoals bij elke implementatie in de cloud, ontstond de behoefte aan meer verbeterde infrastructuurworkflows, af en toe productie-uitval, problemen met het onderhoud van de bestaande infrastructuur, verzoeken om nieuwe infrastructuur te provisioneren, beveiligingsinbreuken die een zeer snelle, nauwkeurige en consistente reactie van de DevOps-automatisering vereisten.

Enkele van de hierboven genoemde problemen zijn niet noodzakelijkerwijs te wijten aan kops, maar wel aan gedeeltelijke/onvolledige automatisering van de infrastructuur. Aangezien kops zorgt voor het grootste deel van de netwerken en compute resources op het Kubernetes cluster, vertrouwden we voor andere cloud resources op ad-hoc scripts en op AWS CLI commando scripts. Dit is het gebied van het beheren en definiëren van alle cloud resources (afgezien van de door kops beheerde infrastructuur) die meer automatisering nodig had.

Wat hebben we aan het eind bereikt?

Dus begonnen we al onze cloud resources te coderen met behulp van Terraform modules, inclusief, VPC, EKS, FARGATE profielen, Kubernetes, S3, Route 53, en andere managed services. Het duurde een tijdje voor we een Terraform-configuratie hadden opgebouwd, omdat onze eerste poging was om alle Terraform-configuratie van onze bestaande kops-infrastructuur te importeren met behulp van Terraform import. We hebben dat idee later geschrapt omdat we ontdekten dat het importproces niet echt rechttoe rechtaan is.

Het is aanbevolen en goed als u Terraform-configuraties begint te gebruiken vanaf het begin van het project in uw DevOps-reis.

Dus hebben we de problemen waar we eerder mee te maken hadden aangepakt en opgelost,

  • Apps die zowel pod- als clusteruitval veroorzaken worden verplaatst naar EKS FARGATE, zodat de impact wordt gelokaliseerd en afgehandeld door FARGATE.
  • We kunnen de beheerde AWS diensten definiëren, implementeren en onderhouden met Terraform configuratiebestanden.
  • Alle Kubernetes cluster logs worden door EKS gecentraliseerd naar CloudWatch.
  • Verbeterde netwerken: In de oude setup, draaiden we ongeveer 200 pods in het Kubernetes cluster op NodePort services. De manier waarop deze werden ingezet, vereiste manuele tussenkomst in enkele scenario's zoals het manueel toevoegen van doelgroepen, manueel definiëren van de listener in ALB, manueel toevoegen van nodes aan doelgroepen. Dit is allemaal verdwenen sinds dit allemaal gecodeerde Terraform configuratiebestanden zijn met behulp van de Terraform Kubernetes module en Terraform EKS module.
  • Verbeterde auto-scaling met EKS en FARGATE voor de apps.
  • De problemen die ontstaan door handmatige configuraties worden sterk verminderd.
  • Blauw-groene inzet werd minder omslachtig.
  • We kunnen de kosten berekenen van elke pod die in het cluster draait en betere prijsmodellen voor onze klanten bouwen.

Nog wat leren...

  • De Kubernetes cluster upgrades zijn veel eenvoudiger met EKS dan kops omdat AWS het grootste deel van de upgrade voor zijn rekening neemt.
  • Er is een middenweg om het Kubernetes cluster te creëren en te beheren door zowel kops als Terraform samen te gebruiken, hier.
  • Onze ervaring met het introduceren van Terraform op reeds draaiende productie-infrastructuur was niet zo geweldig en de reden hiervoor is dat Terraform niet goed werk levert bij het effectief importeren van je bestaande infrastructuur.
  • Zeker, er zijn een aantal overwegingen met EKS Fargate die hier zijn opgesomd, maar daar zitten we voorlopig goed mee, en niet al onze werklast draait op EKS Fargate.
  • Nu is onze infrastructuurcode versiebeheerst, snel uit te rollen, zelf te onderhouden, te hergebruiken, en gedocumenteerd (want er is geen betere documentatie voor de programmeur dan de code zelf, hier).
  • De cloud-agnostische infrastructuurprogrammering en tooling is nu mogelijk. Dat betekent dat overstappen naar GCP of Microsoft Azure of een andere bekende cloud provider relatief veel gemakkelijker zal zijn.

Het idee hier was om de ervaring te delen en eventuele suggesties te vragen.

Over Vervotech Mappings:

Vervotech Mappings is een toonaangevende Hotel Mapping en Room Mapping API die gebruik maakt van de kracht van AI en ML om snel en nauwkeurig elke vastgoedvermelding te identificeren door de verificatie van meerdere parameters. Met een van de beste dekking van 98% en een nauwkeurigheid van 99,999% wordt Vervotech Mappings snel de mapping software van keuze voor alle toonaangevende wereldwijde bedrijven die actief zijn in de reis-en hospitality industrie. Voor meer informatie over Vervotech Mappings en de manieren waarop het uw bedrijf op lange termijn kan verbeteren kunt u contact met ons opnemen: sales@vervotech.com

Disclaimer: De auteur is zelf verantwoordelijk voor de inhoud en Vervotech oefent geen controle of invloed uit op de meningen of uitspraken van de auteur.