DEV Community: Dan L

How to destroy an infra deployed with Terraform by .tfstate

Dan L — Mon, 26 Feb 2024 18:30:11 +0000

Sometimes it's necessary to remove previously deployed infrastructure using Terraform, but in some cases it can be challenging to do so.

This could be due to old pipelines where destroying cannot be started due to breaking changes in configuration (e.g. environment variables no longer exists) or manually created infrastructure during development.

Today I want to show you a quick and easy way using only the .tfstate files where Terrafrom stores the current state (assuming you follow best practices and store them in one place like an S3 bucket).

Initial configuration

In my examples, I'll use AWS, but you can easily adapt this to any other supported provider.

You'll need the correct version of Terraform (the version of Terraform used for apply can be found in terraform_version at the beginning of the .tfstate file), to switch between versions I recommend tfenv.

First, create an .env where we'll specify all the variables. For backend configuration we'll pass it as command-line arguments because Terraform still doesn't support variables in the backend section.

TF_VAR_account_id=000000000000
TF_VAR_region=us-east-1
TF_VAR_access_key=XXXXXXXXXXXXXXXXXXXX
TF_VAR_secret_key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
TF_BACKEND_BUCKET=your-bucket-name
TF_BACKEND_KEY=path/to/terraform.tfstate
TF_BACKEND_ENCRYPT=true

Next, create main.tf specifying the provider, its version, and the used backend. Use the optional allowed_account_ids parameter to ensure it runs in the correct AWS account.

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 5.9"
    }
  }

  backend "s3" {}
}

provider "aws" {
  allowed_account_ids = [var.account_id]
  region = var.region
  access_key = var.access_key
  secret_key = var.secret_key
}

Now let's run terraform init, (Note: we use the env $(cat .env | xargs) to read variables from the .env file).

env $(cat .env | xargs) terraform init \
  -backend-config="region=$TF_VAR_region" \
  -backend-config="access_key=$TF_VAR_access_key" \
  -backend-config="secret_key=$TF_VAR_secret_key" \
  -backend-config="bucket=$TF_BACKEND_BUCKET" \
  -backend-config="key=$TF_BACKEND_KEY" \
  -backend-config="encrypt=$TF_BACKEND_ENCRYPT"

And now we can destroy all the infra registered in the .tfstate file.

terraform destroy

Creating a utility

Usually if you start doing this you'll have to execute multiple times which is not very convenient, let's create a run.sh entrypoint where we can pass the path to the .tfstate file as argument.

#!/bin/bash

if [ -z $1 ]; then
  echo "Path to terraform.tfstate is required"
  exit 1
fi

export $(cat .env | xargs)
export TF_BACKEND_KEY=$1

terraform init -reconfigure \
  -backend-config="region=$TF_VAR_region" \
  -backend-config="access_key=$TF_VAR_access_key" \
  -backend-config="secret_key=$TF_VAR_secret_key" \
  -backend-config="bucket=$TF_BACKEND_BUCKET" \
  -backend-config="key=$TF_BACKEND_KEY" \
  -backend-config="encrypt=$TF_BACKEND_ENCRYPT"

terraform destroy -auto-approve

We added the -reconfigure to init to reuse cached plugins and modules (don't delete the .terraform folder between calls, it'll significantly speed up the process). To avoid confirming destroy each time, we added the -auto-approve flag.

How to use it

Now, you can run it (remember to make it executable with chmod +x).

./run.sh path/to/terraform.tfstate

To batch run, we need to find all matching .tfstate files and call our script for each of them using awk. Please double check that you have filtered only what you need to destroy before running it.

