pviana

Objetivo deste post é comentar um pouco sobre a minha recente experiência com um cluster de raspberry pi que montei aqui em casa no ano de 2020, ano de pandemia de covid-19 e também um ano bastante atípico para muitos. Montar o cluster foi um desafio enorme, o comercio no país atravessava momentos de restrições de funcionamento e falta de matéria prima e boa parte das peças do cluster foram compradas sob medida. A motivação inicial para montar o cluster foi ter novamente hardware suficiente para estudar. Por muito tempo o ambiente de estudos aqui em casa foi um virtualbox instalado no meu macbook. Tenho inclusive boas recordações de estudar vagrant para montar as VMs. Infelizmente fui assaltado e meu hardware passou a ser um raspberryPI3 e um laptop corporativo da empresa na qual trabalho. A ideia do cluster nasceu na sequência de quando eu decidi comprar mais raspberry, inclusive não posso negar que enquanto analisava os preços e condições, não resisti, comprei o rasp4 com 4GB de RA...

O HTTPie é um projeto de Jakub Roztocil, desenvolvido em Python, usando as bibliotecas Requests e Pygments , e está sob uma licença BSD. A ferramenta está disponível para instalação através do pip ou pode ser obtida no repositório Github do projeto. A proposta da ferramenta é ser um CLI(Command Line Interface) para servidores web mais humano, a sintaxe dos comandos são simples e o retorno por ex é colorido. Acredite, isso facilita muito a visualização de informações em momentos mais críticos em que você está com pressa. Inevitável não comparar com o cURL até porque os dois possuem recursos semelhante, quer ver um exemplo? Instale os dois na sua maquina e digite o seguinte:  curl -i -X PUT -H 'Content-Type:application/json' -d '{"blog":"pviana"}' http://httpbin.org/put   Agora vamos fazer o mesmo utilizando o HTTPie: http PUT http://httpbin.org/put blog=pviana   Ficou com preguiça? Pois bem o retorno dos dois comandos segue abaixo:   HTTP...

Logs são extremamente importantes para o correto funcionamento de um sistema, pois estão ali as informações necessárias para corrigir um problema ou para entender porque ocorreu uma determinada falha. Agora logs também possuem seus defeitos, afinal eles podem ser o responsáveis por encher uma partição raiz sem que você perceba, deixando assim o ambiente extramente lento e algumas vezes inutilizável causando os mais diversos problemas. Uma excelente opção de gerencia disso é o tradicional LogRotate . Com ele você indica o período de rotação do arquivo de log, pode determinar ainda o apagamento e se for o caso compressão, alias extensão da compressão também é possível configurar. Arquivo de configuração do log rotate é: /etc/logrotate.conf , o que devemos fazer é indicar o arquivo a ser monitorado e quais as métricas por ex: /var/log/messages { rotate 5 weekly postrotate /sbin/killall -HUP syslogd endscript }  Acima temos o arquivo messages (ou syslog em algumas distri...

Devpi é uma excelente opção para repositório pypi, claro não desmerecendo do Bandersnatch . A grande diferença entre os dois é que o Bandersnatch foi pensado para um ambiente totalmente offline. Quando o Bandersnatch é iniciado faz download de todos os pacotes disponíveis no repositório que foi previamente indicado no seu arquivo de configuração para um diretório local só então começa a servir. Enquanto que o Devpi trabalha com cache, ou seja, você também indica um repositório mestre e um diretório onde ele vai guardar os pacotes, mais o download acontecerá sob demanda. Isso sem falar que o Devpi também trabalha com replicação, quando for iniciar o servidor você pode indicar outro servidor devpi como master. As duas opções são boas a diferença está no jeito que cada uma funciona, acredito que a escolha ficará por conta do ambiente que você possui. Caso tenha uma maquina com acesso a internet então eu usaria o Devpi , até porque não imagino alguém precisando dos 180Gb de pacotes ...

Recentemente pesquisando sobre balanceamento de carga e também como melhorar performance do nginx, esbarrei com uma ferramenta simples e ao mesmo tempo muito útil. Para exemplificar melhor a situação vamos considerar uma instancia com 1GB de RAM, 2 CPUs e um Debian8, calma, não se prenda muito nesses valores. Primeiro passo foi entender o que poderia fazer a diferença no nginx.conf. Encontrei duas opções logo no inicio que chamaram muito atenção: worker_processes e worker_connections. Na documentação oficial do nginx existe uma recomendação de preencher o worker_processes com total de CPUs e no worker_connections o valor obtido através do resultado do comando: ulimit -n . Obs: Total de cpu pode ser obtido através do comando: cat /proc/cpuinfo |grep -i processor |wc -l Próximo passo foi encontrar uma ferramenta que fosse capaz de realizar um teste de performance, algo semelhante ao que o AB faz com o Apache. Afinal de contas, será que os valores indicados estão sendo levado...

Já parou para pensar que pode existir um gargalo na sua infraestrutura porque você tem muitos mil acessos e um único servidor web para atender a toda essa demanda? Se você compartilha desse cenário recomendo seguir a leitura desse post e considerar configurar um load balancer no seu NGINX . Sempre muito importante explicar um pouco do conceito, dessa vez para agilizar as coisas recorri a um site bastante conhecido - wikipedia - Balanceamento de carga ou Load balancer (em inglês), em rede de computadores, é uma técnica para distribuir a carga de trabalho uniformemente entre dois ou mais computadores, enlaces de rede, discos rígidos ou outros recursos, a fim de otimizar a utilização de recursos, maximizar o desempenho, minimizar o tempo de resposta e evitar sobrecarga. Utilizando múltiplos componentes com o balanceamento de carga, em vez de um único componente, pode aumentar a confiabilidade através da redundância. Importante ressaltar que o algorítimo padrão para func...

Algum tempo atrás precisei instalar algumas coisas em uma maquina que estava em ambiente de produção e fui surpreendido com a dificuldade, posso afirmar que foi tenso conseguir concluir a tarefa. Questionando a equipe descobri que tínhamos um repositório, mas que não estava atualizado e não atendia muito bem. Combinei de estudar a situação e resolver da melhora maneira possível. Pois bem, a ideia por trás desse post é usar um Ubuntu Server 14.04 como repositório para Python, CentOS e Ubuntu ao mesmo tempo, em outras palavras uma maquina servindo os três simultaneamente. Em um primeiro momento parece um pouco complexo ou até mesmo louco usar isso. Tenho certeza que após executar todos os passos a seguir vai perceber que é fácil levantar um ambiente desses. Repositorio pypi (Bandernatch) Precisamos do virtualenv para isolar a instalaçao do repositorio do python. # apt-get install python-virtualenv Crie um virtualenv com qualquer nome, optei por criar com o nome da aplicaç...

Algum tempo atrás escutei um amigo que foi ao Fisl desse ano falar que ficou impressionado com uma apresentação sobre fluentd. Ele até distribuiu o link com video da apresentação(que eu não achei tão boa assim, mas isso é um detalhe. hehehe). Para sorte desse tutorial comecei a pesquisar sobre a ferramenta antes de ver o video e foi assim que realmente me convenci que era boa. Fluentd é nada mais do que um coletor de dados, a ideia aqui é unificar a coleta para facilitar o entendimento depois. Percebi que a ferramenta mais conhecida nesse meio é o logstash, até encontrei alguns reviews comparando ele com o fluent. Não achei nada relevante, comum ler que o fluentd possui mais performance e o logstash tem uma interação melhor com sistemas operacionais Windows. O desenho acima indica exatamente o que vamos montar, fluentd encarregado de alimentar o elasticsearch com logs e o papel do Kibana nesse ambiente é apenas exibir informações contidas no elasticsearch de forma muito fácil com ...