Merge remote-tracking branch 'csanad/review--chapter-09-rev2'

Author: hjwp

chapter_09_docker.asciidoc

@@ -406,6 +406,10 @@ TIP: I'm deliberately choosing a different port to run Dockerised Django on (888
 
 I'll use the `--failfast` option to exit as soon as a single test fails:
 
+// CSANAD:  are line breaks necessary below and at other occurrences of
+//          --failfast? it does keep the asciidoc lines of source below 80
+// characters but there are some wider lines elsewhere.
+
 [role="small-code"]
 [subs="specialcharacters,macros"]
 ----
@@ -811,6 +815,16 @@ WARNING: Make sure you use the `-it` flags to the Docker `run`
 *******************************************************************************
 If you've got a container that's "hanging" in a terminal window,
 you can kill it from another one.
+// CSANAD:  `docker stop` would trigger a graceful SIGTERM, `docker kill` sends a SIGKILL.
+//          SIGKILL would terminate the container even when SIGTERM cannot, but it could
+// also result in broken DB, leave the port "in use" or other side effects. I would prefer
+// using `docker stop` over `kill` and mention `kill` in case the container is still stuck.
+//
+// However, if we leave it with just `docker kill`, then maybe we should mention these
+// possible side effects and also the title should reflect it like:
+// "How to Forcefully Stop a Docker Container" (since "How to Kill a Container" may sound a bit
+// harsh...
+
 
 The docker daemon lets you list all the currently running containers
 with `docker ps`:
@@ -1271,7 +1285,7 @@ CMD python manage.py runserver 0.0.0.0:8888
 <1> We run `migrate` using the `--noinput` argument to suppress any little "are you sure" prompts.
 
 
-If we try our FTs again, they all pass!  // JAN: That's not true. One needs to rebuild the Docker image and start a new container
+If we rebuild the image and try our FTs again, they all pass!
 
 
 [role="small-code"]
@@ -1406,7 +1420,7 @@ https://en.wikipedia.org/wiki/Digestive_biscuit[chocolate biscuit].
 .Test-Driving Server Configuration and Deployment
 *******************************************************************************
 
-Tests and small steps some of the uncertainty out of deployment::
+Tests and small steps take some of the uncertainty out of deployment::
     For developers, ops and infra work is always "fun",
     by which I mean a process full of fear, uncertainty and surprises.
     My aim during this chapter was to show that a step-by-step approach

chapter_10_production_readiness.asciidoc

@@ -365,6 +365,15 @@ TIP: Forgetting the `-r` and running `pip install requirements.txt`
     (which is thankfully much more helpful than it used to be).
     It's a mistake I still make, _all the time_.
 
+
+// CSANAD:  It's fine for now, but I would definitely put the requirements under
+//          /tmp and then `rm` it after `pip install`. Also, using a non-privileged
+// user is important, something like:
+//     `adduser --no-create-home --disabled-password todoapp`
+// and then setting the user in the Dockerfile with `USER todoapp`.
+// But we can cover this in a later chapter (the next one looks like a good fit,
+// since it's related to the app being production ready).
+
 Let's do a build & run & test to check everything still works:
 
 [subs="specialcharacters,quotes"]