fix typos, formatting

Author: Xronophobe

chapter_11_ansible.asciidoc

@@ -342,7 +342,7 @@ for.
   but the individual tasks themselves are quite declarative.
   Each one usually has a human-readable `name` attribute.
 
-<2> Each tasks uses an Ansible "module" to do its work.
+<2> Each task uses an Ansible "module" to do its work.
   This one uses the `builtin.apt` module which provides a wrapper
   around the `apt` Debian & Ubuntu package management tool.
 
@@ -462,7 +462,9 @@ and organisations will often run private ones,
 hosted by cloud providers like AWS.
 
 So your process of getting an image onto a server is usually
+
 * Push the image from your machine to the registry
+
 * Pull the image from the registry onto the server.
   Usually this step is implicit,
   in that you just specifying the image name in the format registry-url/image-name:tag,
@@ -658,7 +660,7 @@ But we don't want to hard-code secrets like SECRET_KEY into our Ansible files
 and commit them to our repo!
 
 Instead, we can use Ansible to automate the creation of a secret key,
-and then save it to a file on the server, where it _ill be _relatively_ secure
+and then save it to a file on the server, where it will be _relatively_ secure
 (better than saving it to version control and pushing it to GitHub in any case!)
 
 We can use a so-called "env file" to store environment variables.
@@ -722,36 +724,39 @@ And here's how we use it in the provisioning script:
 ====
 
 <1> We use `ansible.builtin.template` to specify the local template file to use (`src`),
-   and the destination (`dst`) on the server
+   and the destination (`dest`) on the server
 
 <2> `force: false` means we will only write the file once.
     So after the first time we generate our secret key, it won't change.
 
 <3> The `vars` section defines the variables we'll inject into our template.
 
 <4> We actually use a built-in Ansible variable called `inventory_hostname`.
-    This variable woul actually be available in the template already,
+    This variable would actually be available in the template already,
     but I'm renaming it for clarity.
 
 <5> This `lookup('password')` thing I copy-pasted from Stackoverflow.
-    Come on there's no shame in that.
-    
+    Come on, there's no shame in that.
+// CSANAD: the source code may be a little too long. The (5) mark renders on
+//         the next line and it should be at the end of the line of the
+// `secret_key`.
+
 
 NOTE: Using an env file to store secrets is definitely better than committing
     it to version control, but it's maybe not the state of the art either.
     You'll probably come across more advanced alternatives from various cloud providers,
-    or Hashicorp's "vault" tool.
+    or Hashicorp's Vault tool.
 
 
 
-.Idempotency and Declarative Configuration
+.Idempotence and Declarative Configuration
 *******************************************************************************
 
 Infrastucture-as-code tools like Ansible aim to be "declarative",
 meaning that, as much as possible, you specify the desired state that you want,
 rather than specifying a series of steps to get there.
 
-This concept goes along with the idea of "idempotency",
+This concept goes along with the idea of "idempotence",
 which is wanting to get the same result when you run something for the first time,
 vs running it again on later occations.
 // CSANAD: I would rephrase it a little:
@@ -1244,16 +1249,16 @@ Every single aspect of deployment can and probably should be automated.
 Here are a couple of general principles to think about
 when implementing infrastructure-as-code:
 
-Idempotency::
+Idempotence::
   If your deployment script is deploying to existing servers,
   you need to design them so that they work against a fresh installation _and_ against
   a server that's already configured.
-  ((("idempotency")))
+  ((("idempotence")))
 
 Declarative::
   As much as possible, we want to try and specify _what_ we want the state to be on the server,
   rather than _how_ we should get there.
-  This goes hand-in-hand with the idea of idempotency above.
+  This goes hand-in-hand with the idea of idempotence above.
 
 
 *******************************************************************************