Successfully reported this slideshow.
Your SlideShare is downloading. ×

OpenStack Summit & KubeConからみるコンテナ技術の最新トレンド - OpenStack Day Tokyo 2018講演資料

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 48 Ad

OpenStack Summit & KubeConからみるコンテナ技術の最新トレンド - OpenStack Day Tokyo 2018講演資料

Download to read offline

タイトル:OpenStack Summit & KubeConからみるコンテナ技術の最新トレンド - OpenStack Day Tokyo 2018講演資料
講演者:玉置(VTJ)&山本(コムシス情報システム)
アジェンダ:
- なぜコンテナ技術にフォーカスするのか
- コンテナ技術の最新トレンド
- デモンストレーション(Kubernetes & Spinnaker)

タイトル:OpenStack Summit & KubeConからみるコンテナ技術の最新トレンド - OpenStack Day Tokyo 2018講演資料
講演者:玉置(VTJ)&山本(コムシス情報システム)
アジェンダ:
- なぜコンテナ技術にフォーカスするのか
- コンテナ技術の最新トレンド
- デモンストレーション(Kubernetes & Spinnaker)

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to OpenStack Summit & KubeConからみるコンテナ技術の最新トレンド - OpenStack Day Tokyo 2018講演資料 (20)

Advertisement

More from VirtualTech Japan Inc. (20)

Recently uploaded (20)

Advertisement

OpenStack Summit & KubeConからみるコンテナ技術の最新トレンド - OpenStack Day Tokyo 2018講演資料

  1. 1. OpenStack Summit & KubeCon からみるコンテナ技術の 最新トレンド 日本仮想化技術株式会社 VitrualTech.jp 2018/8/2 1 OpenStack Days Tokyo 2018
  2. 2. Speakers 2 たまおき のぶゆき • 日本仮想化技術でクラウド関係でビジネス開発している人 • OpenStack Summit ラーメン部 二代目部長 • 「年間30日海外生活」を目標に3年目に突入 • サッカー好き(川崎フロンターレは年パス保有) 山本 聡 • コムシス情報システムのインフラエンジニア • お客様先で構築案件をする傍ら自社のサーバを運用 • 年間1万キロを走破するバイク乗り • 好物は旅先で食べるソフトクリーム
  3. 3. 日本仮想化技術 • ベンダーニュートラルなクラウド・仮想化技術に特化した技術者集団 • NTTドコモ様の大規模 OpenStack 環境の設計・構築・運用の経験を元 に、通信事業者を対象としたコンサルティングサービスを提供 • NFV 基盤での仮想ネットワークの高速化(OVS+DPDK/SR-IOV)の先行 調査なども手がける • 昨年度から新領域として Edge + GPU Computing にフォーカス • NVIDIA 社と連携して Edge Computing での GPU 活用を訴求 https://VirtualTech.jp 3
  4. 4. 本日お話ししたいこと これからコンテナ技術の活用を検討している人を対象に、 「なぜコンテナ技術なの?」「コンテナ技術って便利なの?」 という疑問にお答えいたします。 • なぜコンテナ技術にフォーカスするのか • コンテナ技術の最新トレンド • デモンストレーション(Kubernetes & Spinnaker) 本セッションを参加した人に一つでも多くの気づきを持って帰っ ていただければ幸いです。 4
  5. 5. 1. OpenStack 2. Kubernetes 3. Kubernetes on OpenStack 4. OpenStack on Kubernetes 5. Edge Cloud 6. NFV Cloud Network Function Virtualization 言葉の定義 5 Kubernetes OpenStack OpenStack Kubernetes 3. Kubernetes on OpenStack 4. OpenStack on Kubernetes Kubernetes Hardware Hardware Under Cloud Over Cloud 5. Edge Cloud 6. NFV Cloud OpenStack と Kubernetes の関係 通信事業者でのクラウド技術・コンテナ技術の活用(一例) デバイス Kubernetes Hardware OpenStack OpenStack Hardware アクセス ポイント インター ネット
  6. 6. アジェンダ • なぜコンテナ技術にフォーカスするのか • コンテナ技術の最新トレンド • デモンストレーション(Kubernetes & Spinnaker) 6
  7. 7. クラウド技術をとりまく環境の整理 外的要因 • データ量の増大(データ処理量、 データ転送量、データ保存量) • 2025年に163ゼッタバイトのデータ量 • 2016年の10倍の規模 IDC調査 • 5Gネットワーク、コネクテッド カー、などの適用領域の拡大 • ピーク速度:10Gbps (4Gの10倍) • 遅延:1ミリ秒 (4Gの1/10) 内的要因 • NFV、Edge Cloud、などで Open Infrastructure の本格化 • NFV Cloud基盤でOpenStackが当 たり前のように採用されている • IoT、ML/DL、などの新規アプリ でのコンテナ技術の採用 7 通信事業者の次世代インフラ(5G)への投資は始まったばかり 引用:国内IoT市場 コグニティブ(AI)活用動向調査結果を発表 https://www.idcjapan.co.jp/Press/Current/20171114Apr.html
  8. 8. Edge Cloud + GPUs の推進 1. OpenStack -> NFV Cloud -> Edge Cloud の流れ • OpenStack + GPUs はNTTドコモ様の OpenStack 環境で実績あり 2. Edge Cloud では、軽量のコントローラノード群&ゼロタッチ プロビジョニングが必要 • 基地局の限られたスペースで Edge Cloud 基盤を設置すると想定 3. Edge App はコンテナを利用して作られることが多そう • App の開発生産性の観点から仮想マシンよりコンテナが最適 • 機械学習/深層学習の App はコンテナを利用 • コンテナ技術を習得する必要があった 8
  9. 9. Disaggregated CoreDisaggregated RAN 参考)AT&TのEdge Cloud/NFV Cloudの取り組み 5G Application Ecosystem IoT Connected Car MBB RU DU UPF UPF Macro Radio & Small cell Antennas 5G Base Stations Edge Cloud NFV Cloud CCFCU-CP CU-UP NFV MANO (Management & Orchestration) CU: Centralized Unit CP: Control Plane UP: User Plane UPF: User Plane Function CCF: Core Control Function RU: Radio Unit DU: Digital Unit Implications of 5G RAN and IoT on OpenStack based edge computing. より引用 インター ネット
  10. 10. Container / Compute Nodes Edge Cloud Architecture NFV MANO (Management & Orchestration) Edge Controllers Physical Provisioning Application Provisioning SDN / SDS Monitoring / Alerting Orchestrator GPU Hi speed networking General purpose Low energy Hi speed storage GPU Server GPU Server Storage Server Storage Server Object Storage Servers w/t SmartNIC Servers Scope of Edge Cloud ServerServer Server
  11. 11. Kubernetes Kubernetes vs ”Kubernetes on OpenStack” • Kubernetes • Kubernetes on OpenStack 11 Kubernetes Container ContainerContainer Container ContainerContainer Edge Cloud/NFV Cloud を設計する観点で、 Kubernetes の良いところ • Container Orchestrator としてメジャー • 軽量なコントローラ Kubernetes の良くないところ • マルチテナントはなし • SDNに紐付いたネットワークポリシー設定・ 運用はなし Kubernetes OpenStack “Kubernetes on OpenStack“ はKubernetesの 足りない機能を追加します Edge Cloudで利用するにはOpenStackのコン トローラは場所を占有しすぎるので、適用箇 所について検討が必要
  12. 12. CNCF Landscape https://github.com/cncf/landscape 12
  13. 13. 参考)CNCF Landscape の抜粋 Cloud Public: AWS, Azure, Google Cloud, 等 Private: OpenStack, VMware, 等 Provisioning – host mgmt. Ansible, CFEngine, CHEF, puppet, RUNDECK, SaltStack, Linuxkit, 等 Provisioning – Infra. automation AWS CloudFormation, BOSH, Infrakit, Juju, Terraform, 等 Runtime – Container Runtime containerd, rkt, cri-o, gVisor, kata, 等 Runtime – Cloud-Native Network Cilium, contiv, flannel, OvS, Tangsten Fabric, calico, 等 Runtime – Cloud-Native Storage Rook, Ceph, Gluster, OpenEBS, OpenSDS, 等 Orchestration - Service mgmt. gRPC, Envoy, Linkerd, HAProxy, Istio, nginx, 等 App def/dev – CI/CD GitLab, Jenkins, Spinnaker, Travis CI, 等 Obs. & Analysis - Monitering Prometheus, Glafana, influxdb, nagios, 等 Obs. & Analysis - Logging Fluentd, elastic, 等 Obs. & Analysis - Tracing JAEGER, OpenTracing, 等 13
  14. 14. Container Node 2Container Node 1 参考) k8s + flannel の構成図 14 Container A Container B Container C Container D flannel0 10.1.15.0 eth0: 10.1.15.2 cni0 10.1.15.1 eth0: 10.1.15.3 cni0 10.1.16.1 eth0: 10.1.16.2 flannel0 10.1.16.0 eth0: 10.1.16.3 flanneld etcd etcd flanneld VXLANでカプセル化 eth0: 192.168.0.200eth0: 192.168.0.100 1. Kubeletで podを作成 2. CNI plugin でNetwork I/F 作成 6. Endpoint を交換し、 etcdに格納 3. docker0か らflannel0に 転送 4. Etcdを参照 し、ARP解決 を実施 5. 別ノードと 通信はVXLAN でカプセル化 7. 転送先の物 理IPアドレス を確認 筆者が仕組みを理解するために作成した資料であり、内容に不備がありましたらこっそりとお伝えください。
  15. 15. Master Node 参考) k8s + calico の構成図 15 etcd Container Node 2Container Node 1 Container A Container B Container C Container D eth0: 10.1.15.2 eth0: 10.1.15.3 eth0: 10.1.16.2 eth0: 10.1.16.3 Felix BIRD BIRD Felix FIB FIB eth0: 192.168.0.200eth0: 192.168.0.100 IP tables IP tables etcd:エンドポイント情報やACLなどを保持するデータス Felix: etcdとの同期、経路情報とip tablesの監視/設定を行う BIRD: Node同士で経路情報をBGPで交換し、FIBに設定 FIB: 経路情報を格納し、コンテナにルーティングI/Fを付与 Linux Kernel FIB(Forwarding Information Base) 1. Kubeletで podを作成 3. FIBがルー ティング I/F 作成 5. Endpoint/ ACL情報を入 手 7. Endpoint/ ACL情報を格 納 6. Node同士の 経路情報を BGPで交換手 2. CNI plugin でNetwork I/F 作成 4. FIBがルー ティングI/Fに 経路を付与 筆者が仕組みを理解するために作成した資料であり、内容に不備がありましたらこっそりとお伝えください。
  16. 16. Edge Cloud におけるK8s の課題 1. Cloud-Native Network の選択は難しい 2. 外部ネットワークからコンテナに接続するためのソリュー ションは検討が必要(OpenStack でいう Floating IP が欲し い) 3. Cloud-Native Storage は API が用意されたばかり 4. Cloud-Native アプリの継続的デリバリ(CI/CDのCD)のノウハ ウが日本で不足している 16
  17. 17. アジェンダ • なぜコンテナ技術にフォーカスするのか • コンテナ技術の最新トレンド • デモンストレーション(Kubernetes & Spinnaker) 17
  18. 18. 18 5/2-4 KubeCon EU @Copenhagen 5/21-24 OpenStack Summ @Vancouver
  19. 19. KubeCon/CloudNativeCon EU 2018 • Cloud Native Computing Foundation が主催 • 年3回開催 • 春(5月): ヨーロッパ、秋(11月): 中国、冬(12月): 北米 • 今回は Denmark の Copenhagen で開催 • Kubernetes と関連技術に関するグローバルなカンファレンス • Google や Amazon や Microsoft などの大手クラウドサービスプロバ イダが参加 • 4,000人を超える参加者 • 日本からは60名ほど参加 • エンドユーザが6割(Yahoo!やサイバーエージェントなど) • NTTの研究所から5名ほど参加 19
  20. 20. OpenStack Summit Vancouver 2018 • OpenStack Foundation が主催 • 年2回開催 • 今回は Canada の Vancouver で開催 • OpenStack を中心に Open Infrastructure に関するカンファレンス • コンテナと NFV/Edge についての話が多かった • テーマを決めて参加者同士がディスカッションする “Forum” の評価は高い • 運用者同士が運用課題についてディスカッションする文化がある • 3,000人の参加者 • 日本からは100人ほど参加 • OpenStack Summit 恒例の Japan Night に45名参加いただきました 20
  21. 21. 気になったコンテナソリューション KubeCon はもちろん、OpenStack Summitでもコンテナ関連の発表 はたくさんありました。 その中で2つのコンテナソリューションを紹介します。 • Airship • Kata Container 21
  22. 22. 22 “The OpenStack and Kubernetes Smørrebrød (Open Sandwich)”より引用
  23. 23. OpenStack on Kubernetes 23 Under Cloud Over Cloud Server Server Server Server Server Server Server Server Server Server Server Server Server Server Server Server Server Server Server Server Server Server Server Server Control Plane Control Plane Control Plane Control Plane Control Plane Control Plane Control Plane Control Plane Control Plane Contain er node Contain er node Control Plane Contain er node Control node Control node Control node Control node Control node Control node Control node Compute node Compute node Control node Compute node 1. Single Node Bootstrap 2. Expand Control Plane 3. Deploy Additional Masters 4. Deploy Compute Hosts Kubeadm Self-hosted Deployment •Keystone •Nova •Glance •Heat •Ironic •Ceph Discover baremetal servers using Ironic
  24. 24. airship-in-a-bottle airship-in-a-bottle は Airship の1台構成を構築するためのスクリプト Airship を試してみた – 仮想化通信 https://tech.virtualtech.jp/entry/2018/07/19/175614 % sudo -i # mkdir -p /root/deploy && cd "$_" # git clone https://github.com/openstack/airship-in-a-bottle # cd /root/deploy/airship-in-a-bottle/manifests/dev_single_node # ./airship-in-a-bottle.sh 24
  25. 25. Kata Containers • Container Runtime の一つ • OpenStack Summit Vancouver 2018でv1.0をリリース • 軽量のハイパーバイザー上でコンテナを動作 • OCI(Open Container Initiative) と CRI(Kubernetes Container Runtime Interface) に対応 • OCI: コンテナランタイムおよびコンテナイメージの標準仕様 • CRI: Kubernetesとコンテナランタイムと間のAPI仕様 • コンテナ環境でのマルチテナントを実現 • Hardware Offload や SR-IOV 対応に期待 25
  26. 26. 26 “Kata Containers – The speed of containers, the security of VMs”より引用
  27. 27. 27 “Kata Containers – The speed of containers, the security of VMs”より引用
  28. 28. Kata Containers Install Kata Containers on Ubuntu https://github.com/kata-containers/documentation/blob/master/install/ubuntu-installation-guide.md Install Docker for Kata Containers on Ubuntu https://github.com/kata-containers/documentation/blob/master/install/docker/ubuntu-docker-install.md host$ sudo -s コンテナーの起動 host# docker run --name=cont1 -it alpine ash /# PSコマンドの実行 host# ps aux|grep /usr/bin/qemu-lite-system-x86_64 コンテナーリストの表示 host# kata-runtime list 28
  29. 29. gVisor • Container Runtime のひとつ • Google がオープンソースで公開 • コンテナ上のシステムコールをフックし、実行を制御すること で、セキュアなコンテナ環境を実現 gVisorについて日本語で読める(聞ける)素晴らしい解説たち http://write.kogus.org/articles/TLdiW6 GCPUG Tokyo gVisor Day July 2018 https://gcpug-tokyo.connpass.com/event/90909/ 29
  30. 30. 再掲)Edge CloudにおけるK8s の課題 1. Cloud-Native Network の選択は難しい 2. 外部ネットワークからコンテナに接続するためのソリュー ションは検討が必要(OpenStack でいう Floating IP が欲し い) 3. Cloud-Native Storage は API が用意されたばかり 4. Cloud-Native アプリの継続的デリバリ(CI/CDのCD)のノウハ ウが日本で不足している 30
  31. 31. • Calico の深掘りと Tungsten Fabric と Cilium の調査 • SmartNIC などと組み合わせて、コンテナ環境での仮想ネット ワークの高速化を試してみたい 1. Cloud-Native Network • Edge Cloud の検証環境では Flannel と Calico を稼働済み • NFV Cloud での経験により、仮想ネットワークの高速化や可視 化を課題設定することは多い • DPDK、SR-IOV、VPP、eBPF、など • ハードウェアオフロード • ポートフォワードなどを効率よく実行する仕組み 31
  32. 32. 2. 外部ネットワークからコンテナに接続 • 外部ネットワークからコンテナに接続するためのソリューション の検討が必要(OpenStack でいう Floating IP が欲しい) 1. Hardware LoadBlancer を使うために“type LoadBalancer”を実装 2. Octavia、Heptio Gimbal の利用など • 要件に応じて適用するソリューションを選択することになる “オンプレでも GKE Like な Ingress を使うために 自作 Ingress Controller を実装してみた”より引用 https://adtech.cyberagent.io/techblog/archives/3758 “Kubernetes をいじって Hardware LoadBalancer で “type LoadBalancer” を実現してみた”より引用 https://adtech.cyberagent.io/techblog/archives/3127 32
  33. 33. • Ceph/Rook と Gluster の調査 • Rook は好感触。StorageBackend を BlueStore 、 Storage を SSD にして調査をしてみたい。 3. Cloud-Native Storage • Persistent Volumes で、Dynamic Volume Provisioning に対応 している On-premise ストレージは現状少ない • Ceph • Gluster • OpenEBS • OpenSDS • Rook、など 33
  34. 34. 4. 継続的デリバリのノウハウ不足 Edge Cloud での環境構築・設定変更における課題 • Edge Cloud の個々の Edge Node は全国に数千ある基地局を想定 →ゼロタッチプロビジョニング(遠隔地での環境構築・設定) →環境構築・テストの自動化 34 • Airship プロジェクトによる環境構築の自動化は好印象 • ゼロタッチプロビジョニングも視野に入れた検証を行ってみたい • Spinnaker による継続的デリバリに強い興味を持つ • 帰国後に Spinnaker の深掘りを目的とした調査を開始
  35. 35. アジェンダ • なぜコンテナ技術にフォーカスするのか • コンテナ技術の最新トレンド • デモンストレーション(Kubernetes & Spinnaker) 35
  36. 36. Spinnaker は継続的デリバリーの 実現を支援するツール 動かすのに職人的なスキルは無くてOK Netflix が開発・運用し、後にGoogleが参加 Spinnakerとは 36
  37. 37. CI/CDにおける課題 アプリケーションのデプロイ 37 apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 yamlの作成 kubectl create -f nginx.yaml
  38. 38. コマンドによるデプロイの課題 38 • デプロイの一貫性がない • 安全性が低い • デプロイの履歴が管理されない
  39. 39. デモシナリオ 39 ① 開発者 ② 承認者 ③ 運用者 開発環境 本番環境 Push 判断 OK or NG Devel Auto Deploy Prod Auto Deploy Manual Judgement Monitor Rollback Deploy Deploy
  40. 40. 40
  41. 41. 41
  42. 42. Kubernetes & Spinnaker デモンストレーション 42
  43. 43. Spinnaker のメリット 43 • デプロイ自動化を比較的容易に実装できる • パイプラインによりデプロイの安全性を高め、 進捗を管理できる • クラスタやポッドの状態を可視化し、健全であ るかを把握できる • ロールバックを安全に実施できる
  44. 44. Spinnaker の課題 44 • パイプラインの設計・設定 • ナレッジの量 • マシンリソースの消費量
  45. 45. Spinnaker 環境構築&設定 Spinnaker 環境の構築とパイプラインの設定方法を ブログ記事にしました。 Kubernetes クラスタへ Spinnaker を構築 https://tech.virtualtech.jp/entry/2018/05/23/134107 Spinnaker のパイプラインによる自動デプロイ https://tech.virtualtech.jp/entry/2018/06/25/180834 45
  46. 46. Questions 46
  47. 47. 参考)仮想化通信 コンテナ関連記事1 Spinnakerのパイプラインによる自動デプロイ https://tech.virtualtech.jp/entry/2018/06/25/180834 KubernetesクラスタへSpinnakerを構築 https://tech.virtualtech.jp/entry/2018/05/23/134107 Jujuで構築するKubernetesでGPUを使うには https://tech.virtualtech.jp/entry/2018/03/28/113217 Jujuでデプロイするサービスを追加する方法 https://tech.virtualtech.jp/entry/2018/07/04/120958 KubernetesでPodを作る方法 https://tech.virtualtech.jp/entry/2018/04/06/100843 Kubernetesと永続ストレージの使い方 https://tech.virtualtech.jp/entry/2018/05/28/190542 47
  48. 48. 参考)仮想化通信 コンテナ関連記事2 Kubernetesで永続ストレージを構築するツールのRook(の最新版)を使う https://tech.virtualtech.jp/entry/2018/07/17/121740 JujuでCalicoを使ったKubernetes環境を構築する(前編) https://tech.virtualtech.jp/entry/2018/06/15/115735 JujuでCalicoを使ったKubernetes環境を構築する(後編) https://tech.virtualtech.jp/entry/2018/06/15/162143 Juju + MAAS を使用したOpenstack構築 + 監視設定 https://tech.virtualtech.jp/entry/2018/04/24/131339 Juju + MAAS を使用したKubernetes構築 + 監視設定 https://tech.virtualtech.jp/entry/2018/03/29/104216 Airshipを試してみた https://tech.virtualtech.jp/entry/2018/07/19/175614 48

Editor's Notes

  • This slide is AT&T‘s MEC High level Architecture.
    Right side of slide is Centralized Cloud, called “Core Network”.
    Left side of slide is Radio network for Mobile Network.
    Center side of slide is Edge Cloud using Edge Computing.
    Upper side of slide is NFV MANO. NFV MANO is Orchestrator for Telecom service networks.
    NFV MANO manage Centralized Cloud and Edge Cloud.
  • This is Edge Computing + GPUs Architecture.
    The upper side of slide is Edge Controller.
    The bottom side of slide is Container nodes/Compute nodes.
    For several use-case for edge computing, we will prepare variable type of Container nodes.
  • This slide is Kubernetes vs Kubernetes on OpenStack.

    Kubernetes is good solution. Light weight controller and built-in auto-healing.
    But, today’s Kubernetes is no Multi-tenant and no network policy related SDN.
    If needed, we are choose Kubernetes on OpenStack.
  • “Kata Containers – The way to run virtualized containers”より引用
  •  こんにちは、コムシス情報システムの山本です。
     日本仮想化技術株式会社さんと一緒に、KubernetesやSpinnaker等の
     新技術を研究しました。
     今回得られた知見を、ここに来て頂いた皆様へお渡しできればと思います。
  •  Kubernetesについてはご存知の方も多いかと思いますが、
     Spinnakerとはなんでしょうか。
     
     Spinnakerは継続的デリバリーの実現を支援するツールです。
     
     職人的なスキル、スクリプトがなくても継続的デリバリー環境を
     構築できます。
     
     ちなみにSpinnakerは動画配信で有名Netflixが開発し、
     後にGoogleも開発へ参加、2015年にオープンソース化されました。
     なぜ彼らはSpinnakerをというもの必要としたのでしょうか。
  •  ここで少しKubernetesのアプリケーションデプロイについてのお話。
     
     Kubernetesへのアプリケーションデプロイは、PODと呼ばれる単位で行われます。
     
     具体的なデプロイ方法は、yamlというテキストにインフラ構成を記述、
     これをKubernetesのコマンド「kubectl」を実行し
     Kubernetesクラスタへデプロイさせます。
  •  コマンドによるデプロイというのは、課題がいくつかあると思ってまして、
     例えばデプロイの一貫性が無く、安全性が低かったり、履歴がきちんと
     管理されなかったり。
     
     Spinnakerはこのあたりの問題をうまく解決するように実装されてまして、
     Kubernetesの機能も上手に使いつつ、すばやく・安全にアプリケーションを
     デプロイできるようになります。
  •  今回行うデモの全体像です。
     Spinnakerは、画面中央に描いております3つのパイプラインを動作させ
     開発環境と本番環境の両方のKubernetesにPODをデプロイをします。
     
     まずはじめに画面左側の開発者がgitに対してCodeをPushすると、
     Dockerhubがコンテナイメージを作成、
     
     コンテナイメージが出来上がると、左のパイプラインがそれを検知し
     開発環境へ自動的にPODをデプロイします。
     
     次は真ん中のパイプラインが動作します。
     このパイプラインは承認者へ本番環境へのデプロイしてよいかを伺います。
     
     承認された場合、右のパイプラインが動作し、本番環境へPODをデプロイします。
     
     運用者は、必要に応じてSpinnakerからPODをロールバックします。
  •  これがSpinnakerのクラスタ画面です。
     PODをどの環境にどれだけ配置するかを規定したものとなります。
     
     今回は単一の環境「local」しか表示されてませんが、
     SpinnakerはGoogleのGKE、AmazonのEKS
     といった複数のクラウドサービスを横断できます。
  •  これがSpinnakerのパイプライン画面です。
     Clusterを何を起点にし、いつのタイミングで操作するかを規定します。
  •  それでは、デモを行っていこうと思います。
     今回のデモは動画を撮りましたので、そちらを御覧ください。

     実際に動作させた映像です。
     Githubで管理しているアプリケーションがあります。
     このアプリケーションのコンテンツを編集、バージョン表記と画像を差し替えます。
     編集をコミットします。
     コミットが完了しました。
     
     Github側でのコミットをトリガとして、今度はDockerhubが動作、
     イメージのビルドを始めます。
     ビルドディティールをみるとキューが入っているのがわかりますね。
     ビルドが完了すると、Spinnakerが動き始めます。
     
     コンテナイメージのビルド完了を契機に、開発環境へのデプロイパイプラインが
     動作し始めました。
     開発環境へのポッド作成と古い環境の破棄を行っています。
     
     詳細画面を表示すると、デプロイされたポッド名がわかります。
     Kubernetes側からkubectlコマンドを打って確認してみます。
     
     ポッドのリストを取得するコマンドを送ります。
     一覧が表示されました。
     
     上の方に先程Spinnakerで表示されていたのと同じ名前のポッドが確認できました。
     Spinnakerによってポッドが正常にデプロイされています。
     
     Spinnakerがどのような設定でデプロイを行ったかのyamlファイルを
     ここで閲覧することもできます。
     
     実際のコンテンツはどうでしょうか。
     はい、コンテンツのバージョン表記及び画像がさしかえられています。
     正常にデプロイができたようです。
     
     画面を戻すと次のパイプラインが起動しているのがわかります。
     承認者へ確認を行うパイプラインです。
     開発環境へのデプロイは先程正常に行われたと判断できましたので、
     Continueを押して続行します。
     
     すると三本目のパイプライン、本番環境へのデプロイパイプラインが動作します。
     完了したので一本目と同様に結果を見ていきましょう。
     
     本番環境へはこの名前でデプロイしたようです。
     Kubernetes上からもPodのデプロイが確認できました。
     
     コンテンツはどうでしょう、更新されました。
     これで開発環境と同じ状態になりました。
     
     もし、デプロイしたアプリケーションに何か問題があった場合。
     SpinnakerではRollbackも行うことができます。
     
     起動中のグループを選択し、Rollbackを実行して確認します。
     どうやらロールバック可能なバージョンは過去4つがあるようです。
     バージョンを一つ前のものに選択し、Submitします。
     
     こうするとSpinnakerがKubernetesの設定を変更し、過去のバージョンの
     ポッドに通信を振り分ける設定を行います。
     ポッドの状態を見てみましょう。
     
     Spinnakerで行ったロールバックはロードバランサの振り分けを変更して
     行うので、ポッドは起動したままとなっています。
     
     コンテンツがロールバックされたか確認します。
     バージョン表記と画像が以前の状態に戻っていることが確認できました。
  •  デモ映像は以上です。
     こういった自動化の仕組みをSpinnakerで比較的容易に実装できます。
     
     パイプライン化されたデプロイは自動化・定型化を提供しますので、
     安全性を高め、進捗を管理できたり、証跡を取得できます。
     
     ポッドの状態を可視化してくれますので、システムが健全か確認できます。
     
     ロールバックが必要になった際に、安全に実施できる仕組みがある点も重要です。
  •  課題もいくつかあります。
     パイプラインは設定項目が豊富に存在するため、きちんと設計と設定を
     行う必要があります。
     
     現時点ではまだまだ発展中のプロダクトであるため、ナレッジも少なめです。
     ある程度トライ&エラーをこなす必要があるでしょう。
     
     マシンリソースも結構消費します。
     今回はKubernetes上にSpinnaker自体構築していますが、
     メモリを合計で12GBくらいを消費していました。
  •  Spinnakerの環境構築や設定は、ブログにて掲載しています。
     これが何方かの役にたてば嬉しいですし、
     皆様ともこうした情報を交換できれば幸いです。
     私からは以上です、ありがとうございました。

×