Merge pull request #731 from goldbergyoni/kyle_dockersection

2x Docker drafts

README.md

@@ -1115,11 +1115,11 @@ Bear in mind that with the introduction of the new V8 engine alongside the new E
 
 ## ![✔] 8.4. Lint your Dockerfile
 
-**TL;DR:**
+**TL;DR:** Linting your Dockerfile is an important step to identify issues in your Dockerfile which differ from best practices. By checking for potential flaws using a specialised Docker linter, performance and security improvements can be easily identified, saving countless hours of wasted time or security issues in production code.
 
-**Otherwise:**
+**Otherwise:** A Docker image built with errors or performance bottlenecks could result in security issues in production, or differing from best practices to the detriment of the application end user.
 
-🔗 [**Read More: Lint your Dockerfile**](/sections/docker/file.md)
+🔗 [**Read More: Lint your Dockerfile**](/sections/docker/lint-dockerfile.md)
 
 <br /><br /><br />
 
@@ -1164,13 +1164,15 @@ build, while the runtime environment contains only what's necessary. Multi-stage
 
 <br /><br /><br />
 
-## ![✔] 8.9. Don't use "latest" tags, use a digest
+## ![✔] 8.9. Understand image tags vs digests, and use the "latest" tag with caution
 
-**TL;DR:**
+**TL;DR:** The latest tag can be misleading, and is subject to much confusion. Developers are often led to believe that specifying the latest tag will provide them with the most recent image in the repository, however this is not the case. Using a digest guarantees that every instance of the service is running exactly the same code.
 
-**Otherwise:**
+In addition, referring to an image tag means that the base image is subject to change, as image tags cannot be relied upon for a deterministic install. Instead, if a determinstic install is expected, a SHA256 digest can be used to reference an exact image.
 
-🔗 [**Read More: Don't use "latest", use a digest**](/sections/docker/file.md)
+**Otherwise:** A new version of a base image could be deployed into production with breaking changes, causing unintended application behaviour.
+
+🔗 [**Read More: Understand image tags, and use the "latest" tag with caution**](/sections/docker/image-tags.md)
 
 <br /><br /><br />
 

sections/docker/image-tags.md

@@ -0,0 +1,29 @@
+# Understand image tags vs digests, and use the "latest" tag with caution
+
+### One Paragraph Explainer
+
+If this is a production situation, and security and stability are important, then just "convenience" is likely not the best deciding factor.
+
+In addition, the 'latest' tag is Docker's default tag. This means that a developer who forgets to add an explicit tag, will accidentally push a new version of an image as 'latest', which might end in very unintended results if the latest tag is being relied upon as the latest production image.
+
+### Code example:
+
+```bash
+$ docker build -t company/image_name:0.1 .
+# :latest image is not updated
+$ docker build -t company/image_name
+# :latest image is updated
+$ docker build -t company/image_name:0.2 .
+# :latest image is not updated
+$ docker build -t company/image_name:latest .
+# :latest image is updated
+```
+
+### What Other Bloggers Say
+From the blog by [Vladislav Supalov](https://vsupalov.com/docker-latest-tag/):
+> Some people expect that :latest always points to the most-recently-pushed version of an image. That’s not true.
+
+From the [Docker success center](https://success.docker.com/article/images-tagging-vs-digests)
+> 
+
+<br/>

sections/docker/lint-dockerfile.md

@@ -0,0 +1,25 @@
+# Lint your Dockerfile
+
+### One Paragraph Explainer
+
+As our core application code is linted to conform to best practices and eliminate issues and bugs before it could become a problem, so too should our Dockerfiles. Linting the Dockerfile means you can ensure that there aren’t any structural problems with the logic and instructions specified in your Dockerfiles.
+
+<br/>
+
+### Code example:
+The Open Source Dockerfile linter [Hadolint](https://github.com/hadolint/hadolint) can be used manually or as part of a CI process to lint your Dockerfile/s. Hadolint is a specialised Dockerfile linter that aims to embrace the [Docker best practices.](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)
+
+```bash
+hadolint production.Dockerfile
+hadolint --ignore DL3003 --ignore DL3006 <Dockerfile> # exclude specific rules
+hadolint --trusted-registry my-company.com:500 <Dockerfile> # Warn when using untrusted FROM images
+```
+
+### What Other Bloggers Say
+
+From the blog by [Josh Reichardt](https://thepracticalsysadmin.com/lint-your-dockerfiles-with-hadolint/):
+> If you haven’t already gotten in to the habit of linting your Dockerfiles you should.  Code linting is a common practice in software development which helps find, identify and eliminate issues and bugs before they are ever able to become a problem.  One of the main benefits of linting your code is that it helps identify and eliminate nasty little bugs before they ever have a chance to become a problem.
+
+From the blog by [Jamie Phillips](https://www.phillipsj.net/posts/hadolint-linting-your-dockerfile/)
+> Linters are commonly used in development to help teams detect programmatic and stylistic errors. Hadolint is a linter created for Dockerfiles using Haskell. This tool validates against the best practices outlined by Docker and takes a neat approach to parse the Dockerfile that you should checkout. It supports all major platforms, and this tutorial will be leveraging the container to perform the linting on an example Dockerfile.
+<br/>