Typical Kubernetes CI/CD pipeline, also known as the #PushModel
This model follows a pipeline which, as you can see, we can defined as unilinear and unidirectional: it starts from the developer, follows all the steps of the #CI and, finally, it is the same CI tool that also handles the Continuous Deployment of the application in its target environment.
Although not inherently wrong, this process can present some weaknesses: first of all, the need to provide the target environment credentials to the CI/#CD tool. Second, we see a CI tool that is unable to detect/alert us of discrepancies between the desired state and the current one and forces us to install a second tool that is in charge of monitoring the state of the application.
GitOps: benefits and challenges (and how to deal with them)
No doubt, GitOps can offer many benefits. First, it makes the system fully observable, both by you and by an automated tool. It assures you that what you see in the repository environment is perfectly in line with the Kubernetes cluster, independently making the necessary implementations to match the current state of the system with the desired state (consequently also increasing the verifiability of the system!).
Moreover, GitOps shares an essential benefit with Kubernetes: the declarative model on which the work of the operators is based, thanks to which you can see an increase in productivity. Finally, the Pull model enhances system security by simplifying the problem of having to expose the Kubernetes APIs to your Continuous Integration.
To be absolutely sure that you can take full advantage of these benefits, however, attention must be paid to aspects that can lead to problems if not properly managed. Indeed, it is important to leverage the repository environment and pipelines to prevent, as much as possible, the simultaneous push to the same repository. If Git found that the remote repository was no longer aligned because, in the meantime, another pipeline pushed on the same repository and on the same branch, it would no longer be able to push the changes.
So what are our recommendations to avoid these problems?
First, if possible, we recommend that you always use two repositories, one for your application code and the other as storage for your manifests. Moreover, always remember that you should never store sensitive data in the repository environment. It is true that GitHub helps make your system more secure, but it is still a good idea to take this precaution.
By following these two simple tips and best practices, you can create modern and Cloud Native applications, enjoying all the various benefits that the GitOps paradigm has to offer and will continue to offer with its ever-growing development.
Comments