で始める ゆるふわオーケストレーション FUKUOKA Engineers Day 2019 ~Summer~ pixiv Inc. 2019.7.20

2 名前：田代雅治（たしろまさはる） Twitter: @tasshi820 所属：ピクシブ福岡オフィス（学生アルバイト） Like：Go, TypeScript, Docker, etc.

使ってますか？

使ってますか？

5 Pod? Spec? Namespace? Dockerと文脈が全然違う、、、 そもそもk8sを使うほどの構成だっけ、、？ 2,3コンテナをクラスタリングしたいだけなのに 考えることが多すぎるような、、、 私の場合 k8sを検討する私

もっとゆるふわに コンテナをスケールアウト したい

7 ・Dockerに標準搭載されているオーケストレーション機能 ・元々はdocker swarmという外部ツール ・2016年7月にDocker本体に統合、Dockerにおける標準となる しかし ・k8sが圧倒的機能差でデファクトスタンダードに ・結局2017年10月にk8sもDocker本体でサポートされる swarmはk8sの人気に隠れたDocker自家製のオーケストレーション機能

8 ・2種類のノード managerノード： 　・ユーザーからコマンドを受付 　・workerノードにタスクを送信 workerノード： 　・managerからタスクを受信・実行 manager node worker node worker node worker node swarm cluster

9 Stack： 　・アプリケーション全体 　・1つ以上のServiceで構成 Service： 　・アプリケーションの1機能 　・1つのContainerを実行 Container： 　・Dockerコンテナ Container Service Container Service Stack

Kubernetes (k8s) swarm 機能 高機能（らしい） WebUI標準 clustering, replication, rolling update CLIツール (EE版はWebUI有) 構成 3層 node∋pod∋(container | volume) 2層 node∋(container | volume) コンテナ ランタイム containerd, cri-o, rkt, etc. Dockerのみ 開発元 Cloud Native Computing Foundation （作者はGoogle） Docker, Inc 10 ゆるふわ比較：

11 機能も人気もk8sが上。だけどswarmもいいところもあるよ ・Docker公式のドキュメントが豊富 ・DockerのGet Startedはクラスタリングにswarmを使用 ・Compose fileのDocもswarmに関するオプションをサポート ・composeから移行する際の学習コストが低い ・構成がk8sより単純になりやすい のいいところ

活用事例 でサイドカーパターンした話 archive.drawr.net

13 コア機能と周辺タスクをプロセス・コンテナで分離する Ruby：Sidekiq, Resque　Go：goworker サイドカーパターン メインコンテナ コア機能 サイドカー コンテナ 周辺タスク バックグラウンドジョブ

14 が運営するイラスト ・2008年から11年続く長寿サービス ・ドローツールと筆跡データ再生機能を提供 ・ヘビーユーザーの皆さんに使われている 年 月にクローズが決定 ・2020年のAdobe Flashサポート終了

15 ・投稿イラストの一括ダウンロード機能を提供 1. ブラウザでリクエストを受ける 2. 投稿をfetch, DL用に整形する 3. メールでURLを返す 類似サービス：Twitterの全ツイートDL機能 ・drawr本体の改修は困難 →Goでスクラッチから開発

16 storage server Job Amazon S3 fetch enqueue dequeue request request e-mail

17 storage server Job Amazon S3 fetch enqueue dequeue request request e-mail

18 への道 enqueue dequeue Job コンテナ化 で複数コンテナ管理 に変更 に キーを追加

19 コンテナ化 enqueue dequeue Job server redis worker サイドカーパターン ・server：メインアプリケーション ・worker：サイドカー ・redis：ジョブの記録に使用 ビルドの説明は省略 ・Multi Stage Buildで軽量化とか

20 で 複数コンテナ管理 docker-compose.yml --- version: "3.4" services: server: image: server:${TAG} depends_on: - redis worker: image: worker:${TAG} depends_on: - redis redis: image: redis:alpine3.9 に構成を記述 ・1service 1container 普通の構成なのでスキップ

21 に変更 server redis worker worker worker manager node worker nodes docker swarm cluster 複数インスタンスでクラスタを構築 ・ swarm init でswarm clusterを構築 ・ swarm join でclusterに参加 のデプロイ先を決める ・server, redisは同じノード ・workerを複数ノード上にデプロイ

22 に キーを追加 docker-compose.yml --- version: "3.4" # version >= 3 services: server: - image: server:${TAG} + image: ${CONTAINER_REGISTRY}server:${TAG} depends_on: - redis + deploy: + mode: replicated # 複製ポリシー + replicas: 1 # デプロイ時の複製数 + update_config: # 更新ポリシー + parallelism: 1 # 同時更新数 + delay: 10s # 更新間隔 + order: start-first # 更新時の起動・停止の順序 + restart_policy: # 再起動ポリシー + condition: any # 再起動条件 + delay: 5s # 再起動試行間隔 + max_attempts: 3 # 最大試行回数 + window: 30s # 成功判定の遅延時間 + placement: # 起動ノードの指定 + constraints: + - node.role == manager を編集 ・serviceの設定にdeployキーを追加 ・複製ポリシー ・更新・再起動ポリシー ・ ノードの指定, etc… 詳しくは公式ドキュメントを参照 https://docs.docker.com/compose/compose-file/

- image: server:${TAG} # 失敗 + image: ${CONTAINER_REGISTRY}server:${TAG} # 成功 ハマりどころ 10 指定するコンテナイメージはレジストリサーバにあるものを指定する ・ノード間でコンテナイメージの共有はできないため ・DockerHub以外でもOK (GCP Container Registry 等) ノードへのデプロイが失敗する場合

デプロイ 10 コマンドでサービスをデプロイ # ローカル環境 $ TAG=1.0.0 $ <コンテナのビルド> $ <コンテナをレジストリにpush> # デプロイ先環境 user@prod:~$ docker stack deploy -c $COMPOSE_FILE $APPLICATION_NAME

# ローカル環境 $ TAG=1.0.1 $ <コンテナのビルド> $ <コンテナをレジストリにpush> # デプロイ先環境 user@prod:~$ docker stack deploy -c $COMPOSE_FILE $APPLICATION_NAME 10 コンテナのタグを更新してサービスをデプロイし直すだけ！ ymlの更新ポリシーにしたがって順次コンテナが入れ替わる

26 ・ だと から簡単に移行できる ・ ぐらいはゆるふわにできる ・ のほうが高機能なのでケースバイケース まとめ

27 モバイルは、 キャラをつくって着せ替えて、 写真が撮れる、アバターカメラアプリです。 ・3Dキャラクターモデル作成・着せ替え ・アバターを現実世界に呼び出して AR撮影 詳しくは公式ページをチェック https://vroid.com/mobile