Установка пакета и установка пряжи внутри скрипта ввода - Docker

Question

Я вижу, что bundle install и yarn install обычно выполняются в Dockerfile следующим образом:

RUN bundle install && yarn install

Что означает, что если я изменю Gemfile или yarn.lock, мне нужно заново пересоздать образ , Я знаю, что существует кэширование слоев, и сборка docker не будет перестраивать другие слои, кроме слоя комплекта установки и установки пряжи. Но это значит, что я должен сделать docker-compose up -d --build

Но мне было интересно, можно ли поместить эти команды в сценарий ввода docker -compose или в команду как:

command: bundle install && yarn install && rails s

Таким образом, я считаю, что всякий раз, когда я выполняю docker-compose up -d, bundle install и yarn install, будут выполняться без необходимости создания образа.

Не уверен, что он имеет какие-либо преимущества по сравнению с обычной установкой пакета в Dockerfile, за исключением того, что не нужно добавлять --build в docker-compose up. Исправьте, что если я сделаю это, установка пакета и установка пряжи будут выполняться, даже если нет никаких изменений в файлах Gemfile или Yarn. Я думаю, это одна из плохих сторон.

Пожалуйста, поправьте меня, если это не идеальный путь к go.

Новичок в docker мире.

Answer 1

Это тратит несколько минут времени и использует пропускную способность сети при каждом запуске приложения. Когда вы занимаетесь локальной разработкой, это будет эквивалентно этому, каждый раз, когда вы запускаете приложение:

rm -rf vendor node_modules
bundle install              # from scratch
yarn install                # from scratch
bundle exec rails s

Основная часть Docker - это перестройка образов (так же, как языки типа Go, Java, Typescript, et c. имеют фазу "сборки"). Попытка избежать перестройки изображения обычно не рекомендуется. С хорошо написанным Dockerfile, и особенно для интерпретируемого языка, выполнение docker build должно быть достаточно эффективным.

Один важный трюк состоит в том, чтобы отдельно копировать файлы, которые определяют зависимости, и остальную часть вашего приложения. Как только инструкция Dockerfile COPY обнаружит измененный файл, она отключит кэширование слоев для остальной части приложения. Поскольку зависимости изменяются относительно редко, последовательность, которая сначала копирует файл зависимостей, затем устанавливает зависимости, а затем копирует приложение, может перейти прямо к последнему шагу, если файл зависимостей не изменился.

COPY Gemfile Gemfile.lock ./
RUN bundle install

COPY package.json yarn.lock ./
RUN yarn install

COPY . ./

( Обязательно включите каталог Bundler vendor и каталог node_modules в файл .dockerignore, чтобы последний шаг COPY не перезаписывал ранее установленное.)

Answer 2

Этот вопрос основан на мнении. Как вы уже узнали сами, распространенной практикой является установка зависимостей (связка, пряжа и т. Д.) В процессе сборки образа, а не в процессе запуска образа.

Обоснование заключается в том, что вы run больше раз чем вы build, и вы хотите, чтобы операция запуска начиналась быстро.

Так же, как вы делаете apt install... или yum install... на этапе сборки, вы обычно должны делать bundle install в Этап сборки также.

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

Еще одно замечание о docker слоях: если изменится Gemfile, изменится не только слой, который ссылается на него, но все последующие слои также. По этой причине часто принято отделять копию манифеста зависимостей (Gemfile.*) от копирования приложения, например:

# Pre-install gems
COPY Gemfile* ./
RUN gem install bundler && \
    bundle install --jobs=3 --retry=3 

# Copy the rest of the app
COPY . .

Таким образом, если файлы приложения изменятся, но не зависимости, сборка будет быстрее.