task-tracker

Лабораторна робота №1: Розгортання Web-сервісу з автоматизацією

1. Варіант індивідуального завдання

Розрахунки для номера N = 16:

• V2 = (16 % 2) + 1 = 1 (Спосіб конфігурації: Аргументи командного рядка; База даних: MariaDB)
• V3 = (16 % 3) + 1 = 2 (Тематика: Task Tracker)
• V5 = (16 % 5) + 1 = 2 (Порт застосунку: 5200)

2. Призначення застосунку

Сервіс mywebapp є простим Task Tracker'ом, який дозволяє відстежувати задачі. Написаний на TypeScript з використанням Express.js та MariaDB. Підтримує Content Negotiation (віддає text/html або application/json залежно від заголовка Accept).

3. Документація по API

• GET / - Кореневий ендпоінт. Повертає список доступних API (тільки text/html).
• GET /tasks - Повертає список усіх задач (id, title, status, created_at).
• POST /tasks - Створює нову задачу. Очікує параметр title.
• POST /tasks/<id>/done - Змінює статус задачі на done.
• GET /health/alive - Перевірка життєздатності (завжди 200 OK). Заблоковано ззовні.
• GET /health/ready - Перевірка підключення до БД (200 OK або 500 Error). Заблоковано ззовні.

4. Документація по розгортанню

• Базовий образ ВМ: Офіційний образ Ubuntu 22.04 LTS (Server).
• Вимоги до ресурсів: 1 vCPU, 1 GB RAM, 10 GB Disk.
• Вхід на ВМ: За замовчуванням по SSH за допомогою ключа, користувач ubuntu. Після виконання автоматизації вхід можливий користувачами student, teacher, operator.
• Інструкція з розгортання:
  1. Підключитися до віртуальної машини.
  2. Склонувати цей репозиторій у /opt/mywebapp (або іншу директорію).
  3. Перейти в директорію mywebapp та виконати компіляцію:

     cd /opt/mywebapp/mywebapp
     npm install
     npm run build

  4. Повернутися в корінь репозиторію і запустити скрипт автоматизації від імені суперкористувача:

     cd /opt/mywebapp
     sudo bash deploy.sh

5. Тестування розгорнутої системи

Після успішного розгортання можна перевірити коректність роботи сервісу, виконуючи запити до IP-адреси віртуальної машини (на порт 80, оскільки Nginx проксіює запити):

• Перевірка отримання списку задач у форматі JSON: curl -H "Accept: application/json" http://<IP_ADDRESS>/tasks
• Перевірка створення нової задачі: curl -X POST -d "title=Complete Lab 1" http://<IP_ADDRESS>/tasks
• Перевірка обмеження доступу (має повернути 403 Forbidden): curl -I http://<IP_ADDRESS>/health/alive

6. Запуск за допомогою Docker Compose

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

Вимоги:

• Встановлений Docker
• Встановлений Docker Compose

Інструкція з запуску:

1. Клонуйте репозиторій та перейдіть у його корінь.
2. Виконайте команду для збірки та запуску всіх сервісів у фоновому режимі:

   docker-compose up -d --build
   

Лабораторна робота №3: Налаштування CI/CD пайплайну для Task Tracker

📌 Опис проєкту

[cite_start]Цей репозиторій містить веб-застосунок mywebapp (Task Tracker), розроблений у межах курсу[cite: 102]. [cite_start]Проєкт реалізує REST API для відстеження задач із збереженням даних у СУБД MariaDB[cite: 100, 101, 110].

[cite_start]Головна мета цієї лабораторної роботи — побудова повноцінного автоматизованого конвеєра безперервної інтеграції (CI) та безперервного розгортання (CD) за допомогою інструментів GitHub Actions та Self-hosted Runner[cite: 2, 7, 12, 32].

---

🏗️ Архітектура системи та деплою

[cite_start]Розгортання системи реалізовано з урахуванням вимог безпеки та Cloud-Native підходу[cite: 33]:

1. [cite_start]GitHub Cloud: Виконує статичний аналіз коду (лінтери), проганяє автоматичні тести та збирає production-образ застосунку, публікуючи його в GitHub Container Registry (GHCR)[cite: 14, 20, 26, 27].
2. [cite_start]Self-hosted Runner VM: Окрема ізольована віртуальна машина в локальній мережі, яка підключається до GitHub, підхоплює CD-задачі та виконує деплой/верифікацію[cite: 12, 31, 32].
3. [cite_start]Target Node VM: Цільовий сервер, на якому у Docker-контейнері розгортається нова версія застосунку, взаємодіючи з локальною MariaDB та Nginx[cite: 12, 45, 47].

