Conteneurisez des applications .NET
autour de l'IBM i

Q: La conteneurisation est-elle adaptée aux applications métier existantes basées sur IBM i, ou uniquement aux nouveaux projets .NET ?

Les deux approches sont possibles. Les applications métiers existantes restent sur IBM i et peuvent être exposées progressivement via des services .NET conteneurisés, en conservant les programmes RPG, CLP ou les applications héritées de type S/36. Les nouveaux projets, eux, peuvent être conçus directement en .NET, avec une logique applicative indépendante de l’IBM i.

Q: Comment sont gérées la configuration et les informations sensibles dans une application .NET conteneurisée et connectée à l’IBM i ?

La configuration et les informations sensibles sont gérées côté application, via les mécanismes standards de .NET et des conteneurs, tels que les variables d’environnement ou les fichiers de configuration. Aucun paramétrage spécifique n’est requis côté IBM i.

Q: Peut-on faire cohabiter plusieurs applications .NET conteneurisées autour d’un même IBM i ?

Oui. Chaque application s’exécute dans son propre conteneur, avec son cycle de vie et ses ressources. Cette approche permet de multiplier les usages autour d’un même IBM i sans créer de dépendances croisées entre applications.

Q: La conteneurisation .NET autour de l’IBM i est-elle compatible avec des contraintes fortes de sécurité et de conformité ?

Oui. L’IBM i reste isolé, non exposé, et conserve l'ensemble de ses mécanismes de sécurité natifs. Les applications .NET s’exécutent dans des environnements dont la sécurité est assurée par l’infrastructure d’hébergement, sans modifier ni contourner les règles de sécurité de l’IBM i.

Q: Peut-on conteneuriser une application .NET accédant à l’IBM i avec ODBC ou OLE DB ?

Techniquement oui, mais avec des contraintes importantes. Les connecteurs ODBC ou OLE DB reposent sur des drivers dépendants du système d’exploitation et de l’architecture. Dans un contexte .NET moderne et conteneurisé, cela complexifie fortement la portabilité, la maintenance et les déploiements multi-environnements. NTi s’appuie exclusivement sur le runtime .NET (CLR) pour l’accès à l’IBM i. L’application reste 100 % .NET et s’exécute dans son propre environnement conteneurisé, tout en accédant nativement et directement aux ressources de l’IBM i. Le même code applicatif est utilisé, avec des images de conteneur construites pour chaque plateforme cible (Windows, Linux, ARM, Power, etc.).

Conservez l’IBM i comme système de référence.
Avec NTi, déployez des applications .NET conteneurisées, portables, reproductibles et exécutables sur toutes les infrastructures.

IBM i préservé, jamais exposé
Comportement applicatif maîtrisé
Évolution sans risque

Essayer NTi gratuitement

Voir la documentation

Qu’est-ce qu’un conteneur ?

Un conteneur regroupe votre application et tout ce dont elle a besoin pour fonctionner. Il fournit un environnement isolé, standardisé et indépendant du système hôte.

Machine virtuelle

Votre application

Système d’exploitation complet

Hyperviseur

Inclut un OS complet, souvent plusieurs gigaoctets de surcharge pour une petite application.

Conteneur

Votre application

Dépendances uniquement Runtime, bibliothèques, configuration…

Contient uniquement votre code et ses dépendances. Léger, portable et reproductible.

Portable Reproductible Léger

En embarquant la runtime et les dépendances avec l’application, le conteneur élimine les différences entre les environnements. Ce qui fonctionne en développement fonctionne de manière identique en test et en production.

.NET Cloud Ready

La plateforme conçue pour construire, déployer et exécuter des applications dans différents environnements.

Runtime multiplateforme

.NET s’exécute sur Windows, Linux et macOS, ainsi que sur les architectures x86, ARM et Power. Une même application peut fonctionner sur différents environnements, sans modification.

Application autonome

Tout ce dont l’application a besoin est inclus dans l’image: runtime .NET, bibliothèques, configuration. L’hôte d’exécution se contente de lancer le conteneur, sans installation préalable.

Images de conteneurs officielles

Microsoft fournit des images de base maintenues et supportées. Elles permettent de créer et d’exécuter des applications .NET conteneurisées sans se soucier de l’environnement sous-jacent.

Déploiement standardisé

Une application .NET est construite une seule fois, puis déployée de façon identique sur chaque environnement: développement, test et production.

Dockerfile

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/runtime:8.0
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "MyApp.dll"]

Conteneurisation .NET / IBM i

Avec NTi, l’application .NET communique avec l’IBM i quelle que soit l’architecture cible, permettant d’exécuter les charges applicatives .NET indépendamment de l’environnement d’hébergement.

Accès DB2 for i

Interroger et mettre à jour DB2 for i directement depuis du code .NET standard.

RPG / CL

Exécuter des commandes CL et appeler des programmes RPG depuis une application .NET conteneurisée.

