Série Continuous Integration: Reiniciando Jenkins sem reiniciar o servidor

Olá Pessoal,

No post de hoje vamos ver como reiniciar o Jenkins sem reiniciar o servidor pelo painel de controle. Parece algo que deveria ser simples, ou seja, um simples botão resolveria a situação. Mas não temos esse cara no painel do Jenkins. Então, como fazer?

http://seuservidor:porta/jenkins/restart

jenkinsrestartask

Se tiver local:

http://localhost:8080/jenkins/restart

 

jenkinsrestarting

 

O Jenkins vai perguntar se realmente deseja reiniciar o servidor, caso deseje clique no botão “OK” e aguarde.

Simples, não?

Abraços.

Série Continuous Integration: Deploy Automatizando Jenkins TomCat

Olá Pessoal,

No post de hoje vamos ver como fazer um deploy automatizado usando o Jenkins. Como assim? Vamos entender a seguir.

Lets go…

Entendendo o contexto

Não é muito difícil encontrar algum programador que tenha algum dia trabalhado em um projeto onde o deploy da aplicação era feito manualmente, ou seja, gerar o .war localmente e copiar para o servidor remoto  via FTP, ssh etc. E sabemos o quanto é demorado fazer isso por mais que tenhamos uma boa conexão de internet já que o .war tende a aumentar à medida que nosso projeto vai evoluindo e permanecer fazendo isso manualmente tende a demorar mais ainda o tempo de cópia do .war para um ambiente remoto. Já fiz muito isso e em alguns projetos já levei 30min esperando o .war ser copiado. E quando vejo, a alteração que acabei de fazer não foi junto naquele .war porque fiz o build antes de ter salvo a alteração. O que fazer? Build e aguardar por mais 30min. E ai já foi 1hr do seu dia fazendo algo operacional e que custa caro.

Deploy Automatizado /Delivery Continuous

É ai que entra o deploy automatizado. No jenkis, além de oferecer o build automatizado, há suporte através de plugin para que possamos pegar o artefato (.war/ear) gerado no build e colocar em um servidor remoto (jetty, tomcat, glasshfish etc) de maneira automatizada, ou seja, quem vai copiar e colar o arquivo será a própria ferramenta e certamente será mais rápido que copiar da sua máquina local para o  servidor remoto. E outra coisa, tudo isso fazendo hotdeploy, ou seja, não é preciso parar o Server para colocar .war, mas é recomendado fazer quando a copia .war for muito grande, e se ela não termina antes do tomcat, jetty etc verificar se algo mudou, o arquivo será corrompido. E o que acontece com sua aplicação? Down. E teremos que subir manualmente. Claro que tudo depende do seu ambiente; se é de DEV não tem problema fazer hotdeploy, mas se for um ambiente de PROD, você arriscaria fazer um hotdeploy? A resposta seria: depende. Normalmente não vamos querer fazer uma release para PROD no horário comercial ou de mais acesso da aplicação por uma questão de segurança e disponibilidade do serviço.

Na prática

Considerando que você já tem o Jenkins rodando e um projeto, vamos direto ao ponto.

O que você precisa?

Vá em manager jenkins >> manager plugins

E instale o seguinte plugin

  • – Copy Artifact Plugin
  • – Deploy Plugin

O primeiro tem como objetivo copiar o artefato, ou seja, o .war. Então vamos configurar que após o build success do projeto X vamos copiar o artefato e deployed no servidor TomCat. Quem faz o deploy é o segundo plugin. Instale os plugins. Escolha a opção install without restart.

Criando um novo Job

Considerado que você já tem um projeto configurado no Jenkins, você não precisa fazer nada nesse projeto, apenas crie um novo Job do tipo Freestyle. A seguir o meu:

jenkinsdeploydev

O nome do projeto foi omitido.

Configurando o Job

jenkinsbuilddeploy

Em Project Name você informa de qual projeto você que copiar o artefacto. Verá que ao digitar o nome do projeto/job já existente o Jenkins vai oferecer um autocomplete.  Em seguida informamos que queremos apenas .war, senão ele vai copiar tudo que tiver no outro projeto, ou seja, se tiver um .ear ele seria copiado por exemplo.

Deploy no TomCat

Agora vamos fazer o deploy no TomCat.

jenkinsdeploytomcat

Aqui dizemos aos jenkins o que fazer depois que ele copiar o artefato, e estamos dizendo para fazer um deploy.  Para aparecer esse form, clicque em add post-build action e escolha deploy artficats. Na imagem acima informamos o tipo de arquivo que será deployed, o servidor, o contexto, usuário, password e a url onde está o servidor.

Claro que o usuário precisa ter acesso ao servidor. No caso do tomcat, vá em conf/tomcatusers.xml e verifique se o usuário está lá. E certamente não vai estar com role para execução de script, portanto adicione manager-script, ficando assim:

<role rolename="manager-script"/>

<user username="camilo" password="xxxx" roles=" admin,manager,manager-gui,

manager-script,manager-jmx"/>

 

Isso é requerido, senão o plugin não vai conseguir realizar o deploy. O .war será colocado dentro de webapps do servidor tomcat.  Quando o build terminar com sucesso, acesse sua aplicação. Se for local digite: http://localhost:8080/nomeDaSuaApplicacao

Lembre-se que se definiu o Context, informe o nome depois da / senão acesse pelo mesmo nome do arquivo .war.

Meu case

Antes de implementar o deploy automatizado aqui no projeto o tempo de cópia de um artefato para o ambiente de dev  remoto era de 30min incluindo o stop e start do tomcat, após o deploy automatizado caímos para 55sec, veja :

pipelinegreen

Note: Se você não especifica, o Context será o nome do arquivo .war.

Nota Importante

Se o Jenkins e sua aplicação são deployed no mesmo servidor, você não tem como fugir do hotdeploy, já que ao fazer um restart vai cair todos os serviços que estão rodando no Server.

Vou ficando por aqui espero que tenham gostado do post.

Abraços, see ya!!

Série Continuous Integration: Usando GitHub para autenticação no Jenkins

Olá Pessoal,

No post de hoje vamos ver como usar uma conta do GitHub como autenticação  para o nosso Jenkins. Eu particularmente acho isso fantástico, pois não preciso ficar gerenciando usuários. A única desvantagem é se o projeto não usar GitHub.  Daí podemos optar pelo próprio banco do Jenkins ou criar um com o MySQL, por exemplo, e fazer o Jenkins consultar o usuário nessa base de dados.

Lets go…

Starting…

Considerando que você já tem o Jenkins instalado, por default ele não pede autenticação, ou seja, qualquer um que souber o endereço do seu jenkins, caso esteja publico, pode acessar e buildar ou apagar o seu projeto. Que ruim heim? Vamos ver aqui como fazer autenticação.

Se você vem acompanhando o post no blog, certamente já tem o plugin do GitHub e o de autenticação instalado no Jenkins, senão instale em manage Jenkins >> manage plugins.

 

jenkinsplugingithub

Instale e salve. Escolha a opção Install without restart.

Agora vá novamente a manage jenkins e escolha configure global security. Por default vai estar desabilitada. Habilite.

E escolha:

 

jenkinsgithubauth

Aqui teremos que colocar as informações de autenticação do GitHub. Mas o que colocamos ai? A autorização de que usuários podem logar nessa aplicação a partir do GitHub. Então siga esses passos:

  1. Faça o login no Github com sua conta ou a conta que irá permitir acesso;
  2. Acesse: https://github.com/settings/applications
  3. E agora:

 

jenkinsregistergithub

E preencha:

 

jenkinsgithubregisterdone

O clientID e o Client Secret são gerados. Coloque no campo do Jenkins respectivamente, e agora vamos autorizar os usuários que podem acessar. Coloque no campo a seguir os usuários do GitHub que será admin no Jenkins, ou seja, terá permissão total sobre o build:

jenkinsgithubauthorization

A separação é por vírgula. Não se esqueça disso.

Salve as alterações. Feche o Jenkins e abra novamente. É esperado que apareça:

jenkinsgithublogin

Faça o Login. No primeiro acesso, o GitHub vai perguntar se você deseja acessar a aplicação de terceiro que você foi adicionar, permita o acesso e pronto. Você já vai cair no Jenkins.

Show e simples né?

Abraços. Vou ficando por aqui.

See ya!! 

Troubleshooting Jenkins com repositório privado Github

 

Olá Pessoal,

Quebrei a cabeça esses dias tentando fazer o jenkins se comunicar com um repositório privado no GitHub. Considerando que o jenkins está em um servidor remoto, deu muito trabalho, gastei umas 12hrs até funcionar.

O Problema:

jenkins github private repository returned status code 128:

Essa é a exceção que recebemos quando o Jenkins tenta conectar ao repositório privado para fazer o clone.

O motivo?

O Jenkins não consegue autenticar para fazer o clone.

O que achei?

Não fui muito feliz achando que era da mesma forma que fazemos com repositório público, que apenas gerar o ssh key e adicionar no github. Mas não é bem assim.

Solução

Para resolver o problema eu tive que adicionar 2 ssh key.

  1. Gerei um ssh específico (algo como id_rsa_meuprojeto);
  2. Peguei o id_rsa que já tinha no meu servidor e adicionei ao github.

Resumindo em steps

1. Passphrase não pode ter password, ou seja,  deixar empty para o id_rsa_meuprojeto

2. Criei um key específico id_rsa_meuprojeto e adicionei no github e dei authorized no servidor pelo painel. No meu caso uso  integrator

3. Adicione o id_rsa do servidor no github

4. No Jenkins usei key do id_rsa_meu projeto

Veja na imagem a seguir:

demoniojenkinsfixed

E no Jenkins informe o repositório assim:

jenkinsconfiggithub

Ou seja, usando git@github.com:youruser/yourproject

Não use Https, porque não vai.

É isso ai, só buildar e ver o clone rolando.

Abraços, see ya!! 

Série CI: Integrando Sonar com Jenkins

Olá Pessoal

No post de hoje veremos como integrar o sonar com o jenkins.  Para quem não sabe, o sonar é uma ferramenta PMD para análise do código. Em outras palavras, o Sonar olha e diz: “o nome dessa variável não está legal”, “ei tem código duplicado nessa classe”, etc. Vamos ver  como integrar essa ferramenta com o build, pois logo após fim do build o sonar roda e faz o trabalho dele.

Lets go..

Primeiro Passo

Baixe o sonar http://www.sonarqube.org/downloads/ . Para o exemplo estou usando o sonar 3.4.1, pois é o que tenho aqui . E a versão SonarQube.

Segundo Passo

Vou considerar que você já vem acompanhando a série Continous Integrations com Jenkins aqui no blog, então você já tem o Jenkins e um projeto configurado.

Terceiro Passo

Após ter baixado o sonar, descompacte o .zip e via prompt de comando vá até

sonar-3.4.1\bin

Em seguida entre na pasta referente ao sistema operacional que está usando e execute o arquivo .bat ou .sh.

 

sonarrunninglocal

 

sonarrunning

Quarto Passo

Inicie o Jenkins

Quinto Passo

Instale o plugin do sonar no Jenkins sem reiniciar aplicação. 

 

sonarjenkinsplugin

Sexto Passo

Após  instalação vá em Jenkins >> Manage Jenkins >> Configure Systems . Você vai ver que o sonar foi adicionado. Clique em advanced e deixe conforme a  seguir:

 

sonarconfigjenkins

Apenas informamos a URL onde o Sonar está sendo executado, o resto deixamos em branco porque estamos rodando local e com o banco embedded.  Para fazer com um banco real, consulte a documentação do sonar.

Clique em save.

Sétimo Passo

Vá em configure do seu  projeto no Jenkins

sonarprojectconfigure

E em post build actions clique em add e escolha sonar:

Ao clicar em Add post-build action escolha a opção “Build Pipeline Plugin >> Manually Execute Downstream Project”

 

sonarbuildpost

E deixe assim:

 

sonarjob

Save.

Oitavo Passo

Build Now o projeto e aguarde:

 

sonarbulding

 

sonarbuilddone

 

sonarappreaderweb

Pronto! Simples, não?

Vou ficando por aqui. Espero que tenham gostado.

See ya!!

Abraços.