Met Argo Rollouts kun je Deployment objecten vervangen door Rollout objecten die meer controle geven over hoe updates aan een Deployment uitgerold worden. Langzaam aan met Canaries, atomisch met Green-Blue changeover, en meer. Dit alles kan automatisch gebeuren, met handmatige promotie stappen, combinaties daarvan, en zelfs met probes die kijken of een nieuwe versie goed werkt.
Als je een applicatie die via Hem charts wordt gedistribueerd in je OpenShift GitOps (ArgoCD) wilt opnemen heb je twee opties:
Wander Boessenkool
kustomize laten renderen, en de kustomization.yaml in je ArgoCD opnemen.De eerste oplossing is het makkelijkst, en heeft weinig extra configuratie
nodig. Het nadeel is wel dat je wat betreft aanpassingen gelimiteerd bent op
wat de schrijver van de chart via de values.yaml heeft aangeboden.
Wanneer je extra aanpassingen nodig hebt kom je dus al snel uit op de tweede
methode: De helm chart via kustomize laten renderen (inclusief aanpassingen
via values.yaml), en daar extra aanpassingen op doen via de bekende
kustomize transformers zoals images:, patches:, replicas:, etc.
In een vorige video hebben we gekeken hoe je namespaces kunt beheren met behulp van GitOps methodologieën. Deze week gaan we hierop verder bouwen en gaan we ook (Cluster)ResourceQuotas introduceren.
In het verleden hebben we op dit kanaal al vaker gekeken naar het managen van namespaces voor applicatie-teams op Kubernetes en OpenShift clusters. Deze keer kijken we naar hetzelfde probleem, maar pakken we het op een GitOps methode aan.