Мне часто приходится перестраивать образы Docker, и я делаю это внутри хоста, на котором запускаю свои контейнеры. Иногда я замечаю, что это оказывает значительное давление на ЦП, поэтому я подумал, что могу запустить docker build под nice -n19, но, похоже, это не имеет никакого значения с точки зрения того, сколько докеров дает, когда нужно запускать другие процессы.
Я бы предпочел не использовать репозитории Docker Hub, потому что это личные вещи, и я пытаюсь сэкономить каждую копейку, которую могу прямо сейчас. Я также знаю, что могу настроить другую машину в качестве сборки / репозитория - например, я могу использовать машину в офисе, - но я не уверен, как это сделать.
Итак, вопрос: почему nice -n19 docker build ... кажется не очень полезным?
(бонусные баллы за то, что указали мне на документы о том, как настроить мою собственную машину для сборки / репо)
почему хороший -n19 docker build ... кажется не очень полезным?
В docker commands - это клиент демона docker, который запускает процессы, выполняемые в контейнерах. Когда вы отдаете меньший приоритет docker , приоритет самого демона докера не изменяется, поэтому ваша сборка и exec запускаются с приоритетом по умолчанию. Это похоже на то, что более низкий приоритет вашего веб-браузера не означает, что веб-сервер будет обслуживать ваши запросы с более низким приоритетом.
как настроить мою собственную машину для сборки / репо
Для базовой отдельной машины сборки вы можете просто сделать docker export, scp, docker import. Но для более серьезной системы сборки вы можете захотеть запустить частный реестр докеров. Еще несколько полезных документов:
Если у вас есть собственный частный реестр, вы можете выполнить сборку со своей локальной рабочей станции в офисе, а затем использовать docker push и docker pull чтобы загрузить образ докера в свой частный реестр и получить его в любом месте.
Ответ Ли объясняет причину, по которой Докер не nice ваши сборки. Ниже я хотел бы дать вам практическое решение.
Один из способов сделать ваши сборки Docker более щадящими - это определить ресурсоемкие части вашего Dockerfile, а затем просто nice эти части в самом Dockerfile. Это также сделает вашу сборку более щадящей для инфраструктуры удаленной сборки (например, Jenkins CI).
В моем случае я создавал довольно тяжелый контейнер Apache mod_perl с кучей модулей CPAN. Сборка всех этих модулей была дорогостоящей частью, поскольку большая часть кода компилируется с использованием GCC. Во всяком случае, я смог nice этот шаг моей сборки, изменив строку моего Dockerfile с
RUN cpanm --quiet --installdeps --local-lib-contained /perlmod .
к
RUN nice -n19 cpanm --quiet --installdeps --local-lib-contained /perlmod .
Несмотря на то, что это странно и немного взломано, я не уверен, что буду публиковать программное обеспечение с nice в Dockerfile, но вы сказали, что это все равно для личных вещей, так что это, вероятно, подходящее решение.
Вы можете обобщить это на любую другую дорогостоящую операцию в Dockerfile,
Другие примеры:
Python
RUN nice -n19 pip install some_module
Node.js
RUN nice -n19 npm install .
Дорогой этап сжатия
RUN nice -n19 xz some_file.bin