Slide 1
Slide 1 text
最強のリアルタイムQA投稿アプリを
Cloud Nativeに作ってみた
Cloud Native Developers JP
1
Japan Container Days v1812
Slide 2
Slide 2 text
自己紹介
• 早川 博（はやかわ ひろし）
• 日本オラクル所属
– ソリューション・アーキテクト的な何か
– Containers, Microservices, DevOps
• ErgoDoxユーザー
2
@hhiroshell
Slide 3
Slide 3 text
cndjp - Cloud Native Developers JP
• Cloud NativeなOSSスタックを取り上げる勉強会シリーズ、
およびコミュニティ
• OSS中心（最近はOSSとも限らない傾向）
• 楽しく学ぶ、深く学ぶ
3
Slide 4
Slide 4 text
4
Slide 5
Slide 5 text
cndjp 運営メンバー
• クラウドベンダー、SIer、渋谷系の混成チームで運営しています
5
hhiroshell cotoc
capsmalt nari_trials
nnao45
kitasarah yosshi_
translucens sugimount
ベンダー！ SIer !!
シブヤ！
Slide 6
Slide 6 text
cndjpの歴史 (Season 1)
6
● cndjp発足
● 第1回勉強会 (41)
運営メンバー
取り上げた技術
2017/11
● 第2回勉強会 (31)
2017/12
● 第3回勉強会 (29)
2018/1
● 基礎編第1回 (74)
2018/2
● 第4回勉強会 (71)
2018/3
● 第5回勉強会 (118)
2018/4
Slide 7
Slide 7 text
cndjpの歴史 (Season 2)
7
● 第6回勉強会 (77)
運営メンバー
取り上げた技術
2018/6
● 第7回勉強会 (176)
2018/7
● 第8回勉強会 (145)
2018/10
● Japan Container Days 1812
2018/12
● 新ロゴ完成
● 新ロゴステッカー作成
● リアルタイムQAアプリ
「Qicoo」 開発開始
Slide 8
Slide 8 text
新ロゴ ステッカーを大量に作りました
• 新ロゴ誕生を記念して、
ステッカーを大量に作りました。
• ゲットしたい方は…
– 直接お申し出ください
– または、次回以降のcndjp勉強会でお知らせ
ください
8
Slide 9
Slide 9 text
cndjpの歴史 (Season 2)
9
● 第6回勉強会 (77)
運営メンバー
取り上げた技術
2018/6
● 第7回勉強会 (176)
2018/7
● 第8回勉強会 (145)
2018/10
● Japan Container Days 1812
2018/12
● 新ロゴ完成
● 新ロゴステッカー作成
● リアルタイムQAアプリ
「Qicoo」 開発開始
今日はこれの話です。
Slide 10
Slide 10 text
本日Qicooアプリを初実戦投入いたします！
• 本セッションに関する質問は、最強のリ
アルタイムQA投稿アプリにて受け付け
ます。
• https://qicoo.tokyo/
10
i 投稿いただいた質問データは、アプリの改善や今後よりよい機能を開発するうえでの
参考データとして保存・活用させていただきます。
個人や端末と紐づけて質問が保存されることはありません。
Slide 11
Slide 11 text
Qicooプロジェクトのモチベーション
11
勉強会であまり質問が出ない。せっかくのエンジニアが
集まる場で、インタラクションがないのはもったいない！
Cloud Nativeな技術を注ぎ込んで何か開発したいっす！
QAアプリ…？ ほほう…。
理想のQAアプリを作ってみよう！
コミュニティのボランティアベースでどこまでできるのか？
どういう開発のやり方ができるのか？会議は？
コミュニケーションは？費用の問題は…？
Slide 12
Slide 12 text
約3ヶ月：Qicooプロジェクトの開始！
12
Slide 13
Slide 13 text
やってみてどうだった？- コミュニケーションの工夫
• 無料のオンラインツールをフル活用
– ドキュメンテーション: Scrapbox
– タスク管理: Trello
– 日常のコミュニケーション: Slackの専用チャンネル
– オンライン会議（適宜）: Discord（画面共有しながら）
• これらのツールをフル活用すると、対面で打ち合わせする頻度をかなり
抑えられる。大体1回／月で済んだ
• 費用はゼロ。リモートでも無理なく作業を進められる
13
Slide 14
Slide 14 text
やってみてどうだった？- 費用の工夫
• 開発期間: 約3ヶ月(9/7～12/4)
• ロゴのほうがお金かかったw
• クラウドを必要ないときに確実に
落とす工夫（後述）
14
新ロゴ
ステッカー作成
ドメイン名 (99円/年)
AWS
GCP
新ロゴ
デザイン費
合計
63,834円
Slide 15
Slide 15 text
やってみてどうだった？
• 技術的な障害を乗り越えるパワーに感銘
– スキルの高さと吸収の速さ
– Slackにヘルプすると、皆の知恵が総動員されて短期間で解決に至る
• 本業を抱えながら、労力をOSS開発に注ぐのはやはり難しい
– 油断すると作業が滞りがちになる（しかたない）
– プロジェクトメンバーのモチベーションに支えられた面が大きいのは
反省点。メンバーに感謝
• 費用面は意外となんとかなる
– 我々はエンジニア、テクノロジーを活用して費用を抑えよう
（少しだけ後述）
15
Slide 16
Slide 16 text
自己紹介
16
Slide 17
Slide 17 text
17
自己紹介
@sugimount
● 杉山 卓（すぎやま すぐる）
● ネットワンシステムズ株式会社 所属
● 主な技術：Kubernetes, OpenStack
● 趣味：ベース
Slide 18
Slide 18 text
18
ネットワンシステムズの取り組み SD-HCI3.0
Slide 19
Slide 19 text
目次
19
Slide 20
Slide 20 text
目次
Qicooで利用しているAWSサービスについて
Qicoo Architecture
Qicooの技術要素紹介
CI/CD深堀り
Spinnaker Pipeline入門編
20
1
2
3
4
5
Slide 21
Slide 21 text
目次
Qicooで利用しているAWSサービスについて
Qicoo Architecture
Qicooの技術要素紹介
CI/CD深堀り
Spinnaker Pipeline入門編
21
1
2
3
4
5
最後にQicooの質問に回答します！
基本的には★の多い順に回答してい
きます
Slide 22
Slide 22 text
目次
Qicooで利用しているAWSサービスについて
Qicoo Architecture
Qicooの技術要素紹介
CI/CD深堀り
Spinnaker Pipeline入門編
22
1
2
3
4
5
Slide 23
Slide 23 text
Qicoo で利用している
AWSサービスについて
23
Slide 24
Slide 24 text
利用しているAWSサービス
QicooではAWSを使用してアプリケーションを稼働
利用しているAWSサービスを簡単に紹介
24
Slide 25
Slide 25 text
EKS
25
利用しているAWSサービス
EC2 ElastiCache (Redis)
RDS (MySQL)
Kubernetesコントロールプレーンの
管理・運用をAWS側で提供する
マネージドサービス
コンピューティングリソースを提供
仮想サーバを起動
EKSのNodeとして
EC2インスタンスを利用
マネージド型の
リレーショナルデータベースサービス
QicooではMySQLエンジンを利用
マネージド型のインメモリデータストア
RedisとMemcachedを利用可能
QicooではRedisを利用
Slide 26
Slide 26 text
CloudFront
26
利用しているAWSサービス
Route53 Certificate Manager
S3
低レイテンシーの高速転送
コンテンツ配信ネットワークサービス(CDN)
可用性が高くスケーラブルな
クラウドドメインネームシステム(DNS)
拡張性と耐久性を兼ねそろえた
オブジェクトストレージ
99.999999999%の高い耐久性
SSL/TLS証明書のプロビジョニング、
管理をするためのサービス
httpsアクセスのために利用
Slide 27
Slide 27 text
目次
Qicooで利用しているAWSサービスについて
Qicoo Architecture
Qicooの技術要素紹介
CI/CD深堀り
Spinnaker Pipeline入門編
28
1
2
3
4
5
Slide 28
Slide 28 text
Qicoo Architecture
29
Slide 29
Slide 29 text
30
Qicoo Architecture
Slide 30
Slide 30 text
31
Qicoo Architecture
1. https://qicoo.tokyo/
を名前解決
Slide 31
Slide 31 text
32
Qicoo Architecture
2-1. CloudFrontにアクセス
S3バケットに格納している
静的ファイル(HTMLなど)を取得
2-2. SSL/TLS 証明書の管理
Slide 32
Slide 32 text
33
Qicoo Architecture
3. ブラウザ上に静的ファイルが表
示
Slide 33
Slide 33 text
34
Qicoo Architecture
4. 現在の質問一覧を取得するために、
QicooAPIを名前解決
https://api.qicoo.tokyo/
Route53のレコードは、ExternalDNSで
マニフェストから自動登録
Slide 34
Slide 34 text
35
Qicoo Architecture
5-1. ELB(CLB)経由で
EKS上に稼働している
QicooAPI(Pod)にアクセス
5-2. SSL/TLS 証明書の管理
(Manifestで指定)
Slide 35
Slide 35 text
36
Qicoo Architecture
6. QicooAPIはデータストア
(ElastiCache/RDS)へ質問データを
取りに行く
Slide 36
Slide 36 text
37
Qicoo Architecture
7. ElastiCache(Redis)に
質問データが存在していればRedis
から取得。
存在しない場合は
RDS (MySQL)からデータを取得
Slide 37
Slide 37 text
38
Qicoo Architecture
8. Clientに質問データ(JSON)が
Responseされ、ブラウザ上で
質問一覧が表示される
Slide 38
Slide 38 text
目次
Qicooで利用しているAWSサービスについて
Qicoo Architecture
Qicooの技術要素紹介
CI/CD深堀り
Spinnaker Pipeline入門編
39
1
2
3
4
5
Slide 39
Slide 39 text
Front
40
Slide 40
Slide 40 text
41
Front
このあたり
Slide 41
Slide 41 text
Front
Language, Framework : TypeScript, React, Redux, Bootstrap
主担当： @translucens
ブラウザでQicooを開いた時の表示部分
CircleCI上で静的ファイルを生成し、それらをS3バケットに格納
エンドユーザにはCDN (CloudFront) 経由で配信
42
Slide 42
Slide 42 text
Backend(REST API)
43
Slide 43
Slide 43 text
44
Backend (REST API)
このあたり
Slide 44
Slide 44 text
Backend (REST API)
Language : Golang
主担当： @sugimount
FrontからのRequestに応じて、JSONをResponseするREST API
45
Slide 45
Slide 45 text
Backend (REST API)
curlを使用した質問情報取得実行例
46
■
イベントID
質問取得の開始番号
質問取得の終了番号
ソート種別
昇順降順
Slide 46
Slide 46 text
Backend (REST API)
curlを使用した質問情報取得実行例
47
■
世界平和の方法を教えてください！
Clientは左記JSONを受け取り、
画面に描画
Slide 47
Slide 47 text
CI/CD
53
Slide 48
Slide 48 text
54
CI/CD
このあたり
Slide 49
Slide 49 text
CI/CD
CI : TravisCI
Manifest : Kustomize
CD : Spinnaker
CI主担当： @hhiroshell
CD主担当： @sugimount
詳細は後ほど！
55
Slide 50
Slide 50 text
Auto UP/DOWN
56
Slide 51
Slide 51 text
57
Auto UP/DOWN
全体的に
Slide 52
Slide 52 text
Auto UP/DOWN
EKSを始めとしたAWSサービスはすべて自腹
コスト削減のため、自動的に環境をUP/DOWNする仕組みを用意
HeptioArk, Ansible, Python(SlackBot), CloudFormation など
主担当： @nnao45
58
Slide 53
Slide 53 text
Auto UP/DOWN
SlackでChatbotを提供
「上げて」と打つと、QicooのAWS環境がクレイジーに立ち上がる
59
Slide 54
Slide 54 text
EKSでサービス公開
62
Slide 55
Slide 55 text
EKSでサービス公開
Qicooでは、ExternalDNSを利用し、サービスを任意のFQDNで公開
Kubernetes上でServiceやIngressを作成する際に、公開したいFQDNを
指定することで、自動的に パブリッククラウドのDNSサービスに
名前解決用のAレコードが登録される。
AWS Route53, Azure DNS,
Google Cloud DNS, Oracle Cloud Infrastructure DNS など
https://github.com/kubernetes-incubator/external-dns
Slide 56
Slide 56 text
EKSでサービス公開
以下の流れで、任意のドメインを指定しEKSでhttpsサービス公開を実施
1. お名前.comなどでドメインを購入
2. 購入したドメインを指定して、Amazon Route53でHostedZoneを作成
3. HostedZoneのNSレコードに登録されている値をお名前.comに登録
4. Amazon Certificate ManagerでSSL/TLS証明書を作成
5. EKSにExternalDNSをデプロイ
6. EKSでannotationを付与したServiceを作成することで、
任意のドメインでhttpsサービス公開が可能
Slide 57
Slide 57 text
EKSでサービス公開
ServiceType : LoadBalancerのマニフェスト指定を抜粋
…
指定したドメインで
Serviceが公開
HTTPSに関する
ACMの証明書を指定
Slide 58
Slide 58 text
目次
Qicooで利用しているAWSサービスについて
Qicoo Architecture
Qicooの技術要素紹介
CI/CD深堀り
Spinnaker Pipeline入門編
66
1
2
3
4
5
Slide 59
Slide 59 text
CI/CD深堀り
67
Slide 60
Slide 60 text
CI/CD
QicooではCI/CDでGitOpsを実現
Spinnaker + Kayenta でカナリアリリース
使用ツール
CI : TravisCI
Manifest : Kustomize
CD : Spinnaker + Kayenta
68
Slide 61
Slide 61 text
GitOpsとは
Weaveworksから引用
69
https://www.weave.works/technologies/gitops/
意訳：GitOpsはCDの手法の一つ。Gitのみを使用して、
インフラやアプリケーションを宣言的に管理・展開を行う。
Slide 62
Slide 62 text
GitOpsのメリット
- 誰が、いつ、何を変更したのか、をGitでトレース可能
- 新しいアプリケーションになんらかの不具合が有る場合は、
復旧することが容易 (Git上で前のバージョンに戻せばよい)
- kubediff などの比較ツールと連携することで、
「有るべき姿」と「現状の姿」を比較することが出来る
- https://github.com/weaveworks/kubediff
70
Slide 63
Slide 63 text
Spinnakerとは
- Continuous Deliveryツール (継続的デリバリ)
- Netflixが2015年に公開したOSS
- Supported Provider
- Kubernetes v2
- Public Cloud (AWS, Azure, GCP, Oracle など)
- OpenStack
- など
71
Qicooではこれを使用
Slide 64
Slide 64 text
Kayentaとは
- Spinnakerに含まれているコンポーネントのひとつ
- カナリアリリースに関連して、
カナリア分析を行うためのコンポーネント
- 現行バージョンと、新バージョン間で様々なMetricを比較して
正常異常の判断を自動化することが出来る
- Defaultでは含まれていない。手動で有効化する必要がある
72
Slide 65
Slide 65 text
カナリアリリースとは
SpinnakerとKayentaを利用したカナリアリリースの構成を紹介
73
- 現状バージョンと新バージョンのアプリケーションを並行稼働
- 新バージョンへのトラフィックを少量流すことで
影響範囲を小さくする
- 新バージョンの問題が無いことを確認しリリースする手法
Slide 66
Slide 66 text
カナリアリリースとは
通常のサービス提供状態
74
Kubernetesクラスタ
用
個
100%
Slide 67
Slide 67 text
カナリアリリースとは
Base(現行バージョン)とCanary(新バージョン)をDeploy
75
Kubernetesクラスタ
用
個
94%
用
個
用
個
3%
3%
Slide 68
Slide 68 text
カナリアリリースとは
Base(現行バージョン)とCanary(新バージョン)をDeploy
76
Kubernetesクラスタ
用
個
94%
用
個
用
個
3%
3%
Spinnakerは、Podの数によって
Trafficの分量をコントロールする
Istioのように柔軟には出来ない(2018年12月)
Slide 69
Slide 69 text
カナリアリリースとは
Base(現行バージョン)とCanary(新バージョン)をDeploy
77
Kubernetesクラスタ
用
個
94%
3%
3%
用
個
用
個
この状態で一定時間サービス提供を行い、
BaseとCanary間で様々なMetricを比較し、
Canaryに問題が無いことを確認
Slide 70
Slide 70 text
カナリアリリースとは
BaseとCanaryを削除し、Productionをローリングアップデート
79
Kubernetesクラスタ
100%
用
個
Slide 71
Slide 71 text
カナリアリリースをするために実施した設定
1. PrometheusOperatorをEKSに導入
カナリア分析で使用するMetric収集
2. SpinnakerをDeployするためのツール Halyard をUbuntuマシンに導入
3. HalyardでSpinnakerの構成情報をConfig
3.1. Kayentaの有効化
3.2. PrometheusをMetric収集として登録
3.3. Slack通知の有効化
3.4. SpinnakerのデータストアとしてS3の設定
3.5. GitHubの情報を登録
Slide 72
Slide 72 text
カナリアリリースをするために実施した設定
4. Halyardを使用して、EKS上にSpinnakerをDeploy
5. SpinnakerのWebUIを使用してPipelineを設定
spinコマンドで pipeline as a code も可能
詳細はcndjpで！
https://cnd.connpass.com/
1月か2月には
次回開催する
かも
Slide 73
Slide 73 text
CI/CDパイプライン
82
Slide 74
Slide 74 text
cndjpのGithub
• https://github.com/cndjp
83
「github cndjp」でググると、出てくる
githubと本資料を比べて確認すると理解しやすいかも
Slide 75
Slide 75 text
Gitのブランチ戦略
84
master branch
(production)
QicooAPIのGitHub操作をトリガーにして様々な処理が行われる
release branch
(staging)
新たな機能を追加する場合は、
release branchから派生させて実装
ローカル環境で開発なので、CIのみ
Feature A branch
Slide 76
Slide 76 text
Gitのブランチ戦略
85
master branch
(production)
QicooAPIのGitHub操作をトリガーにして様々な処理が行われる
release branch
(staging)
release branchにマージすると、
EKSのstaging環境にCD
Feature A branch
Slide 77
Slide 77 text
Gitのブランチ戦略
86
master branch
(production)
QicooAPIのGitHub操作をトリガーにして様々な処理が行われる
release branch
(staging)
master branchにマージすると、
EKSのproduction環境にCD
Feature A branch
Slide 78
Slide 78 text
CI/CDパイプライン Feature
87
● FeatureブランチのCI/CDパイプライン
Slide 79
Slide 79 text
CI/CDパイプライン Feature
88
● Featureブランチで新たなバージョンのアプリケーションを実装
Slide 80
Slide 80 text
CI/CDパイプライン Feature
89
● GitHubのqicoo-api Repository のFeature branch へPush
Slide 81
Slide 81 text
CI/CDパイプライン Feature
90
● TravisCIが稼働して、テストコード(go test)やgolintを実施
● コスト面からEKSへのCDは無し。開発作業の動作確認はlocalの環境で行う
● 開発環境で依存しているRedisやMySQLなどはDockerを利用してどこでも利用できるように
Slide 82
Slide 82 text
CI/CDパイプライン Staging
91
● release(staging)ブランチのCI/CDパイプライン
Slide 83
Slide 83 text
CI/CDパイプライン Staging
92
● 開発者が手動でPull Request を投げる
Feature branch から release(staging) branchへのPull Request
● レビュワーが確認し、Mergeする
Slide 84
Slide 84 text
CI/CDパイプライン Staging
93
● TravisCIが稼働して、テストコード(go test)やgolintを実施
● TravisCIでDockerBuildを実施して、DockerHubへPush
Imageのtagの形式は、バージョン-日付の形式
例）v0.0.1-20181109-1537
● バージョンと日付を使用しているのは、バージョンの区切り目を示しつつ、
バージョン番号の管理の煩わしさから脱却するため。
Slide 85
Slide 85 text
CI/CDパイプライン Staging
94
● GitHubで公開しているKustomizeを実行するためのrepository(qicoo-api-manifest)を、
TravisCI環境へgit clone
● kustomizeの事前準備として、独自のパラメータファイルを作成
● 独自のパラメータファイルを追加して、GitHubの「qicoo-api-manifest」へPush
独自のパラメータファイルを生成する理由
次の行程へ、
branch情報と、DockerImageのTag情報を伝えるため
Slide 86
Slide 86 text
CI/CDパイプライン Staging
95
● TravisCI環境にKustomizeの実行用goバイナリファイルをダウンロード
● sedを使用してKustomizeで使用する ImageTagの情報を書き換え
○ overlay/staging/kustomization.yamlをsedしてImageTagの情報を書き換え
○ sedではなく、
kustomize edit set imagetag cndjp/qicoo-api:でも出来そうなことが後で分かった
Slide 87
Slide 87 text
CI/CDパイプライン Staging
96
● kustomize build を実施し、staging用のManifestファイルを生成
● ManifestファイルをGitHubの 「qicoo-api-manifest-staging」 へPush
○ kustomizeでbuildしたファイルを、stagging環境専用の独立したrepositoryで管理
○ GitHubを見ればManifestファイルが見えるため、わかりやすい
○ SpinnakerへManifestファイルの受け渡しが容易
● 「qicoo-api-manifest-staging」にはWebhookを設定しており、Spinnakerへイベント通知
Slide 88
Slide 88 text
CI/CDパイプライン Staging
97
● GitHubからWebhookを受け取り、Spinnakerが起動
● Spinnakerには事前にPipelineを設定しており、
GitHub Repository上のマニフェストファイルを使用してEKSへDelivery
Slide 89
Slide 89 text
CI/CDパイプライン Production
98
● master(production)ブランチのCI/CDパイプライン
Slide 90
Slide 90 text
CI/CDパイプライン Production
99
● 開発者が手動でPull Request を投げる
release(staging) branch から master(production) branchへのPull Request
● レビュワーが確認し、Mergeする
Slide 91
Slide 91 text
CI/CDパイプライン Production
100
● TravisCIが稼働して、テストコード(go test)やgolintを実施
● ProductionパイプラインではDocker Build は実施しない
StagingでBuildしたImageをそのまま利用
Slide 92
Slide 92 text
CI/CDパイプライン Production
101
● Stagingパイプラインと同様に、Kustomizeを実行するためのrepositoryを、
TravisCI環境へgit clone
● Stagingパイプラインで生成した独自のパラメータファイルを書き換え
→
● 変更した独自のパラメータファイルをgit addして、GitHubのqicoo-api-manifestへPush
branch を変更することで、kustomize buildの対象を切り替え
tag は、stagingで生成したImageをそのまま使用したいため、変更
無し
Slide 93
Slide 93 text
CI/CDパイプライン Production
102
● kustomize build を実施し、production用のManifestファイルを生成
● ManifestファイルをGitHubの 「qicoo-api-manifest-production」へPush
○ production環境専用の独立したRepository
● qicoo-api-manigest-production にはWebhookを設定しており、Spinnakerへイベント通知
Slide 94
Slide 94 text
CI/CDパイプライン Production
103
● GitHubからWebhookを受け取り、Spinnakerが起動
● Spinnakerには事前にPipelineを設定しており、カナリアリリースが起動
○ Base, Canaryを新たにDeploy
○ Base, Canary間のMetricをPrometheusより取得し、カナリア分析を実施
● 問題がなければ、Production環境で新たなアプリケーションをローリングアップデート
○ Base, Canaryは削除
Slide 95
Slide 95 text
CI/CDをSpinnakerでやってみて所感
- Spinnakerはシンプルな形で利用
- 例えば、Shellを実行するにも、Jenkinsとの連携が必要 (微妙…)
- Spinnakerが外部のリソースを参照する方法は、制約が多い
(GitHubのマニフェスト、DockerHubのイメージ などの外部リソース)
- 何らかのCI + Kustomize + Spinnaker は相性が良い
- CI側でKustomizeを使用してManifestを生成し、
GitHubへPushすることで、シンプルな形でSpinnakerをトリガー
Spinnakerのハマリポイントを回避出来るはず
CI側の構成が若干複雑になるのが難点・・・。
Slide 96
Slide 96 text
目次
Qicooで利用しているAWSサービスについて
Qicoo Architecture
Qicooの技術要素紹介
CI/CD深堀り
Spinnaker Pipeline入門編
105
1
2
3
4
5
Slide 97
Slide 97 text
Spinnaker Pipeline入門編
106
Slide 98
Slide 98 text
Spinnaker Pipeline入門編
SpinnakerでPipelineを構成する時の手順を簡単に紹介
1. Applicationの作成
2. Pipelineの枠組みを作成
3. Stageを設定
カナリアデプロイ
の設定方法の
詳細はcndjpで！
Manifest
をPush
Webhook CD
Slide 99
Slide 99 text
1. Applicationの作成
まず、Applicationを作成
※ Spinnaker側での定義。
AWS・EKS側には何も反映されない
Slide 100
Slide 100 text
1. Applicationの作成
Slide 101
Slide 101 text
2. Pipelineの枠組み作成
Slide 102
Slide 102 text
2. Pipelineの枠組み作成
Pipelineの開始トリガーを指定
Slide 103
Slide 103 text
2. Pipelineの枠組み作成
Slide 104
Slide 104 text
2. Pipelineの枠組み作成
Slide 105
Slide 105 text
2. Pipelineの枠組み作成
GitHub側でも、Webhookの設定が必要
GitHub → Spinnaker への Push
Slide 106
Slide 106 text
2. Pipelineの枠組み作成
GitHub上に存在するFileといった、外部に存
在するリソースを定義することを、
SpinnakerではArtifactと表現
Slide 107
Slide 107 text
2. Pipelineの枠組み作成
Slide 108
Slide 108 text
2. Pipelineの枠組み作成
GitHub上のFileを指定
Slide 109
Slide 109 text
2. Pipelineの枠組み作成
Pipelineの通知も設定可能
Slide 110
Slide 110 text
2. Pipelineの枠組み作成
Slide 111
Slide 111 text
2. Pipelineの枠組み作成
Slide 112
Slide 112 text
3. Stageの設定
Stageとは、SpinnakerのPipelineで
何かしらの動作を行う概念のこと。
1個のPipelineに、複数のStageを設定することが出来る
Slide 113
Slide 113 text
3. Stageの設定
Manifest Fileを使用したDeploy用のStageを選択
※ Qicooでは、kustomizeで生成したManifestを使用
Slide 114
Slide 114 text
3. Stageの設定
GitHub上のmanifestファイルを指定して、EKSへDeployする
Slide 115
Slide 115 text
設定完了
ここまで設定すると、GitHubにManifestをPushすることで、
SpinnakerのPipelineが稼働し、CDすることが可能。
Manifest
をPush
Webhook CD
Slide 116
Slide 116 text
まとめ
125
Slide 117
Slide 117 text
まとめ
- EKSでサービス提供する際に、関連する様々な技術を紹介
- 時間の都合で深く紹介できない部分も多くあるため、
次回 cndjp ではより詳細に Deep にお話する予定
- 皆様の業務に活用いただけますと幸い
126
Slide 118
Slide 118 text
続きは cndjp で！
127
Slide 119
Slide 119 text
質問と回答のコーナー
128
Slide 120
Slide 120 text
Fin.
129