Merge pull request #75 from UoMResearchIT/3rd-pass-b

3rd pass b

episodes/docker-cli-toolkit.Rmd

@@ -156,7 +156,7 @@ Entrypoint: [python /spuc/spuc.py]
 
 or even get them both at the same time:
 ```bash
-docker inspect spuacv/spuc:latest -f "Command: {{.Config.Cmd}}\nEntrypoint: {{.Config.Entrypoint}}"
+docker inspect spuacv/spuc:latest -f $'Command: {{.Config.Cmd}}\nEntrypoint: {{.Config.Entrypoint}}'
 ```
 ```output
 Command: [--units iuhc]

episodes/docker-compose-microservices.Rmd

@@ -47,9 +47,9 @@ To demonstrate the power of Docker Compose and microservices, let's take a look
 
 The [Apperture](https://github.com/UoMResearchIT/apperture) project is a stack of microservices.
 They combine to provide a log-in secure web portal with built in user-management.
-It is maintained by the University of Manchester's Research IT team, and can easily be combined with other stacks to provide them with a log in portal.
+It is maintained by the University of Manchester's Research IT team, and can easily be combined with other stacks to provide them with a login portal.
 
-`Apperture` is comprised primarily of a `docker-compose.yml` file.
+`Apperture` is comprised primarily of a compose file.
 Just like we have been looking at!
 
 The full `docker-compose.yml` file is available [on github](https://raw.githubusercontent.com/UoMResearchIT/apperture/refs/heads/main/docker-compose.yml).
@@ -126,7 +126,7 @@ One of the most powerful features of Docker Compose is the ability to combine st
 There is no reason we cannot combine the Apperture stack with the SPUC stack we have been working with in previous lessons!
 
 This would allow us to protect our SPUC interface with the Apperture portal.
-An important addition!We need to ensure poachers cannot falsely record sightings of the rare yet valuable unicorns!
+An important addition! We need to ensure poachers cannot falsely record sightings of the rare yet valuable unicorns!
 
 This can be achieved by making a couple of changes to the SPUC `docker-compose.yml` file.
 

episodes/docker-compose.Rmd

@@ -105,7 +105,8 @@ spuc-1  |
 ```
 
 So we have our container running! With a couple of interesting bits of output to note:
-- A container was created named `spuc-1`
+
+- A container was created named `docker-intro-spuc-1`. (The directory name is prepended to the container name)
 - A `network` was created for the container - we will dig into what this means later!
 - The tool is running in the foreground, so we can see the output of the tool
 
@@ -147,7 +148,7 @@ $ docker compose up -d
 ```
 ```output
 [+] Running 1/1
- ✔ Container docker-intro-testing-spuc-1  Started                           0.2s
+ ✔ Container docker-intro-spuc-1  Started                                   0.2s
 ```
 
 Of course, this means we can no longer see the logs! But we can still access them using the `logs` command.
@@ -230,7 +231,7 @@ spuc-1  |
 Now... something a bit funny is happening here... why are we seeing the output twice?
 
 We've actually started the same container twice!
-We only `stop`ped the container when we pressed `[Ctrl+C]`, and didn't remove it.
+We only **stopped** the container when we pressed `[Ctrl+C]`, and didn't remove it.
 
 ### Removing the container when it stops
 
@@ -240,8 +241,8 @@ docker compose down
 ```
 ```output
 [+] Running 2/2
- ✔ Container docker_intro-spuc-1  Removed                           10.1s
- ✔ Network docker_intro_default   Removed                            0.2s
+ ✔ Container docker_intro-spuc-1  Removed                                  0.1s
+ ✔ Network docker_intro_default   Removed                                  0.2s
 ```
 
 In practice, you only *need* to use `down` if you *need* to remove the container.
@@ -262,8 +263,8 @@ docker compose up -d
 ```
 ```output
 [+] Running 2/0
- ✔ Network docker-intro-testing_default  Created                           0.0s 
- ✔ Container spuc_container              Created                           0.0s
+ ✔ Network docker-intro_default          Created                           0.0s
+ ✔ Container spuc_container              Started                           0.0s
 ```
 
 ::::::::::::::::::::::::::::: spoiler
@@ -309,7 +310,7 @@ docker compose up -d
 ```
 ```output
 [+] Running 2/0
- ✔ Network docker-intro-testing_default  Created                           0.0s
+ ✔ Network docker-intro_default          Created                           0.0s
  ✔ Container spuc_container              Created                           0.0s
 ```
 
@@ -415,6 +416,19 @@ $ docker volume ls
 $ docker compose down -v
 $ docker volume ls
 ```
+```output
+DRIVER        VOLUME NAME
+local         docker_intro_spuc-volume
+local         spuc-volume
+
+[+] Running 3/3
+ ✔ Container spuc_container         Removed                   10.2s
+ ✔ Volume docker_intro_spuc-volume  Removed                    0.0s
+ ✔ Network docker_intro_default     Removed                    0.2s
+
+DRIVER        VOLUME NAME
+local         spuc-volume
+```
 
 ### Setting an environment variable
 
@@ -702,7 +716,8 @@ volumes:
 Now both services will be started at the same time!
 
 ```bash
-docker compose up
+docker compose up -d
+docker compose logs
 ```
 ```output
 [+] Running 3/3
@@ -812,6 +827,10 @@ volumes:
   spuc-volume:
 ```
 
+```bash
+docker compose up -d
+```
+
 Now, the SPUC service is only accessible from within the Docker network!
 Try doing a curl to register a sighting and you wont be able to.
 However, you can still register sightings through the SPUCSVi interface.