RPM Package Support

[zmoshansky]

I am planning on taking a stab at adapting this for a CentOS server and wanted to get input ahead of time.

I'm planning on following yoyoclouds' blog post. It seems like that approach would also be easy to transition to Ansible 2.0's package management module in the future.

Yay/Nay/Thoughts?

[HashNuke]

@zmoshansky yes. That would be nice.
Can you hold off for a day or two? I have some fixes in the hot-reload-fix branch that needs to be tested. Once that's done. I'll merge it into master and you can take off from there.

[TigerWolf]

I would be interested in this too! Happy to help if needed.

Edit: Just got it working with Centos 7. There are quite a few changes, will be posting it soon when I fix a few issues.

[TigerWolf]

Work in progress: https://github.com/HashNuke/ansible-elixir-stack/compare/master...TigerWolf:feature/centos_support?expand=1

Happy to merge hot-reload-fix from upstream when you finish it.

[zmoshansky]

Compared to TigerWolf's progress, my current version has a lot of changes. Point being, it seems like a great time to clean up and re-organize.

@HashNuke, are you open to re-organizing this playbook? ie.) Changing many of these tasks into roles, adding tags, etc? In particular, it would help clean up the different configs between RedHat and Debian all over the place, and split some of the install from config. End user wouldn't notice a difference, but power users would have a lot more control.

Top level: Same actions to kick things off {setup, deploy, etc}
Mid level: Tasks such as nginx, postgres, monit get turned into roles
Low level: Roles get tagged so they can be executed individually

Benefits

• ansible-playbook playbooks/setup.yml --tags "nginx" would only install/check nginx which is way quicker and allows fast experimentation with configuration.
• ansible-playbook playbooks/setup.yml would be quicker as entire OS specific plays are skipped instead of ignored task by task
• ansible-playbook playbooks/setup.yml output would be cleaner as it wouldn't include all the verbosity of every skipped task for a different OS.

[TigerWolf]

I have more uncommitted changes from further testing of deployments. Let me know if these could be used. Happy to see any improvements.

[HashNuke]

@zmoshansky if the setup and commands don't change then I'm fine with it. Do the OS-specific tasks vary a lot?

I did check if there was a way to suppress the output for skipped tasks. All I found was an issue on Ansible with a lot of people upvoting but was closed. The problem I was targeting was ease of setup & use. Install-a-role-and-start-flying. Hence I had to dump everything as task files instead of roles. (I still don't remember all the reasons as to why I made this choice)

@zmoshansky Responding to your issue's main post: new Ansible 2.0 package module calls the system-specific package manager module. So package still calls yum or apt modules underneath.

@TigerWolf & @zmoshansky can you both try to consolidate your work? It seems like both of you have useful changes. I'm yet to test my branch. Hopefully I'll find the motivation to do it today.

[zmoshansky]

@TigerWolf @HashNuke Here is a bit of my work to date. I've been working on improving the nginx config to handle tls, gzip, and use the recommended config from the phoenix guide. I would probably split it into a basic config that just works, and a secure/optimized one that people can opt-into. I've also started to add a few comments throughout to help explain some of the less obvious options.

It turns out that package won't be such a panacea as I once first thought.

• most packages are named differently, and it won't handle that.
• the packages install with different default configurations. IE /etc/monit/monitrc on Debian vs /etc/monitrc on EL
• SELinux, bless it's heart. While great for security, it certainly involves a bit of extra configuration on the EL side

The plus side, I've listedsome great ansible roles in the Readme that already handle multi-os deploys and I think it would be great to utilize those for the basic install & config of the various components. We can then simply layer our changes on top and actually offload a bunch of complexity.