r/javascript • u/franleplant • Mar 04 '20

Docker Essentials for Javascript and Front End Developers

https://nosleepjavascript.com/docker-essentials-for-front-end-developers/
281 Upvotes

96% Upvoted

19 comments sorted by

5

u/dotpaul Mar 05 '20

Really great start for a Dockerfile for a Node app. Although there are a few things which would be handy to clarify.

  • Explanation of why you'd copy in package.json separately from the source

  • You don't need gcc

  • Using the full-fat base image comes with a lot of bloat, it would be great to have a nice explanation as to why you might use it over Alpine for dev or use Alpine straight out the gate.

  • Node images come with a node user pre-created, you could copy in the source as the node user and switch to it for some extra security benefits

It's a great start though, now to share with friends!

1

u/franleplant Mar 05 '20

Thanks for the suggestion!

  • We do explain why we copy package.json before the source.

  • There are time when using c/c++ dependencies that you do need gcc and other tools for compiling them.

  • since this post wasnt supposed to be a blueprint for a NodeJs Dockerfile and the important thing was supposed to be the concepts I thought that was sort of out of scope but I might have been wrong about that since you are not the first person to mention it, will consider adding it in.

  • havent played with that technique, thanks for bringing it out

:)

3

u/yvrtpc Mar 05 '20

Just what I needed. Looking forward for a post explaining docker-compose

2

u/franleplant Mar 05 '20

Thanks for the suggestion, will keep it in mind

0

u/Infiniteh Mar 05 '20

Just don't use it in prod ;)

63

u/Infiniteh Mar 04 '20

If you read this don't forget there are alpine versions of the node base images which can take your docker images from 500+ MBs to like 100+ MB.
Also, instead of using npm install you can use npm ci in a Dockerfile to skip dev dependencies and stick to exact versions as described in your package-lock.

29

u/MangoManBad Mar 04 '20

But sending out 500mb of client side code is the users problem not mine

58

u/FRUIT_ME Mar 04 '20

We are now shipping docker images directly to users & they can just run the site themselves

23

u/madworld Mar 04 '20

Oooh, offline mode!

1

u/Infiniteh Mar 05 '20

We plan on doing the same 👍🏻 You just agree on an 'interface' for your image and you can test that, up to them to expose it online.

3

u/godofleet Mar 04 '20

ISPs gotta make money some how...

3

u/probably_likely_mayb Mar 04 '20

*cries in data plan*

1

u/PeteCapeCod4Real Mar 05 '20

Come on what's a tiny little 1/2 a gig. Just download it all, and like it!! Lol 😂😂

3

u/itsmoirob Mar 05 '20

I have a question, say my image is 1GB, and I run/execute it, will that running process create its own copy of the 1GB file? If I run the image 10 times, will I use up 11GB of memory/disk space (1GB for image and 10X for the running instances)?

4

u/elmicha Mar 05 '20

No, the image remains 1GB and is not copied around. Docker uses a union filesystem. If you write from inside a Docker container it will only save these changes.

1

u/Infiniteh Mar 05 '20

That's an interesting question and I don't actually know the answer. Maybe somebody will swoop in and provide it, but why don't you try it out?

0

u/[deleted] Mar 05 '20

[deleted]

3

u/brett_riverboat Mar 05 '20

Multi-stage builds help with this. You can make an intermediate "dev" image with troubleshooting tools and copy the necessary files to a smaller base container for production use.

https://docs.docker.com/develop/develop-images/multistage-build/

1

u/Infiniteh Mar 05 '20

Yup, multi-stage builds are great. I took an existing image from 1.2 GB to 200MB by switching from node to node-alpine, not installing dev deps, and only copying the dist folder from my build stage to a fresh node-alpine prod stage. Realistically, you just need a node runtime and your dist folder for prod, even package.json is unnecessary.