DevOps Days Tokyo 2017に行ってきました(2)
~Habitatの世界へようこそ~

IMG_6230

「DevOps Days Toyo 2017に行ってきました」は、リレー形式でレポートしています。
私がレポートするのは午後の英語セッションからChefのMichael DucyによるHabitatの紹介です。

午前中のKeynoteで登壇したAdam Jacob(ChefのCTO)もMichael Ducyもスケール(拡張性)についてはそんなに問題視しなくてもよい、という趣旨の話をしていました。

スケール(拡張性)が重要でない3つの理由
1. 拡張に関する問題まだ発生していないのでは?

2. まずプロダクトまたはサービスをリリースする。その後、拡張について問題となったときに初めて心配をしていけばよいのでは?(プロダクトアウト優先)

3. 改めて拡張について問題となったとき、マイクロサービスのアーキテクチャーだとより移行がしやすい(後で記述します)

マイクロサービスの開発では、アジャイルとCI/CD(Continuous Integration:継続的インテグレーション、Continuous Deployment:継続的デリバリ)ツールチェーンが必要となります。
また、IndeedのMatteo Taddeiも同様のことを推奨していますが、マイクロサービス開発にあたっては、クロスファンクション機能を持つチーム編成を推奨しています(違う部門からメンバーを募ることが理想的)。

Michaelが提示した「マイクロサービス」に求められる条件は以下4つです。

1. サービスのコンポーネント化
2. 情報単位のエンドポイント定義
3. 分散化
4. 自動化展開

Habitatの役割
さてここからはChefが提供しているHabitatを機能別にみていきたいと思います。Habitatはマイクロサービスの“移行時に”その威力を発揮します。

・従来のシステムはインフラの自動化とアプリケーションのデプロイメントを分離(Chef, Ansible, Puppetなど)

・アプリケーションはそれぞれ最小構成のOS(busybox)が含まれる。複数の機器に同時にインストールし、異なるカーネルを管理することができる

・複数のカーネルを相互接続し、コンポーネント間の通信を管理し、その通信は、Gossipプロトコルによる独自の実装を通じて実施される

・ソースコードの更新の結果として継続的なデプロイメントがデフォルトで実施されるようになる

これらのコンセプトについてAdamは数日で概念を完成させました。コンテナを使用する場合ですが、最初に必要となるすべての依存オブジェクトをインストールした上で、アプリケーションをインストールします。

これはたいていの場合、さまざまなシステム(例:Heat + Ansible)、時にはさまざまなユーザーによって実行されます。Habitatはアプリケーションの設定の中心となるものです。

開発者がアプリケーションに関連するそれぞれの依存するソフトを設定ファイルに書き込み、Habitatは最小構成のアプリケーションをサポートするコンテナを実行します。
また、継続的デリバリにおいて、同一プロセスでのコード管理を可能にします。

Habitatは(tarballのように)パッケージ管理をしてくれるソフトパッケージ管理をしてくれますが、その使い方をみてみると ”リバースコンテナ“ として概念化できるのです。

Adamの見解では、Chefは自動化のサイクルの手助けをしてくれるプロダクトです。

Adamはシステムアドミン(Ops)として自身のキャリアをスタートさせ、インフラの自動管理のためにChefを作り上げました。それから長い時間を経て、開発者(Dev)としてHabitatを世界へ発表することになったのです。

私もAdamと同様にHabitatの今後の可能性を考えると、それだけでわくわくします。

参考リンク: Why Habitat?

著者プロフィール
氏名:Ruiz-Delgado Álvaro(ルイズ・デルガド アルバロ)
伊藤忠テクノソリューションズ株式会社
研究員としてLTE標準化のための3GPP代表を務め、特にMIMO通信の分野で
数多くの特許を保有している。
2016年より伊藤忠テクノソリューションズで最新技術を駆使した
顧客支援を実施。OpenStackやCI/CDにかかわるコンサルティングを得意とする。
Pocket

コメント