57 lines
2.5 KiB
Markdown
57 lines
2.5 KiB
Markdown
---
|
|
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
|