$30 off During Our Annual Pro Sale. View Details »

MeetUpを活性化せよ!最強のリアルタイムQA投稿アプリをCloud_Nativeにつくってみた / JKD v18.12 2W3

cndjp
December 06, 2018
1.2k

MeetUpを活性化せよ!最強のリアルタイムQA投稿アプリをCloud_Nativeにつくってみた / JKD v18.12 2W3

2019/12/05 「Japan Container Days v18.12」Community & Sponsor Dayの発表スライドです。

cndjp

December 06, 2018
Tweet

Transcript

  1. 最強のリアルタイムQA投稿アプリを
    Cloud Nativeに作ってみた
    Cloud Native Developers JP
    1
    Japan Container Days v1812

    View Slide

  2. 自己紹介
    • 早川 博(はやかわ ひろし)
    • 日本オラクル所属
    – ソリューション・アーキテクト的な何か
    – Containers, Microservices, DevOps
    • ErgoDoxユーザー
    2
    @hhiroshell

    View Slide

  3. cndjp - Cloud Native Developers JP
    • Cloud NativeなOSSスタックを取り上げる勉強会シリーズ、
    およびコミュニティ
    • OSS中心(最近はOSSとも限らない傾向)
    • 楽しく学ぶ、深く学ぶ
    3

    View Slide

  4. 4

    View Slide

  5. cndjp 運営メンバー
    • クラウドベンダー、SIer、渋谷系の混成チームで運営しています
    5
    hhiroshell cotoc
    capsmalt nari_trials
    nnao45
    kitasarah yosshi_
    translucens sugimount
    ベンダー! SIer !!
    シブヤ!

    View Slide

  6. 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

    View Slide

  7. cndjpの歴史 (Season 2)
    7
    ● 第6回勉強会 (77)
    運営メンバー
    取り上げた技術
    2018/6
    ● 第7回勉強会 (176)
    2018/7
    ● 第8回勉強会 (145)
    2018/10
    ● Japan Container Days 1812
    2018/12
    ● 新ロゴ完成
    ● 新ロゴステッカー作成
    ● リアルタイムQAアプリ
    「Qicoo」 開発開始

    View Slide

  8. 新ロゴ ステッカーを大量に作りました
    • 新ロゴ誕生を記念して、
    ステッカーを大量に作りました。
    • ゲットしたい方は…
    – 直接お申し出ください
    – または、次回以降のcndjp勉強会でお知らせ
    ください
    8

    View Slide

  9. cndjpの歴史 (Season 2)
    9
    ● 第6回勉強会 (77)
    運営メンバー
    取り上げた技術
    2018/6
    ● 第7回勉強会 (176)
    2018/7
    ● 第8回勉強会 (145)
    2018/10
    ● Japan Container Days 1812
    2018/12
    ● 新ロゴ完成
    ● 新ロゴステッカー作成
    ● リアルタイムQAアプリ
    「Qicoo」 開発開始
    今日はこれの話です。

    View Slide

  10. 本日Qicooアプリを初実戦投入いたします!
    • 本セッションに関する質問は、最強のリ
    アルタイムQA投稿アプリにて受け付け
    ます。
    • https://qicoo.tokyo/
    10
    i 投稿いただいた質問データは、アプリの改善や今後よりよい機能を開発するうえでの
    参考データとして保存・活用させていただきます。
    個人や端末と紐づけて質問が保存されることはありません。

    View Slide

  11. Qicooプロジェクトのモチベーション
    11
    勉強会であまり質問が出ない。せっかくのエンジニアが
    集まる場で、インタラクションがないのはもったいない!
    Cloud Nativeな技術を注ぎ込んで何か開発したいっす!
    QAアプリ…? ほほう…。
    理想のQAアプリを作ってみよう!
    コミュニティのボランティアベースでどこまでできるのか?
    どういう開発のやり方ができるのか?会議は?
    コミュニケーションは?費用の問題は…?

    View Slide

  12. 約3ヶ月:Qicooプロジェクトの開始!
    12

    View Slide

  13. やってみてどうだった?- コミュニケーションの工夫
    • 無料のオンラインツールをフル活用
    – ドキュメンテーション: Scrapbox
    – タスク管理: Trello
    – 日常のコミュニケーション: Slackの専用チャンネル
    – オンライン会議(適宜): Discord(画面共有しながら)
    • これらのツールをフル活用すると、対面で打ち合わせする頻度をかなり
    抑えられる。大体1回/月で済んだ
    • 費用はゼロ。リモートでも無理なく作業を進められる
    13

    View Slide

  14. やってみてどうだった?- 費用の工夫
    • 開発期間: 約3ヶ月(9/7~12/4)
    • ロゴのほうがお金かかったw
    • クラウドを必要ないときに確実に
    落とす工夫(後述)
    14
    新ロゴ
    ステッカー作成
    ドメイン名 (99円/年)
    AWS
    GCP
    新ロゴ
    デザイン費
    合計
    63,834円

    View Slide

  15. やってみてどうだった?
    • 技術的な障害を乗り越えるパワーに感銘
    – スキルの高さと吸収の速さ
    – Slackにヘルプすると、皆の知恵が総動員されて短期間で解決に至る
    • 本業を抱えながら、労力をOSS開発に注ぐのはやはり難しい
    – 油断すると作業が滞りがちになる(しかたない)
    – プロジェクトメンバーのモチベーションに支えられた面が大きいのは
    反省点。メンバーに感謝
    • 費用面は意外となんとかなる
    – 我々はエンジニア、テクノロジーを活用して費用を抑えよう
    (少しだけ後述)
    15

    View Slide

  16. 自己紹介
     
    16

    View Slide

  17. 17
    自己紹介
    @sugimount
    ● 杉山 卓(すぎやま すぐる)
    ● ネットワンシステムズ株式会社 所属
    ● 主な技術:Kubernetes, OpenStack
    ● 趣味:ベース

    View Slide

  18. 18
    ネットワンシステムズの取り組み SD-HCI3.0

    View Slide

  19. 目次
    19

    View Slide

  20. 目次
    Qicooで利用しているAWSサービスについて
    Qicoo Architecture
    Qicooの技術要素紹介
    CI/CD深堀り
    Spinnaker Pipeline入門編
    20
    1
    2
    3
    4
    5

    View Slide

  21. 目次
    Qicooで利用しているAWSサービスについて
    Qicoo Architecture
    Qicooの技術要素紹介
    CI/CD深堀り
    Spinnaker Pipeline入門編
    21
    1
    2
    3
    4
    5
    最後にQicooの質問に回答します!
    基本的には★の多い順に回答してい
    きます

    View Slide

  22. 目次
    Qicooで利用しているAWSサービスについて
    Qicoo Architecture
    Qicooの技術要素紹介
    CI/CD深堀り
    Spinnaker Pipeline入門編
    22
    1
    2
    3
    4
    5

    View Slide

  23. Qicoo で利用している
    AWSサービスについて
    23

    View Slide

  24. 利用しているAWSサービス
    QicooではAWSを使用してアプリケーションを稼働
    利用しているAWSサービスを簡単に紹介
    24

    View Slide

  25. EKS
    25
    利用しているAWSサービス
    EC2 ElastiCache (Redis)
    RDS (MySQL)
    Kubernetesコントロールプレーンの
    管理・運用をAWS側で提供する
    マネージドサービス
    コンピューティングリソースを提供
    仮想サーバを起動
    EKSのNodeとして
    EC2インスタンスを利用
    マネージド型の
    リレーショナルデータベースサービス
    QicooではMySQLエンジンを利用
    マネージド型のインメモリデータストア
    RedisとMemcachedを利用可能
    QicooではRedisを利用

    View Slide

  26. CloudFront
    26
    利用しているAWSサービス
    Route53 Certificate Manager
    S3
    低レイテンシーの高速転送
    コンテンツ配信ネットワークサービス(CDN)
    可用性が高くスケーラブルな
    クラウドドメインネームシステム(DNS)
    拡張性と耐久性を兼ねそろえた
    オブジェクトストレージ
    99.999999999%の高い耐久性
    SSL/TLS証明書のプロビジョニング、
    管理をするためのサービス
    httpsアクセスのために利用

    View Slide

  27. 目次
    Qicooで利用しているAWSサービスについて
    Qicoo Architecture
    Qicooの技術要素紹介
    CI/CD深堀り
    Spinnaker Pipeline入門編
    28
    1
    2
    3
    4
    5

    View Slide

  28. Qicoo Architecture
     
    29

    View Slide

  29. 30
    Qicoo Architecture

    View Slide

  30. 31
    Qicoo Architecture
    1. https://qicoo.tokyo/
    を名前解決

    View Slide

  31. 32
    Qicoo Architecture
    2-1. CloudFrontにアクセス
    S3バケットに格納している
    静的ファイル(HTMLなど)を取得
    2-2. SSL/TLS 証明書の管理

    View Slide

  32. 33
    Qicoo Architecture
    3. ブラウザ上に静的ファイルが表

    View Slide

  33. 34
    Qicoo Architecture
    4. 現在の質問一覧を取得するために、
    QicooAPIを名前解決
    https://api.qicoo.tokyo/
    Route53のレコードは、ExternalDNSで
    マニフェストから自動登録

    View Slide

  34. 35
    Qicoo Architecture
    5-1. ELB(CLB)経由で
    EKS上に稼働している
    QicooAPI(Pod)にアクセス
    5-2. SSL/TLS 証明書の管理
    (Manifestで指定)

    View Slide

  35. 36
    Qicoo Architecture
    6. QicooAPIはデータストア
    (ElastiCache/RDS)へ質問データを
    取りに行く

    View Slide

  36. 37
    Qicoo Architecture
    7. ElastiCache(Redis)に
    質問データが存在していればRedis
    から取得。
    存在しない場合は
    RDS (MySQL)からデータを取得

    View Slide

  37. 38
    Qicoo Architecture
    8. Clientに質問データ(JSON)が
    Responseされ、ブラウザ上で
    質問一覧が表示される

    View Slide

  38. 目次
    Qicooで利用しているAWSサービスについて
    Qicoo Architecture
    Qicooの技術要素紹介
    CI/CD深堀り
    Spinnaker Pipeline入門編
    39
    1
    2
    3
    4
    5

    View Slide

  39. Front
     
    40

    View Slide

  40. 41
    Front
    このあたり

    View Slide

  41. Front
    Language, Framework : TypeScript, React, Redux, Bootstrap
    主担当:  @translucens
    ブラウザでQicooを開いた時の表示部分
    CircleCI上で静的ファイルを生成し、それらをS3バケットに格納
    エンドユーザにはCDN (CloudFront) 経由で配信
    42

    View Slide

  42. Backend(REST API)
     
    43

    View Slide

  43. 44
    Backend (REST API)
    このあたり

    View Slide

  44. Backend (REST API)
    Language : Golang
    主担当:  @sugimount
    FrontからのRequestに応じて、JSONをResponseするREST API
    45

    View Slide

  45. Backend (REST API)
    curlを使用した質問情報取得実行例
    46

    イベントID
    質問取得の開始番号
    質問取得の終了番号
        ソート種別
         昇順降順

    View Slide

  46. Backend (REST API)
    curlを使用した質問情報取得実行例
    47

    世界平和の方法を教えてください!
    Clientは左記JSONを受け取り、
    画面に描画

    View Slide

  47. CI/CD
     
    53

    View Slide

  48. 54
    CI/CD
    このあたり

    View Slide

  49. CI/CD
    CI : TravisCI
    Manifest : Kustomize
    CD : Spinnaker
    CI主担当:  @hhiroshell
    CD主担当: @sugimount
    詳細は後ほど!
    55

    View Slide

  50. Auto UP/DOWN
     
    56

    View Slide

  51. 57
    Auto UP/DOWN
    全体的に

    View Slide

  52. Auto UP/DOWN
    EKSを始めとしたAWSサービスはすべて自腹
    コスト削減のため、自動的に環境をUP/DOWNする仕組みを用意
    HeptioArk, Ansible, Python(SlackBot), CloudFormation など
    主担当: @nnao45
    58

    View Slide

  53. Auto UP/DOWN
    SlackでChatbotを提供
    「上げて」と打つと、QicooのAWS環境がクレイジーに立ち上がる
    59

    View Slide

  54. EKSでサービス公開
    62

    View Slide

  55. 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

    View Slide

  56. 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サービス公開が可能

    View Slide

  57. EKSでサービス公開
    ServiceType : LoadBalancerのマニフェスト指定を抜粋

    指定したドメインで
    Serviceが公開
    HTTPSに関する
    ACMの証明書を指定

    View Slide

  58. 目次
    Qicooで利用しているAWSサービスについて
    Qicoo Architecture
    Qicooの技術要素紹介
    CI/CD深堀り
    Spinnaker Pipeline入門編
    66
    1
    2
    3
    4
    5

    View Slide

  59. CI/CD深堀り
    67

    View Slide

  60. CI/CD
    QicooではCI/CDでGitOpsを実現
    Spinnaker + Kayenta でカナリアリリース
    使用ツール
    CI : TravisCI
    Manifest : Kustomize
    CD : Spinnaker + Kayenta
    68

    View Slide

  61. GitOpsとは
    Weaveworksから引用
    69
    https://www.weave.works/technologies/gitops/
    意訳:GitOpsはCDの手法の一つ。Gitのみを使用して、
    インフラやアプリケーションを宣言的に管理・展開を行う。

    View Slide

  62. GitOpsのメリット
    - 誰が、いつ、何を変更したのか、をGitでトレース可能
    - 新しいアプリケーションになんらかの不具合が有る場合は、
    復旧することが容易 (Git上で前のバージョンに戻せばよい)
    - kubediff などの比較ツールと連携することで、
    「有るべき姿」と「現状の姿」を比較することが出来る
    - https://github.com/weaveworks/kubediff
    70

    View Slide

  63. Spinnakerとは
    - Continuous Deliveryツール (継続的デリバリ)
    - Netflixが2015年に公開したOSS
    - Supported Provider
    - Kubernetes v2
    - Public Cloud (AWS, Azure, GCP, Oracle など)
    - OpenStack
    - など
    71
    Qicooではこれを使用

    View Slide

  64. Kayentaとは
    - Spinnakerに含まれているコンポーネントのひとつ
    - カナリアリリースに関連して、
    カナリア分析を行うためのコンポーネント
    - 現行バージョンと、新バージョン間で様々なMetricを比較して
    正常異常の判断を自動化することが出来る
    - Defaultでは含まれていない。手動で有効化する必要がある
    72

    View Slide

  65. カナリアリリースとは
    SpinnakerとKayentaを利用したカナリアリリースの構成を紹介
    73
    - 現状バージョンと新バージョンのアプリケーションを並行稼働
    - 新バージョンへのトラフィックを少量流すことで
    影響範囲を小さくする
    - 新バージョンの問題が無いことを確認しリリースする手法

    View Slide

  66. カナリアリリースとは
    通常のサービス提供状態
    74
    Kubernetesクラスタ


    100%

    View Slide

  67. カナリアリリースとは
    Base(現行バージョン)とCanary(新バージョン)をDeploy
    75
    Kubernetesクラスタ


    94%




    3%
    3%

    View Slide

  68. カナリアリリースとは
    Base(現行バージョン)とCanary(新バージョン)をDeploy
    76
    Kubernetesクラスタ


    94%




    3%
    3%
    Spinnakerは、Podの数によって
    Trafficの分量をコントロールする
    Istioのように柔軟には出来ない(2018年12月)

    View Slide

  69. カナリアリリースとは
    Base(現行バージョン)とCanary(新バージョン)をDeploy
    77
    Kubernetesクラスタ


    94%
    3%
    3%




    この状態で一定時間サービス提供を行い、
    BaseとCanary間で様々なMetricを比較し、
    Canaryに問題が無いことを確認

    View Slide

  70. カナリアリリースとは
    BaseとCanaryを削除し、Productionをローリングアップデート
    79
    Kubernetesクラスタ
    100%


    View Slide

  71. カナリアリリースをするために実施した設定
    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の情報を登録

    View Slide

  72. カナリアリリースをするために実施した設定
    4. Halyardを使用して、EKS上にSpinnakerをDeploy
    5. SpinnakerのWebUIを使用してPipelineを設定
    spinコマンドで pipeline as a code も可能
    詳細はcndjpで!
    https://cnd.connpass.com/
    1月か2月には
    次回開催する
    かも

    View Slide

  73. CI/CDパイプライン
    82

    View Slide

  74. cndjpのGithub
    • https://github.com/cndjp
    83
    「github cndjp」でググると、出てくる
    githubと本資料を比べて確認すると理解しやすいかも

    View Slide

  75. Gitのブランチ戦略
    84
    master branch
    (production)
    QicooAPIのGitHub操作をトリガーにして様々な処理が行われる
    release branch
    (staging)
    新たな機能を追加する場合は、
    release branchから派生させて実装
    ローカル環境で開発なので、CIのみ
    Feature A branch

    View Slide

  76. Gitのブランチ戦略
    85
    master branch
    (production)
    QicooAPIのGitHub操作をトリガーにして様々な処理が行われる
    release branch
    (staging)
    release branchにマージすると、
    EKSのstaging環境にCD
    Feature A branch

    View Slide

  77. Gitのブランチ戦略
    86
    master branch
    (production)
    QicooAPIのGitHub操作をトリガーにして様々な処理が行われる
    release branch
    (staging)
    master branchにマージすると、
    EKSのproduction環境にCD
    Feature A branch

    View Slide

  78. CI/CDパイプライン Feature
    87
    ● FeatureブランチのCI/CDパイプライン

    View Slide

  79. CI/CDパイプライン Feature
    88
    ● Featureブランチで新たなバージョンのアプリケーションを実装

    View Slide

  80. CI/CDパイプライン Feature
    89
    ● GitHubのqicoo-api Repository のFeature branch へPush

    View Slide

  81. CI/CDパイプライン Feature
    90
    ● TravisCIが稼働して、テストコード(go test)やgolintを実施
    ● コスト面からEKSへのCDは無し。開発作業の動作確認はlocalの環境で行う
    ● 開発環境で依存しているRedisやMySQLなどはDockerを利用してどこでも利用できるように

    View Slide

  82. CI/CDパイプライン Staging
    91
    ● release(staging)ブランチのCI/CDパイプライン

    View Slide

  83. CI/CDパイプライン Staging
    92
    ● 開発者が手動でPull Request を投げる
    Feature branch から release(staging) branchへのPull Request
    ● レビュワーが確認し、Mergeする

    View Slide

  84. CI/CDパイプライン Staging
    93
    ● TravisCIが稼働して、テストコード(go test)やgolintを実施
    ● TravisCIでDockerBuildを実施して、DockerHubへPush
    Imageのtagの形式は、バージョン-日付の形式
    例)v0.0.1-20181109-1537
    ● バージョンと日付を使用しているのは、バージョンの区切り目を示しつつ、
    バージョン番号の管理の煩わしさから脱却するため。

    View Slide

  85. CI/CDパイプライン Staging
    94
    ● GitHubで公開しているKustomizeを実行するためのrepository(qicoo-api-manifest)を、
    TravisCI環境へgit clone
    ● kustomizeの事前準備として、独自のパラメータファイルを作成
    ● 独自のパラメータファイルを追加して、GitHubの「qicoo-api-manifest」へPush
    独自のパラメータファイルを生成する理由
    次の行程へ、
    branch情報と、DockerImageのTag情報を伝えるため

    View Slide

  86. CI/CDパイプライン Staging
    95
    ● TravisCI環境にKustomizeの実行用goバイナリファイルをダウンロード
    ● sedを使用してKustomizeで使用する ImageTagの情報を書き換え
    ○ overlay/staging/kustomization.yamlをsedしてImageTagの情報を書き換え
    ○ sedではなく、
    kustomize edit set imagetag cndjp/qicoo-api:でも出来そうなことが後で分かった

    View Slide

  87. 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へイベント通知

    View Slide

  88. CI/CDパイプライン Staging
    97
    ● GitHubからWebhookを受け取り、Spinnakerが起動
    ● Spinnakerには事前にPipelineを設定しており、
    GitHub Repository上のマニフェストファイルを使用してEKSへDelivery

    View Slide

  89. CI/CDパイプライン Production
    98
    ● master(production)ブランチのCI/CDパイプライン

    View Slide

  90. CI/CDパイプライン Production
    99
    ● 開発者が手動でPull Request を投げる
    release(staging) branch から master(production) branchへのPull Request
    ● レビュワーが確認し、Mergeする

    View Slide

  91. CI/CDパイプライン Production
    100
    ● TravisCIが稼働して、テストコード(go test)やgolintを実施
    ● ProductionパイプラインではDocker Build は実施しない
    StagingでBuildしたImageをそのまま利用

    View Slide

  92. CI/CDパイプライン Production
    101
    ● Stagingパイプラインと同様に、Kustomizeを実行するためのrepositoryを、
    TravisCI環境へgit clone
    ● Stagingパイプラインで生成した独自のパラメータファイルを書き換え

    ● 変更した独自のパラメータファイルをgit addして、GitHubのqicoo-api-manifestへPush
    branch を変更することで、kustomize buildの対象を切り替え
    tag は、stagingで生成したImageをそのまま使用したいため、変更
    無し

    View Slide

  93. CI/CDパイプライン Production
    102
    ● kustomize build を実施し、production用のManifestファイルを生成
    ● ManifestファイルをGitHubの 「qicoo-api-manifest-production」へPush
    ○ production環境専用の独立したRepository
    ● qicoo-api-manigest-production にはWebhookを設定しており、Spinnakerへイベント通知

    View Slide

  94. CI/CDパイプライン Production
    103
    ● GitHubからWebhookを受け取り、Spinnakerが起動
    ● Spinnakerには事前にPipelineを設定しており、カナリアリリースが起動
    ○ Base, Canaryを新たにDeploy
    ○ Base, Canary間のMetricをPrometheusより取得し、カナリア分析を実施
    ● 問題がなければ、Production環境で新たなアプリケーションをローリングアップデート
    ○ Base, Canaryは削除

    View Slide

  95. CI/CDをSpinnakerでやってみて所感
    - Spinnakerはシンプルな形で利用
    - 例えば、Shellを実行するにも、Jenkinsとの連携が必要 (微妙…)
    - Spinnakerが外部のリソースを参照する方法は、制約が多い
    (GitHubのマニフェスト、DockerHubのイメージ などの外部リソース)
    - 何らかのCI + Kustomize + Spinnaker は相性が良い
    - CI側でKustomizeを使用してManifestを生成し、
    GitHubへPushすることで、シンプルな形でSpinnakerをトリガー
    Spinnakerのハマリポイントを回避出来るはず
    CI側の構成が若干複雑になるのが難点・・・。

    View Slide

  96. 目次
    Qicooで利用しているAWSサービスについて
    Qicoo Architecture
    Qicooの技術要素紹介
    CI/CD深堀り
    Spinnaker Pipeline入門編
    105
    1
    2
    3
    4
    5

    View Slide

  97. Spinnaker Pipeline入門編
    106

    View Slide

  98. Spinnaker Pipeline入門編
    SpinnakerでPipelineを構成する時の手順を簡単に紹介
    1. Applicationの作成
    2. Pipelineの枠組みを作成
    3. Stageを設定
    カナリアデプロイ
    の設定方法の
    詳細はcndjpで!
    Manifest
    をPush
    Webhook CD

    View Slide

  99. 1. Applicationの作成
    まず、Applicationを作成
    ※ Spinnaker側での定義。
     AWS・EKS側には何も反映されない

    View Slide

  100. 1. Applicationの作成

    View Slide

  101. 2. Pipelineの枠組み作成

    View Slide

  102. 2. Pipelineの枠組み作成
    Pipelineの開始トリガーを指定

    View Slide

  103. 2. Pipelineの枠組み作成

    View Slide

  104. 2. Pipelineの枠組み作成

    View Slide

  105. 2. Pipelineの枠組み作成
    GitHub側でも、Webhookの設定が必要
    GitHub → Spinnaker への Push

    View Slide

  106. 2. Pipelineの枠組み作成
    GitHub上に存在するFileといった、外部に存
    在するリソースを定義することを、
    SpinnakerではArtifactと表現

    View Slide

  107. 2. Pipelineの枠組み作成

    View Slide

  108. 2. Pipelineの枠組み作成
    GitHub上のFileを指定

    View Slide

  109. 2. Pipelineの枠組み作成
    Pipelineの通知も設定可能

    View Slide

  110. 2. Pipelineの枠組み作成

    View Slide

  111. 2. Pipelineの枠組み作成

    View Slide

  112. 3. Stageの設定
    Stageとは、SpinnakerのPipelineで
    何かしらの動作を行う概念のこと。
    1個のPipelineに、複数のStageを設定することが出来る

    View Slide

  113. 3. Stageの設定
    Manifest Fileを使用したDeploy用のStageを選択
    ※ Qicooでは、kustomizeで生成したManifestを使用

    View Slide

  114. 3. Stageの設定
    GitHub上のmanifestファイルを指定して、EKSへDeployする

    View Slide

  115. 設定完了
    ここまで設定すると、GitHubにManifestをPushすることで、
    SpinnakerのPipelineが稼働し、CDすることが可能。
    Manifest
    をPush
    Webhook CD

    View Slide

  116. まとめ
    125

    View Slide

  117. まとめ
    - EKSでサービス提供する際に、関連する様々な技術を紹介
    - 時間の都合で深く紹介できない部分も多くあるため、
    次回 cndjp ではより詳細に Deep にお話する予定
    - 皆様の業務に活用いただけますと幸い
    126

    View Slide

  118. 続きは cndjp で!
    127

    View Slide

  119. 質問と回答のコーナー
    128

    View Slide

  120. Fin.
    129

    View Slide