DevOpsのための道具箱: 自動化のためのツール – 「若手エンジニアのためのDevOps入門」(11)
こんにちは、山本和道です。
本記事は連載「若手エンジニアのためのDevOps入門」の第11回です。
| 第1回 | インフラエンジニアにとってのDevOps |
|---|---|
| 第2回 | Webアプリでの開発環境構築 |
| 第3回 | バージョン管理システム |
| 第4回 | 継続的インテグレーション/デリバリー |
| 第5回 | DevOpsのための道具箱: APIを使いこなす |
| 第6回 | リリース/構成管理: 概要 |
| 第7回 | リリース/構成管理: Terraform編 |
| 第8回 | リリース/構成管理: Ansible/Packer編 |
| 第9回 | リリース/構成管理: サンプルアプリによるCI/CD環境構築実践 |
| 第10回 | モニタリング/フィードバック |
| 第11回 | DevOpsのための道具箱: 自動化のためのツール |
前回はモニタリング/フィードバックについて扱いました。
今回はDevOpsプロセス間を繋ぐための便利なツールとして各種連携ツールやチャットボットについて扱います。
自動化のための連携ツール
DevOpsはこれまでの記事で扱ってきたように複数のプロセスから構成されます。プロセスを運用しだすと手動で行うと大変なために自動化を進めたくなる部分が出てきます。GitHubにプルリクエストが作成されたらCIサーバでテストを行い、成功したらステージング環境にデプロイといった、何らかのアクションを契機とする後続プロセスのための環境構築や任意のコマンドの実行、関係者への通知などです。
プロセス間を繋ぐための自動化を行う際にGitHubとTravisCI間をWebhookで繋ぐというように利用するツール/サービス側で密に連携できる場合は良いですが、そうでない場合は別途自動化のための連携ツールを利用したり、ある程度自分でスクリプトやプログラムを書いたりするなどの対応が必要になります。
今回は自動化のための連携ツールの例としてIFTTTを取り上げます。
連携ツール IFTTT(イフト)
IFTTTとは様々なアプリケーションを連携させるためのサービスです。
例として、以下のような連携を行うことが可能です。
- GitHubにイシューが投稿されたら担当者へSMSで通知
- 特定のEmailアドレス宛てに問い合わせメールを受信したらSlackへ通知
- Webhookを受信したらGitHubにイシューを投稿
IFTTTを利用するとプログラムを作成せずともWeb画面上からの操作で簡単に各アプリケーションを連携させることが可能です。
管理画面などは英語のみ対応ですがドキュメントは充実しており、あまり迷うことなく手軽に試せるようになっています。
IFTTT以外の連携サービス
類似のサービスとしてはMicrosoft FlowやmyThings、Zapierといったものもあります。
どのサービスもプログラムを作成せずとも各種連携処理を行うことができますので、要件に合致する場合は手軽に利用できると思います。
連携サービスの使い所
連携サービスでは何らかのイベントを受けてSlackやメールなどへ通知するという機能が充実しており、担当者へ通知して何らかのアクションを促すといった場合に対しては力を発揮すると思います。
対して、受け取ったデータを柔軟に加工するといったことや、パラメータに応じた条件分岐、複数の処理をつなげて処理をするというような部分は若干面倒であったり非対応であったりということがあります。
この場合はLogic Apps(Microsoft Azure)といったより高度な設定ができるサービスを利用したり、スクリプトや自作プログラムなどを利用したりすることになります。スクリプトや自作プログラムを動かすためには別途Webサーバなどが必要になることもありますが、Google App Scriptのようなスクリプト実行環境を提供してくれるサービスもありますので、それぞれのサービスで出来ることなどを加味した上で行いたい処理に応じた適切な方法を選択してください。
チャットアプリケーションとの統合
IFTTTなどの連携ツールで対応しきれない場合は自分でスクリプトやプログラムを書くといった対応が必要になります。コマンドラインから簡単に使えるようにCLIを作成したり、簡易的な管理UIを備えたWebアプリケーションを作成したりするといった方法もありますが、Slackなどの普段使い慣れたチャットアプリケーションを拡張するという方法もあります。
例えばアプリケーションのリリース作業をSlack上で稼働するBotに行わせることで、Slackの利用者であれば誰でも別途ツールをインストールすることなくリリース作業が行えるようになるといった利点があります。
当記事では例としてSlackを拡張する方法を扱います。
Slackを拡張する方法
アプリを利用する
まず、Slackには「アプリ」と呼ばれるSlackを拡張するための仕組みが用意されています。
Slackヘルプセンター: ワークスペースにアプリを追加する
様々な分野のアプリが存在し、当連載で取り上げたGitHubやTravisCIなども対応アプリが用意されています。例えばGitHubアプリであれば特定のリポジトリに対してイシューやプルリクエストの投稿、コードのコミットなどが行われた際にSlackに通知するような機能が利用できます。
アプリは「Slack App ディレクトリ」のページから一覧の表示/検索が行えますので、Slackを拡張したい場合はまずその機能がアプリとして提供されていないかを調べてみましょう。
WebHook/APIを利用する
アプリが提供されていない場合でもWebHookやAPIを利用して拡張することが可能です。例として以下のようなAPIが利用可能です。
・Incoming webhooks
提供されるエンドポイントに対してHTTPリクエストを行うことでメッセージの送信を行うことが出来る仕組み。
・Bot users
ユーザーと対話するためのBotを作成するための仕組み。
BotはWeb APIやEvents API、RTM APIなどのAPIを利用してメッセージの送信やユーザーとの対話機能などを実装出来る。
・Slash commands
ユーザーがスラッシュ(/)で始まるコマンドを入力した際に実行するコマンドを作成出来る仕組み。
例えば前述のGitHubアプリではイシューを投稿するための「/github open」といったコマンドが利用できます。
各APIの詳細については以下のAPIドキュメントを参照してください。
APIを利用したBotの例
Slack APIを利用したBotの例として、さくらのクラウド ユーザーコミュニティ「sacloud」にて利用しているBotを紹介します。
sacloudではGitHub/TravisCIを利用して開発やテスト、リリースを行なっています。リリース時にBotを利用してリリースするバージョンの決定やリリース処理の起動などを行なっています。
この例では行なっていませんが、TravisCIで動作確認用のステージング環境を用意したら、テスト担当者へ動作確認用のURLを送信したり、動作確認後はBotに応答することでそのままリリース作業依頼が行えるようにしたりする仕組みを作ることも可能です。
なお、この例のBotについては雛形となるソースコードをGitHubにて公開しています。
GitHub: sacloud/slack-bot-template
カスタマイズして利用できるような形になっていますので、Bot作成の際はぜひご利用ください。
API/Botがもたらす効果
先ほどの例ではSlackを介してDevOpsのプロセス間を結ぶことで、本番環境へのデプロイといった作業の敷居を下げ、カジュアルに実行できるようにしています。プロセスをまたがる処理がカジュアルに実行できることで、テストやリリースといった各プロセスが特別なものではない日常的な作業として実施できるようになり、結果として各プロセスの実行頻度を上げることが可能となります。
テストやリリースが頻繁に行えるということは「ソフトウェアの品質を確保しつつ迅速/頻繁にリリースを行うことで、フィードバックを取り入れニーズに即したアプリケーションを提供し続ける」ことにつながる、DevOpsへの取り組みそのものと言えます。
とはいえ、APIを利用する場合はある程度スクリプトやプログラムコードを書くことや、Botを利用するのであればBotを動かすための環境構築なども必要となりますのでその分のコストはかかります。IFTTTなどの他の連携方法も含めて検討した上でBotを作成すべきか判断するようにしましょう。
まとめ
今回は自動化のための連携ツールとしてIFTTTなどの連携サービスやSlackなどのチャットアプリケーションとBotの利用について扱いました。
DevOpsに取り組む上でプロセス間を円滑に繋ぐことはプロセス全体の速度や質を向上させるための強力な武器となります。連携サービスであれば手軽に使い始められますし、多少の開発や環境構築が必要になるものの、Botを作成することでより柔軟な対応が可能となりますので、DevOpsに取り組む際はぜひこれらのツールを使いこなせるようにしておきましょう。
当記事で「若手エンジニアのためのDevOps入門」連載は完結となります。
この連載ではDevOpsの各プロセスでどのような活動を行うのか、各プロセスにどういったツールが存在するのかという紹介を行いました。連載第1回でも触れましたが、DevOpsに取り組む最終的な目的はツールの導入ではなく、DevOpsの各プロセスを導入することで「ニーズに即したアプリケーションを提供し続ける」ことになります。
単純にツールの使い方を追うのではなく、紹介したツールを起点としてDevOpsの各プロセスの全体像を掴み、皆様の所属する組織に合致した形でDevOpsに取り組んでみていただければと思っております。
ここまでお読みいただきありがとうございました。