CI/CD has become an important 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 GitLab and Jenkins.
Ansible Semaphore is a web interface for running Ansible scripts with rudimentary CI/CD. With it, you can turn your playbook into a simple CI/CD system. This is an open source project that has been in development since 2015 and currently has 5200 stars on GitHub.
The Ansible Semaphore interface resembles that of Jenkins and AWX. The description of the interface can be found in the documentation.
The following assumes that the reader is familiar with Ansible.
For demo purposes 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 scheduling of Ansible Semaphore, all this will work automatically.
Firstly, 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- for delivering the application to the servers of the dev and production environments.
Here is the source code: github.com/fiftin/ansible-semaphore-deploy-test.
Web interface of Ansible Semaphore
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 - The process of executing the Ansible playbook.
Task Template - the template on the basis of which the task is created.
Inventory - a 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 servers.
Repository - a git repository where the Ansible playbook code is stored.
Project setup
Let's create 3 Inventories (link):
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 (link):
Build, Dev, Production.
Let's create 3 task templates (link):
Build - to build the application and send it to S3 storage.
Deploy to Dev - for delivering the application to the servers of the dev environment.
Deploy to Production - for delivering the application to the servers of the production environment.
We will deploy this simple web application: github.com/fiftin/ansible-semaphore-test-app :)
Launch
The Build task is executed automatically when a new commit appears in the repository. Successful builds are loaded into S3 storage.
After each successful build, the Deploy to Dev task is automatically launched, which deploys the application to the Dev environment. A demo dev site is available at demo-dev.ansible-semaphore.com.
You can play around with the above example at demo.ansible-semaphore.com.
Top comments (3)
Good afternoon people
Does semaphore work with wmi connection for Windows environments? I have some playbooks that are used to perform services in the Windows environment and I would like to trigger them via semaphore
Hi Denis, may I know how is the Build task executed automatically when a new commit appears in the repository? I did see related code in the source code github.com/fiftin/ansible-semaphor..., or I missed anything? Thanks.
Hi,
You should config your template with using Cron.