Skip Navigation
Show nav
Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
    • .NET
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku のアーキテクチャ
    • Dyno (アプリコンテナ)
      • Dyno Management
      • Dyno Concepts
      • Dyno Behavior
      • Dyno Reference
      • Dyno Troubleshooting
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • Developer Tools
    • コマンドライン
    • Heroku VS Code Extension
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリーとインテグレーション
    • 継続的統合
  • 言語サポート
    • Node.js
      • Working with Node.js
      • Node.js Behavior in Heroku
      • Troubleshooting Node.js Apps
    • Ruby
      • Rails のサポート
      • Bundler の使用
      • Working with Ruby
      • Ruby Behavior in Heroku
      • Troubleshooting Ruby Apps
    • Python
      • Working with Python
      • Python でのバックグランドジョブ
      • Python Behavior in Heroku
      • Django の使用
    • Java
      • Java Behavior in Heroku
      • Working with Java
      • Maven の使用
      • Spring Boot の使用
      • Troubleshooting Java Apps
    • PHP
      • PHP Behavior in Heroku
      • Working with PHP
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
    • .NET
      • Working with .NET
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres スターターガイド
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
      • Migrating to Heroku Postgres
    • Heroku Data For Redis
    • Apache Kafka on Heroku
    • その他のデータストア
  • AI
    • Working with AI
    • Heroku Inference
      • Inference API
      • Quick Start Guides
      • AI Models
      • Inference Essentials
    • Vector Database
    • Model Context Protocol
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
      • シングルサインオン (SSO)
    • Private Space
      • インフラストラクチャネットワーキング
    • コンプライアンス
  • Heroku Enterprise
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Salesforce とのインテグレーション
  • 言語サポート
  • Go
  • Heroku の Go サポート

Heroku の Go サポート

日本語 — Switch to English

この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。

最終更新日 2023年10月26日(木)

Table of Contents

  • サポートされる依存関係/ベンダーマネージャー
  • Go のバージョン
  • リンカーへの記号 (およびオプションの文字列) の受け渡し
  • 他のビルド時の動作
  • ランタイムの動作
  • 静的なアセットおよびファイル
  • デフォルトの Web プロセスタイプ
  • アドオン
  • ベンダーディレクトリのサポート
  • 追加のメインパッケージのベンダー化
  • 理解を深める

このドキュメントでは、Go アプリケーションの認識と実行に関連した Heroku の一般的な動作について説明します。アプリケーションのデプロイ方法の詳細については、Heroku スターターガイド (Go) を参照してください。

コミュニティ buildpack を使用するようにアプリケーションを以前に設定したユーザーは、Go アプリケーションごとに heroku buildpacks:clear​ を実行できます。その後のプッシュは、ビルドシステムでキャッシュされた現在のリリースの Go buildpack を使用して、デプロイのスピードを高めます。

サポートされる依存関係/ベンダーマネージャー

現在サポートされている依存関係/ベンダーマネージャーは次のとおりです。

  1. godep
  2. govendor
  3. gb
  4. dep​ (コミュニティサポート*)

アクティベーション

Heroku Go buildpack​ は、アプリケーションが次のいずれかの要件を満たす場合に使用されます。

  1. godep​ により管理されているものとしてアプリケーションを識別する Godeps/Godeps.json​ ファイルがある。
  2. govendor​ により管理されているものとしてアプリケーションを識別する vendor/vendor.json​ ファイルがある。
  3. サブディレクトリを持ち、1 つまたは複数の .go​ ファイルを含む src​ ディレクトリがあり、gb​ によって管理されているものとしてアプリケーションを識別する。

デプロイしたアプリケーションが Go アプリケーションとして認識されると Heroku は次のように -----> Go app detected​ と応答します。

$ git push heroku master
...
remote: -----> Go app detected
...

さまざまなメタデータファイル (Godeps.json​、vendor.json​ など) を使用する前に、その基本構造を検証します。エラーがある場合は、次のように表示されます。

$ git push heroku master
...
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Go app detected
remote: -----> Checking Godeps/Godeps.json file.
remote: parse error: Expected value before ',' at line 4, column 15
remote:  !     Bad Godeps/Godeps.json file
remote:
remote:  !     Push rejected, failed to compile Go app
...

Go のバージョン