Aucune installation IBM i

Toute la gestion de l’accès à l’IBM i est assurée côté application par NTi. Aucune dépendance à la plateforme d’exécution, aucun composant à installer sur l’IBM i.

Un accès IBM i unique, quel que soit l’environnement

Linux Application .NET conteneurisée

ARM Application .NET conteneurisée

Power Application .NET conteneurisée

Déploiement cloud Aucune contrainte d'architecture

IBM i Système central

Image unique multi-plateforme

Code identique partout

Développement .NET standard

Tutoriels & Actualités

Fonctionnement en pratique

Un processus basé sur les standards .NET

Développez une application .NET classique

Créez votre application avec les outils et patterns .NET habituels. API web, service ou application console : tous les types de projets sont compatibles.

Accédez à l’IBM i avec NTi

Ajoutez le package NuGet NTi et connectez-vous à votre IBM i. Accès DB2, appels de programmes et commandes CL via du code .NET standard.

Construisez l’image de conteneur

Utilisez un Dockerfile standard pour packager l’application. L’image contient l’application et son environnement d’exécution.

Déploiement multi-environnements

La même image est exécutée sous forme de conteneur sur l’infrastructure de votre choix (Linux, ARM, Power, cloud ou on-premise). L’accès à l’IBM i fonctionne de manière strictement identique partout.

Bénéfices clés

Le standard de référence pour concevoir, déployer et faire évoluer ses applications.

Découplage applicatif maîtrisé

Les applications .NET s’exécutent hors IBM i. Les évolutions, incidents ou montées en charge n’impactent jamais le système central.

Portabilité et reproductibilité

Une application construite une fois, s'exécute partout. Même image, même runtime, même comportement sur tous les environnements.

Scalabilité contrôlée

Les applications .NET scalent horizontalement par duplication de conteneurs. La charge est absorbée côté .NET, sans solliciter l’IBM i.

Optimisation des ressources

Les conteneurs sont légers et consomment peu de CPU et de mémoire. Aucune VM lourde par application, meilleure densité et meilleure efficacité.

Sécurité par isolation

Chaque application s’exécute dans son propre conteneur. L’IBM i n’est jamais exposé et conserve l’intégralité de ses mécanismes de sécurité natifs.

Standardisation des compétences

Les développements et déploiements reposent sur des outils .NET standards: Visual Studio, Git, CI/CD. Moins de dépendance aux compétences IBM i.

Cas d’usage .NET / IBM i
en environnement conteneurisé

Des scénarios concrets, applicables aujourd’hui avec des outils standards.

API .NET conteneurisée comme couche d’accès IBM i

Contexte

Exposer les données et la logique métier IBM i sans exposer directement le système à Internet.

Mise en œuvre

Une API .NET s’exécute dans un conteneur et accède à DB2 for i, aux commandes CL et aux programmes RPG via NTi.

Clients externes

↓

API .NET
Exécutée dans un conteneur

↓

IBM i
DB2 / RPG / CL
Non exposé à Internet

L’IBM i reste le système de référence
La charge applicative est traitée hors IBM i
L’IBM i n’est jamais exposé directement

Frontends web modernes connectés à l’IBM i

Contexte

Construire des interfaces utilisateurs modernes tout en conservant l’IBM i comme backend.

Mise en œuvre

Un frontend web conteneurisé consomme une API .NET conteneurisée. La même application .NET peut accéder à DB2 for i et à d’autres bases de données.

Frontend web
Conteneur

↓

API .NET
Conteneur
Code .NET unique

↓

DB2 for i

Autres bases

Interfaces modernes sans réécriture RPG
Scalabilité indépendante du frontend et du backend
Accès multi-bases depuis un même code .NET

Conteneurs Linux haute performance sur IBM Power

Contexte

Exploiter une infrastructure IBM Power avec des exigences élevées de performance et de latence.

Mise en œuvre

Les applications .NET s’exécutent dans des conteneurs Docker sur une partition Linux on Power, connectée à l’IBM i via le réseau interne PowerVM.

Linux sur IBM Power
Conteneurs .NET

→

IBM i
Réseau interne PowerVM
Faible latence

Très faible latence et haut débit
L’IBM i n’est pas exposé aux réseaux externes
Infrastructure IBM Power pleinement valorisée

CI/CD et environnements reproductibles

Contexte

Garantir un comportement strictement identique entre les environnements de développement, de test et de production.

Mise en œuvre

Une image Docker unique est construite et déployée via des pipelines CI/CD .NET standards. La configuration repose uniquement sur des variables d’environnement.

Code
source

→

Image
Docker

→

Dev·Test·Prod
Même image partout

Comportement identique sur tous les environnements
Déploiements automatisés et retours arrière simples
Aucun impact sur la configuration IBM i

Conteneurisez des applications .NET
autour de l'IBM i