Що з'явилося раніше – курка чи яйце? Досить дивний початок для статті про Infrastructure-as-Code, чи не так?
Що таке яйце?
Найчастіше Infrastructure-as-Code (IaC) – декларативний спосіб подання інфраструктури. У ньому ми описуємо стан, який хочемо отримати, починаючи від залізної частини, до конфігурації ПЗ. Тому IaC використовується для:
Resource Provision. Це VMs, S3, VPC і т.д. Основні інструменти для роботи: Terraform и CloudFormation.
Будь-який код лежить у git-репозиторіях. І рано чи пізно тимлід вирішить, що треба навести лад у них. І рефакторитиме він. І створить певну структуру. І побачить він, що це добре.
Також добре, що вже існує GitLab и GitHubпровайдер для Terraform (і це Software Configuration). З їхньою допомогою можна керувати всім проектом: членами команди, CI/CD, git-flow і т.д.
Звідки взялося яйце?
Ось ми й поступово підходимо до головного питання.
Насамперед треба починати з репозиторію, який описує структуру інших репозиторіїв, у тому числі себе. І звичайно, в рамках GitOps потрібно додати CI, щоб автоматично зміни виконувались.
Якщо Git ще не створено?
Як його зберігати у Git?
Як прикрутити CI?
Якщо Gitlab ми теж розвертаємо за допомогою IaC та ще й у Kubernetes?
І GitLab Runner теж у Kubernetes?
А Kubernetes у хмарному провайдері?
Що з'явилося раніше: GitLab, на який я завантажу свій код, або код, який описує те, який GitLab мені потрібний?
Крок 2. Готуємо наш Terraform для «запікання» кластера з 2 нід. Якщо ви впевнені в тому, що у вас вистачить на всі ресурси, то можна включити автоквоти:
Будемо використовувати стандартний для багатьох nginx-ingress. Інструкцій щодо його встановлення вже достатньо, так що не будемо на цьому затримуватись.
Крок 8. Наводимо Git-репозиторії до правильної ієрархії за допомогою Gitlab Provider.
cd ../internal/gitlab/hierarchy && terraform apply -input=false -auto-approve planfile
На жаль, у terraform GitLab provider є плаваючий баг. Тоді доведеться видалити конфліктуючі проекти руками, щоб tf.state полагодився. Потім перезапустіть команду `$make all`
Крок 9. Переносимо локальні репозиторії на сервер.
Ми досягли того, що з нашої локальної машини можемо декларативно керувати всім. Тепер хочеться перенести всі ці завдання до CI і лише натискати кнопочки. Для цього потрібно передати наші локальні стани (Terraform state) у CI. Про те, як це зробити, у наступній частині.
Підписуйтесь на наш блогщоб не пропустити виходи нових статей!