Autorisation

Pour travailler dans un projet, les utilisateurs doivent avoir accès au service de projets IBM Cloud, au groupe de ressources du projet et à IBM Cloud® Schematics. Pour plus d'informations sur l'accès, voir Affectation d'accès utilisateur à des projets.

L'autorisation des projets à déployer sur un compte cible est gérée par la transmission d'une clé d'API dans l'architecture déployable. Les projets peuvent être directement autorisés à l'aide d'un profil de confiance, mais certains services tels que IBM Cloud Kubernetes Service et GitLab ne prennent pas en charge les profils de confiance. Les clés API continuent d'être prises en charge, mais un profil de confiance est la méthode privilégiée pour autoriser le déploiement vers les comptes cibles.

Gestion des configurations

Les configurations peuvent être ajoutées, supprimées et renommées. Le déplacement d'une configuration entre des projets doit être effectué manuellement en éditant des documents project.json sur les deux projets. S'il existe plusieurs configurations dans un projet, elles ne peuvent être organisées qu'à l'aide de conventions de dénomination.

Estimation du coût

L'estimation des coûts est disponible pour les architectures déployables dans le catalogue IBM Cloud. En fonction de l'architecture déployable, un coût de départ est estimé en fonction des données disponibles. Ce montant estimé est susceptible d'être modifié à mesure que l'architecture est personnalisée dans un projet et n'inclut pas toutes les ressources, l'utilisation, les licences, les frais, les remises ou les taxes. Pour plus d'informations, voir Estimation des coûts d'architecture dans un projet.

{{../account/known-issues.md#policy-version-limit}}

Limites de détection de dérive

Schematics et Terraform peuvent détecter une dérive uniquement entre une ressource modifiée et la configuration spécifique qui a créé cette ressource lors du déploiement. Le service ne peut pas détecter la dérive dans les ressources réutilisées ou référencées.

Par exemple, dans un scénario spécifique, la configuration config-1 a créé une instance Cloud Object Storage lors du déploiement. Par la suite, vous avez déployé des configurations config-2 et config-3 et elles ont réutilisé la même instance Cloud Object Storage. Lorsque vous avez renommé la ressource, la dérive a été détectée uniquement entre config-1 et l'instance Cloud Object Storage renommée. config-2 et config-3 ont échoué au travail de détection de dérive car la dérive peut être détectée uniquement entre une configuration et la ressource qu'elle a créée, non réutilisée.

Pour plus d'informations, voir Gestion de la dérive.