language/golang: use "console" for shell examples

This allows for easier copying of the commands, without selecting the
prompt.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

language/golang/build-images.md

@@ -37,7 +37,7 @@ The source code for the application is in the [olliefr/docker-gs-ping](https://g
 
 For our present study, we clone it to our local machine:
 
-```shell
+```console
 $ git clone https://github.com/olliefr/docker-gs-ping
 ```
 
@@ -84,7 +84,7 @@ func main() {
 
 Let’s start our application and make sure it’s running properly. Open your terminal and navigate to the directory into which you cloned the project's repo. From now on, we'll refer to this directory as the **working directory**.
 
-```shell
+```console
 $ go run main.go
 ```
 
@@ -104,7 +104,7 @@ ____________________________________O/_______
 
 Let's run a quick _smoke test_ on the application. **In a new terminal**, run a request using `curl`. Alternatively, you can use your favourite web browser as well.
 
-```shell
+```console
 $ curl http://localhost:8080/
 Hello, Docker! <3
 ```
@@ -234,7 +234,7 @@ The build command optionally takes a `--tag` flag. This flag is used to label th
 
 Let's build our first Docker image!
 
-```shell
+```console
 $ docker build --tag docker-gs-ping .
 ```
 
@@ -271,7 +271,7 @@ To see the list of images we have on our local machine, we have two options. One
 
 To list images, simply run the `images` command:
 
-```shell
+```console
 $ docker images
 ```
 
@@ -291,7 +291,7 @@ An image is made up of a manifest and a list of layers. In simple terms, a “ta
 
 To create a new tag for our image, run the following command.
 
-```shell
+```console
 $ docker tag docker-gs-ping:latest docker-gs-ping:v1.0
 ```
 
@@ -299,7 +299,7 @@ The Docker `tag` command creates a new tag for the image. It does not create a n
 
 Now run the `docker images` command to see the updated list of local images:
 
-```shell
+```console
 $ docker images
 ```
 
@@ -314,14 +314,14 @@ You can see that we have two images that start with `docker-gs-ping`. We know th
 
 Let’s remove the tag that we had just created. To do this, we’ll use the `rmi` command, which stands for "remove image":
 
-```shell
+```console
 $ docker rmi docker-gs-ping:v1.0
 Untagged: docker-gs-ping:v1.0
 ```
 
 Notice that the response from Docker tells us that the image has not been removed but only "untagged". Verify this by running the images command:
 
-```shell
+```console
 $ docker images
 ```
 
@@ -379,8 +379,8 @@ ENTRYPOINT ["/docker-gs-ping"]
 
 Since we have two dockerfiles now, we have to tell Docker that we want to build using our new Dockerfile. We also tag the new image with `multistage` but this word has no special meaning, we only do so that we could compare this new image to the one we've built previously, that is the one we tagged with `latest`:
 
-```shell
-docker build -t docker-gs-ping:multistage -f Dockerfile.multistage .
+```console
+$ docker build -t docker-gs-ping:multistage -f Dockerfile.multistage .
 ```
 
 Comparing the sizes of `docker-gs-ping:multistage` and `docker-gs-ping:latest` we see an order-of-magnitude difference!

language/golang/configure-ci-cd.md

@@ -211,7 +211,7 @@ This workflow is similar to the CI workflow, with the following changes:
 
 Let's save this workflow and check the _Actions_ page for the repository on GitHub. Unlike the CI workflow, this new workflow cannot be triggered manually - this is how we set it up. So, in order to test it, we have to tag some commit. Let's tag the `HEAD` of the `main` branch:
 
-```shell
+```console
 $ git tag -a 0.0.1 -m "Test release workflow"
 
 $ git push --tags
@@ -235,7 +235,7 @@ That's easy to fix. We follow our own guide and add the secrets to the repositor
 
 To remove the tag on the `remote`:
 
-```shell
+```console
 $ git push origin :refs/tags/0.0.1
 To https://github.com/olliefr/docker-gs-ping.git
  - [deleted]         0.0.1
@@ -243,7 +243,7 @@ To https://github.com/olliefr/docker-gs-ping.git
 
 And to re-apply it locally and push:
 
-```shell
+```console
 $ git tag -fa 0.0.1 -m "Test release workflow"
 Updated tag '0.0.1' (was d7d3edc)
 $ git push origin --tags
@@ -261,7 +261,7 @@ And the workflow is triggered again. This time it completes without issues:
 
 Since the image we've just pushed to Docker Hub is public, now it can be pulled by anyone, from anywhere:
 
-```shell
+```console
 $ docker pull olliefr/docker-gs-ping
 Using default tag: latest
 latest: Pulling from olliefr/docker-gs-ping

language/golang/develop.md

@@ -32,14 +32,14 @@ The point of a database is to have a persistent store of data. [Volumes](../../s
 
 To create a managed volume, run :
 
-```shell
+```console
 $ docker volume create roach
 roach
 ```
 
 We can view the list of all managed volumes in our Docker instance with the following command:
 
-```shell
+```console
 $ docker volume list
 DRIVER    VOLUME NAME
 local     roach
@@ -51,14 +51,14 @@ The example application and the database engine are going to talk to one another
 
 The following command creates a new bridge network named `mynet`:
 
-```shell
+```console
 $ docker network create -d bridge mynet
 51344edd6430b5acd121822cacc99f8bc39be63dd125a3b3cd517b6485ab7709
 ```
 
 As it was the case with the managed volumes, there is a command to list all networks set up in your Docker instance:
 
-```shell
+```console
 $ docker network list
 NETWORK ID     NAME          DRIVER    SCOPE
 0ac2b1819fa4   bridge        bridge    local
@@ -79,7 +79,7 @@ When choosing a name for a network or a managed volume, it's best to choose a na
 
 Now that the housekeeping chores are done, we can run CockroachDB in a container and attach it to the volume and network we had just created. When you run the folllowing command, Docker will pull the image from Docker Hub and run it for you locally:
 
-```shell
+```console
 $ docker run -d \
   --name roach \
   --hostname db \
@@ -105,7 +105,7 @@ Now that the database engine is live, there is some configuration to do before o
 
 We can do that with the help of CockroachDB built-in SQL shell. To start the SQL shell in the _same_ container where the database engine is running, type:
 
-```shell
+```console
 $ docker exec -it roach ./cockroach sql --insecure
 ```
 
@@ -175,7 +175,7 @@ The example application for this module is an extended version of `docker-gs-pin
 
 To checkout the example application, run:
 
-```shell
+```console
 $ git clone https://github.com/olliefr/docker-gs-ping-roach.git
 # ... output omitted ...
 ```
@@ -347,7 +347,7 @@ Regardless of whether we had updated the old example application, or checked out
 
 We can build the image with the familiar `build` command:
 
-```shell
+```console
 $ docker build --tag docker-gs-ping-roach .
 ```
 
@@ -361,7 +361,7 @@ Now, let’s run our container. This time we’ll need to set some environment v
 > 
 > **Don't run in insecure mode in production, though!**
 
-```shell
+```console
 $ docker run -it --rm -d \
   --network mynet \
   --name rest-server \
@@ -378,14 +378,14 @@ There are a few points to note about this command.
 
 * We map container port `8080` to host port `80` this time. Thus, for `GET` requests we can get away with _literally_ `curl localhost`:
 
-  ```shell
+  ```console
   $ curl localhost
   Hello, Docker! (0)
   ```
 
   Or, if you prefer, a proper URL would work just as well:
 
-  ```shell
+  ```console
   $ curl http://localhost/
   Hello, Docker! (0)
   ```
@@ -396,7 +396,7 @@ There are a few points to note about this command.
 * The actual password does not matter, but it must be set to something to avoid confusing the example application.
 * The container we've just run is named `rest-server`. These names are useful for managing the container lifecycle:
 
-  ```shell
+  ```console
   # Don't do this just yet, it's only an example:
   $ docker container rm --force rest-server
   ```
@@ -405,7 +405,7 @@ There are a few points to note about this command.
 
 In the previous section, we have already tested querying our application with `GET` and it returned zero for the stored message counter. Now, let's post some messages to it:
 
-```shell
+```console
 $ curl --request POST \
   --url http://localhost/send \
   --header 'content-type: application/json' \
@@ -420,7 +420,7 @@ The application responds with the contents of the message, which means it had be
 
 Let's send another message:
 
-```shell
+```console
 $ curl --request POST \
   --url http://localhost/send \
   --header 'content-type: application/json' \
@@ -429,13 +429,13 @@ $ curl --request POST \
 
 And again, we get the value of the message back:
 
-```shell
+```json
 {"value":"Hello, Oliver!"}
 ```
 
 Let's see what the message counter says:
 
-```shell
+```console
 $ curl localhost
 Hello, Docker! (2)
 ```
@@ -444,7 +444,7 @@ Hey, that's exactly right! We sent two messages and the database kept them. Or h
 
 First, let's stop the containers:
 
-```shell
+```console
 $ docker container stop rest-server roach
 rest-server
 roach
@@ -452,7 +452,7 @@ roach
 
 Then, let's remove them:
 
-```shell
+```console
 $ docker container rm rest-server roach
 rest-server
 roach
@@ -460,15 +460,15 @@ roach
 
 Verify that they are gone:
 
-```shell
+```console
 $ docker container list --all
 CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
 ```
 
 And start them again, database first:
 
-```shell
-docker run -d \
+```console
+$ docker run -d \
   --name roach \
   --hostname db \
   --network mynet \
@@ -481,8 +481,8 @@ docker run -d \
 
 And the service next:
 
-```shell
-docker run -it --rm -d \
+```console
+$ docker run -it --rm -d \
   --network mynet \
   --name rest-server \
   -p 80:8080 \
@@ -496,7 +496,7 @@ docker run -it --rm -d \
 
 Lastly, let's query our service:
 
-```shell
+```console
 $ curl localhost
 Hello, Docker! (2)
 ```
@@ -509,7 +509,7 @@ Such is the power of managed volumes. Use it wisely.
 
 Remember, that we are running CockroachDB in "insecure" mode. Now that we had built and tested our application, it's time to wind everything down before moving on. You can list the containers that you are running with the `list` command:
 
-```shell
+```console
 $ docker container list
 ```
 
@@ -610,7 +610,7 @@ Other ways of dealing with undefined or empty values exist, as documented in the
 
 Before you apply changes made to a Compose configuration file, there is an opportunity to validate the content of the configuration file with the following command:
 
-```shell
+```console
 $ docker-compose config
 ```
 
@@ -620,7 +620,7 @@ When this command is run, Docker Compose would read the file `docker-compose.yml
 
 Let’s start our application and confirm that it is running properly.
 
-```shell
+```console
 $ docker-compose up --build
 ```
 
@@ -669,7 +669,7 @@ This is not a big deal. All we have to do is to connect to CockroachDB instance
 
 So we login into the database engine from another terminal:
 
-```shell
+```console
 $ docker exec -it roach ./cockroach sql --insecure
 ```
 
@@ -681,7 +681,7 @@ It would have been possible to connect the volume that we had previously used, b
 
 Now let’s test our API endpoint. In the new terminal, run the following command:
 
-```shell
+```console
 $ curl http://localhost/
 ```
 
@@ -701,7 +701,7 @@ You can run containers started by the `docker-compose` command in detached mode,
 
 To start the stack, defined by the Compose file in detached mode, run:
 
-```shell
+```console
 $ docker-compose up --build -d
 ```
 

language/golang/run-containers.md

@@ -20,7 +20,7 @@ A container is a normal operating system process except that this process is iso
 
 To run an image inside of a container, we use the `docker run` command. It requires one parameter and that is the image name. Let’s start our image and make sure it is running correctly. Execute the following command in your terminal.
 
-```shell
+```console
 $ docker run docker-gs-ping
 ```
 
@@ -40,7 +40,7 @@ When you run this command, you’ll notice that you were not returned to the com
 
 Let’s make a GET request to the server using the curl command.
 
-```shell
+```console
 $ curl http://localhost:8080/
 curl: (7) Failed to connect to localhost port 8080: Connection refused
 ```
@@ -53,13 +53,13 @@ To publish a port for our container, we’ll use the `--publish` flag (`-p` for
 
 Start the container and expose port `8080` to port `8080` on the host.
 
-```shell
+```console
 $ docker run --publish 8080:8080 docker-gs-ping
 ```
 
 Now let’s rerun the curl command from above.
 
-```shell
+```console
 $ curl http://localhost:8080/
 Hello, Docker! <3
 ```
@@ -72,7 +72,7 @@ Press **ctrl-c** to stop the container.
 
 This is great so far, but our sample application is a web server and we should not have to have our terminal connected to the container. Docker can run your container in detached mode, that is in the background. To do this, we can use the `--detach` or `-d` for short. Docker will start your container the same as before but this time will “detach” from the container and return you to the terminal prompt.
 
-```shell
+```console
 $ docker run -d -p 8080:8080 docker-gs-ping
 d75e61fcad1e0c0eca69a3f767be6ba28a66625ce4dc42201a8a323e8313c14e
 ```
@@ -81,7 +81,7 @@ Docker started our container in the background and printed the container ID on t
 
 Again, let’s make sure that our container is running properly. Run the same `curl` command:
 
-```shell
+```console
 $ curl http://localhost:8080/
 Hello, Docker! <3
 ```
@@ -90,7 +90,7 @@ Hello, Docker! <3
 
 Since we ran our container in the background, how do we know if our container is running or what other containers are running on our machine? Well, we can run the `docker ps` command. Just like on Linux, to see a list of processes on your machine we would run the `ps` command. In the same spirit, we can run the `docker ps` command which will show us a list of containers running on our machine.
 
-```shell
+```console
 $ docker ps
 ```
 
@@ -103,14 +103,14 @@ The `ps` command tells a bunch of stuff about our running containers. We can see
 
 You are probably wondering where the name of our container is coming from. Since we didn’t provide a name for the container when we started it, Docker generated a random name. We’ll fix this in a minute but first we need to stop the container. To stop the container, run the `docker stop` command which does just that, stops the container. You will need to pass the name of the container or you can use the container ID.
 
-```shell
+```console
 $ docker stop inspiring_ishizaka
 inspiring_ishizaka
 ```
 
 Now rerun the `docker ps` command to see a list of running containers.
 
-```shell
+```console
 $ docker ps
 CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
 ```
@@ -119,7 +119,7 @@ CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
 
 Docker containers can be started, stopped and restarted. When we stop a container, it is not removed but the status is changed to stopped and the process inside of the container is stopped. When we ran the `docker ps` command, the default output is to only show running containers. If we pass the `--all` or `-a` for short, we will see all containers on our system, that is stopped containers and running containers.
 
-```shell
+```console
 $ docker ps -a
 ```
 
@@ -135,13 +135,13 @@ If you’ve been following along, you should see several containers listed. Thes
 
 Let’s restart the container that we have just stopped. Locate the name of the container and replace the name of the container below in the restart command:
 
-```shell
+```console
 $ docker restart inspiring_ishizaka
 ```
 
 Now, list all the containers again using the `ps` command:
 
-```shell
+```console
 $ docker ps --all
 ```
 
@@ -159,7 +159,7 @@ Let’s stop and remove all of our containers and take a look at fixing the rand
 
 Stop the container we just started. Find the name of your running container and replace the name in the command below with the name of the container on your system:
 
-```shell
+```console
 $ docker stop inspiring_ishizaka
 inspiring_ishizaka
 ```
@@ -170,7 +170,7 @@ To remove a container, run the `docker rm` command passing the container name. Y
 
 Again, make sure you replace the containers names in the below command with the container names from your system:
 
-```shell
+```console
 $ docker rm inspiring_ishizaka wizardly_joliot magical_carson gifted_mestorf
 ```
 
@@ -187,12 +187,12 @@ Now let’s address the pesky random name issue. Standard practice is to name yo
 
 To name a container, we must pass the `--name` flag to the `run` command:
 
-```shell
+```console
 $ docker run -d -p 8080:8080 --name rest-server docker-gs-ping
 3bbc6a3102ea368c8b966e1878a5ea9b1fc61187afaac1276c41db22e4b7f48f
 ```
 
-```shell
+```console
 $ docker ps
 ```
 

language/golang/run-tests.md

@@ -63,11 +63,8 @@ The second test in `main_test.go` has almost identical structure but it tests _a
 
 In order to run the tests, we must make sure that our application Docker image is up-to-date.
 
-```shell
-docker build -t docker-gs-ping:latest .
-```
-
-```
+```console
+$ docker build -t docker-gs-ping:latest .
 [+] Building 3.0s (13/13) FINISHED
 ...
 ```
@@ -78,15 +75,15 @@ Note, that the image is tagged with `latest` which is the same label we've chose
 
 Now that the Docker image for our application had been built, we can run the tests that depend on it:
 
-```shell
-go test ./...
+```console
+$ go test ./...
 ok      github.com/olliefr/docker-gs-ping       2.564s
 ```
 
 That was a bit... underwhelming? Let's ask it to print a bit more detail, just to be sure:
 
-```shell
-go test -v ./...
+```console
+$ go test -v ./...
 ```
 
 ```