Перейти к содержимому

Как развернуть проект из gitlab

  • автор:

Руководство. Развертывание репозиториев GitLab в Статические веб-приложения Azure

Статические веб-приложения Azure имеет гибкие варианты развертывания, позволяющие работать с различными поставщиками. В этой статье вы развернете веб-приложение, размещенное в GitLab, в Статические веб-приложения Azure.

Из этого руководства вы узнаете, как выполнять такие задачи.

  • Импорт репозитория в GitLab
  • Создание статического веб-приложения
  • Настройка репозитория GitLab для развертывания в Статические веб-приложения Azure

Предварительные требования

  • Учетная запись GitLab
  • Учетная запись Azure
    • Если у вас еще нет подписки Azure, создайте бесплатную пробную учетную запись.

    Создание репозитория

    В этой статье используется репозиторий GitHub в качестве источника для импорта кода в репозиторий GitLab.

    1. Войдите в учетную запись GitLab и перейдите по адресу https://gitlab.com/projects/new#import_project
    2. Выберите Репозиторий по URL-адресу.
    3. В поле URL-адрес репозитория Git введите URL-адрес репозитория для выбранной платформы.

    Создание статического веб-приложения

    Теперь, когда репозиторий создан, можно создать статическое веб-приложение на портале Azure.

    1. Перейдите на портал Microsoft Azure.
    2. Выберите Создать ресурс.
    3. Выполните поиск по запросу Статические веб-приложения.
    4. Выберите Статические веб-приложения.
    5. Щелкните Создать.
    6. В разделе Основные сведения начните с настройки нового приложения.

    Параметр Значение
    Подписка Azure. Выберите подписку Azure.
    Группа ресурсов Щелкните ссылку Создать и введите static-web-apps-gitlab.
    Имя Введите my-first-static-web-app.
    Тип плана Выберите Бесплатно.
    Область для API Функций Azure и промежуточных сред Выберите ближайший к вам регион.
    Источник Выберите Другой.

    Создание задачи конвейера в GitLab

    Затем добавьте задачу рабочего процесса, отвечающую за сборку и развертывание сайта по мере внесения изменений.

    Добавление маркера развертывания

    1. Перейдите в репозиторий в GitLab.
    2. Выберите Параметры.
    3. Выберите CI/CD.
    4. Рядом с разделом Переменные выберите Развернуть.
    5. Выберите Добавить переменную.
    6. В поле Ключ введите DEPLOYMENT_TOKEN.
    7. В поле Значение вставьте значение маркера развертывания, которое вы отложили на предыдущем шаге.
    8. Выберите Добавить переменную.

    Добавление файла

    1. Выберите пункт меню Репозиторий .
    2. Выберите Файлы.
    3. Убедитесь, что в раскрывающемся списке ветви в верхней части выбрана главная ветвь.
    4. Нажмите раскрывающийся список «плюс » и выберите Создать файл.
    5. Создайте новый файл с именем .gitlab-ci.yml в корне репозитория. (Убедитесь, что файл имеет .yml расширение .)
    6. Введите в файл следующий код YAML.
    variables: API_TOKEN: $DEPLOYMENT_TOKEN APP_PATH: '$CI_PROJECT_DIR/src' deploy: stage: deploy image: registry.gitlab.com/static-web-apps/azure-static-web-apps-deploy script: - echo "App deployed successfully." 
    variables: API_TOKEN: $DEPLOYMENT_TOKEN APP_PATH: '$CI_PROJECT_DIR/src' OUTPUT_PATH: '$CI_PROJECT_DIR/dist/angular-basic' deploy: stage: deploy image: registry.gitlab.com/static-web-apps/azure-static-web-apps-deploy script: - echo "App deployed successfully." 
    variables: API_TOKEN: $DEPLOYMENT_TOKEN APP_PATH: '$CI_PROJECT_DIR/Client' OUTPUT_PATH: 'wwwroot' deploy: stage: deploy image: registry.gitlab.com/static-web-apps/azure-static-web-apps-deploy script: - echo "App deployed successfully." 
    variables: API_TOKEN: $DEPLOYMENT_TOKEN APP_PATH: '$CI_PROJECT_DIR' OUTPUT_PATH: '$CI_PROJECT_DIR/build' deploy: stage: deploy image: registry.gitlab.com/static-web-apps/azure-static-web-apps-deploy script: - echo "App deployed successfully." 
    variables: API_TOKEN: $DEPLOYMENT_TOKEN APP_PATH: '$CI_PROJECT_DIR' OUTPUT_PATH: '$CI_PROJECT_DIR/dist' deploy: stage: deploy image: registry.gitlab.com/static-web-apps/azure-static-web-apps-deploy script: - echo "App deployed successfully."

    Следующие свойства конфигурации используются в файле .gitlab-ci.yml для настройки статического веб-приложения.

    Переменная $CI_PROJECT_DIR сопоставляется с расположением корневой папки репозитория в процессе сборки.

    Свойство Описание Пример Обязательно
    APP_PATH Расположение кода приложения. Введите $CI_PROJECT_DIR/ , находится ли исходный код приложения в корне репозитория или $CI_PROJECT_DIR/app находится ли код приложения в папке с именем app . Да
    API_PATH Расположение кода Функций Azure. Введите $CI_PROJECT_DIR/api , находится ли код приложения в папке с именем api . Нет
    OUTPUT_PATH Расположение выходной папки сборки относительно APP_PATH . Если исходный код приложения находится в $CI_PROJECT_DIR/app , а скрипт сборки выводит файлы в папку $CI_PROJECT_DIR/app/build , установите $CI_PROJECT_DIR/app/build в качестве значения OUTPUT_PATH . Нет
    API_TOKEN Маркер API для развертывания. API_TOKEN: $DEPLOYMENT_TOKEN Да

    После завершения развертывания можно просмотреть веб-сайт.

    Просмотр веб-сайта

    При развертывании статического приложения следует учитывать два фактора. На первом шаге создаются базовые ресурсы Azure, составляющие ваше приложение. Второй — это рабочий процесс GitLab, который создает и публикует приложение.

    Прежде чем перейти на новый статический сайт, сборка развертывания должна завершиться.

    В окне обзора службы «Статические веб-приложения» отображается ряд ссылок, которые помогут вам взаимодействовать с веб-приложением.

    1. Вернитесь к статическому веб-приложению в портал Azure.
    2. Перейдите в окно Обзор .
    3. Щелкните ссылку под меткой URL-адреса . Веб-сайт загружается на новой вкладке.

    Очистка ресурсов

    Если вы не собираетесь продолжать использовать это приложение, можно удалить экземпляр Статические веб-приложения Azure и все связанные службы, удалив группу ресурсов.

    1. Выберите группу ресурсов static-web-apps-gitlab в разделе Обзор .
    2. Выберите Удалить группу ресурсов в верхней части группы ресурсов Обзор.
    3. Введите имя группы ресурсов static-web-apps-gitlab в диалоговом окне подтверждения Удалить static-web-apps-gitlab?
    4. Выберите Удалить.

    На удаление группы ресурсов может потребоваться несколько минут.

    GitLab для начинающих: как и для чего используется

    промо картинка

    В материале подробно разбираем, что такое GitLab, для чего используется, чем отличается от аналогов и как с ним работать.

    Что такое GitLab

    GitLab представляет собой веб-приложение и систему управления репозиториями программного кода для распределенной системы контроля версий Git. GitLab, как правило, используется с Git, что позволяет разработчикам сохранять написанный код в онлайн-формате и работать с другими разработчиками над разными проектами.

    GitLab позволяет взаимодействовать с репозиториями, управлять правами доступа и пользователями, отслеживать ошибки, автоматизировать процессы и выполнять многие другие операции. Установить и использовать его можно на собственном сервере или же в облаке.

    Для чего нужен GitLab

    GitLab имеет множество возможностей, основные из них представлены ниже.

    Планирование
    GitLab способен эффективно поддерживать различные модели коллективной работы вне зависимости от выбранной методологии разработки. Гибкие инструменты управления проектами GitLab позволяют делать процесс разработки наглядным, координировать его, отслеживать и назначать приоритеты.

    Создание
    С Gitlab команда разработчиков может консолидировать исходный код в общей распределенной среде контроля версий. Веб-сервис позволяет управлять и поддерживать распределенную среду, не нарушая процессы разработки.

    GitLab имеет целый арсенал инструментов для управления ветками и доступом к проектам, создавая общую достоверную среду для совместной работы команды разработчиков.

    Тестирование
    В GitLab реализованы инструменты ревью кода, его тестирования и оценки качества, что позволяет разработчикам быстрее находить ошибки и сокращать цикл их исправления.

    Можно персонально настраивать модель приемки качества, тестировать код в автоматическим режиме и назначать изменения в среды тестирования для каждой версии кода.

    Сборка
    Репозиторий контейнеров GitLab дает возможность создавать безопасное хранилище кастомных образов контейнеров Docker. Причем для этого не придется задействовать дополнительные инструменты — возможности скачивания и загрузки образов внедрены в среду управления репозиторием Git по умолчанию.

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

    Конфигурирование
    GitLab позволяет автоматизировать весь процесс разработки приложения. Для этого предоставляются готовые шаблоны моделей, с которыми начать работу можно без сложных предварительных настроек — достаточно добавить специфику приложения на каждом этапе сборки и развертывания.

    В качестве сервиса с предварительно настроенными шаблонами приложений для разработки можно использовать GitLab CE Virtual Appliance.

    Мониторинг
    С GitLab можно отслеживать время, затраченное на каждый этап, проверять работоспособность приложения, собирать и просматривать метрики, а также анализировать, как изменения кода влияют на производительность среды.

    Пример страницы Мониторинга

    Git, GitLab и GitHub

    Каждому разработчику важно знать и понимать, чем отличаются и схожи Git, GitLab и GitHub.

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

    GitHub, как и GitLab, представляет собой онлайн-сервис для размещения репозиториев, удаленного управления ими и других задач разработки. В нем предусмотрены багтрекинг, вики для каждого проекта, история коммитов, графика, вложенные списки задач и многое другое.

    Оба сервиса предназначены для использования группами разработчиков, поэтому многие функции и возможности GitHub и GitLab дублируются. Вместе с тем, есть и отличия:

    • В GitLab реализована встроенная бесплатная непрерывная интеграция. В GitHub есть инструмент Actions. Он позволяет запускать бесплатные непрерывные интеграции в публичных репозиториях, а что касается частных репозиториев — стоимость указана здесь.
    • GitLab задействует Kubernetes для беспроблемного развертывания. В GitHub встроенной платформы развертывания нет.
    • В GitLab есть бесплатные репозитории частного формата для проектов, имеющих открытый исходный код. В GitHub такого нет.

    Подробнее о том, чем еще отличается GitLab, можно прочитать на официальном сайте веб-приложения.

    Еще одним решением для разработки является Cloud Container Engine от SberCloud — сервис для автоматизации развертывания, масштабирования и управления приложениями в высокопроизводительных кластерах Kubernetes. Он обеспечивает высокую производительность, корпоративную надежность и безопасность, а также открытость и совместимость.

    Калькулятор виртуальных машин

    Виртуальная машина+диск от 96 копеек/час

    Картинка продукта

    Как пользоваться GitLab

    Рассмотрим основные этапы работы с GitLab:

    Создание аккаунта

    На GitLab простая процедура регистрации. На главной странице официального сайта есть форма входа, в которой надо ввести только имя пользователя или адрес электронной почты и придумать пароль. После отправки запроса остается только подтвердить регистрацию в письме, отправленном на указанную почту.

    Страница регистрации в GitLab

    Для входа можно использовать аккаунты в других сервисах и социальных сетях.

    Создание репозитория

    Для создания нового проекта надо нажать на значок «+» по центру экрана и выбрать соответствующий пункт.

    Страница создания проекта

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

    После указания всех данных и нажатия на кнопку «Create repo», репозиторий будет создан, а на его странице будет доступен стартовый набор действий.

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

    Загрузка файлов проекта

    В интерфейсе предусмотрены удобные варианты загрузки проектов. На главной странице репозитория можно загрузить файл, создать новый файл, добавить лицензию и файл Readme. При этом загрузка файлов с компьютера выполняется быстро, не требует переформатирования или других операций.

    SSH-ключи

    Чтобы во время загрузки данных репозитория не приходилось вводить логин и пароль, для авторизации можно использовать SSH-ключи. Они создаются в несколько шагов:

    • открывается терминал и выполняется «ssh-keygen»;
    • указывается путь к файлу для сохранения ключа.

    После этого создается два файла — закрытый и открытый. Для создания ключей нужен открытый. Его нужно открыть в текстовом редакторе и скопировать содержимое в буфер обмена. Затем нужно перейти в GitLab и выбрать «Настройки» (Settings). В меню настроек в пункте «SSH Keys» в поле «Key» надо вставить скопированный ранее текст и сохранить изменения. Далее нужно перейти в репозиторий и нажать на кнопку «Clone». После этого нужно вернуться к локальному репозиторию, удалить адрес https и добавить ssh. На этом настройка SSH-ключей будет завершена.

    Ветки репозитория

    По умолчанию в репозитории GitLab предусмотрена только одна ветка — master(main). При этом для реализации вспомогательных функций отдельные этапы разработки можно выносить в независимые ветки. В веб-интерфейсе сервиса ветки отображаются слева, что упрощает переход между ними. Ветки создаются в пару кликов — нужно выбрать «+» по центру экрана и нажать «New branch». Кроме того, после обновления изменений в репозитории в GitLab отображаются и новые ветки, созданные в Git. Все операции с ветками можно выполнять через настройки.

    Слияние веток

    В ветках разрабатывается функциональность, поэтому может потребоваться их перенос — для этого предназначены запросы слияния («Merge request gitlab»). Для использования этой возможности в интерфейсе GitLab нужно нажать кнопку «Create merge request», задать описание «Merge Request», выбрать исходную и целевые ветки. После одобрения запроса на слияние надо нажать на кнопку «Merge». В результате файлы ветки преемника будут заменены файлами из ветки источника.

    Добавление пользователей

    В GitLab можно добавлять неограниченное количество разработчиков даже к приватным репозиториям. Чтобы сделать это, надо перейти в меню «Настройки» (Settings) и выбрать пункт «Участники» (Members). В этом пункте в поле «Выбрать участника для приглашения» (Select members to invite) надо указать адрес электронной почты пользователя или его никнейм. Перед отправкой приглашения также указывается уровень доступа. Для добавления надо нажать «Добавить в проект» (Add to project).

    Удаление проекта

    Для удаления проекта нужно перейти в «Настройки» (Settings) -> «Главные» (General) -> «Продвинутые» (Advanced) и выбрать пункт «Удалить проект» (Remove Project). Перед удалением проекта потребуется ввести его имя.

    Возможные проблемы

    При работе с GitLab могут возникать проблемы, для каждой из которых есть решение:

    1. Ошибка при выполнении pull-запросов. Причиной может быть длительная фаза SSH-аутентификации или низкая скорость обработки запросов. Решается перенастройкой репозиториев.
    2. Ошибка при входе. Может появляться после некорректного введения логина и пароля учетной записи. Решается удалением данных через панель управления.
    3. Ошибка при запуске. Система может указывать на отсутствие GitLab-серверов по заявленным IP-адресам. Причиной проблемы может быть неверное введение команды запуска, использование динамического IP или ошибки при назначении порта. Решается перенастройкой.

    Итог

    Веб-приложение GitLab является отличным решением для построения рабочих процессов CI/CD в облаке, в том числе если системы контроля и разработки надо установить на личном сервере.

    GitLab имеет множество сфер применения и широкие возможности, что в сочетании с удобным инструментарием делает его удобным сервисом как для начинающих разработчиков, так и для профессионалов.

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

    Gitlab — это великолепный веб-инструмент, который можно использовать для разработки проектов любого размера и сложности. Каждый разработчик или компания может найти в Gitlab для себя подход, который сделает разработку более надежной, качественной и быстрой. Я считаю, что Gitlab CI, разграничение ролей, автоматическое тестирование и мониторинг незаменимы для разработки в командах и оценки эффективности Кирилл Шеховцов Технический лидер в SberCloud.

    Источники

    1. Что такое GitLab, как и для чего он используется
    2. GitLab и GitHub: в чем различия?
    3. GitLab
    4. GitLab vs GitHub

    Запросите бесплатную консультацию по вашему проекту

    4.8 Git на сервере — GitLab

    GitWeb довольно-таки прост. Если вам нужен более современный, полнофункциональный Git-сервер, есть несколько решений с открытым исходным кодом, которые можно использовать. Так как GitLab это один из самых популярных, мы рассмотрим его установку и использование в качестве примера. Это немного сложнее, чем GitWeb, и скорее всего потребует больше обслуживания, но и функциональность гораздо богаче.

    Установка

    GitLab — это веб-приложение на основе базы данных, так что его установка немного сложней, чем у некоторых других серверов Git. К счастью, этот процесс хорошо документирован и поддерживается. GitLab настоятельно рекомендует установить GitLab на ваш сервер через официальный пакет Omnibus GitLab.

    Другие варианты установки:

    • GitLab Helm chart для использования с Kubernetes.
    • Официальные образы GitLab для использования с Docker.
    • Из исходных файлов.
    • Облачный провайдер, такой как AWS, Google Cloud Platform, Azure, OpenShift или Digital Ocean.

    Для получения дополнительной информации прочтите GitLab Community Edition (CE) readme.

    Администрирование

    Административный интерфейс GitLab доступен через веб. Просто направьте ваш браузер на имя или IP-адрес хоста, где установлен GitLab, и войдите как администратор. Имя пользователя по умолчанию admin@local.host , пароль по умолчанию 5iveL!fe (вас попросят изменить их при входе). Войдя, нажмите иконку «Административная зона» в меню справа и сверху.

    Пункт «Административная зона» в меню GitLab

    Рисунок 50. Пункт «Административная зона» в меню GitLab

    Пользователи

    Пользователи в GitLab — это учётные записи, соответствующие людям. Пользовательские учётные записи не очень сложны; в основном это набор персональной информации, прикреплённый к имени. У каждого пользователя есть пространство имён, логически группирующее проекты данного пользователя. Если у пользователя jane есть проект project, адрес этого проекта будет http://server/jane/project .

    Экран управления пользователями GitLab

    Рисунок 51. Экран управления пользователями GitLab

    Удаление пользователя может быть выполнено двумя способами. «Блокирование» («Blocking») пользователя запрещает ему вход в GitLab, но все данные в его пространстве имен сохраняются, и коммиты, подписанные этим пользователем, будут указывать на его профиль.

    «Разрушение» («Destroying») пользователя, с другой стороны, полностью удаляет его из базы данных и файловой системы. Все проекты и данные в его пространстве имен удаляются, как и все принадлежащие ему группы. Конечно, этим более постоянным и разрушительным действием пользуются реже.

    Группы

    Группы GitLab — это коллекция проектов с указанием того, как пользователи получают к ним доступ. Каждая группа имеет пространство имён проектов (так же как и пользователи), так что если в группе training есть проект materials, его адрес будет http://server/training/materials .

    Экран управления группами GitLab

    Рисунок 52. Экран управления группами GitLab

    Каждая группа связана с пользователями, каждый из которых имеет уровень доступа к проектам группы и к самой группе. Он разнится от «Гостя» («Guest», только проблемы и чат) до «Владельца» («Owner», полный контроль над группой, её членами и проектами). Типы разрешений слишком обширны, чтобы перечислять их здесь, но на экране управления GitLab есть полезная ссылка с описанием.

    Проекты

    Проект GitLab примерно соответствует одному git-репозиторию. Каждый проект принадлежит одному пространству имён, групповому или пользовательскому. Если проект принадлежит пользователю, владелец контролирует, кто имеет доступ к проекту; если проект принадлежит группе, действуют групповые уровни доступа для пользователей.

    Каждый проект также имеет уровень видимости, который контролирует, кто имеет доступ на чтение страниц проекта или репозитория. Если проект Приватный (Private), владелец должен явно дать доступ на чтение отдельным пользователям. Внутренний (Internal) проект виден любому вошедшему пользователю GitLab, а Публичный (Public) проект видим всем. Это относится как к доступу git fetch , так и к доступу к проекту через веб-интерфейс.

    Хуки

    GitLab включает поддержку хуков (перехватчиков, hooks) на уровне проектов и всей системы. В обоих случаях, когда происходит некоторое событие, сервер GitLab выполняет запрос HTTP POST с осмысленным JSON-содержанием. Это отличный способ соединить ваши git-репозитории и инсталляцию GitLab с автоматикой инфраструктуры разработки, такой как сервера непрерывной интеграции, комнаты чатов или инструменты деплоя.

    Базовое использование

    Первое, чего вы захотите от GitLab, это создать новый проект. Это достигается нажатием иконки «+» на панели инструментов. Будут запрошены имя проекта, пространство имён, которому он должен принадлежать, и уровень видимости. Большинство из этих настроек можно потом изменить через интерфейс настроек. Нажмите «Создать проект» («Create Project»), чтобы закончить.

    Когда проект создан, вы, наверное, захотите соединить его с локальным git-репозиторием. Каждый проект может быть доступен через HTTPS или SSH, каждый из которых может быть использован для указания удалённого репозитория. Адреса (URL) видимы наверху домашней страницы проекта. Для существующего локального репозитория, следующая команда создаст удалённый репозиторий с именем gitlab и размещением на сервере:

    $ git remote add gitlab https://server/namespace/project.git

    Если у вас нет локального репозитория, можно просто сделать его:

    $ git clone https://server/namespace/project.git

    Веб-интерфейс даёт доступ к нескольким полезным видам самого репозитория. Домашняя страница каждого проекта показывает недавнюю активность, а ссылки наверху ведут на список файлов проекта и журнала коммитов.

    Совместная работа

    Самый простой метод совместной работы над проектом GitLab — это выдача другому пользователю прямого доступа на запись (push) в git-репозитории. Вы можете добавить пользователя в проект в разделе «Участники» («Members») настроек проекта, указав уровень доступа (уровни доступа кратко обсуждались в Группы). Получая уровень доступа «Разработчик» («Developer») или выше, пользователь может беспрепятственно отсылать свои коммиты и ветки непосредственно в репозиторий.

    Другой, более разобщённый способ совместной работы — использование запросов на слияние (merge requests). Эта возможность позволяет любому пользователю, который видит проект, вносить свой вклад подконтрольным способом. Пользователи с прямым доступом могут просто создать ветку, отослать в неё коммиты и открыть запрос на слияние из их ветки обратно в master или любую другую ветку. Пользователи без доступа на запись могут «форкнуть» репозиторий («fork», создать собственную копию), отправить коммиты в эту копию и открыть запрос на слияние из их форка обратно в основной проект. Эта модель позволяет владельцу полностью контролировать, что попадает в репозиторий и когда, принимая помощь от недоверенных пользователей.

    Запросы на слияние и проблемы (issues) это основные единицы долгоживущих дискуссий в GitLab. Каждый запрос на слияние допускает построчное обсуждение предлагаемого изменения (поддерживая облегчённое рецензирование кода), равно как и общее обсуждение. И те и другие могут присваиваться пользователям или организовываться в вехи (milestones).

    Мы в основном сосредоточились на частях GitLab, связанных с git, но это — довольно зрелая система, и она предоставляет много других возможностей, помогающих вашей команде работать совместно, например вики-страницы для проектов и инструменты поддержки системы. Одно из преимуществ GitLab в том, что, однажды запустив и настроив сервер, вам редко придётся изменять конфигурацию или заходить на него по SSH; большинство административных и пользовательских действий можно выполнять через веб-браузер.

    Настройка конвейера непрерывного развертывания с помощью GitLab на Ubuntu 20/22

    GitLab является платформой для совместной работы команд разработчиков и проектом с открытым исходным кодом, в котором реализованы различные полезные функции для DevOps и где можно размещать репозиторий кода. Также платформа предоставляет возможность для отслеживания проблем, размещения пакетов и реестров, сопровождения Wiki, настраивания конвейеров непрерывной интеграции и развертывания (CI/CD).

    В этой инструкции рассмотрим создание конвейера непрерывного развертывания с помощью платформы GitLab. Настроим его при создании образа Docker, разместим в реестр контейнеров GitLab и развернем на собственном сервере, используя утилиту SSH. Запуск конвейера будет для всех фиксаций, размещенных в репозиториях.

    Необходимо развернуть статическую web-страницу, но в данной инструкции большое внимание будет обращено на настройку конвейера непрерывного развертывания.
    После выполнения всех шагов в этой инструкции, мы сможем посетить нашу платформу, введя в адресную строку браузера IP-адрес нашего сервера для получения результатов автоматического развертывания.

    Подготовка к работе

    С необходимыми требованиями для развертывания GitLab на своем сервере, вы можете ознакомиться на официальном сайте проекта.

    Также вам необходимо развернуть сервер на базе Ubuntu/Debian/CentOS. Настроить брандмауэр и добавить пользователя с правами доступа на выполнения команд, используя sudo.

    Установить Docker согласно нашей инструкции.

    Зарегистрироваться на сайте GitLab для развертывания своего проекта, либо развернуть в собственном сервере, как показано в нашем руководстве.

    Создание репозитория в GitLab

    Первым шагом является создание нового проекта в репозитории. Создадим в нём HTML файл. Позже этот файл скопируем в образ Nginx Docker, который мы развернем на собственном сервере.

    Авторизуйтесь в платформе и создайте проект.

    Добавление нового проекта

    Выберем Create blank project.

    Выбор шаблона проекта

    Укажем название проекта, URL проекта, видимость проекта и нажмём на кнопку Create project.

    Настройки проекта

    Создадим новый файл с помощью кнопки New file.

    Создание нового файла

    Укажем в названии файла index.html и вставим наш код:



    GitLab ServerSpace

    Our project in GitLab


    Необходимо сохранить изменения с помощью кнопки Commit. Укажем название нашего изменения и щелкнем по кнопке Commit.

    В этом коде создается пустая страница с одним заголовком, отображающим при открытии страницы надпись Our project in GitLab.

    Создадим Dockerfile и скопируем файл index.html в образ web-сервера Nginx.

    Вернемся на страницу нашего проекта и создадим новый файл.

    Укажем в названии Dockerfile и вставим следующий код.

    FROM nginx:1.18
    COPY index.html /usr/share/nginx/html

    Добавление Dockerfile

    В параметре FROM обращаемся к образу для наследования, в нашем случае образ nginx:1.18. Необходимо указывать версии образов, при указании параметра latest, могут возникнуть проблемы при сборке проекта.

    Параметр COPY копирует ранее созданный index.html в /usr/share/nginx/html в образе Docker. В этом каталоге будут храниться статические страницы HTML-файлов.
    Внесём изменения в репозиторий, нажав на кнопку Commit.

    В следующем шаге рассмотрим настройку GitLab Runner для контроля выполнения заданий по развертыванию.

    Настройка агента GitLab Runner

    Отслеживание среды происходит следующим образом, необходимо зарегистрировать свой сервер, как исполнителя GitLab с закрытым ключом SSH.

    При использовании SSH для входа на свой сервер конвейера развертывания, необходимо сохранить приватный ключ SSH в нашей переменной GitLab CI/CD (рассматривается в шаге Хранение ключа в переменной GitLab).

    Приватный ключ SSH является конфиденциальной частью данных и считается пропуском на сервер. Необходимо обезопасить его и сделать так, чтобы он не попал в чужие руки.

    Мы рассматриваем иную ситуацию, нам нужно предоставить ключ платформе GitLab для доступа к нашему серверу, чтобы автоматизировать процесс развертывания.

    GitLab Runner считается агентом платформы GitLab, который будет выполнять вход на наш сервер, используя приватный ключ. Каждый конвейер GitLab использует агентов, которых будем указывать в конфигурации CI/CD, для выполнения заданий. Задание развертывания будет выполняться на исполнителе GitLab, по этой причине приватный ключ будет размещен на стороне исполнителя для получения доступа к серверу с помощью SSH.

    Авторизуемся в нашем сервере:

    ssh serverspace@server-host-IP

    Установка утилиты gitlab-runner производится путём скачивания скриптового файла и запуска.

    curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh > script.deb.sh

    Запустим файл script.deb.sh с помощью командного интерпретатора bash:

    bash script.deb.sh

    Настройка репозитория

    Установим утилиту с помощью apt:

    apt install gitlab-runner

    После установки получим результат:

    Установка агента GitLab-Runner

    Перейдём в репозиторий проекта и скопируем Token проекта. Перейдём в раздел Settings – CI/CD – Runners. В Set up a specific Runner manually скопируем наш токен и URL адрес в текстовый документ.

    Копирование токена

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

    gitlab-runner register -n —url https://your_gitlab.com —registration-token project_token —executor docker —description «Deployment Runner» —docker-image «docker:stable» —tag-list deployment —docker-privileged

    В результате получим:

    Использование токена для GitLab-Runner

    -n — регистрирует не интерактивно (все параметры выполняются как опции команды);
    –url — адрес GitLab;
    –registration-token — токен из репозитория;
    –executor — тип исполнителя;
    –description — описание;
    –docker-image — образ Docker;
    –tag-list — список тегов;
    –docker-privived – запуск контейнера Docker.

    Если перейдём в раздел Settings – CI/CD – Runners можем получить результат авторизации нашего агента GitLab-Runner:

    Авторизованные агенты

    Создание пользователя для развертывания

    После успешной авторизации необходимо добавить пользователя в сервер, который будет выполнять задания для развертывания:

    useradd -m dep-user
    passwd dep-user

    Добавим пользователя в группу Docker.

    usermod -aG docker dep-user

    Теперь наш пользователь может выполнять команды, используя docker.

    Настройка ключа SSH

    Необходимо переключиться на пользователя dep-user и сгенерировать ключ SSH.
    При выполнении команды укажем путь, где будет сохранён ключ, укажем пароль и повторим:

    ssh-keygen -b 4096

    Создание ключа

    В следующем шаге рассмотрим добавления ключа в настройках репозитория, сделав его доступным при обработке процесса непрерывного развертывания нашего конвейера.

    Копирование ключа в репозиторий проекта

    Нам нужно хранить приватный ключ в платформе GitLab для конвейера, который использует ключ для входа на сервер.

    GitLab добавляет конвейер CI/CD и отправляет все данные исполнителю, которые будут установлены на время выполнения задания.

    Посмотрим наш созданный ключ:

    cat .ssh/authorized_keys

    Скопируем наш ключ и перейдём в Settings – CI/CD – Variables и добавим переменную (Add variable).

    Key: ID_RSA
    Value: Скопированный ключ
    Type: File
    Environment scope: All
    Flags:
    — Protect variable – поставить галочку
    — Mask variable – снять галочку

    Таким образом, добавим адрес нашего сервера и пользователя:

    Key: SERVER_IP
    Value: IP-адрес сервера
    Type: Variable
    Environment scope: All
    Flags:
    — Protect variable – поставить галочку
    — Mask variable – поставить галочку
    Key: SERVER_USER
    Value: dep-user
    Type: Variable
    Environment scope: All
    Flags:
    — Protect variable – поставить галочку
    — Mask variable – поставить галочку

    В следующем шаге рассмотрим описание файла gitlab-ci.yml.

    Конфигурирование gitlab-ci.yml

    Мы собираемся развернуть конвейер, который создаст образ Docker и отправит в реестр контейнеров. В GitLab имеется реестр контейнеров для каждого проекта отдельно. Про реестр контейнеров, можно подробнее изучить, перейдя в раздел Packages & Registers -> Container registry в своём проекте. Можно также воспользоваться официальной документацией GitLab.

    В репозитории проекта создадим файл с названием .gitlab-ci.yml, который будет содержать конфигурацию нашего конвейера.

    stages:
    — publish
    — deploy

    Каждое задание закрепляется за этапом (stages). Задания, которые назначаются одному и тому же этапу (stages), выполняются параллельно. Этапы выполняются в том порядке как указываются. В данном этапе публикация рассматривается первой и за ним развертывание.

    Новые этапы (stages) начинают выполняться после успешного выполнения предыдущего этапа.

    Добавим следующую конфигурацию после записанного этапа:

    variables:
    TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest
    TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHORT_SHA

    CI_REGISTRY_IMAGE: это URL-адрес нашего реестра для контейнеров, которые привязаны к конкретному проекту.
    CI_COMMIT_REF_NAME: наименование ветки либо тега, где будет создаваться проект.
    CI_COMMIT_SHORT_SHA: первые восемь символов ревизии фиксации, для которой создается проект.
    TAG_LATEST: добавляет образ к последнему тегу.
    В $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME указывается имя образа Docker по умолчанию. В документации GitLab, название образа Docker должно соответствовать следующей схеме:

    image name scheme
    ///

    Далее внесём изменения в gitlab-ci.yml и добавим следующий код:

    publish:
    image: docker:latest
    stage: publish
    services:
    — docker:dind
    script:
    — docker build -t $TAG_COMMIT -t $TAG_LATEST .
    — docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY
    — docker push $TAG_COMMIT
    — docker push $TAG_LATEST

    Элемент Publish является первым заданием в нашей конфигурации непрерывного интегрирования и развертывания и хранит в себе несколько команд, которые рассмотрим ниже:

    image – Docker образ, который используется в этой инструкции.
    stage – назначает задание стадии публикации.
    services – обозначает Docker-in-Docker. По этой причине мы зарегистрировали GitLab-Runner в привилегированном режиме.
    Рабочий каталог будет установлен в корень репозитория, когда эти команды будут выполнены.
    docker build: создает образ Docker на основе файла Dockerfile и помечает его последним тегом фиксации, определенным в разделе переменных.
    docker login: регистрирует Docker в реестре контейнеров проекта.
    docker push: отправляет оба тега образа в реестр контейнеров.

    Добавим конфигурацию для развертывания в файл gitlab-ci.yml

    deploy:
    image: debian:latest
    stage: deploy
    tags:
    — deployment
    script:
    — sudo apt update && apt install openssh-server
    — ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP «docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY»
    — ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP «docker pull $TAG_COMMIT»
    — ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP «docker container rm -f ServerSpace || true»
    — ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP «docker run -d -p 80:80 —name ServerSpace $TAG_COMMIT»

    Alpine – является облегченным дистрибутивом для образа Docker.

    В разделе script запускается две конфигурационные команды:

    • chmod og= $ID_RSA: для отмены всех разрешений группы и других лиц без приватного ключа.
    • apk update && apk add openssh-client: APK является пакетным менеджером заданного дистрибутива и в данной команде обновляет информацию о пакетах и устанавливает утилиту ssh клиент.

    Затем используются команды ssh из шаблона:

    • ssh connect pattern for all deployment commands
    • ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP “command”

    -i оператор означает файл идентификации
    – $ID_RSA считается переменным GitLab, в котором содержится путь к файлу приватного ключа.
    -o StrictHostKeyChecking=no: с помощью этого оператора мы автоматически пропускаем вопросы о доверие к удаленному хосту.
    $SERVER_USER и $SERVER_IP — ранее созданные переменные, к которым мы прикрепили имя пользователя и адрес нашего сервера для подключения по SSH.

    Добавим наш последний кусок кода, в котором укажем среду развертывания (environment), название среды (production), адрес нашего сервера (url) и единственный раздел (only):

    environment:
    name: production
    url: http://host-address
    only:
    — main

    Итоговый вид файла .gitlab-ci.yml

    Сохраним наши изменения нажав на Commit changes.

    Тестирование развертывания

    На этом этапе рассмотрим развертывание в разных платформах GitLab, на нашем сервере и в браузере.

    После добавления gitlab-ci.yml в репозиторий, GitLab автоматически обнаружит и запустит конвейер.

    Необходимо перейти в раздел CI/CD -> Pipelines в проекте для просмотра статуса конвейера. В списке конвейеров можем увидеть статус своего проекта Passed. Иногда требуется неопределенное количество времени для завершения запуска конвейера.

    После завершения под столбцом Stages должны появиться две галочки:

    Статус конвейера

    Более подробно можем получить информацию о процессе развертывания с помощью нажатия на «passed» под разделом «Status», и мы получим следующие данные:

    • получим информацию о времени выполнения конвейера;
    • название коммита и ветки;
    • задания, которые выполнялись в этом конвейере и их состояние;

    Рассмотрим статус развертывания.

    Завершение развертывания

    Если прокрутить страницу вверх, мы увидим сообщение о том, что это задание развернуто в рабочей среде. Если нажать на кнопку deploy, то перейдём в раздел с результатами стадии развертывания.

    Production

    Процесс повторного развертывания зависит от конфигурации нашего конвейера. Наш конвейер может повторно выполнять те же задания, которые были указаны в .gitlab-ci.yml.

    Если нажать на кнопку «Посмотреть развертывание» (View deployment), то откроется страница с адресом нашего сервера, и увидим надпись «Our project in GitLab».
    Для проверки развернутого контейнера перейдём на наш сервер и подключимся по ssh.

    Далее проверим список контейнеров с помощью команды:

    docker container ls

    И получим следующий результат

    CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
    ba1a841c23d4 registry.gitlab-server.com/authorized_user_of_gitlab/serverspace/master:commit «nginx -g ‘daemon of. » 4 hours ago Up 4 hours 0.0.0.0:80->80/tcp gitlab-serverspace

    Также предлагаем ознакомиться с нашей инструкцией по «Установке и настройке Docker».

    На следующем этапе рассмотрим откат развертывания.

    Откат непрерывного развертывания

    Если обновить веб-страницу, создастся новое развертывание, а затем повторно развернет предыдущее развертывание с использованием сред GitLab. Тем самым охватывает вариант использования отката развертывания в случае ошибочного развертывания.

    Необходимо внести в файле index.html внести небольшое изменение:

    • Перейдём в репозиторий проекта с файлом index.html.
    • Нажмем кнопку «Редактировать» для открытия редактора конвейера.
    • Удалим старый код и добавим новый:


    Successful


    Необходимо сохранить изменения с помощью кнопки «Commit changes».

    Запустится новый конвейер развертывания. В GitLab перейдём в раздел CI/CD > Pipelines. После успешного завершения заданий в конвейере необходимо открыть web-страницу по адресу нашего сервера, в котором отображается надпись Successful.
    Если перейти в раздел Deployments > Environments > production, отображается новый созданный конвейер развертывания. Теперь нажмем кнопку повторного развертывания конвейера для отката на исходное состояние:

    Откат изменений

    Необходимо подтвердить откат во всплывающем окне.

    Наш конвейер развертывания запустит процесс обратного отката и перенаправит автоматически на страницу с результатами выполненного задания. Необходимо подождать до завершения задания и открыть web-страницу, указав адрес нашего сервера в браузере. В итоге будет отображаться старая надпись «Our project in GitLab».

    Выводы

    В этой инструкции мы рассмотрели:

    • создание проекта на сайте GitLab;
    • установку и настройку GitLab на своём сервере;
    • привязку gitlab-runner по SSH ключу на платформе GitLab;
    • описание gitlab-ci.yml с заданиями;
    • описание Dockerfile для запуска образа nginx в контейнере на сервере;
    • запуск процесса непрерывной интеграции и развертывания;
    • откат процесса развертывания web-страницы.
    Похожие публикации:
    1. Html engine что это
    2. Для чего нужен context react
    3. Как вывести содержимое файла в консоль linux
    4. Как отключить блокировщик рекламы в яндекс браузере

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *