Библиотека девопса | DevOps, SRE, Sysadmin

😊 Выберите свой класс 🐸Библиотека devops'a #развлекалово

🔄 Как переехать из Kubernetes в Terraform Когда инфраструктура разрастается — десятки кластеров, множество регионов, разные окружения — управление Kubernetes через локальные манифесты, Helm-чарты, скрипты и ad-hoc утилиты становится болью. Почему вообще стоит рассматривать Terraform — Единый подход к инфраструктуре как к коду (IaC). Меньше ad-hoc скриптов, меньше особенных случаев. — Одинаковые шаблоны, модули, terraform-пакеты можно применять для разных кластеров, регионов, окружений. — Когда инфраструктура описана декларативно в Terraform, её проще тестировать, планировать изменения и откатывать. С чего начать переезд Прежде чем двигать сервисы, стоит договориться о структуре: где хранится код, как выглядят модули, как будут разделены окружения вроде dev, staging и prod. Важно определиться с управлением состоянием: локальные файлы .tfstate неприемлемы в продакшене, поэтому лучше сразу настроить удалённое хранилище — например, S3 с DynamoDB для блокировок или Terraform Cloud. Следующий шаг — начать с малого. Не стоит пытаться перенести сразу весь кластер или десятки сервисов. Лучше выбрать один изолированный сервис, у которого нет сложных зависимостей, и попробовать описать его в Terraform. Так команда поймёт процесс, столкнётся с первыми проблемами импорта и научится проверять планы перед применением. Когда базовые принципы обкатаны, становится ясно, что без инструментов миграция будет мучительной. Поэтому стоит вложиться в создание шаблонов и модулей. Один модуль может описывать типовой сервис — Deployment, Service и Ingress. Другой — целый namespace или набор ресурсов для окружения. Самая непростая часть — импорт существующих ресурсов. Kubernetes кластеры редко пустые, в них уже работают десятки объектов. Их нужно постепенно поднимать под контроль Terraform, используя команду terraform import. Но просто импортировать недостаточно — нужно сверять, чтобы конфигурация в HCL совпадала с реальностью. Когда появляется больше кластеров, возникает вопрос мультикластерного управления. Terraform позволяет описывать несколько провайдеров и работать с ними через алиасы. Это значит, что можно использовать одни и те же модули для разных окружений, меняя только контекст и параметры. Главная ценность миграции — в стандартизации. Инфраструктура становится предсказуемой и масштабируемой, а команды получают единый язык управления. Это долгий процесс, но итогом становится устойчивая и безопасная платформа. 🐸Библиотека devops'a #буст

⭐️ Кто такие Unit-лид и Technical Owner Всё чаще IT-команды переходят на продуктовый подход, где важна не только скорость разработки, но и долгосрочная ценность продукта. Но стандартных ролей вроде тимлидов и проектных менеджеров уже недостаточно. Мы собрали 5 карточек, чтобы разобраться: • зачем нужны эти роли; • чем они отличаются от привычных тимлидов и архитекторов; • в каких случаях без них не обойтись. ➡️ Подробнее про роли 🐸Библиотека devops'a

MTC Engineer Hack — хакатон на стыке инженерии и ИТ от МТС. Реши технический кейс онлайн и получи приглашение в финал, где сможешь поработать на реальном оборудовании МТС. 12 победителей разделят призовой фонд в 500 000 рублей. 📎 Зарегистрироваться: ссылка 🎯 Для кого: студенты и молодые инженеры в областях аппаратной разработки, DevOps, радиоинженерии, сетевых технологий. 💻 Формат: онлайн-тур + офлайн-финал в Москве 👤 Участие: индивидуальное Приглашаем всех, кто интересуется телеком-отраслью, хочет прокачать навыки в инженерии и попробовать себя в задачах МТС. Будет отлично, если ты владеешь одним из навыков: → разбираешься в сотовых сетях и оборудовании базовых станций; → умеешь работать с данными и статистикой; → знаком с LTE/NR и схемотехникой; → интересуешься цифровой обработкой сигналов; → понимаешь маршрутизацию и пишешь скрипты для сетевого оборудования. C 3 по 5 октября пройдёт онлайн-этап: участники готовят кейс по своему профилю. 11 октября — встреча финалистов на площадке и работа с настоящим оборудованием МТС, где эксперты компании помогут разобраться в деталях и дадут советы по доработке решений. Что тебя ждёт: 🔺 Задачи, близкие к реальной работе инженеров МТС: от проектирования до оптимизации сетей. 🔺 Возможность познакомиться с экспертами компании и показать им свои решения. 🔺 Практика, которая позволит почувствовать себя частью технологической команды МТС. 🔺 Офлайн-финал в Москве: живое общение и защита проектов. Билеты и проживание оплатят организаторы. Регистрация открыта до 1 октября включительно: https://cnrlink.com/mtsengineerhackdevopslib

🐳 Шпаргалка по сетям Docker Docker изолирует контейнеры не только по процессам и файловой системе, но и по сети. От этого зависит, смогут ли контейнеры общаться между собой, будут ли они доступны извне и насколько безопасно это взаимодействие. Основные типы сетей • Bridge — сеть по умолчанию. Контейнеры получают внутренний IP и могут общаться друг с другом. Для связки нескольких сервисов в одной среде лучше создавать свои пользовательские сети (docker network create). Тогда контейнеры будут доступны по имени, например ping db. • Host — общая сеть с хостом. Контейнер не имеет отдельного IP: он использует сетевой стек машины. Это снижает изоляцию, но убирает накладные расходы на маршрутизацию. Подходит для сервисов, где важна скорость. • None — полная изоляция. Контейнер запускается без сети. Применяется редко, в основном для задач, где сеть не нужна (утилиты, тесты). • Overlay — сеть для кластера. Объединяет несколько Docker-хостов. Используется в Swarm и Kubernetes. Контейнеры на разных серверах работают так, будто они рядом. • Macvlan — контейнер как полноценный участник LAN. Контейнер получает MAC-адрес и «выглядит» в локальной сети как отдельное устройство. Это удобно, если требуется доступ из реальной сети напрямую, например для IoT или legacy-приложений. Полезные команды Список сетей:

docker network ls

Подробная информация о сети:

docker network inspect bridge

Создать сеть:

docker network create mynet

Удалить сеть:

docker network rm mynet

Подключить контейнер к сети:

docker network connect mynet app1

Отключить контейнер от сети:

docker network disconnect mynet app1

🐸Библиотека devops'a #буст

Несколько инженеров иногда одновременно запускают terraform apply, рискуя повредить state. Как это правильно предотвратить? 👾 — Хранить state локально у каждого разработчика 👍 — Использовать удалённый backend с блокировкой (S3 + DynamoDB lock / GCS / Az Blob) и -lock=true 🥰 — Поставить git-hook, запрещающий git push во время apply ⚡️ — Перед каждым apply делать terraform refresh Библиотека задач DevOps

📰 Недельный дайджест Собрали для вас материалы прошедшей недели. — AWS CLI v2 теперь доступен для macOS С версии 2.30.0 AWS CLI v2 предоставляет универсальные бинарные установщики для macOS, которые работают нативно как на процессорах Apple Silicon, так и на Intel. — Динамическое обновление доступных слотов в k8s В Kubernetes v1.34 поддержка динамического обновления количества доступных слотов для CSI-драйверов перешла в стадию Beta. Теперь драйверы могут периодически обновлять информацию о количестве доступных слотов для подключения томов. — Вышел KDE Linux Alpha — Unit-лид и Technical Owner — FreeBSD 15.0-ALPHA1 🐸Библиотека devops'a

⚙️10 стратегий снижения рисков в гибридных облаках Гибридные облака — это для тех, кто хочет гибкость и масштабируемость, но они также приносят с собой уникальные риски. Без корректной стратегии эти риски могут привести к уязвимостям в безопасности, проблемам с управлением ресурсами и даже утечкам данных. Чтобы эффективно управлять гибридной инфраструктурой, необходимо соблюдать правила, которые помогут снизить эти риски и повысить стабильность. ➡️ Про стратегии минимизации рисков в статье 🐸Библиотека devops'a #буст

