Download as PDF, PPTX
More Related Content
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn.slidesharecdn.com/ss_thumbnails/amazonauroratips-170307140000-thumbnail.jpg?width=640&height=640&fit=bounds)
インフラCICDの勘所
- 1. インフラCI/CDの勘所 Azureのアーキテクトが語る 真壁 徹 日本マイクロソフト株式会社 2018/08/02 Cloud NativeDays Tokyo 2018 C-1-5
- 2. 自己紹介 { “名前” : “真壁徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “部署” : “クラウドアーキテクト技術本部”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研 → HP Enterprise”, “特技” : “クラウド & オープンソース”, “Twitter” : “@tmak_tw” }
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13. インフラCI/CDパイプライン 本日の定義 コミュニケー ション支援 タスク・イ シュー管理 コード管理 Continuous Integration 成果物 (コード) Continuous Delivery (*) インフラ(本番) インフラ (ス テージング) インフラ (開 発・検証)コード (*)”Continuous”にしないこともある インフラ オーナー インフラ 技術者 • 構文チェック • テスト • シミュレーション • デプロイ用 コード生成・配置 監視 デプロイ インフラ (サン ドボックス) バグ、不具合、考慮漏れ
- 14.
- 15. インフラCI/CDの目的は何か コスト削減以外の目的がありますか インフラCI/CDの代表的な効果 -> インフラ構築・変更時の検証、デプ ロイの工数削減と時間短縮 工数削減-> コスト削減 というロジックが典型的だが… そもそもインフラの検証やデプロイのコストを把握しているか？ それだけで投資効果を説明できるか？
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27. ツール先行になりやすい 楽しいからしょうがないですよね Ansible? Terraform? Chef?CircleCI? Jenkins? Concourse CI? VSTS? GitHub? GitLab? Bitbucket? 流行り廃りが激しい 使ってみて「当面」信じられると感じたツールを使う どれを使っても苦労する時は苦労するし、急に下火になりうる 「使わせる人」じゃなく、使う人が選ぶ、使う人を選定に巻き込む 選んだ人を後から非難しない
- 28. • Git難しい問題 • 完全に理解した-> さっぱりわからない の繰り返し
- 29. コード管理と共同作業は最重要課題 Your infrastructure dependon your code & collaboration コードでインフラを表現するなら、コードの管理は最重要テーマ 現在Gitがデファクトスタンダード、が、正直難しい 多くのインフラ技術者がここでつまづく ぼっちGit -----(高い壁、そしてマサカリ)----- チームGit 手を動かし、小さな成功体験を積んで学ぶしかない チームは”ダイバーシティ & インクルージョン”を大切に
- 30. これまでの経験や経歴、得意な分野、発想、仕事に対する考 え方、価値観、ライフステージなどは十人十色。誰一人とし て同じではないからこそ、その力を結集したときの可能性は 未知数であり無限大です。 マイクロソフトの ダイバーシティ &インクルージョン https://www.microsoft.com/ja-jp/mscorp/diversity/default.aspx
- 31. コード管理: ブランチとフロー 唯一の解はない Git Flow?GitHub Flow? GitLab Flow? 良し悪し以前にコンセプトの理解、周知が難しい チームメンバーが理解できることが重要 (みんなが腹落ちするなら独自のやり方でもOK) コードと環境が一致することがポイント 例: リリースバージョンごとにブランチを作り、変数で環境を分ける
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39. Subnet 監視をテストの一部とする 変更点ではなくアプリ、サービス視点でチェックする アプリ、サービスとして正しく動いているかを監視 もし変更点が影響すれば検知できる ステージングや開発・検証環境で影響を洗い出す Service A Service B ServiceC Packet Filtering Rules User Defined Routes この変更点が、動いているサー ビスにどんな影響を与えるか、 簡単にはテストできない… Monitoring ポート監視 コンテンツ監視 フロー監視
- 40.
- 41. Continuous “Delusion” atthe Infrastructure Layer “Infrastructure is more sensitive to a catastrophic change because if the infrastructure fails, everything fails.” Randy Bias (http://cloudscaling.com/blog/devops/continuous-delusion-at-the-infrastructure-layer/) Delusion = 妄想, Continuous Delusion = 継続的妄想
- 42.
- 43. ├── dynamic │ ├──container.code │ └── vm.code └── static ├── network.code └── datastore.code 管理単位を分ける DynamicとStaticを分ける 頻度やライフサイクル、リスクを考慮してパイプラインを分割する 仮想マシンやコンテナーと、ネットワークやデータストアを分ける デプロイ時間が長ければ、さらにその中で分割する
- 44.
- 45.
- 46. 基盤の維持ではなく 新に作って切り替える 「データは王様」戦略 最も動かしにくいのはデータ データストアは独立させる アプリもインフラも CI/CDパイプラインがあれば 再現、テストできる リスクある継ぎ足しCDや インプレースアップグレードではなく 新規作成し、切り替える 王様 Current NetworkNew Network Traffic Control (例: DNS応用) 切り替え アプリ & インフラ CI/CD パイプラインCluster VM/ Containers Cluster VM/ Containers
- 47. 外部とのインターフェイスを絞る Hub & Spoke戦略 IPアドレスを直に使わず名前解決 絶対 外部とつなぐネットワークを集約する ゲートウェイの類をハブに集約する ハブにプロジェクトをつなぐ 仮想ネットワークアドレス空間が 被らないのが理想だが、 ピアリングの制御で なんとかなることも Hub Network Project A Network Project B Network Project B’ Network External A Network External B Network Spokeごと切り替え 仮想プライベート ネットワークの ピアリング
- 48.
- 49.
- 50. © Copyright MicrosoftCorporation. All rights reserved.