One common best practice when building Docker images is placing the layers that do not change often as close to the top of the Dockerfile as possible, so for me the next few instructions are the following: EXPOSE 3000ĬMD ĮNV PATH $GEM_HOME/bin:$BUNDLE_PATH/gems/bin:/usr/lib/fullstaq-ruby/versions/$RUBY_VERSION/bin:$' /opt/google/chrome/google-chrome \
#Speed up docker for mac install#
Fullstaq Ruby provides some packages we can install in Debian to get up and running with Ruby, so that’s what we will be doing. The easiest way I found to achieve this is with Fullstaq Ruby, a version of Ruby that includes jemalloc and other optimisations that make it lighter and often faster. The reason is that I prefer using a version of Ruby that takes advantage of jemalloc to reduce the memory consumption significantly. One thing you may be wondering is why I am using Debian-slim instead of the official Ruby image.
You can customise both depending on your app and how you would like your dev environment to look. We are also specifying which packages are required for building stuff, and which packages are always required - this one will be identical in the prod Dockerfile.
Here we are setting the version of Ruby we want to install, as well as the s3 settings (also as build args do NOT add these directly to the Dockerfile or these secrets will be persisted in the Docker image) that we need to download/upload the cached bundle and assets from/to s3. The very first lines of this Dockerfile specify Debian-slim as the base image, as well as some build args: FROM debian:buster-slimĪRG S3_ENDPOINT=s3.ĪRG BUILD_PACKAGES="build-essential yarn git-core vim tmux unzip python3-pip python3-setuptools zlib1g-dev libssl-dev"ĪRG REQUIRED_PACKAGES="fullstaq-ruby-$RUBY_VERSION fullstaq-rbenv nodejs tzdata imagemagick libpq-dev" Let’s build the first Dockerfile, which we’ll call v, one step per time. The dev/CI Dockerfileįor my app, I am currently using two Dockefiles: one for development and test/CI builds, and the other for production which is based on the first Dockerfile and makes use of multi stage builds. Debian-slim may not have as small as footprint as Alpine, but it’s still quite small as base image and works basically with everything without hacks and workarounds, so for now I will stick with it and I suggest you do too unless you are paranoid about image size.įor this post, I will assume some familiarity with Docker and Docker builds, so I am going to skip the basics. It is a fact that Alpine makes for faster builds and much smaller images out of the box, however at times I’ve had to fight with incompatibilities or other issues due to musl-C being the libc of choice.
#Speed up docker for mac mac#
For example, in my case I build images both on my Mac and in CI/CD with Github Actions.įor the base OS image I have been switching between Alpine and Debian/Ubuntu every now and then, but I think I finally settled on Debian-slim. An additional benefit of using an external storage for this caching, is that the cache is shared between multiple environments. Using the same trick, we will also cache precompiled assets, so to speed up that step as well whenever we change static assets.
#Speed up docker for mac how to#
We’ll see how to optimise image layer caching, as well as how to reduce the image size where possible speaking of the caching, we’ll also see how to leverage an external storage (I use Wasabi, an affordable s3 compatible storage service) to cache the gem bundle this way, if we make changes to the Gemfile, we won’t be able to benefit from the layer caching but we can use a bundle cached on s3 so we only need to install new gems, instead of installing everything from scratch - which can slow down our builds considerably in fact, downloading a compressed bundle from s3 and using that to only install new gems, is typically a lot faster than reinstalling the whole bundle. In this post I would like to share some tips re: building Docker images, especially for Rails apps. Since I started using Docker and Kubernetes for my apps, I have been trying to optimise the way my images are built, so to make the builds as fast as possible while keeping the images as small as possible at the same time.
0 kommentar(er)
