Gruntwork Blog

Gruntwork (http://www.gruntwork.io/) | Anywhere | DevOps | Contractor

At Gruntwork, we offer DevOps as a Service.

Our mission is to make it an order of magnitude easier to understand, develop, and deploy software. The first step in that direction is to take the thousands of hours we’ve spent building infrastructure and to condense all that experience and code into pre-assembled Infrastructure Packages. Each Infrastructure Package is a best-practices definition of a single piece of infrastructure (e.g. a Docker cluster or a relational database) that is reusable, battle-tested, documented, configurable, and supported (read more here: https://blog.gruntwork.io/gruntwork-infrastructure-packages-7434dc77d0b1).

In other words, we're like a DevOps team that has already built everything you need. We give customers 100% of the source code for our packages and we offer a subscription that includes support, package updates, access to the Gruntwork community, security alerts, proactive maintenance, and more.

We are looking for Full Stack Engineers, DevOps Engineers, and AWS experts. We make heavy use of Terraform, Docker, Packer, AWS, and Go. Currently, we have one project where we're looking for experts in the Windows environment (e.g. IIS, SQL Server, Active Directory) and one where we are looking for an expert on Kubernetes. We are a completely distributed company, so location doesn't matter, and the work is 100% remote.

If you're interested, email us at careers@gruntwork.io.

I've written code like that for clients (and specifically executed a transition from bare metal+shell scripts to EKS for a "generic backend" module once), but I can't publish any of it for unfortunate obvious reasons. But FWIW I think it's inherent to IaC to involve a lot of copy-pasta, sometimes your best abstraction will just lead to shifting the copy-pasta from code to call-sites, which tends to be more maintainable but still.

What I can recommend is to treat your modules for what they are: Public library functions. Meaning common sense advice for those applies:

- Approach writing modules by actually designing an API for it. Don't treat it as a folder to dump resources in.

- Make your API as small as you can get away with.

- Its variables and outputs should be, whenever possible, describe a generic black box that could have its internals swapped.

- Make modules composable where you can. Being able to pass around entire module instances in variables because they have clean, stable APIs is very nice.

- Accept some things will inevitably leak but put in the effort to minimize them.

This blog post and the book from the authors (Terraform Up & Running) has some good ideas that got me started with the basics, but there's not much written with regards to more involved usecases: https://blog.gruntwork.io/how-to-create-reusable-infrastructure-with-terraform-modules-25526d65f73d

Take a look at this talk - it explains what both tools do and how they can work together well:

https://www.hashicorp.com/resources/ansible-terraform-better-together/

TLDW; You can do resource management (e.g. creating EC2 instances in AWS) and deployment (e.g. installing packages on an instance) through both Terraform and Ansible. Terraform is best used for resource management - the documentation states using the "provisioning"/deployment function is a last resort. Ansible is great at deploying packages but less so at resource management for the reasons you'll see in the other comments. Either use them together for what they're good at, or use Terraform to do resource management and other techniques (such as prebuilt images) for deployment:

https://www.terraform.io/docs/provisioners/index.html

Also useful:

https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c

We just released Terragrunt 1.0.

Notable updates:

- Terragrunt Stacks. A modern way to define higher-level infrastructure patterns, reduce boilerplate, and manage large estates without losing independently deployable units.

- Streamlined CLI. A less verbose, more consistent; `run` replaces `run-all`, and new commands `exec`, `backend`, `find`, and `list`.

- Filters `--filter`. One targeting/query system to replace several older targeting flags, plus new capabilities for selecting units/stacks.

- Performance improvements, especially if you’re upgrading from older Terragrunt versions, and automatic shared provider cache when using OpenTofu ≥ 1.10.

- And an explicit backwards compatibility guarantee. Gruntwork is making a formal commitment to backwards compatibility for Terragrunt across the 1.x series.

Read the full announcement https://www.gruntwork.io/blog/terragrunt-1-0-released

Questions/feedback welcome.

We (http://gruntwork.io) are still establishing best practices around managing multiple AWS accounts, but so far having a single "admin" account where all IAM Users are managed seems like a best practice. You can then implement a nifty dropdown that allows IAM Users to easily switch accounts. [1] I'm not sure about how IAM Groups fits into this.

For IAM Roles, we use Infrastructure-as-Code (Terraform) to create all those anyway, so I still prefer to create those in the AWS account that contains the resources to which they apply.

[1] https://aws.amazon.com/blogs/security/enable-a-new-feature-in-the-aws-management-console-cross-account-access/

Gruntwork (https://gruntwork.io) | Golang Engineer - Open Source | Worldwide Remote | Contract

Gruntwork is hiring a senior Golang engineer to focus specifically on Open Source projects, primarily OpenTofu but also Terragrunt and other tools.

Work collaboratively with the open source community to design and implement innovative new features at the frontier of devops tooling.

Help maintain and improve the quality of our codebase, infrastructure, and documentation.

Review and provide feedback on pull requests from the community and team members.

https://jobs.ashbyhq.com/Gruntwork/a6b852e6-2ab6-4eaf-b643-37b080633f1b