We have been working hard on some exciting changes to Galaxy that we think you’re going to like. The changes are substantial, and we want your feedback, so today we are releasing Galaxy 2.0 in beta.
Check it out and help us shape the future of Galaxy. Comments and bug reports can be filed at Galaxy Issues. Keep in mind that the beta site is purely a playground for trying out the new Galaxy. Any roles you import or remove will not be reflected in a future production Galaxy site.
What follows is a summary of some of the new features you’ll see on the beta site.
Using your GitHub login, Galaxy now interacts directly with the GitHub API. This allows you to import all the repositories you collaborate on, including those in organizations you belong to.
To make it even better, we decoupled roles from the Galaxy username. Roles imported into Galaxy are now namespaced by GitHub user rather than Galaxy username. This gives you the flexibility of importing roles from your GitHub account or from an organization. The repo namespace in Galaxy will exactly match the GitHub namespace.
This might sound scary, Continue reading
We have been working hard on some exciting changes to Galaxy that we think you’re going to like. The changes are substantial, and we want your feedback, so today we are releasing Galaxy 2.0 in beta.
Check it out and help us shape the future of Galaxy. Comments and bug reports can be filed at Galaxy Issues. Keep in mind that the beta site is purely a playground for trying out the new Galaxy. Any roles you import or remove will not be reflected in a future production Galaxy site.
What follows is a summary of some of the new features you’ll see on the beta site.
Using your GitHub login, Galaxy now interacts directly with the GitHub API. This allows you to import all the repositories you collaborate on, including those in organizations you belong to.
To make it even better, we decoupled roles from the Galaxy username. Roles imported into Galaxy are now namespaced by GitHub user rather than Galaxy username. This gives you the flexibility of importing roles from your GitHub account or from an organization. The repo namespace in Galaxy will exactly match the GitHub namespace.
This might sound Continue reading
If you missed our latest AnsibleFest in San Francisco you missed out connecting with over 450 members of the Ansible community and some amazing presentations from Splunk, NEC, Riot Games, J.Crew, SparkCentral and others.
Tickets are on sale now for AnsibleFest London and we are busy planning our New York event (details coming soon).
AnsibleFest San Francisco 2015 Presentations
This post is a direct result of the insightful questions asked by attendees during Ansible Fest 2015 San Francisco during the "Ask an Expert". This was a great opportunity for the Ansible Tower team to engage with customers of both Ansible and Tower and to understand their use cases, frustration, and love when working with our products.
*The "Ask an Expert" allowed attendees to sign-up for 15 minute slots to talk with Ansible employees about particular problems or use cases. This resulted in over 50 customer questions! Two Ansible employees were stationed at a heavy traffic area to engage attendees and listen to their initial questions or concerns to help choose from more than 15 experts to best engage with. Attendees then engaged with the expert, identifiable by the "Ask an Expert" picture included in their check-in packet, during their registered time.
* The "Ask an Expert" interaction was much more organic than the above description. Times often ran over when in-depth conversations were had and empty time slots were often filled with discussion from attendees in a more ad-hoc manor.
The feedback from the "Ask an Expert" from the attendees was overwhelmingly positive. I can say that the feeling Continue reading
This question is one of the many insightful questions asked by attendees during AnsibleFest 2015 San Francisco at our "Ask an Expert" tables. AnsibleFest was a great opportunity for the Ansible team to engage with customers of both Ansible and Tower and to understand their use cases, frustration, and love when working with our products.
The "Ask an Expert" program allowed attendees to sign-up for 15 minute slots to talk with more than 15 Ansible experts, resulting in over 50 customer questions!
Feedback from the attendees was overwhelmingly positive. I can say that the feeling is mutual from the Ansible team side! It was a joy to hear from so many users of Ansible and Tower.
Example AnsibleFest "Ask an Expert" sign-up sheet:
Now that we have the back story out of the way, let's get into the playbooks. Several attendees asked how to spin up multiple ec2 instances, all with differing tags.
Extrapolating from that question the user wants/concerns are:
From the above requirements I will demonstrate a general Continue reading
Hi, I'm David Federlein and you may know me from such tickets to the Customer Success Team as “How does Tower’s Dynamic Inventory use Private IPs?" and “How do I import my Ansible inventory to Tower?" Or perhaps you just knew me from grade school. If that’s the case I’d like to apologize for that incident with the fake perfume that smelled like farts and further reassure you that I never again ordered any novelty items from the back of comic books.
In regards to Tower and Ansible, I am here today to share some tips that may be of help in your endeavor for automated nirvana. Perhaps after I’ve shared some of this with you I can one day have someone call me “Sir” without adding “you’re making a scene.” Let’s get down to business.
By now you should be familiar with our love of cowsay, but cows can be dangerous! Don't kid yourself: If a cow ever got the chance, he'd eat you and everyone you care about! So if you’d like to turn off the bovines throwing taunting barbs as you run your playbook, remember two things:
1) That cow is judging Continue reading
Hi, I'm David Federlein and you may know me from such tickets to the Customer Success Team as “How does Tower’s Dynamic Inventory use Private IPs?" and “How do I import my Ansible inventory to Tower?" Or perhaps you just knew me from grade school. If that’s the case I’d like to apologize for that incident with the fake perfume that smelled like farts and further reassure you that I never again ordered any novelty items from the back of comic books.
In regards to Tower and Ansible, I am here today to share some tips that may be of help in your endeavor for automated nirvana. Perhaps after I’ve shared some of this with you I can one day have someone call me “Sir” without adding “you’re making a scene.” Let’s get down to business.
By now you should be familiar with our love of cowsay, but cows can be dangerous! Don't kid yourself: If a cow ever got the chance, he'd eat you and everyone you care about! So if you’d like to turn off the bovines throwing taunting barbs as you run your playbook, remember two things:
1) That cow is judging Continue reading
We’re happy to announce the release of Ansible Tower 2.4. In this release, we’ve focused on some core improvements for our customers operating in spaces like government and security who have specific needs around authentication and tracking, but we expect these features will be useful to much of our general user base as well.
No one wants to manage their users in multiple places, and many groups today use external providers for handling their identity and authentication. We’ve added support for pulling users and teams from either GitHub or Google Apps, using OAuth2. With this, you don’t need to add users directly to Tower - they can use the accounts they already have and are using in your organization.
Previously, for Enterprise users who have a standard corporate infrastructure Tower has included support for connecting to an LDAP or Active Directory server for user and team information. But not everyone exposes their LDAP for use with all internal services. With Tower 2.4, we’ve extended that enterprise authentication support to also include support for authenticating to a SAML 2.0 identity provider, and to authenticate against a RADIUS server. With this, Continue reading
As you may already know, Ansible Tower 2.3.0's release offers 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 the bootstrapping of Ansible for you, if it is not already installed. If Ansible is already installed, ensure that it is the latest stable version before proceeding with your Tower installation.
In addition to other bug fixes and performance improvements, the documentation for the Tower 2.3.0 release also included a few updates.
The biggest update for the Tower Documentation Set hits the Tower API Guide.
The REST API in Tower is browsable and simple to use, but you must be logged into your Tower instance to view the endpoints. Now, for the very first time, the Tower API endpoints have been included for easy review.
For example, the Ping Endpoint, which is fairly simple as an example, includes the following information:
Another feature we are trying out for the Tower 2.3.0 Documentation Set is a new custom search. At the bottom right of your browser screen, a new "search this site" button appears that scrolls the Continue reading
Just because your organization has a multi-OS strategy should not automatically increase the complexity of your environment management. Each OS vendor likely drags along its own ecosystem of partners, development platforms, support and capability matrixes, and for the most part, once a system is developed on a particular OS platform, it tends to stay there.
Enter cloud. With growing abstraction of the infrastructure layer, cloud has done a great job of providing enterprise IT organizations with a level of control and flexibility once only available to the most advanced of greenfield deployments.
Even in a cloud-deployed environment, there is still a lot of potential baggage based on your particular cloud vendor, let alone your entire development suite and application platform. In nearly all cases, once an app is written for a particular platform, it stays on that platform for the entirety of its lifecycle. If your primary cloud vendor doesn’t provide you an easy way to deploy-- in a supported manner-- your preferred application platform, customers face yet another area of complexity. Just like that, you could be stuck with few choices.
This is precisely why the joint Red Hat/Microsoft announcement today is a huge win for customers, and further Continue reading
We’re back again with a quick update to Galaxy. In the last release we did some cool things to make searching roles much easier. This release is a mini release focused on fixing a few bugs and adding minor enhancements we couldn’t squeeze into the last cycle.
Galaxy issues are tracked publicly at https://github.com/ansible/galaxy-issues. Here are the issues addressed in release 1.1.1:
#88 Role Data Should Show Last Modified Instead of Created Date
#86 `ansible-galaxy -r roles.txt` - Incorrect Example
#84 README.md Fails to Render When it Contains a Variable String Like
#82 "Sign in" Option Should Appear on Home Page Header
#81 Better Filter for RHEL/Centos -> EL in Platform Search
#53 Adding a Role Called "Ansible" Results in Un-named Role
#14 Add Galaxy support for Debian Jessie
#9 Periods in Role Names Cause Installs to Fail
As part of fixing issue #81, Better Filter for RHEL/Centos -> EL in Platform Search, we changed the way the new role filtering works. A lot of times you know what you’re looking for, and don’t want to wait for autocomplete suggestions. For example, you might be looking for a Platform value of ‘centos’. Typing Continue reading
Kolla provides production-ready containers and deployment tools for operating OpenStack clouds that are scalable, fast, reliable, and upgradable, using community best practices. Kolla entered the OpenStack Big Tent during the Liberty cycle by submitting Kolla to OpenStack technical committee oversight -- enabling the Kolla project and its contributors to have access to community resources such as marketing, technical resources, bi-yearly conference space and voting rights in the OpenStack Technical Committee election.
During the creation of the Kolla mission statement, we agreed as a community not to permit the selection of technology choices in our mission statement. Still: we knew we would choose Docker as our container runtime technology, and Ansible as our orchestration system. We made these choices not only because “that’s what all the cool kids are doing’ -- but also because they solve real technical problems for our problem domain. Docker solves our image management process and Ansible solves our multi-node deployment process. We could have chosen other technologies to solve these problems, but both Docker and Ansible do something orders of magnitude better than competitors: a complete and absolute focus on simplicity coupled with a high degree of capability.
Since a fundamental factor in outcome of Continue reading
Deploying OpenStack can be a challenging process, and securing it can be even more daunting. Fortunately, there's a new project in the OpenStack big tent that wants to make this process easier: openstack-ansible-security.
Securing an OpenStack deployment involves multiple levels of configuration:
The goal of openstack-ansible-security is to tackle the second level -- securing the host. A spec was proposed for the Mitaka release of OpenStack to secure OpenStack infrastructure hosts using the Red Hat Enterprise Linux 6 Security Technical Implementation Guide (STIG).
The STIG is a collection of best practices for securing a host and its services against common attacks. The collection is broken up into multiple sections, called categories. The STIG Viewer service makes these categories easier to review. The categories include:
These are meant to be stackable, so an extremely sensitive system would require categories 1, 2 and 3. Each STIG item provides a description of what needs to be changed, why it should be changed, how to change it, and Continue reading
Now that Ansible is a part of Red Hat, some people may wonder about the future of the Ansible project. Specifically, a few people have expressed concerns that Ansible may become more Red Hat-centric at the expense of other platforms or open source projects. Here is the good news: the Ansible community strategy has not changed.
As always, we want to make it as easy as possible to work with any projects and communities who want to work with Ansible. Now that we have the resources of Red Hat behind us, we plan to accelerate these efforts. We want to do more integrations with more open source communities and more technologies.
One of the reasons that Red Hat purchased Ansible in the first place was because Red Hat understands the importance of a broad and diverse community. Google “Ansible plus <open source project>” for nearly any project and you will find Ansible playbooks and modules and blog posts and videos and slide decks and all kinds of other information, all intended to make working with that project easier. We have thousands of people attending Ansible meetups and events all over the world. We have millions of users. We Continue reading
We began by searching for an orchestration and configuration management tool for our test lab, and we ended up with Ansible playbooks that we ship with our product.
Automation is a key tenet of our engineering team at AppFormix. Repetitive tasks are automated, such as those surrounding continuous integration, host configuration, maintenance, and backups. This saves time and allows us to document a task, which in turn enables others to understand, contribute, and use the automation. Our engineers spend their time creating our product that provides infrastructure performance optimization for cloud-based datacenters, leaving the mundane work to computers.
We began our automation with Python and Bourne shell scripts, since we were familiar with these languages. Such scripts worked great for a set of steps to perform on a single host, but become very complex when managing several hosts (like in a cloud). We used ssh, scp, and Fabric, but found it challenging to maintain configuration about every host and handle errors robustly.
As our engineering team and deployments grew in size, we needed a sustainable tool to configure our testbeds and deploy our software. We chose Ansible for a number of reasons, including:
We are really excited to announce the release of Galaxy 1.1. It’s only been a few short weeks since Galaxy 1.0 debuted, and here we are again!
This time we added some powerful enhancements to make searching Ansible roles a much better experience. With over 3,500 roles in Galaxy and more being added every day, it can be a real challenge to sift through platforms, categories and descriptions to find exactly what you need. In Galaxy 1.1 we solved this problem.
As the author of a role, you know better than we do how to describe the role and what terms users will search to discover the role. So to make describing roles better for authors and users, we replaced our limited set a categories with Galaxy Tags, allowing the author to add a list of free-form search terms to a role.
Let’s take a quick look at creating a role with Galaxy and using the new Galaxy Tags feature. We start by creating a role using the ansible-galaxy command line utility that comes installed with Ansible:
ansible-galaxy init ansible-role-myrole
This creates the following directory structure and some supporting files for the new role:
ansible-role-myrole/ Continue reading
The title should come as no surprise, as many have predicted such an acquisition in the past. The similar open source ideologies, the technology fit, the executive team's open source background and the rapid adoption of Ansible in the enterprise certainly draw parallels to the world's leader in open source technology. What was once a prediction is now reality, in just a little more than two years since Ansible, Inc., opened its doors, and we are thrilled!
Ansible made its name in IT automation, and our agile, simple and agentless model allowed us to reach beyond just configuration management and into application deployment and multitier orchestration. This helped to establish a strong lead in DevOps with CI/CD, while latching on to fast growing areas such as cloud, network and container management. Our open source project boomed, becoming one of the most successful projects on GitHub (#1 follower presence in IT automation) with more than 1,200 contributors. Ultimately, this success led to the Ansible project being named as one of 2014's top 10 open source projects, and a place in Gartner's ‘Cool DevOps Vendor’ report in 2015.
Our customer adoption has also rapidly grown since inception, with more than Continue reading
Knowing the members of our Ansible community is important to us, and we want you to get to know the members of our team in (and outside of!) the Ansible office. Stay tuned to the blog to learn more about the people who are helping to bring Ansible to life.
This week we're happy to introduce you to Peter Sprygada, who recently joined Ansible to tackle all things networking. Prior to joining us at Ansible, Peter built a long career building and operating next generation network infrastructures and most recently ran the EOS+ CS team at Arista focusing on the integration of network operations with DevOps methodologies. |
What’s your role at Ansible?
Mostly my days revolve around working closely with customers, partners and the fantastic Ansible community to bring more robust support for networking devices into Ansible and Ansible Tower. This includes applying Ansible to help evolve DevOps methodologies to solve problems associated with running network operations teams.
What exciting Ansible networking projects can you tell us about?
To start, we have been working closely with our network partners to transition many of the great modules that have been available in the wild and make them available to Continue reading