OpenShift 3 - Partie 2 : Construire votre application
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.
Sommaire
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 :
- Récupérer les sources applicatives.
- 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 !
