Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Infrastructure as Code: базові принципи vs інструменти, що еволюціонують

Якщо ви тільки починаєте працювати з інструментами для Infrastructure as Code або думаєте, як інтегрувати його у ваш CI/CD-пайплайн — це стаття для вас. Ми з’ясуємо, як побудувати процес автоматизації інфраструктури та втілити Infrastructure as Code.

Стаття дає базовий огляд Infrastructure as Code як концепції і фокусується на методології і принципах її впровадження в щоденній розробці та деплойменті.

Дисклеймер: ця стаття НЕ є серйозною документацією щодо конкретних інструментів і технологій.

Що таке інфраструктура

Інфраструктура — це ресурси, які потрібні для підтримки коду. Водночас дехто може уявити серверні стійки, світчі та зміїне кубло кабелів... Але це вчорашній день. Сьогодні 99% проєктів живе в «хмарах». Тобто ресурси — це віртуальні машини, контейнери, load balancers.

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

Infrastructure as Code — це спосіб постачання та керування обчислювальними та мережевими ресурсами методом їх опису у вигляді програмного коду, на відміну від налаштовування необхідного обладнання власноруч чи з допомогою інтерактивних інструментів.

Чому варто звернути увагу на Infrastructure as Code

Infrastructure as Code є (вже не таким) новим трендом, який розв’язує актуальну проблему автоматизації інфраструктури.

Багатьом із нас доводилося бути в схожій ситуації:

— Слухай, мені треба задеплоїти лоад-балансер...
— Вибач, у нас завал! Будь ласка, створи тікет у JIRA і повертайся за два дні...

Якби інфраструктура була автоматизована, цього діалогу б не відбулося (як і затримки в роботі), бо лоад-балансер автоматично деплоївся б. Тому автоматизація інфраструктури така популярна. Вона розв’язує не тільки технічні питання, а й організаційні та комунікаційні. Автоматизація полегшує наше життя і перетворює безлад на передбачуваний процес.

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

Проблема масштабу

За моїми спостереженнями, один мікросервіс в середньому потребує 10-12 інфраструктурних ресурсів (a load balancer, RDS instance, security groups тощо). Якщо в нас є три середовища — test, staging, production — то це вже близько 30 ресурсів. А якщо мікросервісів 10-20-100, проблема стає ще більш масштабною.

Проблема передбачуваності

Якщо створювати всі ці ресурси вручну, то питання «Що робити, якщо ми припустимося помилки і наші середовища будуть відрізнятися; до яких багів це може призвести?» перетворюється на «Що робити, коли...» Бо вірогідність припуститися помилки в кількох сотнях ручних операцій наближається до 100%.

З урахуванням цих проблем автоматизація інфраструктури стає не просто модним трендом, а необхідністю.

Шляхи розв’язання

У нас є перевірені методології роботи з кодом, які ми можемо використати. Ми вже знаємо, як побудувати процес: як код зберігати, тестувати і деплоїти.

Одна з найвідоміших методологій роботи з кодом — The 12 Factor App. Її популяризував один із хмарних провайдерів — Heroku. Серед цілей цієї методології такі:

  • забезпечити максимальну портабельність між середовищами, зменшуючи ризик відмінностей та багів. Таким чином ми робимо можливим Continuous Deployment;
  • зробити автоматизацію максимально простою. Щоб розробники не витрачали багато часу на початок роботи над проєктом.

І якщо ми пригадаємо наші проблеми, то це те, що лікар прописав!

З-поміж 12 принципів The 12 Factor App найголовнішими є:

  • Codebase
  • Configuration
  • Logging
  • Development/Production Parity

Codebase

Коли ми працюємо з кодом мікросервісів, то не зберігаємо його локально, а користуємося системами контролю версій (Git, Mercurial тощо). І код для інфраструктури не має бути винятком. Так ми не втратимо історію змін і знатимемо причину для кожної з них.

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

Configuration

