Download as PDF, PPTX
![Microservices, Service Mesh, and CI/CD Pipelines: Making It All Work Together
Istio + BRIGADE + kashti (WebUI) を使った ServiceMesh + CI/CD 環境
BRIGADE を使うことで
● Event driven な CI/CD Pipeline
○ DockerHub の変更を検知
○ Github の変更を検知
● JavaScript による Pipeline 定義
○ コード化が可能
● 全てを網羅
○ Go binary の作成、Docker Image の作成、Helm Charts の作成、Slack 通知
events.on("exec", () => {
var job = new Job("test", "alpine:3.4")
job.tasks = [
"echo Hello",
"echo World"
]
job.run()
})](https://image.slidesharecdn.com/kubeconcloudnativecon2017-180109203023/85/Kube-con-cloudnativecon-2017-51-320.jpg)
![Building Better Containers: A Survey of Container Build Tools
現状の Dockerfile の問題
● イメージの再現性が乏しい
● Bash での Programmability
● イメージフォーマット間での連携が弱い
Dockerfile 使ってコンテナイメージ作る時代はきっと終わるよ！
[ソースからイメージビルド]
source-to-image (s2i)
buildkit
habitat
詳しくは凄い量になるので、
付録の SpreadSheet で。
[従来方式]
buildah
nixos-container
ansible-container
smith
(distroless)](https://image.slidesharecdn.com/kubeconcloudnativecon2017-180109203023/85/Kube-con-cloudnativecon-2017-53-320.jpg)
Uploaded byMasaya Aoyama
Kube con + cloudnativecon 2017 社内報告会（外部公開用）
KubeCon + CloudNativeCon 2017 NorthAmerica @Austin に参加してきた共有資料になります。 社内向けに Keynote 1 + 2 日目と CI/CD 周りの話をまとめてあります。
![Recap: [Code fresh] Deploying to kubernetes thousands of times per day @kuber...](https://cdn.slidesharecdn.com/ss_thumbnails/codefreshdeployingtokubernetesthousandsoftimesperdaykubernetesmeetup9-180112141040-thumbnail.jpg?width=640&height=640&fit=bounds)
![[External] 2021.12.15 コンテナ移行の前に知っておきたいこと @ gcpug 湘南](https://cdn.slidesharecdn.com/ss_thumbnails/external2021-211216025522-thumbnail.jpg?width=640&height=640&fit=bounds)
Kube con + cloudnativecon 2017 社内報告会（外部公開用）
- 1. KubeCon + CloudNativeCon2017 社内報告会 〜Keystone day 1,2 + CI/CD Sessions〜 青山 真也, CyberAgent adtech studio
- 2. 青山 真也 (MasayaAoyama) @amsy810 普段の主な仕事↓ 世界で 138 番目 https://adtech.cyberagent.io/techblog/ archives/3086
- 3.
- 4. KubeCon + CloudNativeCon2017 @Austin 概要
- 5.
- 6. KubeCon + CNConコンテンツの一覧 Keynote：基調講演 Session：セッション Lightning Talk：LT セッション Salon：特定分野の相談所＋ディスカッションをする場 SIG：特定分野の詳しい話＋ディスカッションをする場 BoF：特定分野の情報交換
- 7. Keynote は満員。別会場で Livestreaming も。
- 8. Sponsor Booth はいろんなSaaS 等もあり興味深い
- 9. All Atendees Party 参加者全員による懇親会 RainyStreet の飲み屋を貸し切り！
- 10. KubeCon Austin 2017日本人会 主催 コペンハーゲンでまたお会いしましょう！
- 11.
- 12. CNCF Executive Directorの Dan Kohn さん 基本的にコミュニティ周りの話 まず、Kubernetes はデファクトとなり、 CloudNative は全体として 1.0 になった 今回は事実上 CNCF の勝利宣言セッションに近い感じ 1: A Community of Builders: CloudNativeCon Opening Keynote
- 14. CNCF がホストするプロジェクトが増加 寄贈もより活発となり、CNCF の全プロジェクトを使うことで CloudNative なアプリケーションが構築可能に 1: A Community of Builders: CloudNativeCon Opening Keynote
- 15. KubeCon の参加者数は一気に激増 今回は KubeConのチケットが完売となりました 1: A Community of Builders: CloudNativeCon Opening Keynote
- 16. Kubernetes は現状かなり活発な OSSとしてデファクトとなりました 1: A Community of Builders: CloudNativeCon Opening Keynote
- 17. 1: A Communityof Builders: CloudNativeCon Opening Keynote Kubernetes の爆発的広がりにつき、Certified Program が開始 Kubernetes Certified Service Provider：コンサル等の認定企業 Certified Kubernetes Administrator：K8s 管理者としての技術認定 Certified Kubernetes Distribution/Platform：K8s としての機能確認
- 18. 1: A Communityof Builders: CloudNativeCon Opening Keynote 2018 年の KubeCon ● KubeCon + CloudNativeCon Europe 2018 ○ コペンハーゲン デンマーク ○ 2018/5/2-4 ● KubeCon + CloudNativeCon China 2018 ○ 上海 中国 ○ 2018/11/14-15 ● KubeCon + CloudNativeCon North America 2018 ○ シアトル アメリカワシントン州 ○ 2018/12/11-13
- 19. 2: CNCF ProjectUpdates 各プロジェクトの Update トピックスを紹介 多くのプロジェクトがこのタイミングで 1.0 化 CNCF からの ● CloudNative は既に Ready かつ ● デファクトスタンダードを確立した とのメッセージに近い印象を受けました
- 20. 2: CNCF ProjectUpdates Kubernetes 1.9 リリース Workload API が app/v1 リリース kube-dns の実装が SkyDNS > CoreDNS に（alpha） CoreDNS 1.0 リリース containerd 1.0 が OCI 準拠な実装としてリリース rktlet が CRI / OCI 準拠な実装としてリリース CNI の IPv6 フルサポート
- 21. 2: CNCF ProjectUpdates Prometheus 2.0 リリース K8s に最適化されたストレージエンジンを導入し、 劇的なパフォーマンス改善 ● CPU 使用率 1/3 以下 ● ディスク使用量半分 ● I/O 数 1/100
- 22. 2: CNCF ProjectUpdates fluentd 1.0 リリース マルチプロセス worker が導入され並列実行可能に sub-second をサポート buffer 最適化により高速化 fluentd forwarder protocol v1 リリースにより高速化 native tls/ssl サポート
- 23. 2: CNCF ProjectUpdates fluentbit リリース C 言語 で書かれた CloudNative な軽量 fluentd 少ないメモリ使用量と CPU 使用率 Event driven / async network IO Build-in TLS/SSL プラグインは使いまわせず現状は 35 個のみ 基本的にコンテナからの forward や簡単な filtering 等を想定
- 24. 3: Accelerating theDigital Transformation OpenStack Foundation が発表した Kata Container の紹介 OCI / CRI に準拠し、Intel Clear Containers と Hyper runV をベースとした実装 コンテナ間でカーネルを共有しないため、よりセキュア スポンサーブースで見てきた感じだと即時起動
- 25. 4: Cloud NativeCD: Spinnaker and the Culture Behind the Tech Netflix の Spinnaker が出来るまでのテクノロジーの歴史 ● 時間区切りで Deploy タイミングを指定する Time Window ● トラフィックガード機能 ● Canary / Blue-Green デプロイ ● Manual Judgement によるデプロイ判断のフロー ● 今後の展望 ○ CI ○ Declartive CD （恐らく 宣言的コードによる CD の設定化） ○ デプロイ方法の詳細を抽象化して提供
- 26. 5: Cloud Nativeat AWS Elastic Kubernetes Service ● コミュニティへの Contribute を元に EKS を改良（Open & Management K8s） ○ kube2iam ■ IAM role を pod に割り当てる（ServiceAccount / RBAC） ○ AWS CNI plugin ■ VM に NIC をアタッチし Pod NW と VPC NW をマッピング ● 各種 AWS Service との Integration ● 3 AZ にまたがって etcd / k8s master が展開 ○ GKE は シングルマスタらしい （一応コンテナ課金の Fargate の紹介もちらっとしてました）
- 27. 6: Service Meshesand Observability OpenTracing を導入することで、複雑な ServiceMesh のデバッグを容易にする ServiceMesh の規模が大きくなると分散トレーシングは必須に API Response が遅いのはどこが影響しているか？ MicroService 化した際に計測するべきところは？
- 28. 7: Kubernetes: ThisJob is Too Hard 例えば Application の bind port を 8080 から 7070 に変える 1. アプリケーションのコードを変えてビルド 2. Dockerfile の EXPOSE を変えてビルド 3. K8s の Service 定義や Pod Template を変えてデプロイ Files Language Tools Application .java, etc Java, etc Editor Docker Dockerfile Dockerfile docker Kubernetes k8s config YAML kubectl
- 29. 7: Kubernetes: ThisJob is Too Hard デプロイフローを工夫すれば一箇所にまとめることも可能 その他の選択肢として Metaparticle の提案 言語上に Annotation を付与して Docker Image 生成と K8s へのデプロイを行なう
- 30. 8: Can 100Million Developers Use Kubernetes? OpenStack、Hadoop のように熟練者でなくても Kubernetes を使えるように 簡単に誰でも使える OpenFaaS を使った Function as a Service プラットフォーム
- 31. 8: Can 100Million Developers Use Kubernetes? 開発者はコードを書いて OpenFaaS に登録するだけ Docker Image 登録は OpenFaaS にお任せ HTTP Path > Function の登録を行なう スケーリングも自動で行われる
- 32. 9: KubeCon OpeningKeynote - Project Update ちなみに 2 日目からは KubeCon + CNCon K8s クラスタ構築のデモ + CI/CD 周りのデモ
- 33. 9: KubeCon OpeningKeynote - Project Update まさかの音声クラスタ構築と deployment の scaling 「OK, Google. Create Kubernetes Cluster...」
- 34. 9: KubeCon OpeningKeynote - Project Update 1. アプリケーションコードの変更 a. git clone HOGE; b. git checkout -b funcA; c. vi test.java; d. git push origin funcA e. PR を出す f. Merge する（Dev 環境へ反映） g. Docker Image の build h. Registry への upload i. リリース Tag を打つ 2. Kubernetes クラスタへの反映 a. 上記で Tag を打ったことで、Kubernetes Manifest YAML が生成されてPR が自動で出される b. マージするとapply される（本番適用） GitHub k8s YAML manifest GitHub Application Code
- 35. 9: KubeCon OpeningKeynote - Project Update アプリケーション開発者は CI/CD Pipeline を確立し、kubectl を使う必要はない ＝ kubectl は ssh と同等（kubectl exec -it SOMETHING /bin/sh） Replica 数は Kubernetes Manifest YAML には書かない ＝ Manifest の apply 時に変更されないように
- 36. 9: KubeCon OpeningKeynote - Project Update 余談ですが、サイン本を頂きつつ写真を撮ってもらいました
- 37.
- 38. Using Containers forContinuous Integration and Continuous Delivery Jenkins のスケーリング手法 ● 1 Master に Agent を沢山ぶら下げる ○ Master が SPOF ○ Agent の管理が必要 ○ エージェント数に限界がある ● 複数 Master を用意する ○ SSO ○ 共通設定や管理の集中化を考える必要がある 結構しんどい。
- 39. Using Containers forContinuous Integration and Continuous Delivery
- 40. Using Containers forContinuous Integration and Continuous Delivery podTemplate(label: 'mypod') { node('mypod') { sh 'Hello world!' } } build task をコンテナとして起動 Groovy で記述可能 PodTemplate と同等の表現力 https://github.com/jenkinsci/kubernetes-plugin
- 41. Deploying to KubernetesThousands of Times Per/Day Kubernetes を使って High Velocity を実現しましょう！ ※ 変更から反映までの間隔を出来るだけ短くすること
- 42. Deploying to KubernetesThousands of Times Per/Day １．Image First ● Immutable なコンテナにする ● Entrypoint を設定してそのまま起動できるようにする ● local / dev / prd で同じイメージを利用する ● latest タグは使わない ● GitHub の特定のコミットと Image Tag を紐付けておく ● local でビルドして push はしない（自動化必須）
- 43. Deploying to KubernetesThousands of Times Per/Day ２．Shift Left テストは出来るだけ前倒ししましょう Bottleneck
- 44. Deploying to KubernetesThousands of Times Per/Day ３．Maintain Application Portability クラスタが消し飛んだときに復旧できますか？ （会場では x hour ~ x day の声） ちゃんと移行出来るようにメンテナンスをし続ける ● 設定ファイルはコンテナイメージに内包せず ConfigMap / Secret を使う ○ Docker Build は出来るだけ避ける ○ 環境変化に強い設計にする ● Helm Charts 化も検討する ● ディザスタリカバリのテストもする
- 45. Deploying to KubernetesThousands of Times Per/Day ４．Outsource Cluster Management ● クラスタの管理は専門チームに任せる ● スケーラビリティや冗長化の計画を持っておく ● Certified Kubernetes Conformance Program に準拠した構成にしましょう ○ 一部の Kubernetes 環境にしかない機能に依存すると移行が難しい
- 46. Deploying to KubernetesThousands of Times Per/Day CodeFresh Kubernetes に特化した Spinnaker + CircleCI + DockerHub のようなもの？ ● Github のコード変更 ● Docker Image の作成 ● Deployment の Config や Helm Charts を生成 ● （Performance Test） ● Kubernetes クラスタにデプロイ
- 47. Deploying to KubernetesThousands of Times Per/Day
- 48. Continuous Delivery withKubernetes at Box Kubernetes Cluster の状態 ＝ Github のリポジトリになるように構築 Docker Build 時に YAML を自動生成して manifest Github に PR をする方式 Kubernetes Cluster GitHub k8s YAML manifest＝
- 49. Continuous Delivery withKubernetes at Box Kubernetes クラスタに Agent を仕込んでおく クラスタの状態となる Github を Agent に登録 Agent が Github を監視して変更があれば反映 障害時にも Agent を入れるだけで復旧可能 Kubernetes Cluster GitHub k8s YAML manifest＝
- 50. Microservices, Service Mesh,and CI/CD Pipelines: Making It All Work Together Istio + BRIGADE + kashti (WebUI) を使った ServiceMesh + CI/CD 環境 Istio を使うことで ● トラフィックコントロール ○ Canary リリース ● Chaos テストのために Fault injection（遅延やドロップ） ○ 障害試験 ● メトリクスのスコアリング ○ パフォーマンス低下の検知 ○ 複雑な ServiceMesh 内でのパフォーマンスチェック
- 51. Microservices, Service Mesh,and CI/CD Pipelines: Making It All Work Together Istio + BRIGADE + kashti (WebUI) を使った ServiceMesh + CI/CD 環境 BRIGADE を使うことで ● Event driven な CI/CD Pipeline ○ DockerHub の変更を検知 ○ Github の変更を検知 ● JavaScript による Pipeline 定義 ○ コード化が可能 ● 全てを網羅 ○ Go binary の作成、Docker Image の作成、Helm Charts の作成、Slack 通知 events.on("exec", () => { var job = new Job("test", "alpine:3.4") job.tasks = [ "echo Hello", "echo World" ] job.run() })
- 52. Microservices, Service Mesh,and CI/CD Pipelines: Making It All Work Together あとこのセッションでちょっと納得したのは ● PR で Canary リリース ● Merge で正式リリース というのは良さそうだなと思いました
- 53. Building Better Containers:A Survey of Container Build Tools 現状の Dockerfile の問題 ● イメージの再現性が乏しい ● Bash での Programmability ● イメージフォーマット間での連携が弱い Dockerfile 使ってコンテナイメージ作る時代はきっと終わるよ！ [ソースからイメージビルド] source-to-image (s2i) buildkit habitat 詳しくは凄い量になるので、 付録の SpreadSheet で。 [従来方式] buildah nixos-container ansible-container smith (distroless)
- 54. GitOps - Operationsby Pull Request GitOps の 3 つの法則 ● システム全体が正常に稼働する状態を Git で管理する ● 実際の状態と Git の状態（想定する状態）の差分を比較 ● 全ての変更操作は PR 経由で実行する
- 55. GitOps - Operationsby Pull Request GitOps の 3 つの柱 ● Pipeline ● Observility ● Controll この３つをベースに話して行きます
- 56. GitOps - Operationsby Pull Request Pipeline ● 1 Repository は 1 app / service で構成 ● ブランチは prd / stg / dev などで切る ● ブランチは Namespace か Cluster にマップさせる ● stg に展開するときは stg ブランチにマージしたら自動で行われる ● ブランチはプロテクトしてレビューを必須にする
- 57. GitOps - Operationsby Pull Request
- 58. GitOps - Operationsby Pull Request Observility メトリクス等を駆使して PR をマージしていいかを判断する レスポンスタイムが 100ms 以下かどうか等 Controll すべては Git を介して行い Kuberentes を直接操作しない
- 59. Developer Tooling forKubernetes Configuration Validation（kubeval） ● Manifest YAML のフォーマットが正しいかどうか Unit Test（kubetest） ● podSpec のチェック ● label 設定のチェック ● 特権コンテナを使っていないかのチェック ● etc… jsonnet や helm charts などでもテスト可能
- 60. Webhooks for AutomatedUpdates DockerHub の Webhook を使った自動デプロイ CircleCI / ConcourceCI などから K8s を操作するのではなく直でやる方法
- 61. Webhooks for AutomatedUpdates Rancher の Webhook Framework を使うとココらへんが自動化出来るらしい 早い話が Webhook 用の管理サーバを Rancher が請け負うよって形
- 62.
- 63. is coming soon... 来年はココらへんの話で発表したい！ 「GKE互換のオンプレコンテナ基盤 AKE (Adtech Container Engine)」 https://developers.cyberagent.co.jp/blog/archives/12058/ 「Kubernetes をいじって Hardware LoadBalancer で “type LoadBalancer” を実装」 https://adtech.cyberagent.io/techblog/archives/3127 「オンプレでも GKE Like な Ingress を使うために 自作 Ingress Controller を実装」 https://adtech.cyberagent.io/techblog/archives/3758