OpenShift 3 - Partie 2 : Construire votre application

OpenShift 3 - Partie 2 : Construire votre application

Introduction

Maintenant que vous connaissez les bases du fonctionnement d’Openshift, je vais pouvoir aborder la partie Build, pour vous montrer les différentes stratégies présentes pour construire votre application.

Il faut avoir conscience qu'il n'existe pas de stratégie parfaite mais plutôt une sélection judicieuse en fonction de multiples facteurs. Celle à utiliser dépendra principalement de l'historique de l’application, sa criticité et le budget alloué.

Toutefois, il s’agit d’un choix crucial car la modification d’une stratégie de construction d’une application peut être irrémédiable donc un choix qui a de forte chance de perdurer.

Prérequis

Il est possible de lancer Openshift localement avec Minishift. Il s’agit d’un projet open-source forké du projet MiniKube. L’installation et l’utilisation de Minishift est expliquée ici.

Après l’installation de Minishift et le démarrage du cluster OpenShift, vous devez avoir accès à OpenShift via la console Web ou l’OC Cli (command line interface).

Pour tester l’accès à la console web, il suffit d’utiliser le Cli Minishift :

$ minishift console

La console web d’authentification est ouverte dans votre browser. Vous saisissez admin/admin et vous êtes connecté en tant qu’administrateur.

Vérifiez qu’il y a bien le projet default avec les applications suivantes :

  • docker-registry : le registry Docker d’OpenShift.
  • router : le service routeur d’OpenShift.

Pour tester l’accès via l’OC Cli, vous remplacez l’adresse IP par celle de votre cluster (à récupérer au niveau de l’adresse url de la console web ou via la ligne de commande : minishift ip) :

$ oc login https://192.168.99.100:8443 -u admin -p admin
Login successful.

You have access to the following projects and can switch between them with 'oc project <projectname>':

  * default
    kube-system
    openshift
    openshift-infra

Using project "default".

$ oc get pods
NAME                             READY     STATUS     RESTARTS   AGE  
docker-registry-1-palm8       1/1       Running            2          105d  
router-1-25ofa                       1/1       Running            12         187d

Je vous conseille pour la suite de créer un nouveau projet de test qu’on peut nommer “poc” :

$ oc new-project poc2
Now using project "poc2" on server "https://192.168.64.2:8443"  

et vérifiez que vous pointez sur le bon projet. Dans notre exemple, ceci est bien le cas puisqu'il y a une étoile juste au niveau du projet “poc”.

$ oc projects
You have access to the following projects and can switch between them with 'oc project <projectname>':

    default
    kube-system
    openshift
    openshift-infra
  * poc

Stratégies de build dans OpenShift

Avant d’évoquer les différentes stratégies de build d’une application dans OpenShift, il est important de savoir que l’étape de build pourrait également se faire en dehors. OpenShift ne ferait ainsi que le déploiement de votre application.

Par contre, il est nécessaire de construire une image Docker de votre application en respectant les règles définies par OpenShift et de pusher cette image dans le registry OpenShift.

Source-To-Image (S2I)

Il s’agit d’un outil autonome qu’on peut utiliser hors OpenShift pour construire une image Docker à partir des sources de l’application.

Si vous voulez utiliser S2I hors Openshift, vous pouvez télécharger la dernière version ici.

Les étapes importantes du S2I sont le suivantes :

  1. Récupérer les sources applicatives.
  2. Injecter ces sources dans une builder image.

Une builder image contient tout ce qu’il faut pour construire l’image Docker (scripts assembly, binaires, …).

Exécuter le script assembly présent dans le builder image qui construit l’application.

Dans OpenShift, vous déclenchez le S2I à partir de la commande oc new-app en précisant la stratégie de build source .

Prenons l’exemple suivant pour builder une application web :

oc new-app registry.access.redhat.com/jboss-webserver-3/webserver31-tomcat7-openshift:1.0-10~https://github.com/akramWewe/openshift-examples.git --context-dir=/helloworld --strategy=source  

webserver31-tomcat7-openshift:1.0-10 est une S2I image builder qui permet de construire l’application ayant le code source localisé dans
https://github.com/akramWewe/openshift-examples.git.

Nous aurions aussi pu lancer cette commande sans préciser l’image builder. Dans ce cas, new-app détermine quel type d’application vous voulez construire en examinant les fichiers présents à la racine de votre application.
Par exemple, pour les applications JEE, new-app vérifie l'existence d’un pom.xml (Maven) à la racine.
La liste complète des langages que new-app sait déterminer est détaillée ici.

Docker Build

La stratégie de build Docker invoque la commande Docker build.
Le repository renseigné doit préciser une application ayant un DockerFile et les ressources nécessaires à la construction de l’application :

oc new-app https://github.com/akramWewe/labs.git  --context-dir=/beginner/static-site/  

Custom

Cette stratégie, similaire à celle de Docker, permet aux développeurs de spécifier un builder image responsable de l’ensemble du process de build.

Un builder image est une image Docker qui intègre le processus de build de votre application. Pour pouvoir le faire, il est donc nécessaire de rajouter l’install d’un daemon dans le builder image ayant la même version que le client Docker.

À son invocation, une liste de variables d’environnements est passée à l’image builder. Il n’est pas obligatoire de toutes les renseigner, par contre certaines sont nécessaires pour le build de votre application. Il est toutefois suffisant d’utiliser la variable d'environnement *BUILD * avec un objet JSON comme valeur. L’objet JSON regroupe dans son contenu tout ce qui est nécessaire au build.

L’image openshift/origin-custom-docker-builder est un bon exemple d’une image builder. À son exécution, le script /tmp/build.sh est exécuté et effectue le build de l’image applicative, en se basant sur des variables d’environnement :

  • SOURCE_REPOSITORY : L’url du code source de l’application
  • SOURCE_REF : La branche ou le tag des sources
  • OUTPUT_IMAGE : Le nom de l’image à construire

La stratégie custom est à préciser au niveau du buildConfig. Aujourd’hui, il n’y a pas moyen de préciser ce type de stratégie avec la propriété strategy de oc new-app. Les valeurs possibles de la propriété strategy sont source et docker.

Voici un exemple de la partie buildConfig qui spécifie les détails de la stratégie custom à appliquer pour le build :

 type: Custom
    customStrategy:
      from:
        kind: DockerImage
        name: 'openshift/origin-custom-docker-builder:latest'
      env:
        -
          name: SOURCE_REPOSITORY
          value: 'https://github.com/akramWewe/OpenShiftLabs.git'
      exposeDockerSocket: true

Ici nous remarquons que la propriété exposeDockerSocket a pour valeur true.
Ceci permet au conteneur du build d’avoir accès au socket Docker et ainsi pouvoir lancer les commandes telles que docker build.

Vérification du bon déroulement du build

Au lancement d’un build dans OpenShift, un objet OpenShift est créé : buildConfig.
Il s’agit d’un objet OpenShift portant toutes les informations nécessaires concernant votre build (strategy, url gestionnaire de sources, …).

Ainsi, pour avoir des informations concernant votre build, vous pouvez utiliser :

La console Web

Au niveau de Builds -> Builds, nous constatons qu’il y a bien eu un build de type Source terminé avec succès et nous avons bien l’url de source applicative :

Pour chaque build, OpenShift génère un nouveau buildConfig qu’on peut modifier ou relancer.

À partir de la console web, au niveau de la page des Builds (Menu gauche : Builds -> Builds), vous avez accès à l’ensemble des builds exécutés pour votre application. Vous avez accès aux statuts des différents builds. Il est aussi possible de relancer un build, éditer le buildConfig ou le supprimer.

Vous pouvez accéder aussi aux logs de l’un de vos builds. Il suffit de choisir le build qui vous intéresse. Dans notre cas, nous avons choisi le seul build qui existe :

Pour accéder aux logs, il suffit de cliquer sur “Logs”. Il est aussi possible de modifier le buildConfig utilisé pour ce build et le relancer.

L’utilisation de l’imageStream dans OpenShift est très intéressante pour pouvoir bénéficier de certaines actions automatiquement (builds, déploiements ... ) dès la modification de la version de l’image applicative. À la création d’une nouvelle application avec oc new-app, l’image est par défaut ajoutée au niveau de l’imageStream du nameSpace de l’application.

L’imageStream comprend des images Docker qui peuvent provenir de plusieurs sources : le registry Docker OpenShift, un registry externe ou un autre ImageStream.

Au niveau de la page image Streams (Menu gauche: Builds -> Images), nous constatons qu’il y a deux nouvelles images Docker qui ont été ajoutées :

OC Cli

Avec le OC Cli, vous avez la possibilité de consulter le statut, les logs de vos builds, ainsi que les différents objects OpenShift créés suite à votre build.

Pour récupérer l'ensemble des buildConfigs (bc) :

$ oc get bc
NAME                 TYPE      FROM      LATEST  
openshift-examples   Source    Git       1

Pour avoir le détail concernant un buildConfig :

$oc describe bc openshift-examples

Name:        openshift-examples  
Namespace:    poc  
Created:    2 days ago  
(...)

Pour afficher la log d’un build :

$ oc logs bc/openshift-examples

Cloning "https://github.com/akramWewe/openshift-examples.git" ...  
    Commit: 0d49eb300863b5fa8e8e60cdffffaaf46ecd6459 (Add example standalone-openshift.xml configuration to perform manual RH-SSO ..)
    Author: Jan Lieskovsky <jlieskov@redhat.com>
    Date:   Wed May 10 11:58:59 2017 +0200

