What does /g/ think of Ansible?

>>60621265
Love it.

>>60621265
You could explain what it is

File: Screen Shot 2017-05-28 at 12.09.56 AM.png (354KB, 1356x1600px) Image search: [Google]

354KB, 1356x1600px

>>60621881
what was not clear from the first page of google results that you wanted the OP to further explain?

and honestly if you don't even know what it is, why do you think the OP wants to know what you think of it?

File: 1475157201510.jpg (494KB, 1024x768px) Image search: [Google]

494KB, 1024x768px

>>60621881
>>60621893
>implying anyone on /g/ actually has a workplace where you'd come in contact with ansible

>>60621265
I'm an apprentice to our senior network engineer and as such usually get the work-intensive shit stuff to do like disabling a specific port on all switches or searching for the switch which has an access port in a specific vlan. I've written python scripts for this until now (paramiko scraping for cisco (yeah, this sucks) and pyez for junos) and am considering pitching Ansible at him.
Can it detect which OS a box has and use the correct modules accordingly? Or even just some means of detecting the OS so I can put in a conditional?

>>60622474
>Can it detect which OS a box has and use the correct modules accordingly
Yes.

>>60621265
It was the best candidate for ops automation we found at work a year and a half ago. Before that, we did a lot of manual setting up, which could take up to a week to replicate our stack in its simplest form. Now, our nightly build does it in about half an hour, and the setup is verified using a bunch of tests implemented in Ansible itself. It's beautiful.

Deployment speed and chance of errors have improved significantly as well.

Right now, we're trying to use Ansible for the dev setups as well to be as close as possible to production. It looks like it's going to be more convergence of dev and prod instead of making dev like prod, though, because containerizing prod like we do with dev would make our playbooks and roles much simpler, and details like dependencies to install can be handled by pure developers, who don't want to have much to do with ops.

One of the best things about Ansible is that you don't have to perfectly implement more complex ops things yourself thanks to some great roles that already exist. For instance, it just takes a handful of settings to set up OpenVPN or self-refreshing Let's Encrypt certificates.

great at making monkeys think they are engineers

File: 1495965362669.jpg (9KB, 450x338px) Image search: [Google]

9KB, 450x338px

>>60621265
>open tar archive
>uses the zip utility by default
>open zip archive
>uses the tar utility by default
really fired up my neurons after debugging that shit for 3 hours

>>60626351
Ansible did this?
Oh well, Puppet it is.

>>60621265
Ansible itself is pretty useful, but YAML sucks

Also, has anyone had any luck using ansible to deploy to docker? I tried it for a bit and it seems somewhat redundant

>>60626412
>Also, has anyone had any luck using ansible to deploy to docker? I tried it for a bit and it seems somewhat redundant
It's sometimes a bit quirky, but generally works quite well. The docker(-compose) module is consistent with the CLI/docker-compose format.

Using Docker reduces Ansible's usefulness, but it doesn't eliminate it. It's still great to get the host system Docker-ready, do some security stuff, and orchestrate whatever containers are running on the system.

In case of provisioning an image using Ansible, I've been there too. For most practical purposes, a simple Dockerfile is completely sufficient. I would only go so far to use Ansible to build an image in very complex cases, and those are usually the ones where Docker is abused (images should be simple).

Well, I have been working with that for a year, and this is what I experienced:
Pros:
No need for agent on the client side, so it is great for nodes,where you have only SSH access
Human readable, so for system administrators, it can be easier to understand and operate.
Uses Python and jinja instead of ruby and erb (Not a python fanboy, but erb is a mess)
Serial execution. More deterministic, and testable.
Cons:
Idiotic variable usage (I guess they fixed it in 2.0)
Playbooks are really tied into the distribution
Lack of interfaces. Everything needs be written down using the concrete module. As a developer, I missed using interfaces, and polymorphism (Puppet provided such tools)
Core Ansible developers can choose the most idiotic ways to implement modules (seriously, who uses aptitude?)
Module writing is a mess. You have to write it for every single distribution ever. Python versioning can fuck up your module.

>>60626495
How did you deal with deployment? I was working with a docker registry, and was trying to figure out if it made sense to use ansible to:

A) manage the machine with the registry stored on it
B) build the images and deploy them to the registry
C) have the production nodes pull from the registry instead of having them build the containers

In all cases, the answer to me seemed to be "yes" but it caused my ansible setup to quickly balloon to massive size just to deploy one app with a few components. I suppose the upside is that once this all is in place, it easily scales out to a bigger production setup with more apps?

>>60627334
>A) manage the machine with the registry stored on it
>B) build the images and deploy them to the registry
>C) have the production nodes pull from the registry instead of having them build the containers

That's exactly how we do it. CI takes care of image building, Ansible creates containers from those images. Access to the registry (which is in a VPN) is handled using a remote tunnel in the inventory.

Building the image with CI makes sense, because the build nodes need to have the relevant tools anyway, and production servers stay free of non-runtime stuff.

Scaling horizontally is a breeze. Just add a host to the relevant group in the inventory and done. Delegation can be used to add new hosts to stuff like monitoring and load balancers.

One thing I'm not quite happy with yet is how we deal with staged deployments. Right now, we manually keep track of which hosts have been deployed, and continue with more at a later time. I could imagine a long-lived Jenkins pipeline to keep track of that in a more automatic way, but that's probably abuse of the technology.