There are som things that need to be set up regardless of the technology used. This is outlined here.

For specifics about a technology, check out the Node or .Net sections.

Each service needs two dockerfiles. The one named Dockerfile-Cloud should contain the production build, utilizing Multi-stage builds to create lean production images. Dockerfile is used to build an image with debugging capabilities and volume mounting so we don't need to rebuild the image each time the code changes locally.

Tip: Since VSCode only recognizes and adds code highlighting to files name Dockerfile, it is possible to add this code snippet to your user settings: "files.associations": { "Dockerfile-cloud": "dockerfile" }

The ingress must be made aware of the new service. Add an entry to Infrastructure/kubernetes/charts/default/templates/_paths.tpl. path should be the prefix you want the service to respond to in the ingress, and serviceName is the name of the service-resource in your template.

We are using Helm to orchestrate our Docker containers. To set up your new service, add a new .yaml-file in Infrastructure/kubernetes/charts/default/templates/ named after your service. The existing files should have enough comments to get you started. It is important to note that the name you are giving the service-resource here is the hostname other containers can reach your service on. This means that a GET-request to http://service1/ from another service will reach the service registered as service1 in its .yaml-template.

If you need to expose a port out of the container, you can use the service resource's ports-list to map an internal port in the container to a port on the host and set the Type to NodePort. Then the container will be reachable on http://localhost:.

All development-specific settings are set in values.dev.yml, for example exposing the node debug port (9229) or specifying which image to use.

Before starting the development, the specification should be defined as an openapi-spec. This could be done in the Azure Api Management UI (and then exported) or by hand.

If done by hand, be aware of some import restrictions outlined here.

The api specification should be placed in the same folder as the Dockerfile and should be named api.swagger.json.