Cet article est la suite d'un article sur l'organisation des processus d' intégration continue / livraison continue qui automatisent l'assemblage, les tests et la livraison des applications applicables aux solutions basées sur la plate-forme InterSystems.

Considérez des sujets tels que:

• Conteneurs 101
• Conteneurs à différentes étapes du cycle de développement logiciel
• Livraison continue avec conteneurs

Conteneurs 101

Beaucoup d'articles et de livres ont été écrits sur les conteneurs et la conteneurisation, je vais donc faire ici une petite introduction, qui ne prétend cependant pas être définitive. Commençons donc.

Les conteneurs, techniquement, sont une méthode de virtualisation dans laquelle le noyau du système d'exploitation prend en charge plusieurs instances isolées d'espace utilisateur (conteneurs), au lieu d'une. Cela ressemble visuellement à ceci:

Il est important de noter que les conteneurs ne sont pas des machines virtuelles, voici un bon article sur leurs différences.

Avantages du conteneur

L'utilisation de conteneurs présente plusieurs avantages:

• La portabilité
• Efficacité
• L'isolement
• Légèreté
• Immuabilité

La portabilité

Le conteneur contient l'application ainsi que toutes les dépendances. Cela facilite l'exécution des applications dans divers environnements, tels que les serveurs physiques, les machines virtuelles, les environnements de test et les environnements de produits, et les clouds.

De plus, la portabilité consiste dans le fait qu'après que l'image Docker est assemblée et qu'elle fonctionne correctement, elle fonctionnera n'importe où si Docker y fonctionne, c'est-à-dire sur les serveurs Windows, Linux et MacOS.

Efficacité

Lorsque vous travaillez avec des applications de machine virtuelle, avez-vous vraiment besoin de processus OS, de programmes système, etc.? En règle générale, non, seul le processus de votre candidature est intéressant. Les conteneurs offrent exactement cela: seuls les processus qui sont clairement nécessaires sont lancés dans le conteneur, et rien de plus. Étant donné que les conteneurs ne nécessitent pas de système d'exploitation distinct, ils utilisent moins de ressources. Une machine virtuelle prend souvent plusieurs gigaoctets, tandis qu'un conteneur peut être aussi petit que quelques mégaoctets, ce qui vous permet d'exécuter beaucoup plus de conteneurs que les machines virtuelles sur un seul serveur.

Étant donné que les conteneurs ont un niveau d'utilisation du serveur plus élevé, moins de matériel est requis, ce qui entraîne des coûts inférieurs.

L'isolement

Les conteneurs isolent l'application de tous les autres processus et bien que plusieurs conteneurs puissent s'exécuter sur le même serveur, ils peuvent être complètement indépendants les uns des autres. Toute interaction entre conteneurs doit être explicitement déclarée. Si un conteneur tombe en panne, cela n'affecte pas les autres conteneurs et peut être redémarré rapidement. La sécurité est également renforcée par cet isolement. Par exemple, l'exploitation d'une vulnérabilité de serveur Web sur un hôte peut donner à un attaquant un accès à l'intégralité du serveur, mais dans le cas d'un conteneur, un attaquant n'aura accès qu'au conteneur du serveur Web.

Légèreté

Étant donné que les conteneurs ne nécessitent pas de système d'exploitation distinct, ils peuvent être démarrés, arrêtés ou redémarrés en quelques secondes, ce qui accélérera tous les processus associés, y compris les processus d'intégration continue. Vous pouvez commencer à développer plus rapidement et ne pas perdre de temps à configurer votre environnement.

Immuabilité

L'infrastructure immuable se compose de composants immuables qui sont remplacés pour chaque déploiement et non mis à jour. La cohérence réduit les incohérences et vous permet de répliquer et de vous déplacer facilement et rapidement entre les différents états de votre application. Plus sur l'immuabilité .

De nouvelles fonctionnalités

Tous ces avantages vous permettent de gérer votre infrastructure et vos applications d'une manière nouvelle.

Orchestration

Les machines virtuelles et les serveurs au fil du temps acquièrent souvent une "personnalité", ce qui entraîne de nombreuses surprises généralement désagréables à l'avenir. Une solution à ce problème est Infrastructure as a Code (IoC) - gestion de l'infrastructure à l'aide d'un modèle descriptif utilisant un système de contrôle de version.

Lors de l'utilisation d'IoC, l'équipe de déploiement d'environnement apporte toujours l'environnement cible à la même configuration, quel que soit l'état initial de l'environnement. Ceci est réalisé en configurant automatiquement un environnement existant ou en recréant l'environnement à partir de zéro.

À l'aide d'IoC, les développeurs apportent des modifications à la description de l'environnement. Par la suite, l'environnement cible est modifié dans un nouvel état. Si vous devez apporter des modifications mercredi, sa description est modifiée.

Tout cela est beaucoup plus facile à faire avec des conteneurs. L'arrêt du conteneur et le démarrage d'un nouveau prend quelques secondes, et l'allocation d'une nouvelle machine virtuelle prend quelques minutes.

Mise à l'échelle

Les outils d'orchestration peuvent également fournir une mise à l'échelle horizontale en fonction de la charge actuelle. Il est possible d'exécuter autant de conteneurs que nécessaire et de faire évoluer l'application en conséquence. Tout cela réduit également le coût de l'application.

Conteneurs à différentes étapes du cycle de vie du logiciel

Tenez compte des avantages des conteneurs à différentes étapes du cycle de vie du logiciel.

Développement

L'avantage le plus important est la facilité de démarrage du développement. Après avoir installé Docker , il suffit d'exécuter deux commandes: docker pull pour charger l'image et docker run pour la démarrer. Toutes les dépendances sont déjà résolues au stade de la création de l'application.

Débogage

Tous les environnements sont cohérents et leurs définitions existent; en outre, il est facile de déployer l'environnement nécessaire. Il suffit de faire docker pull le conteneur d'intérêt et l'exécuter.

Test / QA

En cas d'erreur, l'environnement du problème et les conditions de reproduction de l'erreur peuvent être transférés avec le conteneur. Tous les changements d'infrastructure sont «documentés». Le nombre de variables diminue - versions de bibliothèques, frameworks, OS ... Il est possible d'exécuter plusieurs conteneurs pour paralléliser les tests.

La livraison

L'utilisation de conteneurs vous permet de créer une seule fois, en plus d'utiliser des conteneurs, vous avez besoin d'un haut niveau d'automatisation des processus d'assemblage et de déploiement. La livraison en conteneur d'une application peut être plus sûre en raison d'une isolation supplémentaire.

Livraison continue

Passons de la théorie à la pratique. Voici une vue générale de notre solution d'automatisation d'assemblage et de livraison:

On distingue trois étapes principales:

• Assemblage
• La livraison
• Lancement

Assemblage

Dans l'article précédent, l'assemblage était incrémentiel - nous avons considéré la différence entre l'environnement actuel et la nouvelle base de code et changé notre environnement afin qu'il corresponde à la nouvelle base de code. Avec les conteneurs, chaque assemblage est complet. Le résultat de la construction est une image Docker qui peut être exécutée n'importe où.

La livraison

Une fois notre image compilée et testée, elle est téléchargée dans le Docker Registry, une application spécialisée pour l'hébergement de l'image Docker. Là, il peut remplacer l'image précédente par le même nom (tag). Par exemple, en raison d'un nouveau commit dans la branche master, nous avons assemblé une nouvelle image ( MyProject/MyApp:master ), et si les tests sont réussis, nous pouvons mettre à jour l'image dans le Docker Registry et tous ceux qui téléchargent MyProject/MyApp:master obtiendront une nouvelle version.

Lancement

Enfin, l'image doit être démarrée. Un système de CD, tel que GitLab, peut gérer cela directement ou avec l'aide d'un orchestrateur spécialisé, mais le processus est généralement le même - certaines images sont lancées, les performances sont périodiquement vérifiées et mises à jour si une nouvelle version devient disponible.

Consultez le webinaire expliquant ces étapes.

Alternativement, en termes de commit:

Dans notre configuration de livraison continue, nous:

