Комментарии 21
Согласно GitHub Flow в мастер попадают фичи готовые к продакшну, релизы вы делаете тегами.
Однако GitLab таки рекомендует использовать бранчи для енвов Объясняется это тем, что вы не всегда контролируете процесс резила, например в случае с мобильным приложением.
Почему кто то решил что включение Pipelines по умолчанию сделает мир лучше?
1. В одном проекте надо было настроить чтобы Gitlab Только хранил сорцы, CI уже был настроен на appveyor. Так и не вышло нормально настроить эту связку. На один коммит appveyor билдит несколько раз.
2. Если в проект добавить YAML файл а потом удалить, таски из него навсегда останутся в Jobs
3. Саппорт гитлаба не очень.
4. Доки не очень. Часто попадаются решения для админов gtlab server которые неприменимы когда gitlab используется как сервис.
2 — это не баг, но фича. На каждый коммит (точнее даже на пуш ветки или тэга) GitLab создаст Pipeline с ровно такой конфигурацией, какая задана в .gitlab-ci.yml для этого коммита (и для той ветки/тэга, в которой он был). Это позволяет тестировать разные варианты конфига CI в отдельной ветке и вообще экспериментировать. И то, что билды остаются в истории — это хорошо. Потому что как только вы начинаете деплоить с помощью GitLab CI, то вывод консоли утилиты деплоя теперь видит не только тот, кто деплоит, но вообще все и в случае любых проблем с деплоем ссылка на job'у скидывается в чат и сразу несколько пар глаз могут посмотреть, в чём проблема.
На прошлой работе (где был запрет на публичные облака — всё хостили во внутренней сети компании) использовали GitLab CI и не нарадовались. Легко конфигурируется, кастомизируется, собирает и пушит докер образа, гоняет тесты, деплоит тестовую и боевую среды, ветки со специальными именами деплоит на специальные review app'ы, кофе вот только не варит (но при наличии подключенной к сети кофеварки и это можно решить).
потом деплоим с указанием ссылок на эти образы.
Можно подробнее? Сейчас я сделал bluegreen с помощью ansible, закидывая docker-compose на продакшен. Может есть способ проще?
Из более простых:
1) Если на vps/vds есть доступ по ssh — можно посмотреть в сторону docker-machine. Отпадает проблема с репозиторием — он сам перекачает с машины собранные образа на машину где их запускать. По разным причинам мне этот вариант не нравится, но попробовать стоит.
2) Если запрета на использование облаков нет — можно попробовать использовать docker cloud (сервис от самого докера). Он возьмёт вашу машину (или создаст по вашей просьбе) и будет накатывать туда конфиги и образа. У меня например сейчас так поднято, на время переезда.
В GitLab CI можно. Настраиваете работу docker-in-docker (dind) на машине с Runner'ом и запускаете docker build, docker push сколько угодно. Хоть на внешний docker registry, хоть на встроенный в GitLab. Документашка тут: https://docs.gitlab.com/ce/ci/docker/using_docker_build.html
When using docker-in-docker, each job is in a clean environment without the past history. Concurrent jobs work fine because every build gets it's own instance of Docker engine so they won't conflict with each other. But this also means jobs can be slower because there's no caching of layers.
И под «jobs can be slower» нужно читать «каждый раз будешь пересобирать образ с нуля». Сейчас пытаюсь настроить всё с «Docker socket binding».
Если же у вас голый докер без аркестратора (что странно для продакшна), вы должны этим докером запулить обновленный имейдж и пересоздать контейнер. Сделать это можете с помощью докера удаленно (нужно тащить в CI ключики от апи докера)
Костылик с BUILD_ENV тоже использовали, но начиная с 8.15 появились CI_ENVIRONMENT_NAME и CI_ENVIRONMENT_SLUG.
Ну и хотел бы уточнить, как у вас происходит сборка сборочного образа? То есть в репозитории есть Dockerfile с описанием образа сборки и Dockerfile с описанием образа приложения. В какой момент и как собирается сборочный образ? Это отдельная задача в пайплайне? Как вы ставите тэг, если вдруг сборочный образ обновился? В общем интересен этот процесс.
Похоже, что нужно аккуратно ставить тэги или руками запускать сборку сборочного образа или даже менять .gitlab-ci.yml, когда изменится тэг сборочного образа. В силу объёмности нашего проекта, мы используем свою утилиту dapp для сборки и описание в двух Dockerfile не требуется, за обновлениям сборочного образа следит сам dapp. Но теперь в самом docker из коробки есть multi stages и похоже этот способ (с двумя Dockerfile) перестаёт быть актуальным. Что думаете?
GitLab CI: ветки больше не нужны