The Ops Community ⚙️: Leonardo Rodrigues de Oliveira

A Quebra de Linha no Final dos Arquivos e sua Necessidade no Ambiente Linux

Leonardo Rodrigues de Oliveira — Mon, 20 Feb 2023 14:15:26 +0000

A quebra de linha no fim dos arquivos é um assunto pouco conhecido para muitos usuários de Linux, mas é essencial para o funcionamento adequado de muitas aplicações. A quebra de linha no final de cada linha de um arquivo é um padrão que indica ao sistema operacional como ler e interpretar o arquivo.

Nos sistemas Unix e Linux, a quebra de linha é indicada pelo caractere LF (line feed), enquanto no Windows, é indicada pelos caracteres CR (carriage return) e LF. Isso significa que um arquivo criado no Windows com a quebra de linha adequada pode não funcionar corretamente em um ambiente Unix ou Linux, e vice-versa.

Sem a quebra de linha no final de um arquivo, o sistema operacional não pode determinar onde uma linha termina e onde começa a próxima. Isso pode causar erros ao tentar ler ou executar o arquivo, e até mesmo corromper o arquivo completamente.

Por isso, é importante garantir que todos os arquivos criados em um sistema Unix ou Linux tenham a quebra de linha adequada no final de cada linha. Isso pode ser feito facilmente usando editores de texto como o vi ou o nano, que inserem automaticamente a quebra de linha ao final de cada linha.

Além disso, existem ferramentas de conversão de arquivos disponíveis que podem ser usadas para converter arquivos com quebras de linha incompatíveis em um formato que funcione em sistemas Unix e Linux.

Em resumo, a quebra de linha no final dos arquivos é um padrão essencial que deve ser seguido para garantir que os arquivos funcionem corretamente em sistemas Unix e Linux. É importante lembrar de incluir a quebra de linha ao final de cada linha ao criar ou editar arquivos, e converter arquivos incompatíveis quando necessário. Dessa forma, podemos evitar problemas e garantir que nossos arquivos sejam lidos e executados corretamente.

We Need to Talk About AzureRM's Terraform Provider Limitations and Known Bugs

Leonardo Rodrigues de Oliveira — Thu, 16 Feb 2023 10:44:14 +0000

Terraform is an open-source infrastructure as code (IAC) tool that enables users to provision and manage cloud infrastructure resources across multiple providers, including Microsoft Azure. The Azure provider for Terraform, known as "azurerm," has become increasingly popular for managing Azure resources due to its ease of use and extensive feature set. However, like any software product, the azurerm provider has some known limitations and bugs that users should be aware of.

One limitation of the azurerm provider is that it can be slow to apply changes to large or complex environments. This can be particularly noticeable when working with larger virtual networks or storage accounts. Some users have reported that applying changes to these resources can take several minutes or even hours, which can be frustrating when working on time-sensitive projects.

Another known limitation of the azurerm provider is that it can be difficult to manage dependencies between resources. This can be especially problematic when working with complex infrastructure configurations that require resources to be created in a specific order. While Terraform does provide some tools to manage these dependencies, users may need to manually configure resource dependencies in some cases, which can be time-consuming and error-prone.

In addition to these limitations, the azurerm provider also has some known bugs that can cause issues for users. For example, some users have reported issues with the provider's support for managing Azure AD groups and permissions. There have also been reports of intermittent issues with the provider's support for certain Azure resource types, such as load balancers and virtual networks.

Despite these limitations and bugs, the azurerm provider for Terraform remains a powerful and flexible tool for managing Azure resources. To mitigate these issues, users can take steps such as optimizing their resource configurations for speed, carefully managing resource dependencies, and keeping an eye out for updates and bug fixes from the Terraform community. By doing so, users can continue to take advantage of the benefits of Terraform and the azurerm provider for managing their cloud infrastructure resources in Azure.

Multi-Stage Dockerfiles, Why and How to Use Them

Leonardo Rodrigues de Oliveira — Wed, 15 Feb 2023 03:20:35 +0000

When building Docker images, it's often necessary to install build tools and dependencies to compile your application. However, these build tools and dependencies can take up a lot of space in your Docker image, which can make your image larger than necessary. To solve this problem, Docker introduced multi-stage builds.

Multi-stage builds allow you to use multiple FROM statements in a single Dockerfile. Each FROM statement begins a new build stage, allowing you to build and package different parts of your application in separate stages. This can result in smaller and more efficient Docker images.

Here's an example of a multi-stage Dockerfile for a Node.js application:

# Stage 1: Build the application
FROM node:14-alpine AS build

WORKDIR /app

COPY package.json package-lock.json ./
RUN npm install

COPY . .
RUN npm run build

# Stage 2: Serve the application
FROM node:14-alpine

WORKDIR /app

COPY --from=build /app/dist ./dist
COPY package.json package-lock.json ./
RUN npm install --production

CMD ["npm", "start"]

Let's go over what this Dockerfile is doing. In the first stage, we're using the node:14-alpine base image to build the application. We set the working directory to /app, copy the package.json and package-lock.json files, and run npm install. Then, we copy the rest of the application files and run npm run build. This will compile the application into the /app/dist directory.

In the second stage, we're using the node:14-alpine base image again to serve the application. We set the working directory to /app, copy the compiled files from the previous stage using the --from flag, copy the package.json and package-lock.json files, and run npm install --production. Finally, we set the command to start the application using npm start.

When building this Dockerfile, Docker will first build the first stage, then use the compiled files in the second stage. This allows us to keep the build tools and dependencies in the first stage, and only include the compiled files and runtime dependencies in the second stage. The resulting Docker image will be smaller and more efficient.

To build this Dockerfile, run the following command in the same directory as the Dockerfile:

docker build -t my-node-app .

This will build the Docker image and tag it with the name my-node-app. You can then run the Docker image using the following command:

docker run -p 8080:8080 my-node-app

This will start the Docker container and map port 8080 on the container to port 8080 on the host machine.

That's it! You now know how to create a multi-stage Dockerfile to build and package your applications more efficiently.

How I Keep my Dependencies Updated on GitHub

Leonardo Rodrigues de Oliveira — Fri, 10 Feb 2023 03:11:22 +0000

First I want to let you know I have a hard time keeping track of my projects dependencies, specially if it is something I don't update often, and it might be too late when I finally find out something I'm using is no longer supported, so I was glad to find out about GitHub's way of dealing with this.

Sometime ago, I learned about a few ways to check for updates on your dependencies, and from time to time I would remember to check it and update my stuff, but it wasn't enough for me, and it got old fast, too manual, until...

And even if this is not exactly new I don't think we use it enough!

Dependabot checks for dependency updates for many different package systems, such as NPM, Terraform and even GitHub Actions! Besides the range of this tool it can also:

Open automatic Pull Requests with the updates;
Ask for specific reviewers;
Run as often as you want, daily, weekly, and so on;
Tag the Pull Request it opens as you like;
Be configured with a file inside the repository itself;
Show you changelogs for every single update it finds;
Check dependencies inside specific directories;
Check dependencies for multiple technologies inside the same repository;

Setting up

To configure Dependabot the way you want it to work inside your repositories all you have to do is add a file called dependabot.yml inside the directory .github on the root of your repository.

A simple version of the file to keep track of your GitHub Actions dependencies with daily checks could look like this:

version: 2

updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "daily"

And that's about it! It is already set and ready to start helping you.

Considerations

If you want to know more about the launching of this tool, check the original post by GitHub:
Dependabot's Announcement

To learn about dependabot.yml check the official syntax guide:
dependabot.yml syntax

Also here's an example of mine on how dependabot.yml looks like inside a repository:
dependabot.yml example

Finally there's also a list for supported package ecosystems:
Packages Support

How to Create Automatic Documentation for your Terraform Modules

Leonardo Rodrigues de Oliveira — Thu, 09 Feb 2023 02:13:44 +0000

When I first started writing my Terraform modules, inside organizations or on my own, I struggled with the idea of creating useful documentation for them, and specially looking at the official Terraform Registry it became obvious there should be a way of keeping my README files up to date and useful without a lot of pain, so I started looking for something to solve these issues.

Eventually I found a tool called "terraform-docs", yeah, pretty straightforward! After testing it for a while it was basically the answer to all my prayers, just to name a few of this tool's capabilities:

very simple configuration syntax;
generates markdown valid output;
replaces or appends to your existing README files;
can mix the automatic stuff with your own content;
the results are really useful and look good;

And besides those, when I got to it, there's a handy GitHub Action to make these updates fully automatic even if you commit new stuff without updating the README file, the workflow runs and updates it for you!

Here is the one example of the results:

LontriTech / terraform-azurerm-available-ips

Module responsible for getting available IPs inside a subnet.

Terraform Azure Module: Available IPs

Module responsible for getting available IPs inside a subnet.

Requirements

Name	Version
azurerm	~> 3.7
null	~> 3.1

Providers

Name	Version
azurerm	~> 3.7
external	n/a
null	~> 3.1

Resources

Name	Type
null_resource.keepers	resource
azurerm_client_config.current	data source
azurerm_subnet.this	data source
external_external.available_ips	data source

Inputs

Name	Description	Type	Default	Required
resource_group	Subnet's resource group.	`string`	n/a	yes
subnet_name	Subnet's name.	`string`	n/a	yes
vnet_name	Subnet's virtual network name.	`string`	n/a	yes
keepers	Keepers for this IP.	`list(string)`	`[]`	no
subscription_id	Subnet's subscription ID.	`string`	`null`	no

Outputs

Name	Description
all	List all checked available IPs for the Subnet.
one	List one checked available IP for the Subnet.

View on GitHub

First: Do It Locally

To achieve this I created a "default" configuration file for terraform-docs named .terraform.docs.yml and it looks something like this:

formatter: "markdown"

recursive:
  enabled: true
  path: examples

output:
  file: "README.md"
  mode: replace

settings:
  color: false
  description: "true"
  hide-empty: true
  read-comments: true
  sensitive: true
  lockfile: true

sort:
  enabled: true
  by: required

Then I downloaded the tool itself following these steps, found on the official guide:

curl -sSLo ./terraform-docs.tar.gz https://terraform-docs.io/dl/v0.16.0/terraform-docs-v0.16.0-$(uname)-amd64.tar.gz
tar -xzf terraform-docs.tar.gz
chmod +x terraform-docs
mv terraform-docs /some-dir-in-your-PATH/terraform-docs

After the download all I had to do was run terraform-docs . from my command line inside of the module's directory and it was done!

Now: Using GitHub Actions

Assuming you have the .terraform-docs.yml file on your repository as shown above you just need to create a new workflow, with whatever name you want it to have, mine is just "Terraform Docs", and it should look like this:

name: Terraform Docs

on:
  push:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: terraform-docs-gh-actions
        uses: terraform-docs/gh-actions@v1.0.0
        with:
          config-file: .terraform-docs.yml
          git-push: true
          git-push-sign-off: true

And, now you just have to wait for it to run, and you will be good to go!

Considerations

The configuration file used for terraform-docs is just an example, and even if it works for me, it may not work for you or your organization, so this is what you need to know to create your own:
terraform-docs configuration guide

Also, the installation process may not work in a non-linux environment, so if you are working on Mac or Windows, you will need to use a different approach like the ones listed here:
terraform-docs installation guide

About GitHub Actions and Workflows, I assumed for this article you know the basics of it, but if you need help seting up your workflow, you should definitely check out this quickstart guide:
GitHub Actions Quickstart

If you are wondering what the official docs on Terraform's Registry look like, here is an example:
Terraform Registry Example

Finally, if you are wondering how to publish your Terraform Modules on the Official Registry, here's how you do it:
How to Publish a Terraform Module on the Official Registry

Understanding Terraform's Core Workflow

Leonardo Rodrigues de Oliveira — Wed, 01 Jun 2022 17:31:24 +0000

Terraform is a growing tool created by HashiCorp to deploy cloud resources using the same syntax, making it easier to apply what you already know to new cloud providers.

Enough about the reasons, let's get into how you can manage your cloud infrastructure using Terraform.

Terraform uses a three step core workflow:

init
plan
apply

Init

First of all, you'll need to write your Terraform configuration using valid cloud credentials, these can be your own or some service account with the necessary permissions.

With your configuration ready you'll have to initialize your Terraform module using terraform init, this will download any dependencies, such as providers and referenced modules, the init command also creates the terraform.lock.hcl file, an automatically generated dependency lock file simmilar to requirements.txt from Python.

The last thing done during the module's initialization is configuring the backend, this is where Terraform will store its state file, the state file or TFState is responsible for holding everything Terraform needs to know about your infrastructure to be able to manage it.

Plan

Planning your Terraform configuration works as a way of comparing three things, and it looks something like this diagram:

The items compared during a plan are:

Terraform Configuration

The configuration itself, what Terraform assumes is the desired state for the cloud resources you declared inside the module.

Terraform State

Everything mapped by Terraform from previous applies/updates, this is only used as a way of knowing what was done by Terraform and what was done by outside sources.

Cloud Provider

The cloud provider is the place where your actual infrastructure is running, by checking the provider's API, Terraform is able to tell the current status of things, any changes from what is registered in the state will make Terraform want to update things, always trying to match the desired state declared on your configuration.

Terraform always needs to perform this step to plan what changes need to be done to the running infrastructure so it matches the desired state declared in the configuration.

Using the -o or -output option on the CLI you're able to generate a plan file, this can be used when applying the planned changes to make sure only the planned/approved changes will take place.

Apply

The final command of what is known as Terraform's Core Workflow is apply, running this command starts the same way as running plan if a plan file is not provided.

After determining what changes should take place, Terraform will ask for the user's approval before applying any real changes/updates to the infrastructure, the -auto-approve flag eliminates the need for the manual approval, but it's not a recommended practice, since it may even delete running infrastructure.

At the bottom of the changes list, there's a summary telling the user how many of each operation will take place if the plan is actually approved and applied.

The kinds of operation are:

Add - New resources will be added to your infrastructure
Change - Existing resources will be changed in your infrastructure
Destroy - Existing resources will be deleted from your infrastructure

The summary will look something like this:

Plan: 2 to add, 5 to change, 4 to destroy.

In some cases destroying a resource might mean the resource is going to be replaced due to a breaking change. Terraform doesn't decide what is a breaking change, this is a responsability of the cloud provider and its API, since Terraform is not responsible for the resource's configuration and/or contents, it cannot guarantee if the replacements won't break dependencies and running applications.

When approved, the changes will start to be applied.

Conclusion

Applying changes using Terraform may have destructive impacts to your infrastructure, so do it carefully, but it's predictable and repeatable, making it one of the safest way to manage a cloud environment, if you don't think so, just think about the mistakes you could have done by forgetting a route table or a single NSG rule.

Sources and References

Official Docs

The Ops Community ⚙️: Leonardo Rodrigues de Oliveira

A Quebra de Linha no Final dos Arquivos e sua Necessidade no Ambiente Linux

We Need to Talk About AzureRM's Terraform Provider Limitations and Known Bugs

More Content

Multi-Stage Dockerfiles, Why and How to Use Them

More Content

How I Keep my Dependencies Updated on GitHub

Setting up

Considerations

More Content

How to Create Automatic Documentation for your Terraform Modules

LontriTech / terraform-azurerm-available-ips

Module responsible for getting available IPs inside a subnet.

Terraform Azure Module: Available IPs

Requirements

Providers

Resources

Inputs

Outputs

First: Do It Locally

Now: Using GitHub Actions

Considerations

More Content

Understanding Terraform's Core Workflow

Init

Plan

Terraform Configuration

Terraform State

Cloud Provider

Apply

Conclusion

Sources and References