GitHub Actions

    Nesse artigo rápido eu mostro um exemplo do uso do GitHub Actions para um projeto Java. O arquivo deve ficar em uma pasta workflow dentro da pasta .github do projeto (.github/workflows).

name: CI/CD with Docker and GitHub Actions

on:

  push:

    branches:

      - main

jobs:

  build:

    runs-on: ubuntu-latest

    steps:

    - name: Checkout repository

      uses: actions/checkout@v2

    - name: Build Docker image

      run: docker build -t gbdaniel/projeto:latest .

    - name: Log into Docker Hub

      run: docker login -u gbdaniel -p ${{ secrets.DOCKERHUB_TOKEN }}

    - name: Push image to Docker Hub

      run: docker push gbdaniel/projeto:latest

  deploy:

    runs-on: ubuntu-latest

    needs: build

    steps:

    - name: Install SSH key

      uses: webfactory/ssh-agent@v0.5.3

      with:

        ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

    - name: SSH into EC2 instance and update Docker Compose

      run: |

        ssh -o StrictHostKeyChecking=no ec2-user@IP_DO_SERVIDOR_EC2 "cd /home/ec2-user && docker-compose pull && docker-compose up -d"

Glowroot - Ferramenta grátis para profiling remoto de aplicações Java

       Hoje vou apresentar uma ferramenta de profiling gratuita para aplicações Java, o Glowroot. 

   

    Mas primeiro uma rápida explicação dobre o que é profiling. Profiling é o processo de monitoramento e medição de desempenho das aplicações para manutenção e melhoria de performance e busca de erros que levam a queda do sistema. 

    

    Existe uma vasta variedade de programas que fazem esse tipo de serviço, a maioria deles é pago, e os gratuitos geralmente são bem limitados ou não tem uma interface web para acesso remoto. O Glowroot é uma boa opção porque é gratuito e tem a interface web, facilitando o trabalho. Antes dele eu usava o Jvisualvm que já vem por padrão nas JDKs (até a versão 8 se não me engano) mas é bem limitado e exige que o servidor tenha a parte gráfica habilitada e o acesso direto ao programa. 

    

    O Glowroot permite acompanharmos o uso de memória, mostra as falhas a nível de métodos, permite vermos as consultas mais pesadas da aplicação, etc. Ou seja, uma ferramenta completa e de fácil instalação. 

     A ferramenta pode ser baixada no seguinte endereço: https://glowroot.org/ 

    

    Lá também tem as instruções de instalação. Após instalar o Glowroot, na pasta glowroot vai ser criada uma subpasta de logs e uns arquivos. Para disponibilizar o Glowroot pela web é preciso alterar o endereço de 127.0.0.1 para 0.0.0.0 no arquivo admin.json. 

    A versão disponível nesse endereço é sempre a última, para versões anteriores você pode acessar o repositório do projeto: https://github.com/glowroot/glowroot/releases.

    Você também pode ver uma demo da aplicação rodando como na imagem abaixo:

Evitando o erro: sun.awt.X11GraphicsEnvironment

Para evitar problemas com aplicações Java rodando em servidores Linux sem modo gráfico disponível, é sempre bom usar o parâmetro:

-Djava.awt.headless=true

Isso vai evitar que em algum momento você se depare com um erro no servidor e gaste um bom tempo até se lembrar desse problema. E qual o problema que esse parâmetro evita?

Bom, você pode diretamente usar alguma classe do pacote sun.aws ou alguma biblioteca que use classes desse pacote (como o IReport, etc), e o problema é que esse pacote trabalha com algumas coisas que precisam ser renderizadas e tenta usar bibliotecas que se comunicam com a interface gráfica do servidor pra isso, e ao serem usadas suas classes ele verifica se o servidor tem modo gráfico disponível ou não, caso não, ele lança uma exceção.

Provavelmente a exceção vai ter algo a ver com sun.awt.X11GraphicsEnvironment

O parâmetro indicado acima a grosso modo diz ao Java pra ignorar o uso das bibliotecas do modo gráfico do servidor.

Então esse é um bom parâmetro pra usar sempre.  

Fonte:
http://www.jguru.com/faq/view.jsp?EID=222296

Inicializando e parando o Tomcat no Linux com o comando "service"

    Nesse post vou mostrar como configurar o Tomcat para ser inicializado e parado através do comando "service", e como colocar o servidor de aplicação para ser startado juntamente com a máquina.

    Vamos a configuração: Crie um arquivo em /etc/init.d/ chamado tomcat (não precisa de extensão) com o seguinte conteúdo:

#config tomcat
 
export CATALINA_HOME="/opt/apache-tomcat-7.0.69"

ERROR=0

case "$1" in
  start)
    echo $"Iniciando o Tomcat"
    sh $CATALINA_HOME/bin/startup.sh
    ;;

  stop)
    echo $"Parando servidor Tomcat"
        sh $CATALINA_HOME/bin/shutdown.sh
    ;;

  restart)
    echo $"Parando servidor Tomcat"
    sh $CATALINA_HOME/bin/shutdown.sh
    echo $"Iniciando servidor Tomcat"
    sh $CATALINA_HOME/bin/startup.sh
    ;;

  *)
    echo $"Uso: $0 {start|stop|restar}"

 exit 1
 ;;

esac

exit $ERROR

    Na parte destacada em amarelo, lembrar de colocar o caminho e versão do Tomcat do seu servidor. Agora vamos dar a permisão de leitura e execução:

chmod +rx /etc/init.d/tomcat

   Pronto, agora para inicializar o Tomcat bastausar o comando:

service tomcat start 

   

   E para parar:

service tomcat stop

   O restart por sua vez executa os dois comandos. Agora vamos configurar para iniciar o script no start do servidor. Basta executar este comando:

update-rc.d tomcat defaults

   Através deste comando é criado o link simbólico para a execução na inicialização do Linux. Para remover ele basta executar o seguinte:

update-rc.d tomcat remove

   Para esse post é só! Como sempre, espero ter ajudado...

 

Forçando o Maven a colocar as libs em WEB-INF/lib

    Quando o Maven não colocar as libs dentro do pacote WEB-INF/lib no projeto por algum motivo, nós podemos dizer ao Maven para fazer isso através da seguinte instrução a ser adicionada no pom.xml:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
        <execution>
            <id>copy-dependencies</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>copy-dependencies</goal>
            </goals>
            <configuration>
                <outputDirectory>./WebContent/WEB-INF/lib</outputDirectory>
                <overWriteIfNewer>true</overWriteIfNewer>
            </configuration>
        </execution>
    </executions>
</plugin>
   
    Assim estamos especificando como ele deve executar um goal (objetivo) dentro de uma phase (fase) de build. Verifique se no seu projeto o outputDirectory realmente é "./WebContent/WEB-INF/lib".

    Espero ter ajudado!

Usando o Spring Boot no Wildfly 8.1.0

         Nesse post eu vou falar sobre rodar o Spring Boot no Wildfly. Bom, como o wildfly é um container de aplicações JavaEE completo, espera-se que não seja nenhum problema rodar o Spring Boot, certo? Pois é, mas algumas configurações são válidas para melhorar isso, que devem ser feitas no pom.xml.

         O Spring Boot carrega um Tomcat incorporado através da seguinte configuração no pom.xml:

<dependency>

      <groupId>org.springframework.boot</groupId>

      <artifactId>spring-boot-starter-tomcat</artifactId>

      <scope>provided</scope>

</dependency>

         Esta dependência não é necessária pois o Wildfly tem um Toncat Servidor Web chamado Undertow rodando em suas entranhas (O Tomcat era usado nas versões antigas quando era chamado JBoss). Comente esta dependência e no lugar dela deve ficar:

<dependency>

      <groupId>javax.servlet</groupId>

      <artifactId>javax.servlet-api</artifactId>

      <scope>provided</scope>

</dependency>

      Pelo que pesquisei, para garantir que não irá ser carregado o Toncat, é bom alterar também a seguinte dependência:

<dependency>

      <groupId>org.springframework.boot</groupId>

      <artifactId>spring-boot-starter-web</artifactId>

</dependency>

         Deixando da seguinte forma:

<dependency>

      <groupId>org.springframework.boot</groupId>

      <artifactId>spring-boot-starter-web</artifactId>

      <exclusions>

            <exclusion>

                  <groupId>org.springframework.boot</groupId>

                  <artifactId>spring-boot-starter-tomcat</artifactId>

                  </exclusion>

            </exclusions>

</dependency>

Outra coisa importante é garantir que o Mavem vai exportar um arquivo do tipo war:

<packaging>war</packaging>

Basicamente, com essas configurações o projeto que usa Spring Boot vai rodar muito bem no Wildfly, porém deixará de funcionar no modo que usava o Tomcat embutido, e a aplicação terá que ser sempre iniciada através do Wildfly, por isso indiquei que comentasse a configuração antiga, assim pode revezar a configuração quando necessário, comentando as configurações referentes ao wildfly e retirando o comentário a respeito do Tomcat.

Outra dica importante é que a URI quando usamos o Tomcat embutido não necessita do nome da aplicação, bastando digitar apenas o endereço local, a porta e o caminho definido no controller através da annotetion @RequestMapping, por exemplo:

http://localhost:8080/carros/novo  //tomcat embutido

Já com a aplicação no wildfly será necessário acrescentar o nome da aplicação ficando:

http://localhost:8080/loccar/carros/novo  //wildfly

E acrescentar a seguinte configuração no arquivo application.properties:

server.context-path=/loccar   //loccar é o nome da minha aplicação, subtitua pelo nome dado ao pacote war da sua aplicação.

       Se você usava o Tomcat embutido, terá que fazer várias alterações nos links de páginas, imagens, arquivos CSS, arquivos JavaScript, etc... Para isso não ser uma grande dor de cabeça, recomenda-se o uso do Thymeleaf (http://www.thymeleaf.org/) nos projetos, pois ele oferece meios de mapear de forma automática estes recursos.

Veja o link de um post sobre o Thymeleaf usado para este fim AQUI!

       Espero ter ajudado, qualquer dúvida, deixa nos comentários que eu tento da uma força...

Links úteis:

https://spring.io/blog/2014/03/07/deploying-spring-boot-applications

https://github.com/spring-projects/spring-boot/blob/master/spring-boot-deployment-tests/spring-boot-deployment-test-wildfly/pom.xml

Fazendo o deploy de uma aplicação na Nuvem com Wildfly 8.2.1 e PostgreSQL 9.2

Fazer o deploy de uma aplicação Java em um servidor online pode ser meio complicado. Geralmente o Wildfly requer algumas configurações que não vem por default nos servidores de hospedagem, como é o caso de uma aplicação que usa o PostgreSQL como SGBD.

Neste post vou guiar vocês por alguns passos para o deploy em um servidor da RedHat através do host openshift, que inclusive disponibiliza um plano para hospedagem grátis para que você possa testar o serviço ou até começar uma aplicação e depois migrar para um plano melhor que se adéque a sua necessidade e ao seu bolso.
A maioria das coisas está documentada pelo Openshift em inglês, porém tem algumas coisas que vou fazer aqui que não tem no manual da Openshift, mas são muito importantes para que a aplicação funcione corretamente.

·        Criar uma conta.

·        Entender o Openshift e instalar programas necessários para começar.

·        Criar a aplicação com o Container WEB e o SGBD.

·        Uma alternativa para o Git...

·        Configurando o Wildfly para aceitar uma conexão com o PostgreSQL.

·        Configurando o PostgreSQL para acesso local ao servidor via SSH

·        Fazendo o deploy de uma aplicação JEE.

Agora temos uma aplicação rodando em produção em um servidor na nuvem! 

Qualquer dúvida pode postar nos comentários que farei o possível para responder...

Fontes: 

https://developers.openshift.com/en/getting-started-windows.html

https://developers.openshift.com/en/managing-remote-connection.html

https://blog.openshift.com/using-filezilla-and-sftp-on-windows-with-openshift

Criando uma conta em um servidor na Nuvem | Openshift - RedHat

    O primeiro passo é criar uma conta no openshift. Acesse o endereço www.openshift.com e acesse o botão que diz sign up for free no topo ao lado direito.

         Entre com os dados do cadastro na tela subsequente.

         Após o cadastro, observe que nessa tela tem a opção Sign in a direita em azul, para quem já tem a conta criada. Basta clicar, colocar os dados e acessar.

         Pronto, você já possui um cadastro válido no host da RedHat.

Próximo passo...

Entendendo o funcionamento do Openshift e dando os primeiros passos

           Agora que a conta está criada, é preciso entender como funciona a hospedagem na Openshift.

         Após fazer o login, você verá uma tela para criar a aplicação. Clicando em adicionar aplicação, você verá uma tela com vários servidores de aplicação, servidores de banco de dados e até gerenciadores de conteúdo como Wordpress e Drupal.

         Na conta gratuita, você tem direito a até 3 aplicações diferentes, sendo cada uma com 1 GB de disco e 512 MB de Ram. Esse conjunto de hardware disponibilizado é chamado de Cartridges ou cartuchos em português. Caso haja necessidade, você pode combinar um ou mais cartridges para a mesma aplicação, ou deixar a aplicação escalável, e o servidor irá alocar mais memória ou disco quando necessário, o que diminuíra o número de aplicações possíveis.

         Uma aplicação WEB geralmente precisa de duas coisas: Um servidor de aplicação (container WEB) e um banco de dados. Então isso nos custará a principio 2 cartuchos no mínimo.

         Agora vamos com calma! Antes de instalar qualquer coisa no servidor, vamos nos preparar para podermos gerenciar a nossa aplicação. Vamos instalar as ferramentas necessárias para o acesso ao servidor. Precisamos de 3 coisas: Ruby, Git e rhc.

Primeiro vamos instalar o Ruby. Acesse o site http://rubyinstaller.org/downloads e baixe o instalador. Ao instalar certifique-se de que a opção Add Ruby executables to your PATH seja marcada.

Depois vamos instalar o Git. Acesse o endereço https://git-for-windows.github.io/ e faça o download. A medida que a instalação for seguindo, cuide em marcar as opções:

·        Run Git from the Windows Command Link Prompt

·        Checkout Windows-style, commit Unix-style line endings

·        Use Windows' default console window

E por último, instale o rhc, que é um conjunto de ferramentas do Openshift para gerenciar as aplicações via prompt de comando. Com ele, podemos criar, parar e restartar as aplicações, fazer uma conexão ssh com o servidor e acessar as aplicações localmente, entre muitas outras coisas.

Para isso temos que abrir o prompt de comando e executar algumas configurações, siga com atenção as instruções:

gem install rhc

Após o termino da instalação, digite:

rhc setup

Será pedido seu login(e-mail) e senha de acesso ao site, e após fornecê-los, aparecerá um pedido para aceitar gerar um token (chave criptografada) que será armazenado na conta do usuário logado no Windows.

C:\Users\seu usuário\.ssh\id_rsa.pub

Depois o prompt irá perguntar se você deseja fazer upload da chave gerada, basta responder yes para sim e pressionar enter. Nesse momento será feito uma verificação de domínio no servidor, e como é o primeiro acesso, o domínio não existe e será pedido para você fornecer um.

Please enter a domain (letters and numbers only) | <none> |:

O domínio pode ser o seu nome, o nome da sua empresa, etc. Sem espaços ou caracteres especiais. Após criar o domínio, irá aparecer no prompt uma lista de aplicações que o Openshift suporta nativamente (sim, é possível instalar de outras fontes) e a linda mensagem:

Your client tools are now configured.

Pronto! Agora temos as ferramentas necessárias para criar e configurar nosso servidor de aplicação e banco de dados no Openshift que é nosso próximo passo.

Próximo passo...

Criando uma aplicação com o wildfly 8.2.1 e PostgreSQL 9.2

        Chegamos no ponto de instalação da aplicação que terá o Wildfly 8.2.1 e o PostgreSQL 9.2 no servidor e irá utilizar 2 cartuchos (Cartridges).

         É muito simples, basta digitar:

rhc app create nomedaaplicacao jboss-wildfly-8 postgresql-9.2

         E clicar enter. Após ele processar um pouco, a sua aplicação foi criada e está rodando, guarde as credenciais do wildfly e do postgresql que apareceram no prompt. Lembre-se que por aplicação enquanto estamos falando do Openshift é o seu Wildfly e seu SGBD instalados e rodando, aguardando ansiosos pelas configurações e o Deploy!

       Precisamos portanto configurar o Wildfly para ele poder receber o Deploy e se conectar com o PostgreSQL.

Próximo passo...

Configurando o Wildfly para aceitar uma conexão com o PostgreSQL

        Pessoal, quem é acostumado a usar o Wildfly com PostgreSQL sabe que temos que colocar dentro do Wildfly uma cópia do driver .jar do PostgreSQL e um arquivo chamado module.xml. O local aonde colocamos este arquivo varia de acordo com versões do Wildfly, principalmente entre versões do JBoss, que é a versão mais antiga do Container e a versão atual. O Openshift até tenta fazer isso de forma automática quando criamos a aplicação no servidor e selecionamos Wildfly e o PostgreSQL, mas justamente por causa dessa variação que ocorre nas versões, ele acaba colocando os arquivos no local errado e não funciona.

         Tenha em mãos o .jar do PostgreSQL na versão correta e o arquivo module.xml, coloque ambos em uma pasta no seu computador, no meu caso como eu tenho um servidor configurado na máquina local eu irei pegar de lá.

         O driver do banco vem quando se instala o PostgreSQL na máquina e fica em uma pasta chamada pgJDBC, mas pode ser baixado do site do Postgre também separadamente. Para quem não tem o arquivo module.xml basta criar um com o conteúdo abaixo:

<?xml version="1.0" encoding="UTF-8"?>




<module xmlns="urn:jboss:domain:datasources:2.0" name="org.postgresql">




  <resources>

         <resource-root path="postgresql-9.2-1002.jdbc4.jar"/>

  </resources>




  <dependencies>

          <module name="javax.api"/>

          <module name="javax.transaction.api"/>

   </dependencies>




</module>

Vamos copiar os arquivos, lembre-se de estar com o WinSCP aberto e conectado com o servidor como mostrado no post anterior. O que aparece do lado esquerdo é a sua máquina local, e do lado direito é o servidor na nuvem. O que está marcado de vermelho é para auxiliar a navegar na sua máquina, onde você pode escolher o diretório para navegar. o mesmo acontece no lado servidor. 

Do lado esquerdo navegue até a pasta onde está os .jar e o module.xml. Do lado direito que é o lado do servidor entre no seguinte caminho:

Wildfly/modules/system/layers/base/org

Você verá várias pastas, crie uma pasta chamada postgresql e dentro crie uma pasta chamada main onde irão ficar o .jar e o arquivo module.xml. No lado esquerdo selecione os 2 arquivos e clique com o botão direito escolhendo a opção upload. 

Pronto! O Wildfly irá conseguir se conectar com o Postgresql quando criarmos a conexão com o banco no momento do deploy. agora vamos para o próximo passo que é conectar o PostgreSQL como se fosse local através do pgAdmin III para criarmos o banco.

Próximo passo...

Configurando o PostgreSQL para acesso local ao servidor via SSH

         Para administrarmos o PostgreSQL, é necessário ter a versão instalada na máquina e o pgAdmin III também instalado. O que vamos fazer é criar um túnel SSH que permite acessarmos de modo seguro o banco da WEB que se encontra no servidor remoto como se estivesse localmente.

Primeiro vamos criar o “túnel SSH” para podermos conectar o banco como em um servidor local. Abra o prompt de comando e digite:

rhc port-forward nome-da-sua-aplicação

Irá ser solicitado a sua senha de acesso ao Openshift 2 vezes, e então a conexão será feita e será exibido uma lista mostrando o endereço local de cada serviço e o endereço remoto correspondente.

        Note que o endereço local 127.0.0.1:8080 irá dar o acesso a página inicial do Wildfly, o endereço 127.0.0.1:9990 irá dar acesso ao painel de administração do Wildfly e o endereço 127.0.0.1:51461 pertence ao banco de dados. (Confira se a porta do BD é igual no seu caso). Deixe o prompt aberto nesse ponto, pois enquanto estiver aberto, o nosso túnel SSH está ativo.

             Abra o pgAdmin III e clique em file, e depois em Add Server... 

          Na próxima tela, preencha um nome qualquer para o servidor, o host coloque 127.0.0.1, na porta, coloque a porta especificada no prompt de comando, e em username e password coloque os dados que foram exibidos no omento da criação da aplicação. Caso não tenha esses dados, acessando sua aplicação pelo site do Openshift é possível conseguir. 

             Basta confirmar para criar o servidor. (Para que isto funcione o prompt precisa estar aberto na tela de aguardo). Pronto, enquanto o prompt permanecer aberto e como mostrado à cima você poderá usar normalmente o PostgreSQL como se o servidor de banco estivesse na sua máquina. Pode criar seu banco e suas tabelas de acordo com sua necessidade. E depois do banco criado estamos prontos para fazer o Deploy! Que será nosso próximo e último passo...

Último passo...

Fazendo o deploy de uma aplicação JEE.

Antes de exportar o .war da sua aplicação no eclipse ou seja qual for a sua IDE, lembre-se de alterar os dados de acesso ao banco para os fornecidos pela Openshift. Qualquer dúvida, você pode digitar no prompt de comando:

rhc app-show nome-da-aplicacao 

E será exibido url, usuário e senha para a conexão Java com o banco.

Agora que já temos tudo configurado, o que temos que fazer é o Deploy. Abra o WinSCP e faça a transferência do arquivo .war da sua aplicação para a pasta:

wildfly/standalone/deployments/

Depois basta acessar localhost:8080/nomedaaplicacao. E ela já estará disponível online também pelo endereço do servidor, que é o endereço que fica depois do @ no WinSCP.

Pronto! Sua aplicação já está Online!

Uma alternativa para o Git...

          Bom pessoal, o Git é uma ferramenta muito bacana, principalmente para manutenção do sistema, alteração de um arquivo e tal, porém, aqui nesse momento, nós iremos fazer algumas alterações que são bem mais produtivas se feitas usando uma ferramenta que eu possa manipular as pastas e arquivos como se estivesse localmente. Dessa forma vamos usar 2 programinhas.

  Primeiro vamos usar o PuTTY que você pode estar baixando pelo link http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html procurando ao parecido com  putty-0.67-installer.exe  abaixo de uma frase que diz: A Windows MSI installer for everything except PuTTYtel. Após baixar pode realizar a instalação normalmente.




       Depois de instalar, execute o PuTTYgen, clique em conversions no menu e em seguida em Import key. Na tela de busca, selecione Todos os arquivos ou All Files e navegue até o diretório:




C:\Users\seu usuário\.ssh

E selecione o arquivo id_rsa.




Salve a chave no mesmo diretório clicando em Save private key com a extensão .ppk colocando o nome que desejar. Agora feche o PuTTYgen.




Para a segunda parte, vamos precisar do WinSCP que você pode está fazendo o download em http://winscp.net/. Instale o programa normalmente e execute-o.







    Clique em Advanced... e na tela seguinte, na lateral esquerda, clique em Authentication, abaixo de SSH, preenchendo o campo Private key file com a chave que geramos com o PuTTYgen e clique em OK.

Agora preste atenção nesses passos! Para pegar o Host name e User name vamos precisar acessar o Openshift e acessar a nossa aplicação. 




Você irá encontrar uma frase no lado direito: Remote Access. Embaixo tem um link que ao clicar seleciona um código parecido com:




563s01d22d55721db8698720@portfolio-gbdanieloliveira.rhcloud.com




Onde 563s01d22d55721db8698720 é o usuário




E portfolio-gbdanieloliveira.rhcloud.com é o Host name.




A senha é a que você cadastrou no site do Openshift.




       Depois basta clicar em Login e pronto, estamos conectados no servidor através de uma conexão SSH. 










        O que aparece do lado esquerdo é a sua máquina local, e do lado direito é o servidor na nuvem. O que está marcado de vermelho é para auxiliar a navegar na sua máquina, onde você pode escolher o diretório para navegar. o mesmo acontece no lado servidor. Na próxima aula você irá entender melhor. O próximo passo será a configuração do Wildfly para aceitar se conectar com o Postgresql.




Próximo passo...