For AWS with the S3 backend run this (if you are using another backend, you'll need to adapt this command).

aws s3 ls s3://your-bucket-name --recursive |
  grep terraform.tfstate |
  awk '{ system("./run.sh " $4) }'

That's it, just run it and wait for Terraform to do the rest.

🚀 Fastest way to bundle JavaScript in 2023

Dan L — Fri, 31 Mar 2023 18:20:53 +0000

JavaScript bundlers are essential tools for modern web development. They handle all the routine tasks for building an application, which allows developers to focus on writing code.

However, as applications grow in size and complexity, bundling performance can become a bottleneck, slowing down the deployment process and negatively impacting the overall developer experience.

Luckily, we are now entering a new era of build tools written in high-performance languages like Go or Rust. In this article, we will compare the speed and bundle size of the most popular bundlers across various configurations.

Available options

Despite the variety of available bundlers, most of them use the same packages for transpilation and minification.

The first option is Babel and Terser, two popular JavaScript tools for transpiling and minifying code, respectively. They are often used together, and many popular toolkits such as CRA (Create React App) are based on them. While both tools have large communities and are widely used, which makes it easy to find answers to most questions, their main drawback is their speed.

The second option is Esbuild, a lightweight and extremely fast bundler and minifier developed by Evan Wallace. It also supports bundling of other web assets like CSS and images, and can be extended using a variety of plugins. Esbuild is written in Go, which enables it to be significantly faster than any JavaScript bundlers. It’s easy to configure and supports JSX syntax and TypeScript out of the box.

And last but not least, SWC is a popular compiler designed to be blazingly fast and efficient. It is written in Rust and maintained by the developer community. It can be used to transpile and minimize JavaScript or TypeScript code. Also worth noting is that the swcpack bundler is currently under active development and it has all chances to become an extremely fast alternative to Webpack.

Benchmark

The story of this performance benchmark began with an attempt to understand why it takes more than half a minute to build a relatively small application with Material UI components and how to improve that.

For tests I created several React projects:

Empty as the baseline
Project containing five different libraries with a large codebase commonly used in web development
All components from Material UI
Synthetic test with 5000 small components as a way to measure the overhead of the bundler itself

Initially, the project with Material UI components also included an icons package, but after the first measurements I found a performance degradation in Rollup, so as not to distort the final results I removed it.

To keep results accurate there are no other files that can require additional loaders or plugins, as the main goal is to measure time spent on JavaScript bundling not on CSS or other assets.

The benchmark includes four bundlers in various configurations, all of them are configured as closely as possible (production build, no cache):

Esbuild as bundler without any extra plugins
Parcel in its default configuration with Babel and Terser
Rollup and Webpack in three different presets: Babel and Terser, Esbuild and SWC

For the testing environment I used Mac OS 11.5.2 and Node 16.20.0, with the latest package versions at the time of writing this article.

Tests were done on a 6-core 2019 MacBook Pro with 16gb of RAM. To ensure the accuracy of my measurements each test was run three times consecutively, the final results represent the average value.

In addition, I have measured the size of the resulting bundle and its size after gzip compression with standard settings.

All code is available in the GitHub repository

Results

Time in sec (average time for 3 runs)

	Empty	Libraries	Mui	Synthetic
Esbuild	0.046	0.142	0.192	0.685
Parcel: babel + terser	3.737	11.529	8.892	57.232
Rollup: babel + terser	3.121	13.056	9.495	37.689
Rollup: esbuild	1.874	5.553	5.746	14.612
Rollup: swc	1.788	5.966	5.802	14.644
Webpack: babel + terser	2.471	11.529	6.406	23.889
Webpack: esbuild	0.808	3.145	2.665	8.798
Webpack: swc	0.849	4.033	2.927	9.134

Bundle size in KiB

	Empty	Libraries	Mui	Synthetic
Esbuild	164.60	1239.04	607.99	1008.50
Parcel: babel + terser	348.28	1546.24	950.09	1351.68
Rollup: babel + terser	157.85	1454.08	592.64	786.78
Rollup: esbuild	163.61	1239.04	621.77	816.58
Rollup: swc	166.95	1351.68	712.35	1064.96
Webpack: babel + terser	158.33	1464.32	593.95	868.48
Webpack: esbuild	166.17	1617.92	613.37	891.19
Webpack: swc	163.00	1454.08	600.74	878.15

Bundle size after gzip in KiB

	Empty	Libraries	Mui	Synthetic
Esbuild	54.75	367.50	183.51	132.16
Parcel: babel + terser	106.91	424.13	264.39	139.05
Rollup: babel + terser	52.81	353.12	173.57	67.34
Rollup: esbuild	54.68	368.10	185.70	84.23
Rollup: swc	54.24	368.08	190.88	93.57
Webpack: babel + terser	52.90	407.58	175.36	84.42
Webpack: esbuild	56.04	445.32	185.35	86.71
Webpack: swc	54.49	409.35	178.29	93.34

Conclusion

Esbuild as a bundler currently is significantly faster than others, it will be fascinating to see how it compares to swcpack in the future, but at the moment it's the ultimate winner.

When we consider Esbuild and SWC as plugins with other bundlers, there is really not much difference between them, it completely depends on the specific configuration, detailed comparison between them you can find here.

A couple of words about Parcel, when I tried to build 10 copies of three.js my results were completely identical to Esbuild benchmark, it really was the fastest, but for React application the metrics are different.

The unpleasant discovery for me was the build time of Rollup, on a large number of files/imports it shows worse results even than Webpack.

So, what to choose for React app:

To achieve maximum performance and if you don't care about HMR support consider using Esbuild as bundler
If you are already using Webpack, you can simply improve the build speed by using Esbuild or SWC as a loader and minimizer, in this case you can keep using CRA configuration
If you really need HMR you can use combination of the previous options, Esbuild for production, Webpack + Esbuild loader for development (don’t use different tools for dev and production builds, there is a chance that the generated code may be different)