Transcript from the "Tags" Lesson
>> So the next thing that we're gonna be talking about is tags, right? So you can see here on the webpage we're gonna go into Tags, under Docker. And so we've kind of been dancing around the topic a little bit. But I wanna kinda get into depth with what tags are, why you use them, so on and so forth.
[00:00:20] So you can see right there if I do docker run -it node right there and I leave off anything else, any sort of qualifier for that. It implies that you're gonna put on the latest tag, right? And latest is one of the few tags. It's actually like a special tag, right?
[00:00:37] It implies the last one that you publish. That is the latest version of whatever you're doing, right? So this is fine when you're messing around, kinda like what we're doing right now. It's fine to just say, cool, give me the latest, give me whatever the newest version is.
[00:00:50] But whenever you're making your environments or whenever you're doing anything like that, you wanna have it tied to a specific version. Because I'm sure we've all had issues with appendices before where they've half-created and stuff broke, right? We wanna avoid that. That's why in this particular course I've been very careful to give you specific tags to download.
[00:01:13] Now, you might ask, is there any sorta rhyme or reason of how tags are made? And the answer is, not really. It's not like npm, where they're expecting semantic versioning or anything like that. Docker tags are much more loose, right? It's whatever the author decides to name the tags.
[00:01:29] So an example of that would be node:8 right here, right? Let's say I had something that I had an app that dependent on node 8, I can say node:8. And this will give me whatever the latest release of 8 is, which I feel much more comfortable with, rather than the latest of whatever.
[00:01:46] Now, don't do this because Node 8 is deprecated, right? It's no longer in service, right? So it's not getting security fixes or anything like that. But it's still out there. If you needed it, you could do that, okay? So let's go ahead and take a look at the Docker Hub page for that.
[00:02:01] This is the Docker Hub page for the Node container, right? And everyone at any one of these containers are all gonna have some sort of Docker Hub page. So you can see here, these all of the labels that exist for this, right? There are a lot of node containers.
[00:02:16] Now, why is that? You can see here you can request a lot of very specific things, right? So if I come down here, we've been asking for 12 stretch which is this one right there. But you can see there is a lot of different things that all refer to the same thing, right?
[00:02:33] We could've referred to this as erbium-stretch. Because, technically, Node 12 is the erbium release of node. Not that you ever needed to know that. And I totally forgot that until I just read it right now. So it does have a name, not just no one ever calls it that.
[00:02:50] But you could refer it to as LTS stretch which LTS is like, Node 12 is the latest LTS, right, for a Node. Or you could just actually just said node:lts, right? Which have been referred to the LTS of stretch Debian and the LTS of node. I'm still not gonna recommend that though I don't think that's a good idea because as that LTS rolls forward, right, when we move on to Node 14, and Debian 10.
[00:03:17] Or whatever the next version of Debian that's gonna be the next LTS, right? That LTS tag is going to roll along with it, right? And if you build an app and then it's like sitting on the shelf for five years, and then you come back to it that LTS is gonna be very different, right?
[00:03:31] So these are the kinda things you wanna be thinking through is like, how can I capture this moment in time so this doesn't break in the future? That's what you wanna do with containers. But there's other things here, right? There's stretch-slim, right? So so far, we've been downloading the full Debian, right?
[00:03:48] But we could say 12-stretch-slim, and by their definition that there's no special definition of slim but this will give us a more slender version or like a smaller version of Debian, right? In general you wanna have the smallest container possible for several reasons. And there's a whole section on that so we'll get to that later but there's even beyond stretch, right?
[00:04:12] There's Jesse and Buster and these are other versions of Debian as well, right? You can also see here that we can run in Alpine, right? So I can say, give me node colon, Alpine dash, whatever, right? And all those versions exists as well. What else is in there?
[00:04:53] We're moving to Chromium as well. So suffice to say there's a lot of different versions. And so it behooves you and figure out exactly which versions of what that you want, right? To figure out the right tags. I think the one that I gave you is a pretty good one.
[00:05:10] If you give it stretch, right? If there's more security patches that come out later you want those, right? You want those to automatically be incorporated into your containers. That's why it's good dependent to stretch, right? And then I think it's good dependence to 12 because it as minor patch versions come out, you'll probably want those as well.
[00:05:30] But if you wanna mess around with node 13, you can totally do that, right? So you can see there, that's what latest is, right? It's 13.3.0-stretch. In case it wasn't obvious, each one these lines, these are all the same container, right? They're all various tags for the same container.
>> How do you decide which one do you want? I know you mentioned that depends on your needs. But is this some kinda rule of thumb? I know you just mentioned that stretch is good version, but does every container have sort of like, hey, here's kinda the default one.
[00:06:00] When in doubt, pick this one.
>> Yes. So I think there are good rules of thumb for something like this, like a Node container and apply to Ruby or something like that. I would go find the latest LTS for the Linux that I'm on and the latest LTS for the Node or go or whatever I'm on and then tie it to that, right?
[00:06:23] So that's why the 12 stretch cuz of the two latest LTS is for both of those. Now, if I'm just messing around with something, I'll just do latest cuz I wanna play the latest and greatest tech, right? But you don't wanna ship Node 13 right now, right? That's considered the current version of Node, which means that they're experimenting and things like that.
[00:06:41] There's no promises that it's not gonna break or anything like that. So that's why it's good to be on 12 for your production workloads.
>> So [COUGH] when, for example, 12.13.2 comes out, is that another entry in this list or do patches get overwritten or overwrite this kinda list?
>> Cuz it seems like there'd be even more than this if it was every single patch version ever.
>> Yeah so you can definately tie it to a specific patch release if you felt that was importnat. I would not suggest that.
>> Right. I guess I was mostly asking, cuz if you created it with 12.13.1, Do you just want us to say 12, I guess is my question, the major version, and then leave off the minor and patch?
>> Yeah, so if I tied it to 12.10, right, or whatever, we're on right now, 12.13. So if I did 12.13, it would bump up to 0.4, right? But it would not bump up to 12.14, right? It would keep it on 13. So there are more versions here that are not even listed.
>> Okay, thank you.
>> Yep. It's important stuff for you to know, right? It's important stuff to know how to tie it to the correct versions of what you're expecting. And every Docker Page is gonna have these for you. So there are people that would disagree with me, like I do 12 stretch, there are people that would say just do 12.13, right, dash stretch, cuz they would keep it to the same minor version.
[00:08:19] I think everyone would universally agree, it's a good idea to let patches roll forward no matter what, because that means you'll get the security patches. I would assert that I've never had a minor version of Node break what I'm doing. They're pretty good about major versioning with Node, so I have a lot of trust in them.
[00:08:38] And I work with them at Microsoft and they're very careful about it. But it depends on how much you trust the authors of the container, right? If you're based on someone Joe's Crab Shack and Node container right? Then maybe you trust them a bit less, right? It just depends