A Kubernetes Mutating Webhook Server, that injects an Argo Rollout for every Deployment. The rollout will take the configuration of the deployment and automatically enables a Blue Green Strategy for them.
The current (alpha) version does not support any specific configuration and just acts on every deployment in the given namespace. It scales the original deployment down to 0 and creates the pods through a rollout. The service from the original one is left in place and a preview-service is created, using a "-preview" post-fix.
All objects created are annotated with "argocd.argoproj.io/compare-options" = "IgnoreExtraneous" and "argocd.argoproj.io/sync-options" = "Prune=false" to not interfer with ArgoCD.
Deployment happens, following the standard procedure of a Webhook-Deployment.
- Create a certificate to be used by the webhook. This could be a self-signed(see issuer and certificate) certificate, issued by cert-manager.
- Since the webhook needs to access the kubernetes APIs, a proper role has to be provided. It needs CRUD-Access to "Services" and "argoproj.io/Rollouts", thus a a service-account with such permissions needs to be created. See the cluster-role, role-binding and service-account on how to create such.
- The server needs to be deployed. Create a simple deployment, mounting the certificate to
/etc/certsand a service, offering the 443 endpoint to the cluster. See deployment and service. Be aware that the injecting webhook acts namespaced, e.g. it needs to be deployed to the namespace it should inject the rollouts. - Create the webhook. The webhook also needs to be added to the namespace(namespaced webhooks limit the blast-radius in case of errors) and needs to get the CA of the certificate provided. If the certificate was created via cert-manager, this could be done via annotaiton. See the mutating-webhook
In order to exclude a deployment from beeing replaced by a rollout, just add the annotation:
metadata:
name: webhook-server
annotations:
wistefan/rollout-injecting-webhook: ignore