par Jeff Tickner & Olenka Van Schendel
Auparavant, le déploiement des applications s’effectuait généralement à partir d’un serveur central connecté à tous les systèmes concernés. Cependant, dans le contexte actuel de sécurité accrue, il existe une demande croissante de déploiement dans des environnements de production entièrement séparés du développement, fonctionnant indépendamment sur un réseau isolé. Cette pratique est devenue fondamentale en matière de sécurité et vise à protéger les systèmes critiques et à maintenir l’intégrité des activités de l’entreprise.
Cependant, peu importe où vous en êtes dans votre parcours DevOps, le déploiement d’applications dans des environnements » isolés » pose des défis spécifiques, en particulier pour les plates-formes IBM i. Historiquement, cette tâche était accomplie à l’aide de supports physiques tels que des bandes et des DVD, dans une sorte de » slow motion « . Cependant, dans un environnement numérique contemporain au rythme accéléré, de nouvelles options sont apparues, comblant le fossé entre les méthodes de déploiement traditionnelles et modernes.
Sommaire
1. Les défis propres au déploiement d’applications sur IBM i
Le déploiement d’applications sur la plate-forme IBM i requiert une attention particulière en raison de son architecture et de son environnement d’exploitation uniques. Par ailleurs, étant donné que de nombreuses applications IBM i sont essentielles aux activités de l’entreprise, les mises à jour de production nécessitent souvent des processus adaptés et optimisés spécifiques à l’IBM i.
Ceux qui découvrent la plate-forme IBM i seront peut-être surpris de l’apprendre :
- Les applications IBM i sont généralement volumineuses et sont invariablement déployées en mode « delta » (compte tenu du volume, il n’est pas possible de remplacer l’ensemble des objets).
- Les applications IBM i superposent généralement des bases de données massives qui ont un impact sur le processus de mise à niveau et peuvent nécessiter une gestion spécifique telle qu’une promotion « tant qu’elle est active » afin d’éviter des temps d’arrêt excessifs pour les utilisateurs finaux.
- Les applications IBM i sont souvent critiques pour l’entreprise et exigent un niveau de sécurité élevé qui limite l’accès et la disponibilité lors de la mise à jour.
- Le système d’exploitation IBM i est orienté objet, ce qui signifie que chaque type d’objet possède des propriétés spécifiques définissant (entre autres) la manière dont il doit être déployé et les actions spécifiques qui doivent être invoquées (le déploiement d’IBM i exige bien plus que le simple placement d’un fichier dans un répertoire !)
- Grâce à cette orientation objet, la sécurité est intégrée au système d’exploitation (un programme n’est pas un fichier, c’est un objet programme. Un simple fichier ne peut pas être transformé en objet exécutable).
- Invariablement, les applications IBM i dépendent fortement des applications middleware/frontend, ce qui signifie que le déploiement doit être étroitement synchronisé pour éviter les incohérences dans la production
De plus, le déploiement des artefacts IBM i peut être complexe et nécessiter des instructions spéciales qui peuvent s’appliquer à tous les déploiements ou être propres à des déploiements spécifiques. Un exemple courant de déploiement concerne l’initialisation de nouvelles colonnes ajoutées à une table ; il s’agit évidemment d’une action unique lorsque la modification de la table est déployée, et cette action est également contenue et gérée dans le module spécifique.
Tout compte fait, l’objectif principal à atteindre sur IBM i en ce qui concerne l’automatisation du déploiement est de réconcilier deux objectifs apparemment opposés : d’une part, comment assurer un environnement de production hautement sécurisé et stable, et d’autre part, fournir en permanence des services à l’entreprise, avec tous les avantages qu’apporte une véritable approche DevOps !
2. Tirer parti de la technologie du monde des systèmes ouverts
Sur les systèmes distribués, les référentiels d’artefacts tels que JFrog Artifactory ou Azure Artifacts sont largement utilisés pour remédier à la « déconnexion de l’environnement ». Cependant, comme de nombreux outils DevOps standards, ces référentiels d’artefacts ne peuvent pas être utilisés directement à partir d’IBM i dans leur forme brute. Ils exigent que la présentation du contenu réel à déployer soit dans un format compatible avec IBM i et contienne des métadonnées propriétaires nécessaires.
Dans le monde de l’IBM i, un package commun est un SAVF contenant des objets à déployer. Pour une gestion sécurisée du cycle de vie, il doit également y avoir des identificateurs et un manifeste pour permettre la validation du contenu avant le déploiement.
L’accessibilité des outils standards de gestion d’artefacts à partir d’IBM i est devenue une condition essentielle pour DROPS, la solution multiplateforme de gestion des versions d’ARCAD.
L’ouverture de la solution DROPS a été le facteur clé qui a permis l’intégration des processus de pipeline et des outils CI/CD. Cette ouverture, par le biais d’extensions, de plugins, de CLI et d’API, a permis de bénéficier également d’outils de gestion d’artefacts. De plus, la solution DROPS étant librement paramétrable, il est facile de l’adapter aux flux de travail DevOps spécifiques des clients.
Exemple : Configuration de DROPS dans des environnements IBM i isolés (avec ARCAD/Azure DevOps)
3. Travailler avec des environnements « isolés » de haute sécurité
Le défi qui se présente lorsque nous avons une déconnexion complète entre les environnements de développement et de production est que le déploiement régulier en une seule étape n’est pas possible. Les outils n’ont PAS accès à la mise en forme et aux métadonnées ALM en même temps des deux côtés. Dans ce cas, l’architecture consiste à utiliser le référentiel d’artefacts comme un « coffre-fort » sécurisé, accessible depuis les environnements de développement et de production :
- Tout d’abord, lorsque les développeurs produisent du code, un serveur DROPS dédié dans le domaine du développement créera le package, y compris les composants à déployer et les métadonnées requises
- Ensuite, DROPS livrera le package dans le dépôt d’artefacts sécurisé.
- Dans l’environnement de production, un second serveur DROPS importera le package à déployer depuis le coffre-fort sécurisé.
- Les Release Managers utilisent alors ce second serveur DROPS pour déployer le package en production en activant les processus d’automatisation et de validation des workflows en place.
4. Exploiter les systèmes génériques de gestion des artefacts sur IBM i
Un déploiement sûr et fiable vers des cibles isolées dépend d’une intégration étroite entre le référentiel d’artefacts (générique) et la technologie DevOps IBM i utilisée.
La plupart des anciens outils de gestion des changements ont été conçus à une époque où le niveau de sécurité et la séparation presque physique des environnements n’étaient pas nécessaires. En revanche, les outils modernes de gestion des versions intègrent ces aspects de manière similaire à un coup de billard à deux bandes (ou plus).
Compte tenu de la fréquence élevée des livraisons dans une configuration DevOps moderne, les processus de déploiement doivent devenir beaucoup plus efficaces.
Pour relever ce défi, DROPS a l’avantage de disposer d’un accès complet aux « métadonnées » de l’application IBM i (ou connaissance des dépendances) qui sont maintenues en temps réel par les outils d’ARCAD for DevOps.
Grâce à ces métadonnées, avec DROPS, nous pouvons utiliser un référentiel d’artefacts standard (JFrog, Azure Artifacts, Nexus, référentiel d’artefacts DROPS, etc.) dans le workflow IBM i d’un client et vérifier directement que l’artefact reçu est la bonne release, la bonne version et le bon manifeste lorsqu’il est réimporté dans le workflow DevOps. Nous pouvons valider le package importé par rapport au package attendu et garantir ainsi l’intégrité du déploiement.
Avec DROPS, la mise en forme de la version IBM i est gérée automatiquement, et les artefacts IBM i et front-end interdépendants sont déployés de manière synchrone afin de garantir l’intégrité de l’application complète.
DROPS permet également de personnaliser l’identifiant de la version, de sorte que des identifiants externes, comme un élément de travail, peuvent être utilisés. Cela rend très facile le suivi des déploiements IBM i à partir de systèmes de gestion de projet standard tels que Jira et ServiceNow.
Tout cela est possible grâce aux plus de 30 ans d’expérience d’ARCAD dans le déploiement d’artefacts IBM i, ainsi qu’à ses 10 années d’expertise dans le déploiement synchrone d’artefacts multiplateformes et qui a connu de nombreuses évolutions pour fournir cette fonctionnalité.
Conclusion
Désormais, il apparaît qu’ ARCAD DROPS assure à la fois le packaging et le déploiement des artefacts IBM i avec un processus continu à travers des environnements isolés. Cela permet de transférer le package vers le domaine cible pour la mise en place du déploiement. Il peut s’agir d’un transfert physique si le domaine est vraiment séparé, ou, ce qui est plus courant chez nos clients, d’une réplication avec état de l’artefact entre les domaines du réseau, selon ce qui est utilisé du côté des systèmes ouverts pour fournir la sécurité nécessaire.
Comme toujours lorsque nous discutons du workflow et des outils avec l’équipe IBM i, nous recommandons un ensemble d’outils unifiés et un flux de travail partagé avec l’équipe des systèmes ouverts, en tirant parti de l’expertise interne à la fois pour la mise en œuvre et la maintenance continue du workflow DevOps.
L’ouverture des outils DROPS brise les barrières traditionnelles entre IBM i et les systèmes ouverts afin d’obtenir le meilleur des deux mondes.
Prochainement : une capacité de déploiement DROPS équivalente sera bientôt disponible pour IBM z !
