Comment authentifier les modules Go privés sur Google App Engine Standard avec Go 1.11 ?

Authentification d'un module Go privé sur Google App Engine Standard avec Go 1.11

Lors de la mise à niveau vers le système de modules Go 1.11 pour une application Go Projet Engine Standard, l'authentification des modules privés peut présenter des défis. En suivant la documentation de migration, vous pouvez rencontrer une erreur « 403 Forbidden » lors de la tentative de déploiement du projet.

L'erreur

L'erreur provient du système de build Google Cloud. ne pas avoir accès au référentiel privé qui héberge le module. Le système de build cloud nécessite des informations d'identification pour accéder au référentiel pendant le déploiement, mais ces informations d'identification ne sont pas fournies dans la configuration actuelle.

Solution

Pour résoudre ce problème, vous pouvez utilisez la fonctionnalité de remplacement de module de Go. Cela vous permet de configurer le système de build cloud pour utiliser une copie locale du module privé au lieu de le récupérer à partir du référentiel.

Structure des répertoires

Créer un répertoire dédié structure de cette approche :

myService/
    src/
        service.go  # contains run() function for routers and other setups
        go.mod      # depends on private and external modules
        ...         # other source files
    build/
        gae/
            src/        # symlink to ../../src
            modules/    # stores cloned or locally modified private modules
            app.go  # contains main() to call service.run() and appEngine.Main()
            go.mod  # includes main() and required modules
            app.yaml

Configuration

Dans le fichier myService/gae/go.mod, ajoutez la configuration suivante :

module myServiceGAE

require (
    bitbucket.org/me/myService v0.0.0
    google.golang.org/appengine v1.4.0
)

replace bitbucket.org/me/myService => ./src

# Optionally replace other private modules
replace bitbucket.org/me/myModule => ./modules/utils

Cette configuration demande au système de build cloud d'utiliser la copie locale de myService à partir du répertoire src. La directive replace agit comme un pseudo-fournisseur, garantissant que le système de build utilise la version locale au lieu de la récupérer dans le référentiel.

Avantages et inconvénients

Avantages :

• Le code du module privé n'est pas partagé avec Google Cloud, ce qui préserve la confidentialité.
• Le code du projet reste découplé d'App Engine, permettant une intégration facile avec d'autres plates-formes. .

Inconvénients :

• L'approche peut devenir complexe si les modules privés dépendent d'autres modules privés.

Conclusion

En utilisant le remplacement de module et une structure de répertoires modifiée, vous pouvez authentifier avec succès les modules privés sur Google App Engine Standard à l'aide de Go 1.11. Cette approche offre à la fois sécurité et flexibilité, permettant une intégration transparente de modules privés dans votre projet.

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!