🐸Библиотека devops'a #развлекалово

⭐️ 5 трендов IT-найма 2025 Грейды уже не гарантируют рост зарплаты, джоб-борды теряют эффективность, а AI вмешался в процесс собеседований так, что теперь компании делятся на лагеря — одни разрешают использовать ChatGPT, другие устраивают собесы с ручкой и листочком. В карточках — пять трендов, которые перевернули рынок: от смерти грейдинга до «AI-friendly» собеседований. ➡️ Читать статью 🐸Библиотека devops'a

🔥 Последняя неделя перед стартом курса по AI-агентам Старт курса уже 15го числа! Если вы планировали вписаться — сейчас ПОСЛЕДНИЙ шанс забронировать место На курсе: — разложим LLM по косточкам: токенизация, SFT, PEFT, инференс — соберём RAG и научимся оценивать его адекватно — построим настоящую мультиагентную систему — архитектуру, которая умеет расти — разберём CoPilot, сломаем через prompt injection (спасибо Максу) — и наконец, посмотрим, как это работает в MCP и реальных кейсах 📍 Это 5 живых вебинаров + раздатка + домашки + чат с преподавателями И главное — возможность реально разобраться, как проектировать системы на LLM, а не просто «поиграться с API» Промокод на 5.000₽: LASTCALL 👉 Курс здесь

📰 Недельный дайджест Собрали для вас материалы прошедшей недели. — AWS CLI v2 теперь доступен для macOS С версии 2.30.0 AWS CLI v2 предоставляет универсальные бинарные установщики для macOS, которые работают нативно как на процессорах Apple Silicon, так и на Intel. — Динамическое обновление доступных слотов в k8s В Kubernetes v1.34 поддержка динамического обновления количества доступных слотов для CSI-драйверов перешла в стадию Beta. Теперь драйверы могут периодически обновлять информацию о количестве доступных слотов для подключения томов. — Вышел KDE Linux Alpha — Unit-лид и Technical Owner — FreeBSD 15.0-ALPHA1 🐸Библиотека devops'a

🔄 Жизненный цикл пода в Kubernetes Жизненный цикл пода в Kubernetes — это цепочка процессов, от создания манифеста до завершения работы контейнеров. Сейчас разберем, как происходит запуск, мониторинг и завершение подов в Kubernetes. 1. Отправка манифеста пода и сохранение в etcd Первым шагом при создании пода является отправка его манифеста в API-сервер Kubernetes. Этот запрос проверяется на корректность, и после успешной проверки информация о поде сохраняется в распределённом хранилище etcd, которое является источником правды для всего кластера. 2. Выбор ноды для пода планировщиком После того как манифест пода успешно сохранен, наступает этап его размещения. планировщик Kubernetes принимает решение о том, на какую ноду будет размещен под. Этот процесс основан на нескольких критериях: • количество доступных CPU и памяти. • правила, которые могут ограничивать или рекомендовать размещение подов на определённых нодах. • метки или предпочтения, которые могут влиять на выбор ноды. 3. Подготовка пода на выбранной ноде После того как нода была выбрана, на ней начинает работать kubelet, агент, который занимается подготовкой пода. 4. Запуск контейнеров и мониторинг их состояния Как только все подготовительные работы завершены, контейнеры начинают переходить в состояние Running. На этом этапе Kubernetes использует health probes для мониторинга состояния контейнеров. 5. Мониторинг фаз пода Kubernetes отслеживает состояние пода на высокоуровневом уровне. Изначально под находится в статусе Pending, затем, когда контейнеры начинают свою работу, он переходит в фазу Running. После завершения работы под может попасть в одну из следующих фаз: • Succeeded — если контейнеры завершили свою работу без ошибок. • Failed — если контейнеры завершили работу с ошибками. • Unknown — если состояние пода не удается определить по каким-либо причинам. 6. Завершение работы пода и очистка ресурсов Когда контейнеры в поде завершили свою работу, Kubernetes посылает SIGTERM сигнал для корректного завершения их работы. Если контейнеры не успевают завершиться в отведённое время, Kubernetes отправляет SIGKILL, чтобы принудительно их остановить. 🐸Библиотека devops'a #буст

