Installing Ansible 2 on CentOS 7



  • Ansible, now owned by Red Hat, is one of the most popular, open source, DevOps management frameworks replacing cfEngine as the third of the big names in the space (along with the more well known Puppet and Chef.) As we use CentOS and Suse for most of our production servers and as Ansible is a Red Hat product, running it on Red Hat's CentOS 7 platform seemed to make the most sense. We are running this on our Scale hyperconverged cluster. Having a DevOps management toolset for a large scale virtualized environment is important for rapid building, changes, change tracking and more.

    A default CentOS installation is going to have Python 2.7.5 which will work great. Ansible recommends getting the latest version from the EPEL repository but this does not work and Ansible has not updated the repo nor fixed the documentation. So we have to attempt installation through different means. We would use PIP, a Python package manager (similar to NPM for Node.) For PIP we will need the EPEL anyway, though. But PIP goes for an old version of Ansible too. Like the repos, PIP is on the Ansible 1.9 family when 2.0 and 2.0.1 releases are the current stables. So we need to go straight to GIT.

    I like RPMs, they are easier to track, so we will use the GIT sources to build an RPM so that we get the best of both. Of course you could do this with a lot less effort skipping the RPM build, but since I am documenting it all and making it easy, there isn't any need to do so. This will allow RPM and YUM to report on Ansible being installed.

    yum -y install git asciidoc rpm-build python2-devel
    cd /usr/src
    git clone git://github.com/ansible/ansible.git --recursive
    cd ansible
    yum install rpm-build/ansible-2.1.0-0.git201601101956.c3dd021.devel.el7.centos.noarch.rpm
    

    That last line is for Ansible 2.1.0-0, which is the current version as of the time of this writing in the developer branch. You'll need to adjust this line to reflect the version that you have at the time that you do this.

    That's it. Ansible 2 is installed. With the very latest developer release. Not ideal for you? Next we will modify this to get a stable release.



  • Taking what we did above, let's modify that command list to get a pre-determined, stable release of Ansible rather than the latest developer release. For a lab, the devel release is probably good. For production, we want stable. So right now 2.0.1 is the latest stable. Let's get that....

    yum -y install git asciidoc rpm-build python2-devel
    cd /usr/src
    git clone git://github.com/ansible/ansible.git --recursive
    cd ansible
    git checkout stable-2.0.1
    make rpm
    yum install rpm-build/ansible-2.0.0-0.git201601051704.a2a786e.stable201.el7.centos.noarch.rpm
    

    Only one more command than doing the default developer release. Nice and easy. No Ansible is installed!



  • We are excited to be going down the Ansible / DevOps path for use in the new lab. With the huge Scale cluster at our disposal, the ability to build quickly and manage all of the VMs is going to be a huge deal.



  • I think you forgot the make rpm before you run yum.



  • @johnhooks said:

    I think you forgot the make rpm before you run yum.

    Fixed. I wonder where that line went. I must have overwritten it somehow.



  • This will be nice, you can replace your users script with it.

    Here's kind of a maybe strange question, do you think these tools will ever end up hurting (I don't want to use that word but I can't think of a better one at the moment) normal system tasks. The reason I ask is because with ansible to copy a file you use:

    copy: src=file dest=file owner=jhooks group=jhooks mode=0644
    

    Which is fairly different from

    scp file [email protected]:/file  and then chmod 0664 file
    

    Same with yum, ansible is:

    yum: name=<package>
               state=latest
    

    Do you think there will be people who use these tools and don't know the actual underlying commands?

    This would obviously be far in the future, but just asking.



  • @johnhooks Yes, I think that soon we will find that there are a lot of people who only know the DevOps stuff and have no idea what is happening under the hood.



  • @scottalanmiller This would more than likely be a result of someone coming into a DevOps role from the perspective of a Developer, versus that of a person who has worked the Systems/Infrastructure side of things. I wonder how soon something like this will switch the current demand from that of developers/programmers/coders to that of systems/infrastructure specialists.

    DevOps, from this perspective, makes me kind of anxious. Having the expectation that everyone share the load across the board (infrastructure,development, testing, etc...) creates an odd simile in my mind likened to the overly engineered coffee maker that grinds your coffee, brews a couple shots of espresso, steams your milk, and combines everything into a cup. In many ways an overly complex costly appliance that is rendered useless if one single component fails; not to mention costly to repair. I prefer having a separate tools that are engineered to perform their task well and are easy to maintain. I don't want a cable modem with a built in router, switch, and wireless access point.

    In reference to the DevOps trend, I can see how having a very competent team is advantageous for startups. As the trend continues to grow aren't we going to hit a wall or cap on talent acquisition? How many people can ADEQUATELY fill those roles? Or is it acceptable to have a team composed of a few infrastructure-heavy members, and a few dev-heavy members and expect their skillsets to balance out overtime? What happens when demand is so high that the grass is nearly always greener? (if that isn't already the case)



  • @RamblingBiped said:

    DevOps, from this perspective, makes me kind of anxious. Having the expectation that everyone share the load across the board (infrastructure,development, testing, etc...) creates an odd simile in my mind likened to the overly engineered coffee maker that grinds your coffee, brews a couple shots of espresso, steams your milk, and combines everything into a cup.

    I know of now shop approaching DevOps like that except for when NTG did in the 1990s because there weren't enough of us and someone (me) had to take on the lowly IT duties so other people could focus on code.

    DevOps shops today are not mixing their development staff with their IT staff, they are approaching IT from a "defined as code" perspective. It's not true DevOps, it's using DevOps techniques. And DevOps techniques are taking hold very, very quickly. But I don't see duties crossing over, that makes no sense.



  • @RamblingBiped said:

    In reference to the DevOps trend, I can see how having a very competent team is advantageous for startups. As the trend continues to grow aren't we going to hit a wall or cap on talent acquisition?

    Traditional IT did that long ago. Shops looking for high end systems people have almost no ability to hire and it has been this way for a long time. The market can't produce half as many traditional admins as are necessary to run things the old fashioned way. DevOps specifically addresses this by reducing the head count needed to do work. Fewer admins, more servers.

    The only thing that will continue to cause the inability to hire will be the continuous increase in server count.



  • I think it's just a natural progression of things also. It's kind of like with programming, very few people use assembly language, but it's still there.

    That might be a bad analogy since I'm sure we need more people as admins and engineers than we need people writing assembly language, but it's the same type of principle from my view point.

    And as @scottalanmiller has said before, we still need people who know this stuff because of his example with the shop that didn't have anyone with Vi experience.



  • I ran through the steps. I had to skip the 'git checkout stable-2.0.1' command. I got the following error:

    it checkout stable-2.0.1
    error: pathspec 'stable-2.0.1' did not match any file(s) known to git.

    Regardless, I skipped the step, proceeded to the next step, built and installed the RPM successfully.

    Thanks for making this easy. I was looking for the RPM but apparently it is not yet released.



  • As far as we can tell no RPM is forthcoming. No platform is getting the Ansible 2 updates, it seems. Not RPM, not DEB, not PIP.



  • @pm9448 said:

    And welcome to the MangoLassi community, by the way!



  • Been a while since we talked about Ansible. How many people have been trying it out and/or using it?



  • @scottalanmiller said in Installing Ansible 2 on CentOS 7:

    Been a while since we talked about Ansible. How many people have been trying it out and/or using it?

    I've just started playing with it. Plan is to control lots of Raspberry's, Banana Pi's, Beagle's and other SBC's.



  • @scottalanmiller said in Installing Ansible 2 on CentOS 7:

    Been a while since we talked about Ansible. How many people have been trying it out and/or using it?

    Still using it. I have it set up for everything here at work. Mostly been using ad hoc stuff, but I have a couple playbooks set up for things that are difficult to do during a kickstart.



  • By the way, is there some frontend available?Found something on SF, but that's just a better text editor. I don't mind hacking through textfiles, but I plan to give some of the administrative stuff to a colleague who is still new to the job.

    Tower is just too expensive for us poor EDU guys.



  • A nice GUI would be awesome.



  • Haven't tried it personally, Semaphore Open source Ansible UI.





  • @scottalanmiller said in Installing Ansible 2 on CentOS 7:

    @Romo said in Installing Ansible 2 on CentOS 7:

    Haven't tried it personally, Semaphore Open source Ansible UI.

    logo.png

    That's the one I've tried but it doesn't seem to do much at all



  • @thwr you could also try running Rundeck + ansible.



  • @Romo said in Installing Ansible 2 on CentOS 7:

    @thwr you could also try running Rundeck + ansible.

    Their site is not super obvious as to what they do. It's just a scheduler?



  • @scottalanmiller remote execution of commands and scripts + scheduler



  • I tried Rundeck. It was more confusing than just using Ansible without a GUI. IMO, just having the playbook with yaml and jinja files is easier to read and use. GUIs always have at least one thing you need in a place you wouldn't think.

    I guess I wouldn't mind having some reports in a GUI but I'll stick with just text files.