Complete Intro to Containers (feat. Docker) Docker Compose & nodemon
Transcript from the "Docker Compose & nodemon" Lesson
>> So let's make this even a little bit nicer developer experience. This is what I would do if this was my particular container. I'd probably write a different dev.docker file but let's just modify this one directly. What we're gonna do here is under here we're gonna say RUN npm install --global.
[00:00:28] Or I'm lazy, so I'll just say npm i -g, Nodemon. And I've heard people say this a million different ways, no demon, no demon. I'm gonna go with nodemon. So it's up to you how you wanna say that nodemon. This basically is a file watcher that will research your node server every single time that it sees a file change.
[00:00:53] So makes it really nice to developers So I'm gonna install that up here. And then down here, instead of saying node, I'm gonna say, nodemon. And this will make a really nice developer experience so we can just be going and writing our server. And then every time that we change our file, we'll click save and everything will just work So right now, we have to stop all this stuff and then restart it every single time that we change a file.
[00:01:22] I would say that's unfun. So now with nodemon, we can make this really fast because I won't have to restart the container every single time that we make our change to the files. So now that we've done that we save to docker file, we're gonna say docker-compose up.
[00:01:37] It should go through and rebuild our container. It doesn't look like it actually rebuilt our container, do we need to do it ourselves? I might be modifying the wrong one, I am, I modified the wrong one. It's due when you have 19 Docker files. All right, sorry. So come into your networking Docker file.
[00:02:03] I'm gonna do that up here. Same thing. RUN npm i -g nodemon, and then down here, nodemon. So that we can restart our development environment every single time that we save a file. Okay, stop our server. You can see that it's creating networks on the fly for us, which is nice.
[00:02:32] And then here we'll restart docker-compose up. So everything should be still working here. And then here, this is a networking, so instead of saying success: true, maybe we're gonna say success: false And I'm not sure this actually ended up rebuilding it, let's check. Yeah, it didn't. So why is that?
[00:03:16] Is there somewhere I can force rebuild? Yeah, let's do that. Okay, so what we're gonna do, is we're gonna say docker-compose up --build because we know we modified our Docker file. It's gonna force it to build the web container for us. Typically, you're not modifying your Docker file very much.
[00:03:48] Usually you write your Docker file and then it's a couple of months before you have to go modify it again. And then once this is built this will work for us. Okay, so, now, this is saying false here. So instead of having to do that whole song and dance, right, typically we'd have to stop docker-compose, docker-compose up, build, wait for the Docker file to build again every single time that we wanna see a change.
[00:04:22] Now, in theory, if I come back. It says false right now right there. If I say true, and I go look here, it should tell me that it restarted maybe. Well, in any case, it's true now. So now this allows us to more rapidly iterate, So you can be like brianIsCool, and that's 100% true.
[00:04:47] And I could refresh now, brianIsCool: true. Very cool, right? Just like me. Again, this is a very kind of scratching the surface. There's a lot more you can do with this. Let's actually do something a little bit fun here as well. So I'm gonna stop this again, wait for this to stop.
[00:05:12] The cool thing about docker compose is if you wanna simulate like running multiple servers at the same to make sure that everything is working correctly, we can say docker-compose up and then I can say --scale web=10. Instead of starting just one web container which is what it was doing before, now it's gonna start ten web containers.
[00:05:38] I don't even know why, it's probably because they're all listening to the same ports. Yes, they're all trying to bind to the same port. Yeah, and so we have to go through and have like a smarter like round-robin way of binding to different ports. Just to show you how this actually would work, let's just.
[00:06:05] If I just got rid of this which means it wouldn't work anymore, but it would start up. There you go. So then it's gonna go and start these various different containers up. And you can see here now I have a bunch of all these different logs flown in from seven different versions of the same web container.
[00:06:31] So if you're a bit smarter about how you're binding into ports and how you're listening, you probably have to have some sort of like load balancer in front of it. So you could do that with like nginx, you could do with like traffic, there is a bunch of things that will do it for you.
[00:06:42] And then it would load balance between all your various different containers. That's a lot more involved than I wanna get right now with Docker compose, but all things are definitely possible here. And it's pretty cool that we just scaled out our service to ten different containers just like that, just for fun.
[00:07:00] Okay, cool. Yeah, ha_proxy would work for here as well.