I Push the Button, Argo CD Do the Magic Deployments

Argo CD — Declarative GitOps CD for Kubernetes

Photo by SpaceX on Unsplash

This specific blog post about Argo CD is like a “microservice :)” in the larger cloud native architecture of our main article about Cloud Native— https://medium.com/@raymondsquared/cloud-native-without-strings-2e7babf78c85

Continuous Integration and Continuous Delivery/Deployment (CI/CD)
Modern software development requires a streamlined delivery pipeline to achieve optimal efficiency. Continuous Integration and Continuous Delivery/Deployment (CI/CD) provide a robust framework for this purpose. Continuous Integration (CI) offers seamless integration of code changes from multiple developers by facilitating automated testing. This proactive approach not only safeguards code quality but also accelerates development cycles through early bug detection. Continuous Delivery/Deployment (CD), on the other hand, automates the deployment process, enabling frequent and reliable software releases. By leveraging automation for testing, builds, packaging, deployments and promotions, CI/CD minimises manual errors, enhanced collaboration between development teams, and empowers businesses to adapt swiftly to market demands. Ultimately, this translates to increased agility and a competitive advantage in today’s dynamic digital landscape.

Why is CD alone essential? Can I use CI/CD as one single unit?
Separating Continuous Delivery (CD) from Continuous Integration (CI) allows for a dedicated focus on automating the release and deployment processes, enhancing control and flexibility in software delivery. Features like blue-green deployments facilitate seamless traffic swaps between different versions of an application, minimising downtime and enabling quick rollback capabilities in case of issues. Canary deployments enable gradual rollout of changes to a small subset of users or infrastructure, providing early feedback and reducing the risk of widespread disruption. Additionally, promotion mechanisms automate the progression of tested changes through various environments, ensuring consistency and reliability in deployment pipelines. Rollback capabilities offer a safety net by swiftly reverting to a previous stable version if necessary. While CI and CD can be integrated into a unified pipeline (CI/CD), separating CD allows for specialised tools and processes tailored specifically to deployment automation, optimising the efficiency and reliability of software releases.

Argo CD secret sauce?

GitOps — YAML
Pull mechanism for drift detection.

Argo CD distinguishes itself through its innovative Unique Selling Propositions, notably GitOps via YAML and its pull mechanism for drift detection. By adopting GitOps principles, Argo CD allows for declarative configuration management using YAML files, enabling seamless synchronisation of application states with Git repositories. This not only simplifies versioning and collaboration but also ensures consistency across environments. The pull mechanism enhances reliability by continuously monitoring for configuration drifts and automatically detecting discrepancies, thereby maintaining the desired state of applications. These features collectively empower organisations to achieve robust, scalable, and automated Kubernetes deployments with enhanced efficiency.

Typical Modern CI/CD

In a typical modern CI/CD process, the workflow unfolds as follows:

1. Developers commit code changes to the repository, illustrated on the left side of the workflow.
2. The system, guided by the project’s branching strategy, retrieves the code from the repository. It proceeds to execute tests to validate the code’s functionality and quality. Once tests pass successfully, the system packages the application into an artifact stored in a designated artifact repository, such as Artifactory.
3. Upon successful completion of the CI phase, Continuous Delivery (CD) takes over. CD automates the deployment process by fetching the deployment configuration tailored for the target environment. This configuration specifies how the application should be deployed and configured on the deployment target server.
4. The deployment target server receives and interprets the deployment configuration, fetching the built artifact from the artifact repository. Subsequently, it orchestrates the deployment across multiple application servers, ensuring that the latest version of the application is deployed and running correctly. This systematic approach not only automates the software delivery pipeline but also ensures consistency, reliability, and efficiency in deploying applications to production and other environments.

CI/CD with Kubernetes

In the Kubernetes ecosystem, the deployment process follows a structure similar to the above modern CI/CD workflow. However, a notable distinction lies in how deployments are orchestrated. Instead of the deployment server directly handling the deployment process, it generates and transmits a YAML deployment configuration to Kubernetes (k8s) worker nodes. These worker nodes are responsible for fetching the built artifact from the designated artifact repository, such as an artifact repository, before initiating the deployment into pods. This distributed approach leverages Kubernetes’ container orchestration capabilities to efficiently manage application deployments across clusters of nodes, ensuring scalability, resilience, and optimal resource utilisation within dynamic and containerised environments.

Argo CD — Secret Sauce

Argo CD distinguishes itself with a unique approach through its pull-based drift detection mechanism. This feature actively monitors configuration changes, comparing the desired state specified in the code repository with the actual state deployed in Kubernetes. By continuously detecting discrepancies between the intended and current configurations, Argo CD ensures alignment and enables automated adjustments to maintain consistency across environments. This proactive approach not only enhances reliability but also simplifies the management of Kubernetes applications, offering robust control and operational efficiency.

Demo

Why Not

Its primary limitations include a focus limited to applications deployment Kubernetes clusters.
Argo CD itself requires deployment within a Kubernetes environment to work.

Argo CD presents notable advantages for Kubernetes-based deployments but may not be suitable for all scenarios. Its primary limitations include a focus limited to Kubernetes clusters, excluding direct support for serverless functions such as Serverless (Azure Functions, Lambda and Google Cloud Functions) or virtual machines deployments. Additionally, Argo CD itself requires deployment within a Kubernetes environment to operate effectively. For more diverse deployment needs that extend beyond Kubernetes, traditional CI/CD pipelines offer broader deployment options and may be more appropriate.

Other notes:

Argo CD can be deployed in various ways to support the scale and reliability metrics that the business needs:
- One Argo CD per environment (staging, dev, and production)
- One Argo CD per domain (based on DDD) — the most recommended approach
- One Argo CD per service/application

Additionally, Kargo — https://kargo.akuity.io/ can be used for orchestrating ArgoCD and managing promotions across different environments.

Alternatively, considering managed Argo CD services, such as those offered by providers like https://akuity.io/, can provide the benefits of Argo CD without the complexities of deployment management. These options cater to different deployment requirements and offer flexibility depending on organisational needs and infrastructure setups.

To contribute, roll out your code reinforcements into Argo CD’s GitHub battalion — https://github.com/argoproj