IT staat nooit stil en daarom is ACA Group voortdurend op zoek naar innovatieve oplossingen en tools. Een van die tools is Flux. In deze blogpost delen onze experts hun ervaringen en bevindingen.

Ten eerste, wat is Flux? Flux is cloud-native tooling, ontworpen om gebruik te maken van de flexibiliteit, schaalbaarheid en veerkracht van de cloud. Het kan draaien op elke Kubernetes-gebaseerde oplossing in de public/private cloud en op een lokaal Kubernetes-cluster. Flux is een gecontaineriseerde tool die maar één doel dient: het implementeren van Continuous Delivery. Om dit te bereiken, houdt Flux het Kubernetes-cluster waarop het wordt ingezet in sync met een configuratiebron. Een typische bron zou een GIT repository zijn. De configuratiebron wordt gemonitord door Flux (pull-aanpak); en als er een wijziging wordt gedetecteerd, wordt de wijziging uitgerold naar het cluster.

De wijziging wordt ingezet via een afstemmingsmethode. Dit betekent dat Flux niet alle bronnen vernietigt en aanmaakt, maar alleen de wijzigingen aanbrengt die nodig zijn om overeen te komen met de toestand zoals beschreven in de GIT-repository. U hebt bijvoorbeeld een Deployment.yaml en Service.yaml, maar u wilt alleen de eerste wijzigen om een nieuwe versie van een containerimage te gebruiken. Dan wordt alleen de Deployment.yaml vervangen binnen het cluster; zonder de service te veranderen. Samengevat wordt het proces van het synchroniseren van de inhoud in GIT GitOps genoemd.

Wat is GitOps?

In een GitOps aanpak is de toestand van het cluster volledig beschreven in GIT repositories; het bevat alles wat nodig is om een applicatie uit te rollen (Deployment.yaml, Service.yaml, ConfigMap.yaml,...). Om het cluster met de staat te matchen, hebben we een geautomatiseerde oplossing nodig. In dit geval zal Flux een reconciliatie uitvoeren als er iets veranderd is in GIT.

Het gebruik van GitOps wordt beschouwd als een meer ontwikkelaargerichte ervaring. Het is gebaseerd op tools en principes die ontwikkelaars al kennen, dus extra kennis is niet meer nodig.

De voordelen van GitOps

Het gebruik van de door Flux geïmplementeerde GitOps-aanpak heeft veel voordelen:

• de volledige Kubernetes-clusterstatus is zichtbaar in GIT, waardoor deze begrijpelijker is voor ontwikkelaars
• ontwikkelteams kunnen onafhankelijker werken omdat er geen complexe deploy pipelines nodig zijn
• het is veel eenvoudiger om extra applicaties op te zetten die kunnen worden ingezet op het Kubernetes-cluster
• het gebruik van pull request flows vergemakkelijkt het monitoren van wijzigingen in applicaties
• branching- of versiebeheerstrategieën maken het eenvoudig om verschillende omgevingen (test, acceptatie, productie) synchroon te houden.
• de aanpak kan uniform zijn voor alle soorten Kubernetes-clusters (EKS, Rancher, OpenShift of een lokale opstelling)
• flux is lichtgewicht en kan eenvoudig op elk Kubernetes-cluster worden geïnstalleerd, omdat de capaciteit meestal al aanwezig is
• flux heeft goede documentatie en een actieve community

Omdat de Flux-bronnen binnen ons cluster draaien, is het niet nodig om andere ontwikkeltools te gebruiken (zoals Jenkins of Bamboo). Dit heeft ook enkele voordelen

• minder beveiligingsproblemen omdat we een pull-aanpak gebruiken en geen referenties hoeven op te slaan in externe tools
• geen onverwachte downtime veroorzaakt door externe implementatietools
• geen onverwachte downtime door externe implementatietools
• minder overhead omdat er geen deployment tools onderhouden hoeven te worden.

Hoe applicaties beheren met Flux

Stel dat we een GIT repo hebben met de naam flux-app die de Deployment.yaml bevat die we willen implementeren. Hoe kunnen we Flux opdracht geven om deze Deployment aan te maken in het Kubernetes-cluster?

Voordat we onze applicaties kunnen deployen, moeten we eerst Flux installeren. Flux gebruikt ook een GitOps-aanpak om zijn eigen installatie te beheren:

1. maak een GIT repository aan die de bronnen voor de Flux installatie zal bevatten
2. download de Flux CLI
3. voer het bootstrap commando uit

De YAML-bestanden worden opgeslagen in de eerder genoemde GIT-repository en worden toegepast op je cluster. De belangrijkste resources die zijn aangemaakt zijn zichtbaar in de afbeelding hieronder.

