はじめに
キャディでバックエンドエンジニア兼DevOpsエンジニアをやっている山下です。
今回取りあげたいのはCircleCIのOrbという機能です。
現在、開発者は、開発する際、息をするぐらい自然にOSSライブラリーを使って開発を進めますよね。 インフラに関しても、TerraformやAnsibleなどではモジュールが公開されていたりと、 少しずつですがOSSの考えが普及してきているように思います。
ただ、その中間に位置する、CI/CDの部分になると、技術スタックや開発の流れに個別性が強いからか、 あまりOSS化・共通化が進んでこなかったように思います。
そんな中、CircleCIがOrbという機能をリリースしています。
最近では、Facebook広告などで、Orbの宣伝をするほど、CircleCIとしても力を入れている機能です。
https://www.youtube.com/watch?v=B5-UWDnvKRo
Orbって何?
早速、Orbについて説明すると、 Orbは簡単にいうと、CircleCIの設定を共通化するためのパッケージになります。
そして、そのパッケージを、npmやDocker Hubのようにクラウドで管理できるように、 CircleCIがレジストリーを保持しています
これによって、CircleCIでCIを構築する際は、このレジストリーから必要なパッケージを選んで使用するだけで、 簡単に複雑な設定を組み込むことができるようになります。
どうやって使うの?
使い方はシンプルで、CircleCIの設定ファイルに必要なパッケージを 下記のようにインポートするだけで使用することができます。
version: 2.1
orbs:
slack: circleci/slack@0.1.0
heroku: circleci/heroku@0.0.1
ただ、この状態は、コードにライブラリーをインポートしただけの状態ですので、 実際に使用するためには、定義を書いていく必要があります。
そして、使い方の詳細は各Orbによって異なるため、Orb毎のドキュメントを読む必要があります(ライブラリーと同じですね)
CIでよく行う設定として、Slack通知が上げられると思うので、 今回はSlackを例にOrbを使った設定までの流れを説明していきたいと思います。
ステップとしては三つです
- 調べて選ぶ
- ドキュメントを読む
- 実装する
調べて選ぶ
まずやるのが、レジストリーでの検索です この時、目安となるのがタグの表示です
Certified
と記されているものが、CircleCIが公式で提供しているもので、
Partner
と記されているものが、CircleCIとパートナープログラムを締結した会社によるものです
他にも会社やコミュニティ、個人などが公開したOrbが多数存在します。 (タブを切り替えることで確認することが可能です)
基本的に、公式かパートナーのものを選びましょう。
ドキュメントを読む
ドキュメント読めっていうなら、この記事読まんわい、という感じかと思いますが、 結局、最後に頼りになるのはドキュメントなので、読み方をご紹介出来ればと思います。
Slackだとこちらが公式で提供しているドキュメントになります。
公式のドキュメントの構成は大体下記の5つで、他のOrbも項目としては一緒で、構成に応じて、一部欠けていることがあります。 (これは、ドキュメントが自動生成されるためで、定義していない項目は表示されないからです)
- Usage Examples
- Jobs
- Commands
- Executors
- Orb Source
Usage Examples
名前の通り使用例になります。 その後に書かれているJobやCommandの使用例が書いてあります。
簡単な使い方であれば、こちらを参考に実装だけで十分ですが、 細かなパラメーターやその説明を読みたい場合は、その後の二つを読みます。
JobとCommandの違い
初めて読むと混乱するのが、JobとCommandの違いです JobはWorkflowの項目で他の自分で設定したジョブと同じように実装します
orbs:
slack: circleci/slack@x.y.z
version: 2.1
workflows:
your-workflow:
jobs:
- your-original-job
- slack/approval-notification:
message: Pending approval
webhook: webhook
Jobは簡単な設定をするだけで使えるため大変便利ですが、細かな設定をジョブの途中に差し込みたい場合は不便です。 その時に使うのがCommandです。
Commandは、Jobの設定を行う際に使用します。 steps以下に、他に設定したい項目と合わせて設定し、自分の使い方にあったジョブを作成することができます。
jobs:
build:
docker:
- image: <docker image>
steps:
- your-original-step
- slack/notify:
channel: CHANNELID
color: '#42e2f4'
mentions: 'USERID1,USERID2,'
message: This is a custom message notification
webhook: webhook
orbs:
slack: circleci/slack@x.y.z
version: 2.1
workflows:
your-workflow:
jobs:
- build
JobとCommandの呼び出し方
呼び出し方としては、JobもCommandも一緒で
最初に下記のようにインポートした際のキーを使って、slack/${JOB_NAME}
やslack/${COMMAND_NAME}
とすれば使用可能です
orbs:
slack: circleci/slack@x.y.z
このキーは自由に設定することができる
ため、下記のように設定したら、my_slack/${JOB_NAME}
という風に使用します
このように、Orb名ではなく自分が設定したキー名で指定する
ことを忘れないでください
orbs:
my_slack: circleci/slack@x.y.z
Executors
Executorsは実行時に使用するDocker Imageを指します。 その他パラメーターを設定できることもあり、imageのtagや言語バージョン、executorのリソースクラスの変更などが設定出来るようにしていることが多いです。 (サンプルにgcp-cliのOrbのリンクを載せておきます)
使い方としては、何かと使う機会の多いリソースサイズだと下記のように設定します
orbs:
slack: circleci/slack@x.y.z
version: 2.1
workflows:
your-workflow:
jobs:
- slack/approval-notification:
executor:
name: slack/alpine
resource_class: large
message: Pending approval
webhook: webhook
リソースクラスとは
リソースクラスとは 名前の通り、実行環境のリソースを定義するものです。
何だか、CIでのビルド時間が長くなってきたな、という場合などに使用します。 実は、20CPU, 40GB RAMまで拡張することが可能だったりします。 (ただ、お財布はオートスケーリング出来ないので注意して使いましょう)
Orb Source
最後に、Orb Sourceですが、これは名前の通り、Orbのソースコードになります。 内部で何を実装しているか、詳細を知りたい時に使用します。
ドキュメントが少ない時に使用すると便利です。 ここら辺も他の言語のライブラリーなどと同じですね。
ただ、Orbの場合、あまりコードが長くなることが少ないので、全部読んでもそこまで時間は掛からないです。
因みに、何だか、ぐちゃっとしてて読みにくいなぁ、という印象を受けられるかと思いますが、 これは、CirlceCIのOrbをファイル分割して実装しても、レジストリーに公開する時にBundleする必要があるためです。
そのため、大規模なOrbの場合は、Githubレポジトリーを探して読むと良いです。 (そう、Gitレポジトリーへのリンクを定義出来ないのです。対応してくださいCircleCIさん >_<)
後、実は非常に役立つタイミングとしてはオリジナルのOrbを実装する時に、どんな実装方法をすると良いのかの参考になります (案外、地道に書いているな、ということも多いですが)
実装する
お気付きかと思いますが、ドキュメントが読めれば、 後はただ自分が使いたいOrbを複数持ってきて、自分好みに実装していくだけです!
良いOrbライフを!
最後に
キャディでは、このOrbを自分たちで実装して、最適なフローを組織全体に即座に展開できるようにしています。
実は、この記事では、そうした独自Orbの実装方法や展開・運用までを書こうと思って書き始めたのですが、 書き始めるとあっという間に膨張してしまったので、一旦、こちらで終えて次の記事に書きたいと思います。
キャディでは、言語や設計で最新のやり方を取り入れているだけでなく、インフラ領域においても積極的に新しい取り組みを行っております。 絶賛SREポジションでも募集中ですので、少しでも興味を持った方は、お話に聞きに来て頂ければ幸いです!