• Home
    • Sobre Nós
  • Treinamentos

    Sobre Nossos Cursos

    • Treinamentos
    • Teste seus conhecimentos
    • Perfil Instrutor – LinkedIn
  • Consultoria
    • DBA ORACLE
    • DBA CASSANDRA
    • AWS
  • Blog
  • Contato
    Alguma dúvida?
    (11) 98193-2301
    contato@yadax.com.br
    Login
    YadaxYadax
    • Home
      • Sobre Nós
    • Treinamentos

      Sobre Nossos Cursos

      • Treinamentos
      • Teste seus conhecimentos
      • Perfil Instrutor – LinkedIn
    • Consultoria
      • DBA ORACLE
      • DBA CASSANDRA
      • AWS
    • Blog
    • Contato

      AWS

      • Home
      • Blog
      • AWS
      • Terraform Providers

      Terraform Providers

      • Postado por Adriano Bonacin
      • Categorias AWS, Terraform
      • Data 28/09/2019
      • Comentários 0 comentário

      INTRODUÇÃO

      Olá pessoal, tudo em ordem? Vou começar uma série de posts sobre terraform utilizando AWS. Neste primeiro artigo vou discutir alguns pontos sobre o Provider AWS.
      Vou começar com uma brevíssima descrição sobre AWS para dar sentido ao post, mas imagino que  se você chegou até este artigo, provavelmente já tem algum conhecimento de AWS e busca como aprimorar seu uso utilizando Infra as Code (IaC). Então, para sintetizar nosso papo sobre Cloud Provider, AWS é um conjunto de recursos/serviços na nuvem que normalmente você paga pelo tempo de uso, alguns são completamente free e outros são free até determinado limite.
       
      Se você tiver começando com AWS, você ainda pode aproveitar o free tier, onde alguns serviços podem ser utilizados gratuitamente por um ano, desde que respeitado seu tamanho (sempre é indicado na console) e quantidade de uso. Eu explico melhor sobre ele neste artigo ( https://yadax.com.br/aws/aws-free-tier/).
       
      Entre os recursos disponíveis na AWS que usarei como exemplo, temos alguns de network, como VPC, subnet e route table. Já voltado para Infra as a Service (IaaS), temos as instâncias EC2 que são máquinas virtuais de uso geral. Para o lado de Platform as a Service (PaaS), o RDS é um banco de dados relacional prontinho para o uso.
      O importante aqui é que tudo isso será tratado como Resource dentro de nossos scripts do Terraform.

      TERRAFORM

      Mas o que é Terraform? Ela é uma ferramenta open source criada pela HashiCorp que permite o provisionamento (criação) prático e reprodutível de sua infraestratura. Imagine que você tenha um blog e precisa de uma infra básica de redes, uma instância de processamento (EC2) e um banco de dados (RDS). Tudo isso pode ser criado e gerenciado a partir de arquivo textos, por isso o nome de Infrastructure as Code.
       
      O Terraform tem uma linguagem simples e declarativa. Você só precisa escolher seu provider (provedor), seus recursos e apertar o play. Provider é  qual tipo de Cloud você está usando. Você precisa indicar isso nos seus scripts e automaticamente o Terraform baixa um plugin que sabia conversar com ele. Providers mais comuns? São eles: AWS, GPC, Azure…

      PROVIDER

      Olhando especificamente para o Terraform Provider – um arquivo de configuração que nos permite “conversar” com seu Cloud Provider – temos algumas informações obrigatórias e outras opcionais.

      Uma importante é a região em que irá fazer o deploy, ela é obrigatória, e, alternativamente, pode ser passada via variável de ambiente. Outra é a versão do Provider, que talvez você não precise se preocupar caso sua infra não tenha coisas relacionadas a serviços lançados recentemente. Caso não informe, o terraform utilizará a mais recente.
       
      Este é um exemplo bem simples de uma configuração de Cloud Provider: um arquivo provider.tf dentro de sua pasta de trabalho.
      # AWS Provider
      provider "aws" {
      version = "~> 2.0"
      region = "us-east-1"
      }
      As últimas informações necessárias estão relacionadas as credenciais que você utilizará para aplicar sua infra. Vou gastar um parágrafo chamando a atenção de um ponto crucial de segurança, pois neste ponto olhamos para a Access Key (AK) e Secret Access Key (SAK).
      Para utilizar a console da AWS normalmente você usa usuário e senha, correto? Porém, se ao invés de dar cliques você preferir gerenciar seus recursos via AWS CLI, via API utilizando python ou via Terraform, por exemplo, como é feito esta autenticação? Através do AK e SAK. Então, pense assim: seu AK e SAK está ligado a um User, o que você consegue fazer via console com este User, você conseguirá fazer programaticamente. Por fim, se seu AK e ASK vazarem (o mais comum é commit inocente no GitHub), é o mesmo que ter seu User e Senha vazados, com o detalhe que programaticamente você consegue subir 100 instances EC2 em poucos segundos. Resumindo, jamais versione AK e SAK em repositório público. 🙂
       
      Aqui entra uma combinação de fatores. Para o caso da AWS, temos quatro opções:
      1 – Na estática, você passa sua AK e SAK na chamada do provider, desta forma:
      provider "aws" {
       region     = "us-west-2"
       access_key = "my-access-key"
       secret_key = "my-secret-key"
      }
       Novamente, olhando pelo ponto de vista que normalmente nosso código Terraform está versionado em algum lugar, como um github, este modelo não é recomendado, principalmente se o repositório for público. Acredite, se fizer isto em poucas horas a AWS bloqueia sua conta ou algum mal intencionado subirá tantas máquinas quanto sua conta permitir.
       
      2 – A próxima opção é utilizar variáveis de ambiente para indicar suas keys: AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY. Também é possível indicar a região através da AWS_DEFAULT_REGION e, desta forma, seu provider pode ficar assim:
       
      provider "aws" {}

      E para chamar o terraform você faz:

      $ export AWS_ACCESS_KEY_ID="anaccesskey"

      $ export AWS_SECRET_ACCESS_KEY="asecretkey"

      $ export AWS_DEFAULT_REGION="sa-east-1"

      $ terraform apply

      3 – A terceira opção, e talvez a mais comum, é ter um arquivo de credentials compartilhado, com AccessKey e SecretKey separados por profiles (um profile para cada projeto).

      Seu arquivo de credenciais (~/.aws/credentials) fica parecido com:

      [accounting]

      aws_access_key_id = AAWWVXXXXXXXOKAASS

      aws_secret_access_key = abclkjiwjASJDFWskadfiw



      [customer-xp]

      aws_access_key_id = ASDFKJWIWKKKKKKKSOK

      aws_secret_access_key = 123KJHGSUUwwsjisjiajsdkfj123KKKK
      E ao declarar seu provider, você especifica o caminho deste arquivo e o profile a ser utilizado. Desta forma:
      provider "aws" {
       region                  = "sa-east-1"
       shared_credentials_file = "~/.aws/credentials"
       profile           = "accounting"
      }

      4 – E por último, você pode fazer a entrega de sua infra a partir de um resource AWS, como uma instância EC2, que pode ter attachado um Role que permite a criação de outros resources. Neste caso, no seu provider é necessário informar a Role a ser utilizada.

      provider "aws" {
      assume_role {
         role_arn     = "arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME"
       }
      }

      Se quiser dar uma olhada na documentação, basta clicar aqui (https://www.terraform.io/docs/providers/aws/index.html).

      No próximo artigo vamos começar organizar nosso código Terraform e iniciar os primeiros recourses. Se quiser ser notificado quando o artigo sair, basta se escrever na nossa newsletter. Até lá.

      Tag:AWS, infra as code, terraform

      • Compartilhe:
      Adriano Bonacin

      Post anterior

      AWS Free Tier
      28/09/2019

      Próximo post

      Erro ao startar Apache Cassandra 2.2.16
      22/03/2020

      Você também pode gostar

      aws-logo-new
      AWS Free Tier
      15 setembro, 2019
      dynamodb
      AWS – Rodando DynamoDB local
      3 maio, 2019
      Cassandra-300×201
      Deploy Cassandra AWS com Ansible
      12 novembro, 2018

      Deixe uma resposta Cancelar resposta

      Você precisa fazer o login para publicar um comentário.

      Buscar

      Categorias

      • AWS
      • Bigdata
      • cassandra
      • Database
      • DynamoDB
      • Eventos
      • IAM
      • Linux
      • NiFi
      • NoSQL
      • Redshift
      • scala
      • scylladb
      • SSH
      • Terraform

      YADAX

      • Sobre nós
      • Blog

      Links

      • Próximos cursos

      Suporte

      • Consultoria
      • Contato

      Yadax. Todos os direitos reservados.

      • DBA CASSANDRA
      • DBA ORACLE
      • AWS
      • NoSQL

      Seu time de Data Engineer/DBA precisa de ajuda com uma nova tecnologia?

      Solicite nossos treinamentos In Company.

      Conheça

      Conecte com:

      Login com: Facebook Login com: Google

      logo

      Faça login com sua conta de site

      Conecte com:

      FacebookGoogle

      logo


      Perdeu sua senha?