Thanks, Marcus - that's a good point! I'll definitely keep "minimally separate" dev/prod deployments in mind, whichever way we go.
Right now, I'm leaning towards Ansible as a quick solution (< 1 day to implement & lightly test, unless I'm missing something in the install guide), but Docker seems like an interesting way to go. It *does* look like it would involve building a few different containers for the individual services involved php app, mysql, rabbitmq, and airavata itself. If noone objects, I'll probably take an hour or two tomorrow to see how far a quick attempt at 'Ansiblizing' this goes - even if the PGA goes in a new direction in the future, a small amount of work might save some pain in the meantime. Cheers, Eric C. On Fri, Jan 6, 2017 at 2:34 PM, Pierce, Marlon <marpi...@iu.edu> wrote: > +1 in general for this “requirement”. I was thinking the same thing. > > > > *From: *"Christie, Marcus Aaron" <machr...@iu.edu> > *Reply-To: *"dev@airavata.apache.org" <dev@airavata.apache.org> > *Date: *Friday, January 6, 2017 at 2:20 PM > *To: *"dev@airavata.apache.org" <dev@airavata.apache.org> > *Subject: *Re: Improving the PGA Install > > > > Eric, > > > > It’s great to have you working on this. > > > > I’m not sure if this really impacts the decision making process much, but > I had a thought. One need I have for an improved installation process for > PGA is to use that as a much easier to use local development environment. > However, the needs for a local development environment vs a deployed > production instance of an application are somewhat different. For example, > if I were using Docker for local development I would want to map my local > filesystem into the Docker instance so that code changes I make are > reflected in the app running in Docker. But that sort of filesystem > mounting wouldn’t be needed when running in production. > > > > If we end up with a Docker configuration for development and one for > production app deployments, it would be good if they could share as much > configuration as possible. > > > > Also, just to be clear, I’m just using Docker as an example above to > illustrate the point. > > > > Thanks, > > > > Marcus > > > > On Jan 5, 2017, at 2:22 PM, Eric Coulter <coulter...@gmail.com> wrote: > > > > Greetings, all! > > As of the new year, I'm funded to help out more with different bits of > the Airavata project and the SGRC. One of the first things I'd like to > look at is > improving the installation process for the default PGA. After a meeting > this morning, it seems there are a few options. I'd like to start moving > on one of them pretty soon, but we thought some discussion would be > helpful to see which way might be most useful. > > Please take a look at these, and let me know any > thoughts/feedback/preferences, or any useful experience with the tools > mentioned! (They are in no particular order.) > > 1. Continue to use Ansible; develop a role that is as OS-agnostic as > possible (can detect OS, dynamic inventory, etc.) There is already some > work done in this direction, but is this the best place to spend my time? > > 2. Develop OS-specific packages - rpm, deb, something for mac > (homebrew/port?) > - nice from a "getting other people to host this" viewpoint, but that > doesn't seem to be a huge sticking point. > > 3. Docker/Singularity? Puppet? Chef? Vagrant? Singularity might be > better for other people in the research space. This would still require > creating different container images for each OS. Does this cause any > problems for database backups? Worth the time to get used to a new tool? > > 4. Should we be leveraging the tools available from Amazon more heavily? > This might require a fundamental change in the PGA, but could possibly > save a lot of work on our side. We don't know how much it could save, > though. > > Cheers, > Eric C. > > >
