Приятные новости от gitlab! Теперь для создания проекта можно просто пушить в несуществующий репозиторий и он создастся.

$ git push --set-upstream ssh://git@gitlab.example.com:12345/group/project.git master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 1.12 KiB | 0 bytes/s, done.
Total 5 (delta 0), reused 0 (delta 0)
remote: 
remote: The private project group/project was successfully created.
remote: 
remote: To configure the remote, run:
remote:   git remote add origin git@gitlab.example.com:group/project.git
remote: 
remote: To view the project, visit:
remote:   http://gitlab.example.com/group/project
remote: 
To ssh://gitlab.example.com:12345/group/project.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from ssh://git@gitlab.example.com:12345/group/project.git.

Подробнее: https://docs.gitlab.com/ee/gitlab-basics/create-project.html#push-to-create-a-new-project

и.. куча других нововведений: https://habrahabr.ru/post/350660/

#gitlab #git

Переустанавливаем gitlab с заданием root пароля

export GITLAB_ROOT_PASSWORD="pwd_>=8_chars"
export GITLAB_ROOT_EMAIL="host@example.com"

gitlab-rake gitlab:setup ${GITLAB_ROOT_PASSWORD:+GITLAB_ROOT_PASSWORD=$GITLAB_ROOT_PASSWORD}       ${GITLAB_ROOT_EMAIL:+GITLAB_ROOT_EMAIL=$GITLAB_ROOT_EMAIL}

Это к вопросу, например, какого хрена у меня не логинится в gitlab, когда я поставил helm install gitlab, все же должно работать из коробки! А вот.. Длинна пароля больше 8 символов должна быть, иначе запись этого пользователя в базу даже не попадет.

#gitlab #helm #kubernetes

Обновление gitlab до 10.5.6 ломает web hook

Обновил в кубе инсталляцию gitlab с 10.5.4 на 10.5.6 и обнаружил вдруг, что сломались билды в jenkins. Поскольку среда была тестовая, я в это же время обновил jenkins, несколько плагинов.. в общем, сами понимаете, концы искать стало куда тяжелее. В итоге, при вызове из интерфейса хука, или при пуше тега (я триггерю билд по тегу) в jenkins рисовался большой половой орган. В самой первой попытке решения я откатил хелм до предыдущего гитлаба, но это проблемы не решило. После долгих каяний пошел читать комменты на гитхабе. Как оказывается, в последнее время, это - самый нормальный способ понять проблемы развивающихся продуктов. Большинство проблем с кубом только так и решаются - лезешь в гитхаб и читаешь, а что же там наворочено и как это решить...

Обсуждение и лечение:
https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3307

#gitlab #troubleshooting

Gitlab helm stable chart

Gitlab наконец-то зарелизили стабильный chart:

https://about.gitlab.com/2018/08/22/gitlab-11-2-released/#cloud-native-gitlab-helm-chart-generally-available

#gitlab #helm #kubernetes

Обновляем Gitlab 10.8 -> 11.x установленный через helm

нужно изменить переменную git_data_dir в templates/configmap.yaml на следующее:

git_data_dirs['default']['path'] = '/gitlab-data/git-data';

Ошибка:

Chef Client finished, 274/445 resources updated in 04 minutes 26 seconds

Deprecations:

Your git_data_dir settings are deprecated.
Please update it to the following:

git_data_dirs({
    "default" => {
        "path" => "/gitlab-data/git-data"
    }
})

Please refer to https://docs.gitlab.com/omnibus/settings/configuration.html#storing-git-data-in-an-alternative-directory for updated documentation.

#helm #kubernetes #gitlab

Gitlab массовое включение deploy key через API

За смешивание баша и руби прошу не пиннать =)

Задача: включить deploy key всем проектам в пределах одной группы

1. Идем в свой ЛК и получаем там токен

2. Получаем список групп, находим среди них нужную и смотрим ее id.

curl --header 'PRIVATE-TOKEN: TOKEN' https://gitlab.company.com/api/v4/groups

3. Получаем список всех id проектов которые входят в группу

curl -s --header 'PRIVATE-TOKEN: TOKEN' https://gitlab.company.com/api/v4/groups/18 |  ruby -ryaml -e 'p YAML.load($<)["shared_projects"].map {|prj| prj["id"]}'

4. В режиме отладчика в браузере включаем в любом нужном проекте deploy key и смотрим на URL. В нем написан key id, в моем случае это 54.

5. Включаем нужный ключ для всех нужных проектов (не забываем изменить deploy key id)

for repo_id in 13 12 11 10 9 8 7 6 4 2 1; do curl --request POST --header "PRIVATE-TOKEN: TOKEN' https://gitlab.company.com/api/v4/projects/${repo_id}/deploy_keys/54/enable; done

#gitlab

Создать некоторое количество проектов через Gitlab API

Для создания проекта нужно знать:
- Имя проекта (придумать)
- Namespace ID, в которое будет помещен проект

В поисках Namespace

# смотрим все доступные ns
curl -s --header 'PRIVATE-TOKEN: TOKEN' "https://gitlab.company.com/api/v4/namespaces | json_pp
# или ищем по части имени
curl -s --header 'PRIVATE-TOKEN: TOKEN' "https://gitlab.company.com/api/v4/namespaces?search=libs" | json_pp

В результате нам нужно найти namespace ID, который нужно подставить в параметр при создании проекта.

