⚙️ Velero
— инструмент для бэкапа, миграции и аварийного восстановления Kubernetes-кластеров и их данных.

Позволяет безопасно сохранять и восстанавливать ресурсы кластера (поды, deployment, конфигурации), включая прикреплённые тома через снапшоты.

📍 Основной функционал:
— Резервное копирование ресурсов кластера и их восстановление в том же или другом кластере
— Снапшоты постоянных томов (PV)
— Миграция ресурсов между кластерами и облачными платформами
— Планирование бэкапов по расписанию
— Выборочное восстановление ресурсов с фильтрацией по namespace, меткам

📍 Ключевые особенности:
— Поддержка Restic для бэкапа любых томов (включая NFS, hostPath)
— Интеграция с облачными хранилищами (S3, GCS, Azure Blob)
— Расширяемая архитектура через плагины
— Ролевая модель доступа для безопасного использования

Velero превращает сложную задачу резервного копирования Kubernetes в предсказуемый и управляемый процесс.

👉 Git
#полезное

📸 LVM Snapshot: быстрые снимки без простоя

Снимок LVM — это точное состояние логического тома (LV) на момент создания. Он занимает место только для изменённых блоков и создаётся без остановки сервиса.

✅ Как это работает (Copy-on-Write, CoW)

— При создании снимка исходный том и снимок ссылаются на одни и те же данные

— При изменении данных в исходном томе, старые блоки копируются в область снимка перед записью

— Таким образом, снимок хранит только те данные, которые были изменены после его создания

*Речь про «классические» снимки LVM. У thin-томов механика и команды отличаются.

🧑‍💻 Практика

Создать снимок (2 ГиБ под изменения)

lvcreate -s -n my_lv_snapshot -L 2G /dev/my_vg/my_lv

Паспорт snapshot через lvdisplay

lvdisplay /dev/my_vg/my_lv_snapshot

  --- Logical volume ---
  LV Path                /dev/my_vg/my_lv_snapshot
  LV Name                my_lv_snapshot
  VG Name                my_vg
  LV UUID                y9FV7q-8UxB-7MmE-S8No-5A3F-2QJi-8x9LAD
  LV Write Access        read/write
  LV snapshot status     active destination for my_lv
  LV Status              available
  # open                 0
  LV Size                3.00 GiB
  Current LE             768
  COW-table size         2.00 GiB
  COW-table LE           512
  ...

Смонтировать для проверки (читать безопаснее в ro)

mkdir -p /mnt/snapshot
mount -o ro /dev/my_vg/my_lv_snapshot /mnt/snapshot
# Для XFS добавьте: -o ro,nouuid

Откат к снимку (merge)

# Если origin смонтирован, снимите его:
umount /mnt/data

# Запустить merge:
lvconvert --merge /dev/my_vg/my_lv_snapshot

# Если origin был активен/смонтирован, merge произойдёт при следующей активации LV
# (часто это выглядит как "после перезапуска сервиса/узла").

После успешного merge сам snapshot-LV исчезает — это нормально.

Удалить снимок (если не нужен)

lvremove /dev/my_vg/my_lv_snapshot

Важные нюансы

✅ Размер снимка должен покрывать ожидаемый объём изменений. Если CoW-область переполнится, снимок станет неконсистентным и будет потерян.

✅ Снимки читаются и монтируются как обычные тома; писать в snapshot можно, но обычно это не требуется.

✅ Производительность: CoW даёт накладные расходы на запись в origin.

✅ Merge требует, чтобы origin был не смонтирован/не активен; иначе откат откладывается до следующей активации.

✅ Thin LVM: у thin-томов своя логика снапшотов и квот; команды и возможности merge отличаются от classic snapshots.

👍 Отличный способ создать точку возврата перед обновлениями/миграциями: быстрый откат без полного бэкапа и долгого восстановления. (Бэкапы всё равно нужны — снапшоты не заменяют резервное копирование.)

