Multi Stage Builds Back Story So way back in the beginning of this we briefly discussed layers. Each line in a dockerfile adds a layer. Which means it adds size to the dockerfile.
Lets look at when we added git to our first image.
1 RUN apk update && apk add --no-cache git Its just git. No big deal right? It can’t take that much space. But lets look at all the extra things that happened to add git.
Now we are going to start getting into the weeds of leveraging docker. I think an easy way to start this one would be with a user story. So here we go.
As a developer I would like to have an environment to develop that alleviates the “Works on my box” problem. It should work just the same on my box as it does in production. I shouldn’t be able to install something in my environment that doesn’t exist when I deploy my app to production.
Here is just a huge list of handy docker commands.
So here is how I got my blog all set up. It was a lot of back and forth on how I set this up. So this post is for those that read it. But also for me. It was a lot of work and I want to capture what I did so I can reproduce it later.
I recently made a change to how I work on repositories when I have to work with others. It has been a life saver.
So far we have created a small api that runs in a container. We’ve tested that its working. Worked with environment variables inside the container on the docker run command. Accessed a shell inside the container with the docker exec command. Now I want to talk about the docker build context.
Docker Build Context The most common way to work with the build context is to build an image based on our current path.
We’ve built an image. Now lets make it go vroom!
Lets build our first docker image together
Getting started with docker. In this tutorial we will take a quick run at getting our environment set up in preparation for the rest of the series.