社内勉強会　DevOps勉強会

1. DevOps勉強会
0
2017/11/30
Future Architect, Inc.
Shuntaro Saiba

2. 本日の内容
1
1 DevOpsとは
2 DevOpsを支える ツールの紹介
4 最後に
1 自動化されたインフラ
2 ソースコードのバージョン管理
3 継続的インテグレーション

3. 本日の内容
2
1 DevOpsとは
2 DevOpsを支える ツールの紹介
4 最後に
1 自動化されたインフラ
2 ソースコードのバージョン管理
3 継続的インテグレーション

4. 3
“DevOps” って
聞いたことある人はいますか？

5. 4
最近話題のDevOps

6. DevOpsとは
5
DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と
運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携
して協力する開発手法をさす。ソフトウェアのビルド、テスト、そしてリリースの文
化と環境を以前よりも迅速に、頻繁に、確実に発生する確立を目指している。
チームで開発する際の重要な考え方 & 手法
(まあ、けっこう曖昧らしい）

7. 6
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
高速なWebサイトを作るにはどうしたらい
いかということをテーマにした
”Velocity 2009”というイベントにて、
Flickrエンジニアによって提唱された
「開発と運用が協力することで、1日に10回以
上のペースでリリースが可能になる」
というプレゼンです
DevOpsの始まり

8. 7
1日、 10回のリリース..？

9. DevOpsの生まれた背景
8
 アジャイル開発による継続的な開発へ変化
– 継続的な開発によって見えてきた運用課題が発生
 「動いているシステムには触るな」という格言があるIT業界だったが
今の時代必要なことは、常に変化すること
 システムを変化させることには、リスクが伴う

10. DevOpsの生まれた背景
9
 アジャイル開発による継続的な開発へ変化
– 継続的な開発によって見えてきた運用課題が発生
 「動いているシステムには触るな」という格言があるIT業界だったが
今の時代必要なことは、常に変化すること
 システムを変化させることには、リスクが伴う
カルチャー ツール
でそのリスクを軽減させる

11. 10
カルチャー ツール

12. 11
カルチャー ツール
本日のメイン

13. DevOpsに大切なカルチャー
12
 Respect (尊重)
 Trust (信頼)
 Healty attitude about failure
(失敗に対する前向きな姿勢)
 Avoiding Blame (非難をしないこと)
大切ですが、私にはそんなに語れません

14. DevOpsに大切なツール
13
自動化された
インフラ
ソースコードの
バージョン管理
継続的
インテグレーション
メトリクスの共有 IRC チャット bot

15. DevOpsに大切なツール
14
自動化された
インフラ
ソースコードの
バージョン管理
継続的
インテグレーション
メトリクスの共有 IRC チャット bot
Gitlab GitHab
Docker
Jenkins Drone.io
SVN

16. DevOpsに大切なツール
15
ソースコードの
バージョン管理
監視
継続的
インテグレーション
テスト環境
本番環境
インフラの自動化
Serverspec
フィードバック &
コミュニケーション
開発者
運用者
よくある構成
ソース取得
デプロイ
インフラ構築
フィードバック
コミット

17. 16
ソースコードの
バージョン管理
Gitlab

18. 17
Jenkins
継続的
インテグレーション

19. 18
Docker
自動化された
インフラ

20. 19
ElasticSearch
メトリクスの共有

21. 20
IRC チャット bot
Slack

22. 21
こちら: https://xebialabs.com/periodic-table-of-devops-tools/

23. 22

24. 23
車輪の再発明は必要ありません

25. DevOpsに大切なツール (再掲)
24
自動化された
インフラ
ソースコードの
バージョン管理
継続的
インテグレーション
メトリクスの共有 IRC チャット bot
Gitlab GitHab
Docker
Jenkins Drone.io
SVN

26. DevOpsに大切なツール (再掲)
25
自動化された
インフラ
ソースコードの
バージョン管理
継続的
インテグレーション
メトリクスの共有 IRC チャット bot
Gitlab GitHab
Docker
Jenkins Drone.io
SVN
本日紹介するもの

27. 26

28. 27
結局DevOpsはツールなの？

29. 28

30. 29
 (ただの) ツールではない
 (ただの) カルチャーではない
 (ただの) 開発(Dev)と運用(Ops)ではない
 (ただの) 自動化ではない
 何物でもない。
Devops ??
Practical DevOps & Continuous Delivery
https://www.slideshare.net/hugomesser/practical-devops-continuous-
delivery-a-webinar-to-learn-in-depth-on-devops-platform

31. 30

32. 31

33. 32

34. DevOpsとは (再掲)
33
DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と
運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携
して協力する開発手法をさす。ソフトウェアのビルド、テスト、そしてリリースの文
化と環境を以前よりも迅速に、頻繁に、確実に発生する確立を目指している。

35. 34
これがDevOpsです

36. 本日の内容
35
1 DevOpsとは
2 DevOpsを支える ツールの紹介
4 最後に
1 自動化されたインフラ
2 ソースコードのバージョン管理
3 継続的インテグレーション

37. ツール (手法) の紹介
36
自動化された
インフラ
ソースコードの
バージョン管理
継続的
インテグレーション

38. 37
自動化されたインフラ

39. 38
構築手順書がメンテナンスされてない
構築手順書通りに構築したのに動かない
設計書と実際のインフラの設定値
全然が違う
扱うマシンが多すぎて
構築に時間がかかる
構築したインフラのテストが大変
インフラあるある
環境変わるの怖くて触れない
だれか間違えて設定してる

40. 39
いつのまにか
サーバがブラックボックスに

41. 40
いつのまにか
サーバがブラックボックスに
そこで
“Infrastructure as Code”

42. Infrastracuture as code とは
41
Infrastructure as Codeは、ITシステムにおけるインフラストラクチャの状態を
(人手を介した手順としてではなく)自動実行可能なコードの形で記述し、インフラ構
築を自動化するプロセスである

43. 42

44. そもそもインフラって？？
43
 インフラとは「あるシステムが稼働するために前提となる周辺環境すべ
て」を指します
ネットワーク
ハードウェア
OS
ミドルウェア
アプリケーション
インフラ

45. 改めてインフラ構築って？？
44
 以下のように3つに分類できます
 (Infrastrucute as Codeの観点で分類しました)
仮想マシン作成 OSインストール
OS/ミドルウェア設定
デプロイ・サーバ間連携3. Orchestrasion
2. Configuration
1. Bootstraping
 アプリケーションをデプロイしたり
 クラスタ構成を組んだり
 監視ツールの対象に追加したり
 OSの設定(NW,ストレージ)を設定したり
 MW(DB,Webサーバ)をインストールしたり
 MWのパラメータを設定したり
 CentOSとかインストールしたり
 Vagrantで仮想マシン立ち上げたり
 Dockerでコンテナ立ち上げたり

46. 45
話を戻して

47. Infrastracuture as code とは
46
従来
手順書 手作業
&
x N台
x N台
x N台
 自動実行可能なコードの形でインフラの状態を記述し、インフラ構築を自
動化するプロセス
Infrastructure as Code

48. 47
手作業でインフラ構築。。。
パラメータシート
(設定値が記載されている)
手順書
(操作手順が記載されいる)
作業者
確認者
コマンドライン
作業対象サーバ

49. 48
時間かかるし、、
絶対にミスるでしょ

50. 49
そこで
Infrastracuture as Code

51. 50
 手作業が多く発生
 手順書&スクリプトの構成管理が困難
従来 Infrastructure as Code
手順書 手作業
&
x N台
x N台
x N台
ソースコード
&
x N台
x N台
x N台
自動化ツール
 作業の省人化と効率化によるコスト削減
 オペレーションミスの発生可能性を低減
 手順書のコード化による高度な品質保証
Infrastructure as Code

52. Infrastructure as Code
51
 インフラ構築作業は以下のようなツール群で自動化できる！
仮想マシン作成 OSインストール
OS/ミドルウェア設定
デプロイ・サーバ間連携3. Orchestrasion
2. Configuration
1. Bootstraping

53. 何がうれしいのさ
52
 作業の省人化と効率化によるコスト削減
 オペレーションミスの発生可能性を低減
自動化
 コード化による高度な品質保証
 継続的なインテグレーション(インフラの)を実現
インフラ環境の
構成管理

54. 何がうれしいのさ
53
自動化できないと。。

55. 何がうれしいのさ
54
ご
め
ん
な
さ
い
ご
め
ん
な
さ
い
え
、
昨
日
頼
ん
だ
検
証
環
境
ま
だ
で
き
て
な
い
の
ね
え
、
こ
こ
の
設
定
間
違
え
た
で
し
ょ
ダ
ブ
ル
チ
ェ
ッ
ク
し
た
の
！
？
ね
え
、
ダ
ブ
ル
チ
ェ
ッ
ク
し
た
の
！
？

56. 何がうれしいのさ
55
構成管理できないと。。

57. 何がうれしいのさ
56
ご
め
ん
な
さ
い
ご
め
ん
な
さ
い
い
つ
の
間
に
か
、
DB
の
パ
ラ
メ
ー
タ
変
わ
っ
た
ん
だ
け
ど
ね
え
、
な
ん
で
！
？
あ
の
サ
ー
バ
で
は
動
い
て
た
ん
だ
け
ど
こ
こ
だ
と
動
か
な
い
ん
で
す
け
ど
ダ
ブ
ル
チ
ェ
ッ
ク
し
た
の
！
？
ね
え
、
ダ
ブ
ル
チ
ェ
ッ
ク
し
た
の
！
？

58. 57
いろいろ思い出しますな

59. 58
でも、もう大丈夫！
Infrastracuture as Code
があるからね！

60. 何がうれしいのさ (再掲)
59
 作業の省人化と効率化によるコスト削減
 オペレーションミスの発生可能性を低減
自動化
 コード化による高度な品質保証
 継続的なインテグレーション(インフラの)を実現
インフラ環境の
構成管理

61. 各ツールの紹介
60
 有名なツール
 2012年~
 使用言語はPython
 エージェントレス
 2009年~
 使用言語はRuby
 Rubyの文法がそのまま使用可能
 管理サーバ&エージェントの構成
 2005年~
 使用言語はRuby
 独自のDSLで構成を記述
今日はこいつを
扱います

62. Ansibleについて
管理サーバ
対象サーバ
・・・etc.
サービス起動・停止
設定ファイル書き換え
パッケージインストール
ファイルデプロイ
Ansibleで自動化
x N台
x N台
x N台
 RedHat社が提供。オープンソースのサーバ構成管理ツール

63. 62
Ansibleの由来
アーシュラ・K・ル＝グウィンのSFシリーズ、
ハイニッシュ・ユニバースに登場する超光速通信技術

64. Ansibleについて
 基本は以下の要素
– Inventoryファイル (捜査対象ホストを定義)
– Playbook (yml形式でサーバの操作を記載)
[web]
10.0.11.121
10.0.11.122
(..)
10.0.11.152
[batch]
10.0.21.100
10.0.21.101
(..)
10.0.21.151
[hoge]
(..)
Inventoryファイル
---
- name: サンプル
hosts: all
become: true
tasks:
- name: ディレクトリ作成
file:
path: /etc/some_directory
state: directory
mode: 0755
- name: httpdのインストール
yum:
name: httpd
state: present
(... )
Playbook ファイル (yml)
＆

65. Ansibleの特徴
 Ansibleがインストールされた管理サーバから、捜査対象にログインして
直接を操作を実行する「プッシュ型」アーキテクチャ
 従って、操作対象マシンにエージェントのインストールが不要
 特別なプロトコルは使用せず、SSH接続&SCPのみを利用
※対象サーバにPython2.6以上が必要
エージェントレス
 他の構成管理ツール(Chef, Puppet)と比較し仕組みが非常にシンプル
 Ansibleでは、YAML形式というシンプルフォーマットで設定ファイル
(Playbook)を記述。
学習コスト低
 管理対象サーバーやサービスごとに様々なモジュールが用意されている
http://docs.ansible.com/ansible/list_of_all_modules.html
 NW機器を管理するモジュールもある
モジュールが多数

66. Ansibleの特徴
 冪等性が保たれる (ある操作を何度実行しても常に結果が同じになる
 新規のサーバにはスクリプトの内容がすべて適用され、既存のサーバには
差分のみが適用される
※ 2回目の処理で状態が変わったことでコケルということがない
冪等性
 任意のコマンドの実行結果を取得するだけ、等にも簡単に利用可能
(全サーバの設定ファイルの取得等に使ったり)
 ファイルデプロイのみにも利用可能
(全サーバに対してのファイル配布のみに使ったり)
多目的

67. Ansibleの特徴
66
 けっこう幅広い範囲をカバーしてます。イケてます
 2,3の範囲はもちろん、AWS,Dockerの管理もAnsibleでできます
仮想マシン作成 OSインストール
OS/ミドルウェア設定
デプロイ・サーバ間連携3. Orchestrasion
2. Configuration
1. Bootstraping

68. ちょっとデモ

69. ツール (手法) の紹介
68
自動化された
インフラ
ソースコードの
バージョン管理
継続的
インテグレーション

70. 69
ソースコードのバージョン管理

71. 70

72. 71

73. ちなみに
72
GitHub Gitlab
OSS

74. ちょっとデモ

75. ツール (手法) の紹介
74
自動化された
インフラ
ソースコードの
バージョン管理
継続的
インテグレーション

76. 75
継続的インテグレーション

77. 継続的インテグレーションとは
76
コミット
ビルド
テスト/
インスペクション
デプロイ
 インテグレーション(ビルド⇒テスト⇒デプロイのプロセス)を自動化し
継続的に行うこと

78. 継続的インテグレーションとは
77
コミット
ビルド
テスト/
インスペクション
デプロイ
 インテグレーション(ビルド⇒テスト⇒デプロイのプロセス)を自動化し
継続的に行うこと

79. 継続的インテグレーションとは
78
コミット ビルド
テスト/
インスペクション デプロイ
 インテグレーション(ビルド⇒テスト⇒デプロイのプロセス)を自動化し
継続的に行うこと

80. 79
いいことは、分かった。
でも、どうやるのよ

81. 80
https://youtu.be/k_fVlU1FwP4

82. ちょっとデモ

83. 82

84. 83

85. 84
私のマシンでは動いた
だけど結合テストではこけた
は世界共通

86. 85
回帰テスト

87. 何がうれしいのさ
86
継続的インテグレーション
ができないと。。

88. 何がうれしいのさ
87
ご
め
ん
な
さ
い
ご
め
ん
な
さ
い
え
、
昨
日
頼
ん
だ
リ
リ
ー
ス
ま
だ
で
き
て
な
い
の
ね
え
、
モ
ジ
ュ
ー
ル
古
い
ん
だ
け
ど
ダ
ブ
ル
チ
ェ
ッ
ク
し
た
の
！
？
ね
え
、
ダ
ブ
ル
チ
ェ
ッ
ク
し
た
の
！
？

89. 88
いろいろ思い出しますな

90. 何がうれしいのさ
89
回帰テストができないと。。

91. 何がうれしいのさ
90

92. 91
でも、もう大丈夫！
継続的インテグレーション
があるからね！

93. 92
私、悟ったんです。

94. 93
人間は、絶対にミスる

95. 94
プログラム、絶対にミスらない

96. 95
自動化、大事

97. 96
自動化、大事

98. 継続的インテグレーションとは
97
コミット
ビルド
テスト/
インスペクション
デプロイ
 インテグレーション(ビルド⇒テスト⇒デプロイのプロセス)を自動化し
継続的に行うこと
コレ

99. 最後に
98

100. 99

101. 100
カルチャー ツール

102. 101
導入するの難しいんじゃないの

103. 102
導入するの難しいんじゃないの
以前だったら、難しいと思います

104. 103
今は、使いやすいツールが
たくさんあるんです！

105. 104
自動化
技術
ツール

106. 105
自動化
技術
ツール
学習コスト
実践経験
コンプライアンス
文化
組織
セキュリティ

107. 106
自動化
技術
ツール
学習コスト
実践経験
コンプライアンス
文化
組織
セキュリティ
やっぱり難しい。(困)

108. 107
ただ、実現する価値はあると思います

109. まとめ
108
 DevOpsとは、ソフトウェアのビルド、テスト、そしてリリースの文化と
環境を以前よりも迅速に、頻繁に、確実に発生する確立を目指す開発手法
 今回はDevOpsのツールとして以下を紹介しました
– 自動化されたインフラ (Ansible)
– ソースコードのバージョン管理 (Git)
– 継続的インテグレーション (Jenkins)
 導入は簡単ではないけれど、使いやすいツールはたくさんあります