Але для автоматизованого деплойменту конфігурацію треба зберігати окремо від коду і надавати доступ до неї під час деплойменту. The 12 Factor App рекомендує робити це через змінні середовища. Це універсальний підхід, який працює на будь-який операційній системі. Понад те, це безпечний підхід, на відміну від аргументів командного рядка, адже змінні середовища не можна отримати з іншого процесу простим ‘ps aux’.

Logging

Під час деплойменту інфрастурктури нам треба контролювати стан деплойменту і стан системи загалом. І зробити це можна за допомогою логів. Щоб вони працювали будь-де, The 12 Factor App пропонує розглядати логи як потік евентів без кінця та початку, які відсортовані хронологічно і виведені в stdout.

Логування — це окрема проблема, яку можна розв’язувати за допомогою Fluentd, Elasticsearch або скеруванням в інший файл чи процес. Найголовніше, що логи у stdout можуть інтегруватися з будь-якою системою або працювати локально, коли ви займаєтесь дебагінгом.

Development/Production Parity

І найголовніший принцип — це Development/Production Parity (еквівалентність середовищ). Якщо ми зберігаємо код у системі контролю версій і використовуємо його як універсальне джерело істини, а в самому коді немає спеціальних кейсів для окремих середовищ, усі унікальні налаштування зберігаються окремо і доступні під час деплойменту як змінні середовища — ми отримаємо систему, де немає розбіжностей між середовищами (test vs staging vs production).

The 12-Factor App FTW

Так, у нас може виникнути ситуація на кшталт «для тесту мені потрібні два інстанси, а для продакшену — 50». Але тут буде різниця в налаштуваннях, а не в коді. І це відкриває нам шлях до Continuous Deployment. Якщо ми можемо автоматично задеплоїти та протестувати наші зміни, то можемо автоматично це робити в будь-якому середовищі.

Якщо наші логи доступні у stdout, а наша конфігурація доступна як змінні середовища, то в нас немає жодних проблем з інтеграцією із сучасними CI/CD-рішеннями. Travis CI, Gitlab CI, Github Actions, Jenkins та інші інструменти можуть читати код із системи контролю версій, давати доступ до конфігурації через змінні середовища та працювати з логами в stdout.

«Hello, World!», або З чого почати

Якщо ми почнемо гуглити «infrastructure tools», то можемо здивуватися з вибору, який є на ринку. Нам треба обрати інструмент, з яким не просто вдасться написати аналог «Hello, World!», а з яким буде зручно підтримувати реальну систему.

Першим вибором (якщо ви користуєтеся AWS) може стати AWS CLI. З його допомогою можна створювати, змінювати та видаляти хмарні ресурси:

aws elb create-load-balancer
  --load-balancer-name myELB
  --listeners
      "Protocol=HTTP,
       LoadBalancerPort=80,
       InstanceProtocol=HTTP,
       InstancePort=80"
  --subnets subnet-15aaab61

Ось приклад команди, яка створює load balancer за допомогою AWS CLI. На перший погляд досить прозоро, ця команда буде працювати, як заплановано, і створить load balancer... Але чи існують інші ресурси (subnets, security groups), на які ця команда посилається. Якщо ні, їх треба створити (а це ще кілька команд). Якщо ресурси існують, але в них інші ідентифікатори — треба знайти ці правильні ідентифікатори і підставити їх у команду.

А що, як load balancer вже існує? Значить, треба додати команду, яка перевірить його існування. А що, як у нього інші параметри, не такі, як потрібно? Отже, доведеться перевірити його стан — і загорнути нашу команду в if-else-statement: «Якщо ресурсу немає — створи, якщо є — зміни його параметри».

Це занадто багато команд! І проблема навіть не в розмірі скрипта, а в його нестабільності: для кожної банальної операції нам треба обробити безліч винятків. І якщо ми пропустимо один, є шанс зруйнувати всю інфраструктуру.

Декларативні vs імперативні інструменти

Проблема нестабільності скрипта спричинена тим, що AWS CLI — імперативний інструмент. Імперативні інструменти працюють за схемою «я хочу змінити світ, для цього зроблю X». Але якщо світ не є в тому стані, який ми очікуємо, то в найкращому разі інструмент нам поверне помилку і нічого не зробить, у найгіршому — зробить не те, що ми очікуємо.

