Што з'явілася раней - курыца ці яйка? Даволі дзіўны пачатак для артыкула пра Infrastructure-as-Code, ці не так?
Што такое яйка?
Часцей за ўсё Infrastructure-as-Code (IaC) – дэкларатыўны спосаб прадстаўлення інфраструктуры. У ім мы апісваем стан, які жадаем атрымаць, пачынальна ад жалезнай часткі, сканчаючы канфігурацыяй ПА. Таму IaC выкарыстоўваецца для:
- Resource Provision. Гэта VMs, S3, VPC і т.д. Асноўныя прылады для працы: и .
- . Асноўныя інструменты: , Chef і г.д.
Любы код ляжыць у git-рэпазітарах. І рана ці позна тымлід вырашыць, што трэба было б навесці парадак у іх. І будзе рэфактарыць ён. І створыць некаторую структуру. І ўбачыць ён, што гэта ёсць добра.
Таксама добра, што ўжо існуе и -правайдэр для Terraform (і гэта Software Configuration). З іх дапамогай можна кіраваць усім праектам: чальцамі каманды, CI/CD, git-flow і т.д.
Адкуль узялося яйка?
Вось мы і паступова падыходзім да галоўнага пытання.
Найперш трэба пачынаць з рэпазітара, які апісвае структуру іншых рэпазітараў, у тым ліку сябе. І вядома ж, у рамках GitOps трэба дадаць CI, каб аўтаматычна змены выконваліся.
Калі Git яшчэ не створаны?
- Як яго захоўваць у Git?
- Як прыкруціць CI?
- Калі Gitlab мы таксама разгортваем з дапамогай IaC, ды яшчэ і ў Kubernetes?
- І GitLab Runner таксама ў Kubernetes?
- А Kubernetes у хмарным правайдэры?
Што з'явілася раней: GitLab, на які я загружаю свой код, ці код, які апісвае тое, які GitLab мне патрэбен?
Курыца з яйкамі
«3 з дыназаўрам» []
Паспрабуем прыгатаваць страву, выкарыстоўваючы ў якасці хмарнага правайдэра. .
TL, д-р
А можна, каб адразу і ў адну каманду?
$ export MY_SELECTEL_TOKEN=<token>
$ curl https://gitlab.com/chicken-or-egg/mks/make/-/snippets/2002106/raw | bashІнгрэдыенты:
- Акаўнт ад my.selectel.ru;
- Токен ад акаўнта;
- Навыкі Kubernetes;
- Навыкі Helm;
- Навыкі Terraform;
- Helm chart GitLab;
- Helm chart GitLab Runner.
рэцэпт:
- Атрымаць MY_SELECTEL_TOKEN з панэлі my.selectel.ru.
- Стварыць кластар Kubernetes, перадаўшы ў яго токен ад акаўнта.
- Атрымаць KUBECONFIG ад створанага кластара.
- Устанавіць GitLab у Kubernetes.
- Атрымаць GitLab-token ад створанага GitLab для карыстальніка корань.
- Стварыць структуру праектаў у GitLab, выкарыстоўваючы GitLab-token.
- Запушыць наяўны код у GitLab.
- ?
- Profit!
Крок 1. Токен можна атрымаць у раздзеле .
Крок 2. Падрыхтоўваем наш Terraform для "запякання" кластара з 2 нод. Калі вы ўпэўненыя ў тым, што ў вас хопіць на ўсе рэсурсы, то можна ўключыць аўтаквоты:
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",
}
}Дадаем карыстальніка ў праект:
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
}Выхадныя дадзеныя:
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
}Запускаем:
$ env
TF_VAR_region=ru-3
TF_VAR_username=diamon
TF_VAR_my_selectel_token=<token>
terraform plan -out planfile
$ terraform apply -input=false -auto-approve planfile
Крок 3. Атрымліваем кубканфіг.
Каб праграмна спампаваць KUBECONFIG, трэба атрымаць токен ад OpenStack:
openstack token issue -c id -f value > tokenІ ўжо з гэтым токенам зрабіць запыт у Managed Kubernetes Selectel API. k8s_id выдае тэрафарм:
curl -XGET -H "x-auth-token: $(cat token)" "https://ru-3.mks.selcloud.ru/v1/clusters/$(cat k8s_id)/kubeconfig" -o kubeConfig.yamlКубконфіг таксама можна атрымаць праз панэль.
Крок 4. Пасля таго, як кластар запекся і ў нас есць да яго доступ, можна дадаць зверху yaml па гусце.
Я аддаю перавагу дадаваць:
- namespace,
- storage class,
- pod security policy і іншае.
для Selectel можна браць з .
Так як першапачаткова я абраў кластар у зоне by-3a, то і Storage Class мне патрэбен з гэтай зоны.
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Крок 5. Ставім балансавальнік нагрузкі.
Будзем выкарыстоўваць стандартны для многіх nginx-ingress. Інструкцый па ім усталёўцы ўжо звышдастаткова, так што не будзем на гэтым затрымоўвацца.
$ 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Чакаем, калі ён атрымае знешні IP прыкладна 3-4 хвіліны:
Атрымалі знешні IP:
Крок 6. Усталёўваны 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"Зноў чакаем, калі ўсе поды паднімуцца.
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...Поды падняліся:
Крок 7. Атрымліваем GitLab-token.
Спачатку даведаемся пароль для ўваходу:
kubectl get secret -n gitlab gitlab-gitlab-initial-root-password -o jsonpath='{.data.password}' | base64 --decodeЦяпер аўтарызуемся і атрымаем токен:
python3 get_gitlab_token.py root $GITLAB_PASSWORD http://gitlab.gitlab.$EXTERNAL_IP.nip.ioКрок 8. Прыводзім Git-рэпазітары да правільнай іерархіі з дапамогай Gitlab Provider.
cd ../internal/gitlab/hierarchy && terraform apply -input=false -auto-approve planfileНажаль, у terraform GitLab provider ёсць плывучы . Тады давядзецца выдаліць канфліктуючыя праекты рукамі, каб tf.state паправіўся. Затым перазапусціце каманду `$ make all`
Крок 9. Пераносім лакальныя рэпазітары на сервер.
$ make push
[master (root-commit) b61d977] Initial commit
3 files changed, 46 insertions(+)
create mode 100644 .gitignore
create mode 100644 values.yml
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 770 bytes | 770.00 KiB/s, done.
Total 5 (delta 0), reused 0 (delta 0)гатова:
Заключэнне
Мы дабіліся таго, што з нашай лакальнай машыны можам дэкларатыўна кіраваць усім. Цяпер жадаецца перанесці ўсе гэтыя задачы ў CI і толькі кнопачкі націскаць. Для гэтага трэба перадаць нашы лакальныя станы (Terraform state) у CI. Аб тым, як гэта зрабіць, у наступнай частцы.
Падпісвайцеся на наш , Каб не прапусціць выхады новых артыкулаў!
Крыніца: habr.com