terça-feira, 31 de janeiro de 2017



Você sempre quis saber o quanto de carga seu servidor Web aguenta? Sempre quis testar, garantir ou refutar a capacidade do seu host ou VPS? Sempre quis saber qual configuração do seu Apache ou NGINX funciona melhor para o seu tipo de serviço? Continue lendo este post e veja X ferramentas que podem te auxiliar no teste de carga do seu Site ou API.

Sempre que eu preciso utlizar um teste de carga em alguma parte dos meus projetos, eu utilizo bastante essas ferramentas, principalmente o ab pela simplicidade. Eu recomendo bastante os itens a seguir:

Apache Benchmark - Ab



O Apache Benchmark (vulgo ab) é um um cli para benchmark de web services muito poderoso. Pode automatizar numeros muito altos de requests, simular concorrência, conexões Keep Alive além de possuir suporte para REST como POST/PUT/GET e uma autenticação via HTTP básica. Ele é da Apache, porém pode ser utilizado para testar qualquer tipo de Web Service ou API, seja em Apache, NGINX, Node, Django e etc. Ele é simples e muito performático, mas pra testes que requerem sessão, cookies e etc, seu uso pode ser um pouco problemático.

Site do projeto: http://httpd.apache.org/docs/2.4/programs/ab.html

A Instalação do ApacheBench é simples. Está disponível dos repositórios da maioria das distribuições como o pacote de ferramentas adicionais do Apache.
 # apt-get install apache2-utils  
 # ab -kc 1000 -t 60 http://minhaapi.com  
 # ab -n 10000 -c 100 http://minhaapi.com  

Onde:
 - kc (Keep Connected) Simula uma conexão persistente  
 - t  Seta um tempo de timeout de Keep Alive da requisição  
 - n Um numero de conexões simultâneas   
 - c  Simula um numero de usuários concorrentes na aplicação   


HTTPerf

O HTTPerf é uma alternativa bacana ao Client do Apachebench. Igualmente poderosos e possui opções bem bacanas para customizar o load test do sistema. É um pouco mais verboso que o AB, mas atende igual.

Git do projeto: https://github.com/httperf/httperf

 # sudo apt-get install httperf  
 # httperf --server minhaapi.com --port 80 --num-conns 1000 --rate 1  
 # httperf --client=0/1 --server=minhaapi.com --port=2206 --uri=/login --send-buffer=4096 --recv-buffer=16384 --num-conns=8000 --num-calls=10  

Onde:
 -- server : Servidor requisitado   
 -- port: porta do servidor a ser requisitada   
 -- num-conns: numero de conexões no teste  
 -- rate: numero de conexões por segundo  
 -- uri: metodo requisitado da API  


Outras opções: 

CURL - Loader



Site: http://curl-loader.sourceforge.net/

JMeter


Site: http://jmeter.apache.org/







Toolbox Benchmark :: Ferramentas de Teste de Performance de Web Servers no Linux

sexta-feira, 27 de janeiro de 2017


O Gitlab é um gerenciador de Git como o Github, Bitbucket e vários outros, porém você pode instalá-lo e gerenciá-lo de um servidor próprio. Basicamente, você pode criar seu próprio servidor de Git privado em uma versão feita para a comunidade.
A documentação da ferramenta é bem completa, e existem várias opções de instalação. Você pode ter uma abordagem muito mais detalhada lá.

Site do projeto: https://about.gitlab.com/
Documentação do Gitlab: https://docs.gitlab.com/

Ubuntu 16.04:

Instalando as dependências:
 sudo apt-get install curl openssh-server ca-certificates postfix  

Instalando o Gitlab:
 curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash  
 sudo apt-get install gitlab-ce  


Debian 8:

Instalando as dependências:
 sudo apt-get install curl openssh-server ca-certificates postfix  

Instalando o Gitlab:
 curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash  
 sudo apt-get install gitlab-ce  


CentOS:

Instalando as dependências:
 sudo yum install curl policycoreutils openssh-server openssh-clients  
 sudo systemctl enable sshd  
 sudo systemctl start sshd  
 sudo yum install postfix  
 sudo systemctl enable postfix  
 sudo systemctl start postfix  
 sudo firewall-cmd --permanent --add-service=http  
 sudo systemctl reload firewalld  

