Forem: Paddy Morgan

Enhancing Terraform with Terragrunt

Paddy Morgan — Fri, 23 Apr 2021 08:04:59 +0000

Over the last few months, I've become very familiar with using Terraform to deploy infrastructure across multiple cloud vendors. I'm a big fan of it, but some of its idiosyncrasies can be frustrating, particularly as the size of your project begins to increase.

Fortunately, there's a tool that helps to mitigate many of these issues; Terragrunt.

Below is a short post on some of the features of Terragrunt that I've found useful in my projects. I've also created an example that can hopefully better illustrate the benefits I'm writing about. Provided you have the following, you should be able to spin up the example resources yourself:

What is Terragrunt?

Terragrunt is a thin wrapper that overlays Terraform that allows you to avoid having large amounts of repetition in your infrastructure as code, as well as helping with Terraform modules and remote state.

DRY Providers

You can use the generate block in your root terragrunt.hcl file to inject common configuration files. One of the most common uses for it is to use it to generate your provider configuration. By adding the generate block in your root, you can delete the provider.tf files in your other directories. Whenever any Terragrunt command is called, the providers will be copied to the appropriate directories.

The change in my tutorial repo can be found here

Executing on multiple modules

When you use Terraform, you can't run commands against all of your modules at the same time. With Terragrunt, you can. If you add a terragrunt.hcl file to each module, you can run commands using run-all from root to run every module. Terragrunt recursively looks through each of your directories for the presence of that file, and if it finds it, will run the command you've included with run-all.

For example, if you wanted to apply all of the modules in this solution, you can run the following commands from the root of your repo:

terragrunt run-all init
terragrunt run-all apply

If you subsequently wanted to tear down everything you had, you can run:

terragrunt run-all destroy

Parallelism

Another nice feature of Terragrunt is when you run commands such as run-all, it will run as many of the modules that have terragrunt.hcl files as possible in parallel. Terragrunt doesn't put a constraint on this, which is a blessing and a curse. Your infrastructure deployment times will be faster, but if you're not careful you can get rate limited by your provider, so use it with caution.

If you do start to experience rate limits, you can specify the --terragrunt-parallelism flag:

terragrunt run-all apply --terragrunt-parallelism 1

The change in my tutorial repo can be found here

DRY CLI Flags

It's quite likely that when you run Terraform you're running commands with extra arguments. For example, you may have some common variables that you pass for each module, or you may want to restrict parallelism to avoid rate limiting.

With Terragrunt, you can specify an extra_arguments block that makes sure that commands that you repeat each time are always included.

terraform {
  # Ensures paralellism never exceed two modules at any time
  extra_arguments "reduced_parallelism" {
    commands  = get_terraform_commands_that_need_parallelism()
    arguments = ["-parallelism=2"]
  }

  extra_arguments "common_tfvars" {
    commands = get_terraform_commands_that_need_vars()

    required_var_files = [
      "${get_parent_terragrunt_dir()}/tfvars/common.tfvars"
    ]
  }
}

The change in my tutorial repo can be found here

Before and After Hooks

Terragrunt gives you the ability to run commands before and after the execution of a Terraform command. For example, you may run a script to bootstrap your environment or clean up after an apply has been run. You may want to copy files to certain locations, or even just add extra information that can be outputted as part of the terragrunt commands.

  before_hook "before_hook" {
    commands     = ["apply"]
    execute      = ["echo", "Applying my terraform"]
  }

  after_hook "after_hook" {
    commands     = ["apply"]
    execute      = ["echo", "Finished applying Terraform successfully!"]
    run_on_error = false
  }

Commit here

Auto-init

Something that people will have had to do countless times when running Terraform is running terraform init before running any other Terraform command. Running this command initialises your working directory by installing provider plugins and initialising your backend configuration. A feature of Terragrunt is that you don't need to explicitly call init, it will do this automatically before any other commands being run.

Generally auto-init works fine, but I have found occasions where it hasn't worked as expected. If you want to be totally sure that your modules are initialised before you apply/destroy/plan, you can add in your own before_hook to cover off the scenario.

