Downloaded 19 times
![Example tini Dockerfile
•Add tini to your Dockerfile, then use
it in CMD (permanent workaround)
>RUN apk add --no-cache tini
>ENTRYPOINT ["/sbin/tini", "--"]
>CMD ["node", "./bin/www"]](https://image.slidesharecdn.com/dcsf19nodejsrocksindockerfordevandops-190626232840/85/DCSF-19-Node-js-Rocks-in-Docker-for-Dev-and-Ops-20-320.jpg)
![Example tini Dockerfile
•Add tini to your Dockerfile, then use
it in CMD (permanent workaround)
>RUN apk add --no-cache tini
>ENTRYPOINT ["/sbin/tini", "--"]
>CMD ["node", "./bin/www"]](https://image.slidesharecdn.com/dcsf19nodejsrocksindockerfordevandops-190626232840/75/DCSF-19-Node-js-Rocks-in-Docker-for-Dev-and-Ops-20-2048.jpg)
Uploaded byDocker, Inc.
DCSF 19 Node.js Rocks in Docker for Dev and Ops
The document outlines best practices for using Node.js with Docker, including guidelines for writing Dockerfiles, managing Node.js processes, and implementing multi-stage builds. It emphasizes proper shutdown procedures, security considerations, and the use of Docker Compose for managing multi-service applications. Additionally, it addresses common issues like handling node_modules in Docker and ensures a solid production checklist for Node.js applications.
More Related Content
Similar to DCSF 19 Node.js Rocks in Docker for Dev and Ops
![UiPath Automation Suite Installation (Hands-On) [2/3]](https://cdn.slidesharecdn.com/ss_thumbnails/automationsuitecommunitysession2-251015095633-a6d862f1-thumbnail.jpg?width=600ounds&width=560&fit=bounds)
DCSF 19 Node.js Rocks in Docker for Dev and Ops
- 1. Bret Fisher Docker Captain,DevOps Dude bretfisher.com/docker Node.js Rocks in Docker
- 2. Who's This SessionFor? •You know some Node •You know some Docker •You want more Node+Docker awesomesauce
- 3. What We Gonna'Learn Bret? •Node Dockerfile Best Practices •Make a real-world multi-stage Dockefile •Build with auditing and sec scans •Proper Node shutdown •Node HTTP connection management
- 4.
- 5. Every Node SampleDockerfile
- 6. Node Base ImageGuidelines •Stick to even numbered major releases •Don't use :latest tag •Start with Debian if migrating •Use stretch (default) not jessie •Try slim first •Move to Alpine later, maybe
- 7. When to useAlpine Images •Alpine is "small" and "sec focused" •But Debian/Ubuntu are smaller now too •~100MB space savings isn't significant •Alpine has its own issues •Alpine CVE scanning fails •Enterprises may require CentOS or Ubuntu/Debian
- 8. Image Sizes fornode/slim/alpine
- 9. Image Sizes fornode/slim/alpine
- 10. node_modules in Images •Problem:we shouldn't build images with node_modules from host •Example: node-gyp •Solution: add node_modules to .dockerignore •copy .gitignore?
- 11. Least Privilege: Usingnode User •Official node images have a node user •But it’s not used until you USER node •Do this after apt/apk and npm i -g •Do this before npm i •May cause permissions issues with write access •May require chown node:node
- 12.
- 13.
- 14.
- 15. Node Process ManagementIn Containers •No need for nodemon, forever, or pm2 on server •We'll use nodemon in dev for file watch later •Docker manages app start, stop, restart, healthcheck •Node multi-thread: Docker manages multiple “replicas” •One npm/node problem: They don’t listen for proper shutdown signal by default
- 16. The Truth AboutThe PID 1 Problem •PID 1 (Process Identifier) is the first process in a system (or container) (AKA init) •Init process in a container has two jobs: • reap zombie processes • pass signals to sub-processes •Zombie not a big Node issue •Focus on proper Node shutdown
- 17. Proper CMD forHealthy Shutdown •Docker uses Linux signals to stop app (SIGINIT/SIGTERM/SIGKILL) •SIGINIT/SIGTERM allow graceful stop •npm doesn't respond to SIGINIT/SIGTERM •node doesn't respond by default, but can with code •Docker provides a init PID 1 replacement option
- 18. Proper Node ShutdownOptions •Temp: Use --init to fix ctrl-c for now •Workaround: add tini to your image •Production: your app captures SIGINIT for proper exit
- 19. Example init command •Runany node app with --init to handle signals (temp solution) >docker run --init -d nodeapp
- 20. Example tini Dockerfile •Addtini to your Dockerfile, then use it in CMD (permanent workaround) >RUN apk add --no-cache tini >ENTRYPOINT ["/sbin/tini", "--"] >CMD ["node", "./bin/www"]
- 21.
- 22.
- 23.
- 25. •Used to trackHTTP connections and send them FIN packets when Node shuts down >https://github.com/hunterloftis/stoppable Better: Connection Tracking
- 26. Multi-stage Builds •Build multipleimages from one file •Those images can FROM each other •COPY files between them •Space + security benefits •Great for "artifact only" •Great for dev + test + prod
- 27. Avoiding devDependencies InProd •Multi-stage can solve this •prod stages: npm i --only=production •Dev stage: npm i --only=development •Optional: Use npm ci to speed up builds •Ensure NODE_ENV is set
- 28.
- 29.
- 30. Building A SpecificStage •To build dev image from dev (last) stage >docker build -t myapp . •To build prod image from prod stage >docker build -t myapp:prod --target prod .
- 31. More Multi-stage: test •Adda test stage that runs npm test •Have CI build --target test stage before building prod •Don’t COPY code into dev stage •Keep it DRY (for COPY and RUN)
- 32.
- 33.
- 34.
- 35. Security Scanning andAudit •Create audit stage for optional build •Consider RUN npm audit •Consider CVE scanner •Only report at first, no failing (most images have at least one CVE vuln)
- 36.
- 37.
- 38.
- 39.
- 40. Compose YAML v2vs v3 •Myth busting: v3 does not replace v2 •v2 focus: single-node dev/test •v3 focus: multi-node orchestration •If not using Swarm/Kubernetes, stick to v2
- 41. Every Node SampleCompose
- 42. node_modules in Bind-Mounts •Problem:we can't just bind-mount node_modules content from host on macOS/Windows (different arch) •Two Potential Solutions
- 43. node_modules in Bind-Mounts •Solution1, common but less flexible: •Bind-mount /app which includes modules •You can't docker-compose up until you've used docker-compose run •node_modules on host is now only usable from container •Never npm install from host
- 44. node_modules in Bind-Mounts •Solution2, more complex but flexible: •Move node_modules up a directory in Dockerfile •Use empty volume to hide node_modules on bind-mount •node_modules on host doesn't conflict
- 45. Bind-Mounting: Performance •On Linux,bind-mounts are native •On macOS add delegated write mode •Slower in Windows, mounting across Samba/SMB •Consider file sync if it gets real bad •Or WSL + Docker
- 46.
- 47.
- 48. File Monitoring andNode Auto Restarts •Use nodemon for compose file monitoring •webpack-dev-server, etc. work the same •If Windows, enable polling •Create a nodemon.json for advanced workflows (bower, webpack, parcel)
- 49. Startup Order andDependencies •Problem: Multi-service apps start out of order, node might exit or cycle •Multi-container dependencies need: •Name resolution (DNS) •Connection failure handling
- 50. Dependency Awareness •depends_on: serviceA needs service B •Fixes name resolution issues with "can't resolve <service_name>" •Only for compose, not Orch •compose YAML v2: works with healthchecks like a "wait for script"
- 51.
- 52.
- 53. Production Checklist •CMD nodedirectly •Build with .dockerignore •capture SIGTERM, properly shutdown •npm ci or npm i --only=production •Scan/audit/test during builds •Healthchecks (readiness/liveness)
- 54.