hashrocket / gatling

Deployment tool for Phoenix apps
496 stars 17 forks source link

Question: support for umbrella projects? #16

Closed benrom closed 8 years ago

benrom commented 8 years ago

Looking at the PORT section of the Readme, it looks like this tool will work for a single phoenix app. What about umbrella projects hosting multiple phoenix apps ?

This is quite a common requirement when your server provides APIs and an Admin for instance. As they share common data structures the umbrella project is a good solution. In this case, there are several endpoints and thus several ports that can be then mapped to different nginx subdomains (port 4000 is www.domain.com, port 4001 is api.domain.com, port 4002 is admin.domain.com, ...).

mrmicahcooper commented 8 years ago

Currently this should work fine. With Gatling, one should not set PORT globally. It is all handled by Gatling.

When Gatling deploys your application, it finds an open port and saves it in two places:

Also slightly related is an upcoming feature seen here:

https://github.com/hashrocket/gatling/issues/10

benrom commented 8 years ago

So you mean when the project is run, it is not calling mix phoenix.server from the umbrella root but calling mix.phoenix server from each child app folder, setting the environment variable PORT for each one separately?

In that case, if two phoenix apps A and B share and depend on the same supervised app X (for DB operations for instance), does that mean the app X will run twice on the same server?

mrmicahcooper commented 8 years ago

No, it doesn't call mix phoenix.server is uses Distillery to create a release and then uses the commands given to you by that release. I think the same would be true with an umbrella app; Use the one start command to start the entire application. But I'll have to do some research on how Distillery handles umbrella apps to better understand how to handle them. Ideally, having your own Nginx config file in your project should easily handle this but that's still in the works. It would work like the following:

Manually set the port in your application(s). Don't use the PORT env at all. Have a ./nginx.config file in your parent application that uses said ports.

What are your thoughts @benrom ?

benrom commented 8 years ago

I think this would be a good solution, yes!

In what timeframe do you think the changes required for #10 will be added to Gatling (just looking for a rough estimate there)?

Also what target OS is needed for Gatling? it looks like a Debian based OS is the way to go. What about FreeBSD? (dependency on systemD)

mrmicahcooper commented 8 years ago

Cool! Yeah. I may be able to get this in today. But if I don't finish, it'll be some time next week. Probably next Friday.

Regarding the SystemD dependency; I think this script will also work with upstart but don't quote me on that as I'm super unfamiliar these startup service programs in general. If you're familiar with this or can offer any insight to the startup script, I would love some guidance!

benrom commented 8 years ago

Cool, I'm in no hurry, take your time for that :)

I'm no expert of systemd/upstart, I've just used supervisord in the past. It's not exactly the same as those two because it's not out of the box and requires a little configuration to get going, but it's available on many unix platforms. Perhaps it's a safer bet to target more servers than systemd

mrmicahcooper commented 8 years ago

That's a good thought. I'd like to see how people end up using Gatling to determine expanding the target OSes. It could definitely support more but I don't know what that would look yet. Need more issues! :)

I'm going to close this issue since the features exposed here are included in https://github.com/hashrocket/gatling/issues/10

Thanks for the feedback, by the way, @benrom!