👀 Домашний докер Наткнулись на видео, где показывается интересный подход к организации Docker контейнеров в домашней лаборатории. Вместо использования решений вроде Kubernetes, в видео предлагается настройка на виртуальной машине с Debian, с привязкой томов. А ещё в видео демонстрируется использование нескольких полезных Docker контейнеров, таких как Fresh RSS для удобного чтения новостей, Jellyfin для медиастриминга и Netbird для создания безопасных сетевых соединений. ➡️ Смотреть видео 🐸Библиотека devops'a #буст

🚀 Как вы стали девопсом Для многих путь в DevOps — это не линейный процесс, а целое путешествие через различные роли и технологии. Кто-то пришёл из системного администратора, кто-то — из разработки, а кто-то стал девопсом после нескольких лет работы в ИТ-сфере. Какие шаги стали решающими на вашем пути Были ли важные курсы или сертификаты, которые помогли вам перейти в эту роль? Какую роль сыграли практические проекты и опыт работы с CI/CD, контейнерами или облачными сервисами? Какие сложности возникли при переходе, и как вы их преодолели? 💬 Давайте обсудим! Поделитесь своей историей в комментариях 👇 🐸Библиотека devops'a #междусобойчик

⭐️ Вышел FreeBSD 15.0-ALPHA1 Команда FreeBSD представила первую альфа-версию 15.0-RELEASE. Образы доступны в различных форматах: ISO, memstick, QCOW2, VHD, VMDK, а также OCI-контейнеры. ➡️ Официальный анонс 🐸Библиотека devops'a #свежак

⚙️ Kubernetes 1.34 упрощает работу с .env файлами В Kubernetes v1.34 появилась поддержка автоматической загрузки .env файлов в контейнеры. Теперь переменные окружения можно хранить в стандартных .env файлах, которые Kubernetes сам распознаёт и применяет при деплое. Как это работает 1. Создаём .env файл

# app.env
APP_NAME=MyCoolApp
APP_ENV=production
APP_DEBUG=false

2. Применяем .env в Pod через ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-env
data:
  # Kubernetes автоматически прочитает строки из файла app.env
  # в v1.34 можно указать директорию с .env файлами через envFrom
  APP_NAME: MyCoolApp
  APP_ENV: production
  APP_DEBUG: "false"

3. Используем ConfigMap в контейнере

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
  - name: demo-container
    image: nginx
    envFrom:
      - configMapRef:
          name: app-env

Теперь контейнер получает переменные окружения напрямую из .env файла. ➡️ Блог разработчиков 🐸Библиотека devops'a #буст

🐸Библиотека devops'a #развлекалово

💻Сетевая безопасность — это не только технологии, а целостная система: архитектура, процессы и механизмы защиты. 🎯На практикуме «Архитектура сетевой безопасности предприятия», который стартует 6 октября, вы узнаете, как строится устойчивая система. 💡В течение 6 недель вы: • Разберёте реальные атаки и ошибки проектирования • Узнаете, как проектировать сетевую архитектуру с учётом актуальных угроз и требований регуляторов • Отработаете навыки на облачном стенде с NGFW, PT NAD и MaxPatrol SIEM • Освоите методы контроля и оценки эффективности защиты 👨‍💻Практикум ведут эксперты Positive Technologies: Сергей Сахаров, Александр Бирюков, Алексей Сивенков и другие специалисты, которые поделятся опытом работы по построению сетевой безопасности. 📢 Авторы практикума — Михаил Кадер и Андрей Скрипкин, архитекторы решений по информационной безопасности с опытом более 30 лет. Участие платное, количество мест ограничено. [Узнать подробнее]