Everyone loves the promise of containers.
More specifically: everyone loves the promise of a world where they can build an application on their laptop, and have that application run exactly the same way in every environment -- from their laptop all the way to production, and at every step in between.
That's still a holy grail, though. In the meantime, people seem to be looking for practical ways to get all of the advantages of containers -- consistency, lightweight environments, application segregation, and so on -- while still maintaining the flexibility required to work with the many environments that are not amenable to containerization.
Which may explain why so many people... wow, just a lot of people... seem to be talking about Ansible and containers together:
* Ansible playbooks are portable. If you build a container with a pure Dockerfile, it means that the only way you can reproduce that application is in a Docker container. If you build a container with an Ansible playbook, you can then reproduce a very similar environment in Vagrant, or in a cloud instance of your choice, Continue reading
When: June 4th
Where: Conrad Hotel NYC - 102 North End Ave, New York, NY 10282
AnsibleFest is a day-long conference bringing together Ansible users, developers and industry partners to share best-practices, case studies and Ansible news. If you are a developer, sysadmin, operations director or devops practioner, AnsibleFest is for you.
Past speakers have included Twitter, Google, Rackspace, EdX, HP, Twilio, Cumulus Networks, Telescope.tv and many more - as well as members of the Ansible Team.
SPECIAL OFFER: Buy an Ansible Tower Starter Kit and get 4 free tickets. Simply enter the promo code festnyc at checkout. BUY NOW
If you are interested in speaking, please contact [email protected]
If you are interested in sponsoring, please email [email protected] for details
Be sure to follow us on Twitter to stay informed of all of the AnsibleFest news. We'll be announcing some special surprises in the weeks leading up to the event.
Many security baseline processes are rife with challenges. Whether organizations use scripts to manually brute-force their system-level compliance baseline, or perhaps leverage the all-too-common “Gold Disk” approach, routine security baseline compliance remediation remains largely an unsolved and constant challenge even for the most mature of IT organizations.
Even for organizations that are using an existing management tool to help with their security baselining, issues frequently arise around how to identify systems that require baselining as they come online, and then immediately recognize what needs to be done on those systems in order to verify their compliance.
To add to the challenge, applying a baseline to a newly deployed server or application is one thing, but validating compliance throughout the server and application lifecycle typically requires a separate set of tools or processes, or at very least scripts that are smart enough to smartly change the existing state of a server or application without impacting its availability.
MindPoint Group knew there was a better way. The security folks at MindPoint group are leveraging the power and simplicity of Ansible to bring automation to the problem of security baselines. And thanks to Ansible’s design, the work that MindPoint group has done is Continue reading
“You’re a rockstar!” Chances are, you’ve either a) been told this as a compliment for some work you’d done; b) heard this told to someone else for some work they’d done; or c) told someone this for some work they’d done. If you said this to someone else—I just told someone this quite recently—chances are also very likely that you had nothing but positive intentions behind this statement and your goal was to compliment them on what you saw as outstanding work. But is “rockstar” the wrong term to use? And if so, what is the right term?
Recently, Tyler Britten (a very talented professional and a former colleague when I worked as an EMC vSpecialist) posted an article titled “Time to Retire the Rockstar,” in which he draws a connection between the use of terms like “rockstar,” “superstar,” “genius,” or “guru” and the myth of the lone genius. I see his point, and don’t necessarily disagree with it. Something can be said that calling someone a rockstar (or any of the other terms listed) isn’t automatically encouraging them to “eschew teams and communities and to work alone”, but that isn’t the point of this post. Here I’d rather Continue reading
When Ansible was first founded three years ago, the underlying premise was to simplify some of the complexity in the existing DevOps tools. The mere idea of needing a strong developer toolset to automate your IT infrastructure was an overwhelming concept for most. I believe this is one of the underlying reasons that the majority of the IT shops are still using home-crafted scripts to automate updates to their infrastructure and shying away from having to add more complexity to an already complex world.
The well known quote from, Dieter Rams, the famous industrial designer, saying: “Less but Better”, has become somewhat of a guiding principle for Ansible. Being able to achieve in few lines of YAML script, during lunch hour what you can’t do in days of writing code with others.
In fact, not only do we apply that principle to our products in general, but to other operational things we do at Ansible, Inc. - from our internal communication to the onboarding process of new employees to how we handle customer support tickets. We are building an organization and an enterprise product based on simplicity. In fact, I’ve become a strong believer in the notion that complex Continue reading
Ansible architect and craft beer connoisseur Jonathan Davila played a critical role in working with our trusted security partner MindPoint Group to get our joint automated security baseline project off the ground. With our release this week of the DISA STIG for RHEL 6, we’ve immediately improved the lives of Government IT admins that struggle to ensure their systems are compliant.
Merely building the Ansible role for Red Hat Enterprise Linux 6 (And CentOS variants) STIG required more than writing and organizing a collection of playbooks. In order to ensure that the role actually achieved the remediation goal, we needed to validate and verify updates through a continuous integration testing process that leverages the DISA-provided SCAP/OVAL definitions.
You can learn more about the mechanics of how Jonathan and the MindPoint Group built the STIG Role, along with technical details about how to replicate this testing method in your own environment here.
Want to learn more about the how and why? Jonathan also penned a LinkedIn article with his own thoughts about why this is an important step in the right direction for any IT organization that’s concerned about automagically applying and validating security baselines.
Learn more about automated baseline testing.
Continue reading