5 Reasons to Use Ansible in Government

January 29, 2015 by Justin Nemmers


As many US Government programs look to adopt DevOps and agile development methodologies, there’s a need for tools to manage the application lifecycle, and make it easier and more predictable to deploy and manage entire application environments.

So why do Government customers chose Ansible?


Ansible does not require a software agent to be running on the remote hosts it manages. Instead, it relies on the trusted management ports you’re already using on a daily basis to log into your servers: secure shell (SSH) on Linux, and Windows Remote Management (WinRM) on Microsoft-based systems. This means that you don’t need to change existing firewall port filtering rules, which removes a large barrier to entry that other tools that run an agent require.

Additionally, agentless management means that there is little likelihood of a library conflict. What happens when a management tool agent requires one version of a library, but your application requires another?

Finally, Ansible’s agentless model does not increase your system’s security footprint or attack profile. Ansible relies on the operating system’s encryption tooling, and ensures that there are no separate agents that require vulnerability patching.

More Than Just CM

Configuration Management in the Government space is nothing new. Government programs have used tools including HP Server Automation (formerly Opsware), BMC BladeLogic, and more recently, Puppet and Chef.

However, your applications are not just a collection of files. Effective application deployment requires a tool that can provision resources, make configuration changes, run commands in a variety of environments, change states of network infrastructure, etc. Configuration management alone doesn’t do these things, but configuration management plus orchestration can.

Human-Readable Playbooks

Ansible Playbooks and Roles are written in plain-text YAML, and are human readable, and themselves easily managed using a versioning control system. Playbooks and Roles can be shared with various stakeholders who, knowing little to nothing of Ansible, will be able to interpret what the Playbook or Role is describing. For instance, a team that needs Information Assurance approval for environment and application deployment changes can submit a Playbook for review and approval. In turn, this process eases management and reduces delays by streamlining the change management process.

Audit Trails and Role Based Access Control

Role-Based Access Controls (RBAC) are built into Ansible Tower from the beginning. RBAC allows Tower admins to delegate access to server inventories, Playbooks, and Roles. Administrators can also centralize the management of various credentials, allowing end users to leverage a needed token without ever exposing that token to the end user. This has a dually interesting effect: increasing security and streamlining management.

Tower also keeps a detailed record of every action a user takes within the system, whether initiated via Tower’s UI, API or CLI.

Unify Providers

Often Government environments have multiple providers that are each responsible for one specific contract area. The company that develops the application is different from the one that is tasked with deploying and maintaining it, and yet another contract covers the infrastructure that the application runs on. In this model, miscommunication abounds, and your application’s users are negatively affected.

Using Ansible to create and maintain a precise definition for each application greatly reduces the likelihood of just such a miscommunication. When the initial application is delivered to the deployment and management team, an Ansible Playbook that perfectly describes how to deploy that application greatly reduces the likelihood of miscommunication and the ensuing finger-pointing that often occurs in these environments when something goes wrong.


Ultimately, application development, deployment, and ongoing management doesn’t have to be so difficult.  Ansible Core provides you with the end-to-end capabilities your organization needs to quickly and easily start managing existing applications, even helping move them to the cloud. Ansible Tower further extends the power of Ansible Core by enabling push-button access to the various Playbooks and Roles that define your environments and applications. The right tools make everything easier, so why not give them a try for yourself?


Ansible Tower


Justin Nemmers

Justin is the former GM, Ansible, Red Hat. He has spent a career helping organizations transform their IT environments by adopting new and making better use of existing technologies. Over his career, he has held both technical, sales, marketing and product leadership roles at a number of organizations, including Red Hat, where he ran a large services team. He resides in Raleigh, NC with his wife and children and tweets from @justnems.

rss-icon  RSS Feed