---

🛠️ Специфікація CI/CD Пайплайну (pipeline.yml)

[cite_start]Конвеєр складається з трьох послідовних етапів (jobs)[cite: 38]:

[cite_start]1. Етап lint-and-test (Запуск на кожен Commit та Pull Request) [cite: 18, 22]

• [cite_start]Статичний аналіз коду: * Перевірка синтаксису та якості коду Node.js за допомогою ESLint[cite: 16].
  • [cite_start]Аналіз інструкцій збірки контейнера за допомогою Hadolint (Dockerfile Linter)[cite: 17].
• [cite_start]Автоматичне тестування: Проганяє юніт-тести та інтеграційні тести з генерацією звіту про покриття коду (Code Coverage)[cite: 20].
• [cite_start]Контроль якості: Пайплайн здійснює валідацію ліміту покриття коду (мінімум 40%)[cite: 21].
• [cite_start]Збереження артефактів: Актуальний звіт покриття тестами автоматично завантажується та зберігається у репозиторії у вигляді GitHub Artifact[cite: 24].

[cite_start]2. Етап build-and-push (Запуск при пуші в main/master або тегах) [cite: 26]

• Проводиться збірка оптимізованого багатоетапного (Multi-stage) Production-образу на базі легкого дистрибутиву node:22-alpine.
• [cite_start]Автоматично виконується автентифікація в GHCR через вбудований ${{ secrets.GITHUB_TOKEN }}[cite: 27].
• [cite_start]Стратегія тегування образів (згідно з ТЗ): [cite: 28]
  • [cite_start]При коміті в основну гілку: latest та sha-<full-commit-hash>[cite: 29].
  • [cite_start]При створенні анотованого тегу версії: stable та <tag_name>[cite: 29].

[cite_start]3. Етап deploy-and-verify (Запуск СУВОРО по анотованих тегах v*) [cite: 46]

• [cite_start]Виконується на локальному Self-hosted Runner[cite: 47].
• [cite_start]За допомогою безпечного підключення через SSH-ключі (збережені в GitHub Secrets) ранер віддалено керує контейнерами на Target Node[cite: 40, 63].
• Забезпечує зв'язок додатка з СУБД MariaDB через мапінг хостів --add-host=db:$TARGET_IP.
• [cite_start]Автоматична верифікація (Post-deployment testing): Викликає інфраструктурний скрипт ./scripts/verify.sh, який здійснює HTTP-запити до ендпоінтів /health/alive для підтвердження успішного старту та доступності веб-сервісу[cite: 51, 52, 115].

---

📂 Структура папок автоматизації

• .github/workflows/pipeline.yml — конфігураційний файл конвеєра GitHub Actions.
• [cite_start]scripts/setup_runner.sh — Bash-скрипт для первинної підготовки та встановлення залежностей на машині-ранері[cite: 36].
• [cite_start]scripts/deploy_target.sh — сценарій автоматизації оновлення Docker-контейнерів на цільовому сервері[cite: 15, 43].
• [cite_start]scripts/verify.sh — скрипт автоматизованої верифікації працездатності та post-deploy перевірок[cite: 51, 55].
• [cite_start]configs/mywebapp.service — конфігураційний файл Systemd-unit для декларативного керування життєвим циклом контейнера[cite: 49, 127].

---

🚀 Як запустити деплой нової версії (Реліз)

Розгортання нової версії на проде відбувається автоматично через механізм тегування в Git:

1. Створіть та додайте зміни у локальний репозиторій:

   git add .
   git commit -m "feat: імплементація нових можливостей API"

---

Лабораторна робота №4: IaC (Terraform) та Configuration Management (Ansible)

Інфраструктура проєкту розгортається на двох віртуальних машинах (worker та db), створених автоматично.

Запуск Terraform

1. Перейдіть до папки terraform: cd terraform
2. Ініціалізуйте провайдер: terraform init
3. Створіть ВМ: terraform apply (підтвердіть введенням yes).
4. Скопіюйте IP-адреси ВМ, які з'являться на екрані.

Запуск Ansible

1. Перейдіть до папки ansible: cd ansible
2. Відкрийте файл inventory.ini та впишіть актуальні IP-адреси, які ви отримали від Terraform.
3. Запустіть налаштування командою: ansible-playbook -i inventory.ini playbook.yml

Усі налаштування застосовуються декларативно (використовуються модулі apt, user, systemd, template). База даних не доступна ззовні, а застосунок динамічно отримує її IP-адресу з Ansible templates.