🥇Pollo o uovo: analizziamo IaC

Cosa è arrivato prima — l'uccello o l'uovo? È un inizio piuttosto strano per un articolo su Infrastructure-as-Code, non credi?

Cosa è un uovo?

Nella maggior parte dei casi, Infrastructure-as-Code (IaC) è un modo dichiarativo di rappresentare l'infrastruttura. In esso descriviamo lo stato che vogliamo ottenere, partendo dall'hardware fino alla configurazione del software. Ecco perché IaC viene utilizzato per:

Provisioning delle Risorse. Questi sono VMs, S3, VPC, ecc. Gli strumenti principali per lavorare sono: Terraform e CloudFormation.
Configurazione del Software. Gli strumenti principali sono: Ansible, Chef, ecc.

Qualsiasi codice si trova nei repository git. Prima o poi, il team leader deciderà che è ora di mettere ordine. E lui rifattorazione. E creerà una certa struttura. E vedrà che è una cosa positiva.

È anche positivo che esista già GitLab e GitHub-un provider per Terraform (e questo è Software Configuration). Con essi puoi gestire l'intero progetto: membri del team, CI/CD, git-flow, ecc.

Da dove è uscito l'uovo?

Così stiamo gradualmente arrivando alla domanda principale.

Innanzitutto, bisogna partire dal repository che descrive la struttura degli altri repository, incluso se stesso. E naturalmente, nell'ambito di GitOps, è necessario aggiungere CI, affinché le modifiche vengano eseguite automaticamente.

Cosa fare se Git non è ancora stato creato?

Come memorizzarlo in Git?
Come integrare CI?
E se stiamo anche implementando GitLab con IaC, e in Kubernetes?
E GitLab Runner anche in Kubernetes?
E Kubernetes presso un fornitore cloud?

Cosa è apparso prima: GitLab, dove caricherò il mio codice, o il codice che descrive quale GitLab mi serve?

Il pollo e le uova

«Oyakodon3 con un dinosauro» [src]

Proviamo a preparare un piatto utilizzando come fornitore cloud Managed Kubernetes Selectel.

TL;DR

Si può fare tutto in un solo comando?

$ export MY_SELECTEL_TOKEN=
$ curl https://gitlab.com/chicken-or-egg/mks/make/-/snippets/2002106/raw | bash

Ingredienti:

Account da my.selectel.ru;
Token dell'account;
Competenze in Kubernetes;
Competenze in Helm;
Competenze in Terraform;
Helm chart GitLab;
Helm chart GitLab Runner.

Ricetta:

Ottenere MY_SELECTEL_TOKEN dal pannello my.selectel.ru.
Creare un cluster Kubernetes, passando il token dell'account.
Ottenere KUBECONFIG dal cluster creato.
Installare GitLab in Kubernetes.
Ottenere GitLab-token da GitLab creato per l'utente root.
Creare la struttura dei progetti in GitLab, utilizzando GitLab-token.
Caricare il codice esistente in GitLab.
???
Profitto!

Passo 1. Il token può essere ottenuto nella sezione Chiavi API.

Passo 2. Prepariamo il nostro Terraform per il "baking" di un cluster di 2 nodi. Se sei sicuro di avere sufficienti risorse, puoi attivare le quote automatiche:

provider "selectel" {
 token = var.my_selectel_token
}

variable "my_selectel_token" {}
variable "username" {}
variable "region" {}


resource "selectel_vpc_project_v2" "my-k8s" {
 name = "my-k8s-cluster"
 theme = {
   color = "269926"
 }
 quotas {
   resource_name = "compute_cores"
   resource_quotas {
     region = var.region
     zone = "${var.region}a"
     value = 16
   }
 }
 quotas {
   resource_name = "network_floatingips"
   resource_quotas {
     region = var.region
     value = 1
   }
 }
 quotas {
   resource_name = "load_balancers"
   resource_quotas {
     region = var.region
     value = 1
   }
 }
 quotas {
   resource_name = "compute_ram"
   resource_quotas {
     region = var.region
     zone = "${var.region}a"
     value = 32768
   }
 }
 quotas {
   resource_name = "volume_gigabytes_fast"
   resource_quotas {
     region = var.region
     zone = "${var.region}a"
     # (20 * 2) + 50 + (8 * 3 + 10)
     value = 130
   }
 }
}

resource "selectel_mks_cluster_v1" "k8s-cluster" {
 name         = "k8s-cluster"
 project_id   = selectel_vpc_project_v2.my-k8s.id
 region       = var.region
 kube_version = "1.17.9"
}

resource "selectel_mks_nodegroup_v1" "nodegroup_1" {
 cluster_id        = selectel_mks_cluster_v1.k8s-cluster.id
 project_id        = selectel_mks_cluster_v1.k8s-cluster.project_id
 region            = selectel_mks_cluster_v1.k8s-cluster.region
 availability_zone = "${var.region}a"
 nodes_count       = 2
 cpus              = 8
 ram_mb            = 16384
 volume_gb         = 15
 volume_type       = "fast.${var.region}a"
 labels            = {
   "project": "my",
 }
}

Aggiungiamo un utente al progetto:

risorsa "random_password" "my-k8s-user-pass" {
 lunghezza = 16
 speciale = true
 override_special = "_%@"
}

risorsa "selectel_vpc_user_v2" "my-k8s-user" {
 password = random_password.my-k8s-user-pass.result
 name = var.username
 enabled  = true
}

risorsa "selectel_vpc_keypair_v2" "my-k8s-user-ssh" {
 public_key = file("~/.ssh/id_rsa.pub")
 user_id    = selectel_vpc_user_v2.my-k8s-user.id
 name = var.username
}

risorsa "selectel_vpc_role_v2" "my-k8s-role" {
 project_id = selectel_vpc_project_v2.my-k8s.id
 user_id    = selectel_vpc_user_v2.my-k8s-user.id
}

Uscita:

output "project_id" {
 value = selectel_vpc_project_v2.my-k8s.id
}

output "k8s_id" {
 value = selectel_mks_cluster_v1.k8s-cluster.id
}

output "user_name" {
 value = selectel_vpc_user_v2.my-k8s-user.name
}

output "user_pass" {
 value = selectel_vpc_user_v2.my-k8s-user.password
}

Iniziamo:

$ env 
TF_VAR_region=ru-3 
TF_VAR_username=diamon 
TF_VAR_my_selectel_token= 
terraform plan -out planfile

$ terraform apply -input=false -auto-approve planfile

Passo 3. Otteniamo il kubeconfig.

Per scaricare programmaticamente il KUBECONFIG, è necessario ottenere un token da OpenStack:

openstack token issue -c id -f value > token

E con questo token fare una richiesta all'API Managed Kubernetes di Selectel. k8s_id restituisce terraform:

curl -XGET -H "x-auth-token: $(cat token)" "https://ru-3.mks.selcloud.ru/v1/clusters/$(cat k8s_id)/kubeconfig" -o kubeConfig.yaml

Il kubeconfig può anche essere ottenuto tramite il pannello.

Passo 4. Dopo che il cluster è stato creato e abbiamo accesso, possiamo aggiungere yaml aggiuntivo a piacimento.

Preferisco aggiungere:

namespace,
classe di archiviazione,
politiche di sicurezza dei pod e altro.

Classe di archiviazione per Selectel può essere preso dal repository ufficiale.

Poiché inizialmente ho scelto un cluster nella zona ru-3a, anche la Storage Class deve essere di questa zona.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
 name: fast.ru-3a
 annotations:
   storageclass.kubernetes.io/is-default-class: "true"
provisioner: cinder.csi.openstack.org
parameters:
 type: fast.ru-3a
 availability: ru-3a
allowVolumeExpansion: true

Passo 5. Configuriamo il bilanciatore di carico.

Utilizzeremo il comune nginx-ingress. Ci sono già molte istruzioni per la sua installazione, quindi non ci soffermeremo su questo.

$ helm repo add nginx-stable https://helm.nginx.com/stable
$ helm upgrade nginx-ingress nginx-stable/nginx-ingress -n ingress --install -f ../internal/K8S-cluster/ingress/values.yml

Aspettiamo che riceva un IP esterno per circa 3-4 minuti:

Ricevuto IP esterno:

Passo 6. Installiamo GitLab.

$ helm repo add gitlab https://charts.gitlab.io
$ helm upgrade gitlab gitlab/gitlab -n gitlab --install -f gitlab/values.yml --set "global.hosts.domain=gitlab.$EXTERNAL_IP.nip.io"

Aspettiamo di nuovo che tutti i pod siano attivi.

kubectl get po -n gitlab
NAME                                      	READY   STATUS  	RESTARTS   AGE
gitlab-gitaly-0                           	0/1 	Pending 	0      	0s
gitlab-gitlab-exporter-88f6cc8c4-fl52d    	0/1 	Pending 	0      	0s
gitlab-gitlab-runner-6b6867c5cf-hd9dp     	0/1 	Pending 	0      	0s
gitlab-gitlab-shell-55cb6ccdb-h5g8x       	0/1 	Init:0/2	0      	0s
gitlab-migrations.1-2cg6n                 	0/1 	Pending 	0      	0s
gitlab-minio-6dd7d96ddb-zd9j6             	0/1 	Pending 	0      	0s
gitlab-minio-create-buckets.1-bncdp       	0/1 	Pending 	0      	0s
gitlab-postgresql-0                       	0/2 	Pending 	0      	0s
gitlab-prometheus-server-6cfb57f575-v8k6j 	0/2 	Pending 	0      	0s
gitlab-redis-master-0                     	0/2 	Pending 	0      	0s
gitlab-registry-6bd77b4b8c-pb9v9          	0/1 	Pending 	0      	0s
gitlab-registry-6bd77b4b8c-zgb6r          	0/1 	Init:0/2	0      	0s
gitlab-shared-secrets.1-pc7-5jgq4         	0/1 	Completed   0      	20s
gitlab-sidekiq-all-in-1-v1-54dbcf7f5f-qbq67   0/1 	Pending 	0      	0s
gitlab-task-runner-6fd6857db7-9x567       	0/1 	Pending 	0      	0s
gitlab-webservice-d9d4fcff8-hp8wl         	0/2 	Pending 	0      	0s
Waiting gitlab
./wait_gitlab.sh ../internal/gitlab/gitlab/.pods
waiting for pod...
waiting for pod...
waiting for pod...

I pod sono attivi:

Passaggio 7. Otteniamo il token GitLab.

Innanzitutto scopriamo la password per l'accesso:

kubectl get secret -n gitlab gitlab-gitlab-initial-root-password -o jsonpath='{.data.password}' | base64 --decode

Ora ci autorizziamo e otteniamo il token:

python3 get_gitlab_token.py root $GITLAB_PASSWORD http://gitlab.gitlab.$EXTERNAL_IP.nip.io

Passaggio 8. Ordiniamo i repository Git nella corretta gerarchia utilizzando Gitlab Provider.

cd ../internal/gitlab/hierarchy && terraform apply -input=false -auto-approve planfile

Purtroppo, nel provider GitLab di Terraform c'è un bug intermittente bug. A quel punto sarà necessario rimuovere manualmente i progetti in conflitto per ripristinare tf.state. Poi riavvia il comando `$ make all`

Passo 9. Trasferiamo i repository locali sul server.

$ make push

[master (commit radice) b61d977]  Commit iniziale
 3 file cambiati, 46 inserimenti(+)
 crea modalità 100644 .gitignore
 crea modalità 100644 values.yml
Enumerazione degli oggetti: 5, fatto.
Conteggio oggetti: 100% (5/5), fatto.
Compressione delta utilizzando fino a 8 thread
Compressione oggetti: 100% (5/5), fatto.
Scrittura oggetti: 100% (5/5), 770 byte | 770.00 KiB/s, fatto.
Totale 5 (delta 0), riutilizzati 0 (delta 0)

Fatto:

Conclusione

Siamo riusciti a gestire tutto in modo dichiarativo dalla nostra macchina locale. Ora vogliamo trasferire tutte queste attività in CI e premere solo i pulsanti. Per fare ciò, è necessario trasferire i nostri stati locali (Terraform state) in CI. Di come farlo ne parleremo nella prossima parte.