#HashiCode #1 HashiCorp 道場に入門してきました
今週も秋葉原のクリエーションラインさんのオフィスにお邪魔してきました。*1
今回は「HashiCorp道場〜入門編〜」ということで、HashiCorp 製品ラインナップの Overview と各製品の機能概要、既存の同種のツールとの比較について講演がありました。
HashiCorp 製品はいろいろと記事を読んだりはしていたものの、Vagrant ぐらいしかまともに使ったことがありませんでした。
そんな私にとっては Vagrant も含めて各製品の情報をまとめて得られるという、とてもありがたいセミナーでした。
講師は @zembutsu さんでした。
発表資料は下のスライドです:
以下、講演内容のメモになります。
Tao of HashiCorp (HasihCorp道)
※今日も10分ほど遅刻しました。。
元ネタは本家サイトの The Tao of HashiCorp - HashiCorp のようです。
- Tao of HashiCorp
- HashiCorp製品の特徴
- Workflows, not Technologies
- Simple, Modular, Composable
- 個々の製品は1つの目的に特化
- unix哲学
- 学習コストが低い
- Communicating Sequential Processes
- Immutability
- Versioning through Codification
- コード化を通したバージョン管理
- Infrastructure as Code
- Automation through Codification
- システム化・自動化しやすい
- Resilient System
- 予想外の Input/Output に耐えられる
- リアルタイムに変化を検出して自動的に対応
- 高い信頼性
- Pragmatism - 実用主義
- 現在の手法を利用者に押し付けるものであってはいけない
HashiCorp Tools HashiWares
- それぞれの製品の役割を見ていく
- 製品の特徴軸
- 開発環境構築
- デプロイ・本番環境構築
- サービス運用
- 製品の特徴軸
- Vagrant
- Packer
- 複数環境に対応した仮想マシン・イメージ作成
- 生成作業をシンプル・自動化
- Atlas 用のイメージ Artifact を生成
- 利点
- 素早い環境構築と並列処理
- AWS だと Region ごとに手順を用意して環境構築しないといけない
- マルチ・プロバイダ対応
- 環境構築やテストと連携
- 素早い環境構築と並列処理
- ゴールデンイメージ作成・利用の流れ
- Packer がやること
- マシンイメージを元に仮想マシンを起動し、テンプレートを適用して、新イメージ作成
- AWS で新しい AMI を作成する流れ
- AMI => インスタンス => スナップショット => 新AMI
- AWS + Packer
- AMIから起動したインスタンスに packer を適用する
- DigitalOcean にも対応
- Packer 対応環境
- Builder: マシン・イメージ環境
- EC2, DigitalOcean, Docker, VirtualBox, VMware, ...
- Provisioner: イメージ内のプロビジョニング
- Ansible, Chef, ...
- Post Processor: 環境操作
- Builder: マシン・イメージ環境
- Terraform
- インフラ環境をコードとして管理
- クラウドの複雑な構成管理を自動化
- コードで管理するので正確・迅速な構築
- Atlas 上の Artifact を様々な環境にデプロイ
- 使い方
- .tf 設定ファイル
- terraform plan ... 実行前確認
- terraform apply ... 適用
- terraform show ... 適用結果の参照
- terraform destory ... 削除
- AWS, DigitalOcean に対応
- Provider:
- Provisioner
- Chef
- 他のツールとの比較
- Chef, Puppet
- Terraform は構成管理しない。あくまで構築のみ
- CloudFormation
- AWS 以外にも対応
- Chef, Puppet
- Q&A
- Serf
- 非中央集権型のクラスタ構成ツール
- メンバ管理
- parallel-ssh と Serf の違い
- 誰でも命令を実行できる
- イベントの情報をすぐに共有できる
- クラスタ内の障害検知
- ノード間で相互監視
- クラスタ構成 =>
serf agent --join=<別のノードのIP>
- メンバ管理系イベント
- member-join
- member-update
- member-failed
- ...
- カスタムイベント
- 任意のイベント発生時に何かの処理を実行
- Serf 対応環境
- 他のツールとの比較
- ZooKeeper, doozerd, etcd
- 同様の機能を提供するが、環境構築・運用が複雑になりがち
- 高い可用性や高度な機能をもつ
- Fabric
- Serf と同じように使えるがより高度な機能をもつ
- Consul
- Serf が扱えないサービスレイヤを監視、オーケストレーション
- ZooKeeper, doozerd, etcd
- Consul
- サービス監視
- Consulサーバ
- Consul Agent/Client
- サーバに情報を集約
- KVS
- Consul サーバは冗長構成
- master 1台、slave 複数台
- consul client
- 対応環境
- Linux, ...
- 他のツールとの比較
- ZooKeeper, doozerd, etcd
- 強い一貫性を持つ似たような基盤だが、監視の仕組みが異なる
- ZooKeeper, doozerd, etcd
- Q&A
- Consul Template
- Q&A
- Serf は Consul の内部でしか使われなくなるのでは?
- A) 残ると思う
- Consul を立てるほどもない環境なら、Serf で十分なこともあるだろう
- A) 残ると思う
- Serf は Consul の内部でしか使われなくなるのでは?
- Vault
- HashiCorp まとめ
- オーケストレーションを実現する HashiCorp ツール群
- 既存の業務フローを変えずに導入できる
- 個々のツールを単体で使うことも、組合せも可
Atlas
XaaS 的なサービス。
開発者と運用者が同じツールを使おうという思想
- みんなばらばらなツールを使ってる状況
- ATLAS を使えば ATLAS に統合される
- ATLAS の概念図
- Application Code
- ATLAS
- Build
- packer
- Artifact Registry
- Deployment
- terraform
- Build
- Application
- Vault はまだだけど、今後入りそう
- 開発・デプロイ・運用を1つのフローで提供
- 2014年発表、現在ベータ版として提供中
- 全ての機能を使う必要はない
- DEMO
- Q&A
- 環境が北米というのは日本から使う上ではデメリット
LT
- TIS 森元さん
- CloudConductor 作ってます
- CloudFormation みたいな
- AWS, OpenStack に環境構築できる
- TIS とあくしゅの提携
- 仮想データセンター構想
- 同じサーバがどこでも動く
- プレスリリース駆動開発w
- Docker 遅いよという記事を書いたら識者にボコボコにされた
- => リベンジ記事を書いた
- ストレージの使い方が大事のようだ
- => リベンジ記事を書いた
所感
HashiCorp 製品といえば @zembutsu さんという印象を持っていました。
てっきり業務の一環でいろいろ調査・検証されてるのだろうなーと思っていたのですが、ほとんどは趣味で追いかけてらっしゃるという言があり、そこにびっくりしました。
Packer あたりは成果物がイメージしやすく、試しやすい気がします。
Serf や Consul は、上手く使えればインフラの管理をする上で便利で強力なツールになりそうなので、どこかに適用できたらいいな、と思います。
おまけ
こんなの(↓)見つけちゃいました(笑)
昨日現実逃避で作ったネタスライドです。本日の前座で使いました。本編は改めてアップロードします。 / “Hashi collection koto ku tokyo 2015” http://t.co/tCkZPxo6rY
— 前佛 雅人 - Masahito Zembutsu (@zembutsu) 2015年5月27日