Deploy Packages From a Cloudsmith Repository With Ansible

What is Ansible?

Ansible is an open source continuous configuration automation (CCA) tool.  You can use it to automate the management of the configuration of host systems. For example: installing and configuring applications, services, security policies; or to perform a wide variety of other administration and configuration tasks.

You also can use Ansible with a provisioning tool (such as the excellent Terraform, from the awesome folks over at Hashicorp) to automate the entire build and deployment of your infrastructure, and take steps towards true Infrastructure-as-code DevOps practices.

Ansible And Cloudsmith

Ansible is also a perfect partner for your artifacts and assets stored in your private Cloudsmith repositories.  As your Cloudsmith repositories can be your single source of truth, with all the access control and permission control that they provide, they give you another secure layer to your infrastructure build and management. By providing you with control of the sources of your packages that you use with your Ansible configuration automation, you insulate yourself further from any upstream changes.

Getting started – The Ansible Playbook.

An Ansible playbook is where you define the series of tasks that you wish to perform to ensure the configuration of your hosts is in the desired state.  As an example, we have created an Ansible playbook that will install and configure a Cloudsmith repository for Debian packages, and then install a package from this repository

Here is our example Ansible playbook:

- hosts: DebianHosts

remote_user: dmckinney

tasks:

- name: add Cloudsmith Repository GPG key

apt_key:

url: https://dl.cloudsmith.io/QOH0JBRgKQx5lE7S/demo/examples-repo/cfg/gpg/gpg.7D4D4CE49534374A.key

state: present

become: yes

- name: add Cloudsmith Repository

apt_repository:

repo: 'deb https://dl.cloudsmith.io/QOH0JBRgKQx5lE7S/demo/examples-repo/deb/debian buster main'

state: present

update_cache: yes

become: yes

- name: install Cloudsmith Example package

apt:

name: cloudsmith-debian-example

state: present

update_cache: yes

become: yes

Let’s break down what this playbook will do.

Hosts:

This is where we specify which of our hosts these tasks will run against. The hosts and their addresses are defined in a separate Ansible Inventory file and for this example, our inventory file is just a single host.

These hosts can be bare metal servers, cloud instances or virtual machines etc. You can define different groups of hosts within a playbook for different tasks and in this way a single playbook can manage a single machine or several hundred or even thousands of hosts.

Remote User:

This is where you specify the user on the host machine that the tasks will run as

Tasks:

This is where we specify the tasks themselves.

The first task is the “add Cloudsmith Repository GPG key” task.  This task uses the apt_key ansible module to retrieve the GPG key from our Cloudsmith Repository and install in on our host system. We specify the URL for the GPG key and as this is a private Cloudsmith repository the URL contains an embedded entitlement token to authenticate for read only access:

- name: add Cloudsmith Repository GPG key

apt_key:

url: https://dl.cloudsmith.io/QOH0JBRgKQx5lE7S/demo/examples-repo/cfg/gpg/gpg.7D4D4CE49534374A.key

state: present

become: yes

We also add the `state: present` – which means Ansible will install the key if it is not already installed, and if it is already installed it will do nothing. This is important, as it means our task will be idempotent, meaning no matter how many times we run this task the outcome, and therefore the configuration will always be the same.  We will see this `state: present` in all our ansible tasks in this playbook.  Finally, as all apt operations on our host system require sudo permissions, we add `become: yes` which tells ansible to run this task with elevated permissions. Again, we will see this on all tasks in this playbook.

The second task is the “add Cloudsmith Repository” task. This task uses the apt_repository Ansible module to install our Cloudsmith repository on our host system.  We specify the URL for the repository, again containing our embedded entitlement token for authentication:

- name: add Cloudsmith Repository

apt_repository:

repo: 'deb https://dl.cloudsmith.io/QOH0JBRgKQx5lE7S/demo/examples-repo/deb/debian buster main'

state: present

update_cache: yes

become: yes

The final task is the “install Cloudsmith Example package” task, and this task uses the apt Ansible module to install a deb package. We just need to specify the name of the package we wish to install:

- name: install Cloudsmith Example package

apt:

name: cloudsmith-debian-example

state: present

update_cache: yes

become: yes

And that’s it, that’s all we need in this playbook to get this repository set up and our package installed.

Running the playbook.

To run a playbook, we use the `ansible-playbook` command:

ansible-playbook -i cloudsmith-demo-inventory cloudsmith-demo-playbook -K

the -K flag tells ansible to ask for our sudo password, but you can also store secrets and password encrypted using Ansible Vault – which means you could check the encrypted vault file into your version control system, alongside your playbooks themselves. But to keep things simple for this example, we will just have ansible ask us for the password:

When we run this playbook, the output was as follows:

You can see that the three tasks ran successfully, and report that they made a total of three changes. If we now check what packages we have installed our Debian host, we can see our cloudsmith-debian-example package:

And finally, if we were to run this playbook a second time (or any subsequent number of times), it reports that all tasks are OK, no changes need to be made:

In Closing

While this is a very simple example, we hope that it demonstrates the possibilities and the power of using a configuration automation tool like Ansible in association with a private Cloudsmith repository. It gives you the ability to automate not only common system configuration tasks, but deployment of your own packages, your own custom configurations and even the software build of your entire infrastructure. You can version these builds in your version control systems, track changes and provide an audit-trail-of-truth all the way back to your packages, stored securely in your own private repositories.

We hope you have very happy continuous configuration automation!

Liked this article? Don\'t be selfish (:-), share with others:   Tweet