Ansible automation for setting up a VPC

This Blog has been moved from Medium to blogs.tensult.com. All the latest content will be available there. Subscribe to our newsletter to stay updated.

In this blog, I will be informing you about, how to automate VPC set up for a three-tier architecture using Ansible. It also sets up a VPN connection for your VPC. If you are new to the concepts of a VPC or a VPN have a quick read through here to understand the basic concepts. It contains a web layer, an application layer, and a database layer. A three tier architecture is a type of software architecture that comprises of three tiers or layers. The three-tier architecture provides many benefits for production and development environments by modularising the user interface, business logic, and data storage layers. This gives greater flexibility by allowing to update a specific part of an application independently of the others. Scalability is also another benefit of three tier architecture. You can scale each layer independently depending on the need at any time. All the layers are private. The web layer and application layer has two subnets each, each belonging to two different availability zones.

The user inputs the parameters for each of the components such as name, CIDR block, tags, etc. This is done using “vars_prompt” in Ansible which allows you to get inputs from the user. It is then stored using “set_facts”. Ansible contains a number of modules for controlling AWS. Starting from the VPC to configuring each of the components of the VPC, are done using these modules.

The main playbook I have created is “3tier_arch.yml” which calls other play-books to configure the different components. Each playbook calls the concerned role to execute the task and configure the required component. The different roles used are:

1. vpc — This role is used to create the VPC in the initial step. It takes parameters such as name of the VPC, the CIDR block, region, etc as inputs from the user and then configures the VPC based on these inputs.
2. igw — This role is used to set-up the internet gateway for the VPC.
3. subnet — This role is used to create a subnet inside the VPC. The web layer and application have two subnets each in two different availability zones and database layer has a subnet all of which are private. The load balancer has two subnets in the two availability zones which is the same as the zones for the web layer. Different playbooks are used to call this role which then creates a subnet based on the parameters passed to the role from the respective playbook.
4. nat— This role is used to create a NAT gateway for the VPC.
5. route table — This role is used to create the route table for the different associated subnets in the VPC. The same process whereby we call the same role with different playbooks as in the case of the “subnet” role is used to create different route tables for the different layers in the VPC.
6. rds_subnet_group — This role is used to create an RDS subnet group so that we can configure a relational database service within the VPC.
7. rds— This role is used to create an RDS instance. The concerned playbook accepts inputs from the user to determine the type of RDS, instance, size, username etc which passes the inputs to the role so that it can configure it accordingly.
8. security_group— This role is used to create the security group for the different subnets. The different roles used to create security groups are app_security_group, db_security_group and wb_security_group. The playbooks associated with each role accepts the required inputs and passes it to the concerned role.
9. ec2 — This role is used to create the EC2 instances for the web and application layer. As we have seen in the case of “subnet” roles, the different playbooks accept inputs from the user and then they call the “ec2” role which configures the required instance in the VPC.
10. app_lb and target_groups— This role is used to create a target group and then a application load balancer to manage the traffic to the web layer.
11. cgw — This role is used to create a customer gateway for the VPN connection. The concerned playbook gathers the inputs from the user and then invokes the role.
12. vgw — This role is used to create a virtual private gateway and then attach it to the VPC.
13. vpn_connection — This role is used to set-up the virtual private network connection between the customer gateway and the virtual private gateway.
14. vpn_routetable — This role is used to create a routetable for the virtual gateway and also to allow route propogation for the virtual gateway.

The roles invoke the AWS modules in Ansible to carry out their respective tasks.

The Ansible code for the above can be found here on GitHub. The requirements for running the above code can be found in the readme file of the code. The code can be further improved to support one/two/three tier architecture implementation based on the user’s input. Depending on the user’s inputs, the main playbook can call different playbooks which in turn calls associated roles to implement the task. Another thing that can be improved is the configuration of the security groups. There are some restrictions on how the security groups are configured in my code. They can be improved so that we create multiple security groups with multiple rules based on the user’s inputs and how the user wants to configure the security groups.