Unify the the styling for notes in assignments

Author: jfahrer

_assignments/assignment_03.md

@@ -46,7 +46,7 @@ Todo.create!(title: "laundry")
 
 Press `Ctrl-D` to quit the rails console and terminate the container.
 
-__*Side note*__: Wondering why you didn't have to create/migrate the database? The data is currently stored in SQLite database which is part of this repository and hence part of the container image as well.
+> **Note**: Wondering why you didn't have to create/migrate the database? The data is currently stored in SQLite database which is part of this repository and hence part of the container image as well.
 
 
 ## Running the tests
@@ -57,7 +57,7 @@ docker container run -it your_docker_id/rails_app:v1 rspec
 
 You will see that __one of the tests will fail__ - that is OK and expected! You will get the time to fix the failing test later in the workshop.
 
-__*Side note:*__ We don't need the `-it` flags here because we don't run an interactive program like the Rails console. However, we will only see the colors in the output with the `-t` flag. As there is no harm in adding those flags, we will keep doing this from there on even if we start non-interactive programs.
+> **Note**:*__ We don't need the `-it` flags here because we don't run an interactive program like the Rails console. However, we will only see the colors in the output with the `-t` flag. As there is no harm in adding those flags, we will keep doing this from there on even if we start non-interactive programs.
 
 ## Finding out what is going on
 The Docker CLI is pretty straight forward. To get more information about what is possible, try just typing `docker`.

_assignments/assignment_04.md

@@ -14,9 +14,9 @@ Go ahead and try to create a few books via the web interface.
 
 Once you are done, you can terminate Rails and the container by pressing `Ctrl-C`.
 
-__*Side note*__: Accessing a service inside a container will NOT work of the service only listens on `localhost`. In other words, you have to make sure that the service listens on the outwards facing ethernet interfaces of the container. We told our Rails application to listen on `0.0.0.0` which is an alias for all interfaces.
+> **Note**: Accessing a service inside a container will NOT work of the service only listens on `localhost`. In other words, you have to make sure that the service listens on the outwards facing ethernet interfaces of the container. We told our Rails application to listen on `0.0.0.0` which is an alias for all interfaces.
 
-__*Side note*__: When using `-p 3000:3000` you instruct Docker to listen on all interfaces on your local machine. That means that your rails service will be accessible from other machines. Not what you want? Try `-p 127.0.0.1:3000:3000` instead to only listen on `localhost`.
+> **Note**: When using `-p 3000:3000` you instruct Docker to listen on all interfaces on your local machine. That means that your rails service will be accessible from other machines. Not what you want? Try `-p 127.0.0.1:3000:3000` instead to only listen on `localhost`.
 
 ## Enhancing the Dockerfile
 Let's make some changes to our Dockerfile to make our life a little easier and safe us some typing. **Before we get started, make sure to terminate any running containers**.

_assignments/assignment_05.md

@@ -48,9 +48,9 @@ The environment variables that we pass in are used to configure the connection t
 
 You might also have spotted the `--link` flag in our command. This flag allows us to talk to our Postgres container by its name `pg`. 
 
-__*Side note*__: We don't need to tell Docker which command we want to execute in the container because we made `rails server` the default in the prior assignment.
+> **Note**: We don't need to tell Docker which command we want to execute in the container because we made `rails server` the default in the prior assignment.
 
-__*Side note*__: `--link` is deprecated and we will learn about a better mechanism later in the workshop. However, it is the easiest way to get the app up and running for now.
+> **Note**: `--link` is deprecated and we will learn about a better mechanism later in the workshop. However, it is the easiest way to get the app up and running for now.
 
 If you open your browser and go to http://localhost:3000, you will see that we need to migrate our database. So let's do that in another container (in another shell):
 ```

_assignments/assignment_07.md

@@ -32,7 +32,7 @@ We can also append some additional flags to the `docker-compose logs` command. U
 ## Getting the app up and running
 Try browsing http://localhost:3000 - you will see that the database has not been migrated. That makes sense, we just created a whole new set of containers and volumes. 
 
-__*Side note*__: Docker Compose automatically prefixes all resources with the project name (the name of the current directory per default).
+> **Note**: Docker Compose automatically prefixes all resources with the project name (the name of the current directory per default).
 
 So let's run the migrations. Just as with the Docker CLI, we can run arbitrary commands in the context of a service:
 ```
@@ -51,7 +51,7 @@ And we can easily start a rails console as well:
 docker-compose run --rm app rails c
 ```
 
-__*Side note*__: We don't have to specify the `-it` flags with `docker-compose run`. Docker Compose takes care of that for us automatically when using the `run` command.
+> **Note**: We don't have to specify the `-it` flags with `docker-compose run`. Docker Compose takes care of that for us automatically when using the `run` command.
 
 
 ### Shutting things down

_assignments/assignment_08.md

@@ -25,7 +25,7 @@ The key part here is the `volumes` definition:
 
 We instruct Docker Compose to mount the current local working directory (`./`) to the `/usr/src/app` directory in the container. The `/usr/src/app` directory in the image contains a copy of our source code. We essentially just "replace" the content with what is currently on our local file system.
 
-__*Side note*__: The `cached` options will [increase the performance](https://docs.docker.com/docker-for-mac/osxfs-caching/) of the bind-mount on MacOS. Unlike on Linux, there is some overhead when using bind-mounts on MacOS. Remember, Linux containers need to run on Linux and Docker will setup a virtual machine running Linux on your Mac. Getting the data from your Mac into the virtual machine requires a shared file system called [`osxfs`](https://docs.docker.com/docker-for-mac/osxfs/). There are significant overheads to guaranteeing perfect consistency and the `cached` options looses up the those guarantees. We don't require perfect consistency for our use case: Mounting our source code into the container.
+> **Note**: The `cached` options will [increase the performance](https://docs.docker.com/docker-for-mac/osxfs-caching/) of the bind-mount on MacOS. Unlike on Linux, there is some overhead when using bind-mounts on MacOS. Remember, Linux containers need to run on Linux and Docker will setup a virtual machine running Linux on your Mac. Getting the data from your Mac into the virtual machine requires a shared file system called [`osxfs`](https://docs.docker.com/docker-for-mac/osxfs/). There are significant overheads to guaranteeing perfect consistency and the `cached` options looses up the those guarantees. We don't require perfect consistency for our use case: Mounting our source code into the container.
 
 In addition to the bind mount we will also add a volume for our `tmp/` directory. This is not strictly required but recommended for the following reasons:
 * On MacOS a volume will be a lot faster than a bind-mount. Since we Rails will read and write temporary and cache data to `tmp/` we want to give ourselves maximum speed.

_assignments/assignment_09.md

@@ -159,7 +159,7 @@ And there we go! If you press `ENTER` you will see that you are in a `byebug` se
 
 If we end the session by typing `continue`, we will see the Rails log on our screen - we are still attached to the container. In order to detach from the container we can use the key sequence `Ctrl-p` `Ctrl-q`. We could also press `Ctrl-c`, but that would terminate the container and we would have to restart the service.
 
-__*Side note*__: The naming conventions of Docker Compose makes it pretty straight forward to "guess". I also recommend using command-line completion for Docker and [Docker compose](https://docs.docker.com/compose/completion/)
+> **Note**: The naming conventions of Docker Compose makes it pretty straight forward to "guess". I also recommend using command-line completion for Docker and [Docker compose](https://docs.docker.com/compose/completion/)
 
 ## There is more
 Another very useful command you should be aware of is `docker stats`. It shows you CPU, memory, disk and network usage of your containers. The fantastic thing here is that you have isolated statistics for each part of our application!

_assignments/assignment_12.md

@@ -58,7 +58,7 @@ docker-compose build app
 docker-compose up -d
 ```
 
-*__Side note__*: Run the command a second time if you get an error - depending on the order in which things happen the app container might still be holding port 3000 open.
+> **Note**: Run the command a second time if you get an error - depending on the order in which things happen the app container might still be holding port 3000 open.
 
 
 Instead of using `docker-compose run` we can now use `docker-compose exec` and send arbitrary shell commands to a running container of the `app` service:

_assignments/assignment_13.md

@@ -41,7 +41,7 @@ To make calling `pg_isready` easier, we are going to wrap it in another script.
 cp -rp _examples/wait-for-postgres ./bin
 ```
 
-__*Side note*__: We place the `wait-for-postgres` script in `bin/` because it is intended to be executed within the application context. That means we make it part of the application and run it in containers. Everything in `script/` is not part of the actual application. Those are helpers that we use to interact with our application. Everything in `script/` is intended to be run on the Docker Host.
+> **Note**: We place the `wait-for-postgres` script in `bin/` because it is intended to be executed within the application context. That means we make it part of the application and run it in containers. Everything in `script/` is not part of the actual application. Those are helpers that we use to interact with our application. Everything in `script/` is intended to be run on the Docker Host.
 
 The script uses the `POSTGRES_HOST` environment variable that we pass to the our containers to connect to Postgres. `pg_isready` will yield a unsuccessful exit code if it can't connect to Postgres. The script simply executes `pg_isready` until it returns successful.