Running kong in DB-LESS mode on digital ocean app plataform.
Categorias
O que é o Redis?
Redis significa REmote DIctionary Server, e é uma solução distribuída de armazenamento de dados muito popular em sistemas desenvolvidos nos últimos tempos. Os dados são armazenados na forma de chave-valor.
O Redis é extremamente rápido, tanto para escrita como para leitura, graças ao fato de armazenar seus dados em memória RAM.
Com configurações adicionais, os dados podem ser persistidos em disco, mas tira um pouco da principal característica do REDIS, que é a velocidade.
Tipos de Dados
Ao contrário de datastores de chave-valor simples, que oferecem estruturas de dados limitadas, o Redis oferece uma grande variedade de estruturas de dados para atender aos requisitos dos aplicativos. Os tipos de dados do Redis incluem:
- Strings – dados em texto ou binários com tamanho de até 512 MB
- Listas – uma coleção de strings na ordem em que foram adicionadas
- Conjuntos – uma coleção não ordenada de strings com o recurso de executar operações de intersecção, união e diferente com outros tipos de conjuntos
- Conjuntos ordenados – conjuntos ordenados por um valor
- Hashes – uma estrutura de dados para armazenar uma lista de campos e valores
- Bitmaps – um tipo de dados que oferece operações com bits
- HyperLogLogs – uma estrutura de dados probabilística para estimar os dados únicos em um conjunto de dados
Conforme seu projeto for crescendo, mais microsserviços surgirão e consequentemente mais rotas, services, plugins e etc serão necessários no kong. Ao mesmo tempo cresce a necessidade da gestão simples e unificada dessas configurações.
O decK fornece uma opção para configurações declarativas (YAML e JSON). Através de um yaml é possível declarar todas as rotas, services, plugins e até mesmo os certificados SSL.
Versionando esse yaml, conseguiremos saber exatamente quem fez a configuração. “Jogando” o yaml num pipeline de CI/CD, conseguiremos fechar esse fluxo de deploy automático das configurações do kong.
Veja na imagem abaixo um exemplo de YAML com declaração do service com o nome mockbin
Instalação
Você pode instalar o deck no mac, linux ou windows, mas aqui vamos rodá-lo num container docker
docker run kong/deck help
Em nossos testes o kong está rodando num container e o kong admin respondendo em http://kong:8001/
A rede do kong em teste chama-se “network-microservicos”
Deck Ping
Testando conexão com o kong admin. Repare que passei o parametro –network e o parametro –kong-addr. Assim consigo fazer com que o deck converse com o kong admin que esta em outra rede. Caso não utilize –kong-addr, ele chamará o endereço http://localhost:8001
docker run --rm \
--network=network-microservicos \
kong/deck \
--kong-addr=http://kong:8001 \
ping
Exportando sua configuração atual com o comando DUMP
Caso você ja tenha várias configurações no kong e queira jogar as mesmas para dentro de um arquivo yaml, utilize o comando a seguir para exporta-las e salvar no caminho deck/kong.yaml
docker run --rm --network=network-microservicos kong/deck --kong-addr=http://kong:8001 dump --output-file - > deck/kong.yaml
Deck Diff
Antes de aplicar as configurações, você pode verificar a diferença entre as configurações do seu .yaml e as configurações que já estão aplicadas no kong. Uma espécie de dry-mode.
docker run --rm \
--network=network-microservicos \
-v /home/onovaes/Documents/Sites/dothnews/microservicos/kong_konga/deck/:/deck/ \
kong/deck \
--kong-addr=http://kong:8001 \
diff -s deck/kong.yaml
Deck Sync
Esse é o principal comando e faz a sincronização do seu arquivo yaml local com o kong admin
docker run --rm \
--network=network-microservicos \
-v /home/onovaes/Documents/Sites/dothnews/microservicos/kong_konga/deck/:/deck/ \
kong/deck \
--kong-addr=http://kong:8001 \
sync -s deck/kong.yaml
Múltiplos YAML
Você pode também declarar vários arquivos .yaml dentro de um diretório e aplicar as configurações com o seguinte comando.
No exemplo a seguir todos os yaml estão dentro da pasta deck.
docker run --rm \
--network=network-microservicos \
-v /home/onovaes/Documents/Sites/dothnews/microservicos/kong_konga/deck/:/deck/ \
kong/deck \
--kong-addr=http://kong:8001 \
sync -s deck/
Comandos Disponíveis
Aqui é um CTRL C + CTRL V do manual! =D
convert Convert files in one format to another format
diff Diff the current entities in Kong with the one on disks
dump Export Kong configuration to a file
help Help about any command
konnect Configuration tool for Konnect (in alpha)
ping Verify connectivity with Kong
reset Reset deletes all entities in Kong
sync Sync performs operations to get Kong’s configuration to match the state file
validate Validate the state file
version Print the version of decK
Flags:
–analytics share anonymized data to help improve decK (default true)
—ca-cert string Custom CA certificate to use to verify Kong’s Admin TLS certificate.
This value can also be set using DECK_CA_CERT environment variable.
—config string config file (default is $HOME/.deck.yaml)
–headers strings HTTP Headers(key:value) to inject in all requests to Kong’s Admin API.
This flag can be specified multiple times to inject multiple headers.
-h, –help help for deck
–kong-addr string HTTP Address of Kong’s Admin API.
This value can also be set using DECK_KONG_ADDR
environment variable. (default “http://localhost:8001”)
–konnect-addr string address of the Konnect endpoint (default “https://konnect.konghq.com”)
–konnect-email string Email address associated with your Konnect account
–konnect-password string Password associated with your Konnect account, this takes precedence over –konnect-password-file flag
–konnect-password-file string File containing password to your Konnect account
–no-color disable colorized output
–skip-workspace-crud Skip API calls related to Workspaces (Kong Enterprise only)
–tls-server-name string Name to use to verify the hostname in Kong’s Admin TLS certificate.
This value can also be set using DECK_TLS_SERVER_NAME environment variable.
–tls-skip-verify Disable verification of Kong’s Admin TLS certificate.
This value can also be set using DECK_TLS_SKIP_VERIFY environment variable.
–verbose int Enable verbose verbose logging levels
Setting this value to 2 outputs all HTTP requests/responses
between decK and Kong.
O wrk é uma ferramenta opensource (GitHub) que possibilita a execução completa de testes de stress. (teste de carga)
Costumo usar ele para ver o número de requisições por segundo que a aplicação aguenta e pra isso vamos rodar o wrk dentro de um container docker. Para isso vamos usar a imagem wg/wrk.
O Kubernetes é uma ferramenta open source usada para automação e orquestração de containers Linux.
O Pod é a unidade básica de trabalho do Kubernetes; ele especifica um único contêiner ou um grupo de contêineres que se comunicam e são escalonados em conjunto.
Um Deployment é um recurso de alto nível do Kubernetes que gerencia Pods de maneira declarativa, implantando, escalonando, atualizando e reiniciando os Pods quando for necessário.
Um Service é o equivalente do Kubernetes a um balanceador de carga ou proxy, roteando tráfego para seus Pods correspondentes por meio de um endereço IP ou nome de DNS único, conhecido e durável.
O escalonador (scheduler) do Kubernetes procura um Pod que ainda não esteja executando em nenhum nó, encontra um nó apropriado para ele e instrui o kubelet nesse nó a executar o Pod.
Recursos como Deployments são representados por registros no banco de dados interno do Kubernetes Externamente, esses recursos podem ser representados por arquivos-texto (conhecidos como manifestos) em formato YAML. O manifesto é uma declaração do estado desejado para o recurso.
O kubectl é a ferramenta principal para interagir com o Kubernetes, permitindo-lhe aplicar manifestos, consultar recursos, fazer alterações, remover recursos e executar várias outras tarefas.
O Helm é um gerenciador de pacotes para Kubernetes. Ele simplifica a configuração e a implantação de aplicações Kubernetes, permitindo-lhe utilizar um único conjunto de valores (por exemplo, o nome da aplicação ou a porta a ser ouvida) e um conjunto de templates para gerar arquivos YAML para o Kubernetes, em vez de exigir que você mesmo mantenha os arquivos YAML brutos.
Fonte: Devops antivo de nuvem com kubernetes (Editora Novatec)
Categorias
O Kernel Ring Buffer do Linux
O kernel ring buffer é um espaço de memória que armazena as mensagens emitidas diretamente pelo kernel do linux, inclusive durante a inicialização, mesmo que estas tenham sido ocultadas por alguma tela ou animação de carregamento.
O kernel ring pode ser consultado com o comando dmesg.
Em sistemas que utilizam o systemd, também pode ser usado o comando journalctl com a opção, -b , –boot, k ou –dmesg
O kernel ring buffer é zerado que o sistema é reniciado, mas caso vc queira zerar por conta própria, utilize o comando dmesg –clear
As mensagens emitidas pelo sistema operacional são armazenadas em /var/log/
Caso algum erro impeça o sistema de carregar, você pode bootar seu computador com um outro sistema operacional via USB e analisar as mensagens registradas em /var/log/ para identificar o problema e possíveis soluções.
A tag é apenas uma marca, em geral, em um branch específico que marca uma situação em um determinado momento.
Listar as tags existentes no Git é simples. Basta digitar git tag (com opcional -l ou –list):
git tag
Adicionando uma tag localmente
git tag -a 5.1.4 -m "Adicionando tag de versão"
Por padrão, o comando *git push* não transfere tags para servidores remotos. Você terá que explicitamente enviar tags para um servidor compartilhado depois de criá-las.
git push origin 5.1.4
Vejas algumas estratégias para voltar a versão anterior no GIT. (desfazer commit errado)
git checkout
Utilizando o comando git checkout, podemos dar checkout no commit anterior, ex a1e8fb5, colocando o repositório em um estado antes do commit problemático acontecer.
git checkout a1e8fb5
Ao dar checkout em um commit específico, você colocará o repo em um estado “HEAD desvinculado (detached)”. Isso quer dizer que você não está mais trabalhando em nenhuma ramificação (branch).
Em um estado desvinculado, qualquer novo commit feito ficará órfão quando você mudar ramificações de volta a uma ramificação estabelecida. Commits órfãos serão excluídos pelo coletor de lixo do Git. O coletor de lixo executa em um intervalo configurado e destrói permanentemente commits órfãos. Para evitar que commits órfãos sejam coletados como lixo, precisamos garantir que estamos em uma ramificação.
git revert
Vamos supor que estejamos de volta ao nosso exemplo de histórico de commit original. O histórico que inclui o commit 872fa7e. Desta vez, vamos tentar reverter um “desfazer”. Se executarmos git revert HEAD, o Git criará um novo commit com o inverso do último commit. Isso adiciona um novo commit ao histórico de ramificação atual e agora o faz parecer assim:
git revert fadf87e
git reset
O git reset é um comando extenso com vários usos e funções. Se executarmos o git reset –hard a1e8fb5, o histórico de commit é redefinido para aquele commit específico.
A saída de log mostra que as confirmações e2f9a78 e 872fa7e não existem mais no histórico de confirmação. Neste ponto, podemos continuar trabalhando e criando novos commits como se os commits ‘problemáticos’ nunca tivessem acontecido.
Esse método de desfazer alterações tem o efeito mais limpo no histórico. Fazer uma redefinição é ótimo para alterações locais, no entanto, adiciona complicações ao trabalhar com um repositório remoto compartilhado. Se tivermos um repositório remoto compartilhado que tenha o 872fa7e commit empurrado para ele, e tentarmos forçar o push de uma ramificação onde redefinimos o histórico, o Git irá detectar isso e lançar um erro. O Git assumirá que a ramificação que está sendo enviada não está atualizada devido à falta de commits. Nestes cenários, git revert deve ser o método de desfazer preferido.
O que é o netstat?
O comando netstat mostra informações sobre as conexões de rede, tabelas de roteamento e estatísticas da utilização da interface na rede.
Comandos Úteis
Listar todos os endereços IP conectados ao seu servidor ordenando pelo número máximo de conexões.
Este comando pode ser útil para detectar se o servidor está sob ataque, ou recebendo conexões demasiadas vindas de um mesmo ip
netstat -tn 2>/dev/null | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
Saída do comando
Categorias
Containers úteis e de rápida execução
Fiz esse post para armazenar alguns container de docker que são úteis dia a dia. A ideia desse post é somente registrar containers que podem ser executados diretamente com docke run. Sem docker-compose por aqui 😀
Simples apache webserver com php7.4 e a APACHE rodando no docker
$docker run -d -p 80:80 -v ~/Documents/meu_site/:/var/www/html php:7.4-apache
Container padrão do bitbucket pipeline
Mais informações sobre as imagens do bitbucket pipeline https://support.atlassian.com/bitbucket-cloud/docs/use-docker-images-as-build-environments/
$docker run -tid atlassian/default-image:2
Gabriel Novaes 