If you're just here to copy and paste, here's the final Dockerfile that will produce an image for your Express.js app:
FROM node:22.10.0-alpine....
For further actions, you may consider blocking this person and/or reporting abuse
it's also a good practice to switch add
USER nodein the Dockerfile, so as your in-docker runtime was not the root user. If I am not mistaken, you also need to runRUN chown -R node /appso as thatnodeuser had write access to the app.Yes! 100% true
Great One Jonas!
Thanks:)
Good one! :-) Any thoughts on express vs h3? 👀
I don't think I've ever used h3, but the website is sleek so it must be good xD
One basic question always bother me.
Let's say I want to deploy my NodeJs project on hostinger vps, so without using docker approach I will install NodeJs MySQL express etc and then I will pull code from my repo and install dependency and then start pm2.
But Now let's say my manager asked me to implement docker, I will create the docker image then container and then let say I deployed that container, now what?
Now that container contain my entire code?
Like I won't need pull from the GitHub to bring my whole code into my VPS?
Or I would just run docker there?
Means I won't be having code on server? Just docker file or what?
I had the same question when I first was introduced to docker. What is it good for? As a front end developer doing react its not really important. As a full stack developer it opens doors.
Question:
"Now that container contain my entire code?"
Answer:
Yes and no.
Once you build your docker image, think of that like your build of a computer operating system with all its dependencies. You aren't going to build a whole windows operating system with hardware drivers, microsoft office, email etc. You are building the equivalent of a node dist folder ( but - for full stack, not just front end code ). The bare minimum of production ready dependencies.
1 Dockerfile = build image
You might build nginx and react app in one Dockerfile because nginx is going to serve the static build content of your react production code.
2 Dockerfiles = 2 build images, that will communicate with each other over docker network.
You might build nextjs server which runs on port 3000 and nginx which runs on port 80. Nginx is reverse proxy to nextjs server because they run on separate ports. Here you have two separate Dockerfiles images built but a docker compose file which works them together, or if you were deploying these to a cloud service like aws, intead of a docker compose file you have a task definition file respectively.
Answer yes:
Yes it contains your build image.
Yes it does once you built your image:
docker build myproject . -t myproject:versionXmyproject:versionX contains all your "BUILD" code per Dockerfile. That can be deployed to the docker registry.
Answer no:
That being said, all that above is your deployed code. You still need to store your development code.
Question:
"Like I won't need pull from the GitHub to bring my whole code into my VPS?"
No. You may have built your production code and stored that in docker registry or other cloud hosting space like amazon ecr, but you have not stored your development code. Ie your Dockerfile and all your development code. That all needs to be under revision control.
Question:
So why use docker at all?
Dockerfile does a few things:
npm run myscript -- --someEnvVar value, docker does similardocker run myImage env someEnvVar myImg:versionI hope I answered the question.
nice reply! thanks for the long explanation, i hope that helps Saqib:)
Hi! Your Dockerfile will basically be the description of the steps you did without docker. You would install Nodejs (using a baseimage), copy the code, install dependencies etc the same, but Docker would do that when you build your image. Your image will then contain the final state of your files basically, which you can use to then run a container. Does that make sense?
Nicely done Jonas, but can you deploy some docker-compose file on sliplane?
Thank you, no not yet!
Nice content
Thanks:)
hono > express
fair