#линуксятина

📚 Книги про бэкапы

Помогут разобраться в бэкапах от базовой механики и утилит — к стратегиям для гибридной инфраструктуры, облаков, SaaS и Kubernetes.

🤓 Backup & Recovery

Практический справочник по планированию и внедрению резервного копирования в смешанных средах с акцентом на Unix/Linux и open-source.

🔎 Рассматривается:

— инвентаризация, расписания, ротации, offsite и регулярные тесты восстановления;
— базовые утилиты: tar/cpio/dump/restore/dd/rsync;
— Amanda, BackupPC, Bacula: архитектура, конфигурации, сценарии восстанавления;
— near-CDP на базе rsync/snapshots (rsnapshot, rdiff-backup);
— носители: ленты/VTL, bare-metal восстановление, бэкап баз данных.

Автор: W. Curtis Preston · Издательство: O’Reilly, 2007

🤓 Modern Data Protection

Руководство по современной стратегии бэкапа и DR: процессы, метрики и инструменты для инфраструктуры.

🔎 Рассматривается:

— RPO/RTO, runbook’и, регулярные проверки восстановления;
— 3-2-1, неизменяемые копии, air-gap, шифрование;
— full/incremental, дедупликация, snapshots, репликация, (near)-CDP;
— защита VMware/Hyper-V, физических серверов, NAS, рабочих станций и мобильных;
— базы данных on-prem и PaaS; SaaS (M365, Google Workspace, Salesforce);
— контейнеры/Kubernetes; модели DR (cold/warm/hot), DRaaS.

Автор: W. Curtis Preston · Издательство: O’Reilly, 2021

✔️ Полезно ИТ-руководителям и архитекторам, которые обновляют стратегию защиты данных под облака и контейнеры; инженерам бэкапа/ИБ, SRE и DevOps, кому важно понимать устройство решений «на земле» и уверенно проводить восстановления; системным администраторам, строящим надёжный бэкап из доступных инструментов в смешанных средах.

#книги #полезное

🛒 Кейс: бэкапы как основа DR для дистрибьютора

Клиент: крупный дистрибьютор продуктов питания с круглосуточной работой и «тяжёлой» ERP.

🔵 Проблема:
при серьёзном сбое компания не была уверена, что сможет быстро восстановить работу из резервных копий — риск простоя, потери данных и денег.

🔵 Почему такие риски:

— не было удалённой DR-площадки, откуда гарантированно подниматься;

— метрики RPO/RTO с бизнесом не были формально согласованы;

— регламенты и тестовые восстановления требовали доработки;

— репликация «журналами» периодически давала расхождения в данных.

🤝 Совместно с заказчиком выстроили DR-процесс «под ключ»:
согласовали RPO/RTO, определили стратегию бэкапов, развернули удалённую площадку, зафиксировали регулярные test-restore и обновляемый runbook — всё, что превращает копии в гарантированное и предсказуемое восстановление.

🔵 Что сделали

✅ Развернули географически удалённую DR-площадку в облаке CORTEL.

✅ Согласовали с бизнесом RPO/RTO и настроили под них стратегию резервного копирования:
— базы данных — онлайн-обновления + полные бэкапы;
— виртуальные машины — ежедневные копии;
— мониторинг успешности бэкапов и регулярные test-restore.

✅ Обеспечили консистентные копии ERP и ускорили восстановление критичных сервисов (в т.ч. за счёт SSD на DR-стороне).

✅ Подготовили DR-план и runbook, распределили роли и ответственность, зафиксировали SLA/поддержку.

🔵 Что получили

👀 Подтверждённые метрики: RTO ≤ 4 часа, RPO < 24 часов.

👀 Предсказуемый подъём из резервных копий по отработанному сценарию.

👀 Снижение операционных рисков и прозрачные процессы восстановления.

➡️Подробную архитектуру, шаги и нюансы читайте в кейсе.

