host.kramarets.net Open in urlscan Pro
178.136.127.163 Public Scan

Back to summary

URL:
https://host.kramarets.net/
Submission: On March 09 via api (March 9th 2024, 12:51:51 pm UTC) from US — Scanned from US

Form analysis
1 forms found in the DOM

GET https://devops.lviv.ua/

<form role="search" method="get" action="https://devops.lviv.ua/" class="wp-block-search__button-outside wp-block-search__text-button wp-block-search"><label for="wp-block-search__input-1" class="wp-block-search__label">Пошук</label>
  <div class="wp-block-search__inside-wrapper"><input type="search" id="wp-block-search__input-1" class="wp-block-search__input" name="s" value="" placeholder="" required=""><button type="submit" class="wp-block-search__button ">Пошук</button></div>
</form>

Text Content

Skip to content Skip to main menu
DevOps Lviv Ua
DevOps lake …

Menu
Mobile menu toggle
 * Головна




AGROCD GITOPS ДЛЯ KUBERNETS

Posted on 12.01.2022 by taras — No Comments ↓

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

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

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

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

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

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

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

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

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

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

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

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

Posted in CI/CD, GitOps, Kubernetes




GITLAB І TERRAFORM

Posted on 12.01.2022 by taras — No Comments ↓

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

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

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

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

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

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



Posted in CI/CD, Gitlab, IaaC, terraform




IAAC TERRAFORM АВТОМАТИЗАЦІЯ LEGACY/BAREMETAL ENVIRONMENT

Posted on 30.08.2021 by taras — No Comments ↓

З чого починається будь-який масштабний проект в інтернеті, з серверів та іншого
устаткування, а так як тепер важливо 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.) для прикладу ви можете вказати
більшу кількість пам’яті чи створити декілька віртуальних машин, чи взагалі
змінити ім’я цієї машини і таке інше, можливостей купа

Posted in terraform


Пошук
Пошук


НЕДАВНІ ЗАПИСИ

 * AgroCD GitOps для Kubernets
 * Gitlab і terraform
 * IaaC Terraform автоматизація legacy/baremetal environment


ОСТАННІ КОМЕНТАРІ

Немає коментарів до показу.
 * 

© 2024 DevOps Lviv Ua
Responsive II powered by WordPress
↑

host.kramarets.net Open in urlscan Pro 178.136.127.163 Public Scan

Form analysis 1 forms found in the DOM

GET https://devops.lviv.ua/

Text Content

host.kramarets.net Open in urlscan Pro
178.136.127.163 Public Scan

Form analysis
1 forms found in the DOM