Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple instances (production, development, test) on same server #375

Open
mcjon3z opened this issue Jan 17, 2018 · 2 comments
Open

Multiple instances (production, development, test) on same server #375

mcjon3z opened this issue Jan 17, 2018 · 2 comments

Comments

@mcjon3z
Copy link

mcjon3z commented Jan 17, 2018

Due to the way that the application names apache config files and file hosting directories based upon campaign ID, it is not possible to host both a development and a production environment simultaneously on the same server without one environment mangling the other. Duplicate ID numbers issued in sequence will affect the other instance to the extent that a change made on one environment happens to have the same ID number present in the other environment. Even if you use separate PF instances running out of separate directories, the apache config files still get mangled because of the store location.

One possible solution would be to change the location of the apache config files to reside in the PF directory and to add that directory as an include in the main apache config file as is done with sites-enabled. This would also keep from having to grant access to www-data to the sites-enabled directory.

@zeknox
Copy link
Member

zeknox commented Jan 18, 2018

This is good call out. We can modify the name of the configuration files by adding in the current Rails environment to the filename.

2.3.0 :001 > Rails.env
 => "development" 

So I would imaging the filename would look something like: 1development.conf based on the Rails environment that is running.

@mcjon3z
Copy link
Author

mcjon3z commented Jan 19, 2018

If you are going that route I would also use the same naming convention for the deployed campaign directories too. That would give you the option to have a test and production environment that is different databases but the same repo pull. Thats what I was originally trying to do - give a staff guy something to play with without having to worry about him messing with live campaigns or templates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants