🚀 Хороший образ, плохой образ

Docker — это не только про контейнеры, но и про грамотный подход к их созданию. Собрали советы, которые сделает ваши образы безопаснее, легче и быстрее.

1. Лейблы важны

Добавляйте метаданные LABEL maintainer="[email protected]" version="1.2.0", чтобы понимать: кто собрал образ, зачем он нужен и какой это релиз. Это упростит отладку и автоматизацию в CI/CD.

2. Сканируйте образы на уязвимости

Перед выкладкой прогоняйте образы через Trivy или Grype:

trivy image myapp:1.0.0

3. Запускайте контейнеры от непривилегированного пользователя

Не используйте root без необходимости.

RUN adduser --disabled-password appuser
USER appuser

4. Используйте .dockerignore

Не надо тащить в образ .git, тестовые файлы и кэш IDE.

.git
node_modules
*.log

5. Мультистейдж-сборка

Стройте, а потом очищайте.

FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

FROM alpine:3.18
COPY --from=builder /app/main .
CMD ["./main"]

6. Используйте конкретные версии образов

FROM python:3.11.4 лучше, чем FROM python:latest.
Это делает сборки предсказуемыми и исключает сюрпризы при апдейтах.

7. Следите за порядком слоёв

Сначала копируйте файлы, которые редко меняются (requirements.txt), а уже потом код.
Так кэширование будет работать эффективнее.

8. Используйте переменные окружения

Они упрощают деплой на разных средах:

ENV APP_ENV=production

9. Используйте официальные образы

Начинайте с доверенных источников — они безопаснее и поддерживаются сообществом.
Например:

FROM nginx:1.25-alpine

Профессиональный Docker — это не про магию, а про дисциплину.

🐸Библиотека devops'a

#буст

👍 Вышел KDE Linux Alpha

KDE объявила о выпуске альфа-версии своей Linux-среды, открывая доступ к экспериментальным функциям и обновлённому интерфейсу.

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

➡️ Анонс

🐸Библиотека devops'a

#свежак

🤩 Кто такие Unit-лид и Technical Owner

В условиях роста масштабов разработки и усложнения продуктов классическая иерархия вроде «тимлид + продакт-менеджер» теряет актуальность.

Появляются новые, более адаптированные к продукции роли — Unit-лид и Technical Owner. Эти специалисты проживают продукт, а не только выполняют задачи:

• Unit-лид отвечает за стратегию, бюджет и приоритизацию функционального блока, объединяя команду аналитиков, разработчиков и DevOps.

• Technical Owner — это мост между бизнес-сторонами и техниками, который встраивает технические детали в оперативный бэклог и защищает архитектуру от хаоса.

➡️ Подробнее про них в статье

🐸Библиотека devops'a

📌 Команда для проверки порта

Вы запускаете сервис, а терминал отвечает, что адрес уже занят.

Эта команда покажет, какой процесс слушает нужный порт:

lsof -i :8080

В ответ вы увидите PID процесса и имя бинаря, который держит порт.

🐸Библиотека devops'a

#буст

🔒 4 преимущества гибридной миграции

Booking поделились опытом гибридной миграции в облако, подчеркнув четыре ключевых выигрыша в безопасности:

• Централизованное управление секретами — все креденшалы, токены и ключи хранятся безопасно и управляются единым инструментом.

• Повышенный контроль доступа — точные политики и роли для пользователей и сервисов уменьшают риск несанкционированного доступа.

• Автоматизация и аудит — процессы деплоя и изменения инфраструктуры автоматизированы и полностью логируются для проверки безопасности.

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

🐸Библиотека devops'a

#буст

💻Сетевая безопасность — это не только технологии, а целостная система: архитектура, процессы и механизмы защиты.

🎯На практикуме «Архитектура сетевой безопасности предприятия», который стартует 6 октября, вы узнаете, как строится устойчивая система.

💡В течение 6 недель вы:
• Разберёте реальные атаки и ошибки проектирования
• Узнаете, как проектировать сетевую архитектуру с учётом актуальных угроз и требований регуляторов
• Отработаете навыки на облачном стенде с NGFW, PT NAD и MaxPatrol SIEM
• Освоите методы контроля и оценки эффективности защиты

👨‍💻Практикум ведут эксперты Positive Technologies: Сергей Сахаров, Александр Бирюков, Алексей Сивенков и другие специалисты, которые поделятся опытом работы по построению сетевой безопасности.

📢 Авторы практикума — Михаил Кадер и Андрей Скрипкин, архитекторы решений по информационной безопасности с опытом более 30 лет.

Участие платное, количество мест ограничено.

[Узнать подробнее]

🐸Библиотека devops'a

#развлекалово

⚙️ Как работать с .env файлами в Kubernetes

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

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

1. Создаём .env файл

# app.env
APP_NAME=MyCoolApp
APP_ENV=production
APP_DEBUG=false

2. Применяем .env в Pod через ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-env
data:
  # Kubernetes автоматически прочитает строки из файла app.env
  # в v1.34 можно указать директорию с .env файлами через envFrom
  APP_NAME: MyCoolApp
  APP_ENV: production
  APP_DEBUG: "false"

3. Используем ConfigMap в контейнере

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
  - name: demo-container
    image: nginx
    envFrom:
      - configMapRef:
          name: app-env

Теперь контейнер получает переменные окружения напрямую из .env файла.

🐸Библиотека devops'a

#буст

⭐️ Вышел FreeBSD 15.0-ALPHA1

Команда FreeBSD представила первую альфа-версию 15.0-RELEASE. Образы доступны в различных форматах: ISO, memstick, QCOW2, VHD, VMDK, а также OCI-контейнеры.

➡️ Официальный анонс

🐸Библиотека devops'a

#свежак

🚀 Как вы стали девопсом

Для многих путь в DevOps — это не линейный процесс, а целое путешествие через различные роли и технологии. Кто-то пришёл из системного администратора, кто-то — из разработки, а кто-то стал девопсом после нескольких лет работы в ИТ-сфере.

Какие шаги стали решающими на вашем пути

Были ли важные курсы или сертификаты, которые помогли вам перейти в эту роль?

Какую роль сыграли практические проекты и опыт работы с CI/CD, контейнерами или облачными сервисами?

Какие сложности возникли при переходе, и как вы их преодолели?

💬 Давайте обсудим! Поделитесь своей историей в комментариях 👇

🐸Библиотека devops'a

#междусобойчик

👀 Домашний докер

Наткнулись на видео, где показывается интересный подход к организации Docker контейнеров в домашней лаборатории. Вместо использования решений вроде Kubernetes, в видео предлагается настройка на виртуальной машине с Debian, с привязкой томов.

А ещё в видео демонстрируется использование нескольких полезных Docker контейнеров, таких как Fresh RSS для удобного чтения новостей, Jellyfin для медиастриминга и Netbird для создания безопасных сетевых соединений.

➡️ Смотреть видео

🐸Библиотека devops'a

#буст

🔄 Жизненный цикл пода в Kubernetes

Жизненный цикл пода в Kubernetes — это цепочка процессов, от создания манифеста до завершения работы контейнеров. Сейчас разберем, как происходит запуск, мониторинг и завершение подов в Kubernetes.

1. Отправка манифеста пода и сохранение в etcd

Первым шагом при создании пода является отправка его манифеста в API-сервер Kubernetes. Этот запрос проверяется на корректность, и после успешной проверки информация о поде сохраняется в распределённом хранилище etcd, которое является источником правды для всего кластера.

2. Выбор ноды для пода планировщиком

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

Этот процесс основан на нескольких критериях:

• количество доступных CPU и памяти.

• правила, которые могут ограничивать или рекомендовать размещение подов на определённых нодах.

• метки или предпочтения, которые могут влиять на выбор ноды.

3. Подготовка пода на выбранной ноде

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

4. Запуск контейнеров и мониторинг их состояния

Как только все подготовительные работы завершены, контейнеры начинают переходить в состояние Running. На этом этапе Kubernetes использует health probes для мониторинга состояния контейнеров.

5. Мониторинг фаз пода

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

После завершения работы под может попасть в одну из следующих фаз:

• Succeeded — если контейнеры завершили свою работу без ошибок.

• Failed — если контейнеры завершили работу с ошибками.

• Unknown — если состояние пода не удается определить по каким-либо причинам.

6. Завершение работы пода и очистка ресурсов

Когда контейнеры в поде завершили свою работу, Kubernetes посылает SIGTERM сигнал для корректного завершения их работы. Если контейнеры не успевают завершиться в отведённое время, Kubernetes отправляет SIGKILL, чтобы принудительно их остановить.

🐸Библиотека devops'a

#буст