DevOps Fest 2020. Богдан Матейко. Infrastructure as a Code в реальному світі

Continuous Delivery. Continuous DevOps. KYIV, 2020
CONTINUOUS DELIVERY. CONTINUOUS DEVOPS.
20-21,MARCH 2020
KYIV, UKRAINE
Infrastructure as a code в реальному світі

• SRE
• Azure consultant
• 2+ роки IaaC
About me
BOHDAN MATEIKO
@id27182

Проблеми
• Зв’язок модулів компонентів /
Передача outputs між модулями
• Конфігурація backend
• Оркестрація модулів
• Georedundancy
• Патерни деплоймента інфраструктури
• Проблема організації команд /
розподіл обов’язків
• Формування артефактів

Зв’язок модулів компонентів

Remote state
data "terraform_remote_state" "backend" {
backend = "remote"
config = {
# ...
}
}
resource "aws_instance" "foo" {
# ...
subnet_id = data.terraform_remote_state.backend
.outputs.subnet_id
}

Remote state
ПЛЮСИ:
• Не потрібно додаткової
інфраструктури, тільки backend
• Стандартне оголошення output
• Мало додаткового коду при
зчитуванні, один datasource на
модуль
МІНУСИ:
• Потрібно писати в datasource повну
конфігурацію бекенда
• Проблеми при реорганізації модулів
• Важко мокати залежності

Remote state

Key-Value Bus
data "azurerm_key_vault_secret" "backoffice_apim_key" {
name = "${var.environment_name}-backend-output-
apim-backofficekey"
key_vault_id = var.infra_vault_rid
}
resource "azurerm_app_service" "galaxy_app_service" {
name = "${var.environment_name}backoffice"
location = var.location
# ...
app_settings = {
# ...
BACKEND_APIM_KEY = data.azurerm_key_vault_secret.backof
fice_apim_key.value
}
}

Key-Value Bus
ПЛЮСИ:
• Явна декларація залежностей
модуля (більш явна ніж з remote
state)
• Ідентифікатор output-a не залежить
від модуля
• Просто мокати залежності
• Вирішує додаткові проблеми
МІНУСИ:
• Додаткивий сервіс в інфраструктурі
• Окремий datasource на кожну
змінну, яка зчитується модулем

Key-Value Bus: конфіги/сертифікати

Напівавтоматизована інфарструктура

Підготовка / передача конфігурації backend
> terraform init --backend-config 'storage_account_name=backend_storage_account' --
backend-config 'container_name=backend_container_name' --backend-config
'resource_group_name=tf_backend_rg’
> terraform apply -var 'vault_rid=/subscriptions/342c4f42-4425-4042-422a-
422cb42f242d/resourceGroups/backend_resource_group_name/providers/Microsoft.Key
Vault/vaults/backend_key_vault'
> terraform destroy -var 'vault_rid=/subscriptions/342c4f42-4425-4042-422a-
422cb42f242d/resourceGroups/backend_resource_group_name/providers/Microsoft.Key
Vault/vaults/backend_key_vault'

Приклад врапера
ПАРАМЕТРИ МОДУЛІВ:
• Environment
• Location
• Cloud provider credentials
• Backend configuration
• Key-value bus configuration
PRE-REQUIREMENTS:
• Azure
• В кожному сабскрібшені ресурсна
група, в якій storage account і key
vault
• В якості backend – azure storage
account.
• Для кожного енва – свій блоб
контейнер.
• В якості key-value – azure key-vault

Приклад врапера
> Set-Environment -environment ‘dev’ -force
> terraform apply
> terraform destroy

Оркестрація модулів

Оркестрація модулів: terragrunt
 Запуск кількох модулів однією
командою
 Залежності модулів в коді
 Конфігурація бекенда в одному місці
 CLI флаги в одному місці

terragrunt: залежності модулів
dependencies {
paths = ["../core-infrastructure", "../k8s-config"]
}

terragrunt: backend конфіг
remote_state {
backend = "azurerm"
config = {
key = "${path_relative_to_include()}-
terraform.tfstate"
resource_group_name = "${get_env("TF_VAR_backend_storage_account
_rg", "")}"
storage_account_name = "${get_env("TF_VAR_backend_storage_accoun
t_name", "")}"
container_name = "${get_env("TF_VAR_backend_container_name", "")
}"
}
}

terragrunt: cli опції terraform
terraform {
extra_arguments "common_var" {
commands = [
"apply",
]
arguments = [
"-var-
file=${get_terragrunt_dir()}/../vars/${get_env("TF_VAR_environment_
name", "")}.tfvars"
]
}
}

Georedundancy

Georedundancy – custom module structure

Патерни деплоймента інфраструктури
• Blue-green deployment (terraform)
• Rolling updates (terraform)

Патерни деплоймента інфраструктури
ROLLING UPDATE
1. Деплоймент InstanceHub
2. Для кожного регіону:
1) Terraform destroy InstanceLBRule
2) Terraform apply для Instance
3) Тест інстанса
4) Terraform apply InstanceLBRule

Формування артефактів

Версіонування модулів: опції
Module sources
• GitHub
• Bitbucket
• Generic Git, Mercurial repositories
• Terraform Registry
• HTTP URLs
• S3 buckets
• GCS buckets
Packaging options
• Git tags
• Збірка модулів в пакети (mbt)

Git tags vs mbt
Плюси git tags:
• Просто версіонувати
• Не потрібно додаткового стореджа
для модулів
Мінуси git tags:
• Проблеми з організацією доступу
• Незручно організувати release
notes/package metadata
Плюси mbt:
• Легко поширювати/роздавати доступ
• Легко додавати в модуль metadata
• В пакет можна включати додаткові
модулі
Мінуси mbt:
• Потрібен сторедж/репозиторій

Проблема організації команд / розподіл обов’язків

Деспотія експлуатації VS анархія розробки
Devs IT

Корисні ресурси
• Terraform / Terragrunt врапер і приклад для georedundancy:
https://github.com/id27182/devopsfest2020samples
• https://terragrunt.gruntwork.io/
• CI & тестування: https://www.contino.io/insights/top-3-terraform-testing-strategies-
for-ultra-reliable-infrastructure-as-code
• Branching workflow comparison: https://medium.com/@patrickporto/4-branching-
workflows-for-git-30d0aaee7bf
• Monorepo vs Polyrepo: https://danielkummer.github.io/git-flow-cheatsheet/
https://github.com/joelparkerhenderson/monorepo_vs_polyrepo
• Про клауд і IaaC: https://www.youtube.com/watch?v=BEZKub1BYCE&feature=youtu.be

Q&A

Деспотія експлуатації VS анархія розробки

DevOps Fest 2020. Богдан Матейко. Infrastructure as a Code в реальному світі

Recomendados

Recomendados

Más contenido relacionado

Más de DevOps_Fest

Más de DevOps_Fest (20)

Último

Último (16)

DevOps Fest 2020. Богдан Матейко. Infrastructure as a Code в реальному світі

Notas del editor