Почему Zsh такой крутой 😍

В стандартных шеллах вроде bash, чтобы поработать со строками, обычно приходится пайпить переменные в sed, basename и прочие утилиты. В Zsh эта логика встроена прямо в синтаксис расширения переменных.

Да, это ломает переносимость скриптов из-за несовместимости с POSIX. Но для интерактивной работы и личных конфигов это на порядок быстрее и удобнее.

Самый полезный модификатор? :r (root) — отрезает расширение файла.

Синтаксис такой: ${file:r}

Допустим, нужно передать имя файла (game.cpp) и чтобы итоговый бинарник назывался так же (game), не прописывая имя дважды.

Используем ${1:r}, чтобы автоматически убрать расширение из аргумента. Пример функции в Zsh:

function grun() {
  # $1 это "game.cpp"
  # ${1:r} станет "game"
  
  g++ -Wall -std=c++17 "$1" -o "${1:r}" && ./"${1:r}"
}

Запуск grun main.cpp скомпилирует и сразу запустит main – одним махом.

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

Ещё полезные модификаторы:

:e — получить только расширение

:a — получить абсолютный путь

:h — получить имя родительской директории

:t — получить basename

И да, снова: переносимость скриптов ограничена из-за несовместимости с POSIX.

👉 DevOps Portal

Как превратить init-container в sidecar-container?

В Kubernetes 1.28 появилась нативная поддержка sidecar-контейнеров через механизм init-containers.

Это стало возможным благодаря новому полю restartPolicy, которое устанавливается в значение "Always".

Фича основана на концепции "персистентного init-контейнера". Init-container стартует первым, а за счёт restartPolicy получает поведение sidecar-контейнера.

Такой контейнер работает на протяжении всего жизненного цикла Pod’а.

Проще говоря, чтобы превратить init-container в sidecar, достаточно добавить в его спецификацию атрибут:

restartPolicy: Always

Это опциональная настройка. Если restartPolicy не указан, контейнер будет работать как обычный init-container.

Нативный sidecar поддерживает поля livenessProbe, readinessProbe и startupProbe. Также можно добавить lifecycle-хуки PostStart и PreStop.

Чтобы подробнее разобраться в init-контейнерах и нативных sidecar-контейнерах, читайте статью:
https://devopscube.com/kubernetes-init-containers/

👉 DevOps Portal

Kide — это платформа наблюдаемости (observability), которая в реальном времени принимает и индексирует логи и метрики, позволяя вам искать, анализировать данные кластеров и приложений и настраивать алерты без ожидания.

GitHub: kide

👉 DevOps Portal

Как работает NAT?

Несколько устройств внутри сети используют приватные IP-адреса.
Маршрутизатор применяет NAT, чтобы сопоставить их с одним публичным IP-адресом в интернете.

Исходящий трафик → NAT подменяет приватный IP на публичный IP

Входящий ответ → NAT подменяет публичный IP обратно на приватный IP

👉 DevOps Portal

Можно ли защитить непреднамеренно открытый порт сервера с помощью файрвола?

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

Удачи: https://labs.iximiuz.com/challenges/linux-protect-ports

👉 DevOps Portal

Docker за 60 секунд

👉 DevOps Portal

Небольшое, но интересное упражнение по отладке Kubernetes — сможете ли вы отредактировать файл в уже запущенном pod’е?

Если задача кажется слишком простой, попробуйте пройти её:
https://labs.iximiuz.com/challenges/edit-file-in-running-kubernetes-pod

Почему-то этот челлендж помечен как «hard» 😉

👉 DevOps Portal

Прочитай это – и ты больше никогда не забудешь разницу между CMD и ENTRYPOINT в Docker.

Ответ:

🔹 ENTRYPOINT → Думай об этом как об основной команде, которая всегда выполняется при старте контейнера.
🔹 CMD → Это аргументы по умолчанию для этой команды (их можно переопределить при запуске контейнера).

Пример на картинке

➡️ Когда контейнер запускается → он выполняет ping http://google.com
➡️ Если переопределить CMD → docker run myimage http://yahoo.com
тогда выполнится ping http://yahoo.com

Запомни:

