- git e github
- aws
- docker
- linux
- kubernets
- Controle de versão (gerenciamento de versões de um documento)
- Snapshot dos estados dos documentos (versão)
- Desenvolvimento não linear (brachs em paralelo)
- Github é diferente de Git. O Github é um serviço para armazenamento dos projetos versionados em Git
- untracked: o arquivo que não esta sendo versionado
- unmodified: o arquivo esta sendo versionado, mas não tem mudanças
- modified: o arquivo mudou em relação a versão anterior, mas não esta preparado para entrar na próxima versão
- staged: o arquivo esta preparado para um commit (versão do repositório ou snapshot dos arquivos)
$ git config --global user.name "Nome"
$ git config --global user.email "[email protected]"
$ git config user.name
$ git config user.email
$ git config --list
$ git init
$ git status
$ git add nome_do_arquivo
$ git commit -m "mensagem"
$ git commit -am "mensagem"
$ git log
$ git log --author="Nome"
$ git shortlog
$ git shortlog -sn
$ git log --graph
$ git show identificador_do_commit
$ git diff
$ git diff --name-only
$ git checkout nome_do_arquivo
$ git rm --chached nome_do_arquivo
$ git reset HEAD nome_do_arquivo
$ git reset --soft identificador_do_commit_anterior
$ git reset --mixed identificador_do_commit_anterior
$ git reset --hard identificador_do_commit_anterior
$ git remote add origin endereco_do_repositorio
$ git push -u origin main
$ git push origin main
O clone é usado quando o dono do repositório é o próprio usuário, enquanto que o fork é o contrário, e portanto, deve ser usado quando o usuário não é o dono de repositório.
São ponteiros associados aos commits que permitem criar "cópias" do repositório para o desenvolvimento paralelo sobre o mesmo projeto
$ git clone endereco_do_repositorio
$ git checkout -b nome_da_branch
$ git branch
$ git branch -D nome_da_branch
$ git checkout nome_da_branch
Tanto o merge quanto rebase são métodos para unir os commits das branchs. O merge é uma operação não destrutiva, no entanto, depende de um novo commit que aponta para os commits de outras branchs. Em contrapartida, o rebase move os commits de uma branch para "frente" da sequência de commits de uma outra branch.
$ git merge nome_da_branch
$ git rebase nome_da_branch
É um arquivo que determina os arquivos que serão ignorados no processo de versionamento
É um comando para armazenar temporariamente as mudanças de arquivos que estão no estado modified
$ git stash
$ git stash apply
$ git stash clear
$ git stash list
São marcações que representam uma versão da release do projeto
$ git tag -a versao -m "mensagem"
$ git tag
$ git push origin master --tags
É uma maneira de criar um novo commit para voltar para uma versão anterior
$ git revert endereco_do_commit
Esta documentação usou como referências os seguintes conteúdos:
Os serviços da AWS são soluções disponibilizadas para desenvolver a infraestrutura em cloud
- EC2: ambiente de computação (máquinas)
- VPC: ambiente de rede
- Route 53: dns
- S3: armazenamento
- Cloud Watch: monitoramento de
- IAM: gestão e controle de acessos
Para novos clientes, a AWS disponibiliza um nível de gratuidade chamada de Free Tier para as suas novas contas. O Free Tier possui limites dependendo do serviço e é compreendido por níveis:
- Sempre gratuito
- 12 meses gratuitos
- Testes (são de curto prazo)
O Free Tier é caracterizado por não ser acumulativo, ou seja, caso não use o beneficío naquele determinado momento e com aquelas determinadas restrições ele não vai se acumular para ser usado em um próximo momento. Uma outra característica é que o Free Tier possui limites dependendo dos níveis e dos serviços
Existem duas maneiras de acessar o console da AWS: uma por meio de um root user e a outra a partir de um IAM user (usuário não root). O root user é usuário proprietário da conta. A partir do usuário raiz, é possível realizar as primeiras interações com o console da AWS e criar os outros usuário da conta (também chamados de IAM users). Durante o acesso ao console da AWS, enquanto o usuário root precisa inserir o e-mail da conta, o usuário IAM tem que colocar o ID da conta que esta vinculada ao root user
É uma segunda camada de segurança representada por uma "contrasenha" dinâmica (geralmente um código de segurança):
- MFA Virtuais: aplicativo (Authy e Google Authenticator)
- U2F Security Key: dispositivo conectado em porta USB
- MFA de Hardware: dispositvo que gera os códigos
Para habilitar o MFA para o root user é necessário seguir os seguintes passos:
1. No serviço IAM, entrar na página Security Credentials
2. Na seção Multi-factor authentication (MFA), existe o botão Assign MFA device, responsável pelo cadastro do MFA. Clique nesse botão para habilitar o MFA
3. Por fim, é preciso selecionar o dispositivo desejado e associar um nome ao dispositivo
4. Configurar o dispositivo de acordo com o device selecionado
Com um nome vinculado ao dispositivo, é possível cadastrar mais de um dispositivo
As políticas de senha definem regras que precisam ser seguidas ao criar uma senha para um novo usuário
1. No serviço IAM, basta acessar a página Account Settings
2. Clique em editar na seção Password policy
3. Configure as regras de acordo com duas diretrizes: IAM default ou Custom
Os contatos alternativos são informações que a AWS pode usar para se comunicar com os representantes de cobrança, operação ou segurança. Em situações onde a AWS consiga identificar uma cobrança fora do padrão ou o vazamento de credenciais, ela pode tentar entrar em contato os representantes usando as informações cadastradas na conta root
As respostas também são cadastradas no dashboard de configuração da conta root. O objetivo delas é criar uma outra camada de segurança e criar uma outra maneira da AWS garantir a identidade do proprietário da conta, assim como, disponibiliza um novo meio de recuperar a conta caso ela seja perdida
Existem várias manerias de interagir com AWS e a AWS CLI é uma delas. O CLI é uma aplicação integrada ao terminal que permite implementar, gerenciar e interagir com os recursos disponibilizados pela AWS. Na documentação da AWS é possível encontrar o passo a passo de instalação a partir do sistema operacional:
https://docs.aws.amazon.com/pt_br/cli/latest/userguide/getting-started-install.html
Atualmente, a versão recomendada para uso é a 2.x. Caso instale a versão 1.x é recomendado migrar e atualizar para a versão mais nova
Usar a conta root para realizar as tarefas do dia a dia não é considerado uma boa prática. Por isso é importante criar um novo usuário e usar a conta root somente quando necessário
- Entre no serviço de gerenciamento de acessos (IAM) e acesse a página User Groups pelo menu lateral
- Depois, associe as políticas de acesso para esse grupo de usuários e clique no botão Create group. Nessa etapa, é possível identificar dois tipos de políticas: uma criada e gerenciada pela AWS, enquanto que a outra é criada pelos usuários
- No menu lateral do IAM, selecione a opção para criar usuários (Users). Por fim, preencha o nome do usuário e associe o usuário ao grupo de usuários criados anteriormente
- Com o usuário criado, selecione-o para visualiza-lo no dashboard de gerenciamento de usuários e na aba Security credentials, clique em Create access key
- Marque a opção Command Line Interface (CLI) para gerar as credencias de acesso e por fim, grave essas credenciais em um lugar seguro
Durante a criação de um usuário é importante saber a maneira como esse usuário quer interagir com a AWS. Se a ideia é que esse usuário acesse somente o console da AWS ou somente o CLI, é necessário marcar as respectivas caixas de seleção que esses privilégios
No termial execute o comando da CLI para configurar as credencias de acesso geradas durante a seção anterior:
$ aws configure
AWS Access Key ID: *******
AWS Secret Access Key: *******
Default region name: us-east-1
Default output format: json
Para listar as credencias de acesso cadastradas no CLI é necessário rodar o seguinte comando:
$ aws configure list
Uma credencial de acesso também pode ser cadastrada a partir de profiles. Com os perfis, o usuário consegue cadastrar mais de uma credencial de acesso:
$ aws configure --profile my-profile
Por padrão o profile padrão é chamado de default
Para identificar o usuário da AWS que a CLI esta usando parar executar os comandos, bastar executar o seguinte comando no terminal:
$ aws sts get-caller-identity
O modelo de responsabilidade compartilhada, como o próprio nome sugere, é representado por um conjunto de diretrizes de segurança da nuvem onde a AWS compartilha as responsabilidades com o cliente. A AWS, por exemplo, se responsabiliza do hardware e software que são entregues como serviços. Com relação ao hardware, a AWS precisa cuidar dos servidores, data centers, regiões e zonas de disponibilidade. Enquanto que, com relação ao software, a AWS se responsabiliza com a disponibilização da computação e hypervisors, armazenamento, banco de dados, rede e outros serviços SaaS (RDS e MSK, por exemplo). Em contrapartida, o cliente precisa se responsabilizar aos dados, configurações do sistema operacional e firewall e gerenciamento de acessos (IAM)
Fonte: https://aws.amazon.com/pt/compliance/shared-responsibility-model/
Nesse contexto, os serviços podem ser classificados como:
1. on premise: o cliente possui responsabilidade sobre toda a infraestrutura do servidor
2. iaas: a plataforma disponibiliza a infraestrutura como serviço
3. paas: a plataforma disponibiliza a plataforma como serviço
4. saas: a plataforma disponibiliza o software como serviço
Sobre cada serviço o compartilhamento de resposabilidades entre cliente e AWS acontece sobre aspectos diferentes:
O EC2 trata-se de um serviço da AWS que disponibiliza recursos de computação com capacidade "dimensionável" onde não é necessário investimento em hardware. Esse serviço compreende os seguintes pontos:
- Instâncias (virtualização de máquinas e servidores)
- Balanceamento de carga (Load Balancer)
- Escalonamento (AWS Auto Scaling)
- Armazenamento (EBS, S3)
- Segurança (keys)
Cada região é composta por pelo menos três data centers que representam as zonas de disponibilidades (também chamadas de AZ). As zonas de disponibilidades estão conectadas entre si. É muito comum encontrar o termo Multi AZ. Quando o serviço é Multi AZ, quer dizer que possui alta disponibilidade, uma vez que o serviço está hospedado em mais de uma zona de disponibilidade. Já as zonas locais se conectam a uma ou mais zonas de disponibilidade para diminuir a latência com o cliente (por estarem em locais que estão mais próximos dos clientes). As conexões entre zonas de disponibilidades, zonas locais e clientes consideram os seguintes componentes:
- Direct Connect: conexão dedicada entre uma zona local e o cliente
- Backbone: conexão entre uma zona local e uma zona de disponibilidade
A AWS disponibiliza vários tipos de instâncias que possuem caraceristicas próprias baseadas em seus recursos. As máquinas de uso geral, por exemplo, são caracterizadas por serem destinadas a propósitos gerais, com recursos equilibrados e intermediários. Também, determinadas famílias de máquinas são limitadas por créditos de cpu. A família T, por exemplo, (t3 e t4) é baseada nessa política. No momento em que esse limite é ultrapassado, o desempenho de processamento é reduzido ou ele se mantem, entretanto, tarifas são cobradas sobre esse limite. Basicamente, um crédito de cpu disponibiliza o desempenho de um núcleo em 100% de utilização por um minuto. As principais categorias de máquinas EC2 são para:
- Uso geral
- Otimizadas para cpu
- Otimizadas para ram
- GPU
- Otimizadas para armazenamento
Entrando no serviço de EC2 no console da AWS, no submenu ao lado, existe a opção Tipos de Instância (Instance Types). Essa opção traz uma lista com todas as instâncias disponiveis na AWS
O contrato das instâncias EC2 se resumem a 3 modalidades: on-demand, reserved e spot:
-
on-demand: É a modalidade padrão do contrato. Com esse contrato, o usuário paga somente pelo tempo de uso da instância, ou seja, enquanto a instância estiver desliga, não havera cobranças. Contudo, mesmo estando desligada, pode haver cobrança sobre o armazenamento, caso haja um disco associado a instância. O pagamento é por hora ou por segundo (considerando no mínimo 60 segundos), dependendo da AMI (imagem da instância). Sobre as instâncias com Linux, por exemplo, a cobrança é realizada sobre os segundos de uso. Entretanto, já para outras instâncias (como Linux) a cobrança é realizada sobre a hora. Em outras palavras, se usar somente 30 minutos, a cobrança sera o valor da hora. A definição de preço é baseada, principalmente, na capacidade computacional. O preço também é baseado nas amis públicas e privadas. Para essa modalidade, não existe contrato a longo prazo
-
reserved: Na modalidade reservada é possível economizar cerca de 72% em relação ao modelo on-demand. Com esse contrato, o usuário consegue reservar uma determinada categoria de uma instância. Nessa modalidade existem ainda 3 níveis: padrão, conversíveis e programadas. Na modalidade padrão, não é possível realizar alterações nas instâncias. Para essa modalidade o desconto é de 72%. Já a modalidade conversível permite realizar alterações nas instâncias, entretanto, o desconto é menor (54%). Por fim, as instâncias programadas são aquelas máquinas reservadas por um curto período de tempo. Com relação as formas de opção, existem 3 disponíveis: no upfront, partial e full upfront. No no upfront, não precisa pagar nada de imediato. No modelo partial upfront, é possível pagar uma parte e, por fim, o full upfront, é necessário pagar de imediato. O contrato reserved possui, no mínimo 1 ano e no máximo 3 anos. Durante a vigência do contrato não é possível cancelar, mas é possível vender as máquinas reservadas no marketplace da AWS.
-
spot: É a modalidade com o maior desconto (90% de desconto). As instâncias spots podem ser destruídas a qualquer momento, sendo que a aws envia os avisos sobre o encerramento 2 minutos antes das interrupções. Em sua contração é necessário definir o valor máximo a se pagar pela instância e a instância vai ser liberada quando tiver uma máquina disponível por esse valor. Caso o valor mude, existem 2 soluções: pagar a diferença ou deixar de usar
Também é um modelo que compreende preços menores, principalmente quando comparado com o modelo on-demand. Nesse contrato, também é necessário escolher uma categoria de instâncias, contudo, o contratante pode apenas mudar para uma categoria superior a que ele escolheu no contrato
Existem 3 categorias de saving plans: ec2, compute saving plans (compreende os serviços ec2, fargate e lambda) e sagemaker saving plans. Antes de começar a usar os saving plans, é necessário habilitar o serviço cost explorer para analisar os ambientes e começar a receber recomendações de economia. As primeiras recomendação podem começar a aparecer somente depois de 24 horas
Os preços baixos dos saving plans são respostas ao compromisso do contrato. Os termos de contrato não pode ser mudadados, entretando, é possível se inscrever planos de poupança adicionais (o que torna possível aumentar o workload do plano). O compromisso é com base no preço por hora, ou seja, o workload no mês. Portanto, é definido no contrato a carga horária de uso das instâncias. Tanto o plano compute quanto o ec2 se aplicam sobre as instâncias compreendidas pelos cluters emr, eks e ecr. Os preços dos saving plans podem ser diferentes em relação as instâncias reservadas por um contrato, quando considerado determinados sitemas operacionais (como sles, por exemplo). Os saving plans não se aplicam as máquinas contratadas por ir (reserved instances)
Saving plans:
- suporta várias soluções computacionais: ec2, fargate, lambda
- são mais flexiveis, pois, permitem trocas de famílias, sistemas operacionais, tamanhos, localizações e regiões
- adaptação automática ao ambiente, porque existem recomendações a patir de cost explorer (que garantem uma automação sobre os processos de gerenciamento e monitoramento das instância)
IR:
- suporta varias soluções de banco de dados: rds, redshift e elasticsearch
- é recomendado para criar ambientes onde os aplicativos precisam estar rodando 24x7, para aproveitar o máximo do contrato
- necesita definir uma categoria específica de instância e um sistema operacional
Primeiramente, para criar as instâncias, é necessário acessar o dashboard do serviço. Depois de acessar o dashboard, siga as seguintes instruções para criar a primeira instância:
-
Selecione a opção Instances do menu lateral
-
Clique em Launch Instance para Iniciar o processo de criação das instâncias
-
Na tela Choose an Amazon Machine Image (AMI), é necessário escolher a imagem do sistema operacional da instância (também chamado de AMI). Existem vários tipos de AMIs: AMIs criadas pelo próprio usuário, os do marketplace e os da comunidade
-
Na tela Choose an Instance Type, o usuário precisa determinar o tipo de instância (principalmente com relação aos recursos de hardware)
-
Na tela Configure Instance Details, a AWS disponibiliza a configuração da instância
-
A próxima tela (Add Storage), o usuário consegue adicionar um volume e configurar o tamanho e o tipo do disco
-
Em Configure Security Group, o usuário consegue criar um novo grupo ou associar a instância a um grupo já criado anteriormente. O grupo de segurança determina as regras de acessar a instância
-
Em Select an existing pair or create a new key pair, crie um novo par de chaves ou selecione um par de chaves já existente. Os pares de chaves são usados para acessar a instância via SSH
-
Selecione a opção Instances do menu lateral
-
Clique em Launch Instance para Iniciar o processo de criação das instância
-
Defina o nome e/ou tags da instância
-
Na seção Application and OS Images é possível escolher a imagem do sistema operacional. Em Browse more AMIs, o usuário consegue selecionar uma outra imagem que não esta presente na seção Quick Start. É recomendado usar as imagens desenvolvidades pela a AWS e/ou por seus parceiros (AWS Marketplace AMIs)
-
Observe que no lado direito, existe um pop-up com um resumo das características da máquina
-
Defina o tipo da instância
-
Defina o par de chaves para acessar a máquina via ssh
-
Na seção Network settings, é possível definir a configuração de rede. Em Advanced network configuration, o usuário consegue adicionar novos grupos de segurança e novas interfaces de rede e ips
-
Defina o tipo de armazenamento e o seu tamanho. Também é possível definir dois File systems: o efs (é um nfs que permite o compartilhamento de arquivos entre sevidores linux) e fsx (file server da microsoft)
Em EC2 Global View o usuário consegue ter uma visão global sobre todas as instâncias, vpc, secutiry group, subnet
Comportamento de desligamento (Shutdown Behavior), Proteção de finalização (Termination Protection) e Proteçao de parada (Stop Protection)
Existem dois tipos de comportamento de desligamento: o stop e o terminate. Enquanto o objetivo do stop é parar a máquina, o terminate é finalizar (apagar). Então, quando o usuário tenta parar a máquina com o comportamento de desligamento definido como stop pelo console da AWS, a instância desliga. Caso, o comportamento de desligamento seja o de terminate, a máquina também se desliga igual ao do stop, caso esse procedimento seja executado pela console. Contudo, se entrar na máquina via terminal e tentar desligar ela, por exemplo, ela consequentemente vai se encerrar.
A proteção de encerramento, impede que uma máquina seja finalizada acidentalmente. No console, quando usuário tenta finalizar uma instância com esse recurso habilitado, a AWS dispara um pop-up que bloqueia a operação. Contudo, esse recurso é ignorado caso o usuário tente desligar a máquina com o comportamento de desligamento configurado para terminate. A proteção de parada, assim como a proteção de finalização, tem como objetivo evitar a parada acidental de uma instância
- Shutdown behavior: comportamento executado no momento que a máquina é desligada
- Terminate: impede que a máquina seja inicializada novamente depois de desligada (em outras palavras, a instância é terminada)
- Stop: permite que a máquina seja inicializada novamente depois de desligada
- Termination protection: protege contra o desligamento acidental de uma máquina
É importante que apenas o dono tenha a permissão de realizar a leitura da chave
$ chmod 400 caminho_da_chave
$ ssh -i caminho_da_chave nome_do_usuario@endereco_da_instancia
Listar todas as instâncias:
$ aws ec2 describe-instances
Remover uma instância:
$ aws ec2 terminate-instances --instance-ids "id-xyz"
Exemplo de parâmetros para criar uma instância:
$ aws ec2 run-instances --image-id ami-0323c3dd2da7fb37d --count 1 --instance-type t2.micro --key-name chave_ssh --security-group-ids sg-0529062a5d07f7eab --subnet-id subnet-1deb2d3c
Uma AMI é uma imagem de uma máquina. Uma instância sempre está associada à uma AMI e portanto, todas as instâncias são criadas baseadas nas AMIs. A AMI compreede todas informações necessárias para iniciar uma instância
Os tipos de AMIs definem várias características de uma instância. Por causa dessas características, por exemplo, não é possível criar uma instância em um região diferente da AMI, ao mesmo tempo que também não é possível instalar um sistema operacional diferente do que a AMI define. É possível destacar alguns tipos de AMIs: - Região - Sistema Operacional - Arquitetura - Permissões de execução (pública, explícita e implícita) - Armazenamento
Com relação as permissões de execução, existem 3 permissões: - pública: são concedidas permissões de execução a todas as contas da AWs - explicita: são concedidas permissões de execução a determinadas contas da AWS - implicíta: são concedidas permissões de execução implícitas para uma AMI
Por padrão, uma AMI é privada e reservada para a sua região de origem, o que torna um recurso não global. A AMI é armazenada pelo serviço do bucket s3 e portanto, a cobrança sobre a AMI é realizada a partir do custo de armazenamendo s3
É possível criar uma instância com base em AMI e depois de customizar essa instância, o usuário consegue criar uma nova AMI com base na instância customizada. Uma AMI pode ser customizada em tempo de execução por meio do user-data
Primeiramente, é preciso iniciar o processo de criação de uma instância. O cmapo User data da seção Advanced Detail permite inserir um script que será executado durante a criação da instância. Esse campo aceita texto ou o upload de um arquivo shell com o script a ser executado.
Segue um exemplo de um script que pode ser executado em tempo de execução durante a criação da instância
$ #!/bin/bash
$ yum update -y
$ yum install httpd -y
$ systemctl start httpd
$ systemctl enable
Para criar uma AMI, primeiramente é necessário ter uma instância já criada. Depois, selecione a instância na qual se deseja criar a instância e por meio do menu de contexto Actions, selecione Image and templates e, por fim, a opção Create image. Na nova janela, preencha o nome, a descrição, o disco e as tags. Existe uma opção chamada No reboot. Quando desmarcada, a imagem será criada sem que a máquina reinicie. Gerando uma cópia da instância com essa opção desmarcada, torna o processo mais rápido e integro
Para criar uma instância a partir de uma AMI é recomendado entrar no dashboard das AMIs e em seguida selecionar a AMI e clicar em Launch instance from AMI
$ aws ec2 create-image --instance-id endereco_da_ami --name "nome_da_imagem" --description "descricao_da_ami" --no-reboot
Toda AMI está associada a uma SNAPSHOT que
-
Mudar as permissões da AMI
- EC2
- Instances
- Actions
- Modify Image Permissions
-
Compartilhar a AMI de uma região para outra
- Selecionar a AMI
- Actions
- Copy AMI
- Destination region
- Selecionar a AMI
- Actions
- Deregister
- Selecionar a SNAPSHOT
- Actions
- Delete
As Tags são usadas para categorizar os recursos por meio da estrutura chave:valor
- Tags
- Add/Edit Tags
- Create Tag
- Key
- Value
- É um serviço de armazenamento para usar com o EC2. Em outras palavras é um disco virtual de uma instância EC2
- Tanto a EC2, quanto a sua EBS, precisam estar na mesmo zona de disponiblidade
- O volume EBS é replicado para todas as zonas de disponibilidade de uma região
- O EBS é separado da instância EC2, e por isso se uma instância pode ser removida sem perder a EBS
- Garante disponibilidade de dados, persistência de dados, criptofrafia de dados e snapshots
- Volume baseadado em SSD: Otimizado para grandes transações de dados
- Volume basedo em HDD: Otimizado para armazenar grandes volumes de dados
-
Criar uma instância
- Add Storage
- Add New Volume
- Volume Type
- Size
- Volume Type OBS: Quando o IOPS precisa ser MAIOR QUE 16,000 é recomendado o Provisioned IOPS SSD
- Delete on Termination
- Add Storage
-
Criar um volume
- Volumes
- Create Volume
- Volume Type
- Size
- Availabity Zone
- Add Tag
- Key
- Value
- Create Volume
-
Conectar com a maquina via SSH
$ ssh -i MinhaChaveSSH.pem [email protected] -
Mudar o usuario no root
$ sudo su - -
Listar todos os dispositivos de armazenamento
$ fdisk -l -
Criar um volume
- Quando o state de um volume está como "avalaible", quer dizer que ele está disponível e preparado para ser anexado
-
Selecionar o volume
-
Actions
-
Attach Volume
- Instance
- Devide
$ aws ec2 help | grep {termo}
$ aws ec2 create-volume --volume-type gp2 --size 5 --availability-zone us-east-1b
$ aws ec2 attach-volume --volume-id vol-0ad91b69b44c62007 --instance-id i-001c3531c5a4dc46b --device /dev/sdp
- Volumes
- Selecionar o volume
- Actions
- Detach volumes
- Actions
- Delete volumes
- É uma "foto" do estado de um volume e por isso, geralmente é um recurso usado para realizar um backup dos dados dos volumes
- Os backups sào incrementais, ou seja, é copiado apenas aquilo que mudou em relação ao snapshot mais recente
- Snaphots
- Create Snapshot
- Voulume ou Intance
- ID
Segunda maneira de criar um snapshot
- Volume
- Selecionar o volume
- Actions
- Create Snapshot
- Description
- Key
- Value
- Snapshots
- Selecionar snapshot
- Actions
- Create Image
- AMI
- Selecionar AMI
- Launch
Segunda maneira de criar um snapshot
- Snapshots
- Selecionar snapshot
- Actions
- Create Volume
- Volume Type
- Size
- Availabity Zone
- Key
- Value
- Volumes
- Actions
- Attach Volume
- Instance
- Device
Identficar o UUID do volumes
$ blkid
Em sistemas operacionais Linux, náo é possível montar volumes com os mesmos UUIDs
$ mount /dev/xdo1 /mnt
Mudar o UUID de um volume
$ xfs_admin -U $(uuidgen) /dev/xdo1
Recurso que permiter criar uma política para gerenciamento automático de snapshots
- Volume
- Tags
- Add/Edit Tags
- Key
- Value
- Lifecycle Policy
- Description
- Select resouce type
- Target with these tags
- Lifecycle Policy Tags
- Policy Schedule
- Selecionar Copy Tags from volume
- Create Policy
- É um firewall que controla o tráfego de entrada e saída de dados de uma instância
- Todas as regras são permissivas, ou seja, elas estão desativadas e precisam ser ativadas, quando são necessárias
- Por padrão, os Security Groups são stateful permitem o tráfego de saída
- É importante ser muito restritivo ao criar uma regra
- Componentes das regras
- Protocolo: TCP, UDP, ICMP
- Intervalo de portas: 22 (SSH) ou 2000-3000
- Tipo de código do ICMP: echo-reply ou echo-request
- Origem ou destino 172.29.0.3/32 ou 172.29.0.0/24
- Criar uma nova instância EC2
- Na etapa de Configure Security Group
- Selecionar Create a new security group
- Remover a regra padrão de acesso à SSH
- Clicar no botão de Review
- Clicar no botão de Launch
- Clicar no botão Launch Instances para iniciar as intancias
- Na etapa de Configure Security Group
- No menu Security Groups
- Selecionar um Security group ID
- Inbound rules: regras de entrada e interna
- Outbound rules: regras de saída e exerna
- É importante evitar regrad any-to-any (regras que liberam tudo)
- Selecionar o Type da regra
- Selecionar o Source da regra (de qualquer lugar ou de um determinado ip)
- Clicar no botão Save rules
$ ping [ip]
- Selecionar Custom ICMP - IPV4 em Type
- Selecionar Echo Reply em Protocol
- Selecionar My Ip em Source
- Add rule
- Selecionar Custom ICMP - IPV4 em Type
- Selecionar Echo Request em Protocol
- Selecionar My Ip em Source
- Save rules
$ telnet [ip] 22
1. Selecionar Custom ICMP - IPV4 em Type
- Selecionar SSH em Protocol
- Preencher o campo Port range com a porta 2222
- Selecionar My Ip em Source
- Add rule
- Save rules
São as regras de saída do Security Group
- Selecionar HTTP em Type
- Selecionar Anywhere para Destination
- Add rule
- Selecionar HTTPS em Type
- Selecionar Anywhere para Destination
- Save rules
- Selecionar a instância
- Clicar em Actions
- Clicar em Networking no menu do Actions
- Change Security Groups
- Selecionar o Security Group desejado para aquela instância
Adicionar um ip estático a uma instância
- Clicar em Elastic IP no submenu Network & Security
- Clicar em Allocate Elastic IP address
- Selecionar Amazon's pool of IPv4 addresses
- Selecionar o Elastic IP
- Clicar em Actions
- Clicar em Associate Elastic
- Selecionar Instance para Resouce type
- Selecionar a instância em Instance
- Selecionar o IP privado que será associado ao Elastic IP
- Associate
- O objetivo das chaves é criptotagrar e descriptografar informações de login de uma instãncia
- As chaves públicas são inseridas no arquivo authorize_keys (localizado em ~/ssh/)
- Com as chaves privadas é possível descriptografar as informações de login a partir das chaves públicas correspondentes
- Clicar em Key Pairs no submenu Network & Security
- Clicar em Create Key pair
- Colocar o nome do par de chaves no campo Name
- Escolher pem (SSH) em File Format
- Clicar em Create Key pair
- Clicar em Key Pairs no submenu Network & Security
- Selecionar a chave a ser excluida
- Clicar no botão Actions
- No submenu do actions, clicar em Delete
- Nesse caso, o objetivo é importar uma chave já existente em outro ambiente para o ambiente da AWS
-
Criar uma chave SSH
$ ssh-keygen -t rsa -b 2048 -
Recuperar o conteúdo da chave pública
$ cat id_rsa.pub -
Clicar em Key Pairs no submenu Network & Security
-
Clicar em Actions
-
Selecionar Import Key pair do menu do Actions
- Preencher o nome da chave no campo Name
- Colar o conteúdo da chave pública no campo que está abaixo do Name
- Clicar em Import Key pair
- O ELB distribui o tráfego de entrada de aplicativos entre diversos destinos (instâncias, contêiners, endereços IP)
- É recomendado implementar o ELB quando existe mais de uma zona de dispobilidade (multi AZ)
- Quando o balanceamento de carga entre as zonas de disponibilidades está ativado, cada instância recebe a mesma quantidade de carga. Em contrapartida, quando o balanceamento de carga entre as zonas de disponibilidades está desativado, cada zona de disponibilidade recebe recebe a mesma carga e por isso pode ser que as instâncias de zonas de disponibilidades diferentes também recebam cargas diferentes, dependendo da distribuição de instâncias entre cada zona de disponibilidade
- Cada zona de disponibilidade possui uma instância responsável pelo balanceamento de carga
- Cria um ponto único de acesso (DNS)
- Cada elastic load balancing possui hostname estático para o DNS
- Disponibiliza SSL (HTTPS)
- Um ELB pode ser privado ou público
- O ELB responde por meio do padrão HTTP. Basicamente, existe três tipos de códigos de retorno
- 200: requisições realizadas com sucesso
- 4xx: requisições realizadas com erros no lado do cliente
- 5xx: requisições realizadas com erros no lado do servidor
- Existem três tipos de elastic load balancing:
- Application Load Balancer: trabalha com os protocolos HTTP e HTTPS
- Network Load Balancer: trabalha com os protocolos TCP e UDP
- Classic Load Balancer: trabalha com o HTTP, HTTPS e TCP, mas como se trata do primeiro tipo de ELB criado pela AWS, não é muito recomendado
- Atua na camada de aplicação (camada 7) do modelo de referência OSI
- É recomendado para o balanceamento de tráfego HTTP e HTTPS
- Roteamento avançado
- Escala automaticamente
- O endereço IP não é estático
- Permite o uso de stickiness (Quanto o stickness está habilitado, é possível manter uma seção de acesso com um único target. Caso o stickness estiver desabilitado, a conexão poderia estaria apontando para outros targets)
- Round Robin: a requisiçào é distribuida entre os targets (uma para cada target)
- Cabeçalhos HTTP
- Path: de acordo com o path, é possível redirecionar a requisição para uma determinada pool
- Origem
- Descido
- Atua na camada de transporte (Camada 4) do modelo de refeência OSI
- É recomendado para o balanceamento de tráfedo TCP e UDP
- O endereço pode ser estático
- Algoritmo de hash que se baseia no protocolo, endereço IP e na porta de origem, endereço IP e na porta de destino, número de sequência TCP;
- Atua na camada de aplicação (camada 7) e na camada de transporte (camada 4) do modelo de referência OSI
- É praticamente legado, principalmente, quando se trata do balanceamento de tráfego HTTP e HTTPS
- Roteamento não avançado
- Endereço IP não estático
- Não é recomendado
- Com o Gateway Load Balance é possível executar, gerenciar e escalar Appliances Virtuais (Firewalls, IDS/IPS) Exemplos: Check Point, Fortinet Paloalto, Cisco
- Atua na camada de rede (camada 3) do mode de referência OSI
- É recomendado para o balanceamento de tráfego IP
- Implementa o protocolo GENEVE na porta 6081
- Conexão entre duas ou mais redes
- Antes de uma requição chegar no seu destino (destination), ela precisa chegar no Gateway Load Balance que enviara a requição para as Appliances (responsáveis pela política de segurança) por meio do protocolo GENEVE na porta 6081
- Para o Gateway Load Balance, os Appliances são targets
-
Clicar em Load Balancers no submenu Load Balancing
-
Clicar em Create Load Balancer
-
Clicar em Create do Application Load Balancer
-
Step 1: Configure Load Balancer
- Preencher o campo Name
- Selecionar a opcão HTTP do Load Balancer Protocol
- Selecionar a VPC
- Selecionar as Zonas de Disponibilidades
- Preenchar a Key e o seu respectivo Value em Tags
- Next
-
Step 3: Configure Security Groups
- Selecionar um Security Group
- Next
-
Step 4: Configure Routing
- Selecionar New target group para criar um novo Target group
- Preencher o campo Name
- Selecionar Instance para enviar todos os pacotes (tráfego) para um conjunto de instâncias
- Selecionar o protocolo HTTP do Target Group
- Preencher 80 como a porta do protocolo (a porta da instância que o Load Balancer precisa encaminhar)
- Selecionar o protocolo em HTTP do Health Check
- Colocar a pasta raiz ("/") para realizar o Health Check e determinar a integridade do serviço
- Configurar os parâmetros do Advanced health check settings
- Next
-
Step 5: Register Targets
- Next
-
Step 6: Review
- Create
-
-
Selecionar o Load Balancer criado nos passos anteriores
-
Clicar na aba Description
- Edit attributes
- Marcar a opção Enable do Delete Protection para evitar que o LB seja deletado acidentalmente
- Clicar em Instances no submenu Instances do EC2
- Clicar em Launch Instance
-
Step 1: Choose AMI
- Escolher a AMI e clicar em Select
- Next
-
Step 2: Choose an Instance Type
- Selecionar o tipo de instância (t2.micro, por exemplo)
- Next
-
Step 3: Configure Instance Details
-
Preencher o número de instâncias em Number of Instances (para realizar os testes com o Load Balacer, é interessante que esse número seja maior que 1)
-
Selecionar a subnet onde o Load Balancer está localizada
-
Em Advanced Details, na seção User Data, é possível incorporar um script para ser executado quando as instancias são criadas:
#!/bin/bash yum update -y yum install httpd -y echo "Olá, eu sou o servidor $(hostname -f)" > /var/www/html/index.html systemctl enable httpd && systemctl start httpd -
Step 4: Add Storage
- Next
-
Step 5: Add Tags
- Clicar em Add Tags
- Preencher o campo Key e a seu respectivo Value
-
Step 6: Configure Security Group
- Selecionar Select an existing security group
- Escolher um Security Group da tabela de Security Groups
- Clicar em Review and Launch
-
Step7: Review
- Launch
-
-
OBSERVAÇÃO: Para realizar os testes com o serviço Apache, é importante garantir que o Security Group associado as intâncias estejam com a porta 80 e o protocolo HTTP
- Entrar em Target Groups da Seção Load Balancing a partir do menu na lateral esquerda
- Selecionar o Target Group desejado para adicionar os Targets
- Clicar em Edit da seção Attributes
- Deregistration delay: tempo esperado antes de remover um Target de um Targer Group. O propósito é minimizar problemas de conexão enquanto o usuário estiver usando o serviço do Target.
- Slow start duration: tempo esperado antes do Target Group permetir que um Targer comece a receber conexões.
- Load balancing algorithm: é o algoritmo para o balanceamento de carga
- Clicar na aba Targets da seção de Targets Groups
- Clicar em Register targets para adicionar os Targets
- Selecionar as instâncias que serão adicionadas como Targets
- Clicar em Register pending targets
- Clicar em Edit da seção Attributes
- Copiar o DNS name do Load Balancer na aba Description para poder acessar os serviços que estão rodando nas instâncias marcadas como Targets
É uma ferramenta para garantir a integridade dos serviços que estão rodando nas instâncias do Load Balancer. A checagem da saúde do serviço acontece periodicamente a partir do envio de requisições e checagem dos status code das respostas
-
Acessar as instâncias que estão no Target Group pelo terminal
-
Verificar o status do serviço httpd
$ systemctl status httpd -
Verificar o log do serviço httpd. No log, pode ser indentificado a açào do Health Check
$ cd /var/log/httpd $ tail -f access_log
No menu de controle dos Load Balancers, é possível criar regras que determinam os comportamentos dos tráfegos. Por padrão, toda requisição é redirecionada para um Load Balancer. Contudo, o sistema de controle da AWS permite criar novas regras. As regras podem redirionar as requisições que chegam na porta que esta rodando um serviço HTTP (porta 80), para o serviço HTTPS, por exemplo
- Entrar no menu de controle dos Load Balancers clicando na opção