#изПрактики

➡️ Основные стратегии действий в момент аварии и восстановления (DR) в облаке:

➡️ Backup & Restore — просто достаём бэкап и поднимаем систему.
➡️ Pilot Light — заранее подготовлено ядро системы, остальное разворачиваем при аварии.
➡️ Warm Standby — почти рабочая копия, быстрое переключение.
➡️ Multi-Site — всё работает параллельно, авария почти не ощущается.

*чем ниже RTO/RPO — тем выше стоимость.

#полезное #красивое

🔍 Навигация по каналу

Друзья, вы же заметили, что у нас появилось несколько новых регулярных рубрик 🤗

🫥 Чтобы быстро находить нужные материалы — кейсы, инструменты, лайфхаки и т.д. — мы собрали всё по хэштегам.

➡️ #изПрактики — реальные кейсы и результаты проектов.

➡️ #заметкиИнженера — практические лайфхаки от DevOps-инженеров.

➡️ #гайды — пошаговые инструкции и чек-листы “как сделать”.

➡️ #полезное — инструменты, сервисы, песочницы.

➡️ #проИБ — всё, что касается информационной безопасности.

➡️ #линуксятина — всё про Linux.

➡️ #ИТиЗАКОН — регуляторка, изменения, соблюдение требований.

➡️ #книги — то, что стоит прочитать.

➡️ #MentalDebug — поддержка ментального здоровья в ИТ.

💎 Виртуализация — помогает управлять надёжностью, затратами и гибкостью инфраструктуры.

В ней есть основные функции, которые напрямую влияют на ключевые показатели:
SLA — фактическая доступность сервисов;
RTO/RPO — скорость восстановления и допустимые потери данных;
TCO — совокупная стоимость владения.

🧬 Разберем эти термины в виде краткого глоссария.

🟣 Live Migration (миграция на лету)

Перенос работающей ВМ между физическими серверами без остановки. Позволяет проводить плановое обслуживание и ребалансировку нагрузки без остановки сервисов.

*Снижается количество плановых простоев и соблюдается SLA.

🟣 High Availability (HA)

Автоматический перезапуск ВМ на другом узле при отказе. Сокращает простои из-за поломок оборудования.

*Предсказуемый RTO и выполнение SLA без ручных вмешательств.

🟣 Fault Tolerance (FT)

Параллельный «зеркальный» экземпляр ВМ с мгновенным переключением. Нужен там, где нельзя потерять ни секунды работы или транзакции.

*Исключаются простои для самых критичных систем, снижаются финансовые и репутационные риски.

🟣 Snapshot (снимок состояния)

Фиксация состояния ВМ в конкретный момент времени. Позволяет мгновенно создать "точку отката" перед рискованными операциями (обновления, изменение конфигураций) и быстро вернуться к ней в случае сбоя.

*Снижается время на восстановление после инцидентов (RTO) и риски при внесении изменений.

🟣 vSwitch и оверлеи (VXLAN/GENEVE)

Программные сети для связности и сегментации сервисов. Изменения выполняются политиками, без перестройки «железа».

*Быстрее запускаются новые среды и ограничивается влияние инцидентов.

🟣 Thin / Thick Provisioning

Способ выделять дисковое место: сразу целиком (thick) или по мере роста (thin). Thick — про стабильную производительность. Thin — про экономию ёмкости и плотность.

*Выбор нужного баланса цены и предсказуемости.

🟣 Scheduler / DRS

Автоматическое распределение и балансировка виртуальных машин между узлами кластера. Обеспечивает равномерное потребление ресурсов железа, предотвращая перегрузку отдельных серверов.

*Повышается общая эффективность использования инфраструктуры и снижается необходимость ручного вмешательства.

🟣 Ресурсные политики (Reservations / Limits / Shares)

