Fix markdown linting errors - line length

CONTRIBUTION.md

@@ -9,7 +9,8 @@ The exercise should have the following sections:
 * Exercise (Step-by-step instructions on how to solve the exercise)
 * Extras and wrap-up (optional)
 
-When creating a new exercise, you should use the [exercise template](exercise-template.md) as a starting point.
+When creating a new exercise, you should use the [exercise template](exercise-template.md) as a
+starting point.
 
 ## Best practices
 
@@ -19,7 +20,8 @@ Use :bulb: `:bulb:` to indicate a hint to the exercise.
 
 ### Dealing with text rich content
 
-When ever you think there is too much text, but that it is necessary, please use the `details` tag to make the text toggleable, by clicking the arrow:
+When ever you think there is too much text, but that it is necessary, please use the `details` tag
+to make the text toggleable, by clicking the arrow:
 
 <details>
     <summary>A Hint</summary>

README.md

@@ -29,7 +29,8 @@ You can find a summary of many of the commands used in the exercises in the
 
 There are several ways to get a free Kubernetes cluster for running the exercises.
 
-[Amazon][eks], [Google][gke], [Microsoft][aks] and [Oracle][oke] provide various degrees of free managed clusters.
+[Amazon][eks], [Google][gke], [Microsoft][aks] and [Oracle][oke] provide various degrees of free
+managed clusters.
 
 Alternatively, you can set up a local cluster with [Docker
 Desktop][docker-desktop] or [Kind][kind].
@@ -50,7 +51,8 @@ echo "source <(kubectl completion bash)" >> ~/.bashrc
 . ~/.bashrc
 ```
 
-The commands above will enable kubectl autocompletion when you start a new bash session and source (reload) bashrc i.e. enable kubectl autocompletion in your current session.
+The commands above will enable kubectl autocompletion when you start a new bash session and source
+(reload) bashrc i.e. enable kubectl autocompletion in your current session.
 
 See: [Kubernetes.io - Enabling shell autocompletion][autocompletion] for more info.
 

accessing-your-application.md

@@ -10,15 +10,20 @@
 
 Deploying a pod is not enough to make it accessible from outside the cluster.
 
-In this exercise you will learn how to make temporary connections to a pod inside the cluster via `kubectl port-forward`.
+In this exercise you will learn how to make temporary connections to a pod inside the cluster via
+`kubectl port-forward`.
 
 ## Port-forward
 
-The `kubectl port-forward` command allows you to forward one or more local ports to a pod. This can be used to access a pod that is running in the cluster, using for example a web browser or a command line tool like `curl`.
+The `kubectl port-forward` command allows you to forward one or more local ports to a pod. This can
+be used to access a pod that is running in the cluster, using for example a web browser or a
+command line tool like `curl`.
 
-The command takes two arguments: the pod name and the port to forward. The port is specified as `local:remote` to forward a local port to a remote port inside the pod.
+The command takes two arguments: the pod name and the port to forward. The port is specified as
+`local:remote` to forward a local port to a remote port inside the pod.
 
-For example, if you want to forward port 8080 on your local machine to port 5000 in the pod, you can use the following command:
+For example, if you want to forward port 8080 on your local machine to port 5000 in the pod, you
+can use the following command:
 
 `kubectl port-forward frontend 8080:5000`
 
@@ -27,9 +32,12 @@ You can then access the pod on `localhost:8080`.
 <details>
 <summary>:bulb: How does this port-forward work?</summary>
 
-Port forwarding is a network address translation that redirects internet packets form one IP address with specified port number to another `IP:PORT` set.
+Port forwarding is a network address translation that redirects internet packets form one IP address
+with specified port number to another `IP:PORT` set.
 
-In Kubernetes `port-forward` creates a tunnel between your local machine and Kubernetes cluster on the specified `IP:PORT` pairs in order to establish connection to the cluster. `kubectl port-forward` allows you to forward not only pods but also services, deployments and other.
+In Kubernetes `port-forward` creates a tunnel between your local machine and Kubernetes cluster on
+the specified `IP:PORT` pairs in order to establish connection to the cluster.
+`kubectl port-forward` allows you to forward not only pods but also services, deployments and other.
 
 More information can be found from [here](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
 
@@ -85,14 +93,17 @@ Port forward can be achieved with:
 
 `kubectl port-forward --address 0.0.0.0 frontend 8080:5000`
 
-> :bulb: We add the `--address 0.0.0.0` option to the port-forward command to make it accept commands coming from remote machines, like your laptop!
-> `0.0.0.0` Means any address, so you probably don't want to do this on your own machine in, unless you want to expose something to the internet.
+> :bulb: We add the `--address 0.0.0.0` option to the port-forward command to make it accept
+> commands coming from remote machines, like your laptop! `0.0.0.0` Means any address, so you
+> probably don't want to do this on your own machine in, unless you want to expose something
+> to the internet.
 
-It can now be accessed on `http://workstation-<number>.<prefix>.eficode.academy:8080` (from the internet).
-Notice the plain, unencrypted `http` connection. It is not `https`, and your browser may complain about it.
-TLS signing is an advanced topic and out of scope for now.
+It can now be accessed on `http://workstation-<number>.<prefix>.eficode.academy:8080`
+(from the internet). Notice the plain, unencrypted `http` connection. It is not `https`, and your
+browser may complain about it. TLS signing is an advanced topic and out of scope for now.
 
-> :bulb: VSCode will ask you if you what to see the open port. Unfortunately vscode proxy does not proxy requests correctly back to the pod, so use the URL of the instance instead.
+> :bulb: VSCode will ask you if you what to see the open port. Unfortunately vscode proxy does not
+> proxy requests correctly back to the pod, so use the URL of the instance instead.
 
 - Look at it in the browser.
 
@@ -194,7 +205,8 @@ Extra exercise
 
 While still having the port-forward running
 
-- Access the frontend in the browser and check that it still works and that frontend has access to the backend.
+- Access the frontend in the browser and check that it still works and that frontend has access to
+  the backend.
 - Try to delete the backend pod with `kubectl delete pod backend` command.
 - Try to recreate the backend pod with `kubectl apply -f backend-pod.yaml` command.
 - Access the frontend in the browser.
@@ -206,9 +218,11 @@ If not, why not?
 <summary>Solution</summary>
 
 The frontend pod is not configured to automatically re-resolve the backend IP address.
-So when we deleted the pod, and recreated it, the IP address changed, but the frontend pod still has the old IP address in its environment variables.
+So when we deleted the pod, and recreated it, the IP address changed, but the frontend pod still
+has the old IP address in its environment variables.
 
-Thankfully Kubernetes has a networking abstraction called `services` which solves this exact (and more!) problem, which we will learn about in the next exercise.
+Thankfully Kubernetes has a networking abstraction called `services` which solves this exact (and
+more!) problem, which we will learn about in the next exercise.
 
 </details>
 </details>
@@ -220,5 +234,6 @@ Thankfully Kubernetes has a networking abstraction called `services` which solve
 - Delete the pod with `kubectl delete pod frontend` command.
 - Delete the pod with `kubectl delete pod backend` command.
 
-Congratulations! You have now learned how to make temporary connections to a pod inside the cluster via `kubectl port-forward`, and how to use environment variables to configure the pod.
+Congratulations! You have now learned how to make temporary connections to a pod inside the cluster
+via `kubectl port-forward`, and how to use environment variables to configure the pod.
 And lastly, you have learned how to use `kubectl exec` to execute commands inside a pod.

configmaps-secrets.md

@@ -7,20 +7,24 @@
 
 ## Introduction
 
-Configmaps and secrets are a way to store information that is used by several deployments and pods in your cluster.
-This makes it easy to update the configuration in one place, when you want to change it.
+Configmaps and secrets are a way to store information that is used by several deployments and pods
+in your cluster. This makes it easy to update the configuration in one place, when you want to
+change it.
 
-Both configmaps and secrets are generic `key-value` pairs, but secrets are `base64 encoded` and configmaps are not.
+Both configmaps and secrets are generic `key-value` pairs, but secrets are `base64 encoded` and
+configmaps are not.
 