terraform {
  before_hook "auto_init" {
    commands = ["validate", "plan", "apply", "destroy", "workspace", "output", "import"]
    execute  = ["terraform", "init"]
  }
}

The change in my tutorial repo can be found here

CLI options

Outside of the commands we've been using with Terragrunt, much of which mirrors the commands you would see with Terraform, there are a few particularly useful CLI options to use with Terragrunt as well. This list isn't exhaustive (you can find that here), it's just a list of commands I have found useful in the past:

terragrunt run-all apply --terragrunt-non-interactive

This will stop interactive prompts from being displayed, and will prompt all answers with a "yes". Particularly useful when running in CI/CD environments.

terragrunt run-all apply --terragrunt-working-dir registry

You can pass directories to Terragrunt to indicate where the Terraform command should run. Note that for any *-all commands, it will start from that directory but run any subsequent sub-folders with a terragrunt.hcl file.

terragrunt run-all apply --terragrunt-exclude-dir registry
terragrunt run-all apply --terragrunt-include-dir registry

The commands allow you to explicitly exclude and include certain modules (and their dependencies).

terragrunt run-all apply --terragrunt-parallelism 1

When passed in, limit the number of modules that are run concurrently to this number during *-all commands. Note that this parallelism is markedly different from the one you specify using Terraform directly. With Terraform, parallelism indicates running resource creation concurrently. With Terragrunt, it indicates running entire modules concurrently.

terragrunt run-all apply --terragrunt-log-level trace

If you want some more detail in your output, you can modify the log levels to do so.

Summary

Terragrunt is a fantastic foil for Terraform, taking you the extra yards to make your experience of using Terraform that much better. I've worked on a few projects using Terraform, and my advice would be to leave Terragrunt to the side, at least initially. It's important to understand the problems you're trying to solve, and when they start to manifest for you, that's the time to pull the trigger.

I've found that the value of Terragrunt increases exponentially with the size of your project. Smaller ones can generally be managed easily with "raw" Terraform, whereas larger, multi-module projects start to really benefit from Terragrunts features.

Resources

Credit

Goran Ivos for the photo 📷

WSL 2 and terminals

Paddy Morgan — Fri, 16 Apr 2021 08:41:13 +0000

My previous post focussed on configuring Docker Desktop so that you could integrate seamlessly with WSL 2.

In this post, I wanted to talk about setting up a standalone terminal for WSL 2. Over the time I've used WSL I've worked with a couple myself and wanted to tell you about my experiences with them, as well as how I configured them for WSL 2.

VS Code integrated terminal

I predominantly operate within VS Code as part of any work and personal projects I'm doing. The natural choice when it came to using a terminal was to use the one integrated into VS Code.

The experience with WSL is seamless. Once you've opened your project in WSL, you can open the terminal pane with ctrl + '

If you want to open additional terminals, you can do so with ctrl + shift + '

I personally find the size of the terminal restrictive. I've tried to mitigate this to an extent by adding a few of my own key bindings to make the most out of the somewhat limited space:

ctrl + up - Resize the terminal pane to make it larger
ctrl + down - Resize the terminal pane to make it smaller
ctrl + s - Split existing terminal
ctrl + x - Toggle terminal pane being maximised
ctrl + shift + t - Switch focus from terminal pane to editor (and vice versa)

You can set your own key bindings up by using ctrl + k ctrl + s, this will bring up the keybindings page. You'll notice that some of the bindings I use are fairly common and likely taken by other commands, ctrl + s for example. One nice feature with VS Code is that you can add conditional factors for when a keybinding will trigger.

Using ctrl + s as an example, it's actually used on 3 occasions, but only triggers on certain conditions that I have specified, making each command unique:

You can find the rest of my VS Code key bindings in my dotfiles repo.

In general, I find the integrated terminal perfectly adequate for what I need. One thing I wish would change, however, is the fact that you can't use VS Code across multiple monitors. I have a dual-screen setup, and after coming from the world of Visual Studio, it felt very natural for me to use one screen for my code, and the second screen for other purposes; such as debugging, terminals, problems and any other outputs I want to display.

