Properly designed and implemented automation system requires its own infrastructure. You need to place components like code and configuration repository, agents responsible for executing the automated tests, acceptance tests software and tool to define automation processes. A leader in the last category is Jenkins. You can use it to automate the building, testing and deployment processes. Many of Jenkins features are available as plugins. In my previous post, I recommended running the infrastructure components as Docker containers. That includes Jenkins as well. You can use official images available on Docker Hub, but very soon you will find those images are missing many components, so you need to make your own. Of course not manually! Let Jenkins build the Jenkins image!Read More
The more you work with automation, the more you will like the containers. They fit and scale correctly in CI/CD model and can be easily managed. The whole infrastructure for automation should be flexible, easy to maintain and extendable – containers fit perfectly into this model. So why not start from putting Jenkins in the container?Read More
Everyone who worked on any project knows that sites like GitHub, GitLab or StackOverflow are full of open-source examples, functions, issue solutions and so on. I used them as well. It is not obligatory, but I feel that it is fair if I share something I create that may be useful for others. After all, I know what I was looking for in the past. No matter if we are creating Python script, the Java application or Docker templates.
I decided to create a small project called the DockerTemplates. The repository contains at the moment docker-compose files for various products I set up using Docker containers. I prefer using the docker-compose for everything even project consists only of one container. I find it the easiest way to maintain a consistent approach across multiple systems or projects. You will find the docker-compose configuration files in folders named after the application. In each folder, there is a separate documentation of what are the configuration details implemented in each file.
The initial release of this repository contains configuration files for following applications:
The repository will accept pull requests for any registered GitLab user so it is easy to participate and put your configuration. Please check requirements described in CONTRIBUTING.md guideline. You can also email files directly to me or leave a comment.
In many deployments, people do not run the Ansible playbooks directly via command line. In the long term, it is not flexible and cannot provide proper permission granulation as well as trusted code control. So people use Ansible or its free version – AWX. Every playbook, no matter how you run it, needs an inventory definition. Sometimes you use static files with a list of hosts, another time you use the script that dynamically provides the inventory for the playbook. We call it then a dynamic inventory.
If you keep your Ansible project with all scripts and playbooks on GIT repository, you can import it to AWX. You can also maintain dynamic inventory scripts as a part of your project and use them to build AWX inventory.
Best way to learn Ansible and the whole idea of automation is to start from the small playbooks and then grow big. If you first automate simple tasks, even those that may be easier and quicker to perform from the command line, you will learn how Ansible is working. Let’s say, we want to test if SNMP is responding on the remote host (we name it HostA). We will use SNMPv3 and authPriv security model. And of course, we want to write the Ansible playbook and run it on server HostNOC.
Ansible is one of the powerful tools providing us an automation of recurring tasks. In the current world, it is impossible to manage infrastructure manually efficiently. Many people still do this but the world has already changed and we need to progress otherwise our business will be cost ineffective. You can provide static inventory – list of the devices where you want to execute the playbook. But in dynamic environments, such as Cisco VIRL simulations you don’t want to edit inventory file manually. That is why I use Python script that will generate Dynamic VIRL inventory for Ansible playbook for me.
Now it is time to create Lambda functions for our small state machine. The first one will fetch version stored in S3 bucket object; the second function will get it from firewall using REST API. Then we will pass the collected values to the third function. With AWS Step Functions it is very easy to achieve!
In the previous post, I told you that it is not possible to update State Machine configuration once you create it. I prefer an approach like in API Gateway where you have stages of the same project, but Amazon for some reason did not follow this way. So if you want to deploy a new version of your Step Functions project you need to delete old and create new State Machine. Using the GUI interface is not efficient in a long term, you can do this much easier using AWS CLI.
AWS has many great tools and products that may simplify your task. In day to day work, no matter if you are networks engineer, software administrator or have a different role in your organization you will perform small repetitive tasks to complete the bigger project. Writing a long, complex scripts or programs is a solution, but it is flexible? Step Functions is a good option in such cases.
Good programming rule is to create small functions to complete small chunk of work and then pass it on another one. So instead of writing one script that will log into 100 devices to fetch firmware version you create a small function that does it for one device and then you call it in a loop in other function passing the new IP as an argument. That is exactly what AWS Step Functions are meant for. Using this service you can create a flow of small tasks, each dependent on other if required, to complete bigger work. Let me show you the basics and how you can use it.
It is time for some new final tuning of my small certificate signing service. In previous parts, I showed you what AWS Lambda service is and how to import simple Python application into serverless microservice. I also connected Lambda function to S3 storage service where I put certificates and key files. Then I added a trigger to the function, so Lambda function will execute automatically every time someone uploads new CSR file with certificate request to S3 bucket. Now I will show you not only how to make this function serverless but also storageless using API Gateway. It is not standard approach but in some scenarios might be interesting. So we will connect API Gateway and Lambda without S3 backend for keys and certificates.