Serverless DevOps Tools
How to execute your DevOps tools and forget about the rest.
Introduction
Ok, so the Ansible servers are up and running! But it turns out that now you and your team have to maintain the Linux servers, one day you are developing Ansible playbooks and the other you are checking disk space, adding the security patches required by infosec, debugging why the weekend executions failed and the list continues, unfortunately.
Also, you have to constantly work to match the server requirements to the developer's demand. Either the servers are not enough for the requests or the server is underused, running 24 by 7 while you actually use it for a few hours.
Ok, you figure it out, this is a real-life story, that was me not that long ago and you can change the Ansible word for whatever you use. Actually, for the rest of the post, I will focus on Terraform but this will apply to any tool of this nature.
The Need
One of the interesting projects I have been working on here at Sudo Labs included the implementation of Terraform to create AWS resources based on the customer need(I can share more in another post) but I just remember all that support work I did with Ansible just to keep the operations running I knew I didn’t want to take the same path.
So we needed to trigger Terraform when the customer clicked a website button, which meant we would have to make it accessible via API, this wasn’t the traditional CI/CD pipeline triggered when the developer pushes changes to a branch(but you can use it that way also).
This will be a SaaS platform, customers might create the AWS infrastructure every now and then so we don’t know how many requests we will have, we don’t want to overpay in the billing every month. What can we do?
Implementation
Using ECS, API gateway, and Step Functions we exposed Terraform as an API so that we are only being charged for the execution time and completely forget about sysadmin tasks.
I will briefly explain each service and how we are making use of it in this architecture:
- ECS: Fully managed container orchestrator, like Kubernetes. Used to execute Terraform as a Docker container.
- S3: Fully managed storage service, object-based. Used to store the state files and to download the project files.
- DynamoDB: Fully managed NoSQL database engine. Used to lock the state file to avoid overwrites.
- API Gateway: Fully managed service to create APIs at scale. Used to create the API that receives the parameters and authentication to execute Terraform.
- Step Functions: Fully managed low-code workflow builder to connect AWS services. Used as the orchestrator between API Gateway and ECS.
What do you see in common here? Right, all these are managed services so the solution created is serverless.
I am assuming some level of knowledge to put this solution in place, for that reason I am giving the core configurations only to make this work. I hope to share the whole template later with Terraform or CloudFormation:
- ECS: For the ECS section you need to have a container capable of running Terraform and upload the image to ECR, here is the container definition:
I did an example entrypoint script as a reference only, the basic idea is to download the Terraform files from an S3 bucket every time Terraform will be executed, then with a parameter provider it will do “apply”, “refresh” or “destroy” and that parameter comes from the Step Function described later:
Once you uploaded the container to ECR, you must create an empty ECS cluster and one task definition to be called by the Step Function. The task definition is very simple, make it Fargate type, operating system Linux, and just provide the image from ECR like:
000000000000.dkr.ecr.us-east-2.amazonaws.com/terraform:latestThe autogenerated permissions should be good enough for both “Task role” and “Task execution role” we need to take note of the role name to add permissions to download S3 files.
- S3: Create an S3 bucket with versioning enabled, encryption enabled, block all public access and use the following permissions:
- DynamoDB: This section is very straightforward, all that is needed is to create one table with the “Partition Key” as a string “LockID”, there are many examples out there about how to achieve this, so instead I will give you an example about how your project should configure this section:
- API Gateway: Create a REST API with a POST method of “AWS Service” integration type with the following configuration
In order to be able to provide parameters to ECS the mapping template must be configured with the content-type as “application/json” with the following template:
That will send the command “create” to the Terraform container, so the ideal scenario would be a method per action. Now the only part we are missing is the IAM permissions:
- Step Functions: Create a standard Step Function with the following state machine definition:
The permissions required for the execution should be auto-generated during creation and that will be enough.
Conclusion
The solution we are providing here is quite more complicated than just installing Terraform/Ansible directly on EC2, but if you want to reduce that billing and forget about all the server maintenance tasks this might be the correct path for you. If this post gains enough traction we could generate a Terraform/CloudFormation template for you.
Do you like this implementation? Do you have any comments or suggestions? Please leave us a comment, we would love to hear from you.
Interested in getting a serverless environment set up to help scale your business? Reach out to us at Sudo Labs to see if we can help.
