Developers Summit 2018【15-B-L】mzu1h様、飯島様の講演資料です。

1. Spinnakerで実現する
デプロイの自動化
ハッシュタグ：#devsumiB
セッションID ：【15-B-L】

2. 株式会社エーピーコミュニケーションズ
APCって言ったりします
・ 設立： 1985年
・ 社員数： 350名ぐらい
・ 7割はインフラエンジニア
・ アプリ開発や技術研究もやってます

3. ITインフラ業界に起きている変化
- 仮想化 -
- クラウド -
- コンテナ -
 サーバー設定(BIOS,OS)
 ネットワーク構築
 ストレージ設定
 冗長化設定
 各種MWインストール、設定
 構成管理、変更管理
 システム監視
 インフラをプログラミング
 自動構築設定
 手順書運用は自動化
 オートスケール
 構成はコードで管理
 CI/CD
 システム監視 (自動障害対応)

4. 本日の内容
•自己紹介
•導入の経緯
•Spinnakerの特徴
•Spinnakerを実際に動かしてみた
•良い点/改善(してほしい)点
•まとめ

5. 自己紹介
•株式会社エーピーコミュニケーションズ
でエンジニアをやっています。
•インフラエンジニアです。
•普段は客先常駐で仕事しています。
•それ以外にも、他部署の自動化の推進や、営業
支援のひとつでOSSの検証などを行っています。

6. 今回の発表のテーマは
•日本でも最近認知度があがってきたSpinnaker
というCDツールをさわってみて、デプロイの手間を
本当に減らせることができたのか検証した結果を
発表します。
•日本で(ほぼ) 記事がないAWS上で動かすことを
試してみたので、その操作感も含めてお話します。

7. まず初めに

8. “Spinnaker”、知っていますか？

10. “Spinnaker”との出会いのきっかけ

11. とあるユーザの要望
• アプリケーションをデプロイするときは確実に
実施したい。問題があったら即時に切り戻
したい。
• アプリケーションのデプロイに手間をかけたく
ない。
• プロジェクトごとでクラウド環境が変わってく
るが、デプロイ方法は同じ方法にしたい。

12. 考えた解決案
• アプリケーションをデプロイするときは確実に
実施したい。問題があったら即時に切り戻
したい。
• アプリケーションのデプロイに手間をかけたく
ない。
• プロジェクトごとでクラウド環境が変わってく
るが、デプロイ方法は同じ方法にしたい。

13. 考えた解決案
• アプリケーションをデプロイするときは確実に
実施したい。問題があったら即時に切り戻
したい。
• アプリケーションのデプロイに手間をかけたく
ない。
• プロジェクトごとでクラウド環境が変わってく
るが、デプロイ方法は同じ方法にしたい。
切り替わり時間
の短縮化が必要

14. 考えた解決案
• アプリケーションをデプロイするときは確実に
実施したい。問題があったら即時に切り戻
したい。
• アプリケーションのデプロイに手間をかけたく
ない。
• プロジェクトごとでクラウド環境が変わってく
るが、デプロイ方法は同じ方法にしたい。
自動化が必要
切り替わり時間
の短縮化が必要

15. 考えた解決案
• アプリケーションをデプロイするときは確実に
実施したい。問題があったら即時に切り戻
したい。
• アプリケーションのデプロイに手間をかけたく
ない。
• プロジェクトごとでクラウド環境が変わってく
るが、デプロイ方法は同じ方法にしたい。
自動化が必要
切り替わり時間
の短縮化が必要
APIの差分吸収
が必要

17. Spinnakerの特徴
自動化が必要
切り替わり時間
の短縮化が必要
APIの差分吸収
が必要

18. Spinnakerの特徴
Blue/Greenデプロイメントを含めた複数のデプロ
イ方法をサポート
自動化が必要
切り替わり時間
の短縮化が必要
APIの差分吸収
が必要

