AWS + Terraform + GitLab workshop #3
Нещодавно провів 3-й воркшоп із благодійного циклу AWS + Terraform + GitLab для DevOps01.
На першому воркшопі ми:
- розібрали application, навколо якого будується інфраструктура;
- розгорнули infra в AWS.
На другому - поринули в IaC та Terraform:
- імпортували інфраструктуру в Terraform-ресурси;
- зберегли працездатність без downtime.
Тому логічним наступним кроком став CI/CD - як для інфраструктурного репозиторію, так і для application repo, чим ми й займалися на воркшопі.
З чого починаємо?
Незалежно від інструментів, спочатку потрібно зробити головне:
- Виділити час на формулювання задач і скласти scope of work - список завдань із пріоритетами та термінами.
- Розписати acceptance criteria, щоб мати чітке розуміння, який результат очікується.
- Не скочуватися в overengineering - будувати best practices і писати «чистий код», не даючи при цьому реального імпакту бізнесу. Те, що довго робиться, може вже й не знадобитися…
- Бізнесу найчастіше потрібен fail fast і agile-підхід.
Наша мета - MVP, який вирішує ключові задачі. Все інше додаємо ітеративно, відповідно до пріоритетів.
Для CI/CD застосунку на старті потрібно
- Репозиторій, що зберігає код і генерує git-події (commit, MR/PR, tag, branch);
- Container image, який запускатиметься на нашому CI/CD-агенті (раннері) і міститиме всі необхідні інструменти.
Далі - визначити, що саме має відбуватися у відповідь на git-події:
- Збірка артефакту (наприклад, Docker image), запуск юніт-тестів або додаткових перевірок;
- Розгортання артефакту на середовище (розробка / тестування / продакшн);
- Сповіщення відповідних осіб або виклик зовнішніх ендпоінтів (наприклад, запуск іншого пайплайну без передачі артефактів).
Додаткові питання:
- На які git-події ми реагуємо? Що запускається під час коміту в певну гілку, а що - на MR?
- Які дії виконуються автоматично, а які - з ручним підтвердженням від інженера?
- Скільки оточень ми маємо? Один dev чи dev, test, prod?
- Чи потрібно кешувати залежності?
- Інтеграції: хмари, сторонні сервіси, container registry?
- Чи зберігаємо артефакти з джобів для дебагу або метрик?
- Чи потрібна додаткова автоматизація (trigger downstream/upstream pipelines, звіти тощо)?
Application CI/CD
GitLab pipeline run example
Коли все працює…
Пайплайн зібраний, артефакти створюються, деплой працює - час чекати на фідбек від команди або братися за задачі з беклогу:
- прискорення build/deploy-процесу;
- зменшення кількості фейлів;
- додаткові вимоги щодо security.
Майндмапа покращень
Для інфраструктурного репозиторію - аналогічно
Ми розуміємо задачі й обсяг, тому нам потрібно:
- створити репозиторій для коду, організувати командну роботу;
- побудувати container image з CLI (terraform, aws, etc.);
- налаштувати автентифікацію та авторизацію Terraform-запитів із GitLab-раннерів до AWS (OIDC + IAM Roles);
.terraformrcдля доступу до приватних модулів;- доступ до бекенду для зберігання state-файлів із підтримкою state locking.
Додаткові питання
- Скільки в нас AWS-акаунтів? Потрібно мати окремі значення змінних залежно від GitLab environment.
- Чи потрібен статичний аналіз коду або інші перевірки?
- Яку версію Terraform використовують раннери?
- Manual apply чи auto approve?
Terraform Infra pipeline
GitLab pipeline run
Куди можемо рухатися далі
Звісно, за один воркшоп усе не встигнеш, але головне - що обговорили та зробили, і грошей на ЗСУ зібрали.
Documentation
- Gitlab<->AWS OIDC
- pipelines-architecturing
- jobs
- predefined-vars
- vars
- gitlab-ci.yml syntax
- environments
#Hashicorp #Terraform #GitLab #AWSCommunity
Вперше опубліковано на LinkedIn 29 березня 2025 р.: оригінал.