Cup of Joe with Jon and James
Two of Ansible’s very own Solutions architects, James Martin and Jonathan Davilla, will be hanging out at various coffee shops in the Washington, DC metro region in the upcoming weeks. Stop by during your lunch hour and ask them about automation, DevOps culture, Ansible, and the difference between a latte and a machiatto. Follow them on twitter for last minute updates @grepless and @defionscode.
3/13 , 11am-2pm - Swing’s Coffee 1702 G Street NW
3/27, 11am-2pm - Chinatown Coffee 475 H St. NW
We are excited to announce that the next AnsibleFest will be held in New York City!
We are still working out the details, but we wanted to make some tickets available at a huge discount. AnsibleFest NYC is currently being planned for early June and will be at a great venue in New York City. If you are flexible and can plan ahead as well as make changes to your schedule, these tickets are for you!
The SUPER Early Bird price is just $179 (over 30% off the standard price) and is only available until March 23, 2015.
Purchase Super Early Bird AnsibleFest tickets here
We'll be announcing the exact date and location soon!
Upon hearing the news that Red Hat had released the Atomic Host variant of Red Hat Enterprise Linux, I decided that it would be a good idea for me to take a look at the CentOS flavor of the Atomic Host variant. In case you’re unfamiliar, the Atomic Host variant is the result of Project Atomic, which aimed to provide a container-optimized flavor of RHEL/CentOS/Fedora. This container-optimized flavor would leverage rpm-ostree for atomic system updates (hence the name) and come with Docker preinstalled. What I found, frankly, disappointed me.
Before I continue, I will make two very important disclaimers:
Note that there has been no official announcement of the release of final builds of an Atomic Host variant for CentOS 7. So, it’s entirely possible that all the issues I mention here are known issues that will be addressed. That being said, I did find CentOS 7 Atomic Host builds dated March 5, 2015; this is the same date as the Red Hat announcement. It’s reasonable, therefore, to believe that these builds are very close to final builds.
It’s entirely possible these issues are the result of errors on my part. I’ve spent most of my time with Continue reading
In this post, I’m going to show you how to set up and run your own Docker Swarm cluster. Docker Swarm is a relatively new orchestration tool from Docker (the company) that allows you to create a cluster of hosts running Docker (the open source project) and schedule containers across the cluster. However, just scheduling and running containers across a cluster isn’t enough, so I’ll show you how to add service registration and service discovery to this environment using Consul.
In the event you’re interested in following along, I’ve created a set of files that will allow you to use Vagrant to run this Docker Swarm cluster (on your laptop, if so desired). You can find all these files in the “docker-swarm” folder of my GitHub learning-tools repository.
The Docker Swarm cluster I’m going to show you how to build has 3 major components:
There are lots of ways to enable self-service VMs within an organisation - what some might call 'a private cloud'. However, these usually require layers and layers of complex software. What if you could leverage your existing hypervisor and 15 lines of code to do the same? And what if those 15 lines became an even simpler single click?
Ansible Core contains a module for managing virtual machines in VMware vSphere environments called vsphere_guest. Using this one module we can talk to an existing vSphere instance to create new VMs, clone VM templates, and control and delete VMs. Couple up a simple playbook with Ansible Tower and we can do some pretty amazing things with very little effort.
Here's our playbook to create a new virtual machine from a template in vSphere:
The really important bit that's doing the work is the 15 lines associated with the 'Create VM from template' task. Note the extensive use of variables in this play to give us lots of flexibility. We'll make use of this in Tower in just a moment.
Tower 2.1 introduced 'Surveys', which are a great way to create interactive forms for a given play. The form can Continue reading
Over the last few days, I’ve been experimenting with Docker, Registrator, and Consul in an effort to explore some of the challenges involved in building a robust containerized infrastructure. While I haven’t finished fully exploring the idea (and documenting what I’ve learned), I did discover one interesting—and unexpected—interaction.
Here’s a quick overview of my testing environment:
Registrator, if you’re not already familiar with it, is a service registry tool that listens to the Docker Continue reading
We are in the planning stages of our next stop in the AnsibleFest 2015 tour. We had a our biggest turnout ever at AnsibleFest London and know that our New York event will be even bigger and better!
AnsibleFest NYC is currently scheduled for late May/early June in NYC.
Details are being finalized now and tickets will go on sale soon.
If you are interested in speaking please email [email protected]
If you are interested in sponsoring please email [email protected]
I’ve written about CoreOS a fair amount (see here, here, and here), but one of the things that is both good and bad about CoreOS is the automatic update mechanism. It’s good because you know your systems will stay up to date, but it’s bad if you haven’t taken the time to properly address how automatic updates will affect your environment (for example, you’ve manually started some Docker containers instead of using systemd unit files—when the CoreOS system reboots after an update, your Docker containers will no longer be running). Re-architecting your environment to fully account for this change in architecture and behavior is a larger discussion than can be addressed in a single blog post, but in this post I want to at least tackle one small part of the discussion: separating your persistent data. In this post, I’ll show you how to mount an NFS share on a CoreOS instance deployed on OpenStack (or any cloud that leverages cloud-init).
Now, you could probably go into your CoreOS instance and manually make these changes, but that’s still thinking the old way. In addition to thinking about keeping persistent data separate, we (data center/cloud architects) also need Continue reading