- 経緯
- Kindle Unlimited について
- 凡例
- 本の概要
- 章ごとの詳細・要点など
- 感想・まとめ (影響: この本を読んで変わったことを書こう)
- 試してみよう(実践のコーナー)
- この読書記事で
- 実践
- 所要時間
- ファイナル感想
経緯
- Ansibleをなんとなくで書いてきたので、知らない書き方があるような気がしていた
- この本は何度か見かけていたし、他の方の読書ブログで「初心者から上級者まで」と書かれていたので、その知りたいところが書かれてそうな感じがした
Kindle Unlimited について
- この本や、評価の高いソ連の興味深い解説本もUnlimitedの対象
- いい本が対象になってそう
- 自分は一度も無料体験や2ヶ月300円を使ったことがない
- Amazonのこの手の無料体験はしばらくするとまた使えるようになると聞いた覚えがあるので調べる
- なお通常価格は月額980円
- 大体、3ヶ月～1年経つと無料が復活していることが多いらしい
- 今回のキャンペーンだと、1ヶ月無料を使うと、2ヶ月99円が使えなかった (後者を選べばよかった)
凡例
- 文末や文頭の数字はページ番号
本の概要
- book.impress.co.jp
- 2019年9月の本
- Ansible も CentOSマークも Red Hat の商標
- アプリケーションデプロイメントの自動化とかも書いてあるよ
- 第4章からが実践的な内容 (全8章)
- Ansible 2.8
書評 (全部読んだ結果)
- 自分の用途では使わなさそうなことについて書かれたページがそれなりにあったかも。
- 使いそうなことが書かれたところを重点的に読むといいかも
- 1～4章、5-1、7章 はみんな使いそう。(残りの3割は人を選ぶかも)
- まだAnsibleを導入してない組織だと、一線級のAnsibleを導入できて素晴らしい書だと思う
- Ansibleを導入済みの組織でなんとなくAnsibleを読み書きしていた自分にとっては…
- 「知らないことがありそう感」「雰囲気でAnsibleをやっている感」はなくなった (Ansibleのことは一通り知ってるはず感)
- 「知らない書き方」は少しあった感 (↓の◎などを付けたところ)
章ごとの詳細・要点など
はじめに
- 6 Windows Serverの構成もAnsibleでできるのね
第一章 概要
1-1 Ansibleをとりまく背景
- 13 (1-1 環境、1-1-1 アジリティを追求)
- Ansibleの前の世界はChefだと思うけど、その前は構築ドキュメントという認識… だけど、Chefの前もなにかあったのかな？(Make？)
- 14
- 構成管理には2種類あるらしい (この後のページに詳しく書かれてそう)
- サービスの最適化のための構成管理
- 構築自動化のための構成管理 (Ansibleはこっち)
- ビジネスのために俊敏になりましょう
- DevOpsもこのためにあるのです
- 構成管理には2種類あるらしい (この後のページに詳しく書かれてそう)
- 15
- やはりChefの前は構築ドキュメントだったらしい
- いまでは保守期限が切れるまで長期的に使わないこともよくある (オンプレでなければ確かにそうっぽい)
- オンプレだと今でも結構長期に使うような…？
- 昔は投資対効果の効率を重視していたのだ。でも、最近は柔軟に変化できることが大事になったのだ(と書かれてると予想)
- インフラリソースの頻繁な変更が必要になったので手作業は無理だね
- 現在の構成情報を取得するのも構成管理ツールの大事な役割
- 16
- ITサービスの最適化のための構成管理には、構成管理データベース(CMDB)というものがあるらしい (本書の範囲外っぽい)
- 自社にどんな機材があるか？とか、どんなソフトのどのバージョンをどの機材で使ってるか？とか？
- ITサービスの最適化のための構成管理には、構成管理データベース(CMDB)というものがあるらしい (本書の範囲外っぽい)
- 17
- ここでのDevOpsの定義
- 「組織文化とツールの両面をKAIZENしてアジリティUP、リスクDOWN」
- 組織文化のところでDevさんとOpsさんが仲良くしそう (意識改革)
- 表面的には流行りのツールを導入して行われる事が多いらしい
- ここでのDevOpsの定義
- 18
- 19 (1-1-2 IaC)
- 「繰り返し可能なビルドやテスト」.
- Ansibleで構成のテストもできるっぽい。楽しみ (dry-runして差分が出ないかとか…？)
- CI環境を自動で構築して、アプリケーションのテストが通るかな？っぽい(？)
- 「繰り返し可能なビルドやテスト」.
- 20
- IaCは自動化だけでなく、CIできるようになるというメリットもある
- 21,22
- プロビジョニングには 3つあるよ
- オーケストレーション
- (アプリケーションデプロイ)
- 作ったものを連携させてサービスを提供
- Capistranoなど
- システムの構成管理 (システム設定)
- Ansibleは標準的にはこのレイヤを担当(拡張可能)
- ブートストラッピング(マシンイメージやクラウドリソース立てたり、OS入れたり)
- Terraform, Dockerなど
- オーケストレーション
- プロビジョニングには 3つあるよ
- 23
- 徐々に自動化させていこう
- (4)までの段階があるが、本来の目的はビジネスのアジリティアップ (縦割りでもそこで評価はできそう)
- (感想) やっぱり、規模が小さかったりすると、規模が大きいものとは最適解が違うよね
1-2 Ansibleとは
- 24
- 25 (1-2-1 特徴)
- Ansibleのおかげで世界的にアジリティが上がった
- 26
- 28
- Ansibleは適用範囲が広い
- 全体の構成管理を冪等性を保ちながらできる (すごい)
- AWSやDockerのモジュールもあります
- モジュールを使うとAnsibleコードの品質が均一になるね
- 必要な処理が既に用意されてるから簡単に書けるね
- 29
- 冪等性管理を各モジュールで実装しています
- だから、各モジュールの中身は外見よりファットなのだろう(羽沢の推測)
- 冪等性管理を各モジュールで実装しています
- 30 (1-2-2 Ansibleを利用する際の注意点)
- 31 (1-2-3 他の構成管理ツールとの比較)
- 35
- Puppet:2005, Chef:2009, Ansible:2012
- manifest, recipe, playbook
- Chefは難しいけど複雑な処理を書けるので、熟練メンバーしかいなければいいかも (と読めた)
- Puppet:2005, Chef:2009, Ansible:2012
- 35 (Ansibleのプロダクト)
- 37 (1-2-5 Ansibleのユースケース)
- Kubernetes環境も構築できるよ (4章)
- Windowsの設定も俺に任せろー (5章)
- AWSやDockerやVagrantのブートストラップもできる (6章)
2章 Ansibleの基礎
2-1 アーキテクチャについて
- 40 (2-1 アーキテクチャ) (2-1-1 基本動作)
- Ansibleの仕組みを把握しよう
- (感想)さすがにこのあたりは知っていることだった
- 41
- 42 (2-1-2 内部コンポーネント)
- AnsibleコアエンジンにいろいろなPlugin(接続やログ吐きなどなどを担う)を付け加えて動かす仕組み
- 43
- モジュールを作る時は、冪等性の担保と再利用可能にして、属人化してないモジュールをつくろう
- 44
- RedHat が保守するモジュール(コア部分)と 認定モジュール(認定ベンダーが保守する)、コミュニティモジュールがあるよ
- 45
- モジュールカテゴリの表
- Cloud, Cluster(Kubernetesなど), Commands, Crypto, Database, Files, Inventory, Messaging(RabbitMQなど), Monitoring, Net Tools, Network(A10とか), Notification, Packaging, Sourcec ontrol, Storage, System, Utilities, Web Infrastructure(Apacheなど), Windows, Identity, Remote Management
- 46
- 47 プラグイン色々
vars:
local_home: "{{ lookup('env', 'HOME') }}"
とすると、 {{ local_home }} にコントロールノードの $HOMEが使える感じ (ファイルコピーに便利)
- 47
- Callback Plugin で実行おわったら通知とか
- Cache Plugin でターゲットノードの情報(ファクト)をキャッシュしたり
- Vars Plugin は host_vars や group_vars がその仲間らしい (詳しくは3章で)
- jijja2のフィルタが使える(文字列とか変数を加工するやつ)
- 50 便利なコマンド
- ansible-{config,console,doc,garaxy,inventory,pull,vault}
- 便利な(？)コンソールがある
- manみたいなのが実はある (ansible-doc)
- inventoryで対象ノードをらくらく一覧
- pull型の実装も実はできる
- ansible-{config,console,doc,garaxy,inventory,pull,vault}
2-2 インストール
- 50 (2-2 インストール) (2-2-1 準備)
- (感想) 構成管理情報のデータベースは「こういう機材があって、そのIPアドレスは何番で、何がインストールされている」情報が入ってるのだろうなあ
- Ansibleは途中のバージョンを飛び越して別バージョンへ移行可能とのこと
- 51
- Ansibleを使う機材の要件について
- Windowsマシンはコントロールノードにできない (ので自分はWSLでもやってる…非推奨だったかも)
- /usr/bin/python3 に pythonがあるLinuxディストリビューションでは、 ansible_python_interpreter で そこを指定しようね
- 52
- ターゲットノードでは /usr/bin/python がデフォルトで使われるので、Python2にデフォルトではなる。ansible_python_interpreter で変更可能
- 本書は Ansible 2.8の話。コントロールノード、ターゲットノードはCentOS7 (64bit)
- 53 Ansibleのインストール方法の種類
- 54 (2-2-2 インストール実施)
virtualenv env_name #作成, source env_name/bin/activate #有効化 deactivate #無効化 通常環境に戻る
- 57
- pipを使ったAnsibleインストール方法(コマンド)が書かれている
- python36u{,-libs,-devel,-pip} が必要
- 重要なコマンドは pip3.6 install ansible==2.8.4
- ソースコードからインストール編
- pipを使ったAnsibleインストール方法(コマンド)が書かれている
2-3 動作確認 (簡単に実行してみる)
- 58 (2-3 動作確認) (2-3-1 事前準備)
- 59 Ansible実行ユーザ
- 特権ユーザでやるより、Ansible実行専用ユーザを創って、必要な権限だけ割り振るのがオススメ
- 59 ssh公開鍵認証
- 60 作業ディレクトリ
- Ansibleのディレクトリ構造は複数流派があるのだった(記憶)
- 61 ansible.cfg
- $HOME/.ansible.cfg がオススメ。コマンド実行者ごとに変えれるので
- forks(昔使った) 並列数
- デフォルト5なので、大抵15くらいに増やす
- host_key_checking
- フィンガープリントチェックしない false がオススメとのこと
- gathering ターゲットノードの詳細情報をいつ何回取得するか
- デフォルト implicit (毎回集める)なので、 初回だけ集める smart がオススメとのこと
- 62 (2-3-2 コマンド実行してみる)(ansibleコマンド)
- 63
- ansibleコマンドのモジュールのオプション(アーギュメントオプション)は -a ですね (知ってた)
- -a 'path=jHOME/test.txt state=touch mode=0644' みたく指定する
- 複数のターゲットノードに対して一度にオペレーションできるのでオススメ (僕もたまにやろうとしていました)
- ansibleコマンドのモジュールのオプション(アーギュメントオプション)は -a ですね (知ってた)
- 64
- sudoが要る時は -b -Kをつけましょう(知らなかった) (プレイブックの become: yes はよく使ってた …というか先頭に書いてた)
- 64 (ここから ansible-playbookコマンド使ってみようのコーナー)
- recap : 要約 (一般的な英単語)
- PLAYを複数に分けることもできるらしい (自分ではやったことない。他の人のでは確かに2,3に別れてることあったかも)
- ansibleコマンドはansible-playbookと違って、出力が詳細だよ (ansible-playbookにもverboseオプションあった記憶)
- 68 (2-4 Ansibleの基礎 まとめ)
- シンプルにコード化し、メンバが共通の認識を持てる のが自動化の第一歩 とのこと
3章 プレイブックとインベントリ
- 69 動的インベントリのやり方とか知りたいね
3-1 インベントリの基礎
- 70 (3-1-1 ホストのグループ化)
- デフォルトインベントリは /etc/ansible/hosts
- (知識)でも大抵 -i で指定する
- グループには階層をつけることも可能 (使ってた)
- [group_name:children] 的な この下に 子グループの名前を書く
- 192.168.101.[1:5] みたいに連番を指定できる。 [a:d] もあり。
- {yamada,tanaka,satou} はないのかな？
- デフォルトインベントリは /etc/ansible/hosts
- 71
- グループ階層が複雑になると大変だから、チームで階層ルールをつくろうね
- 全ターゲットノードは勝手に [all] に属する
- ダイナミックインベントリは6章にて
- ホストパターン指定では正規表現も使える (お得情報)
- なので、インベントリはグループを複雑にせず、ターゲットノード候補をAnsibleに伝えるのを優先して、ホストパターンで絞り込むのがオススメ とのこと
- 72 (3-1-2 ホスト変数とグループ変数)
- インベントリ変数 (意識したことない感)
- グループ変数は知ってたし使ってた 4.5min
- ホスト変数は使うと複雑になるからできれば避けよう とのこと
- 別途インベントリ変数用ファイルを用意する(よくみる)
- インベントリ変数 (意識したことない感)
- 73
- ターゲットノードに ansible_host 変数で名前をつけたりできるよ 5.5min
- 74 (3-1-3) インベントリ変数のファイル分割 8min
- インベントリファイルは(この例では)INIだから複雑に書きにくいということもあるよ 8.5min
- (感想) まぁ、 細かい各ノードの情報は別ファイルにまとまってた方が一個一個が小さくなって見やすいね ９分
- 指定ディレクトリに指定名でファイルをおいてね
- group_vars/group_name.yml or group_vars/group_name/sukina_namae.yml
- group_vars/all.yml はよく使われるもの
- hostは上のgroup_nameがhost_name になったかたち
- group_vars/group_name.yml or group_vars/group_name/sukina_namae.yml
- インベントリファイルは(この例では)INIだから複雑に書きにくいということもあるよ 8.5min
3-2 プレイブックの基礎
- 76 13.5m (3-2-1 YAMLの基礎)
- 77
- Ansibleは PyYAML を利用していて libyaml を使用していて YAML 1.1の書式に対応 (大事そう) 18m
- 範囲指定コメントはないよ
- 78
- 80 スカラー値 25m
- |- で始めると、複数行文字列。 - は最後の改行をなしにする。 > なら 改行がスペースになる (1行になる) (お得情報)
- 81 真偽値で判定すると true = yes = on = 1, false = no = off = 0 。大文字も可能。 30m
- モジュールのアーギュメントには yes/no その他は true/false が一般的 とのこと
- 81 (3-2-2 プレイブックの構造)
- プレイブックはTargesセクションとTasksセクションでできている― 補助的に handlers セクションと vars セクションがある (handlersは一回だけみたことがあるかも)
- targets セクションごとに play は分割される
- 82
- playbook は ディレクティブを書ける場所が決まってるから誰が書いても同じ構成になるのだ (規約)
- 範囲としては プレイ、ロール、タスク、ブロックがある (多分この後説明があるのだろう)
- 83 Targets セクション 35m
- hosts: には
でも指定できるよ。 "*-yamada-db" とか - ansibleコマンドのホスト指定でも使えるよ 40.5m
- YAMLのルールで、 * を文字として普通に使うにはダブルクォーテーションが必要 2m
- hosts: には
- 85 3m
- yum とか template がモジュール(タスクに1つ)で、他の name とかはAnsibleのディレクティブ
- 86 4.5m
- ansible-doc module_name を活用しよう
- Handlers は notify: に書いたnameのタスクを、taskがchangedになったときだけ実行させる(感想 タスクの仲間っぽい)
- 87 6.5m
- notify: "Reload Web contents" みたいに文字列を指定して、 それをhandlers が listen することもできる (複数のハンドラに同じ文字列をlistenさせられる)
- 88 9m
- 89 10m
- 90 12m (3-2-3 変数)
- 91 13m
- play単位の変数。play vars 通常のvars, task vars, role vars
- Host単位の変数、inventory vars, host facts, registered vars 戻り値
- 定義済み変数(Magic Variables グループ名とか)
- 92 15.5m
- 特殊なよく使う変数に vars: proxy_env: http_proxy: http://proxy.hoge.local:8080 があるよ
- vars_file や vars_prompt と違って vars はタスク、ロール、ブロックで使える
- 93 18m
- debug: var: var_name でらくらく変数表示
- 94 20m
- changed とか はよく使われるレジスタ変数 rc とかも
- 95 21m
- ansible コマンドの -m setup で 事前に ansible_facts を見れるよ
- gathering_facts するのでデフォルトでファクト変数を使える
- 96 22m
- Local Facts を作って入れ込むこともできる。 /etc/ansible/facts.d (変更可能)に .fact ファイル (オススメはしない)
- 97 24m
- ルールを作って仲良く変数をりようしよう
- 98 25m
- jinja2の説明
- 99 26m
- {{ yamada.taro.age }} , {{ yamada['taro']["age"] }}
- 100 27.5m
- 文字列は {{ hensuu_mei[0:5] }} で5文字目まで読めるよ
- 101 28.5m
- if と for をよく使うとのこと
- フィルタもあるよ
- default, join, length, lower, upper
- 102 29.5m
- 103 30m
- 変数の優先順位 (よく見ていた表)
- 104 30.5m
- ロールの中の変数は優先順位が低いからデフォルト値的に使えるよ。とはいえ、変数名かぶらないようにできるといい とのこと
- 104 (3-2-4 特殊なディレクティブ)
- when とか
- 105 32.5m
- when: ansiblem os_family == 'RedHat' みたいな
- 106 33.5m
- changed_when を使うと shell モジュールでも本当に変わった時を指定できるよ。failed_when もある
- 107 35.5m
- ignore_errors: true
- loop は Ansible 2.5 以降使えるようになった。 with_items は古い、推奨は loop
- 108 37m
- loop: -yamada -saitou - nakata を モジュールのアーギュメントとしてつける。もちろんシーケンス変数でいいよ。呼び出しは {{ item }}
- loop は with_items 的ではなく with_list 的 (後述)
- 109 39m
- product フィルタというのがすごい
- loop: "{{ db_info[0]|product(db_info[1])|list }}" で {{ item[1] }} で nameを参照できるようになる、みたいな
- |list を つけると シーケンスになる
- product フィルタというのがすごい
- 41m
- 110 2m
- loop control というものがある(初耳)。 loop を強化する
- 使いすぎはわかりにくくなる
- 秒単位でループをコントロールしてたりできる(すごい) pause
- loop control というものがある(初耳)。 loop を強化する
- 111 4m
- 112 5m
- with_items, with_list からの移行。公式ドキュ麺とがあるよ
- loop は with_list 相当らしい
- with_items は シーケンスが展開される [1, 2], 3 は ３回になる…ので、loopにするときは注意
- (自分ごと)新規にはloop が良いとは思うが、既存の with_items はそのままでいいんじゃないかな
- ルールを決めてどっちを使うか考えよう
- 113 6.5m (3-2-5 タスクのグループカ)
- block。when や tag をつけられるよ
- 前のチームでは、わざわざ別のタスクファイルにして include に tag を付けてしまっていたけど、これなら同じファイルでタグを付けれるんだなぁ
- 114 9m
- block の中にモジュール(タスク)をかいていくだけ。一層 block の層が増えるだけ
- rescue や always もあるよ
- でも 個別のタスクのエラーハンドリングには failed_when がオススメ とのこと
- 115 11m
- Ansible Workshops というサイトにたくさんお手本があるよ。 Ansible Red Hat Enterprise Linux Workshop, Ansible Network Automation Workshop (ルータやスイッチなど)
3-3 プレイブックの応用
- 116 12m (3-3-1 ロール)
- プレイブックを分割しよう
- 会社でもよく使ってますね
- main.yml が固定で読み込まれる
- 117 13.5m
- defaults/main.yml という デフォルト変数を指定すんこともできる。
- 優先順位が一番低いのでデフォルト値として使いやすい
- handlersもあるよ。notify: restart mysql みたいに書いて呼び出すやつ
- meta/main.yml というロールの依存関係を書くこともできる
- 先にコッチのroleッ実行してね、って感じのをかける
- あとロール情報や、この環境じゃないと動かないよとか
- でも、プレイブックで依存関係順にロールを呼び出す方がsinnpuルでわかりやすくてオススメとのこと
- vars ロール変数のこと
- defaults/main.yml という デフォルト変数を指定すんこともできる。
- 118 15m
- tasksは必須
- 119 16.5m
- 120 18.5m
- 121 20m
- 複雑にするのはサケましょうね(属人化排除、共有のため)
- 122 21m
- metaを使うよりプレイブックでwhenとか変数定義がいいよ
- 122 (3-3-2 プレイブックの活用)
- 123 23m
- タスクなどの実行順が書かれている
- pre_tasks, post_tasks はレイヤをまたぐ yum update とかに便利
- 124 24m
- {import,include}_{tasks,vars,roles} があるよ
- import: 最初にpythonコードにする時に読む(静的)
- --start-at-taskや tags= で読み込み先のを使うにはこっちじゃないとダメ
- include: playbook実行中に読む(動的)。 loopと組み合わせ可能
- notify で呼び出せない
- 125 25.5m
- include は将来なくなるみたいなので、 include_xxx にしていこう (前のチームで多用していた) import_xxxでもいいよ
- 126 28m
- 127 29.5m
- 依存関係は最小限に抑えよう
- 少しずつ実行しながらプレイブックを作るといいよ (エラーの範囲が限定されるので)
- debugモジュールやPlaybook Debugger オススメ とのこと
- 128 31m
- Ansible標準モジュールに取り込んでもらわなくていいなら、実はモジュールはどんな言語でも作れる
- でもモジュール作りは大変なのた、標準モジュール利用がオススメ
4章 アプリケーションデプロイメント (オーケストレーション)
4-1 WordPressのデプロイメント
- 129 32.5m
- ここから実践的内容
- WordPressの例
- 130 33m (4-1-1 基本構成の説明)
- 実はAnsibleはPHPやデータベースをインストールするインストーラもある(今回つかわない)
- ロードバランサもあるよ
- LBニ台、App Server 3大、DB 3台の大規模サイト
- HAProxyャ Keepalivedもあるよ
- 131 35m
- ロードバランサが HAProxyと Keepalived : Virtual IPを提供する)
- 132 37m
- 最初に Virtual IP を決めましょうね
- inventory.ini に db1i ansible_host=192.168.10.31 みたいにかけるよ
- lb1i と lb1e みたいに外と内をインベントリとしてそれぞれ定義してる
- 外側IPと内側IP
- 133 39.5m
- プレイブック構成
- OS -> database -> app -> app用LBの順
- サーバは database -> app -> lb の順につくっていくよ
- 41m
- 134 2m
- 135 3.5m
- roles/example/tasks/check_install.yml みたいに分けて、分割しようね (tasks/main.yml が肥大化すると読みにくいので)
- 大体、 check_install (事前タスク)、 install, configure の３つに分かれるとのこと
- 136 5.5m (4-1-2 OSの基本設定)
- OS設定を common role に書いてるよ
- 137 6.5m
- 138 8m
- 138 4-1-3 データベース構築
- 139 11m
- Keepalived で VIP を3台でつかいまわすぞ
- 140 12.5m
- 141 13m
- include は廃止予定。include_tasks を使おう
- 全13タスク
- 142 14.5m
- 143 17.5m.
- yum: state: absent でいらないパッケージをけすぞ
- OSでデフォルトではいってるパッケージッあると、バージョン指定インストールに邪魔なので
- 頻繁に変えないなら、バージョン番号はハードコードが自己少ないかもね
- 144 20m
- 145 21.5m
- 146 23m
- {%- for -%} {%- endfor -%} にすると、改行コードをなくして一行で出力できるよ
- 147 24.5m
- LOCK ファイルの有無で、パスワード設定ずみかどうかを判別するテクニック
- 148 26m
- 149 27m (4-1-4 ロードバランサ)
- vars/{app,db}_cluster.yml と、varsファイルッわけて、両方でroleを使い回せるようにするとスマート
- 150 28.5m
- cluster_service という変数を使っっ、節損先がどっちかみわけよう
- 151 29.5m
- tasks/main.yml のセントとで include_vars して、 必要な方の vars ファイルを読み込もう (動的な変数読み込み)
- 152 30.5m
- 153 31.5m
- 大体のミドルウエアでは、タスクより設定ファイルテンプレ作りがメインの作業になる
- 154 32.5m
- haproxy_backend_groups: databases と指定して、データベースグループへの接続を指定できる(？)
- 155 34m
- 156 34.5m
- 157 35m
- echo "show stat" | sudo socat stdio /var/run/haproxy.sock をして起動確認しよう
- http://192.168.10.31:10080/ にブラウザアクセスして haproxy haproxy で管理画面というか統計画面もみれる HAProxy
- 158 37.5m
- keepalived_target: "{{ groups['databases'] }}" と指定して、分散するものを変数で指定している
- 159 38.5m
- KeepAlivedのインストール&設定
- 160 39m
- Keepalivedを使うには、 firewalld で VRRPを許可必要。そのためにRich Rules をオンにしないといけない
- IPフォワーディングも要るよ
- 40.5m
- 161 0.5m
- 162 2m
- keepalived の設定とか
- 163 2.5m
- jinja2 の loop.index は便利。 他にも6種類くらい主要なのがアる
- keepalived の優先順位をつけたり、サーバに固有のIDをつけるのに便利
- 164 4m
- Rsyslog は startswith で keepalived か判別できるぞ。(keepalivedのログを管理したい)
- 165 6m
- local_action ディレクティブを使うと、コントロールノードからの確認を記述できる
- 166 7m (4-1-5 実行環境 appサーバ)
- nginxから (nginxユーザでいろいろ動かすから)
- 167 8m
- チューニング用設定数値も vars に切っておくといい
- 168 9m
- wait_for モジュールが起動確認に便利
- やはりだいたいのrollは firewalldポート解放からはじまる
- 169 10m
- WordPressがmariaDBに接続できるように MySQL-python パッケージをyumでいれてる
- 170 12m
- 4ステップで設定され軌道するnginx 。 設定配置、Vhost設定配置、軌道、起動確認
- 起動確認はwait_for: host: "{{ adoresu }}" port: "{{ pooto }}" delay: 3 timeout: 60 みたいな感じでできる☆
- 変数の不透明性とジュウナンせいのトレードオフは気をつけよう (変数は直接見えないが、変更しやすい)
- 171 14m
- 172 14.5m
- 173 16.5m
- 174 17m
- 175 18m
- 176 20m
- 177 20.5m
- 177 4-1-6 WordPress
- 178 22m
- 179 22m
- CentOSのminimal ではgit がないのでいれる
- 180 23m
- git でとってくる (clone を git モジュールでやる)
- バージョンを指定しないとmaster (開発最新版)になるので注意
- 181 24m
- 182 25.5m
- 便利な mysql_db モジュールがあるよ (データベースを作成できる)☆
- 183 27m
- delegate_to ディレクティブを使うと、別のサーバに処理をしてもらえる。そのサーバにしか必要な権限もち ユーザがいないとかのときに。☆
- 184 28.5m 4-1-7 接続確認
- 185 29.5m
4-2 WordPress のメンテナンス
- 186 30.0m
- Ansibleはメンテ、保守にも使えるよ
- データベースバックアップとかアプリケーション更新とか、パッチ適用とか、SSL証明書更新とか
- 実行がはやい 属人化もなくなる
- 弊社でもSREチームなどなどやってそう というかアプリケーションのチームでもやってるところはやってそう
- 4-2-1 スケールアウト
- いい感じにAnsibleッ書いたので、インベントリファイルを追加するだけでサーバを増やせるのだ
- 187 33m
- 188 33.5m
- -t haproxy の作業は、 -l lb1i とか1台ずつやると影響が警備でいいよ
- 終わっっラhaproxy の統計画面で確認しましょう
- 再利用できるPlaybook を目指しましょう
- 188 4-2-2 ローリングアップデート
- 1代ずつ更新して、無停止を目指そう
- 189 35m
- 190 37m
- これまでの wordpress_deploy.yml では ターゲットノードを並列にあつかっちゃうっので新規playbook
- serial: 1 (おなじみ)
- 191 39m
- max fail_percentage を指定すると、ナン％のノートが失敗したら、ぜんたいの実行止めるができる (0だと、ちょっとでも失敗したら全体が止まる)
- serial: -1 -5 -"20%" みたいに、 三段階での実行もできる (すごい) (がそんなに実用性なさそう)
- 40.5m
- 192 0m
- haproxy モジュールで メンテナンスモードにしよう
- 193 2m
- 194 2.5m
5章 システムの構成管理(OS)
- 195 6.5m
5-1 Linux の構成管理
- 196 8m
- Ansibleのモジュール利用だと、ディストリビューションのち外を吸収できることも多い
- lineinfile や replace , blockinlineモジュールの多用はやめようね
- 設定を変えるためのモジュールがあればそれを使おう user, cron, mount, hostname モジュールなど
- nmcli timedatectl localectl コマンドをcommand モジュールで使うのが次善の策。その次は template, copy, synchronize モジュールで設定ファイルをコントロールノードから配る。
- 197 10m 5-1-1 作るものの構成の説明
- 198 12.5m
- やはりインベントリファイルに server1 ansible_host=192.168.20.11 みたいなIPを書くと便利だね ☆
- 199 13.5m
- NW設定を変えた後に reboot モジュールを使うと、接続を保ったまま reboot できて超便利
- 200 14.5m
- Ansibleには async(指定した秒数は待つ) や poll (タスク終了監視)ディレクティブがあるよ
- デフォルトでは300秒でssh切れるからこれらを使おう ◎
- async: 1000 poll: 0 register:yum_sleeper みたいに指定する (始めたら、すぐ次の処理に進んで、最大1000秒まつ)
- 最後にちゃんと終わったか register の中身をチェックシましょう async_status: jid "{{ yum_sleeper.ansible_job_id }}" register: job_result until: job_result.finished retries: 30 みたいにしてチェックできる
- ただ、チームで話し合いをしたところ、そんなに急ぐシーンはなさそう、となった。(変に複雑になりそう) (本の中でもコラムに出てきただけで、実践的なプレイブックの中にはでてこなかった)
- 201 19m 5-1-2 ロケール処理
- 設定保証のテストにもなるよ
- 202 19.5m
- ロケールの場所は、ノードによって変える可能性高いので、デフォルト変数(一番ゆうせんど低い)でデフォルトを指定するととてもいいね
- roles/common/locale/defaults/main.yml に書くとロールのデフォルト変数になる (vars よりだいぶ優先度が低い)
- 203 21.5m
- 中には CentOSで使えない Ansible モジュールがあるけど、手元で動かしてみて動いたらOK (超がんばれ)
- モジュール使えなかったら command モジュールでコマンド実行する localectl とかで
- 204 23m 5-1-3 パッケージ管理
- 1つのロールで複数のディストリビューション対応をここで示してもらえてる
- roles/common/packages/vars/{Debian,RedHat}.yml を include_vars で読み込む (include_vars で読み込むので、vars/main.yml はいらない)
- 205 26m
- 206 27m
- グループ変数にどっちのOSか書けることもアるね
- 207 29m 5-1-4 ゆーざ管理
- templates/{admin,member}_sudoers.js でsudoer できるものをカえてる
- 208 31m
- vars に user02: detail: "donna yuuzaa" pass: groups: priv: admin みたいなのをかいてる
- dict2item というフィルタでディクショナリ形式(マッピング形式)を展開デキる
- group, user, authorized_key といった専用モジュールがあるので便利
- 209 33m
- 210 33.5m
- password_hash() フィルタを使うと、パスワードをテンプレとかの上でハッシュ化できるよ
- まぁだいたいは ansible-vault を使う
- lookup プラグインでコントロールノードのファイルを参照できるよ
- /etc/sudoers.d/ の↓にファイルをおくことで、本体のsudoers 設定ッ傷つけずにせっていしましょう
- template: モジュールのvalidate: 'visudo -c -f %s' をするとバリデートできてとてもよい ☆
- %s に更新したファイルが入るとのこと。いろんなファイルモジュールにこのバリデートkinouがある ☆☆
- sudoers に限らず、プロセスの設定ファイルを更新したら、プロセスの構文チェックを入れてvalidateしておくととてもいいぞ ☆
- 211 38m
- 権限ごとにsudoers ファイルをわけると保守しやすい
- 211 5-1-5 ネットワーク管理
- CentOS7 では ifcfg-eth* ファイルではなく、NetworkManager でのNW動的設定になった ◎
- nmcli コマンドである ☆☆
- 40m
- 212 0m
- NWの設定内容をgroup_vars と host_vars で管理しよう
- 213 1.5m
- group_vars/linux_servers.yml に共通設定を描く感じ
- 214 2.5m
- 215 3m
- nmcli モジュールを使いましょう (いろいろなディストリビューション対応)
- 216 3.5m
- nmcli モジュールは冪等性の担保が弱い。ので、既に接続プロファイルがあったらwhen でskipしたりする
- 最後に systemd モジュールで再起動しようね
- 217 5m 5-1-6 リゾルバ管理
- 218 6m
- 219 6.5m
- hostname モジュールで永続的にホスト名を設定しよう
- 220 8m
- ☆ hosts ファイルを jinja2 の for で構成している 便利そう
- 221 9m 5-1-7 タスクの実行と確認
- 確認コマンドもプレイブック化して、イテレーションテストと同時に実行できると最高
5-2 Windowsの構成管理
- 223 10m
- 223 5-2-1 概要
- PowerShell オブジェクト嗜好コマンドライン方式シェルスクリプト言語
- これにより Windowsの構成管理自動化が進んだとのこと
- Windows Management Instrumentation 設定情報とかを取得できる
- PowerShell オブジェクト嗜好コマンドライン方式シェルスクリプト言語
- 224 13m
- 225 15.5m 5-2-2 事前準備
- 226 16m
- どのWindowsバージョンならAnsible使えるかの表
- 227 16.5m
- 228 17.5m
- 229 20m
- NWの設定の注意 Public にしようとか
- 230 20m
- 自己署名状名所の有効期限とか
- 231 20.5m
- 232 21.5m
- 233 22.5m
- 234 23m 5-2-3 Windows 管理の実装
- 235 24.5m
- 236 26m
- 237 27m
- タスクスケジューラをtukaltutaりするので、リナックスより時間かかることも
- 238 28m
- Linuxでおなじみのモジュールに win_がついてる感じ
- 239 28m
- 240 29m
- 241 29.5m
- win_regedit モジュールを使う
- 壊れやすいから(レジストリ内容の)バックアップをとってからやろうね
- 242 30.5m
- 243 32m 5-2-4 タスク実行と確認
- win_package というのもあるけど アンインストールが大変だったりする (ので win_chocolateyがよい)
- 244 33m
- 245 33.5m
5-3 ネットワーク機器の構成管理
- 246 34m
- ネットワーク機器もSSHでログインできるのでAnsibleできる
- エージェントインストール不要なので対応範囲が広い
- 5-3-1 ネットワークmozilyuーnnの特徴 モジュール
- 機器(プラットフォーム)ごとにモジュールがある
- 247 36m
- 248 37.5m
- 249 38.5m
- 250 39m
- commands: - show version の結果が result.stdout_lines[0] にはいるよ result.stdout[0] ニも入る
- 40m
- 251 0m
- 252 1m
- 253 1m
- 254 1.5m
- 255 2m
- もしNW機器をAnsibleで操作する時がきたらここらへんをみてAnsibleを描くと良いと思った
- 256 2.5m
- おすすめ接続方法など、おすすめのやり方がたくさん書かれている。NW機器のAnsibleに詳しい
- 257 3m
- 258 3.5m
- 259 3.5m
- 260 4m
- 261 4m
- NW機器のAnsibleでよくあるエラー集が書かれている
- 262 4.5m 5-3-2 NW機器情報取得の実装
- 263 5m
- NW機器に paramiko や ncclient をいれルのだ(コントロールノードに、かも。というかそうっぽい)
- 264 6m
- NW機器ごとに group を切ると便利
- 265 6.5m
- show_commands: - show system uptime みたいなのを group_vars に書いてやってる
- 266 7m
- 267 7.5m
- block: に when: ansible_network_os == "ios" みたいに指定して、それぞれの危機の処理を書いてる
- 268 8m
- 269 8.5m
- 30分おきとかに？機器の情報を取得してコントロールノードのファイルに保存すると状態監視が便利?みたいな？(1分おきとかかも)
- 270 9.5m
- 271 9.5m
- NW機器向けのAnsibleの詳しい例(コマン度を実行させる実践的な例)
- 272 10m
- 273 10.5m
- 274 11m
- 275 11m
- 実行してみて、コントロールノードに ログファイルができた とのこと
- 276 11.5m
- Juniper Junos 対応モジュールは Ansible標準モジュールとGalaxy モジュールがあるから混同に注意。どちらの情報かチェックすべし。 とのこと
- 276 5-3-3 NW機器設定変更の実装 13m
- NW機器上で NTP, SNMP, Syslog, User といった運用管理昨日を設定するぞ
- 277 14m
- 278 14.5m
- NW拠点ごとにグループ分けるかもね dc_a dc_b dc_c
- 279 15m
- 機器ごとにSNMP設定fulainn形式アンのでテンプレを書かれてる
- 280 16m
- 281 16m
- playbook ではやはり ios* とか junos* モジュールを使う
- 282 16.5m
- 283 17m
- 284 17m
- 285 17.5m
- 286 17.5m
- 287 18m
- 実行して変更できた様子
- 自動化したいものを対象に自動化するのが大事 (繰り返すもの 対象が多いもの 手動が不向きなもの) 効果的で安全なものを見極めよう
- 288 19m 5-4 まとめ
- みんなでAnsibleのコードを作ると楽だよ
- 自動化すると工数が減っていいね
- 289 20m
- 290 22m
- 291 23m
- 292 23m
6章 ブートストラッピング(インスタンスを建てたりする)
6-1 クラウドAPIの利用
6-2 Azureの連携
- 297 31m 6-2-1 AzureでのAnsible の利用
- プロビジョニング(構築)と構成管理(運用)ができる
- オートスケーリングにも構築自動化が書かせませんね
- 確認作業の自動化も大事
- 298 33m
- Azure Resource Manager からクラウドリソース情報をゲットしよう
- 299 34m 6-2-2 Azureに接続するぞ
- 認証情報(サービスプリンシパル)を設定します
- アプリケーションごとに権限を付与します
- 認証情報(サービスプリンシパル)を設定します
- 300 35.5m
- 301 36.5m
- 一度見た覚えがある az login コマンド
- 何度かみたことがある Microsoft のコードの入力画面
- 302 37m
- role (3種類)から適切なものを選ぼう Owner Contributor Reader
- 303 38.5m
- 認証方法3種類。クレデンシャルファイル、環境変数、モジュールのパラメータに定義 (後ろほど優先)
- 304 39.5m
- 41m
- 305 0.5m
- 306 1m 6-2-3 クラウドリソースのプロビジョニング
- 307 5m
- 308 7m
- 309 7.5m
- 仮想マシン作成では image を指定してる
- az account list-locations --query ".name" -o tsv でアカウントのロケーションリストをチェックできる
- 310 9.5m
- 311 11m
- 312 13.5m 6-2-4 クラウドリソースの構成管理 (運用自動化)
- テストも自動化しよう
- azure_rm*facts を使おう
- 313 15m
- ☆assert モジュールを使うとテストできる
- azure_rm_virtualmachine_facts: re... register: ansible01_confirm
- assert: that: - ansible01_confirm.vms[0].location == "japaneast" みたいな
- ダイナミックインベントリを活用しよう のコーナー
- 314 17m
- ansible_azure_rm.yml では、 名前にansible を含むhost みたいな指定ができる。いろんなこんな漢字のオプシションッある
- 仮想マシン情報とかを全部とると重いので、必要なものだけをとりましょう
- 315 19m
6-3 Docker と連携
- 316 20m 6-3-1 DockerでのAnsibleりよう
- Docker は軽量でいいぞ。ポータブル
- 手元、開発、本番、パブリッククラウドとどこにでも展開できるぞ
- 仮想マシンより軽いぞ
- こういう特徴があるのでアジリティ(開発速度的なもの)が高いのだ
- Dockerだけでコンテナいプロビジョニングは終わる
- Kubernetes などのコンテナオーケストレーションが主流
- ので、この節でAnsibleの役割を説明する とのこと
- 317 23m
- Ansibleの役割
- プロビジョニング自動化
- 稼働中コンテナへのデプロイや変更の自動化
- お言葉(囲みの中)
- 「Inmmutable Infrastructure は リソースを使い捨てと扱い、状態管理を常に行わない運用方法です」
- (共産圏でよくいろいろなところで貼ってそうな感じに書かれてる)
- 世の中ではステートレスなプロセスばかりじゃないとのこと
- データベースはアプリケーションからの接続状態を管理しないといけない とのこと
- こういうときに、状態管理もできるAnsibleが大活躍 するとのこと
- (理解) Ansibleの方が immutable より フクザツな(人間がやってるような)操作ができるのだろう ◎
- コンテナオーケストレーションツールの昨日だけでできるならソッチがおすすめとのこと
- 318 28m
- Ansible Container で プレイブックからコンテナビルドもできる(Ansible role だけで Docker Imageをつくれる)が、本書では扱わない(普通にDockerfileを書いてね)
- 今回も Docker Hub にアップロードしてあるコンテナをAnsibleで配置したりしますよ
- 318 6-3-2 Docker環境の事前準備
- 319 30m
- DockereEngine をインストールしたホストOS を用意しよう。yumでいれてる
- 320 32m
- 321 33m
- 322 36m
- 323 38m
- 接続情報の設定の仕方
- 324 39m
- 324 6-3-3 コンテナのプロビジョニング
- Docker Hub からコンテナイメージを取得したり、Dockerfileでイメージ作ったりするぞ。それを立ち上げたり
- 41.5m
- 325 0m
- AnsibleのDocker専用モジュール (docker_comose モジュールもあるよ)
- Docker Swarm (クラスタリングするやつ) 用モジュールもある。
- モジュールも移り変わりが激しいので適宜公式ドキュメントを確認してね
- 複数のDockerホストに対して命令がだせるAnsible
- 326 3.5m -ネットワークつくって、CentOS7イメージ取得して、NginxのDockerfile準備して、DockerBuild、Nginxコンテナ起動、Ansibleコンテナ起動
- 328 5.5m
- 329 6m
- 330 9m 6-3-4 コンテナの構成管理
- Immutable Infrastructureでは構成管理できない(毎回0からつくる)ので、ここがAnsibleの真骨頂だね
- Dockerfile化できない場合とか、常時かどうするコンテナからオペレーションしたい、とかのとき (従来のサーバに近い使い方の時)
- Docker Connection プラグイン
- 331 11.5m
- 332 14.5m
- ansible -i ./docker.py みたいに指定すると、インベントリファイルの代わりになる
- docker-compose をいれるト、docker.py に必要なものも入るらしい
- 名前空間の競合が起こってるので、このページでやってるようなことをしないといけないらしい (Python3.6で別途docker-composeのライブラリをインストール？)
- 構成管理もできるけど、フクザツにそれをやるとImmutable Infrastructureの概念から離れるのでほどほどにしましょう
- フクザツになるとツールの管理工数が増える
- コンテナオーケストレーションツールでできることはそっちでやるのがオススメ
- 333 18.5m
- 334 19m
- プレイブックのテスト実施
- Fail-Fast (DevOpsの概念の一つ) 早い段階でやってみてトライアンドエラー
- そのために、失敗できる作りになっているAnsible
- Ansibleは実施成功した地点で、タスクに定義した構築が行われたことが保証されてるので、ちゃんと行われたかのテスト不要。
- でも、パラメータミスとかはあるので、サービスが期待通りに提供されてるかのテストは要る
- 期待したコンテンツが帰ってくるかテストをデプロイメントのワークフローに組み込むのが大事◎
- それをプレイブックに組み込んでもいいね。wait_forやassertモジュールが役に立つ
- wait_for: port:80 host: "{{ inventory_hostname }}" delegate_to: localhost とか uri: url: ... return_content: yes delegate_to: localhost register: web_result - fail: msg: 'sippai' when "'hoge' not in web_result.content" みたいな
- テストプレイブックを流してもいいね。 CIに組み込もう
- テストスクリプトを実行するコンテナを用意して、プレイブックの最後に実行するとかもある
7章 Ansibleの徹底活用
- 335 25m
- 実践テクニック
7-1 プレイブックのベストプラクティス
- 336 26m
- 336 7-1-1 インベントリの分割
- [Webサーハ]とか[Database] とか以外の分け方もあるよ
- (inventoryファイル)production.ini [osaka] [db_servers]
- 337 29m
- 環境複製に適した構成の例 Ansibleの並列実行もできるよ
- 338 30m
- production.ini と staging.ini をわけて、そこで使われてる共通の grrup_varsを group_vars/web_servers.yml とか host_vars / jp-web01.yml にかく
- jp_webseversの上位グループで jp とか webservers とかがあると、それぞれで指定できていい
- [jp:children] [web_servers:children] の両方に同じグループを所属させることができる (production.ini に各)
- jpを指定したときにも、 web_serversのvarsも適用されるので注意(重複する名前つかえなくなる)
- 339 35m
- 340 35.5m
- 341 38m
- インベントリファイル(hosts) のあるのと同一階層のgroupvars とかが自動で読み込まれる
- 可読性は低くなる。小規模にはオススメできない
- 後からでもインベントリは簡単に分割できるので、まずは階層分けしないのがオススメ
- 341 7-1-2 プレイブックの分割
- 343 43.5m
- 小規模だと、playbookに直接タスクを各(roleを使わない)のがオススメ
- 344 45.5m
- 中規模はroleをtukaltuta標準的な構成がオススメ
- 345 46.5m
- deploy とか update とかやることベースで プレイブックを分割すると拡張しやすいよ
- 大規模では クラウドとか監視とかWebタービスの統合運用管理とか
- 運用作業もプレイブック化してみよう
- main.yml , site.yml という全体プレイブックだけでなく、部分playbookで include_role して、やりたいことだけできるプレイブックを作るといいね
- cluster_config.yml みたいなメインのを流す前に、config値だけを整えるプレイブックがあるといいよ どっかのノードだけ変わっていても元に戻せる
- 目指せ「プレイブック自体が環境を管理できる1つのコマンドみたいな動き」
- 347 50m
7-2 Ansible Galaxy
- 347 51.5m 7-2-1 検索
- 348 52m
- 349 52.5m
- 品質スコア(静的解析) と コミュニティスコアがついてるよ
- 350 53.5m 7-2-2 ロール管理
- 例えば、 nginxinc.nginx という、nginxサーバを立てるGalaxy Role があるよ
- 351 54.5m
7-3 パフォーマンスチューニング
- 351 56m
- 352 56.5m 7-3-1 ファクトキャッシュ
- gather_facts: false (高速)
- 353 57.5m
- 354 59m
- 355 59m 7-3-2 タスク並列処理
- ansible.cfgの [defaults] forks = 15
- デフォルトの5は少ない
- ストラテジプラグイン を使うと、タスク順序違いに対応できるぞ
- 60m
- ストラテジプラグインを使うと、通常(linear)ではタスクごとに全ノードを待つという挙動を変えられる
- host_pinned とか freeとか
- freeだとそれぞれのホストが勝手に進むので早い
- host_pinned は forksを無視する？釣果する？のでさらにはやい
- プレイブックの最初らへんに strategy: free とかくとできる
- 357 2.5m 7-3-3 SSHチューニング
- タスクはごとにSSH接続をデフォルトでは行うので遅い
- 多重接続とかパイプラインをつかうと早くなる 2.5min(150m)が 43秒にになる 。３倍の速さ。特に多重接続設定が聞く(150s->65s。2.5倍の速さかな )
- ansible.cfg に [ssh_connection] pipelining = True ssh_args = -o ControlMaster=auto と描くとこうなる
- autoでなくyesにしてしまうと、毎回マスターコネクション作ってしまいそうでダメそう(？)
- OpenSSHの多重接続機能は、最初にマスターコネクションをつくって、それをUnixドメインソケットにして、他の接続をそこにつなげる感じ
- 本来はTCPコネクション削減目的だが、新規にSSHしないので早い
- 358 6.5m
- OpenSSH 5.6以上だと、Ansibleで自動的に多重接続機能を利用する デフォルトで
- 359 9m
- 360 11m 7-3-4 パッケージインストールタスクの高速化
- 外部コンテンツの取得時間を短縮したい
- ローカルにミラーレポジトリを作ろう
- 会社にもあるね(過去形かも)
- こういうミラーレポジトリを作るのには reposync が便利(CentOS用？) cronで定期的に回す。createrepo したりする
- 361 13.5m
- 362 17m
7-4 プレイブックのデバッグ
- 363 18.5m 7-4-1 Playbookオプション
- プレイブックでエラーが出たら、ターゲットノードにsshとかでログインして、処理コマンドをまずは実行シテミルのがオススメ
- -v オプションはおすすめ vvv とか
- check diff limit list-hosts list-tags list-tasks start-at-task step 知ってる&活用してる
- 364 21m
- ANSIBLE_DEBUG=1 をこまんどの最初にツケると開発者用出刃っぐ表示になる
- 365 23m 7-4-2 console
- 特定のインベントリに対話的に実行できる
- 366 24.5m
- list hosts とか list groups でだして cd test_servers:!test101 で実行対象を絞る listで確認
- モジュール名とアーギュメント指定で実行するけど、存在しないモジュール名や!が戦闘についてたらシェルコマンド(というかshell モジュールのアーギュメントになる)になる
- tab キーで保管できる
- set_fact addr={{ hoge }} ファクト変数便利とのこと
- -v オプションもあるぞ
- 367 27m 7-4-3 実行ファイルの保存
- 368 29m 7-4-4 Playbook Debugger
- 31m
- 369 31.5m
- 370 33.5m
- task_vars['key'] や args['key'] を使いこなそう
7-5 暗号化
- 371 34.5m 7-5-1 Ansible Vault
- (自分のこと)自分は、各暗号の中身ごとにvaultするのが、どんな変数あるかgithub ↑で見れていいと思う
- ansible-vaultのオプション create decrypt encrypt encrypt_string edit rekey(Vaultパスワードを変更できる) view
- rekey はしらなかった
- 372 37m
- ここでは --ask-vault-pass がオススメされてる (別途パスワードを管理しなくてよいためとのこと)
- ふくすうのYAMLに対して個別のパスワードをつけられるよ VaultIDによって. --new-vault-id オプションをつかう
- 373 38.5m
- --new-vault-id=vaulta みたいに指定すると、 vaulta用のパスワードを設定できる。実行時は --vault-id vaulta@prompt 。vaulta の部分に何も入力しない(デフォルト的な運用)も可能。 prompt のところを ファイル名にすることも可能 (パスワード格納fulaiる) 権限はrだけじゃないとダメ(xがあるとダメ)
- 374 40m
- encrypt_stringで変数の中身だけを暗号できるよ (羽沢の好きな方法)
- 375 43m
- 値だけ暗号は、変数名がどこにあるかわかりやすく、とても便利な方法と著者の方も絶賛○
- 機密情報が少ない時は積極的に変数のみの暗号を使用してね とのこと
- 実行時の出力に機密情報を出力しない方法
- タスクに no_log: true をつければいい (プレイ全体につけることもできるが全部見えなくなって不便)
- 376 45m
- 45.5 m
8章 組織で自動化を実践
- 377 46m
- 自動化のための意識改革
- 業務プロセスを改善
- 作業全体のプロセスを改善しましょう
- (感想)自分の苦手なところだ
8-1 自動化2.0
- 378 47m 8-1-1 サイロ化した自動化からの脱却
- NoOpsは最終目標じゃないよ 完全自動化は
- どこを手作業にするか見極めよう
- こうした流れが「自動化2.0」
- 人ごとにノウハウが違うのが「サイロ化」 属人的
- インフラやさんだけでなく、アプリやサンャNWやさんも仮想マシン自動で作れるようになると組織効率アップ
- これがプロセスの自動化、自動化2.0です とのこと
- 379 50.5m
- 自動化1.0 では、それぞれの部署が独自自動化ツールで個別に自動化
- 自動化2.0では、依頼プロセス簡略化や、承認レビューの自動化もはかる 自動で通知が飛んだりすんのかな？
- コミュニケーションパスがでかいので、1つのVM払い出しに1,2週間かかる企業も多くあるとのこと
- 業務プロセスをセルフサービス化できるといいとのこと
- ログ取得や細かい権限管理が鍵
- 380 54m
- ボタン1つで承認できると承認の手間も減る とのこと
- 省力化を目指そう(自動化2.0)
- 380 8-1-2 自動化のセルフサービスポータル
- ジョブのスケジュールと集約
- ロールベースの権限管理
- 奪取ボードによる視覚化
- Red Hat Ansible Tower でこれらのことができる(これは商用商品)
- そのアップストリームプロビジェクトが Ansible Works (AWX) Project
- 381 57m
- Ansible Tower が プロビジョニング、設定、オーケストレーションのジョブ管理、権限管理、視覚化をしてくれる感じ(分かりやすい図)
- Ansible Tower がAnsibleを実行してサーバとかを整える
- 382 58.5m
8-2 Ansible Works (AWX) Project を導入
- 382 59m 8-2-1 アーキテクチャ
- 各コンポーネントがコンテナとして動くので、Kubernetesとかのオーケストレーション↑でも動く
- プレイブック実行もコンテナ ansible-runner からになった
- awx_{web,memcached,rabbitmq,task,postgres} といった5つのコンポーネントが協力してAWXP を提供している
- 61m
- 383 0m
- 5つコンテナが起動して連携する。web-memcached, rabbimq-task, postgres の3つの組
- 8-2-2 AWXのインストール
- Docker compose で AWXを建ててみよう (Kubernetesとかもあるよ)
- 384 2m
- 385 2m
- 386 2.5m
- ansible/awx.git をgit clone するよ
- 387 3m
- 388 4m
- 389 5m 8-2-3 基本オブジェクトを作ってみよう
- オブジェクトというのをAWX↑につくって、管理とかAnsibleの実行をするらしい
- 390 5.5m
- オブジェクトの種類: organization job jobtemplate permission project survey
- まずは組織 ユーザ 認証情報の順で作ろう
- 391 6.5m
- organization が inventories, teams, projects, jobs を管理する
- 392 7.5m
- AWXをブラウザで開いてポチポチで組織やユーザを作ってる
- 393 8m
- 394 8.5m 8-2-4 ジョブを実行してみよう
- プレイブックの集まりがプロジェクト
- プロジェクトとして Source Code Management や ローカルディレクトリを登録して、特定のプレイブックを取得するようにする
- ジョブテンプレートを作ってジョブを実行しようね
- インベントリ、プロジェクト、ジョブテンプレートを作るとジョブが実行できるよ
- 395 10m
- AWXのGUIでインベントリを設定できる
- 396 10.5m
- ホストの前にグループを作成しておきましょう
- 397 11m
- 398 11.5m
- 399 12m
- ワークフロージョブテンプレートというのもあるよ
- 400 12.5m
- プレイブックの実行をならべて、(複数のjobを並べて)業務プロセス全体を管理できる より大きなやつ
- 401 13.5m
- 多くの人が共通して使えるAWXみたい仕組みがあるとブラウザで簡単にポチポチだし、自動化2.0になるよ (AWXまとめ)
終わりに
- 403 14.5m
- 「どんな小さいスクリプトでもまずはヘルプから書きなさい」
- ヘルプ機能が大事
- ツールと同様に組織文化改善が大事
- 404 16m
- ビジネスアジリティを高めよう
- 自動化をシンプルにして保守しやすくしておこう
- 405 16.5m 索引
- 413 17m 著者プロフィール
- レッドハットにお勤めの北山さん。Kubernetes実践ガイド、GitLab実践ガイドも
- ディーエヌエーの佐藤さんとヒューレット・パッカードの塚本さん、
- 畠中さん、横地さん
- 414 19m
- 417 20m
感想・まとめ (影響: この本を読んで変わったことを書こう)
- 5 やっぱりシェルは共通語で誰でも使えるね
- 15 結構難しいことが書かれていて気合が要る
- ここでも大活躍する湯婆婆メソッド (横文字は最後の1,2文字だけ読む)
- でも、その後は普通に読める難しさだった
- 31 Chefの前にPuppetがあったことを知れた
- 58 詳しいところまで細かく知れた
- 64 ansibleコマンドでsudoが要る時は -b -Kをつけましょう(知らなかった) (become とかの意味)
- 72 やはりいままでなんとなくでAnsibleを使っていたんだなぁ。知らないことが結構ある。ホストパターンに正規表現使えるとか
- 72 インベントリ変数(ホスト変数) 知らなかった。 使い所は…あまりないかも。
- 77 Ansibleは PyYAML を利用していて libyaml を使用していて YAML 1.1の書式に対応 (大事そう)
- 78 シーケンスでは.. 値の無い行(ハイフンだけ)の後に 子を入れて入れ後をつくれる (はっきりとは知らなかった)
- 80 |- で始めると、複数行文字列。 - は最後の改行をなしにする。 > なら 改行がスペースになる (1行になる) (>は知らなかった)
- 83 具体的なコードのことになると、知らないことがたくさんあった
- 310 Azure と AWS で結構同じなのかなと思いきや、やっぱりAWSと違いそうでやはり不安は残った
- 312 まぁ、AWSでも同様のことができるだろう、と思った
- 343 Ansibleへの苦手意識というか知らないことがある意識はなくなった
- 便利なモジュールに知らないものはあったが、構文に知らないことはなかった(と思う)
- assert モジュールとか、 loop (ずっとitem_withでやってた)とかやはり☆をつけたような知らないことは結構あった
知りたいこと
- 60 Ansibleのディレクトリ構造は複数流派があるのだった(記憶)
- 後ろの方に書いてあるだろうか 2021/03/10 16:28
- 7章にかなり詳しく書いてあった2021/03/29 16:27
- 69 動的インベントリのやり方とか知りたいね 2021/03/10 16:34
- 6章とかに書いてあった2021/03/29 16:27
わからなかったこと
- 70 インベントリの記法に{yamada,tanaka,satou} は使えない？ (書いてないので使えないのだと思う) (使うシーンも無いと思うので調べない)
- 正規表現でやればよさそう。2021/03/29 16:28
自分ごと
- 機材がたくさんある時は、自動化しないととてもじゃないけどやってられないね
- 23 うちらは 結構 (4) 継続的オペレーションまで行ってるのでは？
- 行ってないシステムがあったら、この(4)の状態まで引き上げられると、点数高い
- ☆ 306 こういうAnsibleじゃないかもしれないけど、こういうのを使って、会社で使ってるクラウド構築を自動化できるとポイント高い (CloudFormation？)
試してみよう(実践のコーナー)
- WSLから個人プロダクトのサーバに対して、今までAnsibleでしたことないことをやってみよう
- 会社のansibleレポジトリの構成を調べてみよう
- この記事に書いたことを最後に読み返したい
この読書記事で
よかったこと
- 本の中のことばは「」で囲えた
- 本に書いてあることから派生したこと、考えたことを別のコーナーに書くことで見返しやすくなったと思う
- オススメ情報は☆で目立たせよう☆
できなかったこと
次回に活かそう
- ◎とか☆とか記号を付けた行は下線 をつけよう (後で特に読み返したいところ)
実践
- (今の所やってない)
所要時間
分はその日の累計時間
- 2021/03/02
- このブログ記事を書き始める
- このブログ書きとKindle Unlimited のこと調べまで15分
- はじめにと目次おわり 28min
- P.16 (第一章途中)まで読んだ 46min
- 2021/03/03
- P.17 - 25 (9ページ) 41min。 1章
- 1ページ 4.5分もかかっている (1ページ1分が目標)
- 難しめの文字が多いページが続いたので、具体的なコードが出てきたら、ある程度は知ってることもあり、加速するだろうと期待
- ちなみに、こういう読書記録の1行を書くのに大体30秒かかる
- 2021/03/05
- P.26 - 37 (12ページ) 43分 1章おわり
- 1ページ3.5分 はやくなってきた いい感じ
- 2021/03/08
- P.38 - 45 (8ページ) 17.5分 2章途中
- 1ページ2分 ますます早くなってきた (途中に白紙ページありそう)
- 2021/03/09 (5日め)
- P.46 - 58 (13ページ) 41分 2章途中
- 1ページ3分。遅くなった
- 途中で コード書こうとして記法に手間取った (がマスターした)
- 残り
- 残り350ページ。1ページ3分なら 1000分？ ということは 33日かな。(全部で38日) もう少し加速したいところ。
- 2021/03/10
- P.59-71 (13ページ) 40分 3-1の途中
- うーん、1ページ3分かかってるな… (本全体が410ページなので、 1200分 = 40日かかる)
- 25日(1ページ2分)で見積もってるので、1.5倍以上このままではかかる
- ◎1ページ読むごとに いま何分経過したかを記録しよう。目指す1ページ2分
- 2021/03/11
- やっぱり、コードが出てくると読むのが加速される感
- P.72-83 (12ページ) 40分 3-2 プレイブック
- 今日は調子いまいちなので、明日こそ1ページ2分(1.5倍のスピード)を意識するぞ！
- 2021/03/12
- 各ページに到達した時の経過時間を記すと、急ぐ気持ちが出てよい
- 漢字をちゃんと変換シナイトイウカ、いちいち書き直さないのもいいかも もしさらに早くする必要があれば
- 41分で P.84-109 (26ページ) 1ページ1.6分。 書くページに到達した経過時間を書くととても良かった
- この速度なら全体は 660分 = 11時間 = 22日で終わる (いいかんじ) のこり 300ページなのであと 473分 = 8時間 = 16日
- 2021/03/15
- ワンインデント分をコピーしておくと素早く×かも。辞書登録がいいかも。
- 39分で P.110-133 (24ページ) 1ページ 1.6分。 早くていいね。 3章-4章
- あと 15日だろう。 (のこり 276ページ)
- 2021/03/17
- 38.5m で P.134-160 (27ページ) 1.4分/ページ。 4章で mariaDBなどをインストールした。
- のこり 250ページ。350分(=6時間 = 12日間)
- 2021/03/18 (11日め)
- 40.5m で P.161-191 (31ページ) 1.3分/ページ。 4章 nginxやWordPressインストール
- コード多くなったので、速度もアップ
- のこり 220ページ。 286分 = 4時間46分 = 9.5日。 全体としては 20.5日？になりそう？
- 2021/03/19
- 40mで P. 192-211 (19ページ) 2.1分/ページ。 5章 OS設定
- ためになることが多かったので、記事に書くことが多かった
- 残り 200ページ。
- 2021/03/22
- 40mで P.212-250 (39ページ) 1分/ページ 5章 WindowsとNW機器の設定
- 過去最速
- 残り 160ページ。 160分なら 5日か！？
- 2021/03/23
- 41mで P.251-304(54ページ) 0.76分/ページ 5章NW機器と6章Azure
- 過去最速。NW機器はかなりながら読みだった
- 残り 113ページ。あと2,3日かな。
- 2021/03/24
- 41m で P.305 - 324 (20ページ) 2分/ページ ６章 Azure, Docker
- 興味あるところなので順当に遅くなった
- 残り 93 ページ。 あと 4.5日かな。 サブスクいつ切れるんだっけ。 4/1 まで。まぁギリギリ終わるでしょう。3/31にキャンセルしないといけない。
- 2021/03/26 (16日目)
- サブスク切れそうなので加速
- 60mで P.325-355 (31ページ) 2分/ページ。 6章Docker, 7章ベストプラクティス
- 興味あるところなので、 1ページ2分かかった,
- 残り 62ページ。 土日3/27,28に60分ずつやるつュリナノデ、日曜に終わる予定
- 2021/03/27
- 61mで P.356-382 (27ページ) まぁ 2分/ページか。
- 7章ベストプラクティス、8章 Ansible Works Project
- 興味あるところなので遅い、あと1、2日でおわり
- 2021/03/28 (18日目)
- 20m で P.383-417 (35ページ) 0.57分/ページ
- 次の営業日にこの本のまとめをするぞ！
所要時間まとめ(最後に)
- 全体として何分かかったのか、1ページ何分だったのか出したい
- 2021/03/02 ～ 3/28 (27日後に終わった)。実際に読んだのはそのうちの 18日
- 417ページを730.5分(12.2時間)で読んでいた。1.75分/ページ
- この速度データを集めて、読書・勉強計画に役立てていくぞ。
- → 読書・勉強・実践速度まとめ2021 - t_hazawaの日記
ファイナル感想
- NW機器やDockerやAnsible Works のところは直接業務に使えそうにはなかったけれど、他の7割の部分は◎とか☆とかつけた知識は役立ちそうだったので、Ansible業務の時に思い出したい。
