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

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

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

👉 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

Вопросы для собеседования DevOps

Нашёл годный ресурс с вопросами и ответами по ключевым темам:

🔹Core DevOps Concepts
🔹K8s
🔹CI/CD
🔹Мониторинг и логгирование
🔹SRE и куча других

Из минусов — вопросов пока маловато и местами поверхностно. Но как стартовый чеклист или разминка перед интервью — пойдет

https://interview.devopscommunity.in/

👉 DevOps Portal

Реверс-инжиниринг Docker-образа

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

Неудивительно, что сами эти утилиты — это тоже Docker-образы. Так что без лишних движений — запускай одну из команд ниже, и получишь восстановленную версию Dockerfile:

sudo docker run -v /var/run/docker.sock:/var/run/docker.sock --rm dduvnjak/dockerfile-from-image $IMAGE_ID
sudo docker run -v /var/run/docker.sock:/var/run/docker.sock --rm laniksj/dfimage $IMAGE_ID
sudo docker run -v /var/run/docker.sock:/var/run/docker.sock --rm mrhavens/dedockify $IMAGE_ID

Где $IMAGE_ID — это ID нужного тебе образа, Dockerfile которого вы хотите восстановить

После выполнения получишь дамп с примерным содержимым Dockerfile. Все три утилиты (dockerfile-from-image, dfimage, dedockify) работают схожим образом: они анализируют слои, которые появились во время сборки. Каждая инструкция из Dockerfile потенциально создаёт слой (но не всегда). Единственное отличие в том, что первая написана на Ruby, а вторые две на Python.

Чтобы не возиться каждый раз с полной командой — можно завести алиас:

alias dedockify="sudo docker run -v /var/run/docker.sock:/var/run/docker.sock --rm mrhavens/dedockify"

И потом просто запускать:

dedockify $IMAGE_NAME

Ещё есть полезный инструмент — dive. Он позволяет посмотреть, что именно лежит в слоях Docker-образа. Можно запускать как через контейнер, так и через бинарь. Удобно, если нужно отладить, что именно пошло не так в сборке.

alias dive="sudo docker run -ti --rm  -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive"

Пример:

dive nginx:latest

Если хочешь прикрутить его в CI/CD пайплайн — просто добавь:

CI=true dive $IMAGE

👉 DevOps Portal

Принес годноту – Labex. Более 1000 интерактивных лабораторий и туториалов по DevOps, Linux, инфобезу, Python и многому другому

Всё работает прямо через браузер — никакой установки, просто открыл и погнал

Забираем абсолютно бесплатно здесь

👉 DevOps Portal

Конвейеры CI/CD для Kubernetes — 8 лучших практик и инструментов

Узнайте о лучших практиках и методах управления CI/CD-конвейерами с использованием Kubernetes. Эти стратегии помогут вам автоматизировать развёртывания напрямую в ваши продуктивные кластеры.

https://spacelift.io/blog/kubernetes-ci-cd

👉 DevOps Portal

Совет дня по Linux

Используйте расширение скобок с mkdir -p, чтобы создать несколько вложенных каталогов за один раз

Эта однострочная команда

$ mkdir -p projects/{frontend,backend}/{src,test,docs}

мгновенно создаст 6 каталогов

👉 DevOps Portal

Многообещающее начало отпуска

👉 DevOps Portal

Запустите собственный ИИ в стиле ChatGPT локально с помощью Docker Compose

Устали от ограничений по количеству запросов? Разверните self-hosted open-source LLM, такой как Ollama с Open WebUI, всего лишь с использованием Docker Compose.

👉 DevOps Portal

Все используют балансировщик нагрузки, но немногие понимают алгоритмы балансировки

Вот несколько популярных:

🔹Round Robin — распределяет входящие запросы по серверам по очереди в фиксированном циклическом порядке.

🔹IP Hash — использует хеш-функцию от IP-адреса клиента, чтобы стабильно направлять его на один и тот же сервер.

🔹Least Connections — перенаправляет новые запросы на сервер с наименьшим количеством активных соединений.

🔹Weighted Round Robin — распределяет запросы с учётом веса (веса или производительности) каждого сервера, передавая больше трафика более мощным узлам.

🔹Least Response Time — направляет запросы на сервер с наименьшей средней задержкой или временем отклика.

🔹Random — выбирает сервер случайным образом для каждого входящего запроса, без определённой логики или последовательности.

👉 DevOps Portal

Краткий совет по Linux

Вы можете вывести все возможные варианты автодополнения в терминал, нажав ESC + * после ввода начальных символов

👉 DevOps Portal

Пошаговое руководство по развертыванию кластера Kubernetes с использованием Kubeadm с одним мастер-узлом и двумя воркер-узлами

https://devopscube.com/setup-kubernetes-cluster-kubeadm/

👉 DevOps Portal