Forem: Yan.ts

Design Patterns

Yan.ts — Wed, 03 Aug 2022 04:03:04 +0000

Design Patterns são um conjunto de soluções comuns para problemas recorrentes, inicialmente foram definidos pela Gang of Four (GoF) lá em 1994 no livro Design Patterns: Elements of Reusable Object-Oriented Software

Muitos padrões são utilizados até hoje como o singleton por exemplo que é usando por padrão no nestjs sempre que fazemos uma injeção de dependências. No entanto eles não são uma bala de prata e devem ser utilizados com cuidado

Nesse artigo vou falar sobre alguns dos designs mas se quiser conhecer outros e principalmente ver implementações deles recomendo que leia o livro original ou utilize esse site https://refactoring.guru/pt-br/design-patterns/catalog onde além de exemplos bem simples de entender qual o problema que estamos tentando resolver com os patterns ele ainda tem exemplos de implementação em diversas linguagens

Adapters

O adpters é uma forma de abstrair libs externas deixando o código flexível então por exemplo no javascript temos diversas bibliotecas com o intuito de lidar com datas (dateFns, DayJs, momentjs), a ideia desse padrão é, ao invés de utilizar diretamente a lib na classe onde vamos manipular datas, criarmos uma interface que declara todos os métodos que vamos utilizar e receber essa interface no construtor da classe que queremos manipular as datas, assim podemos facilmente trocar a implementação dessa interface por diversas libs diferentes porem para nossa classe não vai fazer diferença pois ela sempre vai estar chamando o método definido na interface, não importando quem implementou ele e nem como que ele foi implementado

Decorators

A ideia do decorator é que quando uma classe pode conter mais de uma logica pertencente a ela, nos podemos passar uma outra instancia dela para ela mesma para que ela consiga chamar essas novas instancias, por exemplo, vamos supor que estou criando um modulo de notificações, onde quero enviar a notificação para o celular da pessoa então cria uma instancia que extende a classe notificações porém tem a logica de mandar a notificação para o celular, e crio também uma instancia para enviar e-mail da mesma forma, agora supondo que eu precise enviar uma notificação que é Celular + E-mail, o padrão então sugere que ao invés de chamarmos uma notificação e depois a outra, todas as notificações possam receber uma outra notificação no seu construtor e ir chamando a próxima até que não tenha recebido mais nenhuma, dessa forma podemos misturar as notificações de diversas formas

Composite

Muito semelhante ao Decorators mas com diferença que a hierarquia importa mais. A ideia é deixar a gente compor objetos na estrutura de arvore e depois ir trabalhando com esses objetos de forma individual, então por exemplo se queremos saber o preço total de um pedido podemos receber itens que compõem esse pedido ou até mesmo um pedido anterior que vai compor esse pedido, e a ideia é percorrermos esse pedido anterior buscando o valor dele para somar com o valor dos itens do pedido atual e termos um valor total

Facade

A ideia é ter um objeto que funciona como uma fachada escondendo um processo complexo onde tem que ser chamados vários métodos em ordens especificas, ao invés de deixar isso para o cliente nos podemos criar uma fachada com um método único que vai executar tudo na ordem que deve ser executada escondendo essa complexidade do cliente

Proxy

O proxy tem como objetivo otimizar o tempo das chamadas, então por exemplo se eu preciso fazer algo que gasta muito recurso eu posso criar uma classe proxy que tem acesso a essa classe que queremos evitar chamar a toa, e então utilizamos a classe proxy para saber se a classe mais pesada deve ou não ser chamada, por exemplo, quero pegar um dado do banco de dados mas não tenho acesso, se eu fizer a chamada pelo proxy ele n vai deixar nem eu tentar acessar, mas se eu fizer normalmente eu vou conseguir e provavelmente vai falhar a chamada, outra utilização é usar o proxy como uma espécie de cache, digamos que eu precise de um valor que para conseguir esse valor eu preciso fazer uma conta complexa que demora muito tempo, se mais na frente na mesma execução eu precise desse valor novamente, o proxy pode me retornar ele direto

Kubernets

Yan.ts — Sun, 31 Jul 2022 02:31:59 +0000

Kubernets é um orquestrado de containers, feito pela google ele veio do Borg que era uma ferramenta interna da empresa, um dos motivos da google criar o kubernets foi fazer a GCP (Google Cloud Provider) ficar mais competitiva com a AWS que na época dominava o mercado de cloud. Hoje em dia todas as grandes clouds dão suporte ao kubernets

O kubernets é disponibilizado por um conjunto de APIS mas normalmente utilizamos ele pela CLI com o kubectl, o k8s(abreviação para kubernets) funciona de uma forma parecida com o docker, definimos um arquivo yaml onde passamos todas as configurações para o nosso pod e aplicamos esse yaml no kubernets onde ele sobe essas configurações.

O k8s trabalha em formato de clusters (conjunto de maquinas), onde dentro desse cluster temos um node que é o master que quem vai controlar tudo o que os outros nodes vão fazer, esse node master tem os seguintes serviços rodando pra ele:

control manager
scheduler
api server

e os outros nodes tem:

kubelet
kubeproxy

Dinâmica

Temos um cluster que é conjunto de maquinas onde cada uma dessas maquinas chamamos de nodes, cada maquina dessas possui uma quantidade de vCPU e Memória.

Dentro do nosso cluster temos também os pods, os pods são unidades que contem os containers provisionados, eles representam os processos rodando no cluster, cada pod pode ter mais de um container, mas na maioria das vezes e inclusive todas as vezes que eu utilizei foi sempre um pod por container

Temos também o Deployment que é um outro tipo de objeto do k8s que seu objetivo é provisionar os pods, mas para isso ele precisa saber quantas replicas desse pod precisamos, e para isso temos um replicaSet onde podemos informar quantas replicas de cada pod queremos, geralmente informamos isso na mesma descrição do deployment.

O ReplicaSet funciona da seguinte forma, informamos quantos pods queremos de cada tipo, então por exemplo, quero 3 replicas para o meu serviço de pagamento, caso uma dessas replicas caia o replica set sobe outro pod igual no lugar imediatamente.

Caso queira saber mais sobre quando utilizei o k8s pela primeira vez e principalmente como aprender a usar ele sem precisar gastar dinheiro com cloud para isso eu fiz esse post a um tempo atrás

Extensão Gitflow

Yan.ts — Sat, 16 Jul 2022 04:19:17 +0000

Gitflow

A ideia do GitFlow é que a branch master (hoje em dia o nome está sendo trocado para main) Vai ser a branch onde fica o sistema em produção para isso vamos ter uma branch auxiliar, no caso da imagem a branch "Develop" onde vamos subir os nossos códigos que vão ser produzidos a partir dessa branch.

Depois de um tempo a branch vamos ter uma segunda branch que vai ser a release onde vamos subir ela para produção, fazemos isso para poder continuar atualizando a branch develop.

