Rodando NGINX no Google Kubernetes Engine utilizando IaC com Pulumi e Typescript *em 7 passos*, a thread
~ Gists e imagens ao longo da thread ~
🧶 🕸️
1. Requisitos necessários, assumindo que já estão devidamente instalados:
- Conta na Google Cloud (eles oferecem um trial de $300 o que é ótimo para playground)
- Google Cloud SDK (gcloud)
- kubectl
- Node v12+, pois vamos utilizar Typescript para os scripts do Pulumi
2. Convém obter as credenciais do gcloud, que serão armazenadas localmente e utilizadas posteriormente pelo Pulumi para autenticar comunicar com o GCP
7. Expor a pod como service LoadBalancer. O Kubernetes irá criar um LoadBalancer na cloud (no caso, GCP), o que permitirá ter um IP externo e acessar o NGINX através de HTTP
Se rodar `kubectl get svc nginx-svc`, pode ser que o external IP fique "pending" durante alguns minutos onde, caso o LB seja criado com sucesso, o IP será eventualmente atribuído
YAY! Kubernetes no GKE sem utilizar o web UI, o mais puro extrato do sumo do IaC
~muito hacker isso nossa uau~
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Não costumo dar dica de inglês pq não sou professor, mas tá aqui oq funcionou pra mim lá atrás qdo tudo era mato e não tinha internet nem dinheiro pra pagar cursinho de inglês.
Short🧵
(tldr; imagem já é pequeno spoiler)
Disclaimer
Assumindo que vc, assim como
eu, não nasceu com o c# virado pra lua e nao teve acesso a bons cursos de ingles com a devida frequencia. +
Basics
Pra correr atras do preju, esse livro é gold. Mesmo.
Ajuda a dar o up necessario na gramatica.
Cada pagina é uma lesson diferente com explicacao e exercicios. That’s enough, tudo oq nós mortais precisamos. Next.
Alguns ajustes no NGINX e PostgreSQL e minha versão Ruby ganha um aumento de tput que garante 46k inserts.
"Ajuste pra cima", eles dizem.
Não. É pra baixo.
As queries são rápidas, ñ preciso floodar a stack toda com mtos requests à espera: latência gera custo.
Detalhes na 🧵
TL;DR
- API com I/O assíncrono
- NGINX com 256 worker connections
- NGINX com least_conn para não jogar mais requests em upstream muito ocupado
- PostgreSQL com 30 max connections e tbm com 30 acessos simultâneos ao I/O
- Connection pool de 15 em cada API
Configuração do NGINX
Se eu abrir a torneira no NGINX pra sei lá, 10 mil conexões, ele vai tentar jogar o máximo possível no socket.
pessoal, apesar da zuera do Java não ter estado no TOP 15 da @rinhadebackend (kkkkk), queria deixar aqui algumas impressões sobre aspectos de concorrência em sistemas,
e que a natureza do desafio não coloca nenhuma lang em demérito, apesar da _zuera never ends_™️
as always, 🧵
quando um programa ou processo precisa realizar alguma computação, este é colocado pelo sistema operacional (SO) em uma fila,
tão logo a CPU fica disponível, o processo é atribuído à CPU e ganha uma fatia de utilização definida pelo escalonador do SO, que faz +
a troca de contexto entre diferentes processos na CPU.
processos não compartilham memória a princípio, e acontece que dentro de certos processos, podem ainda ser utilizadas outras estruturas menores de concorrência no SO, que compartilham memória, tbm chamadas de threads +
nesta pequena 🧵, iremos ver como utilizar xargs pra resolver o problema ali proposto pelo Seraphini. sem precisar de ferramentas adicionais, xargs funciona out-of the-box em qualquer sistema UNIX-based.
cada opção do comando será explicada ao detalhe 🔎 https://t.co/MLAVd4XLyI
Embora Tekton sirva para rodar o próprio CI no Kubernetes, os conceitos aqui apresentados podem ajudar a *entender melhor* de sistemas CI/CD no geral, inclusive os que trabalhamos no dia-dia, tais como Github, Gitlab, CircleCI etc
+
O primeiro foi uma introdução aos 3 principais componentes do Tekton: Step, Task e Pipeline.
São peças importantes que têm sua lógica fundamentada em diversos outros sistemas de CI/CD.