Schedule a FREE onboarding and start making pipelines fast.

Hello Whale: Layers in Docker

Docker Tutorial | May 23, 2017

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:

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?

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

If we run…

…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.

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:

Delicious Ninja Turtles 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.

Dip Layer GIF - Find & Share on GIPHY

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. 🐳

About Chloe Condon

Developer Evangelist at Codefresh. Hackbright Alumni/Ambassador/Mentor/frequent conference speaker. Former actress, and one of the only humans who can code while singing the entire score of "Pirates of Penzance".

Reader Interactions

Enjoy this article? Don't forget to share.

Comments

Your email address will not be published. Required fields are marked *

Follow me on Twitter