Closed orangewolf closed 6 years ago
I agree completely on (2) I think I've accomplished that but I haven't done a lot of hound-ci so we'll see if that worked. As far as (1) is concerned there are a few groups of things.
1) repos we didn't change AnsibleShipyard.ansible-zookeeper DavidWittman.redis carlosbuenosvinos.ansistrano-deploy carlosbuenosvinos.ansistrano-rollback evrardjp.keepalived geerlingguy.nodejs geerlingguy.repo-epel openmicroscopy.haproxy repleo.postfix rvm_io.ruby
2) stuff from https://github.com/curationexperts/ansible-hydra which may or may not have changes to better support RHEL and clustering hydra-stack packages sidekiq sufia_dependencies system_setup webserver
3) anything custom for this install deploy - these are specific to this rails app hooks for the deploy sudoersfix - this is needed the docker set up ucsd.proxy - this is needed to deal with the proxy settings on the configured live machines
4) Notch8 packages notch8.ffmpeg - modified version of geerlingguy.ffmpeg notch8.ssh - I dont think we have this published anywhere, but we probably should
So the easiest ones to deal with are (3) and (4). (3) are pretty specific to this app and belong in the repo. (4) should be published as part of the cleanup of this work set.
(2) we'll work on contributing back to the Curation Experts repo what they will take, including a proposal to break it out in to smaller, more usable pieces. There is substantial refactoring that should be done here at some point
(1) These are the easiest to move out of the repo and just pull down with Ansible Galaxy. But the issue is that these upstream libraries will change. They will go away, break or have different arguments. So to keep things really repeatable, I recommend a pattern of clear delineation of the roles. So you may want to hold on to them in the app repo as the versions that they are and they can be refreshed from upstream on purpose as desired. We can do that the way we have at the moment, or we can move them in to git submodules. I'm pretty open about which way we do that.
Thanks @orangewolf , this helps a lot.
So in your experience, for (1), is using the versioning in ansible galaxy not as dependable as one might hope? I'm honestly curious, because I have essentially no experience using it in practice like you all do.
re: (2) - that sounds great
re: (3,4) - that also sounds great, and makes sense. Thanks!
For the most part they will stay stable. But it only takes one going away or changing focus to break the build. The roles on galaxy essentially just point at github repos. We find this same problem with pointing at remote github repos in our Gemfile. Did you notice I had to change the Gemfile to fix loading the Samvera dependencies. The app was essentially un-deployable do to things outside our control. In my experience that's not a big deal except at 3 am when there is a critical fix that needs to launch.
I'll look at the ansible role this afternoon to see if we can't get synced up there.
@orangewolf, another change we'd like is to remove the roles/* from this PR, and replaced with a roles.yml
or the like.
For the roles that are modified from upstream, or not in Ansible Galaxy, we (ucsdlib) can fork, and have the modifications applied, or we can pull directly from notch8's organization's github.
- name: rvm_io.ruby
version: v2.0.0
- name: carlosbuenosvinos.ansistrano-deploy
version: 2.7.0
- name: carlosbuenosvinos.ansistrano-rollback
version: 2.0.1
- name: notch8.ssh
src: https://github.com/notch8/ansible-role-ssh.git
version: master
This way we can take advantage of roles in other projects without having to duplicate code.
bin/provision would have to be updated with a call to ansible-galaxy:
system "ansible-galaxy install --roles-path ops/roles --role-file ops/roles.yml"
Initial ansible stack for the Horton app. Requires encrypted settings for production deployment not found in repo. See README for deploy instructions.