Check out a free preview of the full Complete Intro to Containers (feat. Docker) course

The "Bind Mounts" Lesson is part of the full, Complete Intro to Containers (feat. Docker) course featured in this preview video. Here's what you'd learn in this lesson:

Brian explains that bind mounts ship files from the host computer into the container. Bind mounts allow access to preexisting development environments, which fast forwards the work of engineers.


Transcript from the "Bind Mounts" Lesson

>> So now we're gonna go into some features in Docker, and I'm gonna just show you the door down to multiple different pathways. And you're welcome to peek in and you can go deeper into these topics, right? Like, for example, networking, that's a real deep rabbit hole that, again, I'm not particularly qualified to talk to you about.

But I'm just gonna show you how to do the basics of networking and then from there you can go and learn more about it. So the first one is, these are relatively similar topics, bind mounts and volumes, but they accomplish relatively different results, let's go with. The idea is that you have some sort of persistent storage between runs, right?

So if I have this container and it does a bunch of stuff and then outputs it to this bind mount or volume, and then I go run that container again, that state will still be there, right? We need some way that we can have this state maintained between runs of containers, right?

Cuz when containers get closed, they drop everything that they had before, right? So, so far, we've been dealing with self contained containers. So, this is normally like this is all you ever want, is just a container that is totally self contained, that runs, does something and disappears, right?

And a big key about this is that we do not wanna have what we call snowflakes. A snowflake is like some special server that you have out running on your production servers. And you've just massaged it and it's like this bespoke artisanal server that has all the proper versions and everything's working correctly.

If it just goes away, your entire system can come down, right? And what happens if that happens, right? Then you have to go back and you have to go recreate all those various different sets to figure out how you got there. And that's problematic, right, because we don't want that necessarily to happen, right?

We don't wanna be subjugated to this bespoke, snowflake service. So that's why containers are great, because you can spin them up and you can close them down, you can spin them up and you can close them down, and that's kind of like the appeal here of containers. So we're trying to avoid snowflakes.

There's the idea of like, you don't want snowflakes and you want what people call cattle, right? And I swear to God, this is not my analogy, but the idea is that you have many cattle and one cow is not any different than the other cow, right? So you just wanna have everything is just exactly the same and you can swap them out and you can replace them and everything else, and that's just fine.

I will go no further into that metaphor, but that's what people say, okay? However, not everything can fit neatly into a container all the time and a really good example of this is databases, right? So I can spin up and down my SQL databases, right? And it's fine that I have various different clients or servers of that right?

But the core data needs to be preserved between runs, right? So if I scale up my database and I have 100 containers running, then I scale down to 10, I don't wanna lose that data, that's the important part, right? So that's why we're gonna get into things called mounts, right?

And the two different kinda mounts that we're gonna talk about today, and I think there's four or five different types. But the two primary, useful ones are going to be bind mounts and volume mounts. So bind mounts are like portals to your host computer, right? So I can say, okay, here's this folder, and this container can see just this folder, right?

And we're gonna mount it in this one particular place and it's bound, right? So anything that container changes shows up on the host computer, anything the host computer changes ends up in the container, right? They're bound together, okay? This can be really useful for things like developer containers, right?

So, if I'm writing code, it needs to execute in a specific kinda container or environment, this is really useful for that, right? Like for example, I don't have a Go installed in my computer, but if I wanted to develop a Go project or run a Go project, right, I could do that with a container.

And then use a bind mount so that anytime I modify the code, it modifies the code inside of the container. So that's where bind mounts are gonna be useful. So, I'm gonna show you how to do this really quickly here with this particular command right here, which you can copy and paste directly off of my notes here.

So let's clear. So I'm inside of my, again, static-assets-project, the one that you just built, right? And I'm gonna do docker run -- mount, right here, right, and then I would do a type= bind. So this is a bind mount, not a volume mount. You're gonna say, the source and this is this pwd, you have to give it a full path, an absolute path as it's called, right?

And I don't wanna type out all of it, so you can do this trick right here, which is "$(pwd)" is like output where I am right now, that's what this does. Or you could just put the whole qualified path if you wanna do that, /build, which is the part that I already built out, right?

And then target, this is where I want it to output within the container, right? So this outputs to the usr/share/nginx/html, that should look familiar to you, right, because that's where we output the build process. And then we're publishing on port 8080, and we're gonna run nginx, and let's just put in 1.17 so that we can be running on a consistent version, okay?

So what do you expect to happen now? I'm actually gonna be running the nginx container directly, right, I'm not building anything on top of it. But we're gonna accomplish the same thing, right, it's still gonna work the exact same way. So now that we've done that, this starts up and now we can still go to 8080, right?

So 8080, and look, it's still running, right? It's running directly from nginx, it's not running from our built container, it's running from nginx, right? But we used a bind mount to mount basically a portal from our file system here and putting that into nginx. So, we'll do more examples of this, but that's like the base of what bind mounts are.

So this is really directly out of my Mac to serve this up into the container. Does it make sense?
>> The build folder is not in the container, it's just sitting like regular folder, and then the container's actually nginx. It's like, okay, I'm gonna go grab that static folder, I'm gonna serve it.

>> Right, cuz I basically tunneled between my Mac and the inside of the container.
>> There's no Docker file involved.
>> There's no additional Docker file involved, correct, yeah, we're just running the nginx container directly off the Docker hub with no changes. Magic. So that's what bind mounts can be useful for is we can mount in stuff like that, right?

Now, would I do this in production versus building my own container? No, I would still build a container because if I build that container, it's totally self contained, I can throw it anywhere. I can put it on Azure, I can put it on AWS, I can say just execute that container.

I don't have to set it up any more than that, it just runs the container and it just works, right? Whereas if I try and accomplish this, I have to like, okay, well, bind mount this, this, this is here and you have to read from this place and a bunch of stuff like that.

It's a bit more snowflaky for that, to use our previous terminology. So, does that makes sense, that makes sense what bind volumes are doing, right? So again, this is quite useful for things like development environments. And that was the last thing I was gonna mention, is you can mount that file to etsy, nginx, nginx.conf.

If you wanna modify the configuration, you could use another bind mount to modify the configuration of nginx and that would totally work as well. To the operating system, like to the container, it cannot tell the difference between a bind mount and just normal files there, right? It just shows up to that container as if it was normally mounted into that file system, which is pretty cool.

So again, I imagine many of you have started at new development jobs and when you walk in the first thing they do is they hand you a read me that's probably about six months out of date, right? And then you have to go and figure out how to set up this development environment step by step and things break, and you have to go ask the senior developer, how do I do this?

It's like, fine, do this, right? Or no one knows, that's the even worse thing, right? I've been there, I imagine many of you have been there. So that's where bind mounts and containers can come together and be very useful to you, right? Because they can just hand you a container, so like, here, this container has everything that you need to get started.

Just bind mount your code into this particular area, say run container, and you have this development environment that someone else has already set up for you. And you can just start coding away and it works on day one. That's kinda the promise of development environments with containers. And, not next section, but the section after that we'll show you how to do that.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now