
Mi volt előbb — a tojás vagy a tojásból kikelt csibe? Elég furcsa kezdés egy Infrastructure-as-Code cikkhez, nem igaz?
Mi az a tojás?
Leggyakrabban az Infrastructure-as-Code (IaC) — egy deklaratív módja az infrastruktúra ábrázolásának. Ebben leírjuk azt az állapotot, amelyet el szeretnénk érni, kezdve a hardver elemekkel, egészen a szoftver konfigurációjáig. Ezért az IaC a következők kezelésére használható:
- Erőforrás biztosítás. Ezek VMs, S3, VPC stb. A főbb eszközök: és .
- . A főbb eszközök: , Chef stb.
Bármely kód git-repozitóriumokban található. Előbb vagy utóbb a csapatvezető úgy dönt, hogy rendet kellene rakni bennük. És refaktorálni fog. És létrehoz egy bizonyos struktúrát. És látni fogja, hogy ez jó dolog.
Az is jó, hogy már létezik és -szolgáltató a Terraformhoz (és ez szoftver konfiguráció). Ezek segítségével az egész projektet kezelhetjük: a csapat tagjai, CI/CD, git-flow stb.
Honnan származik a tojás?
Most már fokozatosan elérkezünk a fő kérdéshez.
Először is, a repóval kell kezdeni, amely leírja más repók szerkezetét, beleértve saját magát is. És természetesen a GitOps keretein belül CI-t kell hozzáadni, hogy automatikusan végrehajtsuk a változtatásokat.
Mi van, ha a Git még nem jött létre?
- Hogyan tároljuk a Gitben?
- Hogyan fogjunk hozzá a CI-hez?
- Ha a GitLab-ot is IaC-val telepítjük, ráadásul Kubernetes-en?
- És a GitLab Runner is Kubernetes-en?
- A Kubernetes pedig egy felhőszolgáltatón van?
Mi jött előbb: a GitLab, ahová feltölthetem a kódom, vagy a kód, amely leírja, hogy milyen GitLab-ra van szükségem?
Tojás és csibe
«3 dínóval” []
Próbáljunk meg készíteni egy ételt, használva felhőszolgáltatóként .
Röviden összefoglalva
Lehet, hogy egy parancsba összesítve?
$ export MY_SELECTEL_TOKEN=
$ curl https://gitlab.com/chicken-or-egg/mks/make/-/snippets/2002106/raw | bashHozzávalók:
- Fiók a my.selectel.ru-tól;
- Token a fiókból;
- Kubernetes ismeretek;
- Helm ismeretek;
- Terraform ismeretek;
- Helm chart GitLab;
- Helm chart GitLab Runner.
Recept:
- Szerezze meg a MY_SELECTEL_TOKEN-t a panelről my.selectel.ru.
- Hozzon létre egy Kubernetes klasztert, átadva neki a fiókból származó tokent.
- Szerezzen KUBECONFIG-ot a létrehozott klasztertől.
- Telepítse a GitLab-ot Kubernetes-en.
- Szerezzen GitLab-token-t a létrehozott GitLab-ból a felhasználó számára. , felhasználó nevében fut, mivel alapvető rendszerbeállításokat módosítanak, de a WordPress közvetlenül egy normál felhasználóként működik..
- Hozzon létre projektstruktúrát a GitLab-ban a GitLab-token használatával.
- Töltse fel a meglévő kódot a GitLab-ba.
- ???
- Profit!
1. lépés. A tokent a következő szakaszban lehet megszerezni: .
2. lépés. Készítjük el a Terraformot a 2 csomópontból álló klaszter „sütéséhez”. Ha biztos benne, hogy elegendő erőforrása van, akkor bekapcsolhatja az automatikus korlátozásokat:
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",
}
}Felhasználó hozzáadása a projekthez:
resource "random_password" "my-k8s-user-pass" {
length = 16
special = true
override_special = "_%@"
}
resource "selectel_vpc_user_v2" "my-k8s-user" {
password = random_password.my-k8s-user-pass.result
name = var.username
enabled = true
}
resource "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
}
resource "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
}Kimeneti adatok:
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
}Indítjuk:
$ 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 
3. lépés. Megkapjuk a kubelkonfigot.
A KUBECONFIG programozott letöltéséhez token-t kell kérni az OpenStack-től:
openstack token issue -c id -f value > tokenEzután ezzel a tokennel kérdést kell indítani a Managed Kubernetes Selectel API-ban. k8s_id visszaadja terraform:
curl -XGET -H "x-auth-token: $(cat token)" "https://ru-3.mks.selcloud.ru/v1/clusters/$(cat k8s_id)/kubeconfig" -o kubeConfig.yamlA kubelkonfigot a panelen keresztül is megszerezhetjük.

