Docker Meetup Tokyo #26 Docker Meetup Tokyo #26 に参加してきたのでそのメモ。 Stress Test with LOCUST on k8s（株式会社プレイド Masahiro Yamauchi(@algas)さん | Twitter) k8s使った事ある人 8割くらい 負荷テストの難しさ（ネットワークやスペックがボトルネックになる） LOCUST pythonベース k8sでLOCUST環境を構築(GKE) worker台数を自由に増減させられる DDoSとみなされないように 10000ユーザーくらいでテストした KubeCon China参加報告(ゼットラボ株式会社 Kazuki Suda / すぱぶら(@superbrothers)さん | Twitter) ゼットラボ(yahoo 100%子会社) Harbor,Dragonfly KubeConの中国開催は初(アジア圏で初めて) 上海は綺麗、ご飯美味しい、アメリカはご飯が微妙だった ファーウェイクラウドでk8sのマネージドを提供,企業3番目にコントリビュートしてる k8s靴下販売してた Harbor:イメージレジストリ TiKV:分散トランザクション Dragonfly:P2Pコンテナイメージ配信(Alibaba) CNCFサーベイ2018では58%で本番でk8sを本番運用している k8s is boring(本番で心配なく運用できている) ブロックチェーンとかマシンラーニングとかIoTで使われはじめてる Harbor(会場内では使っている人はいない) Dragonfly（本番で使っている人はいない） etcdの初期の開発をしていた人がつくっている OSS Javaで書かれている(Goで書き換えるらしい) k8sでベアメタルを管理したりするセッションとかもあった k8sでk8sを管理する https://speakerdeck.com/superbrothers/kubecon-plus-cloudnativecon-china-2018-recap いま話題のいろいろなコンテナランタイムを比較してみた (Comparison of several container runtimes)(NTT Kohei Tokunaga(@TokunagaKohei)さん | Twitter) [高レイヤー]containerd,cri-o,rkt [低レイヤー]runc,gVisor,Nabla Containers,Kata Containers critoolsを使ってpodの作成から破棄までを測定 rkt -> 最近は盛り上がりがなくなってきてる containerd,cri-oはパフォーマンスに差は殆ど無い rktはパフォーマンスがあまり良くない runcはLinuxの機能フル活用してセキュリティを担保している gVisorはGoogleが発表 アプリはgoroutineで実行 runnc(Nabla Container)はIBMが開発 Kata-runtime(Kata Containers)はOpenStack Foundationのプロジェクト PodとしてLinuxのVMを作成して中のコンテナが起動する Kata ContainerはPodの起動が他のランタイムより遅い 一番性能が良かったのは Containerd + runnc 一番性能が悪かったのは rkt + coreos Docker Swarm-mode(ZOZO inductor(▼・Å・▼)(@inductor)さん | Twitter) いまはSwarm Modeになってる swarmpit k8sはコミュニティが強い クラウドプロバイダが躍起になって対応している k8sの理解は難しい 分散基盤とかいらないレベルの小さなWebアプリの環境に入れるほどの規模じゃない 業務コストにみあうものは？ Docker Swarmを使うのも一つ Swarmのデモ https://speakerdeck.

AWS Fargate ECS/EKS祭り 8/3(金) AmaozonWebServices目黒セントラルスクエア AWS Fargate & Amazon ECS/EKS最新情報 ECS AWS 西谷さん(@Keisuke69) コントロールプレーン=コンテナの管理をする場所(ECS/EKS)どこでコンテナを動かす？生死は？デプロイ時にどこに配置する？など データプレーン=実際にコンテナが稼働する場所(Fargate/EC2) ECSの話 ローンチされてから数年 数百万インスタンス/数億コンテナが毎週起動 プロダクションでコンテナ運用を支援するために開発されている CloudWatchLogと簡単に連携 CloudWatch Iventと連携 Fargateのローンチ 7月からTokyoリージョンサポート AutoScallingをユーザー側で考えなくても良い(ECSと同じ) スケジューラ、LBなどはECSと同じで利用可能 課金はCPUとメモリが秒単位 FarageteはVPCネットワーク利用のみ ALB/ELBをサポートしている パーミッションタイプ（Cluster/Application/HouseKeeper） CloudWatchでモニタリング Farfateで難しいもの Windows Containers GPU Support docker exec デバッグ SpotやRIベースの価格モデルの適用→必要ならEC2モード Lambdaのほうがよい場合 イベント・ドリブン ミリ秒単位のコンピュート ランタイム管理したくない 分散バッチコンピューティング コンテナのAutoScaling ECS Trackingとの連携がおすすめ SLA99.99%(ECSと同じ) EKS k8sをプロダクションを運用している人→ちらほら k8sは可用性のためにAZをまたいで3つ作成が必要 on AWS k8sは人気があるが自前構築が大変… AmazonEKSはずっとプレビューだったが、6月末で一般公開になった(AWS、Kubernetesを簡単に実行できる「Amazon EKS」を正式リリース) Confirmability CNI plugin ENI Secondary IP LB: CoreOSALB エンドポイント認証はIAMできる FlutendでCloudWatch Logsと連携が簡単 WorkerのメトリックスはCloudWatchで取れる AmazonECS + AmazoneEKS + Faragte 連携予定 コンテナ化したアプリケーションをAWSを動かすためのベストプラクティス 福井さん(@afukui) カナリアデプロイ/ブルー・グリーンデプロイ がやりやすいのがコンテナのメリット マイクロサービス化している方？ – ちらほら コンテナを利用した開発に必要な技術要素 アプリのステートレス化 レジストリ コンテナの中にいれるのはステートレスなアプリに ステートが必要なものはコンテナの外に RDBMS -> RDS オブジェクト -> S3 Twelve-Factor App(The Twelve-Factor App) レジストリの自前運用は大変なのでマネージドを使うのがおすすめ CI/CDパイプラン 自動化するメリットは誰がデプロイしても同じ結果になる デプロイ職人(!