Для інфраструктури більше підходять декларативні інструменти. Вони працюють за схемою «я хочу змінити світ і залишити цей світ у стані Y». Замість того, щоб окремо описувати кожен крок, який нам треба зробити, щоб досягнути мети, декларативні інструменти описують саму мету, кінцевий стан. А які саме кроки — декларативні інструменти вирішують самостійно, користувач не повинен описувати кожну дію і кожну умову.

Серед декларативних інструментів для AWS є AWS CloudFormation і Terraform. Для нашого прикладу оберемо Terraform. У ньому load balancer матиме такий вигляд:

resource "aws_elb" "myELB" {
  name = "myELB"

  listener {
    instance_port     = 8000
    instance_protocol = "http"
    lb_port           = 80
    lb_protocol       = "http"
  }

  subnets = [...]
  security_groups = [...]
}

...

Тут ми бачимо ще одну проблему — посилання одних ресурсів на інші. Щоб наш псевдокод став реальним, треба додати дефініції для security groups (subnets тощо). Наприклад, посилання на security group може мати такий вигляд:

resource "aws_elb" "myELB" {
  name = "myELB"
  ...
  security_groups = ["${aws_security_group.elb.id}"]
}

resource "aws_security_group" "elb" {
  name = "web_alb"
  description = "Allow incoming HTTP connections to ALB."

  ingress {
    from_port = 80
    to_port = 80
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port = 0
    to_port   = 0
    protocol  = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Ми визначаємо правила для цієї security group — приймати трафік на порт 80 — і деталі деплоймента цієї групи стають неважливими. Terraform сам задеплоїть ресурс, отримає його ID і підставить у параметри load balancer.

Ми можемо додати декларації Terraform до системи контролю версій і використовувати їх як джерело істини для різних середовищ. І тут ми бачимо наступну проблему.

Стан світу

Як Terraform дізнається, що треба деплоїти, а що ні? Для цього йому потрібно десь зберігати поточний стан усіх описуваних ресурсів. За замовчуванням цей стан зберігається у файлі terraform.tfstate. Може постати питання: а чому б не зберегти цей файл і в системі контролю версій? Є дві причини, чому цього не варто робити:

  • По-перше, цей файл де-факто містить у собі конфігурацію. А ми намагаємося розділити код і конфігурацію. Тому зберігати їх разом не варто.
  • По-друге, цей файл може містити конфіденційну інформацію. Наприклад, пароль бази даних, яку ви створили в AWS.

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

output "web_alb_sg_id" {
  value = aws_security_group.web_alb.id
}

terraform {
 backend "s3" {
   key    = "iacdemo.tfstate"
   region = "us-west-2"
   bucket = "demobucket"
 }
}

Terraform підтримує багато механізмів remote state, але якщо ви працюєте з AWS, то рекомендую дивитися на AWS S3, оскільки цей механізм:

  • підтримує шифрування, чим розв’язує проблему зберігання конфіденційних даних;
  • підтримує версіонування — у разі несправностей ви завжди зможете знайти останній коректний варіант стану вашого світу;
  • більшість команд може використовувати його безкоштовно протягом року (AWS free tier).

Але навіть розв’язавши цю проблему, ми одразу бачимо наступну. Так, ми створили load balancer та інші ресурси, але...

Не всі ресурси однакові

Так, load balancer важливий для нашого мікросервіса. Але security group, на яку він посилається, важлива для всіх мікросервісів. Зламати security group — це набагато гірше, ніж зламати один load balancer.

Саме тут пролягає межа конфлікту між розробниками та DevOps. Розробникам треба якомога швидше описати та задеплоїти ресурси для своїх сервісів. DevOps потрібно, щоб уся система була стабільною. Однак розробники не хочуть чекати, поки кожна зміна в інфраструктуру буде ретельно перевірена вручну перед релізом. Вони прагнуть якнайшвидше задеплоїти свої зміни в production.

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

Як розділити інфраструктуру

Але розробникам все одно треба посилатися на ключові ресурси. Як це зробити?

Розгляньмо на прикладі Terraform. Ми зберігаємо стан світу окремо від коду. Це дає можливість імпортувати його і під час декларації ресурсів посилатися на ті його параметри, які були експортовані:

data "terraform_remote_state" "core" {
 backend = "s3"
 config = {
   key    = "iacdemo.tfstate"
   region = "us-west-2"
   bucket = "demobucket"
 }
}


resource "aws_elb" "myELB" {
  name = "myELB"
  ...
  security_groups = "${terraform_remote_state.core.web_alb_sg_id}"
}

Тепер ключова інфраструктура може бути задеплоєна окремо від інфраструктури мікросервісів.

І ми переходимо до найважливішого питання...

Як організувати процес деплойменту інфраструктури

Як і під час роботи зі звичайним кодом, ми можемо розбити процес деплойменту на частини:

  1. Валідація
  2. Тестування
  3. Деплоймент
  4. Димове тестування
  5. (і потім усе повторюється в наступному оточенні, починаючи з п.1)

Тестування та димове тестування заслуговують на окрему статтю, тому наразі зупинимося на валідації та деплойменті.

Валідація інфраструктури — особливо ключової — дуже важлива. Нам треба переконатися, що зміни в інфраструктурі, які будуть деплоїтися — насправді ті, що нам потрібні і що в них немає непередбачуваних побічних ефектів.

У Terraform це можна зробити за допомогою команд:

terraform init 
terraform plan -input=false

Перша команда ініціалізує Terraform і створює remote state або синхронізується з ним.

Друга команда повертає нам перелік ресурсів, які будуть створюватися або змінюватися. Щоб ми могли перевірити, чи насправді заплановані зміни — ті, які ми очікуємо. (Параметр «-input=false» потрібен для того, щоб усі змінні бралися зі змінних оточень, не чекаючи на введення з консолі. Це дуже корисно, коли команди виконуються в headless оточенні, наприклад у Jenkins, де консолі немає).

Обережно з видаленням

Під час перегляду переліку змін треба звернути особливу увагу на видалення ресурсів: без знання специфіки їхньої роботи можна помилитися. Наприклад, зробити на перший погляд тривіальну зміну — в імені load balancer — яка може призвести до того, что наявний load balancer буде видалено, а новий створено за хвилину опісля.

Якщо ваша інфраструктура не потребує 99.9% аптайму, це можна пережити, якщо ні — можливо, вам треба застосувати налаштування create_before_destroy. Але для цього потрібно розуміти, як це відобразиться на ресурсах, які залежать від того, в якому виникла проблема.

А тепер деплоїмо

Якщо всі зміни є такими, як нам треба, можна сміливо переходити до деплойменту. Подивимось, який вигляд матиме фінальний скрипт, потрібний для повної автоматизації:

# initializing configuration!
export TF_VAR_<your variable>=... 

# setting up or syncing with a remote state
terraform init


# reviewing a list of changes
terraform plan -input=false	
    
# deploying our infrastructure changes
terraform apply -input=false -auto-approve

Як бачимо, це банальний shell-скрипт, який можна інтегрувати і з Jenkins, і з Gitlab CI, і з іншим CI-CD рішенням, зокрема з нашим CI-CD pipeline. Це розв’язує проблему з неавтоматизованим деплоєм лоад-балансера, описану на початку статті. Тепер ми можемо описати нашу інфраструктуру як код, зберігати зміни в системі контролю версій, робити їм code review та автоматично деплоїти за хвилини, а не за дні чи тижні. Але усе це стосується лише Terraform...

Чи є життя за межами Terraform

Так! Розглянемо приклад з Kubernetes, який дає змогу описувати інфраструктуру для контейнерів та мережних ресурсів декларативно. Можемо загорнути цю декларацію в шаблон, використовуючи банальний shell-скрипт (або більш просунуті інструменти — від YTT до Helm. Але це я залишу як домашнє завдання охочим :)

#!/bin/bash
cat <<YAML
apiVersion: apps/v1beta1
kind: Deployment
...
spec:
 replicas: 1
 template:
   spec:
     containers:
       - name: $SERVICE_NAME
         image: $DOCKER_IMAGE
         imagePullPolicy: Always
         ports:
           - containerPort: 8090
...
YAML

Цей скрипт так само можна конфігурувати за допомогою змінних середовища. Якщо ми подивимося на процес деплойменту kubernetes-ресурсів, то побачимо, що принципової різниці немає:

# initializing configuration!
export DOCKER_IMAGE=hello:latest
export SERVICE_NAME=helloworld

# reviewing a list of changes
k8s_template.yaml.sh | kubectl apply --dry-run -f -

# deploying our infrastructure changes
k8s_template.yaml.sh | kubectl apply -f -

Також саме ми описуємо наші ресурси як код, зберігаємо їх у системі контролю версій. Перевіряємо зміни перед тим, як деплоїти, і можемо інтегрувати цей процес з CI-CD pipeline.

А що в майбутньому

І навіть якщо в майбутньому з’явиться принципово новий декларативний інструмент для керування (наприклад!) нейромережами, то всі ці методи можна буде застосувати й для нього! Сподіваюсь, тепер вам буде легше починати експерименти з інфраструктурою. Якщо хочете дізнатися більше, рекомендую послухати ці доповіді про Infrastructure-as-code: evolving tools vs core principles: російською чи англійською, Automated Testing for Terraform, Docker, Packer, Kubernetes, and More.

Також раджу прочитати книги

GitHub-репозиторій для Core infrastructure та GitHub-репозиторій окремо для сервіса.

Дякую за увагу та бажаю всім легких деплойментів і 100% аптайму!

LinkedIn

Похожие статьи

24 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Спасибо за статью и особенно за развернутые комментарии!

Понад те, це безпечний підхід, на відміну від аргументів командного рядка, адже змінні середовища не можна отримати з іншого процесу простим ‘ps aux’.

А как на счет простого `ps aux e`?

Кто что думает на счет www.pulumi.com ? Кто-то работал? Как он по сравнению с Terraform?

Спасибо за фидбек!

Насколько я помню — оно ж все равно не покажет содержимое процессов, не принадлежащих текущему аккаунту?

Да, но докер, чаще всего, настроен чтобы запускаться без sudo и имея доступ к докеру можно получить переменные окружения процессов.

В последнее время часто вижу и слышу о том — что Ias, DevOps (как культрура, а не человек) — все это как часть процесса разработки и делается разработчиками. Но мне не понятно — если разработчик имеет доступ к управлению инфраструктурой, он будет ею управлять как разработчик, что приведет к хаоусу и когда начнется хаос — компания возьмет на работу девопса (сисадмина), которому прийдется разгребать подохо «программист в инфраструктуре». В итоге, подход:

Якби інфраструктура була автоматизована, цього діалогу б не відбулося (як і затримки в роботі), бо лоад-балансер автоматично деплоївся б. Тому автоматизація інфраструктури така популярна.

Как по мне изначально не правильный. Кто будет нести ответтвенность за сбои, поломки и случайное уничтожение ресурсов ? К примеру при «обновлении» EC2 чрезе terraform — нужно указывать политику удаления, как это будет происходить. Из опыта знаю что даже довольно сильные программисты — вскользь просмотрев документацию по terraform, пропускают такие довольно важные моменты. Разбираться с модульным подходом в terraform — то же нужно время и вникнуть в это. Линейное описание инфраструктуры, как в статье — имхо то же изначально неправильный подход, это сходу можно так сделать, но это тупо не правильно. В целом как вводная статья — норм, но стоило бы зацепить хотя бы частично важные моменты работы с terraform, за одно добавить все же подход к уровню ответственности при варианте как вы написал про автоматизацию, так как в любом случае, такие вещи как изменение инфраструктуры — не должны быть решением одного человека. ALB тесно связан с ASG в том же амазоне, его так же нужно учитывать и создавать, задавать его размеры и параметры, что приводит к еще более глубокому погружению в IaS, которое имхо приводт к тому, что программист все же должен педалить код — а не инфраструктуру и оставить этот вопрос даже на начальном этапе тому — кто за это будет нести ответственость. Но в целом повторюсь — за статью спасибо.

Все так, Вы поднимаете правильные моменты — в частности, про модули, без которых когнитивная нагрузка на разработчика становится неприлично велика. Однако, Вы верно заметили, что статью вводная и все моменты в ней охватить невозможно.

Однако момент с ответственностью — он таки интересный, тут я позволю предложить альтернативную точку зрения.

Я неоднократно видел процессы — и не только в Google и Netflix — где на разработчике лежит ответственность за поддержание работоспособности своего сервиса, а SRE/ops/administrators — выполняют роль экспертов-консультантов, подавая разработчикам кирпичики (best practices, tools, processes). Но на линии огня, если что-то пойдет не так — именно разработчики, хотя, конечно, они всегда могут обратиться к экспертам за помощью.

Это, конечно, требует несколько иного подхода к найму — нанимать приходится в первую очередь взрослых и ответственных людей, с прокачанными soft skills. Но, хочу сказать как разработчик, ответственный за выкатку инфраструктуры для критических сервисов: когда ты понимаешь, что если что-то пойдет не так, и на линии огня окажешься ты лично, то ты несколько иначе подходишь что к разработке, что к code review, что к деплойменту, что к мониторингу (и это касается и твоего кода, и инфраструктуры).

Необходимости в SRE/devops — это, кстати, не отменяет — их работа по прежнему критически важна, только при этом они выходят на новый уровень — вместо решения кучи задач по отдельности проблем, они начинают решать проблемы процесса в целом, проблемы обучения людей, проблемы эргономики devops-инструментов. То есть вместо рядового бойца в строю — они становятся и командирами, ведущими за собой, и снабженцами, отвечающими за наличие у остальной команды нужного инструмента, и учителями, которые делятся своими знаниями и практиками.

Агонь, спасибо за фидбек. То — что вы описали, реально принципиально отличается от того — что личо я видел и вижу в реалиях нашего IT, в продуктовых компаниях и аутсорсе, когда инфраструктурные инжинеры решают проблемы, которые создают разработчики по незнанию или не желанию учится — меняться, это ведет к внутрикомандным и проектным конфликтам.

Необходимости в SRE/devops — это, кстати, не отменяет — их работа по прежнему критически важна, только при этом они выходят на новый уровень — вместо решения кучи задач по отдельности проблем, они начинают решать проблемы процесса в целом, проблемы обучения людей, проблемы эргономики devops-инструментов. То есть вместо рядового бойца в строю — они становятся и командирами, ведущими за собой, и снабженцами, отвечающими за наличие у остальной команды нужного инструмента, и учителями, которые делятся своими знаниями и практиками.

А это похоже одно их лучших обьяснений что такое DevOps в контексте управления проектом, а не человека. Спасибо.

дехто може уявити серверні стійки, світчі та зміїне кубло кабелів... Але це вчорашній день. Сьогодні 99% проєктів живе в «хмарах».

то власна інфраструктура тих «хмар» — теж вчорашній день? :-)
що Netflix цілком в AWS зрозуміло, але в усьому іншому світі тільки в цьому 2020 році очікують ріст частки Public cloud до 41% (source: Forbes)
а решта 59% це Hybrid cloud, Private cloud, On-premises, тобто з тим самим власним зміїним кублом :-)

