Тестуємо Docker

4 min readFeb 28, 2023

Розробка будь якої системи чи її складової включає у себе також тестування. Ви написали функцію — її потрібно протестувати. Docker образ не є виключенням. Було би класно отримати зворотній зв’язок по тому чи не допустили ми якихось безпекових вразливостей або неефективно розробили сам образ. У цій статті хочу розглянути декілька інструментів, які нам допоможуть у цьому.

Практика тестувати Docker образ або Dockerfile використовується рідко, бо зазвичай — працює, і працює добре. Самі зміни у Dockerfile можуть вноситись не часто. Тому, зазвичай не проводять якихось додаткових перевірок самого образу.

Якщо ваша ціль:

Покращити захищеність Docker образу
Зробити Dockerfile більш ефективним
Дотриматись стандартів
Перевірити чи структура образу відповідає вашим очікуванням

тоді, у нагоді стануть наступні інструменти:

Snyk

Не так давно Docker Desktop отримав нове розширення від Snyk. Вони є одні із лідерів у сфері безпеки. Розширення дає можливість сканувати ваші Docker образи на наявність вразливостей. В основному, це вразливості пов’язані із залежностями, які у вас встановлені.

Щоб виконати перевірку вам потрібно ввести команду:

docker scan image_nameb

Що з класного, — є посилання на детальний опис і як його виправити.

Документація: https://docs.docker.com/engine/scan/

Hadolint

Маленький лінтер котрий оцінює ваш Dockerfile. Він містить велику базу правил для оптимізації образу. Є 3 види правил — Info, Warning, Error. В основному вони націлені на використанні конкретних версій, уникнення хардкоду шляхів, чи якщо ви пропустили очищення кешу. Наприклад, якщо ви використовуєте інструкцію ADD для розархівування — він вам про це повідомить (Використання ADD для архівів не рекомендується Docker-ом).

Для використання Hadolint вам потрібно його встановити, перейти у директорію з Dockerfile та виконати команду:

hadolint Dockerfile

github — https://github.com/hadolint/hadolint

Checkov

Ще один лінтер, який спеціалізується не лише на Dockerfile-ах, а і Terraform коді, Helm чартах та ще інших Infrastructure-as-a-code системах. Він перевіряє відповідність Dockerfile до вразливостей. На мою думку, у нього менше перевірок з точки зору оптимізації, він не буде сваритись, коли ви оновлюєте всі пакети(тут вам до Hadolint). Але, підтримка декількох технологій — це велика перевага.

Запуск також простий — встановили та виконали команду:

checkov -file Dockerfile

Зараз вони розвивають свою платформу, але вона платна і мені ще не доводилось з нею працювати

github — https://github.com/bridgecrewio/checkov

Container Structure Tests

А чи існують юніт тести для Docker образу ?
ТАК!

Google розробив фреймворк Container Structure Tests саме для того, щоб мати змогу перевірити чи відповідає образ очікуванням. Цей інструмент не є дуже популярним, але він доволі потужний.

З його допомогою ми можемо написати власну перевірку образу. Тест пишеться у YAML файлі. І цим тестом ми можемо перевірити вже зібраний Docker образ.

Існує декілька видів тестів:

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

Цей підхід зручно використовувати якщо ми маємо власні очікування або стандарти до образу. Таким чином можна їх перевіряти.

Для того щоб запустити тест потрібна наступна команда:

container-structure-test test --image ozarevychbsi/py-hello:latest --config py-hello-test.yaml

Я написав декілька прикладів, надіюсь стануть у нагоді:

мої приклади — https://github.com/OlegZarevych/container-test

github — https://github.com/GoogleContainerTools/container-structure-test

Clair

Ще один статичний аналізатор коду із нахилом у безпеку — це Clair. Про цей проект можна багато прочитати, але у мене з ним найгірший досвід. Використовуючи офіційну документацію, я не зміг його запустити. На щастя знайшовся додатковий інструмент який мені полегшив запуск https://github.com/arminc/clair-scanner. Але навіть з ним мені на це пішло багато часу.

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

github — https://github.com/quay/clair

Коли виконувати ці тести?

Все що було розглянуто сьогодні — виконується доволі швидко. Декілька секунд і є результат. Тому перше місце, де варто запустити перевірку — комп’ютер розробника. Можна одразу отримати фідбек і внести зміни. Але багато хто лінується робити це. Тому, найкращий варіант —запуск у CI системі. Тоді ця перевірка буде відбуватись автоматично і явно її не можна буде оминути. Я бачу два місця, де саме — на етапі PR або у основному білд процесі. Особисто надам перевагу на PR, бо Dockerfile змінюється рідко і виконувати ці перевірки на кожному білді може бути надлишково. Але це питання дискусійне.

Головне, щоб хоча б одна перевірка була у вас і ви за допомогою неї покращували ваш продукт.