19. Spinnakerの特徴
Blue/Greenデプロイメントを含めた複数のデプロ
イ方法をサポート
自動化が必要
切り替わり時間
の短縮化が必要
APIの差分吸収
が必要
(アプリケーションをデプロイ済みの)イメージ作成→
インスタンス作成→LB配下に配置までをパイプラ
インで全自動化

20. Spinnakerの特徴
Blue/Greenデプロイメントを含めた複数のデプロ
イ方法をサポート
自動化が必要
切り替わり時間
の短縮化が必要
APIの差分吸収
が必要
(アプリケーションをデプロイ済みの)イメージ作成→
インスタンス作成→LB配下に配置までをパイプラ
インで全自動化
複数のクラウドのAPIをサポート

21. サポートしているデプロイ方法
•Red/Black Deploy(=Blue/Green Deploy)
•Rolling Red/Black Deploy(=Rolling Deploy)
•Canary Deploy

22. Red/Black Deploy

23. Red/Black Deploy

24. Red/Black Deploy

25. Red/Black Deploy

26. Red/Black Deploy

27. パイプライン

28. パイプライン

29. パイプライン

30. パイプライン

31. サポートしているクラウドプロバイダ

32. せっかくなので検証してみた
• 検証の目的
-GitHubにコードをアップロードするだけで、デプロイまで動くのか？
-どの位時間がかかるのか？
-Red/Blackデプロイの実際の(切り替え/切り戻り)動作は？
• 検証の手順
-表示を「Hello World01」→ 「Hello World02」に変更して
GitHubにアップロード。
-正常に本番環境までデプロイできたら、1つ前の状態に切り戻す。

33. 検証のイメージ

34. イメージの流れ

35. 検証の流れ①

36. 検証のイメージ
①
Githubレポジトリにコミットすると、
Jenkinsが変更を検知し、
イベントハンドラを起動
検証の流れ①

37. 検証の流れ②

38. ②
Jenkinsの通知を受けたSpinnkerは、ス
テージング環境でBake→Deployを実行。
※Red/Blackデプロイではない。
検証の流れ②

39. 検証の流れ③

40. ③
ステージング環境に新アプリのデプロ
イが成功したら、管理者に通知。
管理者が次の作業に進むことを
承認する。
検証の流れ③

41. 検証の流れ④

42. ④
②のBakeで作成したイメージを本番環
境でDeployする。
※Red/Blackデプロイなので
新規でサーバグループを作成する。
検証の流れ④

43. 検証の流れ⑤

44. ⑤
１つ前の状態に手動で切り戻す。
(Rollback)
検証の流れ⑤

45. 検証

46. 検証のイメージ
①
Githubレポジトリにコミットすると、
Jenkinsが変更を検知し、
イベントハンドラを起動。
検証の流れ①

47. 検証
GiitHubに新アプリケーションの
プログラムをアップロード。

48. JenkinsがGitHubにアップロードされた
ことを検知。Spinnakerに通知。

49. ②
Jenkinsの通知を受けたSpinnkerは、ス
テージング環境でBake→Deployを実行。
※Red/Blackデプロイではない。
検証の流れ②

50. SpinnakerがJeknkinsからの通知を
検知する

51. Bakeの実行。

52. Bakeの実行状況の確認。

53. Bake(≒Packer)のログに出力される。

54. Bakeの完了。

55. Deployの実行。

56. Deployの完了。

57. ③
ステージング環境に新アプリのデプロ
イが成功したら、管理者に通知。
管理者が次の作業に進む許可する。
検証の流れ③

58. Slackに通知。

59. 管理者はパイプラインが次に進む承認
をする。(Continueボタンをクリック)

60. ④
②のBakeで作成したイメージを本番環
境でDeployする。
※Red/Blackデプロイなので
新規でサーバグループを作成する。
検証の流れ④

61. 承認されたことの検知。

62. Deployの実行。

63. Deployの完了。

64. CLUSTERS画面でサーバグループの
状態確認。

65. それぞれのサーバグループの状態を表
示。(緑が正常、赤が異常)

66. それぞれのサーバグループの状態を表
示。(緑が正常、赤が異常)

67. それぞれのサーバグループの状態を表
示。(緑が正常、赤が異常)

68. ロードバランサのパブリック
DNS名にHTTP通信。

69. 新アプリの内容が表示。

70. 切り戻してみた

71. ⑤
１つ前の状態に手動で切り戻す。
(Rollback)
検証の流れ⑤

72. 切り戻し(Roleback)の実行。

73. 切り戻し先のサーバグループを指定。

74. 切り戻しが自動で実行される。

75. １つ前のサーバグループが有効になる。
(色が半透明→緑色に変わる)

76. 旧アプリの内容が表示。

77. 検証の結果
-Githubにコードをアップロードするだけで、デプロイまで動
くのか？
-どの位時間がかかるのか？
-Red/Blackデプロイの実際の動作は？

78. 検証の結果
-Githubにコードをアップロードするだけで、デプロイまで動
くのか？
→動いた。
-どの位時間がかかるのか？
-Red/Blackデプロイの実際の動作は？

79. 検証の結果
-Githubにコードをアップロードするだけで、デプロイまで動
くのか？
→動いた。
-どの位時間がかかるのか？
→約14分。
-Red/Blackデプロイの実際の動作は？

80. 検証の結果
-Githubにコードをアップロードするだけで、デプロイまで動
くのか？
→動いた。
-どの位時間がかかるのか？
→約14分。
-Red/Blackデプロイの実際の動作は？
→簡単な操作で切り戻った。(約1分)

81. 便利だとおもった点
•あると便利なデプロメント手法を網羅している。
•ひとつの画面でGitHubにアップ→本番環境にデ
プロイまでの進捗状況を確認できる。
•Spinnakerの画面で、ELB/セキュリティグループ
/オートスケーリンググループ/AMIを作成できる。

82. 今後の改善を期待したい点
•若干動作が不安定
GUI上でプルダウンで選択するときに、項目が表示されないことが、よくある。
•サブネット名が決まった名前しかつけられない。(AWS特有)
サブネット名の規則：
{VPC名}. external.{リージョン名} or {VPC名}.internal.{リージョン名}
例：defaultvpc.external.us-east-1
•Spinnaker上でセキュリティグループを作るとき、送信元/
送信先がIPアドレスを指定できない。(AWS特有)
送信元/送信先IPアドレスのセキュリティグループはAWS上で作成するしかない。

83. まとめ

84. まとめ(1/5)
•GitHubにアップ→(クラウド環境の)本番環境
までのデプロイメントまでを全自動で実現可能。

85. まとめ(2/5)
•機器の状態(正常/異常)をひと目で判断すること
が可能。
インスタンスが何百台とあるときはすごく便利。

86. まとめ
•機器の状態(正常/異常)をひと目で判断すること
が可能
インスタンスが何百台とあるときはすごく便利。
https://cdn-images-1.medium.com/max/2000/1*nnayKYFFI8JGo3KXV3A23Q.png

87. まとめ(3/5)
•トラブルシューティングは骨が折れる。。
マイクロサービスアーキテクチャなので複数のコンポーネントで構成されている
ため、被疑箇所特定が大変。しかもドキュメントが少ない。

88. https://www.travistomsu.com/2016/12/08/an-introduction-to-spinnaker-under-the-hood/

89. まとめ(4/5)
•OSSとしては、発展途上の半ばだと感じた。
すごい頻度でバージョンアップしてるし、公式Slackでは毎日世界中の誰か
がハマっている。。

91. まとめ(5/5)
•複数のクラウドに対して1つのツールで
Blue/Greenデプロイメントを提供できる。

92. クラウドプロバイダごとのBlue/Greenデプロイメントの実現可否の比較

93. •Netflix,Google,Microsoftといった有名企業
の開発者を中心に鋭意開発/改善中。
•いろいろな機能が実装されていく可能性あり。
•クラウド環境でデプロイ方法にお悩みの方は１度
検討してみては！？
最後に

94. ご清聴ありがとうございました。