Когда вы собираете контейнерные образы, которые должны запускаться на разном железе, одного тега недостаточно.

Нужно понимать, действительно ли образ поддерживает несколько архитектур, и здесь помогает docker manifest. Команда docker manifest позволяет инспектировать и управлять мультиархитектурными образами.

С её помощью можно точно увидеть, под какие платформы собран образ, например, AMD64 для облачных серверов и ARM64 для edge-устройств, всё это под одним тегом. Это простой способ убедиться, что образ, который вы тянете, будет стабильно работать в разных окружениях.

Это особенно важно для гибридных деплоев. Например, ваш бэкенд крутится в облаке на AMD64, а edge-шлюзы или IoT-устройства работают на ARM.

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

Для команд, которые доставляют приложения на разнородное железо, использование docker manifest – простой способ избежать ситуации, когда работает на одной машине, но не работает на другой.

👉 DevOps Portal

Многим организациям сложно управлять несколькими Kubernetes-кластерами

Например,

У вас могут быть отдельные кластеры для dev, stage и prod.

Если вы хотите задеплоить что-то вроде стека Prometheus в каждый кластер, вам обычно приходится переключать контексты kubeconfig и накатывать всё по одному.

Вместо этого вы можете использовать Clusternet (открытый проект CNCF) чтобы управлять всеми Kubernetes-кластерами из одного хост-кластера.

Clusternet умеет работать с:

- обычными Kubernetes-кластерами
- managed-кластерами
- on-prem кластерами
- edge-кластерами

В хост-кластере вы поднимаете hub и регистрируете кластеры, которыми хотите управлять, как дочерние.

После регистрации вы можете использовать API-сервер хост-кластера, чтобы деплоить приложения и выполнять операции во всех этих кластерах.

GitHub: clusternet

👉 DevOps Portal

Kubeshark обеспечивает глубокую видимость и мониторинг всего API-трафика и payload'ов, проходящих внутрь, наружу и между контейнерами и подами внутри кластера Kubernetes

Забираем здесь

👉 DevOps Portal

Большинство обсуждений Docker в итоге приходят к одному вопросу: использовать slim или alpine, какой базовый образ выбрать?

Alpine очень маленький и выглядит привлекательно, если нужно максимально ужать размер образа.
Но он использует musl вместо glibc, поэтому некоторые приложения ведут себя иначе, некоторые библиотеки работают не так, как ожидается, и отладка может быть болезненной.

Отлично подходит для простых статических бинарников, которые почти не завязаны на зависимости уровня ОС.

Slim-образы (например, debian:slim или node:22-slim) больше, чем Alpine, но всё ещё значительно меньше полноразмерных дистрибутивов. Они используют glibc, поэтому большинство инструментов и библиотек просто работают.

Это обычно означает меньше сюрпризов в проде, проще отладку и лучшую совместимость с существующей документацией и примерами.

Для большинства веб-приложений, API и инструментов slim — более безопасный выбор по умолчанию. Вы всё равно получаете меньшие образы, быстрые pull’ы и нормальную безопасность, но без борьбы с странными edge-кейсами musl.

Alpine имеет смысл, когда вы:

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

👉 DevOps Portal

Быстрый совет по командам Linux

Скорее всего, вы не знали, но команда find позволяет быстро найти все исполняемые файлы в каталоге:

find . -type f -executable

👉 DevOps Portal

Одна простая привычка, которая делает Dockerfile гораздо проще в поддержке: это алфавитная сортировка многострочных списков пакетов.

Звучит мелочью, но это сильно влияет на читаемость и долгосрочную поддержку

Когда вы ставите пакеты внутри многострочного блока apt-get install или apk add, легко случайно добавить дубликаты или пропустить что-то, затерявшееся в середине списка.

Алфавитный порядок полностью убирает эту проблему: список можно быстро просканировать, моментально найти дубликаты и держать всё единообразным в разных окружениях.

Это также уменьшает «шумные» диффы в код-ревью

Когда пакеты отсортированы, добавление или удаление одного пункта даёт чистое и предсказуемое изменение.

Без сортировки маленькое обновление часто превращается в большой дифф, усложняя ревью больше, чем нужно.

Этот приём помогает и при росте команды.

Когда Dockerfile трогают несколько человек, никто не будет по-разному переставлять пакеты или использовать несогласованное форматирование.

Структура остаётся стабильной, и поддержка со временем становится проще.

Мелкое улучшение, но на сотнях билдов оно экономит массу нервов

👉 DevOps Portal

NGINX Gateway Fabric - это опенсорс проект, который реализует Gateway API, используя NGINX в качестве data plane.

Цель проекта: реализовать базовые возможности Gateway API.

GitHub: nginx-gateway-fabric

👉 DevOps Portal

Интересный симулятор DDoS-атак, чтобы понять, как работают такие атаки и почему защита критически важна.

http://devops-daily.com/games/ddos-simulator

👉 DevOps Portal

OpenTelemetry — это опенсорс стандарт для сбора трассировок, метрик и логов в современных приложениях

Вместо того чтобы каждый язык, фреймворк или библиотека предоставляли собственный способ генерации телеметрии, OpenTelemetry предлагает единый и консистентный подход.

С его API и SDK вы один раз инструментируете свой код и отправляете данные в любой backend по вашему выбору — Grafana, Datadog, New Relic, Prometheus или любой другой. Это означает, что вы не привязаны к какому-то одному вендору и не зависите от конкретного агента.

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

Цель проста: сделать наблюдаемость проще, переносимой и последовательной, чтобы командытратили меньше времени на «склейку» инфраструктуры и больше - на понимание своих систем.

👉 DevOps Portal

💡 Совет дня по Linux

Не нравится бесконечно длинный вывод в команде top?

Используйте опцию -i, чтобы скрыть неактивные процессы и видеть только активные:

$ top -i

👉 DevOps Portal

Запутались в том, чем отличаются Dockerfile и Docker Compose? Это для вас.

Хотя они дополняют друг друга, их назначения в контейнерной среде разные.

- Dockerfile: используется для создания и сборки Docker-образов.

- Docker Compose: используется для запуска Docker-контейнеров в составе мультиконтейнерного окружения или с определёнными параметрами рантайма.

Примечание: начиная с версии 1.28.6, Docker Compose по умолчанию использует файлы compose.yaml или compose.yml, сохраняя обратную совместимость с docker-compose.yaml/yml. Если присутствуют оба варианта, предпочтение отдаётся compose.yaml.

Вот простая иллюстрация, чтобы помочь вам лучше разобраться

👉 DevOps Portal

💡 Быстрый совет по Ansible

Долгий запуск команды приводит к тайм-ауту?

Используйте настройку ansible_command_timeout

Она задает максимальное время (в секундах), в течение которого Ansible будет ждать завершения команды

👉 DevOps Portal

Практические DevOps/Cloud-проекты для обучения: от новичка до продвинутого уровня

GitHub: DevOps-Projects

👉 DevOps Portal

Многие новички сразу бросаются в Kubernetes, Terraform или CI/CD-пайплайны, потому что это выглядит интересно. Но у DevOps есть фундамент, и если его пропустить, дальше будет только сложнее.

Прежде чем трогать Kubernetes, есть несколько базовых навыков, которые должен прокачать каждый инженер.

Начните с Linux. Почти все инструменты, которые вы используете в DevOps, работают на Linux. Вам нужно уверенно разбираться в файловых правах, процессах, сервисах, логах и работе в командной строке. Если вы не можете свободно ориентироваться на Linux-сервере, управление кластерами быстро превращается в хаос.

Тщательно разберитесь с Git. Ветвление, слияние, ребейзы, ревью изменений – это ежедневные задачи в DevOps. Хорошие практики работы с системой контроля версий сильно упрощают совместную работу и автоматизацию.

Освойте Bash-скриптинг. Большая часть автоматизации начинается с простых скриптов. Умение писать, отлаживать и комбинировать команды помогает понимать, как работают CI/CD-пайплайны и облачная автоматизация под капотом.

Разберитесь в основах сетей. IP-адреса, порты, DNS, подсети, маршруты, балансировщики - в облаке ничего не работает без сети. Если вы понимаете, как движется трафик, всё остальное в DevOps становится куда проще.

Когда эти фундаментальные вещи у вас на хорошем уровне, такие инструменты, как Docker, Kubernetes, Terraform или AWS, начинают быть по-настоящему понятны.

Пропуская базу, вы только тормозите себя в будущем; изучая её заранее, вы облегчаете всё, что дальше.

👉 DevOps Portal

Atlas - опенсорс инструмент, предназначенный для анализа сети, визуализации и мониторинга Docker-контейнеров

Будет полезно тем кто хочет хоть как-то понять что твориться с Docker контейнерами у них в сети.

Демку можно посмотреть тут.

👉 DevOps Portal

Изучаете, как вручную размещать Pod'ы в Kubernetes?

На платформе iximiuz Labs доступно задание, которое охватывает node selectors, правила affinity и taints.

Полезно, когда вам нужно контролировать размещение Pod'ов, например, для запуска рабочих нагрузок на узлах с GPU, изоляции сред или распределения трафика.

Если вы хотите освоить эти техники, это задание - отличный способ попрактиковаться.

Попробуйте здесь

👉 DevOps Portal