Check out a free preview of the full Complete Intro to Containers (feat. Docker) course

The "Run a Node.js App" Lesson is part of the full, Complete Intro to Containers (feat. Docker) course featured in this preview video. Here's what you'd learn in this lesson:

Brian explains how to add publishing ports, how to stop a running container, and how to set up a secure user within the container that is different from the root user.


Transcript from the "Run a Node.js App" Lesson

>> So the next thing we're gonna do node-12-stretch. This is running as the root user of the container. In general, don't run things as root. I mean, I think that's kind of a good thing in general just to learn [LAUGH] for system security and stuff like that. If someone takes over your computer and it's being ran as the root user, then they can just do whatever they want to your computer.

So that's kind of the principle of least power right. So you wanna create a user that all that user can do is run your server and can do nothing else, right? So if someone does eventually end up taking over your container, they can only do things that that user is allowed to do.

They can't do root things right? If you're not familiar with what route uses to in Linux, again, this will plot everything out there, so it's probably work, but they're the god of that container, right? That's the gist. So something we could do here is we could say user, Node.

One of the cool things that the node container ships with is that it has another user on it called node, that's build specifically for this purpose. But know that there's nothing special that this is called node and this is called node. It's the creators of this container created a user called node and that you that users in a user group called node to look confusing.

But suffice to say, like, if I start running like a Ruby container, right? There won't necessarily be a Ruby user on that. I don't want that connection to click in your head. That's all I'm trying to say. So now, I think this should work. And this would be executing as the node user.

But any time that we run copy like this, this is still going to copy it as the root user. Which means that this user has no permission to modify or execute or any of that kind of stuff. So we do have to run it. I'm gonna switch those two first of all so that user node comes up here first.

And so we have to do dash dash, and luckily VS code, it's got my back. So you can either do CHOWN or you can do FROM and I'm gonna do CHOWN. And you have to think about the user and the group. So I'm gonna say node:node because the name of the user is node, the name of the group is node.

And so now, this is being copied over and it will be phoned by this user node. I don't know why this is, it's cuz I was doing that. There we go. Okay. So now if I do this run again, or Docker run, build, build, there we go that one.

Everything's all good to go. It's putting a new user node. Check this out. So if I run it again And I say who am I? It's gonna say now node, right? So it's being executed as a node user. But just to kind of like prove my point to if I come back over here and I comment this line out right, and I build it again.

And I say who am I when you expect him to say root right? You're the root user by default?
>> So the user name what's the discover process on that with, will there be the inspect? Command?
>> You could, yeah, you can definitely find out through inspect. I probably just find that through like the documentation on the Docker Hub.

Or in other words, there's not really a specific way of finding that out. Honestly, I probably just do what I showed you which is just run, who am I?
>> Gotcha. Later in the course I'll show you actually how to create users. For example, if you're running it directly out of Ubuntu, they don't have any users created for you, so you have to do it yourself.

It's not very hard, it's basically one command. And I can never remember it, so I always Google it. [LAUGH] Okay, so quick note on copy. There is another command here, which people get confused with, and I just wanted to address that. There's another one, called ADD. And if I did this, you can do the CHON as well with that.

This would also work, right? And actually, At this moment in time, these things do, line seven and line five do exactly the same thing. So ADD has some like extra functionality associated with it. It does work for your local file system. I would say if you're doing stuff like what we're doing right here which just is the local file system.

Use copy, it's safer. It does less, and doing less in general is a better thing for you if it does the thing that you need it to do. However, what's great about ADD is ADD can go out to the network, it can download a file off the network, right?

So if I say add from this particular file, it will go out, download the file, spit it out there. So that's one thing that ADD will do for you. And ADD will also automatically unzip and use it that it gets, right? So if you are a tar, right.

So if I say add this tar, it'll download it and unzip it immediately. Whereas if I had done copy, I'd have to go in there and do a run immediately after that. So if you're doing anything in the network or you need anything on ziip, use ADD. For 100% of everything else use copy.

We won't be using, I don't think we use ADD for the rest of the class but it's good for you to know that it's out there. So the next thing I wanna do is, where's this index.js being copied? The root directory of the project, not very organized. So I'm not gonna suggest that you do that.

So we're gonna add a command right about this and say WORKDIR. And we're gonna put this on home node, right, which is the home directory of the node user. And then I'm gonna just create one on the fly called code, right? I'm gonna put all my code and so home/node/code.

People put it in code people put it in source. Actually source is probably more common. But I am gonna take the code that is on my notes, say, just wherever it is good to put it inside of like the home directory or something like that. Because we know for sure the node user owns its own home directory.

It is good. Good place to put it. So to prove a point here. I'm gonna say pwd and this will tell you, I'm in slash, right? So I'm in the slash directory, but it wasn't before and now if I run docker build again And I run this again, you can see now it's in home node code.

So that means all commands after that will be based in this directory, right? So that's where your working directory Hence, WORKDIR, it's descriptive I suppose. And again, nice thing about WORKDIR, if it doesn't exist, it will just create it for you.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now