Автоматизація оновлення проєктів через GitLab CI/CD на Linux сервері

4 Березня 2024 в 16:47 25

Впровадження автоматичного оновлення проєктів є ключовим аспектом сучасних DevOps практик, забезпечуючи неперервне інтегрування та доставку (CI/CD). Одним із важливих інструментів для реалізації таких процесів є GitLab CI/CD, який дозволяє автоматизувати оновлення проєктів на серверах. У цій статті ми розглянемо, як налаштувати GitLab CI/CD для виконання скрипта auto_update_test.sh на Linux сервері кожного разу, коли відбувається злиття гілки розробки з головною гілкою.

Проблема

Потрібно автоматизувати процес оновлення проєкту на Linux сервері за допомогою GitLab CI/CD, виконуючи скрипт auto_update_test.sh при кожному злитті функціональної гілки з головною гілкою в GitLab. Проєкт зберігається у директорії /opt/splunktest на сервері, де вже встановлено та зареєстровано GitLab Runner.

Рішення

Для вирішення цієї задачі потрібно правильно налаштувати файл .gitlab-ci.yml в корені вашого проєкту в GitLab і забезпечити правильне налаштування скрипту auto_update_test.sh на сервері.

Налаштування `.gitlab-ci.yml`

# .gitlab-ci.yml
stages:
  - deploy
deploy:
  stage: deploy
  script:
    - ./auto_update_test.sh
  only:
    - main

# .gitlab-ci.yml

stages:

- deploy

deploy:

stage: deploy

script:

- ./auto_update_test.sh

only:

- main

Цей файл конфігурації вказує GitLab CI/CD виконати скрипт auto_update_test.sh як частину етапу розгортання (deploy), але лише тоді, коли зміни зливаються в головну гілку (main).

Налаштування скрипта `auto_update_test.sh`

#!/bin/bash
# Path to your Splunk app directory
APP_DIR="/opt/splunktest"
#Git pull in the dev branch
cd "$APP_DIR" || exit
git pull origin main

#!/bin/bash

# Path to your Splunk app directory

APP_DIR="/opt/splunktest"

#Git pull in the dev branch

cd "$APP_DIR" || exit

git pull origin main

У цьому скрипті виконується команда git pull для оновлення репозиторію в директорії /opt/splunktest з головної гілки (main).

Типові проблеми та їх рішення

Помилка “No such file or directory”

Якщо ви отримуєте помилку “No such file or directory” під час виконання скрипта, переконайтеся, що шлях до директорії в APP_DIR вказано правильно і що GitLab Runner має права на читання та виконання скрипту в цій директорії. Також, важливо переконатись, що користувач, під яким працює GitLab Runner, доданий до групи користувачів, які мають доступ до проєкту (у вашому випадку, це група splunk).

Відсутність виконуваних прав

Переконайтеся, що на скрипт auto_update_test.sh надано виконувані права за допомогою команди chmod +x auto_update_test.sh. Без цих прав скрипт не зможе бути виконаним GitLab Runner.

Перезапуск служб

Якщо для коректної роботи вашого проєкту після оновлення потрібен перезапуск певних служб (наприклад, Splunk або самого GitLab Runner), додайте відповідні команди в кінець скрипта auto_update_test.sh. Наприклад:

# Перезапуск Splunk
systemctl restart splunk

1 2	# Перезапуск Splunk systemctl restart splunk

Таке налаштування дозволяє забезпечити, що всі компоненти вашого проєкту будуть коректно оновлені і перезапущені після кожного злиття гілок.

Заключення

Автоматизація процесу оновлення проєктів через GitLab CI/CD на Linux сервері може значно спростити роботу розробників та адміністраторів систем, забезпечуючи швидке та ефективне впровадження змін. Важливо правильно налаштувати файл .gitlab-ci.yml та скрипти оновлення, а також забезпечити відповідні права доступу та виконання для GitLab Runner, щоб уникнути типових проблем. Застосування цих рекомендацій допоможе вам успішно автоматизувати процеси CI/CD для ваших проєктів.