Hello Whale: Layers in Docker

Hello Whale: Layers in Docker

4 min read

In my last “Hello Whale” post, I talked about how containers and VMs are not one in the same. Instead of pip installing various technologies on a VM (often getting more than you actually need), with Docker you can grab the specific parts you require. It’s like putting together the different pieces you need to create the perfect app to your specifications- no extra weight. But what if I told you that Docker images themselves have their own pieces?

Oh My God Wow GIF - Find & Share on GIPHY

Wait, what?

Ok what are these “layer” things?

The first time you pull an image from Docker Hub, it will look like this:

Chloes-MacBook-Pro:~ chloecondon$ docker pull registry
Using default tag: latest
latest: Pulling from library/registry
79650cf9cc01: Pull complete
70ce42745103: Pull complete
77edd1a7fa4d: Pull complete
432773976ace: Pull complete
3234a47fe5a9: Pull complete
Digest: sha256:a3551c422521617e86927c3ff57e05edf086f1648f4d8524633216ca363d06c2
Status: Downloaded newer image for registry:latest

As you can see above, we had to wait for each pull to load. But, have you ever noticed when you’ve pulled an image for a 2nd time, some seem to already be loaded for you?

Chloes-MacBook-Pro:~ chloecondon$ docker pull registry
Using default tag: latest
latest: Pulling from library/registry
Digest: sha256:a3551c422521617e86927c3ff57e05edf086f1648f4d8524633216ca363d06c2
Status: Image is up to date for registry:latest

Believe it or not, this isn’t witchcraft. This is part of the awesomeness that is “layers” in Docker.

If we run…

docker image history YOUR_REPO_NAME:latest

…we’ll see all the layers in this image’s history. Pretty cool huh? We can see the changes that were made, how big they are, and when they were created.

Chloes-MacBook-Pro:~ chloecondon$ docker image history registry:latest
IMAGE CREATED CREATED BY SIZE COMMENT
9d0c4eabab4d 8 days ago /bin/sh -c #(nop) CMD ["/etc/docker/regis... 0 B
<missing> 8 days ago /bin/sh -c #(nop) ENTRYPOINT ["/entrypoin... 0 B
<missing> 8 days ago /bin/sh -c #(nop) COPY file:7b57f7ab1a8cf8... 155 B
<missing> 8 days ago /bin/sh -c #(nop) EXPOSE 5000/tcp 0 B
<missing> 8 days ago /bin/sh -c #(nop) VOLUME [/var/lib/registry] 0 B
<missing> 8 days ago /bin/sh -c #(nop) COPY file:6c4758d509045d... 295 B
<missing> 8 days ago /bin/sh -c #(nop) COPY file:286222b32843a3... 22.8 MB
<missing> 8 days ago /bin/sh -c set -ex && apk add --no-cac... 5.61 MB
<missing> 8 days ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0 B
<missing> 8 days ago /bin/sh -c #(nop) ADD file:9c596c6cb8ba1d7... 4.81 MB

The beauty of layers is that it means less uploading and downloading for you. You know how much I love my visual examples! So here’s another one:

Ninja Turtles Food GIF - Find & Share on GIPHY

This time with 100% more pizza!

Let’s say we had a cheese pizza. We have a base layer of dough, tomato sauce, and cheese. Then I decide I want to have half of my pizza with pepperoni with it. Would I bake another pizza from scratch, make new layers, and add pepperoni to that one? Of course not! I’d just add a layer of pepperoni to half of my existing pizza. No need to go through the trouble of making a whole new base pie. As we make more changes, we create more layers.

 

Ok, now I want pizza.

 

Now, how does this work when a base image gets changed? Well, then Docker uses copy-on-write (or, “cow” ). This means it would take the changed base image and store a copy of it in the container layer. So keeping to our pizza metaphor, we would take out a slice of our pizza from the pie, add some jalapeños on top, and dip the crust in hot sauce. Now our base layer is changed, so we’d save it in its own Tupperware for later (aren’t you just loving these container metaphors?). The purpose of copy-on-write is to not create new resources unless we have to; resources can be shared between the copy and the original in the case of our cheese/pepperoni metaphor. But, when we fundamentally change the base image (by dipping the crust in hot sauce), we need to save it in its own container.

 

Wow I didn’t know I needed this.

Ok, but why would we want to store each layer only once? We’re saving storage space! Not only does this make our host less crowded (avoiding duplicates), but it also saves us time when we are pushing and pulling between registries. So, a container is a layer on top of an image.

https://giphy.com/gifs/dip-layer-IYgMHLSLoWtvW

docker image history 100-layer-dip:latest

The beauty of Codefresh being Docker native is that we are able to cache all the layers, making subsequent builds much faster each time you build. Why spend extra time and build from scratch with another CI when you can get up and running much faster? To learn more about Codefresh, start your free trail today (or, schedule a demo with me!) and see how much time you save.

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

Build your GitOps skills and credibility today with a GitOps Certification.

Get GitOps Certified

Ready to Get Started?
  • safer deployments
  • More frequent deployments
  • resilient deployments