4. lépés. Miután a klaszter beállításra került és hozzáféréssel rendelkezünk, hozzá lehet adni a yaml-hoz tetszés szerint.
Szeretem hozzáadni:
- namespace,
- storage class,
- pod security policy és egyéb.
A Selectel esetében az .
Mivel eredetileg a klasztert a ru-3azónában választottam, a Storage Class-t is ebből a zónából kell szereznem.
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: true5. lépés. Beállítjuk a terheléselosztót.
Használni fogjuk a sokak által elterjedt nginx-ingress. Rengeteg útmutató található a telepítéséről, így nem állunk meg ennél.
$ 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.ymlVárunk, amíg megkapja a külső IP-t, körülbelül 3-4 percig:

Megkaptuk a külső IP-t:

6. lépés. Telepítjük a GitLab-ot.
$ 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"Újra várunk, amíg az összes pod feláll.
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
Várakozás gitlabra
./wait_gitlab.sh ../internal/gitlab/gitlab/.pods
várakozás podra...
várakozás podra...
várakozás podra...A podok elindultak:

7. lépés. Megkapjuk a GitLab-token-t.
Először megtudjuk a belépési jelszót:
kubectl get secret -n gitlab gitlab-gitlab-initial-root-password -o jsonpath='{.data.password}' | base64 --decodeMost bejelentkezünk, és megkapjuk a tokent:
python3 get_gitlab_token.py root $GITLAB_PASSWORD http://gitlab.gitlab.$EXTERNAL_IP.nip.io8. lépés. A Git-tárolók helyes hierarchiába rendezése a GitLab Provider segítségével.
cd ../internal/gitlab/hierarchy && terraform apply -input=false -auto-approve planfileSajnos a terraform GitLab provider-ben van egy lebegő . Akkor kézzel kell eltávolítani a konfliktusos projekteket, hogy a tf.state helyreálljon. Ezután futtassa újra a `$ make all` parancsot.
9. lépés. Helyezzük át a helyi tárolókat a szerverre.
$ make push
[master (root-commit) b61d977] Első commit
3 fájl módosítva, 46 beszúrás (+)
új mód 100644 .gitignore
új mód 100644 values.yml
Objektumok felsorolása: 5, kész.
Objektumok számlálása: 100% (5/5), kész.
Delta tömörítés 8 szál maximális használatával
Tömörítési objektumok: 100% (5/5), kész.
Objektumok írása: 100% (5/5), 770 bájt | 770.00 KiB/s, kész.
Összesen 5 (delta 0), újrahasználva 0 (delta 0)Kész:


Zárás
Elértük, hogy a helyi gépünkről deklaratívan irányítsuk az egészet. Most szeretnénk ezeket a feladatokat a CI-be áttenni, és csak a gombokat megnyomni. Ehhez át kell adnunk a helyi állapotainkat (Terraform state) a CI-nek. Arról, hogy ezt hogyan tegyük, a következő részben olvashatsz.
Iratkozzon fel az , hogy ne maradj le az új cikkek megjelenéséről!
Forrás: habr.com
