gitlab helm release install

Thank you for reading this post, don't forget to subscribe!

ста­вим гит­лаб helm chart в aws eks

aws/infra/rds.tf

поль­зо­ва­тель и пароль добав­ле­ны в secret manager

добав­ля­ем s3 баке­ты 2 шту­ки, 1 для арти­фак­тов дру­гой для бэкапов

aws/infra/s3.tf

созда­ём сер­вис аккаунт

aws/infra/aws-iam-access-roles.tf

откры­ва­ем порт на Ingress для ssh я выбрал порт 2222

aws/infra/eks.tf

 

 

созда­ём поч­то­вый сервер

aws/infra/ses.tf

логин пароль созда­ют­ся вруч­ную внут­ри пане­ли хоть и выгля­дят как обыч­ные клю­чи для iam поль­зо­ва­те­ля - но это не так

aws/infra/main.tf

вот тут зада­ём переменные

aws/infra/variables/infra.yaml

template для гитлаба

aws/infra/templates/gitlab.yaml.tmpl

для gitlab-runner

aws/infra/templates/gitlab-runner-self-hosted.yaml.tmpl

 

все ком­по­нен­ты для гитлаба:

я исполь­зую harbor в каче­стве registry в кото­ром у меня хра­нят­ся образы

так же запус­каю отдель­ную cronjob кото­рая созда­ёт бэка­пы про­ек­тов. я создаю image кото­рые созда­ёт архив с бэка­па­ми и скла­ды­ва­ет в s3

вот этот скрипт:

Dockerfile

.env_example

app.py

 

для успеш­но­го запус­ка это­го скрип­та нуж­но создать access-token и поме­стить его в aws secret manager под име­ненм GITLAB_BACKUP_TOKEN

 

так же я делаю снап­шо­ты EBS дис­ка на кото­ром хра­нит­ся gitlaly делаю это через aws_dlm_lifecycle_policy

мож­но для это­го исполь­зо­вать и backup сервис

так как для созда­ния бэка­па с помо­щью toolbox я исполь­зую диск, то во вре­мя установки

terraform apply --target helm_release.gitlab
спу­стя минут 5 уста­нов­ка подвиснет,

нуж­но запу­стить джобу:

kubectl create job --from=cronjob/gitlab-toolbox-backup gitlab-toolbox-backup-manual-$(date +%s) -n gitlab

чтоб PVC под­со­еди­нил­ся и уста­нов­ка helm завер­ши­лась успешно.

руто­вый пароль мож­но посмот­реть в кластере

kubectl get secret -n gitlab gitlab-gitlab-initial-root-password -o yaml

 

созда­ём токен для гит­лаб раннера

полу­ча­ем токен, добав­ля­ем его в aws secret manager infra/gitlab  пере­мен­ная назы­ва­ет­ся runner-token

и запус­ка­ем установку:

terraform apply --target helm_release.gitlab_runner

теперь нуж­но мигри­ро­вать дан­ные с облач­но­го гит­ла­ба, для это­го настра­и­ва­ем миграцию:

лими­ты выстав­ля­ем по максимуму.

вот такая настрой­ка нуж­на чтоб после invite ново­го поль­зо­ва­те­ля он мог захо­дить с помо­щью google auth без aprove со сто­ро­ны админ­ки гитлаба.

со сто­ро­ны облач­но­го гит­ла­ба созда­ём токен с ука­зан­ны­ми правами:

в нашем гитла­бе созда­ём новую груп­пу и ука­зы­ва­ем что будем её импор­ти­ро­вать с помо­щью токе­на создан­но­го  в облач­ном гитлабе

ука­зы­ва­ем назва­ние нашей груп­пы - луч­ше сде­лать чтоб она сов­па­да­ла с облачной

запус­ка­ем и ждём. у меня это заня­ло око­ло 5-7 часов - всё зави­сит сколь­ко про­ек­тов и сколь­ко дан­ных надо тащить.

во вре­мя тако­го пере­но­са  пере­мен­ные не пере­но­сят­ся, поэто­му вос­поль­зуй­тесь сле­ду­ю­щим скриптом:

 

в нём нуж­но указать

# === Настрой­ки исход­но­го (облач­но­го) GitLab ===
GITLAB_CLOUD_TOKEN= токен в облач­ном гитлабе
GITLAB_CLOUD_DOMAIN="gitlab.com"
GITLAB_CLOUD_GROUP=группа в облач­ном гитлабе

# === Настрой­ки целе­во­го (self-hosted) GitLab ===
GITLAB_SELF_HOSTED_TOKEN= токен в нашем гитлабе
GITLAB_SELF_HOSTED_DOMAIN="gitlab.infra.test.tech"
GITLAB_SELF_HOSTED_GROUP= груп­па в нашем гитлабе

запус­ка­ем скрипт и пере­мен­ные переносятся.

 

 

если вдруг кто то из раз­ра­бот­чи­ков успел доба­вить новые ком­ми­ты в облач­ный гит­лаб и нуж­но син­хро­ни­зи­ро­вать дан­ные то исполь­зу­ем сле­ду­ю­щий скрипт:

в нём нуж­но указать

# === Настрой­ки исход­но­го (облач­но­го) GitLab ===
GITLAB_CLOUD_TOKEN= токен в облач­ном гитлабе
GITLAB_CLOUD_DOMAIN="gitlab.com"
GITLAB_CLOUD_GROUP=группа в облач­ном гитлабе

# === Настрой­ки целе­во­го (self-hosted) GitLab ===
GITLAB_SELF_HOSTED_TOKEN= токен в нашем гитлабе
GITLAB_SELF_HOSTED_DOMAIN="gitlab.infra.test.tech"
GITLAB_SELF_HOSTED_GROUP= груп­па в нашем гитлабе

этот скрипт будет пере­тас­ки­вать дан­ные с помо­щью fetch и rebase т.е. дан­ные зати­рать не будут

 

после пере­ез­да не забы­ва­ем попра­вить для ВСЕХ репок кто может мёр­жить (merge) в репку

 

если у вас есть include из одно­го про­ек­та в дру­гой (напри­мер как у меня шаб­ло­ны хра­нят­ся в одном репо­зи­то­рии и я их под­тя­ги­ваю в осталь­ных про­ек­тах) воз­ник­нет ошиб­ка вот тако­го вида:

Project `devops/gitlab-ci-templates` not found or access denied! Make sure any includes in the pipeline configuration are correctly defi

её реша­ем сле­ду­ю­щим образом

и каж­до­го поль­зо­ва­те­ля кото­рый запус­ка­ет ci/cd pipeline  добав­ля­ем в про­ект кото­рые мы include  с мини­маль­ны­ми пра­ва­ми reporter - по дру­го­му рабо­тать не будет.