is it possible to wildcard alias in virtual host config?

Not applicable

Hi - we are starting to run into a lot of situations (which we didnt predict) where we might need more and more virtual host entries to be able to support our customers.

is it possible to wildcard this setting to prevent us from having to manage a very large list?

Solved Solved
2 14 1,413
1 ACCEPTED SOLUTION

adas
Participant V

@Benjamin Goldman

I tested few other scenarios and I feel confident that this works even with the new nginx based router that we are rolling out.

So here's what I did, I deployed a simply proxy in my org with basepath as /apigee/proxy.

I setup my virtualhost like the one below:

POST v1/o/{org}/e/test/virtualhosts

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VirtualHost name="wildcard">
    <HostAliases>
        <HostAlias>*.api.apigee.net</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>80</Port>
</VirtualHost>

This means I can now call the proxy by using different virtualhost aliases like the following:

myorg.api.apigee.net

myapi.api.apigee.net

api-foo.api.apigee.net

as long as all these CNAMEs to your existing apigee hostAlias like {org}-{env}.apigee.net

So when I call the following:

curl -v http://myorg.api.apigee.net/apigee/proxy
curl -v http://myapi.api.apigee.net/apigee/proxy
curl -v http://foo-api.api.apigee.net/apigee/proxy

all of them worked. So you can use wildcards in the virtualhost alias and call it with any of the aliases as long as that matches the wildcard expression. Only exception to this is that you can't have your hostAlias setup as simply "*" or anything that matches an existing virtualhostAlias like x.api.apigee.net

Let me know, if this works for you.

View solution in original post

14 REPLIES 14

What's the reason for the requirement that you need many virtual hosts?

If you need multiple vhosts, then you need to manage them *somewhere*.

If this is private cloud, does it make sense to use a lighter-weight proxy in front of Edge - something like nginx or even Apache http server with mod_proxy, for defining as many vhosts as you like and mapping to a particular vhost in the Edge server?

Not calling it a requirement 🙂 Just asking if we can. Looking for possible solutions to something. Trying to avoid being a system that manages host entries on top of everything else. I am also trying to avoid adding more infrastructure or more things to manage (like yet another proxy)

I am not very sure - but it looks like you have multiple 'hostnames' for the same org and env? is that correct? if so, can you elaborate on the usecase?

I can have as many as I want. That is correct (up till some limit that im sure I will eventually hit magically). I just dont want to be in the business of managing these.

well.. then i don see a reason why you need multiple hostnames for a same org/env combination.

BUT if you still need to have it, then you could use the classification by port instead of host -- so assign a port for each org/env combination.. No need to specify hostalias in the VH, will that work?

@Mukundha Madhavan

- i can add hostnames until the end of time. This is a well documented and defined function.

I see it as a bad idea to do this though. Unfortunately my customers are now coming at me with more interesting requirements right?

And a REALLY CLEAN solution to this would be to be able to wild card host aliases in an organization.

Which is why im asking if we can 😛

I do appreciate the effort at alternatives though. Unfortunately the problem we are facing will still run into the problem of requiring a virtual host to be defined at some point.

adas
Participant V

@Mukundha Madhavan That would not work, because going forward we would have hostAlias made as a mandatory field when creating/updating a virtualhost, infact that change is already there in production. I think the request is valid and does have a practical use-case.

@Benjamin Goldman The existing apigee router supports the wildcard virtualhost aliases (during classification) but the next generation Edge router, which is based on nginx, may not work well with wildcards. That being said, I will test it out for few cases and then let you know. Incase its not supported, I would open a feature request, so that we try to support this in the future. I will update you with the details of my finding from the tests.

@arghya das - thanks. I will give this a try next week.

If this ISNT carried forward to the nginx based routers that will be a problem (at some point) This ability will be particularly useful as we migrate more and more apis into management from existing workflows. In my scenario i have.. well.. lets just say a lot.. of code deployed already which expects to find its backend at a specific URL. Its a big pain in the proverbial rear end to change that on the client. Why not just add the virtual host to the apigee server? Because i might have 100s of these that I need to do. That just becomes unwieldy.

Any chance you can point to an example of how to do this correctly? That would turn this answer into an article class answer...

@Benjamin Goldman I will post the steps in detail once I am absolutely sure this would work. My preliminary tests suggest that it works fine in the new generation router too. I just want to run few more tests before I post it here.

adas
Participant V

@Benjamin Goldman

I tested few other scenarios and I feel confident that this works even with the new nginx based router that we are rolling out.

So here's what I did, I deployed a simply proxy in my org with basepath as /apigee/proxy.

I setup my virtualhost like the one below:

POST v1/o/{org}/e/test/virtualhosts

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VirtualHost name="wildcard">
    <HostAliases>
        <HostAlias>*.api.apigee.net</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>80</Port>
</VirtualHost>

This means I can now call the proxy by using different virtualhost aliases like the following:

myorg.api.apigee.net

myapi.api.apigee.net

api-foo.api.apigee.net

as long as all these CNAMEs to your existing apigee hostAlias like {org}-{env}.apigee.net

So when I call the following:

curl -v http://myorg.api.apigee.net/apigee/proxy
curl -v http://myapi.api.apigee.net/apigee/proxy
curl -v http://foo-api.api.apigee.net/apigee/proxy

all of them worked. So you can use wildcards in the virtualhost alias and call it with any of the aliases as long as that matches the wildcard expression. Only exception to this is that you can't have your hostAlias setup as simply "*" or anything that matches an existing virtualhostAlias like x.api.apigee.net

Let me know, if this works for you.

@arghya das question: when you say you cannot make the alias "*" or anything that matches an existing virtualhostAlias like x.api.apigee.net - do you mean for this particular environment, for this particular organization, or globally in a single installation?

(remember im talking about private cloud here primarily)

Yes, having * as virtualhost alias would mean that it would match all host header strings so that classification would happen purely based on the port. If you have * or *.api.apigee.net and x.api.apigee.net as virtualhosts across one or more environments, they might get routed incorrectly to * or *.api.apigee.net if your request has a host header of x.api.apigee.net unless the ports are different.

So as a general practice, I would recommend not using * as the alias at any point.

@Benjamin Goldman I came across a case today (private cloud) where the hostAlias was setup as simply "*" and the edge-router wouldn't startup because of the below error seen when configtest was run.

[root@server conf.d]# /opt/nginx/scripts/apigee-nginx configtest
nginx: [emerg] invalid number of arguments in "server_name" directive in /opt/nginx/conf.d/abc_prod_default.conf:6
nginx: configuration file /opt/nginx/conf/nginx.conf test failed

The abc_prod_default.conf.bad file had the entry for server_name as below:
..........
server {
listen 10.x.y.z:9001 ;
listen 127.0.0.1:9001 ;

server_name ;
server_tokens off;
error_log /opt/apigee/var/log/edge-router/nginx/abc~prod.9001_error_log error;
access_log /opt/apigee/var/log/edge-router/nginx/abc~prod.9001_access_log router;
set $client_connection
............