Chapitre 3. Création d’applications


3.1. En utilisant des modèles

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

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

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>
      Copy to Clipboard
    • Envoyez un modèle vers un autre projet en utilisant l’option -n avec le nom du projet:

      $ oc create -f <filename> -n <project>
      Copy to Clipboard

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

Il est possible d’utiliser la console Web pour créer une application à partir d’un modèle.

Procédure

  1. Choisissez Développeur dans le sélecteur de contexte en haut du menu de navigation de la console Web.
  2. Dans le projet souhaité, cliquez sur +Ajouter
  3. Cliquez sur Tous les services dans la tuile du catalogue des développeurs.
  4. Cliquez sur Builder Images sous Type pour voir les images du constructeur disponibles.

    Note

    Les balises de flux d’images qui ont la balise constructeur listée dans leurs annotations apparaissent dans cette liste, comme démontré ici:

    kind: "ImageStream"
    apiVersion: "image.openshift.io/v1"
    metadata:
      name: "ruby"
      creationTimestamp: null
    spec:
    # ...
      tags:
        - name: "2.6"
          annotations:
            description: "Build and run Ruby 2.6 applications"
            iconClass: "icon-ruby"
            tags: "builder,ruby" 
    1
    
            supports: "ruby:2.6,ruby"
            version: "2.6"
    # ...
    Copy to Clipboard
    1
    Inclure le constructeur ici s’assure que cette balise de flux d’images apparaît dans la console Web en tant que constructeur.
  5. 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

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

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
    Copy to Clipboard

3.1.4.2. Liste des paramètres

La liste des paramètres que vous pouvez remplacer sont listées dans la section paramètres du modèle.

Procédure

  1. 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>
    Copy to Clipboard

    Alternativement, si le modèle est déjà téléchargé:

    $ oc process --parameters -n <project> <template_name>
    Copy to Clipboard

    À 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
    Copy to Clipboard

    Exemple de sortie

    NAME                         DESCRIPTION                                                                                              GENERATOR           VALUE
    SOURCE_REPOSITORY_URL        The URL of the repository with your application source code                                                                  https://github.com/sclorg/rails-ex.git
    SOURCE_REPOSITORY_REF        Set this to a branch name, tag or other ref of your repository if you are not using the default branch
    CONTEXT_DIR                  Set this to the relative path to your project if it is not in the root of your repository
    APPLICATION_DOMAIN           The exposed hostname that will route to the Rails service                                                                    rails-postgresql-example.openshiftapps.com
    GITHUB_WEBHOOK_SECRET        A secret string used to configure the GitHub webhook                                                     expression          [a-zA-Z0-9]{40}
    SECRET_KEY_BASE              Your secret key for verifying the integrity of signed cookies                                            expression          [a-z0-9]{127}
    APPLICATION_USER             The application user that is used within the sample application to authorize access on pages                                 openshift
    APPLICATION_PASSWORD         The application password that is used within the sample application to authorize access on pages                             secret
    DATABASE_SERVICE_NAME        Database service name                                                                                                        postgresql
    POSTGRESQL_USER              database username                                                                                        expression          user[A-Z0-9]{3}
    POSTGRESQL_PASSWORD          database password                                                                                        expression          [a-zA-Z0-9]{8}
    POSTGRESQL_DATABASE          database name                                                                                                                root
    POSTGRESQL_MAX_CONNECTIONS   database max connections                                                                                                     10
    POSTGRESQL_SHARED_BUFFERS    database shared buffers                                                                                                      12MB
    Copy to Clipboard

    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

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

  1. Le processus d’un fichier définissant un modèle pour retourner la liste des objets à la sortie standard:

    $ oc process -f <filename>
    Copy to Clipboard

    Alternativement, si le modèle a déjà été téléchargé dans le projet actuel:

    $ oc process <template_name>
    Copy to Clipboard
  2. 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 -
    Copy to Clipboard

    Alternativement, si le modèle a déjà été téléchargé dans le projet actuel:

    $ oc process <template> | oc create -f -
    Copy to Clipboard
  3. Il est possible de remplacer les valeurs de paramètres définies dans le fichier en ajoutant l’option -p pour chaque paire &lt;nom&gt;=&lt;valeur&gt; 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:

    1. 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
      Copy to Clipboard
    2. 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 -
      Copy to Clipboard
    3. 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
      Copy to Clipboard
      $ oc process -f my-rails-postgresql --param-file=postgres.env
      Copy to Clipboard
    4. 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=-
      Copy to Clipboard

3.1.5. La modification des modèles téléchargés

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>
    Copy to Clipboard

3.1.6. Écrire des modèles

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):

apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: redis-template
  annotations:
    description: "Description"
    iconClass: "icon-redis"
    tags: "database,nosql"
objects:
- apiVersion: v1
  kind: Pod
  metadata:
    name: redis-master
  spec:
    containers:
    - env:
      - name: REDIS_PASSWORD
        value: ${REDIS_PASSWORD}
      image: dockerfile/redis
      name: master
      ports:
      - containerPort: 6379
        protocol: TCP
parameters:
- description: Password used for Redis authentication
  from: '[A-Z0-9]{8}'
  generate: expression
  name: REDIS_PASSWORD
labels:
  redis: master
Copy to Clipboard

3.1.6.1. Écrire la description du modèle

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:

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: cakephp-mysql-example 
1

  annotations:
    openshift.io/display-name: "CakePHP MySQL Example (Ephemeral)" 
2

    description: >-
      An example CakePHP application with a MySQL database. For more information
      about using this template, including OpenShift considerations, see
      https://github.com/sclorg/cakephp-ex/blob/master/README.md.


      WARNING: Any data stored will be lost upon pod destruction. Only use this
      template for testing." 
3

    openshift.io/long-description: >-
      This template defines resources needed to develop a CakePHP application,
      including a build configuration, application DeploymentConfig, and
      database DeploymentConfig.  The database is stored in
      non-persistent storage, so this configuration should be used for
      experimental purposes only. 
4

    tags: "quickstart,php,cakephp" 
5

    iconClass: icon-php 
6

    openshift.io/provider-display-name: "Red Hat, Inc." 
7

    openshift.io/documentation-url: "https://github.com/sclorg/cakephp-ex" 
8

    openshift.io/support-url: "https://access.redhat.com" 
9

message: "Your admin credentials are ${ADMIN_USERNAME}:${ADMIN_PASSWORD}" 
10
Copy to Clipboard
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

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:

kind: "Template"
apiVersion: "v1"
...
labels:
  template: "cakephp-mysql-example" 
1

  app: "${NAME}" 
2
Copy to Clipboard
1
Étiquette appliquée à tous les objets créés à partir de ce modèle.
2
Étiquette paramétrée qui est également appliquée à tous les objets créés à partir de ce modèle. L’expansion des paramètres est effectuée à la fois sur les clés d’étiquette et sur les valeurs.

