DigitalOcean Community собирает подробные руководства по Linux!

В разделе Linux Basics есть материалы про командную строку, права доступа, пользователей, процессы, сеть и администрирование сервера. Пошаговые статьи дают команды, поясняют результат и помогают пройти тему от основы до конкретной настройки.

Оставляю ссылочку на DigitalOcean Community

➡️ DevOps Ready | #ресурс

Изоляция процессов в Linux через Unshare без Docker и тяжелых утилит.

Мы научимся использовать системный вызов unshare для создания изолированного пространства имен (namespaces), что является фундаментом контейнеризации в Linux. Это позволяет запустить процесс с собственной таблицей хостов или файловой системой, не влияя на основную ОС. Техника незаменима для безопасного тестирования скриптов и понимания того, как работают Docker и Podman изнутри.

Сначала создадим изолированную среду с собственной сетевой петлей и новым пространством имен для имени хоста:

sudo unshare --fork --uts --net bash

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

Внутри новой оболочки зададим уникальное имя хоста, чтобы убедиться в полной изоляции UTS namespace:

hostname sandbox-env && hostname

Имя хоста изменится только для этой сессии, в то время как основная система сохранит прежнее название.

Для полной демонстрации сетевой изоляции попробуем поднять интерфейс, который будет существовать только в этом пространстве:

ip link set lo up && ip addr show lo

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

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

hostname

Ожидаемый вывод: ваше старое имя хоста (подтверждает, что изоляция работает).

Использование namespaces напрямую через unshare — это мощный способ отладки и запуска недоверенных приложений с минимальным оверхедом.
Помните, что для некоторых флагов изоляции (например, монтирования) требуются права суперпользователя или настройка User Namespaces.

➡️ DevOps Ready | #практика

📂 Напоминалка по единообразию Dockerfile в команде!

Единые правила помогают сократить количество ошибок, упростить ревью и сделать сборку сервисов предсказуемой. На картинке 7 шагов: от определения базовых стандартов и общего шаблона Dockerfile до автоматических проверок в CI, использования общих образов, обучения команды и регулярного улучшения процесса. Такой подход помогает быстрее подключать новые проекты и поддерживать одинаковые практики во всей команде.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Знали, почему jq без -e может пропустить неготовый сервис?

Допустим, проверка здоровья возвращает JSON с признаком готовности:

{"ready": false}

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

jq '.ready' health.json
echo "$?"

jq напечатает false, но сама команда успешно обработала JSON и завершится с кодом 0. Если использовать её напрямую в if, скрипт ошибочно пойдёт по ветке успеха.

Для проверки результата добавьте -e:

jq -e '.ready' health.json >/dev/null
echo "$?"

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

if jq -e '.ready == true' health.json >/dev/null; then
    echo "service is ready"
else
    echo "service is not ready" >&2
    exit 1
fi

Если поле отсутствует, выражение тоже вернёт false. А если JSON сломан, jq завершится с ошибкой разбора, и скрипт не примет его за успешный ответ.

➡️ DevOps Ready | #совет

Шпаргалка по устройству GitHub Actions!

На картинке показано, как событие в репозитории запускает workflow, тот создаёт отдельные jobs, а внутри каждой job последовательно выполняются steps. Схема помогает не путать этапы автоматизации между собой.

Например, push может запустить workflow с независимыми проверками и сборкой. Если деплой должен дождаться тестов, зависимость задают между jobs, а команды внутри одной job записывают как steps.

Сохрани, чтобы не потерять!

➡️ DevOps Ready | #ресурс

Проверяем срок действия TLS-сертификата до аварии!

Сайт может отвечать нормально сегодня, а через неделю начать показывать ошибку сертификата. Проверять только факт ответа по HTTPS недостаточно, нужен контроль срока действия того сертификата, который сервер отдаёт клиенту.

Подключимся к домену через openssl s_client. Параметр servername передаёт SNI, чтобы на сервере с несколькими сайтами получить нужный сертификат:

echo | openssl s_client -connect example.com:443 \
  -servername example.com 2>/dev/null

В полном выводе много технических деталей. Передадим сертификат следующей команде и покажем дату окончания:

echo | openssl s_client -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

