Simple CI

CI / CD has become an integral part of the software development process, both in large and small companies and projects, including open source.

The most popular CI/CD systems are GitLab and Jenkins. Both of these systems are powerful, expandable and include many additional features. With the help of these systems, you can build CI / CD of any complexity.

But it often happens, especially on small projects, that the most simple and straightforward solution is needed, rather than functionality. In this case Ansible Semaphore is a good alternative to GitHub and Jenkins.

Ansible Semaphore is a web interface for running Ansible scripts with CI/CD capabilities. With it, you can turn your playbook into a simple CI/CD system.

The Ansible Semaphore interface resembles that of Jenkins and AWX. The description of the interface can be found in documentation.

The following assumes that the reader is familiar with Ansible.

Since a small project is assumed, we will take the Trunk development model. Unlike Git-flow, this model assumes the same branch for development and production. This greatly simplifies CI/CD.

Our pipeline will look like this:

All elements of the scheme are easily implemented on Ansible. And thanks to versioning and calling tasks on a schedule, all this will work automatically.

Create a repository on GitHub

We need two playbooks and the corresponding roles for them:

  • build.yml – to build the application and send it to S3 storage.

  • deploy.yml – to deliver the application to the servers of the dev- and production-environment.

Here is the source code: github.com/fiftin/ansible-semaphore-deploy-test.

Ansible Semaphore Interface

For those who are familiar with AWX, the interface will be clear. For the rest I will briefly tell. The interface has the following key entities:

  • Task – Ansible playbook execution process.

  • Task Template – the template on the basis of which the task is created.

  • Inventory – list of servers for which the task will be performed.

  • Environment – environment variables (extra vars in Ansible terminology).

  • Key – SSH key or login/password that Ansible will use to connect to the servers.

  • Repository – git repository where the Ansible playbook code is stored.

Project setup

Create 3 Inventory (here they are):

  • Build – indicates on which server the application will be built.

  • Dev – a list of servers to which the application will be deployed in the dev environment.

  • Production – a list of servers to which the application will be deployed in the production environment.

Let’s create 3 environments (here they are): Build, Dev, Production.

Let’s create 3 task templates (here they are):

  • Build – to build the application and send it to S3 storage.

  • Deploy to Dev – to deliver the application to the servers of the dev environment.

  • Deploy to Production – to deliver the application to the servers of the production environment.

launch

A task Build will be executed automatically when a new commit appears in the repository. Assemblies will be loaded into S3 storage.

After its successful completion, the task will be automatically launched Deploy to Dev, which will deploy the application to the Dev environment. A demo dev site is available at demo-dev.ansible-semaphore.com.

task Deploy to Production will need to be started manually. It will deliver the application to the Production environment only if it has been successfully deployed and tested in the Dev environment. Demo here: demo-prod.ansible-semaphore.com.

If you would like to install:

You can play around with the example described above on the site. demo.ansible-semaphore.com.

Similar Posts

Leave a Reply