Atuin

Это инструмент для улучшения истории командной строки, заменяющий стандартную историю оболочки.

Он сохраняет команды в зашифрованной базе данных, синхронизирует историю между устройствами и позволяет легко искать и фильтровать команды. Atuin поддерживает bash, zsh и fish, обеспечивая удобство работы с историей в терминале.

👉 https://github.com/atuinsh/atuin

👉 DevOps Portal

DevOps Roadmap 2025

Этот дорожный план поможет вам освоить ключевые навыки и технологии, необходимые для того, чтобы стать успешным инженером DevOps в 2025

👉 DevOps Portal

⚙️ Руководство по сетевому программированию в Linux — LinuxNetworkProgramming

Полный учебник, охватывающий всё:
✅ Основы сетевого программирования в Linux
✅ Работа с сокетами
✅ Создание HTTP/TCP-клиентов
✅ Использование неблокирующих сокетов
✅ Безопасная коммуникация с libcurl и OpenSSL

👉 GitHub: LinuxNetworkProgramming

👉 DevOps Portal

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

Команда ls — отличный инструмент командной строки для вывода списка файлов и каталогов в Linux.

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

$ lsd -lah

Если команда lsd не установлена в вашей системе по умолчанию, обратитесь к документации вашей системы для инструкций по установке.

👉 DevOps Portal

Введите в вашем терминале эту команду:

watch -d -n 1 sensors

Это отображает данные о температуре CPU, GPU, Wi-Fi, NVMe SSD и HDD в реальном времени.

Подробнее: https://cyberciti.biz/faq/howto-linux-get-sensors-information/

👉 DevOps Portal

Dockerfile: рекомендации и ошибки

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

🔹Последующие сборки не смогут повторно использовать кэш.
🔹Кэшированные файлы увеличат размер финального образа.

...но что если я скажу вам, что:

🔹Разные запуски команды docker build могут повторно использовать кэш менеджера пакетов.
🔹Кэшированные файлы не попадут в финальный образ.
🔹Кэш будет работать, даже если один из вышеуказанных слоев изменится.

И все, что для этого нужно, это использовать инструкцию RUN --mount=type=cache. Вот пример для сборки образа с Python 👆

👉 DevOps Portal

💻 Ошибки Kubernetes: подробный список (часть 1)

Ошибки Pod/контейнера

🔹CrashLoopBackOff

— Причина: Контейнер продолжает падать из-за ошибок в приложении.
— Первый шаг: Проверьте логи с помощью kubectl logs <pod> и отладьте приложение.

🔹ImagePullBackOff

— Причина: Kubernetes не может загрузить образ контейнера из реестра.
— Первый шаг: Проверьте название образа, учетные данные (если образ приватный) и убедитесь, что реестр доступен.

🔹ErrImagePull

— Причина: Kubernetes не удалось загрузить образ контейнера.
— Первый шаг: Убедитесь, что образ существует в реестре и его имя написано правильно.

🔹OOMKilled

— Причина: Контейнер превысил лимит памяти.
— Первый шаг: Увеличьте лимит памяти в спецификации pod или оптимизируйте приложение.

🔹ContainerCreating в течение длительного времени

— Причина: Проблемы с монтированием томов, образами или kubelet.
— Первый шаг: Проверьте привязки томов, статус образа и логи узла.

🔹Неудачная проверка Readiness/Liveness

— Причина: Пробы неправильно настроены или приложение не отвечает.
— Первый шаг: Проверьте настройки проб и убедитесь, что приложение готово.

Ошибки планирования Pod

🔹0/1 узлов доступны: 1 Недостаточно CPU

— Причина: Узлы кластера не имеют требуемых ресурсов CPU.
— Первый шаг: Масштабируйте кластер или отрегулируйте запросы ресурсов для pod.

🔹0/1 узлов доступны: Нет совпадений для селектора узла

— Причина: Селекторы узлов в спецификации pod не совпадают с метками узлов.
— Первый шаг: Обновите метки узлов или измените селектор узла в pod.

🔹0/1 узлов доступны: Правила Pod Affinity/Anti-affinity

— Причина: Правила размещения pod препятствуют планированию.
— Первый шаг: Проверьте и отрегулируйте правила affinity/anti-affinity в спецификации pod.

Ошибки с постоянным хранилищем

🔹VolumeMountConflict

— Причина: Несколько pod пытаются смонтировать том в режиме ReadWriteOnce.
— Первый шаг: Отрегулируйте режимы доступа к томам или конфигурацию хранилища.

