「Ansibleではじめる自動化入門」に行ってきた！

今日（１２月８日）Ansibleではじめる自動化入門に行ってきた！
ので、その内容をメモメモ

---

■ごあいさつ　あにばんさん
　Ansibleはレッドハットが買ったよ

■はじめに
・今日いっぱいきた。まだはいりきれない人が・・
・今日のはビデオでとって、後日セミナー
・このセミナーは入門編

■注目の構成管理ツール　Ａｎｓｉｂｌｅのご紹介
・コミュニティにフォーカス
・Ａｎｓｉｂｌｅ昨年末に買収：この1年に色々
・物理的に実装→ソフトウェアで実装できる時代
　　：ＡＰＩが整備されているからこそ
　ＯＳ、ミドルウェア、クラウド環境を制御
・自己紹介
　　ふぇどらのコーディネーターしてたり・・
　　ＫＶＭの立ち上げに来た
・今年「Ａｎｓｉｂｌｅ徹底活用ガイド」という本が出た
　　ロール、プレイブック
　来年に分厚い本出る
・コレまでの課題
　　大規模サーバーの管理
　　監査証跡の問題：だれがログインしたときのルートなのか
　　権限委譲の難しさ
　　単体管理の限界
　　マルチプラットフォーム＆クラウド
　　管理が煩雑
　　構成変更の柔軟性
・Ａｎｓｉｂｌｅのラインナップ
　　Ａｎｓｉｂｌｅ　Ｔｏｗｅｒ
　　Ａｎｓｉｂｌｅ　Ｃｏｒｅ：オープンソースのところ
　　→単体でなく、一部製品のインストーラー（これはサポートされない）
・Ａｎｓｉｂｌｅ
　プロビジョニング
　オーケストレーション：ＯＳ管理、仮想化、アプリ、ロードバランサ
　構成管理：Ｃｈｅｆ，ｐａｐｐｅｔ（Ｒｅｄｈａｔの標準だった）
　→いまはＰａｐｐｅｔもいいけど、Ａｎｓｉｂｌｅ使おう
　　バッチファイルをＡｎｓｉｂｌｅに置き換え
　　ソフトウェアのインすとレーション
　　構成変更、ファイル転送
・３つの特徴
　　シンプル
　　　全部テキスト、プレイブック何度実行しても同じ
　　パワフル
　　　たくさんの対象部に操作可能
　　エージェントレス
　　　通信エージェント仕込まなくていい
　　　ＳＳＨ，Windows Remote マネジメントを使って

・どのように動くのか
　　インベントリー：テキスト（/etc/hostsファイルみたいなもの）
　　モジュール
・管理対象
　　サーバー
　　ネットワークを強化
　　クラウド：ＡＷＳをはじめ様々（日本に上陸してないものも）
・エージェントレス
　　都度都度プログラムを送っている
　　Ｐｙｔｈｏｎで実行
・ＹＡＭＬ形式とは
　　設定ファイル、ログファイルに一般的に使われる形式
　　プレイブック：いわゆるバッチファイル
　→人間が読みやすい、コンピューターもパージングしやすい
　　プログラミング言語ではない
　　ＤｅｖＯｐｓ：よみやすく、かきやすい
　　Ｃｈｅｆ：Ｒｕｂｙ　Ｐａｐｐｅｔ：Ｐａｐｐｅｔ言語
・Ｐｌａｙｂｏｏｋ
　　Ｈｅｌｌｏ　Ｗｏｒｌｄ：デバッグで文字列出る
　ｈｔｔｐｄ　Ｐｌａｙｂｏｏｋ
　　うしろでyumコマンドを打っている

・インベントリとは
　　グループ定義：ホスト名かＩＰアドレス
　タスク
　　定型化された処理を列挙（プログラミングではない）
　　bashでも書くことが出来る

・モジュール
　　タスクにひもづいて定義
　　クラウド、コンテナも制御できる

・クラウドプロビジョニング
　　ハイブリッドクラウドでも
　　パブリッククラウドは、まず契約してね！
　　くーばねいてぃす、OpenShift
　　dockerの制御にも対応

・playbook記述方法例
　　変数定義が出来る vars
　　　→文字列を埋め込みたいときなど：テスト系、プロダクション系で切り分けたいとき
　　条件分岐：redhat系とdebian系で分ける
　　ループ実行：プログラミングになるので使いたくない
　　　withシーケンス：１、２、３、４、５・・・と創ってくれる
　　テンプレート
　　　変数を埋め込める

・ＤｅｖＯｐｓを実現するＡｎｓｉｂｌｅ

・最新版とロードマップ
　最新版：Ａｎｓｉｂｌｅ　Ｃｏｒｅ　２．２
　　Ｒｅｄｓｈｉｆｔ，らむだも
　Ａｎｓｉｂｌｅ　Ｃｏｒｅ　２．３
　　Ｐｙｔｈｏｎ３対応
　　Windows サーバー２０１６（管理対象）
　　Ａｃｔｉｖｅ　Ｄｉｒｅｃｔｏｒｙ
　　Ａｚｕｒｅスタック
　　ＡＷＳ：２要素認証
　　→２月、３月、４月？春くらいには出る？