Для мониторинга удобнее не разбирать дату текстом. Ключ -checkend принимает число секунд и возвращает ненулевой код, если сертификат истечёт в пределах заданного периода. Тридцать дней составляют 2592000 секунд:

echo | openssl s_client -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -checkend 2592000

Проверку можно запускать по расписанию и отправлять уведомление при ненулевом коде:

set -o pipefail
echo | openssl s_client -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -checkend 2592000

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

➡️ DevOps Ready | #практика

Знали, как заметить конфликтные маркеры и ошибки с пробелами до коммита?

Иногда после разрешения конфликта в файле случайно остаются строки <<<<<<< или =======. В другой раз изменение добавляет пробелы в конце строк или смешивает пробелы с табами в отступах. Код может выглядеть почти нормально, но такая мелочь ломает конфигурацию или мешает сборке.

Сначала посмотрите, какие правки ещё не добавлены в индекс:

git diff --check

Если Git найдёт проблемную строку, команда покажет путь и номер строки и завершится с ненулевым кодом. По умолчанию она проверяет изменения в рабочей папке относительно индекса, а не весь репозиторий.

Перед коммитом важнее проверить именно то, что уже подготовлено к записи. После git add запустите:

git diff --cached --check

Так можно поймать ошибку в staged-части даже тогда, когда в рабочем файле вы её уже исправили, но забыли добавить исправление в индекс. И наоборот, обычный git diff --check не заменяет проверку staged-изменений.

Проверку легко встроить в CI для предлагаемой ветки. Сравните её с базовой веткой через две точки, предварительно получив актуальную ветку origin/main:

git fetch origin main
git diff --check origin/main..HEAD

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

➡️ DevOps Ready | #совет

Trivy помогает проверять образы и инфраструктуру на проблемы безопасности!

Это open-source сканер, который ищет известные уязвимости, ошибки конфигурации и секреты. Он работает с контейнерными образами, файловыми системами, репозиториями и Kubernetes, а ещё умеет формировать список компонентов проекта в формате SBOM.

Оставляю ссылочку на GitHub

➡️ DevOps Ready | #репозиторий

🗂 Пакет Безопасности — папка, которую админ собирал более 10 лет

⚡️ Слитые курсы по IT и ИБ
⚡️ Сервисы и тулзы для приватности
⚡️ Инструкции и шпаргалки
⚡️ Редкие книги и утилиты
⚡️ Гайды написанные автором

Большинство собирает такую базу годами.
Здесь все отсортировали и разбили в одном канале
(первое сообщение в закрепе)

ссылка действует 48 часов

📌Подписывайся: @package_security

📂 Напоминалка по архитектуре минимального, но рабочего CI/CD-пайплайна!

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

На этой схеме — пошаговый гайд о том, как спроектировать лаконичный и стабильный CI/CD-пайплайн для одного микросервиса, который закроет 80% потребностей команды и не будет перегружен лишней логикой.

Сохрани в закладки, чтобы использовать как готовый шаблон для своих проектов!

➡️ DevOps Ready | #ресурс

Знали, почему docker compose restart не применяет изменения из compose.yaml?

Команда restart запускает тот же контейнер с теми же настройками. Она полезна, когда процесс внутри завис или завершился, но не применяет новую конфигурацию сервиса.

Например, после изменения переменной окружения restart оставит старое значение:

docker compose restart api

Переменные окружения контейнера задаются при его создании. Поэтому после правки compose.yaml сервис нужно обновить через up:

docker compose up -d api

Compose сверит описание сервиса с существующим контейнером и применит изменённые параметры. Данные в именованных volumes при этом сохраняются.

Если менялся код, включённый в Docker-образ, добавь сборку:

docker compose up -d --build api

Флаг --build пересобирает образ перед запуском контейнера. Если используется образ из registry, сначала скачай его:

docker compose pull api

Затем запусти сервис на новой версии образа:

docker compose up -d --no-deps api

Флаг --no-deps не трогает зависимые сервисы, поэтому используй его только если они уже запущены и не требуют обновления.

До деплоя проверь, какую конфигурацию Compose получил после объединения файлов и подстановки переменных:

docker compose config

В выводе могут оказаться подставленные значения переменных, поэтому не публикуй его без проверки на секреты. Пересоздание может прервать соединения, так что в production учитывай health checks и порядок обновления зависимых сервисов.

➡️ DevOps Ready | #совет