Docker на співбесіді: до яких запитань варто бути готовим

Використовувати Docker у щоденній рутині та чітко пояснити, як він працює — це дві різні навички.

Ви можете мати багаторічний досвід роботи з цим інструментом і вміти запускати контейнери навіть посеред ночі. А потім на співбесіді вас запитують: «Чому тут спрацював кеш?». І тепер вам треба не запускати команду, а пояснювати логіку її роботи.

Тому ми підготували матеріал, який допоможе систематизувати знання і впевнено відповідати на запитання інтерв’юера.

Як оцінюють знання Docker на технічній співбесіді

Docker рідко стає темою окремої співбесіди. Найчастіше цей інструмент обговорюють під час технічного інтерв'ю на позиції DevOps-інженера, Backend-розробника або Platform-інженера. Зазвичай перевірку знань із ним поділяють на три рівні:

1. Основи.
2. Логіка технічних рішень. 
3. Моделювання робочих ситуацій. 

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

• процес збірки Docker-образів (шари, кешування, оптимізація розміру);
• ізоляція контейнерів (простори імен, cgroups, спільне ядро Linux).

Якщо ви добре розумієте ці принципи, жодне із запитань не застане вас зненацька.

Перший рівень: базові принципи Docker

Це своєрідний бліц, який має на меті перевірити ваші знання ключових понять та функцій Docker.

У чому різниця між образом (image) і контейнером (container)?

Образ (image) — це незмінний шаблон, який містить застосунок, залежності та все необхідне для його запуску. 

Контейнер (container) — це запущений екземпляр цього образу з окремим шаром для запису. Один образ може використовуватися для створення багатьох контейнерів, а зміни в кожному з контейнерів ізольовані й не впливають на сам образ. 

Мета запитання — перевірити, чи розумієте ви, що образ є незмінним, а всі зміни в контейнері тимчасові. 

Чим контейнер відрізняється від віртуальної машини (VM)?

VM віртуалізує обладнання та запускає власну операційну систему з окремим ядром. 

Контейнер віртуалізує операційну систему: він працює як ізольований процес і використовує спільне ядро хост-системи.

Зазвичай контейнери запускають за лічені секунди, займають менше місця та споживають менше ресурсів. Проте за таку швидкість доводиться платити нижчим рівнем ізоляції порівняно з віртуальними машинами, оскільки вони використовують спільне ядро.

Що таке Dockerfile і для чого він використовується?

Dockerfile — це текстовий файл з інструкціями, за якими Docker створює образ. У ньому покроково описано весь процес: який базовий образ використати, які команди виконати, які файли скопіювати та яку команду запускати після створення контейнера.

Його головна перевага — відтворюваність. Це дозволяє будь-кому зібрати однаковий образ незалежно від середовища. 

Що таке шари образу (image layers) і як Docker використовує їх під час кешування збірки?

Кожна інструкція в Dockerfile створює окремий шар (layer), а всі шари разом формують Docker-образ. Переглянути їх можна за допомогою команди docker history.

Docker кешує кожен шар окремо. Якщо інструкція та пов'язані з нею файли не змінилися, під час наступної збірки цей шар не створюватиметься повторно — Docker просто використає кеш.

Наприклад, якщо змінити лише файл app.py, а requirements.txt залишиться без змін, то під час повторної збірки всі попередні шари будуть взяті з кешу.

У цьому випадку Docker повторно виконає лише останній крок — копіювання app.py. Саме тому порядок інструкцій у Dockerfile має значення: що рідше змінюється, то вище варто розміщувати такі кроки. Це допомагає максимально використовувати кеш і прискорювати збірку.

У чому різниця між командами COPY і ADD?

Обидві команди використовуються для копіювання файлів у Docker-образ, але між ними є важлива різниця.

COPY виконує лише одне завдання — копіює локальні файли та каталоги. ADD має ширші можливості: він може завантажувати файли за URL-адресою та автоматично розпаковувати локальні TAR-архіви.

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

Потрібно освіжити знання команд Docker? У блозі ITEDU, знайдете детальний розбір найпоширеніших команд і приклади їх використання.

Що відбувається всередині Docker після виконання команди docker run?

Команда docker run виконує не одну, а одразу три дії: 

• завантажує образ (якщо його немає локально);
• створює з нього контейнер;
• запускає його.

Якщо щось піде не так, важливо розуміти, на якому саме етапі виникла проблема: під час завантаження образу, створення контейнера чи його запуску.

Якими командами можна переглянути наявні контейнери й образи, а також видалити зайві?

Для перегляду контейнерів використовують команду docker ps, а щоб побачити також зупинені контейнери — docker ps -a. Список усіх локальних образів можна отримати за допомогою docker images.

Для очищення зайвих ресурсів застосовують docker system prune, а параметр -a додатково видаляє всі образи, які вже не є актуальними.

Зупинені контейнери та непотрібні образи з часом накопичуються й займають дисковий простір, тому періодичне «прибирання» — одна з базових практик роботи з Docker.

У чому різниця між командами docker stop і docker kill? 

Команда docker stop спочатку надсилає процесу сигнал SIGTERM. Це дає йому час на коректне завершення роботи. Якщо процес не зупиняється протягом стандартних 10 секунд, Docker примусово завершує його за допомогою SIGKILL.

Команда docker kill одразу надсилає SIGKILL, не залишаючи процесу часу на коректне завершення.

Тож docker stop дає застосунку можливість коректно завершити роботу, тоді як docker kill миттєво припиняє його виконання.

Другий рівень: логіка технічних рішень 

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

Як Docker зберігає дані та які способи зберігання доступні?

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

Щоб дані зберігалися незалежно від життєвого циклу контейнера, використовують:

• томи (volumes) — рекомендований спосіб для постійного зберігання даних;
• bind mounts — монтування каталогу з хост-системи, що часто використовують під час локальної розробки;
• tmpfs — зберігання даних в оперативній пам'яті, наприклад для секретів або тимчасових файлів.

Найчастіше для постійного зберігання даних застосовують саме томи.

Як працює мережа Docker одразу після встановлення та яку мережу Docker створює автоматично?

Після встановлення Docker створює три стандартні мережі:

1. bridge — стандартна мережа, у якій контейнери отримують власні IP-адреси та можуть взаємодіяти між собою.
2. host — контейнер, що використовує мережу хост-системи без додаткової ізоляції. Він працює так, ніби запущений безпосередньо на хості.
3. none — контейнер, що запускається без мережевого підключення і є повністю ізольованим. 

Якщо під час запуску контейнера мережу не вказано, Docker автоматично підключить його до bridge.

У чому різниця між директивою EXPOSE у Dockerfile та публікацією порту за допомогою параметра -p?

EXPOSE лише повідомляє Docker, який порт прослуховує контейнер. Реальний доступ до нього відкриває команда -p (--publish), що зіставляє порт контейнера з портом хост-системи.

Що таке Docker Compose і в яких випадках його доцільно використовувати?

Docker Compose — це інструмент, який дозволяє описати багатоконтейнерний застосунок в одному YAML-файлі. У ньому визначають сервіси, мережі, томи та інші параметри. Запуск усього застосунку виконується однією командою — docker compose up.

Docker Compose використовують, коли застосунок складається з кількох контейнерів (наприклад, API, бази даних і Redis) або потрібно швидко розгорнути однакове середовище для розробки.

Чому використання тегу latest вважається ризикованою практикою?

Тег latest не означає «нова версія». Це тег, який Docker використовує автоматично, якщо ви не вказали інший.

Його головний недолік у тому, що вміст образу може змінюватися з часом. Через це одна й та сама команда docker pull, виконана в різні дні, може завантажити різні версії образу. 

Саме тому в робочих проєктах рекомендують використовувати конкретні теги версій (або дайджести), а latest залишити для локальної розробки чи тестування.

Які підходи допомагають зменшити розмір Docker-образу?

Це можна зробити кількома способами:

• використовувати багатоетапну збірку (multi-stage build), щоб не включати у фінальний образ інструменти для збірки;
• обирати легкі базові образи, наприклад Alpine або slim-версії;
• об'єднувати команди RUN та очищати кеш у тому ж шарі;
• додати файл .dockerignore, щоб не копіювати зайві файли й каталоги (наприклад, .git або node_modules).

Навіть кілька таких оптимізацій можуть суттєво зменшити розмір образу та прискорити його збірку.

У чому різниця між інструкціями RUN, CMD та ENTRYPOINT?

RUN виконує команди під час збірки образу, наприклад встановлює пакети або залежності.

CMD і ENTRYPOINT визначають, яка команда буде виконана після запуску контейнера. Різниця між ними полягає в тому, що ENTRYPOINT задає основну команду, а CMD — аргументи, які використовуються під час запуску контейнера, але за потреби їх можна легко перевизначити.

Як передати контейнеру конфігурацію та секрети, не вбудовуючи їх в образ?

