Запутались в том, чем отличаются 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

Веб-симулятор экзаменов по Kubernetes, который можно без труда развернуть локально. Он позволяет отработать прохождение экзаменов CKAD, CKA и CKS, а также предоставляет подсказки, тайм-трекер и автоматическую проверку результатов

GitHub: CK-X Simulator

👉 DevOps Portal

Полезная шпаргалка по различным Kubernetes специфичным логам

👉 DevOps Portal

Ограничение сетевого трафика с помощью eBPF

Ещё один отличный практический туториал от Теодора Подобника на iximiuz Labs. Узнайте, как реализовать базовый packet rate limiter с использованием eBPF/XDP, чтобы применять ограничения прямо в ядре

Читайте здесь

👉 DevOps Portal

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

GitHub: yardstick

👉 DevOps Portal

Годная CTF от WIZ – The Cloud Hunting Games CTF. Здесь вам нужно расследовать инцидент в облаке. Задания базируются на распространенных TTP злоумышленников in the wild.

Попробовать порешать можно тут

👉 DevOps Portal

Быстрая заметка по k8s

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

кстати, M – это Mbps, G – это Gbps

👉 DevOps Portal

В статье A Practical Approach to Keycloak Token Exchange: Converting External Tokens for Internal Use with Kubernetes and Istio рассматривается подход к настройке обмена токенами Keycloak в Kubernetes с помощью Istio.

Автор показывает как сконфигурировать CRD ресурс EnvoyFilter, в котором будет заложена Token Exchange Logic:

- Extract Authorization Header
- Make HTTP Call to Keycloak
- Inject Internal Token

👉 DevOps Portal

Не забудьте создать и использовать непривилегированного (non-root) пользователя в вашем Dockerfile.

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

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

Переход на non-root пользователя ограничивает доступ запущенного процесса, снижает потенциальный ущерб от любой эксплуатации и заставляет соблюдать более аккуратную гигиену с владением файлами и разрешениями

👉 DevOps Portal

Сегодня разбирается классическая задача распределённых систем: как надёжно стримить логи с нескольких реплик в хронологическом порядке?

Удивительно, но ни один из популярных контейнерных тулов этого не делает.

docker service logs, kubectl logs, stern, kubetail, k9s — все они просто перемешивают потоки по мере поступления. Стандартный костыль – прогонять вывод через | sort 🙃

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

Для новой команды uc logs используется следующий подход:

1. Low watermark

Трекать минимальный timestamp среди всех лог-стримов и безопасно печатать буферизированные логи с таймстампами ниже этой метки.

watermark = min(latest_timestamp for each stream)
sort and print all buffered logs where timestamp < watermark

2. Heartbeat-таймстампы

Что если контейнер замолчит? Весь поток залипнет, потому что watermark больше не будет сдвигаться.

Решение: периодически отправлять пустые heartbeat-записи с текущим timestamp от серверов. Это своего рода обещание: «У меня нет логов старше этого».

Это позволяет клиенту продвигать watermark сразу, не блокируя вывод. Интервал в 500 мс – 1 с работает хорошо на практике.

Что насчёт несинхронизированных часов?

Много тут не сделать, если не плодить лишнюю сложность. Просто детектируйте ситуацию, предупредите пользователя, и на этом всё.

👉 DevOps Portal