Présentation

Sujet : Gradle et application à eCOM avec Docker Plugin
Auteur : Rémi GATTAZ
Enseignants : Didier Donsez, Georges-Pierre Bonneau
Date : 30/09/2016

Résumé

Gérer manuellement le cycle de vie d'une application se fait par la répétition d'actions simples. De ce constat, des logiciels appelés moteurs de productions ont été développés. Le premier d'entre eux était Make. Depuis, beaucoup d'autre ont vu le jour et notamment Gradle. Créé en 2007, il est aujourd'hui un des moteurs de production les plus populaires. Conçus pour allier le meilleur de deux alternatives très populaire, Graddle est aujourd'hui présenté comme un logiciel très complet pour gérer le cycle de vie d'un logiciel.

Mots-clés : Gradle, Moteur de production, cycle de vie

Abstract

Handling manually the life cycle of an application is done through the repetition of simple tasks. From that finding, build automation solution were designed. The first of them was Make. Since, many others were created and among them is Gradle. Created in 2007, it has become one of the most used build automation solution. Gradle was desgined to bring the best of two of very popular alternatives while removing their issues, Gradle is considered to be a good solution to handle the life cycle of a software.

Keywords : Gradle, build automation, life cycle

Synthèse

Moteurs de production

Les moteurs de production sont des logiciels dont le but est principalement d'automatiser la gestion d'un développement logiciel. La compilation, la création de documentation, la gestion de tests automatisés ou encore la publication de livrables sont les actions les plus classiques qui peuvent généralement être automatisées avec ces logiciels. Leurs utilisations permet donc de faciliter le lancement de ces tâches et ainsi d'augmenter la productivité.

Il existe beaucoup de moteur de production. Les plus connus sont les suivants :

Apache Ant
Apache Maven
CMake
GNU Make
Gradle
NMake
SCons
Waf

Les actions ou tâches qui vont être possible d'effectuer et les langages de développement supportés vont varier selon les moteurs de production.

La configuration de ces actions passe toujours par la modification de fichier de configuration. La syntaxe de ces fichiers va elle aussi changer selon l'outil utilisé. Parmis les modèles les plus répandus se trouvent les fichiers xml et Yaml.

    <project name="MyProject" default="dist" basedir=".">
        <description>
            simple example build file
        </description>
        <!-- set global properties for this build -->
        <property name="src" location="src"/>
        <property name="build" location="build"/>
        <property name="dist" location="dist"/>
        <target name="init">
            <!-- Create the time stamp -->
            <tstamp/>
            <!-- Create the build directory structure used by compile -->
            <mkdir dir="${build}"/>
        </target>

        <target name="compile" depends="init"
            description="compile the source">
            <!-- Compile the java code from ${src} into ${build} -->
            <javac srcdir="${src}" destdir="${build}"/>
        </target>
        <target name="dist" depends="compile"
            description="generate the distribution">
            <!-- Create the distribution directory -->
            <mkdir dir="${dist}/lib"/>
            <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
            <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
        </target>
        <target name="clean"
            description="clean up">
            <!-- Delete the ${build} and ${dist} directory trees -->
            <delete dir="${build}"/>
            <delete dir="${dist}"/>
        </target>
    </project>

Configuration exemple du moteur Apache Ant tirée du manuel officiel

Gradle

Gradle est un moteur de production crée en 2007 qui se base sur les concepts de Apache Ant et Apache Maven, deux autres moteurs de production. Le projet est née pour apporter la création d'un outil alliant les avantages de ces deux outils tout en essayant de retirer les défauts.

Pour cette raison, Gradle dispose tout comme Maven d'un gestionnaire de dépendance intégré et du concept de convention plutôt que configuration permettant d'obtenir des fichiers de configurations léger. Aussi, Gradle dispose tout comme Apache Ant d'une très forte flexibilité au niveau de l'écriture du fichier de configuration. En revanche, contrairement à Maven et Apache Ant qui utilisent des fichiers de configuration XML dont la structure peut rapidement devenir importante, Gradle utilise des fichiers de configurations dans un langage s'apparentant à Groovy. L'utilisation de ce langage permet de rendre les fichiers de configurations beaucoup moins verbeux et ainsi beaucoup plus clair.

A sa première version, sortie en 2012, le logiciel était uniquement capable de gérer des projets Java, Scala et Groovy et se basait très fortement sur Apache Ant et Maven pour fonctionner. Aujourd'hui en version 3.1, beaucoup des fonctionnalités qui provenaient de Ant et Maven sont maintenant dans le coeur de Gradle. Et puisque le moteur de production a été conçu avec la notion de plugin, il a été très fortement étendue et il peut donc être utilisé pour pratiquement n'importe quel type de projet. Les plugins officiels et de la communauté permettent à Gradle de supporter plus de 60 langages et augmentent très fortement ses capacités.

Le fichier build.gradle

Le fichier build.gradle est l'emplacement principal de la configuration des tâche Gradle. Une tâche gradle étant ce qui est effectué lorsque Gradle est exécuté.

Exemple: Exemple d'un fichier build.gradle minimaliste

    apply plugin: "java"

    /* block could be removed since sources in src/main is standard configuration */
    sourceSets {
        main.java.srcDirs "src/main"
    }

    jar{
        manifest.attributes (
            "Main-class" : "air.vts.simple.HelloWorld",
        )
    }

Cet exemple est très simple et est tiré d'un projet java avec seulement quelques fichiers qu'il faut mettre dans un jar qu'on rend exécutable en spécifiant le point d'entrée du programme dans le fichier manifest du jar.

