Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

新卒3年目のぼくが、でぶおぷす???なオジサンだらけのエンプラ金融PJにAnsibleを導入してみた

14,235 views

Published on

【明日の開発カンファレンス 2018】
方眼紙Excelのサーバ変更手順書、実機と設定値が異なるパラメーターシートがはびこるプロジェクトを、開発・保守・運用チームまで巻き込み、変革した話です。
周りはGit??CI??なおじさんたちばかり。そして、エンプラ&オンプレというInfrastructure as Codeと相性の悪い領域。泥臭く、根気よく、最後まであきらめずに、導入を進めてきました。
"先進的なツール"と"今までのやり方や文化"をうまく結びつけるために、どのような工夫をしたかをお伝えします。

Published in: Technology

新卒3年目のぼくが、でぶおぷす???なオジサンだらけのエンプラ金融PJにAnsibleを導入してみた

  1. 1. 新卒3年目のぼくが、でぶおぷす???な オジサンだらけの エンプラ金融PJ にAnsibleを導入してみた Future Architect, Inc. Shuntaro Saiba 明日の開発カンファレンス 2018
  2. 2. 本日お話しすること 1 ”今までのPJのやり方や文化”と“先進的なツール” これをどう結びつけたか
  3. 3. 本日お話しすること 2 ”今までのPJのやり方や文化”と“先進的なツール” これをどう結びつけたか おじさん でぶおぷす??
  4. 4. 補足: Ansibleとは 3 管理サーバ 対象サーバ ・・・etc. サービス起動・停止 設定ファイル書き換え パッケージインストール ファイルデプロイ Ansibleで自動化 x N台 x N台 x N台  オープンソースなサーバ管理ツールです
  5. 5. 補足: Ansibleとは 4  Infrastructure as Code のツールです  手作業が多く発生  手順書&スクリプトの構成管理が困難 従来 Infrastructure as Code 手順書 手作業 & x N台 x N台 x N台 ソースコード & x N台 x N台 x N台 自動化ツール  作業の省人化と効率化によるコスト削減  オペレーションミスの発生可能性を低減  手順書のコード化による高度な品質保証
  6. 6. 補足: おじさんとは 5  いろいろ知らない & 使いたがらない 人を指します
  7. 7. 6
  8. 8. 7 チームメンバーに対する表現は 脚色しており、あくまでも”演出”です チームのみなさまへ ※ プレゼンでのウケを優先しています ※ ほんとはおじさんとか思っていません 承 認 済
  9. 9. 自己紹介 8  齋場 俊太朗 (さいば しゅんたろう)  インフラ ~ CI回り担当 (新卒4年目)  Future Architect, Inc. Technology Innovation Group所属  Qiita 記事 “EC2上にHoneypot(T-Pot)をインストールして サイバー攻撃をELKで可視化してみた。” @tarosaiba
  10. 10. 自己紹介 9 2015年 新卒入社 今 現在 エンプラ小売り & AWS エンプラ金融 & オンプレ エンプラ小売り & GCP  新人で配属されたPJ  インフラ&CIを担当  クラウドの魅力を知る  その反面サーバ管理のツラミも知る  3年目で配属  オンプレについても知りたく希望  Ansible導入を推進  今現在のPJ  GCP & Kubernetesに苦戦中  まさに、夢のような世界
  11. 11. 自己紹介 10  新人で配属されたPJ  インフラ&CIを担当  クラウドの魅力を知る  その反面サーバ管理のツラミも知る  3年目で配属  オンプレについても知りたく希望  Ansible導入を推進  今現在のPJ  GCP & Kubernetesに苦戦中  まさに、夢のような世界 2015年 新卒入社 今 現在 エンプラ小売り & AWS エンプラ金融 & オンプレ エンプラ小売り & GCP
  12. 12. 話の経緯 11  金融系プロジェクトの基盤更改にアサイン(昨年4月~12月) – はじめは、サーバ&NWの下っ端として  バリバリのエンプラ系 – なかなかお堅いです。もちろんオンプレ  問題あり。現行のサーバはまさに、ブラックボックス – Excelの設計書はもはや意味なし。「それ、信じちゃだめだからね」byボス  サーバ台数 ≒ 150台 (複数環境合わせて) – それぞれのサーバが5年間の手作業によって育ってきちゃっている
  13. 13. 12 新卒3年目のぼくが、でぶおぷす??? なオジサンだらけの エンプラ金融PJ にAnsibleを導入してみた 結果..
  14. 14. 13 新卒3年目のぼくが、でぶおぷす??? なオジサンだらけの エンプラ金融PJ にAnsibleを導入してみた 結果..
  15. 15. 今できていること 14 MW設定 ベンダ-構築 サーバ構成要素 その他の構成要素 パッケージ管理 OSユーザグループ ディレクトリ作成 ファイル 構築 - MW ログ その他 ベンダ構築 - MW MW 個人ユーザ 全て NW設定 ディスク設定 ssh設定 cron設定 カーネル設定 構築 その他 :ソースコード化済み
  16. 16. 今できていること 15
  17. 17. 16 神戸さん (Vulsのちょんまげ) 本気モードで泥臭ーい話したってくだせぇ!
  18. 18. 17 新卒3年目のぼくが、でぶおぷす??? なオジサンだらけの エンプラ金融PJ にAnsibleを導入してみた 泥臭い話します結果..
  19. 19. 18 ”エンプラ”と“金融” PJへの導入 簡単なはずがない!
  20. 20. 19 凝り固まった今までの文化&やり方 文 化 や り 方
  21. 21. 20 新しいやり方(ツール)に対する懐疑な声 便利だけど、使うのは(ソースコード書くのは) 難しんでしょ?? みんなが使えるようにならないと いけないんでしょ? セキュリティ面とか大丈夫?? 事故とか起こりそうじゃない? 今までの運用手順から 変わってしまうんでしょ?
  22. 22. 21 新しいやり方(ツール)に対する懐疑な声 便利だけど、使うのは(ソースコード書くのは) 難しんでしょ?? みんなが使えるようにならないと いけないんでしょ? セキュリティ面とか大丈夫?? 事故とか起こりそうじゃない? 今までの運用手順から 変わってしまうんでしょ?
  23. 23. 22 そして、Mutableなオンプレミス きたなくなる きたなくならない
  24. 24. 23 そして、、
  25. 25. 24 これ
  26. 26. 25 NO 項目 コマンド 確認者 10 11 13 さいば バッチサーバ1号機へログインする ssh user@bat01svr hostname;whoami;pwd → ホストネームを確認する さいば さいば cp -p /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 ls –l /opt/mw/dir1/hoge/ +AA143 → コピー元とコピー先が同じパーミッションか確認する バッチサーバ2号機へログインする ssh user@bat02svr hostname;whoami;pwd → ホストネームを確認する 設定ファイルのバックアップを取る コピーしたファイルのパーミッショ ンを確認する 12 設定ファイルを書き換える 変更内容は別紙参照 vim /opt/middleware/directory/hoge/fuga.xml diff /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 → diffの差分が以下であることを確認する 3c3 < para3=hogeC --- > para3=fugaC さいば
  27. 27. 26 NO 項目 コマンド 確認者 10 11 13 さいば バッチサーバ1号機へログインする ssh user@bat01svr hostname;whoami;pwd → ホストネームを確認する さいば さいば cp -p /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 ls –l /opt/mw/dir1/hoge/ +AA143 → コピー元とコピー先が同じパーミッションか確認する バッチサーバ2号機へログインする ssh user@bat02svr hostname;whoami;pwd → ホストネームを確認する 設定ファイルのバックアップを取る コピーしたファイルのパーミッショ ンを確認する 12 設定ファイルを書き換える 変更内容は別紙参照 vim /opt/middleware/directory/hoge/fuga.xml diff /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 → diffの差分が以下であることを確認する 3c3 < para3=hogeC --- > para3=fugaC さいば コマンドが改行されてる!!(怒゚Д゚)ノ 変な文字混じってる!!(怒゚Д゚)ノvimなの!!(怒゚Д゚)ノ ここでdiffの確認!?(怒゚Д゚)ノ 2号機..N号機!!(死゚Д゚)ノ 方眼紙!! (怒゚Д゚)ノ ネ申 Excel手順書
  28. 28. 27 NO 項目 コマンド 確認者 10 11 13 さいば バッチサーバ1号機へログインする ssh user@bat01svr hostname;whoami;pwd → ホストネームを確認する さいば さいば cp -p /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 ls –l /opt/mw/dir1/hoge/ +AA143 → コピー元とコピー先が同じパーミッションか確認する バッチサーバ2号機へログインする ssh user@bat02svr hostname;whoami;pwd → ホストネームを確認する 設定ファイルのバックアップを取る コピーしたファイルのパーミッショ ンを確認する 12 設定ファイルを書き換える 変更内容は別紙参照 vim /opt/middleware/directory/hoge/fuga.xml diff /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 → diffの差分が以下であることを確認する 3c3 < para3=hogeC --- > para3=fugaC さいば コマンドが改行されてる!!(怒゚Д゚)ノ 変な文字混じってる!!(怒゚Д゚)ノvimなの!!(怒゚Д゚)ノ ここでdiffの確認!?(怒゚Д゚)ノ 2号機..N号機!!(死゚Д゚)ノ 方眼紙!! (怒゚Д゚)ノ
  29. 29. 28 エンプラ ウェブ系 クラウド (仮想環境) オンプレ (物理環境) 相性良し 相性抜群 制約等がなければ 相性はよい? 相性悪い まさに相性が悪い領域
  30. 30. 29 前置きが長くなりましたが
  31. 31. Ansible導入するまでの話 30 リーダー陣 アプリ インフラ 運用 : 偉い 保守 私
  32. 32. Ansible導入するまでの話 31 リーダー陣 アプリ インフラ 運用 : 偉い 保守 私 はじまり インフラ&アプリチームへ プロジェクトリーダー陣へ 運用チームへ 保守チームへ まとめ&さいごに 1 2 3 4 5 6 1 2 3 4 5 6
  33. 33. 32 自動化 技術 ツール
  34. 34. 33 自動化 技術 ツール 学習コスト 実践経験 コンプライアンス 文化 組織 セキュリティ
  35. 35. 34 自動化 技術 ツール 学習コスト 実践経験 コンプライアンス 文化 組織 セキュリティ メインの話
  36. 36. 35 1. はじまり 1 2 3 4 5 6
  37. 37. 話の経緯 ※再掲 36  金融系プロジェクトの基盤更改にアサイン(昨年4月~12月) – はじめは、サーバ&NWの下っ端として  バリバリのエンプラ系 – なかなかお堅いです。もちろんオンプレ  問題あり。現行のサーバはまさに、ブラックボックス – Excelの設計書はもはや意味なし。「それ、信じちゃだめだからね」byボス  サーバ台数 ≒ 150台 (複数環境合わせて) – それぞれのサーバが5年間の手作業によって育ってきちゃっている 1 2 3 4 5 6
  38. 38. 37 「 サーバ構築は“元気玉”で 」 っえ?.. ※元気玉: メンバーみんなで手分けして、(手作業で)頑張ろうということ ボス わたし 1 2 3 4 5 6
  39. 39. 昔の記憶が、よみがえりました。。
  40. 40. 39 構築作業を自動化できていなかったあの時代.. 1 2 3 4 5 6
  41. 41. 40 ご め ん な さ い ご め ん な さ い え 、 昨 日 頼 ん だ 検 証 環 境 ま だ で き て な い の ね え 、 こ こ の 設 定 間 違 え た で し ょ ダ ブ ル チ ェ ッ ク し た の ! ? ね え 、 ダ ブ ル チ ェ ッ ク し た の ! ? 構築作業を自動化できていなかったあの時代.. 新人の私 1 2 3 4 5 6
  42. 42. 41 サーバの構成管理をできていなかったあの時代.. 1 2 3 4 5 6
  43. 43. 42 ご め ん な さ い ご め ん な さ い い つ の 間 に か 、 DB の パ ラ メ ー タ 変 わ っ た ん だ け ど ね え 、 な ん で ! ? あ の サ ー バ で は 動 い て た ん だ け ど こ こ だ と 動 か な い ん で す け ど ダ ブ ル チ ェ ッ ク し た の ! ? ね え 、 ダ ブ ル チ ェ ッ ク し た の ! ? サーバの構成管理をできていなかったあの時代.. 新人の私 1 2 3 4 5 6
  44. 44. 43 サーバ管理で苦しむのは もう、いやだーーーー! 1 2 3 4 5 6
  45. 45. 44 サーバ管理で苦しむのは もういやだーーーー! そこで Ansible を導入しようと 考えました 1 2 3 4 5 6
  46. 46. インフラチームボスへ提案してみた 45  Infrastructure as Codeについての説明資料は自前で – DevOpsとかの言葉は通じない.. Gitも初なのでレベルを合わせて  初めは????だけど、実際に動くものを見せたらいい感じだった  エージェントレス & Redhatブランド は大きな後ろ盾になった 1 2 3 4 5 6
  47. 47. インフラチームボスへ提案してみた 46 説明資料 yamlファイル DEMO ボスわたし 1 2 3 4 5 6 こんなことができます ほーちょっとやってみてよ
  48. 48. インフラチームボスへ提案してみた 47 説明資料 yamlファイル DEMO ボスわたし 1 2 3 4 5 6 こんなことができます ほーちょっとやってみてよ Ansible導入が始まりました
  49. 49. 48 2. インフラ&アプリチーム まずは身近なところを仲間にしよう 1 2 3 4 5 6
  50. 50. 大切にしたポイント 49 • スモールスタートで拒絶反応をなくす • 仕組みを先に作ってしまう 1 2 3 4 5 6
  51. 51. 小さい範囲からAnsibleで自動化 50  まずは、サーバへの設定ファイル配布に絞ってAnsibleを使い始めた – いきなり全てソースコード化するのはハードルが高い&拒否される可能性大と 考えた – はじめは、hosts, resolv.conf のOS設定ファイル..等の配布にAnsibleを利用 1 2 3 4 5 6
  52. 52. 51 小さい範囲からAnsibleで自動化 設定ファイル hosts roles/ etc/web-svr.yml db-svr.yml xxx-svr.yml db-svr/ xxx-svr/ tasks/web-svr/ deploy.yml files/ hosts resolv.conf 構成 1 2 3 4 5 6 はじめ使用したのは Ansible copy module 配布用ファイル
  53. 53. Ansibleファンを増やしていく 52  垣根なくチームの要望に聞き耳を立てて、Ansibleでどんどんこなす!! – NW : NW機器のconfigの構成管理したいな.. – 基盤 : ifconfigの実行結果全部取集したいな..このpkg全台に導入してほしいな.. – APP:設定ファイル勝手に変更されてAPP動かなくなってる.. 構成管理したいな.. – 他にも: Windowsに対しても作業自動化したいな.. 1 2 3 4 5 6
  54. 54. 53 Ansibleファンを増やしていく アプリの人 NW機器も Windowsも NWの人 わたし 1 2 3 4 5 6 要望をヒアリング どんどんAnsibleでこなす
  55. 55. “みんなが”使える仕組みを先に整える 54  AnsibleソースをExcel一覧から自動生成できるようにした – fileデプロイ、dir作成、user&group作成 けっこう簡単 (ymlの恩恵) – サーバ変更依頼は、Excelインターフェースで受けるようなフローに  Ansibleソース変更&実行フローはどんどん自動化 – “ Ansibleソース生成 → デプロイ → サーバへ適用 ” with Jenkins 1 2 3 4 5 6
  56. 56. 55 みんな使えるような仕組みを整えた話 1 2 3 4 5 6 Excel ファイル - name: Add user user-hoge user: name: user-hoge uid: 1001 group: unyo home: /home/user-hoge shell: /bin/bash password: “xxxxxxxx" state: present - name: Add user user-fuga user: name: user-fuga uid: 1002 group: unyo home: /home/user-fuga shell: /bin/bash password: “yyyyyyyy" state: present [..] Ansibleファイル Name uid group home shell password State user-hoge 1001 admin /home/user-hoge /bin/bash xxxxxxxx present user-fuga 1002 admin /home/user-fuga /bin/bash yyyyyyyy present ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ Pyhonスクリプト Jenkins & 使いたい人 みんな大好きExcelを使って yamlファイルの自動生成
  57. 57. 使わざる負えない仕組みを先に整える 56  ソースコードとの差分(手動変更)は自動検知&フィードバック可能にした – Ansibleの仕組み以外(手動)でサーバへ変更が発生する (絶対誰かがやる) – やっぱり(先輩とかだと)、自分からは注意し辛い – 不整合一覧をチーム全体に共有して、ボスから指示いただくフローに 1 2 3 4 5 6
  58. 58. 57 使わざる負えない仕組みを先に整える ソースと突合 フィードバック情報(file)を収集 ボス わたし 1 2 3 4 5 6 手でいじらないように! 手でサーバ葬っちゃう人には ボスからのフィードバックを 変更作業 (手動)
  59. 59. PJメンバー 58 リーダー陣 アプリ インフラ 運用 : 偉い 保守 Ansible いいね!! 1 2 3 4 5 6
  60. 60. PJメンバー 59 リーダー陣 アプリ インフラ : 偉い 運用 保守 1 2 3 4 5 6
  61. 61. 60 DevOps !?!? 1 2 3 4 5 6
  62. 62. 61 3. プロジェクトリーダー陣 運用/保守へ行く前に、 トップダウンで導入に協力してもらおう 1 2 3 4 5 6
  63. 63. 大切にしたポイント 62 • 今までの(インフラ)課題と結びつける • ビジョンを掲げる 1 2 3 4 5 6
  64. 64. 今までの課題の解決法として提案 63  過去のインフラ課題(チケット)を探り出し、解決案としての提案を行った – インフラの不備による障害は、リーダー陣としても課題意識が大きかった – 特に、STG環境と本番環境の意図しない差異による障害について – 構成管理&構築自動化が私のスコープだったが、環境間不備のチェックも行えると アピール 1 2 3 4 5 6
  65. 65. 64 今までの課題の解決法として提案 課題 内容 Infrastructure as Codeを導入した場合 • インフラ(OS,MW, NW) 設定をソースコードとして 正確な構成管理が可能になる • ソースコードに定義した設定と実機の設定を比較することにより 環境の不整合を検知可能 構成管理 • アプリのソースコードはバージョン管理ができているが インフラ(OS,MW, NW)に関しては、バージョン管理が正確に できていない • 構築&設定変更作業の自動化が可能になり、 ヒューマンエラーを防ぐことができる ヒューマンエラー • サーバへの設定変更の大半は、手作業によって行われている • 各環境の環境設定の差分を ソースコードの差分として把握、管理することが可能 • あるべき差分を管理することで意図しない環境間差分を検知可能 環境間差異 • 各環境の環境設定の差分を正確に管理できていない 1 2 3 4 5 6
  66. 66. ビジョンを掲げて提案 65  Ansibleとは何か?ではなく、Ansibleを導入してどう変わるのかを提案 – リーダ人にっては、”いんふらすとらくちゃーあずこーど” なにそれおいしいの? – 細かく説明するのではなく、概念レベルで説明 (絵にしたのが効果的) 1 2 3 4 5 6
  67. 67. 66 ビジョンを掲げて提案 PRD STG DEV ソースコードの自動適用 ソースコードとの自動突合 ソースコミット バージョン管理ツール PRD STG DEV 手作業での変更は 原則禁止 環境 インフラ作業者 ソースコードの履歴管理 環境差異の突合 1 2 3 4 5 6 Ansibleで実現できることをアピール
  68. 68. PJメンバー 67 リーダー陣 アプリ インフラ 運用 : 偉い 保守 どうして今までやってなかったの どんどん進めてください 1 2 3 4 5 6
  69. 69. 68 4. 運用チーム 実際に作業をする人たちに使ってもらって 便利さをわかってもらおう 1 2 3 4 5 6
  70. 70. 大切にしたポイント 69 • 簡単なことで使ってもらって慣れてもらう • だれでも使えるように手順書を作りこむ 1 2 3 4 5 6
  71. 71. 簡単なことから作業改善を提案 70  運用チームが日々行う作業に対して、Ansibleでの効率化を提案 – インフラのソースコード化は難しくても、Ansibleコマンド実行でも役に立つこと沢山 – いままで、1台1台サーバにsshしていた作業を自動化 – まずは、Ansibleの便利さを知ってもらうことを目標に 1 2 3 4 5 6
  72. 72. 簡単なことから作業改善を提案 71 コマンド発行 OK! ファイル回収 OK! NW config回収 OK! ただAnsibleコマンド(ラップシェル)実行すればOK!! Ansible コマンド利用 fetchモジュール 利用 ciscoモジュール 利用 任意のコマンド 任意のファイル NW config 1 2 3 4 5 6
  73. 73. 手順書&ラップスクリプトを整備 72  誰でも便利に使えるように手順書&ラップスクリプトを作成 – PlaybookとかRoleという概念はいきなりハードル高い – コマンド粒度の手順書レベルまで落とし込めば、全然使ってもらえた 1 2 3 4 5 6
  74. 74. 手順書&ラップスクリプトを整備 73 1 2 3 4 5 6
  75. 75. 手順書&ラップスクリプトを整備 74 1 2 3 4 5 6 とにかく書きまくりました
  76. 76. PJメンバー 75 リーダー陣 アプリ インフラ 運用 : 偉い 保守 Ansibleって便利ですね! 運用チームとしても活用したいです 1 2 3 4 5 6
  77. 77. 76 5. 保守チーム Ansibleでのサーバ管理方法を うまく回していってもらおう 1 2 3 4 5 6
  78. 78. 大切にしたポイント 77 • 考え方を押し付けるのではなく、 いっしょに考える • 今までのやり方と調和させる 1 2 3 4 5 6
  79. 79. “いっしょに”ワークフローを検討 78  現状のリリースフローをヒアリングしてしっかりすり合わせする – 今までのSVNのリリースフローとGitフローで整合性を保つ必要があった – リーダ承認のフローもGitのMRフローとして採用してもらうように 1 2 3 4 5 6
  80. 80. 一緒に作り上げたワークフロー 79 1 2 3 4 5 6
  81. 81. 今までのやり方と調和するよう提案 80  ネ申Excel手順書を根絶するのではなく、調和させるようにする – 根本から作業フローを変えるのは難しい – ベースのやり方はそのままで、Ansible実行方法をいっしょに考える 1 2 3 4 5 6
  82. 82. 今までのやり方と調和するよう提案 81 1 2 3 4 5 6
  83. 83. 今までのセキュリティポリシーは守る 82  Ansibleの導入によりセキュリティレベルが下がらないようにする – rootパスワードや鍵の管理は従来の方法を実現できるように実装する – 開発→本番環境 へのNW遮断 もファイル連携でひと手間加えて 1 2 3 4 5 6
  84. 84. 今までのセキュリティポリシーは守る 83 踏み台(Ansible) サーバ 作業対象サーバ rootパスワード 手入力 運用メンバー 踏み台(Ansible) サーバ 作業対象サーバ 本番環境開発環境 運用メンバー Ansible ソース ファイル連携 パスワード管理 OK! NW経路 OK! 1 2 3 4 5 6
  85. 85. PJメンバー 84 リーダー陣 アプリ インフラ 運用 : 偉い 保守 保守・運用としてもAnsibleで インフラ管理、やるしかない! 1 2 3 4 5 6
  86. 86. 85 そして、ついに..
  87. 87. 86 NO 項目 コマンド 確認者 10 11 13 さいば バッチサーバ1号機へログインする ssh user@bat01svr hostname;whoami;pwd → ホストネームを確認する さいば さいば cp -p /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 ls –l /opt/mw/dir1/hoge/ +AA143 → コピー元とコピー先が同じパーミッションか確認する バッチサーバ2号機へログインする ssh user@bat02svr hostname;whoami;pwd → ホストネームを確認する 設定ファイルのバックアップを取る コピーしたファイルのパーミッショ ンを確認する 12 設定ファイルを書き換える 変更内容は別紙参照 vim /opt/middleware/directory/hoge/fuga.xml diff /opt/middleware/directory/hoge/fuga.xml /opt/mw/dir1/hoge/fuga.xml_20171221 → diffの差分が以下であることを確認する 3c3 < para3=hogeC --- > para3=fugaC さいば コマンドが改行されてる!!(怒゚Д゚)ノ 変な文字混じってる!!(怒゚Д゚)ノvimなの!!(怒゚Д゚)ノ ここでdiffの確認!?(怒゚Д゚)ノ 2号機 N号機!!(死゚Д゚)ノ ネ申 Excel手順書 方眼紙!! (怒゚Д゚)ノBEFORE
  88. 88. 87 NO 項目 コマンド 確認者 1 2 3 さいば 踏み台サーバへログインする ssh user@btn01svr hostname;whoami;pwd → ホストネームを確認する さいば ansible-playbook bat-svr.yml ログアウトする exit Ansibleを実行する さいば これだけ!!嬉゜ω゜)楽 ※ 実際には2,3手順あります AFTER これはもうしょうがない。
  89. 89. PJ メンバー 88 リーダー陣 アプリ インフラ 運用 : 偉い 保守Ansible いいね!! by PJメンバー 一同 1 2 3 4 5 6
  90. 90. 89 さいごに 1 2 3 4 5 6
  91. 91. 全体を通じて大切にしたポイント 90 • 今までの文化にツールの方を合わせていく • あきらめない 1 2 3 4 5 6
  92. 92. ベストプラクティスは捨てる 91  Ansibleのベストプラクティスが私たちにベストとは限らない – 今までの考え方に歩み寄りできるようにした – インフラをソースコード化するというプロセスに拒否反応を抱かせないよう、今までの 考え方に親和するようにした 1 2 3 4 5 6
  93. 93. 92 楽 複雑 手間 分かりやすい おじさんにとって 1 2 3 4 5 6 ベストプラクティスは捨てる
  94. 94. 93 hosts roles/ サーバ種=role ファイルシステム を再現 Ansibleの構成 web-svr.yml db-svr.yml xxx-svr.yml web-svr/ db-svr/ xxx-svr/ tasks/ files/ etc/ main.yml deploy_files.yml mkdir.yml ansible.cfg usergroup.yml hosts resolv.conf Excelから自動生成 # ファイル配置する定義 webサーバに対して # dirを作成する定義 # usrgroupを作成する定義 # 配布する実ファイル群 “静的”ファイルのみ 1 2 3 4 5 6
  95. 95. 94 hosts roles/ サーバ種=role ファイルシステム を再現 Ansibleの構成 web-svr.yml db-svr.yml xxx-svr.yml web-svr/ db-svr/ xxx-svr/ tasks/ files/ etc/ main.yml deploy_files.yml mkdir.yml ansible.cfg usergroup.yml hosts resolv.conf Excelから自動生成 # ファイル配置する定義 webサーバに対して # dirを作成する定義 # usrgroupを作成する定義 Ansibleベストプラクティス ガン無視 Orz # 配布する実ファイル群 “静的”ファイルのみ おじさんたちへの分かりやすさを優先 taskファイルの冗長は、自動生成なのでOK 1 2 3 4 5 6
  96. 96. あきらめない 95
  97. 97. 分かってもらえるまで説明する 96 ここがコウデ。.. 自動化できます。 1 2 3 4 5 6 ぐぬぬ。。
  98. 98. 分かってもらえるまで説明する 97 ここがコウデ。.. 自動化できます。 中身の処理は こうなっていて.. 1 2 3 4 5 6 ぐぬぬ。。 ぐぬぬぬ。。
  99. 99. 分かってもらえるまで説明する 98 ここがコウデ。.. 自動化できます。 中身の処理は こうなっていて.. 実際の定義ファイル はこうなっていて.. 1 2 3 4 5 6 なるほどナー! ぐぬぬ。。 ぐぬぬぬ。。 やった!
  100. 100. 分かってもらえるまで説明する 99 1 2 3 4 5 6
  101. 101. 分かってもらえるまで説明する 100 1 2 3 4 5 6
  102. 102. 分かってもらえるまで説明する 101 “考え方”を分かってもらうのは めっちゃ大変。 1 2 3 4 5 6
  103. 103. 絶対にサーバを手で葬らせない 102 & 1 2 3 4 5 6 サーバ
  104. 104. 絶対にサーバを手で葬らせない 103 & ディレクトリ 手で作っちゃおうっか 1 2 3 4 5 6 サーバ
  105. 105. 絶対にサーバを手で葬らせない 104 & サーバへの変更は手で 行わないでください! 手で変更する場合は 作業内容をメモでください ディレクトリ 手で作っちゃおうっか ※ あとで私がAnsibleソース化する 1 2 3 4 5 6 サーバ
  106. 106. 絶対にサーバを手で葬らせない 105 & サーバへの変更は手で 行わないでください! 手で変更する場合は 作業内容をメモでください ディレクトリ 手で作っちゃおうっか ※ あとで私がAnsibleソース化する 1 2 3 4 5 6 サーバ 口うるさい嫌われ役 めちゃ辛い。
  107. 107. 106 振り返ってみて 1 2 3 4 5 6
  108. 108. 導入までの歩み 107 2017 5月 2017 12月 2018 2月 ユーザ会で発表夏祭りで発表 2017 8月 検証 実装 改良 導入検討 Dev 運用検討 運用中 Ops Ansibleでの 構築開始 システム リリース 引継ぎ・勉強会 Ansibleでの 運用開始 今 1 2 3 4 5 6 地道な普及活動
  109. 109. 導入までの歩み 108 2017 5月 2017 12月 2018 2月 ユーザ会で発表夏祭りで発表 2017 8月 検証 実装 改良 導入検討 Dev 運用検討 Ops Ansibleでの 構築開始 システム リリース 引継ぎ・勉強会 Ansibleでの 運用開始 今 私、PJから離脱 1 2 3 4 5 6 地道な普及活動 運用中
  110. 110. 109 (おまけ) 引継ぎ 私がPJを抜けた後でも、この仕組みを 回す&改善していってもらわねば 1 2 3 4 5 6
  111. 111. 引き継いだ内容 110 1 2 3 4 5 6 Ansible の使い方 (+CIツール) 自動化の考え方
  112. 112. 引き継いだ内容 111 1 2 3 4 5 6 今までの文化 これから(理想)の文化
  113. 113. 引き継いだ内容 112 1 2 3 4 5 6 今までの文化 これから(理想)の文化 変えたい
  114. 114. 自動化するかしないか 113  定型作業を自動化するかどうかを考える ・・・ コスト 月日 ・・・ いつものコスト
  115. 115. 自動化するかしないか 114  自動化するためのコストと削減できるコストがある ・・・ コスト 月日 ・・・ いつものコスト 自動化するためのコスト 削減できるコスト
  116. 116. 自動化すれば 115  自動化が進めば余剰の時間が生まれ、さらなる自動化を進められる。  ※ あくまでも理想 作業の自動化 コスト削減 手作業がなくなる 余剰の時間が生まれる
  117. 117. 自動化するかしないか 116  自動化する OR しない どちらかを選択する際の観点 自動化する 自動化しない 自動化するための コスト 運用の変化の 重み 削減できる コスト オペミスの削減 効果 変化しないリスク 変化するリスク
  118. 118. 自動化するかしないか 117  自動化する OR しない どちらかを選択する際の観点 (私の考え) 自動化するための コスト 運用の変化の 重み 削減できる コスト オペミスの削減 効果 変化しないリスク 変化するリスク 自動化する 自動化しない
  119. 119. 118 今、自動化ツールは次々と進化している 私たちは、お客様の業務をシステム化するIT企業なのに その波に乗り遅れてよいのか
  120. 120. 119 今、自動化ツールは次々と進化している 私たちは、お客様の業務をシステム化するIT企業なのに その波に乗り遅れてよいのか って、言って煽りました
  121. 121. 120 ポイントまとめ プロジェクトリーダへ  今までの(インフラ)課題と結びつける  ビジョンを掲げる 運用チームへ  簡単なことで使ってもらって慣れてもらう  だれでも使えるように手順書を作りこむ 保守チームへ  考え方を押し付けるのではなく、いっしょに考える  今までのやり方と調和させる 1 2 3 4 5 6 インフラ&アプリチームへ  スモールスタートで拒絶反応をなくす  みんなが使える仕組みを先に作ってしまう 全体を通じて  今までの文化にツールの方を合わせていく  あきらめない
  122. 122. 121 まとめ&これから  DevOpsのツール&考え方と疎遠な人たちに導入するには工夫が必要 – とにかく、分かりやすい&使いやすいを最優先に – おじさんたちには机上では伝わらない、実際に体験してもらう  PJ内の各チームは意外にも導入に好意的であった – みんなそれぞれ課題を抱えていて、解決方法を求めていた – みんな、”知らない”&”どうやったらよいかわからない” だけ – チームごとに異なるアピール方法が必要  新しい文化を作っていくのはやっぱり時間が必要 – 5年以上育て来た今までの文化をいきなり捨てるのは無理 – 今も、保守・運用チームにこの仕組みを育てていってもらっているところです – (徐々に入れ替わっていって、Excel手順書がなくなることを祈っています) 1 2 3 4 5 6
  123. 123. 本日お話ししたこと 122 ”今までのPJのやり方や文化”と“先進的なツール” これをどう結びつけたか おじさん でぶおぷす! 1 2 3 4 5 6
  124. 124. 123 ありがとうございました 1 2 3 4 5 6
  125. 125. 124 奇人・変人・達人大募集中! We are hiring engineers!!

×