Patrick.Sy/website-and-documentation
1
0
Fork 0
forked from DevFW-CICD/website-and-documentation
Code Pull requests Activity

feat(http-routing): added docs describing routing of http traffic in the platform

Browse source 
Refs: #IPCEICIS-468
This commit is contained in:
Patrick Sy 2024-10-10 20:25:58 +02:00
parent 984c16d3a7
commit ac17c07503
Signed by: Patrick.Sy
GPG key ID: DDDC8EC51823195E
1 changed files with 57 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

57
content/en/docs/solution/tools/idpbuilder/http-routing.md Normal file
View file

@ -0,0 +1,57 @@
---
title: Http Routing
weight: 100
---
### Routing switch
The idpbuilder supports creating platforms using either path based or subdomain
based routing:
```shell
idpbuilder create --log-level debug --package https://github.com/cnoe-io/stacks//ref-implementation
```
```shell
idpbuilder create --use-path-routing --log-level debug --package https://github.com/cnoe-io/stacks//ref-implementation
```
However, even though argo does report all deployments as green eventually, not
the entire demo is actually functional (verification?). This is due to
hardcoded values that for example point to the path-routed location of gitea to
access git repos. Thus, backstage might not be able to access them.
Within the demo / ref-implementation, a simple search & replace is suggested to
change urls to fit the given environment. But proper scripting/templating could
take care of that as the hostnames and necessary properties should be
available. This is, however, a tedious and repetitive task one has to keep in
mind throughout the entire system, which might lead to an explosion of config
options in the future. Code that addresses correct routing is located in both
the stack templates and the idpbuilder code.
### Cluster internal routing
For the most part, components communicate with either the cluster API using the
default DNS or with each other via http(s) using the public DNS/hostname (+
path-routing scheme). The latter is necessary due to configs that are visible
and modifiable by users. This includes for example argocd config for components
that has to sync to a gitea git repo. Using the same URL for internal and
external resolution is imperative.
The idpbuilder achieves transparent internal DNS resolution by overriding the
public DNS name in the cluster's internal DNS server (coreDNS). Subsequently,
within the cluster requests to the public hostnames resolve to the IP of the
internal ingress controller service. Thus, internal and external requests take
a similar path and run through proper routing (rewrites, ssl/tls, etc).
### Conclusion
One has to keep in mind that some specific app features might not
work properly or without haxx when using path based routing (e.g. docker
registry in gitea). Futhermore, supporting multiple setup strategies will
become cumbersome as the platforms grows. We should probably only support one
type of setup to keep the system as simple as possible, but allow modification
if necessary.
DNS solutions like `nip.io` or the already used `localtest.me` mitigate the
need for path based routing