Instalando o Gitlab:
 curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash  
 sudo yum install gitlab-ce  


Configurando e Startando o servidor do Gitlab


Agora temos que editar o arquivo de configuração do gitlab para definir a URL de acesso ao sistema. Se você tiver um domínio apontado, utilize o mesmo. Ou pode testar com localhost, 0.0.0.0 ou o IP cru da máquina em caso de um servidor restrito internamente. O parâmetro que precisa ser alterado é o external_url
 vim /etc/gitlab/gitlab.rb  



Após a instalação, o próprio instalador vai te dar os próximos passos a serem seguidos. Basicamente você vai ter que rodar a primeira configuração do projeto que vai alinhas as dependências do PostgreSQL, Redis e etc. 


 sudo gitlab-ctl reconfigure  


Você pode acessar o Gitlab via URL. O Servidor ficará disponível na porta 80 do host. Ou seja, basta acessar http://ip.do.host/

Durante o primeiro acesso você deverá informar uma senha de administrador e o usuário padrão é o root. Você pode alterar isso quando quiser.



Troubleshoot : ruby_block[supervise_redis_sleep] action run (travado) 

Caso sua instalação fique travada na action supervise_redis_sleep, segue o troubleshoot
Link da Issue: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/430
 /opt/gitlab/embedded/bin/runsvdir-start &   
 gitlab-ctl reconfigure  


Espero ter ajudado :)

Gitlab :: Criando seu próprio servidor de Git privado

quarta-feira, 25 de janeiro de 2017



Esse vai ser mais um presente do meu repositório de Stacks Docker, que eu tenho a meta de passar pra cá até o final do ano. Meio tenso, porque meus Labs lá estão crescendo muito em comparação a minha frequência de posts aqui (rs). Dessa vez é a vez do PHP ser containerizado aqui. Basicamente esta Stack segue uma arquitetura de PHP FPM totalmente separada do Webserver, que no caso da vez, será o Nginx. De leva, vamos criar um container de MySQL persistente para o nosso projeto.

Essa Stack se assemelha mais a um ambiente de desenvolvimento do que um de QA ou produção, porque eu gosto de mapear os arquivos de configuração dinamicamente para dentro dos containers, pra poder ter um controle maior durante o desenvolvimento, alterar configuração, testar e etc. Caso queira levar isso para produção, te aconselho a dar um ADD ou COPY nos arquivos de configuração do Nginx, FPM para dentro dos containers durante o Build.

Link do projeto: https://github.com/msfidelis/CintoDeUtilidadesDocker/tree/master/Nginx-PHP7-FPM

Basicamente, o esquema de diretórios é o abaixo.



docker-compose.yml

Nosso Docker Compose é bem simples, e basicamente se consiste em 3 serviços. O nginx que vai atender nossa porta 80, o fpm que será nosso servidor de PHP e o mysql que vai atender nosso banco de dados. Sem segredo. 




PHP7fpm/Dockerfile

Essa é a Dockerfile do serviço do PHP-FPM. Nela eu não fui muito simplista. Já utilizei uma imagem prontad o php7.0-fpm e instalei algumas dependências que eu uso bastante nos meus projetos em questão de performance, como o Opcache, APCU e algumas outras bibliotecas auxiliares. 



Nginx/Dockerfile

Essa é a Dockerfile do nosso Nginx. Também sem muito segredo. Basicamente é só uma receita de um Debian com o Nginx instalado. Eu procuro não mapear diretamente os arquivos de configuração para dentro dos containers em ambiente de desenvolvimento, só em produção, só pra poder ter um controle maior em questão de mudar parâmetros, testar configurações e etc. Mas caso você não sinta essa necessidade, é só copiar os arquivos do Nginx para dentro do build sem problemas. 



Nginx/nginx.conf

A configuração padrão do Nginx também não tem o que esconder. Configura um servidor padrão. Habilito o gzip para caso eu queira fornecer algumas páginas e conteúdos estáticos. E etc. Aqui você customiza de acordo com a sua necessidade. 



Nginx/app.vhost

Esse é as configurações do nosso virtualhost do projeto. Ele está como Default, ou seja, vai atender qualquer requisição sem a necessidade de um virtualhost específico. Aqui é importante notar o link para o serviço de fpm que vai funcionar como nosso servidor de PHP. Caso sinta a necessidade de alterar o nome do serviço, não pode esquecer de alterar aqui também para não dar problema. 



Agora pra rodar, o mesmo esquema :)
 # docker-compose build   
 # docker-compose up   





Docker :: Containerizando PHP7-FPM, Nginx e MySQL sem complicações.

quarta-feira, 4 de janeiro de 2017



Depois de algum tempo, cá estou para retomar a cobertura do meu repositório Cinto de Utilidades Docker, que está com o ritmo de crescimento muito maior do que os das postagens (rs). Hoje vamos abordar duas das maiores duvidas de quem começa a utilizar containers em ambiente de Dev e Prod: Primeiro: Como persistir dados dos bancos de dados que rodam em containers e  Segundo: como criar meu banco de dados sempre que eu instalar meu ambiente.

Confira os arquivos do ambiente

Estrutura de diretórios

Neste projeto iremos utilizar dois níveis de diretórios.
No primeiro vamos ter nosso docker-compose e no segundo nível, na pasta /Dumper teremos todas as dependências do nosso restore do MySQL, incluindo nossa Dockerfile e nosso arquivo SQL.

  ~/W/CintoDeUtilidadesDocker   master  MySQL-MySQLRestore  tree .     qua 04 jan 2017 08:13:26 BRST  
 .  
 ├── docker-compose.yml  
 └── Dumper  
   ├── Dockerfile  
   └── dump.sql  
   
 1 directory, 3 files  
   



docker-compose.yml

Nosso arquivo docker-compose.yml vai ter somente dois serviços. 
O primeiro é uma imagem oficial do MySQL na versão 5.7. Vamos expor a porta 3306 e setar a senha do root na variável MYSQL_ROOT_PASSWORD. Para garantir persistência nos dados, vamos fazer com que o Docker crie uma pasta ./data dentro do diretório do projeto e mapeie para dentro da pasta /var/lib/mysql, a pasta onde o MySQL guarda todos os dados e metadados dos bancos e tabelas. Assim sempre que ele realizar alguma modificação, isso será mapeado para fora, e quando ligarmos outra instância, ele vai mapear o mesmo volume para dentro com as mesmas configurações e dados da anterior. Com isso garantimos uma persistência no MySQL. 

Em segundo, vamos ter um container temporário chamado dump. 
Vamos setar a pasta de build para a pasta Dumper/ e mapear a mesma para dentro da pasta /var/db do container. Essa pasta vai servir para armazenar o arquivo SQL que vamos restaurar na base. 

Na opção command, vamos criar um mini bashscript. Vamos dar um tempinho com o sleep para garantir que toda a inicialização do MySQL foi completada e em seguida restaurar o banco na base. 

 version: "2" 
 services:  
  mysql:  
   image: mysql:5.7  
   restart: never  
   ports:  
    - "3306:3306"  
   environment:  
    - MYSQL_ROOT_PASSWORD=root  
    - MYSQL_DATABASE=mydatabase  
   volumes:  
    - ./data/db:/var/lib/mysql  
   
  dump:  
   build: Dumper/  
   volumes:  
    - ./Dumper/:/var/db/  
   command: sh -c "sleep 20 && /usr/bin/mysql -h mysql -uroot -proot < /var/db/dump.sql"  
   depends_on:  
    - mysql  
   


Dumper/Dockerfile

Nosso Dockerfile será ridiculamente simples. Iremos utilizar a versão mais nova do Alpine Linux e em seguida instalar o MySQL-Client. Ele vai realizar uma unica ação e morrer, então não adianta enfeitar muito o ciclo de vida do mesmo. 

 FROM alpine:latest  
 RUN apk add --no-cache mysql-client  

Dumper/dump.sql

