.dockerignore: як не передати зайві файли у збірку

Навчальний сценарій: локальний файл конфігурації не показується у Git, але ви запускаєте збірку з COPY . і не впевнені, чи доступний він збирачу. Правила Git не визначають автоматично вміст локального Docker-контексту. Файл .dockerignore дозволяє окремо обмежити цей набір. Перевіримо правило на маленькому каталозі з вигаданими даними, не передаючи справжні паролі й не збираючи продуктивний застосунок.

Мета вправи — побачити, які файли доступні інструкції COPY після застосування виключень. Невеликий експорт файлової системи зручніший за припущення на основі розміру збірки. Він покаже, що потрібний публічний файл збережено, умовну конфігурацію виключено, а безпечний шаблон залишено. Це перевірка навчального прикладу, а не гарантія відсутності секретів у будь-якому образі вашої компанії.

Відокремте Docker-контекст від репозиторію

Контекст локальної збірки задає останній аргумент команди: крапка означає поточний каталог. Саме від цієї межі залежить, до яких файлів може звертатися COPY. Не запускайте вправу з домашньої директорії або кореня великого робочого дерева. У .dockerignore важлива не лише наявність правила, а й те, що файл лежить у корені фактично вибраного контексту. Механізм описано в документації Docker про контекст.

Приклад розрахований на macOS або Linux із уже налаштованими Docker Engine та Buildx і доступом до дозволеного локального збирача. Команда docker buildx version перевіряє доступність Buildx, але не підтверджує справність самого збирача. Якщо середовище не готове, використайте інструкцію встановлення для своєї системи; не змінюйте налаштування спільного сервера заради цієї вправи. Права адміністратора для редагування навчальних файлів не потрібні.

Через редактор створіть новий порожній каталог dockerignore-demo. Додайте public/index.html із довільним навчальним текстом, .env.training із рядком DEMO_NOT_SECRET=1 і .env.example з очевидною заглушкою SETTING=replace_me. Це не справжні облікові дані. Не копіюйте сюди конфігурацію робочого сайту: спочатку ми перевіряємо правило, а не випробовуємо захист на секретах.

У корені цього каталогу створіть .dockerignore з такими рядками. Для реального проєкту узгодьте перелік окремо: журнал може бути потрібним тестовим зразком, а назва локального конфіга — відрізнятися. Не переносіть список механічно на всі репозиторії.

.git
.env
.env.*
!.env.example
*.log

Перші правила виключають Git-каталог, файли середовища та журнали. Рядок із знаком оклику повертає .env.example після ширшого правила .env.*. Порядок важливий. У шаблоні мають бути лише назви параметрів і безпечні заглушки; саме розширення example не робить вміст безпечним. До першої збірки відкрийте всі навчальні файли й переконайтеся, що жодного справжнього значення там немає.

Зробіть результат видимим без запуску застосунку

Створіть у тому самому каталозі файл Dockerfile. Цей рецепт призначений лише для огляду файлів: він не встановлює залежності, не запускає сайт і не містить команди виконання контейнера. scratch використовується як порожня основа, а COPY переносить дозволений контекст у каталог snapshot. Не підмінюйте цим рецептом Dockerfile вашого застосунку.

FROM scratch AS context-check
COPY . /snapshot/

Перейдіть у dockerignore-demo й перевірте, що сусіднього каталогу dockerignore-result-01 ще немає. Якщо він існує, оберіть іншу нову назву та однаково змініть її у всіх командах нижче. Наступна команда запускає збірку, може створювати кеш і записує результат на диск поза контекстом. Не вказуйте як призначення папку із робочими файлами: експорт не повинен змішуватися з ними.

docker buildx build \
  --output type=local,dest=../dockerignore-result-01 \
  .

Параметр output із типом local експортує файлову систему результату в обраний каталог. Це не публікація образу в реєстрі й не запуск вебсервера. Поведінку та підтримувані налаштування пояснює документація локального експортера. Якщо команда завершилася помилкою, спочатку збережіть її причину; не оцінюйте залишки попереднього експорту як новий успішний результат.

Із того самого навчального каталогу виконайте кожну перевірку окремо. Очікується код завершення 0 для кожної: публічна сторінка й шаблон присутні, а .env.training відсутній. Команда test за успіху зазвичай нічого не друкує; відсутність тексту не замінює перевірки коду завершення у вашому терміналі або сценарії.

test -f ../dockerignore-result-01/snapshot/public/index.html
test ! -e ../dockerignore-result-01/snapshot/.env.training
test -f ../dockerignore-result-01/snapshot/.env.example

Якщо файл конфігурації все ж є, зупиніться й перевірте шлях контексту, написання .dockerignore та порядок правил. Також подивіться, чи немає окремого файла виключень для вибраного Dockerfile: він може мати пріоритет над кореневим. У вправі використовується лише звичайний Dockerfile. Не вимикайте всі виключення одразу: це приховає причину й збільшить обсяг доступних збирачу файлів.

Переносьте правило в проєкт як окрему зміну

Для робочого сайту спочатку збережіть чинні правила й погодьте, які каталоги справді потрібні збірці. Додавайте виключення невеликими групами та перевіряйте, чи не зникли шаблони, статичні ресурси або файли залежностей. Невдала збірка після виключення файла не означає, що треба повертати весь домашній каталог у контекст. З’ясуйте конкретну залежність і звузьте потрібний шлях.

Перевірка цього експорту не охоплює додаткові контексти, попередні образи, зовнішні завантаження чи інші етапи вашого справжнього рецепта. Не використовуйте вигадані паролі як заміну правильної передачі секретів. Якщо справжній секрет уже потрапив у чужу збірку або опублікований образ, одного нового правила недостатньо: припиніть використання скомпрометованого доступу та узгодьте окреме реагування. Не додавайте чутливі значення до журналу розслідування.

Після вправи навчальні каталоги можна прибрати вручну, перевіривши їхні точні назви; очищати всі образи чи весь кеш Docker не потрібно. У проєкті залиште коротку перевірку складу контексту й переглядайте підготовлені зміни перед комітом. Якщо нові правила ламають збірку, відновіть попередню версію правил із контролю версій у тестовому середовищі, не стираючи іншу роботу.

Висновок: .dockerignore слід перевіряти за фактичним набором доступних файлів, а не за чистим статусом Git. Окремий каталог із заглушками дозволяє випробувати правила без ризику для справжньої конфігурації. Якщо потрібна допомога з упорядкуванням Docker-збірки вебпроєкту, зверніться до AriZone з описом контексту та знеособленою помилкою — без архіву з паролями й приватними ключами.