Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい

サービスコンテナについて

サービスコンテナを使って、データベース、Webサービス、メモリキャッシュ、あるいはその他のツールをワークフローに接続できます。

注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

サービスコンテナについて

サービスコンテナは、ワークフロー中でアプリケーションをテストもしくは運用するのに必要になるかもしれないサービスをホストするための、シンプルでポータブルな方法を提供する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:16-bullseye コンテナです。

YAML
name: Redis container example
on: push

jobs:
  # Label of the container job
  container-job:
    # Containers must run in Linux based operating systems
    runs-on: ubuntu-latest
    # Docker Hub image that `container-job` executes in
    container: node:16-bullseye

    # Service containers to run with `container-job`
    services:
      # Label used to access the service container
      redis:
        # Docker Hub image
        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 にマップします。

YAML
name: Redis Service Example
on: push

jobs:
  # Label of the container job
  runner-job:
    # You must use a Linux environment when using service containers or container jobs
    runs-on: ubuntu-latest

    # Service containers to run with `runner-job`
    services:
      # Label used to access the service container
      redis:
        # Docker Hub image
        image: redis
        #
        ports:
          # Opens tcp port 6379 on the host and service container
          - 6379:6379

参考資料