Как использовать кеши хоста в сборке сингулярности? - PullRequest
Новая
       93

Как использовать кеши хоста в сборке сингулярности?

0 голосов
/ 26 мая 2020

Я ищу способы оптимизировать время сборки наших уникальных контейнеров HP C. Я знаю, что могу сэкономить время, создавая их слой за слоем. Но все же есть возможности для оптимизации.

Меня интересует использование / кеширование всего, что имеет смысл в хост-системе.

  1. CCache для кэширования артефактов сборки C ++
  2. git клонирование репо
  3. Загрузки пакетов APT

Я провел несколько экспериментов, но ни разу не преуспел.

Что я обнаружил far:

CCache

Я устанавливаю ccache в контейнер и инструктирую систему сборки использовать его. Я знаю, что, поскольку я запускаю singularity build с sudo, кеш будет под /root. Но после запуска сборки /root/.ccache пуст. Я проверил сгенерированные файлы сборки CMake, и они определенно используют ccache.

Я даже создал тестовый рецепт, содержащий %post

touch "$HOME/.ccache/test"

, но тестовый файл нигде не появился на хост-система (не в /root и не в доме моего пользователя). Монтируется ли на этапе сборки каталог, поддерживаемый контейнером, в /root вместо root dir хоста?

Нужно ли что-то еще сделать для использования ccache?

Git

Люди предлагают запустить, например, git -cache-http-server ({ ссылка }) и использовать git config --global url."http://gitcache:1234/".insteadOf https://.

Поскольку особенность может читать части файловой системы хоста, я думаю, может быть даже способ заставить ее работать без прокси-программы. Однако, если репозитории хоста git не находятся внутри $HOME или /tmp, как сингулярность может получить к ним доступ во время сборки? singularity build не имеет флага --bind для указания дополнительных каталогов монтирования. А использование раздела %files в рецепте звучит неэффективно - копировать все при каждом запуске сборки.

APT

Люди предлагают использовать, например, squid-deb- прокси (https://gist.github.com/dergachev/8441335). Опять же, поскольку Singularity может читать файлы файловой системы хоста, я хотел бы просто использовать хост /var/cache/apt. Но /var по умолчанию не монтируется в контейнер. И снова тот же вопрос - как мне смонтировать /var/cache/apt во время сборки контейнера. И в целом это хорошая идея? Разве это не повредит APT-кеш хоста, учитывая, что и хост, и контейнер основаны на одной и той же версии Ubuntu и одной архитектуры?

Или сингулярность сама делает какое-то умное кеширование APT? Я только что заметил, что он загрузил 420 МБ пакетов за 25 секунд, что возможно при моем подключении, но не очень вероятно, учитывая стандартную скорость зеркал ubuntu.

Изменить: я создал выпуск по сингулярному репо: https://github.com/hpcng/singularity/issues/5352.

Ответы [ 3 ]

1 голос
/ 09 июня 2020

Звучит как ненужная оптимизация. Как уже упоминалось, вы можете создать изображение из Docker, которое может использовать некоторое кеширование слоев. Если вы планируете много итераций, вы можете либо сделать это с базовым контейнером docker, либо создать образ сингулярности как песочницу и записать его в доступный только для чтения SIF, когда он будет работать так, как вам нравится. Если вы часто вносите изменения в код, вы можете подключить исходный код при запуске образа, пока он не будет завершен.

Singularity выполняет некоторое кэширование в ОС хоста, по умолчанию $HOME/.singularity/cache (обычно в /root, поскольку в большинстве случаев это sudo singularity build ...). Вы можете увидеть более подробную информацию, используя singularity --verbose или singularity --debug. Я считаю, что это в основном предназначено для кеширования изображений / слоев из других форматов, но я не рассматривал это слишком подробно.

Сборка не монтирует файловую систему хоста и не может быть настроена для этого, чтобы насколько мне известно. Это сделано для воспроизводимости. Вы могли копировать файлы (например, apt cache) в изображение в блоке %files, но это кажется очень хакерским sh и, в конечном итоге, сомнительно, что это было бы быстрее, открывая возможность для некоторых странных ошибки.

Шаги %post построены изолированно в контейнере, и ничего не смонтировано, так что опять же он не сможет воспользоваться никаким кешированием в ОС хоста .

1 голос
/ 30 мая 2020

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

Существует проблема GitHub по этому поводу, когда один из основных разработчиков Singularity дал следующий ответ:

Вы можете построить контейнер Singularity из существующего контейнера на диске. Таким образом, вы можете создать свой базовый контейнер и сохранить его, а затем изменить файл def для сборки из существующего контейнера, чтобы сэкономить время при создании прототипа.

Но поскольку Singularity не создает слои, это действительно невозможно реализовать как Docker.

Один момент по поводу вашего вопроса:

Я знаю, что могу сэкономить время, создавая их слой за слоем

Singularity не имеет концепции слоев, поэтому здесь это не применяется. Docker использует слои, и они кэшируются.

Рабочий процесс, которому я обычно следую при создании образов Singularity, заключается в том, чтобы сначала создать образ Docker из файла Docker, а затем преобразовать его в образ Singularity. Шаг сборки Docker имеет кеширование, так что это может быть вам полезно. 

# Build Docker image
docker build --tag my_image:latest .
# Convert to Singularity format
sudo singularity build my_image.sif docker-daemon://my_image:latest
0 голосов
/ 15 июня 2020

Это показывает, что есть способ использовать некоторые кеши на хосте. Как заявил один из разработчиков сингулярностей , хост /tmp монтируется на этапе %post сборки. И невозможно смонтировать какой-либо другой каталог.

Таким образом, использование кешей хоста - это обеспечение доступа к данным из /tmp.

CCache

Перед запуском build, смонтируйте каталог ccache в /tmp: 

sudo mkdir /tmp/ccache
sudo mount --bind /root/.ccache /tmp/ccache

Затем добавьте следующую строку в %post своего рецепта, и все готово: 

export CCACHE_DIR=/tmp/ccache

Я не уверен, как совместное использование кеша с вашим пользователем, а не root будет работать, но я предполагаю, что документация по совместному использованию кешей может помочь (особенно установка umask для ccache).

APT

На хосте привяжите каталог apt cache: 

sudo mkdir /tmp/apt
sudo mount --bind /var/cache/apt /tmp/apt

В вашем %setup или %post создайте файл-контейнер /etc/apt/apt.conf.d/singularity-cache.conf со следующим содержимым: 

Dir{Cache /tmp/apt}
Dir::Cache /tmp/apt;

Git

git-cache-http-server должен работать без проблем - порты хоста должны быть доступны во время сборки. Я просто не стал им пользоваться, так как он не поддерживает S SH auth. Другой способ - вручную клонировать все репозитории в /tmp, а затем клонировать в процессе сборки с флагом --reference, который должен ускорить клонирование.

...