Gérer les conteneurs avec OpenShift

Gérer des conteneurs, ce n’est pas seulement “faire tourner une image”. C’est organiser un petit système vivant, avec ses cycles de mise à jour, ses besoins réseau, ses contraintes de sécurité, ses pics de charge et ses défaillances inévitables. OpenShift a justement été pensé pour rendre cette complexité plus maîtrisable, en s’appuyant sur les fondations de Kubernetes tout en ajoutant une couche d’intégration, de sécurité et d’exploitation qui fait souvent la différence dans un vrai contexte de production. La plateforme s’appuie sur des nœuds de travail pour exécuter les charges applicatives, des nœuds de plan de contrôle pour orchestrer l’ensemble, et des pods comme unité de déploiement minimale pour emballer un ou plusieurs conteneurs ensemble. (docs.openshift.com)

Ce qui plaît souvent aux équipes, au-delà du discours technique, c’est la sensation de passer d’une gestion artisanale à une gestion gouvernée. On ne manipule plus seulement des conteneurs isolés, on pilote des applications avec des déploiements, des routes d’accès, des images versionnées, des politiques de sécurité, et des mécanismes d’auto-adaptation. OpenShift fournit en plus une interface en ligne de commande, oc, pensée pour créer des applications et gérer des projets depuis un terminal, ce qui reste précieux dès qu’il faut automatiser, déboguer vite, ou travailler sans interface graphique.

Comprendre ce qu’OpenShift apporte vraiment

Dans beaucoup de projets, la première erreur consiste à réduire OpenShift à “Kubernetes avec une console”. En réalité, OpenShift ajoute une opinion d’architecture assez claire : les conteneurs sont regroupés dans des pods, les déploiements orchestrent le cycle de vie des versions, les images sont suivies via des image streams, le trafic entrant passe par des routes ou des ingress, et l’accès aux ressources sensibles est encadré par des SCC, les Security Context Constraints. Cette combinaison change la manière dont on pense une application conteneurisée, parce qu’on ne se contente plus d’exécuter un binaire empaqueté ; on décrit un comportement, un niveau de sécurité, une stratégie d’exposition et une logique d’évolution.

Dans la pratique, cela veut dire qu’un déploiement propre sur OpenShift ne se limite pas à “lancer un conteneur”. Il faut penser à l’image source, aux permissions du conteneur, aux ports exposés, aux variables d’environnement, à la façon dont les mises à jour se propagent, et à la manière dont l’application sera accessible depuis l’extérieur. OpenShift fournit des briques intégrées pour chacune de ces préoccupations, ce qui réduit le nombre d’outils à assembler manuellement et améliore souvent la cohérence globale du système. Le registre d’images intégré, par exemple, permet de construire, stocker, déployer et gérer localement des images dans l’environnement OpenShift, ce qui simplifie la boucle de livraison.

Les objets à connaître avant de gérer des conteneurs

Le point de départ, c’est le pod. OpenShift reprend le concept Kubernetes du pod comme plus petite unité de calcul pouvant être définie, déployée et gérée, et le pod peut contenir un ou plusieurs conteneurs qui partagent le même contexte d’exécution réseau et de cycle de vie. Cette approche est utile dès qu’on veut faire cohabiter un conteneur principal et un conteneur auxiliaire, ou simplement donner à l’application une enveloppe d’exécution cohérente.

Vient ensuite le déploiement. OpenShift décrit les déploiements comme le mécanisme qui pilote la façon dont une application est déployée sous forme de pods, avec une image à récupérer, un nombre de réplicas à maintenir, et une stratégie de mise à jour. La stratégie de type rolling attend que les pods deviennent prêts avant de poursuivre certaines opérations, ce qui évite de casser la disponibilité pendant une montée ou une descente en charge. Autrement dit, le déploiement n’est pas qu’un “start/stop intelligent” ; c’est une logique de continuité de service.

Pour l’exposition réseau, OpenShift met en avant les routes. Une route permet d’héberger une application sous une URL publique, et elle peut être sécurisée ou non selon la configuration de l’application et du réseau. Un route HTTP est un cas simple d’exposition, mais OpenShift propose aussi des mécanismes plus adaptés aux environnements sécurisés, avec le support de TLS et des scénarios d’ingress. Dans l’architecture réseau d’OpenShift, le trafic entrant passe typiquement par des routes ou des ingress, ce qui permet de garder un point de contrôle clair sur l’accès aux services.

Enfin, il faut parler des images. Les image streams sont l’un des éléments les plus distinctifs d’OpenShift. Ils servent d’abstraction pour référencer des images conteneurisées depuis l’intérieur du cluster, suivre leurs versions, déclencher des builds et des déploiements, et conserver une vue stable d’une image même si le contenu source évolue. Les tags d’image sont des pointeurs nommés vers des versions précises, ce qui aide énormément à maîtriser les mises à jour sans perdre le fil entre “la dernière image disponible” et “la bonne image pour cette application”.

Installer sa logique de travail avant même de déployer

Avant de pousser un premier déploiement, il est utile de prendre un petit temps pour préparer la manière de travailler. OpenShift permet d’opérer depuis le terminal avec oc, ce qui est souvent la méthode la plus confortable quand on veut aller vite, écrire des scripts, ou intégrer la plateforme dans un pipeline CI/CD. La documentation officielle précise que oc est adapté au travail direct sur le code source, à l’automatisation d’opérations OpenShift, et aux situations où la console web n’est pas disponible. Il peut être installé sur Linux, Windows ou macOS.

Voici un démarrage typique côté terminal :

oc login https://api.mon-cluster.example:6443 -u mon-utilisateur
oc new-project demo-conteneurs
oc project demo-conteneurs

Ce premier trio de commandes paraît banal, mais il pose les fondations d’un travail propre. On se connecte, on crée un espace isolé, puis on s’assure que toutes les opérations suivantes se font dans le bon projet. Cette discipline évite une grande partie des erreurs de début de parcours, notamment quand plusieurs environnements cohabitent sur le même cluster.

Déployer un premier conteneur de manière propre

La manière la plus saine de gérer un conteneur sur OpenShift consiste à partir d’un manifeste clair. On décrit le déploiement, on rattache un service interne, puis on ajoute une route si l’application doit être accessible de l’extérieur. Le bénéfice est immédiat : l’état désiré est écrit noir sur blanc, versionnable dans Git, relisible par une équipe, et reproductible dans un autre environnement.

Exemple de déploiement simple :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: app-web
  template:
    metadata:
      labels:
        app: app-web
    spec:
      containers:
        - name: app-web
          image: quay.io/mon-equipe/app-web:1.0.0
          ports:
            - containerPort: 8080
          env:
            - name: NODE_ENV
              value: "production"
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

Ce manifeste illustre plusieurs réflexes importants. D’abord, on fixe un nombre de réplicas pour ne pas dépendre d’un seul conteneur. Ensuite, on déclare explicitement les ressources, car un conteneur sans limites ni réserves finit souvent par provoquer des surprises au moment où la charge monte. Enfin, on référence une image versionnée plutôt qu’un tag flou, ce qui facilite le contrôle du changement.

Le service interne associé peut ressembler à ceci :

apiVersion: v1
kind: Service
metadata:
  name: app-web
spec:
  selector:
    app: app-web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

Et pour exposer l’application vers l’extérieur :

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: app-web
spec:
  to:
    kind: Service
    name: app-web
  port:
    targetPort: 80
  tls:
    termination: edge

La route transforme une application interne en point d’accès public, tout en laissant OpenShift gérer la translation vers le service approprié. C’est souvent plus simple et plus gouvernable que d’ouvrir des ports à la main. La documentation indique d’ailleurs qu’une route peut servir à héberger l’application à une URL publique, avec ou sans sécurisation selon le besoin.

On applique ensuite l’ensemble :