Ｑ＆Ａ
　ＡＰＩをもっていたら、ＡＰＩ操作
　ＳＳＨ：実行して
　Windows：リモートマネジメントで操作（Ｐｙｔｈｏｎプログラムは送らない）

ギャラクシー
　アップロードすると、使える：Ｒｅｄｈａｔで運用
　Ａｎｓｉｂｌｅ　ギャラクシーをオンプレで

■SIerからみたAnsibleの構築・運用への活用　ＴＩＳ
・自己紹介
・自動化してますか
・何のために自動化するのか
　　効率化
　　大量生産
　　品質向上
・自動化すると、楽になる：余裕が生まれる　Time is money
　　単位あたりの仕事量が問題
　→時間を大切にする

・お伝えする内容
　　ユーザー目線のＡｎｓｉｂｌｅの活用
　　エンタープライズでのＡｎｓｉｂｌｅの活用

・ユーザー（私）目線のＡｎｓｉｂｌｅの活用
　検証環境
　デモンストレーション
　ハンズオン

・検証環境
　　物理マシン、仮想マシン、コンテナ
　デモンストレーション
　　製品紹介
　　成果発表
　　イベント等
　Windowsの上でubuntuが動く
　ハンズオンの環境：セキュリティで難しい
　　　ブラウザでできる→文句出る：割り込み入る
　クラウドを用いたハンズオン環境自動化

・システムインテグレーター
　　顧客要求分析
　　システム提案
　　システム開発・構築
　　保守運用
　　サービス提供

・テスト：手作業→とらぶる
　ＯＳからミドルウェアの自動構築とテスト
　　インフラのコード化
　　ツールの実装
　　推奨・テンプレート化
　Ｅｘｃｅｌファイルでパラメータシート（パラシー）を創って・・・
　　→yamlに自動変換
　　エビデンスをまたＥｘｃｅｌに戻す
　　ＳＨＩＦＴ

　保守・運用への適用
　　従来の職人技の排除
　　　簡略化
　　　最適化
　　　共通化
　　強みのメニュー化による変革
　　　作業の簡素化
　　　提案段階

　ギャラクシーの話

　保守・運用の活用一例
　　システム情報取得の自動化
　　　ファイルを取得
　　　コマンド実行してから取得

・まとめ
（１）時間を大切に：自動化の本質
（２）Ａｎｓｉｂｌｅが一番。まちがいない
　　Ｃｈｅｆ：Ｒｕｂｙ知っている人に好まれる
（３）構築の自動化、運用保守の自動化
　　空いた時間で、インプット

■Ansible Tower By RedHat
・自動化運用とＡｎｓｉｂｌｅ　Ｔｏｗｅｒ
　既存のビジネス課題
　　管理対象増加→管理者増やせない→ヒューマンエラー
　→自動化
　これまでの自動化
　　自動化ツール：言語を使って　学習コスト高い・属人化
　Ａｎｓｉｂｌｅ
　　簡単に使うことが出来る
　　　Playbookがシンプル（エラー処理不要）
　　　上から下に実行
　Ａｎｓｉｂｌｅ　ｃｏｒｅ
　　　エンジン
　　　管理者がＰｌａｙｂｏｏｋに起こす
　統一された自動化プラットフォームの重要性
　　Ａｎｓｉｂｌｅ　Ｃｏｒｅサーバーを複数立ち上げ、実行してしまうＸ
　　　→統一重要、ナレッジ標準化重要
　Ａｎｓｉｂｌｅ　Ｃｏｒｅで不足する機能
　　ログの保存機能
　　見やすいツール
　　組織内の協調オーサ：セキュリティの担保
　　マルチテナント
・Ａｎｓｉｂｌｅ　Ｔｏｗｅｒ
　　ナレッジ共有と固有情報の管理
　　Ｐｌａｙｂｏｏｋ：バージョン管理
　　　Ｅｘｃｅｌの管理Ｘ
　　　ＰｌａｙｂｏｏｋはテキストＸ
　　→バージョン管理ソフトの中に入れて管理
　　　　ジョブテンプレートとＴｏｗｅｒではいう

　協調作業と情報共有：ＳＬＭ（サービスレベル管理）

・Ａｎｓｉｂｌｅ　Ｔｏｗｅｒ
　ＲｅｄＨａｔが販売。ことし、５～６月から
　　３ヶ月で２００社増えた。いまは１０００社超えている？
　画面と機能
　　ログイン認証
　　スケジューリング実行、アドホック実行
　　ＧＵＩ
　playbookをgitで管理

・便利な機能
　　スキャンジョブ
　　システムトラッキング：ステータスの比較など
　　アクティビティストリーム：履歴・変更など
　　ＲＥＳＴ　ＡＰＩ：自動実行
　　パスワード管理
　　その他
　　　サーベイ機能