-> :bulb: Secrets are not encrypted, they are encoded. This means that if someone gets access to the cluster, they will be able to read the values.
+> :bulb: Secrets are not encrypted, they are encoded. This means that if someone gets access to the
+> cluster, they will be able to read the values.
 
 ## ConfigMaps
 
 You use a ConfigMap to keep your application code separate from your configuration.
 
 It is an important part of creating a [Twelve-Factor Application](https://12factor.net/).
 
-This lets you change easily configuration depending on the environment (development, production, testing, etc.) and to dynamically change configuration at runtime.
+This lets you change easily configuration depending on the environment (development, production,
+testing, etc.) and to dynamically change configuration at runtime.
 
 A ConfigMap manifest looks like this in yaml:
 
@@ -78,9 +82,11 @@ data:
 
 </details>
 
-- Use literal key-value pairs defined on the command line with `kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2`
+- Use literal key-value pairs defined on the command line with
+  `kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2`
 
-> :bulb: remember the `--dry-run=client -o yaml` trick to see what the yaml file will look like before you apply it.
+> :bulb: remember the `--dry-run=client -o yaml` trick to see what the yaml file will look like
+> before you apply it.
 
 <details>
 <summary>
@@ -95,21 +101,26 @@ data:
 
 `secrets` are used for storing configuration that is considered sensitive, and well ... _secret_.
 
-When you create a `secret` Kubernetes will go out of it's way to not print the actual values of secret object, to things like logs or command output.
+When you create a `secret` Kubernetes will go out of it's way to not print the actual values of
+secret object, to things like logs or command output.
 
 You should use `secrets` to store things like passwords for databases, API keys, certificates, etc.
 
-Rather than hardcode this sensitive information and commit it to git for all the world to see, we source these values from environment variables.
+Rather than hardcode this sensitive information and commit it to git for all the world to see, we
+source these values from environment variables.
 
-`secrets` function for the most part identically to `configmaps`, but with the difference that the actual values are `base64` encoded.
-`base64` encoded means that the values are obscured, but can be trivially decoded.
-When values from a `secret` are used, Kubernetes handles the decoding for you.
+`secrets` function for the most part identically to `configmaps`, but with the difference that the
+actual values are `base64` encoded. `base64` encoded means that the values are obscured, but can be
+trivially decoded. When values from a `secret` are used, Kubernetes handles the decoding for you.
 
-> :bulb: As `secrets` don't actually make their data secret for anyone with access to the cluster, you should think of `secrets` as metadata for humans, to know that the data contained within is considered secret.
+> :bulb: As `secrets` don't actually make their data secret for anyone with access to the cluster,
+> you should think of `secrets` as metadata for humans, to know that the data contained within is
+> considered secret.
 
 ## Using ConfigMaps and Secrets in a deployment
 
-To use a configmap or secret in a deployment, you can either mount it in as a volume, or use it directly as an environment variable.
+To use a configmap or secret in a deployment, you can either mount it in as a volume, or use it
+directly as an environment variable.
 
 ### Injecting a ConfigMap as environment variables
 
@@ -182,9 +193,11 @@ postgres-6fbd757dd7-ttpqj  1/1     Running   0          4s
 
 #### Refactor the database user into a configmap and implement that in the backend
 
-We want to change the database user into a configmap, so that we can change it in one place, and use it on all deployments that needs it.
+We want to change the database user into a configmap, so that we can change it in one place, and
+use it on all deployments that needs it.
 
-- Create a configmap with the name `postgres-config` and filename `postgres-config.yaml` and the information about database configuration as follows:
+- Create a configmap with the name `postgres-config` and filename `postgres-config.yaml` and the
+  information about database configuration as follows:
 
 ```yaml
 data:
@@ -226,7 +239,8 @@ data:
 </details>
 
 - apply the configmap with `kubectl apply -f postgres-config.yaml`
-- In the `backend-deployment.yaml`, change the environment variables to use the configmap instead of the hardcoded values.
+- In the `backend-deployment.yaml`, change the environment variables to use the configmap instead
+  of the hardcoded values.
 
   Change this:
 
@@ -257,8 +271,10 @@ data:
 
 #### Change the database password into a secret, and implement that in the backend
 
-We want to change the database password into a secret, so that we can change it in one place, and use it on all deployments that needs it.
-In order for this, we need to change the backend deployment to use the secret instead of the configmap for the password itself.
+We want to change the database password into a secret, so that we can change it in one place, and
+use it on all deployments that needs it.
+In order for this, we need to change the backend deployment to use the secret instead of the
+configmap for the password itself.
 
 - create a secret with the name `postgres-secret` and the following data:
 
@@ -293,7 +309,8 @@ data:
 
 - apply the secret with `kubectl apply -f postgres-secret.yaml`
 
-- In the `backend-deployment.yaml`, change the environment variables to use the secret instead of the configmap for the password.
+- In the `backend-deployment.yaml`, change the environment variables to use the secret instead of
+  the configmap for the password.
 
 Change this:
 
@@ -323,12 +340,16 @@ envFrom:
 
 We are going to implement the configmap and secret in the database deployment as well.
 
-The standard Postgres docker image can be configured by setting specific environment variables, ([you can see the documentation here](https://hub.docker.com/_/postgres)).
-By populating these specific values we can configure the credentials for root user and the name of the database to be created.
+The standard Postgres docker image can be configured by setting specific environment variables,
+([you can see the documentation here](https://hub.docker.com/_/postgres)).
+By populating these specific values we can configure the credentials for root user and the name of
+the database to be created.
 
-This means that we need to change the way we are injecting the environment variables, in order to make sure the environment variables have the correct names.
+This means that we need to change the way we are injecting the environment variables, in order to
+make sure the environment variables have the correct names.
 
-- Open the `postgres-deployment.yaml` file, and change the way the environment variables are injected to use the configmap and secret.
+- Open the `postgres-deployment.yaml` file, and change the way the environment variables are
+  injected to use the configmap and secret.
 
 ```yaml
 ### using configMapKeyRef
@@ -369,4 +390,5 @@ kubectl get secret <secret-name> -o jsonpath="{.data.password}" | base64 --decod
 
 ### Clean up
 
-Delete the resources you have deployed by running `kubectl delete -f .` in the `configmaps-secrets/start` directory.
+Delete the resources you have deployed by running `kubectl delete -f .` in the
+`configmaps-secrets/start` directory.