ノート: GitHub Actionsは、GitHub Enterprise Server 2.22で限定ベータとして利用可能でした。 ベータは終了しました。 GitHub Actionsは、GitHub Enterprise Server 3.0以降で一般に利用可能になりました。 詳しい情報については、GitHub Enterprise Server 3.0 のリリースノートを参照してください。
- GitHub Enterprise Server 3.0以降へのアップグレードに関する詳しい情報については「GitHub Enterprise Serverのアップグレード」を参照してください。
- アップグレード後のGitHub Actionsの設定に関する詳しい情報については、GitHub Enterprise Server 3.0のドキュメンテーションを参照してください。
ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情報を見ることができます。
サービスコンテナについて
サービスコンテナは、ワークフロー中でアプリケーションをテストもしくは運用するのに必要になるかもしれないサービスをホストするための、シンプルでポータブルな方法を提供するDockerコンテナです。 たとえば、ワークフローでデータベースやメモリキャッシュへのアクセスを必要とする結合テストを実行する必要があるかもしれません。
サービスコンテナは、ワークフロー中のそれぞれのジョブに対して設定できます。 GitHubは新しいDockerコンテナをワークフロー中で設定された各サービスに対して作成し、ジョブが完了したときにそのサービスコンテナを破棄します。 ジョブ中のステップは、同じジョブの一部であるすべてのサービスコンテナと通信できます。
ノート: ワークフローがDockerコンテナアクションあるいはサービスコンテナを使うなら、Linuxのランナーを利用しなければなりません。
- GitHubホストランナーを使うなら、Ubuntuランナーを使わなければなりません。
- セルフホストランナーを使っているなら、ランナーとしてLinuxマシンを使い、Dockerをインストールしておかなければなりません。
サービスコンテナとの通信
ワークフロー中のジョブは、直接ランナーマシン上で実行するようにも、Dockerコンテナ中で実行するようにも設定できます。 ジョブと、ジョブのサービスコンテナとの通信は、ジョブがランナーマシン上で直接実行されているか、コンテナ内で実行されているかによって異なります。
コンテナ内でのジョブの実行
コンテナ内でジョブを実行する場合、GitHubはDockerのユーザー定義ブリッジネットワークを使ってサービスコンテナをジョブに接続します。 詳しい情報についてはDockerのドキュメンテーションの「ブリッジネットワークの利用」を参照してください。
コンテナ内でジョブとサービスを実行すれば、ネットワークアクセスはシンプルになります。 サービスコンテナへは、ワークフロー中で設定したラベルを使ってアクセスできます。 サービスコンテナのホスト名は、自動的にラベル名にマップされます。 たとえばredis
というラベルでサービスコンテナを作成したなら、そのサービスコンテナのホスト名はredis
になります。
サービスコンテナでポートを設定する必要はありません。 デフォルトで、すべてのコンテナは同じDockerネットワークの一部となってお互いにすべてのポートを公開し合い、Dockerネットワークの外部へはポートは公開されません。
ランナーマシン上でのジョブの実行
ジョブをランナーマシン上で直接実行する場合、サービスコンテナにはlocalhost:<port>
もしくは127.0.0.1:<port>
を使ってアクセスできます。 GitHubは、サービスコンテナからDockerホストへの通信を可能にするよう、コンテナネットワークを設定します。
ジョブがランナーマシン上で直接実行されている場合、Dockerコンテナ内で実行されているサービスは、ランナー上で実行しているジョブに対してデフォルトではポートを公開しません。 サービスコンテナ上のポートは、Dockerホストに対してマップする必要があります。 詳しい情報については「Dockerホストとサービスコンテナのポートのマッピング」を参照してください。
サービスコンテナの作成
services
キーワードを使って、ワークフロー内のジョブの一部であるサービスコンテナを作成できます。 詳しい情報についてはjobs.<job_id>.services
を参照してください。
以下の例は、container-job
というジョブの中にredis
というサービスを作成します。 この例でのDockerホストはnode:10.18-jessie
コンテナです。
name: Redis container example
on: push
jobs:
# コンテナジョブのラベル
container-job:
# コンテナはLinuxベースのオペレーティングシステム内で実行する
runs-on: ubuntu-latest
# `container-job`が実行されるDocker Hubイメージ
container: node:10.18-jessie
# `container-job`と実行されるサービスコンテナ
services:
# サービスコンテナへのアクセスに使われるラベル
redis:
# Docker Hubのイメージ
image: redis
Dockerホストとサービスコンテナのポートのマッピング
ジョブがDockerコンテナ内で実行されるなら、ポートをホストあるいはサービスコンテナにマップする必要はありません。 ジョブがランナーマシン上で直接実行されるなら、必要なサービスコンテナのポートはホストランナーマシンのポートにマップしなければなりません。
サービスコンテナのポートは、ports
キーワードを使ってDockerホストにマップできます。 詳しい情報についてはjobs.<job_id>.services
を参照してください。
ports の値 | 説明 |
---|---|
8080:80 | コンテナのTCPのポート80をDockerホストのポート8080にマップします。 |
8080:80/udp | コンテナのUDPポート80をDockerホストのポート8080にマップします。 |
8080/udp | コンテナでランダムに選択したUDPポートをDockerホストのUDPポート8080にマップします。 |
ports
キーワードを使ってポートをマップする場合、GitHubは--publish
コマンドを使ってコンテナのポートをDockerホストに公開します。 詳しい情報についてはDockerのドキュメンテーションの「Dockerコンテナのネットワーキング」を参照してください。
Dockerホストのポートを指定して、コンテナのポートを指定しなかった場合、コンテナのポートは空いているポートにランダムに割り当てられます。 GitHubは割り当てられたコンテナのポートをサービスコンテナのコンテキストに設定します。 たとえばredis
サービスコンテナに対し、Dockerホストのポート5432を設定したなら、対応するコンテナのポートにはjob.services.redis.ports[5432]
コンテキストを使ってアクセスできます。 詳細については、「コンテキスト」を参照してください。
Redisのポートのマッピングの例
以下の例は、サービスコンテナredis
のポート6379を、Dockerホストのポート6379にマップします。
name: Redis Service Example
on: push
jobs:
# コンテナジョブのラベル
runner-job:
# サービスコンテナもしくはコンテナジョブの利用の際はLinux環境を使わなければならない
runs-on: ubuntu-latest
# `runner-job`と実行するサービスコンテナ
services:
# サービスコンテナへのアクセスに使われるラベル
redis:
# Docker Hubイメージ
image: redis
#
ports:
# ホストとサービスコンテナのTCPポート6379をオープンする
- 6379:6379