GitHub ActionsのためのDockerfileサポート

ノート: GitHubホストランナーは、現在GitHub Enterprise Serverでサポートされていません。 GitHubパブリックロードマップで、計画されている将来のサポートに関する詳しい情� �を見ることができます。

Dockerfileの命令について

Dockerfileには、Dockerコンテナの内容と起動時の動作を定義する命令と引数が含まれています。 Dockerがサポートしている命令に関する詳しい情� �については、Dockerのドキュメンテーション中の「Dockerfile のリファレンス」を参照してく� さい。

Dockerfileの命令とオーバーライド

Dockerの命令の中にはGitHub Actionsと関わるものがあり、アクションのメタデータファイルはDockerの命令のいくつかをオーバーライドできます。予期しない動作を避けるために、DockerfileがGitHub Actionsとどのように関わるかについて馴染んでおいてく� さい。

USER

DockerアクションはデフォルトのDockerユーザ（root）で実行されなければなりません。 GITHUB_WORKSPACEにアクセスできなくなってしまうので、Dockerfile中ではUSER命令を使わないでく� さい。詳しい情� �については、「環境変数の利用」と、Dockerのドキュメンテーション中のUSERのリファレンスを参照してく� さい。

FROM

Dockerfileファイル中の最初の命令はFROMでなければなりません。これは、Dockerのベースイメージを選択します。詳しい情� �については、Dockerのドキュメンテーション中のFROMのリファレンスを参照してく� さい。

FROM引数の設定にはいくつかのベストプラクティスがあります。

公式のDockerイメージを使うことをおすすめします。たとえばpythonやrubyです。
バージョンタグが存在する� �合は使ってく� さい。メジャーバージョンも含めることが望ましいです。たとえばnode:latestよりもnode:10を使ってく� さい。
Debianオペレーティングシステ� に基づくDockerイメージを使うことをおすすめします。

WORKDIR

GitHub Enterprise Serverは、ワーキングディレクトリのパスを環境変数のGITHUB_WORKSPACEに設定します。 Dockerfile中ではWORKDIR命令を使わないことをおすすめします。アクションが実行される前に、GitHub Enterprise ServerはGITHUB_WORKSPACEディレクトリを、Dockerイメージ内にあったその� �所になにがあってもその上にマウントし、GITHUB_WORKSPACEをワーキングディレクトリとして設定します。詳しい情� �については「環境変数の利用」と、Dockerのドキュメンテーション中のWORKDIRのリファレンスを参照してく� さい。

ENTRYPOINT

アクションのメタデータファイル中でentrypointを定義すると、それはDockerfile中で定義されたENTRYPOINTをオーバーライドします。詳しい情� �については「GitHub Actionsのメタデータ構文」を参照してく� さい。

DockerのENTRYPOINT命令には、shell形式とexec形式があります。 DockerのENTRYPOINTのドキュメンテーションは、ENTRYPOINTのexec形式を使うことを勧めています。 execおよびshell形式に関する詳しい情� �については、Dockerのドキュメンテーション中のENTRYPOINTのリファレンスを参照してく� さい。

You should not use WORKDIR to specify your entrypoint in your Dockerfile. Instead, you should use an absolute path. For more information, see WORKDIR.

exec形式のENTRYPOINT命令を使うようにコンテナを設定した� �合、アクションのメタデータファイル中に設定されたargsはコマンドシェル内では実行されません。アクションのargsに環境変数が含まれている� �合、その変数は置換されません。たとえば、以下のexec形式は$GITHUB_SHAに保存された値を出力せず、代わりに"$GITHUB_SHA"を出力します。

ENTRYPOINT ["echo $GITHUB_SHA"]

変数の置換をさせたい� �合は、shell形式を使うか、直接シェルを実行してく� さい。たとえば、以下のexec形式を使えば、シェルを実行して環境変数GITHUB_SHAに保存された値を出力できます。

ENTRYPOINT ["sh", "-c", "echo $GITHUB_SHA"]

アクションのメタデータファイルに定義されたargsを、ENTRYPOINT中でexec形式を使うDockerコンテナに渡すには、ENTRYPOINT命令から呼ぶentrypoint.shというシェルスクリプトを作成することをおすすめします。

Dockerfileの例

# コードを実行するコンテナイメージ
FROM debian:9.5-slim

# アクションのリポジトリからコードをコンテナのファイルシステ� パス `/` にコピー
COPY entrypoint.sh /entrypoint.sh

# Dockerコンテナの起動時に `entrypoint.sh` を実行
ENTRYPOINT ["/entrypoint.sh"]

entrypoint.shファイルの例

上のDockerfileを使って、GitHub Enterprise Serverはアクションのメタデータファイルに設定されたargsを、entrypoint.shの引数として送ります。 Add the #!/bin/sh shebang at the top of the entrypoint.sh file to explicitly use the system's POSIX-compliant shell.

#!/bin/sh

# `$*`は`array`内で渡された`args`を個別に展開するか、
# 空白で区切られた文字列中の`args`を分割します。
sh -c "echo $*"

コードは実行可能になっていなければなりません。 entrypoint.shファイルをワークフロー中で使う前に、execute権限が付けられていることを確認してく� さい。この権限は、ターミナルから以下のコマンドで変更できます。

chmod +x entrypoint.sh

ENTRYPOINTシェルスクリプトが実行可能ではなかった� �合、以下のようなエラーが返されます。

Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/entrypoint.sh\": permission denied": unknown

CMD

アクションのメタデータファイル中でargsを定義すると、argsはDockerfile中で指定されたCMD命令をオーバーライドします。詳しい情� �については「GitHub Actionsのメタデータ構文」を参照してく� さい。

Dockerfile中でCMDを使っているなら、以下のガイドラインに従ってく� さい。

必� �の引数をアクションのREADME中でドキュメント化し、CMD命令から除外してく� さい。
argsを指定せずにアクションを利用できるよう、デフォルトを使ってく� さい。
アクションが--helpフラグやそれに類するものを備えているなら、アクションを自己ドキュメント化するために利用してく� さい。

サポートされているLinuxの機能

GitHub Actionsは、DockerがサポートするデフォルトのLinuxの機能をサポートします。機能の追� や削除はできません。 DockerがサポートするデフォルトのLinuxの機能に関する詳しい情� �については、Dockerのドキュメンテーション中の「 Runtime privilege and Linux capabilities」を参照してく� さい。 Linuxの機能についてさらに学ぶには、Linuxのman-pageの" Overview of Linux capabilities"を参照してく� さい。

ここには以下の内容があります: