Which came first, the chicken or the egg? Pretty strange start for an Infrastructure-as-Code article, isn't it?
What is an egg?
Most often, Infrastructure-as-Code (IaC) is a declarative way to represent infrastructure. In it, we describe the state that we want to get, starting from the hardware part, ending with the software configuration. Therefore IaC is used for:
resource provision. These are VMs, S3, VPCs, etc. Basic tools for work: terraform ΠΈ Cloud Formation.
Any code is in git repositories. And sooner or later, the team leader decides that it would be necessary to put things in order in them. And he will refactor. And create some structure. And he will see that it is good.
It's also good that it already exists GitLab ΠΈ GitHub-provider for Terraform (and this is Software Configuration). With their help, you can manage the entire project: team members, CI / CD, git-flow, etc.
Where did the egg come from?
Here we are gradually approaching the main question.
First of all, you need to start with a repository that describes the structure of other repositories, including yourself. And of course, within GitOps, you need to add CI so that changes are automatically implemented.
If Git is not created yet?
How to store it in Git?
How to screw CI?
If we also deploy Gitlab using IaC, and even in Kubernetes?
And GitLab Runner in Kubernetes too?
And Kubernetes in a cloud provider?
What came first: GitLab, where I will upload my code, or code that describes what kind of GitLab I need?
Create a Kubernetes cluster by passing the token from the account to it.
Get KUBECONFIG from the created cluster.
Install GitLab in Kubernetes.
Get GitLab-token from GitLab generated for user root.
Create a project structure in GitLab using GitLab-token.
Push existing code to GitLab.
??
Profit!
Step 1. The token can be obtained in the section API keys.
Step 2. We prepare our Terraform for "baking" a cluster of 2 nodes. If you are sure that you have enough resources for all, then you can enable auto quotas:
Step 8. We bring the Git repositories to the correct hierarchy using the Gitlab Provider.
cd ../internal/gitlab/hierarchy && terraform apply -input=false -auto-approve planfile
Unfortunately, the terraform GitLab provider has a floating a bug. Then you will have to delete the conflicting projects by hand so that tf.state can be fixed. Then re-run the `$ make all` command
Step 9. We transfer local repositories to the server.
We have achieved that we can declaratively manage everything from our local machine. Now I want to transfer all these tasks to CI and only press buttons. To do this, we need to transfer our local states (Terraform state) to CI. How to do this, in the next part.
Subscribe to our blogso as not to miss the release of new articles!