When you first start using Ansible, you go from writing bash scripts that you upload and run on machines to running desired end state playbooks. You go from a write-once read-never set of scripts to an easily readable and updatable yaml. Life is good.
Fast forward to when you become an Ansible power user. You’re now:
Writing playbooks that run on multiple distros
Breaking down your complex Ansible project into multiple bite-sized roles
Using variables like a boss: host vars, group vars, include variable files
Tagging every possible task and role so you can jump to any execution point and control the execution flow
Sharing your playbooks with colleagues and they’ve started contributing back
As you gain familiarity with Ansible, you inevitably end up doing more and more stuff-- which in turn makes the playbooks and roles that you’re creating and maintaining longer and a bit more complex. The side effect is that you may feel that development begins to move a bit slower as you manually take the time to verify variable permutations. When you find yourself in this situation, it’s time to start testing. Here’s how to get started by using Docker and Ansible to automatically test Continue reading
As part of a broader effort (see the post on my 2016 projects) to leverage public cloud resources more than I have in the past, some Docker Engine-related testing I’ve been conducting recently has been done using AWS EC2 instances instead of VMs in my home lab. Along the way, I’ve found Docker Machine to be quite a handy tool, and in this post I’ll share how to use Docker Machine with AWS.
By and large, using Docker Machine with AWS is pretty straightforward. You can get an idea of what information Docker Machine needs by running docker-machine create -d amazonec2 --help
. (You can also view the documentation for the AWS driver specifically.) The key pieces of information you need are:
--amazonec2-access-key
: This is your AWS access key. Docker Machine can read it from the $AWS_ACCESS_KEY_ID environment variable, or—if you have the AWS CLI installed—Docker Machine can read it from there.--amazonec2-secret-key
: This is your AWS secret key. As with the AWS access key, Docker Machine can read this from an environment variable ($AWS_SECRET_ACCESS_KEY) or from the AWS CLI credentials file (by default, found in ~/.aws/credentials
).--amazonec2-region
: The AWS driver defaults to Continue readingIn what has been a fairly classic “yak shaving” exercise, I’ve been working on getting Ubuntu 15.10 “Wily Werewolf” running with Vagrant so that I can perform some testing with some other technologies that need a Linux kernel version of at least 4.2 (which comes with Ubuntu 15.10 by default). Along the way, I ran smack into a problem with Ubuntu 15.10’s networking configuration when used with Vagrant, and in this post I’m going to explain what’s happening here and provide a workaround.
The issue (described here on GitHub, among other places) involves a couple of changes in Ubuntu Linux (and upstream Debian GNU/Linux as well, although I haven’t personally tested it). One of the changes is in regards to how network interfaces are named; instead of the “old” eth0
or eth1
naming convention, Ubuntu 15.10 now uses persistent interface names like ens32
or ens33
. Additionally, an update to the “ifupdown” package now returns an error where an error apparently wasn’t returned before.
The end result is that when you try to create a Vagrant VM with multiple network interfaces, it fails. Using a single network interface is fine; the issue only rears its Continue reading
Welcome to Technology Short Take #63. I’ve managed to (mostly) get back to my Friday publishing schedule, though I’m running much later in the day this time around than usual. I’ll try to correct that for the next one. In any case, here’s another collection of links and articles from around the Net on the major data center technology areas. Have fun reading!
While talking with customers over the past couple of weeks during a multi-country/multi-continent trip, one phrase that kept coming up is “lock-in”, as in “we’re trying to avoid lock-in” or “this approach doesn’t have any lock-in”. While I’m not a huge fan of memes, this phrase always brings to mind The Princess Bride, Vizzini’s use of the word “inconceivable,” and Inigo Montoya’s famous response. C’mon, you know you want to say it: “You keep using that word. I do not think it means what you think it means.” I feel the same way about lock-in, and here’s why.
Lock-in, as I understand how it’s viewed, is an inability to migrate from your current solution to some other solution. For example, you might feel “locked in” to Microsoft (via Office or Windows) or “locked in” to Oracle (via their database platform or applications), or even “locked in” to VMware through vCenter and vSphere. Although these solutions/platforms/products might be the right fit for your particular problem/need, the fact that you can’t migrate is a problem. Here you are, running a product or solution or platform that is the right fit for your needs, but because you may not be able Continue reading
In case you missed it, Ansible 2.0’s Windows support includes a number of improvements and new features that make automating Windows with Ansible easier. Because of Red Hat’s commitment to solid cross-platform management, you’ll also see an acceleration of these kinds of improvements in future Ansible releases. I’ll highlight a few of the items I’m most excited about from 2.0, and give a quick peek at what’s scheduled for future releases.
Update management is a common pain point for Windows administrators. The new win_updates module makes it easy to orchestrate updates during your maintenance windows- no more logging into individual machines to kick off updates or hoping a scheduled update pass actually ran!
2.0 shipped with a suite of modules for managing IIS. From configuring websites, AppPools, virtual directories, and more- now Ansible can deploy and manage your IIS apps with ease.
Since WinRM doesn’t have a built-in file transfer mechanism, Ansible has to jump through some “interesting” hoops to deploy its module code and copy files from the control host to a managed Windows box. Historically, this process was very slow, and could only transfer small Continue reading