1
00:00:04,670 --> 00:00:10,720
‫All right. Now that you've learned all about volumes and bind mounts, and why we need to worry about persistent

2
00:00:10,720 --> 00:00:16,120
‫data, let's do something that's a real-world scenario, which is database upgrades.

3
00:00:16,120 --> 00:00:21,250
‫Imagine a situation where you're running a particular version of a database.

4
00:00:21,250 --> 00:00:28,210
‫Let's say postgres, and you're needing to update the patch version because maybe there's a security

5
00:00:28,210 --> 00:00:30,490
‫fix, or a bug fix, or something.

6
00:00:30,490 --> 00:00:36,730
‫Normally on a system, you would just update the software. You'd do a package management system update

7
00:00:37,030 --> 00:00:41,340
‫or upgrade, and it would handle all the updates to the libraries and everything by itself.

8
00:00:41,650 --> 00:00:43,090
‫But how do we do that in a container?

9
00:00:43,180 --> 00:00:48,700
‫Because, if we're trying to follow the best practice of not updating applications in containers, but rather

10
00:00:48,700 --> 00:00:52,810
‫replacing the container with a new version, how do we do that with the database?

11
00:00:52,810 --> 00:00:58,990
‫What you're going to do for this assignment is you're going to use Docker Hub to get you some info around

12
00:00:59,110 --> 00:01:03,910
‫updating the specific version of postgres. We're going to start with you specifically creating a

13
00:01:03,910 --> 00:01:12,100
‫container using version 9.6.1, which is an older version. And you're going to need to create a named volume.

14
00:01:12,100 --> 00:01:18,820
‫You're going to have to lean on Docker Hub's documentation for this, using the official postgres repository.

15
00:01:19,270 --> 00:01:23,920
‫You'll need to go into the Dockerfile for that specific version and learn what the volume path

16
00:01:23,920 --> 00:01:28,260
‫needs to be. Then you can name your volume whatever you want on the left side.

17
00:01:28,270 --> 00:01:33,040
‫But remember that colon on the right side of it, that has to be the path where the actual databases are

18
00:01:33,040 --> 00:01:34,590
‫going to be in the container.

19
00:01:34,810 --> 00:01:38,680
‫Once you've got all that figured out and you started your container, you should start checking

20
00:01:38,680 --> 00:01:43,390
‫the logs to see when it's finished creating the databases and all the startup stuff. Because the first

21
00:01:43,390 --> 00:01:47,680
‫time you start a database container, typically it does a bunch of stuff in the background, like creating

22
00:01:47,710 --> 00:01:51,810
‫the admin user, and a default database, and so on.

23
00:01:51,820 --> 00:01:55,660
‫There will be a point where the logs will stop and then it'll just be running.

24
00:01:55,660 --> 00:02:02,530
‫If you've done it correctly, you'll be able to do a docker volume ls and see the volume listed there,

25
00:02:02,620 --> 00:02:07,630
‫with the name that you gave it, and you should be able to stop that container. Then you're going to create

26
00:02:07,660 --> 00:02:10,560
‫a new container with a new version.

27
00:02:10,630 --> 00:02:16,300
‫It's going to be a very similar command to the first one, only you specify a different version,

28
00:02:16,310 --> 00:02:22,780
‫you'll also make sure you want to specify the samed name volume because it needs to be using the data that

29
00:02:22,780 --> 00:02:24,420
‫you used in the first one.

30
00:02:24,460 --> 00:02:28,060
‫Of course, make sure that you have the first one stopped because both of these can't access the same

31
00:02:28,060 --> 00:02:29,450
‫data at the same time.

32
00:02:29,680 --> 00:02:33,730
‫Once you've started it, then go ahead and check the logs again for that new container.

33
00:02:34,000 --> 00:02:38,980
‫What you should see is that it only has a couple of lines of startup logs because it doesn't have

34
00:02:38,980 --> 00:02:40,900
‫to do all the work of the initial startup.

35
00:02:40,900 --> 00:02:43,650
‫That's kind of how you know it's using the same named volume

36
00:02:43,660 --> 00:02:48,050
‫is that the second time it starts up, it may only have four or five log entries.

37
00:02:48,310 --> 00:02:50,070
‫So this is a real-world scenario.

38
00:02:50,070 --> 00:02:54,860
‫You'll do this if you ever run production databases or anything that you need to keep current.

39
00:02:55,000 --> 00:03:00,700
‫Do note that most database systems don't do major upgrades automatically.

40
00:03:00,700 --> 00:03:05,470
‫It usually requires a tool. With postgres or MySQL, there's a separate tool for each one of them

41
00:03:05,470 --> 00:03:06,670
‫that you have to run.

42
00:03:06,670 --> 00:03:12,310
‫This is really just about upgrading the patch versions or that last number which doesn't require

43
00:03:12,310 --> 00:03:16,800
‫schema changes or any major updates to the data code itself.

44
00:03:16,870 --> 00:03:18,080
‫Like before,

45
00:03:18,160 --> 00:03:24,400
‫if you get stuck, no worries because this is a new thing and it may not be that clear in Docker Hub.

46
00:03:24,730 --> 00:03:28,120
‫If you get stuck at some point and Docker Hub isn't helping you out,

47
00:03:28,120 --> 00:03:33,180
‫just check the next lecture, which is me going through this same exercise as I would do it.

48
00:03:33,190 --> 00:03:33,550
‫Good luck.