Dockerfile - файл содержащий инструкции для создания образа контейнера

FROM - задаёт базовый (родительский) образ
LABEL - описывает метаданные. Например — сведения о том, кто создал и поддерживает образ
ENV - устанавливает постоянные переменные среды
RUN - выполняет команду и создаёт слой образа. Используется для установки в контейнер пакетов
COPY - копирует в контейнер файлы и папки
ADD - копирует файлы и папки в контейнер, может распаковывать архив на лету
CMD - описывает команду с аргументами, которую нужно выполнить когда контейнер будет запущен. Аргументы могут быть переопределены при запуске контейнера. В файле может присутствовать лишь одна инструкция CMD(запускается оболочка /bin/sh)
USER - указывает от какого пользователя всё будет работать
WORKDIR - задаёт рабочую директорию для следующей инструкции
ARG - задаёт переменные для передачи Docker во время сборки образа
ENTRYPOINT - предоставляет команду с аргументами для вызова во время выполнения контейнера. Аргументы не переопределяются
EXPOSE - указывает на необходимость открыть порт, сам порт не открывает
VOLUME - создаёт точку монтирования для работы с постоянным хранилищем
MAINTAINER - информация об авторе имя и <email>

#devops #девопс

@DevOPSitsec

Почему мы используем Kafka вместо RabbitMQ: сравнение и преимущества

При построении больших и сложных систем не обойтись без программных брокеров сообщений. Однако часто возникает вопрос, какой из них выбрать для того или иного проекта. Сегодня мы поделимся особенностями работы Apache Kafka и RabbitMQ, дав точный рецепт, когда и какой брокер стоит использовать.

#devops #девопс

@DevOPSitsec

Практические вопросы для экзамена Certified Kubernetes Security Specialist (CKS)

https://github.com/snigdhasambitak/cks/tree/main

#devops #девопс

@DevOPSitsec

5 приемов оптимизации сборки Docker-образов

Прием 1 — уменьшаем количество слоев в образе
Уменьшить количество слоев в образе можно сворачиванием нескольких однородных инструкций в одну. Например, несколько логически связанных инструкций RUN можно объединить в одну инструкцию с помощью конвейера Linux:

RUN apt-get update && apt-get install -y nginx



