diff --git a/.all-contributorsrc b/.all-contributorsrc index 6e3f96d7..4e26b3f5 100644 --- a/.all-contributorsrc +++ b/.all-contributorsrc @@ -933,6 +933,33 @@ "contributions": [ "content" ] + }, + { + "login": "byeze", + "name": "Ezequiel", + "avatar_url": "https://avatars1.githubusercontent.com/u/7424138?v=4", + "profile": "https://github.com/byeze", + "contributions": [ + "translation" + ] + }, + { + "login": "juaoose", + "name": "Juan José Rodríguez", + "avatar_url": "https://avatars3.githubusercontent.com/u/994594?v=4", + "profile": "https://github.com/juaoose", + "contributions": [ + "translation" + ] + }, + { + "login": "OrBin", + "name": "Or Bin", + "avatar_url": "https://avatars1.githubusercontent.com/u/6897234?v=4", + "profile": "https://github.com/OrBin", + "contributions": [ + "content" + ] } ], "projectName": "nodebestpractices", diff --git a/README.md b/README.md index c1801693..7b7c5be4 100644 --- a/README.md +++ b/README.md @@ -259,7 +259,7 @@ function someFunction() { } // Avoid -function someFunction() +function someFunction() { // code block } @@ -995,7 +995,7 @@ All statements above will return false if used with `===` **TL;DR:** Any step in the development chain should be protected with MFA (multi-factor authentication), npm/Yarn are a sweet opportunity for attackers who can get their hands on some developer's password. Using developer credentials, attackers can inject malicious code into libraries that are widely installed across projects and services. Maybe even across the web if published in public. Enabling 2-factor-authentication in npm leaves almost zero chances for attackers to alter your package code. -**Otherwise:** [Have you heard about the eslint developer who's password was hijacked?](https://medium.com/@oprearocks/eslint-backdoor-what-it-is-and-how-to-fix-the-issue-221f58f1a8c8) +**Otherwise:** [Have you heard about the eslint developer whose password was hijacked?](https://medium.com/@oprearocks/eslint-backdoor-what-it-is-and-how-to-fix-the-issue-221f58f1a8c8)

@@ -1105,7 +1105,7 @@ Bear in mind that with the introduction of the new V8 engine alongside the new E **TL;DR:** When using a Docker run time orchestrator (e.g., Kubernetes), invoke the Node.js process directly without intermediate process managers or custom code that replicate the process (e.g. PM2, Cluster module). The runtime platform has the highest amount of data and visibility for making placement decision - It knows best how many processes are needed, how to spread them and what to do in case of crashes -**Otherwise:** Container keeps crashing due to lack of resources will get restarted indefinitely by the process manager. Should Kubernetes be aware of that, it could relocate it to a different roomy instance +**Otherwise:** Container keeps crashing due to lack of resources will get restarted indefinitely by the process manager. Should Kubernetes be aware of that, it could relocate it to a different roomy instance 🔗 [**Read More: Let the Docker orchestrator restart and replicate processes**](/sections/docker/restart-and-replicate-processes.md) @@ -1133,7 +1133,7 @@ Bear in mind that with the introduction of the new V8 engine alongside the new E


-## ![✔] 8.6. Shutdown smartly and gracefully +## ![✔] 8.6. Shutdown smartly and gracefully **TL;DR:** Handle the process SIGTERM event and clean-up all existing connection and resources. This should be done while responding to ongoing requests. In Dockerized runtimes shutting down containers is not a rare event, rather a frequent occurrence that happen as part of routine work. Achieving this demands some thoughtful code to orchestrate several moving parts: The load balancer, keep-alive connections, the HTTP server and other resources @@ -1296,14 +1296,25 @@ Full Stack Developer & Site Reliability Engineer based in New Zealand, intereste
+ + +[Kevyn Bruyere](https://github.com/kevynb) + + +Independent full-stack developer with a taste for Ops and automation. + +
+ +### Steering Committee Emeriti + [Sagir Khan](https://github.com/sagirk) - + -Deep specialist in JavaScript and its ecosystem — React, Node.js, MongoDB, pretty much anything that involves using JavaScript/JSON in any layer of the system — building products using the web platform for the world’s most recognized brands. Individual Member of the Node.js Foundation, collaborating on the Community Committee's Website Redesign Initiative. +Deep specialist in JavaScript and its ecosystem — React, Node.js, TypeScript, GraphQL, MongoDB, pretty much anything that involves JS/JSON in any layer of the system — building products using the web platform for the world’s most recognized brands. Individual Member of the Node.js Foundation.
@@ -1313,11 +1324,11 @@ Thank you to all our collaborators! 🙏 Our collaborators are members who are contributing to the repository on a regular basis, through suggesting new best practices, triaging issues, reviewing pull requests and more. If you are interested in helping us guide thousands of people to craft better Node.js applications, please read our [contributor guidelines](/.operations/CONTRIBUTING.md) 🎉 -| | | | -| :---------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------: | -| [Ido Richter (Founder)](https://github.com/idori) | [Keith Holliday](https://github.com/TheHollidayInn) | [Kevyn Bruyere](https://github.com/kevynb) | +| | | +| :---------------------------------------------------------------------------------------------------------------------: | :--------------------------------------------------------------------------------------------------------------------------------: | +| [Ido Richter (Founder)](https://github.com/idori) | [Keith Holliday](https://github.com/TheHollidayInn) | -### Past collaborators +### Collaborator Emeriti | | | :-------------------------------------------------------------------------------------------------------------------------: | @@ -1468,6 +1479,11 @@ Thanks goes to these wonderful people who have contributed to this repository!
Dmitry Nikitenko
🖋
bushuai
👀 🖋
Benjamin Gruenbaum
🖋 +
Ezequiel
🌍 +
Juan José Rodríguez
🌍 + + +
Or Bin
🖋 diff --git a/assets/images/anchore-report.png b/assets/images/anchore-report.png new file mode 100644 index 00000000..d733c438 Binary files /dev/null and b/assets/images/anchore-report.png differ diff --git a/assets/images/members/kevyn.png b/assets/images/members/kevyn.png index bd97c1d2..a99f56e1 100644 Binary files a/assets/images/members/kevyn.png and b/assets/images/members/kevyn.png differ diff --git a/sections/docker/docker-ignore.md b/sections/docker/docker-ignore.md index f7e75463..37ab9bd0 100644 --- a/sections/docker/docker-ignore.md +++ b/sections/docker/docker-ignore.md @@ -4,7 +4,7 @@ ### One Paragraph Explainer -The Docker build command copies the local files into the build context environment over a virtual network. Be careful - development and CI folders contain secrets like .npmrc, .aws, .env files, and other sensitive files. Consequently, Docker images might hold secrets and expose them in unsafe territories (e.g. Docker repository, partners servers). In a better world the Dockerfile should be explicit about what is being copied. On top of this include a .dockerignore file that acts as the last safety net that filters out unnecessary folders and potential secrets. Doing so also boosts the build speed - By leaving out common development folders that have no use in production (e.g. .git, test results, IDE configuration), the builder can better utilize the cache and achieve better performance +The Docker build command copies the local files into the build context environment over a virtual network. Be careful - development and CI folders contain secrets like .npmrc, .aws, .env files and other sensitive files. Consequently, Docker images might hold secrets and expose them in unsafe territories (e.g. Docker repository, partners servers). In a better world the Dockerfile should be explicit about what is being copied. On top of this include a .dockerignore file that acts as the last safety net that filters out unnecessary folders and potential secrets. Doing so also boosts the build speed - By leaving out common development folders that have no use in production (e.g. .git, test results, IDE configuration), the builder can better utilize the cache and achieve better performance