Introduction

• CRDS and extent functionallity on kubernetes allows to apply verifications before move to next version
• Blue Green deployment
• Canary Deployments

Develop

Split CI and CD

• why split? Better concern separation, improvements could be more specific.

Argo rollouts

Argo rollouts allows to easy configuration over Blue/Green Deployments or Canary Deployments rights in the manifest level, also provides a way to run experiments, AB testing and Weighted routing.

• More Documentation Dashboard
• More Documentation Init documentation
• More Documentation Experiment resource
• More Documentation Architecture

Install ArgoCd in k8s Cluster

Argo Rollouts allow us on ArgoCD start writing instead deployments and use CRDS for rollouts to start with a dashboard for blue/green deployments and also allows to set canary experiments, also allows experiments over latency/load/, well integration with prometheus.

• More Documentation Installation
• More Documentation ApplicationSet

Configure Registry Images “watcher”

for chatops, is not needed about to configure writeback on git, however can be a good idea

• More Documentation Image Updater
• More Documentation Authentication
• More Documentation Update Methods

Configure Repository credentials and application

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: example
  namespace: <argocd|yournamespace_better_with_configmap>
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  destination:
    namespace: default
    server: default  # try for testing https://kubernetes.default.svc | cluster local or remote
  project: default # a mnemonic name
  source:
    path: couldbeforldername ae.
    repoURL: git repo or helm
    targetRevision: {{ $config.spec.source.targetRevision }} # Version helm chart or 'branch name|tag' on git
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      prune: true
      selfHeal: true

source: Link

many options on configuration going to detail helps on how your workload could be found easier onSyncPolicy, could be one at month?, no one wants that, sync right as the code is ready, however could be helpfull to avoid sync when you know there is something that is not ready, or trully approved

Source of truth with kustomize

with kustomize the name of the file must name it as kustomization.yaml

bases:
- ../../otherKustomization.yaml # what to include first, it could be another proyect complet resources
patches:
- overrides.yaml # what mean want to change on resource assingation or dockerfile
images:
- image_name:version # this part could be handled as part of the Image Updater, (not production ready)

Conclusion

Argo cd help on sync many changes and start building on configurations for right resources and split CI from CD, no one of this was focus on integration, this could be only to met and test over different environment requirements

image_name:version could be better handled manually and also allow to modify always on git your runtime