Прием 2 — удаляем ненужный кэш apt-get
Пакетный менеджер apt-get, обновляя репозиторий, сохраняет кэш, который в большинстве случаев не нужен, и его можно удалить, уменьшив тем самым собираемый образ на 100+ Мбайт. Сделать это совсем несложно, достаточно в инструкции RUN последней командой указать: && rm -f /var/lib/apt/lists/*.

Соединим оба приёма в одну инструкцию:

RUN apt-get update && apt-get install -y nginx && rm -f /var/lib/apt/lists/*
Такая конструкция работает именно в одной инструкции RUN, если вы вынесете rm -f /var/lib/apt/lists/* в отдельный RUN — ничего не сработает, так как кеш будет очищаться в другом слое, а его обновление будет оставаться в предыдущем слое.



Прием 3 — копируем только нужные файлы проекта в образ с помощью .dockerignore-файла
Обычно для копирования проекта в образ используется инструкция COPY с указанием места расположения проекта, как «.», что указывает на текущею директорию. Такой подход имеет один недостаток — будут скопированы все вложенные подкаталоги и файлы, что может значительно увеличить размер образа.

Исправить ситуацию призван .dockerignore-файл, который работает так же как и .gitignore-файл. В этих файлах указываются те папки и файлы, которые «не надо трогать». Gitignore-файл располагается в корневом каталоге копируемого в образ проекта. Обратите внимание на точку в начале названия файла — «.gitignore», так и должно быть.

Рассмотрим пример работы .gitignore-файла. Например, мы работаем с GIT, и в нашем проекте есть GIT-репозиторий. В образе он нам не нужен, поэтому его можно не копировать, а ещё в образе нам не нужен Dockerfile. Укажем эти файлы в .gitignore-файле:

.GIT
Dockerfile
При сборке образа Docker прочтет .dockerignore-файл и не включит в образ указанные в нем папки и файлы.


Приём 4 — используем минималистические Linux-образа Alpine
Как правило, для сборки образов применяются дистрибутивы Debian, Ubuntu, CentOS. Но это оправдано в том случае, если ваш проект будет использовать всё обилие возможностей ядра и пакетов, которые предоставляет выбранный дистрибутив. Если же вам нужно просто создать контейнер с Nginx или иной другой программой — используйте Alpine-сборки.

Alpine-образ весит считанные мегабайты, а не сотни Мбайт как Debian или Ubuntu, при этом в нём есть всё необходимое для запуска большинства приложений. Например, так выглядит dockerfile Nginx-образа на Alpine-сборке, который занимает 7 Мбайт:

FROM alpine
RUN apk add --no-cache nginx && mkdir -p /run/nginx
EXPOSE 80
COPY custom.conf /etc/nginx/conf.d
dockerCOPY . /opt/
CMD ["nginx”,”-g”,”daemon off;”]
Еще один бесспорный плюс Alpine — скорость сборки образа. Она разительно отличается в лучшую сторону по сравнению со скоростью сборки на любом другом дистрибутиве Linux.


Прием 5 — часто изменяемые слои ставим в конец dockerfile
Слоистая структура Docker-образов имеет одно неприятное свойство — при внесении изменения в один из слоев, это слой и все последующие слои будут пересобраны. Поэтому, чтобы сэкономить время на сборке образа — старайтесь ставить инструкции копирования кода проекта и конфигов в конец dockerfile до команды CMD или ENTRYPOINT.


#devops #девопс

@DevOPSitsec

DevSecOps

DevSecOps. Общее погружение
DevOps на пальцах
SecOps. Защита кластера
DevSec. Встраивание ИБ в конвейер разработки
DevSecOps. Process edition
Что такое Audit Policy? Вебинар из цикла DevSecOps
Зачем GitOps в Enterprise? Вебинар из цикла DevSecOps 2-й сезон
Управление секретами: основы
Persistent данные и резервное копирование в кластере
8 Bad Pods: атаки на Kubernetes
Kubernetes в Enterprise: VMware Tanzu
Kubernetes в Enterprise. Обзор, проблематика, решения
DevOps – начало работы в кластере Kubernetes
DevOps в Enterprise. Tech Talks Юрий Семенюков на High Load ++
Как пережить сертификацию по Kubernetes. Личный опыт

источник

#devops #девопс

@DevOPSitsec

Собрал основные концепции Docker в одну диаграмму

#devops #девопс

CI/CD без боли: оптимизация пайплайнов на GitHub Actions 🚀

GitHub Actions — мощный инструмент, но без оптимизации ваш пайплайн легко превратится в тормозную мясорубку. Разбираемся, как выжать максимум из CI/CD на GitHub.


Почему это важно:
Быстрые и надёжные пайплайны — ключ к высокой скорости доставки. Медленные сборки = потеря времени, нервов и денег.


1. Кэшируй разумно
Используй actions/cache для ускорения зависимостей, но не кэшируй всё подряд. Пример для Node.js:

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-node-

⚠️ Ключ должен быть завязан на lock-файлы, иначе можно словить конфликты версий.


2. Делай job-ы параллельными
Разделяй пайплайн на независимые шаги — unit-тесты, линтеры, сборка. Добавляй needs: там, где реально нужно, а не везде.


3. Matrix strategy — must-have
Хочешь тестировать на разных версиях языка/ОС? Используй matrix:

strategy:
  matrix:
    node-version: [16, 18, 20]

Это масштабирует проверку без дублирования кода.


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

on:
  push:
    branches:
      - main
  pull_request:
    paths:
      - 'src/**'

Это поможет не перегружать runners.


5. Используй workflow_dispatch для ручных запусков
Иногда надо протестить пайплайн руками — не бойся добавить ручной триггер:

on:
  workflow_dispatch:

6. Логи и таймауты — твои друзья
Добавляй timeout-minutes к job-ам и выводи ключевые логи через ::group:: и ::endgroup::, чтобы не утонуть в консоли.


Вывод:
Грамотно настроенный GitHub Actions экономит время и снижает головную боль. Избегай монолитных пайплайнов, кэшируй умно и тестируй только то, что нужно. Автоматизация — это про контроль, а не хаос.


#devops #девопс

Полезная таблица инструментов DevSecOps

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

#devops #девопс

@devopsitsec