🔍 Что же такое DevOps на самом деле?
Часто DevOps воспринимают исключительно как набор инструментов — CI/CD, Kubernetes, Terraform, Ansible... Но это лишь вершина айсберга. DevOps — это культурная трансформация, а не просто технологии.
🔹 От разделения к сотрудничеству
Раньше компании жили по принципу «Разработчики создают приложения — админы страдают». DevOps меняет парадигму:
✅ Разработчики и администраторы работают вместе
✅ Ответственность за продукт разделяется между всеми
✅ Меньше конфликтов, больше эффективности
🔹 Автоматизация как необходимость
В современном мире ручные процессы — враги скорости и стабильности. DevOps убирает человеческий фактор, внедряя:
⚙️ Инфраструктуру как код (IaC) – Terraform, Pulumi, SDK
🔄 Автотестирование – Unit, Integration, E2E
📈 Мониторинг и логирование – Prometheus, ELK, Grafana
🤖 CI/CD пайплайны – GitHub Actions, GitLab CI/CD, ArgoCD
DevOps опирается на итеративный подход:
🔹 Маленькие и частые релизы вместо редких, но рискованных
🔹 Постоянный мониторинг — ошибки исправляются сразу
🔹 Обратная связь от пользователей → продукт улучшается в реальном времени
Таким образом, DevOps делает бизнес более гибким, а IT-инфраструктуру — стабильной и предсказуемой.
Часто DevOps воспринимают исключительно как набор инструментов — CI/CD, Kubernetes, Terraform, Ansible... Но это лишь вершина айсберга. DevOps — это культурная трансформация, а не просто технологии.
🔹 От разделения к сотрудничеству
Раньше компании жили по принципу «Разработчики создают приложения — админы страдают». DevOps меняет парадигму:
✅ Разработчики и администраторы работают вместе
✅ Ответственность за продукт разделяется между всеми
✅ Меньше конфликтов, больше эффективности
🔹 Автоматизация как необходимость
В современном мире ручные процессы — враги скорости и стабильности. DevOps убирает человеческий фактор, внедряя:
⚙️ Инфраструктуру как код (IaC) – Terraform, Pulumi, SDK
🔄 Автотестирование – Unit, Integration, E2E
📈 Мониторинг и логирование – Prometheus, ELK, Grafana
🤖 CI/CD пайплайны – GitHub Actions, GitLab CI/CD, ArgoCD
DevOps опирается на итеративный подход:
🔹 Маленькие и частые релизы вместо редких, но рискованных
🔹 Постоянный мониторинг — ошибки исправляются сразу
🔹 Обратная связь от пользователей → продукт улучшается в реальном времени
Таким образом, DevOps делает бизнес более гибким, а IT-инфраструктуру — стабильной и предсказуемой.
📚 Как лучше понять DevOps?
Если хотите не просто разобраться в инструментах, но и вникнуть в DevOps как в культуру, рекомендую прочитать «Проект Феникс» (The Phoenix Project).
Это не учебник, а бизнес-роман, который показывает реальные проблемы IT-команд: долгие релизы, завалы тикетов, хаотичные процессы. Книга объясняет DevOps не через технологии, а через мышление и процессы.
После неё стоит прочитать:
📖 «The Unicorn Project» — продолжение «Феникса» с фокусом на разработчиков и DevOps-подход в их работе.
📖 «Accelerate» — научный разбор принципов DevOps и их влияния на бизнес, основанный на исследованиях.
📖 «Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale» — детально раскрывает культурные аспекты DevOps: как построить сильную команду, наладить процессы и избежать хаоса при масштабировании.
📖 SRE Book (Site Reliability Engineering) — культовый гайд от Google по SRE-подходу (развитие идей DevOps в сторону чётких метрик и надёжности систем). Обязательно к прочтению для любого инженера, связанного с эксплуатацией.
Если хотите не просто разобраться в инструментах, но и вникнуть в DevOps как в культуру, рекомендую прочитать «Проект Феникс» (The Phoenix Project).
Это не учебник, а бизнес-роман, который показывает реальные проблемы IT-команд: долгие релизы, завалы тикетов, хаотичные процессы. Книга объясняет DevOps не через технологии, а через мышление и процессы.
После неё стоит прочитать:
📖 «The Unicorn Project» — продолжение «Феникса» с фокусом на разработчиков и DevOps-подход в их работе.
📖 «Accelerate» — научный разбор принципов DevOps и их влияния на бизнес, основанный на исследованиях.
📖 «Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale» — детально раскрывает культурные аспекты DevOps: как построить сильную команду, наладить процессы и избежать хаоса при масштабировании.
📖 SRE Book (Site Reliability Engineering) — культовый гайд от Google по SRE-подходу (развитие идей DevOps в сторону чётких метрик и надёжности систем). Обязательно к прочтению для любого инженера, связанного с эксплуатацией.
🎯 Итог: DevOps — это не просто тренд / тайтл
DevOps — это не должность, не технология и даже не команда. Это образ мышления и совокупность практик, которые позволяют создавать устойчивые, масштабируемые и надёжные системы.
🚀 А как у вас в компании? DevOps — это реальная практика или просто модный термин? 🤔👇
DevOps — это не должность, не технология и даже не команда. Это образ мышления и совокупность практик, которые позволяют создавать устойчивые, масштабируемые и надёжные системы.
🚀 А как у вас в компании? DevOps — это реальная практика или просто модный термин? 🤔👇
Продолжаем холивары 🔥
Часто можно услышать, что DevOps — это «админ, который автоматизирует». Но это миф. Хороший DevOps-инженер — это не просто человек, который пишет скрипты для рутины, а специалист, находящийся на стыке инфраструктуры и разработки. Без навыков программирования здесь далеко не уйти.
Почему важно уметь программировать?
🔹 Автоматизация — это код, а не костыли
- Вся суть DevOps — в устранении ручных действий. Без кода и понимания структур данных автоматизация превращается в набор костылей
- Infrastructure as Code (Terraform, Pulumi) требует знания синтаксиса и логики.
- K8S Operators — это по сути программы на Go (или на любом другом ЯП), управляющие объектами в K8S кластере.
- Jenkins plugins? Да, их тоже пишут на Groovy.
🔹 CI/CD это полноценные конвееры доставки
Работа с CI/CD — это не просто «настройка пайплайнов». Это разработка сложных сценариев:
- Взаимодействие с API (GitHub, AWS, Slack).
- Написание проверок: «Почему деплой упал?» → Анализ логов через Python-скрипты.
- Автоматизация rollback-стратегий: если новая версия сломалась, система сама откатывается.
Без знания Bash, Python, Go и понимания YAML/JSON сложно создать эффективный пайплайн.
🔹 Отладка и оптимизация
Когда приложение падает, DevOps должен понимать, почему оно упало:
- Читать код, чтобы найти например утечку памяти.
- Анализировать стектрейсы на Java/Python.
- Находить узкие места в производительности (например, медленные SQL-запросы).
- Понимать какие куски кода нагружают CPU
👉 Без навыков программирования вы станете тем, кто просто перезапускает контейнеры и надеется на лучшее.
🔹 Создание инструментов
Хороший DevOps — это инженер, а не просто администратор. В реальных задачах часто приходится писать утилиты для деплоя, операторы для Kubernetes, плагины для Terraform, парсеры логов, а иногда и бэкенд для внутренних сервисов DevOps-команды. Python и Go — одни из лучших языков для этих задач.
🔹 Диагностика и поиск узких мест
DevOps-инженер нередко занимается профилированием и поиском проблем:
📌 Почему контейнер использует 2 ГБ памяти вместо 200 МБ?
📌 Где узкое место в производительности базы?
📌 Почему HTTP-запросы стали медленнее?
📌 Как устранить утечки памяти в JVM-приложении?
Без понимания кода вы будете строить гипотезы, но не находить точных причин.
🔧 Какие еще хард-скиллы нужны DevOps?
✅ Языки программирования: Python, Go, Bash (скрипты, API-интеграции, инструменты).
✅ IaC (Infrastructure as Code): Terraform, Ansible, Pulumi, CloudFormation.
✅ Контейнеризация и оркестрация: Docker, Kubernetes, Helm.
✅ CI/CD: GitHub Actions, GitLab CI/CD, Jenkins, ArgoCD.
✅ Облака: AWS, GCP, Azure.
✅ Мониторинг и логирование: Prometheus, Grafana, ELK, Loki, OpenTelemetry.
✅ Сетевые и операционные системы: Linux, TCP/IP, DNS, безопасность.
✅ Диагностика производительности: профилирование JVM, анализ логов, трассировка запросов.
💡 Вывод
Программирование — не просто «полезный навык», а одна из ключевых компетенций DevOps-инженера. Без него автоматизация превращается в хаос из скриптов, CI/CD работает «как придется», а поиск проблем — в бесконечные гипотезы без точных выводов и гадание на кофейной гуще.
🔥 А как часто вам приходится программировать на позиции DevOps? 🤔 Давайте ломать стереотипы в комментах! 👇
Часто можно услышать, что DevOps — это «админ, который автоматизирует». Но это миф. Хороший DevOps-инженер — это не просто человек, который пишет скрипты для рутины, а специалист, находящийся на стыке инфраструктуры и разработки. Без навыков программирования здесь далеко не уйти.
Почему важно уметь программировать?
🔹 Автоматизация — это код, а не костыли
- Вся суть DevOps — в устранении ручных действий. Без кода и понимания структур данных автоматизация превращается в набор костылей
- Infrastructure as Code (Terraform, Pulumi) требует знания синтаксиса и логики.
- K8S Operators — это по сути программы на Go (или на любом другом ЯП), управляющие объектами в K8S кластере.
- Jenkins plugins? Да, их тоже пишут на Groovy.
🔹 CI/CD это полноценные конвееры доставки
Работа с CI/CD — это не просто «настройка пайплайнов». Это разработка сложных сценариев:
- Взаимодействие с API (GitHub, AWS, Slack).
- Написание проверок: «Почему деплой упал?» → Анализ логов через Python-скрипты.
- Автоматизация rollback-стратегий: если новая версия сломалась, система сама откатывается.
Без знания Bash, Python, Go и понимания YAML/JSON сложно создать эффективный пайплайн.
🔹 Отладка и оптимизация
Когда приложение падает, DevOps должен понимать, почему оно упало:
- Читать код, чтобы найти например утечку памяти.
- Анализировать стектрейсы на Java/Python.
- Находить узкие места в производительности (например, медленные SQL-запросы).
- Понимать какие куски кода нагружают CPU
👉 Без навыков программирования вы станете тем, кто просто перезапускает контейнеры и надеется на лучшее.
🔹 Создание инструментов
Хороший DevOps — это инженер, а не просто администратор. В реальных задачах часто приходится писать утилиты для деплоя, операторы для Kubernetes, плагины для Terraform, парсеры логов, а иногда и бэкенд для внутренних сервисов DevOps-команды. Python и Go — одни из лучших языков для этих задач.
🔹 Диагностика и поиск узких мест
DevOps-инженер нередко занимается профилированием и поиском проблем:
📌 Почему контейнер использует 2 ГБ памяти вместо 200 МБ?
📌 Где узкое место в производительности базы?
📌 Почему HTTP-запросы стали медленнее?
📌 Как устранить утечки памяти в JVM-приложении?
Без понимания кода вы будете строить гипотезы, но не находить точных причин.
🔧 Какие еще хард-скиллы нужны DevOps?
✅ Языки программирования: Python, Go, Bash (скрипты, API-интеграции, инструменты).
✅ IaC (Infrastructure as Code): Terraform, Ansible, Pulumi, CloudFormation.
✅ Контейнеризация и оркестрация: Docker, Kubernetes, Helm.
✅ CI/CD: GitHub Actions, GitLab CI/CD, Jenkins, ArgoCD.
✅ Облака: AWS, GCP, Azure.
✅ Мониторинг и логирование: Prometheus, Grafana, ELK, Loki, OpenTelemetry.
✅ Сетевые и операционные системы: Linux, TCP/IP, DNS, безопасность.
✅ Диагностика производительности: профилирование JVM, анализ логов, трассировка запросов.
💡 Вывод
Программирование — не просто «полезный навык», а одна из ключевых компетенций DevOps-инженера. Без него автоматизация превращается в хаос из скриптов, CI/CD работает «как придется», а поиск проблем — в бесконечные гипотезы без точных выводов и гадание на кофейной гуще.
🔥 А как часто вам приходится программировать на позиции DevOps? 🤔 Давайте ломать стереотипы в комментах! 👇
Мы уже говорили про университет и образование,но давайте по-честному — айтишник без кода — как бариста без кофе ☕🧑💻
В универе у меня была монорепа —туда летело всё: эксперименты, кривые скрипты, тестовые проекты. Сейчас она уже мертва и задепрекейчена 🪦, но пока я писал этот пост, то зашел в нее чтобы посмотреть статистику и она оказалось очень даже не скучная 📊
💡Вывод простой:
Неважно, кто ты — QA, DevOps, Java-разработчик — программируй много и часто. Спустя 2, 4, 5 или 10 лет тебе точно не понравится свой старый код, но и не должен был писать его красиво —ты писал его, чтобы набить руку 🛠️ и прокачаться.
В универе у меня была монорепа —туда летело всё: эксперименты, кривые скрипты, тестовые проекты. Сейчас она уже мертва и задепрекейчена 🪦, но пока я писал этот пост, то зашел в нее чтобы посмотреть статистику и она оказалось очень даже не скучная 📊
💡Вывод простой:
Неважно, кто ты — QA, DevOps, Java-разработчик — программируй много и часто. Спустя 2, 4, 5 или 10 лет тебе точно не понравится свой старый код, но и не должен был писать его красиво —ты писал его, чтобы набить руку 🛠️ и прокачаться.
«Зачем учиться писать код, если можно просто спросить у ChatGPT?» 🤖💬
И правда — казалось бы, зачем?
Открыл ChatGPT или Cursor, написал «сделай мне модуль» — и готово. AI сам всё сделает:
🧩 шаблон наклепает
🔤 переменные придумает
📄 документацию сгенерирует
Но есть нюанс:
чтобы понять, он выдал рабочий код или полную чушь, ты должен уметь его прочитать, понять и оценить.
👉 Это синтаксически валидно?
👉 Это безопасно?
👉 Это вообще работает, или просто похоже на правду?
Ты смотришь:
"Хмм… что-то странно" — идёшь уточняешь, меняешь запрос,
и в итоге приходишь к чему-то нормальному.
Вот для этого и нужен практический опыт, который касается любого языка на котором ведется разработка.
Вывод:
AI — это ускоритель, но не замена головы. Чтобы эффективно пользоваться умными тулзами — надо уметь писать код руками 🛠️🧠
И правда — казалось бы, зачем?
Открыл ChatGPT или Cursor, написал «сделай мне модуль» — и готово. AI сам всё сделает:
🧩 шаблон наклепает
🔤 переменные придумает
📄 документацию сгенерирует
Но есть нюанс:
чтобы понять, он выдал рабочий код или полную чушь, ты должен уметь его прочитать, понять и оценить.
👉 Это синтаксически валидно?
👉 Это безопасно?
👉 Это вообще работает, или просто похоже на правду?
Ты смотришь:
"Хмм… что-то странно" — идёшь уточняешь, меняешь запрос,
и в итоге приходишь к чему-то нормальному.
Вот для этого и нужен практический опыт, который касается любого языка на котором ведется разработка.
Вывод:
AI — это ускоритель, но не замена головы. Чтобы эффективно пользоваться умными тулзами — надо уметь писать код руками 🛠️🧠
Поговорим про всеми любимый Jenkins!
Когда-то данный тул был стандартом де-факто для CI/CD и топ-1 инструментом для DevOps в резюме. Гибкость, тысячи плагинов, возможность кастомизации под любые задачи — всё это сделало его мощным инструментом. Но времена меняются, и сегодня Jenkins уже не выглядит таким удобным, современным и безопасным, как раньше
🚨Почему Jenkins теряет позиции?
Все чаще встречаются проекты, работающие исключительно на GitHub / GitLab CI/CD, и многие инженеры даже не видели Jenkins вживую. Давайте разберёмся, почему это происходит.
1️⃣ Сложная настройка и поддержка
Jenkins требует выделенных серверов, своевременных обновлений, управления зависимостями и постоянного администрирования. В эпоху облачных решений, где всё работает «из коробки», это выглядит как избыточная сложность. Современные инструменты позволяют настраивать пайплайны за минуты, а не тратить часы на настройку Jenkins.
2️⃣ Устаревший подход
Современные CI/CD-инструменты используют декларативные конфигурации в YAML, которые просты, понятны и легко читаются. А что у Jenkins? Groovy-скрипты, сложные pipeline-декларации и необходимость писать кастомные плагины. Если вы когда-нибудь пробовали это делать, то знаете: Groovy + Java = боль.
3️⃣ Более быстрые и простые альтернативы
Облачные CI/CD-решения позволяют настраивать пайплайны за минуты, а не часы. Они легко интегрируются с современными DevOps-практиками, такими как GitOps и Kubernetes. Jenkins пытается догонять конкурентов, но время уходит, и разрыв только увеличивается.
4️⃣ Высокий уровень уязвимостей
Jenkins известен своими уязвимостями. Многие из них имеют статус high или даже critical, особенно в плагинах. А ещё есть небезопасное выполнение (не)изолированного Groovy-кода, что делает систему мишенью для атак. В эпоху, когда безопасность стоит на первом месте, это серьёзный минус.
Когда-то данный тул был стандартом де-факто для CI/CD и топ-1 инструментом для DevOps в резюме. Гибкость, тысячи плагинов, возможность кастомизации под любые задачи — всё это сделало его мощным инструментом. Но времена меняются, и сегодня Jenkins уже не выглядит таким удобным, современным и безопасным, как раньше
🚨Почему Jenkins теряет позиции?
Все чаще встречаются проекты, работающие исключительно на GitHub / GitLab CI/CD, и многие инженеры даже не видели Jenkins вживую. Давайте разберёмся, почему это происходит.
1️⃣ Сложная настройка и поддержка
Jenkins требует выделенных серверов, своевременных обновлений, управления зависимостями и постоянного администрирования. В эпоху облачных решений, где всё работает «из коробки», это выглядит как избыточная сложность. Современные инструменты позволяют настраивать пайплайны за минуты, а не тратить часы на настройку Jenkins.
2️⃣ Устаревший подход
Современные CI/CD-инструменты используют декларативные конфигурации в YAML, которые просты, понятны и легко читаются. А что у Jenkins? Groovy-скрипты, сложные pipeline-декларации и необходимость писать кастомные плагины. Если вы когда-нибудь пробовали это делать, то знаете: Groovy + Java = боль.
3️⃣ Более быстрые и простые альтернативы
Облачные CI/CD-решения позволяют настраивать пайплайны за минуты, а не часы. Они легко интегрируются с современными DevOps-практиками, такими как GitOps и Kubernetes. Jenkins пытается догонять конкурентов, но время уходит, и разрыв только увеличивается.
4️⃣ Высокий уровень уязвимостей
Jenkins известен своими уязвимостями. Многие из них имеют статус high или даже critical, особенно в плагинах. А ещё есть небезопасное выполнение (не)изолированного Groovy-кода, что делает систему мишенью для атак. В эпоху, когда безопасность стоит на первом месте, это серьёзный минус.
🛠️Что используют сегодня для CICD?
✅ GitHub Actions — встроенные CI/CD-пайплайны в экосистему GitHub. Простая настройка, бесплатный тариф для open-source, активное развитие.
✅ GitLab CI/CD — монолитное решение, встроенное в GitLab. Поддерживает автоматизацию тестирования, сборки и деплоя, имеет удобную YAML-конфигурацию.
✅ ArgoCD + Kubernetes — идеальный вариант для GitOps, декларативного управления деплоями в Kubernetes.
✅ CircleCI, Drone, Tekton — мощные CI/CD-инструменты для различных сценариев, особенно в облачных и контейнерных средах.
✅ Jenkins X — попытка адаптации к современным реалиям, облачная версия, ориентированная на Kubernetes и GitOps. Однако его популярность остаётся низкой, а переход на него требует значительных усилий.
✅ GitHub Actions — встроенные CI/CD-пайплайны в экосистему GitHub. Простая настройка, бесплатный тариф для open-source, активное развитие.
✅ GitLab CI/CD — монолитное решение, встроенное в GitLab. Поддерживает автоматизацию тестирования, сборки и деплоя, имеет удобную YAML-конфигурацию.
✅ ArgoCD + Kubernetes — идеальный вариант для GitOps, декларативного управления деплоями в Kubernetes.
✅ CircleCI, Drone, Tekton — мощные CI/CD-инструменты для различных сценариев, особенно в облачных и контейнерных средах.
✅ Jenkins X — попытка адаптации к современным реалиям, облачная версия, ориентированная на Kubernetes и GitOps. Однако его популярность остаётся низкой, а переход на него требует значительных усилий.
📊 А что с классическим Jenkins?
Несмотря на всё вышесказанное, Jenkins всё ещё жив и активно используется. Взглянем на цифры за 2024 год (stats.jenkins.io):
📌 Активные jobs: 82 000 000+
📌 Подключенные nodes: 1 000 000+
📌 Коммиты: 51 000+
📌 Релизы: 13 LTS, 50 Weekly
📌 Pull Requests: 6000+
📌 GitHub Stars: 23 000+
📌 Контрибьюторы: 3000+
📌 Компании-использователи: 39 000+
Как видите, Jenkins по-прежнему используется в крупных компаниях, включая FAANG по следующим причинам:
🔹 Гибкость и мощность — он остаётся универсальным инструментом для действительно сложных пайплайнов. Кастомизировать можно все, что угодно.
🔹 Легаси-инфраструктура — многие проекты исторически зависят от Jenkins, и миграция может быть очень затратной.
🔹 Расширяемость — тысячи плагинов позволяют адаптировать Jenkins под любые нужды.
Несмотря на всё вышесказанное, Jenkins всё ещё жив и активно используется. Взглянем на цифры за 2024 год (stats.jenkins.io):
📌 Активные jobs: 82 000 000+
📌 Подключенные nodes: 1 000 000+
📌 Коммиты: 51 000+
📌 Релизы: 13 LTS, 50 Weekly
📌 Pull Requests: 6000+
📌 GitHub Stars: 23 000+
📌 Контрибьюторы: 3000+
📌 Компании-использователи: 39 000+
Как видите, Jenkins по-прежнему используется в крупных компаниях, включая FAANG по следующим причинам:
🔹 Гибкость и мощность — он остаётся универсальным инструментом для действительно сложных пайплайнов. Кастомизировать можно все, что угодно.
🔹 Легаси-инфраструктура — многие проекты исторически зависят от Jenkins, и миграция может быть очень затратной.
🔹 Расширяемость — тысячи плагинов позволяют адаптировать Jenkins под любые нужды.
💡 Итоги
Jenkins — это легенда, но мир движется вперёд. Современные инструменты предлагают простоту, скорость и безопасность, которые Jenkins уже не может обеспечить в полной мере. Однако он всё ещё остаётся мощным решением для сложных сценариев и легаси-проектов.
Стоит ли выбирать Jenkins? Скорее всего, нет. Сейчас есть более простые, удобные и масштабируемые альтернативы, которые позволяют быстрее достигать результата.
А как у вас? Вы до сих пор на Jenkins или уже перешли на что-то более удобное? Делитесь опытом в комментариях! 🤔👇
PS: В качестве бонуса можете посмотреть выступление с последнего DevOpsConf, на котором снова заговорили про Jenkins: https://www.youtube.com/watch?v=OlD25Cbig_U
PSS: Две недавние статьи, где авторы придерживаются примерно тех же мыслей:
- https://medium.com/@osomudeyazudonu/stop-using-jenkins-4dcb7e4f0e53
- https://habr.com/ru/articles/902300/
Jenkins — это легенда, но мир движется вперёд. Современные инструменты предлагают простоту, скорость и безопасность, которые Jenkins уже не может обеспечить в полной мере. Однако он всё ещё остаётся мощным решением для сложных сценариев и легаси-проектов.
Стоит ли выбирать Jenkins? Скорее всего, нет. Сейчас есть более простые, удобные и масштабируемые альтернативы, которые позволяют быстрее достигать результата.
А как у вас? Вы до сих пор на Jenkins или уже перешли на что-то более удобное? Делитесь опытом в комментариях! 🤔👇
PS: В качестве бонуса можете посмотреть выступление с последнего DevOpsConf, на котором снова заговорили про Jenkins: https://www.youtube.com/watch?v=OlD25Cbig_U
PSS: Две недавние статьи, где авторы придерживаются примерно тех же мыслей:
- https://medium.com/@osomudeyazudonu/stop-using-jenkins-4dcb7e4f0e53
- https://habr.com/ru/articles/902300/
Последний пост про Jenkins на сегодня. Страшно представить, но когда-то, в 2017 или 2018 году, я сам пытался построить свой IAC-фреймворк для создания Jenkins Jobs — на тогда ещё новомодном JobDSL. Сейчас это выглядит перегруженно и дико, но тогда казалось настоящим прорывом: автоматизация в виде кода вместо ручного накликивания джоб.
Если вам интересна археология, вот те самые репозитории:
🔗Сам фреймворк: https://github.com/kvendingoldo/JDCL
🔗Пример описания Jenkins Jobs: https://github.com/kvendingoldo/udc-jobdsl
А раз уж сегодня говорили о важности программирования для DevOps, вот вам фрагмент «страшного» кода того времени — для автоматизированного создания Jenkins Jobs:
Если вам интересна археология, вот те самые репозитории:
🔗Сам фреймворк: https://github.com/kvendingoldo/JDCL
🔗Пример описания Jenkins Jobs: https://github.com/kvendingoldo/udc-jobdsl
А раз уж сегодня говорили о важности программирования для DevOps, вот вам фрагмент «страшного» кода того времени — для автоматизированного создания Jenkins Jobs:
def processConfig(String jcPath) {
def jc
if (this.type == 'LOCAL') {
jc = new Yaml().load(new File(jcPath).getText('UTF-8'))
} else if (this.type == 'JENKINS') {
jc = new Yaml().load(this.dslFactory.readFileFromWorkspace(jcPath))
}
if (jc.containsKey('imports')) {
def jcChild = jc.findAll { key, _ -> !(key in ['imports']) }
(jc.imports).each { jcImport ->
def jcParent = processConfig("${this.importDirectory}/${jcImport}")
if (jcChild.job!=null) {
jcChild = merge(jcChild, jcParent)
} else {
jcChild.findAll { key, _ -> !(key in ['job']) }.each { key, value ->
jcChild."${key}" = merge(jcChild."${key}", jcParent)
}
}
}
return jcChild
} else {
return jc
}
}
private def merge(def config, def object) {
object?.each { key, value ->
if (config."${key}" == null || (!config.containsKey(key))) {
config."${key}" = value
} else {
if (!(config."${key}" instanceof String)) {
config."${key}" = merge(config."${key}", value)
}
}
}
return config
}
И сам пример Jenkins Job описанной на Groovy в ту эпоху:
package jobdsl.build.jobs
import com.kvendingoldo.jdcl.core.Functions
class UdcPreCommit {
static job(dslFactory, jobConfig) {
dslFactory.job(Functions.generateJobName(jobConfig)) {
description(jobConfig.job.description)
label(jobConfig.job.label)
concurrentBuild()
logRotator(jobConfig.job.daysToKeepBuilds, jobConfig.job.maxOfBuildsToKeep)
environmentVariables {
env('GENERATED_VERSION_TYPE', jobConfig.job.generatedVersionType)
overrideBuildParameters(true)
}
wrappers {
colorizeOutput()
timestamps()
preBuildCleanup()
}
scm {
git {
remote {
credentials(jobConfig.job.credentials.github)
github(jobConfig.job.repository, 'ssh')
refspec('+refs/pull/*:refs/remotes/origin/pr/*')
}
branch('${sha1}')
extensions {
wipeOutWorkspace()
submoduleOptions {
recursive()
}
}
}
}
triggers {
githubPullRequest {
cron('*/1 * * * *')
permitAll()
}
}
steps {
gitHubSetCommitStatusBuilder {
statusMessage {
content('building...')
}
}
shell(dslFactory.readFileFromWorkspace('jobdsl/common/bash/emailValidator.sh'))
shell('gcloud docker -a')
shell(dslFactory.readFileFromWorkspace(jobConfig.job.variablesGeneratorScript))
shell(dslFactory.readFileFromWorkspace(jobConfig.job.versionGeneratorScript))
envInjectBuilder {
propertiesFilePath('variables.txt')
propertiesContent('')
}
buildNameUpdater {
fromFile(false)
buildName('${VERSION}')
fromMacro(true)
macroTemplate('${VERSION}')
macroFirst(false)
}
maven {
goals('clean install')
goals('-B')
goals('-C')
goals('-q')
goals(' -Pimage')
goals('-Ddocker.registry.host=gcr.io')
}
}
publishers {
gitHubCommitNotifier {
resultOnFailure('fail')
statusMessage {
content('build is completed')
}
}
}
}
}
}
Kubernetes уже у всех, верно? 🤔 Кажется, что так.
Иногда разработчики удивляются, когда я не предлагаю K8S для нового проекта. В последнее время у многих сложился майндсет: «Поставил куб — и дальше оно как-нибудь само», вплоть до выписывания TLS сертификатов и автоматического создания DNS-записей.
Ну, в целом, конечно, можно накидать YAML'ов и посмотреть, что будет. Но ни одно коробочное решение (вроде CozeStack, DeckHouse или OpenShift) не сделает всё за вас. Kubernetes — это не волшебная таблетка, а сложный инструмент, который требует глубокого понимания.
🚀 Давайте посмотрим, что вам нужно понимать с технической точки зрения , когда вы онбордите Kubernetes.
🔹 Базовый уровень (уровень сертификации CKAD)
Это минимум, без которого лучше вообще не лезть в Kubernetes:
✅ Управление подами. Как создавать, удалять и масштабировать поды.
✅ Sidecars и init-контейнеры
✅ PVC/PV. Как хранить данные в Kubernetes и не потерять их при пересоздании подов.
✅ Service / Ingress. Как прокинуть трафик из кластера наружу
✅ Helm / Kustomize. Как управлять конфигурациями через темплейты.
🔹 Средний уровень (уровень сертификации CKA)
✅ Что такое SMI/CNI/etc. Как сети работают в Kubernetes и почему это важно.
✅ Траблшутинг кластера. Как читать логи, смотреть события через kubectl get events и находить корень проблемы.
✅ Разные CNI-плагины и их особенности. Calico, Flannel, Cilium — чем они отличаются и какой выбрать.
✅ Архитектура Kubernetes (правда ли, что куб это всего 5 бинарей?). Как работают kubelet, API-сервер, etcd и другие компоненты.
✅ Service Mesh. Зачем он нужен и как выбрать между Istio, Linkerd и другими.
✅ Автоматизация сертификатов. Как использовать cert-manager или встроенные возможности Istio.
✅ Тюнинг системных компонентов. Например, как оптимизировать etcd для высокой нагрузки.
✅ Генерация YAML'ов через kubectl. Как не писать их вручную и не допускать ошибок.
✅ Работа с секретами. Как безопасно их хранить и управлять ими.
✅ Логирование и мониторинг. Настройка Prometheus, Loki, OpenTelemetry в Kubernetes.
✅ GitOps. Внедрение ArgoCD или FluxCD для управления конфигурациями.
✅ kubernetes-the-hard-way. Если вы прошли этот гайд, то уже понимаете, как всё устроено под капотом.
🔹 Высокий уровень (beyond CKA/CKS)
✅ Kubernetes и eBPF. Как они связаны и что можно сделать с помощью eBPF для улучшения производительности и безопасности.
✅ Кастомные контроллеры. Создание CRD (Custom Resource Definitions) и разработка операторов.
✅ Мультикластерные решения. Как управлять несколькими кластерами и синхронизировать их. Как собрать федерацию.
✅ Безопасность. Использование OPA, Kyverno, Falco для защиты кластера.
✅ Производительность. Как понять, что API-сервер или etcd не справляются с нагрузкой, и что с этим делать.
Иногда разработчики удивляются, когда я не предлагаю K8S для нового проекта. В последнее время у многих сложился майндсет: «Поставил куб — и дальше оно как-нибудь само», вплоть до выписывания TLS сертификатов и автоматического создания DNS-записей.
Ну, в целом, конечно, можно накидать YAML'ов и посмотреть, что будет. Но ни одно коробочное решение (вроде CozeStack, DeckHouse или OpenShift) не сделает всё за вас. Kubernetes — это не волшебная таблетка, а сложный инструмент, который требует глубокого понимания.
🚀 Давайте посмотрим, что вам нужно понимать с технической точки зрения , когда вы онбордите Kubernetes.
🔹 Базовый уровень (уровень сертификации CKAD)
Это минимум, без которого лучше вообще не лезть в Kubernetes:
✅ Управление подами. Как создавать, удалять и масштабировать поды.
✅ Sidecars и init-контейнеры
✅ PVC/PV. Как хранить данные в Kubernetes и не потерять их при пересоздании подов.
✅ Service / Ingress. Как прокинуть трафик из кластера наружу
✅ Helm / Kustomize. Как управлять конфигурациями через темплейты.
🔹 Средний уровень (уровень сертификации CKA)
✅ Что такое SMI/CNI/etc. Как сети работают в Kubernetes и почему это важно.
✅ Траблшутинг кластера. Как читать логи, смотреть события через kubectl get events и находить корень проблемы.
✅ Разные CNI-плагины и их особенности. Calico, Flannel, Cilium — чем они отличаются и какой выбрать.
✅ Архитектура Kubernetes (правда ли, что куб это всего 5 бинарей?). Как работают kubelet, API-сервер, etcd и другие компоненты.
✅ Service Mesh. Зачем он нужен и как выбрать между Istio, Linkerd и другими.
✅ Автоматизация сертификатов. Как использовать cert-manager или встроенные возможности Istio.
✅ Тюнинг системных компонентов. Например, как оптимизировать etcd для высокой нагрузки.
✅ Генерация YAML'ов через kubectl. Как не писать их вручную и не допускать ошибок.
✅ Работа с секретами. Как безопасно их хранить и управлять ими.
✅ Логирование и мониторинг. Настройка Prometheus, Loki, OpenTelemetry в Kubernetes.
✅ GitOps. Внедрение ArgoCD или FluxCD для управления конфигурациями.
✅ kubernetes-the-hard-way. Если вы прошли этот гайд, то уже понимаете, как всё устроено под капотом.
🔹 Высокий уровень (beyond CKA/CKS)
✅ Kubernetes и eBPF. Как они связаны и что можно сделать с помощью eBPF для улучшения производительности и безопасности.
✅ Кастомные контроллеры. Создание CRD (Custom Resource Definitions) и разработка операторов.
✅ Мультикластерные решения. Как управлять несколькими кластерами и синхронизировать их. Как собрать федерацию.
✅ Безопасность. Использование OPA, Kyverno, Falco для защиты кластера.
✅ Производительность. Как понять, что API-сервер или etcd не справляются с нагрузкой, и что с этим делать.
📌 И напоследок…
Kubernetes — это не просто инструмент, это целая экосистема, которая требует глубокого понимания. Если вы думаете, что можно просто «поставить куб и забыть», то вы сильно ошибаетесь.
В приложении к посту есть картинка от компании Flant (из доклада «Как правильно сделать Kubernetes» Дмитрия Столярова), которая показывает, насколько глубоким является айсберг Kubernetes.
А как вы оцениваете свой уровень владения K8S? Не бесит ли вас, когда кто-то говорит, что умеет с ним работать, но по факту не разбирается дальше создания Deployment? 😅🚀
PS: Как бонус - отличная статья про куб на хабре https://habr.com/ru/companies/h3llo_cloud/articles/902188/
Kubernetes — это не просто инструмент, это целая экосистема, которая требует глубокого понимания. Если вы думаете, что можно просто «поставить куб и забыть», то вы сильно ошибаетесь.
В приложении к посту есть картинка от компании Flant (из доклада «Как правильно сделать Kubernetes» Дмитрия Столярова), которая показывает, насколько глубоким является айсберг Kubernetes.
А как вы оцениваете свой уровень владения K8S? Не бесит ли вас, когда кто-то говорит, что умеет с ним работать, но по факту не разбирается дальше создания Deployment? 😅🚀
PS: Как бонус - отличная статья про куб на хабре https://habr.com/ru/companies/h3llo_cloud/articles/902188/
1️⃣ Навигация по первому дню андерхуда
— DevOps: философия, а не просто набор инструментов
— Почему DevOps обязан уметь программировать
— Jenkins: жив или мёртв?
— Актуальные инструменты CI/CD
— Kubernetes повсюду
— DevOps: философия, а не просто набор инструментов
— Почему DevOps обязан уметь программировать
— Jenkins: жив или мёртв?
— Актуальные инструменты CI/CD
— Kubernetes повсюду
🚀 Kubernetes — новый язык для разработки инфраструктуры?
Раньше инфраструктура была просто средой для запуска приложений. Сегодня Kubernetes (K8S) изменил правила игры: теперь инфраструктура — это код, который нужно писать, версионировать и управлять как программным продуктом.
Почему Kubernetes стал де-факто "языком инфраструктуры"?
🔹 Декларативный подход — манифесты YAML описывают желаемое состояние системы, а K8s сам обеспечивает его выполнение. Это как сказать системе: «Хочу, чтобы было вот так» — и она сделает всё за вас.
🔹 Композиция — как код состоит из модулей и функций, так и инфраструктура в Kubernetes собирается из Deployments, Services, Ingress и других объектов. Это как LEGO для взрослых — собирай, что нужно, и не изобретай велосипед.
🔹 Абстракции — Разработчикам больше не нужно заботиться о физических серверах, балансировке и автошкаллировании. Всё это управляется на уровне кластера. Вы просто говорите: «Мне нужно 10 подов» — и Kubernetes делает это (но помните, только в случае managed решения).
🔹 Расширяемость — С помощью Custom Resource Definitions (CRD) и Custom API servers можно создавать собственные объекты и управлять ими как встроенными ресурсами. Это как добавить в язык программирования свои ключевые слова.
Инфраструктурные инженеры → DevOps-разработчики
Если раньше инфраструктура настраивалась вручную или с помощью bash-скриптов, то теперь:
✅ Helm-чарты = пакетные менеджеры
✅ Kustomize = управление конфигурациями без дублирования кода
✅ Operators и CRD = объектно-ориентированное программирование в инфраструктуре
✅ GitOps (ArgoCD, FluxCD) = версионирование и автоматизация развертывания
К чему мы идем?
Мы движемся к тому, чтобы заранее, на понятном языке, декларировать, что мы хотим от системы. Это понимание должно быть одинаково глубоко на уровне DevOps инженеров и разработчиков.
Но почему мы говорим только про K8S?
Terraform и подобные инструменты хороши, но они, в первую очередь, описывают облачные ресурсы, что ближе к инфраструктурным инженерам, чем к разработчикам. Kubernetes, напротив, представляет собой более высокоуровневую абстракцию, которая позволяет сосредоточиться на архитектуре приложения и его управлении, без глубокой привязки к конкретным облачным провайдерам и их ресурсам.
💡 Вывод
Kubernetes — это не просто оркестратор контейнеров, а новый язык разработки инфраструктуры, который требует от инженеров понимания концепций, аналогичных программированию.
А как у вас?
Kubernetes — удобный инструмент или сложный барьер для входа? Используете ли вы GitOps, Operators или другие продвинутые практики? Считаете ли вы, что K8S действительно стал «языком инфраструктуры»?
PS: Если вам интересно послушать про мой опыт разработки операторов, кастомных планировщиков или подготовку к CKA/CKAD, пишите в комментариях 👇 Сделаю отдельный пост с лайфхаками и советами!
Раньше инфраструктура была просто средой для запуска приложений. Сегодня Kubernetes (K8S) изменил правила игры: теперь инфраструктура — это код, который нужно писать, версионировать и управлять как программным продуктом.
Почему Kubernetes стал де-факто "языком инфраструктуры"?
🔹 Декларативный подход — манифесты YAML описывают желаемое состояние системы, а K8s сам обеспечивает его выполнение. Это как сказать системе: «Хочу, чтобы было вот так» — и она сделает всё за вас.
🔹 Композиция — как код состоит из модулей и функций, так и инфраструктура в Kubernetes собирается из Deployments, Services, Ingress и других объектов. Это как LEGO для взрослых — собирай, что нужно, и не изобретай велосипед.
🔹 Абстракции — Разработчикам больше не нужно заботиться о физических серверах, балансировке и автошкаллировании. Всё это управляется на уровне кластера. Вы просто говорите: «Мне нужно 10 подов» — и Kubernetes делает это (но помните, только в случае managed решения).
🔹 Расширяемость — С помощью Custom Resource Definitions (CRD) и Custom API servers можно создавать собственные объекты и управлять ими как встроенными ресурсами. Это как добавить в язык программирования свои ключевые слова.
Инфраструктурные инженеры → DevOps-разработчики
Если раньше инфраструктура настраивалась вручную или с помощью bash-скриптов, то теперь:
✅ Helm-чарты = пакетные менеджеры
✅ Kustomize = управление конфигурациями без дублирования кода
✅ Operators и CRD = объектно-ориентированное программирование в инфраструктуре
✅ GitOps (ArgoCD, FluxCD) = версионирование и автоматизация развертывания
К чему мы идем?
Мы движемся к тому, чтобы заранее, на понятном языке, декларировать, что мы хотим от системы. Это понимание должно быть одинаково глубоко на уровне DevOps инженеров и разработчиков.
Но почему мы говорим только про K8S?
Terraform и подобные инструменты хороши, но они, в первую очередь, описывают облачные ресурсы, что ближе к инфраструктурным инженерам, чем к разработчикам. Kubernetes, напротив, представляет собой более высокоуровневую абстракцию, которая позволяет сосредоточиться на архитектуре приложения и его управлении, без глубокой привязки к конкретным облачным провайдерам и их ресурсам.
💡 Вывод
Kubernetes — это не просто оркестратор контейнеров, а новый язык разработки инфраструктуры, который требует от инженеров понимания концепций, аналогичных программированию.
А как у вас?
Kubernetes — удобный инструмент или сложный барьер для входа? Используете ли вы GitOps, Operators или другие продвинутые практики? Считаете ли вы, что K8S действительно стал «языком инфраструктуры»?
PS: Если вам интересно послушать про мой опыт разработки операторов, кастомных планировщиков или подготовку к CKA/CKAD, пишите в комментариях 👇 Сделаю отдельный пост с лайфхаками и советами!
Давайте немного поговорим о главном холиваре в мире IaC: OpenTofu vs Terraform. Ну и что использовать в 2025 для описания инфраструктуры.
Почему все так сложно? Контекст драмы
- 2023: HashiCorp перевел Terraform на BSL-лицензию, запретив коммерческое использование в конкурентных продуктах. Сообщество взорвалось — так родился OpenTofu (форк Terraform под MPL 2.0).
- 2024: OpenTofu набрал хайп, но… внезапно заблокировал доступ для пользователей из России и удалил российские облака из реестра. Теперь оба инструмента стали проблемными для многих команд и проектов.
👉 Если коротко имеем следующую картину:
Terraform = стабильность, но BSL и зависимость от HashiCorp/IBM.
OpenTofu = open-source, но без российских провайдеров и с политическими ограничениями.
К сожалению, подобное происходит не только с Terraform, и подробнее об этом можно прочитать здесь. Ну а пока мы с вами разберемся, что же выбрать для нового проекта в 2025 году.
🔥 Ключевые различия:
1️⃣ Лицензия и открытость
🔹 OpenTofu — полностью open-source (MPL 2.0), управляется сообществом, решения принимаются коллективно, без полного контроля одной компании.
🔹 Terraform — изначально open-source, но теперь использует BSL, что вводит ограничения на коммерческое использование. Развивается HashiCorp (а теперь и IBM).
2️⃣ Функциональность
🔹 Оба инструмента работают по декларативному принципу: вы описываете желаемое состояние инфраструктуры, а система сама приводит её в нужное состояние.
🔹 OpenTofu уже предлагает дополнительные возможности, например:
- Шифрование state-файлов из коробки
- Ранняя обработка переменных
- Улучшения в планировании изменений
🔹Terraform выигрывает в стабильности, интеграциях и зрелости экосистемы.
3️⃣ Экосистема и сообщество
🔹 Terraform существует дольше (7+ лет развития), у него зрелая экосистема, HashiCorp активно поддерживает экосистему плагинов и Terraform Cloud. Помимо этого, Terraform обладает огромной базой пользователей.
🔹 OpenTofu растёт быстрыми темпами, за ним стоят крупные игроки, но его сообщество пока не такое зрелое и сформированное
4️⃣ Ограничения для российских пользователей
🔹Terraform заблокировал доступ к реестру провайдеров ещё в 2022 году, но не удалял существующие провайдеры.
🔹 OpenTofu полностью заблокировал пользователей из России и удалил российских облачных провайдеров вызвал этим длительную дискуссию в сообществе. На данный момент, отсуствие провайдеров в официальном реестре делает его непригодным для работы с российскими облаками.
В любом случае, для обхода блокировки реества вам в обоих случаях понадобятся зеркала. Для Terraform их существует достаточно много, а вот для OpenTofu пока ни одного. Про настройку зеркалов вы можете прочитать здесь.
Почему все так сложно? Контекст драмы
- 2023: HashiCorp перевел Terraform на BSL-лицензию, запретив коммерческое использование в конкурентных продуктах. Сообщество взорвалось — так родился OpenTofu (форк Terraform под MPL 2.0).
- 2024: OpenTofu набрал хайп, но… внезапно заблокировал доступ для пользователей из России и удалил российские облака из реестра. Теперь оба инструмента стали проблемными для многих команд и проектов.
👉 Если коротко имеем следующую картину:
Terraform = стабильность, но BSL и зависимость от HashiCorp/IBM.
OpenTofu = open-source, но без российских провайдеров и с политическими ограничениями.
К сожалению, подобное происходит не только с Terraform, и подробнее об этом можно прочитать здесь. Ну а пока мы с вами разберемся, что же выбрать для нового проекта в 2025 году.
🔥 Ключевые различия:
1️⃣ Лицензия и открытость
🔹 OpenTofu — полностью open-source (MPL 2.0), управляется сообществом, решения принимаются коллективно, без полного контроля одной компании.
🔹 Terraform — изначально open-source, но теперь использует BSL, что вводит ограничения на коммерческое использование. Развивается HashiCorp (а теперь и IBM).
2️⃣ Функциональность
🔹 Оба инструмента работают по декларативному принципу: вы описываете желаемое состояние инфраструктуры, а система сама приводит её в нужное состояние.
🔹 OpenTofu уже предлагает дополнительные возможности, например:
- Шифрование state-файлов из коробки
- Ранняя обработка переменных
- Улучшения в планировании изменений
🔹Terraform выигрывает в стабильности, интеграциях и зрелости экосистемы.
3️⃣ Экосистема и сообщество
🔹 Terraform существует дольше (7+ лет развития), у него зрелая экосистема, HashiCorp активно поддерживает экосистему плагинов и Terraform Cloud. Помимо этого, Terraform обладает огромной базой пользователей.
🔹 OpenTofu растёт быстрыми темпами, за ним стоят крупные игроки, но его сообщество пока не такое зрелое и сформированное
4️⃣ Ограничения для российских пользователей
🔹Terraform заблокировал доступ к реестру провайдеров ещё в 2022 году, но не удалял существующие провайдеры.
🔹 OpenTofu полностью заблокировал пользователей из России и удалил российских облачных провайдеров вызвал этим длительную дискуссию в сообществе. На данный момент, отсуствие провайдеров в официальном реестре делает его непригодным для работы с российскими облаками.
В любом случае, для обхода блокировки реества вам в обоих случаях понадобятся зеркала. Для Terraform их существует достаточно много, а вот для OpenTofu пока ни одного. Про настройку зеркалов вы можете прочитать здесь.