Когда-нибудь хотелось просто «запрыгнуть» в работающий Docker-контейнер?

Именно для этого и существует docker exec

Нужно отладить что-то или посмотреть логи?

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

На фото краткая шпаргалка, которая точно пригодится

👉 DevOps Portal

Утилита для мониторинга передачи данных

Недавно я занимался миграцией веб-сайта, в рамках которой нужно было вручную перенести данные из SQL-файла на ноутбуке в новую базу данных MySQL (RDS). Размер файла составлял примерно 450 МБ.

Мне нужно было отслеживать прогресс импорта, и я узнал об утилите Pipe Viewer (pv).

Pipe Viewer, или просто pv, — это инструмент командной строки, позволяющий отслеживать прогресс передачи данных.

Вот команду, которую я использовал:

pv backup.sql | mysql -h rds.amazonaws.com -u bibinwilson -p my_db

Пример вывода:

80.0MiB 0:08:36 [ 158KiB/s]
[==================================>] 100%

Утилиту можно встроить в любой стандартный конвейер (pipeline) между двумя процессами, чтобы наглядно отображать скорость передачи данных, затраченное время, степень завершённости и примерное оставшееся время до окончания операции.

Возможности:

🔹Визуальный индикатор прогресса
🔹Оценка оставшегося времени
🔹Задержка

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

Инструмент: https://ivarch.com/programs/pv.shtml

👉 DevOps Portal

Если вы инженер DevOps и ещё не слышали о метриках DORA — пора это исправить.

DORA расшифровывается как DevOps Research and Assessment (исследование и оценка практик DevOps).

Эта команда стоит за отчётом State of DevOps — ключевым источником информации о том, что действительно отличает высокоэффективные инженерные команды.

Но как метрики DORA применяются в реальных командах?

Вот как их можно отслеживать и даже создавать дашборды для визуализации:

🔹Частота деплоев (Deployment Frequency):
Отслеживайте количество деплоев через вашу CI/CD-платформу (GitHub Actions, GitLab, Jenkins и т.д.). Отправляйте данные о деплоях в систему метрик, такую как Prometheus, Datadog или даже Google Sheets через webhook.

🔹Время выполнения изменений (Lead Time for Changes):
Используйте временные метки Git-коммитов и событий деплоя в прод. Интегрируйте инструменты вроде Jira с GitHub или GitLab. Данные можно визуализировать в Grafana или Looker.

🔹Процент неудачных изменений (Change Failure Rate):
Интегрируйте инструменты управления инцидентами (PagerDuty, Opsgenie и т.д.) с логами деплоя. Коррелируйте инциденты с последними релизами. Это можно отслеживать в Grafana, Datadog или даже в Excel (для небольших команд).

🔹Время восстановления сервиса (Time to Restore Service):
Используйте системы алёртов, такие как Prometheus Alertmanager, Splunk или New Relic. Измеряйте время от срабатывания алёрта до полного устранения инцидента. Визуализируйте тренды на дашборде для контроля MTTR (среднего времени восстановления).

🔹Надёжность (Reliability):
Определите SLO (например, аптайм 99.9%) и отслеживайте их с помощью мониторинга SLI/SLO в Prometheus, Datadog или Nobl9. Визуализируйте бюджеты ошибок и аптайм во времени.

Инструменты вроде Grafana, Looker, Power BI или Tableau отлично подходят для создания кастомных дашбордов.

Не обязательно внедрять всё сразу.

Выберите одну метрику. Постройте простой дашборд. И постепенно улучшайте подход.

👉 DevOps Portal

Освойте деплойменты в Kubernetes

Нашел практическое задание, которое поможет разобраться, как работают Deployment'ы — от их создания до масштабирования, обновления образов, проверки состояния Pod'ов и отката изменений.

Отлично подходит для практики реальных операций, стоящих за kubectl apply/create и kubectl rollout.

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

👉 DevOps Portal

Kubernetes 1.33 (кодовое имя Octarine) был выпущен чуть более двух недель назад

В релиз вошли 64 улучшения (!!), поэтому полезно иметь краткий и наглядный обзор.

Визуальный разбор Kubernetes 1.33:
https://dev.to/aurelievache/understanding-kubernetes-part-55-kubernetes-133-changelog-1k5l

Подробности о релизе доступны в официальных примечаниях к релизу Kubernetes 1.33 и релиз-нотах GKE 1.33.

👉 DevOps Portal

Паттерны проброса портов в Kubernetes

Вы находитесь внутри dev-кластера, доступ к сети ограничен, и только что задеплоенный сервис ведёт себя некорректно.

Нет ни LoadBalancer'а, ни ingress-контроллера, а открыть порт — не вариант, потому что сетевая команда либо медлит, либо отказывает.

В этом случае вас выручает kubectl port-forward.

Здесь представлена упрощённая схема для наглядного понимания.

👉 DevOps Portal

Совет дня по Linux

Большинство людей используют echo для вывода информации

Но в многих случаях его также можно использовать, чтобы избежать ошибок

echo позволяет развернуть подстановочные знаки и понять, что произойдёт, ещё до выполнения команды.

👉 DevOps Portal

Почему ["npm", "start"] — плохой выбор для инструкции CMD в Dockerfile 👇

