Remarques sur les chaînes d'outils et les pipelines

La plupart des applications sont constituées de plusieurs microservices avec des référentiels source différents. Généralement, une seule chaîne d'outils est utilisée pour héberger des microservices qui sont regroupés de manière logique. En général, utilisez une chaîne d'outils et un pipeline, ou le moins de pipelines possible, mais plusieurs déclencheurs. Dans chaque pipeline, vous pouvez dupliquer et configurer autant de déclencheurs que nécessaire, jusqu'à 1024 déclencheurs par pipeline. Cette stratégie permet d'appliquer des processus, des scripts et des fichiers de configuration communs. Pour plus d'informations, voir Configuration de plusieurs applications sur une chaîne d'outils d'EC.

Cette approche présente les avantages suivants :

• L'utilisation de moins de pipelines permet d'éviter les doublons et de réduire les erreurs. Les mises à jour sont également plus faciles à gérer, par exemple, lorsqu'une propriété d'environnement ou un secret est ajouté, édité ou supprimé.
• L'intégration d'un service est plus rapide avec cette approche. Ajoutez une intégration Git pour votre microservice, dupliquez les Git et les déclencheurs manuels et modifiez-les si nécessaire. Ensuite, assurez-vous que votre fichier .pipeline-config.yaml et vos scripts sont implémentés pour votre microservice.

Cette approche présente les inconvénients suivants:

• Une édition peut avoir un impact sur chaque équipe qui utilise le même pipeline.
• L'accès utilisateur est géré à l'aide d' Identity and Access Management(IAM) et est défini au niveau de la chaîne d'outils et non au niveau du pipeline. Par conséquent, si vous utilisez une chaîne d'outils unique pour plusieurs services, chaque membre de l'équipe peut afficher les pipelines d'autres équipes. En fonction de l'accès de l'utilisateur dans IAM, il peut être en mesure d'éditer, de supprimer ou de déclencher un pipeline.

Remarques sur la facturation

Le service Continuous Delivery détermine la facturation en fonction du nombre d'utilisateurs autorisés par instance de CD et du nombre de groupes de ressources que vous utilisez pour vos chaînes d'outils. Les utilisateurs qui ont accès à vos référentiels sont également considérés comme des utilisateurs autorisés. Pour plus d'informations, voir Utilisateurs autorisés. Pour réduire les coûts, vous devez soit organiser toutes vos chaînes d'outils dans le même groupe de ressources, soit configurer la facturation consolidée Continuous Delivery dans une hiérarchie de comptes d'entreprise. Pour plus d'informations, voir Facturation consolidée.

DevSecOps considérations sur les référentiels

Si vous créez une application composée de plusieurs microservices, la plupartDevSecOps les référentiels - à l'exception du référentiel de preuves - peuvent être partagés entre les microservices.

Pour plus d'informations, voir commentDevSecOps les pipelines utilisent des référentiels.

Remarques sur IBM Cloud Object Storage

Si vous utilisez un référentiel d'inventaire partagé, vous pouvez également utiliser une instance partagée de IBM Cloud® Object Storage. Procédez comme suit :

1. Créez une instance de IBM Cloud Object Storage à utiliser dans les chaînes d'outils et les pipelines.
2. Configurez des pipelines et des déclencheurs, le cas échéant, pour utiliser le compartiment IBM Cloud Object Storage en définissant la propriété d'environnement cos-bucket-name.

Tous les microservices au sein des mêmes pipelines CI, CD et CC partagent un seul seau Object Storage, quel que soit l'environnement de déploiement. Le seau Object Storage fonctionne de la même manière que le dépôt de preuves, mais sans les problèmes de performance qui peuvent survenir avec un dépôt de preuves important. Étant donné que les problèmes de performance ne se posent pas avec un volume important de Object Storage, il n'est pas nécessaire d'élaguer les éléments de preuve de Object Storage.

Déploiement dans plusieurs environnements

Le déploiement dans plusieurs environnements cible avec le pipeline CD peut être réalisé de plusieurs manières.

Chaque targeted environment doit avoir une branche correspondante dans le référentiel d'inventaire, où les modifications sont promues d'une branche source à une branche target.

Les conceptions facultatives suivantes peuvent s'adapter à votre architecture:

• Utilisez un déclencheur manuel par environnement cible. Dupliquez un déclencheur, puis éditez les propriétés d'environnement pour qu'elles correspondent au nouvel environnement.
• Utilisez un référentiel de configuration Git avec un dossier par environnement cible, dans lequel des paramètres de configuration spécifiques sont stockés dans des fichiers.

Identifier le script qui est exécuté

Pour identifier le script exécuté pour une étape, ouvrez l'exécution du pipeline (de préférence un pipeline d'EC). Développez une tâche, puis cliquez sur run-stage pour ouvrir les journaux. Le début des journaux run-stage fournit des informations sur les scripts utilisés dans l'étape, y compris le référentiel dans lequel se trouve le script. Dans les journaux, vous pouvez faire défiler la page pour obtenir plus de détails sur les scripts qui ont été exécutés. Par exemple, la tâche code-compliance-checks peut contenir les informations suivantes dans le journal run-stage, qui inclut les propriétés d'environnement de l'étape:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

Dans cet exemple, le script exécuté est /opt/commons/compliance-checks/run.sh, qui se trouve dans la bibliothèque commune. Utilisez cette bibliothèque commune comme source pour copier du code qui peut être personnalisé pour des cas de périphérie spécifiques. Dans l'exemple, compliance-checks/run.sh se trouve dans la bibliothèque compliance-commons.

Remplacement des scripts par défaut

Pour remplacer les scripts par défaut, procédez comme suit:

1. Dans le journal d'étape, copiez le fragment qui identifie un script par défaut:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

1. Collez le fragment dans votre fichier .pipeline-config.yaml.
2. Ajoutez votre code personnalisé avant ou après l'appel du script. Cet extrait de code appelle le script de vérification de conformité par défaut
3. Modifiez, supprimez ou ajoutez des propriétés selon vos besoins.

L'exemple suivant illustre le script mis à jour dans votre fichier .pipeline-config.yaml:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh
    # run some custom script here
    ./scripts/my-custom-script1.sh

    "/opt/commons/compliance-checks/run.sh"

    # then some additional work
    ./scripts/my-custom-script2.sh

Pour plus d'informations, voir Scripts personnalisés.