LINUX.ORG.RU

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

 , , , ,


1

2

Вопрос в следующем, у меня Jenkins с помощью плагина Kubernetes, запускает сборку контейнеров внутри подов в среде Kubernetes с помощью kaniko, хочу ускорить это дело, так как основная проблема скорости сборки в IO диска, при сборке контейнера kaniko распаковывает основной образ и все слои в / (root директори), из-за этого просто примонтировать рам диск в определенный каталог я не могу, как быть в таком случае? Может кому то удавалось решить такую проблему, что бы файловая система контейнера была полностью в ОЗУ сервера.

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

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

dada ★★★★★ ()
Ответ на: комментарий от BartMan

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

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

а по поводу:

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

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

dada ★★★★★ ()
Ответ на: комментарий от dada

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

BartMan ()

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★ ()

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

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

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

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

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

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

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

BartMan ()