As we seen before, for each discovered service, we generate a new application for the main branch of the service, and we will supply some default values to the chart. These values are composed from the metadata derived from the metadata file located in the environments repository. The specific combination is as follows:

The values provided here should be sufficient for every object in the application repository to have a up and running application. If everything went successful with the deployment generator, we should have a service-1 deployed. Let’s investigate.

kubectl get app/service-1 -n argocd -o wide

And the response:

NAME        SYNC STATUS   HEALTH STATUS   REVISION
service-1   Synced        Healthy         1.0.2

The .Release.Name for the main branch application is repository name.

Hostname

The application has now gone through our Tekton Pipeline, has been stored in the Chart Museum, and we’ve generated a new deployment for every new application that was discovered. Our next step is to ensure that the application can be accessed publicly. We will use an ingress template for this purpose.

The ingress resides in the same location as the application’s source code. It comes with a predefined structure, but also provides flexibility for modifications. By default, the template generates an ingress host endpoint in the following format:

• {{ .Release.Name }}-{{ .Values.repo }}.{{ .Values.domain }}
• https://backend-service-1.eu-north-1.training.dx-book.com

This format directs traffic to port 3030 of the application, which we’ve built using the Dockerfile. Now, let’s check to see if it’s responsive.

curl -v https://backend-service-1.eu-north-1.training.dx-book.com/health/

And the response should be something like:

< HTTP/2 200
< access-control-allow-origin:
< content-type: application/json; charset=utf-8
* Connection #0 to host backend-service-1.eu-north-1.training.dx-book.com left intact
[{"ok":true}]