oc apply -f deployment.yaml
oc apply -f service.yaml
oc apply -f route.yaml
oc get pods
oc get svc
oc get route

Cette séquence n’a rien de spectaculaire, mais elle représente exactement ce qu’on cherche dans une plateforme comme OpenShift : un état clair, un déploiement reproductible, et une chaîne de commandes lisible par n’importe quel membre de l’équipe.

Gérer les images avec méthode

Quand on parle de conteneurs, l’image est souvent le vrai produit. Une mauvaise image entraîne des démarrages lents, des vulnérabilités, des doublons de dépendances ou des comportements non reproductibles. OpenShift apporte une gestion plus riche grâce aux image streams, qui ne contiennent pas les données binaires de l’image mais une vue logique sur des images liées entre elles. Cela permet de suivre les versions, d’automatiser des builds et des déploiements, et de conserver une référence stable même si l’image source évolue dans un registre externe.

Cette capacité devient très utile dans une équipe où plusieurs sources d’images coexistent. L’image peut venir du registre intégré d’OpenShift, d’un registre externe comme Quay, ou même d’un autre image stream du cluster. Le point clé, c’est qu’OpenShift peut suivre l’image via un tag et utiliser l’identifiant exact de l’image correspondante au moment du déploiement. Cela limite le risque de “ça marchait hier, pourquoi ce n’est plus pareil aujourd’hui ?”.

Exemple d’usage de l’image stream :

oc new-app openshift/nodejs:18-ubi8~https://github.com/mon-org/mon-app.git --name=mon-app
oc get is
oc describe is mon-app

Dans un scénario plus classique, on peut aussi importer ou suivre un tag précis :

oc tag quay.io/mon-equipe/app-web:1.0.0 app-web:stable
oc get istag

L’intérêt n’est pas seulement esthétique. Les image streams permettent de déclencher des builds ou des déploiements lorsqu’un tag change, et la documentation précise aussi qu’un re-import périodique peut détecter une nouvelle version de l’image source et propager ce changement. Cela aide à mettre en place une chaîne de livraison plus réactive, tout en conservant un bon niveau de contrôle.

Automatiser la mise à jour sans tout casser

Un conteneur qui ne se met jamais à jour finit toujours par devenir un problème. Un conteneur qui se met à jour trop brutalement devient aussi un problème. Toute la finesse de l’exploitation consiste à trouver un équilibre entre fraîcheur, stabilité et traçabilité. Sur OpenShift, les image streams, les triggers et les déploiements rolling sont précisément là pour ça : faire évoluer l’application progressivement, et de manière lisible, plutôt que par à-coups incontrôlés.

Un bon flux consiste souvent à considérer le tag stable comme un signal métier, pas comme une vérité absolue. Lorsqu’une nouvelle image est validée, on fait pointer le tag vers la nouvelle version. Si le déploiement est configuré pour réagir à ce changement, OpenShift peut lancer la mise à jour automatiquement. Ce mécanisme permet de séparer la publication technique de l’intention fonctionnelle : on dit à la plateforme “cette version est prête”, puis on laisse l’orchestration gérer le reste.

Exemple de stratégie de mise à jour avec un rolling update :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-web
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app-web
          image: quay.io/mon-equipe/app-web:1.0.1

Cette approche est précieuse pour limiter les interruptions. La documentation rappelle que, lors d’une montée ou d’une baisse de charge, la stratégie rolling attend que les pods soient prêts avant de poursuivre certaines opérations ; si les pods ne deviennent jamais prêts, le déploiement peut finir en échec après dépassement du délai. C’est une protection utile, parce qu’un déploiement “terminé” mais inutilisable n’est pas un vrai succès. (docs.openshift.com)

Contrôler la sécurité au lieu de la subir

La sécurité des conteneurs est l’un des sujets où OpenShift montre vraiment son caractère. La plateforme utilise des SCC, des Security Context Constraints, pour contrôler les permissions des pods dans le cluster. Ces contraintes déterminent ce qu’un pod peut faire, les ressources auxquelles il peut accéder, et les conditions dans lesquelles il est accepté par le système. La documentation précise aussi que les SCC par défaut sont créées lors de l’installation, qu’un administrateur peut en créer d’autres avec oc, et surtout qu’il ne faut pas modifier les SCC par défaut, car cela peut poser problème lors des déploiements de plateforme ou des mises à jour.

C’est une différence essentielle avec une vision naïve du conteneur “qui doit juste démarrer”. En production, il faut se demander sous quel utilisateur le processus tourne, s’il a besoin de privilèges spéciaux, s’il peut écrire dans certains répertoires, et quels volumes il peut monter. OpenShift pousse à formaliser ces questions au lieu de les laisser dans l’ombre. Cette exigence peut sembler contraignante au début, mais elle évite beaucoup de dettes techniques et de dérives de sécurité.

Exemple d’un manifeste qui respecte cette logique :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-securisee
spec:
  replicas: 2
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: api
          image: quay.io/mon-equipe/api:2.0.0
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true

Il est possible que chaque cluster ait ses contraintes spécifiques, mais l’idée reste la même : mieux vaut déclarer explicitement les besoins de sécurité que compter sur des hypothèses implicites. Dans OpenShift, cette discipline s’aligne naturellement avec les SCC et avec la logique globale de gouvernance du cluster.

Gérer la montée en charge sans improviser

Le monde réel ne prévient pas quand le trafic augmente. Une publication réseau, une campagne marketing, un traitement de lots ou un pic d’activité interne peuvent rapidement faire varier la charge. OpenShift propose l’autoscaling horizontal des pods, le HPA, pour augmenter ou diminuer le nombre de pods quand un seuil CPU ou mémoire est franchi. La documentation le décrit comme un mécanisme d’ajustement automatique du nombre de pods, et précise qu’il peut réagir en fonction de seuils de ressources.

Le HPA est utile, mais il ne fait pas tout tout seul. Il fonctionne mieux lorsque les ressources sont bien déclarées, lorsque les métriques sont propres, et lorsque l’application supporte la multiplication des réplicas. Une application qui écrit en local sans stockage partagé, ou qui conserve trop d’état en mémoire, peut mal réagir à la réplication. L’autoscaling n’est donc pas une baguette magique ; c’est une capacité d’adaptation qui suppose une architecture pensée pour cela.

Exemple de HPA :

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app-web
  minReplicas: 2
  maxReplicas: 8
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Et côté terminal :

oc apply -f hpa.yaml
oc get hpa
oc describe hpa app-web-hpa

La logique ici est simple mais puissante : la plateforme observe, décide et agit en fonction de règles que vous avez définies à l’avance. Cela évite de réagir dans l’urgence au premier pic de charge venu.

Utiliser le registre d’images intégré intelligemment

Le registre d’images intégré d’OpenShift mérite qu’on lui consacre un vrai moment. La documentation officielle indique qu’OpenShift peut construire des images depuis le code source, les déployer et gérer leur cycle de vie, tout en fournissant un registre interne intégré pour stocker et gérer localement les images. Dans un environnement d’entreprise, ce point change beaucoup de choses, parce qu’il facilite la proximité entre build, stockage, contrôle d’accès et déploiement.

Ce registre n’est pas seulement pratique ; il permet aussi de garder une cohérence d’exploitation. Au lieu de multiplier les allers-retours entre plusieurs services externes, on peut centraliser une partie de la chaîne d’image dans le cluster, avec des permissions mieux contrôlées et une meilleure visibilité sur les versions réellement utilisées. Cela reste évidemment compatible avec des registres externes quand c’est le bon choix, mais l’intégration native d’OpenShift simplifie énormément les scénarios standards.

Exemple de flux de build et de push vers le registre intégré :

oc new-build --name=mon-build --binary --strategy=docker
oc start-build mon-build --from-dir=. --follow
oc get builds