🔹PersistentVolumeClaim в состоянии Pending

— Причина: Нет подходящего PersistentVolume.
—Первый шаг: Проверьте конфигурацию PV и убедитесь, что она соответствует требованиям PVC.

🔹Неудачное прикрепление тома

— Причина: Ошибка прикрепления тома к узлу.
— Первый шаг: Проверьте класс хранилища и логи облачного провайдера на наличие ошибок.

Ошибки RBAC и аутентификации

🔹Forbidden: Пользователь <user> не может просматривать ресурс <resource>

— Причина: У пользователя или сервисного аккаунта нет необходимых прав.
— Первый шаг: Создайте или обновите RoleBinding/ClusterRoleBinding.

🔹Unauthorized

— Причина: Неверный или просроченный kubeconfig.
— Первый шаг: Обновите токены, убедитесь в наличии правильных сертификатов или повторно войдите в кластер.

🔹Secret не найден

— Причина: Секрет, указанный в спецификации pod, не существует.
— Первый шаг: Создайте секрет или обновите pod, чтобы использовать существующий секрет.

Ошибки в управляющей плоскости и узлах рабочих

🔹etcdserver: запрос истек по времени

— Причина: Кластер etcd не работает должным образом или перегружен.
— Первый шаг: Проверьте логи и метрики etcd и убедитесь в правильном распределении ресурсов.

🔹Evicted

— Причина: Давление на ресурсы узла (например, недостаточно диска, памяти или CPU).
— Первый шаг: Освободите ресурсы или масштабируйте кластер.

🔹Узел испытывает давление на диск

— Причина: Недостаточно места на диске узла.
— Первый шаг: Очистите неиспользуемые образы или логи и мониторьте использование диска.

🔹Узел испытывает давление на память

— Причина: Слишком высокое использование памяти.
— Первый шаг: Определите процессы, потребляющие много памяти (top или htop), и оптимизируйте их или остановите. Рассмотрите возможность добавления памяти в узел.

🔹Узел испытывает давление по PID

— Причина: Достигнут максимальный лимит процессов (PIDs).
— Первый шаг: Увеличьте лимит PID в /etc/systemd/system.conf. Проверьте "блуждающие" процессы и оптимизируйте использование ресурсов.

(часть 2)

🔹NodeNotReady

— Причина: Узел имеет проблемы (например, истощение ресурсов, проблемы с сетью или сбой kubelet).
— Первый шаг: Проверьте логи kubelet на узле, убедитесь в его работоспособности и что он может подключиться к управляющей плоскости.

🔹Node Ready, NetworkUnavailable

— Причина: Сетевой плагин (CNI) не работает должным образом.
— Первый шаг: Проверьте логи плагина CNI (например, Calico, Flannel, Weave). Проверьте настройки сети и перезапустите pod плагина CNI.

🔹Не удается подключиться к серверу: x509: сертификат подписан неизвестным удостоверяющим центром

— Причина: Несоответствие сертификата сервера Kubernetes API и клиента.
— Первый шаг: Обновите файл ~/.kube/config или пересоздайте сертификат сервера API с действительным CA.

🔹Подключение к серверу <URL> отклонено

— Причина: Сервер API Kubernetes не работает или неправильно настроен.
— Первый шаг: Проверьте логи сервера API и убедитесь, что сервер работает на правильном порту.

Ошибки kubelet

🔹kubelet не работает должным образом

— Причина: Kubelet не может связаться с сервером API или неправильно настроен.
— Первый шаг: Проверьте логи kubelet (journalctl -u kubelet). Убедитесь, что конфигурация kubelet (/var/lib/kubelet/config.yaml) правильная.

🔹kubelet: не удалось запустить контейнер

— Причина: Проблемы с контейнерным окружением (например, Docker, containerd, CRI-O).
— Первый шаг: Проверьте логи контейнерного окружения (например, journalctl -u docker). Убедитесь, что окружение установлено и работает корректно.

🔹kubelet: не удалось смонтировать том

— Причина: Проблемы с постоянным томом или монтированием тома (например, хранилище недоступно, ошибка прав).
— Первый шаг: Проверьте, что хранилище доступно. Убедитесь в правильных правах доступа и настройках тома в спецификации pod.

🔹kubelet: узел не зарегистрирован

— Причина: Kubelet не может зарегистрировать узел в сервере API.
— Первый шаг: Проверьте логи kubelet и убедитесь, что токен kubeadm join действителен. Убедитесь, что узел может подключиться к управляющей плоскости по сети.

Ошибки контейнерного окружения

🔹ContainerRuntime не работает

— Причина: Контейнерное окружение (например, Docker, containerd) не работает или вышло из строя.
— Первый шаг: Перезапустите контейнерное окружение (systemctl restart docker или containerd). Проверьте логи на наличие ошибок.

🔹docker: не удалось загрузить образ

— Причина: Рабочий узел не может загрузить контейнерный образ из реестра.
— Первый шаг: Убедитесь, что у рабочего узла есть доступ в интернет (или к приватному реестру). Проверьте учетные данные для приватных образов.

Ошибки плагина CNI (сети)

🔹Pod застрял в ContainerCreating

— Причина: Pod не может подключиться к сети из-за проблемы с плагином CNI.
— Первый шаг: Проверьте логи плагина CNI в /var/log или с помощью kubectl logs. Убедитесь, что плагин CNI установлен и работает.

🔹Не удалось создать Pod SandBox

— Причина: Узел не смог создать пространство имен сети для pod.
— Первый шаг: Проверьте конфигурацию плагина CNI в /etc/cni/net.d/. Убедитесь, что выделение IP-адресов работает корректно.

🔹NetworkUnavailable

— Причина: Демон CNI (например, Calico, Flannel) не работает.
— Первый шаг: Перезапустите демоны CNI. Проверьте логи на наличие ошибок конкретного сетевого плагина.

👉 DevOps Portal

DevOps
MLOps
CloudOps
AlOps
DataOps
ITOps
RevOpS
FinOps
HROps
LegalOps
SysOps
BizOps
DevSecOps
ClickOps
LLMOps
ChatOps
NoOps

👉 DevOps Portal

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

Если вы хотите удалить пустые директории, команда find может упростить задачу:

$ find . -type d -empty -exec rmdir -v {} +

Опция -type d ищет директории, -empty выбирает пустые, а -exec rmdir {} выполняет команду rmdir, чтобы удалить их.

Команда rmdir гарантирует, что директория пуста, прежде чем удалить её.

Альтернативно, вы можете использовать эту команду для выполнения той же задачи:

$ find . -type d -empty -delete

👉 DevOps Portal

💻 Совет по устранению неполадок в Kubernetes: Устранение проблем с сетью.

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

Лично я предпочитаю использовать инструмент "Netshoot", основанный на Docker-образе. В нем есть большинство необходимых инструментов (ping, curl, dig, nmap, netcat и т. д.), и его можно запустить как временный под. Он будет работать, пока вы им пользуетесь, а как только вы выйдете из пода, тот сразу же будет удален.

Команда для его запуска:
❯ kubectl run tmp-shell --rm -i --tty --image nicolaka/netshoot --namespace=<namespace> -- /bin/bash

👉 DevOps Portal

Kubernetes 101: назначение Pod'ов на узлы

В статье подробно рассматриваются механизмы назначения Pod'ов на узлы в Kubernetes.

Автор объясняет такие инструменты, как nodeSelector, nodeAffinity и taints/tolerations, которые позволяют контролировать, где именно будут запускаться ваши Pod'ы

👉 Ссылка на статью

👉 DevOps Portal

Docker против Kubernetes: В чем разница?

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

— Docker

🔹 Платформа для контейнеризации.
🔹 Упаковывает приложения и зависимости в контейнеры.
🔹 Обеспечивает переносимость между средами.
🔹 Запускает контейнеры на одном хосте.
🔹 Используется в CI/CD-пайплайнах для автоматизации развёртывания.

— Kubernetes

🔹 Система оркестрации контейнеров.
🔹 Управляет контейнеризированными приложениями на большом масштабе.
🔹 Обрабатывает развёртывание, масштабирование и сетевые взаимодействия.
🔹 Распределяет рабочие нагрузки между несколькими узлами.
🔹 Оптимизирован для микросервисов и облачно-ориентированных приложений.

— Как они работают вместе

Docker создает и запускает контейнеры. Kubernetes оркестрирует и управляет ими в большом масштабе. Вместе они позволяют создавать масштабируемые и устойчивые облачные системы и DevOps-процессы.

— Нужны ли вам оба инструмента?

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

👉 DevOps Portal

Строим контейнерные образы как профи 😎

Множество ресурсов по созданию образов:
🔹5 учебных пособий по композиции образов, выбору базового образа, многоступенчатым сборкам и образам без дистрибутива.
🔹12 практических задач для создания и отладки образов.

Посмотреть здесь: https://labs.iximiuz.com/skill-paths/build-container-images

👉 DevOps Portal

Это репозиторий примеров из книги "Ansible for DevOps" Джеффа Гирлинга.

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

👉 https://github.com/geerlingguy/ansible-for-devops

👉 DevOps Portal

💡 Быстрый совет по Docker

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

Используйте команду:

docker system df

👉 DevOps Portal

Репозиторий с кучей полезных материалов и информации, связанных с DevOps

Содержит ресурсы по таким темам, как Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure и GC

👉 DevOps Portal

Структура манифеста развертывания Kubernetes: объяснение

В YAML-файле развертывания Kubernetes определяется, как приложение должно быть развернуто и управляться в кластере Kubernetes.

Ниже приведена структура YAML с пояснениями.

— Объяснение ключевых разделов

🔸apiVersion & kind: Определяет, что этот ресурс является развертыванием и использует API Kubernetes apps/v1.
🔸metadata: Содержит информацию, такую как имя и метки для организации приложения.
🔸spec.replicas: Определяет желаемое количество работающих экземпляров (Pod'ов).
🔸spec.selector.matchLabels: Гарантирует, что развертывание управляет только Pod'ами с соответствующими метками.
🔸spec.template:
- Определяет шаблон Pod'а (его metadata и spec).
- Раздел containers описывает контейнер, включая образ, порты и ресурсы.
- Можно также задать переменные среды, монтирование томов и лимиты ресурсов.
🔸spec.strategy: Управляет стратегией обновления развертывания (RollingUpdate или Recreate).
🔸volumes: Позволяет определить постоянное хранилище, такое как ConfigMaps, Secrets или Persistent Volumes.

— Дополнительные параметры
🔸Проверки работоспособности: Liveness & Readiness Probes
🔸Управление размещением: Affinity & Node Selectors
🔸Предварительная обработка: Init Containers

👉 DevOps Portal

💡 Совет по Linux

Получите контекст вашего поиска с помощью grep, используя параметр -C:

$ grep -C3 filename

Это покажет 3 строки до и после найденного совпадения.

Очень помогает при анализе логов 😎

👉 DevOps Portal

🖥 Основные компоненты Docker: объяснение

Docker решает проблему «у меня на машине работает» 😱

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

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

В основе Docker лежит несколько ключевых компонентов.

Разбираясь в них, вы получите прочную базу понимания. Давайте разберем их!

🔸Образы (Images)
Образы — это неизменяемые шаблоны, используемые для создания контейнеров. Они создаются с помощью инструкций в Dockerfile или загружаются из Docker-реестра, такого как Docker Hub.

🔸Контейнер (Container)
Контейнер — это запущенный экземпляр образа. Это легковесный, автономный пакет, содержащий все необходимое для работы приложения.

🔸Dockerfile
Файл, содержащий последовательность команд для создания образа Docker.

🔸Docker Engine
Docker Engine отвечает за запуск и управление контейнерами. Он состоит из демона Docker и CLI-инструмента, взаимодействующего с ним через REST API.

🔸Docker Daemon
Фоновый сервис, управляющий объектами Docker. Он обрабатывает API-запросы и управляет образами, контейнерами, сетями и томами хранения.

🔸Docker Registry
Репозитории для хранения и распространения образов Docker. Реестры могут быть публичными или частными. По умолчанию Docker использует публичный реестр Docker Hub.

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

🔸Тома (Volumes)
Тома позволяют сохранять данные вне контейнера и делиться ими между контейнерными инстансами, даже после удаления контейнера. Они обеспечивают независимость данных от жизненного цикла контейнера.

Все эти компоненты взаимосвязаны, создавая удобную систему для автоматизации развертывания, масштабирования и управления приложениями. Благодаря этому Docker стал мощным и важным инструментом в современной разработке программного обеспечения.

👉 DevOps Portal

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

Когда вы запускаете программу в терминале или по SSH, она завершится сразу после закрытия сессии терминала (когда вы выйдете из него) или при разрыве соединения.

Чтобы избежать этого и сохранить выполнение программы и всех её процессов, используйте команду nohup (сокращение от no hangup – «без зависания»). Она игнорирует все сигналы разрыва соединения, позволяя процессу продолжать работу даже при закрытии терминала.

Например, чтобы сжать большой объем данных с помощью команды tar и гарантировать, что процесс не прервётся при случайном закрытии терминального окна, выполните команду:

$ nohup tar -cf archive.tar file1 file2

Также nohup создаёт файл nohup.out, в который записывает вывод команды:

$ cat nohup.out

Альтернативно, можно использовать tmux, disown или screen.

👉 DevOps Portal