Successfully reported this slideshow.

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

0

Share

Loading in …3
×
1 of 33
1 of 33

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

0

Share

Description

Всі знають що таке Infrastructure as a Code, але як почати використовувати цей підхід в своїй компанії? Як організувати код? Як налагодити взаємодію між компонентами, розробка яких ведеться окремо ? Як "подружити" розгортання інфраструктури та додавання інстансів в CD пайплайн ? Хто має розробляти інфраструктуру та хто має мати можливість контрібютити в неї? На ці, та інші питання я хочу спробувати дати відповідь в своїй доповіді.

Transcript

  1. 1. Continuous Delivery. Continuous DevOps. KYIV, 2020 CONTINUOUS DELIVERY. CONTINUOUS DEVOPS. 20-21,MARCH 2020 KYIV, UKRAINE Infrastructure as a code в реальному світі
  2. 2. Continuous Delivery. Continuous DevOps. KYIV, 2020 • SRE • Azure consultant • 2+ роки IaaC About me BOHDAN MATEIKO @id27182
  3. 3. Continuous Delivery. Continuous DevOps. KYIV, 2020 Проблеми • Зв’язок модулів компонентів / Передача outputs між модулями • Конфігурація backend • Оркестрація модулів • Georedundancy • Патерни деплоймента інфраструктури • Проблема організації команд / розподіл обов’язків • Формування артефактів
  4. 4. Continuous Delivery. Continuous DevOps. KYIV, 2020 Зв’язок модулів компонентів
  5. 5. Continuous Delivery. Continuous DevOps. KYIV, 2020 Remote state data "terraform_remote_state" "backend" { backend = "remote" config = { # ... } } resource "aws_instance" "foo" { # ... subnet_id = data.terraform_remote_state.backend .outputs.subnet_id }
  6. 6. Continuous Delivery. Continuous DevOps. KYIV, 2020 Remote state ПЛЮСИ: • Не потрібно додаткової інфраструктури, тільки backend • Стандартне оголошення output • Мало додаткового коду при зчитуванні, один datasource на модуль МІНУСИ: • Потрібно писати в datasource повну конфігурацію бекенда • Проблеми при реорганізації модулів • Важко мокати залежності
  7. 7. Continuous Delivery. Continuous DevOps. KYIV, 2020 Remote state
  8. 8. Continuous Delivery. Continuous DevOps. KYIV, 2020 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 } }
  9. 9. Continuous Delivery. Continuous DevOps. KYIV, 2020 Key-Value Bus ПЛЮСИ: • Явна декларація залежностей модуля (більш явна ніж з remote state) • Ідентифікатор output-a не залежить від модуля • Просто мокати залежності • Вирішує додаткові проблеми МІНУСИ: • Додаткивий сервіс в інфраструктурі • Окремий datasource на кожну змінну, яка зчитується модулем
  10. 10. Continuous Delivery. Continuous DevOps. KYIV, 2020 Key-Value Bus: конфіги/сертифікати
  11. 11. Continuous Delivery. Continuous DevOps. KYIV, 2020 Напівавтоматизована інфарструктура
  12. 12. Continuous Delivery. Continuous DevOps. KYIV, 2020 Підготовка / передача конфігурації 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'
  13. 13. Continuous Delivery. Continuous DevOps. KYIV, 2020
  14. 14. Continuous Delivery. Continuous DevOps. KYIV, 2020 Приклад врапера ПАРАМЕТРИ МОДУЛІВ: • 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
  15. 15. Continuous Delivery. Continuous DevOps. KYIV, 2020 Приклад врапера > Set-Environment -environment ‘dev’ -force > terraform apply > terraform destroy
  16. 16. Continuous Delivery. Continuous DevOps. KYIV, 2020 Оркестрація модулів
  17. 17. Continuous Delivery. Continuous DevOps. KYIV, 2020 Оркестрація модулів: terragrunt  Запуск кількох модулів однією командою  Залежності модулів в коді  Конфігурація бекенда в одному місці  CLI флаги в одному місці
  18. 18. Continuous Delivery. Continuous DevOps. KYIV, 2020 terragrunt: залежності модулів dependencies { paths = ["../core-infrastructure", "../k8s-config"] }
  19. 19. Continuous Delivery. Continuous DevOps. KYIV, 2020 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", "") }" } }
  20. 20. Continuous Delivery. Continuous DevOps. KYIV, 2020 terragrunt: cli опції terraform terraform { extra_arguments "common_var" { commands = [ "apply", ] arguments = [ "-var- file=${get_terragrunt_dir()}/../vars/${get_env("TF_VAR_environment_ name", "")}.tfvars" ] } }
  21. 21. Continuous Delivery. Continuous DevOps. KYIV, 2020 Georedundancy
  22. 22. Continuous Delivery. Continuous DevOps. KYIV, 2020 Georedundancy – custom module structure
  23. 23. Continuous Delivery. Continuous DevOps. KYIV, 2020 Патерни деплоймента інфраструктури • Blue-green deployment (terraform) • Rolling updates (terraform)
  24. 24. Continuous Delivery. Continuous DevOps. KYIV, 2020 Патерни деплоймента інфраструктури ROLLING UPDATE 1. Деплоймент InstanceHub 2. Для кожного регіону: 1) Terraform destroy InstanceLBRule 2) Terraform apply для Instance 3) Тест інстанса 4) Terraform apply InstanceLBRule
  25. 25. Continuous Delivery. Continuous DevOps. KYIV, 2020 Формування артефактів
  26. 26. Continuous Delivery. Continuous DevOps. KYIV, 2020 Версіонування модулів: опції Module sources • GitHub • Bitbucket • Generic Git, Mercurial repositories • Terraform Registry • HTTP URLs • S3 buckets • GCS buckets Packaging options • Git tags • Збірка модулів в пакети (mbt)
  27. 27. Continuous Delivery. Continuous DevOps. KYIV, 2020 Git tags vs mbt Плюси git tags: • Просто версіонувати • Не потрібно додаткового стореджа для модулів Мінуси git tags: • Проблеми з організацією доступу • Незручно організувати release notes/package metadata Плюси mbt: • Легко поширювати/роздавати доступ • Легко додавати в модуль metadata • В пакет можна включати додаткові модулі Мінуси mbt: • Потрібен сторедж/репозиторій
  28. 28. Continuous Delivery. Continuous DevOps. KYIV, 2020 Проблема організації команд / розподіл обов’язків
  29. 29. Continuous Delivery. Continuous DevOps. KYIV, 2020 Деспотія експлуатації VS анархія розробки Devs IT
  30. 30. Continuous Delivery. Continuous DevOps. KYIV, 2020 Корисні ресурси • 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
  31. 31. Continuous Delivery. Continuous DevOps. KYIV, 2020 Q&A
  32. 32. Continuous Delivery. Continuous DevOps. KYIV, 2020
  33. 33. Continuous Delivery. Continuous DevOps. KYIV, 2020 Деспотія експлуатації VS анархія розробки

Editor's Notes

  • IaaC з terraform це круто і зручно, але в той же час і складно. В процесі роботи виникає багато проблем, рішення яких не очевидні і не описані в документації. Сьогодні я хочу поговорити про такі проблеми та як їх уникнути (на прикладі azure).
  • Мене звуть БМ, і я працюю з проектами, які стосуються різних варіацій IaaC більше двох років. Давайте починати.
  • Уявимо абстрактну компанію, яка використовує azure, та інфраструктура якої виглядає ось так
    Пройтись по компонентам і зв*язкам
  • Компоненти можуть розроблятись і, відповідно, розгортають окремо, є сенс описувати кожен окремим модулем.
    Але що робити у випадку, коли треба зчитати якесь значення, яке генерується в модуді бекенд, наприклад з модуля бекофіс.
    Це значення може бути апі енндоінтом, ключем, сертифікатом і т д
    Є два рішення
  • Тераформу необхідно зберігати дані про вашу інфраструктуру та конфігурацію. Стейт використовується тераформом для того щоб зберігати інформацію про зв*язок реальних ресурсів і ваших модулів, метадату та для інших цілей. Це означає, що всі динамічно згенеровані значення зберігаються в стейті, і цим можна скористатись.
    Як виглядає в коді (Т)
    Для цього потрібно описати датасорс
  • і окрім всього, може статись (Т)
  • Альтернатива цьому підходу – Key-Value шина
    Підхід полягає в тому, щоб використовувати якийсь KV (приклад) для запису аутпутів і їх зчитування
    Ось як виглядає (Т)
  • Без kv – великі vars файли в сорс контролі або костилі
    З – централізований сторедж
  • уявіть що проект тільки стартує ....
    (Т)
  • Давайте розглянемо приклад
    Всі модулі приймають уніфікований список параметрів (решта в kv)
  • Бувають ситуації, коли потрібно розбивати на окремі модулі
    Наприклад ...
    Потрібно уніфіковано запускати
    (Т)
  • Цю проблему можна вирішити за допомогою терагрант
    Террагрант – це врапер, який дозволяє адекватно ...
  • Адекватний спосіб описувати georedundant серидовища
  • Зручно розділити ресурси по модулям
  • Ще одна проблема, яку може вирішити такий підхід до організації модулів – деплоймент стратегія для продакшн
    Звісно, можна
    Але
  • З вище описаною організацією модулів, можна зробити rolling update з можливістю протестувати перед тим, як повернути в балансувальник навантаження
  • Якщо інфраструктура описється кодом – деплоймент повинен бути такий же, як для коду
  • Одне з питань, яке може виникнути – хто повинен бути оунером коду , та кому можна контрібютити

    Хашикорп рекомендує

  • Але хто ж
    Невизначеність може привести до двох крайностей
    Вихід є: Оунер той – хто найчастіше міняє
  • Хашикорп рекомендує
    Різні види інфраструктури (легісі, cloud-native з функціями і т д, AKS)
    Немає чіткого алгоритму
    Оунер той – хто найчастіше міняє
  • Description

    Всі знають що таке Infrastructure as a Code, але як почати використовувати цей підхід в своїй компанії? Як організувати код? Як налагодити взаємодію між компонентами, розробка яких ведеться окремо ? Як "подружити" розгортання інфраструктури та додавання інстансів в CD пайплайн ? Хто має розробляти інфраструктуру та хто має мати можливість контрібютити в неї? На ці, та інші питання я хочу спробувати дати відповідь в своїй доповіді.

    Transcript

    1. 1. Continuous Delivery. Continuous DevOps. KYIV, 2020 CONTINUOUS DELIVERY. CONTINUOUS DEVOPS. 20-21,MARCH 2020 KYIV, UKRAINE Infrastructure as a code в реальному світі
    2. 2. Continuous Delivery. Continuous DevOps. KYIV, 2020 • SRE • Azure consultant • 2+ роки IaaC About me BOHDAN MATEIKO @id27182
    3. 3. Continuous Delivery. Continuous DevOps. KYIV, 2020 Проблеми • Зв’язок модулів компонентів / Передача outputs між модулями • Конфігурація backend • Оркестрація модулів • Georedundancy • Патерни деплоймента інфраструктури • Проблема організації команд / розподіл обов’язків • Формування артефактів
    4. 4. Continuous Delivery. Continuous DevOps. KYIV, 2020 Зв’язок модулів компонентів
    5. 5. Continuous Delivery. Continuous DevOps. KYIV, 2020 Remote state data "terraform_remote_state" "backend" { backend = "remote" config = { # ... } } resource "aws_instance" "foo" { # ... subnet_id = data.terraform_remote_state.backend .outputs.subnet_id }
    6. 6. Continuous Delivery. Continuous DevOps. KYIV, 2020 Remote state ПЛЮСИ: • Не потрібно додаткової інфраструктури, тільки backend • Стандартне оголошення output • Мало додаткового коду при зчитуванні, один datasource на модуль МІНУСИ: • Потрібно писати в datasource повну конфігурацію бекенда • Проблеми при реорганізації модулів • Важко мокати залежності
    7. 7. Continuous Delivery. Continuous DevOps. KYIV, 2020 Remote state
    8. 8. Continuous Delivery. Continuous DevOps. KYIV, 2020 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 } }
    9. 9. Continuous Delivery. Continuous DevOps. KYIV, 2020 Key-Value Bus ПЛЮСИ: • Явна декларація залежностей модуля (більш явна ніж з remote state) • Ідентифікатор output-a не залежить від модуля • Просто мокати залежності • Вирішує додаткові проблеми МІНУСИ: • Додаткивий сервіс в інфраструктурі • Окремий datasource на кожну змінну, яка зчитується модулем
    10. 10. Continuous Delivery. Continuous DevOps. KYIV, 2020 Key-Value Bus: конфіги/сертифікати
    11. 11. Continuous Delivery. Continuous DevOps. KYIV, 2020 Напівавтоматизована інфарструктура
    12. 12. Continuous Delivery. Continuous DevOps. KYIV, 2020 Підготовка / передача конфігурації 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'
    13. 13. Continuous Delivery. Continuous DevOps. KYIV, 2020
    14. 14. Continuous Delivery. Continuous DevOps. KYIV, 2020 Приклад врапера ПАРАМЕТРИ МОДУЛІВ: • 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
    15. 15. Continuous Delivery. Continuous DevOps. KYIV, 2020 Приклад врапера > Set-Environment -environment ‘dev’ -force > terraform apply > terraform destroy
    16. 16. Continuous Delivery. Continuous DevOps. KYIV, 2020 Оркестрація модулів
    17. 17. Continuous Delivery. Continuous DevOps. KYIV, 2020 Оркестрація модулів: terragrunt  Запуск кількох модулів однією командою  Залежності модулів в коді  Конфігурація бекенда в одному місці  CLI флаги в одному місці
    18. 18. Continuous Delivery. Continuous DevOps. KYIV, 2020 terragrunt: залежності модулів dependencies { paths = ["../core-infrastructure", "../k8s-config"] }
    19. 19. Continuous Delivery. Continuous DevOps. KYIV, 2020 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", "") }" } }
    20. 20. Continuous Delivery. Continuous DevOps. KYIV, 2020 terragrunt: cli опції terraform terraform { extra_arguments "common_var" { commands = [ "apply", ] arguments = [ "-var- file=${get_terragrunt_dir()}/../vars/${get_env("TF_VAR_environment_ name", "")}.tfvars" ] } }
    21. 21. Continuous Delivery. Continuous DevOps. KYIV, 2020 Georedundancy
    22. 22. Continuous Delivery. Continuous DevOps. KYIV, 2020 Georedundancy – custom module structure
    23. 23. Continuous Delivery. Continuous DevOps. KYIV, 2020 Патерни деплоймента інфраструктури • Blue-green deployment (terraform) • Rolling updates (terraform)
    24. 24. Continuous Delivery. Continuous DevOps. KYIV, 2020 Патерни деплоймента інфраструктури ROLLING UPDATE 1. Деплоймент InstanceHub 2. Для кожного регіону: 1) Terraform destroy InstanceLBRule 2) Terraform apply для Instance 3) Тест інстанса 4) Terraform apply InstanceLBRule
    25. 25. Continuous Delivery. Continuous DevOps. KYIV, 2020 Формування артефактів
    26. 26. Continuous Delivery. Continuous DevOps. KYIV, 2020 Версіонування модулів: опції Module sources • GitHub • Bitbucket • Generic Git, Mercurial repositories • Terraform Registry • HTTP URLs • S3 buckets • GCS buckets Packaging options • Git tags • Збірка модулів в пакети (mbt)
    27. 27. Continuous Delivery. Continuous DevOps. KYIV, 2020 Git tags vs mbt Плюси git tags: • Просто версіонувати • Не потрібно додаткового стореджа для модулів Мінуси git tags: • Проблеми з організацією доступу • Незручно організувати release notes/package metadata Плюси mbt: • Легко поширювати/роздавати доступ • Легко додавати в модуль metadata • В пакет можна включати додаткові модулі Мінуси mbt: • Потрібен сторедж/репозиторій
    28. 28. Continuous Delivery. Continuous DevOps. KYIV, 2020 Проблема організації команд / розподіл обов’язків
    29. 29. Continuous Delivery. Continuous DevOps. KYIV, 2020 Деспотія експлуатації VS анархія розробки Devs IT
    30. 30. Continuous Delivery. Continuous DevOps. KYIV, 2020 Корисні ресурси • 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
    31. 31. Continuous Delivery. Continuous DevOps. KYIV, 2020 Q&A
    32. 32. Continuous Delivery. Continuous DevOps. KYIV, 2020
    33. 33. Continuous Delivery. Continuous DevOps. KYIV, 2020 Деспотія експлуатації VS анархія розробки

    Editor's Notes

  • IaaC з terraform це круто і зручно, але в той же час і складно. В процесі роботи виникає багато проблем, рішення яких не очевидні і не описані в документації. Сьогодні я хочу поговорити про такі проблеми та як їх уникнути (на прикладі azure).
  • Мене звуть БМ, і я працюю з проектами, які стосуються різних варіацій IaaC більше двох років. Давайте починати.
  • Уявимо абстрактну компанію, яка використовує azure, та інфраструктура якої виглядає ось так
    Пройтись по компонентам і зв*язкам
  • Компоненти можуть розроблятись і, відповідно, розгортають окремо, є сенс описувати кожен окремим модулем.
    Але що робити у випадку, коли треба зчитати якесь значення, яке генерується в модуді бекенд, наприклад з модуля бекофіс.
    Це значення може бути апі енндоінтом, ключем, сертифікатом і т д
    Є два рішення
  • Тераформу необхідно зберігати дані про вашу інфраструктуру та конфігурацію. Стейт використовується тераформом для того щоб зберігати інформацію про зв*язок реальних ресурсів і ваших модулів, метадату та для інших цілей. Це означає, що всі динамічно згенеровані значення зберігаються в стейті, і цим можна скористатись.
    Як виглядає в коді (Т)
    Для цього потрібно описати датасорс
  • і окрім всього, може статись (Т)
  • Альтернатива цьому підходу – Key-Value шина
    Підхід полягає в тому, щоб використовувати якийсь KV (приклад) для запису аутпутів і їх зчитування
    Ось як виглядає (Т)
  • Без kv – великі vars файли в сорс контролі або костилі
    З – централізований сторедж
  • уявіть що проект тільки стартує ....
    (Т)
  • Давайте розглянемо приклад
    Всі модулі приймають уніфікований список параметрів (решта в kv)
  • Бувають ситуації, коли потрібно розбивати на окремі модулі
    Наприклад ...
    Потрібно уніфіковано запускати
    (Т)
  • Цю проблему можна вирішити за допомогою терагрант
    Террагрант – це врапер, який дозволяє адекватно ...
  • Адекватний спосіб описувати georedundant серидовища
  • Зручно розділити ресурси по модулям
  • Ще одна проблема, яку може вирішити такий підхід до організації модулів – деплоймент стратегія для продакшн
    Звісно, можна
    Але
  • З вище описаною організацією модулів, можна зробити rolling update з можливістю протестувати перед тим, як повернути в балансувальник навантаження
  • Якщо інфраструктура описється кодом – деплоймент повинен бути такий же, як для коду
  • Одне з питань, яке може виникнути – хто повинен бути оунером коду , та кому можна контрібютити

    Хашикорп рекомендує

  • Але хто ж
    Невизначеність може привести до двох крайностей
    Вихід є: Оунер той – хто найчастіше міняє
  • Хашикорп рекомендує
    Різні види інфраструктури (легісі, cloud-native з функціями і т д, AKS)
    Немає чіткого алгоритму
    Оунер той – хто найчастіше міняє
  • More Related Content

    More from DevOps_Fest

    Related Audiobooks

    Free with a 30 day trial from Scribd

    See all

    ×