Deploy Komiser to AWS with Terraform

Komiser is an open-source cloud-agnostic inventory solution that gives you a holistic view of your cloud resources and helps you uncover insights about your infrastructure such as cost wasted, security threats, and compliance issues.

This tutorial will cover all the necessary steps for deploying Komiser on AWS using Terraform. By the end of this tutorial, we’ll deploy the below architecture with the following components:

• Provision an EC2 instance to host the Komiser container, and ensure that inbound and outbound traffic to the instance is restricted using a security group.
• Deploy an ELB in front of the EC2 instance to manage traffic distribution, and configure a security group for the ELB.
• Create an IAM instance profile and attach it to the EC2 instance, including the Komiser recommended IAM policy to manage access to AWS resources.
• Set up an alias record in Route 53 to direct traffic to the ELB DNS with a user-friendly URL.

All Terraform templates used in this tutorial can be found in the GitHub repository.

To get started, define your backend and declare AWS as your provider in the terraform.tf file. In this example, S3 is used as the backend for storing Terraform state files. Once done, run terraform init to download the AWS module.

Next, declare an EC2 instance in ec2.tf file with aws_instance resource. The resource uses Amazon Linux 2 as an AMI which is obtained using the data block and the aws_ami data source. The instance type is t2.medium (recommended size to host Komiser) and uses a public IP address and a security group that allows traffic on port 22 for SSH access and 3000 for serving the Komiser dashboard. It also attaches an IAM instance profile with the permissions required by Komiser to build your asset inventory.

The provisioned blocks define a series of file transfers and commands to execute on the EC2 instance after it's launched. The first three provisioner blocks upload files from the local machine to the EC2 instance. The last provisioner block executes remote commands on the EC2 instance, which installs some needed dependencies by running a bash script that is transferred to one of the previous provisioner blocks and deploys Komiser as a Docker container.

It's important to note that when using Komiser in a production environment, certain additional improvements should be taken to ensure security and scalability.

Firstly, it's recommended to deploy the Komiser instance within a private subnet and restrict SSH access only from a trusted CIDR block or a bastion host. This helps to prevent unauthorized access to the instance and reduces the risk of security threats.

Secondly, automation tools such as Ansible or Packer can be leveraged to further optimize the deployment process. Using Packer, for example, allows for creating a custom AMI that includes all the necessary software and configurations for running Komiser.

The install.sh script installs Docker Community Edition (CE) and Docker Compose. It also adds the ec2-user to the docker group, allowing us to run Docker commands without needing to use sudo.

Once those tools are installed, the deployment of the Komiser container can be initiated by executing the command docker-compose up with reference to the docker-compose.yml file. This will result in the deployment of the latest version of the Komiser image, which is at the time of writing this post v3.0.11.

The container is configured to use a config.toml file that connects to the running AWS account and stores data in an SQLite database. Additionally, the container serves the Komiser dashboard through port 3000.

In the iam.tf file, the next step is to define AWS IAM resources that enable the Komiser EC2 instance to assume an IAM role with the appropriate permissions attached to it.

Next, in elb.tf define a load balancer resource that forwards traffic into the EC2 instance running the Komiser container on port 3000. The ELB is configured with two listeners: one for HTTPS traffic and the other for HTTP traffic. The HTTPS listener is configured with an SSL certificate (requested through ACM) that is specified as a variable.

The health_check block specifies a health check configuration for the ELB. It specifies the target to check for health as "TCP:3000". The health check is configured to check the instances every 5 seconds, with a timeout of 3 seconds, and a threshold of 2 checks for both healthy and unhealthy responses.

Finally, in route53.tf creates a new AWS Route 53 record for a domain name that points to the ELB resource using an alias record. The record type specified is "A" for an IPv4 address.

This creates a Route 53 record that maps the domain name to the ELB, making it possible for users to access Komiser running on the ELB through a user-friendly URL.

After defining variables and outputs, running terraform plan will generate an execution plan detailing the changes that will be made to the infrastructure. Running terraform apply will apply these changes, resulting in the deployment of the 9 new resources necessary for running Komiser on AWS.

After the resources have been successfully provisioned, you can easily access the Komiser dashboard by navigating to https://demo.domain.com. Once accessed, you will be presented with a comprehensive breakdown of your AWS resources, including their associated costs.

Congrats! You’ve successfully deployed Komiser with Terraform.

You can now leverage Komiser's holistic view to take control of your cloud usage and optimize your resources for maximum efficiency and cost savings.

Regardless if you are a Developer, DevOps, or Cloud engineer. Dealing with the cloud can be tough at times, especially on your own. If you are using Tailwarden or Komiser and want to share your thoughts doubts and insights with other cloud practitioners feel free to join our Tailwarden discord server. Where you will find tips, community calls, and much more.