KubePug

Загружает сгенерированный файл data.json, содержащий информацию об устаревании API Kubernetes

Проверяет текущий кластер Kubernetes или входные файлы, проверяя, существуют ли объекты в этих устаревших версиях API, позволяя пользователю проверить перед переносом

Особенности

🔛 Может запускаться в кластере Kubernetes, используя kubeconfig или текущий кластер
🔛 Может выполняться с другим набором манифестов/файлов
🔛 Позволяет указать целевую версию Kubernetes, подлежащую проверке
🔛 Предоставляет заменяющий API, который следует использовать
🔛 Сообщает версии, что API устарел или удален, в зависимости от версии целевого кластера

Как использовать

Запустите kubectl krew install deprecations

Как использовать с Helm

Если хотите проверить сгенерированные манифесты с помощью Helm, можно запустить так:

helm template -f values.yaml .0 | kubepug --k8s-version v1.22.0 --input-file=-

Измените аргументы в kubepug (и шаблоне Helm) по своему желанию

👉 DevOps Portal

#Cобеседования

df сообщает о наличии 20 Гб занятого пространства, подсчёт занятого файлами места при помощи du даёт результат в 20 Мб. При каких обстоятельствах может возникнуть описанная ситуация?

Когда файл удален т. к. файловый дескриптор «держит» его.

Ищем файл через:

lsof -a +L1 | grep var | grep httpd

При удалении файла, который в этот момент был «занят» процессом — его имя удаляется, но inode — остаётся в файловой системе до тех пор, пока не завершится процесс, который «держит» этот файл.

Соответственно, что бы «освободить» уже удалённые файлы — необходимо перезапустить процесс, который этот файл держит.

👉 DevOps Portal

Popeye — утилита, которая сканирует работающие кластеры Kubernetes и сообщает о потенциальных проблемах с развёрнутыми ресурсами и конфигурациями.

👉 DevOps Portal

Полный рабочий процесс CI/CD с Skaffold для вашего приложения

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

🔛 Часть I
https://blog.equationlabs.io/cicd-workflow-with-skaffold-for-your-application-part-i

🔛 Часть II
https://blog.equationlabs.io/how-to-build-a-cicd-workflow-with-skaffold-for-your-application-part-ii

🔛 Часть III
https://blog.equationlabs.io/how-to-build-a-cicd-workflow-with-skaffold-for-your-application-part-iii

👉 DevOps Portal

Лучшие практики работы с Docker

Никогда не запускайте контейнер от имени root.

Запуск от имени root внутри контейнера означает запуск от имени root на хосте Docker. Если злоумышленник получит доступ к вашему контейнеру, он получит все привилегии root и сможет совершать атаки на хост.

👉 DevOps Portal

Как узнать имя функции из самой функции

#!/bin/bash

deploy() {
  # здесь хотим получить "deploy"
}

Для получения имени функции из самой функции, можно воспользоваться переменной ${FUNCNAME[*]}.

Элемент с индексом 0 это имя любой выполняемой функции в данный момент.Элемент с самым большим индексом будет называться main.

deploy() {
    echo ${FUNCNAME[0]}
}

Выведет название функции: deploy

Переменная FUNCNAME существует только во время выполнения скрипта. Если самостоятельно задать переменную FUNCNAME, это ничего не даст и все равно выведется эталонное имя функции.

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

Например:

exp1() {
    echo ${FUNCNAME}
}

exp2() {
    echo ${FUNCNAME[*]}
}

Первая функция выведет: exp1, а вторая выведет весь массив функции: exp2 main.

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

В zsh это называется funcstack, это тот же массив всех функций скрипта.

deploy() {
   echo $funcstack[1]
}

Еще переменная FUNCNAME используется с BASH_LINENO и BASH_SOURCE, об этом можно почитать в официальной документации.

BASH_SOURCE - переменная, содержит путь к исходному файлу оболочки, полезна при отладке и анализе ошибок.

BASH_LINENO - переменная, содержит номер строки на которой произошла ошибка в текущем скрипте.

👉 DevOps Portal

В этом репозитории вы найдете Dockerfile для 13 языков программирования

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

➖ React
➖ NodeJS
➖ Python
➖ Golang
➖ Java Spring Boot
➖ Java Quarkus
➖ ASP.NET Core
➖ Ruby
➖ Rust
➖ PHP Laravel
➖ Dart
➖ R Studio
➖ Contact

👉 https://github.com/hoalongnatsu/Dockerfile

👉 DevOps Portal

Чем отличается команда rm от unlink?

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

Есть ошибочное мнение, что unlink предназначен для удаления лишь ссылок — команда вполне может удалять обычные файлы. А если углубиться, то весь процесс удаления в Linux, это удаление ссылок.

