Chapitre 3. Création d’applications
3.1. En utilisant des modèles Copier lienLien copié sur presse-papiers!
Les sections suivantes fournissent un aperçu des modèles, ainsi que la façon de les utiliser et de les créer.
3.1.1. Comprendre les modèles Copier lienLien copié sur presse-papiers!
Le modèle décrit un ensemble d’objets qui peuvent être paramétrés et traités pour produire une liste d’objets à créer par OpenShift Dedicated. Le modèle peut être traité pour créer tout ce que vous avez la permission de créer dans un projet, par exemple des services, des configurations de construction et des configurations de déploiement. Le modèle peut également définir un ensemble d’étiquettes à appliquer à chaque objet défini dans le modèle.
Il est possible de créer une liste d’objets à partir d’un modèle à l’aide du CLI ou, si un modèle a été téléchargé dans votre projet ou dans la bibliothèque globale de modèles, à l’aide de la console Web.
3.1.2. Chargement d’un modèle Copier lienLien copié sur presse-papiers!
Lorsque vous avez un fichier JSON ou YAML qui définit un modèle, vous pouvez télécharger le modèle vers des projets à l’aide du CLI. Cela permet d’enregistrer le modèle au projet pour une utilisation répétée par tout utilisateur ayant un accès approprié à ce projet. Des instructions sur la rédaction de vos propres modèles sont fournies plus tard dans ce sujet.
Procédure
Envoyez un modèle en utilisant l’une des méthodes suivantes:
Envoyez un modèle dans la bibliothèque de modèles de votre projet actuel, passez le fichier JSON ou YAML avec la commande suivante:
oc create -f <filename>
$ oc create -f <filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Envoyez un modèle vers un autre projet en utilisant l’option -n avec le nom du projet:
oc create -f <filename> -n <project>
$ oc create -f <filename> -n <project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Le modèle est maintenant disponible pour la sélection à l’aide de la console Web ou du CLI.
3.1.3. Créer une application à l’aide de la console Web Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser la console Web pour créer une application à partir d’un modèle.
Procédure
- Choisissez Développeur dans le sélecteur de contexte en haut du menu de navigation de la console Web.
- Dans le projet souhaité, cliquez sur +Ajouter
- Cliquez sur Tous les services dans la tuile du catalogue des développeurs.
Cliquez sur Builder Images sous Type pour voir les images du constructeur disponibles.
NoteLes balises de flux d’images qui ont la balise constructeur listée dans leurs annotations apparaissent dans cette liste, comme démontré ici:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Inclure le constructeur ici s’assure que cette balise de flux d’images apparaît dans la console Web en tant que constructeur.
- Modifiez les paramètres dans le nouvel écran de l’application pour configurer les objets pour prendre en charge votre application.
3.1.4. Création d’objets à partir de modèles en utilisant le CLI Copier lienLien copié sur presse-papiers!
Il est possible d’utiliser le CLI pour traiter les modèles et utiliser la configuration générée pour créer des objets.
3.1.4.1. Ajout d’étiquettes Copier lienLien copié sur presse-papiers!
Les étiquettes sont utilisées pour gérer et organiser des objets générés, tels que des pods. Les étiquettes spécifiées dans le modèle sont appliquées à chaque objet généré à partir du modèle.
Procédure
Ajouter des étiquettes dans le modèle à partir de la ligne de commande:
oc process -f <filename> -l name=otherLabel
$ oc process -f <filename> -l name=otherLabel
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.4.2. Liste des paramètres Copier lienLien copié sur presse-papiers!
La liste des paramètres que vous pouvez remplacer sont listées dans la section paramètres du modèle.
Procédure
Il est possible de répertorier les paramètres avec le CLI en utilisant la commande suivante et en spécifiant le fichier à utiliser:
oc process --parameters -f <filename>
$ oc process --parameters -f <filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Alternativement, si le modèle est déjà téléchargé:
oc process --parameters -n <project> <template_name>
$ oc process --parameters -n <project> <template_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow À titre d’exemple, ce qui suit montre la sortie lors de la liste des paramètres de l’un des modèles de démarrage rapide dans le projet openshift par défaut:
oc process --parameters -n openshift rails-postgresql-example
$ oc process --parameters -n openshift rails-postgresql-example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
Copy to Clipboard Copied! Toggle word wrap Toggle overflow La sortie identifie plusieurs paramètres qui sont générés avec un générateur d’expression régulier lorsque le modèle est traité.
3.1.4.3. Générer une liste d’objets Copier lienLien copié sur presse-papiers!
En utilisant le CLI, vous pouvez traiter un fichier définissant un modèle pour retourner la liste des objets à la sortie standard.
Procédure
Le processus d’un fichier définissant un modèle pour retourner la liste des objets à la sortie standard:
oc process -f <filename>
$ oc process -f <filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Alternativement, si le modèle a déjà été téléchargé dans le projet actuel:
oc process <template_name>
$ oc process <template_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Créez des objets à partir d’un modèle en traitant le modèle et en comblant la sortie pour créer:
oc process -f <filename> | oc create -f -
$ oc process -f <filename> | oc create -f -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Alternativement, si le modèle a déjà été téléchargé dans le projet actuel:
oc process <template> | oc create -f -
$ oc process <template> | oc create -f -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Il est possible de remplacer les valeurs de paramètres définies dans le fichier en ajoutant l’option -p pour chaque paire <nom>=<valeur> que vous souhaitez remplacer. La référence de paramètre apparaît dans n’importe quel champ de texte à l’intérieur des éléments de modèle.
Dans les paramètres POSTGRESQL_USER et POSTGRESQL_DATABASE suivants, les paramètres POSTGRESQL_DATABASE d’un modèle sont dépassés pour produire une configuration avec des variables d’environnement personnalisées:
Création d’une liste d’objets à partir d’un modèle
oc process -f my-rails-postgresql \ -p POSTGRESQL_USER=bob \ -p POSTGRESQL_DATABASE=mydatabase
$ oc process -f my-rails-postgresql \ -p POSTGRESQL_USER=bob \ -p POSTGRESQL_DATABASE=mydatabase
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Le fichier JSON peut être redirigé vers un fichier ou appliqué directement sans télécharger le modèle en supprimant la sortie traitée vers la commande oc create:
oc process -f my-rails-postgresql \ -p POSTGRESQL_USER=bob \ -p POSTGRESQL_DATABASE=mydatabase \ | oc create -f -
$ oc process -f my-rails-postgresql \ -p POSTGRESQL_USER=bob \ -p POSTGRESQL_DATABASE=mydatabase \ | oc create -f -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Lorsque vous disposez d’un grand nombre de paramètres, vous pouvez les stocker dans un fichier, puis passer ce fichier au processus oc:
cat postgres.env POSTGRESQL_USER=bob POSTGRESQL_DATABASE=mydatabase
$ cat postgres.env POSTGRESQL_USER=bob POSTGRESQL_DATABASE=mydatabase
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc process -f my-rails-postgresql --param-file=postgres.env
$ oc process -f my-rails-postgresql --param-file=postgres.env
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Il est également possible de lire l’environnement à partir de l’entrée standard en utilisant "-" comme argument pour --param-file:
sed s/bob/alice/ postgres.env | oc process -f my-rails-postgresql --param-file=-
$ sed s/bob/alice/ postgres.env | oc process -f my-rails-postgresql --param-file=-
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.5. La modification des modèles téléchargés Copier lienLien copié sur presse-papiers!
Il est possible d’éditer un modèle qui a déjà été téléchargé sur votre projet.
Procédure
De modifier un modèle qui a déjà été téléchargé:
oc edit template <template>
$ oc edit template <template>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.1.6. Écrire des modèles Copier lienLien copié sur presse-papiers!
Il est possible de définir de nouveaux modèles pour faciliter la recréation de tous les objets de votre application. Le modèle définit les objets qu’il crée ainsi que certaines métadonnées pour guider la création de ces objets.
Ce qui suit est un exemple d’une définition simple d’objet modèle (YAML):
3.1.6.1. Écrire la description du modèle Copier lienLien copié sur presse-papiers!
La description du modèle vous informe de ce que le modèle fait et vous aide à le trouver lors de la recherche dans la console Web. Des métadonnées supplémentaires au-delà du nom du modèle sont facultatives, mais utiles à avoir. En plus des informations descriptives générales, les métadonnées comprennent également un ensemble de balises. Les balises utiles incluent le nom du langage auquel le modèle est lié par exemple, Java, PHP, Ruby, etc.
Ce qui suit est un exemple de métadonnées de description de modèle:
- 1
- Le nom unique du modèle.
- 2
- Bref, nom convivial, qui peut être utilisé par les interfaces utilisateur.
- 3
- Description du modèle. Incluez suffisamment de détails pour que les utilisateurs comprennent ce qui est déployé et toutes les mises en garde qu’ils doivent savoir avant de le déployer. Il devrait également fournir des liens vers des informations supplémentaires, comme un fichier README. Les nouvelles lignes peuvent être incluses pour créer des paragraphes.
- 4
- Description de modèle supplémentaire. Cela peut être affiché par le catalogue de services, par exemple.
- 5
- Balises à associer au modèle pour la recherche et le regroupement. Ajoutez des tags qui l’incluent dans l’une des catégories de catalogue fournies. Consultez l’id et la catégorieAliases dans CATALOG_CATEGORIES dans le fichier constants de la console.
- 6
- Icône à afficher avec votre modèle dans la console Web.
Exemple 3.1. Icônes disponibles
-
icône-3scale
-
icône-aerogear
-
icône-amq
-
icône-angularjs
-
icône-ansible
-
icône-apache
-
icône-beaker
-
icône-camel
-
icône-capedwarf
-
icône-cassandra
-
icône-catalog-icon
-
icône-clojure
-
icône-codeigniter
-
icône-cordova
-
icône-datagrid
-
icône-datavirt
-
icône-debian
-
icône-decisionserver
-
icône-django
-
icône-dotnet
-
icône-drupal
-
icône-eap
-
icône-élastique
-
icône-erlang
-
icône-fedora
-
icône-freebsd
-
icône-git
-
icône-github
-
icône-gitlab
-
icône-verre de poisson
-
icône-go-gopher
-
icône-golang
-
icône-grails
-
icône-hadoop
-
icône-haproxy
-
icône-helm
-
icône-infinispan
-
icône-jboss
-
icône-jenkins
-
icône-jetée
-
icône-joomla
-
icône-jruby
-
icône-js
-
icône-knative
-
icône-kubevirt
-
icône-laravel
-
icône-charge-balanceur
-
icône-mariadb
-
icône-mediawiki
-
icône-memcached
-
icône-mongodb
-
icône-mssql
-
icône-mysql-base de données
-
icône-nginx
-
icône-nodejs
-
icône-openjdk
-
icône-openliberty
-
icône-openshift
-
icône-openstack
-
icône-autre-linux
-
icône-autre-inconnu
-
icône-perl
-
icône-phalcon
-
icône-php
-
jeu d’icônes
-
icônepostgresql
-
icône-processserver
-
icône-python
-
icône-quarkus
-
icône-rabbitmq
-
icône-rails
-
icône-redhat
-
icône-redis
-
icône-rh-intégration
-
icône-rh-spring-boot
-
icône-rh-tomcat
-
icône-ruby
-
icône-scala
-
icône-serverlessfx
-
icône-shadowman
-
icône-spring-boot
-
icône-spring
-
icône-sso
-
icône-stackoverflow
-
icône-suse
-
icône-symfony
-
icône-tomcat
-
icône-ubuntu
-
icône-vertx
-
icône-wildfly
-
icône-fenêtres
-
icône-motpress
-
icône-xamarin
-
icône-zend
-
- 7
- Le nom de la personne ou de l’organisation fournissant le modèle.
- 8
- D’une URL faisant référence à d’autres documents pour le modèle.
- 9
- D’une URL où le support peut être obtenu pour le modèle.
- 10
- C’est un message d’instruction qui s’affiche lorsque ce modèle est instancié. Ce champ devrait indiquer à l’utilisateur comment utiliser les ressources nouvellement créées. La substitution de paramètres est effectuée sur le message avant d’être affichée de sorte que les informations d’identification générées et d’autres paramètres puissent être inclus dans la sortie. Inclure des liens vers toute documentation suivante que les utilisateurs devraient suivre.
3.1.6.2. Écrire des étiquettes de modèle Copier lienLien copié sur presse-papiers!
Les modèles peuvent inclure un ensemble d’étiquettes. Ces étiquettes sont ajoutées à chaque objet créé lorsque le modèle est instancié. Définir une étiquette de cette façon permet aux utilisateurs de trouver et de gérer facilement tous les objets créés à partir d’un modèle particulier.
Ce qui suit est un exemple d’étiquettes d’objets de modèle:
3.1.6.3. Écrire des paramètres de modèle Copier lienLien copié sur presse-papiers!
Les paramètres permettent qu’une valeur soit fournie par vous ou générée lorsque le modèle est instancié. Ensuite, cette valeur est remplacée partout où le paramètre est référencé. Les références peuvent être définies dans n’importe quel champ dans le champ de liste d’objets. Ceci est utile pour générer des mots de passe aléatoires ou vous permettre de fournir un nom d’hôte ou une autre valeur spécifique à l’utilisateur qui est nécessaire pour personnaliser le modèle. Les paramètres peuvent être référencés de deux manières:
- En tant que valeur de chaîne en plaçant des valeurs dans le formulaire ${PARAMETER_NAME} dans n’importe quel champ de chaîne du modèle.
- En tant que valeur JSON ou YAML en plaçant des valeurs dans la forme ${PARAMETER_NAME}} à la place de n’importe quel champ dans le modèle.
Lors de l’utilisation de la syntaxe ${PARAMETER_NAME}, plusieurs références de paramètres peuvent être combinées dans un seul champ et la référence peut être intégrée dans des données fixes, telles que "http://${PARAMETER_1}${PARAMETER_2}". Les deux valeurs de paramètres sont substituées et la valeur résultante est une chaîne citée.
Lors de l’utilisation de la syntaxe ${{PARAMETER_NAME}} seule une seule référence de paramètre est autorisée et les caractères menant et traînant ne sont pas autorisés. La valeur résultante n’est pas citée à moins que, après la substitution, le résultat n’est pas un objet JSON valide. Lorsque le résultat n’est pas une valeur JSON valide, la valeur résultante est citée et traitée comme une chaîne standard.
Il peut être référencé plusieurs fois dans un modèle et il peut être référencé à l’aide des deux syntaxes de substitution au sein d’un seul modèle.
La valeur par défaut peut être fournie, qui est utilisée si vous ne fournissez pas une valeur différente:
Ce qui suit est un exemple de définition d’une valeur explicite comme valeur par défaut:
parameters: - name: USERNAME description: "The user name for Joe" value: joe
parameters:
- name: USERNAME
description: "The user name for Joe"
value: joe
Les valeurs de paramètre peuvent également être générées en fonction des règles spécifiées dans la définition des paramètres, par exemple en générant une valeur de paramètre:
parameters: - name: PASSWORD description: "The random user password" generate: expression from: "[a-zA-Z0-9]{12}"
parameters:
- name: PASSWORD
description: "The random user password"
generate: expression
from: "[a-zA-Z0-9]{12}"
Dans l’exemple précédent, le traitement génère un mot de passe aléatoire de 12 caractères, composé de toutes les lettres et chiffres de l’alphabet majuscule et minuscule.
La syntaxe disponible n’est pas une syntaxe d’expression régulière complète. Cependant, vous pouvez utiliser \w, \d, \a et \A modificateurs:
- [\W]{10} produit 10 caractères de l’alphabet, des nombres et des accents. Ceci suit la norme PCRE et est égal à [a-zA-Z0-9_]{10}.
- [\d]{10} produit 10 nombres. Ceci est égal à [0-9]{10}.
- [\a]{10} produit 10 caractères alphabétiques. Ceci est égal à [a-zA-Z]{10}.
- [\A]{10} produit 10 caractères de ponctuation ou de symbole. Ceci est égal à [~!@#$%\^&*()\-_+={}\\\\|<,>.?/"';:']{10}.
En fonction de si le modèle est écrit dans YAML ou JSON, et le type de chaîne dans laquelle le modificateur est intégré, vous devrez peut-être échapper au backslash avec un second backslash. Les exemples suivants sont équivalents:
Exemple de modèle YAML avec un modificateur
Exemple de modèle JSON avec un modificateur
En voici un exemple d’un modèle complet avec des définitions de paramètres et des références:
- 1
- Cette valeur est remplacée par la valeur du paramètre SOURCE_REPOSITORY_URL lorsque le modèle est instancié.
- 2
- Cette valeur est remplacée par la valeur non citée du paramètre REPLICA_COUNT lorsque le modèle est instancié.
- 3
- Le nom du paramètre. Cette valeur est utilisée pour référencer le paramètre dans le modèle.
- 4
- Le nom convivial du paramètre. Ceci est affiché pour les utilisateurs.
- 5
- Description du paramètre. Fournir des informations plus détaillées aux fins du paramètre, y compris toute contrainte sur la valeur attendue. Les descriptions doivent utiliser des phrases complètes pour suivre les normes de texte de la console. Il ne s’agit pas d’un duplicata du nom d’affichage.
- 6
- La valeur par défaut du paramètre qui est utilisé si vous ne remplacez pas la valeur lors de l’instanciation du modèle. Évitez d’utiliser des valeurs par défaut pour des choses comme les mots de passe, utilisez plutôt les paramètres générés en combinaison avec des secrets.
- 7
- Indique que ce paramètre est requis, ce qui signifie que vous ne pouvez pas le remplacer par une valeur vide. Dans le cas où le paramètre ne fournit pas de valeur par défaut ou générée, vous devez fournir une valeur.
- 8
- C’est un paramètre qui a sa valeur générée.
- 9
- L’entrée au générateur. Dans ce cas, le générateur produit une valeur alphanumérique de 40 caractères incluant des caractères majuscules et minuscules.
- 10
- Les paramètres peuvent être inclus dans le message de modèle. Cela vous informe des valeurs générées.
3.1.6.4. Écrire la liste d’objets du modèle Copier lienLien copié sur presse-papiers!
La partie principale du modèle est la liste des objets qui est créé lorsque le modèle est instancié. Cela peut être n’importe quel objet API valide, tel qu’une configuration de build, une configuration de déploiement ou un service. L’objet est créé exactement comme défini ici, avec des valeurs de paramètres substituées avant la création. La définition de ces objets peut référencer les paramètres définis précédemment.
Ce qui suit est un exemple d’une liste d’objets:
- 1
- La définition d’un service, qui est créé par ce modèle.
Lorsqu’une métadonnées de définition d’objet comprend une valeur de champ d’espace de noms fixe, le champ est retiré de la définition lors de l’instanciation du modèle. Lorsque le champ namespace contient une référence de paramètre, une substitution de paramètre normale est effectuée et l’objet est créé dans n’importe quel espace de noms auquel le paramètre a résolu la valeur, en supposant que l’utilisateur ait l’autorisation de créer des objets dans cet espace de noms.
3.1.6.5. Marquer un modèle comme liable Copier lienLien copié sur presse-papiers!
Le Template Service Broker annonce un service dans son catalogue pour chaque objet de modèle dont il est conscient. Chacun de ces services est annoncé par défaut comme étant liable, ce qui signifie qu’un utilisateur final est autorisé à se lier contre le service fourni.
Procédure
Les auteurs de modèles peuvent empêcher les utilisateurs finaux de se lier contre les services fournis à partir d’un modèle donné.
- Empêcher l’utilisateur final de se lier contre les services fournis à partir d’un modèle donné en ajoutant l’annotation template.openshift.io/bindable: "faux" au modèle.
3.1.6.6. Exposer les champs d’objets du modèle Copier lienLien copié sur presse-papiers!
Les auteurs de modèles peuvent indiquer que des champs d’objets particuliers dans un modèle doivent être exposés. Le Template Service Broker reconnaît les champs exposés sur les objets ConfigMap, Secret, Service et Route, et retourne les valeurs des champs exposés lorsqu’un utilisateur lie un service soutenu par le courtier.
Afin d’exposer un ou plusieurs champs d’un objet, ajoutez des annotations préfixées par template.openshift.io/expose- ou template.openshift.io/base64-expose- à l’objet dans le modèle.
Chaque clé d’annotation, avec son préfixe supprimé, est passée à travers pour devenir une clé dans une réponse de liaison.
Chaque valeur d’annotation est une expression Kubernetes JSONPath, qui est résolue au moment de la liaison pour indiquer le champ objet dont la valeur doit être retournée dans la réponse de liaison.
Les paires clé-valeur de réponse peuvent être utilisées dans d’autres parties du système comme variables d’environnement. Il est donc recommandé que chaque clé d’annotation avec son préfixe soit un nom de variable d’environnement valide - commençant par un caractère A-Z, a-z, ou _, et étant suivi de zéro ou plus caractères A-Z, a-z, 0-9, ou _.
À moins de s’échapper avec un backslash, l’implémentation JSONPath de Kubernetes interprète des caractères tels que ., @, et d’autres comme métacaractères, quelle que soit leur position dans l’expression. Donc, par exemple, pour se référer à un datum ConfigMap nommé my.key, l’expression JSONPath requise serait {.data['my\.key']}. En fonction de la façon dont l’expression JSONPath est alors écrite en YAML, un backslash supplémentaire peut être requis, par exemple "{.data['my\\\.key']}.
Ce qui suit est un exemple de champs d’objets différents exposés:
Exemple de réponse à une opération de liaison étant donné le modèle partiel ci-dessus:
Procédure
- L’annotation template.openshift.io/expose- renvoie la valeur du champ en tant que chaîne de caractères. C’est pratique, bien qu’il ne traite pas de données binaires arbitraires.
- Lorsque vous souhaitez retourner des données binaires, utilisez l’annotation template.openshift.io/base64-expose- pour coder les données avant qu’elles ne soient retournées.
3.1.6.7. En attente d’un modèle de préparation Copier lienLien copié sur presse-papiers!
Les auteurs de modèles peuvent indiquer que certains objets d’un modèle doivent être attendus avant qu’une instanciation de modèle par le catalogue de service, Template Service Broker ou l’API TemplateInstance soit considérée comme complète.
Afin d’utiliser cette fonctionnalité, marquez un ou plusieurs objets de type Build, BuildConfig, Deployment, DeploymentConfig, Job ou StatefulSet dans un modèle avec l’annotation suivante:
"template.alpha.openshift.io/wait-for-ready": "true"
"template.alpha.openshift.io/wait-for-ready": "true"
L’instanciation du modèle n’est pas terminée tant que tous les objets marqués du rapport d’annotation ne sont pas prêts. De même, si l’un des rapports d’objets annotés a échoué, ou si le modèle ne parvient pas à devenir prêt dans un délai fixe d’une heure, l’instanciation du modèle échoue.
Aux fins de l’instanciation, la préparation et l’échec de chaque type d’objet sont définis comme suit:
Je suis gentille. | L’état de préparation | Échec |
---|---|---|
| La phase des rapports d’objets est terminée. | Les rapports d’objets ont été annulés, une erreur ou un échec. |
| Les derniers rapports d’objets associés sont terminés. | Les derniers rapports d’objets de construction associés ont été annulés, erreurs ou échoués. |
| L’objet signale un nouvel ensemble de répliques et un déploiement disponible. Cela honore les sondes de préparation définies sur l’objet. | L’état d’avancement des rapports d’objet est faux. |
| L’objet signale le nouveau contrôleur de réplication et le déploiement disponible. Cela honore les sondes de préparation définies sur l’objet. | L’état d’avancement des rapports d’objet est faux. |
| Les rapports d’objet sont terminés. | L’objet signale qu’un ou plusieurs échecs ont eu lieu. |
| L’objet signale toutes les répliques prêtes. Cela honore les sondes de préparation définies sur l’objet. | Ce n’est pas applicable. |
Ce qui suit est un exemple d’extrait de modèle, qui utilise l’annotation prête à attendre. D’autres exemples peuvent être trouvés dans les modèles de démarrage rapide OpenShift Dédiés.
Autres recommandations
- Définissez la mémoire, le CPU et les tailles par défaut de stockage pour vous assurer que votre application dispose de suffisamment de ressources pour fonctionner en douceur.
- Évitez de faire référence à la dernière balise à partir d’images si cette balise est utilisée dans les versions principales. Cela peut causer des applications en cours d’exécution à casser lorsque de nouvelles images sont poussées vers cette balise.
- Après le déploiement du modèle, un bon modèle construit et déploie proprement sans nécessiter de modifications.
3.1.6.8. Créer un modèle à partir d’objets existants Copier lienLien copié sur presse-papiers!
Au lieu d’écrire un modèle entier à partir de zéro, vous pouvez exporter des objets existants de votre projet dans le formulaire YAML, puis modifier le YAML à partir de là en ajoutant des paramètres et d’autres personnalisations en tant que formulaire de modèle.
Procédure
Exporter des objets dans un projet sous forme YAML:
oc get -o yaml all > <yaml_filename>
$ oc get -o yaml all > <yaml_filename>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Il est également possible de substituer un type de ressource particulier ou plusieurs ressources au lieu de toutes. Exécutez oc get -h pour plus d’exemples.
Les types d’objets inclus dans oc get -o yaml tous sont:
-
BuildConfig
-
Construire
-
DéploiementConfig
-
ImageStream
-
La pod
-
Contrôleur de réplication
-
Itinéraire
-
Le service
-
L’utilisation de tous les alias n’est pas recommandée car le contenu peut varier selon différents clusters et versions. Au lieu de cela, spécifiez toutes les ressources requises.