Несмотря на то, что эта команда используется почти в каждом Dockerfile, включая некоторые «рекомендованные» Dockerfile, сгенерированные такими инструментами, как create-react-app, использование ["npm", "start"] в CMD приводит к появлению лишней оболочки в дереве процессов контейнера. Это, в частности, может вызывать проблемы с распространением сигналов (signal propagation), что, в свою очередь, нарушает корректное завершение работы контейнеризированного приложения.

Я нашел практическое задание, иллюстрирующее эту проблему:
https://labs.iximiuz.com/challenges/graceful-termination-for-nodejs-container

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

👉 DevOps Portal

Удалённый доступ к Docker-демону с другой машины

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

Чтобы это стало возможным, вы можете открыть Docker-демон по протоколу TCP, обновив файл daemon.json на сервере

👉 DevOps Portal

Совет по Linux для DevOps-инженеров

Как получить публичный IP-адрес сервера с помощью команды?

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

Для AWS и GCP всегда используйте соответствующий сервис метаданных для получения публичного IP-адреса.

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

👉 DevOps Portal

Что такое трансляция сетевых адресов (NAT)?

👉 DevOps Portal

Объяснение Сетевого Взаимодействия в Kubernetes (eng)

Узнайте, как работает сетевая модель Kubernetes (K8s) с использованием Pod'ов, CNI-плагинов и Service'ов. Изучите взаимодействие между Pod'ами, IP-адресацию и сетевые политики. А также создайте свой первый Pod с нуля.

Смотреть на YouTube

👉 DevOps Portal

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

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

Вот несколько примеров

👉 DevOps Portal

Большинство пользователей Linux знакомы с командой cp для копирования файлов. Однако немногие знают о её встроенной поддержке версионности.

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

Понимание версионности в cp

Команда cp предлагает два ключевых параметра для поддержки версионности:

1. --backup: создаёт резервную копию файла назначения перед его перезаписью.

2. --suffix: задаёт пользовательский суффикс для резервной копии.

Простое резервное копирование

Чтобы создать простую резервную копию:

$ cp --backup=numbered /путь/к/исходному/файлу /путь/к/папке/назначения/

Эта команда создаёт резервную копию с суффиксом по умолчанию (~) и увеличивающимся номером (например, файл.~1~, файл.~2~ и т.д.).

Резервная копия с пользовательским суффиксом

Для более наглядных резервных копий:

$ cp --backup=numbered --suffix=.bak /путь/к/исходному/файлу /путь/к/папке/назначения/

Это создаёт резервные копии с суффиксом .bak и увеличивающимся номером (например, файл.bak.1, файл.bak.2 и т.д.).

Практический пример: резервное копирование конфигурации SSH

Предположим, вы часто обновляете файл конфигурации SSH (/etc/ssh/sshd_config) для управления правилами доступа. Вот как можно вести версионированные резервные копии:

1. Создание резервной копии с нумерацией:

$ cp --backup=numbered /etc/ssh/sshd_config /data/backup/

Это создаёт файлы вида sshd_config.~1~, sshd_config.~2~ и т.д.

2. Создание резервной копии с пользовательским суффиксом:

$ cp --backup=numbered --suffix=.bak /etc/ssh/sshd_config /data/backup/

Это создаёт файлы вида sshd_config.bak.1, sshd_config.bak.2 и т.д.

Преимущества

🔹Сохраняется история изменений файлов

🔹Предотвращается случайная перезапись важных данных

🔹Предлагается простая система версионности без необходимости использовать сложные системы контроля версий

👉 DevOps Portal

Двухминутная настройка. Повышение производительности Kubernetes.

Добавление параметров externalTrafficPolicy: Local и sessionAffinity: ClientIP улучшает производительность за счёт снижения задержек и обеспечения привязки клиентских сессий к одному и тому же pod’у.

Внимание: это может увеличить нагрузку на отдельные узлы, но взамен повышается отклик и сохраняется сессия, что критично для пользовательского опыта в высоконагруженных приложениях.

👉 DevOps Portal

Docker vs Podman – Знай различия

🔹 Docker = требует демон

🔹 Podman = без демона и без root-доступа

Оба запускают контейнеры, но Podman обходится без фонового сервиса и хорошо интегрируется с systemd.

Те же команды, больше безопасности.

Заметка: Docker тоже может запускать контейнеры без root-доступа, но для этого требуется дополнительная настройка и конфигурация.

👉 DevOps Portal

Шпаргалка по Netcat

Netcat (nc) — это мощный инструмент для работы с TCP/UDP: от диагностики до передачи файлов и обратных шеллов

👉 DevOps Portal

Основные команды kubectl для отладки в Kubernetes

kubectl get events --field-selector type=Warning --all-namespaces
Выводит предупреждения по всему кластеру, например, ошибки при выделении IP-адресов подам.

kubectl get nodes -o wide --label-columns http://topology.kubernetes.io/zone
Проверяет статус узлов и проблемы, связанные с конкретными зонами.

kubectl blame pod $POD
Отслеживает изменения манифеста пода и их источники.

kubectl lineage pod $POD
Показывает зависимости ресурса и его создателей.

kubectl get endpointslices -o wide
Сопоставляет сервисы с IP-адресами подов; если список пуст — проверь готовность подов и метки.

👉 DevOps Portal

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

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

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

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

Попробуйте здесь:
https://labs.iximiuz.com/challenges/kubernetes-pod-advanced-scheduling-3b631fdf

👉 DevOps Portal