‫This section is going to be full of lectures and assignments around persistent data.
‫First, we're going to discuss the problems of persistent data and how that even became a problem
‫in the first place.
‫Key concepts there that you need to understand are the idea of immutable infrastructure.
‫And the idea around containers being naturally ephemeral in design.
‫We'll cover those in the first lecture. Then we'll dive into data volumes and how those solve
‫some of our problems around persistent data. Then we'll also dig into bind mounts and how that solves
‫different problems with persistent data. Then we'll end up this section with a couple of assignments
‫around how to preserve database data, while replacing containers for databases. And then also around
‫actually mounting code into a container from the host while you're editing it, so that you can run that
‫code inside the container live. Requirements for this first lecture are just understanding how to
‫run containers, and the container and image concepts we've discussed so far.
‫Until now, you've only worried about what's needed to run a container, not the unique data that might
‫be created once a container is running.
‫Containers are meant to be immutable and ephemeral.
‫Those are just fancy buzzwords for unchanging and temporary, or disposable.
‫The idea here is that we can just throw away a container and create a new one from an image,
‫Right?
‫Then we're not talking about an actual limitation of containers, but more of a design goal, or a best
‫practice.
‫This is the idea of immutable infrastructure where we don't change things once they're running.
‫If a config change needs to happen, or maybe the container version upgrade needs to happen, then we
‫redeploy a whole new container.
‫This gives us huge benefits in reliability and consistency, and making changes reproducible.
‫But there's a tradeoff.
‫What about the unique data that your app will produce? Those databases, or a key value stores, or anything
‫else that your app spits out into a file?
‫Ideally, the containers shouldn't contain your unique data mixed in with the application binaries. This
‫is known as "separation of concerns" and Docker actually gives us a big benefit here.
‫We can update our application by recreating a new container, with an updated version of our app, and ideally,
‫our unique data is still where it needs to be and was preserved for us while our container was recycled.
‫In case you haven't noticed so far, the containers that we've been using, by default, were persistent.
‫Any changes in them actually were kept across restarts and reboots until we removed the container.
‫Just because we stopped the container or restarted the host,
‫doesn't mean the container's file changes go away.
‫It's only when we remove the container that it's UFS layer goes away, but we want to be able to do
‫that at will.
‫This problem of unique data is known in the industry as "persistent data" and until containers,
‫we didn't really have a name for that. Because, well, most things we built were persistent, like you know
‫those old servers that have been running that old app for five or 10 years or longer.
‫Everything was persistent by default.
‫Now in the new world of containers and application auto scaling, persistent data creates a unique
‫problem.
‫Docker has two solutions to this problem,
‫known as "data volumes" and "bind mounts." Docker volumes are a configuration option for a container that
‫creates a special location outside of that container's
‫union file system to store unique data.
‫This preserves it across container removals and allows us to attach it to whatever container we want.
‫And the container just sees it like a local file path.
‫Then there's bind mounts, which are simply us sharing or mounting a host directory, or file, into a container.
‫Again, it will just look like a local file path, or a directory path, to the container.
‫It won't actually know that it's coming from the host.