・でも
　Ｇｉｔレポジトリとの連携
　いつ実行するのか
　実行
　ＡＰＩ

・Ａｎｓｉｂｌｅ　Ｔｏｗｅｒのサポート
　Ｃｏｒｅのみのサポートはしていない
　Ｔｏｗｅｒからの操作のみ
　モジュール：
　　コアモジュール
　　エキストラモジュール：公開されている　ベストエフォート
　　そうでないモジュール

・Ｃｏｒｅは管理者一人から、Ｔｏｗｅｒは複数人でも

・でも
　インストール前と後の比較

・宣伝
　これから、いろんなものと連携
　Ｒｅｄｈａｔ　Ｉｎｓｉｇｈｔ

・Q&A
　１０人までは、Tower無料？→機能制限がある

PCでIoTをやる場合の問題点－なぜ、みんな大好きRaspberry Pi？

昨日の

RaspberryPiは量産に向かないことが分かった時点がIoTの幻滅期のはじまりかな？
http://blog.goo.ne.jp/xmldtp/e/4357009ba2c2ca4588d96aa1deb8c904


のはじまり、「なぜ、Raspberry Piを使うの」について、

逆に、「なぜPCではいけないの？」を書いておかないと、
Raspberry Pi陣営から文句でそうなだけでなく、
「みんな大好きRaspberry Pi」の理由も分からないし、
「GPIO端子があるので、マイコンや通信モジュールと接続しやすい」
の意味が通じないので、ちょっとかいてみる。

---

まず、PCにいきなりセンサーをつけるのはむずかしい。
PCにI2CやSPIの端子はない。UARTはできるけど、（シリアルで）センサーと
直接つなぐには（GPIOみたいなのはないので）USBに直接つながるセンサーに
限られる。

なので、PCを使った場合、無線を使うか、LANを使うか、GWをおくかになる。

無線を使う場合、Wifiだと、２．４GHｚ、５GHｚ同時に使っても６０箇所くらい？
なので、１００を越える箇所の接続は難しい。
２．４GHｚ帯の場合、ZigBeeかBLEになるし、
サブギガでWi-SUN,EnOcean,LoRaを使うことになる。

ここでXBeeを使えば、USB経由で（XBeeはUSBドングルが売っているので）
ZigBee、BLEの通信が出来る。
ただし、この場合、センサー側もRFモジュールが必要になり、
センサーが数百もあると、コスト面で問題。

LANはPC側は問題ないけど、センサー側でLANに直すことになり、そのための
チップが必要で、やっぱり、端末数が多くなると、コスト的に問題。

GWを置き、有線でというのは、現実的な回答なんだけど、ではそのGWを
何で作る？という問題が起こる。ちなみに、GWを一番簡単に作れるのが
Raspberry Piだ。

---

ここまでを、まとめると、

「なぜPCではいけないの？」は、以下のことから、PCにセンサーをつなげるのは
コストまで考えると、Raspberry Piよりも不利

・PCにいきなりセンサーをつけるのはUSBのセンサー以外、むずかしい
　　→センサーの多くは、USBの口はない（UARTはあるが、端子があるだけ）

・無線やLANを使う場合、センサー側も対応する必要があり、そのコストが大きい
　　→数百台以上のセンサーに通信モジュールをつけるコストはばかにならない

・GWをおく場合、結局、そのGWは、なんでつくるの？という問題がのこる。

ここで「みんな大好きRaspberry　Pi」

・有線でやるなら、RS485。これなら、
　　　センサー＋
　　　マイコン（PICなら１００円から）＋
　　　RS485トランシーバー（ＳＮ７５１７６ＢＰなら秋月で６０円）
　で、センサー１拠点はできるので、安上がり。

・これを受けるのは、Raspberry　Piなら、GPIOピンがあるので、RS485なら
　　RS485トランシーバー（ＳＮ７５１７６ＢＰなら秋月で６０円）の
　　　　DE,REピンをGPIOのどこかに
　　　　DをGPIOのTXに
　　　　RをGPIOのRXに
　接続してくれれば、/dev/ttyAMA0（今は/dev/S0かな？）に読み書きすることで、
　簡単に送受信できる（もちろん、DE,REピンを制御してね！）
　そして、そのデータを、インターネットに流せばよい。
　ここまでの処理をPythonで簡単に出来る・・・ので、

「みんな大好きRaspberry Pi」

---

ふぉ～ながかった。上記を一言でまとめると、

「GPIO端子があるので、マイコンや通信モジュールと接続しやすい」

になるんです（＾＾；）

　ただ、続きがあって、べつに、Raspberry Piじゃなくても、今

イーサネット-UARTコンバーター
http://www.microtechnica-shop.jp/shopdetail/000000000011/

って、売ってるから、これにRS485トランシーバーつければ、よくね？
というのは・・・し～っ、だまってろ（＾＾；；；）