Управляем версиями: kubectl, terraform, python в одном инструменте. Знакомство с asdf

Проект А требует Terraform v1.7, а новый проект Б — уже v1.8. Ваша команда работает с разными версиями Python. Как управлять этим зоопарком, не засоряя систему и не создавая конфликтов?

asdf — это универсальный менеджер версий для десятков инструментов. Один CLI для управления всеми.

Как это работает — магия в 3 шага:

Устанавливаем плагин для нужного инструмента:

Bash

# Добавляем поддержку Terraform
asdf plugin-add terraform

Устанавливаем нужные версии:

Bash

asdf install terraform 1.7.5
asdf install terraform 1.8.4

Выбираем версию:
Глобально для всей системы:

Bash

asdf global terraform 1.8.4

Локально для текущей директории (главная фича!):

Bash

# Эта команда создаст в папке файл .tool-versions
asdf local terraform 1.7.5

Теперь, когда вы заходите в эту директорию, asdf автоматически активирует нужную версию Terraform.

Взгляд архитектора:
asdf — это инструмент для создания воспроизводимых и изолированных окружений. Файл .tool-versions можно и нужно коммитить в Git-репозиторий вашего проекта. Это гарантирует, что каждый член команды (и ваш CI/CD-пайплайн) будет использовать абсолютно те же версии инструментов, что исключает класс проблем "а у меня на машине работает". Это фундаментальный принцип DevOps.

#devops #cli #asdf #terraform #automation #гайд

AI-промпт: "Напиши за меня production-ready Terraform-модуль"

Админ просит AI: "напиши tf-файл для создания VM". Архитектор просит AI: "напиши переиспользуемый модуль".

Правильно написанный модуль main.tf, variables.tf, outputs.tf — это основа Infrastructure as Code (IaC). Давайте заставим AI следовать лучшим практикам.

Промпт (для ChatGPT/Gemini/Copilot):

Выступи в роли Senior DevOps Engineer, сертифицированного HashiCorp.

Создай структуру Terraform-модуля для развертывания "Azure Virtual Machine" (Linux). Модуль должен быть переиспользуемым, безопасным и следовать best practices.

Требования:
1.  Файлы: Раздели код на `main.tf`, `variables.tf` и `outputs.tf`.
2.  `main.tf`: Должен создавать группу ресурсов, VNet, Subnet, сетевой интерфейс (NIC) и саму VM (SKU `Standard_B2s`).
3.  `variables.tf`: Создай переменные для `location`, `vm_name`, `admin_username` и `admin_ssh_key` (публичный ключ).
4.  Безопасность: Не создавай публичный IP-адрес для VM. Доступ должен быть только по приватному IP.
5.  `outputs.tf`: Выведи наружу `private_ip_address` созданной VM.
6.  Комментарии: Добавь комментарии, объясняющие ключевые блоки.

Предоставь код для каждого из трех файлов.

Взгляд архитектора: AI здесь — не просто генератор кода. Это ускоритель для создания стандартных блоков (building blocks). Архитектор не тратит время на написание типовых модулей. Он использует AI, чтобы быстро получить 80% готового, качественного кода, а затем тратит 20% своего времени на его доработку, аудит и интеграцию в общую систему.

#ai4admin #terraform #iac #devops #azure #промпты #architect

Архитектура: Принцип Idempotency (Идемпотентность)

Если вы дважды (или сто раз) запустите одну и ту же операцию, результат всегда будет одинаковым.

Простой пример:

Неидемпотентно: команда_создать_пользователя_Вася (выдаст ошибку, если Вася уже есть).

Идемпотентно: команда_убедиться_что_пользователь_Вася_существует (создаст, если нет; ничего не сделает, если есть).

Взгляд архитектора: Это основа Infrastructure as Code (IaC). Ваш Ansible-плейбук или Terraform-конфиг должны быть идемпотентны. Вы не боитесь запустить их 10 раз — они просто убедятся, что система в нужном состоянии, без побочных эффектов.

#architect #devops #iac #ansible #terraform #принципы

🧠 Skill: "Terraform Drift Detection" — навык №1 в 2026 году ☁️

В эпоху IaC (Infrastructure as Code) самая большая проблема — это Drift (отклонение).
Это когда кто-то зашел в консоль AWS/Azure/Yandex руками и поменял тип инстанса или открыл порт, а в коде Terraform осталось старое значение.

Почему это опасно: При следующем запуске terraform apply твои ручные правки либо затрутся, либо всё упадет с ошибкой.

Что учить:

1. Terraform Plan Automation: Настрой запуск terraform plan в CI/CD раз в час.

2. Инструменты: Посмотри в сторону Driftctl или встроенного режима --refresh-only.

3. Команда для проверки "разрыва" между кодом и реальностью: terraform plan -refresh-only

Умение находить и устранять такие расхождения без даунтайма — это то, за что сегодня платят Senior DevOps инженерам. 🚀

#devops #terraform #iac #cloud #skills #automation #gitops

🧠 Skills: IaC drift — молчаливый убийца стабильности и как его ловить автоматически

Коллеги, у вас есть Ansible или Terraform. Вы гордитесь тем что инфраструктура описана как код. Но когда последний раз вы проверяли — соответствует ли то что работает в продакшне тому что написано в репозитории?

Configuration drift — это когда кто-то "быстро поправил руками" в пятницу вечером, написал "потом зафиксирую в коде" и конечно не зафиксировал. Через месяц инфраструктура живёт своей жизнью, а код — своей.

