夏は黄昏、やうやう白くなりゆくYo!!チェケラッチョ！！！！！！！！！こと 技術部技術基盤チームの P山 です。こんにちは。今日は筆者が日々メンテナンスしているペパボのCI基盤やそれに関連する技術について紹介します。
Github Actions
ペパボではCI基盤としてGitHub Enterprise Serverと連携して動作する、Github Actionsを利用しています。GitHub Actionsはself-hosted runnerと組み合わせて利用しています。
self-hosted runnerとは、任意のサーバの上でRunnerプロセスを動作させ、そのサーバ上でGithub Actionsを実行することができる仕組みです。サーバの管理が必要ではありますが、柔軟にCIに利用するリソースをコントロールすることができます。ペパボでは社内で運用しているOpenStackのインスタンスにChefを利用してプロビジョニングし、各事業部ごとに割り当て、利用しています。
先に柔軟にリソースをコントロールすることができると記載したとおり、ペパボでは実行されるActionに応じて、複数の種類のself-hosted runnerを利用しています。
CPU、メモリーの割当が異なるインスタンスを用意しておき、それらに例えば、コンテナビルド用途であれば、Builder、並列度の高いテスト実行用途であればLargeというようなラベルを付与し、Actionsの定義のruns-on句でラベルを指定してサイズの異なるインスタンスを使い分けています。また事業部に割り当てたself-hosted runnerが十分に足りているかどうかは、下記のようにGrafanaで可視化し、管理しています。
Dockerの利用
GitHub ActionsではDockerイメージを利用したテストを行うことが可能です。Dockerにおいてもいくつか工夫をして利用しています。
イメージのキャッシュとホスト
Docker社の提供しているコンテナレジストリはレートリミットが存在します。テストで利用するMySQLやRedisなどのミドルウェアは公式イメージを利用することが多いのですが、ペパボ全体で共用しているGithub Actionsでそれらを何も気にせず利用すると、すぐにレートリミットに達してしまいます。それを回避すべく、自社でコンテナレジストリーのキャッシュサーバを用意し、なるべくイメージをキャッシュする、もしくは予めイメージを自社のコンテナレジストリにpullしておき、自社のサーバでホストすることで、レートリミットを回避しています。
ユーザー名前空間の分離
Github ActionsからDockerを利用する場合、何も気にせずに利用すると、self-hosted runnerやDockerがrootユーザーの権限で起動するため、任意のボリュームをマウントして書き換えたり、サーバに対して悪意のある操作が可能です。それらを防止するためにGithub Actionsは一般ユーザーで実行し、Dockerについてはユーザー名前空間を分離することで、コンテナ上のrootをホストOS上では一般ユーザーにマッピングすることで、ホストOSの特権操作をできなくしています。Dockerではそもそもrootlesskitを利用し、一般ユーザーでのコンテナ起動も可能ではありますが、systemdが一部、ユーザー管理になったりすることで依存関係の整理が煩雑になることや、我々の用途ではユーザー名前空間の分離だけで現状の要件は満たせているので、この選択をしました。
Github Packages
ペパボにおいては自社で運用しているサービスのプロダクション、テスト用のDockerイメージを管理するのに、Github Packages を活用しています。こちらもGithub Enterprise Serverで利用することができるため、自社のサーバでホストしています。またDockerイメージ以外にもRubyのGemなども同じく自社でホストしています。
Trivyの活用
自社で管理しているDockerイメージについては筆者が開発したgithub-image-scannerを利用して、全て脆弱性スキャンを行っています。内部で実行される脆弱性のスキャンにはTrivyを採用しています。
github-image-scannerは指定したOrganizationのリポジトリにGithub Packagesとして登録されているDockerイメージをすべてTrivyで検査し、脆弱性が検知された場合、該当のリポジトリにGitHub Issue(以降issue)を作成します。利用方法は、github-image-scannerのREADME.mdを参照してください。実際に脆弱性が検知された場合、下記のようなissueが作成されます。
issueが作成された場合、開発者には下記のアクションを求めます。
- プロダクションで利用されるイメージの場合、速やかに脆弱性を含んだ問題の解消を行う。
- 外部に露見しない用途の場合は、脆弱性を解消するか、スキャンをスキップする設定を行う
コンテナイメージのスキャンについてはビルドと同じタイミングでもれなく実行されることが望ましいと思いますが、抜け、漏れを防止するために、Organizationを対象としたスキャンも行っています。
事例紹介
Github Actionsは主にCI用途で利用される基盤ですが、ペパボでは単純にジョブ実行基盤としても活用しています。Github Actionsには repository_dispatch というon句が定義可能 です。これを利用すると、任意の処理をパラメーター付きでトリガー可能になります。
たとえば大量のサーバに最新のマニフェストを適用するような業務も、repositry_dispatchを利用することでGithub Actionsから実行しています。こうすることでインフラエンジニアが環境構築することや通信経路を準備することなくサーバに対してマニフェストを適用できますし、実行履歴もWEBで見ることができるのでとても便利です。
repository_dispatch の実行には筆者の開発した github-actions-trigger-botを利用しており、実行のイメージは以前同僚のよしこさんが Slack ワークフロー × GitHub Actions で何時でも誰でも楽なステージングデプロイを実現するで紹介したとおりです。
最後に
Github Actionsはself-hosted runnerを上手に利用することでテスト実行基盤という役割だけでなく、例えばキャッシュを効かせながら高速にDockerイメージをビルドすることや、内部システムと連携させてワークフローに組み込んだり、またはコンテナジョブ実行基盤として利用するなど幅広い活用方法があり、これらを自由度高く技術的にアプローチすることができるのはオンプレミスのインフラ基盤をもっている強さの1つであると考えています。
ペパボにはCI基盤だけでなく、大規模なオンプレミスインフラ基盤、AWS、GCPを利用したハイブリッドクラウドインフラ基盤など技術的にトライできる環境が多くあります。今回はCI基盤について紹介しましたが、ペパボには事業部を超えて活躍することができる機会が多く存在します。それらに興味がある、作ってみたいという方は今すぐ、エントリーシートを書いていただき、P山の紹介と書いていただけると僕がリファーラル採用手当で車を買うことができるので、ぜひ一つ！よろしくおねがいします！