O Arquivo dump.sql irá conter todo o conteúdo do seu banco de dados. Aqui fica por sua conta, porém é altamente recomendável você usar as validações IF NOT EXISTS e IF EXISTS em todos os lugares para garantir erros na hora do restore. 
  
 CREATE DATABASE IF NOT EXISTS mydatabase;  
 USE mydatabase;  
   
 CREATE TABLE IF NOT EXISTS mytable (  
  id INT(11) PRIMARY KEY AUTO_INCREMENT,  
  descricao VARCHAR(50)  
 );  
   


Subindo o Container

Vamos inicializar o composer e ver a mágica acontecer. Ele vai iniciar o MySQL, subir nosso dumper que irá restaurar os dados e morrer. Logo após o termino desse processo teremos nosso bando de dados restaurado no MySQL.
 docker-compose up   



:)


Docker :: Restaurando Dumps em Containers MySQL Persistentes.

domingo, 20 de novembro de 2016



Esse post vai ser mais um exemplar explicativo do meu repositório Cinto de Utilidades Docker. Basicamente vamos utilizar o Docker para construir um ambiente de uma API REST utilizando NodeJS e MongoDB, com exemplos práticos de praticamente tudo que você precisa para construir um ambiente completo para seu Backend em Node e Mongo. Basicamente nosso diretório irá conter uma pasta app, onde iremos deixar o código da nossa API, uma Dockerfile para o container do Node e um docker-compose.yml que vai orquestrar nossa aplicação. Basicamente, a estrutura de diretório é esta:



Link dos Exemplos no Github

Node 

Vamos containerizar uma API completa. Nesta caso, no diretório do projeto, vamos criar a pasta app, dentro dela devem existir dois arquivos, um package.json que irá guardar todos os componentes que iremos utilizar na nossa aplicação e o arquivo app.js, que irá conter todo o código da nossa aplicação necessariamente.

./app/app.js

Este é o Código da API que vamos trabalhar com o Docker. Pode parecer grande demais para um exemplo, mas é uma forma de mostrar o funcionamento de ponta a ponta de um código no Docker. 
Basicmente é uma API Rest bem simples com um schema de tasklist já definido que vai gerenciar as informações do MongoDB. Usei essa API na POC do meu TCC na FATEC Itu. Pode ver aqui.

./app/package.json


Aqui iremos satisfazer todas as dependências do nosso projeto. Sem segredo por aqui.


Docker 

Dockerfile 

Veremos a Dockerfile, neste exemplo estaremos baixando uma máquina já preparada com o Node direto do Dockerhub. Pegaremos a versão Latest, que atualmente faz referência a versão 7.1 do Node, copiaremos o arquivo package.json do nosso projeto e irá instalar todas as dependências do mesmo globalmente, e vamos expor a porta 8080 para construção da nossa API e a porta 5858 para debug.
 FROM node:latest  
   
 RUN mkdir -p /usr/src/app  
 RUN npm install nodemon -g  
   
 WORKDIR /usr/src/app  
 COPY app/package.json /usr/src/app/package.json  
 RUN npm install -g  
   
 EXPOSE 8080  
 EXPOSE 5858  
   
 CMD ["npm", "start"]  


Docker Compose

Usaremos o arquivo docker-compose.yml para baixar a versão 3.0 do Mongo, e liberar a porta 27017 do mesmo para a nossa máquina. Em seguida vamos criar/mapear o diretório data, que se não existir será criada no diretório do projeto para pasta /data/db de dentro do container. Essa pasta irá gravar o conteúdo das collections do Mongo, e mapeando para um diretório externo, irá garantir a persistência dos dados do mesmo.
Em seguida iremos buildar nosso Dockerfile, mandando nosso local de build para a pasta local(.), customizando o comando de execução do container para satisfazer as dependências do projeto com o npm install e executar o nodeamon no nosso arquivo servidor do Node.
A pasta que vai ser mapeada para dentro do container é pasta app, que contém todo o nosso projeto do Node. Por ultimo, linkamos o serviço da nossa aplicação para se comunicar com o container do Mongo.
 mongo:  
  image: mongo:3.0.4  
  ports:  
   - "27017:27017"  
  volumes:  
   - './data:/data/db'  
 application:  
  build: .  
  command: bash -c "npm install; nodemon app.js --color=always"  
  ports:  
   - "8080:8080"  
   - "5858:5858"  
  volumes:  
   - ./app:/usr/src/app  
  links:  
   - mongo  

