Runnerをインストールし、稼働させるところまでやってみました。Runnerという新機能が追加されました。これはCIのコントロールプレーンをSaaSに管理してもらい、ワーカーのみを自社ネットワーク内にデプロイできるという機能です。CIから利用する強い権限につながるクレデンシャル類を他社サービスに渡したくないが、かといって自社でCIをセルフホストするのも避けたい・・・という場合に必要になる機能です。これまで、運用の手間をできるだけ減らしつつ、他社サービスにクレデンシャル類を直接渡したくないような場合、CodefreshのEnterpriseプランに代表されるようにSaaSの特定プランを利用するJekinsなどのCIをセルフホストするCircleCIのEnterpriseプランのようにコントロールプレーンごと自社ネットワーク内に置くASP型のサービスを利用するという選択肢しかありませんでした。Runnerを利用すると、これが追加料金なしで(ワーカーの費用はもちろん自社持ちですが)実現できる、ということで個人的に期待しています。Runnerですが、今流行の?コンテナ化前提にはなっていません。公式の手順だと物理マシン・仮想マシン・コンテナなどでいくつかのコマンドを実行することでセットアップする、ということになっています。コンテナでも動かせる、というような趣旨の説明はドキュメントにも書かれていますが、DockerfileやDockerイメージが配布されているわけではありません。Runnerは利用したいが、そのためにVMの管理をするのはできるだけ避けたいので、まずはDockerfileを書きたい・・・ということで、公式のセットアップ手順をコンテナ内で実行して、実際コンテナ化できそうか確認してみたいと思います。Actions以下(https://github.com/$OWNER/$REPO/settings/actions)から公式のRunner追加手順や、現在登録されているRunnerとその稼働状況が確認できる。runner」をクリックすると、以下のような手順が表示される。基本的にはこの手順にそっていけばよい。公式イメージも、Dockerfileもない状態なので、今回は勘所を掴むことを目的に、適当なコンテナの中で公式のインストール手順を追ってみる。sh手順通り、curlでリリースアーカイブをダウンロード、展開する。いうディレクトリ内にファイル一式が展開される。実行できない・・ということなので、適当なユーザをつくる。ユーザがリリースアーカイブから展開したファイルにアクセスできるように、chownしておく。runner再度config.shを実行してみる。実行してインストールする必要がある模様。Dependencies-----------------------------改めて、非rootユーザでconfig.shを実行してみる。Exiting...どうやら実行時に対話的にrunner名と作業用ディレクトリのパスを入力しなければならないようだ。できれば環境変数、コマンドライン引数等で予め指定できると自動化しやすいが・・・。みてもrunner名を先に決めておくためのオプションはないようなので、expectで自動化することにする。0"これをautoconfのような適当な名前のファイルに保存して実行する。Saved.これで指定した名前のRunnerがActionsに登録される。この設定内容は.runnerというファイルに保存されている模様。"_work"}これで設定が完了したので、Runnerを起動する。UI上で以下のように実行待ち状態になったことが確認できる。Runnerを指定する。Unauthorizedになってしまった。(Unauthorized).気になって確認してみたところ、(考えてみれば当たり前かもしれないが)、Runnerを追加するたびに次のRunner専用のトークンが払い出されているようだ。Dockerfileを書くにあたって抑えたいポイントOSの選択肢はいくつかある。今回はubuntu:latestで問題ないことが確認できた。ちなみにubuntu:latestは最新LTSに追従しているので、定期的にビルドし直す前提でこれをベースイメージしてしまってもよいかもしれない。curlおよびexpectのインストール、リリースアーカイブのダウンロードと展開、installdependencies.sh、config.sh、run.shの順で実行する。runner時にGitHubが提示してくれるトークンはRunnerを追加するたびに変わる。したがって、1つランナーを立ち上げるたびにトークンを人力で確認し入力しなければならない・・・。GitHubさんへのお願いRunnerの追加を自動化できるようにしてほしいRunnerの追加を自動化できるようにしてほしいです。UIをスクレイピングすればやれないことはないとは思いますが・・・)。KubernetesのDeploymentやDaemonset、StatefulSetなどでRunnerの個数を柔軟に変えられるようにしようと思った場合、素朴に実装すると、同じトークンで複数のRunnerが登録・起動できるようになっているとうれしいです。(おそらくそうなのだと思いますが)それがセキュリティ的に望ましくないということであれば、Runner用のトークンを払い出す専用のトークンを作れるようにしてほしいです。Operatorなどを自作し、そこからRunnerのインスタンス毎にトークンを払い出すようなことが可能だと思います。upLoginユーザーは見つかりませんでした。