最終更新日 2018年05月23日(水)

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

​

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

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

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​ (コミュニティサポート*)

​

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

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 フラグです。
• ​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

​

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

ビルドは、コンパイル時に ​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​ まで問題を提出してください。