Introduction
Dans ce guide, je vais déployer les conteneurs du système TeoMeWhat de Twitch, qui est actuellement sur AWS, et le placer sur GCP.
Structure actuelle chez AWS
L'architecture chez GCP
Aucun outil d'automatisation complexe ne sera utilisé, tout sera fait via la console, en intégrant Github et en déployant les images à chaque commit vers main.
Nous utiliserons :
- Cloud Run - Pour les applications Web
- Cloud SQL - Pour base de données MySQL
- GCE - Pour exécuter Teomebot
- Stockage Cloud - Stockage d'objets (S3)
- Cloud Build - Pour créer des déploiements d'applications
- Secret Manager - Enregistrez les informations d'identification de l'application en toute sécurité.
Obtenir les candidatures
- Visitez le GitHub de TeoMe Why et le fork d'applications liées au projet.
- Sur la page du référentiel, cliquez sur Étoilé puis sur Fork.
- Sur la page fork, donnez un nom au fork et cliquez sur Créer un fork.
- Répétez le processus pour les autres référentiels du projet si vous souhaitez répliquer l'intégralité de l'environnement.
- Créez le clone du fork pour ajuster l'application si nécessaire avant de l'envoyer à GCP.
git clone git@github.com:cslemes/points-to-go.git
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Création du Dockerfile pour créer l'image du conteneur
Accédez au dossier du référentiel cloné. Le référentiel contient déjà un Dockerfile conçu pour Docker. Analysons-le :
```
FROM golang:latest
WORKDIR /app/
COPY . .
RUN go build main.go
CMD ["./main"]
```
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Ce Dockerfile est fonctionnel, mais nous allons l'optimiser à l'aide de builds en plusieurs étapes pour réduire la taille de l'image finale. Puisque Go ne nécessite pas de dépendances externes, nous pouvons utiliser une image de base minimale comme scratch.
-
Échangez l'image build avec une version plus légère et nommez-la pour référence à d'autres étapes.
FROM golang:1.23.1-alpine3.20 AS build
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
-
Ajoutez la commande go mod download pour mettre en cache les dépendances et go mod verify pour vous assurer qu'elles correspondent aux sommes de contrôle dans le fichier go.sum.
RUN go mod download && go mod verify
Copier après la connexion
Copier après la connexion
Copier après la connexion
-
Pour optimiser le binaire pour la production, ajoutez les paramètres ci-dessous :
-
CGO_ENABLED=0 : désactive la prise en charge de CGO. CGO est la fonctionnalité de Go qui vous permet d'appeler du code C, mais lorsque vous la désactivez, vous obtenez un binaire complètement statique, sans dépendances sur des bibliothèques externes.
-
GOARCH=amd64 : définit l'architecture cible pour la compilation. amd64 est l'architecture utilisée sur les machines équipées de processeurs 64 bits, telles que la plupart des serveurs et ordinateurs de bureau modernes.
-
GOOS=linux : définit le système d'exploitation cible pour la compilation. Ici, il est configuré pour Linux, ce qui signifie que le binaire généré sera exécutable sur les systèmes Linux.
-
go build -o /app/points : compile le code et enregistre le binaire dans le chemin spécifié (/app/points).
-
-a : force la recompilation de tous les packages, y compris les dépendances, même s'ils n'ont pas changé. Il peut être utile de s'assurer que tout est recompilé avec les nouveaux indicateurs et paramètres.
-
-ldflags="-s -w": Ce sont des indicateurs d'optimisation de taille.
-
-s supprime la table des symboles de débogage du binaire.
-
-w supprime les informations de traçage de la pile. Ces options réduisent la taille du binaire final.
-
-installsuffix cgo : ajoute un suffixe au répertoire d'installation pour différencier les binaires avec CGO désactivé. Cela peut éviter les conflits avec les binaires qui utilisent CGO.
git clone git@github.com:cslemes/points-to-go.git
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
-
(facultatif) Pour rendre l'image encore plus petite, nous pouvons compresser le binaire en utilisant upx, upx (Ultimate Packer for eXecutables) est un outil qui compresse les binaires exécutables pour réduire la taille des fichiers, comme les binaires Go. Les points négatifs sont. qu'il y aura un temps de construction plus long et un délai plus long dans le démarrage du conteneur, il faut donc évaluer ce qui est le plus bénéfique pour sa mise en œuvre. Comme l'objectif est de l'utiliser dans Cloud Run qui dispose déjà de Cold Start, il met le conteneur en pause lorsqu'il n'est pas utilisé, nous ne l'utiliserons pas car cela augmentera le temps d'initialisation du conteneur.
```
FROM golang:latest
WORKDIR /app/
COPY . .
RUN go build main.go
CMD ["./main"]
```
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
- Comparaison des builds
- L'optimisation du Dockerfile et l'utilisation de upx donnent une image jusqu'à 3 fois plus petite.
- L'analyse de l'image originale avec Trivy montre 904 CVE, tandis que l'image scratch est exempte de CVE.
Imagem |
Tipo |
Tamanho |
points-to-go |
Otimizado |
14MB |
points-to-go |
Com upx |
5.77MB |
points-to-go |
original |
1.76GB |
- Répétez ces paramètres pour les autres référentiels.
Déploiement de la base de données
- Dans la console, accédez à SQL dans le menu latéral.
- Ou recherchez « SQL » dans la barre de recherche et sélectionnez SQL dans la liste.
- Sur la page Cloud SQL, cliquez sur Créer une instance et choisissez MySQL.
- Sélectionnez Entreprise en cours d'édition.
- Sous « Modification des préréglages », choisissez Bac à sable.
- Laissez la version de la base de données sur MySQL 8.0.
- Donnez un nom à l'instance sous ID d'instance et définissez un mot de passe.
- vous pouvez spécifier des politiques de mot de passe en développant la politique de mot de passe
- Définissez la zone et la région, et nous la laisserons dans une seule zone.
- Dans une instance personnalisée, nous pouvons ajuster le matériel en fonction de nos besoins, les options varieront en fonction de l'édition que nous choisissons.
- Ajustez le processeur sur 1 et le disque sur 10 Go selon vos besoins.
- Dans les connexions, décochez IP publique et cochez IP privée.
- Dans la connexion à accès privé, cliquez sur Configurer la connexion
- Sélectionnez utiliser une plage allouée automatiquement
- Cliquez sur Continuer
- Cliquez sur Créer une connexion
- Cliquez sur Créer une instance et attendez qu'elle soit créée.
-
Pour vous connecter à l'instance, activez Cloud Shell et exécutez :
git clone git@github.com:cslemes/points-to-go.git
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
- Entrez le mot de passe attribué à l'étape précédente.
- Et puis vous obtiendrez une erreur de connexion, car le cloud shell n'a pas accès à votre VPC privé.
- Pour simplifier la connexion via Cloud shell, modifions l'instance et marquons l'IP publique, en annexe je montrerai comment créer un Peering VPC pour accéder à la base de données via Cloud Shell
- Essayez à nouveau de vous connecter.
-
Créer la base de données de l'application :
```
FROM golang:latest
WORKDIR /app/
COPY . .
RUN go build main.go
CMD ["./main"]
```
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Cloud Shell dispose toujours d'un éditeur de texte basé sur VSCode, vous pouvez faire certaines activités directement via celui-ci, il a 5 Go de volume persistant dans votre /home, le le matériel est une petite VM e2 avec 1vCPU et 1,7 Go de RAM.
Créer des conteneurs dans Cloud Run
- Dans la console Google Cloud, accédez à Cloud Run via le menu latéral ou la barre de recherche.
- Sur la page Cloud Run, cliquez sur Déployer le conteneur et choisissez l'option Service.
- Choisir la méthode de déploiement
- Il existe trois options pour déployer un service :
- Utilisez une image de conteneur provenant d'un registre.
- Connectez-vous directement à un référentiel.
- Créez une fonction (à l'aide de Cloud Functions, intégré à Run).
- Pour ce guide, sélectionnez Déploiement continu avec GitHub, permettant à Google de configurer automatiquement le pipeline CI/CD.
Cliquez sur Configurer avec Cloud Build.
Configuration de la connexion à GitHub
Cliquez sur Authentifier pour activer l'intégration de Google avec votre GitHub.
Autorisez l'accès, en choisissant entre autoriser l'accès à tous les référentiels ou seulement à un spécifique.
Après avoir terminé la connexion, cliquez sur Suivant.
Choisir le type de construction
Dans l'étape de création, choisissez entre l'utilisation d'un Dockerfile ou d'applications prises en charge et de Buildpacks de GCP.
Optez pour Dockerfile et ajustez le chemin/nom du fichier si nécessaire
Paramètres du service
-
Configurez les paramètres suivants :
-
Authentification : sélectionnez Autoriser les appels non authentifiés.
-
Allocation du processeur : choisissez Le processeur est alloué uniquement pendant le traitement de la demande.
-
Contrôle des entrées : sélectionnez Interne.
Ajustez le port du conteneur selon les besoins de l'application.
Dans l'onglet sécurité, sous compte de service, cliquez sur créer Nouveau compte de service
-
Ajouter des rôles
- Administrateur d'objets de stockage
- Administrateur Cloud Run
- Conseiller secret de Secret Manager
- Client Cloud SQL
- Compte de service Cloud Build
- Enregistreur de registre d'artefacts
- Utilisateur du compte de service
-
En analysant le code de l'application, nous devons transmettre les variables d'environnement à la base de données.
git clone git@github.com:cslemes/points-to-go.git
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
-
Nous devrons changer le code de l'application vers le standard Cloud Sql qui utilise les sockets Unix, et Cloud Run n'accède pas directement à la base de données, il utilise le Cloud SQL Auth Proxy .
```
FROM golang:latest
WORKDIR /app/
COPY . .
RUN go build main.go
CMD ["./main"]
```
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Dans le conteneur, allez dans l'onglet variables et secrets et cliquez sur ajouter une variable.
Ajoutez les variables nécessaires.
L'adresse de la banque suit le modèle, PROJECT_ID:REGION:INSTANCE_NAME, vous pouvez également obtenir le nom ci-dessous, au point 16.
Le mot de passe bancaire que nous mettrons en REFERENCE A SECRET
Si l'option Créer un nouveau secret est désactivée, c'est parce que vous devez activer l'API.
Cliquez sur CRÉER UN NOUVEAU SECRET
Définissez le nom du secret et cliquez sur Créer un secret
Dans Cloud SQL Connections, nous ajouterons l'URL de la banque que nous avons créée
Pour créer le schéma de l'application, le code nous demande de passer l'argument migrations=true.
Nous ajouterons migrations=true à l'argument de la fonction, puis le supprimerons dans la prochaine révision du conteneur.
Laissez les autres champs par défaut et cliquez sur Créer
Test de l'application à l'aide de Thunder Client.
créer un client
lecture des clients enregistrés
Création du service Teomebot
Le chatbot ne sera pas déployé sur Cloud Run, il sera installé sur Google Compute Engine (GCE). Contrairement à Cloud Run, Compute Engine est idéal, car le chatbot doit être continuellement actif pour interagir avec le chat.
De plus, nous aborderons l'utilisation de conteneurs, la gestion des secrets et la configuration de Cloud Build pour l'automatisation du déploiement.
Créer une VM sur Google Compute Engine (GCE)
- Accédez à Compute Engine dans le menu latéral de la console GCP.
- Cliquez sur Créer une instance.
- Entrez un nom pour l'instance (par exemple, teomebot-instance).
- Configurez la région et la zone selon vos besoins et notez ces informations pour une utilisation ultérieure.
- Dans Configuration de la machine, choisissez le type E2 et dans Préréglage, sélectionnez e2-micro.
- Cliquez sur l'onglet Conteneur et cliquez sur Déployer le conteneur.
- Utilisez temporairement l'image nginx:latest pour terminer la configuration initiale.
- Ajoutez les variables d'environnement :
-
TWITCH_BOT : Nom du robot.
-
TWITCH_CHANNEL : nom de la chaîne Twitch.
-
HOST_DB : IP privée de la base de données Cloud SQL.
-
USER_DB : utilisateur de la banque.
-
PORT_DB : Port bancaire.
-
URL_POINTS : point de terminaison du service Points à parcourir.
- Cliquez sur Sélectionner
- Sous Identité et accès API, sélectionnez le compte de service configuré pour ce projet.
- Laissez le reste des paramètres par défaut et cliquez sur Créer.
Ajouter des secrets avec Secret Manager
- Vous avez peut-être remarqué que nous n'avons pas transmis les secrets, dans le moteur de calcul, il n'y a pas de moyen simple de les transmettre comme dans Cloud Run. Ma solution a été d'ajouter une fonction au code de l'application pour lire les informations directement depuis le gestionnaire de secrets.
- Accédez à Secret Manager dans la console GCP.
- Cliquez sur Créer un secret
- Entrez un nom descriptif (par exemple Twitch-token) et ajoutez la valeur correspondante.
- Copiez le chemin du secret généré (ex. :projects/123456/secrets/twitch-token/versions/latest).
- Créez un nouveau fichier utils/gcp.go
-
Modifiez utils/db.go pour appeler la fonction, en passant le chemin du gestionnaire de secrets en paramètre.
git clone git@github.com:cslemes/points-to-go.git
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
-
Changez main.go pour obtenir les informations d'identification Twitch
```
FROM golang:latest
WORKDIR /app/
COPY . .
RUN go build main.go
CMD ["./main"]
```
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
migration := flag.Bool("migrations", false, "Effectuer des migrations de bases de données")
flag.Parse()
godotenv.Load()
utilisateur := os.Getenv("TWITCH_BOT")
//changer
oauth := utils.AccessSecretVersion("projects/551619572964/secrets/twitch-token/versions/latest")
canal := os.Getenv("TWITCH_CHANNEL")
```
Création de nuages
Configuration de Cloud Build
Cloud Build sera utilisé pour automatiser la création et le déploiement d'images de conteneur sur Compute Engine.
- Créez un fichier cloudbuild.yaml à la racine du référentiel avec le contenu ci-dessous :
-
Substitutions
FROM golang:1.23.1-alpine3.20 AS build
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
La variable _VERSION est définie sur une valeur qui correspond à la v1.0. avec le hachage du commit actuel (${COMMIT_SHA}). Cela crée une version unique pour chaque build, garantissant que chaque image est identifiable par version et par commit.
Étapes
La section Étapes définit les étapes que Cloud Build doit effectuer. Ici, nous avons quatre étapes : construire, pousser (deux fois) et mettre à jour.
-
Étape 1 : Créer l'image Docker
RUN go mod download && go mod verify
Copier après la connexion
Copier après la connexion
Copier après la connexion
Cette étape exécute une construction de l'image Docker :
-
"--no-cache" : force le build sans utiliser le cache.
-
"-t" : définit les balises pour l'image créée :
-
gcr.io/$PROJECT_ID/teomebot:$_VERSION : image avec la balise qui utilise le hachage de validation.
-
gcr.io/$PROJECT_ID/teomebot:latest : image avec la balise Latest.
-
"." : définit le répertoire courant comme contexte de construction.
La balise id: Build est un identifiant facultatif pour l'étape, utile pour la référence et le débogage.
-
Étape 2 : Image Push avec balise de version
RUN CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -o /app/points -a -ldflags="-s -w" -installsuffix cgo
Copier après la connexion
Copier après la connexion
Cette étape pousse l'image avec la balise spécifique ($_VERSION) vers Google Container Registry, permettant à la version générée dans la build d'être stockée dans le référentiel.
Cette étape transfère l'image avec la dernière balise vers Google Container Registry, mettant ainsi à jour l'image avec la dernière version.
Cette étape utilise la commande gcloud pour mettre à jour le conteneur sur une instance Google Compute Engine :
-
"teomebot-instance" : spécifie le nom de l'instance qui exécute le conteneur.
-
--container-image : définit l'image du conteneur que l'instance doit utiliser. Ici, utilisez la dernière version de l'image.
-
--zone=$_DEPLOY_ZONE : utilise une variable pour spécifier la zone de déploiement.
-
--container-restart-policy=always : définit la politique de redémarrage du conteneur pour qu'elle redémarre toujours en cas d'échec.
-
Options
git clone git@github.com:cslemes/points-to-go.git
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
L'option logging : CLOUD_LOGGING_ONLY spécifie que Cloud Build doit uniquement se connecter à Cloud Logging, enregistrer les données et se concentrer sur les journaux GCP.
-
Fichier final
```
FROM golang:latest
WORKDIR /app/
COPY . .
RUN go build main.go
CMD ["./main"]
```
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Création d'un déclencheur pour la création d'images de conteneur
Configuration du compte de service
- Accédez à Cloud Build dans la console Google Cloud.
- Allez dans Paramètres.
- Cliquez sur Autorisations du compte de service.
- Localisez le compte de service créé pour Cloud Run.
- Activez l'option Définir comme compte de service préféré
- Activez le rôle Administrateur d'instance Compute pour le compte de service.
Création du déclencheur
- Dans le menu latéral, cliquez sur Déclencheurs puis sur Créer un déclencheur.
- Entrez un nom descriptif pour le déclencheur.
- Dans Dépôts, cliquez sur Connecter le référentiel et sélectionnez le référentiel Teomebot.
- Dans Configuration, sélectionnez l'option Fichier de configuration Cloud Build.
- Ajoutez la variable de substitution _DEPLOY_ZONE avec la valeur correspondant à la zone dans laquelle l'instance a été créée.
- Dans le compte de service, vérifiez le compte sélectionné s'il est tel que configuré à l'étape 6.
- Cliquez sur Enregistrer.
Exécuter le déclencheur
- Sur l'écran de présentation, dans la ligne de déclenchement nouvellement créée, cliquez sur exécuter pour exécuter le processus manuellement.
- Dans les détails du processus, suivez les étapes de création d'image pour vérifier les erreurs possibles.
Test de l'application
- Dans le panneau Compute Engine, copiez la commande ssh pour accéder à l'instance, ou utilisez le client Web ssh et connectez l'instance.
-
Connectez-vous à l'instance et exécutez les commandes ci-dessous pour vérifier l'état du conteneur :
git clone git@github.com:cslemes/points-to-go.git
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Résoudre les problèmes de certificat
-
Si une erreur liée au certificat se produit (causée par l'image de base scratch), remplacez-la par l'image sans distribution. Dans le Dockerfile, modifiez la ligne qui définit l'image de base de :
git clone git@github.com:cslemes/points-to-go.git
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
à :
```
FROM golang:latest
WORKDIR /app/
COPY . .
RUN go build main.go
CMD ["./main"]
```
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Fichier Docker mis à jour :
FROM golang:1.23.1-alpine3.20 AS build
Copier après la connexion
Copier après la connexion
Copier après la connexion
Copier après la connexion
Ajustement des autorisations pour Secret Manager
- Modifiez la portée du compte de service pour accéder à Secret Manager.
- Accédez à Google Cloud Console.
- Dans le menu latéral, accédez à Compute Engine > Instances de VM.
- Recherchez et cliquez sur le nom de votre instance de VM.
- Sur la page des détails de la VM, cliquez sur Arrêter pour arrêter l'instance (cette étape est nécessaire car la portée du compte de service ne peut être modifiée que lorsque l'instance est arrêtée).
- Une fois l'instance arrêtée, cliquez sur Modifier en haut de la page.
- Faites défiler jusqu'à la section API d'identité et d'accès.
- Sous Compte de service, sélectionnez le compte de service utilisé par votre application.
- Sous Étendues d'accès aux API, sélectionnez Autoriser l'accès complet à toutes les API Cloud ou cliquez sur Définir les étendues d'accès aux API spécifiques et ajoutez l'étendue https://www .googleapis.com/auth/cloud-platform.
- Après avoir ajusté la portée, cliquez sur Enregistrer pour appliquer les modifications.
- Redémarrez l'instance en cliquant sur Démarrer.
-
Ou via la ligne de commande, arrêter l'instance, exécuter la commande et démarrer ensuite.
RUN go mod download && go mod verify
Copier après la connexion
Copier après la connexion
Copier après la connexion
Ajouter plus de conteneurs
Les autres services suivent le même processus de points à parcourir, pour les services qui communiquent entre eux, créent des variables d'environnement pour configurer les adresses des points de terminaison, qui seront toujours le port https 443.
Pour la communication avec d'autres services, j'ai ajusté le code pour recevoir une autre variable d'environnement avec l'url du service, en points par exemple cela ressemblait à ceci :
RUN CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -o /app/points -a -ldflags="-s -w" -installsuffix cgo
Copier après la connexion
Copier après la connexion
Test du bot
Test de la communication du bot avec Twitch.
Ajustement de la sécurité du réseau
Après avoir terminé les tests, placez les conteneurs accessibles uniquement en interne dans le VPC.
Conclusion
Nous avons ainsi terminé la migration du système TeoMeWhat, le guide sert de base pour la migration des autres services TeoMeWhat.
Les principaux objectifs atteints étaient :
Réalisations techniques
- Migration des applications conteneurisées vers Cloud Run, permettant une scalabilité automatique et une réduction des coûts
- Optimisation de l'image Docker grâce à des constructions en plusieurs étapes, réduisant considérablement la taille de l'image et les vulnérabilités
- Mise en place d'une base de données managée avec Cloud SQL, garantissant haute disponibilité et sécurité
- Configuration CI/CD automatisée à l'aide de Cloud Build, permettant des déploiements automatiques depuis GitHub
- Gestion sécurisée des identifiants à l'aide de Secret Manager
Améliorations architecturales
- Séparation claire des responsabilités entre les services
- Utilisation de connexions privées pour plus de sécurité
- Mise en œuvre de standards sans serveur pour l'optimisation des coûts
- Automatisation des processus de création et de déploiement
- Intégration transparente avec les référentiels GitHub
Avantages obtenus
-
Coûts : réduction des coûts grâce au modèle sans serveur et à l'optimisation des ressources
-
Maintenabilité : Facilité de maintenance avec des déploiements automatisés
-
Sécurité : Bonne gestion des secrets et des connexions privées
-
Évolutivité : Possibilité d'évoluer automatiquement en fonction de la demande
-
Surveillance : meilleure visibilité de l'infrastructure grâce aux outils GCP natifs
Appendice
Activer l'API Secret Manager
- Dans la console Google Cloud, recherchez API Secret Manager.
- Cliquez sur API dans les résultats de recherche.
- Sur l'écran des détails, cliquez sur Activer.
Références
- Github TeoMePourquoi
- Twitch Teo Moi Pourquoi
- Documents Cloud Run
- Documents Compute Engine
- Documents Cloud Build
- Documents Secret Manager
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!