From 44814868a62c990a258c7d5b369fe06bd14db9f8 Mon Sep 17 00:00:00 2001 From: Yoni Date: Sun, 14 Jun 2020 21:36:25 +0300 Subject: [PATCH 1/2] Generic advice - 1st draft --- README.md | 11 +++++------ sections/docker/generic-tips.md | 29 +++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+), 6 deletions(-) create mode 100644 sections/docker/generic-tips.md diff --git a/README.md b/README.md index 2d87bcd6..c97bc8ee 100644 --- a/README.md +++ b/README.md @@ -1233,11 +1233,10 @@ Bear in mind that with the introduction of the new V8 engine alongside the new E ## ![✔] 8.16. Generic Docker practices -**TL;DR:** +**TL;DR:** This is a collection of Docker advice that is not related directly to Node.js - the Node implementation is not much different than any other language. Click read more to skim through. -**Otherwise:** -🔗 [**Read More: Generic Docker practices**](/sections/docker/file.md) +🔗 [**Read More: Generic Docker practices**](/sections/docker/generic-tips.md)


@@ -1320,9 +1319,9 @@ 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) | [Kevyn Bruyere](https://github.com/kevynb) | ### Past collaborators diff --git a/sections/docker/generic-tips.md b/sections/docker/generic-tips.md new file mode 100644 index 00000000..de8836ba --- /dev/null +++ b/sections/docker/generic-tips.md @@ -0,0 +1,29 @@ +[✔]: ../../assets/images/checkbox-small-blue.png + +# Common Node.js Docker best practices + +This common Docker guidelines section contains best practices that are standardized among all programming languages and have no special Node.js interpretation + +## ![✔] Prefer COPY over ADD command + +**TL;DR:** COPY is safer as it copies local files only while ADD supports fancier fetches like downloading binaries from remote sites + +## ![✔] Avoid updating the base OS + +**TL;DR:** Updating the local binaries during build (e.g. apt-get update) creates inconsistent images every time it runs and also demands high privilige. Instead use base images that are relatively updated + +## ![✔] Tag images using labels + +**TL;DR:** Providing meta-data for each image might help Ops professional treat it adequately. For example, include the maintainer name, build date and other information that might prove useful when someone need to reason about an image + +## ![✔] Use unprivileged containers + +**TL;DR:** Privileged container have the same permissions and capabilities as the root user over the host machine. This is rarely needed and as a rule of thumb should be avoided + +## ![✔] Inspect and verify the final result + +**TL;DR:** Sometimes it's easy to overlook side effects in the build process like leaked secrets or unnecessary files. Inspecting the produced image using tools like [Dive](https://github.com/wagoodman/dive) can easily help to identify such issues + +## ![✔] Perform integrity check + +**TL;DR:** While pulling base or final images, the network might be mislead and redirected to download malicious images. Nothing in the standard Docker protocol prevents this unless signing and verifying the content. [Docker Notary](https://docs.docker.com/notary/getting_started/) is one of the tools to achieve this From 765b84d00008a3871f93927ef264c5f56c1bfd63 Mon Sep 17 00:00:00 2001 From: Yoni Date: Sun, 26 Jul 2020 16:16:15 +0300 Subject: [PATCH 2/2] Fixes --- sections/docker/generic-tips.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sections/docker/generic-tips.md b/sections/docker/generic-tips.md index de8836ba..54570d5c 100644 --- a/sections/docker/generic-tips.md +++ b/sections/docker/generic-tips.md @@ -10,15 +10,15 @@ This common Docker guidelines section contains best practices that are standardi ## ![✔] Avoid updating the base OS -**TL;DR:** Updating the local binaries during build (e.g. apt-get update) creates inconsistent images every time it runs and also demands high privilige. Instead use base images that are relatively updated +**TL;DR:** Updating the local binaries during build (e.g. apt-get update) creates inconsistent images every time it runs and also demands elevated privileges. Instead use base images that are updated frequently -## ![✔] Tag images using labels +## ![✔] Classify images using labels -**TL;DR:** Providing meta-data for each image might help Ops professional treat it adequately. For example, include the maintainer name, build date and other information that might prove useful when someone need to reason about an image +**TL;DR:** Providing metadata for each image might help Ops professionals treat it adequately. For example, include the maintainer name, build date and other information that might prove useful when someone needs to reason about an image ## ![✔] Use unprivileged containers -**TL;DR:** Privileged container have the same permissions and capabilities as the root user over the host machine. This is rarely needed and as a rule of thumb should be avoided +**TL;DR:** Privileged container have the same permissions and capabilities as the root user over the host machine. This is rarely needed and as a rule of thumb one should use the 'node' user that is created within official Node images ## ![✔] Inspect and verify the final result