‫All right. Now that you've learned all about volumes and bind mounts, and why we need to worry about persistent
‫data, let's do something that's a real-world scenario, which is database upgrades.
‫Imagine a situation where you're running a particular version of a database.
‫Let's say postgres, and you're needing to update the patch version because maybe there's a security
‫fix, or a bug fix, or something.
‫Normally on a system, you would just update the software. You'd do a package management system update
‫or upgrade, and it would handle all the updates to the libraries and everything by itself.
‫But how do we do that in a container?
‫Because, if we're trying to follow the best practice of not updating applications in containers, but rather
‫replacing the container with a new version, how do we do that with the database?
‫What you're going to do for this assignment is you're going to use Docker Hub to get you some info around
‫updating the specific version of postgres. We're going to start with you specifically creating a
‫container using version 9.6.1, which is an older version. And you're going to need to create a named volume.
‫You're going to have to lean on Docker Hub's documentation for this, using the official postgres repository.
‫You'll need to go into the Dockerfile for that specific version and learn what the volume path
‫needs to be. Then you can name your volume whatever you want on the left side.
‫But remember that colon on the right side of it, that has to be the path where the actual databases are
‫going to be in the container.
‫Once you've got all that figured out and you started your container, you should start checking
‫the logs to see when it's finished creating the databases and all the startup stuff. Because the first
‫time you start a database container, typically it does a bunch of stuff in the background, like creating
‫the admin user, and a default database, and so on.
‫There will be a point where the logs will stop and then it'll just be running.
‫If you've done it correctly, you'll be able to do a docker volume ls and see the volume listed there,
‫with the name that you gave it, and you should be able to stop that container. Then you're going to create
‫a new container with a new version.
‫It's going to be a very similar command to the first one, only you specify a different version,
‫you'll also make sure you want to specify the samed name volume because it needs to be using the data that
‫you used in the first one.
‫Of course, make sure that you have the first one stopped because both of these can't access the same
‫data at the same time.
‫Once you've started it, then go ahead and check the logs again for that new container.
‫What you should see is that it only has a couple of lines of startup logs because it doesn't have
‫to do all the work of the initial startup.
‫That's kind of how you know it's using the same named volume
‫is that the second time it starts up, it may only have four or five log entries.
‫So this is a real-world scenario.
‫You'll do this if you ever run production databases or anything that you need to keep current.
‫Do note that most database systems don't do major upgrades automatically.
‫It usually requires a tool. With postgres or MySQL, there's a separate tool for each one of them
‫that you have to run.
‫This is really just about upgrading the patch versions or that last number which doesn't require
‫schema changes or any major updates to the data code itself.
‫Like before,
‫if you get stuck, no worries because this is a new thing and it may not be that clear in Docker Hub.
‫If you get stuck at some point and Docker Hub isn't helping you out,
‫just check the next lecture, which is me going through this same exercise as I would do it.
‫Good luck.