Maj des fichiers
This commit is contained in:
parent
0adfa413ae
commit
e41bac359e
682
dkrun
682
dkrun
|
@ -16,7 +16,11 @@ USAGE
|
||||||
|
|
||||||
OPTIONS
|
OPTIONS
|
||||||
-m, --machine MACHINE
|
-m, --machine MACHINE
|
||||||
Sélectionner la machine spécifiée avant de dérouler le script
|
Sélectionner la machine spécifiée pour les opérations docker. Cette
|
||||||
|
option est incompatible avec --context
|
||||||
|
-M, --context CONTEXT
|
||||||
|
Sélectionner le contexte spécifié pour les opérations docker et
|
||||||
|
kubernetes. Cette option est incompatible avec --machine
|
||||||
|
|
||||||
-n, --no-build
|
-n, --no-build
|
||||||
Ne pas reconstruire l'image avant de déployer/exécuter l'application
|
Ne pas reconstruire l'image avant de déployer/exécuter l'application
|
||||||
|
@ -57,682 +61,6 @@ OPTIONS
|
||||||
"
|
"
|
||||||
}
|
}
|
||||||
|
|
||||||
function display_help_dkbuild() {
|
|
||||||
uecho "\
|
|
||||||
OPTIONS
|
|
||||||
--help Aide générale
|
|
||||||
* --hdk Aide sur le format du fichier dkbuild
|
|
||||||
--href Référence sur les commandes utilisables dans un fichier dkbuild
|
|
||||||
|
|
||||||
DKBUILD
|
|
||||||
=======
|
|
||||||
|
|
||||||
Un fichier dkbuild est un script shell utilisé pour construire une ou plusieurs
|
|
||||||
images docker.
|
|
||||||
|
|
||||||
A cause de l'implémentation utilisée pour les directives, le fichier doit être
|
|
||||||
parcouru (i.e exécuté) à de multiples reprises pour analyser les paramètres et
|
|
||||||
variables définis. il faut donc \"protéger\" les appels de scripts externes ou
|
|
||||||
de fonctions gourmandes avec les commandes 'run' et 'call' pour éviter que ces
|
|
||||||
commandes ne soient exécutées à plusieurs reprises.
|
|
||||||
|
|
||||||
Quand un fichier dkbuild est exécuté, le répertoire courant est toujours le
|
|
||||||
répertoire qui contient le fichier
|
|
||||||
|
|
||||||
## Distributions ###############################################################
|
|
||||||
|
|
||||||
Une distribution s'entend au sens de la distribution linux utilisée comme base
|
|
||||||
pour l'image construite. L'idée est de pouvoir construire des images similaires
|
|
||||||
qui ne diffèrent que par la version de base du système d'exploitation
|
|
||||||
|
|
||||||
Pour une même distribution, plusieurs versions d'une image peuvent être
|
|
||||||
construites. Une version est définie en ajoutant un préfixe à la distribution.
|
|
||||||
|
|
||||||
La commande 'setdists' permet de lister explicitement les distributions valides
|
|
||||||
(et les versions associées le cas échéant). Si la distribution sélectionnée par
|
|
||||||
l'utilisateur n'est pas dans la liste fournie, le script s'arrête sans erreur.
|
|
||||||
La première distribution listée est spéciale: c'est la distribution la plus
|
|
||||||
récente, celle qui reçoit le tag :latest
|
|
||||||
|
|
||||||
La commande 'dist' permet de tester si la distribution spécifiée en argument a
|
|
||||||
été sélectionnée par l'utilisateur. L'argument 'LATEST' permet de tester la
|
|
||||||
dernière distribution.
|
|
||||||
|
|
||||||
La commande 'version' permet de tester si la version spécifiée en argument a été
|
|
||||||
sélectionnée par l'utilisateur. On part du principe qu'une distribution a déjà
|
|
||||||
été testée au préalable avec 'dist'
|
|
||||||
|
|
||||||
Exemple:
|
|
||||||
setdists 3.0-d11 3.1-d11 d10 d9
|
|
||||||
if dist d11; then
|
|
||||||
if version 3.0; then
|
|
||||||
...
|
|
||||||
elif version 3.1; then
|
|
||||||
...
|
|
||||||
fi
|
|
||||||
elif dist d10; then
|
|
||||||
...
|
|
||||||
elif dist d9; then
|
|
||||||
...
|
|
||||||
fi
|
|
||||||
Dans une même distribution, les versions doivent être ordonnées de la plus
|
|
||||||
ancienne à la plus récente. ici, la version 3.1 est listée après la version 3.0
|
|
||||||
pour que l'image construite aie le tag :latest
|
|
||||||
|
|
||||||
Note: 'setdists' ne doit être utilisé qu'une seule fois. Les invocations
|
|
||||||
suivantes sont ignorées.
|
|
||||||
|
|
||||||
## Profils #####################################################################
|
|
||||||
|
|
||||||
Un profil correspond à l'environnement de destination de l'image: production,
|
|
||||||
test, développement.
|
|
||||||
|
|
||||||
La commande 'setprofiles' permet de lister explicitement les profils valides.
|
|
||||||
Si le profil sélectionné par l'utilisateur n'est pas dans la liste fournie, le
|
|
||||||
script s'arrête avec une erreur. Le premier profil listé est spécial: c'est le
|
|
||||||
profil par défaut.
|
|
||||||
|
|
||||||
La commande 'profile' permet de tester si le profil spécifié en argument a été
|
|
||||||
sélectionné par l'utilisateur. L'argument 'DEFAULT' permet de tester le profil
|
|
||||||
par défaut.
|
|
||||||
|
|
||||||
Exemple:
|
|
||||||
setprofiles prod devel
|
|
||||||
if profile prod; then
|
|
||||||
...
|
|
||||||
elif profile devel; then
|
|
||||||
...
|
|
||||||
fi
|
|
||||||
|
|
||||||
Si le build est indépendant de la distribution, ou si la distribution est
|
|
||||||
utilisée sans version, alors il est possible de préfixer le profil d'une
|
|
||||||
version. Exemple:
|
|
||||||
setprofiles v1-prod v2-prod
|
|
||||||
if profile prod; then
|
|
||||||
if version v1; then
|
|
||||||
...
|
|
||||||
elif version v2; then
|
|
||||||
...
|
|
||||||
fi
|
|
||||||
fi
|
|
||||||
Dans un même profil, les versions doivent être ordonnées de la plus ancienne à
|
|
||||||
la plus récente.
|
|
||||||
|
|
||||||
Si les distributions sont utilisées avec des versions, alors c'est une erreur de
|
|
||||||
spécifier une version dans le profil
|
|
||||||
|
|
||||||
Note: 'setprofiles' ne doit être utilisé qu'une seule fois. Les invocations
|
|
||||||
suivantes sont ignorées.
|
|
||||||
|
|
||||||
## Versions ####################################################################
|
|
||||||
|
|
||||||
Si la version de l'image à construire n'est liée ni à la distribution, ni au
|
|
||||||
profil, il est possible de la spécifier avec la commande 'setversion'. La
|
|
||||||
version spécifiée avec 'setversion' est utilisée par défaut pour toutes les
|
|
||||||
images dont la version n'est pas spécifiée dans la distribution ou le profil.
|
|
||||||
|
|
||||||
La commande 'setversion' est évaluée en même temps que les commandes 'setenv',
|
|
||||||
ainsi il est possible d'utiliser la valeur d'une variable définie au préalable.
|
|
||||||
|
|
||||||
## Environnement ###############################################################
|
|
||||||
|
|
||||||
La commande 'machine' permet de tester si le build est fait sur la machine
|
|
||||||
spécifiée. Ce peut être la machine courante, ou la machine spécifiée avec
|
|
||||||
l'option --machine de la commande build
|
|
||||||
|
|
||||||
Exemple:
|
|
||||||
if machine host{1,2,3}-prod; then
|
|
||||||
setprofiles prod
|
|
||||||
elif machine host{1,2,3}-test; then
|
|
||||||
setprofiles test
|
|
||||||
else
|
|
||||||
setprofiles devel test prod
|
|
||||||
fi
|
|
||||||
|
|
||||||
Les variables sont de deux types: argument de build ou variable d'environnement
|
|
||||||
|
|
||||||
La commande 'setenv' permet de définir une variable d'environnement. La commande
|
|
||||||
'setarg' permet de définir un argument de build. Ces valeurs sont alors
|
|
||||||
automatiquement utilisées à l'endroit approprié.
|
|
||||||
|
|
||||||
Ces commandes acceptent une liste d'argument de la forme VAR[=VALUE]
|
|
||||||
|
|
||||||
Si la valeur n'est pas spécifiée (e.g 'setarg DESTDIR'), alors la variable doit
|
|
||||||
être définie dans l'environnement courant. Si la variable n'est pas définie dans
|
|
||||||
l'environnement, alors le script s'arrête avec une erreur.
|
|
||||||
|
|
||||||
Une fois qu'une variable est définie, il n'est plus possible de la modifier. Les
|
|
||||||
commandes alternatives 'resetenv' et 'resetarg' permettent de pallier cette
|
|
||||||
limitation.
|
|
||||||
|
|
||||||
## Valeurs par défaut ##########################################################
|
|
||||||
|
|
||||||
Toutes les commandes ont des arguments requis, mais aussi des arguments
|
|
||||||
facultatifs qui sont fournis sous la forme d'une liste d'éléments VAR=VALUE
|
|
||||||
|
|
||||||
La commande 'default' permet de spécifier les valeurs par défaut de ces
|
|
||||||
arguments. Exemple:
|
|
||||||
if profile prod; then
|
|
||||||
default composer mode=production
|
|
||||||
elif profile devel; then
|
|
||||||
default composer mode=development
|
|
||||||
fi
|
|
||||||
composer install path/to/project
|
|
||||||
|
|
||||||
Une fois qu'une valeur par défaut est définie, il n'est plus possible de la
|
|
||||||
modifier. La commande alternative 'resetdefault' permet de pallier cette
|
|
||||||
limitation.
|
|
||||||
|
|
||||||
Définir des valeurs par défaut pour la commande 'docker' impacte la commande
|
|
||||||
'build' et toutes les commandes qui utilisent docker, comme 'composer' ou 'mvn'
|
|
||||||
|
|
||||||
## Synchronisation de fichiers #################################################
|
|
||||||
|
|
||||||
On peut vouloir s'assurer de la présence de certains fichiers à certains
|
|
||||||
endroits.
|
|
||||||
|
|
||||||
La commande 'checkout URL DESTDIR' permet de s'assurer qu'un checkout du dépôt
|
|
||||||
spécifié existe dans le répertoire DESTDIR. La branche ou le commit à utiliser,
|
|
||||||
la source en mode développement, etc. peuvent être spécifiés par des arguments
|
|
||||||
facultatifs.
|
|
||||||
|
|
||||||
La commande 'copy SRC DEST' permet de s'assurer que SRC et DEST sont
|
|
||||||
synchronisés. Si possible, des liens physiques sont créés pour conserver
|
|
||||||
l'espace disque. Par défaut, les fichiers ne sont créés que s'ils n'existent
|
|
||||||
pas.
|
|
||||||
|
|
||||||
## Support Composer, Maven, commandes génériques ###############################
|
|
||||||
|
|
||||||
La commande 'composer install' permet d'installer les dépendances Composer d'un
|
|
||||||
projet
|
|
||||||
|
|
||||||
La commande 'mvn package' permet de construire un projet Java.
|
|
||||||
|
|
||||||
La commande 'run' permet de lancer une commande quelconque. La commande est
|
|
||||||
cherchée dans le PATH et exécutée avec son chemin complet. celà permet de lancer
|
|
||||||
des commandes comme 'mvn' ou 'composer' ou dont le nom correspond à une fonction
|
|
||||||
déjà définie.
|
|
||||||
|
|
||||||
La commande 'call' permet de lancer une commande quelconque. La différence avec
|
|
||||||
'run' est que la commande est lancée telle quelle, sans modifications. Si une
|
|
||||||
fonction est définie, elle sera utilisée en priorité.
|
|
||||||
|
|
||||||
Si elles sont utilisées sans argument, les commandes 'composer', 'mvn', 'run' et
|
|
||||||
'call' retournent vrai si la commande doit être exécutée dans le contexte
|
|
||||||
courant. Celà permet d'implémenter des traitements complexes. Ainsi le script
|
|
||||||
suivant:
|
|
||||||
run cmd1
|
|
||||||
run cmd2
|
|
||||||
est équivalent à:
|
|
||||||
if run; then
|
|
||||||
cmd1
|
|
||||||
cmd2
|
|
||||||
fi
|
|
||||||
|
|
||||||
En phase d'analyse, ces commandes retournent faux, donc cmd1 et cmd2 ne seront
|
|
||||||
lancés qu'une seule fois lors de l'invocation de dkbuild. Cela signifie qu'il ne
|
|
||||||
faut pas utiliser des directives de définition de variables à l'intérieur. Par
|
|
||||||
exemple, le script suivant ne produit pas forcément l'effet escompté:
|
|
||||||
if run; then
|
|
||||||
setenv var=value
|
|
||||||
default
|
|
||||||
cmd args...
|
|
||||||
fi
|
|
||||||
|
|
||||||
Bien entendu, si on veut être sûr que des commandes externes soient lancées, on
|
|
||||||
peut toujours utiliser 'run' à l'intérieur, e.g
|
|
||||||
if composer; then
|
|
||||||
run extcmd
|
|
||||||
func
|
|
||||||
composer args...
|
|
||||||
fi
|
|
||||||
|
|
||||||
## Support Dockerfile et docker build ##########################################
|
|
||||||
|
|
||||||
La commande 'dockerfile OUTPUT' permet de construire de façon incrémentale et
|
|
||||||
dynamique un fichier Dockerfile. Toutes les commandes d'un fichier dockerfile
|
|
||||||
traditionnelles sont reconnues et elles doivent être spécifiées après la
|
|
||||||
commande 'dockerfile'.
|
|
||||||
|
|
||||||
La commande 'build' termine la construction du fichier Docker puis lance la
|
|
||||||
construction de l'image.
|
|
||||||
* arguments de build: les arguments de build définis dans le script sont passés
|
|
||||||
à docker pour la construction de l'image
|
|
||||||
* nom de l'image et tag: par défaut, la variable d'environnement IMAGE est
|
|
||||||
combinée le cas échéant avec DIST et VERSION pour déterminer les tags que
|
|
||||||
reçoit l'image construite.
|
|
||||||
|
|
||||||
La commande 'cbuild' lance le build de toutes les images mentionnées dans les
|
|
||||||
fichiers 'docker-compose.yml' et 'docker-compose.PROFILE.yml' le cas échéant
|
|
||||||
* variables d'environnement: les arguments de build définis sont inscrits dans
|
|
||||||
un fichier .env qui est utilisé ensuite par docker compose
|
|
||||||
|
|
||||||
Si aucune commande 'build' ou 'cbuild' ne figure dans le fichier, 'build' est
|
|
||||||
lancé automatiquement à la fin
|
|
||||||
|
|
||||||
## Autres commandes ############################################################
|
|
||||||
|
|
||||||
Il est possible d'organiser le script dans plusieurs fichiers qui sont inclus
|
|
||||||
avec la commande 'include'. Fonctionnellement, cela se passe comme si le contenu
|
|
||||||
du fichier inclus était inséré dans le script principal, à ceci près que le
|
|
||||||
répertoire courant devient temporairement celui du fichier inclus.
|
|
||||||
|
|
||||||
Exemple:
|
|
||||||
setdists d11 d10 d9
|
|
||||||
if dist d9; then
|
|
||||||
include d9/dkbuild
|
|
||||||
elif dist d10; then
|
|
||||||
include d10/dkbuild
|
|
||||||
elif dist d11; then
|
|
||||||
include d11/dkbuild
|
|
||||||
fi
|
|
||||||
|
|
||||||
La commande 'dkbuild' lance le build d'un répertoire destination. La différence
|
|
||||||
avec 'include' est que cela est fait dans un processus complètement différent,
|
|
||||||
comme si le build avait été lancé depuis la ligne de commande.
|
|
||||||
|
|
||||||
Les commandes 'section', 'note', 'info', 'debug' permettent d'afficher des
|
|
||||||
messages de différents niveaux
|
|
||||||
|
|
||||||
## Variables globales ##########################################################
|
|
||||||
|
|
||||||
PROJDIR est le chemin absolu du projet, dans lequel se trouve le fichier dkbuild
|
|
||||||
initial
|
|
||||||
|
|
||||||
La distribution actuellement sélectionnée se trouve dans la variable DIST. La
|
|
||||||
version actuellement sélectionnée se trouve dans la variable VERSION. Si la
|
|
||||||
commande 'setdists' n'est pas utilisée, alors ni DIST ni VERSION ne sont définis
|
|
||||||
|
|
||||||
Le profil actuellement sélectionné se trouve dans la variable PROFILE. La
|
|
||||||
version actuellement sélectionnée se trouve dans la variable VERSION (si les
|
|
||||||
distributions sont utilisées sans le support de la version). Si la commande
|
|
||||||
'setprofiles' n'est pas utilisée, alors ni PROFILE ni VERSION ne sont définis
|
|
||||||
|
|
||||||
IMAGE est le nom de l'image à construire. Si le nom de l'image contient le tag
|
|
||||||
(e.g IMAGE:TAG) alors le nom est utilisé tel quel. Sinon, DIST et VERSION sont
|
|
||||||
utilisés comme tags (i.e IMAGE:DIST et IMAGE:VERSION-DIST)"
|
|
||||||
}
|
|
||||||
|
|
||||||
function display_help_reference() {
|
|
||||||
uecho "\
|
|
||||||
OPTIONS
|
|
||||||
--help Aide générale
|
|
||||||
--hdk Aide sur le format du fichier dkbuild
|
|
||||||
* --href Référence sur les commandes utilisables dans un fichier dkbuild
|
|
||||||
|
|
||||||
REFERENCE
|
|
||||||
=========
|
|
||||||
|
|
||||||
## fonctions d'affichage
|
|
||||||
|
|
||||||
USAGE:
|
|
||||||
section TITLE
|
|
||||||
note MESSAGE
|
|
||||||
info MESSAGE
|
|
||||||
debug MESSAGE
|
|
||||||
|
|
||||||
## machine -- vérifier la machine courante
|
|
||||||
|
|
||||||
## setdists -- spécifier les distributions valides
|
|
||||||
|
|
||||||
## dist -- vérifier la distribution courante
|
|
||||||
|
|
||||||
## setprofiles -- spécifier les profils valides
|
|
||||||
|
|
||||||
## profile -- vérifier le profil courant
|
|
||||||
|
|
||||||
## setversion -- spécifier la version par défaut
|
|
||||||
|
|
||||||
USAGE: setversion VERSION
|
|
||||||
|
|
||||||
Les paramètres optionnels sont
|
|
||||||
* from-file=FILE
|
|
||||||
prendre la version depuis le fichier spécifié. les formats pom.xml et
|
|
||||||
VERSION.txt sont supportés
|
|
||||||
* from-repo=REPO
|
|
||||||
calculer la version depuis le dépôt git spécifié
|
|
||||||
* from-glob=GLOB
|
|
||||||
calculer la version depuis le chemin spécifié
|
|
||||||
* extract=REGEXP
|
|
||||||
à partir de la valeur calculée par l'un des paramètres from-*, matcher
|
|
||||||
l'expression régulière au format AWK, et prendre comme version la valeur de
|
|
||||||
l'expression \$1
|
|
||||||
Si from-glob est spécifié, la valeur par défaut de extract est calculée en
|
|
||||||
remplaçant '*' par '(.*)'
|
|
||||||
* add-prefix=PREFIX
|
|
||||||
Ajouter le préfixe spécifié à la version extraite
|
|
||||||
* add-suffix=SUFFIX
|
|
||||||
Ajouter le suffixe spécifié à la version extraite
|
|
||||||
|
|
||||||
## version -- vérifier la version courante
|
|
||||||
|
|
||||||
## setenv -- spécifier une variable d'environnement
|
|
||||||
|
|
||||||
## resetenv -- spécifier une variable d'environnement
|
|
||||||
|
|
||||||
## setarg -- spécifier une variable de build
|
|
||||||
|
|
||||||
## resetarg -- spécifier une variable de build
|
|
||||||
|
|
||||||
## default -- spécifier des arguments par défaut
|
|
||||||
|
|
||||||
## resetdefault -- spécifier des arguments par défaut
|
|
||||||
|
|
||||||
## checkout -- faire et vérifier checkout d'un dépôt git
|
|
||||||
|
|
||||||
USAGE: checkout URL [DESTDIR] [PARAMS]
|
|
||||||
|
|
||||||
Les paramètres optionnels sont
|
|
||||||
* checkout
|
|
||||||
mettre à jour dépôt. c'est la valeur par défaut. utiliser checkout= pour
|
|
||||||
désactiver la mise à jour du dépôt. utiliser checkout=devel pour synchroniser
|
|
||||||
depuis le répertoire de développement.
|
|
||||||
* origin=ORIGIN
|
|
||||||
spécifier l'origine. Par défaut, prendre 'origin'
|
|
||||||
* branch=BRANCH
|
|
||||||
spécifier la branche à utiliser dans l'origine spécifiée. La valeur par défaut
|
|
||||||
est 'master' si les profils ne sont pas utilisé. Si les profils sont utilisés,
|
|
||||||
la valeur par défaut est 'develop' pour les profils 'test' et 'devel', sinon
|
|
||||||
c'est 'master'.
|
|
||||||
Utiliser la syntaxe ^COMMIT pour ignorer l'origine et sélectionner un commit
|
|
||||||
en particulier.
|
|
||||||
* develdir=DIR
|
|
||||||
spécifier l'emplacement du répertoire de développement, utilisé avec
|
|
||||||
checkout=devel
|
|
||||||
* develtype=TYPE
|
|
||||||
spécifier le type de projet pour la synchronisation depuis le répertoire de
|
|
||||||
développement. certains projets, notamment les projets composer avec des
|
|
||||||
dépendances de type 'path', nécessitent une méthode de synchronisation
|
|
||||||
particulière. Si ce paramètre n'est pas spécifié, il est auto-détecté. Les
|
|
||||||
valeurs supportées sont:
|
|
||||||
* composer -- détecté de par la présence d'un fichier composer.json
|
|
||||||
* maven -- détecté de par la présence d'un fichier pom.xml
|
|
||||||
* none -- valeur par défaut: pas de type particulier
|
|
||||||
|
|
||||||
## copy -- synchroniser des fichiers
|
|
||||||
|
|
||||||
USAGE: copy SRC DEST [PARAMS]
|
|
||||||
|
|
||||||
Si SRC est un fichier, alors DEST doit être un chemin vers le fichier
|
|
||||||
destination. Si SRC est un répertoire, alors DEST doit être un chemin vers le
|
|
||||||
répertoire destination. On peut forcer à considérer SRC et/ou DEST comme un
|
|
||||||
répertoire en les suffixant de '/'
|
|
||||||
|
|
||||||
Par exemple:
|
|
||||||
* copy SRCDIR/ DESTDIR/
|
|
||||||
échoue si SRCDIR et/ou DESTDIR sont des fichiers
|
|
||||||
* les commandes suivantes sont équivalentes:
|
|
||||||
copy SRC DESTDIR/
|
|
||||||
copy SRC DESTDIR/SRCNAME
|
|
||||||
|
|
||||||
Les paramètres optionnels sont
|
|
||||||
* copy
|
|
||||||
synchroniser les fichiers. c'est la valeur par défaut. utiliser copy= pour
|
|
||||||
désactiver la synchronisation des fichiers.
|
|
||||||
* overwrite
|
|
||||||
autoriser l'écrasement des fichiers destination, ce qui permet de rendre la
|
|
||||||
destination identique à la source. par défaut, un fichier destination est
|
|
||||||
laissé en place, ce qui permet d'avoir le cas échéant des fichiers locaux
|
|
||||||
différents de la source.
|
|
||||||
* gitignore=BASEDIR
|
|
||||||
maintenir le fichier .gitignore de BASEDIR, qui doit être un répertoire parent
|
|
||||||
de DESTDIR. Les fichiers synchronisés sont rajouté le cas échéant dans
|
|
||||||
.gitignore, sauf si le répertoire qui les contient est déjà exclu.
|
|
||||||
NB: Un fichier n'est considéré pour l'ajout dans .gitignore que s'il a été
|
|
||||||
copié au préalable. Ainsi, un fichier déjà existant dans la destination ne
|
|
||||||
sera pas ajouté dans le fichier .gitignore si overwrite=
|
|
||||||
|
|
||||||
## genfile -- créer un fichier générique
|
|
||||||
|
|
||||||
USAGE: genfile OUTPUT [INPUT] [PARAMS]
|
|
||||||
|
|
||||||
Si le fichier INPUT est spécifié, il est utilisé pour créer le contenu initial
|
|
||||||
du fichier. Sinon, l'entrée standard *doit* être redirigée depuis un fichier, et
|
|
||||||
elle est lue pour générer le contenu initial du fichier à générer.
|
|
||||||
|
|
||||||
Les paramètres optionnels sont
|
|
||||||
* context=DIR
|
|
||||||
générer le fichier dans le répertoire spécifié
|
|
||||||
* sed=SCRIPT
|
|
||||||
script sed à appliquer au fichier
|
|
||||||
|
|
||||||
## dockerfile -- créer un fichier Dockerfile
|
|
||||||
|
|
||||||
USAGE: dockerfile [OUTPUT [INPUT]] [PARAMS]
|
|
||||||
|
|
||||||
Si le fichier INPUT est spécifié, il est utilisé pour créer le contenu initial
|
|
||||||
du fichier. Sinon, *si* l'entrée standard est redirigée depuis un fichier, elle
|
|
||||||
est lue pour générer le contenu initial du fichier.
|
|
||||||
|
|
||||||
Les paramètres optionnels sont
|
|
||||||
* context=DIR
|
|
||||||
générer le fichier dans le répertoire spécifié
|
|
||||||
* sed=SCRIPT
|
|
||||||
script sed à appliquer au fichier initial, construit à partir de l'entrée
|
|
||||||
standard. Le fichier n'est plus modifié par la suite.
|
|
||||||
|
|
||||||
## build -- construire une image avec docker
|
|
||||||
|
|
||||||
USAGE: build [PARAMS]
|
|
||||||
|
|
||||||
Les paramètres optionnels sont
|
|
||||||
* build
|
|
||||||
construire les images, c'est la valeur par défaut. utiliser build= pour
|
|
||||||
désactiver la construction.
|
|
||||||
* context=DIR
|
|
||||||
répertoire de contexte. cette valeur est en principe générée automatiquement
|
|
||||||
par la commande 'dockerfile'
|
|
||||||
* dockerfile=FILE
|
|
||||||
fichier de build à utiliser. cette valeur est en principe générée automatiquement
|
|
||||||
par la commande 'dockerfile'
|
|
||||||
* no-cache
|
|
||||||
ne pas utiliser le cache
|
|
||||||
* pull
|
|
||||||
forcer la mise à jour des images dépendantes
|
|
||||||
* host-mappings=MAPPINGS
|
|
||||||
définir des mappings d'hôte. si ce paramètre n'est pas spécifié, consulter
|
|
||||||
aussi la valeur par défaut 'docker host-mappings='
|
|
||||||
* set-tag=TAGS... ou set-tags=TAGS...
|
|
||||||
spécifier des tags à rajouter au nom de l'image, séparés par un espace. cette
|
|
||||||
liste remplace celle calculée automatiquement. ce paramètre est ignoré pour
|
|
||||||
les noms d'images comportant un tag
|
|
||||||
* add-tag=TAGS... ou add-tags=TAGS...
|
|
||||||
spécifier des tags à rajouter à la liste calculée automatiquement, séparés par
|
|
||||||
un espace. ce paramètre est ignoré pour les noms d'images comportant un tag
|
|
||||||
* image=IMAGES... ou images=IMAGES...
|
|
||||||
liste de nom d'images, séparés par un espace. si les noms n'ont pas de tag, le
|
|
||||||
tag est construit à partir de DIST et VERSION sous la forme [VERSION-]DIST
|
|
||||||
* push
|
|
||||||
pousser les images vers le registry après les avoir construites
|
|
||||||
|
|
||||||
## cbuild -- construire une image avec docker compose
|
|
||||||
|
|
||||||
USAGE: cbuild [SERVICE] [PARAMS]
|
|
||||||
|
|
||||||
Les paramètres optionnels sont
|
|
||||||
* files=FILES...
|
|
||||||
spécifier les fichiers docker-compose à utiliser. Par défaut, prendre
|
|
||||||
docker-compose.yml et docker-compose.PROFILE.yml
|
|
||||||
* project-name=PROJECT_NAME
|
|
||||||
spécifier le nom du projet
|
|
||||||
* no-cache
|
|
||||||
ne pas utiliser le cache
|
|
||||||
* pull
|
|
||||||
forcer la mise à jour des images dépendantes
|
|
||||||
|
|
||||||
## include -- inclure un autre fichier dkbuild
|
|
||||||
|
|
||||||
## dkbuild -- lancer un builder externe
|
|
||||||
|
|
||||||
La commande dkbuild qui traite le script de build courant est lancée telle
|
|
||||||
quelle, avec la même syntaxe qu'en ligne de commande. L'intérêt de cette
|
|
||||||
commande est qu'on est assuré d'utiliser le même dkbuild que celui qui traite le
|
|
||||||
script de build courant.
|
|
||||||
|
|
||||||
## composer -- gérer projet composer
|
|
||||||
|
|
||||||
USAGE: composer DESTDIR [ACTION [PARAMS] [ARGS]]
|
|
||||||
|
|
||||||
La destination est obligatoire. Sans arguments, cette commande retourne
|
|
||||||
simplement vrai
|
|
||||||
|
|
||||||
Les actions valides sont
|
|
||||||
* install -- installer les dépendances. c'est l'action par défaut
|
|
||||||
* update -- mettre à jour les dépendances
|
|
||||||
* rshell -- lancer un shell root dans le répertoire du projet
|
|
||||||
* shell -- lancer un shell utilisateur dans le répertoire du projet
|
|
||||||
* none -- ne rien faire
|
|
||||||
|
|
||||||
L'action est exécutée sur DESTDIR. Juste avant de lancer l'action, le répertoire
|
|
||||||
courant est modifié pour être DESTDIR, ce qui permet d'utiliser des chemins
|
|
||||||
relatifs le cas échéant.
|
|
||||||
|
|
||||||
La commande 'rshell' lance un shell bash avec l'utilisateur root au lieu de
|
|
||||||
lancer la commande composer, ce qui permet de faire des opérations plus
|
|
||||||
complexes si le besoin s'en fait sentir. La commande alternative 'shell' lance
|
|
||||||
le shell avec le compte utilisateur. Ces commandes sont particulièrement utiles
|
|
||||||
si composer est paramétré pour être lancé dans un container
|
|
||||||
|
|
||||||
Les paramètres optionnels sont
|
|
||||||
* args=ARGS...
|
|
||||||
arguments à rajouter à la commande composer. La valeur par défaut dépend du
|
|
||||||
profil:
|
|
||||||
* prod: --no-dev -o
|
|
||||||
* test: --no-dev -o
|
|
||||||
* autres profils: (pas d'arguments)
|
|
||||||
* php=VERSION
|
|
||||||
version de PHP en dessous de laquelle image= est utilisé. En d'autres termes,
|
|
||||||
c'est la version minimum de PHP nécessaire pour faire tourner composer. L'idée
|
|
||||||
est que si la version de PHP installée est suffisante, il n'est pas nécessaire
|
|
||||||
de passer par une image docker.
|
|
||||||
Cette valeur doit être spécifiée avec le format de PHP_VERSION_ID i.e 70300
|
|
||||||
pour PHP 7.3
|
|
||||||
* Spécifier 'any' ou 'force' pour forcer l'utilisation de l'image docker.
|
|
||||||
* Spécifier 'none' ou 'system' pour lancer directement composer sans passer
|
|
||||||
par une image docker.
|
|
||||||
* php-max=VERSION
|
|
||||||
version de PHP à partir de laquelle image= est utilisé. En d'autres termes,
|
|
||||||
c'est la version maximum de PHP, à partir de laquelle il faut passer par une
|
|
||||||
image docker. L'idée est que si la version de PHP installée est trop récente,
|
|
||||||
ça peut poser problème avec le calcul des dépendances.
|
|
||||||
Cette valeur doit être spécifiée avec le format de PHP_VERSION_ID i.e 70300
|
|
||||||
pour PHP 7.3
|
|
||||||
Si la valeur n'est pas spécifiée ou vaut 'none', elle est ignorée.
|
|
||||||
* image=COMPOSER_IMAGE
|
|
||||||
image docker utilisée pour lancer composer. La valeur par défaut est la valeur
|
|
||||||
de la variable d'environnement \$COMPOSER_IMAGE
|
|
||||||
Spécifier 'none' pour lancer directement composer sans passer par une image
|
|
||||||
docker.
|
|
||||||
L'image spécifiée doit disposer de la commande 'su-exec' afin de pouvoir
|
|
||||||
lancer la commande avec l'utilisateur courant. Le répertoire \$HOME est monté
|
|
||||||
à l'intérieur du container et le script composer.phar du projet est utilisé le
|
|
||||||
cas échéant.
|
|
||||||
* machine=MACHINE
|
|
||||||
nom de la docker machine sur laquelle se connecter pour lancer l'image docker.
|
|
||||||
La valeur par défaut est -u, ce qui force l'utilisation de l'instance docker
|
|
||||||
locale. Spécifier 'current' pour ne pas modifier la valeur courante le cas
|
|
||||||
échéant
|
|
||||||
* host-mappings=MAPPINGS
|
|
||||||
définir des mappings d'hôte. si ce paramètre n'est pas spécifié, consulter
|
|
||||||
aussi la valeur par défaut 'docker host-mappings='
|
|
||||||
* composer=PATH/TO/COMPOSER
|
|
||||||
chemin vers l'exécutable composer. Par défaut, utiliser composer.phar s'il
|
|
||||||
existe dans le répertoire du projet. Sinon utiliser /usr/bin/composer
|
|
||||||
* setup=CMDS...
|
|
||||||
liste de commandes à lancer pour configurer le container. Un container ayant
|
|
||||||
pour base COMPOSER_IMAGE et nommé d'après le nom du projet est préparé et les
|
|
||||||
commandes spécifiées y sont lancées. Ce container est réutilisé à chaque fois.
|
|
||||||
Ce paramétrage est utilisé par exemple pour installer certains packages
|
|
||||||
nécessaire au projet.
|
|
||||||
* project-name=PROJECT_NAME
|
|
||||||
si setup= est défini, nommer l'image sur la base de ce nom. par défaut, le nom
|
|
||||||
est calculé automatiquement
|
|
||||||
|
|
||||||
Si un fichier .composer.conf existe dans le répertoire du projet, il est sourcé
|
|
||||||
pour obtenir les valeurs par défaut des paramètres:
|
|
||||||
* COMPOSER_PHP -- valeur par défaut de php=
|
|
||||||
* COMPOSER_PHP_MAX -- valeur par défaut de php-max=
|
|
||||||
* COMPOSER_IMAGE -- valeur par défaut de image=
|
|
||||||
* COMPOSER_MACHINE -- valeur par défaut de machine=
|
|
||||||
* COMPOSER_CMD -- valeur par défaut de composer=
|
|
||||||
* COMPOSER_SETUP -- valeur par défaut de setup=
|
|
||||||
|
|
||||||
## mvn -- construire projet maven
|
|
||||||
|
|
||||||
USAGE: mvn DESTDIR [ACTION [PARAMS] [ARGS]]
|
|
||||||
|
|
||||||
Le répertoire de destination est obligatoire. Sans arguments, cette commande
|
|
||||||
retourne simplement vrai. L'action par défaut est 'package'
|
|
||||||
|
|
||||||
Les actions valides sont
|
|
||||||
* install -- lance mvn avec les commandes 'clean package install'
|
|
||||||
* package -- lance mvn avec les commandes 'clean package'
|
|
||||||
* package_only -- lance mvn avec uniquement la commande 'package'
|
|
||||||
* rshell -- lancer un shell root dans le répertoire du projet
|
|
||||||
* shell -- lancer un shell utilisateur dans le répertoire du projet
|
|
||||||
* java -- lancer java au lieu de lancer mvn. il est possible de spécifier la
|
|
||||||
version de java directement, e.g java7, java8, java11
|
|
||||||
|
|
||||||
L'action est exécutée sur DESTDIR. Juste avant de lancer l'action, le répertoire
|
|
||||||
courant est modifié pour être DESTDIR, ce qui permet d'utiliser des chemins
|
|
||||||
relatifs le cas échéant.
|
|
||||||
|
|
||||||
La commande 'rshell' lance un shell bash avec l'utilisateur root au lieu de
|
|
||||||
lancer la commande mvn, ce qui permet de faire des opérations plus complexes si
|
|
||||||
le besoin s'en fait sentir. La commande alternative 'shell' lance le shell avec
|
|
||||||
le compte utilisateur. Ces commandes sont particulièrement utiles si mvn est
|
|
||||||
paramétré pour être lancé dans un container
|
|
||||||
|
|
||||||
Les paramètres optionnels sont
|
|
||||||
* args=ARGS...
|
|
||||||
arguments à rajouter à la commande mvn
|
|
||||||
* java=VERSION
|
|
||||||
version de Java à sélectionner à l'intérieur de l'image docker
|
|
||||||
* Spécifier 'any' ou 'force' pour prendre la valeur par défaut
|
|
||||||
* Spécifier 'none' ou 'system' pour ne pas utiliser l'image docker
|
|
||||||
* image=MAVEN_IMAGE
|
|
||||||
image docker utilisée pour lancer mvn. La valeur par défaut est la valeur
|
|
||||||
de la variable d'environnement \$MAVEN_IMAGE
|
|
||||||
Spécifier 'none' pour lancer directement mvn sans passer par une image
|
|
||||||
docker, même si java= est renseigné
|
|
||||||
L'image spécifiée doit disposer de la commande 'su-exec' afin de pouvoir
|
|
||||||
lancer la commande avec l'utilisateur courant. Le répertoire \$HOME est monté
|
|
||||||
à l'intérieur du container.
|
|
||||||
* machine=MACHINE
|
|
||||||
nom de la docker machine sur laquelle se connecter pour lancer l'image docker.
|
|
||||||
La valeur par défaut est -u, ce qui force l'utilisation de l'instance docker
|
|
||||||
locale. Spécifier 'current' pour ne pas modifier la valeur courante le cas
|
|
||||||
échéant
|
|
||||||
* host-mappings=MAPPINGS
|
|
||||||
définir des mappings d'hôte. si ce paramètre n'est pas spécifié, consulter
|
|
||||||
aussi la valeur par défaut 'docker host-mappings='
|
|
||||||
* mvn=PATH/TO/MVN
|
|
||||||
chemin vers l'exécutable mvn. Par défaut, utiliser la commande trouvée dans le
|
|
||||||
PATH
|
|
||||||
* setup=CMDS...
|
|
||||||
liste de commandes à lancer pour configurer le container. Un container ayant
|
|
||||||
pour base MAVEN_IMAGE et nommé d'après le nom du projet est préparé et les
|
|
||||||
commandes spécifiées y sont lancées. Ce container est réutilisé à chaque fois.
|
|
||||||
Ce paramétrage est utilisé par exemple pour installer certains packages
|
|
||||||
nécessaire au projet.
|
|
||||||
* project-name=PROJECT_NAME
|
|
||||||
si setup= est défini, nommer l'image sur la base de ce nom. par défaut, le nom
|
|
||||||
est calculé automatiquement
|
|
||||||
|
|
||||||
Si un fichier .maven.conf existe dans le répertoire du projet, il est sourcé
|
|
||||||
pour obtenir les valeurs par défaut des paramètres:
|
|
||||||
* MAVEN_JAVA -- valeur par défaut de java=
|
|
||||||
* MAVEN_IMAGE -- valeur par défaut de image=
|
|
||||||
* MAVEN_MACHINE -- valeur par défaut de machine=
|
|
||||||
* MAVEN_CMD -- valeur par défaut de mvn=
|
|
||||||
* MAVEN_SETUP -- valeur par défaut de setup=
|
|
||||||
|
|
||||||
## run -- lancer des commandes
|
|
||||||
|
|
||||||
## call -- lancer des commandes ou des fonctions
|
|
||||||
"
|
|
||||||
}
|
|
||||||
|
|
||||||
##~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
##~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
## shared
|
## shared
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue