#начинающим #docker

Контекст(context).

Мне понадобилось некоторое время на этапе моего обучения несколько лет назад, чтобы поесть всякого, чтобы осознать существование контекста.
Основной пример буду пояснять на примере Docker.
Контекст сборки - это архив (по сути tar-файл), который Docker создаёт из указанной директории и отправляет демону для обработки.
Например, когда вы пишете docker build -t image ., Docker упаковывает все файлы из текущей директории (.) и передаёт их демону😈.

Допустим мы собираем имадж так:

docker build -t image .

Вот точка это и есть контекст. Точка это наша директория нашего проекта.

Что же нам надо знать о контексте?
- нельзя выйти за пределы контекста
Например у нас есть такая структура

/home/user/projects/
├── my_project/
│   ├── Dockerfile
│   ├── app.py
└── shared/
    └── library.so

Находясь в директории my_project мы не сможем собрать имадж типа такого

FROM ubuntu:20.04
COPY ../shared/library.so /usr/lib/

Так как shared находится выше по иерархии и не входит в контекст текущей директории "."

- докер(и другие известные мне утилиты) сканирует все файлы контекста( то есть в текущей директории)
То есть условно если у вас есть 50000 файлов по мегабайту или один файл 50 гигабайт в гит репозитории в контексте, то это замедлит сборку
Даже если мы НЕ используем COPY . . , докер всё равно сканирует эти файлы(точнее Docker демон сканирует и упаковывает файлы для передачи) и мы собираем дольше по времени.
Не думаю, что этот случай для всех, с этим можно столкнутся при не совсем корректных воркфлоу и при монолит приложениях.
Например у вас npm build идёт ВНЕ сборки докера, а потом вы копируете файлы(я видел и такое).
Проблема с переполнением контекста решается через .dockerignore файл.
В этом файле мы указываем те директории/файлы, которые НЕ должны попасть в контекст, по аналогии с .gitignore.

- контекст в multi-stage билдах
Контекст доступен для всех этапов сборки, однако при использовании COPY --from=build копирование идет из предыдущего этапа, а не из исходного контекста.

Концепция контекста применима не только к Docker, но и к другим инструментам, например, к Helm - менеджеру пакетов для кубера.
Некоторые инженеры сталкиваются с ситуацией, когда во время деплоя секрет Helm не удаётся сохранить в ETCD, потому что его размер превышает ограничение в 1 МБ(ограничение ETCD).
Чаще всего это происходит из-за того, что в директорию случайно попадают ненужные файлы: логи, бинарники, архивы или другие "левые" данные. Да, прям внутри кубера в секрете хелма по релизу помимо манифестов yaml валяются бинари/файлы, которые мы по незнанию туда засунули.
Чтобы избежать таких проблем, стоит использовать файл .helmignore, который позволяет исключить лишние файлы из контекста чарта - примерно так же, как .dockerignore помогает в Docker.

Контекст - это не просто техническая деталь, а инструмент, который нужно понимать и оптимизировать.
Используйте .dockerignore/.helmignore и следите за содержимым директорий, чтобы сборка была быстрой и эффективной.