GitOps — DevOps Project 07

The Core Principles

At its core, GitOps advocates for using Git not just for version control but as a single source of truth for declarative infrastructure and applications. It emphasizes the following principles:

• Infrastructure as Code (IaC): Treat infrastructure configurations similarly to application code, enabling teams to manage and version infrastructure alongside application logic.
• Automated Deployments: Utilize continuous integration and continuous deployment (CI/CD) pipelines to automate the process of deploying changes to production environments.
• Immutable Infrastructure: Ensure that all components of an environment are immutable, meaning they cannot be changed once deployed. Any updates require new instances to be spun up.
• Restricted Manual Changes: Limit direct modifications to production environments, enforcing changes to be made through Git repositories. This approach enhances security and traceability.

Setting Up SSH Authentication

To facilitate secure communication between your local machine and remote servers or repositories, setting up SSH authentication is essential. Here’s how to do it:

1. Generate an SSH key pair if you haven’t already. You can do this by running ssh-keygen in your terminal.
2. Add the public key (id_rsa.pub) to your GitHub account under Settings > SSH and GPG keys.
3. Configure your local Git client to use the newly generated private key by editing the ~/.ssh/config file.

Organizing Repositories and Branches

For effective project management, it’s advisable to structure your repositories and branches according to the development lifecycle. Typically, projects have at least two branches:

• Main: Represents the stable version of the application, ready for production deployment.
• Staging: Serves as a pre-production environment where features are tested before being merged into the main branch.

Workflow: From Local Changes to Production Deployment

The GitOps workflow involves making changes locally, pushing them to the staging branch, creating a pull request, and finally merging the changes into the main branch. Here’s a breakdown of the process:

1. Local Development: Make changes to your application or infrastructure code locally.
2. Pushing to Staging: Commit and push your changes to the staging branch. This step allows for testing and review in a controlled environment.
3. Creating a Pull Request: Once the changes are reviewed and approved, create a pull request to merge the changes from the staging branch into the main branch.
4. Merging to Main: After successful review and tests, merge the changes into the main branch, triggering the CI/CD pipeline.
5. Deployment: The CI/CD pipeline builds and pushes the Docker image to a registry (e.g., Docker Hub). Subsequent deployments to production environments are automated based on these images.

we can add secrets from here as well, cool

Settings-> secrets and vars-> actions -> New repo secret

Added repository secrets:

pushed changes to staging branch

Creating a pull request and merging code from staging to main

Successful build-and-push workflow

Image pushed to hub.docker.com

All right! So now everytime code is pushed to the main branch, docker image will be formed and it will be pushed to docker hub.