3.1.6.3. Écrire des paramètres de modèle

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
Copy to Clipboard

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}"
Copy to Clipboard

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 à [~!@#$%\^&amp;*()\-_+={}\\\\|&lt;,&gt;.?/"';:']{10}.
Note

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

  parameters:
  - name: singlequoted_example
    generate: expression
    from: '[\A]{10}'
  - name: doublequoted_example
    generate: expression
    from: "[\\A]{10}"
Copy to Clipboard

Exemple de modèle JSON avec un modificateur

{
    "parameters": [
       {
        "name": "json_example",
        "generate": "expression",
        "from": "[\\A]{10}"
       }
    ]
}
Copy to Clipboard

En voici un exemple d’un modèle complet avec des définitions de paramètres et des références:

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: my-template
objects:
  - kind: BuildConfig
    apiVersion: build.openshift.io/v1
    metadata:
      name: cakephp-mysql-example
      annotations:
        description: Defines how to build the application
    spec:
      source:
        type: Git
        git:
          uri: "${SOURCE_REPOSITORY_URL}" 
1

          ref: "${SOURCE_REPOSITORY_REF}"
        contextDir: "${CONTEXT_DIR}"
  - kind: DeploymentConfig
    apiVersion: apps.openshift.io/v1
    metadata:
      name: frontend
    spec:
      replicas: "${{REPLICA_COUNT}}" 
2

parameters:
  - name: SOURCE_REPOSITORY_URL 
3

    displayName: Source Repository URL 
4

    description: The URL of the repository with your application source code 
5

    value: https://github.com/sclorg/cakephp-ex.git 
6

    required: true 
7

  - name: GITHUB_WEBHOOK_SECRET
    description: A secret string used to configure the GitHub webhook
    generate: expression 
8

    from: "[a-zA-Z0-9]{40}" 
9

  - name: REPLICA_COUNT
    description: Number of replicas to run
    value: "2"
    required: true
message: "... The GitHub webhook secret is ${GITHUB_WEBHOOK_SECRET} ..." 
10
Copy to Clipboard
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

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:

kind: "Template"
apiVersion: "v1"
metadata:
  name: my-template
objects:
  - kind: "Service" 
1

    apiVersion: "v1"
    metadata:
      name: "cakephp-mysql-example"
      annotations:
        description: "Exposes and load balances the application pods"
    spec:
      ports:
        - name: "web"
          port: 8080
          targetPort: 8080
      selector:
        name: "cakephp-mysql-example"
Copy to Clipboard
1
La définition d’un service, qui est créé par ce modèle.
Note

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

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

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.

Note

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 _.

Note

À 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:

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: my-template
objects:
- kind: ConfigMap
  apiVersion: v1
  metadata:
    name: my-template-config
    annotations:
      template.openshift.io/expose-username: "{.data['my\\.username']}"
  data:
    my.username: foo
- kind: Secret
  apiVersion: v1
  metadata:
    name: my-template-config-secret
    annotations:
      template.openshift.io/base64-expose-password: "{.data['password']}"
  stringData:
    password: <password>
- kind: Service
  apiVersion: v1
  metadata:
    name: my-template-service
    annotations:
      template.openshift.io/expose-service_ip_port: "{.spec.clusterIP}:{.spec.ports[?(.name==\"web\")].port}"
  spec:
    ports:
    - name: "web"
      port: 8080
- kind: Route
  apiVersion: route.openshift.io/v1
  metadata:
    name: my-template-route
    annotations:
      template.openshift.io/expose-uri: "http://{.spec.host}{.spec.path}"
  spec:
    path: mypath
Copy to Clipboard

Exemple de réponse à une opération de liaison étant donné le modèle partiel ci-dessus:

{
  "credentials": {
    "username": "foo",
    "password": "YmFy",
    "service_ip_port": "172.30.12.34:8080",
    "uri": "http://route-test.router.default.svc.cluster.local/mypath"
  }
}
Copy to Clipboard

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

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"
Copy to Clipboard

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

Construire

La phase des rapports d’objets est terminée.

Les rapports d’objets ont été annulés, une erreur ou un échec.

BuildConfig

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.

Déploiement

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.

DéploiementConfig

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.

Emploi

Les rapports d’objet sont terminés.

L’objet signale qu’un ou plusieurs échecs ont eu lieu.

ÉtatfulSet

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.

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: my-template
objects:
- kind: BuildConfig
  apiVersion: build.openshift.io/v1
  metadata:
    name: ...
    annotations:
      # wait-for-ready used on BuildConfig ensures that template instantiation
      # will fail immediately if build fails
      template.alpha.openshift.io/wait-for-ready: "true"
  spec:
    ...
- kind: DeploymentConfig
  apiVersion: apps.openshift.io/v1
  metadata:
    name: ...
    annotations:
      template.alpha.openshift.io/wait-for-ready: "true"
  spec:
    ...
- kind: Service
  apiVersion: v1
  metadata:
    name: ...
  spec:
    ...
Copy to Clipboard

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

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>
    Copy to Clipboard

    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
Note

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.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat