Ansible/Puppet/Chef

[Deepak Ravi]

Hello all,

I know there's Puppet and Chef which have been there for quite sometime and now we've Ansible for the past two years or so. 

What would your suggestion be to someone who is just getting into automation tools and it's application in the networking world? To elaborate, should I first play and experiment on something that's popular like Puppet/Chef or something like Ansible which I found a little easy to work with ? 

Or should I touch a little upon everything and wait until one of them comes on top..

There might not be a definite answer to this question but you could give me a personal opinion which would be great too...

Thank you

Deepak

[Lindsay Hill]

If you're leaning towards the network side of things, then Ansible is probably a good choice.

But you might also want to spend a little time with Puppet, just so you've got a handle on how it's implemented, and you understand the difference in approach between that and Ansible.

--
You received this message because you are subscribed to the Google Groups "network.toCode()" group.
To unsubscribe from this group and stop receiving emails from it, send an email to networktocod...@googlegroups.com.
To post to this group, send email to networ...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/networktocode/d75ee262-bb64-4feb-9f0b-7acf3b7ffd0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Patrick Ogenstad]

I would agree learn a bit of both but focus on Ansible. Even if you end up using Puppet in the long run what you learn about Ansible now won't be wasted. 

Though Ansible might have limited support for network devices the real barrier now is a good API and when that exists it's possible to write modules for those devices. Just like Jason Edelman just demonstrated on his blog: http://www.jedelman.com/home/network-automation-with-cisco-nexus-switches-ansible

However Puppet required some sort of agent  to run and I thing it will be awhile until those agents are included on more network devices. 

To view this discussion on the web visit https://groups.google.com/d/msgid/networktocode/CADhybzfnpcQnVyute%3DPHc_DxuUoRUg%2BBL5KkRVHXRzv-Xs0gNQ%40mail.gmail.com.

[Jason Edelman]

Definitely agree with Lindsay, but from a practical sense, it comes down to what problems you are trying to solve, how large your team is, etc. 

  In my first encounter with Puppet to automate Nexus switches, it took me days to get it working.  For Ansible, it was more along the lines of minutes, so just getting started, I'd opt for Ansible.  With Ansible, you'll get to understand workflow, orchestration, idempotency, templating, etc. and even some Python if you wish to start extending and developing custom modules.  That said, it's a win win if you are learning any of these tools.

FWIW, I just posted this today for getting started with Ansible and Nexus switches (3K/9K so far, more in the future):

https://github.com/jedelman8/nxos-ansible

To view this discussion on the web visit https://groups.google.com/d/msgid/networktocode/CADhybzfnpcQnVyute%3DPHc_DxuUoRUg%2BBL5KkRVHXRzv-Xs0gNQ%40mail.gmail.com.

[Michael Payne]

+1 for Ansible. Much lower barrier to entry. One potential problem with Puppet and Chef is a reliance on Ruby. Some have concerns about Ruby security, performance, consumption of RAM and maintenance of the Ruby runtime on your switch.

To view this discussion on the web visit https://groups.google.com/d/msgid/networktocode/CA%2B_m3%2BZ_TB4i0Q6ygocxxiBxoxUw4uLOgsNdmUF8%2BVHQ64biVQ%40mail.gmail.com.

[Michael Kashin]

I might say a word against ansible if I may. People have been advocating Ansible 'agentless' architecture as one of the primary advantages. However bear in mind that Ansible does require an 'agent', the only difference is that it's not stored on the remote device, it is copied every time you need to perform an operation, which, to me, looks like a dirty trick. Remember, for proper ansible  (modules other than raw) to work you MUST have Python installed on the target machine. So all your security and performance concerns are the same for Ansible as they are for other tools. 

The biggest problem i see with ansible/puppet/chef is not the choice of the right tool (all of them would be able to accomplish similar set of goals) but the their availability on the target platforms. RIght now there are too few devices that have python or ruby runtime available for 3rd party intergration and development. Majority of enterprise-class devices still have only cli and snmp and for new devices cisco are offering only onepk (or aci-em). Majority of repetitive tasks, the ones that would benefit from automation, are done (in enterprise at least) on low-end device. That, i think, is the main problem with these tools, we simply can't use them yet. 

/Michael

[Jason Edelman]

You may :) 

I agree it is up for a great debate on agentless vs. a pseudo-agent that is copied and executed for each task.  If you are using modules in Ansible Core automating Linuxy things (other than raw), as you stated, you need python on the remote machine.  BUT, nearly all network modules built for Ansible from vendors such as Arista and Juniper and the ones I released today for Cisco Nexus platforms do NOT require any agent, so in that sense, those modules are truly agentless.  Same goes for Ansible's integration to public cloud providers that are using their APIs (creating AWS VPCs, etc.).  Agentless it would seem, and some of those are technically in core :) 

 What I find compelling is that you can take any script that uses expect or snmp and migrate it to be an Ansible module.  Ideally, more smarts get added to make it idempotent, but that is not a requirement, so to each their own.  It is up to us to create Ansible modules to automate "cli" based devices - because it is technically possible.

--

You received this message because you are subscribed to the Google Groups "network.toCode()" group.
To unsubscribe from this group and stop receiving emails from it, send an email to networktocod...@googlegroups.com.
To post to this group, send email to networ...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/networktocode/ec7c8f16-e7a0-4d46-9371-330019dd7c6b%40googlegroups.com.

[Ajay Chenampara]

Any thoughts on tailfsystems, now a Cisco company?

Cheers,

-ajay

 

To view this discussion on the web visit https://groups.google.com/d/msgid/networktocode/CA%2B_m3%2BaCL5A-CqsPBeApu%3DHCMxiT-mQZptTKFPu0uHbSxT2%3DzA%40mail.gmail.com.

[Jason Edelman]

I've only heard good things about Tail-F.  Would still need to look at its extensibility and price to see how they compare to other tools out there.

[David Barroso]

You don't need agents in Ansible if you don't want to. You can run the code locally on your server/laptop/computer and connect to the device via the API. Potentially you can even use this methodology to support legacy equipment (expect anyone?)

To view this discussion on the web visit https://groups.google.com/d/msgid/networktocode/CA%2B_m3%2BYsTGGfHLSrPv3kF%3DDdUvYQjtteS%3DhMVy7UWSbCbXcQNg%40mail.gmail.com.

[Matt Oswalt]

The "agentless" architecture in Ansible does turn a few heads; you're absolutely right that in normal cases, the module code is copied over SSH to be run locally on the device. So yes, it's agentless, but obviously not "dependency-less". When folks like Jason or myself write Ansible modules for network devices, these aren't designed to leverage this paradigm, since many routers and switches don't allow the sftp subsystem anyways. 

In this case, we use the "connection: local", which forces the module code to run locally on our laptop or whatever's running the playbook. Many other modules leveral local calls to the filesystem, etc. in their implementations, but our modules leverage the networking vendor's API over the network anyways, so running on our laptop is okay.

Hope that helps.

[John O'Connor]

Ajay, Ivan (@ioshints) has a pair of podcasts about about Tail-F. They discuss what is baked in to the product and what you need to do if you require something that isn't supported out of the box.

http://blog.ipspace.net/2015/02/hands-on-tail-f-experience-on-software.html

http://blog.ipspace.net/2015/02/hands-on-tail-f-experience-part-2.html

[Willard Dennis]

Not a dirty trick, just an architecture... If you are going to execute something remotely on a device, you have to have a) a communication channel, and b) and execution environment for the code you want to implement. No magic there :)

At least Ansible can be used to run locally on the management node itself (like say to create a device template, or build a command set) and then execute an API call against whatever the network device offers... That takes absolutely NO "agent" on the network device (other than what the vendor ships that implements the API.)

Will

On Monday, February 23, 2015 at 6:31:40 PM UTC-5, Michael Kashin wrote:

[Mike Biancaniello]

Actually, you don't need python running on the remote machine. If you set 'connection: local' then all the python is run on the local machine.

e.g. To use Ansible with JunOS (which does not support installing python), junos has published an ansible module that essentially uses their NETCONF API to communicate with the devices.

You can also use modules such as netmiko and trigger to communicate with devices that do not have an API.

On Monday, February 23, 2015 at 6:31:40 PM UTC-5, Michael Kashin wrote: