Jmeter (Jenkins + GitHub)
Tabela de conteúdos
avançado - This article is part of a series.
O que é Jenkins? #
Jenkins é um gerenciador de integração contínua baseado no projeto Hudson, iniciado em 2004 pela Sun Microsystems. No entanto, como todos sabemos, Sun Microsystems foi adquirido pela Oracle Corporation em 2010, então as direitos para Hudson foram reclamados por Oracle, e em janeiro de 2011, foi decidido mudar o nome para Jenkins, embora ambos os projetos continuem até hoje. Há muitas semelhanças entre esses dois ferramentas, mas a comunidade de Jenkins é muito maior. Alguns alternativos para gerenciadores de integração contínua incluem:
- Travis CI ( https://travis-ci.org/)
- Circle CI ( https://circleci.com/)
- Codeship ( https://codeship.com/)
Como Jenkins funciona? #
Basicamente com Jenkins você pode criar fluxos ou pilhas de pipelines com múltiplas etapas. Isso significa que ações (jobs) podem ser automatizadas, o que poderia ser conectada por etapas e submetida a condições específicas, como se as ações terminassem bem ou não. Por exemplo, se uma ação tiver um código de saída zero, isso indicaria que terminou corretamente; caso contrário, se o código de saída fosse diferente de zero, poderia indicar falhas na execução, construção ou compilação da ação. Portanto, você poderia parar ou interromper completamente a pilha ou fluxo.
Lembre-se de que existem muitas plugins que podem ser instaladas em Jenkins para integrar diversas canais de comunicação para alertar as pessoas envolvidas quando a pipe ou o fluxo está bloqueado por alguma razão. Dependendo do processo e da gestão dele, ele irá começar novamente desde o início ou continuar com erros, que é possível se houver tolerância para falhas.
O que é Github ? #
GitHub é uma plataforma distribuída e colaborativa para controle de versões do tipo Git, especificamente dirigida à gestão e administração de código-fonte. GitHub está baseado na estruturação Ruby on Rails e é escrito em linguagem Ruby. Em 2018, GitHub foi adquirido pela Microsoft e com isso várias empresas que hospedaram seus códigos-fonte no GitHub migraram para ferramentas semelhantes como:
Algo que vale a pena mencionar sobre GitHub, que contribuiu significativamente para sua popularidade, foi o fato de suportar um dos ataques DDoS (denial of service distribuído) mais grandes da história. No dia 28 de fevereiro de 2018, ele conseguiu lidar com até 135 terabits por segundo (Tbps) enviados através de 126.9 milhões de pacotes por segundo via um ataque vector do que parece ser de 100.000 servidores Memcached, e este foi contido graças à serviço Akamai Prolexic. Há suspeitas fortes de que a principal razão para o ataque foi para roubar o código-fonte de grandes empresas de software.
Como funciona o GitHub? #
O GitHub opera principalmente através de repositórios, cada um desses repositórios tendo sua própria página web no plataforma como também uma Wiki. Quando o repositório é criado, os arquivos são submetidos a ele usando as ordens básicas Git: git add, git commit e git push. Você pode consultar todas as ordens básicas de Git aqui: Ordens Básicas de Git. Isso é para versão do código. O programa também tem outras características como uma interface gráfica (GUI) disponível em plataformas Linux, MacOS e Windows, a plataforma GitHub.com, Wiki, Kanban e interações sociais, entre outros. O que nos interessa para esta publicação é criar um repositório público para nossa integração.
Como a integração de Jenkins e GitHub com JMeter funciona? #
A integração é simples; você apenas precisa criar uma cópia pública do nosso script JMeter em um repositório local no GitHub, para que Jenkins possa clonar este local e ter o versão desejada do script para iniciar a execução. A execução será realizada via o esquema distribuído master-slave, que pode ser sobre uma rede privada (local) ou pública. Os resultados serão salvos no espaço de trabalho de Jenkins para consulta posterior e também publicados como HTML através de um servidor Apache.
- Atualize nosso script JMeter (JMX) no GitHub.
- O projeto Jenkins solicita a cópia local deste repositório.
- GitHub permite clonar repositórios (também pode ser um repositório privado).
- Jenkins executa o JMeter (controller) em modo distribuído na máquina local.
- A máquina envia os resultados via RMI para a controller do servidor (Jenkins), e estes resultados são armazenados no workspace.
- Os resultados são publicados no diretório do Apache e compartilhados em formato HTML.
Por que Usar GitHub na Integração? #
O principal motivo para recomendar a utilização de um plataforma de controle de versões é evitar atualizar diretamente o script JMeter (JMX) no servidor Jenkins ou gerador de carga. Isso pode levar a erros, como colocar incorretamente um arquivo ou versão manualmente. Lembre-se que menos pontos de acesso significa maior confiança nas resultados.
Lembre-se de que o repositório usado também pode ser privado, mas para isso acontecer você precisará configurar credenciais de acesso ao repositório.
Por que Usar um Script Distribuído do JMeter? #
Eu fortemente recomendo evitar executar o teste na mesma máquina onde Jenkins está hospedada. Esta é uma prática muito popular e prejudicial; não preciso listar todas as razões por que isso é ruim, mas se houver dúvidas sobre esta publicação, consulte-a.
Sim, a publicação abrange configuração e ideia geral, então você pode substituir Jenkins por qualquer outro provedor de integração continuada, ou também trocar o GitHub por qualquer outra sistema de controle de versões.
O que precisamos? #
Precisamos de um Apache web server instalado que basicamente só roda algumas comandos; também precisa ter Jenkins instalado e configurado para podermos instalar manualmente a Integração Git. Também precisamos de um repositório Git onde nosso script JMeter será hospedado, se for público não há necessidade de instalação adicional; caso seja privado, você precisará instalar o Plugin de autenticação GitHub. Finalmente, instale e configure JMeter em modo distribuído no Jenkins (controle) e no nó (gerador de carga) usando as diretrizes mencionadas anteriormente.
Receita para cozinhar #
1 - Criar um Projeto #
Vamos criar um projeto aberto e configuraremos a repositório do GitHub para este exemplo. Para isso, usei o repositório JMeter_Script.
2.- Configure o projeto #
Vamos também configurar quatro parâmetros que ajustarão o número de usuários em simultâneo, tempo de ramp-up e duração das testes. Finalmente, introduziremos a IP do servidor remoto onde as testes serão executadas. Para realizar essa tarefa, você precisa seguir os seguintes publicações, dependendo da sua localização: se na rede privada ou na rede pública. Além disso, o script deve estar preparado para aceitar parâmetros como mostrado nesta publicação.
Comando de linha para executar o JMeter, já que a relatório é automaticamente gerado no final do teste na área de trabalho. Neste teste, o JMeter foi baixado e instalado dentro da controller Jenkins dentro da pasta JENKINS_HOME para evitar problemas de permissão.
Command for Jenkins Linux/Unix/MacOS
$JENKINS_HOME/JMeter/apache-jmeter-5.3/bin/jmeter.sh -n -t $WORKSPACE/JMeter_Script_Plugins.jmx -l $WORKSPACE/JMeter_Script_Plugins-$BUILD_NUMBER.jtl -Jthreads=$Threads -Jrampup=$RampUp -Jduration=$Duration -R $RemoteEngine -e -o $WORKSPACE/$BUILD_NUMBER
Command for Jenkins Windows
%JENKINS_HOME%/JMeter/apache-jmeter-5.3/bin/jmeter.bat -n -t %WORKSPACE%/JMeter_Script_Plugins.jmx -l %WORKSPACE%/JMeter_Script_Plugins-%BUILD_NUMBER%.jtl -Jthreads=%Threads% -Jrampup=%RampUp% -Jduration=%Duration% -R %RemoteEngine% -e -o %WORKSPACE%/%BUILD_NUMBER%
Comando para copiar os resultados do Workspace para o servidor Apache, tornando-os disponíveis para todos os usuários de qualquer localização. Deve-se notar que uma pasta de relatórios deve ser criada e as permissões devem ser concedidas ao usuário Jenkins para escrita nela.
cp -R $WORKSPACE/$BUILD_NUMBER /var/www/html/reports/
3. - Executar o projeto #
Execução do teste, para isso selecionaremos a opção “Construir com Parâmetros” (Build with Parameters) (Parâmetros pré-inseridos), esses parâmetros serão preenchidos com os valores definidos por nós. Ao executar, entraremos com os resultados da ID de Construção (neste caso #2) e revisaremos o output do “Saída do Console”. Após completar o teste, verificamos que os resultados estão armazenados na workspace.
O mais recomendado é gerar uma imagem do nó servidor para que ele possa ser parado quando não estiver executando o teste (para economizar custos) e quando necessário, podemos iniciar-o e obter a nova IP do nó servidor para atualizar o valor da variável antes de cada execução.
4.- Avaliação dos resultados #
Certifique-se de revisar o relatório através de um navegador na Web:
Conclusão #
Esta solução parece ser o melhor modo para executar sua testagem de carga e obter resultados que você possa compartilhar ou visualizar fora do Jenkins, já que se você precisar revisar gráficos específicos ou resultados, não precisa entrar no Jenkins para conseguir. Seria muito simples também obter as tabelas de resultado como poderíamos observar na última imagem web, então comparando e exportando as tabelas de resultados seria extremamente útil. Se tivéssemos múltiplos aplicativos, criariamos diretórios como /reportes/app1/ /reportes/app2/ etc., e facilmente acessaríamos centenas de resultados a partir de um navegador.
Devemos garantir que os arquivos de resultado do JTL da workspace (Workspace) sejam segurados e backupeados. Isso é muito importante porque se o servidor Jenkins falhar, é crucial ter backups dessas resultados valiosas históricas. Devem ser notados que esta oportunidade está ligada à segurança e exposição desses resultados. Não é recomendável sempre trabalhar com administradores gerenciando Jenkins, Git ou serviços web para reforçar a segurança e as permissões antes de exponer informações internas sensíveis ou externas.