Запуск докер контейнера в ОЗУ

Jenkins с помощью плагина Kubernetes, запускает сборку контейнеров внутри подов в среде Kubernetes с помощью kaniko

обычно, образ собирается на jenkins, а только потом апплаится в кубер.

Не понял, как вы на дженкинс докер образ собираете? У нас дженкинс даже в кубере сам работает

не совсем корректно мысль изложил. первый коммент должен выглядеть так:

обычно, образ собирается отдельно, а только потом апплаится в кубер.

а по поводу:

как вы на дженкинс докер образ собираете?

у нас jenkins на отдельном docker хосте, где в него проброшен docker.sock
дальше nexus и k8s.

Вот docker build работает медленнее чем kaniko, но с kaniko есть проблема с тем что он диск теребит при каждой сборке, а если еще этих сборок параллельно 10-20, то это все тормозит.

распаковывает основной образ и все слои в /

Это ж какая помойка в результате получится.

Нет, ни чего не получается, он знает что его файлы лежат в образе в таких то директориях и пропускает их...

основная проблема скорости сборки в IO диска

Тебе поможет утилита eatmydata. Она заменяет вызовы подобные fsync ничего не делающими заглушками. Основная проблема при использовании дисков состоит именно в принудительном сбросе данных для сохранности.

kaniko распаковывает основной образ и все слои в /

WUT
Такое сегодня уже считается нормальным?

можно еще read/write заглушками заменить... шучу на самом деле (ну ты и так это понял) fsync редко где (субд, да) явно дергается таки.

Сделал сейчас apt upgrade, обновился один пакет, google-chrome-stable. За время обновления apt и его потомки дёрнули fsync 174 раза и ещё sync_file_range 192 раза. Ещё 6 раз msync, но это мелочи.

Что ни говори, а я глазами вижу, насколько быстрее установка пакетов идёт, если запускать её через eatmydata. Как вариант можно поставить везде быстрые NVMe SSD, но это не всегда возможно. В таких случаях eatmydata заметно помогает.

fsync я в критические секции сам пихал. но тут нюанс что и через что apt дергает

Вообщем кому интересно чем все на данный момент закончилось.

1. Выкинул канику в помойку. 2. Сделал сборку образов через докер в докер пробросив сокет.\ 3. Смонтировал в ОЗУ каталог сборки в дженкинсе при старте пода 4. На сервере в кубернетес смонтировал в ОЗУ каталог /var/lib/docker/tmp (он дергает его копируя артифакты из пода)

Вот и все, диск дергается теперь только при записи готовых образов в докер, от этого с моим объемом ОЗУ никуда уже не деться.

Докер билд нормально использует кеш, в отличии от каники, в версии 0.9.0 которая последняя мне так и не удалось заставить её работать.

Сборка образов ускорилась примерно на 20-30%.

Из-за нормальной работы кэша теперь могу ускориться еще, выделяя копирование библиотек не изменяющихся от сборки к сборке в отдельные слои...

Но главное диск теперь почти не теребонькает.