- CD workflow without ArgoCD
- new feature or bugfix committed to git repo triiggers CI/CD pipeline which
- test changes
- build image
- push to docker repo
- update k8s deployment file with enw image tag and applied in kubernetes
- Challenges
- installing and setting up tools like kubectl, helm, etc
- Configure access to k8s for tools
- Cloud access and require security challenges
- no forther visibility of deployment status
- Jenkins for example unless you have following test steps
- new feature or bugfix committed to git repo triiggers CI/CD pipeline which
- ArgoCD
- CD for Kubernetes
- Based on GitOps
- Reverse the flow
- ArgoCD is part of the cluster
- ArgoCD agent pulls k8s manifest changes and applies them
- CD Workflow
- Deploy ArgoCD in k8s cluster
- Configure ArgoCD to track git repository
- ArgoCD monitors for any changes and applies them automatically in the cluster
- When developer pushes changes to git repo
- trigger Jenkins or GH Actions which
- test
- build image
- push to docker repo
- update k8s manifest file
- Best practice for git repo
- seperate application source code and application configuration(k8s manifest files)
- app configuration(gitOps repsitory)
- git repo that is tracked and synced by ArgoCD
- app configuration(gitOps repsitory)
- seperate git repository for system configurations
- avoid triggering full CI pipeline
- seperate application source code and application configuration(k8s manifest files)
- trigger Jenkins or GH Actions which
- ArgoCD conitinues to track changes
- ArgoCD supports
- k8s yaml files
- helm charts
- kustomize
- Git repository that is tracked and sync
- Seperates CI to developers/DevOps and CD to operations/DevOps
- CI pipeline(developers/DevOps) - configured by Jenkins or Github Actions
- Test
- Build Image
- Push to Docker Repo
- Update k8s mnaifest file
- CD pipeline(operations/DevOps) - configured by ArgoCD
- Configured usign ArgoCD with GitOps repsoitory for manifests
- CI pipeline(developers/DevOps) - configured by Jenkins or Github Actions
- Benefits
- k8s configuration defined as Code in Git REpository
- Config files are not applied manually from local laptops
- Same Interface for updating the cluster
- ArgoCD watches changes in cluster as well
- ArgoCD compares desired configuration in the GitOps repo with the actual state in k8s cluster
- if State divirges, argoCD will sync changes back to gitOps repo app configuration
- Full transparency of the cluster so no one can actually do manual changes
- Can ask ArgoCD to not sync manual cluster changes automatically and send an alert instead
- single interface for changes instead of untrackable commands
- version controlled changes
- history of changes
- better team collboration
- Easy Rollback - move back to the last working version which is in App Configuration(Declarative)
- No need to manually revert every update in the cluster
- Cluster Disaster Discovery
- if Cluster is down, pointing app configuration to new cluster will allow app configuration to deploy automatically
- argoCD is based on GitOps and helps implments GitOps principles
- K8s Access Control with Git
- DevOps Team, Operations Team, Junior Engineers, Senior Engineers can:
- Merge Requests
- Senior Engineers
- can approve and merge requests
- Manage Cluster access indirectly with Git without having to create ClusterRole and User resources in Kubernetes
- Engineers no longer need access cluster but need access to git repository
- don't need to give external cluster access to non human users
- jenkins or github action tools
- No cluster credeintials outside of k8s because argoCD is in the cluster
- DevOps Team, Operations Team, Junior Engineers, Senior Engineers can:
- ArgoCD as kubernetes extension
- ArgoCD uses existing k8s functionalities
- using etcd to store data
- using k8s controllers to monitor and compare actual disired state which allows for visibility in the cluster
- Real-time updates of application stae
- ArgoCD uses existing k8s functionalities
- AgoCD makes sure the following are in sync
- Git Repository - desired state
- Kubernetes cluster - actual state
- How to configure ArgoCD
- deploy ArgoCD int k8s cluster
- Extends the k8s API with crd
- allows argocd using kubernetes native yaml files
- Main resource is "Application" which is in
application.yaml
- which git repsitory(source) needs to be configured with which cluster(destination)
- either internal or external clusters
- AppProject Crd
- configures individual application.yamls for different microservices
- and logically group tnem in AppProject crd
- ArgoCD and MultiCluster Setups
- Three Clusters(Dev, Stage, Prod)
- Only have to manage one argoCD instance and configures a fleet of K8s clusters
- In Each environment, deploy changes for the same repository not all at once but onlty after test changes and promotion changes
- Use git branch for each environment
- using overlays with kustomize - see myapp-cluster
- Allows for Continuous integration pipelines for different environments to deploy the application using kustomization overlays
- Is not a replacement for other CI/CD tools
- still need to configure CI poeline for application testing, image building, pushing to docker repo and updating k8s manifest file
- Repalcement for Continuous Delivery for Kubernetes
- Alternatives - flux and jenkinsx
- Demo Steps
- ArgoCD in k8s cluster
- Configure ArgoCD with "Application" CRD
- Test our setup by updating Deployment.yaml
- Enable automatic sync, self-healing, and autmoatic pruning are disabled by default and need to be updated to
application.yaml
- must apply application.yaml for argocd to recognize source of truth gitOps repo
- App of Apps
- an helm chart for example consisting of multiple of applications
- Avoid Risks of secret injection plugins by
- updating network policies to prevent direct access to argo cd components
- enable apssword auth on redis instance that stores secrets
- consider running argocd on its own cluster
- Rolling Updates
- Types
- BlueGreen Rollout - keeps active service reciving production traffic while the the rollout configures the preview service to send traffic to the new version
- Canary Rollout - rollout and scaleup the new version to recieve a certain percentage of traffic, wait for a specific amount of time and set the percentage back to 0, then wait to rollout the service completely
- Must satisfy user before rollout is promoted
- should include service and ingress to expose and test preview service
- rollout is deployed if app has matches rollout deployment
- use kubect rollout create dashboard to promote application
- Types
- speciify blueprint that configures eks cluster
- pipeline - fork blueprints and update username
- deploying blueprints across multiple cluster environments require you to provide stages
- Application Team managed by ApplicationTeam blue print that allows you to define teams and link it to arn principal
- creates the namespace for applications of the configured team
- creating the IAM role that is automatically configured aws-auth configmap
- optionally apply any kubernetes anifest for the team
- set namespace quotas limit
- Configuring GitOps with ArgoCD
- Argo ApppProject per application
sourcRepo
specify the source code for helm, k8s manifests or kustomizedestinations
- specify the kubernetes cluster and namespace
- ArgoCD add ons
- apps on apps configuration
- application configuration that specify the path of helm chart that consists of child applications
- bootstrap values - to specify ingress and additonal add ons for apps on apps configuration
- values - specifies deployment for specific repositories to speicifc namespaces
- apps on apps configuration
- Argo ApppProject per application
- API Server - exposes api consumed by web ui, cli and ci/cd
- rbac enforcement
- listener/forwarder for git webhook events
- repository and cluster credential management(k8s secrets)
- authentication and auth delegation to external identity providers
- invoke app ops(sync, rollback, user-definition actions)
- app management and status reporting
- Repository server - maintains local cache of git repo holding application maniests for generating and returning k8s manifests. needs following inputs
- Repository URL
- revision(commit,tag, branch)
- application path
- template specific settings: parameters, helm values.yaml
- Application controller
- monitors running app and compares live state to desired target state
- takes corrective action if app state is outofSync if enabled
- Responsible for user-defined, preSync, Sync, and Postsync hooks