4 de July de 20244 de July de 2024 André Ramoni

ARGLabs projects list

Here is a list of project repositories of use cases we developed.

In order:

Organization administrators scope:

Pre-requisites for IaC to work and basic Organization stuff
- Post: Main account preparation
- Repository of pre-reqs: https://bitbucket.org/arglabs/arglabs-main-org-prereqs/src/master/
- Basic Org stuff: https://bitbucket.org/arglabs/arglabs-main-org-stuff/src/master/
Network CIDR control
- Post: CIDR Control with terraform
- Repository: https://bitbucket.org/arglabs/arglabs-main-org-cidr-control/src/master/
AWS Account creation for AIO scope
- Post:
- Repository: https://bitbucket.org/arglabs/arglabs-main-bigbang-aio/src/master/
Network Infrastructure creation for SRE Team on AIO account
- Post:
- Repository: https://bitbucket.org/arglabs/arglabs-main-bigbang-aio-sre-infrastructure/src/master/

AIO Scope – SRE Team

2 de July de 20248 de July de 2024 André Ramoni

ARGLabs tech stuff summary

This is for quick reference about our design decisions.

Where terraform data is stored for the company, teams, how DNS works etc.

Everything here is covered by complete articles explaining why.

This is just a quick reference summary.

Environments

Environments used in ARGLabs:

Default: where IaC is developed and every unique stuff is deployed.
Prd: production environment derived from the default environment.

Scopes

We’ll have just one scope named AIO (for All In One).

AWS Accounts

Read about here: AWS multi-account model and ARGLabs

One account for each environment per scope.

This means:

AIO Default
AIO Prd

Network

Each environment will use only one VPC in which each team will have it’s own network.

Default: 10.255.0.0/16
- SRE Team: 10.255.0.0/24
- Team01: 10.255.1.0/24
- Team02: 10.255.2.0/24
Prd: 10.0.0.0/16
- SRE Team: 10.0.0.0/24
- Team01: 10.0.1.0/24
- Team02: 10.0.2.0/24

CIDR Control is done at this repo: https://bitbucket.org/arglabs/arglabs-main-org-cidr-control/src/master/

Terraform

Remote state bucket

arglabs-terraform-states: company-wide stuff. Used for resources outside the teams accounts.
arglabs-aio-terraform-states: Used to store all AIO account terraform projects.

Terraform and providers versions

We decided to use latest versions because

DNS

Projects

AIO BigBang

AIO Account

SRE Infrastructure

Pending

AIO bigbang wont have state aggregator anymore and will only save state on the main account s3 bucket.
Infrastructure repos should get remote state from the main account but stores its states on the bucket inside the default account.
- change-data should help to do this

13 de June de 2024 André Ramoni

AWS multi-account model and ARGLabs

An AWS account does not have any cost by itself, so why we should share the same account across different scopes ?

Here we’ll talk about how we think real environments should look like and how we’ll do it in ARGLabs, since it’s just a lab and not a real environment.

AWS recommends the multi-account model for many reasons, we’ll focus on just a few of them here.

Access control

An AWS account is the first access control layer and blast radius limiting mechanism.

AWS accounts costs nothing by themselves, so you may have 3 or 56 accounts that you will only pay for what you run inside them.

It is much easier to control which accounts users have access to than to control the different access that different users need to different resources within a unique account.

So, access control is the first reason to do that.

Cost

Not only AWS accounts add no cost to your organization but it, in fact, helps to reduce costs.

In a shared account with multiple teams, applications and/or products, how do you know what are the costs for each of them ? Ok you can use tags, but there are many things that are not easy like this.

When you define a scope for AWS accounts and limit it’s usage to that scope, you can easily know the costs of that scope. Say you define a large product as an scope, and you run the entire product on one account and use another one for development/QA environments. The total cost of this product is the simple sum of the 2 accounts billings.

Isolation

Having just one scope inside an AWS account brings ownership to the people involved.

The responsible people is more likely to care about costs, efficiency, security etc because they will be the ones that the finops, security and other teams will talk to in case of problems. They own their product and the AWS account is like their exclusive environment where their product runs on.

The fact that only they are using the AWS account will make them confidently to take decisions like completely purge the development environment when they are not using, reducing costs to literally zero (yes, destroying all the infrastructure also!).

AWS account scope

What is the AWS account for ?

Should we have one set of accounts (environment accounts) by team ? Or by product ?

There’s no one-size-fits-all answer.

You should decide it based on the above benefits. If you have a large product made by a few teams applications and makes sense to have this product costs clearly visible and you don’t need to have different permissions for the teams that will have access to it, go for it.

If you have many apps from a group of teams that are part of a “business unit”, use accounts for that business unit.

You decide it.

In ARGLabs

Here in ARGLabs we’ll be using just one scope for our examples because it’s a lab.

One scope for all, that’s why we named it “The AIO (all-in-one) Scope”, and we’ll have 3 accounts for the different environments.

19 de May de 20245 de December de 2024 André Ramoni

ECS or EKS: Native cloud containers or kubernetes ?

There’s a lot of articles comparing the two and telling you about their differences and when you should go with one or another. I’ll make it slightly different.

I’ll tell you what I want to accomplish considering technology, culture, operations, costs, support and compliance and what is my choice to do so.

I want to provide developer teams a platform so they can easily build, deploy and run their apps in compliance with the Cloud Engineering Team’s best practices and Security Team’s policies.

Speedup cloud usage, cloud services details abstraction, best practices and security policies enforced, costs and permissions controlled with no bureaucracy and 100% cloud provider support.

19 de September de 202319 de September de 2023 André Ramoni

CIDR Control with terraform

Do you want to do everything as code ?

Do you know that you CAN manage your CIDRs allocations as code, and that it’s very simple, much more than you probably think ?

I’m not telling you that everybody should do it, but here I’ll try to show you that’s possible and very simple.

What are the main benefits ?

You’ll have a central place to manage every VPC network address
Everyone could query this central place to discover another team network address

We just need a centralized terraform state that everyone could read.

This terraform project just outputs our CIDRs allocations onto a state every other project can read: https://bitbucket.org/arglabs/arglabs-main-org-cidr-control/src/master/

Just put the CIDRs by environment on the cidr local map variable as following:

# CIDRs delegations:
  cidr = {

    # Entire company cidr by env:
    org = { 
      dev = "10.200.0.0/16"
      stg = "10.100.0.0/16"
      prd = "10.0.0.0/16"
      default = "" 
    }

    # Teams cidrs:
    sre = { 
      dev = "10.200.0.0/24"
      stg = "10.100.0.0/24"
      prd = "10.0.0.0/24"
      default = ""
    }
    
    team01 = {
      dev = "10.200.1.0/24"
      stg = "10.100.1.0/24"
      prd = "10.0.1.0/24"
      default = ""
    }
    # And so on...

  }

And let the pipeline run:

Then, in every project you need to get your own CIDR or any other CIDR, you can just read the terraform state as following:

data "terraform_remote_state" "cidr" {
  backend   = "s3"
  workspace = "default"
  #workspace = local.env
  config = {
    bucket   = "arglabs-terraform-states"
    region   = "us-east-1"
    role_arn = "arn:aws:iam::005801295308:role/deployer"
    key      = "main/org-cidr-control.tfstate"
  }
}

locals {

  cidr     = data.terraform_remote_state.cidr.outputs.cidr
  org_cidr = data.terraform_remote_state.cidr.outputs.cidr["org"][local.env]
  my_cidr  = data.terraform_remote_state.cidr.outputs.cidr[local.infra_scope_parsed][local.env]
}

output "my_cidr" { value = local.my_cidr }

19 de June de 202321 de September de 2023 André Ramoni

Main account preparation

First things first. Before we can create resources as code through a pipeline, we need to create some resources to make it possible, specially because we don’t want to use any credentials variables on the pipeline tool.

Most companies already have all the needed resources to run a terraform project through a pipeline but, as we want to make everything repeatable, we’ve manually created just the very basic resources and made a repository with the “not so basic” resources.

So, what we need to be able to run the “not so basic” terraform project:

IAM user with access key and secret key
IAM Identity Center (formerly AWS SSO) enabled

IAM User

Our IAM user will be “iac-main-iam” and will have the following policies:

AmazonS3FullAccess
AWSSSOMasterAccountAdministrator
IAMFullAccess
STS:AssumeRole

Don’t forget to create access and secret keys.

IAM Identity Center

Go to your main region and enable it.

Terraform pre-reqs project

Get the code here: https://bitbucket.org/arglabs/arglabs-main-org-prereqs/src/master/

Change variables on variables.tf file and remove the state file.

Run it, like in this video:

That’s it.

Terraform Org Stuff project

With these basic resources created, we can now run the next terraform project, now using the pipeline tool.

ARGLabs Org Stuff project: https://bitbucket.org/arglabs/arglabs-main-org-stuff/src/master/

It will run like:

Now the basic stuff on the main account is ready.

13 de January de 202221 de February de 2023 André Ramoni

ARGLabs fictitious company

So you are a newcomer on our company. Congratulations !

Our DevOps culture

We like the DevOps “You build it, you run it.” culture.

It means that our Cloud Engineers (call them DevOps, SRE, infrastructure guys or whatever you want), will help you with the basic cloud infrastructure on which your applications will run, but they won’t be called to solve your apps problems and incidents, so please, take the ownership of everything you bring up on the cloud, including costs, incidents etc.

Cloud Engineers can always help you with architecture decisions and deployment pipelines, but once it’s running, it’s up to you to keep things up.

12 de January de 202218 de September de 2023 André Ramoni

Why a .church domain ?

Because churches are places of faith.

I love IaC. I really do IaC. I think I understood what we can really do with IaC.

But I’ve seen many “good practices” out there that I thought aren’t good enough, many written by famous people and others even by the tool suppliers themselves.

In fact, everyone can write and publish anything and call it a “best practice”, and in fact, it could be for them, for many reasons. Good practice is what works best for your way of working.

ARGLabs is my church because this is where I’m going to show what I believe are best practices for the work I do.

In ARGLabs Church, I am the law (as Rodrigo Goes says 🙂 ).

These are not intended to be best practices for everyone.

12 de January de 20222 de February de 2022 André Ramoni

What is ARGLabs ?

Take ARGLabs as a fictional company where we’ll be running some applications like a real company

And with “real company” we mean that we’ll bring up everything needed to run our applications.

Every tech company “just” need to “run their applications”. By design, no specific tools are needed as long as the chosen tools meet the applications needs. With that in mind, we’ll choose the simplest tools and only those which allow us to configure them as code.

So what makes ARGLabs worth it, and why you would read more about it ?

Our tech design principle is: “If it can’t be done as code, it cannot be done.”

With that, many other benefits come along:

Knowledge is written down in code and no more in anyones head.
Disaster recovery or any number of dev/testing environment is just a matter of cost, but without managing effort.

And countless benefits more. Majority of them already included by the above mentioned (please don’t ask me to tell you every single benefit. If you can’t see them, maybe you should ask you tech staff after reaching us)

We’ll use many tools (where a free account could meet our needs) that a real company would use.

We’ll try to have every tech stuff a modern company usually have:

Public and private applications
Deployment pipelines, CI/CD
Monitoring tools and metrics
Incident Management
Communication platform and integrations

ARGLabs

IaC made simple.

Author: André Ramoni