Конфігурацію контейнера зазвичай передають через змінні середовища (-e, env_file) або змонтовані конфігураційні файли. Завдяки цьому один і той самий образ можна використовувати в різних середовищах, змінюючи лише налаштування.

Чутливі дані (паролі, токени, ключі доступу) не можна зберігати в Dockerfile або всередині образу, оскільки їх можна отримати з його шарів. Для цього використовують механізми керування секретами, наприклад Docker Secrets або спеціалізовані сховища секретів.

Третій рівень: моделювання робочих ситуацій

На цьому етапі техлід перевіряє, як ви дієте в умовах, наближених до реальної роботи. Вам можуть запропонувати вирішити типову проблему, пов’язану з Docker. 

Ваше Docker-образ займає понад гігабайт і збирається повільно. Як знайти причину та зменшити його розмір? 

Перш за все варто знайти, що саме займає найбільше місця. Для цього використовують команду docker history <image>, яка показує розмір кожного шару образу. Часто найбільше місця займає базовий образ або встановлені залежності.

Після цього варто:

• використовувати багатоетапну збірку (multi-stage build);
• обрати легший базовий образ;
• оптимізувати порядок інструкцій у Dockerfile, щоб ефективніше використовувати кеш;
• додати .dockerignore, щоб не включати до контексту збірки зайві файли.

Багатоетапна збірка може дозволити зменшити розмір образу з умовних 1,27 ГБ до 15,5 МБ, адже інструменти для збірки не потраплять до фінального образу. Крім того, правильний порядок інструкцій і файл .dockerignore допомагають не лише зменшити розмір образу, а й значно прискорити його збірку.

Контейнер запускається, але відразу завершує роботу. Що перевірити насамперед? 

Насамперед перевіряється стан контейнера та його журнали за допомогою команд docker ps -a і docker logs <container>.

Зазвичай проблема навіть не в помилці, контейнер просто завершив виконання свого головного процесу (PID 1), а разом із ним зупинився і сам.

Якщо контейнер мав працювати постійно, перевірте CMD або ENTRYPOINT. Основний процес не повинен завершуватися одразу чи працювати у фоновому режимі.

Якщо контейнер завершився з ненульовим кодом виходу, причину збою можна знайти в журналах.

Після виконання docker build зміни в коді не з'явилися. Чому?

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

Треба переглянути, чи інструкція COPY не була взята з кешу (CACHED), а зміни дійсно потрапили до нового образу. За потреби варто перебудувати образ без використання кешу.

Окрім цього важливо перевірити, що запускається саме щойно зібраний образ, а не його стара версія. 

Контейнер завершив роботу з кодом виходу 137. Про що це свідчить?

Код виходу 137 означає, що контейнер було примусово завершено сигналом SIGKILL. Це відбувається через нестачу пам'яті (Out of Memory, OOM), коли система зупиняє контейнер, який перевищив доступний ліміт.

Перевірити це можна за допомогою команди docker inspect <container>.

Якщо результат містить OOMKilled=true, причина підтверджена.

У такому разі потрібно або збільшити ліміт пам'яті, абознайти й усунути причину її надмірного споживання, наприклад витік.

Дані, записані всередині контейнера, зникли після docker rm. Чому і як цьому запобігти? 

Дані зникли, тому що вони зберігалися у файловій системі контейнера, яка видаляється разом із ним. Це стандартна поведінка Docker, а не помилка.

Щоб дані зберігалися після видалення контейнера, потрібно використовувати томи (volumes) або bind mounts, які зберігають інформацію поза контейнером.

Не забуваймо про основний принцип Docker: файлова система контейнера є тимчасовою, тому важливі дані слід зберігати поза нею.

Контейнер працює локально, але коли запущений з образу в реєстрі, — ні. Де шукати причину?

Причина ховається в одній із трьох ситуацій:

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

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

Підсумовуючи 

Теорія — важлива, але успішне проходження технічної співбесіди з Docker залежить не лише від знання команд. Інтерв’юери цінують, коли ви можете підкріпити свої відповіді реальним досвідом і пояснити, як застосовували ці знання на проєктах.

Перед співбесідою радимо повернутися до цієї статті — вона допоможе за 10 хв. освіжити ключові теми. 

Якщо хочете глибше розібратися в Docker і зрозуміти принципи його роботи, запрошуємо на практикум з адміністрування Docker від ITEDU. 

Бажаємо успіхів!

Анастасія Хітрова