Полный цикл в digital

Разворачивание исходников на сервере

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

Дальше перед вами откроется редактор файла .gitlab-ci.yml, файл в формате YAML, поэтому отступы перед значениями очень важны. Сразу можете удалить все комментарии и код который есть в файле. Структура самого простого файла примерно такая:

gitlab-ci.yml# этапы задачь
stages:
  - deploy
# задача на деплой
deploy-prod:
  # этап задачи
  stage: deploy
  # выполняем скрипты
  script:
    # выводим сообщение
    - echo "Деплой hmarketing успешно отработал"

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

Здесь отображаются все задачи CI/CD. В данном случае у вас должна быть одна задача:

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

В результате откроется лог выполнения раннера для этой задачи:

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

Простое разворачивание на сервере

При простом разворачивание на сервере, в момент регистрации Runner'а, в качестве исполнителя должно быть выбрано значение Shell. Подробнее можно почитать в статье про регистрацию Runner'а.

Если все шаги выполнены правельно, программа уже скачивает исходники на сервер и складывает их в домашнию папку по пуи home -> gitlab-runner -> build:

Настраивать раннер загружать исходники прямо в папку веб-сервера не стоит, программа для этого не предназначена. Для копирования исходников лучше использовать rsync. Эта утилита позволяет копировать только изменившиеся файлы. Например, для копирования файлов из репозитория в /var/www/project необходимо добавить такую команду в секцию script:

rsync -av --no-perms --no-owner --no-group --exclude ".git*" $CI_PROJECT_DIR/ /var/www/project

Папка, в которую вы собираетесь разврачивать проект должна существовать на сервере и у пользователя gitlab-runner должны быть права на запись в неё:

sudo mkdir -p /var/www/project
sudo chown gitlab-runner:gitlab-runner /var/www/project

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

Если всё было сделано верно на этот раз, то файлы появятся в папке:

Лог выполнения раннера для этой задачи:

Насторойка Rsync при простом разворачивание

Зададим нужные привилегии пользователю gitlab-runner добавим его в группу sudo, команду выполняем от суперпользователя root:

usermod -aG sudo gitlab-runner

Разрешим запуск команд без пароля, меняем строки в файле /etc/sudoers:

#%sudo  ALL=(ALL:ALL) ALL
%sudo ALL=(ALL) NOPASSWD:ALL

При помоши редактора nano:

nano /etc/sudoers

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

gitlab-runner ALL= (root) NOPASSWD: /usr/bin/mkdir
gitlab-runner ALL= (root) NOPASSWD: /usr/bin/touch

Пример файла

gitlab-ci.yml# этапы задачь
stages:
  - deploy
# задача на деплой
deploy-prod:
  # этап задачи
  stage: deploy
  # выполняем скрипты
  script:
    # выкачиваем ветку main
    - git checkout main && git pull origin main
    # запускаем rsync для копирования файлов в рабочию директорию
    # атрибут -a сохраняются все атрибуты оригинальных файлов
    # атрибут -v выводим подробную информацию о процессе копирования
    # атрибут --stats показать статистику передачи
    # атрибут --exclude исключаем файлы по шаблону
    # атрибут --delete удаляем файлы которых нет в источнике
    # атрибут $CI_PROJECT_DIR путь, по которому клонируется проект и где выполняется задание
    # атрибут /var/www/project путь, куда клонируется проект
    - rsync -av --stats --delete --exclude={'.git','.gitlab-ci.yml','.gitignore','README.md','node_modules','package.json','package-lock.json','gulpfile.js'} $CI_PROJECT_DIR/ /var/www/project
    # устанавливаем права 775 на дириктории по пути /var/www/project
    - sudo find /var/www/project -type d -exec chmod 775 {} +
    # устанавливаем права 664 на файлы по пути /var/www/project
    - sudo find /var/www/project -type f -exec chmod 664 {} +
    # меняем владельца для пути /var/www/project
    - sudo chown -R gitlab-runner:gitlab-runner /var/www/project
    # выводим сообщение
    - echo "Деплой hmarketing успешно отработал"
  rules:
    # деплой запускается автоматически при мерже в ветку main
    - if: $CI_COMMIT_BRANCH == "main"

Пример файла для автоматического разворачивания стилей и скриптов посредствам Gulp

gitlab-ci.yml# этапы задачь
stages:
  - deploy
# задача на деплой
deploy-prod:
  # этап задачи
  stage: deploy
  # выполняем скрипты
  script:
    # выкачиваем ветку main
    - git checkout main && git pull origin main
    # устанавливаем/обновляем npm
    - npm install -s
    # запускаем сборку проекта через npm
    - npm run build
    # запускаем rsync для копирования файлов в рабочию директорию
    # атрибут -a сохраняются все атрибуты оригинальных файлов
    # атрибут -v выводим подробную информацию о процессе копирования
    # атрибут --stats показать статистику передачи
    # атрибут --exclude исключаем файлы по шаблону
    # атрибут --delete удаляем файлы которых нет в источнике
    # атрибут $CI_PROJECT_DIR путь, по которому клонируется проект и где выполняется задание
    # атрибут /var/www/project путь, куда клонируется проект
    - rsync -av --stats --delete --exclude={'.git','.gitlab-ci.yml','.gitignore','README.md','node_modules','package.json','package-lock.json','gulpfile.js'} $CI_PROJECT_DIR/ /var/www/project
    # устанавливаем права 775 на дириктории по пути /var/www/project
    - sudo find /var/www/project -type d -exec chmod 775 {} +
    # устанавливаем права 664 на файлы по пути /var/www/project
    - sudo find /var/www/project -type f -exec chmod 664 {} +
    # меняем владельца для пути /var/www/project
    - sudo chown -R gitlab-runner:gitlab-runner /var/www/project
    # выводим сообщение
    - echo "Деплой hmarketing успешно отработал"
  rules:
    # деплой запускается автоматически при мерже в ветку main
    - if: $CI_COMMIT_BRANCH == "main"

Полный проек можно посмотреть и скачать в моем Гите.

Разворачивание на сервере внутри контейнера Docker

При простом разворачивание на сервере, в момент регистрации Runner'а, в качестве исполнителя должно быть выбрано значение Docker. Подробнее можно почитать в статье про регистрацию Runner'а.

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

Установка Docker

Устанавливаем Docker на сервер с веб проектом, подробнее об этом смотрите инструкцию Установка Docker на Linux.

Регистрация Runner'а

При регистрации раннера на последнем этапе, где предлагается выбрать средство запуска Enter an executor, выбираем docker:

Enter an executor: parallels, virtualbox, docker+machine, docker-ssh+machine, kubernetes, custom, docker, docker-ssh, shell, ssh:
docker
Настройка ssh

Сгенерируем ключи ssh при помощи команды:

ssh-keygen

Ключи можно разместить где угодно, их можно сгенерировать один раз и забыть про них. В данном случае будут сгенерированы 2 ключа:

  1. ~/.ssh/id_rsa.pub публичный ключ неоходимо разместить на сервере в дириктории ~/.ssh/authorized_keys, к которому происходит подключение. Если этого файла нет, его нужно создать
  2. ~/.ssh/id_rsa приватный ключ необходимо разместить в переменной CI/CD под названием SSH_PRIVATE_KEY
Добавляем образ

При написании pipeline мы должны добавить опцию image с указанием образа, который хотим использовать. Важно понимать, все команды будут выполнятся в изолированной среде Docker используя только те программы которые в нем есть:

bioqwer/ubuntu-rsync:0.1
Располагаем образ локально

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

nano /etc/gitlab-runner/config.toml

Находим созданный раннер, определяем по описанию, которое мы задавали при регистрации и в нем также находим [runners.docker]::

[[runners]]
  name = "3711995-ot93272.twc1.net"
  url = "https://gitlab.com/"
  id = 43328766
  token = "t3_yV2ke9HH4Ks7J1f8d-LP"
  token_obtained_at = 2024-11-04T17:15:05Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    MaxUploadedArchiveSize = 0
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    tls_verify = false
    image = "ruby:2.7"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    network_mtu = 0

И добавим опцию pull_policy:

pull_policy = "if-not-present"
Перезапуск сервиса

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

systemctl restart gitlab-runner

Пример файла

gitlab-ci.ymldefault:
  # образ докера
  image: bioqwer/ubuntu-rsync:0.1
  # подготовительные скрипты
  before_script:
    # включаем ssh агент
    - eval $(ssh-agent -s)
    # добавляем в ssh агент секретный ключ
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    # создаем в домашней дириктории папку .ssh
    - mkdir -p ~/.ssh
    # задаем для папки .ssh права
    - chmod 700 ~/.ssh
    # отключаем строгую проверку ключа хоста для всех хостов
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
# этапы задачь
stages:
  - deploy
# задача на деплой
deploy-prod:
  # этап задачи
  stage: deploy
  # выполняем скрипты
  script:
    # выкачиваем ветку main
    - git checkout main && git pull origin main
    # запускаем rsync для копирования файлов в рабочию директорию
    # атрибут -a сохраняются все атрибуты оригинальных файлов
    # атрибут -v выводим подробную информацию о процессе копирования
    # атрибут --stats показать статистику передачи
    # атрибут --exclude исключаем файлы по шаблону
    # атрибут --delete удаляем файлы которых нет в источнике
    # атрибут $CI_PROJECT_DIR путь, по которому клонируется проект и где выполняется задание
    # атрибут /var/www/project путь, куда клонируется проект
    - rsync -av --stats --delete --exclude={'.git','.gitlab-ci.yml','.gitignore','README.md','node_modules','package.json','package-lock.json','gulpfile.js'} $CI_PROJECT_DIR/ gitlab-runner@194.87.118.230:/var/www/project
    # устанавливаем права 775 на дириктории по пути /var/www/project
    - ssh gitlab-runner@194.87.118.230 "sudo find /var/www/project -type d -exec chmod 775 {} +"
    # устанавливаем права 664 на файлы по пути /var/www/project
    - ssh gitlab-runner@194.87.118.230 "sudo find /var/www/project -type f -exec chmod 664 {} +"
    # меняем владельца для пути /var/www/project
    - ssh gitlab-runner@194.87.118.230 "sudo chown -R gitlab-runner:gitlab-runner /var/www/project"
    # выводим сообщение
    - echo "Деплой hmarketing успешно отработал"
  rules:
    # деплой запускается автоматически при мерже в ветку main
    - if: $CI_COMMIT_BRANCH == "main"

Заполните форму уже сегодня!
Для начала сотрудничества необходимо заполнить заявку или заказать обратный звонок. В ответ получите коммерческое предложение, которое будет содержать индивидуальную стратегию с учетом требований и поставленных задач
Работаем по будням с 9:00 до 18:00. Заявки, отправленные в выходные, обрабатываем в первый рабочий день до 12:00.
Спасибо, ваш запрос принят и будет обработан!
Эйч Маркетинг