3

I'm trying to deploy a service to a specific url address on AKS. The following yaml let's me access the service at desired address, like xxxx.europe.cloudapp.azure.com/service-a. This works great, i've managed to hide the entire service under desired url:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: istio
spec:
  hosts:
  - "*"
  gateways:
  - istio-gateway
  http:
  - match:
    - uri:
        prefix: /service-a
    rewrite:
      uri: /    
    route:
    - destination:
        host: service-a.default.svc.cluster.local

However when the welcome page is displayed, i only see text. No css/javascript/image files are loaded. Everything that this page is trying to load still has original url address without any rewriting being made by my gateway configuration. So the home page requests this:

http://xxxxx.europe.cloudapp.azure.com/icon.jpg

instead of this:

http://xxxxx.europe.cloudapp.azure.com/service-a/icon.jpg

What is the best way to handle rewriting urls for resources and links on a page? Do i have to manually change the urls on a home page?

EDIT:

To be more clear.

  1. Rewriting of the url works as expected, the address is exactly how i want (the entire service is hidden under "xxxx.europe.cloudapp.azure.com/service-a".
  2. Once i enter the "xxxx.europe.cloudapp.azure.com/service-a" i see service's welcome page, but without any css/jpegs/js loaded. Also the links visible on the welcome page don't work.
  3. for example, "icon.jpg" is not loaded. Page wants to load it from http://xxxx.europe.cloudapp.azure.com/icon.jpg but it's not there anymore. Due to rewriting it's available at http://xxxx.europe.cloudapp.azure.com/service-a/icon.jpg which is as expected.

I kind of expected that the http://xxxx.europe.cloudapp.azure.com/icon.jpg request will be automatically rewritten to http://xxxx.europe.cloudapp.azure.com/service-a/icon.jpg. But obviously i was mistaken. So i wonder how i can handle the links within the service itself in a manageable way - i mean i can modify every possible link within the app, but what if we change the url again (from /service-a to /service-b). The service is written with ASP.NET Core, i will look for some kind of internal rewriting solution that is maintainable.

skyrunner
  • 460
  • 1
  • 7
  • 18

1 Answers1

8

The rewriting is happening because of this part of the config:

  - match:
    - uri:
        prefix: /service-a
    rewrite:
      uri: /

Which results that the matched prefix is replaced with the value of the rewrite.uri property.

Example 1: (virtual service is activated)

Original: http://www.page.com/service-a/icon.jpg
                             ^--------^
Rewritten: http://www.page.com/icon.jpg

Example 2: (this virtual service is activated)

Original: http://www.page.com/service-a/service-a/icon.jpg
                             ^--------^
Rewritten: http://www.page.com/service-a/icon.jpg

Example 3: (this virtual service is not activated, fall back on some other virtual service, or on a default route, or blackhole which returns 404)

Original: http://www.page.com/icon.jpg

Rewriting: DOESN'T HAPPEN

For rewriting there are no recommendations and cannot be, it's dependent on your services. Istio's docs for rewriting props can be found here

If every subdomain will have it's own service then this would be an option:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: istio
spec:
  hosts:
  - "service-a.domain.com"
  gateways:
  - istio-gateway
  http:
  - match:
    - uri:
        prefix: /
    rewrite:
      uri: /service-a
    route:
    - destination:
        host: service-a.default.svc.cluster.local
Rinor
  • 1,790
  • 13
  • 22
  • Thank you for your answer. I added to rewrite.uri on purpose to hide the entire service under /service-a sub-route. But resources/url addresses related to the service are not rewritten. So when the page is requesting a css, it doesn't know anything about /service-a rewrite, hence no file is loaded. So i wonder what's the best way to maintain this. Do all links/resources have to be manually changed within the service to contain /service-a part? I kind of hoped there is some built-in solution to rewrite request coming from the service itself. I guess i have to manually adapt urls. – skyrunner Jan 03 '19 at 14:02
  • @skyrunner just to ensure that I understood you correctly: You want xhttp requests to include the prefix (/service-a), but when you request static files you don't want to rewrite those (i.e. avoid updating the webpage)? To achieve that you just need to add a second matcher (regex one) that sends to the destination without rewriting – Rinor Jan 03 '19 at 14:20
  • 1
    ok, i provided additional explainations in the main message. you made me realize i have to perform additional rewriting in the service itself to make the resources work again,. – skyrunner Jan 03 '19 at 14:49