Розгортання центра

Що ми налаштовуємо і навіщо

Зі зростанням складності сучасних IT-систем, кількість генерованих логів експоненціально збільшується. Кожен сервіс, додаток, операційна система та мережевий пристрій створює власні журнали подій. Ручний перегляд цих логів на безлічі серверів стає неефективним, а часто й неможливим. Централізована система логування вирішує цю проблему, збираючи всі логи в одному місці для зручного пошуку, аналізу та моніторингу.

Ми будемо розгортати стек, що складається з трьох ключових компонентів:

• Fluent Bit: Легковажний та високопродуктивний процесор логів, метрик і трасувань. Він буде встановлений на сервері (або кількох серверах), де генеруються логи, і відповідатиме за їх збір, фільтрацію, трансформацію та надсилання до центрального сховища. Fluent Bit відомий своїм низьким споживанням ресурсів, що робить його ідеальним для використання на VPS або в контейнеризованих середовищах.
• OpenSearch: Форк Elasticsearch, що є розподіленою, масштабованою пошуковою та аналітичною СУБД, оптимізованою для роботи з великими обсягами даних, такими як логи. OpenSearch забезпечує швидку індексацію та пошук, агрегацію даних та зберігання історичних записів.
• OpenSearch Dashboards: Веб-інтерфейс для OpenSearch, що дозволяє візуалізувати дані, створювати дашборди, виконувати інтерактивний пошук та аналізувати логи без прямої взаємодії з API OpenSearch. Це основний інструмент для операторів та розробників.

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

Альтернативи: Cloud-managed vs Self-hosted

Існує два основні підходи до реалізації систем логування:

• Cloud-managed рішення: Такі сервіси, як AWS CloudWatch, Google Cloud Logging, Azure Monitor, Datadog, Splunk Cloud, Logz.io та інші. Вони пропонують повністю керовані платформи, знімаючи з вас турботи щодо розгортання, масштабування та обслуговування інфраструктури. Переваги включають простоту використання, високу доступність та потужні функції з коробки. Недоліки — висока вартість, особливо при великих обсягах логів, та потенційна прив'язка до конкретного хмарного провайдера.
• Self-hosted рішення на VPS/dedicated сервісі: Це підхід, який ми реалізуємо в цьому посібнику. Ви самостійно встановлюєте та керуєте всіма компонентами на власному або орендованому сервері. Переваги включають повний контроль над даними, значно нижчі експлуатаційні витрати (особливо для середніх та великих обсягів), можливість тонкого налаштування під специфічні потреби та відсутність прив'язки до провайдера. Недоліки — необхідність у технічних знаннях для розгортання та обслуговування, а також відповідальність за забезпечення надійності та масштабованості системи.

Вибір self-hosted рішення на VPS ідеально підходить для власників VPS/dedicated серверів, стартапів, розробників та компаній, які хочуть заощадити на хмарних витратах, зберігаючи при цьому гнучкість та контроль. Для обсягів логів до кількох десятків гігабайт на день цей підхід виявляється найбільш економічно вигідним і дозволяє ефективно використовувати ресурси сервера.

Який VPS-конфіг потрібен для цього завдання

Вимоги до VPS для централізованої системи логування сильно залежать від обсягу генерованих логів, частоти їх надходження, а також від періоду зберігання даних. Для початкового розгортання та середніх навантажень (до 10-20 ГБ логів на день) можна орієнтуватися на такі параметри:

Мінімальні вимоги

• CPU: 2 ядра. OpenSearch досить вимогливий до процесора для індексації та виконання запитів.
• RAM: 8 ГБ. OpenSearch активно використовує оперативну пам'ять для кешування індексів та буферів. Менше 8 ГБ може призвести до низької продуктивності та частих збоїв.
• Диск: 100-200 ГБ SSD. SSD критично важливий для продуктивності OpenSearch, оскільки операції введення-виведення (читання/запис логів) дуже інтенсивні. Обсяг диска має бути достатнім для зберігання логів за бажаний період. При 10 ГБ логів на день, 200 ГБ вистачить на ~20 днів.
• Мережа: 100 Мбіт/с. Для передачі логів та доступу до Dashboards.

Рекомендований VPS-план для початкового розгортання

