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 の様子はこちら