De Flux-installatie heeft 4 belangrijke componenten toegevoegd aan ons Kubernetes-cluster:

• source-controller pod
• kustomize-controller pod
• GitRepository CRD (Custom Resource Definition)
• Kustomization CRD (Custom Resource Definition)

⚠️ Wat zijn Custom Resource Definitions?

Kubernetes levert standaard een specifieke set API resources. Dit zijn de bekende resources zoals Pods, ConfigMaps, Deployments, Secrets. Een CR, Custom Resource, is een uitbreiding op de Kubernetes API. Het biedt een manier om nieuwe resourcetypes toe te voegen naast deze bestaande resources. Maar net als bij bekende resources hebben we een specificatie nodig over hoe we zo'n resource kunnen maken.

De CustomResourceDefinition (CRD) is in feite een blauwdruk van hoe de CustomResource (CR) eruit moet zien. Bovendien hebben we logica nodig over wat er moet gebeuren als zo'n resource wordt aangemaakt. Deze logica wordt meestal toegevoegd aan de applicatiecontainer, die de CRD controleert op wijzigingen en de vereiste acties onderneemt wanneer deze zich voordoen.

Klik hier voor meer informatie over dit onderwerp in de officiële Kubernetes documentatie.

In het geval van Flux heeft de source-controller pod de logica om actie te ondernemen als een GitRepository CR wordt aangemaakt/gewijzigd. Op dezelfde manier heeft de kustomize controller pod de logica om actie te ondernemen wanneer een Kustiomization CR wordt aangemaakt/gewijzigd. Flux levert de CustomResourceDefintion (blauwdruk) en de logica (die in de containers draait) om iets met een Custom Resource te doen. De Custom Resource wordt in de volgende stappen toegevoegd aan het Kubernetes-cluster.

GitRepository aangepaste bronnen toevoegen

Nu we de GitRepository CustomResourceDefinition en de source controller hebben, kunnen we GitRepository resources gaan toevoegen. Deze resource bevat de logica om verbinding te maken met de GIT repository waar de YAML-bestanden van je applicatie zijn opgeslagen.

We maken de GitRepository bron aan.

Merk op dat de revisie verwijst naar branch/commit-id

Op dit punt wordt de GIT repository bekeken, maar er wordt niets uitgerold naar ons cluster. Om de YAML-bestanden uit te rollen die zijn opgeslagen in de flux app GIT repository, moeten we een Kustomization resource aanmaken.

⚠️ U moet een geheim voor authenticatie toevoegen aan de Bitbucket-repository. Omdat dit op meerdere manieren kan worden gedaan, is dit niet aan dit artikel toegevoegd. Als het geheim is aangemaakt, moet je ernaar verwijzen in je GitRepository yaml bestand.
secretRef: naam: bitbucket-cloud-credentials

Meer informatie kun je hier vinden!

Kustomization aangepaste bronnen toevoegen

De Kustomization resource zal configureren welke GitRepository resource op veranderingen moet letten. Zodra de GitRepository bron naar een nieuwe revisie wijst, zal de kustomize-controller de huidige versie van de artefacten naar het cluster deployen.

We maken de Kustomization bron aan.

Als we de status van de aangemaakte Kustomization resource opvragen, zien we dat deze overeenkomt met de laatste revisie.

Bij het controleren van BitBucket zien we dat er een Deployment bestand in onze GIT repository staat - de commit komt overeen met degene die door Kustomization is genoemd.

Deze Deployment is toegepast op ons Kubernetes-cluster.

Dingen samenvoegen

Samengevat vat het bovenstaande ontwerp de flow samen:

1. een ontwikkelaar maakt een pull request aan
2. het pull-verzoek wordt samengevoegd tot een tak die bewaakt wordt door flux
3. de broncontroller bewaakt de branch; het zal een nieuwe commit id opmerken en de revisie van de GitRepository bron veranderen in 'branch/commit-id'.
4. de aanpassingscontroller houdt de GitRepository bron in de gaten
5. als een nieuwe versie wordt opgemerkt, zal de nieuwe versie van de bestanden worden toegepast, de revisie van de Kustomization bron zal worden veranderd in 'branch/commit-id'.

Conclusie

In deze blogpost hebben we uitgelegd hoe Flux werkt en hoe eenvoudig het is om Flux te gebruiken voor continuous delivery. Binnen ACA zijn we momenteel bezig met de migratie van complexe Jenkins deploy pijplijnen naar een eenvoudig te begrijpen GitOps aanpak met behulp van Flux. We geloven dat deze GitOps aanpak in de nabije toekomst de standaard manier zal worden om workloads uit te rollen.

Meer weten over Flux?