This might be the last straw for windows
Sooooo….
Windows and docker just don’t mix well. I have no idea what they are doing with the whole docker-for-windows or windows containers, but docker is a linux tool and windows just doesn’t seem to jive with it.
The latest came when now, localhost which accepts self signed TLS on 2375 changed to docker.for.win.localhost.
Seriously, this is just stupid now. There were all the permissions issues before that when you ran docker behind active directory joined machines, the whole thing crapped out on the permissions layer. Now renaming the localhost, really. Well if that is what they have to do to fix the aweful experience so far, please.
Anger post… We all deserve our time….
Terraform + Terragrunt Versioning
This is awesome. I used to do this manually but now there is a nice CLI tool that downloads the version of Terraform and Terragrunt that you want and then replaces a symlink in /usr/local/bin or somewhere else in PATH.
Awesome….
Terraform Switcher - tfswitch
Installation and use. [Docs](https://github.com/warrensbox/terraform-switcher/)
curl -L https://raw.githubusercontent.com/warrensbox/terraform-switcher/release/install.sh | sudo bash
sudo chown -R $USER /usr/local/bin
tfswitch
If running into permissions issues then switch to user install and fix path
mkdir ~/bin
export PATH=$PATH:~/bin
tfswitch -b ~/bin/terraform
Terragrunt Switcher - tgswitch
Installation and use. [Docs](https://github.com/warrensbox/tgswitch/)
curl -L https://raw.githubusercontent.com/warrensbox/terraform-switcher/release/install.sh | sudo bash
sudo chown -R $USER /usr/local/bin
tfswitch
Modular interfaces
So I’m trying to modularize a bunch of terraform code and I get stuck on the idea of coupling. To couple or not to couple is always the greatest question. Right now I format my terraform based on a sort of hierarchy where I go something like this:
├── infrastructure
│ ├── dev
│ │ ├── terragrunt.hcl
│ │ ├── us-east-1
│ │ │ └── ec2
│ │ │ └── terragrunt.hcl
│ │ │ └── some other service
│ │ │ └── terragrunt.hcl
Note that both Resource Group and Service are optional. Simple deployments would maintain one level
So this hierarchy is critical to everything as when we use tools like Terragrunt, we persist the state in a remote object store based on a key structure that is reflected from the naming of the folder hierarchy that we store the configuration files in and run from. Thats a lot of information that honestly, you are best off reading this doc if you really want to dive and understand the justification to all of this. Instead so lets just show an example.
Lets say we have a repo like this.
├── infrastructure
│ ├── dev
│ │ ├── terragrunt.hcl
│ │ ├── us-east-1
│ │ │ └── ec2
│ │ │ └── terragrunt.hcl
│ │ │ └── some other service
│ │ │ └── terragrunt.hcl
Time to start writing…
Ok, it’s just got to start happening. I’ve been thinking about doing this for a really long time and I think I have enough to say to finally put it out there on the interwebs worldwide. I got a ton of notes on various dev ops topics that I want to make public and musings about random stuff and things that it’s about time.
I want to open source this all mostly because the documentation I want to post will evolve and I want to take PRs to improve it potentially. I don’t know if anyone will take the time but it would be cool to see if the docs I have are in any way authoritative enough to warrant a PR…
Exploring the idea of giving Insight Data Science
Anyways, lets give this a shot.