Why would you copy your Gemfile.lock into Docker, then immediately overwrite it?

Question

Why would you copy Gemfile.lock, run bundle install to create a new Gemfile.lock, then immediately copy the current directory which contains the original Gemfile.lock and overwrite the Gemfile.lock that was just created by Bundler within the Docker container?

Also why can you get away with not having EXPOSE 3000?

https://docs.docker.com/compose/rails/#define-the-project

FROM ruby:2.3.3
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs
RUN mkdir /myapp
WORKDIR /myapp
COPY Gemfile /myapp/Gemfile
COPY Gemfile.lock /myapp/Gemfile.lock
RUN bundle install
COPY . /myapp

That isn't the only place it does that. It's also done here, which seems pretty official. Maybe I'm missing a fundamental aspect of Docker?

https://hub.docker.com/_/ruby/

COPY Gemfile Gemfile.lock ./
RUN bundle install

COPY . .

Answer 1

More a guess than an answer, but sometimes you order the steps in Dockerfiles slightly differently to improve the caching mechanism. When you change things in your application, it's less likely that it will affect the Gemfiles, so you don't have to do a bundle install after everything you change. Ordering the steps in this way avoids having to execute bundle install for changes to your application that do not affect the Gemfiles.

Documentation on build caching: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#build-cache