P.S. «evolving tools vs core principles: російською» — url недійсний

то власна інфраструктура тих «хмар» — теж вчорашній день? :-)

В тих хмар є свої інструменти автоматизації, які нам, простим смертним, не дуже доступні, якщо ми працюємо не в Гуглі, Фейсбуці або Амазоні.

Але автоматизація приватних хмар — це дуже цікава проблема. Тут (я буду чесним) в мене нема якогось простого рецепту.

нам, простим смертним, не дуже доступні, якщо ми працюємо не в Гуглі, Фейсбуці або Амазоні.

из этих троих, Facebook как раз не только софт опенсорсят, они же в основателях Open Compute Project
и, при желании, любой может строить собственный датацентр на таких же Open Compute Rack, которые использует Facebook — www.youtube.com/watch?v=2l6gI-ksdKs

все так, I stand corrected

Якби інфраструктура була автоматизована, цього діалогу б не відбулося (як і затримки в роботі), бо лоад-балансер автоматично деплоївся б.

Я правильно понимаю что при описаном подходе каждый разработчик имеет доступ к терраформу и изменению инфраструктуры?

Как настроете права, так и будет.

Для своих сервисов — да.

Где гарантия что разработчик не создаст S3 Bucket с публичным доступом (по незнанию конечно) где будут лежать например пользовательские данные. Подобных примеров можно найти много (например неправильно сконфигураированный RDS), как от этого защититься?

Пост аудит применяемых конфигураций. То есть кто-то что-то сделал, мы сразу берем в анализ это изменение, если оно пот. открывает доступ и так далее — notice в сторону SRE с ручным разбором

Есть сервисы которые интегрируются в аккаунт aws и делают периодический аудит открытых портов разных служб для таких случаев.

Тут есть несколько подходов:

1) заранее подготовленные стандартные модули-кирпичики с лучшими практиками, которые разработчик может использовать просто из коробки.

(Собственно, они заслуживают отдельной статьи, потому что они нужны как минимум для того, чтобы уменьшить когнитивную нагрузку на разработчика — без них многих разработчиков просто перегрузит сложность работы с инфраструктурой)

2) код-ревью — если мы описываем инфраструктуру как код, то нам не помешает и стандартная практика код-ревью, где эксперт сможет поймать явный косяк.

3) автоматизированное тестирование инфраструктуры — тут уже говорили про сканирование и аудит конфигураций, но в целом это опять же, интересная тема, заслуживающая отдельного разговора.

Спасибо за статью
Опыта в «Infrastructure as Code» нет, но тема очень интересна.

Подивимось, який вигляд матиме фінальний скрипт, потрібний для повної автоматизації:

А как при автоматизированном деплое проверять вывод «terraform plan -input=false» ?
Единственное, что приходит в голову: например, в CircleCI, можно добавить «job» c с типом «approval» — человек должен руками подтвердить, что можно продолжать.
Но тогда это не совсем полная автоматизация.
Или это так и работает, и ручное вмешательство все таки нужно?

