Organizing Application Files

[00:00:00]
>> Brian Holt: Right now we're just kind of being willy-nilly with our copy statement here. Typically, you'll want to be a little bit more organized with this. You'll put it in your home directory, or your www directory, or something like that. We're gonna put ours in home. Node is the name of the user by default, you can put it in code, index.js, something like that.

[00:00:22]
And then you'll have to make sure that this matches the same thing, and we'll just do build, I'm just gonna call it three again cuz I'm too lazy, and then if I do that again, everything still works. But now it's actually in a better place, which is good.

[00:00:44]
Okay, something else that we wanna do is,
>> Brian Holt: It's not good to use the default user inside your containers, cuz we're trying to exercise caution and be the most secure that we possibly can be. So you don't wanna give them access to the root user or anything like that, there's just a bunch of reasons.

[00:01:05]
Let's say that there's a Python vulnerability that they can get access to whatever user is running your Python process. If you're the root user, they now have root access to whatever box you're on. So you wanna be a bit smarter about that. So we're just gonna say user node.

[00:01:22]
Node is the name of a user that is pre-created on all node containers. That's not necessarily a docker thing, that's a node container specific thing. So this now means that when I run this copy, the owner of this, in Linux terms, is the the node user, which is just a bit more secure than running it as root.

[00:01:49]
I actually think this is done by default, so I think this is actually redundant. But it's always good for you to just denote this is the user that's going to be in charge of this particular file.
>> Speaker 2: So if you want it to be bad and do root, you type in root right there?

[00:02:06]
>> Brian Holt: I don't even know if it'll build, cuz I think you have to build it with special privileges to run root user. I don't know, let's see what happens here. Well, they're getting anatomy From, there's that.
>> Brian Holt: Well, it might just work, right? And then I'm gonna say,
>> Brian Holt: Cuz I wanna see what it actually is.

[00:02:41]
Docker exec and a bash.
>> Brian Holt: And I have to do -it.
>> Brian Holt: So it should be running. You can see here, everything is running as root, which is not awesome. And if I go into home/node/code, and I say, ps aux, it is owned all by root. So, not awesome.

[00:03:21]
Not great, it would be way better if this was all owned by node, right?
>> Brian Holt: So I was wrong. Yeah, you can go ahead and do everything by root. I guess they don't stop you from shooting yourself in the foot. Node is very nice, they just include this node user for you.

[00:03:39]
Not every container is gonna do that for you. It's pretty straightforward to do yourself. Let me just find that, yeah, it's this one right there. So if I went back over to my notes here and I did this, useradd -ms /bin/bash lolcat, and then now I could do a lolcat and now everything will be owned by the user lolcat.

[00:04:10]
Let's just
>> Brian Holt: Okay, and then, just to prove my point here.
>> Brian Holt: Okay, and then if I do this again, I do build it to exec.
>> Brian Holt: So you can see, I'm connected as the lolcat user right there, right off the bat. And if I go in and I say, ps aux, you can see everything is now owned by lolcat, right?

[00:04:59]
>> Brian Holt: So it doesn't have to be the node user, that's just the one that node happens to use. Totally fine to do it that way, you can also just go ahead and create and use your own as well.
>> Brian Holt: Another cool thing that I will frequently do when you do copy here,
>> Brian Holt: You can do --chwon, and then you just put node or lolcat or whatever.

[00:05:28]
We'll get rid of, I'll just do this with node.
>> Brian Holt: And here we go. So this chown or change own, right? You can just identify specifically who you want whatever you're doing to be the owner there as well. This is redundant, right? Because if your user node here, whatever this copy is, is gonna be done by that, but the the flag lets you identify that as well.

[00:06:06]
>> Brian Holt: It's not a big deal that this code directory doesn't exist, COPY by default will create that for you.
>> Brian Holt: A quick note on ADD. So, totally would work as well, I'm pretty sure you could just literally do this and this would work as well. Why do we use COPY instead of ADD?

[00:06:26]
ADD can do a lot more. ADD can add remote URLs. ADD will automatically unzip files for you if you put zips in there. It has some just like additional functionality in there, that almost never do I need. And then. And so I just kinda stick with the least powerful thing, the most comfortable thing to use, which is COPY.

[00:06:48]
So I'm gonna advocate for you to use ADD if you are gonna use one of those extra features, otherwise, just stick to COPY. And, yeah, one more thing, in other words, it's fair to say I never use ADD.
>> Brian Holt: Another fun one here is WORKDIR. And if I just do /home/node/code like that, this will put me like my working directory of wherever I'm copying files and stuff like that, so that I don't have to have fully Manage paths there.

[00:07:24]
And now that my working directory is there, I can just say dot, right?
>> Brian Holt: So that helps as well.
>> Brian Holt: Yeah, it's like as if you had CD'd into that directory.
>> Speaker 2: Does WIRKDIR also apply to the command right at the end
>> Brian Holt: Yes, it does. So you could actually get this down even further to that, make sure that I'm not making stuff up, as I want to do.

[00:07:56]
And I'm gonna say, build
>> Brian Holt: Nope, not what I wanted to do. Docker build that, and then we're gonna run that again. And then let's go look at local host 3000. Yep, and you can see there, working just the way we want, and that has the working directory and the user as well.