はじめに
こんにちは！ACS事業部の谷合です。
皆さん、CI/CDする時にどのツールを使いますか?
そう！みんな大好きGitHub Actionsですよね！！
今回はタイトルの「GitHub Actionsのstepでdockerコンテナを実行する2つの方法のユースケース」について考えてみました。
事の発端
ところで、Workflow内でstepごとにdockerコンテナを実行したいときありますよね?
(僕はありませんでした)
しかし案件内で、そのようなタイミングが来たのです。
dockerコンテナをsteps実行するには、以下の2つの方法があります。
- jobs.<job_id>.steps[*].runでdocker run
- jobs.<job_id>.steps[*].usesでdocker://<イメージ名>:<タグ>
そこで気になりました。どっちがいいの！？
各実行方法の使用
上記2つの方法の差異について、ご存じでしょうか?
jobs.<job_id>.steps[*].run
jobs.<job_id>.steps[*].runでdocker runを実行するのは、ローカルでdocker runするのと変わりません。
つまり、通常のdocker runで指定できるオプションはすべて実行できるというわけです。
jobs.<job_id>.steps[*].uses
次にjobs.<job_id>.steps[*].usesでdocker://<イメージ名>:<タグ>の方について見てみます。
jobs.<job_id>.steps[*].usesでdockerコンテナを利用する場合、以下のようにdocker runがデフォルトで実行されます。
/usr/bin/docker run --name ubuntulatest_713bf6 --label ef7d85 --workdir /github/workspace --rm -e "INPUT_ARGS" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_ENVIRONMENT" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/test-repo/test-repo":"/github/workspace" ubuntu:latest cat /github/workspace/testfile
今回着目すべきはここです。
この-vオプションで、Runnerのディレクトリをdockerコンテナにバインドマウントしています。
-v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/test-repo/test-repo":"/github/workspace" ubuntu:latest cat /github/workspace/testfile
色々とマウントしていますが、/home/runner/work/test-repo/test-repo がRunnerのデフォルトディレクトリです。
正確には/home/runner/work/リポジトリ名/リポジトリ名となるはずです。
上記docker runしたリポジトリはtest-repoですので、このようなディレクトリとなっています。
このディレクトリがRunnerのデフォルトディレクトリとなります。
デフォルトディレクトリはコンテナ内の/github/workspaceにマウントされているので、コンテナ内からはRunnerのファイルが見れるというわけです。
以降でjobs.<job_id>.steps[*].usesのメリットについて解説します。
仕様により実現できること
Self-hosted runnerを使っている環境でAWS CLIがインストールされていないため、AWS CLIをdockerコンテナとして実行する必要があるケースを考えてみましょう。まず、GitHub ActionsからAWSに接続する際には、以下のActionを利用してOIDCをしますよね? github.com その際、認証情報はデフォルトディレクトリに保存されます。
jobs.<job_id>.steps[*].usesでは、自動でデフォルトディレクトリをバインドマウントするので、特別な設定なしでデフォルトディレクトリのファイルを参照可能です。そのため、 jobs.<job_id>.steps[*].usesでAWS CLIを実行した場合は、通常通り実行できるわけです。
jobs.<job_id>.steps[*].runの場合は、通常通りdocker runするのみなので、デフォルトディレクトリのファイルを参照するにはバインドマウントする必要があります。そのため、 マウントなしでjobs.<job_id>.steps[*].runでdocker runしてAWS CLIを実行した場合は以下のエラーが発生します。
You must specify a region. You can also configure your region by running "aws configure"
ユースケースについて考える
まとめると、以下のユースケースが考えられます。
jobs.<job_id>.steps[*].uses
- 特別な設定なしで、コンテナ内でRunnerのファイルを参照したい場合
- dockerの知識なしで、コンテナを実行したい場合
jobs.<job_id>.steps[*].run
- docker runでマウント対象を色々と指定したい場合
- 詳細なオプションを記載したい場合
さいごに
今回は、なかなかコアなテーマで書いてみました。
私もGitHub Actionsでdockerコンテナを実行する際の違いについて整理できたので、いい機会になったかなと思います。
上記ユースケース以外でも互いの選択方法は存在するかと思います。
ファイル参照以外でもいろんな使い方を模索してみるも面白いかもしれませんね。
ACS事業部のご紹介
私達ACS事業部はAzure・AKSなどのクラウドネイティブ技術を活用した内製化のご支援をしております。
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
