InfraSketch Tutorial, Part 1

Published in

FAUN — Developer Community 🐾

7 min readApr 26, 2021

Our journey to help DevOps engineers automate the Terraform template creation process started in 2020. A year later, with a ton of elbow grease, our product, “InfraSketch” is ready for release. This blog will walk you through every component of the product and how a DevOps engineer can use InfraSketch to generate Terraform templates and spin up their infrastructure.

You can try InfraSketch for yourself here.

Interested in learning more? Join our Slack, led by DevOps experts, to meet other professionals and learn more about Terraform. We will also have more opportunities to engage closely with InfraSketch in Slack.

For a full review of how to deploy infrastructure on cloud, check out our post on Best Terraform Tutorial Guides.

In this post, we’ll go over an overview of InfraSketch. That will include:
-A Brief Summary of InfraSketch
-Icons & Properties in InfraSketch:
a) Server
b) Gateway
c) Load Balancer
d) Subnet
e) Export

Try InfraSketch for yourself here and let us know what we can improve on.

What is InfraSketch?

InfraSketch is a Terraform template creation tool developed by InfraCode. The product has evolved from our previous open-source project InfraRapid, where you had to note down your infrastructure configurations in a YAML file and execute the executable Python file in order to generate the templates. However, this still required the DevOps engineer to be able to write the configurations manually in a YAML file. To make the lives of engineers easier, we created InfraSketch. In InfraSketch, you have a drawing board with configuration options to fill in. All you need to do is use the available components to sketch out your infrastructure on the board and the application will generate a fully coded Terraform template for you.

An Overview of InfraSketch

InfraSketch with grid switched off

InfraSketch currently has a black background with an optional grid. With the grid switched on, the application provides a grid on the background, which would serve the purpose of a better organization or alignment of your components. The application currently supports Amazon Web Services (AWS) and Microsoft Azure.

InfraSketch with grid switched on

All templates will have the default name “Untitled”, but you can also rename the template as you’d like. The template can be renamed by simply clicking on “Untitled” and then giving it a new name.

Let’s now go through each of the icons and their properties.

1. Server

The server is represented as a monitor on InfraSketch. To add a server to your template, you can simply drag and drop it. When you add a server to your template, a pop-up with fields to fill in appears on the right-hand side. This can be used to define the properties of your server.

Server properties and their definition:

1. Name: By default, the server names are defined as server-0, server-1, and so on. You can update the name of the server under this field.

2. Size: You define/select the size specifications of your server instance from the drop-down. Currently, we are using the naming conventions by AWS and Azure, but in the future, this may be modified to a cloud-agnostic naming convention. Example- t2.micro means that 1 virtual CPU will be allocated with 1GiB of memory.

3. Count: This property is used to define the number of servers with the same specifications that need to be created.

4. Operating System Image (AMI): You can select the type of OS that will be required from the list of options available in the dropdown here.

5. Elastic: This is a Boolean selection, where you may define whether your infrastructure will support elastic IP address selection or not.

6. Remote Command: Once your server and OS are set up on your infrastructure, there could be a few remote commands that you would need to be executed in order for your infrastructure to work as expected. You may define these commands that need to be executed here.

7. Inbound/Outbound Security rules: This section of the properties is used to filter the incoming and outgoing traffic to your server through the cloud provider. You can add the source, the port, and also the protocol that needs to be followed. You may also delete a rule that you have created here. For example- Source- All, Port-80, and Protocol- TCP.

8. Tags: If there are any Key-Value pairs that are required to be included in your configuration, you may enter them here. There are no restrictions on the number of entries that could be made.

9. SSH Key Path: You will have to specify the path of your SSH keys here. By default, the path is set to “~/.ssh/id_rsa.pub”. However, if your key is stored elsewhere, update the path accordingly.

II. Gateway

This is used to mention the region and the VPC IP address through which the instance needs to be set up on the cloud.

Gateway properties:

1. Region: This property is used to define the region where the infrastructure needs to be deployed on the cloud. A “region” is a broad spectrum of the geographical area where the data center of your cloud provider is present.

2. VPC Network: By default, the IP address here is set to “10.0.0.0/16”. You can update this as per your network requirement. The IP address mentioned here becomes your “main_cidr” value in your “.tfvars” file.

III. Load Balancer

A load balancer is responsible for managing the load on the network, passing it to all your backend servers. The load balancer receives the connection request and then attempts to establish a connection to one of the ports maintained under the listener configuration.

Load Balancer properties:

1. Name: By default, the load balancers will have the names “load_balancer-0”, “load_balancer-1”, etc. You may update the name to anything of your choice.

2. Listeners: These are key-value pair arguments, where you specify the list of ports that will act as the listeners for the load balancer.

3. Health: Under this property, you define the “Port”, “Path”, and the “Protocol” whose health or traffic density will have to be considered.

IV. Subnet

You may add a subnet to your main network by using this. A subnet is represented by the yellow-colored square box on the left-hand side of the web application.

Subnet Properties:

1. CIDR: You can define the subnet IP address here. The value mentioned here is maintained as the public and private subnet address in your “.tfvars” file.

2. Availability Zone (AZ): The availability zone is the available data centers within a particular region that was defined in the gateway. This is maintained as the public and private “subnet_az” in the “.tfvars” file.

V. Export button

Once you have sketched out and defined the properties of all the components, you may click on the “Export” button to generate the Terraform templates and store them as a zipped folder on your local system.

We hope you enjoyed this quick sneak preview of our newest tool, InfraSketch. Looking to discuss more use cases for InfraSketch — or simply looking to find out more? Join our Slack community to connect with other DevOps professionals.

PS — Did you know we have weekly Jam sessions on DevOps topics? The weekly invites go out on our Slack and Twitter channels. We hope to see you there!