This section contains explanations for the commands presented in the developer workflow.

Starting development:

The pods will usually crash because of two things: Errors with volume mounting or problems pulling container image. kubectl get pods are used to list all pods (the resource in Kubernetes where docker containers live) and their status. kubectl delete pods --all will delete all the pods. This is not as destructive as it seems, as pods are created using a deployment. A deployment is instructions to Kubernetes about the desired state of the system. If we delete a pod, Kubernetes will pick up that something is missing and recreate it. This is the easiest way to restart the running code.

It is possible to access the services on port 30010 because of something called an Ingress. It is basically a service (defined in templates/ingress.yaml) that has an exposed NodePort (defined in values.dev.yaml). The ingress will receive all requests and route to the correct service based on the specification, found in templates/_paths.tpl.

Changing a node-service without adding new dependencies to package.json:

As mentioned in Starting development, we can just delete a pod to restart it. the -l flag tells Kubernetes to look for a pod with the specified label. We are labeling the pods with the service name, so this will delete and recreate pods related to a specific service. When they are recreated, the will restart and load the new source from the local volume mount.

Changing a node-service that adds a new dependency

When adding a dependency, we need to rebuild the container. We are resolving node_modules when creating the image so we don't need to download them every time we start a container. This saves time in the long run, as we typically do not add dependencies as often as we make code changes.

docker build builds the specified Dockerfile. We are tagging it with the service name. The important part is to match the image name mentioned in values.dev.yaml.

helm upgrade <deployment name> will force Kubernetes to fetch the new image and recreate pods using that image. The flag -f is used to specify configuration files. Locally, we are using two:

• values.dev.yaml is all dev specific configuration, mostly related to debugging ports, volume mounts etc
• local.yaml has a single property: The path to the root of the repository as seen by the Kubernetes cluster. This file is different for each developer, and is therefore not included in source control.

The deployment name is the name you got when first installing. If you can't remember it, execute helm list to get a list of all deployments. We are upgrading and not installing a new deployment each time because of a config map collision across multiple deployments. Also because there is a lot of state persisted for old deployments, and we don't need that in dev.

TODO: Investigate if changing the config map-name each deploy will restart the Ingress.

Changing a .Net-service without adding new nuget-packages:

In this situation we can just restart the service. We have mounted our filesystem in the container, so all local changes is automatically present inside the container. This means that dotnet run watch will see the updated .cs-files without having to rebuild the image. Dotnet apps have hot reloading enabled, so we do not need to restart the container.

Changing a .Net-service that adds new nuget-packages:

When adding a dependency, we need to rebuild the container. We are resolving nuget-packages when creating the image so we don't need to download them every time we start a container. This saves time in the long run, as we typically do not add dependencies as often as we make code changes.

See the related Node-section for an explanation of the commands.

Adding a new service:

When adding a new service, we need to build the image to make it available for deploy in Kubernetes, and then we can just deploy using helm as usual.

Accessing the Kubernetes Dashboard

This is a GUI that could make it easier to check the status of the cluster without using CLI.