Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

コンテナ時代にインフラエンジニアは何をするのか

GREE Tech Conference 2020 で発表された資料です。
https://techcon.gree.jp/2020/session/Session-4

  • Be the first to comment

  • Be the first to like this

コンテナ時代にインフラエンジニアは何をするのか

  1. 1. コンテナ時代に インフラエンジニアは何をするの か グリー株式会社 開発本部 駒﨑 拓斗
  2. 2. 2 ●グリー入社前 ○ 組み込みソフト企業 ○ 携帯電話向けプラットフォームの開発 ●2012年より グリーインフラ部門 ○ 開発環境の構築、運用 ○ デプロイツール・フロー改善 ○ 商用サービス部門向き合いのインフラ構築・運用・相談 ○ 最近の主なフィールドは AWS や GCP 2 自己紹介 駒﨑 拓斗
  3. 3. 3 3 とつぜんですが クイズです
  4. 4. 1. init オプション付きで起動する 1. pid=host オプション付きで起動する 1. user=1000:1000 オプション付きで起動する 1. sig-proxy=true オプション付きで起動する 4 次のコマンドは Ctrl+C で停止できません run のオプションで停止可能にできます。効果があるものを全て選んでください Q1. Docker クイズ $ docker run --rm busybox sleep 10000 $ docker run --rm --init busybox sleep 10000 $ docker run --rm --pid=host busybox sleep 10000 $ docker run --rm --user=1000:1000 busybox sleep 10000 $ docker run --rm --sig-proxy=true busybox sleep 10000
  5. 5. 5 5 ⓘ Start presenting to display the poll results on this slide. Ctrl+c で停止可能なのはどれ? (複数選択)
  6. 6. 1. init オプション付きで起動する 1. pid=host オプション付きで起動する 1. user=1000:1000 オプション付きで起動する 1. sig-proxy=true オプション付きで起動する 6 次のコマンドは Ctrl+C で停止できません run のオプションで停止可能にできます。効果があるものを全て選んでください Q1. 簡易解説 $ docker run --rm busybox sleep 10000 $ docker run --rm --init busybox sleep 10000 $ docker run --rm --pid=host busybox sleep 10000 $ docker run --rm --user=1000:1000 busybox sleep 10000 $ docker run --rm --sig-proxy=true busybox sleep 10000 PID1 のプロセスは明示的にハンドルしない限 り INT や TERM シグナルで停止しない 軽量 init プロセスを PID1 とし、 コマンドをその子として実行するオプション → init 経由でシグナルが伝わり停止する ホストと PID namespace を共有するオプション → PID1 でなくなりシグナルが伝わり停止する uid:gid を指定するオプション → 特に本件では関係ない シグナルの伝搬を指定するオプション → デフォルトで true 、本件では指定しても意味がな い 逆に false にすると Ctrl+C で KILL が送信され停止する
  7. 7. 1. Service type: ExternalName を作成し Pod から Service 名で参照 $ curl https://greetech/ 2. そのままの名前で参照 $ curl https://greetech.example.com/ 3. そのままの名前 (末尾 . 付き)で参照 $ curl https://greetech.example.com./ 7 Kubernetes の ある Pod から 外部サービス https://greetech.example.com にアクセスします 最も少ない DNS トラフィックが期待できるのは次のうちどれでしょう ※ 一般的な初期設定の Kubernetes クラスタにおいて Pod - クラスタ内 DNS サーバ間 Q2. Kubernetes クイズ apiVersion: v1 kind: Service metadata: name: greetech spec: type: ExternalName externalName: greetech.example.com. ※同一 namespace
  8. 8. 8 8 ⓘ Start presenting to display the poll results on this slide. DNS トラフィックが少ないのは?
  9. 9. 1. Service type: ExternalName を作成し Pod から Service 名で参照 $ curl https://greetech/ 2. そのままの名前で参照 $ curl https://greetech.example.com/ 3. そのままの名前 (末尾 . 付き)で参照 $ curl https://greetech.example.com./ 9 Kubernetes の ある Pod から 外部サービス https://greetech.example.com にアクセスします 最も少ない DNS トラフィックが期待できるのは次のうちどれでしょう ※ 一般的な初期設定の Kubernetes クラスタにおいて Pod - クラスタ内 DNS サーバ間 Q2. 簡易解説 apiVersion: v1 kind: Service metadata: name: greetech spec: type: ExternalName externalName: greetech.example.com. ※同一 namespace # 標準的な resolv.conf (EKS) nameserver 10.100.0.10 search default.svc.cluster.local svc.cluster.local cluster.local ec2.internal options ndots:5 search リスト、ndots: 5 が特徴 → 名前に含まれるドットが5より少なければ search リストを順番にためすよ、の意 ドット<5 なので search リストの先頭 greetech.default.svc.cluster.local. に問い合わせ、 返された CNAME greetech.example.com. に問い合わせ ドット<5 なので search リストの先頭から greetech.example.com.default.svc.cluster.local. , greetech.example.com.svc.cluster.local. , greetech.example.com.cluster.local. , greetech.example.com.ec2.internal. , と問い合わせた後、 greetech.example.com. に問い合わせ FQDN なので greetech.example.com. に問い合わせ
  10. 10. 10 10 お付き合いありがとうございました
  11. 11. 11 11 本題 コンテナ時代のインフラ
  12. 12. ●アプリケーション担当者/チーム (アプリチーム) ○ あるサービスのビジネスロジックを担当する ○ カスタマーに対し サービスを開発、運用する ○ 典型的には、サーバアプリケーション開発者チーム ●インフラストラクチャ担当者/チーム (インフラチーム) ○ アプリチームに対し基盤を提供、開発、運用する ○ 複数のサービスを受け持ち、共通課題を横串で担当する ■ 横串で受け持つことで、コスト・リソースの最適化を狙う ●理想的にはワンチームでプロダクトが作れたらよい、が ○ 複数事業をさばくため 12 アプリチームとインフラチーム 背景: 本日の "インフラエンジニア" について
  13. 13. ●サービスを提供するインフラは絶えず変化 ●ベアメタルから VM、コンテナへ ●2020 現在グリーでは ○ オンプレミス・パブリッククラウド併用中 ○ さらにパブリッククラウドへ移行中 13 グリーグループのインフラの歩み 背景: Web サービスインフラの移り変わり ベアメタル オンプレ VM パブリッククラウド VM サーバレス コンテナ
  14. 14. ●ベアメタル時代 ○ サーバ調達、インベントリ管理、OS 設定、プロビジョニング、... ○ 監視・アラートシステム 内製 ●VM 時代 初期 ○ プロビジョニングツールの導入 ○ Infrastructure as Code による自動化 ○ 構造はそのまま クラウドへの "リフト" が行われた ●VM 時代 後期 ○ パブリッククラウドの活用 ■ プログラマブル / 宣言的な構築 により自動化がさらに進む ■ クラウドに合わせた設計の浸透 ■ スケーリング操作など一部運用がアプリチーム側へ 14 インフラのデリバリー・運用の変化 これまでの変化 (ホストベース時代)
  15. 15. ●実用的なコンテナ基盤の普及 ○ アプリチームからもコンテナが身近なものに ■ docker-compose ■ Cloud Run ■ AWS copilot (ecs-cli) ■ Kubernetes ●マネージド Kubernetes の大きなインパクト 15 コンテナ時代へ
  16. 16. 16 消えるインフラ業務、残る生まれるインフラ業務 マネージド Kubernetes の出現 ランタイム / Lib 更新したい VM イメージ作り直してもらえます か サーバにつなげる 最小限の E2E 環境がほしい 構築とデプロイお願いします デプロイツールの改修を … Dockerfile をちょいと FROM php:7.4-apache 、と クラスタぽちぽち、 Deployment に Service に Ingress 書いて、apply 、と
  17. 17. ●たしかに 一部の既存業務は ほぼなくなった ○ VM イメージ管理 ○ デプロイツール ○ オートスケーリング設定 ●引き続きやってくモノ・新しく生まれるモノ ○ サイト信頼性エンジニアリング (SRE) 関連 ■ 可観測性の面でより重要度が高まる ○ データストアやネットワーク、CDN などの専門知識 ○ 本番運用に耐えるための Kubernetes 自体の知識 ○ これまでも VM やパブリッククラウドの登場による変化はあったが Kubernetes による変化はそれよりかなり大きい 17 消えるインフラ業務、残る生まれるインフラ業務 マネージド Kubernetes の出現
  18. 18. ●(少なくとも今のとこは) まだまだ ●例. 冒頭のクイズの領域 ○ Q1. Docker クイズ (The PID1 Problem) ■ Dockerfile の書き方を気をつける問題、nodejs で遭遇しがち ○ Q2. Kubernetes クイズ (dnsPolicy ClusterFirst の設定) ■ 名前解決のお作法に気をつける問題 ○ しかし全くビジネスロジックには関係無い ■ アプリチームが頑張るところだろうか? ■ 組織として横串で共有すべきノウハウの類 ●"アプリチームに基盤を提供する" 仕事の本質は同じ ○ が、どこまでが基盤なの? 18 Kubernetes でインフラの業務範囲はどんどん縮小する? これから仕事減りそう?
  19. 19. 19 ホストベースのころ 19 PHP : アプリチーム CI : アプリチーム Deploy : インフラチーム apache : インフラチーム VM : インフラチーム LB : インフラチーム ︙ チーム担当範囲の境界はどこだ これから Dockerfile : アプリチーム...? ちょっとインフラ? CI/CD : アプリ?インフラ? K8s : インフラチーム...? とアプリチーム...? ︙ 従来型分担とのアンマッチ
  20. 20. ●ソフトの構造と組織の構造に相関がある、として ●従来のチーム分け ○ VM時代以前(ホストベース) の構造に最適化されたもの ●インフラの新しいレイヤが積まれ構造が変化 ○ 一段上のプラットフォームができた ○ 抽象化・ソフトの構造が変化した ○ 従来の組織でアンマッチを感じるのは自然 20 ソフトウェアの変化、変化前の組織とのアンマッチ なぜアンマッチが発生するか
  21. 21. ●現状は双方からコミット ●コミュニケーションを大事に ●サービスの時期によって柔軟に ○ 弊社ケース ■ 初期はインフラチーム率高め ■ 安定運用 & K8s 習熟度向上してくるとアプリチーム率高め ■ 境界のあいまいさは許容 21 インフラチーム / アプリチームの壁を越えてコミュニケーション 現時点の状況 Dockerfile インフラチーム アプリチーム K8s manifest K8s Cluster Config Dockerfile インフラチーム アプリチーム K8s manifest K8s Cluster Config Dockerfile インフラチーム アプリチーム K8s manifest K8s Cluster Config CI/CD CI/CDCI/CD むしろ、従来の構造のチームにキッチリ 合わせようとしてしまうと Kubernetes 的/クラウドネイティブ的 なソフトを活かせなくなる可能性も
  22. 22. ●グリーでは現状 ホストベース環境が主流 ○ コンテナ/Kubernetes に向けて即組織刷新とかはない ●いま 2020 年、両方やらなくちゃいけない ●Kubernetes との向き合い方には気をつける ○ コンテナ管理ツール ではなく プラットフォームとして ○ 今までのやり方を延長するより、段を登ってみる ○ さらにプラットフォームのためのプラットフォームでもある ○ プラットフォームの意図を汲む 22 従来のホストベース環境も両方見ていく 現時点の状況
  23. 23. ● Dokcer も Kubernetes も関係無しに 実現するとしたら? ○ 環境ごとに VPC を分ける VPC ごとの DNS サーバを使って レコードを切り替える ○ AWS Route53 など 23 例. 23 DNS 管理者の帽子 「自前 DNS サーバでコントロールしよう」 アプリから外部サービス API を参照する。 Production / QA / Develop の 環境ごとに参照先を切りかえたい… どうやって実現しようか
  24. 24. ● Dokcer コンテナ的なお作法で 実現するとしたら? ○ コンテナ内で環境変数を参照させ 実行環境で環境変数に参照先ドメインを流し込む ○ コンテナ内に全パターンの config を埋めておき、 環境変数で config パスを切り替える 24 例. 24 Docker の帽子 「APP_PORT_TCP_ADDR 環境変数を 参照させよう」 DNS 管理者の帽子 「自前 DNS サーバでコントロールしよう」 アプリから外部サービス API を参照する。 Production / QA / Develop の 環境ごとに参照先を切りかえたい… どうやって実現しようか
  25. 25. ● Kubernetes のお作法で 実現するとしたら? ○ コンテナ内の名前は固定してよい Service リソースで流し込む ○ または Docker のとこで挙げたパターンもよい 25 例. 25 Kubernetes の帽子 「Service リソース名を参照させよう」 「もしくは環境変数でもよい」 Docker の帽子 「APP_PORT_TCP_ADDR 環境変数を 参照させよう」 DNS 管理者の帽子 「自前 DNS サーバでコントロールしよう」 アプリから外部サービス API を参照する。 Production / QA / Develop の 環境ごとに参照先を切りかえたい… どうやって実現しようか
  26. 26. ●帽子のかぶりわけ ○ 範囲を明確に認識出来ている状態 ●まずは一番上の帽子をかぶる ○ だめなら下の帽子をかぶりなおす ○ どの帽子をかぶっているかを忘れない ●柔軟なプラットフォームほど 帽子を見失いがち ●作る側に回るときにも必要 26 このプラットフォームはどう使われることを想定しているのか プラットフォームの意図を汲む Kubernetes の帽子 「Service リソース名を参照させよう」 「もしくは環境変数でもよい」 Docker の帽子 「APP_PORT_TCP_ADDR 環境変数を 参照させよう」 外部サービスの参照先を 環境ごとに切りかえたい … DNS 管理者の帽子 「自前 DNS サーバでコントロールしよう」
  27. 27. ●アンラーニングで新しい帽子を手に入れる ○ 既存知識との境界を認識する、引きずらない ■ 既存知識の活用・応用はあとからでいい ●多くの場合、高次の帽子が "筋がいい" が ○ ときには帽子をかぶりわける ○ プラットフォームの機能が十分でないとき ○ あえて違う作法を選ぶとき ●帽子を混ぜない!どっちつかずは運用混乱を招く ○ どっちつかずの例. ■ ingress-controller で LB を作成したが、別の方法で設定追加 ■ external-dns で作成したレコードと手動作成したレコード混在して参照させる 27 新しい帽子を手に入れる・帽子をかぶりわける どっちつかずの帽子
  28. 28. ●コンテナ・クラウドネイティブ時代も変わらないもの ○ アプリチームがビジネスに集中できる基盤を提供する ○ 横串でノウハウ・サービスを展開する ●ホストベース時代とコンテナ時代の構造の違いを認識 ○ どちらにもマッチするチームは難しい ○ (気持ちは) チームの柵を越えていく ●インフラの階層ごとに頭を切り替える ○ インフラ領域も確実に抽象化層が増えた ○ 帽子をかぶりわけるように ○ どの階層の話なのか? をはっきり 28 移行期のインフラエンジニアとして ホストベース時代からコンテナ時代へ
  29. 29. 29 29 ⓘ Start presenting to display the poll results on this slide. よろしければ教えて下さい皆様の担当領域は?
  30. 30. 30
  31. 31. 31 Q1. Docker クイズ (The PID1 Problem) 資料 参考リンク ● "Docker/Kubernetes で PID 1 問題を回避する" https://text.superbrothers.dev/200328-how-to-avoid-pid-1- problem-in-kubernetes/ ● "PID1 は、カーネルから特別扱いされてるって本当ですか?" https://speakerdeck.com/superbrothers/pid1-ha- kanerukara-te-bie-xi-isareterututeben-dang-desuka ● "Docker and Node.js Best Practices" > Node.js was not designed to run as PID 1 which leads to unexpected behaviour … https://github.com/nodejs/docker-node/blob/master/docs/BestPractices.md#handling-kernel-signals ● Google Cloud "PID 1、シグナル処理、ゾンビプロセスの適切な処理" https://cloud.google.com/solutions/best- practices-for-building-containers?hl=ja#signal-handling ● docker アプリが適切な signal handling をしていない場合に、アプリの適切な終了処理ができなかったり、実行環境・ア プリによっては fork したプロセスが回収されずゾンビ大量発生などの問題を招く ● 現実的には nodejs や LL の簡易サーバ、crond などで遭遇しがち ● 自分のアプリが適切に handling できているかについては、クイズのように docker run してみて Ctrl+C や docker stop / docker kill --signal="TERM" のようにしてみると簡単に確認できる ● 対応については、alpine ベースであれば apk で tini (軽量 init プロセス) を入れてしまうのが便利 $ docker run --rm busybox sleep 10000
  32. 32. 32 Q2. Kubernetes クイズ (dnsPolicy ClusterFirst の設定) 資 料 参考リンク ● "RESOLV.CONF(5)" https://linuxjm.osdn.jp/html/LDP_man-pages/man5/resolv.conf.5.html ● "Kubernetes Documentation >..> DNS for Services and Pods" https://kubernetes.io/docs/concepts/services- networking/dns-pod-service/#srv-records ● GitHub "update docker's resolv.conf file with options ndots:5" https://github.com/kubernetes/kubernetes/pull/10266 ● GREE Engineer's blog "スマホゲームの API サーバにおける EKS の運用事例 > DNS の名前解決に失敗する" https://labs.gree.jp/blog/2020/01/20271/#anker612 ● "Amazon EKS での DNS 障害のトラブルシューティング" https://aws.amazon.com/jp/premiumsupport/knowledge- center/eks-dns-failure/ ● まずは resolv.conf(5) man の options ndots 項を参照のこと ● Kubernetes 固有の問題。ふつうの(?) Linux 環境であれば ndots: 5 が入っていることはそうそう無いので、 curl https://greetech.example.com/ で何も問題ない ● Kubernetes では、SRV レコードによるサービスディスカバリの利便性のためにこういう設定になっている (下記 github の kubernetes/kubernetes リンクも参照) ● クイズで問題のある例として挙げた方法では、IPv6 が有効な場合 AAAA レコードにも問い合わせを行い、1つの名前解決 だけで 10 以上のクエリが発生する場合がある # 標準的な resolv.conf (EKS) nameserver 10.100.0.10 search default.svc.cluster.local svc.cluster.local cluster.local ec2.internal options ndots:5 search リスト、ndots: 5 が特徴 → 名前に含まれるドットが5より少なければ search リストを順番にためすよ、の意

    Be the first to comment

GREE Tech Conference 2020 で発表された資料です。 https://techcon.gree.jp/2020/session/Session-4

Views

Total views

744

On Slideshare

0

From embeds

0

Number of embeds

664

Actions

Downloads

0

Shares

0

Comments

0

Likes

0

×