У unlink есть всего лишь два ключа запуска help и version. Очень ограниченный инструмент, но чем инструмент проще, тем проще его синтаксис.

# unlink /tmp/hardlink
# unlink /tmp/file

Софт очень молчаливый — после удаления, он промолчит и ничего не выведет на экран.

Команда unlink использует системную команду unlink, в то время как команда rm использует системный вызов unlinkat. Оба системных вызова практически одинаковы.

Unlink не умеет работать с wildcard и globbing шаблонами. Так же вы не сможете с помощью нее удалить каталог.

Запустим команду и пытаемся насильно удалить файл которого нет в каталоге:

rm -f test.txt

И получаем - НИЧЕГО. То есть rm -f не вернул ошибку, что файл отсутствует. А если сделать так:

unlink test.txt

получим ошибку:

unlink: cannot unlink 'test.txt': No such file or directory

То есть если нужно будет обработать результат выполнения команды rm -f, то будет непонятно, существовал ли вообще файл.

С unlink можно гибче обрабатывать эксепшены в скриптах. А еще при использовании команды unlink отсутствует проверка безопасности. Она удалит файл, защищенный от записи. Хотя современная версия rm теперь тоже так умеет.

Небольшой секрет: если нужно, чтобы файл никто не смог удалить, включая root:

chattr +i test.txt

chattr позволяет устанавливать и отключать атрибуты файлов, на уровне файловой системы не зависимо от стандартных (чтение, запись, выполнение).

Ключ i - сделает файл неизменяемым. Чтобы снять с файла этот аттрибут, в команде которая выше, замените знак «+» на «-».

👉 DevOps Portal

Если любишь унижения от железного друга, это просто must-have

Включаем "режим унижений". Суть его проста: ошибаешься с паролем при использовании sudo — система выдаёт порцию "тёплых слов" ❤️

Активируется добавлением в файл /etc/sudoers (либо в /etc/sudoers.d/fuck.conf) строчки:

Defaults insults

А после этого попробуй выполнить от пользователя:

sudo apt update

и ошибись с паролем. Получишь в ответ:

Take a stress pill and think things over.
You fucking stupid shit!
My mind is going. I can feel it.
Realy? Are you on drugs?

А если базовых оскорблений недостаточно, кастомизируй через:

Defaults  badpass_message="Ты там в порядке, вообще?"

А кто хочет пойти ещё дальше, может собрать свой bash-скрипт с выборкой «теплых слов» для рандомного вывода. Например:

#!/bin/bash

messages=("Неверный пароль! Твой мозг там как, цел?"
          "Еще раз и я в логах всё твоё позорище сохраню."
          "Ты серьезно? Ну хоть капслок проверь...")

echo "${messages[$RANDOM % ${#messages[@]}]}"

Режим точно не для слабонервных, но если вам не хватает эмоций в консоли — милости просим😈

👉 DevOps Portal

OpenCost — инструмент мониторинга затрат с открытым исходным кодом для Kubernetes

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

👉 https://github.com/opencost/opencost

👉 DevOps Portal

Пять GitHub проектов, которые помогут вам стать лучшим инженером DevOps

Давненько у нас не было топовых репозиториев. Исправляемся:

🔹 Active Directory Exploitation Cheat Sheet
Памятка по эксплуатации Active Directory.

🔹 k'exp - Kubernetes Explorer
Предназначен не для управления продом, а для изучения Kubernetes через визуализацию. Может отражать состояние вашего кластера в режиме реального времени. Есть возможности для разработки приложений, контроллеров и операторов.

🔹 Configu
Простой, универсальный стандарт для управления и совместной работы с конфигурациями ПО.

🔹 SadServers
Сервис для практики troubleshooting на Linux-серверах. Предоставляется полный доступ к серверу Linux через SSH. Нужно устранить поставленную проблему в течение ограниченного времени.

🔹DockerCheatSheet
Шпаргалка по Docker – от установки и запуска контейнера до работы в сети и безопасности.

👉 DevOps Portal

systemd: как писать юниты с элегантной перезагрузкой

Разработка системы с элегантным завершением работы может оказаться той ещё пляской с бубном. В идеальном мире каждый сервис управлялся бы юнитом systemd. ExecStart запускала бы процесс, обрабатывающий SIGTERM, а ExecStop оповещало бы процесс и осуществляло блокировку, которая бы корректно завершала процесс и его ресурсы.

Однако многие программы завершаются некорректно, а то и вовсе сбивают все настройки при закрытии. В этой статье мы рассмотрим поведение systemd при завершении работы и методы написания юнитов systemd для выборочной очистки (custom cleanup) перед закрытием.

👉 https://www.psdn.io/posts/systemd-shutdown-unit/

👉 DevOps Portal

Наткнулся на интересную штуковину — Linux Command Library

Это просто находка для всех, кто шарит за Linux

Огромная библиотека команд Linux, насчитывающая более 6000 страниц, причём всё раскидано по категориям, чтобы не путаться

И всё это работает офлайн, без интернета и трекинга.

Доступ как на сайте, так и в виде мобильного приложения, а исходный код можно найти на GitHub

👉 DevOps Portal

Автоматизируй всё с Ansible!

Ansible — это мощный инструмент, который упрощает управление конфигурацией, развертывание приложений и оркестрацию задач.

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

🔛https://agralrst.medium.com/automate-everything-with-ansible-aac7eb4d5cf9

👉 DevOps Portal

Что будете делать если у команды chmod убрали права на исполнение?

🔹 Используем утилиту setfacl. По умолчанию её может не быть в системе.

setfacl -m u::rwx,g::rx,o::x /usr/bin/chmod

🔹 Можно запустить утилиту chmod, передав её явно динамическому компоновщику. В контексте данной заметки считайте компоновщик интерпретатором для программы chmod. В разных дистрибутивах он может иметь разное название и расположение. Пример для Debian 11:

/usr/lib64/ld-linux-x86-64.so.2 /usr/bin/chmod +x /usr/bin/chmod**

🔹 Можно скопировать права с любого исполняемого файла и записать содержимое утилиты chmod в этот файл. Получается рабочая копия chmod. Создаём пустой файл с правами утилиты ls.

cp --attributes-only /usr/bin/ls ./new_chmod

Копируем содержимое утилиты chmod в созданный файл:

cat /usr/bin/chmod > ./new_chmod

Можно использовать:

/new_chmod +x /usr/bin/chmod

🔹 Почти то же самое что и предыдущий вариант только проще:

install -m 755 /usr/bin/chmod ./new_chmod

или так:

rsync --chmod=ugo+x /usr/bin/chmod ./new_chmod

🔹 Если умеете программировать, то, пример с Python:

python -c "import os;os.chmod('/usr/bin/chmod', 0755)"

👉 DevOps Portal

Визуализация процесса работы с Docker 👇

Давайте разберем основные термины с помощью аналогии:

🔹Dockerfile
— Представьте Dockerfile как рецепт или набор инструкций.

Вы начинаете с создания Dockerfile, который перечисляет все «ингредиенты» (программное обеспечение и конфигурации), необходимые для работы вашего приложения.

🔹Docker Image
— Используя Dockerfile как рецепт, вы «готовите» или «собираете» Docker Image.

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

🔹Docker Container
— После создания Docker Image вы можете «подать его на стол», создав Docker Container.

Контейнер — это как реальный работающий экземпляр вашего приложения. Его можно запускать, останавливать и даже клонировать по мере необходимости.

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

👉 DevOps Portal

Как скрыть процессы в Linux от других пользователей.

Если запустить pstree, ps, htop можно увидеть процессы не только свои, но также системные и пользовательские. В левой колонке будут имена пользователей.

Чтобы скрыть свои процессы от других пользователей, нужно перемонтировать /proc с опцией hidepid.

Работает только с пользователями, рут будет по-прежнему в курсе запущенных процессов

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

Параметры которые можно задать:

hidepid=0 - Включена по умолчанию, все видят всё, полный доступ к /proc/PID/.

hidepid=1 - Разрешает обращаться к информации только о своих процессов. Часть файлов в каталоге /proc/PID/ защищена.

hidepid=2 - Это тот же самый hidepid=1 + всё в /proc/PID будет невидимо для других пользователей.

Запускаем от рута:

mount -o remount,rw,nosuid,nodev,noexec,relatime,hidepid=2 /proc

Теперь снова запускаем от обычного пользователя htop и наблюдаем, что выборка процессов пропала, и осталось +- 2, bash и htop.

Естественно после ребута сервера, все это пропадет. Чтобы этого не произошло — монтируем /proc в fstab.

Вставляем в /etc/fstab

proc /proc proc defaults,nosuid, nodev, noexec,relatime,hidepid=2 0 0

Встречаются приложения которые могут отвалиться. Для этого нужно зафиксить маунт с опцией gid=VALUE.

Значением gid параметра может быть имя группы в системе, членам которой доступ к процессам будет разрешён. И затем маунтить /proc таким образом:

proc /proc proc defaults, hidepid=2, gid=devopsport 0 0

