2.9. Déployer des conteneurs

Si quelque chose se produit au cours du processus de construction, ou si une vulnérabilité est découverte après le déploiement d'une image, vous pouvez utiliser des outils pour un déploiement automatisé, basé sur des règles, afin de remédier à la situation. Vous pouvez utiliser des déclencheurs pour reconstruire et remplacer les images, en garantissant le processus de conteneurs immuables, au lieu de patcher les conteneurs en cours d'exécution, ce qui n'est pas recommandé.

Par exemple, vous construisez une application en utilisant trois couches d'images de conteneurs : le noyau, l'intergiciel et les applications. Un problème est découvert dans l'image core et cette image est reconstruite. Une fois la construction terminée, l'image est poussée vers votre OpenShift Container Registry. OpenShift Container Platform détecte que l'image a changé et reconstruit et déploie automatiquement l'image de l'application, en fonction des déclencheurs définis. Ce changement incorpore les bibliothèques corrigées et garantit que le code de production est identique à l'image la plus récente.

Vous pouvez utiliser la commande oc set triggers pour définir un déclencheur de déploiement. Par exemple, pour définir un déclencheur de déploiement appelé déploiement-exemple :

$ oc set triggers deploy/deployment-example \
    --from-image=example:latest \
    --containers=web

Il est important que les images prévues soient effectivement déployées, que les images et leur contenu proviennent de sources fiables et qu'elles n'aient pas été modifiées. La signature cryptographique fournit cette assurance. OpenShift Container Platform permet aux administrateurs de clusters d'appliquer une politique de sécurité plus ou moins large, en fonction de l'environnement de déploiement et des exigences de sécurité. Deux paramètres définissent cette politique :

Vous pouvez utiliser ces paramètres de stratégie pour autoriser, refuser ou exiger une relation de confiance pour des registres entiers, des parties de registres ou des images individuelles. En utilisant des clés publiques de confiance, vous pouvez vous assurer que la source est vérifiée cryptographiquement. Les règles de stratégie s'appliquent aux nœuds. La stratégie peut être appliquée uniformément à tous les nœuds ou ciblée en fonction des charges de travail des différents nœuds (par exemple, construction, zone ou environnement).

{
    "default": [{"type": "reject"}],
    "transports": {
        "docker": {
            "access.redhat.com": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ]
        },
        "atomic": {
            "172.30.1.1:5000/openshift": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"
                }
            ],
            "172.30.1.1:5000/production": [
                {
                    "type": "signedBy",
                    "keyType": "GPGKeys",
                    "keyPath": "/etc/pki/example.com/pubkey"
                }
            ],
            "172.30.1.1:5000": [{"type": "reject"}]
        }
    }
}

La politique peut être enregistrée sur un nœud sous le nom de /etc/containers/policy.json. La meilleure façon d'enregistrer ce fichier sur un nœud est d'utiliser un nouvel objet MachineConfig. Cet exemple applique les règles suivantes :

Un transport de signature est un moyen de stocker et de récupérer le blob de signature binaire. Il existe deux types de transport de signature.

L'API OpenShift Container Platform gère les signatures qui utilisent le type de transport atomic. Vous devez stocker les images qui utilisent ce type de signature dans votre OpenShift Container Registry. Comme l'API docker/distribution extensions découvre automatiquement le point de terminaison de la signature de l'image, aucune configuration supplémentaire n'est nécessaire.

Les signatures qui utilisent le type de transport docker sont servies par un serveur de fichiers ou un serveur web local. Ces signatures sont plus souples ; vous pouvez servir des images à partir de n'importe quel registre d'images de conteneurs et utiliser un serveur indépendant pour fournir des signatures binaires.

Cependant, le type de transport docker nécessite une configuration supplémentaire. Vous devez configurer les nœuds avec l'URI du serveur de signatures en plaçant des fichiers YAML aux noms arbitraires dans un répertoire du système hôte, /etc/containers/registries.d par défaut. Les fichiers de configuration YAML contiennent un URI de registre et un URI de serveur de signatures, ou sigstore:

docker:
    access.redhat.com:
        sigstore: https://access.redhat.com/webassets/docker/content/sigstore

Dans cet exemple, le Red Hat Registry, access.redhat.com, est le serveur de signatures qui fournit des signatures pour le type de transport docker. Son URI est défini dans le paramètre sigstore. Vous pouvez nommer ce fichier /etc/containers/registries.d/redhat.com.yaml et utiliser l'opérateur Machine Config pour placer automatiquement le fichier sur chaque nœud de votre cluster. Aucun redémarrage de service n'est nécessaire puisque les fichiers Policy et registries.d sont chargés dynamiquement par le runtime du conteneur.

Le type d'objet Secret fournit un mécanisme pour contenir des informations sensibles telles que les mots de passe, les fichiers de configuration du client OpenShift Container Platform, les fichiers dockercfg et les informations d'identification du référentiel source privé. Les secrets découplent le contenu sensible des pods. Vous pouvez monter des secrets dans des conteneurs à l'aide d'un plugin de volume ou le système peut utiliser des secrets pour effectuer des actions au nom d'un pod.

Par exemple, pour ajouter un secret à votre configuration de déploiement afin qu'il puisse accéder à un référentiel d'images privé, procédez comme suit :

Les cartes de configuration sont similaires aux secrets, mais elles sont conçues pour permettre de travailler avec des chaînes qui ne contiennent pas d'informations sensibles. L'objet ConfigMap contient des paires clé-valeur de données de configuration qui peuvent être consommées dans des pods ou utilisées pour stocker des données de configuration pour des composants du système tels que les contrôleurs.

Vous pouvez intégrer votre propre outil de déploiement continu (CD) à OpenShift Container Platform.

En tirant parti de CI/CD et d'OpenShift Container Platform, vous pouvez automatiser le processus de reconstruction de l'application afin d'intégrer les dernières corrections, de tester et de veiller à ce qu'elle soit déployée partout dans l'environnement.