6

Puppet modules like the ones from puppetforge could be deployed using r10k.

Question

What is the equivalent of this tool in Ansible?

Attempt to answer the question

This Google Q&A was found that does not answer the question

  • 1
    You mean other than ansible-galaxy? – Michael Hampton Jul 26 '16 at 22:58
  • 1
    Reading somethingsinistral.net/blog/rethinking-puppet-deployment I'm still not sure what it does. Ansible doesn't use a git-heavy model like the one described there, so the answer may be "it doesn't need one". – ceejayoz Jul 26 '16 at 22:59
  • 1
    @ceejayoz How to manage all the modules and versions from galaxy.ansible.com then? – 030 Jul 26 '16 at 23:04
  • 3
    @030 galaxy.ansible.com/intro#download indicates a roles.txt file with lines like user1.role1,v1.0.0. – ceejayoz Jul 26 '16 at 23:07
  • @ceejayoz This looks very familiar with Puppet's r10k indeed. sudo ansible-galaxy install -r requirements.yml downloads the required roles and versions. – 030 Jul 26 '16 at 23:14
10

Based on the discussion with @ceejayoz the conclusion is that Ansible's equivalent of Puppet's R10K is ansible-galaxy install -r requirements.yml.

R10K

In R10K a Puppetfile is used. A Puppetfile is a definition of modules (e.g. from Puppetforge) that need to be assembled in a certain environment, e.g. the Puppetfile of the development environment could look as follows:

mod 'garethr/docker', '5.3.0'
mod 'unibet/vagrant', '0.2.1'

mod 'jenkins',
  :git => 'https://github.com/jenkinsci/puppet-jenkins',
  :ref => 'master'

mod 'jdk_oracle',
  :git => 'https://github.com/schrepfler/puppet-jdk_oracle.git',
  :ref => 'master'

While the Production Puppetfile contains stable versions:

mod 'garethr/docker', '5.2.0'
mod 'unibet/vagrant', '0.2.0'
mod 'schrepfler/puppet-jdk_oracle', '0.2.0'
mod 'rtyler/jenkins', '1.6.1'

The equivalent of r10k in ansible

In order to assemble roles (equivalent of Puppet's modules) from Puppet's Puppetforge equivalent in Ansible - Ansible Galaxy or custom sources the roles or sources could be defined in yml files (based on the link provided by @ceejayoz and this link). The development environment could look as follows:

development.yml

- src: geerlingguy.composer
  version: 1.3.0

- src: geerlingguy.java
  version: 1.2.1

- src: bennojoy.mysql

- src: https://github.com/ANXS/postgresql.git
  version: master

and it could be run by issuing sudo ansible-galaxy install -r development.yml. While the production could look like:

production.yml

- src: geerlingguy.composer
  version: 1.2.0

- src: geerlingguy.java
  version: 1.1.1

and be run by executing sudo ansible-galaxy install -r production.yml. The outcome could look as follows:

user@host ~ $ sudo ansible-galaxy install -r development.yml
- geerlingguy.composer is already installed, skipping.
- downloading role 'java', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-java/archive/1.2.1.tar.gz
- extracting geerlingguy.java to /etc/ansible/roles/geerlingguy.java
- geerlingguy.java was installed successfully
- bennojoy.mysql is already installed, skipping.
  • 2
    Thanks a lot. I was already thinking about forking r10k code to work with Ansible. I think it is useful to point out that the requirements is not limited to roles from ansible-galaxy. As described in the documentation you can add custom sources. – Henrik Pingel Jul 27 '16 at 9:16
  • Indeed, you can install from Galaxy, Git, Mercurial, SVN, or even a tarball over HTTP/S! – geerlingguy Aug 7 '16 at 4:13
1

Think ansible-galaxy is only half of the answer because it doesn't do anything about Ansible playbooks, which are synonymous to Puppet role modules. One of the benefits of r10k is that you can manage all aspects of each environment separately.

You might consider separate branches per environment with all of the Ansible roles being pulled in via ansible-galaxy. This would let you isolate playbook, inventory, and role changes per environment without unintentionally letting them slip into production and not duplicating role logic per branch.

  • the concept of environment is not native in ansible like in puppet, because in puppet if you have the agent that is attached to an specific environment, in ansible you don't have agent. – c4f4t0r Nov 19 '18 at 10:11
  • Environment, inventory, potato, potato. Ansible control machine is dynamically building the ephemeral agent as a temporary python script on the remote machine; only difference is that it isn't running on schedule unless this is an AWX or Tower job running on schedule. – andyfeller Oct 7 '19 at 11:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.