Submit Search
Upload
コンテナ時代にインフラエンジニアは何をするのか
•
0 likes
•
2,396 views
gree_tech
Follow
GREE Tech Conference 2020 で発表された資料です。 https://techcon.gree.jp/2020/session/Session-4
Read less
Read more
Engineering
Slideshow view
Report
Share
Slideshow view
Report
Share
1 of 32
Download now
Download to read offline
Recommended
20220409 AWS BLEA 開発にあたって検討したこと
20220409 AWS BLEA 開発にあたって検討したこと
Amazon Web Services Japan
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
Hiromasa Oka
AWS CLIでAssumeRole
AWS CLIでAssumeRole
Tetsunori Nishizawa
DeNA の AWS アカウント管理とセキュリティ監査自動化
DeNA の AWS アカウント管理とセキュリティ監査自動化
DeNA
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
Trainocate Japan, Ltd.
Oracleからamazon auroraへの移行にむけて
Oracleからamazon auroraへの移行にむけて
Yoichi Sai
20190911 AWS Black Belt Online Seminar AWS Batch
20190911 AWS Black Belt Online Seminar AWS Batch
Amazon Web Services Japan
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga
Recommended
20220409 AWS BLEA 開発にあたって検討したこと
20220409 AWS BLEA 開発にあたって検討したこと
Amazon Web Services Japan
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
ZOZOTOWNのマルチクラウドへの挑戦と挫折、そして未来
Hiromasa Oka
AWS CLIでAssumeRole
AWS CLIでAssumeRole
Tetsunori Nishizawa
DeNA の AWS アカウント管理とセキュリティ監査自動化
DeNA の AWS アカウント管理とセキュリティ監査自動化
DeNA
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
Trainocate Japan, Ltd.
Oracleからamazon auroraへの移行にむけて
Oracleからamazon auroraへの移行にむけて
Yoichi Sai
20190911 AWS Black Belt Online Seminar AWS Batch
20190911 AWS Black Belt Online Seminar AWS Batch
Amazon Web Services Japan
コンテナ未経験新人が学ぶコンテナ技術入門
コンテナ未経験新人が学ぶコンテナ技術入門
Kohei Tokunaga
AWSで実現するバックアップとディザスタリカバリ
AWSで実現するバックアップとディザスタリカバリ
Amazon Web Services Japan
20190731 Black Belt Online Seminar Amazon ECS Deep Dive
20190731 Black Belt Online Seminar Amazon ECS Deep Dive
Amazon Web Services Japan
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
AWS X-Rayによるアプリケーションの分析とデバッグ
AWS X-Rayによるアプリケーションの分析とデバッグ
Amazon Web Services Japan
NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
NTT DATA Technology & Innovation
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Amazon Web Services Japan
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
Amazon Web Services Japan
GitLab から GitLab に移行したときの思い出
GitLab から GitLab に移行したときの思い出
富士通クラウドテクノロジーズ株式会社
20191029 AWS Black Belt Online Seminar Elastic Load Balancing (ELB)
20191029 AWS Black Belt Online Seminar Elastic Load Balancing (ELB)
Amazon Web Services Japan
20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatib...
20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatib...
Amazon Web Services Japan
20200714 AWS Black Belt Online Seminar Amazon Neptune
20200714 AWS Black Belt Online Seminar Amazon Neptune
Amazon Web Services Japan
AWS Black Belt Online Seminar 2017 Amazon DynamoDB
AWS Black Belt Online Seminar 2017 Amazon DynamoDB
Amazon Web Services Japan
Amazon Athena で実現する データ分析の広がり
Amazon Athena で実現する データ分析の広がり
Amazon Web Services Japan
20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用
20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用
Amazon Web Services Japan
Dep005 azure ネットワーク設計
Dep005 azure ネットワーク設計
Tech Summit 2016
Infrastructure as Code (IaC) 談義 2022
Infrastructure as Code (IaC) 談義 2022
Amazon Web Services Japan
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
Masahito Zembutsu
20190723 AWS Black Belt Online Seminar AWS CloudHSM
20190723 AWS Black Belt Online Seminar AWS CloudHSM
Amazon Web Services Japan
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介
cloudconductor
Dockerでデプロイ
Dockerでデプロイ
oshiro_seiya
More Related Content
What's hot
AWSで実現するバックアップとディザスタリカバリ
AWSで実現するバックアップとディザスタリカバリ
Amazon Web Services Japan
20190731 Black Belt Online Seminar Amazon ECS Deep Dive
20190731 Black Belt Online Seminar Amazon ECS Deep Dive
Amazon Web Services Japan
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Amazon Web Services Japan
AWS X-Rayによるアプリケーションの分析とデバッグ
AWS X-Rayによるアプリケーションの分析とデバッグ
Amazon Web Services Japan
NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
NTT DATA Technology & Innovation
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Amazon Web Services Japan
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
Amazon Web Services Japan
GitLab から GitLab に移行したときの思い出
GitLab から GitLab に移行したときの思い出
富士通クラウドテクノロジーズ株式会社
20191029 AWS Black Belt Online Seminar Elastic Load Balancing (ELB)
20191029 AWS Black Belt Online Seminar Elastic Load Balancing (ELB)
Amazon Web Services Japan
20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatib...
20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatib...
Amazon Web Services Japan
20200714 AWS Black Belt Online Seminar Amazon Neptune
20200714 AWS Black Belt Online Seminar Amazon Neptune
Amazon Web Services Japan
AWS Black Belt Online Seminar 2017 Amazon DynamoDB
AWS Black Belt Online Seminar 2017 Amazon DynamoDB
Amazon Web Services Japan
Amazon Athena で実現する データ分析の広がり
Amazon Athena で実現する データ分析の広がり
Amazon Web Services Japan
20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用
20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用
Amazon Web Services Japan
Dep005 azure ネットワーク設計
Dep005 azure ネットワーク設計
Tech Summit 2016
Infrastructure as Code (IaC) 談義 2022
Infrastructure as Code (IaC) 談義 2022
Amazon Web Services Japan
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
Masahito Zembutsu
20190723 AWS Black Belt Online Seminar AWS CloudHSM
20190723 AWS Black Belt Online Seminar AWS CloudHSM
Amazon Web Services Japan
What's hot
(20)
AWSで実現するバックアップとディザスタリカバリ
AWSで実現するバックアップとディザスタリカバリ
20190731 Black Belt Online Seminar Amazon ECS Deep Dive
20190731 Black Belt Online Seminar Amazon ECS Deep Dive
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
AWS X-Rayによるアプリケーションの分析とデバッグ
AWS X-Rayによるアプリケーションの分析とデバッグ
NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
NTTデータ流Infrastructure as Code~ 大規模プロジェクトを通して考え抜いた基盤自動化の新たな姿~(NTTデータ テクノロジーカンフ...
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Kinesis + Elasticsearchでつくるさいきょうのログ分析基盤
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
GitLab から GitLab に移行したときの思い出
GitLab から GitLab に移行したときの思い出
20191029 AWS Black Belt Online Seminar Elastic Load Balancing (ELB)
20191029 AWS Black Belt Online Seminar Elastic Load Balancing (ELB)
20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatib...
20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatib...
20200714 AWS Black Belt Online Seminar Amazon Neptune
20200714 AWS Black Belt Online Seminar Amazon Neptune
AWS Black Belt Online Seminar 2017 Amazon DynamoDB
AWS Black Belt Online Seminar 2017 Amazon DynamoDB
Amazon Athena で実現する データ分析の広がり
Amazon Athena で実現する データ分析の広がり
20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用
20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用
Dep005 azure ネットワーク設計
Dep005 azure ネットワーク設計
Infrastructure as Code (IaC) 談義 2022
Infrastructure as Code (IaC) 談義 2022
Re: ゼロから始める監視設計
Re: ゼロから始める監視設計
20190723 AWS Black Belt Online Seminar AWS CloudHSM
20190723 AWS Black Belt Online Seminar AWS CloudHSM
Similar to コンテナ時代にインフラエンジニアは何をするのか
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介
cloudconductor
Dockerでデプロイ
Dockerでデプロイ
oshiro_seiya
半日でわかる コンテナー技術 (入門編)
半日でわかる コンテナー技術 (入門編)
Toru Makabe
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
Akihiro Kuwano
Fabric Essentials
Fabric Essentials
Yoshinari Takaoka
サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所
サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所
真吾 吉田
Dockerを使ったローカルでの開発から本番環境へのデプロイまで
Dockerを使ったローカルでの開発から本番環境へのデプロイまで
Ryo Nakamaru
捕鯨!詳解docker
捕鯨!詳解docker
雄哉 吉田
Tdd
Tdd
Tsukasa Oishi
Docker Swarm モード にゅうもん
Docker Swarm モード にゅうもん
Masahito Zembutsu
Dapr on Kubernetes
Dapr on Kubernetes
Shiho ASA
Jenkins cicdテンプレートazure版の利用方法解説
Jenkins cicdテンプレートazure版の利用方法解説
Changhwan Lee
ドリコムJenkins勉強会資料
ドリコムJenkins勉強会資料
Go Sueyoshi (a.k.a sue445)
アドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニング
Yosuke Mizutani
Application Architecture for Enterprise Win Store Apps with DDD Pattern
Application Architecture for Enterprise Win Store Apps with DDD Pattern
Atsushi Kambara
はてなにおける継続的デプロイメントの現状と Docker の導入
はてなにおける継続的デプロイメントの現状と Docker の導入
Yu Nobuoka
The road of Apache CloudStack Contributor (Translation and Patch)
The road of Apache CloudStack Contributor (Translation and Patch)
Kimihiko Kitase
AnsibleおよびDockerで始めるInfrastructure as a Code
AnsibleおよびDockerで始めるInfrastructure as a Code
Satoru Yoshida
Db2 Warehouse Spark利用ガイド チュートリアル編
Db2 Warehouse Spark利用ガイド チュートリアル編
IBM Analytics Japan
ドリコムのInfrastructure as code
ドリコムのInfrastructure as code
Yosuke Hiraishi
Similar to コンテナ時代にインフラエンジニアは何をするのか
(20)
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介
Consulによる運用自律化体験ハンズオンとConsul活用事例紹介
Dockerでデプロイ
Dockerでデプロイ
半日でわかる コンテナー技術 (入門編)
半日でわかる コンテナー技術 (入門編)
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
泥臭い運用から、プログラマブルインフラ構築(に行きたい)
Fabric Essentials
Fabric Essentials
サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所
サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所
Dockerを使ったローカルでの開発から本番環境へのデプロイまで
Dockerを使ったローカルでの開発から本番環境へのデプロイまで
捕鯨!詳解docker
捕鯨!詳解docker
Tdd
Tdd
Docker Swarm モード にゅうもん
Docker Swarm モード にゅうもん
Dapr on Kubernetes
Dapr on Kubernetes
Jenkins cicdテンプレートazure版の利用方法解説
Jenkins cicdテンプレートazure版の利用方法解説
ドリコムJenkins勉強会資料
ドリコムJenkins勉強会資料
アドテク×Scala×パフォーマンスチューニング
アドテク×Scala×パフォーマンスチューニング
Application Architecture for Enterprise Win Store Apps with DDD Pattern
Application Architecture for Enterprise Win Store Apps with DDD Pattern
はてなにおける継続的デプロイメントの現状と Docker の導入
はてなにおける継続的デプロイメントの現状と Docker の導入
The road of Apache CloudStack Contributor (Translation and Patch)
The road of Apache CloudStack Contributor (Translation and Patch)
AnsibleおよびDockerで始めるInfrastructure as a Code
AnsibleおよびDockerで始めるInfrastructure as a Code
Db2 Warehouse Spark利用ガイド チュートリアル編
Db2 Warehouse Spark利用ガイド チュートリアル編
ドリコムのInfrastructure as code
ドリコムのInfrastructure as code
More from gree_tech
アナザーエデンPC版リリースへの道のり 〜WFSにおけるマルチプラットフォーム対応の取り組み〜
アナザーエデンPC版リリースへの道のり 〜WFSにおけるマルチプラットフォーム対応の取り組み〜
gree_tech
GREE VR Studio Laboratory「XR-UX Devプロジェクト」の成果紹介
GREE VR Studio Laboratory「XR-UX Devプロジェクト」の成果紹介
gree_tech
REALITYアバターを様々なメタバースで活躍させてみた - GREE VR Studio Laboratory インターン研究成果発表
REALITYアバターを様々なメタバースで活躍させてみた - GREE VR Studio Laboratory インターン研究成果発表
gree_tech
アプリ起動時間高速化 ~推測するな、計測せよ~
アプリ起動時間高速化 ~推測するな、計測せよ~
gree_tech
長寿なゲーム事業におけるアプリビルドの効率化
長寿なゲーム事業におけるアプリビルドの効率化
gree_tech
Cloud Spanner をより便利にする運用支援ツールの紹介
Cloud Spanner をより便利にする運用支援ツールの紹介
gree_tech
WFSにおけるCloud SpannerとGKEを中心としたGCP導入事例の紹介
WFSにおけるCloud SpannerとGKEを中心としたGCP導入事例の紹介
gree_tech
SINoALICE -シノアリス- Google Cloud Firestoreを用いた観戦機能の実現について
SINoALICE -シノアリス- Google Cloud Firestoreを用いた観戦機能の実現について
gree_tech
海外展開と負荷試験
海外展開と負荷試験
gree_tech
翻訳QAでのテスト自動化の取り組み
翻訳QAでのテスト自動化の取り組み
gree_tech
組み込み開発のテストとゲーム開発のテストの違い
組み込み開発のテストとゲーム開発のテストの違い
gree_tech
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
gree_tech
データエンジニアとアナリストチーム兼務になった件について
データエンジニアとアナリストチーム兼務になった件について
gree_tech
シェアドサービスとしてのデータテクノロジー
シェアドサービスとしてのデータテクノロジー
gree_tech
「ドキュメント見つからない問題」をなんとかしたい - 横断検索エンジン導入の取り組みについて-
「ドキュメント見つからない問題」をなんとかしたい - 横断検索エンジン導入の取り組みについて-
gree_tech
「Atomic Design × Nuxt.js」コンポーネント毎に責務の範囲を明確にしたら幸せになった話
「Atomic Design × Nuxt.js」コンポーネント毎に責務の範囲を明確にしたら幸せになった話
gree_tech
比較サイトの検索改善(SPA から SSR に変換)
比較サイトの検索改善(SPA から SSR に変換)
gree_tech
コードの自動修正によって実現する、機能開発を止めないフレームワーク移行
コードの自動修正によって実現する、機能開発を止めないフレームワーク移行
gree_tech
「やんちゃ、足りてる?」〜ヤンマガWebで挑戦を続ける新入りエンジニア〜
「やんちゃ、足りてる?」〜ヤンマガWebで挑戦を続ける新入りエンジニア〜
gree_tech
法人向けメタバースプラットフォームの開発の裏側をのぞいてみた(仮)
法人向けメタバースプラットフォームの開発の裏側をのぞいてみた(仮)
gree_tech
More from gree_tech
(20)
アナザーエデンPC版リリースへの道のり 〜WFSにおけるマルチプラットフォーム対応の取り組み〜
アナザーエデンPC版リリースへの道のり 〜WFSにおけるマルチプラットフォーム対応の取り組み〜
GREE VR Studio Laboratory「XR-UX Devプロジェクト」の成果紹介
GREE VR Studio Laboratory「XR-UX Devプロジェクト」の成果紹介
REALITYアバターを様々なメタバースで活躍させてみた - GREE VR Studio Laboratory インターン研究成果発表
REALITYアバターを様々なメタバースで活躍させてみた - GREE VR Studio Laboratory インターン研究成果発表
アプリ起動時間高速化 ~推測するな、計測せよ~
アプリ起動時間高速化 ~推測するな、計測せよ~
長寿なゲーム事業におけるアプリビルドの効率化
長寿なゲーム事業におけるアプリビルドの効率化
Cloud Spanner をより便利にする運用支援ツールの紹介
Cloud Spanner をより便利にする運用支援ツールの紹介
WFSにおけるCloud SpannerとGKEを中心としたGCP導入事例の紹介
WFSにおけるCloud SpannerとGKEを中心としたGCP導入事例の紹介
SINoALICE -シノアリス- Google Cloud Firestoreを用いた観戦機能の実現について
SINoALICE -シノアリス- Google Cloud Firestoreを用いた観戦機能の実現について
海外展開と負荷試験
海外展開と負荷試験
翻訳QAでのテスト自動化の取り組み
翻訳QAでのテスト自動化の取り組み
組み込み開発のテストとゲーム開発のテストの違い
組み込み開発のテストとゲーム開発のテストの違い
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
サーバーフレームワークに潜んでる脆弱性検知ツール紹介
データエンジニアとアナリストチーム兼務になった件について
データエンジニアとアナリストチーム兼務になった件について
シェアドサービスとしてのデータテクノロジー
シェアドサービスとしてのデータテクノロジー
「ドキュメント見つからない問題」をなんとかしたい - 横断検索エンジン導入の取り組みについて-
「ドキュメント見つからない問題」をなんとかしたい - 横断検索エンジン導入の取り組みについて-
「Atomic Design × Nuxt.js」コンポーネント毎に責務の範囲を明確にしたら幸せになった話
「Atomic Design × Nuxt.js」コンポーネント毎に責務の範囲を明確にしたら幸せになった話
比較サイトの検索改善(SPA から SSR に変換)
比較サイトの検索改善(SPA から SSR に変換)
コードの自動修正によって実現する、機能開発を止めないフレームワーク移行
コードの自動修正によって実現する、機能開発を止めないフレームワーク移行
「やんちゃ、足りてる?」〜ヤンマガWebで挑戦を続ける新入りエンジニア〜
「やんちゃ、足りてる?」〜ヤンマガWebで挑戦を続ける新入りエンジニア〜
法人向けメタバースプラットフォームの開発の裏側をのぞいてみた(仮)
法人向けメタバースプラットフォームの開発の裏側をのぞいてみた(仮)
コンテナ時代にインフラエンジニアは何をするのか
1.
コンテナ時代に インフラエンジニアは何をするの か グリー株式会社 開発本部 駒﨑
拓斗
2.
2 ●グリー入社前 ○ 組み込みソフト企業 ○ 携帯電話向けプラットフォームの開発 ●2012年より
グリーインフラ部門 ○ 開発環境の構築、運用 ○ デプロイツール・フロー改善 ○ 商用サービス部門向き合いのインフラ構築・運用・相談 ○ 最近の主なフィールドは AWS や GCP 2 自己紹介 駒﨑 拓斗
3.
3 3 とつぜんですが クイズです
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 ⓘ Start presenting
to display the poll results on this slide. Ctrl+c で停止可能なのはどれ? (複数選択)
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.
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 ⓘ Start presenting
to display the poll results on this slide. DNS トラフィックが少ないのは?
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 お付き合いありがとうございました
11.
11 11 本題 コンテナ時代のインフラ
12.
●アプリケーション担当者/チーム (アプリチーム) ○ あるサービスのビジネスロジックを担当する ○
カスタマーに対し サービスを開発、運用する ○ 典型的には、サーバアプリケーション開発者チーム ●インフラストラクチャ担当者/チーム (インフラチーム) ○ アプリチームに対し基盤を提供、開発、運用する ○ 複数のサービスを受け持ち、共通課題を横串で担当する ■ 横串で受け持つことで、コスト・リソースの最適化を狙う ●理想的にはワンチームでプロダクトが作れたらよい、が ○ 複数事業をさばくため 12 アプリチームとインフラチーム 背景: 本日の "インフラエンジニア" について
13.
●サービスを提供するインフラは絶えず変化 ●ベアメタルから VM、コンテナへ ●2020 現在グリーでは ○
オンプレミス・パブリッククラウド併用中 ○ さらにパブリッククラウドへ移行中 13 グリーグループのインフラの歩み 背景: Web サービスインフラの移り変わり ベアメタル オンプレ VM パブリッククラウド VM サーバレス コンテナ
14.
●ベアメタル時代 ○ サーバ調達、インベントリ管理、OS 設定、プロビジョニング、... ○
監視・アラートシステム 内製 ●VM 時代 初期 ○ プロビジョニングツールの導入 ○ Infrastructure as Code による自動化 ○ 構造はそのまま クラウドへの "リフト" が行われた ●VM 時代 後期 ○ パブリッククラウドの活用 ■ プログラマブル / 宣言的な構築 により自動化がさらに進む ■ クラウドに合わせた設計の浸透 ■ スケーリング操作など一部運用がアプリチーム側へ 14 インフラのデリバリー・運用の変化 これまでの変化 (ホストベース時代)
15.
●実用的なコンテナ基盤の普及 ○ アプリチームからもコンテナが身近なものに ■ docker-compose ■
Cloud Run ■ AWS copilot (ecs-cli) ■ Kubernetes ●マネージド Kubernetes の大きなインパクト 15 コンテナ時代へ
16.
16 消えるインフラ業務、残る生まれるインフラ業務 マネージド Kubernetes の出現 ランタイム
/ Lib 更新したい VM イメージ作り直してもらえます か サーバにつなげる 最小限の E2E 環境がほしい 構築とデプロイお願いします デプロイツールの改修を … Dockerfile をちょいと FROM php:7.4-apache 、と クラスタぽちぽち、 Deployment に Service に Ingress 書いて、apply 、と
17.
●たしかに 一部の既存業務は ほぼなくなった ○
VM イメージ管理 ○ デプロイツール ○ オートスケーリング設定 ●引き続きやってくモノ・新しく生まれるモノ ○ サイト信頼性エンジニアリング (SRE) 関連 ■ 可観測性の面でより重要度が高まる ○ データストアやネットワーク、CDN などの専門知識 ○ 本番運用に耐えるための Kubernetes 自体の知識 ○ これまでも VM やパブリッククラウドの登場による変化はあったが Kubernetes による変化はそれよりかなり大きい 17 消えるインフラ業務、残る生まれるインフラ業務 マネージド Kubernetes の出現
18.
●(少なくとも今のとこは) まだまだ ●例. 冒頭のクイズの領域 ○
Q1. Docker クイズ (The PID1 Problem) ■ Dockerfile の書き方を気をつける問題、nodejs で遭遇しがち ○ Q2. Kubernetes クイズ (dnsPolicy ClusterFirst の設定) ■ 名前解決のお作法に気をつける問題 ○ しかし全くビジネスロジックには関係無い ■ アプリチームが頑張るところだろうか? ■ 組織として横串で共有すべきノウハウの類 ●"アプリチームに基盤を提供する" 仕事の本質は同じ ○ が、どこまでが基盤なの? 18 Kubernetes でインフラの業務範囲はどんどん縮小する? これから仕事減りそう?
19.
19 ホストベースのころ 19 PHP : アプリチーム CI
: アプリチーム Deploy : インフラチーム apache : インフラチーム VM : インフラチーム LB : インフラチーム ︙ チーム担当範囲の境界はどこだ これから Dockerfile : アプリチーム...? ちょっとインフラ? CI/CD : アプリ?インフラ? K8s : インフラチーム...? とアプリチーム...? ︙ 従来型分担とのアンマッチ
20.
●ソフトの構造と組織の構造に相関がある、として ●従来のチーム分け ○ VM時代以前(ホストベース) の構造に最適化されたもの ●インフラの新しいレイヤが積まれ構造が変化 ○
一段上のプラットフォームができた ○ 抽象化・ソフトの構造が変化した ○ 従来の組織でアンマッチを感じるのは自然 20 ソフトウェアの変化、変化前の組織とのアンマッチ なぜアンマッチが発生するか
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.
●グリーでは現状 ホストベース環境が主流 ○ コンテナ/Kubernetes
に向けて即組織刷新とかはない ●いま 2020 年、両方やらなくちゃいけない ●Kubernetes との向き合い方には気をつける ○ コンテナ管理ツール ではなく プラットフォームとして ○ 今までのやり方を延長するより、段を登ってみる ○ さらにプラットフォームのためのプラットフォームでもある ○ プラットフォームの意図を汲む 22 従来のホストベース環境も両方見ていく 現時点の状況
23.
● Dokcer も
Kubernetes も関係無しに 実現するとしたら? ○ 環境ごとに VPC を分ける VPC ごとの DNS サーバを使って レコードを切り替える ○ AWS Route53 など 23 例. 23 DNS 管理者の帽子 「自前 DNS サーバでコントロールしよう」 アプリから外部サービス API を参照する。 Production / QA / Develop の 環境ごとに参照先を切りかえたい… どうやって実現しようか
24.
● Dokcer コンテナ的なお作法で 実現するとしたら? ○
コンテナ内で環境変数を参照させ 実行環境で環境変数に参照先ドメインを流し込む ○ コンテナ内に全パターンの config を埋めておき、 環境変数で config パスを切り替える 24 例. 24 Docker の帽子 「APP_PORT_TCP_ADDR 環境変数を 参照させよう」 DNS 管理者の帽子 「自前 DNS サーバでコントロールしよう」 アプリから外部サービス API を参照する。 Production / QA / Develop の 環境ごとに参照先を切りかえたい… どうやって実現しようか
25.
● Kubernetes のお作法で 実現するとしたら? ○
コンテナ内の名前は固定してよい Service リソースで流し込む ○ または Docker のとこで挙げたパターンもよい 25 例. 25 Kubernetes の帽子 「Service リソース名を参照させよう」 「もしくは環境変数でもよい」 Docker の帽子 「APP_PORT_TCP_ADDR 環境変数を 参照させよう」 DNS 管理者の帽子 「自前 DNS サーバでコントロールしよう」 アプリから外部サービス API を参照する。 Production / QA / Develop の 環境ごとに参照先を切りかえたい… どうやって実現しようか
26.
●帽子のかぶりわけ ○ 範囲を明確に認識出来ている状態 ●まずは一番上の帽子をかぶる ○ だめなら下の帽子をかぶりなおす ○
どの帽子をかぶっているかを忘れない ●柔軟なプラットフォームほど 帽子を見失いがち ●作る側に回るときにも必要 26 このプラットフォームはどう使われることを想定しているのか プラットフォームの意図を汲む Kubernetes の帽子 「Service リソース名を参照させよう」 「もしくは環境変数でもよい」 Docker の帽子 「APP_PORT_TCP_ADDR 環境変数を 参照させよう」 外部サービスの参照先を 環境ごとに切りかえたい … DNS 管理者の帽子 「自前 DNS サーバでコントロールしよう」
27.
●アンラーニングで新しい帽子を手に入れる ○ 既存知識との境界を認識する、引きずらない ■ 既存知識の活用・応用はあとからでいい ●多くの場合、高次の帽子が
"筋がいい" が ○ ときには帽子をかぶりわける ○ プラットフォームの機能が十分でないとき ○ あえて違う作法を選ぶとき ●帽子を混ぜない!どっちつかずは運用混乱を招く ○ どっちつかずの例. ■ ingress-controller で LB を作成したが、別の方法で設定追加 ■ external-dns で作成したレコードと手動作成したレコード混在して参照させる 27 新しい帽子を手に入れる・帽子をかぶりわける どっちつかずの帽子
28.
●コンテナ・クラウドネイティブ時代も変わらないもの ○ アプリチームがビジネスに集中できる基盤を提供する ○ 横串でノウハウ・サービスを展開する ●ホストベース時代とコンテナ時代の構造の違いを認識 ○
どちらにもマッチするチームは難しい ○ (気持ちは) チームの柵を越えていく ●インフラの階層ごとに頭を切り替える ○ インフラ領域も確実に抽象化層が増えた ○ 帽子をかぶりわけるように ○ どの階層の話なのか? をはっきり 28 移行期のインフラエンジニアとして ホストベース時代からコンテナ時代へ
29.
29 29 ⓘ Start presenting
to display the poll results on this slide. よろしければ教えて下さい皆様の担当領域は?
30.
30
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 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 リストを順番にためすよ、の意
Download now