Кое е по-старо - кокошката или яйцето? Доста странно начало за статия за Infrastructure-as-Code, нали?
Какво е яйце?
Най-често Infrastructure-as-Code (IaC) е декларативен начин за представяне на инфраструктура. В него описваме състоянието, което искаме да получим, от хардуерната част до конфигурацията на софтуера. Затова IaC се използва за:
- Provisioning на ресурси. Това са VMs, S3, VPC и т.н. Основните инструменти за работа са: и .
- . Основните инструменти са: , Chef и т.н.
Всяка кодова база се намира в git-репозитории. Рано или късно тимлидерът решава, че е време да подреди нещата в тях. И ще направи рефакторинг. И ще създаде определена структура. И ще види, че това е добре.
Също така е добре, че вече съществува и -провайдер за Terraform (и това е Конфигурация на софтуера). С тяхна помощ можем да управляваме целия проект: членовете на екипа, CI/CD, git-flow и т.н.
От къде дойде яйцето?
Ето че постепенно достигаме до основния въпрос.
Преди всичко трябва да започнем с репозитория, който описва структурата на другите репозитории, включително самия себе си. И разбира се, в рамките на GitOps трябва да добавим CI, за да се изпълняват автоматично промените.
Ако Git все още не е създаден?
- Как да го съхраняваш в Git?
- Как да добавим CI?
- Ако развиваме Gitlab с помощта на IaC и в Kubernetes?
- И GitLab Runner също в Kubernetes?
- А Kubernetes в облачен провайдер?
Кое е по-старо: GitLab, където ще кача кода си, или кодът, описващ какъв GitLab ми е нужен?
Кокошка с яйца
«3 с динозавър» []
Нека опитаме да приготвим ястие, използвайки като облачен провайдер .
TL;DR
А може ли всичко да бъде в една команда?
$ export MY_SELECTEL_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 за потребителя root.
- Създайте структурата на проектите в GitLab, използвайки GitLab-token.
- Пушнете съществуващия код в GitLab.
- ???
- Profit!
Стъпка 1. Токенът може да се получи в секцията .
Стъпка 2. Подготвяме нашия Terraform за "запичане" на кластер от 2 ноди. Ако сте сигурни, че имате достатъчно ресурси за всичко, можете да включите автоматични квоти:
доставчик "selectel" {
token = var.my_selectel_token
}
переменная "my_selectel_token" {}
переменная "username" {}
переменная "region" {}
ресурс "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
}
}
}
ресурс "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"
}
ресурс "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",
}
}Добавяне на потребител в проекта:
ресурс "random_password" "my-k8s-user-pass" {
length = 16
special = true
override_special = "_%@"
}
ресурс "selectel_vpc_user_v2" "my-k8s-user" {
password = random_password.my-k8s-user-pass.result
name = var.username
enabled = true
}
ресурс "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
}
ресурс "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
}Изходни данни:
изход "project_id" {
value = selectel_vpc_project_v2.my-k8s.id
}
изход "k8s_id" {
value = selectel_mks_cluster_v1.k8s-cluster.id
}
изход "user_name" {
value = selectel_vpc_user_v2.my-k8s-user.name
}
изход "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=
terraform plan -out planfile
$ terraform apply -input=false -auto-approve planfile 
Стъпка 3. Получаваме кубконфиг.
За да изтеглите KUBECONFIG програмно, е нужно да получите токен от OpenStack:
openstack token issue -c id -f value > tokenИ с този токен да направите запитване към API на Managed Kubernetes Selectel. k8s_id върна terraform:
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 може да се вземе от .
Тъй като първоначално избрах кластера в зоната ru-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