Для більш комфортної роботи та можливості масштабування в майбутньому, а також для зберігання логів за більший період, рекомендується наступний конфіг:

• CPU: 4 ядра.
• RAM: 16 ГБ.
• Диск: 500 ГБ NVMe SSD. NVMe забезпечить значно вищу швидкість читання/запису порівняно зі звичайним SSD, що критично важливо для OpenSearch.
• Мережа: 1 Гбіт/с.

Для оренди VPS з такими характеристиками можна розглянути VPS із зазначеними характеристиками, що пропонують гнучкі тарифи та високу продуктивність.

Коли потрібен dedicated, а не VPS

Dedicated сервер стає необхідним, коли обсяги логів перевищують можливості одного потужного VPS, або коли потрібна максимальна продуктивність та ізоляція ресурсів. Це актуально для сценаріїв, де:

• Обсяг логів становить сотні гігабайт або терабайти на день.
• Потрібне тривале зберігання логів (місяці, роки) зі швидким доступом.
• Необхідний кластер OpenSearch з кількох вузлів для забезпечення високої доступності та розподілу навантаження.
• Важливі специфічні апаратні конфігурації (наприклад, дуже швидкі NVMe RAID масиви, велика кількість RAM).

У таких випадках, оренда відповідного dedicated сервера з можливістю кастомізації конфігурації буде більш виправданою.

Локація: на що впливає

Вибір локації VPS або dedicated сервера впливає на кілька факторів:

• Затримка (Latency): Чим ближче сервер до джерел логів (ваших додатків) та до користувачів OpenSearch Dashboards, тим менша затримка при передачі даних та роботі з інтерфейсом. Для критично важливих систем обирайте локації, максимально наближені до ваших основних серверів.
• Законодавство: У різних країнах діють різні закони щодо зберігання даних. Переконайтеся, що обрана локація відповідає вимогам конфіденційності та регуляторам, якщо це стосується ваших даних.
• Вартість: Ціни на сервери можуть незначно відрізнятися в різних регіонах.

Оптимальним є розміщення системи логування в тому ж датацентрі або регіоні, де знаходяться основні сервери, що генерують логи.

Підготовка сервера

Перед встановленням основних компонентів необхідно виконати базове налаштування безпеки та встановити необхідні утиліти. Ми будемо використовувати Ubuntu Server 24.04 LTS як основу.

1. Підключення по SSH та створення користувача

Підключіться до вашого VPS як користувач root (якщо це єдиний доступ) і створіть нового користувача з правами sudo. Замініть youruser на бажане ім'я користувача.

ssh root@your_vps_ip # Підключення до сервера
adduser youruser # Створення нового користувача
usermod -aG sudo youruser # Додавання користувача до групи sudo

Вийдіть із сесії root і увійдіть під новим користувачем:

exit # Вихід із сесії root
ssh youruser@your_vps_ip # Вхід під новим користувачем

2. Оновлення системи

Завжди починайте з оновлення пакетної бази та встановлених пакетів.

sudo apt update # Оновлення списку пакетів
sudo apt upgrade -y # Оновлення всіх встановлених пакетів
sudo apt autoremove -y # Видалення непотрібних залежностей

3. Налаштування SSH-ключів (рекомендується)

Для підвищення безпеки рекомендується використовувати SSH-ключі замість паролів. Якщо ви ще не використовуєте їх, згенеруйте пару ключів на локальній машині та скопіюйте публічний ключ на VPS.

# На вашій локальній машині
ssh-keygen -t rsa -b 4096 # Генеруємо SSH-ключі (якщо їх немає)
ssh-copy-id youruser@your_vps_ip # Копіюємо публічний ключ на VPS

Після цього вимкніть вхід за паролем для SSH (рекомендується, але будьте обережні, щоб не заблокувати собі доступ):

sudo nano /etc/ssh/sshd_config # Відкриваємо конфігурацію SSH-сервера

Знайдіть і змініть наступні рядки:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no # Може знадобитися вимкнути, якщо використовуються інші методи автентифікації

Збережіть файл і перезапустіть SSH-сервіс:

sudo systemctl restart sshd # Перезапуск SSH-сервісу

4. Налаштування брандмауера (UFW)

Дозвольте лише необхідні порти: SSH (22), HTTP (80), HTTPS (443). Для OpenSearch Dashboards ми будемо використовувати HTTPS.

