← CI/CD: практика
12 мин · просто · Урок 5 из 10

Деплой: сайт в интернете по своему адресу

Добавляем стадию deploy и job pages. GitLab публикует папку public, и сайт открывается по ссылке без единого ручного действия.

Что осталось

Сайт собирается, проверка проходит, артефакт с папкой public доезжает до следующей стадии. Не хватает последнего шага: выложить эту папку туда, где её увидят люди.

Для статики у GitLab есть встроенный хостинг, он называется Pages. Отдельный сервер, домен и настройка nginx не нужны.

Job с именем pages

Pages включается не галочкой в настройках, а самим пайплайном. Job с именем pages GitLab распознаёт автоматически и публикует содержимое папки public.

Финальный .gitlab-ci.yml целиком:

stages:
  - build
  - test
  - deploy

build-site:
  stage: build
  script:
    - mkdir -p public
    - cp index.html style.css public/
  artifacts:
    paths:
      - public

check-build:
  stage: test
  script:
    - test -f public/index.html

pages:
  stage: deploy
  script:
    - echo "Публикуем содержимое public/"
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Имя pages и папка public это умолчания, а не жёсткие требования. В свежих версиях GitLab job может называться как угодно, если объявить публикацию явно:

create-pages:
  stage: deploy
  script:
    - echo "Публикуем"
  pages:
    publish: dist

Пока вы идёте по умолчаниям, помните главное: если назвать job иначе и не добавить pages:, публикация просто не произойдёт, а пайплайн останется зелёным.

rules ограничивают деплой основной веткой. Без этого условия любая ветка с любым экспериментом затирала бы живой сайт.

Что происходит после пуша

Запушьте и откройте страницу пайплайна. Стадий три, а jobs почему-то четыре:

build    build-site    Passed
test     check-build   Passed
deploy   pages         Passed
         pages:deploy  Passed

pages:deploy вы не писали, его добавил GitLab. Ваш job готовит файлы, служебный забирает артефакт и раскладывает по хостингу.

Весь пайплайн занимает примерно полторы минуты, и большая часть этого времени уходит на подъём трёх контейнеров.

Где адрес сайта

Deploy -> Pages. Вверху страницы GitLab пишет, что сайт живой, и даёт кнопку Access pages:

Your Pages site is live at https://<проект>-<хеш>.gitlab.io

Адрес выглядит как https://my-ci-site-a1b2c3.gitlab.io, со случайным хвостом из шести символов. GitLab выдаёт каждому проекту такой уникальный домен, чтобы чужой сайт на соседнем проекте не мог читать куки вашего.

Адрес держится за проектом, но не навсегда: он собран из имени проекта, и переименование его меняет. Ещё есть кнопка Regenerate unique domain, после которой старая ссылка перестаёт работать.

Открывайте. Там ваш index.html со стилями из style.css.

Проверьте, что цикл замкнулся

Поменяйте заголовок в index.html, закоммитьте, запушьте. Ничего больше не делайте.

Через полторы минуты обновите страницу сайта: заголовок новый. Между вашим коммитом и живым сайтом не осталось ни одного ручного шага. Это и называется continuous deployment, просто в очень маленьком масштабе.

Если сайт не открылся

Пайплайн зелёный, а Pages пуст. Почти всегда виновато имя: job должен называться pages, а папка public. Блок artifacts в свежих версиях GitLab для этого не обязателен, путь публикации дописывается сам, но лишним он не будет.

404 сразу после первого деплоя. Подождите минуту, раскладка занимает время. Ещё проверьте, что файл называется index.html: без него по корневому адресу отдавать нечего.

Вместо сайта открывается форма входа GitLab. Значит доступ к Pages ограничен участниками проекта. Так бывает, если проект создавался приватным: даже после переключения его в Public настройка страниц остаётся прежней. Лечится в Settings -> General -> Visibility, project features, permissions: пункт Pages перевести из Only Project Members в Everyone With Access.

Стадия deploy не запустилась. Сработало rules, значит вы пушите не в основную ветку. Проверьте её имя, у новых проектов это main.

Что дальше

У вас есть репозиторий, пайплайн из трёх стадий и сайт, который выкатывается сам. Схема дальше не меняется, растёт только начинка: на месте cp оказывается сборщик, на месте test -f тесты и линтеры, а Pages в какой-то момент сменится регистром образов и настоящим сервером.

Если общие раннеры недоступны, тот же пайплайн работает на своём раннере: gitlab-runner ставится контейнером, а в проекте создаётся запись через Settings -> CI/CD -> Runners -> New project runner. GitLab выдаёт токен аутентификации, им раннер и подключается. Минуты при этом становятся вашими собственными.

Что важно запомнить

Job pages плюс папка public в артефактах. Этого достаточно для хостинга статики, ничего настраивать не надо.

pages:deploy GitLab добавляет сам, писать его не надо.

Адрес сайта живёт в Deploy -> Pages и выглядит как <проект>-<хеш>.gitlab.io.

rules с проверкой ветки защищают живой сайт от выката из эксперимента.

Прошли материал до конца? Отметьте урок пройденным.