
We’re happy to announce the release of Ansible Tower 2.3, our console and service that brings control, security, and delegation to your Ansible deployments.
Historically Tower has been installed with a simple setup playbook that you run with the Ansible you already have to download and install Tower. But not everyone has the luxury of access to the internet at all times.
Starting with Tower 2.3, we now offer a bundled installer for Red Hat Enterprise Linux and CentOS systems. This all-in-one installer contains everything you need to get Tower started in one bundle, including bootstrapping of Ansible for you as needed. All you need is a Red Hat or CentOS machine with access to the vendor OS repositories - no other external access required. The playbook installer is still available as well, and Tower is also still available via Vagrant image or AMI if you’d prefer to try it via that method.
As usual, this release of Tower includes a variety of bug fixes as well, including performance improvements around listing jobs and job templates.
For more information on Tower 2.3, check the release notes at: http://docs.ansible.com/ansible-tower/latest/html/installandreference/release_notes.html
To try Ansible Tower 2.3 Continue reading
Welcome to Technology Short Take #54! In this episode, I’ve gathered an odd collection of links and articles about key data center technologies. Without further ado, let’s get to the content.
Spousetivities returns to VMworld EMEA this year with a new set of activities. If you haven’t registered yet, here’s a quick look at the pretty impressive set of tours and activities that are planned.
For more detailed descriptions of the activities, I encourage you to visit the Spousetivities site. When you’re ready to get signed up, head on over to the registration page. These are some pretty great activities!
Many of the questions we frequently get are related to deploying applications and stacks into Amazon Web Services. Back in July, Ansible Government teamed up with partner DLT Solutions to host a webcast demonstrating the creation of a Red Hat stack in AWS entirely managed with Ansible. Watch it now and continue reading below for more information.
IT organizations look toward AWS for a number of reasons, but according to IDC, deploying applications in AWS results in a 64% lower TCO and 82% less downtime. Now let’s be honest. Who doesn’t like less downtime?
Red Hat is the leading Open Source provider for infrastructure and middleware solutions. Their industry-standard Red Hat Enterprise Linux and JBoss middleware are widely deployed in on-prem physical and virtual environments, and are the benchmark for stability, security, and performance.
But how can you leverage that power in AWS? With Ansible, it’s easy.
In the webcast, we demonstrate the deployment of a complete JAVA-based web application, including RHEL, JBOSS, and a load balancer. Once installed, we demonstrated how to use the same playbook that deployed the application to update the application. Better yet, these examples are available for you to start using and experimenting with today.
Here’s Continue reading
MYTH: using Ansible to do fully-automated provisioning of Windows instances in AWS is difficult, because WinRM is not enabled by default on Amazon’s Windows AMIs, and the admin password is not known at startup.
In this post, I’m going to show you how to use the Git command-line to check out GitHub pull requests locally. I take absolutely no credit for this trick! I picked this up from this GitHub Gist, and merely wanted to share it here so that others would benefit.
The GitHub gist shows you how to modify the Git configuration for a particular repository so that when you run git fetch it will fetch all the pull requests for that repository as well. This is handy, but what I personally found most helpful was a comment that showed the command to fetch a specific pull request. The command looks like this:
git fetch origin pull/1234/head:pr-1234
Let me break that command down a bit:
origin in this case refers to the Git remote for this repository on GitHub. If you are using the fork-and-pull method of collaborating via Git and GitHub, then you will have multiple Git remotes—and the remote you want probably isn’t origin. For example, if you want to fetch a pull request from the original (not forked) repository, you’d want to use the name that corresponds to the Git remote for the original repository (I Continue reading