• Valider le code dans le référentiel GitLab
• Nous collectons l'image
• Le tester
• Publiez une nouvelle image dans notre Docker Registry
• Mettre à jour l'ancien conteneur vers la nouvelle version à partir du registre Docker

Pour cela, nous avons besoin de:

• Docker
• Registre Docker
• Domaine enregistré (facultatif, mais souhaitable)
• Outils GUI (facultatif)

Docker

Tout d'abord, nous devons démarrer Docker. Je recommanderais de commencer avec un seul serveur avec une version courante de Linux, comme Ubuntu, RHEL ou Suse. Je ne recommande pas de commencer avec des distributions telles que CoreOS, RancherOS, etc. - elles ne sont pas destinées aux débutants. N'oubliez pas de basculer le pilote de stockage sur devicemapper .

Si nous parlons de déploiements à grande échelle, puis en utilisant des outils d'orchestration tels que Kubernetes, Rancher ou Swarm, vous pouvez automatiser la plupart des tâches, mais nous n'en discuterons pas (du moins dans le cadre de cet article).

Registre Docker

Il s'agit du premier conteneur que nous devons exécuter, c'est une application autonome qui nous permet de stocker et de distribuer des images Docker. Vous devez utiliser le Docker Registry si vous voulez:

• Contrôlez où vos images sont stockées
• Posséder un serveur de distribution d'images
• Intégrer le stockage et la distribution d'images dans le processus de développement

Voici la documentation sur le lancement et la configuration de Docker Registry.

Connectez Docker Registry et GitLab

Pour connecter le Docker Registry à GitLab, vous devez exécuter le Docker Registry avec la prise en charge HTTPS . J'utilise Let's Encrypt pour obtenir des certificats, et j'ai suivi cette instruction pour obtenir un certificat. Après avoir vérifié que le registre Docker est accessible via HTTPS (vous pouvez le vérifier dans le navigateur), suivez ces instructions pour connecter le registre Docker à GitLab. Ces instructions varient en fonction de votre installation de GitLab et de la configuration dont vous avez besoin. Dans mon cas, la configuration consistait à ajouter le certificat et la clé Docker Registry à /etc/gitlab/ssl , et ces lignes à /etc/gitlab/gitlab.rb :

 registry_external_url 'https://docker.domain.com' gitlab_rails ['registry_api_url'] = "https://docker.domain.com" 

Après avoir reconfiguré GitLab , un nouvel onglet du Registre est apparu, qui fournit des informations sur la façon de nommer correctement les images créées afin qu'elles apparaissent ici.

Domaine

Dans notre configuration de livraison continue, nous créerons automatiquement une image pour chaque branche, et si l'image réussit les tests, elle est publiée dans le Docker Registry et démarre automatiquement, donc notre application sera automatiquement déployée depuis toutes les branches, par exemple:

• Branches de <featureName>.docker.domain.com multiples sur <featureName>.docker.domain.com
• Testez la version sur master.docker.domain.com
• Version d' preprod.docker.domain.com sur preprod.docker.domain.com
• Version du produit sur prod.docker.domain.com

Pour ce faire, nous avons besoin d'un nom de domaine et d'un enregistrement DNS générique qui redirige les demandes vers * .docker.domain.com vers l'adresse IP de docker.domain.com . Alternativement, vous pouvez utiliser différents ports.

Nginx

Étant donné que nous avons plusieurs environnements, nous devons rediriger automatiquement les demandes vers des sous-domaines vers le conteneur approprié. Pour cela, nous pouvons utiliser Nginx comme proxy inverse. Voici un guide .

Outils GUI

Pour commencer à travailler avec des conteneurs, vous pouvez utiliser la ligne de commande ou l'une des interfaces graphiques. Il en existe de nombreux disponibles, par exemple:

• Rancher
• Microbadger
• Portainer
• Docker ui simple
• ...

Ils vous permettent de créer des conteneurs et de les gérer à partir de l'interface graphique au lieu de l'interface CLI. Voici à quoi ressemble Rancher:

Gitlab runner

Comme précédemment, pour exécuter des scripts sur d'autres serveurs, nous devons installer le runner GitLab. Cette question est décrite en détail dans un article précédent .

Notez que vous devez utiliser le shell exécuteur, pas le Docker. Executor Docker est utilisé lorsque vous avez besoin de quelque chose de l'intérieur de l'image, par exemple, lors de la création d'une application Android dans un conteneur java, et que vous n'avez besoin que d'apk. Dans notre cas, l'artefact est le conteneur entier, et cela nécessite l'exécuteur Shell.

Configuration de livraison continue

Maintenant que tous les composants nécessaires sont configurés, vous pouvez commencer à créer une configuration de livraison continue.

Assemblage

Tout d'abord, nous devons assembler une image.

Notre code, comme toujours, est stocké dans le référentiel, la configuration du CD dans gitlab-ci.yml , mais en plus (pour améliorer la sécurité) nous allons stocker plusieurs fichiers liés à l'image sur le serveur de build.

Gitlab.xml

Contient un code de rappel pour CD. Il a été développé dans un article précédent et est disponible sur GitHub . Il s'agit d'une petite bibliothèque pour télécharger du code, exécuter divers rappels et tester le code. Il est préférable d'utiliser des sous-modules git pour inclure ce projet ou quelque chose de similaire dans votre référentiel. Les sous-modules sont meilleurs car il est plus facile de les maintenir à jour. Une autre alternative consiste à créer une version sur GitLab et à la télécharger à l'aide de la commande ADD déjà au moment de la construction.

iris.key

Clé de licence. Il peut être chargé lors de l'assemblage du conteneur, et non stocké sur le serveur. Il n'est pas sûr de stocker la clé dans le référentiel. Vous pouvez obtenir une clé d'essai au WRC ou essayer InterSystems IRIS Experience .

pwd.txt

Fichier contenant le mot de passe par défaut. Encore une fois, le stockage du mot de passe dans le référentiel est plutôt dangereux.

load_ci.script

Un script qui:

• Comprend l' authentification du système d'exploitation dans InterSystems IRIS
• Charge GitLab.xml
• Initialise les paramètres de rappel GitLab
• Charge le code

 set sc = ##Class(Security.System).Get("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) set AutheEnabled = Properties("AutheEnabled") set AutheEnabled = $ZBOOLEAN(+AutheEnabled,16,7) set Properties("AutheEnabled") = AutheEnabled set sc = ##Class(Security.System).Modify("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) zn "USER" do ##class(%SYSTEM.OBJ).Load(##class(%File).ManagerDirectory() _ "GitLab.xml","cdk") do ##class(isc.git.Settings).setSetting("hooks", "MyApp/Hooks/") do ##class(isc.git.Settings).setSetting("tests", "MyApp/Tests/") do ##class(isc.git.GitLab).load() halt 

Notez que la première ligne est intentionnellement laissée en blanc. Si ce script initial est toujours le même, vous pouvez simplement l'enregistrer dans le référentiel.

gitlab-ci.yml

Passons maintenant à la configuration de livraison continue:

 build image: stage: build tags: - test script: - cp -r /InterSystems/mount ci - cd ci - echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt - mv temp.txt load_ci.script - cd .. - docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.domain.com/test/docker:$CI_COMMIT_REF_NAME . 

Que se passe-t-il ici?

Tout d'abord, étant donné que le processus d'assemblage d'images ne peut accéder qu'aux sous-répertoires du répertoire de base - dans notre cas, le répertoire racine du référentiel, vous devez copier le répertoire "secret" (qui contient GitLab.xml , iris.key , pwd.txt et load_ci.skript ) pour référentiel cloné.

De plus, un utilisateur / mot de passe est requis pour accéder au terminal, nous les ajouterons donc à load_ci.script (pour cela nous avons besoin d'une ligne vide au début de load_ci.script ).

Enfin, nous créons une image Docker et la docker.domain.com/test/docker:$CI_COMMIT_REF_NAME : docker.domain.com/test/docker:$CI_COMMIT_REF_NAME

où $CI_COMMIT_REF_NAME est le nom de la branche. Remarque: la première partie de la balise image doit correspondre au nom du référentiel dans GitLab afin qu'il puisse être vu sur l'onglet Registre (des instructions plus complètes pour un balisage correct sont disponibles ici).

Dockerfile

Docker Image est créée à l'aide de Dockerfile , la voici:

 FROM docker.intersystems.com/intersystems/iris:2018.1.1.613.0 ENV SRC_DIR=/tmp/src ENV CI_DIR=$SRC_DIR/ci ENV CI_PROJECT_DIR=$SRC_DIR COPY ./ $SRC_DIR RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ \ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ \ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt \ && iris start $ISC_PACKAGE_INSTANCENAME \ && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script \ && iris stop $ISC_PACKAGE_INSTANCENAME quietly 

Les actions suivantes sont effectuées:

• Nous prenons l'image d'InterSystems IRIS comme base. Il devrait se trouver dans votre Docker Registry. Si vous n'avez jamais travaillé avec Docker auparavant, essayez First Look: Docker , qui décrit comment obtenir une image IRIS InterSystems, l'ajouter au registre Docker et la lancer manuellement.
• Tout d'abord, copiez notre référentiel (et le répertoire "secret") à l'intérieur du conteneur.
• Copiez la clé de licence et GitLab.xml dans le répertoire mgr .
• Remplacez le mot de passe par la valeur de pwd.txt . Notez que pwd.txt est supprimé lors de cette opération.
• Démarre InterSystems IRIS.
• Le load_ci.script est load_ci.script .
• InterSystems IRIS s'arrête.

 Running with gitlab-runner 10.6.0 (a3543a27) on docker 7b21e0c4 Using Shell executor... Running on docker... Fetching changes... Removing ci/ Removing temp.txt HEAD is now at 5ef9904 Build load_ci.script From http://gitlab.eduard.win/test/docker 5ef9904..9753a8d master -> origin/master Checking out 9753a8db as master... Skipping Git submodules setup $ cp -r /InterSystems/mount ci $ cd ci $ echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt $ mv temp.txt load_ci.script $ cd .. $ docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME . Sending build context to Docker daemon 401.4kB Step 1/6 : FROM docker.intersystems.com/intersystems/iris:2018.1.1.613.0 ---> cd2e53e7f850 Step 2/6 : ENV SRC_DIR=/tmp/src ---> Using cache ---> 68ba1cb00aff Step 3/6 : ENV CI_DIR=$SRC_DIR/ci ---> Using cache ---> 6784c34a9ee6 Step 4/6 : ENV CI_PROJECT_DIR=$SRC_DIR ---> Using cache ---> 3757fa88a28a Step 5/6 : COPY ./ $SRC_DIR ---> 5515e13741b0 Step 6/6 : RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt && iris start $ISC_PACKAGE_INSTANCENAME && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script && iris stop $ISC_PACKAGE_INSTANCENAME quietly ---> Running in 86526183cf7c . Waited 1 seconds for InterSystems IRIS to start This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement %SYS> 1 %SYS> Using 'iris.cpf' configuration file This copy of InterSystems IRIS has been licensed for use exclusively by: ISC Internal Container Sharding Copyright (c) 1986-2018 by InterSystems Corporation Any other use is a violation of your license agreement 1 alert(s) during startup. See messages.log for details. Starting IRIS Node: 39702b122ab6, Instance: IRIS Username: Password: Load started on 04/06/2018 17:38:21 Loading file /usr/irissys/mgr/GitLab.xml as xml Load finished successfully. USER> USER> [2018-04-06 17:38:22.017] Running init hooks: before [2018-04-06 17:38:22.017] Importing hooks dir /tmp/src/MyApp/Hooks/ [2018-04-06 17:38:22.374] Executing hook class: MyApp.Hooks.Global [2018-04-06 17:38:22.375] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.375] Importing dir /tmp/src/ Loading file /tmp/src/MyApp/Tests/TestSuite.cls as udl Compilation started on 04/06/2018 17:38:22 with qualifiers 'c' Compilation finished successfully in 0.194s. Load finished successfully. [2018-04-06 17:38:22.876] Running init hooks: after [2018-04-06 17:38:22.878] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.921] Executing hook class: MyApp.Hooks.Global Removing intermediate container 39702b122ab6 ---> dea6b2123165 [Warning] One or more build-args [CI_PROJECT_DIR] were not consumed Successfully built dea6b2123165 Successfully tagged docker.domain.com/test/docker:master Job succeeded 

Lancement

Nous avons une image, exécutez-la. Dans le cas des branches de fonctionnalités, vous pouvez simplement détruire l'ancien conteneur et en démarrer un nouveau. Dans le cas de l'environnement du produit, nous pouvons d'abord démarrer le conteneur temporaire et remplacer le conteneur moyen si les tests réussissent.

Tout d'abord, le script pour supprimer l'ancien conteneur.

 destroy old: stage: destroy tags: - test script: - docker stop iris-$CI_COMMIT_REF_NAME || true - docker rm -f iris-$CI_COMMIT_REF_NAME || true 

Ce script détruit le conteneur en cours d'exécution et réussit toujours (par défaut, Docker renvoie une erreur lorsqu'il essaie d'arrêter / supprimer un conteneur inexistant).

Après cela, nous lançons un nouveau conteneur et l'enregistrons en tant qu'environnement.

 run image: stage: run environment: name: $CI_COMMIT_REF_NAME url: http://$CI_COMMIT_REF_SLUG.docker.eduard.win/index.html tags: - test script: - docker run -d --expose 52773 --volume /InterSystems/durable/$CI_COMMIT_REF_SLUG:/data --env ISC_DATA_DIRECTORY=/data/sys --env VIRTUAL_HOST=$CI_COMMIT_REF_SLUG.docker.eduard.win --name iris-$CI_COMMIT_REF_NAME docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME --log $ISC_PACKAGE_INSTALLDIR/mgr/messages.log 

Le conteneur Nginx redirige automatiquement les demandes à l'aide de la VIRTUAL_HOST environnement VIRTUAL_HOST vers le port spécifié - dans ce cas 52773.

Puisqu'il est nécessaire de stocker certaines données (mots de passe,% SYS, données d'application) sur l'hôte dans InterSystems IRIS, il existe une fonctionnalité % SYS durable qui vous permet de stocker des données sur l'hôte telles que:

• iris.cpf est le fichier de configuration principal.
• Le /csp avec les fichiers d'application Web.
• /httpd/httpd.conf avec la configuration du serveur Apache privé.
• Le répertoire /mgr dans lequel sont stockés:
  
  • Bases de données IRISSYS , IRISTEMP , IRISAUDIT , IRIS , USER .
  • IRIS.WIJ .
  • Annuaire /journal stockant des magazines.
  • Le répertoire /temp pour les fichiers temporaires.
  • Journaux messages.log , journal.log , SystemMonitor.log .

Pour activer Durable% SYS, l'argument volume est spécifié qui ISC_DATA_DIRECTORY répertoire hôte et la variable ISC_DATA_DIRECTORY définit le répertoire de stockage des fichiers Durable% SYS. Ce répertoire ne devrait pas exister, il sera créé automatiquement.

Ainsi, l'architecture de notre application conteneurisée est la suivante:

Pour construire une telle application, nous devons au moins créer une base de données supplémentaire (pour enregistrer le code de l'application) et créer son mappage dans la zone d'application. J'ai utilisé la portée USER pour stocker les données d'application, car cette portée a été ajoutée à Durable% SYS par défaut. Le code d'application est stocké dans un conteneur afin de pouvoir être mis à jour.

Sur la base de ce qui précède, % Installer devrait:

• Créer une zone / base de données APP
• Téléchargez le code dans la zone APP
• Créez des classes de cartographie de notre application dans la zone USER
• Effectuer une autre configuration (j'ai créé une application Web CSP et une application Web REST)

 Class MyApp.Hooks.Local { Parameter Namespace = "APP"; /// See generated code in zsetup+1^MyApp.Hooks.Local.1 XData Install [ XMLNamespace = INSTALLER ] { <Manifest> <Log Text="Creating namespace ${Namespace}" Level="0"/> <Namespace Name="${Namespace}" Create="yes" Code="${Namespace}" Ensemble="" Data="IRISTEMP"> <Configuration> <Database Name="${Namespace}" Dir="/usr/irissys/mgr/${Namespace}" Create="yes" MountRequired="true" Resource="%DB_${Namespace}" PublicPermissions="RW" MountAtStartup="true"/> </Configuration> <Import File="${Dir}Form" Recurse="1" Flags="cdk" IgnoreErrors="1" /> </Namespace> <Log Text="End Creating namespace ${Namespace}" Level="0"/> <Log Text="Mapping to USER" Level="0"/> <Namespace Name="USER" Create="no" Code="USER" Data="USER" Ensemble="0"> <Configuration> <Log Text="Mapping Form package to USER namespace" Level="0"/> <ClassMapping From="${Namespace}" Package="Form"/> <RoutineMapping From="${Namespace}" Routines="Form" /> </Configuration> <CSPApplication Url="/" Directory="${Dir}client" AuthenticationMethods="64" IsNamespaceDefault="false" Grant="%ALL" Recurse="1" /> </Namespace> </Manifest> } /// This is a method generator whose code is generated by XGL. /// Main setup method /// set vars("Namespace")="TEMP3" /// do ##class(MyApp.Hooks.Global).setup(.vars) ClassMethod setup(ByRef pVars, pLogLevel As %Integer = 0, pInstaller As %Installer.Installer) As %Status [ CodeMode = objectgenerator, Internal ] { Quit ##class(%Installer.Manifest).%Generate(%compiledclass, %code, "Install") } /// Entry point ClassMethod onAfter() As %Status { try { write "START INSTALLER",! set vars("Namespace") = ..#Namespace set vars("Dir") = ..getDir() set sc = ..setup(.vars) write !,$System.Status.GetErrorText(sc),! set sc = ..createWebApp() } catch ex { set sc = ex.AsStatus() write !,$System.Status.GetErrorText(sc),! } quit sc } /// Modify web app REST ClassMethod createWebApp(appName As %String = "/forms") As %Status { set:$e(appName)'="/" appName = "/" _ appName #dim sc As %Status = $$$OK new $namespace set $namespace = "%SYS" if '##class(Security.Applications).Exists(appName) { set props("AutheEnabled") = $$$AutheUnauthenticated set props("NameSpace") = "USER" set props("IsNameSpaceDefault") = $$$NO set props("DispatchClass") = "Form.REST.Main" set props("MatchRoles")=":" _ $$$AllRoleName set sc = ##class(Security.Applications).Create(appName, .props) } quit sc } ClassMethod getDir() [ CodeMode = expression ] { ##class(%File).NormalizeDirectory($system.Util.GetEnviron("CI_PROJECT_DIR")) } } 

Je note que pour créer une base de données non sur l'hôte, j'utilise le répertoire /usr/irissys/mgr , car l'appel ##class(%File).ManagerDirectory() renvoie le chemin d'accès au répertoire pour Durable% SYS.

Les tests

Exécutez maintenant les tests.

 test image: stage: test tags: - test script: - docker exec iris-$CI_COMMIT_REF_NAME irissession iris -U USER "##class(isc.git.GitLab).test()" 

La livraison

Les tests sont passés, nous publierons notre image dans le Docker Registry.

 publish image: stage: publish tags: - test script: - docker login docker.domain.com -u user -p pass - docker push docker.domain.com/test/docker:$CI_COMMIT_REF_NAME 

Le login / mot de passe peut être transmis à l'aide de variables secrètes .

Maintenant, l'image est affichée sur GitLab.

Et d'autres développeurs peuvent le télécharger depuis le Docker Registry. Dans l'onglet Environnements, tous nos environnements sont disponibles pour la visualisation:

Conclusions

Cette série d'articles traite des approches courantes de l'intégration continue. L'automatisation de l'assemblage, des tests et de la livraison de votre application sur les plateformes InterSystems est possible et facile à mettre en œuvre.

L'utilisation des technologies de conteneurisation aidera à optimiser les processus de développement et de déploiement d'applications. L'élimination des incohérences entre les environnements facilite les tests et le débogage. L'orchestration vous permet de créer des applications évolutives.

Les références

• Article précédent
• Série communautaire InterSystems
• Code
• Code Github