Создаем сами проекты

 
for repo_name in project1 project2 ... projectN; do \
curl -s --header 'PRIVATE-TOKEN: TOKEN' -X POST "https://gitlab.company.com/api/v4/projects?\
namespace_id=31&\
path=${repo_name}&\
wiki_enabled=false&\
merge_method=rebase_merge&\
visibility=private&\
issues_enabled=false&\
only_allow_merge_if_all_discussions_are_resolved=true&\
jobs_enabled=false&\
snippets_enabled=false&\
lfs_enabled=false";
done

Тут перечислен пример параметров, которые сразу можно задавать при создании репозитория, в вашем случае они могут быть совершенно другие, смотрите документацию или смотрите на уже существующие проекты, обратившись GET-запрсом по /api/v4/projects/PROJECT_ID. project_id можно взять из /projects или зайдя в свойства проекта (settings->general->General project)

#gitlab

Github и ssh-ключи

Узнал о фишке в гитхабе, что по такой ссылке можно забрать публичный ключ аккаунта. Типа удобно передавать ключ просто ссылкой.

https://github.com/bykvaadm.keys

З.Ы. Gitlab тоже так умеет.

#github #gitlab

Собираем helm-чарт в gitlab-ci и пушим в docker registry

Используем экспериментальную фичу с oci-registry в которую научился хелм. Это значит что мы можем чарты теперь просто пушить рядом с контейнерами докера с таким же именованием и тегированием.

deploy_helm:
  stage: deploy
  image: docker:18-dind
  services:
  - docker:18-dind
  environment: { name: production }
  tags: [docker]
  only:
    refs: [master]
  script:
  - export CHART_VERSION=$(grep version Chart.yaml | awk '{print $2}')
  - chmod 400 $DOCKERCONFIG
  - mkdir registry
  - alias helm='docker run -v $(pwd)/regisry:/root/.cache/helm/registry -v $(pwd):/apps -v ${DOCKERCONFIG}:/root/.docker/config.json -e DOCKER_CONFIG="/root/.docker" -e HELM_REGISTRY_CONFIG="/root/.docker/config.json" -e HELM_EXPERIMENTAL_OCI=1 alpine/helm'
  - helm chart save . registry.company.com/helm/charts/debezium:${CHART_VERSION}
  - helm chart push registry.company.com/helm/charts/debezium:${CHART_VERSION}

Структура репозитория - файлы чарта и .gitlab-ci.yml. После запуска деплоя создается воркер - докер с поддержкой docker-in-docker. Мы качаем публичный контейнер хелма на альпине. Все пробросы нужны для того чтобы хелм внутри докера умел ходить в регистри и сохранять промежуточный кэш для докер регистри. Помещаю его в "алиас" команды хелма для того чтобы логически отделить запуск хелма и запуск докера. последние 2 строки - сохранить чарт в локальный кэш и подготовить для пуша в регистри и собственно запушить. Чтобы всё это работало нужно подготовить docker config.json с готовыми параметрами пользователя для доступа к докер регистри и сохранить его в переменные джобы как файл.

#helm
#gitlab
#docker

В догонку к CI о сборке чарта, CI для деплоя это чарта

в этом деплое помимо докер конфига требуется еще сделать кубконфиг, в который поместить токен админа неймспейса (1 ci = 1 app = 1 admin = 1 ns). Здесь часть сниппета, остальное что пропущено абсолютно симметрично предыдущему посту.

```

  script:
  - chmod 400 $DOCKERCONFIG
  - chmod 400 $KUBECONFIG
  - mkdir registry
  - alias helm='docker run -v ${KUBECONFIG}:/root/.kube/config -v $(pwd)/regisry:/root/.cache/helm/registry -v $(pwd):/apps -v ${DOCKERCONFIG}:/root/.docker/config.json -e DOCKER_CONFIG="/root/.docker" -e HELM_REGISTRY_CONFIG="/root/.docker/config.json" -e HELM_EXPERIMENTAL_OCI=1 alpine/helm'
  - helm chart pull company.com/helm/charts/debezium:$chart_version
  - helm chart export rcompany.com/helm/charts/debezium:$chart_version
  - helm upgrade --install -f ....... 

```

#helm
#gitlab
#kubernetes

Шобы отсылать почту через гуголя в gitlab, нужно

1) зайти на https://myaccount.google.com/lesssecureapps и переключить выключатель в положение ON.

2) прописать в конфиг как в указано в мане, например

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.gmail.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "sendmail@company.com"
gitlab_rails['smtp_password'] = "password"
gitlab_rails['smtp_domain'] = "smtp.gmail.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
gitlab_rails['smtp_openssl_verify_mode'] = 'peer'

3. gitlab-reconfigure

#gitlab

Ненавижу блядь гитлаб

Получая ошибку 403 при попытке залить npm пакет в package registry подумайте о том, что это на самом деле не проблема в CI_JOB_TOKEN (и права того кто запустил сборку), не права deploy_token, не права access_token или еще какой токен, а это ошибка того, что пакет с такой версией УЖЕ СУЩЕСТВУЕТ в репозитории. ни в одном месте - ни в логах npm, ни в логах гитлаба вам об этом не напишут.

---
define true=false
// удачи в отладке, суки

#gitlab

как разлочить локального админа в гитлабе при LDAP

# попадаем в консоль
docker exec -it <container-id> gitlab-rails console

# меняем пароль
user = User.find_by(email: 'admin@example.com')
new_password = ::User.random_password
user.password = new_password
user.password_confirmation = new_password
user.password_automatically_set = false

# разлочить юзера
user.unlock_access!
user.state = 'active'

# сохраняем
user.save!

# включаем вход по паролю
Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: true)

#gitlab