As a result, I started looking into using a standalone terminal for times when the VS Code integrated terminal isn't quite enough.

Hyper

One recommendation I received was Hyper.js. Hyper is an open-source terminal built using Electron. This immediately appealed to me; I find myself crossing OS boundaries more and more often, so having a consistent terminal across them all would be ideal.

Much like VS Code, it offered a wide range of extensions to enhance your experience. Adding plugins in itself is straightforward; with Hyper open, just press ctrl + , and the hyper.js config will appear. You just need to add the plugin names and Hyper will load them for you:



  plugins: [
     "hyper-dracula",
     "hyper-tabs-enhanced",
     "hyper-spotify",
     "hyper-blink", 
     "hyper-tab-icons"
     //"hyper-solarized-dark"
     //"hyper-material-theme"
],

You can set up integration with WSL with a couple of changes in your hyper.js file:



    shell: 'C:\\Windows\\System32\\wsl.exe',
    shellArgs: ['~', '-d', 'Ubuntu-18.04'],

I'm specifying the -d flag in the shellArgs to determine the distro I want to open, which in this case is Ubuntu-18.04. I've also included ~ as an additional argument so that the shell opens in my WSL home directory. Without it, Hyper will default to your Windows %userprofile% directory.

You can see my full configuration file in my dotfiles repo.

Although I was initially quite excited with what Hyper had to offer, it didn't take me long to become frustrated with it. It has a wide array of plugins, but I found that a lot of them just didn't work with Windows, leaving me with a rather limited terminal experience. It also restricts you to configuring just one shell, something I wanted to avoid as I often switch between WSL and Powershell.

Windows Terminal

Windows Terminal is a relatively new terminal application developed by Microsoft. Not only does it support built-in tabs, but it also allows you to configure separate profiles where you can customise a variety of different shells:

Better yet, I can split my terminal vertically (Alt + Shift + +) or horizontally (Alt + Shift + -) to view them both at once:

From an aesthetics point of view, Windows Terminal is heavily customisable as well. You can change the colour scheme, change background opacity, and if, like me, you're a fan of using programming ligature through fonts like Fira Code, there's support for that too. You can even configure background images for each profile:

Getting configured with WSL is pretty easy too. Here's the profile I have configured in the settings, which you can open with ctrl + ,:



{
  "guid": "{c6eaf9f4-32a7-5fdc-b5cf-066e8a4b1e40}",
  "hidden": false,
  "name": "Ubuntu-18.04",
  "fontFace": "Fira Code",
  "source": "Windows.Terminal.Wsl",
  "startingDirectory": "\\\\wsl$\\Ubuntu-18.04\\home\\paddy",
  "colorScheme": "Dracula"
},

You can see my full configuration file in my dotfiles repo.

If you want to go an extra step with Windows Terminal there's a very nice extension you can install for VS Code. The extension gives you the ability to open Windows Terminal from VS Codes context menu, but I've extended my keybindings to speed the process up a little. This way I just need a couple of keystrokes and I have a maximised Windows Terminal available on my other monitor.

That's a wrap

That's part 4 of my WSL while you work series finished, I hope you found it useful 👍

Choosing and configuring your terminal is a very personal process, so this post acts as more of a guide to my experiences, as well as some help with integrating them with WSL 2.

For me, using a combination of VS Codes offering in tandem with Windows Terminal is working really well, and I'm enjoying personalising both tools over time to make myself more productive in my day-to-day working life.

Next up, I'll be discussing configuring global level settings for WSL using .wslconfig.

Credit

Prateek Katyal for the photo 📷

WSL 2 and Docker

Paddy Morgan — Fri, 09 Apr 2021 08:24:42 +0000

My previous post focussed on getting WSL 2 integrated with VS Code, so at this point, you should have a fully-fledged WSL 2 distro that plays nicely with VS Code.

The next step is to get WSL 2 working with Docker.