Uma exceção para esse fluxo é o hotfix, onde caso encontremos um bug em master que seja importante a resolução rápida, criamos uma nova branch a partir de master e fazemos o merge dela direto em master e em develop para garantir que os dois foram corrigidos.

Extensão

existe uma extensão para lidar com o gitflow ela pode ser instalada por esse link https://github.com/petervanderdoes/gitflow-avh/wiki/Installing-on-Linux,-Unix,-etc.

depois de instalarmos a extensão podemos rodar o comando

git flow

e se ele retornar os comandos que pode usar está tudo certo.

ao usarmos o

git flow init

ele vai pedir umas configurações para inicializar

e como usar a extensão? se quisermos criar uma nova feature a ideia é que vamos criar uma branch feature

perceba que a própria extensão criou uma nova branch com o prefixo de feature e me colocou nessa branch, criei um arquivo main.js nessa branch e isso era tudo que queria fazer nela, nesse caso vou rodar o comando

git flow feature finish <nome_da_feature>

a extensão já faz automaticamente o merge para a branch develop e me leva para ela. A continuação do fluxo é criar uma branch de release, então temos uma configuração para isso na extensão também

git flow release start <versão_da_release>

Agora podemos continuar criando features e passando elas para develop sem problemas

e quando damos o finish no release ele vai pedir uma mensagem para o commit e uma tag e então vai fazer o merge direto com a main e com a develop para garantir a consistência

O hotfix segue o mesmo padrão das outras, mas a diferença é que ele vai pedir uma tag quando usarmos o finish pois ele vai fazer um merge direto para main

Considerações

Achei a extensão muito legal para conhecer e a forma que ela automatiza algumas coisas como a criação de novas branches já com o prefixo e a deleção dessas branches ao serem finalizadas , mas acabei não gostando dos merges automáticos para dev e master, no contexto do dia a dia acabo preferindo muito mais fazer pull requests ou no caso do gitlab merge requests para que os outros devs da equipe possam fazer os code reviews e garantir a qualidade do código

Kafka Connect

Yan.ts — Fri, 08 Jul 2022 21:16:32 +0000

Kafka connect é um componente do Apache Kafka que trabalha como um hub de dados centralizados para integrações simples, então ele serve muito para pegar dados de um lado e jogar para um banco de dados ou alguma outra aplicação.

Dinâmica

O Kafka vai ter connectors que podem estar ligados a data sources ou Sinks, esse conector vai constantemente pegar os dados de um data source como um postgres por exemplo em um topico do kafka e desse topico para um Sink como um ElasticSearch

Standalone Workers

O Kafka connect é formado a partir de workers que são na verdade maquinas que rodam tarefas ou seja eles ficam pegando os dados de um sistema A e guardando no Kafka ou pegando do kafka e jogadno em um sistema B, esses workers podem ter mais de uma tarefa para que eles rodem em paralelo

Distributed Workers

Nesse caso os workers vão trabalhar em um cluster onde as maquinas vão se ajudar a trabalhar nas tarefas, por exemplo, se tivermos uma tarefa com mais de uma partição, podemos deixar esses workers cada um lendo de uma partição semelhante como o consumer do próprio kafka funciona. No caso de workers distribuídos os workers individualmente podem executar mais de uma tarefa também.

Converters

As Tarefas usam os converters para mudar o formato dos dados para leitura ou escrita no kafka então podemos informar o tipo dos dados que estamos trabalhando, evitando assim o problema de por exemplo termos um int que acabou sendo convertido de forma errônea para string, temos algumas opções de formatos de dados como:

Avro
Protobuf (dados binarios)
JsonSchema
Json
String
ByteArray

Nessa imagem temos um exemplo mais ou menos de como funciona o connect pega os dados e converte para o formato Avro e salva no Kafka, e então o o conector do Sink pega esses dados converte para outro formato e joga de volta para a Sink

DLQ - Dead Letter Queue

Quando tem um registro invalido o erro pode ser tratado na configuração do conector. Porem esse tipo de configuração só pode ser realizado para conectores do tipo Sink, que são dados que já estão no Kafka.

Temos alguns tipos de tolerancia para esses errors:

none: Caso dê erro a tarefa vai falhar, porem ela vai fazer a tarefa parar
all: Ignora os errors e continua com a tarefa (porem dessa forma não vai ficar nos logs esse errors, vai ser de fato completamente ignorado)
errors.deadleatterqueue.topic.name = : com a tolerância de errors como all e essa configuração, todas as vezes que der erro vamos pegar a mensagem e jogar no tópico que passamos o nome, e no header da mensagem vai ter o erro que o kafka connect encontrou

Kafka

Yan.ts — Fri, 01 Jul 2022 22:25:21 +0000

O Kafka é uma plataforma distribuída de streaming de eventos. Além disso ele é open source e utilizado por milhares de empresas.

Hoje em dia tudo é evento e o kafka nos ajuda a processar esses eventos de forma rápida, fácil e resiliente. O kafka por padrão salva os eventos que passam por ele para guardar histórico, inclusive podem ser utilizados como um storage, nesse post do blog do linkedin de 2013 o Jay Kreps fala uma pouco mais sobre isso (curiosidade: O Kafka nasceu no Linkedin).

Poderes do Kafka

Altíssimo throughput: Ele tem uma capacidade muito alta de ser bombardeado por requisições
Latência extremamente baixa (2ms): Leva muito pouco tempo para uma informação ser trafegada nele
Escalável
Armazenamento
Alta disponibilidade
Existe driver para quase qualquer linguagem
Bibliotecas prontas para mais diversas tecnologias
Ferramentas open-source, ex: kafka-connect, kafka-streams, ksqldb

Como funciona

A dinâmica básica é um produtor de mensagem de um lado e um consumidor dessa mensagem dos outros porem ao invés do produtor mandar a mensagem direto para o consumidor ele enviar para o kafka (que na verdade é um cluster de brokers), e então o broker salva o valor em seu banco de dados e então o consumer acessa esse cluster e pega essa nova mensagem. Existe uma concepção errada que inclusive eu tinha de que o kafka envia a mensagem para o consumer mas na verdade o consumer que vai buscar pela mensagem.

A recomendação mínima para colocar o kafka em produção são 3 brokers, para gerenciar todas as questões com relação a esses brokers como: ver se a maquina está rodando, em qual maquina vai ser armazenado a mensagem e etc temos o apache zookeeper que também é um sistema open source da apache, porem atualmente o plano é retirar o zookeeper e deixar o kafka totalmente independente

Tópicos

Tópico é o canal de comunicação responsável por receber e disponibilizar os dados enviados para o kafka, então quando o producer envia uma mensagem para um broker na verdade ele envia para um tópico desse broker e o consumer também lê as mensagens desse tópico. Podemos inclusive ter mais de um consumer lendo mensagens de um mesmo tópico, então podemos por exemplo ter um sistema de logs, e o sistema de evento lendo as mesmas mensagens do tópico.

Cada mensagem enviada para um tópico é armazenada uma depois da outra em ordem de chegada, para cada mensagem armazenada ela recebe um offset que é sua posição nesse array de mensagens. Dois consumers podem estar em diferentes offsets de um mesmo tópico sem problema algum

Anatomia de uma mensagem

Uma mensagem é composta por 4 partes principais

1. Headers

São dados opcionais que podemos trabalhar como se fossem metadados que podemos passar para nos ajudar

2. Key

Como o nome diz é a chave da mensagem, é um conceito um pouco complicado de explicar que no começo me confundiu bastante, mas pense que ela é um parâmetro não obrigatório que podemos passar quando queremos garantir uma ordem de chegada de mensagens em um determinado contexto. Depois vou explicar com um exemplo.

3. Value

Como o nome já diz é conteúdo da mensagem, os valores que enviamos naquela mensagem

4. Timestamp

Marca quando a mensagem foi enviada

Partições

Cada tópico pode ter uma ou mais partições para garantir a distribuição e resiliência dos dados. Para evitar deixar todos os dados em um mesmo broker o kafka faz varias partições para um mesmo tópico em diferentes brokers para que assim caso um broker caia não aconteça de nenhum consumer conseguir ler essas mensagens.

Outro beneficio de aumentar as partições é que podemos ter mais de uma replica de consumer lendo de um topico cada uma pode se conectar com uma partição e ler todas as mensagens dessa partição, multiplicando assim sua velocidade.

Ex: Temos 1.000.000 de pagamentos em um tópico e apenas um serviço de processar esses pagamentos, esse serviço vai ter que então ler essas 1.000.000 mensagens para processarmos todos os pagamentos, mas e se replicarmos esse serviço? ai temos um problema de garantir que esses dois serviços não vão acabar lendo as mesmas mensagens, agora se adicionarmos mais uma partição e dividirmos 500.000 mensagens para cada, cada consumer pode se conectar em uma partição e vamos processar essas mensagens no dobro da velocidade incial

Como funciona a Key

Vamos imaginar uma operação de compras onde a ordem é bem importante de ser mantida, então quando o cliente faz uma compra nós enviamos uma mensagem com uma key que pode ser um uuid gerado para representar essa compra, a partir de agora todas as mensagens que chegarem com essa key o kafka vai GARANTIR que vai manter a ordem de chegada mantendo essas mensagens com a mesma key na mesma partição, evitando assim de acontecer por exemplo a mensagem de emitir uma nota fiscal vir primeiro que a de aprovar pagamento.

O consumidor que for ler a partição sempre vai pegar essas mensagens na ordem correta, diferente de se por exemplo elas estivessem em diferentes partições que não temos como garantir que um consumidor não vai consumir mais rápido que o outro gerando assim uma ordem errada de processamento

Replication Factor e Partition Leadership

Trabalhando com partições já temos uma boa solução para como manter os dados distribuídos porem ainda não temos uma resiliencia total, pois se um broker cair vamos ter uma perda temporaria dos dados daquela partição o que pode ser tolerado, porem se o broker perder o hd por exemplo vamos ter uma perda definitiva daqueles dados o que não pode ser tolerado.

Podemos então utilizar o replication factor, onde informamos quantas replicas de cada partição queremos, na imagem podemos ver que temos 1 copia de cada partição e sempre essa copia em brokers diferentes, assim, caso aconteça algo com o broker 1 por exemplo ainda temos todos os dados dele replicados nos brokers 2 e 3

Sempre que replicamos as partições teremos uma partição líder e sempre que o consumidor for ler dessa partição ele vai ler também da partição líder. Somente se a partição líder cair que o Kafka vai fazer um novo sorteio e definir qual a nova partição que será a líder

Garantia de entrega das mensagens

Quando o producer envia uma mensagem para o tópico ele pode configurar um parâmetro que é o Ack.

Ack 0: o producer informa que ele não precisa saber se a mensagem de fato chegou, isso também é chamado de FF: Fire and Forget onde simplesmente passamos a mensagem para o tópico sem se importar se ele recebeu ou não

Ack 1: o producer envia uma mensagem e espera que a partição líder responda informando que salvou a mensagem. Ainda temos o risco de perder a mensagem caso o líder caia antes de replicar as mensagens para os seus seguidores

Ack -1: O producer envia a mensagem, o líder salva essa mensagem, replica para os seguidores os seguidores avisam que salvaram e só então ele responde ao producer informando que salvou, é a forma de ter 100% de certeza que a mensagem foi salva

Garantias de entrega no consumer:

At most once: O consumer vai receber as mensagens no máximo uma vez, é a forma mais performática porem pode perder mensagens no meio do caminho

At least once: O consumer vai receber as mensagens pelo menos uma vez, assim é garantido que ele vai receber, tem um tempo de processamento moderado mas é preciso garantir que o consumer sabe o que fazer ao receber uma mensagem repetida

Exactly once: O consumer vai receber as mensagens exatamente uma vez. Essa forma tem a pior performance pois o kafka tem que garantir que o consumidor recebeu a mensagem que ele enviou e q ele ainda não recebeu a mensagem que ele vai enviar

Consumer Group

Vamos supor um cenário com mais partições do que consumidores porem os consumidores estão em um mesmo grupo, nesse caso eles vão se dividir para ler as partições, agora vamos imaginar mais um consumidor que não está nesse mesmo grupo, esse consumidor vai ler de todas as partições. Agora se no nosso grupo tivermos mais consumers do que partições o que acontece é que esses consumers extra ficam esperando uma partição livre para que eles leiam, em um mesmo grupo nunca vai ter mais de um consumer por partição

Fazendo deploy com o kubernets no GCP

Yan.ts — Thu, 30 Jun 2022 01:00:23 +0000

Com uma conta ativa e com faturamento ativo no google cloud provider podemos procurar pelo kubernets engine na barra de pesquisa e ativar essa opção.

Com ela ativa podemos criar um cluster do tipo standard, dentro das configurações do cluster q vou criar somente mudei o nome e o numero de nós de 3 para 2

Como quero fazer esse teste com o kafka fui no confluent cloud e criei uma conta lá, e subi um cluster gratuito no google cloud por lá

Em seguida para continuar instalei o cli do google cloud mas não é obrigatório, se quiser abaixo de onde o google cloud coloca a string de conexão ele também dá a opção de usar o terminal online

Depois de feita a conexão podemos testar rodar o kubectl get nodes e então o output deve ser os nodes lá do GCP

depois disso criei uma pasta para colocar os arquivos k8s do meu simulador então criei um deploy.yml

se quiser saber mais sobre deployment pode ir no meu post sobre kubernets

apiVersion: apps/v1
kind: Deployment
metadata:
  name: simulator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: simulator
  template:
    metadata:
      labels:
        app: simulator
    spec:
      containers:
        - name: simulator
          image: yansb/codedelivery:latest
          volumeMounts:
            - name: simulator-volume
              mountPath: /go/src/.env
              subPath: .env


      volumes:
        - name: simulator-volume
          configMap:
            name: simulator-conf
            items:
              - key: env
                path: .env

e um configmap.yml que tem minhas variáveis de ambiente

yml apiVersion: v1 kind: ConfigMap metadata: name: simulator-conf data: env: | KafkaReadTopic=route.new-direction KafkaProduceTopic=route.new-position KafkaBootstrapServers= KafkaConsumerGroupId=simulator security.protocol=SASL_SSL sasl.mechanisms=PLAIN sasl.username= sasl.password=`

depois de criados esses arquivos temos que rodar os comandos

kubectl apply -f k8s/simulator/configmap.yml
kubectl apply -f k8s/simulator/deploy.yml

e agora nossos pods já estão subindo

E como a aplicação q eu subi foi o simulator que está conectado no kafka posso verificar que o pod está online pelo confluent cloud

Ele já está conectado, recebendo e mandando mensagens.

Observabilidade com kafka connect e elasticsearch

Yan.ts — Fri, 24 Jun 2022 21:15:15 +0000

Kafka connect

O kafka connect é um serviço do kafka que serve para pegar dados de um serviço e jogar para um outro.

Por exemplo pegar os dados do meu banco de dados e passar para um arquivo txt, ou para um elastic search ou algo desse tipo

O kafka connect é um cluster com diversas maquinas que realizam essas tarefas, essas maquinas são chamadas de worker sendo que cada worker pode lidar com mais de uma tarefa.

Dashboard do kafka

Irei deixar o yml do compose no final do post. Mas uma coisa q ele faz é colocar o control center da confluent na porta 9021 e é isso q vamos abrir.

No menu lateral do dashboard tem a opção de connectors onde ele mostra todos os clusters do kafka connect conectados atualmente, de inicio não vai ter nenhum, ainda temos que fazer essa conexão, quando subir o docker-compose vai perceber que ele vai criar duas pastas no seu diretório atual data e es01 essas pastas vão ser usadas para manter as configurações. Porem além delas também vamos criar uma pasta connectors com um arquivo elasticsearch.properties, nesse arquivo vamos definir algumas configurações como o nome do desse conector, a classe dele, os tópicos que esse conector vai ouvir, a url de conexão, o tipo dos documentos e o conversor de valores para que os dados cheguem como json

name=elasticsearch-sink
connector.class=io.confluent.connect.elasticsearch.ElasticsearchSinkConnector
topics=route.new-direction,route.new-position
connection.url=http://es01:9200
type.name=_doc
value.converter=org.apache.kafka.connect.json.JsonConverter
value.converter.schemas.enable=false
schema.ignore=true
key.ignore=true
transforms=InsertField
transforms.InsertField.type=org.apache.kafka.connect.transforms.InsertField$Value
transforms.InsertField.timestamp.field=timestamp

Com esse arquivo criado podemos voltar ao dashboard na parte de conectores e adicionar um novo conector fazendo o upload dele. Se tudo der certo (caso algo dê errado escrevi o que aconteceu de errado comigo e como solucionei no final do post) na parte de connectors ele vai exibir um connector como running

Se formos agora no Kibana, que está na porta 5601 podemos abrir o menu lateral e ir em Stack Management

Nessa pagina temos o Index Management que vai nos mostrar já os dois tópicos que selecionamos pra ele escutar. E temos também o Index Patterns.

Onde vamos criar um novo index-patern com base nos nossos tópicos, se eles já tiverem recebido uma mensagem com o kibana rodando quando criarmos o pattern ele já vai vai vir com os campos desse tópico

Agora se formos no menu lateral do kibana e clickar na parte de analytics ele já vai passar a mostrar todas as mensagem que recebemos em cada tópico

Adicionando os tipos dos campos

Para ficar com os index melhor formatados apaguei os que foram gerados automaticamente e fui na parte de devTools do menu do kibana, lá escrevi os seguintes comandos.

PUT route.new-position
{
  "mappings": {
   "properties": {
      "clientId": {
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword"
          }
        }
      },
      "routeId": {
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword"
          }
        }
      },
      "timestamp": {
        "type": "date"
      },
      "finished": {
        "type": "boolean"
      },
      "position": {
        "type": "geo_point"
      }
    }
  } 
}

PUT route.new-direction
{
  "mappings": {
   "properties": {
      "clientId": {
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword"
          }
        }
      },
      "routeId": {
        "type": "text",
        "fields": {
          "keyword": {
            "type": "keyword"
          }
        }
      },
      "timestamp": {
        "type": "date"
      }
    }
  } 
}

Agora o position vai ser lido como uma localização ao invés de numero como estava antes e podemos visualizar ele no mapa

clickando em visualize vamos para o mapa onde podemos visualizar esses positions no mapa

Criando visualizações

Na opção de visualizações vamos criar uma nova visualização do tipo Lens

Dentro da parte de visualizações podemos adicionar os dados que queremos e exibir-los da forma desejada

Então por exemplo, coloquei o contador de records do tópico new-direction, mudei seu tipo para métrica e coloquei o nome de corridas e então salvei.

Criei também a visualização de mapa e por fim criei um dashboard com todas essas informações

Docker-compose

Aqui o docker compose que usei para aprender, lembre de trocar o ip para o seu próprio, caso não saiba qual o ip pode rodar esse comando
docker run -it --rm alpine nslookup host.docker.internal que o docker te informa qual o ip

version: "3"

services:  

  zookeeper:
    image: confluentinc/cp-zookeeper:latest
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
    extra_hosts:
      - "host.docker.internal:192.168.65.2"

  kafka:
    image: confluentinc/cp-kafka:latest
    depends_on:
      - zookeeper
    ports:
      - "9092:9092"
      - "9094:9094"
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_INTER_BROKER_LISTENER_NAME: INTERNAL
      KAFKA_LISTENERS: INTERNAL://:9092,OUTSIDE://:9094
      KAFKA_ADVERTISED_LISTENERS: INTERNAL://kafka:9092,OUTSIDE://host.docker.internal:9094
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: INTERNAL:PLAINTEXT,OUTSIDE:PLAINTEXT
    extra_hosts:
      - "host.docker.internal:192.168.65.2"

  kafka-topics-generator:
    image: confluentinc/cp-kafka:latest
    depends_on:
      - kafka
    command: >
      bash -c
        "sleep 5s &&
        kafka-topics --create --topic=route.new-direction --if-not-exists --bootstrap-server=kafka:9092 &&
        kafka-topics --create --topic=route.new-position --if-not-exists --bootstrap-server=kafka:9092"

  control-center:
    image: confluentinc/cp-enterprise-control-center:6.0.1
    hostname: control-center
    depends_on:
      - kafka
    ports:
      - "9021:9021"
    environment:
      CONTROL_CENTER_BOOTSTRAP_SERVERS: 'kafka:9092'
      CONTROL_CENTER_REPLICATION_FACTOR: 1
      CONTROL_CENTER_CONNECT_CLUSTER: http://kafka-connect:8083
      PORT: 9021
    extra_hosts:
      - "host.docker.internal:192.168.65.2"

  kafka-connect:
    image: confluentinc/cp-kafka-connect-base:6.0.0
    container_name: kafka-connect
    depends_on:
      - zookeeper
      - kafka
    ports:
      - 8083:8083
    environment:
      CONNECT_BOOTSTRAP_SERVERS: "kafka:9092"
      CONNECT_REST_PORT: 8083
      CONNECT_GROUP_ID: kafka-connect
      CONNECT_CONFIG_STORAGE_TOPIC: _connect-configs
      CONNECT_OFFSET_STORAGE_TOPIC: _connect-offsets
      CONNECT_STATUS_STORAGE_TOPIC: _connect-status
      CONNECT_KEY_CONVERTER: org.apache.kafka.connect.storage.StringConverter
      CONNECT_VALUE_CONVERTER: org.apache.kafka.connect.json.JsonConverter
      CONNECT_INTERNAL_KEY_CONVERTER: "org.apache.kafka.connect.json.JsonConverter"
      CONNECT_INTERNAL_VALUE_CONVERTER: "org.apache.kafka.connect.json.JsonConverter"
      CONNECT_REST_ADVERTISED_HOST_NAME: "kafka-connect"
      CONNECT_LOG4J_ROOT_LOGLEVEL: "INFO"
      CONNECT_LOG4J_LOGGERS: "org.apache.kafka.connect.runtime.rest=WARN,org.reflections=ERROR"
      CONNECT_LOG4J_APPENDER_STDOUT_LAYOUT_CONVERSIONPATTERN: "[%d] %p %X{connector.context}%m (%c:%L)%n"
      CONNECT_CONFIG_STORAGE_REPLICATION_FACTOR: "1"
      CONNECT_OFFSET_STORAGE_REPLICATION_FACTOR: "1"
      CONNECT_STATUS_STORAGE_REPLICATION_FACTOR: "1"
      # # Optional settings to include to support Confluent Control Center
      #   CONNECT_PRODUCER_INTERCEPTOR_CLASSES: "io.confluent.monitoring.clients.interceptor.MonitoringProducerInterceptor"
      #   CONNECT_CONSUMER_INTERCEPTOR_CLASSES: "io.confluent.monitoring.clients.interceptor.MonitoringConsumerInterceptor"
      #  ---------------
      CONNECT_PLUGIN_PATH: /usr/share/java,/usr/share/confluent-hub-components,/data/connect-jars
    # If you want to use the Confluent Hub installer to d/l component, but make them available
    # when running this offline, spin up the stack once and then run :
    #   docker cp kafka-connect:/usr/share/confluent-hub-components ./data/connect-jars
    volumes:
      - $PWD/data:/data
    # In the command section, $ are replaced with $$ to avoid the error 'Invalid interpolation format for "command" option'
    command:
      - bash
      - -c
      - |
        echo "Installing Connector"
        confluent-hub install --no-prompt confluentinc/kafka-connect-elasticsearch:10.0.1
        #
        echo "Launching Kafka Connect worker"
        /etc/confluent/docker/run &
        #
        sleep infinity
    extra_hosts:
      - "host.docker.internal:192.168.65.2"

  es01:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.11.2
    container_name: es01
    environment:
      - node.name=es01
      - cluster.name=es-docker-cluster
      - cluster.initial_master_nodes=es01
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - ./es01:/usr/share/elasticsearch/data
    ports:
      - 9200:9200
    extra_hosts:
      - "host.docker.internal:192.168.65.2"

  kibana:
    image: docker.elastic.co/kibana/kibana:7.11.2
    container_name: kib01
    ports:
      - 5601:5601
    environment:
      ELASTICSEARCH_URL: http://es01:9200
      ELASTICSEARCH_HOSTS: '["http://es01:9200"]'
    extra_hosts:
      - "host.docker.internal:192.168.65.2"

Problemas que encontrei

Ao tentar rodar o docker-compose depois de criar o es01 precisei alterar as permissoes dessa pasta pois ela não estava deixando o docker do elastic criar os arquivos dentro dela
sudo chown -R 1000:1000 es01
Ao subir o elasticsearch ele reclama do meu vm.max_map_count, tive que redefinir essa variavel no meu sistema rodando o comando:
sysctl -w vm.max_map_count=262144, porem isso só dura a sessão atual, se quiser uma solução mais duradoura nessa pagina encontrei tambem
https://stackoverflow.com/questions/51445846/elasticsearch-max-virtual-memory-areas-vm-max-map-count-65530-is-too-low-inc

RabbitMQ

Yan.ts — Tue, 21 Jun 2022 02:02:03 +0000

O RabbitMQ é um Message broker, ele faz o meio de campo entre a pessoa que envia a mensagem a pessoa q vai receber a mensagem. Ele implementa os protocolos AMQP, MQTT, STOMP e HTTP, sendo que o mais utilizado é o AMQP, que é baseado no TCP deixando o assim com uma velocidade muito rápida. Ele foi desenvolvido em Erlang, facilita o processo de desacoplamento entre os serviços pois ele que vai lidar com a comunicação entre esses serviços, ele é extremamente rápido e poderoso, além disso ele tem I/O por padrão diferente do Kafka que temos que implementar técnicas para isso.

Por baixo dos panos

Temos um client e um server, e essa conexão acontece por padrão por TCP, que de inicio é um pouco lenta, mas para evitar esse processo toda vez que formos no conectar e consumir uma fila no RabbitMQ ele abre apenas uma conexão e dentro dessa conexão ele cria subconexões que são chamadas de channels. Evitando assim todo o processo de abertura de conexão, isso é chamado de multiplexing connection, todo channel aberto também é uma nova thread

Funcionamento Básico

Temos um Publisher que como o nome já diz é o cara que vai publicar a mensagem e o consumidor que é quem vai ler a mensagem. Porem o publisher não envia a mensagem diretamente para o consumidor, ele envia para uma exchange que pega a mensagem que o publisher mandou, processa a mensagem e descobre para qual fila a mensagem deveria ser enviada e ai envia a mensagem para essa fila, e então o consumidor fica lendo essa fila de mensagens

Tipos de Exchange

Em um sistema podemos ter n filas e n exchanges, sendo que n filas podem estar conectadas com n exchanges e n exchanges podem estar conectados com n filas

Direct
A exchange manda a mensagem especificamente para uma determinada fila
Fanout
Quando manda uma mensagem pra essa exchange ela envia essa mensagem para todas as filas ligadas a essa exchange
Topic
Adicionamos algumas regras para dependendo do routing key ela encaminhar seguindo essa regra
Headers
O header da mensagem determina em qual fila queremos que a mensagem seja entregue

Direct Exchange

Na mensagem vamos especificar qual a routing Key da fila que queremos enviar a mensagem e então o exchange faz somente o processo de encaminhar a mensagem para a fila com o mesmo routing key

Fanout Exchange

Nesse caso não passamos nenhuma routing key, enviamos apenas uma mensagem e essa mensagem vai ser replicada para todas as filas vinculadas a essa exchange

Muito útil por exemplo em um sistema de compras onde queremos informar a diversos sistemas que a compra ocorreu como o sistema de estoque, administrativo, logs, nota fiscal e etc... Basta conectarmos todos esses sistemas na mesma exchange que ela já encaminha a mensagem para todos

Topic Exchange

Ele também funciona com as routing keys porem nesse caso as routing keys conseguem ter regras semelhantes a RegEx, e a exchange vai procurar quais as filas que dão match nessa RegEx

Queues

As filas trabalham no padrão FIFO (First in First Out)

Propriedades

Durable: Se ela deve ou não ser salva depois do restart do broker por padrão elas vem como duráveis
Auto-delete: Removida automaticamente quando o consumer se desconecta
Expiry: Define o tempo que não há mensagens ou clientes consumindo
Message TTL: Tempo de vida da mensagem
Max length ou bytes: Quantidade de mensagens que podem ir para uma fila ou o tamanho de bytes máximo permitido
Overflow: O que fazer quando a fila encher
- Drop Head (remove a última)
- Reject publish (não aceita novas mensagens)
Exclusive: Somente o channel que criou pode acessar

Dead letter queues

Algumas mensagens não conseguem ser entregues por algum motivo. Essas mensagens são encaminhadas para uma exchange especifica que roteia elas para uma dead letter queue, e então elas podem ser consumidas e averiguadas posteriormente.

Lazy queues

Quando o RabbitMQ chega no limite da memoria as mensagens passam a ser armazenadas em disco. Porem o ponto negativo é que exige um alto I/O, quando há muitas mensagens em uma fila por qualquer motivo. há a possibilidade de liberar a memória jogando algumas mensagens especificas para o disco

Simulador

Utilizei um simulador de RabbitMQ para testar os conceitos aprendidos

Confiabilidade

Como garantir que as mensagens não serão perdidas no meio do caminho? e que as mensagens puderam ser processadas corretamente pelos consumidores?

O RabbitMQ tem alguns recursos pensados para resolver essas situações:

Consumer acknowledgement: quando um consumer avisa que recebeu a mensagem
Publisher confirm: Todas as vezes que enviamos a mensagem o publisher informa que a imagem chegou até a exchange
Filas e mensagens duráveis / persistidas

Consumer acknowledgement

Existem 3 tipos de consumer acnowledgement:

Basic.Ack
O consumer recebe a mensagem e informa que está tudo ok
Basic.Reject
Rejeita a mensagem fazendo ela voltar e ficar na fila novamente
Basic.Nack
É semelhante ao reject porem pode rejeitar mais de uma ao mesmo tempo

Publisher confirms

A mensagem vai ter um id que vai ser do tipo int, quando o publisher enviar essa mensagem para a exchange, ela avisa para o publisher que recebeu a mensagem e passa o id, então o publisher fica sabendo que a mensagem foi recebida pela exchange. Porem se a exchange tiver algum problema ela vai retornar um Nack passando o id da mensagem que deu o problema para que o publisher saiba que aquela mensagem não foi publicada

Kong API Gateway

Yan.ts — Sat, 18 Jun 2022 14:11:13 +0000

Alguns pontos sobre o kong

Api Gateway Open Source e gratuito
Caracteristicas Micro Gateway ou seja, ele não prove configurações para controles de ciclo de vida
Deployment flexível
Pronto para kubernets
Extensível via plugins

Modelos de deployment

O kong tem 3 modelos de deployment

DB-Less

Fazemos a configuração dele por um arquivo Yaml ou JSON e subimos ele com base no arquivo, quando ele subir essa configuração ver carregada na memoria de cada nó do Kong.

Com danco de dados

As configurações ficam todas em um banco de dados compartilhado por todos os nós. Um dos nós vai agir como control-plane e passar as configurações para o postgres que passa para os outros nós

Hibrido

O modelo de deployment hibrido é o modelo recomendado pela equipe do Kong, a ideia é ter um control-plane que somente ele vai acessar o banco de dados, diferente do deploy com banco onde todas as instancias tem acesso ao banco. Nesse modelo hibrido os outros nós vão sempre receber as configurações do control-plane

Konga

Interface administrativa para o Kong
Visualização de métricas das instâncias
Controle de usuarios
Gerencia mais de um Kong

Servicos

Um serviço é uma entidade que representa uma API ou microsserviço upstream. Por exemplo um microsserviço de pagamentos ou de cadastro etc..

Criando um novo serviço

Primeiro temos que ir até a pagina de services e clickar no botão de adicionar um novo service

e então cadastrar ele:

Rotas

As rotas são os caminhos de url que permite que um serviço cadastrado no nosso API Gateway seja acessado através do gateway

Para cadastrar uma rota temos que ir dentro do serviço cadastrado e ir na opção "Routes" quando criamos uma rota podemos definir algumas configurações uma delas sendo o Host,

Quando definimos o Host somente requests que tem o host esperado vão conseguir acessar aquela rota

com o Host:

sem o Host:

Plugins

Plugins são um pedaço de código que pode ser executado dentro de um ciclo de vida de uma requisição HTTP, tanto no request como no response, em outras Gateways isso pode ser encontrado como policy mas no Kong se chama plugin

Os plugins podem ser configurados nas Rotas, Serviços, Consumers e Globalmente, tem uma precedência para as configurações

essa é a ordem de precedência, quanto menor, mais prioridade

Podemos escrever nossos proprios plugins em Lua, Javascript e Golang. Porêm o suporte é muito maior para Lua.

Consumers

É quem pode consumir sua API, para testar essa parte, criei dois consumidores, um que é um usuário e uma app

no usuário fui até a parte de credentials e criei uma senha para esse usuário, enquanto na app fui nessa parte também porem criei uma API key

Depois disso foi só utilizar o plugin basic auth que a minha api já está me retornando como unauthorized

Apesar de não ser uma solução de fato muito segura, é muito interessante a facilidade para aplicar isso

Observabilidade

O kong tem plugins de suporte ao prometheus além de um dashboard oficial no grafana basta subirmos o prometheus e o grafana no docker-compose e instalar o plugin do prometheus no kong que temos um dashboard totalmente funcional

Além disso tem todo um suporte para diversos sistemas de logs sendo facilmente possivel integrar um Datadog por exemplo

API Gateway

Yan.ts — Fri, 17 Jun 2022 16:13:57 +0000

O que é API

APIs são um conjunto de operações bem definidas com o objetivo de fornecer aos seus consumidores um serviço, produto ou integração

Na pratica o consumidor de uma API utiliza o serviço sem precisar entender os detalhes da implementação.

Essa imagem ilustra bem o objetivo da API, seguindo essa analogia de restaurante um casal que pediu uma refeição geralmente não liga muito quem é a pessoa que está preparando essa refeição, eles ligam que o prato chegue até a mesa.

Da mesma forma quando vamos consumir uma API no Frontend, não importa se ela foi construída em Node, Java, Go ou qualquer outra linguagem, o que importa é o front receber o que ele espera

Existem algumas APIs famosas por serem muito bem desenhadas fazendo com que empresas ou desenvolvedores solo possam integrar facilmente com essas APIs, por exemplo a API do twitter que é super bem documentada.

API Gateway

Os API gateways surgiram para resolver um problema gerado pela arquitetura de microsserviços, vamos imaginar que temos uma api publica e um cliente quer fazer uma integração com ela, porem nosso Backend é distribuído, já pensou falar pro cliente qual a api que ele precisa chamar para cada microsserviço que ele queira trabalhar? Isso seria inviável.

Eles são ferramentas de gerenciamento, geralmente adicionadas entre um cliente e um grupo de sistemas, atuando como um ponto unico de entrada para as APIS

Nessa imagem podemos ver dois clients Front consumindo a API porem eles falam com a API Gateway e a Gateway redireciona a requisição para o microsserviço que eles querem de fato se comunicar, inclusive fazendo a tradução de protocolo pois tem duas apis REST e uma AMQP, isso fica abstraído para o front

O Gateway vai ser sim um single point of failure (ponto único de falha), portanto temos que garantir a escalabilidade e resiliência dele.

Responsabilidades do Gateway

Rate limiting
Autenticação (Isso não isenta o serviço de ter uma autenticação própria com permissionamento e tudo mais)
Controle de logs
Gerenciamento de APIs (routing)
Métricas padronizadas (ops team)
Tracing Distribuido

Tipos de API Gateway

Enterprise Gateway

O foco dele é permitir gerenciar exposição e gerenciamento de apis voltadas ao negocio. Em geral ele permite controlar o ciclo de vida da API também.

Como o Enterprise Gateway normalmente tem muitas funcionalidades extras temos que tomar cuidado para não deixar ele fortemente acoplado com a nossa aplicação dificultando assim uma migração no futuro.

Seu proposito principal é a exposição, composição e gerenciamento de APIs externas ou internas, a manutenção em geral é feita pelo portal do API gateway e ela suporta múltiplos ambientes.

Micro/Microservices Gateway

Geralmente esse tipo de gateway tem a capacidade de "rotear" o trafego de entrada para APIs ou serviços. Em geral ele não tem suporte para o ciclo de vida da API e a equipe tem que cuidar disso em um processo separado. Geralmente é open source.

Em geral não possuem dependências externas, e são componentes standalone, facilitando assim o kubernets gerenciar o estado necessário para execução da aplicação

Seu proposito principal é a exposição, observabilidade e monitoramento de serviços, a manutenção é feita pelo time de API que via configuração declarativa fazem atualizações, isso faz parte do deployment do serviço ela controla um único ambiente, mas possui suporte a um roteamento mais dinâmico como por exemplo o Canary para facilitar o debug.

Algumas boas praticas são, usar a flexibilidade do deployment para "particionar" as APIs. E tentar ser Stateless o máximo possível aumentando assim muito a facilidade da escalabilidade e disponibilidade

Vantagens e desvantagens

Vantagens

Padronização de alguma features como logging e segurança
Ajuda na governança de rede da companhia
Ponto único de entrada na rede facilitando o gerenciamento

Desvantagens

Adiciona complexidade na arquitetura
Precisa de um cuidado extra, devido a disponibilidade
Ferramenta que precisa de manutenção/atualização

Usando o Kubernets pela primeira vez

Yan.ts — Fri, 17 Jun 2022 00:16:56 +0000

Já subi uma aplicação para a AWS umas 3 vezes mas todas foram um processo muito manual usando o EC2, hoje pela primeira vez usei o kubernets para automatizar esse processo.

Kubernets (K8s)

O kubernets é um orquestadror de containers que fica responsável por transformar esses containers em pods e subir esses containers de forma mais automatizada para uma cloud como AWS ou GCP ou outras opções, porem ele não faz só isso, ele também tem o load balancer onde ele tenta distribuir as cargas para não deixar um pod sobrecarregado e também toda a parte de service discovery além de levantar pods novos sempre que os antigos caírem

Como usar o K8s

Primeiro vamos criar um arquivo do tipo yml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
      - containerPort: 80

Nesse arquivo inicial temos:
apiVersion: Versão da api do k8s, nesse caso é a v1
kind: qual o tipo do recurso a ser criado, nesse caso um pod
metadata: dados complementares

name: nome do pod
labels: label do pod então podemos depois filtrar por pods com a label ngnix por exemplo spec: especificação do serviço
containers: qual o container dentro daquele pod com seu nome a sua imagem e a sua porta > Existem casos de termos mais de um pod em um container porem como regra geral geralmente temos um pod por container

Com isso temos já um pod, para testar esse pod podemos usar o kind que serve para rodar o kubernets localmente, no próprio site do kind eles ensinam como instalar em diversos sistemas operacionais. Depois de instalado podemos rodar o comando
kind create cluster --name={algo}

e entao o kind vai sugerir rodarmos o comando kubectl cluster-info --context kind-{algo} mas para isso vamos precisar do kubectl depois de rodarmos o comando do kubectl conseguimos ver que o kubernets já está como ready

por padrão o kubernets tem o control-plane que gerencia tudo, e quem é gerenciado são as maquinas que ficam conectadas no control-plane. Para rodar um cluster kubernets é recomendado no minimo 3 maquinas

agora para conectar o pod precisamos rodar kubectl apply -f {nome_do_yml} e com o kubectl get pods ele vai retornar o pod rodando, e para conectar com o ngnix? temos que dar um port-forward com o comando kubectl port-forward pod/nginx 9090:80 onde 80 é a porta que declaramos no yml e o 9090 é a porta que disponibilizei no meu computador, então se eu for no meu localhost 9090 vou encontrar o nginx

ReplicaSet

Porem o kubernets ainda não está mantendo o pod online todo o tempo, se rodarmos o comando kubectl delete pod nginx o pod vai ficar fora do ar. Para garantir que os pods estejam sempre online precisamos adicionar o Replica set, que fica gerenciando os pods e vendo se algum pod saiu do ar para ele criar um novo.

O yml do replicaSet ficou assim:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      name: nginx
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

onde ele é do tipo ReplicaSet e ele monitora todos os pods que a label é 'nginx', ele tem também um template igual ao pod que definimos no yaml anterior, para que ele saiba como vai ser o pod que ele vai criar.

Podemos ver que agora sempre que eu excluo um pod o replicaSet logo em seguida sobe um novo no lugar, além disso é possivel ver que já está salva a configuração que eu desejo manter apenas uma replica daquele pod.

Deployments

Se eu quiser mudar a versão da imagem que estou utilizando o replicaSet não vai fazer essa mudança de forma automática, para isso vou precisar matar o pod para quando subir novamente ele subir com a versão nova, o replicaSet só verifica se o pod caiu e quantos pods eu quero.

Agora imagine essa situação onde eu tenho por exemplo 100 replicas, eu teria que matar os pods para atualizar a versão da imagem. E para isso temos os deployments, que são responsaveis por cuidar dos replicasets.

O Deployment sempre que quisermos mudar a versão da imagem ele vai criar um novo replicaSet, então por exemplo, temos 10 pods na versão 1.0, queremos atualizar para a versão 1.1, o deployment cria um novo replicaset com a versão 1.1 e pedindo 10 pods, enquanto no da versão 1.0 ele pede por 0 pods, e se a versão 1.1 estiver quebrada e precisarmos voltar ele pede por 10 pods na versão 1.0 e 0 pods na versão 1.1

O yml do deployment é igual ao do replicaSet, só muda que no kind ao inves de ReplicaSet vai ser Deployment, porem todo o processo é mesmo, basta dar um apply que vai funcionar

Da para ver como ele fica alternando entre os replicaSets conforme a configuração muda

Rodando o kubernets com o meu servidor

Para isso criei um servidor bem basico em GO, tudo que ele faz é escrever hello world quando acessamos a porta 9090

package main

import "net/http"

func main() {
    http.HandleFunc("/", hello)
    http.ListenAndServe(":9090", nil)
}

func hello(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("Hello World!"))
}

alem disso vou criar um arquivo docker

FROM golang:1.18 as builder

WORKDIR /app
COPY main.go .
COPY go.mod .
RUN GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o server main.go

FROM scratch
COPY --from=builder /app/server .
CMD [ "./server" ]

vou buildar esse arquivo docker build -t yansb/goserver:latest . e se e eu rodar o comando docker run --rm -p 9090:9090 yansb/goserver:latest já consigo acessar minha porta 9090 e ver o hello world, depois disso posso dar um push dessa imagem para o meu dockerhub, agora ja posso criar um novo yaml com o essa imagem e fazer esse novo deployment

Se eu der um port-forward e for na porta 9090 já consigo ver o meu hello world

Load balancer

Agora com diversas replicas dos pods (10 com o GO e 10 nginx) temos um problema, como K8s vai saber para qual pod mandar a pessoa que está acessando a aplicação

Vamos criar um yaml para o service:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

Esse service vai pegar todos os pods com a label nginx e vai fazer o loadBalance baseado nessa seleção agora qualquer pessoa que internamente procurar pelo nginx-service ou pelo ip dele, vai chegar até um dos nginx.

O external ip está como pending pois meu computador não consegue gerar um IP externo, porem se estivesse rodando na aws, já poderíamos acessar esse ip externo e ter acesso ao ngnix

Tudo que fiz hoje com o kubernets está nesse repositório: https://github.com/Yansb/full-cycle-course/tree/master/kubernets

Configurando testes de integração no Nestjs com o Typeorm

Yan.ts — Thu, 16 Jun 2022 00:59:10 +0000

Teste de integração

Testes de integração como o nome já dá uma noção, são testes integrados com serviços externos, então por exemplo: em um teste unitário eu faço o mock do retorno do banco de dados para não precisar me conectar no banco de dados e fazer as queries. Enquanto nos testes de integração a ideia é subir um banco de dados separado só para teste e rodar e depois destruir esse banco.

Por que usar o teste de integração? tive essa necessidade principalmente pois os testes unitários não me deixaram confortável em garantir o pleno funcionamento da aplicação. Em alguns endpoints onde a função principal era fazer uma busca paginada por exemplo os testes unitários não bastavam pois o que mais importa nessa função é a querie que vai rodar no banco e as suas variações com filtros, e no teste unitário como eu que defino o retorno que a função vai ter não ia ter como testar isso.

Fazendo as configurações

Primeiro precisei configurar uma conexão 'mãe' que vai ser responsável por criar o banco de dados, e também configurar uma conexão secundaria que vai ser a conexão com o banco de testes

const masterConnection = new DataSource({
  type: 'postgres',

  database: process.env.DATABASE_NAME,
  host: process.env.DATABASE_HOST,
  password: process.env.DATABASE_PASSWORD,
  port: process.env.DATABASE_PORT
    ? parseInt(process.env.DATABASE_PORT, 10)
    : undefined,
  username: process.env.DATABASE_USERNAME,

  entities: ['dist/**/*.entity{.ts,.js}'],
  migrations: ['dist/src/db/migrations/*.js'],

  logging: false,
  name: 'master',
  migrationsRun: false,
});

const connection = new DataSource({
  ...(masterConnection.options as PostgresConnectionOptions),
  database: databaseName,
  migrationsRun: true,
  name: undefined,
});

e então fiz uma função para fazer a conexão e criar o banco de dados o banco de dados e gerei um nome aleatório para o banco

Não é obrigatório gerar um nome aleatório pois ainda vou apagar o banco de testes quando acabar com teste poderia também ser um nome definido como 'test_db' por exemplo

Nessa função fazemos a conexão que vai gerar o banco, geramos ele e retornamos a conexão com esse banco gerado

const databaseName = `test_${randomBytes(8).toString('hex')}`;


export async function databaseIntegrationSetup() {
  try {
    await masterConnection.initialize();
    await masterConnection.query(`CREATE DATABASE "${databaseName}"`);
  } catch (err) {
    process.stderr.write(
      `${err instanceof Error ? err.stack : JSON.stringify(err)}\n`,
    );
    process.exit(1);
  }

  return connection;
}

E uma função para fechar a conexão com o banco de dados, onde ele dropa o database criado para testes e fecha a conexão

export async function closeDatabaseIntegrationConnections() {
  try {
    await masterConnection.query(`DROP DATABASE "${databaseName}"`);
    await masterConnection.destroy();
  } catch (err) {
    process.stderr.write(
      `${err instanceof Error ? err.stack : JSON.stringify(err)}\n`,
    );
    process.exit(1);
  }
}

Inicializando o teste

describe('Integrations tests', () => {
  let app: INestApplication;
  jest.setTimeout(30000);

  beforeAll(async () => {
    const databaseConnection = await databaseIntegrationSetup();

    const module: TestingModule = await Test.createTestingModule({
      imports: [TypeOrmModule.forRoot(databaseConnection.options)],
    }).compile();

    app = module.createNestApplication();

    await app.init();
  });

  afterAll(async () => {
    await app.close();
    await closeDatabaseIntegrationConnections();
  });

  it('should be defined', async () => {
    expect(app).toBeDefined();
  });
});

Para definirmos o teste a gente basicamente vai pegar a conexão com o database que retornamos na primeira função e vamos declarar um modulo de testes e passar essa conexão para o modulo do Typeorm, e vamos inicializar o app nesse momento o teste já vai passar, porem depois de todos os testes rodarem precisamos fechar o app e chamar a função de fechar a conexão com o banco de dados e apagar esse banco criado só para testes