If you were at AnsibleFest NYC, you saw a sneak preview of Ansible Tower 2.2, coming this summer. For those of you that didn't, we thought we'd mention some of the things that are coming in the next release.
Ansible Tower remains the best way to run Ansible in your organization - marrying the simple, agentless, and powerful automation of Ansible with the control, security, and delegation you need to supercharge your IT teams ability to tackle complex automation tasks simply.
And we've worked to make Tower even better for you, bringing you new features like:
We've listened to our customers and foregrounded the things you need on a day to day basis.,Meanwhile, Tower’s new setup screen gathers all the parts of Tower the administrator needs to configure such as organizations, users, groups, and permissions, in one place.
Just add a Galaxy requirements file to your project directory, and Tower will automatically pull any playbook roles you need from Ansible Galaxy, GitHub, or any other centralized source.
Ansible is committed to help make OpenStack simple for everyone to use, and we've now made it simple to Continue reading
Yesterday, I posted about using Vagrant to learn Ansible, in which I showed you one way to combine these two tools to make it easier to learn Ansible. This is a combination I’m currently using as I continue to explore Ansible. Today, I’m going to expand on yesterday’s post by showing you how to make Vagrant automatically build an Ansible inventory for a particular Vagrant environment.
As you may already know, the Vagrantfile
that Vagrant uses to instantiate and configure the VMs in a particular Vagrant environment is just Ruby. As such, it can be extended in a lot of different ways to do a lot of different things. In my case, I’ve settled on a design pattern that involves a separate YAML file with all the VM-specific data, which is read by the Vagrantfile
when the user runs vagrant up
. The data in the YAML file determines how many VMs are instantiated, what box is used for each VM, and the resources that are allocated to each VM. This is a design pattern I’ve used repeatedly in my GitHub “learning-tools” repository, and it seems to work pretty well (for me, at least).
Using this arrangement, since I Continue reading
I’ve been spending some time with Ansible recently, and I have to say that it’s really growing on me. While Ansible doesn’t have a steep learning curve, there is still a learning curve—albeit a smaller/less steep curve—so I wanted to share here a “trick” that I found for using Vagrant to help with learning Ansible. (I say “trick” here because it isn’t that this is complicated or undocumented, but rather that it may not be immediately obvious how to combine these two.)
Note that this is not to be confused with using Ansible from within Vagrant as a provisioner; that’s something different (see the Vagrant docs for more information on that use case). What I’m talking about is having a setup where you can easily explore how Ansible works and iterate through your playbooks using a Vagrant-managed VM.
Here are the key components:
Vagrantfile
and any associated support files).Vagrantfile
, you’ll need an Continue readingFirst, we'd like to thank EVERYONE who attended, was a sponsor, or just followed along online via the AnsibleFest hashtag. While we will have a more in-depth recap, which will include video, we wanted to make sure the speaker's slides were easily available to everyone.
From Ansible:
Bill Nottingham - Ansible Tower 2.2
James Cammarata - Ansible V2 and beyond
Brian Coca - Ansible Tips & Tricks
Irakli Nadareishvili - API Academy- Building a Docker-ized Microservice In Node, Using Ansible
Be honest. How many of you are still logging directly into the systems that you administer, via SSH, and changing things? I am. It’s a hard habit to break, but it’s one worth breaking. Luckily I don’t have very many servers of my own to manage, but changing things manually, instead of modeling those things in a language of automation is a sure way to build up technical debt and regret it later.
It’s been a long time since I’ve done any sort of system administration as my day job. But I talk to Ansible customers on a daily basis, and I have seen all sorts of environments: simple, complicated, small, large, well-managed, and poorly-managed. But one constant that I see throughout is increasing complexity and scale. Even for small shops with a few users, today’s platforms for data management, cloud hosting, and containers require a lot more distinct machines under management for their operation than the good old days when a couple of bare-metal LAMP servers could run a full web application.
Many people have written about the exponential growth in computing: from the early days of mainframes hosting hundreds of users and applications, to a single server rack Continue reading