Ou, dans un flux source-to-image :

oc new-app registry.access.redhat.com/ubi8/nodejs-18~https://github.com/mon-org/mon-app.git

Le vrai avantage n’est pas seulement de construire une image. C’est de pouvoir relier cette image à une politique de livraison : qui peut la voir, qui peut la consommer, quelle version doit être déployée, et quel événement doit déclencher une mise à jour. C’est là qu’OpenShift devient plus qu’un simple orchestrateur ; il devient une couche de gouvernance autour du conteneur.

Bien gérer le réseau d’une application conteneurisée

On sous-estime souvent le réseau parce qu’il semble moins visible que le conteneur lui-même. Pourtant, en production, c’est souvent le réseau qui raconte la vraie histoire : latence, exposition, TLS, accès externe, communication inter-services, politiques d’autorisation, contrôle d’entrée et de sortie. OpenShift structure ce sujet autour des services, des routes et de l’ingress, avec une distinction claire entre trafic interne et trafic exposé à l’extérieur. La documentation précise que l’ingress traffic accède aux services du cluster via une route, et qu’Ingress et Routes sont les ressources principales pour gérer ce trafic entrant.

Dans un contexte simple, le service permet de stabiliser le point d’entrée interne vers un ensemble de pods. La route, elle, donne une adresse publique stable pour l’utilisateur ou l’application cliente. C’est particulièrement utile quand les pods changent, se relancent ou se multiplient, parce que l’identité réseau d’un pod reste temporaire alors que la route et le service jouent le rôle de points d’accès stables.

Exemple d’une exposition HTTPS plus réaliste :

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: front-office
spec:
  host: front-office.apps.mon-cluster.example
  to:
    kind: Service
    name: front-office
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

Le point important ici, c’est qu’on ne donne pas directement aux utilisateurs accès à un pod. On leur donne accès à une entrée stable qui s’appuie sur des ressources gérées par la plateforme. Cette différence paraît subtile sur le papier, mais elle rend le système beaucoup plus robuste à long terme.

Penser en plateforme, pas en conteneur isolé

L’une des erreurs les plus fréquentes dans les migrations vers OpenShift consiste à garder une mentalité “machine virtuelle miniaturisée”. Or, OpenShift fonctionne mieux lorsqu’on pense en application distribuée, en services, en réplicas, en version d’image et en politiques. Les pods sont conçus pour être éphémères ; les déploiements sont conçus pour être refaits ; les routes sont conçues pour rester stables ; les image streams sont conçus pour suivre le changement ; les SCC sont conçues pour cadrer le comportement ; le HPA est conçu pour accompagner la variation. Quand ces éléments sont alignés, la plateforme devient très agréable à exploiter.

C’est aussi pour cela qu’OpenShift est souvent apprécié dans les organisations où l’on veut standardiser sans tout rigidifier. On peut laisser l’équipe produit travailler sur la logique métier, tout en gardant des garde-fous autour du réseau, de la sécurité et du cycle de vie des images. Le résultat est une sorte de contrat implicite : l’équipe applicative a la liberté de livrer vite, et la plateforme impose une structure exploitable par l’exploitation.

Une routine saine pour l’exploitation au quotidien

En exploitation, une routine simple vaut mieux qu’une stratégie trop ambitieuse. Il est raisonnable de commencer chaque journée ou chaque incident par quelques vérifications récurrentes : l’état des pods, la version de l’image, les événements de déploiement, la présence d’une route valide, le comportement de l’HPA et les messages liés aux politiques de sécurité. Avec oc, ces vérifications sont rapides à lancer depuis le terminal, ce qui réduit le temps entre le doute et la réponse.

Exemples utiles :

oc get pods
oc describe pod <nom-du-pod>
oc logs deploy/app-web
oc rollout status deployment/app-web
oc get events --sort-by=.metadata.creationTimestamp

