2018-12-05 JapanContainerDays v18.12 Day2
2018/12/05 に開催された JapanContainerDays v18.12 Day2 のイベントレポートです。
●イベントのテーマ
JapanContainerDays（JKD）はコンテナ活用/クラウドネイティブの現状をひとまとめにした開発者のためのイベントです。コンテナエコシステムを形成する数多くの技術やソリューションを歓迎します。
■Kubernetesではじめる深層学習♥推論環境構築ハンズオン
阿佐 志保さん ほか数名（日本マイクロソフト）
●コンテナの利用シーン
・Lift and Shift
・Microservices
・Machine Learning
・IoT
●K8sの基本（この概念は理解しよう）
・Pod
k8sの最小管理単位
複数コンテナ
1ホストで動く
・ReplicaSet
Podのレプリカのグループ
指定数だけ起動を保持
・Deployment
ReplicaSetの世代管理
ローリングアップデート、ロールバック
●深層学習のタスク
・データの準備 > モデル構築/ガウク集 > 推論デプロイメント
・推論環境もアプリと同様にデプロイが必要です！
●AzureのCustomVision
・オリジナル画像で画像認識アプリを作成するSaaS
・Dockerfileとして学習済みモデルをエクスポートできる！
●ハンズオン
・MSアカウント作成
・AzurePass有効化
・手順
https://github.com/asashiho/ContainerDays1812
●QA
・深層学習 & Dockerfile の運用イメージ
Containerに学習済みモデルを含める
学習済みモデル と Container image のバージョンを揃える
# ハンズオンの再接続時に必要だった環境変数
RES_GROUP=AKS-HandsOn
LOCATION=eastus
AKS_CLUSTER=akscluster
# from Deployment.yaml
ACR_NAME=acrregistry99999
CLIENT_ID=$(az aks show -g $RES_GROUP -n $AKS_CLUSTER --query "servicePrincipalProfile.clientId" -o tsv)
ACR_ID=$(az acr show -n $ACR_NAME -g $RES_GROUP --query "id" -o tsv)
# from ConfigMap.yaml
BLOB_ACCOUNT=blobstorage999990
■GitLabによるコンテナCI/CDパイプラインのこれから
北山 晋吾さん（GitLab Tokyo）
●GitLabのビジョン
・開発チームがToolchainを維持する工数をなくす
・開発に注力してほしい
●Concurrent DevOps
・Traditional DevOps
Plan > Create > Verify > Package > Release > Configure > Monitor
多くの企業はDevOpsパイプラインに 3~6個のツール雨を利用している
連携が大変！
社内統制が取れない
→ GitLab の Complete DevOps
・Concurrent DevOps
●Container CI/CD with GitOps
・これまでのCI/CD
AppCode Repository > CI > Application Packages
> Application Deploy > Maintenance > Release > alert
・Container CI/CD
AppCode Repository > CI > Application Packages
> Manifest Repository
> Container Deploy > Maintenance > Release > alert
・SREの負荷が高まる
デプロイ承認の負荷
デプロイ運用の負荷
→GitOps
・GitOps
Application CodeだけでなくManifest運用も、MergeRequestで！
Manifest用リポジトリはApplicationと分ける
・GitOpsでの動的な運用
「動いている設定」と「管理している設定」
自動でDiff Check & 同期
-> Weave Flux
katacodaがついている
GitLab と Weave Flux で GitOps してみた のスライド
●Auto DevOps
・対象領域
CI/CD, Security, Monitoring, Alert...
Kubernetesがやってくれないこと
・ステージ
AutoBuild
AutoTest
AutoCodeQuality
AutoSAST
AutoDependencyScanning
AutoLicenseManagement
AutoContainerScanning
AutoReviewApp
AutoDAST
AutoDeploy
AutoBrowserPerfomanceTest
AutoMonitoring
・構成
GitLab Instance
KubernetesCluster
gitlab-managed-apps
project-name
ブランチごと
●できること
・GKEならクラスタも作れる
・デプロイ可能なアプリ
JupyterHub
Knative
も
・環境ごとにnamespaceも分けられる
・自動デプロイ と 手動デプロイ も切り分けられる
・helmの設定も作ってくれる
・静的解析もかかる
・レビュー用のアプリケーションをデプロイ
・sitespeed.io: パフォーマンスチェック
・prometheus: モニタリング
・MergeRequest に指摘事項も入れてくれる
・OWASP ZAP: 動的なテスト
・clair: コンテナスキャン
●まとめ
・DevSecOpsのToolchainが全部入り
・GitLab Meetup Tokyo #12 が 12/20にあるよ！
・クリエーションラインで学べるよ
※Weave Fluxの参考スライド
■改めてDockerfileのベストプラクティスを振り返ろう
林 如弥さん（オイシックス・ラ・大地）
※mobyのmulti stage buildに対応したコミットが勉強になるよ！
●Dockerfileとは
・docker imageをつくる設定
・17個の命令
●ベストプラクティスをふりかえる
・docs.docker.comで公開されている
・26分では読めないw
・章立て
一般的なガイドライン
命令語について
オフィシャルなサンプル
追加情報へのリンク
●一般的なガイドライン
・ステートレスなコンテナを創るべし
停止=データは削除
バージョンアップ
12 factor apps
・docker build時にどこでビルドされるのかを理解
ビルドコンテクスト
デフォルトはカレント
-fで指定できる
contextと Dockerfileの管理でディレクトリを分けられる
・dockerfileを作成しなくてもパイプラインでstdoutからdocker buildへコマンドを渡せる
ヒアドキュメントとか
リモートのビルドコンテクストにも標準出力からdockerfileを渡せる
・.dockerignoreで除外
・マルチステージビルドを使う
goなど。ビルド前、ビルド後でステージを分ける
皇族は、 scratch & 前ステージを参照
・軽くしよう
・1コンテナ = 1アプリが原則
1コンテナ = 1プロセスではない
apache, postgresなど
・レイヤ数は可能な限り減らす
RUN, COPY, ADDがレイヤを増やす
LABELも創るけどサイズ影響なし
マルチステージ使ってね
docker historyでレイヤ数、レイヤの各サイズが見れる
GitHub orisano/dlayer で更に見れる
・複数行の引数はソートしよう
・ビルドキャッシュを活用する
上から順にキャッシュされる
変更されるものは、後ろに書こう
ADD, COPYはファイルのハッシュをチェックしている
RUNは文字列でチェック
apt updateなど気をつけよう
●命令語について
・FROM
小さいイメージをベースに
・RUN
可能な限りコマンドをまとめる
削除を別のレイヤでやっちゃだめ
・CMD
デフォルトコマンドの指定
exec formを使う
環境変数が展開できないから shell -c で！
毎回同じコマンドなら ENTRYPOINT
・ADD / COPY
基本はCOPY
ADDは展開しながら取り込み、URLからも撮ってこれる
・ENTRYPOINT
docker run
ENTRYPOINT + CMD
引数が渡されると CMD が上書きされる
●まとめ
・ADD/COPY, CMD/ENTRYPOINT の使い分けは覚える
・ベストプラクティスは参考程度で
・container builders meetup 面白いよー
■GitOpsではじめるKubernetes CI/CD Pipeline
遠藤 耕平さん（LINE）
●バージョン管理のおさらい
・gir-flow, github-flow, gitlab-flow などアプリのブランチ戦略
ちゃんとやらないとデグレ頻発
・コンテナだと
アプリ
Dockerfile
Manifest
・manifestもアプリと同様にバージョン管理が必要
●GitOpsとは？
k8s manifest をクラスタにContinuous Deliveryする手法
・原則
すべてgit管理
実行環境で変更しない
変更をモニタリング
※非コンテナと同じ
・CIOps
CI toolがk8sクラスタに直接展開
複雑なパイプラインの最後でデプロイ
クレデンシャルの管理が大変
CI Toolにクレデンシャル持っていてよいの？
・Developer, CI Tool から k8sにdeployさせない
これが正解ではないはず
・実現するには？
すべてをgit管理
GitOpsを実現するkubernetes operatorを同ニュ
・もたらしてくれること
継続的で安定したクラスタ運用
●導入するポイント
・gitのリポジトリを分ける
app + Dockerfile
k8s manifest
-> manifestの変更でデプロイできる
・git上のmanifestとk8sで動いている差分をチェック
・Replica吸うの扱い
manifestに数を指定していると動機が遅れるかも
・機密情報の扱い
secretをgit管理は危険
暗号化して管理 sealed-secret など
・リソースの削除(rename)
残っちゃうことも
・gitブランチとk8sクラスタのデプロイ戦略
●どんなツールがある？
・Argo CD / weave flux / JenkinsX の三つ巴
・ポイント
WebUI
差分検知/同期の種類
manifest削除時の挙動
対応しているmanifestの形式
・参考
GitLab と Weave Flux で GitOps してみた ※前述
■MeetUpを活性化せよ! 最強のリアルタイムQA投稿アプリをCloud Nativeに作ってみた
早川 博さん、杉山 卓さん（Cloud Native Developers JP）
●cndjp
Cloud NativeなOSSスタックを取り上げる勉強会、コミュニティ
●Qicoo
・読み方
きこー
・URL
https://qicoo.tokyo
・モチベーション
せっかくエンジニアが集まるのにインタラクションがないのはもったいない
●やってみてどうだった？
・コミュニケーションの工夫
・オンラインのツールを使うと結構行ける
・費用の工夫
・開発期間: 3ヶ月
・クラウドの料金よりロゴのほうがお金かかった
・技術的な障害を乗り越えるパワーに感銘
・本業を抱えながらOSS開発は難しい
・費用面は意外となんとかなる
●Qicooで利用しているAWSサービス
・EKS, EC2, RDS(MySQL), ElasticCache(Redis)
・CloudFront, Route53, S3, Certificate Manager
●Qicoo Architecture
1. route53で名前解決
2. CloudFrontの静的ファイル & CertificateManagerの証明書
3. ブラウザ上に静的ファイルが表示
4. Route53のExternalDNSでk8sから解決
5. ELB経由でEKSにアクセス & 証明書
6. データストアから取得
7. ElasticCache or RDS
8. ClientにJSONレスポンス
●Qicooの技術要素紹介
・Front
TypeScript, React, Redux, Bootstrap
・Backend
Golang
v1/イベントID/questions?start開始番号&end=終了番号&sort=xxx&order=xxx
・CI/CD
TravisCI
Kusomize
Spinnaker
・Auto UP/DOWN
HeptioArk, Ansible, Python(Slackbot), CloudFormationなど
・EKSでのサービス公開
ExternalDNSで任意のFQDNで公開
k8sでservice, ingressで公開したい名前を指定 -> Route53にAレコード
手順
ドメイン購入
Route53でHostedZone作成
NSレコードの値を買ったドメインに設定
Certificate Managerで証明書
EKSでExternalDNS
●CI/CD深掘り
・GitOpsしてます
・SpinnakerのKayenta(カエンタ)
カナリアリリース
Spinnakerでは、数でリクエストを制御
様々なMetricを比較してくれる
Defauultでは含まれていない
・手順
PrometheusOperator
Halyardで設定
spinコマンドで、pipeline as a codeできるようになった！
・cndjpのGithub
github.com/cndjp
・ブランチ戦略
masterブランチ > productionデプロイ
releaseブランチ > stagingデプロイ
featureブランチ
・CI/CDパイプライン
featureブランチ
push > TravisCI
CDなし
動作確認はlocal
releaseブランチ
プルリのmerge > TravisCI
DockerBuild, push
バージョン番号-日付
Kustomizeを実行するrepoをclone
kustomizeのパラメータを用意
push > TrabisCI
image tagを設定
kustomize build でmanifest生成
webhook > spinnaker
masterブランチ
spinnakerからカナリアリリース
・Spinnakerの所管
シンプルなら良い
shell実行でjenkins連携
外部リソース参照でも制約が多い
何らかのCI + Kustomize + Spinnakerは相性良さそう
CI側でKusomize
Spinnakerはシンプルに
●QA
・AWSとGCPはどう使い分けている？
metricデータをBigQueryに入れたかった
slackbotの実行環境
・どうやって図を描いたの？
cloudcraft
・他の勉強会でも使って良い？
使って良いものですが、まだ情報揃ってない
■改めて見直すコンテナベースで作るメリット
リクルートテクノロジーズ
●事例のサービス
ジョブオプLite
●インフラアーキテクト視点
・いきなり全部盛りは事故のもと
組織にノウハウと文化ができてから
・CloudNative Trail Mapでマイルストーンを決める
既存の技術スタック
メンバーの数、習熟度
開発期間
・インフラ面の要件
1. インフラの提供がアプリ開発うの足かせにならないように
オンプレ -> パブリッククラウド
2. 何かあっても他の環境で動かせるように
ECS -> Kubernetes
3. 中期的なコスト削減
Monitoring
Prometheus -> Datadog
CI
circleci
1.x -> 2.xの過渡期だった
ライセンス料
jenkins
バージョンアップ辛い
concourse
コンテナベース
機能が豊富
アドホック排除
managed service
SQS, SNS, SESなどを利用した
コンテナが得意でないもの
手間を省いてくれるもの vs ロックイン
●アプリケーションエンジニア視点
・CIの役割
高頻度のテスト実行
欠陥の早期検出 ※ここが大切
・割れ窓理論
長期間修理されない割れた窓
-> ぞんざいな扱いの感覚が植え付けられていく
-> 割れた瞬間に検出！
・CIに求められること
信頼性: 環境依存で失敗があると使えない
短時間: 時間がかかると使えない
-> 環境差分があると信じられなくなる
・環境差分あるある
モジュールの初期化順
並列数に依存
外界に依存
ローカルキャッシュに依存
共用環境で一緒に走っているタスクに影響を受ける
-> 調査できない
・コンテナとCIの親和性
ビルドごとに隔離された環境
CIと同じ環境を、ローカルに持ってくることもできる
-> 調査が楽。DXが高い！
・コンテナベースのCI
ビルド/テストをコンテナ上で実行
ビルドに使ったコンテナは都度push
プルリ作成でトリガー
-> CIの信頼性高まった！
・ビルド実行時間の問題
テスト実行ごとに build / push / pull
-> 2hかかってしまうことも
・CIの健全化
失敗させるべきものに早く気づく
外界に依存しないテストは docker build で失敗させる
Test Sizes
Small(外界依存なし) / Medium(localhost) / Large
テスト名にプリフィックスをつけるルールなど
大多数はsmallで検出できる
●インフラエンジニア視点
・コンテナベースのCI/CD
機能はモダン
非機能で問題
・CIサイクルの長さ
開発効率が低下: PRのバッチサイズが大きく
masterブランチが壊れる: 一気に入れて壊れる
・ビルド速度に配慮のないDockerfile
レイヤキャッシュ
依存ライブラリのCOPYを分けて、前に持ってくるとか
CI上でcache
近いtagのimageを持ってくる
中間レイヤも持ってくる
など
※詳しくは別スライドで
・安心して開発するために
アプリ-インフラ間のコミュニケーション
接続情報は環境変数で、など決める必要がるものは先にルール化
CD
モブデプロイして敷居を下げる
誰でも実施できるように整備
・開発で最初に運用するのはCI/CDサーバ！
●まとめ/これから/残課題
・品質向上
安全になっているから、別のカイゼンに挑戦できる
CIのカイゼンはずっと必要！
・アプリ-インフラのコミュニケーション
これは開発の内側
-> 経営層などの上位へ
-> 隣のプロジェクトへ
■NoOpsが目指す未来像とコンテナ技術
岡 大勝さん、川崎 庸市さん（NoOps Japan）
●NoOpsとは
・システムは「価値」と「負担」でできている
理想: 価値は大きく、負担は軽い
現実: 価値はそこそこ、重い負担
負担だらけで身も心も、競争力も消耗
・NoOps = No "Uncofortable" Ops
運用の"うれしくない"を、なくそう
・攻めのNoOps/守りのNoOps
王道は守り: SRE
NoOps最上の索 > 攻め
・Design for NoOps + Less Ops
Design for NoOps
Self Healing
In-flight renewing
Adaptive Scale
・NoOps のライフサイクル
監視・検知
自動構成
高い回復性: 30秒以内
正常稼働
●現状
・攻めのNoOpsが実現できるようになってきた
観点は、自動化 / 抽象化 / 標準化
・コンテナ標準化とガバナンス
OCI / CNCF の標準化で、ツールがたくさん出てきた！
-> k8sでのステートフルワークロードを扱う仕組みも出てきた
まだ、理想には遠い
・コンテナのデリバリサイクル
コンテナ可搬性
マイクロサービス
CI/CDパイプライン
・コンテナセキュリティ
セキュリティの伴わない自動化に価値はない
・監視/問題検知
豊富な選択肢から組み合わせで選べるようになってきた
・マイクロサービスが抱える問題
Commuunication
Discovery
Observability
Security ※重要！
・Service Mesh
Control Plane と Data Plane
ネットワーク抽象化レイヤ
アプリ変更なしでネットワーク周りをいろいろやってくれる
・k8s + Service Mesh をベースにしたアプリのライフサイクルを抽象化
●未来
・シナリオ
・想定を遥かに越えたアクセスが来ようが
リージョン、クラウドサービス全体が落ちようが
どんな状況でも安定稼働
・リリース、パッチ、アップデート、設備更改などの
システム運用を無停止で実施
・鍵は、動的な資源管理
取り回しの軽さで直ぐに回復
・無限のリソース雨を、ミリ秒単位で架空補できるならどう設計するか
-> 構造的にOps不要にするならどう設計する？
・インターネットをひとつのコンピュータとして考えてみる
高台でフラットなリソースプール
自律的なリソースの割り当て、開放、リソース
統一されたリソースAPI
・The Network is the Computer.
42億のノードがデプロイ候補
システム構成を投げ込むと世界のどこかにデプロイしてくれる
不具合に気づいてglobalにリカバリ
過去の知見が生かされて、実現されてきている
・足りないシナリオ: セキュリティ
システム外部からの攻撃、ウィルスの混入、不正行為など
42億のノードをどう守る？
・Zero Trust Network
境界線 vs. Zero Trust
Vnet, VPCの中で、という発想は境界線側の発想
ネットワークのどこに置いても保護される
・Service Meshは、Zero Trust Architectureの実装
k8s + Service Meshで、コンテナアプリをマルチクラウドに
・Design for NoOps を今日更新
Self Healing
In-flight renewing
Adaptive Scale
Safety Everywhere ←追加！
・限りなくBroundaryのない世界
オンプレ、クラウド、クラウドベンダーを選ぶ > toilだね
・コンテナ技術の延長に未来がある
KeyTech は Mesh と その相互互換性
中でもService Mesh Proxyの進化
datastoreはまだ見えない。要チェック
●今から着手すべきこと
・コンテナを「回復性」に着目して使いはじめる
5秒で回復するならどう設計する？
・ネットワークを小刻みにせず、できるだけ広くとる
・境界線主義のセキュリティとサヨナラ
-> The Network is the Computer を見据える
●NoOps = No Boundary
・意図的な境界線をなくす
・商業的な囲い込み戦略を見直そう
・オープンでフラットな世界にこそ未来がある
■感想
今日も、ワクワクをたくさんいただきました！
Design for NoOps のお話を聞いて、個人的に再認識したのは
・仕組みが整ってきたことで No Ops は、きっと実現できる！
・実現に向けて、考えて試し続けていかなくては！
・その価値を利用できるヒトを増やしていく方法を考えなくては！
でした。
こんなにワクワクする展望が望めるほど進んだテクノロジーが
届いていない、地域、業種・職種、世代は、まだまだ沢山。。。
テクノロジーを届ける活動を進めていきたいと思います！
The Agile Guild(TAG) Advent Calendar 2018 5日目の記事として書いてみました。
> TAGに参加する
> TAGに相談する
どちらも、こちらのページから。
Day1 の様子はこちら
この記事が参加している募集
いつも応援していただいている皆さん支えられています。