AgroCD GitOps для Kubernets

Все більше людей хоче використовувати GitOps і ArgoCD для Kubernetes так як за

допомогою даної тули і її функціоналу apps of apps ми можемо один раз налаштувати

ArgoCD для усіх деплойментів, бенефіти очевидні так як ArgoCD може відслідковувати

стан наших деплойментів і якщо він не співпадає редеплоїти його з тим що є у git

тим самим надає можливість контролю за нашими деплойментами і не дозволяє

вносити зміни мимо git’a тим самим ми маємо автоматичний контроль за тими хто

має адміністративний доступ до kubernets, так як будь який kubectl edit автоматично

буде перестворений з того що є у гіті і відповідно ми можемо спати спокійно.

Для реалізації apps of apps достатньо задеплоїти argocd згідно з офіційним манулом

через хельм для прикладу і підготувати сам файл для apps of apps просто і швидко

далі все одно залишаться моменти з безпекою та додатковими налаштуваннями

так як для великих проектів важко без певних змін добитись найкращих результатів

Gitlab і terraform

Друзі дуже часто люди користуються terraform не думаючи про наслідки та ситуації що призводить до повністю розваленої інфраструктури … чому так відбувається тому що не розуміють як правильно будувати IaaC підхід… по факту при хорошому підході усіх цих проблем можна уникнути і запобігти їх появі.

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

Для запобіганню проблем найкраще скористатись CI/CD підходом для terraform і тим самим запобігти появі таких проблем по максимуму так як на рівні пайплайну дуже просто можна перевірити практично усе та й сам терраформ код у окремому репозиторії і білдиться і релізиться окремо впевнений що не вікриваю Америку, але досить багато людей цей підхід ігнорує і у результаті отримують розвалений прод чи будь яке інше оточення.

Реалізація підготована ось тут :

https://docs.gitlab.com/ee/user/infrastructure/iac/

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

IaaC Terraform автоматизація legacy/baremetal environment

З чого починається будь-який масштабний проект в інтернеті, з серверів та іншого устаткування, а так як тепер важливо 100% можливість відтворити всю інфраструктуру з коду то й використання terraform для побудови такої інфраструктури буде ідеальним рішенням, так як використання git як source of truth є логічним і правильним і коли у нас є велика кількість providers для того ж terraform ( libvirt, xen та інших ) також можливо розробити свого провайдера котрий для прикладу налаштує маршрутизатор чи коммутатор.

Розглянемо простоту конфігурації для libvirt( kvm ) віртуалізації :

  1. Створимо файл main.tf з наступним контентом :
terraform {
  required_providers {
    libvirt = {
      source = "dmacvicar/libvirt"
    }
  }
}

provider "libvirt" {
    uri = "qemu:///system"
}

resource "libvirt_domain" "terraform_test" {
  name = "terraform_test"
}

2. далі нам потрібно запустити terraform init

3. після запускаємо terraform plan

у данному прикладі ми створюємо віртуальну машину terraform_test

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # libvirt_domain.terraform_test will be created
  + resource "libvirt_domain" "terraform_test" {
      + arch        = (known after apply)
      + emulator    = (known after apply)
      + fw_cfg_name = "opt/com.coreos/config"
      + id          = (known after apply)
      + machine     = (known after apply)
      + memory      = 512
      + name        = "terraform_test"
      + qemu_agent  = false
      + running     = true
      + vcpu        = 1
    }

Plan: 1 to add, 0 to change, 0 to destroy.

4. далі створюємо віртуальну машину за допомогою terraform давши команду terraform apply:

terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # libvirt_domain.terraform_test will be created
  + resource "libvirt_domain" "terraform_test" {
      + arch        = (known after apply)
      + emulator    = (known after apply)
      + fw_cfg_name = "opt/com.coreos/config"
      + id          = (known after apply)
      + machine     = (known after apply)
      + memory      = 512
      + name        = "terraform_test"
      + qemu_agent  = false
      + running     = true
      + vcpu        = 1
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

libvirt_domain.terraform_test: Creating...
libvirt_domain.terraform_test: Creation complete after 1s [id=cd2f61a8-cf03-432b-b5f5-d4d623be374b]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

5. переконаємось що віртуальну машину було створено за допомогою команди virsh list :

virsh list
 Id    Name                           State
----------------------------------------------------
 2     terraform_test                 running

Як ми побачили створилась віртуальна машина, тепер заберемо цю віртуальну машину за допомогою terraform destroy :

terraform destroy

libvirt_domain.terraform_test: Refreshing state... [id=cd2f61a8-cf03-432b-b5f5-d4d623be374b]

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply":

  # libvirt_domain.terraform_test has been changed
  ~ resource "libvirt_domain" "terraform_test" {
      + cmdline     = []
        id          = "cd2f61a8-cf03-432b-b5f5-d4d623be374b"
        name        = "terraform_test"
        # (8 unchanged attributes hidden)
    }

Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  # libvirt_domain.terraform_test will be destroyed
  - resource "libvirt_domain" "terraform_test" {
      - arch        = "x86_64" -> null
      - cmdline     = [] -> null
      - emulator    = "/usr/libexec/qemu-kvm" -> null
      - fw_cfg_name = "opt/com.coreos/config" -> null
      - id          = "cd2f61a8-cf03-432b-b5f5-d4d623be374b" -> null
      - machine     = "pc" -> null
      - memory      = 512 -> null
      - name        = "terraform_test" -> null
      - qemu_agent  = false -> null
      - running     = true -> null
      - vcpu        = 1 -> null
    }

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

Все це доволі просто, а запитання як змінити параметри ? – ви їх бачите в конфігурації ( name,memory,vcpu,cmdline etc.) для прикладу ви можете вказати більшу кількість пам’яті чи створити декілька віртуальних машин, чи взагалі змінити ім’я цієї машини і таке інше, можливостей купа