Go 1.11을 사용하여 Google App Engine 표준에서 비공개 Go 모듈을 인증하는 방법은 무엇입니까?

Go 1.11을 사용하여 Google App Engine 표준에서 비공개 Go 모듈 인증

Go 앱용 Go 1.11의 모듈 시스템으로 업그레이드하는 경우 엔진 표준 프로젝트에서는 개인 모듈을 인증하는 것이 어려울 수 있습니다. 마이그레이션 문서에 따르면 프로젝트를 배포하려고 할 때 "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의 로컬 복사본을 사용하도록 지시합니다. 바꾸기 지시문은 의사 공급업체처럼 작동하여 빌드 시스템이 저장소에서 로컬 버전을 가져오는 대신 로컬 버전을 사용하도록 합니다.

장점과 단점

장점:

• 비공개 모듈 코드는 Google Cloud와 공유되지 않아 개인정보 보호가 유지됩니다.
• 프로젝트 코드는 App Engine과 분리된 상태로 유지되므로 다른 플랫폼과 쉽게 통합할 수 있습니다. .

단점:

• 개인 모듈이 다른 개인 모듈에 의존하는 경우 접근 방식이 복잡해질 수 있습니다.

결론

모듈 교체 및 수정된 디렉터리 구조를 사용하면 Go 1.11을 사용하여 Google App Engine Standard에서 비공개 모듈을 성공적으로 인증할 수 있습니다. 이 접근 방식은 보안과 유연성을 모두 제공하여 개인 모듈을 프로젝트에 원활하게 통합할 수 있습니다.

위 내용은 Go 1.11을 사용하여 Google App Engine 표준에서 비공개 Go 모듈을 인증하는 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!