How to Authenticate Private Go Modules on Google App Engine Standard with Go 1.11?

Authenticating a Private Go Module on Google App Engine Standard with Go 1.11

When upgrading to Go 1.11's module system for a Go App Engine Standard project, authenticating private modules can present challenges. Following the migration documentation, you may encounter a "403 Forbidden" error when attempting to deploy the project.

The Error

The error stems from the Google cloud build system not having access to the private repository that hosts the module. The cloud build system requires credentials to access the repository during deployment, but these credentials are not provided in the current setup.

Solution

To resolve this issue, you can utilize Go's module replace functionality. This allows you to configure the cloud build system to use a local copy of the private module instead of fetching it from the repository.

Directory Structure

Create a dedicated directory structure for this approach:

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

In the myService/gae/go.mod file, add the following configuration:

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

This configuration instructs the cloud build system to use the local copy of myService from the src directory. The replace directive acts like a pseudo-vendor, ensuring that the build system uses the local version instead of fetching it from the repository.

Pros and Cons

Pros:

• The private module code is not shared with Google Cloud, maintaining privacy.
• The project code remains decoupled from App Engine, allowing easy integration with other platforms.

Cons:

• The approach may become complex if private modules depend on other private modules.

Conclusion

By using module replace and a modified directory structure, you can successfully authenticate private modules on Google App Engine Standard using Go 1.11. This approach provides both security and flexibility, enabling seamless integration of private modules into your project.

The above is the detailed content of How to Authenticate Private Go Modules on Google App Engine Standard with Go 1.11?. For more information, please follow other related articles on the PHP Chinese website!