Testando 

Para buildar nosso projeto, iremos utilizar o Docker Compose como de costume. 
 # docker-compose build   
 # docker-compose up  

Agora com ajuda do Postman, ou qualquer cliente REST, podemos fazer requisições para todos os Endpoints da API, pra ver funcionando. Por exemplo, uma requisição POST para o endpoit /api/add com o conteúdo decricacao e concluido por POST, Ou pegar todos registros por GET via /api/all. Exemplificando, o comportamento é esse, mas você pode explorar todos os métodos da API pra ver que funciona. ;)


 Espero ter ajudado ;)


Docker :: Containerizando o NodeJS e o MongoDB de forma rápida

terça-feira, 15 de novembro de 2016


Criando um container para execução de Crontabs 

Neste exemplo vou estar passando um cookbook de como criar um Container Docker responsável por executar crontabs específicas no Linux. Esta é um exemplo bem cru, você deve customizar os arquivos de exemplo e configuração com as dependências e comandos para atender a sua necessidade. Estaremos utilizando um container base rodando Ubuntu 16.04, mas as crontabs são universais pra praticamente todo sistema Linux, então você pode selecionar qual distribuição preferir ajustando os parâmetros para mesma. 

Você deverá criar uma estrutura de diretórios similar a abaixo, onde deve existir uma pasta chamada "crontabs" que vai ser mapeada como um volume para dentro da pasta de configurações do Cron. Nesta pasta iremos guardar os arquivos texto que vão ter as crontabs escritas. Mapeie mais volumes para adicionar seus scripts a vontade, para o exemplo estarei adicionado uma pasta "scripts".

Esse exemplo pode ser adaptado para montar servidores de cron, que requisita URL's, realiza backups, consome ou atualiza API's e etc. Existem N possibilidades. 



Dockerfile 

Para subir o container, irei utilizar o Ubuntu 16.04. Mas como foi dito, customize como preferir :D.

 FROM ubuntu:16.04
 MAINTAINER 

 RUN touch /var/log/cron.log

 RUN apt-get update \
     && apt-get -y install cron

 CMD ["cron && tail -f /var/log/cron.log"]

docker-compose.yml

Agora vamos orquestrar nosso container da melhor forma possível. De forma com que ele sempre inicie junto com o sistema. Vamos buildar nosso projeto utilizando o docker-compose. 
 version: '2'
services:
  crontab:
    build: .
    volumes:
      - ./crontabs:/etc/cron.d
      - ./scripts:/var/scripts

Crie um pasta chamada crontabs dentro da pasta do projeto. E dentro crie um arquivo qualquer. Esse arquivo será utilizado para fazer o apontamento das crontabs.

crontab/crontabs

A crontab de exemplo é essa abaixo. Basicamente roda dois crons a cada minuto. Uma crontab direta e um script de exemplo. 
 * * * * * root echo "Exemplo de Comando" >> /var/log/cron.log 2>&1  
 * * * * * root chmod +x /var/scripts -R ; /var/scripts/exemplo.sh >> /var/log/cron.log 2>&1  

scripts/exemplo.sh 

 #!/bin/bash  
 uptime;  
 echo "Exemplo de Script"  


Rodando o Container 

Dentro da pasta do projeto, vamos iniciar o docker-compose build e em seguida um up para iniciar o processo dos containers.
 # docker-compose build   

Em seguida, vamos subir o projeto com o up. Utilize a opção -d para rodar em segundo plano:
 # docker-compose up 


Liberei todos os arquivos de configuração neste link do Git. Estou fazendo um repositório com os meus ambientes lá.

Vou começar a postar algum material sobre Docker. Assunto bastante presente nos meus dias de DevOps e inclusive do meu TCC. Espero ter ajudado :)

Links de ajuda: 




Docker :: Criando um Container para Execução de Crontabs

 
Nanoshots | Open Source Security, Linux e Tutoriais © 2015 - Designed by Templateism.com