Ansible has logging plugins to send the data to log stash, log DNA, etc. But is it possible to log specific details like person who ran the playbook, on what servers playbook was executed , IP addresses. I am trying to understand whether is there any module specifically for logging.
I bet the thing you want is ARA from the OpenStack folks. I have been using it for a while and find it a ton easier to read than wading through a sea of log output.
That said, you may also be happier with AWX, or "Tower" (their commercial verion). Using AWX would have the benefit of enforcing access to the playbooks, versus asking people to correctly configure their ansible.cfg to use ARA.
Related
Assume that a normal deployment script does a lot of things and many of them are related to preparing the OS itself.
These tasks are taking a LOT of time to run even if there is nothing new to do and I want to prevent running them more often than, let's say once a day.
I know that I can use tags to filter what I am running but that's not the point: I need to make ansible aware that these "sections" executed successfully one hour ago and due to this, it would skip the entire block now.
I was expecting that caching of facts was supposed to do this but somehow I wasnt able to see any read case.
You need to figure out how to determine what "executed successfully" means. Is is just that a given playbook ran to completion? Certain roles ran to completion? Certain indicators exist that allow you determine success?
As you mention, I don't think fact caching is going to help you here unless you want to introduce custom facts into each host (http://docs.ansible.com/ansible/playbooks_variables.html#local-facts-facts-d)
I typically come up with a set of variables/facts that indicate a role has already been run. Sometimes this involves making shell calls and registering vars, looking at gathered facts and determining if certain files exist. My typical pattern for a role looks something like this
roles/my_role/main.yml
- name: load facts
include: facts.yml
- name: run config tasks if needed
include: config.yml
when: fact_var1 and fact_vars2 and inv_var1 and reg_var1
You could also dynamically write a yaml variable file that get's included in your playbooks and contains variables about the configured state of your environment. This is a more global option and doesn't really work if you need to look at the configured status of individual machines. An extension of this would be to write status variables to host_vars or group_vars inventory variable files. These would get loaded automatically on a host by host basis.
Unfortunately, as far as I know, fact caching only caches host based facts such as those created by the setup module so wouldn't allow you to use set_fact to register a fact that, for example, a role had been completed and then conditionally check for that at the start of the role.
Instead you might want to consider using Ansible with another product to orchestrate it in a more complex fashion.
Imagine a server setup with Ansible with a production and a reference system/cluster and a separate server running Ansible (with ssh-keys). The different clusters are identified in two inventory files.
Every playbook usage will somehow look like ansible-playbook -i production ... or ansible-playbook -i reference....
How do I prevent an accidental usage of the production inventory?
This could happen easily by either using an history entry in the shell or copy the command from some documentation.
Some ideas:
As a start every documentation is referring to the reference inventory and is also using --check.
Use two different Ansible instances and the common part is mirrored via Git. But this will result in some overhead.
Prompt once for i.e. database passwords and use different on production and reference. But not all task/tags have such a password requirement.
Actually I'm looking for something like a master password when using a specific inventory? Or a task that is always executed even if a tag is used? What is the best practice here? Do you have other ideas? Or am I somehow totally wrong here and there is a better way for my scenario?
Your production inventory could either be vaulted or even just include a vaulted file (which doesn't actually have to contain anything).
This will mean that when you attempt to run:
ansible-playbook -i production playbook.yml
It will fail with a message telling you to pass a vault password to it.
The vault password could be something simple such as "pr0duct10n" so it's entire purpose is to remind people that they are about to run it in production and so to think things through (much like how many people use a sudo password).
I have been looking into Ansible vault but want to check something incase I have missed a crucial point.
Do you have to run the playbook and provide the password. Encrypting the data seems a great idea but if I share the playbook the person running it will require the password. If they have the password then they can decrypt the file and see the data.
I would like to use it to set passwords for files but would like non admins to be able to run the playbook.
Have I missed something. I am struggling to see its worth if this is the case.
Thanks
The purpose of the vault is to keep secrets encrypted "at rest" (eg, in your source control repo, on-disk), so that someone can't learn the secrets by getting ahold of the content. As others have mentioned, if you want to delegate use of the secrets without divulging them, you'll need an intermediary like Tower.
In your case you need something that will be brokering ansible execution. Because like you've said an encryption would be useless if you share the password.
Like it's mentioned in the comment you can use Ansible Tower, or you can try and set a simple http endpoint that will be trigerring ansible based on specified parameters.
My current Ansible project is setup like so:
backup-gitlab.yml
roles/
aws_backups/
tasks/
main.yml
backup-vm.yml
gitlab/
tasks/
main.yml
start.yml
stop.yml
backup-gitlab.yml needs to do the following:
Invoke stop.yml on the gitlab host.
Invoke backup-gitlab.yml on a different host.
Invoke start.yml on the gitlab host.
The problem I'm running into is Ansible doesn't seem to support a way of choosing which task files to run within the same role in the same playbook. Before I was using tags to control what Ansible would do, but in this case tagging the include statements for start.yml and stop.yml doesn't work because Ansible doesn't appear to have a way to dynamically change the applied tags that are run once they are set through the command line.
I can't come up with an elegant way to achieve this.
Some options are:
Have each task file be contained within its own role. This is annoying because I will end up with a million roles that are not grouped in any way. It's essentially abandoning the whole 'role' concept.
Use include with hard coded paths. This is prone to error as things move around. Also, since Ansible deprecated combining with_items with include (or using any sort of dynamic looping with include), I can no longer quickly change up the task files being run. Any minor change in my workflow requires lots of coding changes. I would really like to stick with using tags from the command line to control exactly what Ansible does.
Use shell scripts to invoke separate Ansible playbooks.
Use conditionals (when clause) on every single Ansible action, and control what gets run by setting variables. While several people have recommended this on SO, it sounds awful. I will have to add the conditional to hundreds of actions and every time I run a playbook the output will be cluttered by hundred's of 'skip' statements.
Leverage Jinja templates and ansible's local_connection to dynamically build static main.yml files with all the required task files included in the proper order (using computed relative paths). Then invoke that computed main.yml file. This is dangerous and convoluted.
Use top level Ansible plays to invoke lower level plays. Seems messy, also this brings in problems when I need to pass variables between plays. Using Ansible's Python Api may help this.
Ansible strives to bring VMs into idempotent states but this isn't very helpful and is a dated way of thinking in my opinion (I would have stuck with Chef if that is all I wanted). I want to leverage Ansible to actually do things such as: actively change configuration states, kick off processes, monitor events, react to events, etc. Essentially I want it to automate as much of my job as possible. The current 'role' structure (with static configurations) that Ansible recommends doesn't fit this paradigm very well even though their usage of remote command execution via SSH gets us so close to the dream.
Just use a playbook for these types of management tasks.
Granted the skip statements do somewhat clutter the output. If you wish to fix that you can further breakdown the roles into something like aws_backups-setup and aws_backups-managment.
Also the roles documentation has some information on how you can run pre_tasks and post_tasks on roles.
The problem is best described with an example:
There are two roles:
mailserver: a basic mail server configuration
mailinglist: mailing list application
The mailing list software needs the mailserver to transport incoming mails to the mailing list software's "virtual inbox". This requires some configuration of the mail server. But the mailserver does not know about the mailing list role, nor other roles with similar configuration requirements.
What I would like to do is this:
mailinglist (and other similar roles) stores the transport configuration in a variable transport_config. This could be a "transport map" like $email => $spool.
mailinglist depends on the mailserver role.
mailserver configures it's "transport" using the variable transport_config.
Is there a way to do something like this in Ansible? Or another solution to this problem? It's not possible to use role variables like {role: mailserver, transport_config: ...}, as there may be more than one role depending on the mailserver.
What I can think of is a workaround: The mailserver reads/parses a configuration directory where transport maps are defined. mailinglist and other roles add files to this directory. The problem here is that this often requires a "configuration builder" which reads such configuration directories and generates the main configuration file.
You can accomplish this using role dependencies.
In the mailinglist role under roles/mailinglist/meta/main.yml, add something like this:
---
dependencies:
- { role: mailserver, transport_config: ... }
Do the same for any other similar roles.
In response to your comment about a "configuration builder", see the assemble ansible module. The tricky part might be getting all the files into one place, before you run the assemble module.
Otherwise, tima's suggestion of host_ and group_vars makes sense.
I know this is long answered, but I only just found a workable solution, and it's a little sneaky.
I use a third settings role, which has no tasks, only variables in a defaults/main.yml. The docs are a bit vague on this, but values here get rippled to all dependent roles, so if both roles depend on settings through their meta/main.yml files, both get a common set of values. These are overridable in the usual ways, through a group_vars file.
The surprise to me was that since, yes, the settings role is used more than once, it doesn't matter because there are no tasks in it, and that data can flow from there up the chain of dependencies.
It's an entirely new form of data flow in Ansible that I didn't know was possible.
Consider managing the mailserver configuration file with something like dotdee:
Original Post by Dustin Kirkland describing the concept
Dustin's dotdee repository
A simpler implementation with less features in Python
With dotdee, you assemble your final configuration file from a series of files placed in a .d directory.
In your case, the mailinglist role and others depending on mailserver would drop configuration snippets in a .d directory (created by the mailserver role) and run a command to update the mailserver configuration file like dotdee --update /path/to/mailserver/conf.
I'm not familiar enough with your apps here to be sure, but I'm thinking that you may be better served using host or group variables to pass your configuration in to your roles. The roles can hold your defaults et al and expect to retrieve host/group variables values that you set on an individual basis. This may mean treating each app instance as a host rather than psychical host. How you model it depends on many finer points in your workflow, configuration and app.
This recent thread touches on some of this sort of thing: https://groups.google.com/forum/#!topic/ansible-project/yrnsx2Mw6rc