Les blocs présent dans l'exemple ne sont pas des tâches. Il s'agit de configurations. Une tâche est décrite selon la syntaxe suivante :

    task nameOfTaks(type: TYPE) {
        /* Content of Task */
    }

Dans l'exemple, même si aucune tâche n'est spécifié dans ce fichier, les tâches 'build', 'javadoc', 'jar' sont disponibles puisqu'elle proviennent du plugin java.

Ses forces

La plus grande force de Gradle provient de son extensibilité. Puisqu'il est basé sur un principe de plugin, la communauté peut proposer ses plugins et les publier sur le site de Gradle afin de les partager. Le nombre de plugins existant n'est pas communiqué mais est important.
https://plugins.gradle.org/

Sa documentation est également très fourni et contient beaucoup d'exemple permettant de comprendre l'outil facilement et ainsi prendre rapidement en main le logiciel.

https://docs.gradle.org/current/userguide/userguide.html

Selon des tests effectués par Revel Labs en janvier 2014, les performances générales de Gradle sont supérieure à Apache Ant et Maven.

http://www.slideshare.net/ZeroTurnaround/java-build-tools-part-2-a-decision-makers-guide

Gradle et docker

Parmi les plugins de Gradle créés et diffusés par la communauté, il existe des plugins pour gérer des images et conteneurs docker. Parmi ceux ci se trouve notamment docker-remote-api, un plugin se trouvant dans le pack [gradle-docker-plugin https://github.com/bmuschko/gradle-docker-plugin].

Ce plugin a été conçu pour permettre la gestion de conteneurs et d'images docker depuis Graddle. Ainsi, avec ce plugin, il est possible de créer des images et de les exécuter pour obtenir des environnement de développement, de tests et production. Utiliser ce plugin permet ainsi de contrôler les environnements utilisés et ainsi permettre leurs harmonisations pour que les environnements finaux (de production) soit les plus proches possibles de ceux de test et de developpement.

Gradle, docker et le projet eCOM

Dans le cadre du projet eCOM, il est imposé de créer une application Java EE qu'il faut packager dans un fichier .ear qui doit être publié sur un serveur compatible tel que GlassFish ou WildFly.

Pour suivre cette consigne, il est possible de générer un fichier .ear puis de manuellement le déployer sur un serveur. Il est également possible de le publier directement avec Gradle en précisant dans le fichier de build.gradle l'adresse du serveur et les identifiants nécessaire.

Une dernière solution, qui va être détaillé ici, est d'utiliser docker avec Gradle afin de produire une image Docker contenant l'application complète. C'est à dire le serveur d'application java et le fichier .ear qui est produit. Au cours du développement de cette application, il est alors possible d'utiliser cette image pour tester l'application eCOM et éventuellement la déployer en production.

Architecture

Le plugin docker-remote-api qui va être utilisé pour construire l'image docker peut être utilisé avec un fichier Dockerfile ou en définissant dans le fichier build.gradle les éléments du fichier qui est alors généré dynamiquement.

Pour faciliter ce cas d'utilisation et limiter le contenu du fichier build.gradle, nous allons créer un fichier Dockerfile et le placer dans le dossier docker situé à la racine du projet.

DockerFile

La première chose à définir est le choix du serveur. Puisque l'image docker du serveur GlassFish est très mal supporté et qu'elle a été déprécié, l'utilisation de WildFly est préféré.

La construction de l'image WildFly dans lequel un fichier .ear est déployé est simple puisqu'il suffit de déposer un fichier .ear dans le dossier /opt/jboss/wildfly/standalone/deployments/ de l'image. Le fichier Dockerfile faisant cette création est donc le suivant :

    #
    # Super simple Dockerfile to deploy wildfly
    #
    FROM jboss/wildfly:10.1.0.Final

    MAINTAINER Rémi GATTAZ "remi.gattaz@gmail.com"

    ADD myApp.ear /opt/jboss/wildfly/standalone/deployments/

Notons toutefois qu'il faut avoir accès au fichier .ear dans le dossier Docker

Ajout de la configuration gradle

Voici la configuration nécessaire à mettre en place pour construire l'image docker.

    /* DOCKER PLUGIN */
    /* Add docker plugin as dependency */
    buildscript {
        repositories {
            jcenter()
        }

        dependencies {
            classpath 'com.bmuschko:gradle-docker-plugin:3.0.3'
        }
    }

    /* Apply docker plugin */
    apply plugin: 'com.bmuschko.docker-remote-api'
    repositories {
        mavenCentral()
    }

    /* docker configuration (for docker-machine only) */
    docker {
        url = System.env.DOCKER_HOST
        certPath = new File(System.env.DOCKER_CERT_PATH)
    }

    /* Copy build res in docker folder */
    import org.gradle.api.tasks.Copy
    task copyBuildRes(type: Copy) {
        from 'build/libs/myApp.ear'
        into 'docker/myApp.ear'
    }

    /* buildImage task */
    import com.bmuschko.gradle.docker.tasks.image.DockerBuildImage
    task buildImage(type: DockerBuildImage) {
        dependsOn build
        dependsOn copyBuildRes

        tag = 'my-container'
        /* By default, uses the Dockerfile in the folder docker */
    }

La tâche copyBuildRes permet de copier le fichier myApp.ear construit par Graddle dans le dossier docker. Ainsi, le fichier Dockerfile aura accès à l'ear.

Build

Une fois ces fichiers mis en place, la tâche buildImage permet de construire l'image Docker de l'application eCOM.

VT2016 Gradle

Contents