Два подхода в зависимости от инструмента:

# ---- ANSIBLE: детекция дрейфа через --check --diff ----
# Запускаем playbook в режиме проверки без изменений
ansible-playbook site.yml \
  -i inventories/production/hosts.yml \
  --check \
  --diff

# Вывод покажет ВСЕ расхождения между кодом и реальностью
# Строки с "-" = что есть сейчас, "+" = что должно быть по коду

# Автоматизируем: добавляем в cron или CI/CD pipeline
# crontab -e:
# 0 9 * * 1 ansible-playbook /opt/ansible/site.yml -i production --check --diff \
#   2>&1 | mail -s "Weekly drift report" admin@company.com

# ---- TERRAFORM: детекция дрейфа через plan ----
# Показывает расхождения между state и реальным состоянием ресурсов
terraform plan -detailed-exitcode
# Exit code: 0 = нет изменений, 1 = ошибка, 2 = есть изменения (drift!)

# В CI/CD (GitLab CI пример):
# drift_check:
#   schedule: "0 8 * * *"  # каждый день в 8:00
#   script:
#     - terraform init
#     - terraform plan -detailed-exitcode
#   allow_failure: false

# ---- ПРАВИЛО: что делать при обнаруженном дрейфе ----
# Вариант 1: исправить реальность под код (правильно)
#   ansible-playbook site.yml -i production  # применяем playbook
#   terraform apply                           # применяем план

# Вариант 2: зафиксировать реальность в код (если изменение было намеренным)
#   Обновить playbook/tf-файл, commit, PR, code review
#   terraform import resource_type.name resource_id  # импортируем в state

Зачем это нужно:
Drift detection для Ansible превращает идемпотентность в реальный механизм контроля: если ничего не меняется при запуске — системы соответствуют коду. Terraform использует state file для сравнения желаемого и реального состояния — это его главное преимущество перед Ansible в вопросе дрейфа.

Итог: IaC без регулярной проверки дрейфа — это как бэкап без тестирования восстановления. Выглядит серьёзно, но не работает в нужный момент. Настрой еженедельный отчёт сегодня — это 20 минут работы.

#skills #iac #ansible #terraform #drift #sysadmin #admin_future

🧠 Skills: Cattle vs Pets — принцип которому 15 лет, но половина инфраструктур его игнорирует

Коллеги, вторник — хороший момент для фундаментального разговора. Принцип «скот vs питомцы» (Cattle vs Pets) сформулировали ещё в 2011 году, но я до сих пор регулярно вижу инфраструктуры где каждый сервер — уникальный именованный питомец с историей ручных конфигураций.

Вместо питомцев у нас есть Cattle — стадо: серверы анонимны, взаимозаменяемы. Если узел № 154 ведёт себя нестабильно, его не лечат как любимого котика — его пристреливают как охромевшую лошадь. Удаляют и автоматически поднимают новый, идентичный, здоровый. Именно этот принцип породил Infrastructure as Code.

Как выглядят «питомцы» в реальной жизни:

ПРИЗНАКИ "ПИТОМЦА":
  - У сервера есть имя собственное: "Старый-Файловый",
    "Сервак-Богдана", "Этот-трогать-нельзя"
  - Никто не знает что на нём запущено кроме одного человека
  - Последний раз переустанавливали в 2019 году
  - Конфиги правились руками, в git не попадали
  - Апгрейд невозможен — "упадёт всё"

ПРИЗНАКИ "СКОТА":
  - Серверы называются по роли + номер: web-01, db-03
  - Любой сервер можно удалить и поднять заново за минуты
  - Конфигурация полностью в Ansible/Terraform
  - Нет уникальных ручных настроек которые нигде не записаны
  - Новый член команды может задеплоить среду с нуля

Практический переход от питомцев к скоту — четыре шага:

# ШАГ 1: Аудит — какие серверы у нас "питомцы"?
# Признак: uptime больше года без переустановки
uptime -s  # дата последнего старта
# Если дата 2023 и раньше на продакшн-сервере — питомец

# ШАГ 2: Документируем что реально запущено (chef-solo, ansible-pull)
# На подозрительном сервере:
ss -tlnp          # что слушает
systemctl list-units --type=service --state=running
crontab -l; ls /etc/cron.d/   # кроны
find /etc -newer /etc/os-release -type f 2>/dev/null | head -20
# Последнее — файлы изменённые после установки ОС

# ШАГ 3: Описываем текущее состояние как Ansible playbook
# ansible-pull или ручное написание по результатам аудита
# Проверяем идемпотентность:
ansible-playbook site.yml --check --diff

# ШАГ 4: Blue/Green замена
# Поднимаем новый сервер по playbook
# Переключаем трафик (DNS, LB)
# Старый питомец умирает с почестями
# Держим его неделю на всякий случай

Почему это важно именно сейчас:
Copy Fail и Dirty Frag показали — сервера которые нельзя быстро пересоздать это не просто технический долг. Это риск. Если патч ломает питомца — нет возможности быстро откатиться на чистую конфигурацию. Если питомец умирает — нет возможности его воссоздать.

Infrastructure as Code: инфраструктура описывается в коде, воспроизводится автоматически, тестируется и версионируется как любой другой программный продукт.

Итог: посмотри на свой список серверов прямо сейчас. Посчитай сколько из них питомцы. Это твой список технического долга на следующий квартал.

#skills #iac #infrastructure #ansible #terraform #sysadmin #admin_future