Cette page décrit les bonnes pratiques à adopter pour créer des déploiements à l'aide de Google Cloud Deployment Manager. Cette page est conçue pour les utilisateurs familiarisés avec Deployment Manager, elle ne vous apprendra pas à utiliser cet outil.
Si vous ne connaissez pas encore Deployment Manager, consultez d'abord la page Démarrage rapide.
Gérer les ressources
|
❑
Une fois que vous avez créé une ressource dans le cadre d'un déploiement, utilisez Deployment Manager si vous devez modifier la ressource.
Si vous modifiez une ressource sans utiliser Deployment Manager, (avec la console Google Cloud ou l'outil
gcloud, par exemple), des erreurs peuvent survenir lorsque vous essayez d'effectuer cette tâche dans votre déploiement d'origine.
Si vous souhaitez supprimer une ressource d'un déploiement sans l'effacer, procédez comme suit :
|
|
❑
Si vous souhaitez rattacher des disques persistants aux instances Compute Engine présentes dans votre déploiement, définissez le disque séparément de l'instance afin de pouvoir le gérer facilement. Par exemple, le disque
example-disk est défini séparément de l'instance example-instance dans le déploiement ci-dessous. Pour que le disque soit rattaché, la configuration inclut sa référence :
resources: # instance - name: example-instance type: compute.v1.instance properties: disks: - type: PERSISTENT source:$(ref.example-disk.selfLink) # disk - name: example-disk type: compute.v1.disk properties: zone: us-central1-a sizeGb: 10 type: ... |
|
❑
Si vous souhaitez créer et gérer des clusters Google Kubernetes Engine (GKE) privés avec Deployment Manager, définissez les options privateClusterConfig: enablePrivateNodes: true enablePrivateEndpoint: true # Configure the IP range for the hosted master network masterIpv4CidrBlock: IP_RANGE ipAllocationPolicy: useIpAliases: true createSubnetwork: true Pour connaître les exigences et d'autres considérations à prendre en compte lors de la création d'un cluster privé avec GKE, consultez la section Configurer un cluster privé. |
Inclure des identifiants dans votre déploiement
|
❑
Deployment Manager masque certains champs liés aux identifiants dans les propriétés de vos configurations YAML. Ce masquage se produit en fonction de la clé de la propriété. L'exemple suivant illustre ce genre de masquage :
# Config provided to Deployment Manager resources: - name: example-resource type: gcp-types/service-v1:sample-type-with-password properties: zone: us-central1-a username: test-user password: hunter2 # Config as surfaced by Deployment Manager resources: - name: example-resource type: gcp-types/service-v1:sample-type-with-password properties: zone: us-central1-a username: test-user password: (redacted) |
|
❑
Si vous incluez les identifiants dans un modèle Jinja ou Python pour votre déploiement, ils sont masqués dans les fichiers de configuration développée et de mise en page résultants, mais restent visibles dans le fichier d'importation d'origine. C'est pourquoi nous recommandons vivement de placer tous les identifiants que vous souhaitez garder secrets dans votre configuration YAML de premier niveau. De là, vous pouvez les référencer à l'aide des propriétés de modèle.
|
|
❑
Tous les identifiants inclus dans une paire clé-valeur se trouvant dans un fichier YAML ou une liste d'éléments ne seront pas masqués, comme dans l'exemple suivant. Pour cette raison, nous vous recommandons vivement de ne pas fournir d'identifiants à Deployment Manager en tant que paires clé-valeur dans des fichiers YAML ou des listes d'éléments.
# Not a valid instance configuration, used solely for demonstration resources: - name: example-resource type: gcp-types/compute-v1:instances properties: zone: us-central1-a disks: - autoDelete: true boot: true # Will not be redacted password: hunter2 |
Créer des modèles
|
❑
Pour accélérer la création de vos modèles, envisagez d'utiliser les exemples de modèles prêts pour la production du projet du kit Cloud Foundation.
|
|
❑
Si vous avez des exigences complexes en termes d'infrastructure, telles que la nécessité de créer plusieurs environnements, consultez le tutoriel et les exemples concernant l'utilisation de Deployment Manager à grande échelle.
|
|
❑
Nous vous recommandons d'utiliser Python pour construire vos modèles.
Il est possible de créer des modèles avec Python ou Jinja2. Jinja est plus facile à utiliser, mais Python est plus flexible pour les déploiements complexes dans lesquels de nombreuses ressources peuvent être réparties dans plusieurs environnements.
|
|
❑
Structurez votre fichier de configuration (le fichier YAML) afin qu'il n'utilise qu'un seul type et utilisez un modèle de niveau supérieur (correspondant à ce type) pour appeler tous les autres modèles. L'adoption de cette pratique facilite la modification d'un ensemble de modèles en un type composite.
|
|
❑
Utilisez un fichier de schéma.
Les schémas définissent un ensemble de règles qu'un fichier de configuration doit respecter pour pouvoir utiliser un modèle particulier. Définissez un schéma et encouragez les autres utilisateurs à en examiner les exigences. Cela leur permettra de comprendre plus facilement quelles sont les propriétés requises ou pouvant être définies pour le modèle concerné. Ils pourront ainsi utiliser votre configuration sans avoir à examiner le détail des modèles. Au minimum, créez un fichier de schéma pour le modèle de niveau supérieur.
|
|
❑
Utilisez les propriétés et les sorties de modèles.
L'utilisation des propriétés et des sorties vous permet de transmettre des variables telles que la zone, la taille des machines, le nombre de machines et l'état de l'application (test, production ou préproduction) dans vos modèles, et d'obtenir en retour des valeurs de sortie telles que l'adresse IP et le
selfLink d'une instance de machine virtuelle. Les propriétés et les sorties permettent de concevoir des modèles flexibles qui peuvent être réutilisés sans modification des modèles sous-jacents.
|
|
❑
Utilisez des fichiers de modèles individuels que vous importez dans votre fichier de configuration principal. Cela vous offre une plus grande liberté lorsque vous travaillez avec vos configurations.
|
|
❑
Décomposez vos configurations en unités logiques. Par exemple, vous pouvez créer des configurations spécifiques pour les services avec état tels que les bases de données et les buckets, et d'autres configurations pour les services plus temporaires tels que les instances frontend.
|
|
❑
Utilisez des références.
Des références sont requises pour les valeurs qui ne sont pas définies tant qu'une ressource n'est pas créée, telles que le
selfLink d'une ressource, l'adresse IP ou l'ID généré par le système. Sans références, Deployment Manager crée toutes les ressources en parallèle. Il n'y a dans ce cas aucune garantie que les ressources dépendantes soient créées dans le bon ordre. L'utilisation de références permet de s'assurer que les ressources seront créées dans le bon ordre.
|
|
❑
Prévisualisez vos déploiements pour évaluer l'impact qu'une mise à jour pourrait avoir sur eux.
Deployment Manager n'instancie aucune ressource réelle lorsque vous prévisualisez une configuration. Au lieu de cela, il développe la configuration complète et crée des ressources "shell". Cela vous permet de voir les modifications apportées à votre déploiement avant de valider son exécution.
|
|
❑
Vérifiez les méthodes d'API pour une ressource spécifique afin de comprendre les implications de l'exécution d'une mise à jour. Définissez des stratégies de mise à jour pour vos déploiements. Cela vous permet de contrôler la façon dont Deployment Manager appliquera chaque mise à jour.
|
|
❑
Utilisez des libellés pour vos ressources. Si les ressources que vous définissez prennent en charge les libellés, vous pouvez utiliser ces derniers pour "marquer" ces ressources. Les libellés sont utiles pour catégoriser les ressources qui appartiennent à différents déploiements. En outre, ils permettent de distinguer à quel stade les ressources peuvent être employées. Avec les libellés, il est facile de déterminer si une ressource prend en charge un environnement de production ou de test.
|
Gérer la taille de vos déploiements
Deployment Manager peut fonctionner sur un grand nombre de ressources, soumis à des limites de quota. Si vous souhaitez réduire le temps nécessaire à la création, à la mise à jour ou à la suppression de vos déploiements, vous pouvez réduire le nombre de ressources pour chaque déploiement.
|
❑
Si un groupe de ressources ne dépend d'aucune ressource extérieure à ce groupe, vous pouvez déplacer ce groupe de ressources dans un déploiement distinct. Par exemple, si votre déploiement contient plusieurs modèles, vous pouvez regrouper chaque modèle en tant que déploiement distinct.
|
|
❑
Supprimez les ressources inutiles de votre configuration. Si vous avez besoin de ressources supplémentaires par la suite, vous pourrez en ajouter à votre déploiement à ce moment-là.
|
|
❑
Vous pouvez éventuellement limiter vos déploiements à 1 000 ressources ou moins.
|
Autorisations
Par défaut, Deployment Manager utilise les informations d'identification du compte de service des API Google pour s'authentifier auprès d'autres API. Le compte de service des API Google est spécialement conçu pour exécuter les processus Google internes en votre nom.
Lorsque vous souhaitez autoriser d'autres utilisateurs à accéder à votre projet Deployment Manager, vous devez leur attribuer un rôle IAM disposant des autorisations appropriées pour l'utilisation de Deployment Manager. Il existe un certain nombre de rôles IAM prédéfinis que vous pouvez utiliser pour déterminer le niveau d'accès dont doit disposer l'utilisateur pour les appels à Deployment Manager.
|
❑
Employez des rôles IAM afin de limiter les autorisations accordées aux utilisateurs pour l'utilisation de Deployment Manager.
|
|
❑
Si vous souhaitez que les utilisateurs puissent accéder aux ressources créées par Deployment Manager, accordez-leur les rôles dont ils ont besoin pour utiliser les ressources, mais ne leur accordez pas l'autorisation de déployer des ressources directement.
|
|
❑
L'attribution du rôle de propriétaire à un compte principal lui permet de modifier la stratégie IAM. Par conséquent, accordez ce rôle uniquement si le compte principal a une raison légitime d'accéder à la gestion de la stratégie IAM, car votre stratégie contient des données de contrôle d'accès sensibles. Si le nombre d'utilisateurs ayant accès à la gestion de la stratégie IAM est réduit au strict minimum, les opérations d'audit seront bien plus faciles à mener.
|
|
❑
Deployment Manager utilise le compte de service des API Google pour créer et gérer vos ressources. Lorsque vous gérez des ressources critiques, telles que des rôles IAM personnalisés, à l'aide de Deployment Manager, vous devez attribuer des rôles IAM supplémentaires au compte de service par défaut des API Google. Par exemple, si vous souhaitez utiliser Deployment Manager pour créer et gérer des rôles IAM personnalisés, vous devez ajouter le rôle "Administrateur de rôle" au compte de service des API Google.
Pour une présentation du compte de service des API Google, consultez la section Comptes de service gérés par Google. Pour connaître les étapes de la procédure d'attribution de rôles à un compte de service, consultez la section Attribuer des rôles aux comptes de service. |
Automatisation
Envisagez d'automatiser la création de projets, ainsi que celle des ressources contenues dans les projets. Cela vous permet d'adopter une approche de type "infrastructure en tant que code" pour le provisionnement de projet. Cette approche offre de nombreux avantages, notamment la possibilité :
- d'autoriser l'application des exigences de l'entreprise lors de la fourniture de projets aux équipes qui ont besoin d'accéder aux ressources Google Cloud ;
- de fournir une série d'environnements de projet prédéfinis pouvant être rapidement et facilement provisionnés ;
- de mettre en œuvre un contrôle de version pour gérer la configuration de base de votre projet ;
- de vous assurer que vous déployez des configurations de projets reproductibles et cohérentes ;
- d'intégrer la création de projet au sein d'un processus de provisionnement automatisé.
|
❑
Automatisez la création de projets en utilisant les modèles disponibles sur GitHub comme point de départ.
|
Intégration continue (CI)/Déploiement continu (CD)
Utilisez Deployment Manager dans le cadre de votre pipeline CI/CD.
|
❑
N'utilisez pas un pipeline CI/CD pour créer ou supprimer des projets de test ou de contrôle qualité complets.
|
|
❑
Utilisez Deployment Manager pour créer les parties "avec état" du projet ainsi que la configuration réseau et les déployer en dehors du processus CI/CD dans le cadre de la configuration initiale. Une fois les tests terminés, vous pouvez supprimer les déploiements qui contiennent uniquement des ressources sans état qui ont été déployées dans le pipeline.
|
|
❑
Dans le cadre du processus CI/CD, utilisez une configuration distincte pour déployer des ressources sur vos projets de test et de contrôle qualité. Une fois les tests terminés, vous pouvez utiliser Deployment Manager pour supprimer les ressources de vos projets de test et de contrôle qualité.
|
| Testez les déploiements. Deployment Manager offre la possibilité d'intégrer le provisionnement de ressources dans un pipeline CI/CD. Cela vous permet de traiter la configuration de votre projet comme du code. Vous pouvez donc facilement la tester et reproduire des copies cohérentes de votre environnement de production actuel (ou de l'environnement actuel avec les modifications apportées lors des tests), et ce, en toute confiance. |
|
❑
Utilisez le contrôle de version. L'utilisation d'un système de contrôle de version dans le cadre du processus de développement des déploiements vous permet :
|