Доработанный под наши задачи Firecracker используется, как герметичная среда исполнения тестовых сценариев. Чтобы фазу сетапа теста не проводить каждый раз мы используем механику snapshot/restore. Где за счет оптимизированного цикла, время restore составляет порядка сотен микросекунд и в результате мы исполняем полносистемные тесты до 500 раз в секунду на среднем сервере с восемью ядрами. Это позволяет один раз подготовить стартовый (чистый) сетап и дальше исполнять сотни сценариев в секунду без дорого степа окружения.
Для этого нам необходимо иметь гибкий способ создания и расширения базовых образов. Чтобы нужные зависимости тестируемой системы оказались в окружении.
Для этого мы используем следующую схему:
Ubuntu squashfs → Base Docker Image → Rootfs Docker Image → merged rootfs → tar → ext4
Сначала берется подготовленный Ubuntu squashfs для Firecracker и первый этап распаковывает squashfs, а второй превращает его содержимое в базовый Docker Image. Таким образом у нас получается базовый образ в точности соответствующий струкртуре изначального sqashfs образа для виртуальной машины.
Поверх базового образа применяется обычный Dockerfile.rootfs.
Через apt-get устанавливаются зависимости будущей VM: Python, Docker, containerd, runc, сертификаты и необходимые библиотеки.
Таким образом Docker выступает как конструктор файловой системы из подготовленного образа.
После сборки создается временный контейнер, а его объединенная файловая система экспортируется через docker export.
Далеее с помощью mkfs.ext4 создается ubuntu.rootfs.ext4, который подключается уже к Firecracker.
Такой способ удобен и для отладки в докер окружении, и непосредственно для запуска виртуальной машины, а также удобен для интеграции в CI если вам необходимы изолированные кастомные зависимости. Т.е. докер не как среда запуска, а как способ менеджмента файловой системы и зависимостей.
PS: если тема интересна, пишите в комментарии – выложу докерфайлы.
– @tthread