A methodology where all the configurational and/or infrastructure codes are set up in a separate single repository is known as GitOps.
This suits tools like Ansible, Terraform and Kubernetes, where they do require separate files for their configuration.
For example, deployments and services YAML files in Kubernetes.
I will have Kubernetes as my main example here but it applies to most of the configuration and infrastructure management tools.
Though it can be committed to version control, since the updates are done manually it is of not much use to be kept in version control. Another problem with committing is that env variables and other secrets are generally stored in secret and config files, where most of them shouldn’t be available to everyone in the project. This makes it a bit tricky, where someone will have an original secret file and can’t know for a fact whether it is the latest one or not since it is not under version control. We also don’t know who did these changes unless we dig deep into the logs of the Kubernetes service.
So the problem is that we want to automate these configurational and infrastructure codes, at the same time to have easier rollbacks, Use Git as the main source to give permissions to people and not use Kubernetes roles, and check who did this change and when. And also find a way to manage the secrets without explicitly pointing them to the repository.
GitOps aims to solve this problem by having all the infra and config codes in a single repo, Using CI and/OR CD, to build and deploy to the respective hosting environment. With respect to secret management, GitOps generally do not have any specific requirement and can be used like how normally secrets are managed. But preferably there are secret management tools that can solve this issue which is general and not specific to GitOps.
There are several tools that are available that enforce this and I will write about them in the upcoming weeks.
Have a great day. See you at the next one.
]]>