Код Меркури

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 не справляются с нагрузкой, и что с этим делать.

И сам пример 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')
                    }
                }
            }
        }
    }
}

Последний пост про Jenkins на сегодня. Страшно представить, но когда-то, в 2017 или 2018 году, я сам пытался построить свой IAC-фреймворк для создания Jenkins Jobs — на тогда ещё новомодном JobDSL. Сейчас это выглядит перегруженно и дико, но тогда казалось настоящим прорывом: автоматизация в виде кода вместо ручного накликивания джоб. Если вам интересна археология, вот те самые репозитории: 🔗Сам фреймворк: 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 — это легенда, но мир движется вперёд. Современные инструменты предлагают простоту, скорость и безопасность, которые 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 всё ещё жив и активно используется. Взглянем на цифры за 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 под любые нужды.

🛠️Что используют сегодня для 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. Однако его популярность остаётся низкой, а переход на него требует значительных усилий.

Поговорим про всеми любимый 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-кода, что делает систему мишенью для атак. В эпоху, когда безопасность стоит на первом месте, это серьёзный минус.

«Зачем учиться писать код, если можно просто спросить у ChatGPT?» 🤖💬 И правда — казалось бы, зачем? Открыл ChatGPT или Cursor, написал «сделай мне модуль» — и готово. AI сам всё сделает: 🧩 шаблон наклепает 🔤 переменные придумает 📄 документацию сгенерирует Но есть нюанс: чтобы понять, он выдал рабочий код или полную чушь, ты должен уметь его прочитать, понять и оценить. 👉 Это синтаксически валидно? 👉 Это безопасно? 👉 Это вообще работает, или просто похоже на правду? Ты смотришь: "Хмм… что-то странно" — идёшь уточняешь, меняешь запрос, и в итоге приходишь к чему-то нормальному. Вот для этого и нужен практический опыт, который касается любого языка на котором ведется разработка. Вывод: AI — это ускоритель, но не замена головы. Чтобы эффективно пользоваться умными тулзами — надо уметь писать код руками 🛠️🧠

Мы уже говорили про университет и образование,но давайте по-честному — айтишник без кода — как бариста без кофе ☕🧑‍💻 В универе у меня была монорепа —туда летело всё: эксперименты, кривые скрипты, тестовые проекты. Сейчас она уже мертва и задепрекейчена 🪦, но пока я писал этот пост, то зашел в нее чтобы посмотреть статистику и она оказалось очень даже не скучная 📊 💡Вывод простой: Неважно, кто ты — QA, DevOps, Java-разработчик — программируй много и часто. Спустя 2, 4, 5 или 10 лет тебе точно не понравится свой старый код, но и не должен был писать его красиво —ты писал его, чтобы набить руку 🛠️ и прокачаться.

Продолжаем холивары 🔥 Часто можно услышать, что 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 — это реальная практика или просто модный термин? 🤔👇

📚 Как лучше понять 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 воспринимают исключительно как набор инструментов — 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-командами или отдельными специалистами с таким тайтлом. Но что на самом деле скрывается за этим термином? 📜 Немного истории DevOps как концепция родился в 2009 году, когда Патрик Дебуа (Patrick Debois) организовал первую конференцию DevOpsDays. Но корни движения уходят в 2000-е, когда компании вроде Google и Amazon осознали, что стены между разработкой и администрированием мешают инновациям. До этого мир жил по принципу «Dev vs. Ops»: ✅ Разработчики пишут код → отправляют его в продакшен ✅ Администраторы и инженеры обеспечивают его стабильную работу 💥 Проблемы? → Каждый винит друг друга -> сроки релиза бесконечно сдвигаются DevOps разрушает эти барьеры, превращая команды в единый организм, где разработка и эксплуатация не просто взаимодействуют, а работают совместно.

Паша о том, как оказался в нашей команде 🪐

🧠 Уже 20–21 мая в Маунтин-Вью стартует Google I/O Ждём пачку громких анонсов: - Android 16: новый дизайн Material 3 Expressive, виджеты на локскрине, улучшенные уведомления и поддержка Auracast - Gemini Ultra: свежая версия топовой AI-модели + слухи о подписках Premium Plus и Pro - Astra и Mariner — ИИ-агенты, которые умеют понимать мир в реальном времени и даже «гулять» по интернету за вас - Утечка намекает на генератор видеообзоров на базе Veo 2 и апдейт NotebookLM Также обещают сессии по Chrome, Google Cloud, Wear OS, Android XR и новой открытой AI-коллекции Gemma.

Swift Regex прокачали — теперь с дебаггером Писать и проверять регулярки стало намного проще: в Swift Regex теперь есть дебаггер, который шаг за шагом показывает, как работает ваше выражение. А ещё разработчики собрали в репозитории классную практику: 🧠 объяснения человеческим языком 🧪 примеры на каждый кейс 🤓 задачки для закрепления Мощная база по регэкспам — вот тут Если вы давно откладывали знакомство с регулярками в Swift — самое время закрыть этот гештальт.

🧠 У ChatGPT теперь можно просить ревью кода прямо из GitHub Новая фича — Deep Research по репозиториям. Отправляете бота в своё GitHub-репо, а он возвращается с: - анализом кода - комментами к PR’ам - прожаркой архитектуры - ссылками на конкретные строки и участки Поддержка уже прилетает всем на платных планах.

Если вы вдруг не знали, как наглядно выглядит фишинговая атака 🐑