Download as PDF, PPTX
![役割ベースの設計
• Chefを活用する場合、システムが提供する
サービスを役割で分け、レイヤを積み重ねる
ように設計するのが良いです。
!
• 『ベテランシステム管理者であれば、既にサー
バーをロールベースでスクリプト化している
はず』
- [翻訳] Dockerについてよくある勘違い(http://
techracho.bpsinc.jp/hachi8833/2014_06_16/17982) より
33](https://image.slidesharecdn.com/chef2014-140622013837-phpapp01/85/2014-Chef-Infrastructure-as-code-33-320.jpg)
More Related Content
![Aws OpsWorks [JAWSDAYS 2014 ACEに聞けトラック]](https://cdn.slidesharecdn.com/ss_thumbnails/awsopsworksoverview-140316224852-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![さくらのクラウドフォーメーション with Chef [XEgg session]](https://cdn.slidesharecdn.com/ss_thumbnails/xegg01-chef-140214221012-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to 2014年のChefとInfrastructure as code
![[LT] インフラの人がChefやServerspec(ほか)が Rubyだったおかげですこし プログラムをするようになった話](https://cdn.slidesharecdn.com/ss_thumbnails/kansai-ruby6local-150711080405-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
2014年のChefとInfrastructure as code
- 1. 2014年のChefと Infrastructure as code JTF2014(June 22 2014) @sawanoboly (HiganWoks LLC)
- 2. 運営組織 2 • 業務執行社員をつとめる合同会社 • アプリケーションのためのプラットフォーム構築/運 用自動化をテーマにした活動を担当 •http://opsrock.in 共同開発・運営 • Chefをはじめ、Infrastracture as Code 関連を主に取り扱うソリューションを提供 • 導入支援・トレーニングも
- 3. 本日のお話 • Chefをひと通り解説 • Chef本ベース+補足など ! •近頃のChef関連 Update • Chef-Zero, ChefDK, Chef-Metal.. • local_mode, local_template 3
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. Chefとは • 米Chef社(Chef Software,Inc.)が開発保守 する構成管理のフレームワーク • 旧社名Opscode • Infrastructure as codeの一部で利用 9
- 10. Infrastructure as code •背景に、APIコールでサーバインスタンスが 調達できる環境 • インフラを抽象化し、設計、実装といったプ ロセスをコードで管理しよう • テストなど、アプリ開発の優れた手法を取り 入れ • バージョン管理を行い、Githubなどでコー ドを中心にしたコミュニケーション 10
- 11. Chef社が提唱する10の原則のうち 構成管理ツールに求められる要素抜粋 • 拡張に対応しやすい • 変更や増強、改良が容易。 •再現できる • 環境の再生や複製は重要。 • 冪等性を持つ • 必要な時にだけ実行 • 収束性がある • 宣言し、その通りの状態へ。 11
- 12. Chefの基本機能 • ノード(サーバ)情報の収集 • 収集した情報の集約 •コンフィグレーション • Cookbook/Recipeにリソースを定義し、 収集したノード情報を元に状態を収束する • ほか、いわゆるプロビジョニング 12
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19. Chef-Serverの概要 • ノード情報の集約 • ポリシー配布のハブ •作業端末とノードの中間に位置 • 基本的にメタデータの保持 • 種類は2つ • Open Source Chef • Enterprise Chef 19
- 20.
- 21. Chef-Clientの一味 (Chef-Client, Chef-Solo, Chef- apply,Chef-Shell) 書籍:Chef活用ガイドより
- 22. Chef-Clientの役割 • Chef-Server(または任意のデータストア)への Node情報アップロード • Nodeの収束 •実行状況と結果のレポート ! • 意外と多機能なエージェントとして作られてい ます • サーバに色々入れるの嫌か、インスタンスのイ ンターフェースとして受け入れるかは自由 22
- 23. Chef-Clientの種類 • Chef-Client: 前項の全て •Chef-Shell: 対話式 • Cookbook開発やデバックに • Knifeによる一括更新 • Chef-Apply: 簡易実行 • Chef-Solo: 主にプロビジョナ用途 • handler等の活用で、Chef-Server環境に劣 らない連携も可能 23
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30. Infrastructure as code 導入のキモWorkstatonとリポジトリ 30 引用：Infrastructureas Code - naoyaのはてなダイアリー <http://d.hatena.ne.jp/naoya/20131215/1387090668>
- 31. Seach Data Bags Environment Role Cookbook &LWRP 書籍:Chef活用ガイドより 書籍:Chef活用ガイドより 書籍:Chef活用ガイドより
- 32.
- 33. 役割ベースの設計 • Chefを活用する場合、システムが提供する サービスを役割で分け、レイヤを積み重ねる ように設計するのが良いです。 ! • 『ベテランシステム管理者であれば、既にサー バーをロールベースでスクリプト化している はず』 -[翻訳] Dockerについてよくある勘違い(http:// techracho.bpsinc.jp/hachi8833/2014_06_16/17982) より 33
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40. 2014年のChef傾向 • Chef-Server構成 • 検証しやすさを向上 •Chef-Client系 • 単体でもServer相当機能 • 極シンプルな実行をサポート • WorkStation系 • セットアップ負担の軽減をめざす • ? Infrastructure as code推進系 • リソース定義の概念を広げる 40
- 41.
- 42. Chef-Zeroの特徴 • Chef-Server APIのCRUDを全てサポート •ただし認証は全部通る • オンメモリでデータの永続性は無い • 消しやすさ = テスト向き 42
- 43. Chef-Zeroの活用 • Test-KitchenでChef-Server対応Cookbook の動作確認に • Vagrantのchef-clientプロビジョナと組み合 わせてクラスタ向けCookbookの動作確認 •vagrant-pluginもあるがやや環境依存 • 専用VMを当てるかローカルで上げ下げす るのが無難 43
- 44.
- 45. Chef-DKとは • ChefのCookbook開発とServer管理ツール 一式をパッケージ形式にしたもの。 • 新規:chefコマンド • Mac OS X, Linux対応、Windowsは Coming Soon… • (現状)公式おすすめのワークフローを実践す るツールとの連携設定済み • Test-Kitchen, Barkshelf, Foodcritic等 45
- 46. で、DK使ったほうがいいの？ • 古参からするとあまり必要でないかも • Rubyプロジェクト管理手法がわかってい ればとくに •Chef系以外にもインテグレーションしたい ツールは沢山ある • チームで環境を えたい等にはよいのかも • あと、DKパッケージは妙にデカイ 46
- 47.
- 48. Local Mode • chef-client-z / knife -z • knife solo っぽい形態 • ローカルファイルシステムにあるChef-Repo を元にChef-Clientを実行 • nodes/以下に自分及び他nodeの情報を設置 して、Searchが可能 • knifeでServer環境と同一の操作体系 48
- 49.
- 50.
- 51.
- 52. Chefで扱うリソースの拡大 • 従来の一般的なChefリソース • 単一Node上の要素(file,service, package等) ! • Chef-Metalで扱うリソース • IaaS上のコンピュータリソース • 台数などの要素を状態管理 52
- 53. 補足:状態を持つリソースについて • recipe =単一ノードへの変更という概念はわか りやすさ優先のミスリード • 構造化されたデータを取得し、定義通りになるア クションを(主にRubyで)実行できるならば、なん でも管理対象 • LWRPでは以前から実践されている • コミュニティCookbook等では、LWRPとして 『リソース=クラスタ』という状態管理するも のも存在 • MongoDB, RabbitMQ, ElasticSerach等 53
- 54. Chef-Metalの対応 • 基本はコンピュータリソースの調達 (ノードの増減とレシピの適用) • vagrant •fog (マルチクラウド対応ライブラリ) • ec2, digitaloceanなどPublic IaaS • *Stackな Private IaaS • 国内ベンダ 『Sakura no Cloud』 54
- 55. fog補足 • fogの対象はコンピュート系リソース以外にも 及ぶ • ストレージ •Network • NameServiceなどなど ! • 複数クラウドを対象に可搬性のある CloudFormation (にするつもりかもしれない) 55
- 56.
- 57. 予備知識：Chef-Apply • Recipeを次の形式で実行 • 標準入力 •単一ファイル • 簡単な設定変更やバッチ処理に • Cookbookのお決まり事が不要 57
- 58.
- 59. local trueでの挙動は単純 • local=> false • erbテンプレートのサーチ対象 • レシピと同じCookbook • 任意Cookbook内のtemplates/ ! • local => true • 絶対パス • Chef-Applyがtemplateを気軽に扱えるように 59
- 60. 2014年のChef傾向まとめ • Chef-Server構成 • 検証しやすさを向上(Chef-Zero, Local Mode) • Chef-Client系 • 単体でもServer相当機能 (Local Mode) • 極シンプルな実行をサポート (Local Template) • WorkStation系 • セットアップ負担の軽減をめざす (Chef-DK) • ? Infrastructure as code推進系 • リソース定義の概念を広げる (Chef-Metal) 60
- 61.