VHOST per scaled container?

1

Is there a way to add virtual host per scaled container? We’re thinking of running admin on the separate thread / container and I wonder if we should just scale the process and point dns to that process…

2

Can you elaborate a bit? How would the admin web service be invoked? Would it be on a different port than the main web service?

3

Sure.

Currently we use completely separate app for our admin but it is just a clone of the api stack. The only difference is subdomain, so admin.​* api.*​

I thought we could just scale main api process (as stack is the same[admin lives in the same app]). get vhost for that new proccess and point route52 to it

Essentially we want to split monolithic app into two but there’s no time for it yet. So instead of building separate app would could run admin on the separate thread for now.

4

I’d recommend adding a new entry to the Procfile, something like:

admin: command-to-start-admin-server

Then you can easily add a second VHOST to that process.

Would that work?

5

Yeah that’s what I thought. I tried that earlier but forgot to EXPOSE the port :confounded:

6

I should point out that in order to determine what port to use for a VHOST, we just look at the first EXPOSEd port

So you’ll want to use the same port for your admin server as your main server.

7

hmm… not sure if I get that right

So

api: thin start -p 3000
admin: thin start -p 4000

and

`EXPOSE 3000 4000``

wouldn’t cut it?

8

That’s right, both would need to be thin start -p 3000

But, if they’re really started with the same command, you probably don’t even need the separate process…

9

well how would you ensure that we have separate processes supporting separate endpoints?

10

Well, if it’s just that you want www.example.com and admin.example.com to both point at the app, you should only need to add a DNS entry on your side for admin.example.com

11

Well yeah that’s what we have now–problem with that set up is availability. When admin runs a report main thread is affected…

12

Ahh… got it.

So, a couple options:

api: thin start -p 3000
admin: thin start -p 3000

(with EXPOSE 3000), and have a VHOST on each process. That will guarantee that the admin endpoint never shares processes with the api endpoint.

OR

You can simply scale up the api process. That won’t completely eliminate contention between the long-running admin requests and api requests, but it would mitigate it.

Make sense?

13

Yep makes perfect sense. I guess my problem is that I kept thinking one box per procfile instead of one box per service.

I’ll give the first options a try.

Thanks! :thumbsup: