令和最新版 actions-cache-s3

こんにちは、whywrite.it CI/CD班のwhywaitaです。

つくりました。

これはなに

GitHub Actionsにはactions/cacheというものがあって、ビルド時の依存関係を解決したものとかをキャッシュしておくことができます。

標準ではGitHubが提供するキャッシュサーバにファイルが保存されるんですが、さまざまな事情により自分たちが管理するストレージに置きたいことがあります。

  • AWSなどでself-hosted runnerを運用している
  • GitHub Enterprise Server を運用している (2022年現在未対応)

というわけでS3にアップロードするようなActionを作りました。冒頭にある whywaita/actions-cache-s3 です。

令和最新版とは

このS3にアップロードするというアイデアは別に新しいものでもないので、既にインターネットには色んな実装が存在しています。

ただ、軽く調べた限りだと ~/go/pkg/mod のようなチルダが含まれるパスに対応していなかったりと細かい actions/cache の機能に追従できていないことが多かったため、エイヤで作ったのが今回のものです。

沢山似たようなものがあるけど現時点だと1番新しいものに対する表現といえばそう、「令和最新版」ですね。

まとめ

以前から開発しているGitHub Actionsのrunner基盤はGHESとGHECに対応していて、「GHESだと actions/cache 使えないんですよね」という声をよく聞いていたので実装してみました。

社内だと同じチームのメンバーが提供しているAWS S3互換のオブジェクトストレージが提供されたのでその上で動作するように実装されています。具体的にはこのへん

とはいえAWSが提供するS3でも動作する(はず)ですので、もし何らかの事情でS3にキャッシュを置きたくなった方はぜひどうぞ。

バイナリぽん置きでファイルをGitHubに保存するツールを書いた

こんにちは。 whywrite.it 開発班のwhywaitaです。

標題の通りです。雑にサーバ上にバイナリ置いてcron等に登録したらバックアップが取れる!!みたいなのが欲しくて書きました。
名前はファイルを上に上げるというだけの思いつきです。

(さらに…)

技術書典7にてPull ReqベースのモダンKubernetes開発環境についての本を出します #技術書典

こんにちは。whywrite.it 出版班のwhywaitaです。

09/22 に開催される技術書典7にてKubernetesを用いたモダン開発環境についての本を出します。
頒布場所は「お13C てっき〜メディア」さん、表紙はへびつかいさんにご提供いただきました。

前半部分を私(@whywaita)が、後半部分を新卒同期の@msy_mtd_a5が担当しています。

サークル詳細 | てっき〜メディア | 技術書典

(さらに…)

kubernetesに自分のコードがマージされるまでのフロー

はじめに

こんにちは。kubernetes班のwhywaitaです。皆さんkubernetesやっていますか?

kubernetes を使う場合、アプリケーションをデプロイする際にミドルウェアの管理に悩むことがあり、その解決策として様々なアプリケーションが開発されています。1

その中でも私はHelmがお気に入りです。
自分のアプリケーションを含めた全てのデプロイをHelmで賄うのには向いていないように感じますが、アプリケーションで必要なミドルウェア(DB、KVSなど)を立ち上げる用途としてはかなり優秀なプロダクトだと思います。

そのHelmでインストールすることの出来るミドルウェアの単位をchartと呼びます。chartが集まったものをリポジトリと呼び、 stable リポジトリと incubator リポジトリはGitHub上で公開されています。

GitHub上で公開されているので、もし何らかの修正を行いたい場合はPull Requestを送る事が出来るのですが、一般的に使われているフローではなく、一定のルールを満たす必要があります。
あまり日本語情報が無いように思ったので、今回は実際にkubernetes OrganizationであるHelmにPull Requestを送り、無事マージされるまでのフローを書きます。

バージョン

Pull Requestであるためそれほどアプリケーションのバージョンは依存しませんが、念のため作業環境のバージョン書いておきます。

  • kubernetes: v1.10.3
  • kubectl: v1.10.4
  • helm client: v2.8.2
  • helm server: v2.8.2

Pull Requestフロー

まずは、kubernetesが定めるContributor License Agreements、略してCLAの提出が必要となります。
これはkubernetesにコントリビュートする際に満たすべき制約に、コントリビュートした全員が承諾する事を担保するものです。

kubernetesはCloud Native Computing Foundation(CNCFと呼ばれます)に入っているプロジェクトの1つであり、CNCFはLinux Foundationに入っているプロジェクトの1つです。
このような関係を持つため、kubernetesのCLAは現状Linux Foundationのシステムを用いて、CNCFのCLAを提出すれば認可されます。

Linux Foundationアカウント発行

Linux FoundationのCLAには個人向けと企業向けの2種類が存在しています。私は個人としてCLAの提出を行ったため、今回は個人向けの作業をお伝えします。

下記のURLから、Linux Foundationのアカウントを発行します。
https://identity.linuxfoundation.org

ソーシャル連携でアカウントを作成しても良いですし、Linux Foundationのアカウントを新規に作っても構いません。
最終的にLinux FoundationのアカウントとGitHubのアカウントを紐付ける必要があるため、GitHub連携でログインしておけば若干手間が減るかもしれません。
私はLinux Foundationのアカウントを作り、その後GitHub連携を行いました。勿論この方法でも問題無くCLAの提出は可能です。

アカウント作成中にFirst nameとLast nameを入力する欄がありますが、基本的には公開されず、usernameで書いた部分のみ公開されます。

また、この時設定するメールアドレスにはGitHubのコミット上で用いているメールアドレスと同じものを利用するようにしてください。コミットとの紐付けに利用しているようです。
現在利用しているメールアドレスは以下のコマンドで確かめられます。

$ git config user.email
whywaita@whywrite.it  # 私の場合

最後に、GitHub連携以外の方法でアカウントを作成した場合は、こちらからGitHub連携を追加しておいてください。

CLAを提出し、CNCFグループに入る

以下のURLから、自分のLinux FoundationアカウントをCNCFグループに参加させることができます。

https://identity.linuxfoundation.org/projects/cncf

アカウント作成、およびGitHub連携が既に済んでいる場合、以下のような画面が出ます。

名前とメールアドレスが間違っていなければ、そのままSubmitを押します。
すると、登録しているメールアドレスにHelloSignというサービスからメールが届きます。

HelloSignは電子署名システムの1つで、実際に紙を印刷してサインをせずともWebブラウザのみで電子署名が行えるシステムです。
Review & Signのリンクからページに飛ぶと、CLAで承諾すべき項目が実際に表示され、問題無ければ項目を埋めて提出します。

CLAの文章自体はこちらに公開されています。
HelloSignのサービスを利用したくなかったり、紙を用いた証拠が欲しい場合は、PDFをスキャンして info@cncf.io に送信したり、Linux Foundationのオフィスに国際郵便で送付することも可能です。CLAの文書にどのような手法を用いられるのか記載されているので、CLAを提出する際にご確認ください。2

HelloSign上でCLAを提出した場合、提出に成功したことがメールで通知され、HelloSign上のシステムでも提出が完了したことを確認できます。
私が提出した時は、数分程度で提出完了のメールが届きました。

これにてCLAの提出は完了です。

Pull Requestの作成

これでようやくコードを書くことができます。
ここからは実際に私が出し、マージされたPull Requestを例としながら説明していきます。

Pull Requestの作り方(Forkして、ブランチを切って、など)は一般的なフローと同じですので割愛させて頂きます。

実際にPull Requestを出すと、k8s-ci-robotというユーザが自動的にラベル付けなどを行ってくれます。
このユーザはkubernetesチームが用意した自動化用のbotシステムであり、そのPull Requestの状況等を管理してくれます。

3

CLAの提出が正しく出来ていれば、この段階でこのようなメッセージが来ます。

レビューしてもらう

Pull Requestが自分の中でレビューして貰って問題無い状態になったら、レビューアーをアサインしてレビューしてもらいます。

レビューアーに指定するべき人がランダムで提案されますが、基本的には担当者全員アサインして良いようです。
この時のアサイン対象者ですが、誰でも良いという訳ではなく、chart毎に指定するべき人が決まっています。例えば私が今回出したdatadogであれば、以下のURLにあるOWNERSファイルに書かれています。

https://github.com/kubernetes/charts/blob/master/stable/datadog/OWNERS

GitHubのシステム上、ブラウザ上からアサインすることも技術的には可能なのですが、アサインの状態を可視化するためにk8s-ci-robotにアサインしてもらう運用になっているようです。
/assign コマンドを実行します。実際のコメントはこちらです。

その後はレビューアーの指示に従い、修正や議論を行います。4

実際にマージする実行をするのはk8s-ci-robotですが、レビューアーに lgtm ラベルと approve ラベルを付けてもらう必要があります。
その時々でラベルの付ける順番などは変わるようなので、適宜レビューアーに聞いてみると良いかもしれません。
私も聞いた結果ラベルが付与されました

最終的に問題がないと判断されれば、k8s-ci-robotによってマージされます!

おわりに

このフローを踏むことで、無事kubernetesグループに貢献することが出来ました。
OSSを使うだけでなく、OSSに貢献することで、OSSの素晴らしいライフサイクルを回せていければと思います。

また、本記事公開以降コントリビュート手順が変更される可能性があります。
もし不明な点があった場合は、原文であるこちらを参照してください。

HERP広告

この記事は株式会社HERPの勤務中に書かれた物である。
株式会社HERPでは今後もOSSに貢献し続けます。

株式会社HERPは様々な職種での人材を募集しています。

また、この広告箇所は本の虫のオマージュです。


  1. Kubernetes YAMLの壁 | SOTA 
  2. ちなみに私が提出した際のCLAはこのコミットです。 
  3. robotは既に終了した自分のコメントに関しては消してしまうので、私のメーラーに来ていた通知メールのスクリーンショットです 
  4. ここが一番難しいかもしれませんね…