Правила приоритета, гарантий и ограничений по CPU/памяти/IO. Критичные сервисы защищены от «соседей», фоновые — не мешают.

*Управление качеством сервисов и прозрачное планирование мощности.

🟣 NUMA и совместимость CPU (EVC)

Согласование ВМ с архитектурой процессоров и миграции между разными поколениями железа. Нагрузки свободно перемещаются по кластеру без привязки к конкретным узлам.

*Быстрее обновляется парк и получается избежать длительных простоев.

🟣 Storage QoS

Гарантии и лимиты по IOPS/пропускной способности для томов и ВМ. «Шумные» задачи не влияют на критичные сервисы.

*Стабильные задержки в пиковые часы и понятную связь уровня сервиса с затратами.

#полезное

💿 zVirt: «Диск в некорректном состоянии» после сбоя миграции

Во время плановой миграции диска ВМ между доменами хранения (HDD → SSD) произошёл сбой задачи миграции.

✅ Симптомы

В карточке ВМ появился снимок с пометкой «Диск в некорректном состоянии»; выключать/перезагружать ВМ рискованно из-за возможной потери данных.

✅ Что произошло

Система создала snapshot на исходном домене и delta на целевом; snapshot полностью скопировался, но ссылки в БД не переключились на новый слой — delta оказалась на целевом домене, а база продолжила указывать на старый.

✅ Как исправили

Так как snapshot уже был на целевом домене, обновили ссылки в БД на корректный снимок и принудительно активировали его; статус ВМ стал «Включено». После проверки работы удалили лишние тома на исходном домене.

👀 Вывод

В zVirt диск ВМ многослойный; при сбоях возможен разрыв ссылок между слоями. Сначала — диагностика по документации вендора, затем точечные правки.

#изПрактики

🕐 Live Migration: как переместить работающую ВМ между серверами без простоя

Есть задача: перенести работающую виртуальную машину с одного физического сервера на другой (чтобы обновить железо или перераспределить нагрузку). При этом пользователи не должны заметить перерыва в работе.

🗣Основные шаги Live Migration:

⏺ Подготовка

Проверяется совместимость хостов (CPU, память, устройства). На целевом хосте выделяются ресурсы. QEMU устанавливает соединение (TCP или RDMA для скорости). Если что-то несовместимо (например, разные CPU флаги), миграция не стартует.

⏺ Фаза предварительного копирования (Pre-copy)

Итеративно копируется память VM с источника на цель, пока VM продолжает работать. Сначала вся RAM, затем только "грязные" страницы (изменённые). Это повторяется, пока разница не станет минимальной (конвергенция).

⏺ Фаза остановки и переноса (Stop-and-copy)

VM приостанавливается на источнике (downtime начинается). Передаются оставшиеся страницы памяти, состояние CPU, устройств (диски, сетевые карты). Это быстрый шаг, чтобы минимизировать простой.

⏺ Фаза запуска на целевом хосте

VM запускается на целевом хосте. Трафик перенаправляется (если нужно, через ARP или SDN). Источник очищается.

⏺ Live Migration — это сложный оркестр синхронизации состояний, превращающий, казалось бы, невозможную задачу перемещения работающей системы в рутинную операцию для современных дата-центров.

#заметкиИнженера

🔄 KubeVirt

Фреймворк для управления виртуальными машинами прямо внутри Kubernetes.

Позволяет запускать ВМ как native-ресурсы кластера через Custom Resource Definitions (CRD).

⚙️ Основной функционал:

— Запуск и управление ВМ через Kubernetes API и kubectl
— Использование стандартных Kubernetes-сетей (CNI) и хранилищ (CSI)
— Live Migration ВМ между нодами кластера
— Поддержка cloud-init и автоматизированной настройки ВМ
— Интеграция с KVM/QEMU через специальные поды

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

#полезное
👉 Git

KVM + QEMU — виртуализация на Linux

KVM (Kernel-based Virtual Machine) — модуль ядра, обеспечивающий аппаратную виртуализацию.

QEMU — эмулятор, который с KVM превращается в полноценный гипервизор. Вместе они позволяют запускать VM быстро и эффективно, без overhead, как в VirtualBox или VMware.

Полезно для тестирования, разработки.

🟢 Пример 1

Создание VM одной командой (через QEMU)

qemu-system-x86_64 \
  -enable-kvm \
  -m 1G \
  -cpu host \
  -drive file=focal-server-cloudimg-amd64-disk-kvm.img,format=qcow2 \
  -netdev user,id=net0 \
  -device virtio-net-pci,netdev=net0 \
  -nographic

Где:
-enable-kvm — используем аппаратное ускорение
-m 1G — выделяем 1 ГБ памяти
-cpu host — пробрасываем CPU хоста без эмуляции
-nographic — запускаем без GUI (для серверов)

Преимущество
Максимально быстро и минималистично, но без персистентности — закрыли терминал = ВМ остановилась.

🟢 Пример 2

Создание управляемой ВМ одной командой (через libvirt)

virt-install \
  --name vm \
  --ram 2048 \
  --vcpu 2 \
  --disk my_disk.qcow2,size=8 \
  --cdrom ubuntu-24.04.3-live-server-amd64.iso

✅ Что это дает

— Автоматическая регистрация ВМ в libvirt
— Управление через virsh
— Сетевые мосты "из коробки"
— Персистентность конфигурации

Управление такими виртуальными машины происходит через утилиту virsh.

Основные команды:

virsh list --all           # список всех ВМ
virsh start vm             # запуск ВМ
virsh shutdown vm          # штатная остановка
virsh destroy vm           # принудительное завершение
virsh edit vm              # редактирование конфигурации
virsh undefine vm          # удаление ВМ (но не дисков)

📍 Первый пример с qemu-system-x86_64 — ваш выбор для быстрого тестирования образов и экспериментов, когда нужно запустить ВМ буквально одной командой.

📍 Второй подход через virt-install + virsh идеален, когда требуется полноценное управление виртуальными машинами — здесь на помощь приходит libvirt с его персистентностью и удобным CLI.

Оба способа отлично дополняют друг друга в арсенале инженера.

#линуксятина

🤓 Mastering KVM Virtualization

Практическое руководство по KVM, QEMU и libvirt

🔎 Рассматривается:
— архитектура и внутреннее устройство KVM/QEMU, работа libvirt;
— установка окружения и создание ВМ (virt-manager, virt-install, PXE);
— виртуальные сети и хранилища: Linux bridge, NAT/ routed/ isolated сети, MacVTap, iSCSI, LVM;
— управление жизненным циклом ВМ: консоли (VNC/SPICE), агенты гостя, live-миграция;
— шаблоны и снапшоты, форматы дисков, клонирование/тонкое развёртывание;
— Kimchi: веб-управление KVM/libvirt;
— SDN для KVM: Open vSwitch, туннели (VXLAN), OpenDaylight;
— интеграция с OpenStack и устранение неполадок виртуализации;
— производительность и best practices: VirtIO, CPU/memory/NUMA, I/O, тайм-кипинг;
— инструменты V2V/P2V (virt-v2v) и конвертация гостевых систем.

Авторы:
Humble Devassy Chirammal, Prasad Mukhedkar, Anil Vettathu.
Издательство:
Packt Publishing, 2016.

#книги

💎 Виртуализация vs Контейнеризация

Обе технологии позволяют запускать несколько изолированных сред на одной физической машине, но подходы у них разные.

➡️ Время запуска:

ВМ — минуты / контейнеры — секунды

➡️ Диск:

ВМ занимают больше / контейнеры легче

➡️ Портативность:

ВМ сложнее переносить / контейнеры проще

➡️ Эффективность:
у контейнеров выше

➡️ ОС и ядро:

ВМ используют собственную ОС / контейнеры — общее ядро

#полезное

⬆️ Кейс: Частное облако и российская виртуализация для энергокомпании

Запрет на использование иностранных ПАКов на объектах КИИ и растущие требования к отказоустойчивости заставляют критическую инфраструктуру искать быстрые и надёжные решения.

📞 Задача

Крупная энергокомпания — объект КИИ, обеспечивающий энергоснабжение в Сибири, обратилась с запросом:
— быстро нарастить ресурсы и повысить устойчивость ИТ-систем;
— перейти на российскую виртуализацию.

🖲️ Решение

Базой проекта стала платформа частного облака CORTEL с использованием отечественной системы виртуализации zVirt.

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

⭐️ Этапы внедрения

— Анализ требований КИИ и проектирование архитектуры.
— Развёртывание частного облака на базе zVirt в ЦОДе заказчика.
— Интеграция с существующей ИТ-инфраструктурой.
— Настройка политики доступа и мониторинга.
— Проверка производительности и переход в эксплуатацию.

🚩 Результат

— Развёртывание за 2 дня.
— SLA 99,95% (максимум ~4 часа недоступности в год).
— Соответствие требованиям КИИ.
— Отсутствие затрат на долгий цикл закупок оборудования.

«Подрядчик взял всё на себя — оборудование, мощности и отечественную виртуализацию. Мы получили удобный интерфейс, гарантии и специалистов на связи, отвечающих за работоспособность и администрирование кластера.»
— отметил ИТ-директор заказчика.

О нюансах проекта читайте здесь

Чем заменить VMware ➡️ здесь

#изПрактики

🛡 КИИ: Новости и материалы.

Если вы занялись вопросом недавно, вот памятка для ответственных и заинтересованных по теме КИИ, с ответами на основные вопросы.

Про актуальные изменения за первое полугодие 2025 года тут

Подробный план о том, как проводить категоризирование критической информационной инфраструктуры тут

Из последних новостей за второе полугодие:

Сроки миграции перенесли до 1 января 2028 и 1 декабря 2030.
Переход значимых объектов КИИ на российское ПО официально сдвинут.
Минцифры 19 сентября 2025 представило проект ПП о сроках и правилах перехода на отечественное ПО: предельная дата — 1 января 2028; при объективной невозможности и решении Президиума Правкомиссии срок может быть продлён, но не далее 1 декабря 2030.

Появился стандарт по ПАК для КИИ ПНСТ 1007-2025
В конце июня 2025 утверждён предварительный национальный стандарт, который классифицирует программно-аппаратные комплексы по назначению и задаёт основу для их признания «доверенными» для применения на объектах КИИ. Полный текст опубликован на портале Росстандарта.

Сформированы «Типовые отраслевые объекты КИИ»
ФСТЭК опубликовала проект постановления с перечнями типовых отраслевых объектов КИИ

#ИТиЗАКОН

👋 make-argocd-fly — генератор ArgoCD Applications.

Превращает шаблоны на базе Helm, Kustomize и Jinja2 в Kubernetes-манифесты, а также автоматически создает ресурсы Argo CD Application, адаптированные для разных окружений (например, dev, stage, prod).

Основной функционал:

✅Рендерит Helm-чарты и Kustomize-оверлеи в детерминированный YAML — видно, что именно будет применено в кластер.

✅Генерирует ресурсы Application для Argo CD на основе ваших шаблонов.

✅Поддерживает шаблоны на Jinja2 (переменные, логика, частичные шаблоны).

✅Работает с несколькими окружениями (dev/stage/prod) и раскладывает вывод по понятной структуре каталогов: output/<env>/<app>/…

✅Упрощает код-ревью: идентичные шаблоны всегда генерируют одинаковые манифесты, поэтому в Pull Request видно только смысловые изменения.

✅Установка:

pip install make-argocd-fly   # требуется Python ≥ 3.11

