¶ 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 допоможе зберегти файл у чистоті, не дозволить випадковим браузерам репозиторію побачити деталі середовища та дозволить вам змінити значення конфігурації без редагування файлу конвеєра.
Стаття взята тут