Как про­тес­тировать образ Docker

Тес­тирова­ние — важ­ный шаг на всех эта­пах раз­работ­ки ПО. Но не все ком­понен­ты име­ют оче­вид­ные, извес­тные и понят­ные пути тес­тирова­ния. К при­меру, обра­зы Docker либо не тес­тиру­ют вооб­ще, либо тес­тиру­ют толь­ко на при­год­ность к запус­ку. В сегодняшней статье я рас­ска­жу, как про­тес­тировать образ Docker так, что­бы убе­дить­ся в том, что он на 100% выпол­няет свои задачи.

РЕКОМЕНДУЕМ:
Безопасность Docker
Как с помощью Docker упаковать приложение ASP.NET Core

Введение в тестирование

Юнит‑тес­тирова­ние (или модуль­ное тес­тирова­ние) — это про­цесс в раз­работ­ке прог­рам­мно­го обес­печения, поз­воля­ющий про­верить работос­пособ­ность отдель­ных модулей исходно­го кода. Такое тес­тирова­ние при­выч­но при­меня­ется в раз­работ­ке непос­редс­твен­но прог­рам­мно­го обес­печения, одна­ко с ходу слож­но себе пред­ста­вить юнит‑тес­тирова­ние обра­за Docker.

Взгля­нем на прос­тей­ший Dockerfile:

Здесь мы выпол­няем единс­твен­ное дей­ствие — добав­ляем файл со стро­кой Hello, <wbr />World! в файл /<wbr />test.<wbr />txt.

Как мож­но про­верить, что мы дос­тига­ем жела­емо­го резуль­тата? Мож­но запус­тить соб­ранный кон­тей­нер и пос­мотреть, что, во‑пер­вых, нуж­ный файл при­сутс­тву­ет, а во‑вто­рых, его содер­жимое рав­но ожи­даемо­му.

Не слиш­ком удоб­но, не так ли? К счастью, сущес­тву­ет фрей­мворк terratest. Он поз­воля­ет писать тес­ты на Golang для Docker (и docker-compose) так же, как и для обыч­ного кода!
Взгля­нем на прог­рам­мную реали­зацию дан­ного тес­та:

Ста­ло ощу­тимо удоб­нее! Бла­года­ря пол­ноцен­ному язы­ку прог­рамми­рова­ния мы можем соз­давать нам­ного более слож­ные сце­нарии тес­тирова­ния, исполь­зовать API докер и так далее.

Усложняем: тестирование HTTP-сервера с зависимостями

К сожале­нию, при­меры вро­де Hello World ред­ко объ­ясня­ют реаль­ные кей­сы при­мене­ния тех­нологии, поэто­му давай пред­ста­вим нес­коль­ко более слож­ный слу­чай. К при­меру, есть Golang-при­ложе­ние (прос­той HTTP-сер­вер):

Пред­положим, при­ложе­нию так­же тре­бует­ся бинар­ник curl для работы. Тог­да Dockerfile будет выг­лядеть сле­дующим обра­зом:

Что здесь мож­но про­верить:

• на­личие бинар­ника curl;
• что сер­вер успешно под­нима­ется и порт 8080 открыт и прос­лушива­ется.

Взгля­нем, какие мож­но написать тес­ты (код пол­ностью дос­тупен в кон­це статьи).
Вы­несем сбор­ку обра­зов в отдель­ную фун­кцию, что­бы не пов­торять­ся:

Пер­вым тес­том про­верим, как и в пре­дыду­щем при­мере, наличие бинар­ника curl:

Вто­рым — дос­тупен ли HTTP-сер­вер. Здесь уже слож­нее:

Базы данных и Compose

Рас­смот­рим нес­коль­ко более слож­ный при­мер, ког­да при­ложе­ние тре­бует под­клю­чить­ся к некото­рой базе дан­ных Postgres. У офи­циаль­ного обра­за есть воз­можность под­ложить скрипт, который будет выпол­нять кон­фигура­цию схе­мы и добав­лять какие‑то тес­товые дан­ные. Исполь­зуем это на эта­пе тес­тирова­ния.
При­мера скрип­та ини­циали­зации БД:

В код прог­раммы добавим прос­тую фун­кцию, которая будет забирать из БД стро­ку по ее ID в таб­лице:

Dockerfie для сбор­ки при­ложе­ния выг­лядит схо­же с прош­лым при­мером, но добави­лось ска­чива­ние пакетов:

Для тес­тирова­ния напишем docker-compose-файл, который запус­кает БД, и рядом соб­ранное при­ложе­ние:

Сам слу­чай тес­тирова­ния стал слож­нее, но тест — про­ще. Прос­тая фун­кция для сбор­ки самого обра­за:

И сам тест:

Ес­ли все прош­ло хорошо, то вывод очень лаконич­ный.

Ес­ли тест валит­ся по каким‑то при­чинам, то будет доволь­но прос­то понять, что имен­но пош­ло не так.
С этим фрей­мвор­ком мож­но про­тес­тировать все шаги сбор­ки внут­ри самого Dockerfile, а так­же общую фун­кци­ональ­ность при­ложе­ния. И быть уве­рен­ным, что далее в окру­жения отправ­ляют­ся пол­ностью рабочие обра­зы.
Пол­ный код тес­та HTTP-сер­вера:

Пол­ный код при­мера тес­тирова­ния с помощью docker-compose:

Го­тово!