Добавляем пользователя от имени которого будет работать приложение/демон в эту группу и проверяем — если всё сделано верно, то приложение заработает как обычно.

👉 DevOps Portal

Walk — это инструмент на Go, который позволяет рекурсивно обходить директории и выполнять команды для каждого найденного файла или папки.

Ключевые особенности:
🔹 Простая команда для выполнения скриптов или операций над файлами.
🔹 Гибкость и высокая скорость работы.
🔹 Подходит для автоматизации задач, связанных с обработкой файлов.

👉 Репозиторий: https://github.com/antonmedv/walk

👉 DevOps Portal

👩‍💻 Основы сетевого взаимодействия Pod'ов

— Основы Pod Networking

🔹 Уникальный IP для каждого Pod: Каждый Pod получает уникальный IP-адрес, действующий во всем кластере.

🔹 Общая сеть для контейнеров Pod: Контейнеры внутри одного Pod'а делят одно сетевое пространство (например, виртуальная "сетевая комната"). Они общаются через localhost и используют общий IP и порты.

— Взаимодействие внутри кластера

🔹 Прямой трафик между Pod'ами:

1. Pod'ы могут общаться напрямую, даже если они находятся на разных узлах. Для этого не нужны прокси или NAT.

2. Исключение: Pod'ы на Windows, использующие host-сеть, не поддерживают это правило.

🔹 Node-агенты могут взаимодействовать с Pod'ами: Такие инструменты, как kubelet (агент узла), могут общаться со всеми Pod'ами на своем узле.

— Сервисы: стабильный доступ к Pod'ам

🔹 API Service: Предоставляет стабильный IP/имя хоста для группы Pod'ов (например, backend-серверов).

Пример: Frontend веб-приложения может подключаться к backend-сервису, не беспокоясь об изменении IP-адресов отдельных Pod'ов.

🔹 EndpointSlices: Kubernetes автоматически обновляет их для отслеживания активных Pod'ов, обслуживающих сервис.

— Маршрутизация трафика и прокси

🔹 Service Proxy: Направляет трафик к нужным Pod'ам.

— По умолчанию: kube-proxy (встроенный прокси Kubernetes).
— Альтернативы: Некоторые сетевые плагины заменяют kube-proxy своими прокси (например, Cilium).

— Внешний доступ к сервисам

🔹 Gateway API/Ingress:

1. Ingress: Устаревший способ предоставления внешнего доступа к сервисам (например, через HTTP-маршруты).

2. Gateway API: Современный и гибкий метод управления внешним трафиком (поддерживает сложную маршрутизацию и многокомандные настройки).

🔹 Тип LoadBalancer: Самый простой способ предоставить внешний доступ к сервису (работает с облачными провайдерами, такими как AWS или GCP).

— Сетевая безопасность (NetworkPolicy)

🔹 Контроль трафика: Определяет правила, например: "Только Pod'ы frontend могут взаимодействовать с Pod'ом базы данных."

🔹 Не всегда поддерживается: Зависит от сетевого плагина (например, Calico поддерживает NetworkPolicy, а простые плагины могут не поддерживать).

— Без ручной настройки сети

🔹 Автоматическое подключение: В отличие от старых систем (например, Docker links), Kubernetes автоматически управляет сетями.

🔹 Pod'ы как виртуальные машины: Подходите к Pod'ам как к отдельным серверам — не нужно вручную сопоставлять порты или управлять подключениями.

— Как Kubernetes реализует сети

🔹 Kubernetes задает правила: Указывает, что должно быть сделано (например, Pod'ы должны общаться напрямую).

🔹 Внешние инструменты выполняют работу:

1. Container Runtime Interface (CRI): Настраивает сетевые пространства Pod'ов (общие для контейнеров внутри Pod'а).
2. CNI-плагины: Управляют реальной сетью Pod'ов (например, Calico, Flannel).
3. Сервисные прокси: Обрабатывают маршрутизацию трафика (например, kube-proxy или прокси плагинов).

— Ключевые моменты для понимания

🔹Сеть Pod'ов vs. Host-сеть:

1. Сеть Pod'ов: Режим по умолчанию (Pod'ы получают уникальные IP).

2. Host-сеть: Pod'ы используют IP узла (редко используется, например, для инструментов мониторинга сети).

🔹 Устаревшие vs. современные инструменты:

1. Ранее требовалась ручная привязка портов (например, docker run -p 80:80).

2. Kubernetes автоматизирует этот процесс — ручная работа не требуется.

🔹 Примеры Gateway API:

1. Облачные: AWS Gateway API Controller, Google Cloud Gateway.

2. Универсальные: Istio, NGINX Gateway.

👉 DevOps Portal