- ENTRYPOINT = что запускать
- CMD = с какими аргументами

👉 DevOps Portal

Как работает контейнерный нетворкинг 🧐

Docker, Podman и Kubernetes (через CRI) под капотом используют очень похожую схему – виртуальную bridge-сеть.

Собрать bridge-сеть с нуля, используя только базовые Linux-утилиты (ip, nsenter, iptables) – отличный способ разобраться в теме на практике:
https://labs.iximiuz.com/tutorials/container-networking-from-scratch

👉 DevOps Portal

SBOM становится критически важным для DevOps-команд, управляющих современными CI/CD пайплайнами

Вот почему его стоит внедрить каждой команде

Помните уязвимость Log4j? Тогда компании в спешке пытались определить, какие приложения оказались затронуты.

При наличии SBOM (Software Bill of Materials) этот процесс проходит значительно быстрее.

SBOM предоставляет полный инвентарь всех программных компонентов, входящих в состав приложения.

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

Традиционные файлы зависимостей, такие как pom.xml или package.json, дают лишь поверхностное представление о составе проекта.

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

Вот подробный гайд по SBOM:
https://newsletter.devopscube.com/p/sbom-what-why

👉 DevOps Portal

Поды не "падают" на ноды случайным образом. kube-scheduler оценивает каждое размещение с учётом доступных ресурсов, ограничений и политик.

В следующем уроке курса "Kubernetes the Very Hard Way" подробно разбирается, как kube-scheduler работает изнутри

https://labs.iximiuz.com/courses/kubernetes-the-very-hard-way-0cbfd997/control-plane/kube-scheduler

👉 DevOps Portal

В этой статье объясняется, как предотвратить сбои системы, вызванные несбалансированным масштабированием в Kubernetes, используя KEDA с корректной настройкой триггеров и стратегий автоскейлинга

Читайте тут

👉 DevOps Portal

Изучите Kubernetes и подготовьтесь к сдаче экзамена Certified Kubernetes Administrator (CKA)

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

https://youtu.be/l57xKN6OBhY?si=ye6hGpF2lezRyvgB

👉 DevOps Portal

Kubernetes за 60 секунд

👉 DevOps Portal

Вы когда-нибудь использовали curl для работы с Kubernetes API или смотрели, что именно сохраняется в etcd после выполнения kubectl apply?

Следующий урок в курсе «Kubernetes the Very Hard Way» разбирает, как kube-apiserver интегрируется в Kubernetes и как он работает под капотом:
https://labs.iximiuz.com/courses/kubernetes-the-very-hard-way-0cbfd997/control-plane/kube-apiserver#overview

👉 DevOps Portal

Быстрый совет по Linux

Во время редактирования файла в nano нажмите Ctrl + T, чтобы выполнить shell-команду, не выходя из редактора.

Nano выполнит команду и вставит её вывод в текущий файл – это удобно, когда нужно быстро добавить результат команды или сгенерированный текст прямо в процессе редактирования

👉 DevOps Portal

Одна из концепций Istio, которую стоит понимать: HBONE

HBONE расшифровывается как HTTP-Based Overlay Network Environment.

По сути, это механизм, с помощью которого Istio безопасно гоняет трафик внутри Kubernetes-кластера.

Вот что он делает:

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

До появления HBONE каждое соединение между workload’ами приводило к созданию отдельных соединений между их sidecar-прокси.

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

Как это работает?

HBONE объединяет три веб-стандарта:

• HTTP/2 — позволяет передавать несколько потоков в рамках одного TCP-соединения

• HTTP CONNECT — используется для построения туннеля поверх существующего соединения

• mTLS (mutual TLS) — шифрует туннель и обеспечивает взаимную аутентификацию сторон

Даже если вы напрямую не администрируете service mesh, как DevOps-инженеру вам важно понимать, как все эти компоненты состыкуются между собой.

Если вы работаете с service mesh, разберитесь в базовых принципах и понимайте, что именно происходит под капотом

Примечание: HBONE существует только внутри экосистемы Istio. Это не стандартный сетевой протокол, который можно встретить в спецификациях TCP/IP или HTTP

👉 DevOps Portal