Your development team has completed weeks of work, delivering their masterpiece-an application-to IT for deployment, but it doesn’t work.
See, the developers made use of a different port, that now needs to be opened on the firewall so end users can communicate with the software. IT changed the firewall rule, but didn’t tell development, so they never even knew it was an issue. Later, they create another application with the same issue, except this time, it will be deployed in a different environment.
No procedure or policy was created to capture all of the changes necessary to successfully deploy the app, so the same thing happens again. It’s a vicious cycle.
IT departments struggle to manage thousands of configurations and hundreds of applications with everyone working in silos. Teams who develop the apps frequently are not on the teams that use them. Meanwhile, operations teams deploy apps they didn’t write and have to convey to the development team when changes need to be made in order for them to work in this new and foreign-to-development thing called "a production environment".
Sound familiar?
Today’s IT environments are extremely complex. In the past, applications and hardware were closely connected. Apps came from Continue reading
We held another free Ansible Training session today. These trainings are held online and are scheduled twice a month. If you haven't attended one yet, please register here. The trainings are free, run about two hours and cover a number of Ansible basics.
Here is the recording from today's session:
Ansible is about simple, yet powerful automation. We want to make automation easy for everyone to learn, use, and deploy, for developers, system administrators, and operators of every skill level.
Every day we hear the success stories of people who have been able to take Ansible’s powerful automation and use it to cut their IT costs, stabilize their deployments, and allow them to get back to their focus of their job rather than continually grinding through manual tasks.
On top of that, we’ve built Ansible Tower, a web interface and API that brings those same simple principles to applying command, control, and delegation to an Ansible deployment. Customers like Nike, Splunk, Grainger, and others use Tower to centralize their Ansible deployment, delegate credentials and tasks to users in a controlled manner, and allow easy self-service access to users without them knowing the specifics of those automation.
We’re always interested in making things simpler for our users, and this extends to deploying and trying Tower as well. That’s why we’ve decided to make Tower available for use with Vagrant - what’s simpler than that?
You can try out Ansible Tower in Vagrant with just a few commands.
In this post, I’ll just share a quick command that can be used to build and install a KVM guest using PXE instead of an ISO image. There’s nothing new here; this is just me documenting a command so that it’s easier for me (and potentially others) to find next time I need it.
I shared how to use the virt-install
command to build KVM guest domains in a blog post talking about working with KVM guests. In that post, I used an ISO image with the virt-install
command to build the guest domain.
However, there may be times when you would prefer to use PXE instead of an ISO image. To build a KVM guest domain and instruct the guest domain to boot via PXE, you would use this command (I’ve inserted backslashes and line returns to improve readability):
sudo virt-install --name=guest-name --ram=2048 --vcpus=1
--disk path=/var/lib/libvirt/images/guest-disk.qcow2,bus=virtio
--pxe --noautoconsole --graphics=vnc --hvm
--network network=net-name,model=virtio
--os-variant=ubuntuprecise
The key here is the --pxe
parameter, which virt-install
uses to instruct the guest domain to PXE boot instead of booting from a virtual CD-ROM backed by an ISO image.
Naturally, you’d want to substitute the desired values for the KVM Continue reading
OpenStack has long had a reputation for being difficult to install and manage. This reputation may be a bit overblown, but it's not entirely unwarranted.
The plain truth is that OpenStack has a lot of components, all of which must be working in concert to be successful. A simple misconfiguration in one component can lead to cascading failures throughout the system, which can then be difficult to diagnose and correct.
It's one of the essential problems of managing any distributed system: one must effectively manage both individual components (i.e. configuration) and the relationships between those components (i.e. orchestration).
Ansible is a simple tool that excels at both -- which helps to explain Ansible's surging popularity in the OpenStack ecosystem. Over the past year, several OpenStack projects have emerged to take full advantage of Ansible's power and simplicity.
We've been watching with great interest. Now we think it's time to get more directly involved.
On Monday, May 18th, we will hold an Ansible Collaboration Day at the OpenStack Summit. Our collective goal is simple and ambitious: to make the installation and management of OpenStack as simple as we can possibly make it.
The first part of the day will Continue reading
To celebrate the release of O'Reilly's Ansible Up and Running: Automating Configuration Management and Deployment the Easy Way by Lorin Hochstein we are offering a special package for Ansible fans. Buy an Ansible Tower Starter Kit and get a physical copy of the book, 2 Ansible t-shirts, 2 Ansible hats, stickers, pins and an Ansibull.
To take advantage of this offer simply purchase an Ansible Tower Starter Kit here and enter ansiblefan at checkout. Offer expires on 6/5/15 or while supplies last. Quantities are limited so act fast.
*Offer available to NEW Ansible Tower customers only.
With the recent release of Ubuntu 15.04, aka “Vivid Vervet”, the Ubuntu community has also unveiled an early release of LXD (pronounced “lex-dee”), a new project aimed at revitalizing the use of LXC and LXC-based containers in the face of application container efforts such as Docker and rkt. In this post, I’ll provide a quick introduction to LXD.
To make it easier to follow along with some of the examples of using LXD, I’ve created an lxd
directory in my GitHub “learning-tools” repository. In that directory, you’ll find a Vagrantfile
that will allow you to quickly and easily spin up one or more VMs with LXD.
LXD works in conjunction with LXC and is not designed to replace or supplant LXC. Instead, it’s intended to make LXC-based containers easier to use through the addition of a back-end daemon supporting a REST API and a straightforward CLI client that works with both the local daemon and remote daemons via the REST API. You can get more information about LXD via the LXD web site. Also, if you’re unfamiliar with LXC, check out this brief introduction to LXC. Once you’ve read that, you can browse some Continue reading