
Cosa è apparso prima: il pollo o l'uovo? Un inizio piuttosto strano per un articolo su Infrastructure-as-Code, non credi?
Cos'è un uovo?
Spesso 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. Pertanto, IaC è utilizzato per:
- Provisionamento delle risorse. Questi sono VM, S3, VPC, ecc. Gli strumenti principali per lavorare sono: e .
- . Gli strumenti principali sono: , Chef, ecc.
Qualsiasi codice è presente nei repository git. Prima o poi, il team leader deciderà che è necessario mettere ordine in essi. E inizia a rifattorizzare. E creerà una certa struttura. E vedrà che è una cosa positiva.
È anche una cosa positiva che esista già e -un provider per Terraform (e questo è Configurazione software). Con loro è possibile gestire l'intero progetto: membri del team, CI/CD, git-flow, ecc.
Da dove è venuto l'uovo?
Eccoci quindi a porre la domanda principale.
Prima di tutto bisogna iniziare con un repository che descrive la struttura di altri repository, incluso se stesso. E naturalmente, nell'ambito del GitOps è necessario aggiungere CI affinché le modifiche vengano eseguite automaticamente.
Se Git non è ancora stato creato?
- Come conservarlo in Git?
- Come integrare il CI?
- Se stiamo anche creando GitLab utilizzando IaC, e in Kubernetes?
- E GitLab Runner sempre in Kubernetes?
- E Kubernetes su un provider cloud?
Cosa è apparso prima: GitLab, su cui caricherò il mio codice, o il codice che descrive quale GitLab mi serve?
Il pollo con le uova
«3 con il dinosauro» []
Proviamo a preparare un piatto, utilizzando come provider cloud .
TL;DR
È possibile farlo tutto in un unico comando?
$ export MY_SELECTEL_TOKEN=
$ curl https://gitlab.com/chicken-or-egg/mks/make/-/snippets/2002106/raw | bashIngredienti:
- Account da my.selectel.ru;
- Token dall'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 dal GitLab creato per l'utente root.
- Creare una struttura di progetti in GitLab utilizzando GitLab-token.
- Pushare il codice esistente in GitLab.
- ???
- Profitto!
Passo 1. Il token può essere ottenuto nella sezione .
Passo 2. Prepariamo il nostro Terraform per "cuocere" un cluster di 2 nodi. Se sei sicuro di avere abbastanza risorse, puoi attivare le quote automatiche:
fornitore "selectel" {
token = var.my_selectel_token
}
variabile "my_selectel_token" {}
variabile "username" {}
variabile "region" {}
risorsa "selectel_vpc_project_v2" "my-k8s" {
nome = "my-k8s-cluster"
tema = {
colore = "269926"
}
quote {
nome_risorsa = "compute_cores"
risorse_quote {
regione = var.region
zona = "${var.region}a"
valore = 16
}
}
quote {
nome_risorsa = "network_floatingips"
risorse_quote {
regione = var.region
valore = 1
}
}
quote {
nome_risorsa = "load_balancers"
risorse_quote {
regione = var.region
valore = 1
}
}
quote {
nome_risorsa = "compute_ram"
risorse_quote {
regione = var.region
zona = "${var.region}a"
valore = 32768
}
}
quote {
nome_risorsa = "volume_gigabytes_fast"
risorse_quote {
regione = var.region
zona = "${var.region}a"
# (20 * 2) + 50 + (8 * 3 + 10)
valore = 130
}
}
}
risorsa "selectel_mks_cluster_v1" "k8s-cluster" {
nome = "k8s-cluster"
progetto_id = selectel_vpc_project_v2.my-k8s.id
regione = var.region
kube_version = "1.17.9"
}
risorsa "selectel_mks_nodegroup_v1" "nodegroup_1" {
cluster_id = selectel_mks_cluster_v1.k8s-cluster.id
progetto_id = selectel_mks_cluster_v1.k8s-cluster.project_id
regione = selectel_mks_cluster_v1.k8s-cluster.region
zona_di_disponibilità = "${var.region}a"
conteggio_nodi = 2
cpus = 8
ram_mb = 16384
volume_gb = 15
tipo_volume = "fast.${var.region}a"
etichette = {
"progetto": "my",
}
}Aggiungiamo un utente al progetto:
risorsa "random_password" "my-k8s-user-pass" {
lunghezza = 16
speciale = true
sovrascrivi_speciale = "_%@"
}
risorsa "selectel_vpc_user_v2" "my-k8s-user" {
password = random_password.my-k8s-user-pass.result
nome = var.username
abilitato = true
}
risorsa "selectel_vpc_keypair_v2" "my-k8s-user-ssh" {
chiave_pubblica = file("~/.ssh/id_rsa.pub")
id_utente = selectel_vpc_user_v2.my-k8s-user.id
nome = var.username
}
risorsa "selectel_vpc_role_v2" "my-k8s-role" {
progetto_id = selectel_vpc_project_v2.my-k8s.id
id_utente = selectel_vpc_user_v2.my-k8s-user.id
}Output:
output "project_id" {
valore = selectel_vpc_project_v2.my-k8s.id
}
output "k8s_id" {
valore = selectel_mks_cluster_v1.k8s-cluster.id
}
output "user_name" {
valore = selectel_vpc_user_v2.my-k8s-user.name
}
output "user_pass" {
valore = selectel_vpc_user_v2.my-k8s-user.password
}Avviamo:
$ 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 > tokenE già 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.yamlIl kubeconfig può essere ottenuto anche tramite il pannello.

Passo 4. Dopo che il cluster è stato creato e abbiamo accesso, possiamo aggiungere yaml a piacere.
Preferisco aggiungere:
- namespace,
- classe di archiviazione,
- policy di sicurezza del pod e altro.
per Selectel si può prendere da .
Poiché inizialmente ho scelto un cluster nella zona ru-3a, quindi ho bisogno della classe di archiviazione da 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: truePassaggio 5. Configuriamo il bilanciatore di carico.
Utilizzeremo lo standard per molti nginx-ingress. Ci sono già molte istruzioni su come installarlo, 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.ymlAspettiamo che ottenga un IP esterno per circa 3-4 minuti:

Abbiamo ottenuto un IP esterno:

Passaggio 6. Installa 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 si avviino.
kubectl get po -n gitlab
NOME PRONTO STATO RIAVVI ETÀ
gitlab-gitaly-0 0/1 In attesa 0 0s
gitlab-gitlab-exporter-88f6cc8c4-fl52d 0/1 In attesa 0 0s
gitlab-gitlab-runner-6b6867c5cf-hd9dp 0/1 In attesa 0 0s
gitlab-gitlab-shell-55cb6ccdb-h5g8x 0/1 Inizializzazione:0/2 0 0s
gitlab-migrations.1-2cg6n 0/1 In attesa 0 0s
gitlab-minio-6dd7d96ddb-zd9j6 0/1 In attesa 0 0s
gitlab-minio-create-buckets.1-bncdp 0/1 In attesa 0 0s
gitlab-postgresql-0 0/2 In attesa 0 0s
gitlab-prometheus-server-6cfb57f575-v8k6j 0/2 In attesa 0 0s
gitlab-redis-master-0 0/2 In attesa 0 0s
gitlab-registry-6bd77b4b8c-pb9v9 0/1 In attesa 0 0s
gitlab-registry-6bd77b4b8c-zgb6r 0/1 Inizializzazione:0/2 0 0s
gitlab-shared-secrets.1-pc7-5jgq4 0/1 Completato 0 20s
gitlab-sidekiq-all-in-1-v1-54dbcf7f5f-qbq67 0/1 In attesa 0 0s
gitlab-task-runner-6fd6857db7-9x567 0/1 In attesa 0 0s
gitlab-webservice-d9d4fcff8-hp8wl 0/2 In attesa 0 0s
Attesa gitlab
./wait_gitlab.sh ../internal/gitlab/gitlab/.pods
in attesa del pod...
in attesa del pod...
in attesa del pod...I pod sono stati avviati:

Passo 7. Otteniamo il token di GitLab.
Per prima cosa scopriamo la password per accedere:
kubectl get secret -n gitlab gitlab-gitlab-initial-root-password -o jsonpath='{.data.password}' | base64 --decodeOra ci autentichiamo e otteniamo il token:
python3 get_gitlab_token.py root $GITLAB_PASSWORD http://gitlab.gitlab.$EXTERNAL_IP.nip.ioPassaggio 8. Mettiamo in ordine i repository Git con Gitlab Provider.
cd ../internal/gitlab/hierarchy && terraform apply -input=false -auto-approve planfileSfortunatamente, nel provider GitLab di terraform ci sono conflitti . Dobbiamo quindi eliminare manualmente i progetti conflittuali affinché tf.state si ripristini. Poi riavvia il comando `$ make all`
Passaggio 9. Trasferiamo i repository locali sul server.
$ make push
[master (root-commit) b61d977] Commit iniziale
3 file modificati, 46 inserimenti(+)
crea modalità 100644 .gitignore
crea modalità 100644 values.yml
Enumerando oggetti: 5, fatto.
Controllando 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)Fattoo:


Conclusione
Siamo riusciti a gestire tutto in modo dichiarativo dalla nostra macchina locale. Ora vogliamo trasferire tutte queste attività nel CI e premere solo dei pulsanti. Per fare ciò, dobbiamo trasferire i nostri stati locali (Terraform state) nel CI. Come faremo questo sarà descritto nella parte successiva.
Iscriviti al nostro , per non perdere l'uscita di nuovi articoli!
Fonte: habr.com
