Support custom domains about serving

[evankanderson]

We are configuring the Istio ingress based on hostname (rather than IP-based) rules. This substantially simplifies setup for the automatic names (i.e. you can create a single ingress IP, and map *.elafros.mycompany to that IP), but it means that you probably need to use an HTTP reverse proxy to map custom domains to services.

I think this should be something that we document; a few options:

1. How to set up nginx as a reverse proxy, which I think would look like:

server {
    listen myhost:80;
    server_name  myhost;
    location / {
        proxy_set_header X-Forwarded-Host $host:$server_port;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass https://elaservice.namespace.elaclusterprefix;
    }
}

2. How to configure Envoy via Istio to forward the additional hostname to the ElaService.
3. How to configure Envoy without Istio.

[mchmarny]

#26 seems related

[mchmarny]

@evankanderson are you saying doc for how to configure nginx is the path forward here? I thought we decided to leverage Istio route rules for that?

[mdemirhan]

@mchmarny Can we close this issue now?

[asciimike]

From a product perspective, I think I'm looking for some higher level constructs that make this easier, maybe like:

domain: mydomain.com
  - path: /login
    service: login  # login.namespace.clusterprefix
  - path: /search
    service: search  # search.namespace.clusterprefix
  - path: /catalog
    service: catalog  # catalog.namespace.clusterprefix

It's possible we might also want to do different subdomains (either for different environments or for regionalization):

domain: eu.mydomain.com
  - path: /login
    service: login-eu  # login-eu.namespace.clusterprefix
  - path: /search
    service: search-eu  # search-eu.namespace.clusterprefix
  - path: /catalog
    service: catalog-eu  # catalog-eu.namespace.clusterprefix

This is somewhat aligned with what Ambassador (API Gateway) does with it's Mapping resource.

Istio and Envoy native options are here:

• Istio Gateway
• Envoy Route

Options as I see them today:

• Require developers use a third party solution (e.g. nginx [low level] or Ambassador [high level])
• Surface Istio or Envoy configs directly
• Create our own resource on top of Istio/Envoy configs

Note that I think these solutions exist for a host of other "API gateway" like problems (e.g. data plane auth).

[asciimike]

@tcnghia would you mind re-opening, as I don't think it's fully resolved?

[mdemirhan]

@mcdonamp Thanks for the clarification. We have an issue tracking this: #540 - Would you mind adding your comments there? We need input especially on things that are most commonly used and should be supported by Elafros out of the box. Istio supports many different ways to route the traffic, but we are not sure if all of them are commonly used and should be exposed, or we should start with a smaller set and expand as there is customer demand.