What is Docker (and why it's great)

Docker, in a nutshell, is a tool for deploying and managing containers. Containers are loosely isolated environments that allow you to package your application into a standardised "unit". They allow you to abstract away your application from the environment you're running them on. You create containers from an image, which in turn is created through a set of steps defined through a Dockerfile.

I've been using Docker increasingly over the last couple of years, and the more I use it, the more uses I find for it:

I've worked with Docker as part of projects; providing consistent, repeatable and scalable environments for use by others.
I've used it to run tooling; meaning that I don't have to clutter my machine with a multitude of packages as I jump between projects, I can simply pull an image, run it, and trash it once I'm done.
More recently, I've started to use it as a fully functioning development environment, thanks in no small part to the VS Code Remote Container extension. @benmatselby has written a great tutorial on getting up and running with VS Code dev containers, I'd wholeheartedly recommend that you give it a read.

Installing Docker Desktop for Windows

First things first, you're going to need to install Docker Desktop Stable 2.3.0.2 or later. Docker Desktop is the application that will allow us to build and run our containers on both Windows and WSL.

During the installation, you'll be prompted to enable any Windows components necessary for WSL 2. You want to do this.

Provided you've followed the steps from my first post in the series, you should be ready to go with Docker Desktop 🐳

Configuring Docker Desktop for WSL 2

Now we've got Docker Desktop installed, there's a two-step checklist we'll need to run through to integrate with WSL 2.

Step 1: Enable the WSL 2 based engine

Theoretically, this option should be enabled by default; Docker Desktop will recognise the fact that you have WSL 2 enabled and assume that you want this feature switched on, which you do. It's always good to confirm these things though, so open up Docker Desktop, then select Settings -> General.

If for whatever reason you did need to enable the WSL 2 engine, be sure to "Apply & Restart" Docker Desktop.

If we have a little peek under the hood at what's happened here, you'll notice that we now have a couple of extra WSL distros.

> wsl -l -v

  NAME                   STATE           VERSION
* Ubuntu-18.04           Running         2
  docker-desktop-data    Running         2
  docker-desktop         Running         2

These are installed by Docker Desktop when you enabled the WSL 2 engine. At the risk of horribly exposing my lack of knowledge around the architecture of Docker Desktops WSL 2 backend, I'll keep this short and sweet:

docker-desktop replaces the Hyper-V VM implementation Docker Desktop previously used. This handles bootstrapping and management of containers.
docker-desktop-data is where your images and configuration are stored; this is essentially a direct replacement of the Virtual Hard Disk that was used previously by Hyper-V.

This is great for a couple of reasons. Firstly, it solves the odd restriction Microsoft placed on Windows Home users, for whom Hyper-V (and by extension, Docker) is not available. Although as Jeff says, life finds a way.

Secondly, because your WSL distros get full access to all of your CPU cores and 80% of your RAM, resource allocation is far more dynamic, which on the whole helps to improve a Windows users' Docker experience.

Step 2: Enable WSL integration for your distro

Now we have the WSL 2 Engine running, we need to make sure our distro has access to the Docker server running in docker-desktop. Open up Docker Desktop, then select Settings -> Resources -> WSL Integration.

Any WSL 2 distro will appear in this list. Select whatever distros you'd like to have access to Docker, then select "Apply & Restart".

Kicking the tyres

All that's left to do now is give Docker a go in our WSL 2 distro of choice:

Bonus Content: Docker with WSL 1

Although I'm a strong advocate of using WSL 2, there may be reasons why this is either unavailable or impractical for you.

There's a little more legwork involved (and a lot less documentation) in getting WSL 1 working with Docker, so here's a quick guide on how I got this working before I migrated to WSL 2:

Step 1: Install Docker Desktop

If you don't already have it, you're going to need to install Docker Desktop for Windows.

Step 2: Expose the Docker daemon on Docker Desktop

Docker Desktop has an option that allows you to open a port to expose the Docker daemon to other clients. You're going to need to have this setting selected:

Step 3: Install the Docker CLI on WSL 1

Follow the instructions for installing Docker on Ubuntu, right up until you get to this point:

sudo apt-get install docker-ce docker-ce-cli containerd.io

You need only install docker-ce-cli, as you're going to connect to the exposed port on your Windows machine to access the Docker daemon.

sudo apt-get install docker-ce-cli

Step 4: Update DOCKER_HOST

The Docker CLI has a list of environment variables that it looks for when it runs. One of these is DOCKER_HOST.

We want to update DOCKER_HOST in WSL so that the Docker CLI knows that we want to connect to the exposed Docker daemon on your Windows machine:

export DOCKER_HOST=tcp://localhost:2375

If you want to make this change a little more permanent, you can add it to a shell config file of your choosing:

echo "export DOCKER_HOST=tcp://localhost:2375" >> ~/.zshrc && . ~/.zshrc

With those 4 steps complete, you'll be able to run Docker commands from WSL 1.

That's a wrap

Part 3 of the series is complete! The next item I'll discuss is using a standalone terminal with WSL 2, and how to configure it.

Resources

Credit

Jexo for the photo 📷

WSL 2 and VS Code

Paddy Morgan — Thu, 01 Apr 2021 08:39:57 +0000

My first post in the series focussed primarily on installing WSL 2 and getting familiar with some of its standard features and commands. Hopefully, at this point, you'll have a fully functioning distro running on your machine. If not, have a read back and get yourself up and running.

With the second post, I want to focus more on how you can start to make use of WSL 2 as part of your day to day engineering life.

Working with VS Code

I primarily use VS Code as my IDE. It's open-source, lightweight & clean, has a very active community with regular updates, and it has a vast array of extensions available to you, one of which is the Remote WSL extension.

While your IDE remains on Windows, all your commands, extensions, files, and terminal are running on your WSL instance. Once you've installed the extension you'll see a little icon at the bottom left of VS Code.

Opening a project

To better show this, I'm going to clone one of my repos into WSL. When I clone git repos, I like to have a git folder in the $HOME directory, followed by the organisation or user within that. So for example, on a fresh WSL distro install, I would do this:

> cd ~ 
> mkdir -p git/paddymorgan84
> cd git/paddymorgan84
> git clone https://github.com/paddymorgan84/dotfiles.git

Sidenote: The -p flag we're using for mkdir indicates that if the parent directory doesn't exist (which in this case, it definitely won't) rather than error it will create that directory as well, concatenating your mkdir command into a single call.

There's a couple of ways you can open a project:

Option 1: From VS Code. You can use ctrl + shift + p to open up your command palette, then search for WSL, which will provide you with a multitude of WSL related options. Clicking on the new icon in the bottom left of VS Code will also present you with the same options:

Select Remote-WSL: Open folder in WSL... and it will open up Windows Explorer and point you to a network drive that's been created on your machine to support WSL:

This gives you the ability to browse your WSL distro in the same way you would a Windows filesystem to locate your project:

Once you've selected your folder, VS Code will open up your project:

Two things to take note of here. The first is that the bottom left of your IDE will indicate you're now using a remote WSL connection to your Ubuntu-18.04 distro. The second is that your integrated terminal (ctrl + ' if you don't see this) is also using your distro, and will have automatically opened to the location of your project on your WSL filesystem. This gives you a clean, immersive experience of developing within Linux.

Option 2: From WSL. If you want to work directly from the terminal (as I tend to do) then you can call the code command from your distro, which will open a VS Code instance on your Windows machine with whatever folder you've run the code command for. For example:

> cd git/paddymorgan84/dotfiles
> code .

Or alternatively...

> code ~/git/paddymorgan84/dotfiles

Personally, I'm a big fan of using the terminal and I try to operate out of there as much as possible. I feel it's more efficient and makes me more productive as an engineer, and it also means I can add cool little aliases that can open my common projects up with a few keystrokes:

I'll be discussing aliases later in the series.

Installing extensions

Using the Remote WSL extension means that instead of having a totally native experience, what you actually have is a "client-server" architecture; VS Code (the UI, at least) is running on Windows, but the server (everything else under the hood) is running remotely on WSL.

As a result, a lot of your extensions will need to be re-installed on your distro (and any subsequent distro) for you to have them available.

Fortunately, VS Code makes this really easy. Assuming you have a WSL remote project open, press ctrl + shift + x to present you with the Extensions pane. You'll notice a few subtle differences from a standard Windows VS Code experience (I've highlighted the important bits):

Local - Installed tells you what extensions you have installed when running VS Code with a Windows-based project.
WSL:Ubuntu-18.04 - Installed tells you what extensions you have installed on your distro.
Install in WSL:Ubuntu-18.04 does what it says on the tin.

The thing I want to emphasise about this is that getting all the extensions you love to use on Windows can be installed onto your distro in a matter of seconds 👍

Don't halfway-house the filesystem

When I first started dabbling with WSL, I rather confusingly decided to keep my files located on my Windows drive, then use the mount points WSL provide (/mnt/c/, for example) to locate those files and operate from WSL.

As I write this now, I struggle to remember why I did this other than the fact it wasn't quite as big a leap away from Windows and there was less up-front work to get started.

I would wholeheartedly recommend you don't do this. Firstly, Microsoft themselves try to warn you against this, primarily because the performance isn't great.

Secondly, I found that I would have annoying inconsistencies that meant I had to modify my configuration to work around it. For example, I often found myself battling with line endings in my GitHub repos, something that differs between Windows and Linux. Git has ways and means to help solve this, but ultimately I migrated all of my projects to my distro and my experience improved drastically.

My advice would be to just take the leap.

That's a wrap

Part 2 of my series is done and dusted, I really hope that you've found it useful. Next up I'll be talking about using WSL 2 with Docker. 🐳

References

Credit

Remy_Loz for the photo 📷

Getting started with WSL 2

Paddy Morgan — Fri, 26 Mar 2021 09:21:01 +0000

My life as an engineer has predominantly been one within the realms of Windows. Whilst some may shudder at the thought, I've always been happy working in this environment. Over the last couple of years, however, I've gradually been exposed to the world of Linux, predominantly through my use of WSL.

This year I've been co-running a weekly technical workshop with Ben Selby on a range of subjects. Last week I ran a workshop on my experiences with WSL, outlining what I've learnt along the way and how I try to get the most out of it.

This post marks the first of a small series around WSL I'd like to do off the back of that workshop.

What is WSL?

WSL, or Windows Subsystem for Linux, is an optional feature on Windows that allows you to install a Linux distribution without any of the previous legwork you would have done previously, such as dual-booting your PC, or setting up a VM.

Why WSL 2?

I originally started using WSL 1, and while I could work fairly comfortably with it, the nature of my work meant that I did have a couple of frustrating issues, namely around Docker and the way WSL resolved the mounting of volumes.

WSL 2 was a major architectural change for WSL, introducing the use of a full Linux Kernel, increased file system performance and 100% system call compatibility.

In my opinion, WSL 2 is far superior, and if you're new to WSL I'd skip straight past WSL 1. As always, there are exceptions to bear in mind, but they're unlikely to be an issue for the majority.

Pre-requisites

I'll get the boring stuff out of the way early. To install WSL 2, you're going to need to be running the following at the very least:

x64: Windows version 1903 or higher, with Build 18362 or higher.
ARM64: Windows version 2004 or higher, with Build 19041 or higher.

You can use winver to find this out 👍

Installation

Installing WSL is quick and simple; I'm using PowerShell (as admin) for the commands below:

Step 1 - Enable WSL and virtual machine features

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

Step 2 - Download the linux kernel package

Step 3 - Set WSL 2 as your default (more on wsl.exe later)

wsl --set-default-version 2

Step 4 - Choose your distro

Step 5 - Create your user account and password

Step 6 - Confirm everything is up and running

> wsl --list -v

  NAME                   STATE           VERSION
  docker-desktop-data    Running         2
* Ubuntu-18.04           Running         2
  docker-desktop         Running         2

Making use of `wsl.exe`

As you may have gathered from the installation instructions, you can interact with WSL by using the wsl command.

There are a few different things you can do with it, but here are the commands I've found most useful:

Opening the default distro

> wsl --list -v

    NAME                   STATE           VERSION
    docker-desktop-data    Running         2
  * Ubuntu-18.04           Running         2
    docker-desktop         Running         2

> wsl

The * denotes the default distribution. If you enter wsl it opens the default shell, which in this case is Ubuntu-18.04.

If you do have multiple distros and you want to log in to a "non-default", you can add some more context to your command:

> wsl --list -v

  NAME                   STATE           VERSION
  docker-desktop-data    Running         2
* Ubuntu-18.04           Running         2
  Debian                 Running         2
  docker-desktop         Running         2

> wsl -d Debian

Changing the version of WSL for your distro

> wsl --set-version Ubuntu-18.04 1
> wsl --list -v

  NAME                   STATE           VERSION
  docker-desktop-data    Running         2
* Ubuntu-18.04           Running         1
  docker-desktop         Running         2

This is admittedly an odd example given my belief that most engineers will be best served by using WSL 2, but it's useful nonetheless. You can switch between versions with a single command, which can be handy if for whatever reason you have a version-specific issue you need a workaround for. For now, at least, Microsoft has no plans to deprecate WSL 1, so it's worth having this in your locker.

Importing and exporting distros

> wsl --export Ubuntu-18.04 C:\wsl-exports\ubuntu.tar

> wsl --import Ubunthree-18.04 C:\my-distros\ubunthree C:\wsl-exports\ubuntu.tar
> wsl --list -v

  NAME                   STATE           VERSION
  docker-desktop-data    Running         2
* Ubuntu-18.04           Running         2
  docker-desktop         Running         2
  Ubunthree-18.04        Running         2

Once you install your distro of choice from the Microsoft Store you can't subsequently get that same distro again as it's now considered installed.

You can, however, export your existing distro to a .tar file, then import it again under a different name, as the example above shows. I found this very useful when I was comparing the features of WSL 1 & 2, but you could do it for a multitude of other reasons, such as splitting your personal or work projects across distros or splitting by technical disciplines, such as front or backend development.

If you work with a team of engineers, it can also be useful to have a tarball of a "base" distro that has everything your team needs pre-baked into the distro.

The snagging list

As great as WSL 2 is, there's a couple of hiccups that I've found along the way that I want to share in the hope that others avoid the hair pulling and excessive profanity I engaged in:

Symantec Endpoint Protection played havoc with my ability to perform apt package-management updates and upgrades. Fortunately, I don't use Symantec anymore and I'm not sure if they've patched out a fix to resolve it.
Recently I came across an issue with my distro whereby I couldn't hit the internet at all. I was stumped, but thankfully @coltenkrauter created a gist that gave step by step instructions on how to solve it. ❤️
The ability to convert your distro between WSL 1 & WSL 2 can be really useful but be warned that the larger it gets, the longer the conversion times will get. Conversion on a fresh distro is a matter of seconds, but when I've been using a distro for a protracted amount of time (I'm talking months here) with large numbers of cloned repos, you're going to be looking at hours.

That's a wrap

This marks the end of part 1 of my WSL while you work series. Next up will be a post on how I use VS Code in conjunction with WSL for my day-to-day engineering.

References

Credit

Oskar Yildiz for the photo 📷

Forem: Paddy Morgan

Enhancing Terraform with Terragrunt

What is Terragrunt?

DRY Providers

Executing on multiple modules

Parallelism

DRY CLI Flags

Before and After Hooks

Auto-init

CLI options

Summary

Resources

Credit

WSL 2 and terminals

VS Code integrated terminal

Hyper

Windows Terminal

That's a wrap

Credit

WSL 2 and Docker

What is Docker (and why it's great)

Installing Docker Desktop for Windows

Configuring Docker Desktop for WSL 2

Kicking the tyres

Bonus Content: Docker with WSL 1

That's a wrap

Resources

Credit

WSL 2 and VS Code

Working with VS Code

Opening a project

Installing extensions

Don't halfway-house the filesystem

That's a wrap

References

Credit

Getting started with WSL 2

What is WSL?

Why WSL 2?

Pre-requisites

Installation

Making use of wsl.exe

The snagging list

That's a wrap

References

Credit

Making use of `wsl.exe`