Coined back in 2009, the DevOps methodology changed the way developers and operational teams collaborated to bring an application to life. Manual communications, redundant tasks along with heavy duty coding consumed much of the product team's bandwidth, leaving little room for quick-fire innovations or constant improvements demanded by end users. A single deployment could take months and one change request could never see the light of the day, lost in the web of approvals or the modular malfunctions it posed to the monolithic application it was meant for. Woven on the backbone of Agile operations, DevOps knot together an automated software development lifecycle (SDLC) where developers and operational teams collaborated in unison to write code, test, run, update, and deploy finally on staging and live. Notably, the larger software cycle was broken into inter-dependent modular bits having their own automated micro-cycles, allowing easy updates, faster releases, and pinned issue resolutions without jeopardizing the entire application at once for one broken line of code!
GitOps, the modern scion of DevOps, tackles the one looping hole lacking in the conventional latter; infrastructure automation. In traditional DevOps, the infrastructure configuration, environment spin-offs, authentications and authorizations, rollback management, and application management of infrastructure (part of the final deployment phase) were mostly manual or disjointed from the core SDLC leading to irreversible delays. Often, final release would get stuck for months resulting in customer satisfaction, budget overruns, and revenue hits.
GitOps utilizes Git repos and its celebrated features of easy collaboration, branching and forking, version control, review management, CI/CD pipelines as single source of truth to define the deployable infrastructure and application code. This is especially vital and tailor-built for the modern IT context involving multiple cloud/on-prem/third-party landscapes, Kubernetes clusters or containerized workloads distributed across ecosystems, and variant applications running for a single BU.
Like source code stored in the original repos for the SDLC counterpart, infrastructure provisioning and configuration codes (IaC) are stored in Git repos and shared with requisite teams for utilization. Automated features ensure that the infrastructure is adequately provisioned, maintained, and performance monitored for live application deployments with easy version control and rollback features, thereby granting a coherent, unified environment to automate the infrastructure and application development, management lifecycle. This vastly accelerates software production and innovation releases, including quick improvements to meet user needs.
Key Segments of a GitOps Workflow: An Overview
- Git repository: Single source of truth for application infrastructure configuration and code
- CI/CD Pipeline: For building, testing, deploying the application on the concerned infrastructure
- Deployment tool: For administering the application resources in the target infrastructure environment
- Monitoring system: Tracking application on the provisioned infrastructure
GitOps Implementation with ArgoCD
ArgoCD is one of the most popular GitOps tools, a GitOps-based continuous delivery tool with pull model, designed specifically for deploying and managing applications on Kubernetes clusters/containerized infrastructure. It follows a declarative in Git repositories using YAML manifests.
ArgoCD Best Practices:
- Separating source code and configuration repositories
- Selecting a suitable number of deployment configuration repositories
- Preventing external changes to manifests
- Testing manifests before each commit
Designing a CI/CD Workflow with ArgoCD
The CI/CD workflow with ArgoCD involves several components functioning together to manage the deployment and synchronization of applications. Here are the key components of the ArgoCD workflow:
- ArgoCD Server:
The central component responsible for the core ArgoCD functionality. It manages the application deployment lifecycle, syncing declared applications with the desired state from Git repositories.
- ArgoCD API Server:
The API server exposes RESTful APIs that clients, including the ArgoCD UI and CLI, use to interact with the ArgoCD server. It handles user authentication, authorization, and application lifecycle management.
- ArgoCD UI:
A web-based user interface that allows users to visualize, monitor, and manage applications deployed with ArgoCD. The UI provides an overview of applications, their status, and allows users to perform actions such as syncing, rolling back, and viewing application details.
- ArgoCD CLI:
The ArgoCD command-line interface provides a set of commands for interacting with the ArgoCD API. It's a powerful tool for automation, scripting, and advanced usage of ArgoCD.
- Application Controller:
The application controller is responsible for monitoring the state of applications and comparing it with the desired state specified in Git repositories. When there are changes, the controller triggers a sync operation to bring the application to the desired state.
- Repo Server:
The repo server is responsible for serving Git repositories containing Kubernetes manifests for applications. It watches Git repositories for changes and notifies the application controller when updates occur.
- Redis (Optional):
ArgoCD can use Redis as a caching layer to improve performance and scalability. Redis stores information about application state, comparison results, and other data. While Redis is optional, it is recommended for larger installations.
Dex is an OpenID Connect (OIDC) identity provider used for user authentication. It allows you to integrate ArgoCD with external authentication providers, such as LDAP or OAuth, for secure user authentication.
These components function in cohesion to ensure continuous delivery of applications risk-proof on Kubernetes clusters, following the GitOps best principles. ArgoCD allows users to define the desired state of their applications and underlying infra parameters in Git repositories and automatically syncs the cluster to match that state. The components collaborate to ensure consistency and provide a user-friendly interface for managing the deployment lifecycle.
ArgoCD Deployment: Step by Step
Add Deployment Manifest to the Application Repository
Run these commands to commit and push the changes. Use your GitHub PAT when prompted for the password:
git commit -m"Add deployment manifest"
- Define a Git Repository in ArgoCD
- Log out and then login into the ArgoCD web console.
- Click the settings button.
- Click Repositories.
- Click CONNECT REPO
- Click the Choose your connection method drop down and select VIA HTTPS
Enter the following values:
Repository URL: https://github.com/your GITHub user/gitops-demo-app
Username: Your GitHub user
Password: Your GitHub PAT
At the top, click CONNECT
Make sure the connection is successful.
- Define an Application
An application is basically a folder inside the Git repo where manifest YAML files are stored. We will now define an application in ArgoCD.
- Open the menu for the Git repo and click Create application.
- For the application's name enter demo. The name must be lowercase and aside from letters and numbers can only have “-” or “.” in it.
- For the project, name enter default. It must be default at this time.
- Leave the synchronization policy to manual for now.
- Scroll to the SOURCE section.
- In the Revision area, enter main as the branch name.
In the Path text box enter gitops-config. This is where we store our YAML files.
- In the DESTINATION section, under cluster URL, enter https://kubernetes.default.svc. This tells ArgoCD that the application will be deployed in the same cluster as where ArgoCD itself is installed.
- In the Namespace text box enter the default
- Finally click the CREATE button at the top.
- Verify that the application is created. The status will show as Missing because we have never synchronized the application yet.
Synchronize the Application
This step will make ArgoCD pull the deployment manifest file and apply it to the cluster.
Click the application's name to view the manifest details.
As we have defined in the deployment.yaml file, a service component called gitops-demo, and a deployment component called gitops-demo will be created.
- Click the SYNC button at the top to begin the synchronization process.
Then, click SYNCHRONIZE.
Verify that the synchronization went without an error.
In the Terminal, run this command to verify that the application's pod is up and running: kubectl get pods
Test the Application
Access the application using LoadBalancer.
GitOps on AWS with Cloud-native tools and ArgoCD
GitOps as an operating model can be seamlessly blueprinted for development and infrastructure environments running on AWS cloud. GitOps is widely deployed to provision critical applications on AWS and manage the underlying infrastructure at scale. ArgoCD, one of the most popular GitOps continuous delivery tools, is used to manage application provisioning and deployment on AWS Kubernetes clusters, the Amazon Elastic Kubernetes Service (EKS). On the spin, GitOps environments are also configured where the base storage/repositories are spread across Git libraries and Amazon storage systems such as S3 buckets, Amazon DynamoDB, or Amazon Simple Queue Service (SQS). AWS-native services along with commonly used ArgoCD tools could be helpful in building an extensible, available, and reliable multi-cluster GitOps system for organizations running their critical applications on AWS.
Cloud4C, one of the world's leading application-focused cloud MSPs and an AWS Advanced Tier Services partner, is trusted by Fortune 500 companies for its automation-driven multi-cloud migration, modernization, and managed services in a single SLA from infra till application login. We lead with DevOps style delivery, ensuring collaborative, autonomous, and platform-driven approach to mission-critical application, asset transformations, helping firms achieve their digital evolutions at scale, speed, and at no risk. Connect with our experts today.