Instalando

É necessário que você já tenha o Docker instalado e rodando na sua máquina. Antes de começar o primeiro passo tenha certeza de que o Docker está rodando! Todas as instruções são via linha de comando e funcionam igualmente no PowerShell e no terminal do Linux (eu uso o Ubuntu 22.04).

O primeiro passo aqui é baixar a imagem do Elastic Search que atualmente está na 8.10.4. Vou usar o repositório de imagens do próprio Elastic pois no repositório do Docker a última versão é a 8.10.2 no dia de hoje e quero usar a última porquê sim. Você pode verificar outras versões aqui https://www.docker.elastic.co/r/elasticsearch.

docker pull docker.elastic.co/elasticsearch/elasticsearch:8.10.4

Se tudo der certo o resultado vai ser algo parecido com a imagem abaixo. No meu caso rodando no Ubuntu tive que rodar o comando com o sudo .

Podemos ver que na minha lista de imagens salvas localmente temos lá o Elastic Search na versão 8.10.4. Lembrando que no meu caso tive que adicionar o sudo .

docker image ls

Rodando

Até aqui todos os tutoriais foram bem. Alguns instalando diredo do repositório do Docker outros do repositório do ElasticSearch, mas daqui em diante é o que estava me confundindo um tanto, mas que vai ficar bem claro aqui.

docker run --name elasticboladao -p 9200:9200 -it -m 1GB docker.elastic.co/elasticsearch/elasticsearch:8.10.4

Deu erro?

Em alguns tutoriais o container subia e tudo funcionava magicamente bem, mas quando eu tentei encontrava alguns erros e que seguindo o tutorial me dava a entender de que eu estava fazendo alguma coisa errada. Seguindo o passo a passo até aqui dava um erro tanto rodando no Windows quanto rodando no Ubuntu, então se você rodou até aqui e se esbarrou com o erro node validation exception\n[1] bootstrap checks failed. You must address the points described in the following [1] lines before starting Elasticsearch.\nbootstrap check failure [1] of [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144] siga a recomendação abaixo, caso não tenha tido problema e o comando tenha rodado pode pular direto para o tópico “Testando”.

Significa que você precisa aumentar o valor do vm.max_map_count para o valor minimo de 262144, como recomendando pelo Elastic Search. No Ubuntu basta rodar o comando baixo.

sysctl -w vm.max_map_count=262144

Se você quiser deixar esse valor minimo definido como padrão no seu sistema sempre você só precisa editar o arquivo /etc/sysctl.conf e adicionar ao final dele o vm.max_map_count=262144.

Deu bom?

Se você não teve o problema acima, ou fez o ajuste necessário, depois de rodar o comando docker run e ao final da processo de inicialização do container você provavelmente vai ver essa tela na primeira.

Testando

Esse foi um outro ponto confuso em que cheguei depois de seguir os tutoriais. O pessoal simplesmente lançava na URL http://localhost:9200 e entrava com uma autenticação básica e conseguia fazer algumas consultas direto no navegador. No entanto temos ai duas possibilidade: No Windows, rodando o Docker Desktop com WSL ativado, não consegui acessar a URL diretamente pelo navegador. Só consegui fazer as requisições usando o Postman/Insomnia ou pelo CURL. No Ubuntu funcionou com https, mas não com o http e até aí tudo bem, pois não pretendo usar o navegador mesmo. Acessar via navegador era mais um teste simples para verificar se estava funcionando.

Depois de autenticar com o usuário elastic e com a senha que é gerada quando o elastic é iniciado (da uma olhada na imagem do Deu Bom?).

Insomnia/Postman

Tanto usando o Insomnia quanto o Postman talvez seja necessário desabilitar a validação de certificados SSL, ao menos tive que fazer isso, já que o certificado gerado localmente não é realmente reconhecido.

Antes de você realizar uma requisição você precisa configurar a autenticação do tipo basic e há duas formas de fazer isso a primeira é usando o recurso direto do Postman ou do Insomina que basicamente é ir na aba de Authorization, escolher a opção Basic preencher o usuário com o elastic e a senha com aquela que já sabemos.

A outra forma é configurar diretamente no Headers o cabeçalho Authorization com o usuário e senha separado por “:” encodados na base64. Eu particularmente prefiro essa pois já fica mais baixo nível e mais próximo da chamada que vou precisar fazer via código. Algo como elastic:O*ZMpUEhF*+5cHAYW3yR viraria ZWxhc3RpYzpPKlpNcFVFaEYqKzVjSEFZVzN5Ug==.

É isso, objetivo aqui foi alcançado que era deixar rodando o ElasticSearch com Docker. Fiquem a vontade pra tirar dúvidas dessa instalação ou mesmo outras coisas que tenha dito e não tenha ficado claro.

Pra fechar

Se você precisar gerar uma nova senha para o usuário elastic você pode em um outro terminal enviar um comando para essa troca.

docker exec -it elasticboladao bin/elasticsearch-reset-password -u elastic

Referências

https://www.elastic.co/guide/en/elasticsearch/reference/current/docker.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html

The post Rodando o Elastic Search no Docker appeared first on Pereira, Thiago Santos..

Para os apressados a solução é rodar o cron em foreground. Dessa forma ele segura o container e ele não morre de cara.

ENTRYPOINT ["cron", "-f"]

Para quem curte uma solução mais completa abaixo está o Dockerfile que usei para resolver essa tarefa. No container deveria haver dois scripts, o primeiro que consultava uma API e retornava uma lista contendo um GUID, data da ultima alteração e a periodicidade que esse GUID deveria ser chamado. O segundo script que era chamado pelo cron passando o GUID respeitando a periodicidade definida.

Assim o primeiro script, deveria acessar uma API a cada 15 minutos, verificar localmente se aqueles GUID recebidos já tinham seus respectivos arquivos cron gerados. A solução foi que para cada GUID recebido criariamos arquivos na pasta do cron.d no formato abaixo.

#/etc/cron.d/run_primeiro_script
*/15 * * * * root /app/primeiro_script.py

O segundo script precisa ser chamado dada uma periodicidade e passando um ID como parâmetro.

#/etc/cron.d/426c3f18-8f87-4ca7-98a9-aaa865ae46d1
*/5 * * * * root /app/segundo_script.py --id 426c3f18-8f87-4ca7-98a9-aaa865ae46d1

O Dockerfile ficou assim.

FROM ubuntu:23.04 AS base

WORKDIR /app
RUN apt-get update && apt-get install -y cron python3
RUN echo "*/15 * * * * root python3 /app/primeiro_script.py > /proc/1/fd/1 2>/proc/1/fd/2" > /etc/cron.d/run_primeiro_script

COPY . .

ENTRYPOINT ["cron", "-f"]

Eu ressalto que como a tarefa do cron é executado em um bash as mensagens da aplicação não saem no bash principal e como consequência não é possível ver essas mensagens no log. Por isso redirecionamos o stdout e o stderr do “primeiro_script.py” para o processo de PID 1 que é o comando executado pelo entrypoint.

Essa é uma solução interessante também para manter o log quando o cron executar scripts, programas e aplicações que tenham muita saída no stdout e que normalmente estivessem rodando em foreground seriam enviados para o log do pod.

The post Docker Cron appeared first on Pereira, Thiago Santos..