Found pom.xml... attempting to build with 'mvn -e -Popenshift -DskipTests -Dcom.redhat.xpaas.repo.redhatga package --batch-mode -Djava.net.preferIPv4Stack=true '  
(...)

Il est aussi possible d’éditer directement un build et le relancer :

$ oc edit bc openshift-examples
⇒ Afficher le yaml du buildConfig pour l’éditer.

$ oc start-build openshift-examples
build "openshift-examples-2" started  

Si vous voulez éditer le buildConfig avec votre éditeur de texte préféré et modifier après le buildConfig de votre application :

Sauvegarde du buildConfig avec le format json :

$ oc get bc/labs -o json > labs.json 

Une fois que vos modifications sont faites sur labs.json, vous pourrez effectuer le remplacement du buildConfig dans OpenShift et lancer un build :

$ oc replace -f labs.json
$ oc start-build bc/labs

Pour connaître les différentes propriétés d’un build config :

oc explain bc  
DESCRIPTION:  
BuildConfig is a template which can be used to create new builds.

FIELDS:  
   apiVersion    <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers 

(...)

Si vous voulez en savoir plus sur la propriété spec par exemple :

$ oc explain bc.spec
RESOURCE: spec <Object>

DESCRIPTION:  
     spec holds all the input necessary to produce a new build, and the
     conditions when to trigger them.

    BuildConfigSpec describes when and how builds are created

FIELDS:  
   serviceAccount    <string>
     serviceAccount is the name of the ServiceAccount to use to run the pod
     created by this build. The pod will be allowed to use secrets referenced by
     the ServiceAccount

   strategy    <Object> -required-
     strategy defines how to perform a build.
(...)

Pour consulter l’ensemble des images présentes au niveau de l’imageStream (is) :

$ oc get is
NAME                            DOCKER REPO                                           TAGS      UPDATED  
labs                            172.30.28.57:5000/poc/labs                            latest    3 days ago  
nginx                           172.30.28.57:5000/poc/nginx                           latest    3 days ago  
openshift-examples              172.30.28.57:5000/poc/openshift-examples              latest    3 days ago  
webserver31-tomcat7-openshift   172.30.28.57:5000/poc/webserver31-tomcat7-openshift   1.0-10    3 days ago  

Triggers

GitHub Trigger

Il est utile de déclencher un build automatique au niveau OpenShift dès que le code source dans le gestionnaire de sources est modifié. OpenShift supporte la gestion du webhook et particulièrement des sources localisées dans GitHub.

Prenons par exemple l’un des builds que nous avons effectué. Au niveau de Configuration, nous retrouvons le GitHub webhook URL à copier

Maintenant, il suffit de rajouter un webhook au niveau de votre GitHub puis de coller l’url Webhook copié depuis OpenShift vers la propriété Playload URL.

Changement de l’image Trigger

Ce trigger vous permet d’avoir toujours une image applicative à jour. Un nouveau build est déclenché dès que l’image en amont est modifiée.

Pour ce faire, le moyen le plus simple est de passer par la webConsole. Dans l’écran qui permet d’éditer un BuildConfig, vous pourrez activer le trigger Image change :

À son activation, un trigger est rajouté dans le BuildConfig :

    "triggers": [
                  {
            "type": "ImageChange",
            "imageChange": {
                "lastTriggeredImageID": "registry.access.redhat.com/jboss-webserver-3/webserver31-tomcat7-openshift@sha256:992790d31d40d882d3c231e213f8e4ddf53a749eee07e3a9"

        }
    ],

Ici, dès que la détection d’une nouvelle image webserver31-tomcat7-openshift est réalisée au niveau du registry, un nouveau build est lancé.

Il est possible de modifier le trigger pour que le build soit déclenché uniquement quand il y a une détection d’une nouvelle version de l’image webserver31-tomcat7-openshift dans l’imageStream :

        "triggers": [
                    {
                "type": "ImageChange",
                "imageChange": {
                    "from": {
                        "kind": "ImageStreamTag",
                        "name": "webserver31-tomcat7-openshift:1.0-10"
                    }
                }
            },

Modification de la configuration Trigger

Avec ce trigger, la modification du buildConfig déclenche un nouveau build. Ce trigger est ajouté systématiquement au niveau du buildConfig quand vous passez pas par oc new-app :

"triggers": [
            {
                "type": "ConfigChange"
            }
        ]

Conclusion

J’ai abordé dans cet article les différentes possibilités qu'offre OpenShift pour effectuer l’étape de build de votre application.

Maintenant que j’ai terminé la phase de build, j’aborderai dans la prochaine partie la phase de déploiement. Je montrerai comment déployer l’application dans OpenShift. Je détaillerai les différents objets OpenShift utiles lors de la phase de déploiement : configMap, secrets, route …

À très vite pour la suite !