Отличный вопрос. Я не стал углубляться в детали полной автоматизации — но без полного автоматического тестирования инфраструктуры избавиться от вмешательства человека не получится.

Поэтому короткий ответ — так, самый простой вариант это как минимум получить подтверждение от человека (как минимум, когда речь идет о production deployment).

Длинный ответ — полностью автоматизированный пайплайн требует:

1) полностью автоматизированного тестирования
2) полностью автоматизированного роллбека — один из вариантов тут может быть green/blue deployment, при котором два environment (новый и старый) какое-то время существуют одновременно, траффик перенаправляется от старого к новому, мониторятся метрики, и при сбое — траффик перенаправляется обратно.

Однако это нетривиальная задача — тут нужно управлять траффиком, иметь копии двух environments одновременно (что может быть недешево), управлять stateful services отдельно — потому что иначе придется дуплицировать не только инфраструктуру как таковую, но и данные, а это опять же совсем нетривиально. В большинстве случаев такой подход просто не окупает инвестиций.

дякую за статтю!
до речі, в запропонованої Вами книги є оновлена версія
www.amazon.com/...​-Code-ebook/dp/B07XKF258P

Вона доречі чи то вишла чи т готуєтсья вийти російською у видавництві Пітєр ( це якщо ви не вмієте мовою оригіналу).

diamail.com.ua/book/9343.html

Вже є. Але іншої книги
www.amazon.com/...​rvers-Cloud/dp/1491924357
Не має в перекладі. Я як раз Її Гуглив і натрапив на цю статтю

Подписаться на комментарии