{"id":14970609,"url":"https://github.com/buarki/linuxtips-containers-vpc-aws","last_synced_at":"2025-08-01T20:39:28.707Z","repository":{"id":254227619,"uuid":"845832741","full_name":"buarki/linuxtips-containers-vpc-aws","owner":"buarki","description":"Consolidando dia de treino sobre arquitetura de containers e VPC","archived":false,"fork":false,"pushed_at":"2024-08-22T04:32:27.000Z","size":3574,"stargazers_count":3,"open_issues_count":0,"forks_count":1,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-01-31T19:11:09.840Z","etag":null,"topics":["aws","terraform"],"latest_commit_sha":null,"homepage":"","language":"HCL","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/buarki.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-08-22T02:35:32.000Z","updated_at":"2024-12-18T18:13:20.000Z","dependencies_parsed_at":"2024-08-22T06:51:35.738Z","dependency_job_id":null,"html_url":"https://github.com/buarki/linuxtips-containers-vpc-aws","commit_stats":null,"previous_names":["buarki/linuxtips-containers-vpc-aws"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/buarki%2Flinuxtips-containers-vpc-aws","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/buarki%2Flinuxtips-containers-vpc-aws/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/buarki%2Flinuxtips-containers-vpc-aws/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/buarki%2Flinuxtips-containers-vpc-aws/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/buarki","download_url":"https://codeload.github.com/buarki/linuxtips-containers-vpc-aws/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":238337178,"owners_count":19455264,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aws","terraform"],"created_at":"2024-09-24T13:43:51.184Z","updated_at":"2025-02-11T17:31:07.978Z","avatar_url":"https://github.com/buarki.png","language":"HCL","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Arquitetura de containers na AWS: VPCs\n\nRepositório feito a partir da aula do mestre Jedi [Matheus Fidelis](https://github.com/msfidelis) pela Linux Tips (RECOMENDO!).\n\n## Requisitos para executar\n- terraform \u003e= v1.9.4;\n- aws-cli \u003e= 2.17.2;\n- conta na AWS;\n- um usuário com permissão de administrador - apenas para facilitar a vida, não faca isso em produção :);\n- Access Key ID e Secret Access Key para se autenticar;\n- se autentique na sua conta da AWS usando seu Access Key ID e Secret Access Key; \n\n## Como executar\n- Copie o arquivo **environmen/dev/terraform.tfvars.example** e crie um sem o **.example** preenchendo os valores;\n- Copie o arquivo **environmen/dev/backend.tfvars.example** e crie um sem o **.example** preenchendo os valores;\n- Rode o seguinte commando para subir a infra:\n\n```sh\nterraform apply --auto-approve -var-file=environment/dev/terraform.tfvars \n```\n\n- Rode o seguinte commando para destrir a infra:\n\n```sh\nterraform destroy --auto-approve -var-file=environment/dev/terraform.tfvars\n```\n\n## O racional do projeto: por qual motivo o fizemos assim?\n\n### Como um Dev vai solicitar o ambiente para rodar o projeto dele/dela?\n\n- \"Meu amigo DevOps/SRE, vou rodar meu sistema da padaria como um monolitão, onde um sistema Java com spring funciona como API e também serve o frontend dele mesmo. E vou precisar de um Postgres como banco. Se liga nesse diagrama aqui:\"\n\n\u003cimg width=600 src=\"./docs/img-0.png\" /\u003e\n\n\"E outra, precisa estar altamente disponivel, porque nunca sabemos quando o cliente vai querer comprar pão.\"\n\n### O que a gente entende?\n\n- Que clientes vão precisar acessar o sistema em Java (inbound traffic);\n- Que o sistema Java vai precisar chamar algum sistema externo na internet para operações como interagir com um gateway de pagamentos (outbound traffic);\n- Que o banco vai ser acessado somente pelo sistema em Java, dentro da rede interna da azure, sem sair para a internet.\n- Que precisamos colocar um Load Balancers na frente do sistema, e estes precisam estarem abertos para receber o tráfego vindo da internet;\n- Logo, na nossa visão, o sistema fica assim:\n\n![img-1](./docs/img-1.png)\n\n\n- E considerando o requisito de alta disponibilidade, **que é necessário para qualquer sistema de padaria**, decidimos que vamos ter uma \"replica\" do sistema em mais de uma zona, no nosso caso aqui, em **3 zonas**. Sendo assim, uma visao mais fiel do sistema seria:\n\n![img-2](./docs/img-2.png)\n\n- Por essa imagem vemos que temos 3 tipos possveis de redes: (1) publicas (com tráfego de entrada e saída), (2) privadas com tráfego de saída e (3) as redes privadas sem tráfego de entrada e nem de saída, que podemos chamar de **databases**. O que resulta na imagem abaixo:\n\n![img-3](./docs/img-3.png)\n\n\n- Em relação ao tipo 1, conseguimos concluir que não teremos muitas instancias. Logo, é razoável pensar que um bloco /24, contendo 256 IPs é suficiente para essa subnet.\n- Em relação ao tipo 2, por ser onde os workloads vão ficar, e considerando que estes escalam bem mais que o Load Balancer, precisamos de uma subnet maior, por isso, /20, dando 4096 IPs, já deve ser suficiente;\n- E em relação ao tipo 3, temos o mesmo caso do tipo 1. Logo, /24 é suficiente.\n- Sendo assim, a configuração das subnets fica:\n\n\n![img-4](./docs/img-4.png)\n\n\n- Agora precisamos saber qual o tamanho que a VPC dessa region que vamos deployar o sistema precisa ter. Para isso podemos fazer uma ...**conta de padeiro** :)\n\n```txt\n(3 subnets /24 para os Load Balancers) + (3 subnets /20 para os Load Balancers) + (3 subnets /24 para os bancos de dados) = (3 * 256) + (3 * 4096) + (3 * 256) = 13824 IPs.\n```\n\n- Se precisamos de 13824 IPs podemos tranquilamente configurar a VPC da region como /16.\n\n- E em termos da distribuição dos IPs em si, podemos comecar pelas redes maiores. Por exemplo, se iniciamos pela **rede privada** da zona a, podemos atribuir a ela a subnet **10.0.0.0/20**. O último IP dessa rede é **10.0.15.255**, logo, a proxima subnet válida para a zona b é **10.0.16.0/20**. Como o último IP desta rede é **10.0.31.255**, a subnet da zona c vai ser **10.0.32.0/20**;\n\n- Como a rede pública e de bancos de dados são similares em termos de tamanho, o raciocínio delas é igual: se a último subnet configurada dentro da VPC foi 10.0.32.0/20 e seu último IP é 10.0.47.255. Logo, a próxima subnet que podemos alocar para a zona a da rede publica vai ser **10.0.48.0/24**.\n- Daqui em diante o raciocínio vai ser sempre o mesmo: a próxima subnet inicia onde a ultima termina. Com relação a 10.0.48.0/24, o último IP is 10.0.48.255, logo, a subnet da rede publica da zona b vai ser **10.0.49.0/24**, e  **10.0.50.0/24** para a zona c;\n- Para a rede de bancos de dados teremos **10.0.51.0/24** para zona a, **10.0.52.0/24** para zona b e **10.0.53.0/24** para zona c.\n- Imagem abaixo mostra isso melhor:\n\n![img-4](./docs/img-5.png)\n\n\n### Controlando o tráfego\n- Para a rede publica:\n  - Uma vez que esta permite tráfego de **entrada de saída** optamos pelo uso de um **Internet Gateway**\n- Para a rede privada:\n  - Uma vez que esta permite apenas **saída** podemos seguir com **NAT gateways** associados a um **Elastic IP**.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbuarki%2Flinuxtips-containers-vpc-aws","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbuarki%2Flinuxtips-containers-vpc-aws","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbuarki%2Flinuxtips-containers-vpc-aws/lists"}