👉 Git
#полезное

Terraform — инструмент от HashiCorp для декларативного описания инфраструктуры через код (IaC).

Вы описываете желаемое состояние, а Terraform сам понимает, как его достичь.

⏰ Зачем

Упрощает управление инфраструктурой — нет ручных кликов в консолях. Обеспечивает повторяемость, аудит и коллаборацию. Идеально для DevOps: деплоите VPC, EC2 или K8s кластер одним apply.

⏰ Как используется

Пишем конфиг, запускаем terraform init (инициализация), terraform plan (превью изменений), terraform apply (применение). Для разрушения — terraform destroy. Поддерживает state-файлы для отслеживания изменений.

⏰ Модульность

Terraform поддерживает модули — переиспользуемые блоки кода.
Создайте модуль для VPC, и используйте его в разных проектах. Это как Lego: собирайте инфраструктуру из готовых частей, меняя переменные.

⏰ Универсальность языка HCL

HCL (HashiCorp Configuration Language) — декларативный язык Terraform.

Синтаксис одинаковый для всех облаков: ресурсы описываются блоками resource "aws_instance" {} или resource "google_compute_instance" {}. Разница только в провайдерах — плагинах для конкретных облаков (AWS, GCP). Один код — разные среды, легко мигрировать между провайдерами.

🔵 Terraform превращает ручное создание инфраструктуры в предсказуемый и повторяемый процесс. Один раз настроил — используешь везде.

#заметкиИнженера

💎 Terragrunt — тонкая обёртка над Terraform, которая устраняет повторяющийся код и упрощает управление сложной инфраструктурой.

🤔 Основной функционал

— Автоматическое управление зависимостями между модулями (dependencies)
— Поддержка нескольких окружений (dev/stage/prod) с общими настройками
— Интеграция с remote state для хранения состояния Terraform
— Hooks для выполнения скриптов до/после Terraform-операций
— Автоматизация команд Terraform (init, plan, apply) для всей инфраструктуры

🤔 Ключевые особенности

— Универсальность HCL: синтаксис Terraform (HCL) остаётся неизменным, Terragrunt добавляет надстройку для конфигураций
— Провайдер-независимость: работает с любыми облаками, отличия только в провайдерах, а код — единый
— Упрощение CI/CD: легко интегрируется в пайплайны для автоматизированного IaC

Terragrunt делает Terraform масштабируемым и удобным для команд, минимизируя повторения и ошибки.

👉 Git
#полезное

⚙️ Cloud-init — стандартная система инициализации для облачных экземпляров, которая выполняет начальную настройку при первом запуске ВМ. Поддерживается всеми major-облаками и гипервизорами.

✅ Как работает:

1. Образ ОС содержит cloud-init пакет
2. При старте ВМ cloud-init ищет данные конфигурации
3. Выполняет инструкции (пользователи, пакеты, скрипты)
4. Сохраняет логи в /var/log/cloud-init-output.log

✅ Основные возможности:
— Создание пользователей и настройка SSH-ключей
— Установка пакетов и обновление системы
— Настройка сетевых интерфейсов
— Выполнение custom-скриптов
— Монтирование дисков и настройка swap

🚪 Пример конфигурации:

#cloud-config
# Конфигурация пользователя 
users:
  - name: admin
    passwd: $6$rounds=4096$xyz$...  # хэш пароля
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    shell: /bin/bash

# Обновление пакетов
package_update: true
package_upgrade: true

# Установка сurl, htop, git
packages:
  - curl
  - htop
  - git

🤓 Cистема изначально разрабатывалась для Ubuntu, но стала де-факто стандартом и теперь поддерживается всеми major-дистрибутивами, включая CentOS, Debian и даже FreeBSD.

Cloud-init превращает создание новых серверов из рутины в автоматизированный процесс — один раз настроил конфиг и получаешь готовые к работе ВМ в любом облаке.

#линуксятина