Go 1.11 を使用した Google App Engine Standard でのプライベート Go モジュールの認証
Go アプリの Go 1.11 のモジュール システムにアップグレードする場合Engine Standard プロジェクトでは、プライベート モジュールの認証に課題が生じる可能性があります。移行ドキュメントに従って、プロジェクトをデプロイしようとすると、「403 Forbidden」エラーが発生する場合があります。
エラー
このエラーは、Google クラウド ビルド システムに起因します。モジュールをホストするプライベート リポジトリにアクセスできない。クラウド ビルド システムでは、展開中にリポジトリにアクセスするための認証情報が必要ですが、これらの認証情報は現在のセットアップでは提供されません。
解決策
この問題を解決するには、次のことができます。 Go のモジュール置換機能を利用します。これにより、リポジトリからプライベート モジュールをフェッチする代わりに、プライベート モジュールのローカル コピーを使用するようにクラウド ビルド システムを構成できます。
ディレクトリ構造
専用ディレクトリを作成するこのアプローチの構造:
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
構成
myService/gae/go.mod ファイルに、次の構成を追加します:
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
この構成は、src ディレクトリからの myService のローカル コピーを使用するようにクラウド ビルド システムに指示します。 replace ディレクティブは疑似ベンダーのように機能し、ビルド システムがリポジトリからフェッチする代わりにローカル バージョンを使用するようにします。
長所と短所
長所:
短所:
結論
モジュールの置換と変更されたディレクトリ構造を使用すると、Go 1.11 を使用して Google App Engine Standard でプライベート モジュールを正常に認証できます。このアプローチはセキュリティと柔軟性の両方を提供し、プライベート モジュールをプロジェクトにシームレスに統合できるようにします。
以上がGo 1.11 を使用して Google App Engine Standard でプライベート Go モジュールを認証するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。