¶ Rsync и SSH GitLab CI/CD
GitLab CI/CD поддерживает несколько типов исполнителей конвейера. Они определяют среду, в которой будет выполняться ваше задание. Исполнитель оболочки используется по умолчанию и работает на хост-компьютере. Это позволяет вашим конвейерам использовать любую команду, доступную на хосте, без дополнительной настройки. Поскольку большинство популярных дистрибутивов Linux поставляются с установленным rsync, с этим подходом легко справиться.
К сожалению, shell executer не обеспечивает надежной изоляции и со временем может загрязнить среду вашего хоста. Лучшей альтернативой является исполнитель docker, который запускает новый контейнер Docker для каждого задания CI/CD. Все задания выполняются в чистой среде, которая не может повлиять на хост.
Недостатком здесь является то, что базовые образы Docker обычно не включают rsync или ssh. Даже официальные образы ОС, такие как ubuntu:latest, поставляются в виде минимальных сборок без этих команд. Это делает несколько более сложным конвейерным сценарием для добавления зависимостей и rsync ваших файлов.
Вот как добавить rsync в ваш конвейер. Прежде чем продолжить, убедитесь, что у вас есть GitLab Runner на основе Docker. Мы также предполагаем, что у вас есть готовый к использованию проект GitLab.
¶ Подготовка
Вам понадобится пара ключей SSH, если вы будете использовать rsync для подключения к удаленному хосту SSH. Вы можете сгенерировать открытые и закрытые ключи, запустив ssh-keygen -t rsa. Скопируйте открытый ключ на сервер, к которому вы будете подключаться.
Затем скопируйте сгенерированный закрытый ключ в буфер обмена:
cat ~/.ssh/id_rsa | xclip -selection c
Перейдите в свой проект GitLab и нажмите Settings в нижней части левого навигационного меню. Щелкните пункт CI/CD в подменю. Прокрутите страницу вниз до раздела Variables.
Нажмите синюю кнопку Add variable. Дайте вашей новой переменной имя в поле Key. Мы используем SSH_PRIVATE_KEY. Вставьте свой закрытый ключ в поле Value, включая начальную строку ----BEGIN и конечную строку -----END.
¶ Добавление Pipeline
GitLab CI/CD запускает задания на основе содержимого файла .gitlab-ci.yml в вашем репозитории. GitLab автоматически найдет этот файл и запустит определенный им конвейер, когда вы отправляете изменения в свои ветки.
deploy:
stage: deploy
image: alpine:latest
script:
- rsync -atv --delete --progress ./ user@wiset.pp.ua:/var/www/html
Этот .gitlab-ci.yml содержит задание, которое использует rsync для синхронизации содержимого рабочего каталога с /var/www/html на сервере example.com. Он использует образ alpine:latest Docker в качестве среды сборки. Конвейер в настоящее время не работает, так как rsync не включен в образ Alpine.
¶ Установка SSH и rsync
Alpine — хорошая основа для работы, потому что это легковесный образ с небольшим количеством зависимостей. Это снижает использование сети, в то время как GitLab загружает образ в начале задания, ускоряя конвейер. Чтобы заставить rsync работать, добавьте в образ SSH и rsync, а затем запустите агент SSH и зарегистрируйте сгенерированный ранее закрытый ключ.
deploy:
stage: deploy
image: alpine:latest
before_script:
- apk update && apk add openssh-client rsync
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" | ssh-add -
script:
- rsync -atv --delete --progress ./ user@example.com:/var/www/html
OpenSSH и rsync устанавливаются с помощью менеджера пакетов Alpine apk. Запускается агент аутентификации SSH, и ваш закрытый ключ добавляется через ssh-add. GitLab автоматически вставляет переменную среды SSH_PRIVATE_KEY со значением, которое вы определили в настройках вашего проекта.
Если вы использовали другой ключ на экране переменных GitLab, убедитесь, что вы соответствующим образом настроили конвейер.
¶ Управление Host Verification
SSH интерактивно запрашивает подтверждение при первом подключении к новому удаленному хосту. Это несовместимо со средой CI/CD, где вы не сможете видеть эти запросы или отвечать на них.
Для решения этой проблемы доступны два варианта: отключить строгие проверки ключей хоста или заранее зарегистрировать свой сервер как «known» хост.
Для первого варианта добавьте следующую строку в файл before_script вашего пайплайна:
- echo "Host *ntStrictHostKeyChecking no" >> ~/.ssh/config
Хотя это работает, это потенциальная угроза безопасности. У вас не будет предупреждения, если злоумышленник получит контроль над доменом или IP-адресом вашего сервера. Использование проверки ключа хоста позволяет вам убедиться, что личность удаленного устройства соответствует вашим ожиданиям.
Вы можете добавить удаленное устройство в качестве известного узла неинтерактивно, подключившись к нему на своем собственном компьютере за пределами конвейера. Проверьте файл ~/.ssh/known_hosts и найдите строку, содержащую IP-адрес или имя хоста удаленного устройства. Скопируйте эту строку и используйте описанную ранее процедуру, чтобы добавить новую переменную GitLab CI/CD. Назовите эту переменную SSH_HOST_KEY.
Теперь обновите раздел before_script следующей строкой:
- echo "$SSH_HOST_KEY" > ~/.ssh/known_hosts
Теперь вы сможете подключиться к серверу, не получая никаких запросов на подтверждение. Отправьте свой код в репозиторий GitLab и наблюдайте за завершением конвейера.
¶ Улучшения
Этот конвейер — простой пример того, как начать работу с SSH и rsync в среде Dockerized. Существуют возможности для дальнейшего улучшения системы путем переноса этапов подготовки на выделенный этап сборки, на котором создается образ Docker, который можно повторно использовать между конвейерами.
.gitlab-ci.yml также выиграет от более широкого использования переменных. Абстрагирование имени хоста удаленного сервера (wiset.pp.ua), каталога (/var/www/html) и пользователя (user) в переменные GitLab CI/CD поможет сохранить файл в чистоте, не позволит случайным браузерам репозитория увидеть детали среды и позволит вам изменить значения конфигурации без редактирования файла конвейера.
Статья взята тут