Dans une équipe mature, ces commandes ne servent pas seulement à “voir si ça marche”. Elles servent à construire une mémoire collective. Un changement de tag, une hausse de consommation mémoire, un pod bloqué en démarrage, une route mal configurée ou un SCC trop strict laissent presque toujours des traces interprétables. OpenShift permet de les lire dans un cadre cohérent, ce qui accélère le diagnostic.

Bonnes pratiques qui font gagner du temps

La première bonne pratique consiste à versionner tous les manifests. Un déploiement, un service, une route, un HPA et même certaines politiques de sécurité devraient vivre dans Git au lieu d’exister seulement dans la tête de quelques personnes. Cela permet de revenir en arrière, de relire une intention, et de comprendre pourquoi un changement a été introduit.

La deuxième consiste à utiliser des images versionnées plutôt que des tags vagues. Une image latest peut être commode en phase de test, mais elle devient vite une source d’ambiguïté en production. Les image streams aident justement à contrôler cette ambiguïté, en conservant une vue lisible des versions et des déclencheurs d’évolution

La troisième consiste à déclarer les ressources dès le départ. Sans limites ni requests, les pods peuvent se retrouver dans des situations indélicates au moment de la concurrence ou de la saturation. Un bon manifeste raconte à la plateforme combien de mémoire, de CPU et d’espace éphémère un conteneur est censé utiliser. Même si cela peut sembler un détail au départ, c’est l’un des piliers de la stabilité. La documentation rappelle qu’un pod consomme des ressources de nœud et que les ressources peuvent être encadrées par des limites de projet ou de conteneur.

La quatrième consiste à penser sécurité dès le départ. Avec les SCC, OpenShift donne aux administrateurs un moyen de contrôler les permissions des pods sans bricoler a posteriori. Ne pas modifier les SCC par défaut et créer des contraintes propres au besoin est un conseil particulièrement important, car il évite des effets de bord lors des mises à jour.

Gérer les conteneurs avec OpenShift au quotidien, c’est surtout gérer des choix

Au fond, “gérer les conteneurs avec OpenShift” n’est pas seulement une question d’outillage. C’est une manière de faire des choix plus lisibles. Quel est l’état désiré de l’application ? Quelle image doit être exécutée ? Comment expose-t-on le service ? Quelles ressources lui alloue-t-on ? Quelle tolérance au changement accepte-t-on ? Quelles permissions lui accorde-t-on ? Quel événement doit déclencher une mise à jour ? OpenShift force très positivement à répondre à ces questions, et c’est souvent ce qui améliore le plus la qualité d’une plateforme en production.

Il y a aussi quelque chose d’assez humain dans cette manière de travailler. Quand l’infrastructure devient reproductible, les discussions en équipe changent. On passe moins de temps à se demander “qui a fait quoi sur la machine ?” et davantage de temps à réfléchir à la bonne architecture, à la bonne version, au bon niveau de sécurité, au bon découplage. C’est souvent là qu’une plateforme mérite vraiment son nom : elle ne se contente pas d’exécuter, elle aide à mieux décider.

Exemple de mini-chaîne complète

Pour terminer, voici un petit exemple de flux cohérent, que l’on peut adapter à un projet simple. On crée le projet, on applique le déploiement, on expose l’application, puis on ajoute l’autoscaling. Cela reste volontairement compact, mais il donne une bonne image de la logique OpenShift :

oc new-project demo-containers
oc apply -f deployment.yaml
oc apply -f service.yaml
oc apply -f route.yaml
oc apply -f hpa.yaml
oc get all

L’idée n’est pas de multiplier les commandes, mais de faire converger les objets de la plateforme vers une intention claire. Le déploiement décrit l’application, le service stabilise l’accès interne, la route ouvre l’accès externe, l’image stream suit les versions, le HPA ajuste la capacité, et les SCC encadrent l’exécution. C’est cette articulation qui rend OpenShift si intéressant pour les équipes qui veulent industrialiser les conteneurs sans perdre la main sur la sécurité ou l’exploitation.