Closed benrom closed 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:
/etc/nginx/sites-available/<project>
)service
command and handles restarting the application after a server reboot. This sets the PORT per project right before it boots your application. See the template here: https://github.com/hashrocket/gatling/blob/master/lib/gatling/init_script_template.sh.eexAlso slightly related is an upcoming feature seen here:
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?
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 ?
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)
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!
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
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!
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, ...).