sudo ufw allow 22/tcp # Дозволяємо SSH
sudo ufw allow 80/tcp # Дозволяємо HTTP (для Caddy/Certbot)
sudo ufw allow 443/tcp # Дозволяємо HTTPS (для Caddy/Dashboards)
sudo ufw enable # Вмикаємо брандмауер
sudo ufw status # Перевіряємо статус

5. Встановлення Fail2Ban

Fail2Ban допомагає захиститися від брутфорс-атак, блокуючи IP-адреси, з яких відбуваються численні невдалі спроби входу.

sudo apt install fail2ban -y # Встановлення Fail2Ban
sudo systemctl enable fail2ban # Увімкнення автозапуску сервісу
sudo systemctl start fail2ban # Запуск сервісу

Створіть локальну конфігурацію для Fail2Ban, щоб вона не перезаписувалася під час оновлень:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # Копіювання базового конфігу
sudo nano /etc/fail2ban/jail.local # Редагування локального конфігу

У файлі jail.local переконайтеся, що секція [sshd] активна (enabled = true) і налаштуйте параметри на свій розсуд (наприклад, bantime, findtime, maxretry).

[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

Збережіть і перезапустіть Fail2Ban:

sudo systemctl restart fail2ban # Перезапуск Fail2Ban для застосування змін

6. Встановлення Docker та Docker Compose

OpenSearch та OpenSearch Dashboards будуть розгорнуті в Docker-контейнерах для спрощення керування та ізоляції. Caddy також працюватиме в Docker.

# Встановлення залежностей для Docker
sudo apt install ca-certificates curl gnupg lsb-release -y

# Додавання GPG-ключа Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Додавання репозиторію Docker
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Встановлення Docker Engine
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

# Додавання поточного користувача до групи docker для роботи без sudo
sudo usermod -aG docker youruser

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

exit
ssh youruser@your_vps_ip

Перевірте встановлення Docker:

docker run hello-world # Запуск тестового контейнера

Якщо ви бачите вітальне повідомлення, Docker встановлено коректно.

Встановлення ПЗ — покроково

Тепер, коли сервер підготовлено, приступимо до встановлення Fluent Bit, OpenSearch та OpenSearch Dashboards. Ми будемо використовувати Docker Compose для OpenSearch/Dashboards та нативне встановлення Fluent Bit.

1. Підготовка каталогів для OpenSearch та Caddy

Створимо необхідні каталоги для зберігання даних OpenSearch та конфігурації Caddy. Це дозволить зберігати дані навіть при перестворенні контейнерів.

mkdir -p ~/opensearch/data # Каталог для даних OpenSearch
mkdir -p ~/opensearch/dashboards/config # Каталог для конфігів OpenSearch Dashboards
mkdir -p ~/caddy/config # Каталог для конфігів Caddy
mkdir -p ~/caddy/data # Каталог для сертифікатів Caddy

Встановимо правильні права доступу для каталогу даних OpenSearch, оскільки контейнер OpenSearch запускається від непривілейованого користувача.

sudo chown -R 1000:1000 ~/opensearch/data # Змінюємо власника на UID 1000

2. Створення файлу Docker Compose для OpenSearch та OpenSearch Dashboards

Створимо файл docker-compose.yml у домашньому каталозі, який визначить сервіси OpenSearch та OpenSearch Dashboards.

nano ~/docker-compose.yml

Вставте наступний вміст. Зазначені версії (OpenSearch 2.12.0, OpenSearch Dashboards 2.12.0) актуальні на початок 2026 року та є стабільними.

# docker-compose.yml
version: '3.8'
services:
  opensearch:
    image: opensearchproject/opensearch:2.12.0 # Актуальна версія OpenSearch на 2026 рік
    container_name: opensearch
    environment:
      - cluster.name=opensearch-cluster
      - node.name=opensearch-node1
      - discovery.type=single-node
      - bootstrap.memory_lock=true
      - OPENSEARCH_JAVA_OPTS=-Xms4g -Xmx4g # Виділіть половину RAM сервера, але не більше 30 ГБ
      - DISABLE_SECURITY_PLUGIN=true # Вимикаємо плагін безпеки для простоти, для продакшену його потрібно налаштувати
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - ~/opensearch/data:/usr/share/opensearch/data # Збереження даних OpenSearch
    ports:
      - "9200:9200" # Порт для API OpenSearch
      - "9600:9600" # Порт для Transport Layer
    networks:
      - opensearch-net
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:9200/_cat/health || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 5

  opensearch-dashboards:
    image: opensearchproject/opensearch-dashboards:2.12.0 # Актуальна версія OpenSearch Dashboards
    container_name: opensearch-dashboards
    environment:
      - OPENSEARCH_HOSTS=["http://opensearch:9200"] # Підключення до OpenSearch
    volumes:
      - ~/opensearch/dashboards/config/opensearch_dashboards.yml:/usr/share/opensearch-dashboards/config/opensearch_dashboards.yml # Конфіг Dashboards
    ports:
      - "5601:5601" # Порт для OpenSearch Dashboards
    networks:
      - opensearch-net
    depends_on:
      opensearch:
        condition: service_healthy # Запускаємо Dashboards тільки після OpenSearch
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:5601/api/status || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 5

  caddy:
    image: caddy:2.7.6-alpine # Легковажна та актуальна версія Caddy на 2026 рік
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80" # Для Let's Encrypt
      - "443:443" # Для HTTPS
    volumes:
      - ~/caddy/Caddyfile:/etc/caddy/Caddyfile # Конфігурація Caddy
      - ~/caddy/data:/data # Сертифікати Let's Encrypt
      - ~/caddy/config:/config # Інші дані Caddy
    networks:
      - opensearch-net
    depends_on:
      opensearch-dashboards:
        condition: service_healthy # Caddy залежить від працездатності Dashboards

networks:
  opensearch-net:
    driver: bridge

Важливе зауваження щодо безпеки: У цьому прикладі ми вимкнули плагін безпеки OpenSearch (DISABLE_SECURITY_PLUGIN=true) для спрощення розгортання. У продакшн-середовищі вкрай рекомендується увімкнути та налаштувати плагін безпеки, створити користувачів та ролі, а також використовувати HTTPS для доступу до OpenSearch API. Для цього знадобиться складніша конфігурація.

Пам'ять для OpenSearch: Обов'язково скоригуйте параметр OPENSEARCH_JAVA_OPTS=-Xms4g -Xmx4g відповідно до обсягу RAM вашого VPS. OpenSearch повинен використовувати близько 50% доступної пам'яті, але не більше 30-31 ГБ. Якщо у вас 8 ГБ RAM, встановіть -Xms4g -Xmx4g; якщо 16 ГБ, то -Xms8g -Xmx8g.

3. Створення конфігураційного файлу OpenSearch Dashboards

Створіть файл opensearch_dashboards.yml у каталозі ~/opensearch/dashboards/config/:

nano ~/opensearch/dashboards/config/opensearch_dashboards.yml

Додайте наступний вміст:

# opensearch_dashboards.yml
server.host: "0.0.0.0"
server.name: "opensearch-dashboards"
opensearch.hosts: ["http://opensearch:9200"]
opensearch.requestHeadersWhitelist: [ "authorization", "osd-xsrf" ] # Для роботи з безпекою OpenSearch
opensearch.ssl.verificationMode: "none" # Вимикаємо перевірку SSL між Dashboards та OpenSearch, оскільки використовується HTTP

4. Створення конфігураційного файлу Caddy

Створіть файл Caddyfile у каталозі ~/caddy/, замінивши your_domain.com на ваш реальний домен:

nano ~/caddy/Caddyfile

Додайте наступний вміст:

# Caddyfile
your_domain.com { # Замініть на ваш домен
  reverse_proxy opensearch-dashboards:5601 # Проксіювання запитів до Dashboards
  handle_errors {
    respond "{err.status_code} {err.status_text}"
  }
  log {
    output file /var/log/caddy/access.log {
      roll_size 10mb
      roll_keep 5
    }
  }
}

Переконайтеся, що ваш домен (наприклад, your_domain.com) вказує на IP-адресу вашого VPS у DNS-записах (A-запис).

5. Запуск OpenSearch, OpenSearch Dashboards та Caddy

Перейдіть до каталогу, де знаходиться docker-compose.yml, і запустіть сервіси:

cd ~ # Переходимо до домашнього каталогу
docker compose up -d # Запуск усіх сервісів у фоновому режимі

Процес запуску може зайняти кілька хвилин, особливо для OpenSearch під час першої ініціалізації. Перевірити статус контейнерів можна командою:

docker compose ps # Перевірка статусу контейнерів

Переконайтеся, що всі контейнери мають статус running і їх HEALTH знаходиться в стані healthy.

6. Встановлення Fluent Bit

Fluent Bit буде встановлено на тому ж сервері, що й OpenSearch/Dashboards, для збору системних логів та логів Caddy. Якщо у вас є інші сервери, на них також потрібно буде встановити Fluent Bit і налаштувати його на відправлення логів на ваш OpenSearch сервер.

Додамо репозиторій Fluent Bit (версія 2.2.x актуальна на 2026 рік, нові версії можуть бути доступні):

# Додавання GPG-ключа Fluent Bit
curl https://packages.fluentbit.io/fluentbit.key | gpg --dearmor | sudo tee /usr/share/keyrings/fluentbit-keyring.gpg > /dev/null

# Додавання репозиторію Fluent Bit для Ubuntu 24.04 (Noble Numbat)
echo "deb [signed-by=/usr/share/keyrings/fluentbit-keyring.gpg] https://packages.fluentbit.io/ubuntu/noble noble main" | sudo tee /etc/apt/sources.list.d/fluent-bit.list

# Оновлення списку пакетів та встановлення Fluent Bit
sudo apt update
sudo apt install fluent-bit -y # Встановлення Fluent Bit версії 2.2.x

Перевіримо статус сервісу:

sudo systemctl status fluent-bit # Перевірка статусу Fluent Bit

Сервіс повинен бути запущений та активний.

Конфігурація

Тепер, коли всі компоненти встановлено, налаштуємо Fluent Bit для збору логів та відправлення їх до OpenSearch.

1. Налаштування Fluent Bit

Основний конфігураційний файл Fluent Bit знаходиться за адресою /etc/fluent-bit/fluent-bit.conf. Однак, для зручності, краще використовувати окремі файли для вхідних даних (inputs), фільтрів (filters) та вихідних даних (outputs).

sudo nano /etc/fluent-bit/fluent-bit.conf

Переконайтеся, що в кінці файлу fluent-bit.conf є рядки для включення зовнішніх конфігурацій:

# fluent-bit.conf
...
@INCLUDE /etc/fluent-bit/parsers.conf
@INCLUDE /etc/fluent-bit/conf.d/.conf

sudo nano /etc/fluent-bit/conf.d/inputs.conf

# /etc/fluent-bit/conf.d/inputs.conf

[INPUT]
    Name              tail
    Tag               syslog
    Path              /var/log/syslog
    Parser            syslog
    DB                /var/log/flb_syslog.db
    Mem_Buf_Limit     5MB
    Skip_Long_Lines   On
    Refresh_Interval  5

[INPUT]
    Name              tail
    Tag               auth.log
    Path              /var/log/auth.log
    Parser            syslog
    DB                /var/log/flb_auth.db
    Mem_Buf_Limit     5MB
    Skip_Long_Lines   On
    Refresh_Interval  5

[INPUT]
    Name              tail
    Tag               caddy.access
    Path              /var/log/caddy/access.log # Шлях до логів Caddy
    Parser            json # Логи Caddy за замовчуванням у JSON
    DB                /var/log/flb_caddy.db
    Mem_Buf_Limit     5MB
    Skip_Long_Lines   On
    Refresh_Interval  5

sudo nano /etc/fluent-bit/conf.d/output.conf

# /etc/fluent-bit/conf.d/output.conf

[OUTPUT]
    Name            opensearch
    Match           
    Host            opensearch # Ім'я сервісу OpenSearch у Docker Compose
    Port            9200
    Index           fluent-bit-logs-%Y.%m.%d # Індекс з датою
    Type            _doc
    Logstash_Format On
    Logstash_Prefix fluent-bit-logs
    Retry_Limit     False
    Suppress_Type_Name On # Для OpenSearch 7+

1.3. Перезапуск Fluent Bit

Після зміни конфігурації Fluent Bit необхідно перезапустити сервіс:

sudo systemctl restart fluent-bit # Перезапуск Fluent Bit
sudo systemctl status fluent-bit # Перевірка статусу

Переконайтеся, що сервіс запущено без помилок. Ви можете переглянути логи Fluent Bit для налагодження:

sudo journalctl -u fluent-bit -f # Перегляд логів Fluent Bit у реальному часі

2. Перевірка працездатності

2.1. Доступ до OpenSearch Dashboards

Відкрийте в браузері ваш домен (наприклад, https://your_domain.com), який ви вказали в Caddyfile. Ви повинні побачити інтерфейс OpenSearch Dashboards.

2.2. Створення Index Pattern у Dashboards

Після першого входу до Dashboards вам потрібно буде створити "Index Pattern" для перегляду логів.

1. У лівому навігаційному меню перейдіть до Stack Management (іконка шестерні).
2. Виберіть Index Patterns у розділі Kibana.
3. Натисніть Create index pattern.
4. У полі Index pattern name введіть fluent-bit-logs- (або інший префікс, який ви вказали у fluent-bit/conf.d/output.conf). Натисніть Next step.
5. Для Time field виберіть @timestamp. Натисніть Create index pattern.

curl http://localhost:9200 # Перевірка доступності OpenSearch
curl http://localhost:9200/_cat/indices?v # Перегляд створених індексів

Резервне копіювання та обслуговування

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

Що резервувати

• Дані OpenSearch: Це найважливіше. Містять усі зібрані логи. Рекомендується використовувати вбудовані засоби OpenSearch для створення знімків.
• Конфігураційні файли:
  • docker-compose.yml
  • ~/opensearch/dashboards/config/opensearch_dashboards.yml
  • ~/caddy/Caddyfile
  • /etc/fluent-bit/fluent-bit.conf та /etc/fluent-bit/conf.d/.conf
• Сертифікати Caddy: Хоча Caddy автоматично їх оновлює, мати копію не завадить (~/caddy/data).

Простий скрипт авторезервування (OpenSearch + конфіги)

Для OpenSearch рекомендується використовувати API для створення знімків у віддалене сховище (наприклад, S3-сумісне сховище). Для конфігураційних файлів можна використовувати rsync або tar.

Приклад скрипта для резервного копіювання конфігураційних файлів:

#!/bin/bash

# Каталог для резервних копій
BACKUP_DIR="/var/backups/logging_system"
CONFIGS_DIR="$BACKUP_DIR/configs"
DATE=$(date +%Y%m%d%H%M%S)

# Створення каталогів, якщо їх немає
mkdir -p "$CONFIGS_DIR"

echo "--- Починаємо резервне копіювання конфігурацій ($DATE) ---"

# Резервне копіювання файлу Docker Compose
cp ~/docker-compose.yml "$CONFIGS_DIR/docker-compose-$DATE.yml"
echo "docker-compose.yml зарезервовано."

# Резервне копіювання конфігурації OpenSearch Dashboards
cp ~/opensearch/dashboards/config/opensearch_dashboards.yml "$CONFIGS_DIR/opensearch_dashboards-$DATE.yml"
echo "opensearch_dashboards.yml зарезервовано."

# Резервне копіювання конфігурації Caddy
cp ~/caddy/Caddyfile "$CONFIGS_DIR/Caddyfile-$DATE"
echo "Caddyfile зарезервовано."

# Резервне копіювання конфігурацій Fluent Bit
tar -czf "$CONFIGS_DIR/fluent-bit-configs-$DATE.tar.gz" /etc/fluent-bit
echo "Конфігурації Fluent Bit зарезервовано."

# Очищення старих резервних копій (залишаємо останні 7 днів)
find "$CONFIGS_DIR" -type f -name "-$DATE.yml" -o -name "-$DATE.tar.gz" -mtime +7 -delete
echo "Старі резервні копії конфігурацій видалено."

echo "--- Резервне копіювання конфігурацій завершено ---"

Збережіть цей скрипт як ~/backup_configs.sh, зробіть його виконуваним:

chmod +x ~/backup_configs.sh

І додайте до cron для щоденного виконання (наприклад, о 3:00 ночі):

crontab -e

Додайте рядок:

0 3    /home/youruser/backup_configs.sh > /dev/null 2>&1