Openshift, como fazer o deploy de um war pronto no Tomcat

No Openshift é possível trabalhar com diversas tecnologias, como: Java, PHP, Ruby, Node.js e até Perl. Além das linguagens, a plataforma cloud computing da Red Hat (PaaS) também oferece suporte a uma série de serviços complementares, como gestor de build (Maven p/ Java), ferramenta para integração contínua (Jenkins), controlador e repositório de fontes (Git).

O Openshift agrega esses serviços/ferramentas a plataforma com objetivo de ampliar a capacidade de desenvolvimento. Dessa forma além de usar o hosting em nuvem, você pode contar com uma melhor gestão de build, baseado na execução de testes, com a possibilidade de commits em repositórios segmentados.

Mas é possível ignorar esses serviços, e fazer o deploy da aplicação "pronta" no Openshift. Pronto no sentindo de que o artefato foi gerado local, sem interferência do Openshift. Isso pode ser interessante em situações pontuais, como demos ou provas de conceito.

Nesse post demonstro como realizar o deploy de uma aplicação Java web (um war), no Tomcat, sem utilizar o Maven, Jenkins e Git*.
*Na verdade não colocamos os fontes no Git, mas o utilizamos para armazenar o war da aplicação.

1 - Crie a aplicação no Openshift, e faça o clone local do repositório Git. Note que dentro do diretório principal, no repositório local, existe a subpasta webapps.

2 - Acesse o código fonte da aplicação para gerar o artefato web, o war. Se preferir utilize o Maven, rodando local, para controlar o build gerar o war.

3 - Copie o arquivo war para a pasta webapps, dentro do repositório Git local:

$ cp aplicacao.war  [caminho do repositorio]/webapps/

4 - Coloque o arquivo no repositório local e master. Execute o fluxo add / commit e push do Git:

$ cd  [caminho do repositorio]/webapps/

$ git add aplicacao.war
$ git commit -m "seu comentario"
$ git push origin master

Em caso de um redeploy, uma nova versão, antes do passo 3, remova o arquivo war atual:

$ git rm aplicacao.war 

Pronto, com esses passos é possível publicar uma aplicação "pronta" no Openshift.

http://twitter.com/edermag
http://www.yaw.com.br

Gerar MANIFEST.MF no Maven com informações do Git

O arquivo MANIFEST.MF tem como finalidade armazenar atributos sobre o artefato (JAR / WAR / EAR ...). Informações como a versão, as dependências, desenvolvedores, a classe de entrada (para JARs executáveis), ou seja, qualquer informação relevante para a instalação e uso do artefato.

Por padrão, quando um JAR é gerado o MANIFEST.MF é criado automaticamente, dentro da pasta META-INF. Nesse post eu demonstro como utilizar o Maven para criar o MANIFEST.MF com informações e dinâmicas e pré-definidas. Uma informação dinâmica seria, por exemplo, a identificação do último commit realizado no sistema de controle de fontes, o git.

O plugin do Maven buildnumber gera um identificador de build (build number) acessando informações do SCM (svn / git / mercurial). Por exemplo, durante o desenvolvimento pode existir diversar iterações (e commits) para a mesma versão 1-0-SNAPSHOT. Com o plugin é possível aumentar a granularidade na identificação da versão/build do artefato.

Uma vez que o valor do build number é gerado, o plugin jar acessa essa informação para criar o artefato. Esse é o plugin em que definimos a estrutura do MANIFEST.MF que o Maven deve utilizar.

A seguir um exemplo de pom.xml com a url do git e as definições para o Maven criar o MANIFEST.MF:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <modelVersion>4.0.0</modelVersion>
  <groupId>br.com.yaw.sjc</groupId>
  <artifactId>swing-jdbc-crud</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>swing-jdbc-crud</name>
  <url>http://maven.apache.org</url>

  <!-- Defino alguma propriedades, que serao utilizadas para o Manifest  -->
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.title>Demo Swing c/ JDBC</project.title>
    <user.name>YaW Tecnologia</user.name>
    <site>http://www.yaw.com.br</site>
  </properties>

  <dependencies>
    <!-- omiti os trechos com as dependencias -->
  </dependencies>

  <!-- Url para o respositorio git (github), utilizada pelo buildnumber -->
  <scm>
    <connection>scm:git:https://github.com/yaw/swing-jdbc-crud.git</connection>
  </scm>

  <!-- Configuracoes (c/ plugins) para geracao do jar -->
  <build>
    <plugins>
      <!-- Plugin buildnumber, executado durante a fase validation -->
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>buildnumber-maven-plugin</artifactId>
        <version>1.1</version>
        <executions>
          <execution>
            <phase>validate</phase>
            <goals>
              <goal>create</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

      <!-- Plugin jar -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>2.1</version>
        <configuration>
          <archive>
            <manifest>
              <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
            </manifest>
            <manifestEntries>
              <!-- Atributos para o Manifest -->
              <Built-By>${user.name}</Built-By>
              <Implementation-Title>${project.title}</Implementation-Title>
              <!-- Aqui ele usa o buildNumber -->
              <Implementation-Build>${buildNumber}</Implementation-Build>
              <Implementation-Site>${site}</Implementation-Site>
            </manifestEntries>
          </archive>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Esse pom.xml foi baseado no projeto demontração Swing e JDBC, desenvolvido pela YaW.

@edermag

www.yaw.com.br

Acessar repositórios no github com proxy HTTP (http.proxy do git)

No ambiente corporativo é muito comum o uso de proxy HTTP. Portanto para trabalhar com os repositórios remotos do git, com o github via HTTP(s), é necessário considerar as configurações do proxy.

Antes de fazer clone, pull ou push dos fontes no github faça as seguintes configurações do git:

$ git config --global http.proxy http://usuario:senha@host:port

Aonde:

• usuario: deve contar o login para o proxy;
• senha: a senha do proxy;
• host: o ip do servidor proxy;
• port: a porta do proxy;

Para testar, o comando pra clonar um repo:

$ git clone https://github.com/yaw/produtividade-eclipse.git

Pronto!

@edermag
www.yaw.com.br