Heroku では、Go ツールチェーンのさまざまなバージョンを多数使用できます。現在サポートされているバージョンは、ここ​に一覧表示されています。どのバージョンも使用できますが、サポートは通常、最新の 2 つのメジャーバージョンの最新のマイナーリリースにのみ用意されています。

メジャーリリースの識別子は、そのシリーズの最新のリリースを表すために使用されます。例: ​go1.9​ は、go1.9​、go1.9.1​、go1.9.2​ など、コードがビルドされた時点で Heroku がサポートする最新の Go 1.9 リリースに拡張します。

何らかの理由で特定のマイナーリビジョン (go1.8.7​ など) を選択する必要がある場合は、使用する依存関係マネージャーに応じて、適切なメタデータファイルを手動で編集するか、$GOVERSION​ 環境変数を設定する必要があります。

  1. godep
  2. govendor
  3. gb
  4. dep​ (コミュニティサポート*)

メジャーバージョンの最初のリリースに固定する必要がある稀なケースでは (Go には .0​ リリースがありません)、バージョン識別子に .0​ を追加します。例: ​go1.9.0​ はアプリの go バージョンを go1.9​ に固定します。

リンカーへの記号 (およびオプションの文字列) の受け渡し

Heroku は、リンク時に文字列の値を設定する Go リンカーの機能 (-X 記号値) をサポートします。これは、コードをプッシュする前に、アプリケーションの設定で $GO_LINKER_SYMBOL​ および $GO_LINKER_VALUE​ を設定することにより行えます。$GO_LINKER_SYMBOL​が設定されているが、$GO_LINKER_VALUE​ が設定されていない場合は、$GO_LINKER_VALUE​ はデフォルトで $SOURCE_VERSION​ に設定されます。

これは、コミット SHA や他のビルド固有データを、コンパイル済み実行可能ファイルに直接埋め込むために使用できます。

他のビルド時の動作

複数のアプリケーション環境設定でビルドのさまざまな側面を制御できます。以下に、この文書のどこにも説明されていない変数とそれらの制御対象の一覧を示します。

  • CGO_CFLAGS​、CGO_CPPFLAGS​、CGO_CXXFLAGS​、および CGO_LDFLAGS​: これらは、ここ​に記述されているように標準の CGO フラグです。
  • GOPROXY​、GOPRIVATE​、および GONOPROXY​: これらはここ​に記載されているモジュールプロキシの使用を設定する標準の環境変数です。
  • GOVERSION​: 使用する go バージョンへのオーバーライドを提供します。
  • GO_INSTALL_PACKAGE_SPEC​: ​go install​ に渡されたパッケージ仕様をこの値で上書きします。これは、大きなリポジトリがあるが、そのサブセクションだけをコンパイルするときに役立ちます。
  • GO_INSTALL_TOOLS_IN_IMAGE​: ​true​ に設定すると、$HOME/.heroku/go​ の slug に go ツールチェーンをインストールし、$GOROOT=$HOME/.heroku/go​ を設定し、$GOROOT/bin​ を $PATH​ に含めます。通常、go ツールは slug にインストールされません。これにより、slug サイズが約 81MB 増えます。
  • GO_SETUP_GOPATH_IN_IMAGE​: ​true​ に設定すると、$GOPATH=$HOME​ が設定され、ユーザーコードが $GOPATH​ 内部の適切な場所に置かれます ($GOPATH/src/github.com/heroku/go-getting-started​ など)。dyno が開始すると、作業ディレクトリがユーザーコードのルートに設定されます。通常、buildpack は $HOME​ にユーザーコードを保持します。これは、dyno 内部に完全に機能する go ワークスペースおよびツールチェーンが存在するように、GO_INSTALL_TOOLS_IN_IMAGE=true​ とともに使用するときに最も役に立ちます。

上記の環境設定​のそれぞれは、コードをプッシュする前にアプリケーション上で設定する必要があり、これらの環境設定を有効にするために、環境設定が設定された後でコードをプッシュする必要があります。

ランタイムの動作

go1.5 以降、buildpack は Go ランタイム環境変数​を設定しません​。アプリケーションの設定​上でこれらの環境変数を設定でき、アプリケーションはそれらを配備して再起動します。go1.4 以前では、dyno のサイズに応じて、デフォルトの $GOMAXPROCS​ が設定されます。これは、heroku config:set​ を使用して GOMAXPROCS​ の値を設定することによって上書きできます。

buildpack は slug​ にコピーしないので、ランタイム環境には、go ツールチェーンやコンパイルしたパッケージファイル (*.a​) のコピーがありません​。

静的なアセットおよびファイル

git リポジトリに含まれるものはどれも、ランタイムに使用でき、Go の http.FileServer​ またはフレームワークの該当するものを使用してローカルファイルシステムから提供できます。go-assets​、go-bindata​、statik​ などのツールは、必要ではありません​。

デフォルトの Web プロセスタイプ

Go アプリケーションのデフォルトの Web プロセスタイプは定義されていません。Procfile の設定に関する詳細については、いずれかの Go チュートリアル​を参照してください。

アドオン

デフォルトではアドオンはプロビジョニングされていません。アプリで SQL データベースが必要な場合、明示的に追加します。

$ heroku addons:create heroku-postgresql

ベンダーディレクトリのサポート

ベンダーディレクトリサポートは、go1.6 でデフォルトになっており、heroku config:set GO15VENDOREXPERIMENT=0​ を実行することにより無効にできます。go1.5 の場合、GO15VENDOREXPERIMENT=1​ をアクティベートするように設定します。以前のバージョンの Go は vendor/​ ディレクトリをサポートしません。

ビルドは、コンパイル時に vendor/​ ディレクトリの内容を、$GOPATH​ にあるかのように使用します。現バージョンの godep​ は、ローカルで同じ環境変数を使用してベンダーディレクトリをサポート​します。ただし、godep​ を使用してコードをベンダー化するときには、./...​ が vendor/​ 内のパッケージを含むすべてのパッケージに一致するので、パッケージパスの指定は慎重に行う必要があります。Heroku では、このブログポスト​で詳しく述べているように、cmd​ ディレクトリのサブディレクトリの内部に、実行可能ファイルの個々のメインパッケージを配置することをお勧めします。

ここ​やここ​に、ベンダー実験に関する詳細があります。

追加のメインパッケージのベンダー化

さまざまなベンダー化ツールが、プロジェクトのベンダーディレクトリに、ローカルプロジェクト内のもの以外の追加パッケージを保存できます。これは、追加のメインパッケージを含め、コンパイルし、インストールするときに役立ちます。一般的な使用法は、データベースの移行を管理する migrate​ などのパッケージを含めるというものです。

Godep

godep で追加パッケージを保存させるには、godep save ./cmd/... github.com/golang-migrate/migrate​ のように、godep save​ を実行するたびに​、これらのパッケージを $GOPATH にインストールし、コマンドラインに含める必要があります。その結果生じる Godeps/Godeps.json​ および vendor/​ または Godeps/_workspace​ に対する変更はコミットする必要があります。

次回のプッシュで、Heroku は ./cmd/...​ と github.com/golang-migrate/migrate​ の両方をインストールします。

govendor

govendor は、govendor fetch github.com/golang-migrate/migrate​ のように、ローカルプロジェクトのパッケージ以外の追加パッケージを取得し、vendor/​ ディレクトリに直接保存できます。

さらに、vendor.json​ の heroku build configuration​ セクションは、次のように追加パッケージを heroku.install​ 配列に加える必要があります。

  ...
  "heroku" : {
    ...
    "install": [
      "./cmd/...",
      "github.com/golang-migrate/migrate"
    ]
  },
  ...

vendor/*​ に対する変更はコミットする必要があります。次回のプッシュで、Heroku は ./cmd/...​ と github.com/golang-migrate/migrate​ の両方をインストールします。

理解を深める

Heroku Go buildpack はオープンソースです。buildpack の仕組みの技術的な理解を深めるには、github.com/heroku/heroku-buildpack-go​ でソースコードを確認してください。


*​ dep​ サポートはコミュニティで提供されます。dep​ベースのビルド問題のサポートを得るには、Heroku Go Buildpack​ まで問題を提出してください。

関連カテゴリー

  • Go
Que-Go を使用したバックグラウンドジョブ Heroku スターターガイド (Go)

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure
  • .NET

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing
  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Github
  • LinkedIn
  • © 2025 Salesforce, Inc. All rights reserved. Various trademarks held by their respective owners. Salesforce Tower, 415 Mission Street, 3rd Floor, San Francisco, CA 94105, United States
  • heroku.com
  • Legal
  • Terms of Service
  • Privacy Information
  • Responsible Disclosure
  • Trust
  • Contact
  • Cookie Preferences
  • Your Privacy Choices