Проверяем срок действия 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 | #совет