Directory server deployment

geneontology / amigo

AmiGO is the public interface for the Gene Ontology.

http://amigo.geneontology.org

BSD 3-Clause "New" or "Revised" License

29 stars 17 forks source link

Directory server deployment #124

Closed kltm closed 10 years ago

kltm commented 10 years ago

An AmiGO installation should be able to run entirely from the checked out repo.

For a lot of historic and evolutionary reasons, AmiGO is "deployed" out to directories controlled by Apache, where is gets served. The relationship and configuration sharing between the repo and the web dirs is complicated.

To simplify deployment, the source needs to be changed so that Apache is able to serve the AmiGO applications from where they sit in the repo.

Additionally, this can be treated as a transition step to using standalone web servers and PaaS (OpenShift) for AmiGO deployment. In the end, it would be nice for development to occur within the repo with no Apache necessary--Apache becoming an optional deployment step.

cmungall commented 10 years ago

On 11 Jun 2014, at 21:38, kltm wrote:

An AmiGO installation should be able to run entirely from the checked out repo.

For a lot of historic and evolutionary reasons, AmiGO is "deployed" out to directories controlled by Apache, where is gets served. The relationship and configuration sharing between the repo and the web dirs is complicated.

To simplify deployment, the source needs to be changed so that Apache is able to server the AmiGO applications from where they sit in the repo.

Additionally, this can be treated as a transition step to using standalone web servers and PaaS (OpenShift) for AmiGO deployment. In the end, it would be nice for development to occur within the repo with no Apache necessary--Apache becoming an optional deployment step.

Reply to this email directly or view it on GitHub: https://github.com/kltm/amigo/issues/124

kltm commented 10 years ago

Me too!

kltm commented 10 years ago

Proposed steps:

Code changes to get it to run in Apache directly out of checkout; likely involves tossing out most of install.pl and a few directory changes; probably not too hard, but likely very disruptive to current major deployments.
Major components should be able to run as CGI::Application::Server (allowing CLI dev without Apache).
Finally, and optionally, consider transition to PSGI or other stack technologies (although, if deployment to various PaaS is possible with just the first two, may be moot); consider effort/consequences of transition to separate framework like Mojolicious (there are in fact many good things to say about (f)CGI).

kltm commented 10 years ago

Turning out to be a larger rewrite of the installation process and mechanisms--a lot of bits and assumptions are being tossed out. I should get buy-in from the other major installations and make sure that I'm not about to commit to something that will interfere with how they deploy.

kltm commented 10 years ago

All pathing is changing--maintenance scripts will all have to be checked to make sure that they don't do something nasty, like recursively delete your repo or filesystem.

kltm commented 10 years ago

This is blocking pretty much everything else as I don't want to do a nasty merge, so I'm going to go ahead and assume that this will be fine for other installations.

kltm commented 10 years ago

Okay, the major changes in the variables used for the new config file took a while to sort out to get it to work automated and manually on the labs servers. Should be sorted now? Running tomodachi to make sure.

kltm commented 10 years ago

All dev/labs machines running new code and taking automated updates.