Docker Part3

LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker Part2
https://mao.5ch.net/test/read.cgi/linux/1506574845/

AWSはCloudFormationあるけど
terraformより色々使いづらい点が多い
AWS製にも関わらず
たまにCloudFormationでだけ設定できない項目があったりする

S3の期限切れ削除マーカーの削除の設定が
何故か未だに未実装

https://stackoverflow.com/questions/40179860/support-for-expired-object-delete-marker-with-cloudformation

この質問が投稿されたのは2016年10月だが
2020年になっても放置
忘れられているっぽい

まあ本家のツールが使いにくいっていうのならTerraformとかの意味があると思うけど
あとAWSとGCPを行ったり来たりしたり、同じものを別々の場所に構築するとか
コード共通でできるんでしょ？しらんけどｗ

マルチクラウドは出来るらしいがやったことない
GCPやAzureは使ったことが無いし

開発環境と同じ構成で
EC2インスタンスのスペックやドメインだけ変えて作るのは可能

Terraformの方が便利とは言っても
複数モジュールの同時デプロイや
モジュール間の値の受け渡しが
Terraformだけでは不便なので
最近Terragruntも使い始めた

コスト削減のために、開発環境では使わない機能がある、
あるいは複数環境で1つのリソースを共有する場合に
巨大モジュールを作って大量の変数
でAWSリソースを作るか作らないかを制御するより
Terraformモジュールを分けた方が良いというのもある

Kubernetesを使ってもインフラの管理から完全に逃れることはできない

TerraformのKubernetesプロバイダーで
helmのデプロイやKubernetesリソースのデプロイも出来る
TerraformのAWSプロバイダーでIAMロールを作成して
kiamで特定ポッドのみにAWSへのアクセス権限付与したりする合わせ技も可能

しかし微妙にかゆいところに手が届かない感はある
公式KubernetesプロバイダーはKubernetesリソースをHCLで書く必要がある
YAMLをそのまま使いたい、CRDを使いたい場合は
公式のKubernetesプロバイダーでは無理
非公式のプロバイダーが必要
banzaicloudのk8sってやつ

CRDが使えないって割と重大な欠陥の気がする

helmは最近v3が出たが
公式Terraformプロバイダーはまだv2までの対応

なにか便利な機能を提供してくれるならいいけど、
「使い方を変えるだけ」の道具はいらないなぁ

公式で同じことできるんでしょ？
それが簡単になったわけじゃなくて
使い方を変えるだけでしょ？

そしてそのプラバイダーが、ある機能に
対応してない困ったぞーっていうのを
永遠と繰り返してるでしょ？

新しいものにどんどんチャレンジして報告するべきじゃないのかな。
それがコミュニティへの貢献ってものでしょ。
キミたちは人柱なんだから。

WindowsのDocker Desktopを2.2にアップグレードしてから、マウントしたボリュームが時々書き込めなくなってエラーになる状態になって
2.1に戻したら直った
調べたら2.1から2.2で内部構造がだいぶ変わってるんやね

>>504
その状態でansibleにやらせる構成管理ってなんなんや
dockerを動かす物理マシンの構成管理だけやるという意味なんか

この前、Docker HubのREAME.mdがGitHubのREADME.mdを中途半端に
持っていくって話をした件だけどGitHub Actionsで同期取るっぽいのがあった
これで指定したやつを持っていってくれるかも
https://github.com/marketplace/actions/docker-hub-readme-description-sync

k3s使ったらメモリー1GBのインスタンス3つでもHA出来る？

k3sはメモリ512MBしか（笑）食わないんだろ？
ならアプリが512MBまでなら動くんじゃね？

k3sでこれだけだと、k8sはどんだけ食うんだよｗ
カーネルの使用メモリが少なくても台無し

workerは別途用意するだろJK

本家k8sは1GB RAMでは足りない気がする
kiamのサーバーと
helm v2のtiller
kube-iam-authenticator

controllerにこの3つを置いているが
2GBから1GBに減らしたらAPIサーバーが使えなくなった
だから本家は最低でも2GBのメモリーが必要

etcdも同居してるからさらに厳しい

なんでk8sってそんなにメモリ食うんだろう？
ただコンテナを管理するだけの仕組みじゃんか

高いVMインスタンスを売りつけるための
戦略としか思えないな
ウェブサーバーとか数十MB程度で動くのに
k8s化した途端1GBとか必要になる。アホかと

他のクラウドはコントローラーがタダで使えるらしいが
AWSだけまだ72ドル掛かる
高杉

大企業にとってははした金だから
それでも使う奴は居るのだろうが

>>523
GKEは安いの知ってる？

ワーカーノードは1GBでも良い
コントローラーノードの金が気になるならGCP行ってGKE使え
うちもGKE使いたい所だが
AWSを使わねばならない
のっぴきならない事情がある

kubernetsとかさ、クラウドの上にクラウドを作ってるみたいで
気持ち悪いんだよね。せっかく便利に使えるようになったクラウドを
なぜコンテナベースで再発明するのか？

>>526
インフラエンジニアの雇用を維持するためだよ。マジで。
自社サービス系のインフラエンジニアって基本的にトラブルがなければ仕事ないから、
自然と問題なく動いているもののオーバーエンジニアリングに向かうものだ。

オーバーエンジニアリング程度なら良いけどさ
メモリ食い過ぎで前より不便にしてるだけなんだよな
インフラ系って、変わってるだけで、何も良くなってない

>>528
いや、だからGKE使えよ？
コントローラー無料だろ？

>>526
元々クラウドのための仕様なんだが……。

ノードの数を負荷に応じて変更できるから、処理が多い時間はノード増やして処理し、少ない時間はノードを減らす事でコストを最適化できるのがk8sの売り。

規模が小さいとこの利点（オートスケーリング）が意味をなさなくなる。

1台しかないならdocker-composeでよくね？
1台しかないなら

従来は高価なオンプレを1台買ってスペック余らせるのが普通だったが、今はクラスタにする事で、オートスケーリングによりスペック（≒コスト）を最適化できるようになった。

ハイスペック1台ならdockerで十分だが、コスト面で最適化されてるかな？という話。

>>532
それだけならECSとかで十分でしょ
k8sは決まったサイズのクラスタを効率的に使うにはいいけど、クラスタそのもののスケーリングにはあまり適してないよ

>>533
k8sはECSより高機能で汎用的だが学習コスト高めという印象。ECSはベンダー製なので、クラスタに関してはその通りだろうが、ベンダーロックインの問題がある。

ベンダーロックインの問題を気にせず、ECSで案件が済むならECSだろう。

たかがコンテナ立ち上げるだけのことにベンダーロックインねえ
事業視点で言えば、k8sに習熟した少数のエンジニアにインフラをロックインされることの方がよほどリスクが大きいと思うけどね

>>528
単に使い所を間違ってるだけとしか思えんが
そもそも別にk8s使わなくてもdockerはある程度規模に応じたオーケストレーションを標準に
近い形で用意しているはずで、それでは管理できないほど巨大な規模のサービスを運用するから
k8sですよ、って事で、当然メモリが食いすぎとか文句言う人が使う物じゃない気はする。
そういう人にはもっと小規模な物あるでしょ？
昔Googleの論文元にHadoop作って訳も分からずに食いついて先進的だカッコいいぜ俺スゲーとか
いって後からやっぱ遅ーえわこれｗとかいってた連中思い出すね。
自分たちが間違った場所に適用してるとは最後まで考えないｗ

>>535
Amazonがk8sのサービス始めたのはこの理由らしいから、そういう意見も多いということなのだろう。

個人的にはk8sよりマルチビルドのdocker file の方が難解だな

>>533
> k8sは決まったサイズのクラスタを効率的に使うにはいいけど、クラスタそのもののスケーリングにはあまり適してないよ

そうだよね？

広大なCPU空間を確保しておいて、自由に使いましょうというのならいいけど
コストの観点から空間自体を減らしたり増やしたりってのは適してないと思う
スケーリングならすでにGCEとかのクラウドの仕組みで実現できたじゃんって思う

そこにGKEを持ってきて使いづらくしたと思ったら、
どうせコンテナベースで課金とかするでしょ？
なんでクラウドの中にさらにクラウド作ってるんだろうって思う

>>537
> 個人的にはk8sよりマルチビルドのdocker file の方が難解だな

マルチステージビルドの事？ どんだけ複雑なんだよｗ

あんなの、中間ファイルは不要だから
前のイメージでビルドしてできた生成物のみ
コピーして使いましょうってだけじゃんか

k8sの嫌なところは短いタイミングで強制アップデートな所だな
これがあるからストレージとしては使えない
データベースは別のサービスを使えってことなんだろうけど、
これがあるからHAの代わりにはならないんだよね

自前k8sなら誰も面倒見てくれないので
アップデートもされない
証明書の期限短くすると
期限切れした時にAPIサーバーと通信できなくなるけど

APIサーバーの証明書は自動更新機能があった気がする

>>538
ワーカーノードは今まで通り課金される

k8sでのサーバーレス関数の実行は
EKSやGKEで最近できるようになったが
一部機能制限がある上に
確保するリソースが多いと通常通り
ワーカーノードを用意した方が安くなる事がある

サーバーレスはコールドスタートによる遅延の問題なども多分まだある

サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る

とは言ってもノードの起動は時間がかかるので
すぐには無理だが

サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る

とは言ってもノードの起動は時間がかかるので
すぐには無理だが

>>539
他人が書いたのを検証するのが難しいってことね。他人に依存するかどうかという視点の話。

>>543
ノードの増減はk8sなくてもできたじゃん？

・負荷の応じてノードが増減できる
だったのが
・負荷に応じてでポットが増減できて、ポットの増減に応じてノードが増減できる
に変わってるじゃん？

二段階になってややこしくなってるし
ノード（課金対象）が増減しない範囲でのポットの増減が存在するわけで、
こんなんで正確な見積もりなんかできるの？

k8sはプロジェクト単位で使うものじゃななくて、
会社として広大なクラスタ空間を予め確保して、その中で複数の異なる
サブプロジェクトをいくつも動かすって使い方をする
Googleぐらいしかまともに使えないよ

k8sはノード＝1つないし少数のそれぞれ違うポットを配置するという使い方じゃないんだよね

1つのノードが複数のポットを動かすスペックを持っていて、
多数の小さなポッドをその中で動かすという使い方をする。

1つのノードで同じ種類のポットがたくさん生まれて
消えるような場合じゃないとうまく使えない

自動管理されたHA環境ではないんだよね

ECSは当初タスク数がEC2インスタンス数と連動しない残念仕様だった

こちらもタスク数に応じてインスタンスが生成される

https://dev.classmethod.jp/cloud/aws/aws-ecs-cluster-auto-scaling/

5タスクを同時に動かそうとすると、
5台のEC2インスタンスが生成される
超シンプル

ECSサービス開始当初はEC2の数とタスクの数を連動させる機能が
無かったが、去年追加された

>>548
それは一般的な使い方としてはわかりやすいし、できるべきだよね。
ただk8sのそもそもの使い方としては、ずれてるんだと思う

その使い方であれば、インスタンスのオートスケールと変わらないわけだし
コンテナが動かせるというメリットはあるけどね

まあ各クラウドの間で共通のインターフェースができて
どこでも動かせるようになるのはいいと思うけど
そのためにもっと大掛かりなシステムのためのk8sを流用してる感が大きい

もっと間を減らしてシンプルに出来なかったのかねぇ
やっぱりクラウドを使ってクラウドを作ってるように見えてしまう

k8sはある程度の空間を確保していて、そこで小さなポッドを多数起動して
全体の○％を超えたり減ったりしたら、クラスタを増減させて
通常はある程度の余力をもたせておく（遊んでるサーバーがある）という使い方なんだろう
インスタンス数を意識して最小の金額にするためのものじゃないかな

ECSも、タスク数をCPU使用率などのメトリクスと連動させれば、
CPU数に応じて「タスク数とインスタンス数」を同時に増やすことが可能
何が違うと言うのか

ECSも以前から「それぞれ別々に」インスタンス数とタスク数を増減する事は出来たが、
協調せずバラバラに動くので、
負荷の増加に反応してサービスのタスク数は増えたのに、
インスタンス数がちゃんと増えなかった、
あるいはインスタンス数は増えたのにサービス数が増えないとか
そんな動きになる可能性があった

1つのノードに複数のコンテナがあるような状況では
さらに話がややこしくなっていた
ノードのCPU使用率が一時的に増加していても、それはサービスの需要が増えたからではなく、
定期バッチ処理で負荷が一時的に高くなったのが原因だったり

Kubernetesはずっと前から
ポッド数によるノード増減ができた
パクったのはECS

自動でノード数の増減が要らない、
常に2台で良いって言うなら
Cluster AutoScalerを使わなくても良い

そもそもECSって目的毎にクラスタ立てるもんだろ？
何でもかんでも一つのクラスタで済ませようなどと考えなければ従来のインスタンスベースのスケーリングで問題ない
それこそ「クラウドなんだから」だ
ID:RH+cWAifの主張は、クラウドの中にクラウドを作っているという批判に対する反論としては的外れに感じる

RH+cWAifは別にクラウドの中にクラウドが〜に対する回答ではない様な。
クラウドが〜は自分で解答書いてるし。

>そのためにもっと大掛かりなシステムのためのk8sを流用してる感が大きい

結局そういうことだよね。

https://aws.アマゾン.com/jp/docker/

Q: Docker Swarm、Kubernetes、Amazon ECS の違いは何ですか?
>多くの Docker コンテナを実行する場合は、Docker Swarm、Kubernetes、Amazon Elastic Container Service (ECS) などの
>オーケストレーションツールを使用することで、何千 (または何百万) ものコンテナの開始、停止、監視が可能になります。

日本は法人向けサービスやったとしても会社の絶対数が少ないしそもそも余程のことが無い限り
1サービスあたりのサーバは10台超えることは無い。じゃあ10台でオートスケールやるコンテナの仕組みは何なのさ？
ってニーズに全然答えようとしていない。

>>551
一番重要なのはコストの最適化なんだから、タスク数もしくは負荷に応じたインスタンス数の増減なんだよね。

> 負荷の増加に反応してサービスのタスク数は増えたのに、
> インスタンス数がちゃんと増えなかった、

そこな。スケールするのがコンテナとインスタンスの
二重になってるからすごく分かりづらい

そもそも一つのインスタンスの中で動くコンテナを増やしても
並列度は上ががっても処理速度は上がらんのよ
（CPUコアを使い切れるようにはなるだろうけど）

パッチ処理みたいに一つのデータを送ってコンテナで処理して終了みたいのであればわかりやすいけど
ウェブサーバーみたいにそれ自体が並列処理対応になってるものの
コンテナを増やしたって何の意味もない。インスタンスの数を増やすか
インスタンスの性能をあげなきゃならないのに、間にコンテナの話が入り込んでくる

>スケールするのがコンテナとインスタンスの
>二重になってるからすごく分かりづらい

分かりにくいのはそうなんだろうけど、インスタンスを跨ぐコンテナはネットワークに
仕掛けしないと駄目だからしょうがないんじゃないの？それはDockerのあの変な
ネットワークの仕組みの為だろうけど。

>（CPUコアを使い切れるようにはなるだろうけど）

結局インスタンス（VM)の上にコンテナ乗っけてるって時点でハードを使い切る
コンテナ技術のメリットは消えており、AmazonのECSはなんちゃってコンテナで
しかない気はする。

コンテナベースにするなら、インスタンスの存在は完全に見えなくしないとだめだろうね。
そして「これこれの性能を持ったコンテナ」を「いくつ使用するか」で課金する。

あとやっぱりノードのアップグレードに伴う再起動が大変
コンテナ数ノード数が少ないとサービス停止に陥ってしまう可能性が高くなる
アップグレードを放置するとそのうちバージョン古すぎて非対応になるし

なんでみんなk8s頑張ろうとしてるんだろう
殆どの用途では大変なだけじゃないか？

Kubernetesの真の価値はそこで利用出来るソフトウェアにあるのでは？

サービスメッシュとかデータベースのオペレーターとか
なんかk8sで動くhelmチャートが動く環境が欲しいのでなければ
ECSとかでも良いし
そっちのほうが簡単と思う

クラウドの中にクラウドとか言うけどさ
サーバーに自分でインストールして
動かすソフトを作る側に取っては
Kubernetesだけ対応すれば
あらゆるクラウドで動くものが作れるようになった

自社のソフトウェアが様々なクラウドで動くのは、
ビジネスチャンスに繋がるんじゃね？

ソフト自体を配布するんじゃなくて
サービスとして売りたいなら
好きな物を使え

例えて言うなら56コア112スレのXeon買ってきてサーバー作って
そこにESXi入れて、CoreOSを20個インストールしてOS１つあたり
5コンテナ入れてk8s組んで、やったぜ俺スゲーとかｗ
そんな感じやな。

でそこで動く肝心なサービスの保守は完全に片手間で1日16時間労働ｗ

恥づｗｗ

仕事でGKE使ってんだけど世の中の8割のサービスはこんな仕組み要らんだろうなーと思いながら触ってる

>>558
ローカル環境でdockerと比べると、k8sは細やかな制御ができる分やりやすい。

k8sはDockerに比べてIngressとロードバランサが優秀。

替わりにマシンスペックを食うわけだが……。コントローラで2W近く使う

k8sとDockerって比べるものじゃないじゃん

スペックを食うってのもなんだかな

swarmの事もたまには思い出してあげてください

>>566
VMからサービス拡大で手軽なクラスタ使いたいから〜、って理由で
Dockerに移行したらのなら、スケール的には一番しっくり来るんだけどね。
流行の技術じゃないから誰も手を出さんのか？まあDocker Swarmできます！
とかじゃ経歴書にかいても自慢出来んだろうけどね。

ASGとECS組合せて使ってる奴が要るけど、あれは何の役に立つの？
スケーリングされたインスタンス内でCPUと同数のスレッドでサービス立ち上げる事と
何が違うのか全く分からん。事態を面倒くさくしているだけに見えるｗ

>>568
デプロイをECSに任せたいだけだよ
自分でホスト弄りたくない

>>569
それはASGでホストが起動したときに、スタートアップか何かでgit pullする事と
何か違うの？

また仮想マシンイメージ最強おじさん？
老害乙wwwwww

git pullするって
仮想マシンイメージにアプリの内容を突っ込む訳でも無いのか
goとかJavaだったら毎回ビルド？
老害どころの騒ぎではないな

デプロイ成功するかどうか
同じ結果になるかどうか
毎回やってからのお楽しみって感じ？
時間がいくらでもあるなら
そうすれば良いんじゃない？

>>571-572
良くわかんねぇけど、もう少し論理的に説明してくれるかな？
うちのシステムは大体それで大丈夫だからね。

今度はDockerじゃなくてgit使えば良いおじさん登場か
それで困ってないなら別に良いんじゃない？

>>574
だから「ASGとECS組合せて使ってる奴が要るけど、あれは何の役に立つの？」って聞いてるじゃん。
君の反論は、デプロイが複雑な場合においては、有効なこともありうる、ってことでオッケー？
それは分かったよ。
ただ、>>556にあるようにDocker自身はコンテナシステムとしてはイマイチだと思う。理由は557と同じね。
少なくとも変なホスト単位のブリッジはやめにしてPOD単位とかService単位で内部ネットワークにしないと
インスタンスが全面に出てきちゃ、導入する意味が無い。ストレージなんかも必要な部分を予めマッピングして
永続化しないと駄目とか、制限が多いし。こんな事いっても君には分からんだろうけど。

じゃあ使わなきゃいいんじゃね？

マジ質問読めよ文網ｗ
日本語通じないなんてDocker使う以前の話だよｗ

Docker使わなかったらOSアップデートは要らないとでも？
普通に要るでしょ
セキュリティ考慮しないから要らないって話？

>>578
ECSの話してるんじゃないの？
ECSは「インスタンスの上」でコンテナを動かすのだから当然Dockerでも
OSアップグレードは必要で、そういった話をするなら、インスタンスOSと
コンテナ上のOSの両方のセキュリティを考慮しなければならない。

ECSとか関係なく
ASG利用の方が信頼性が高い

ECSはASG無しで使えるように設計されてるのか良く分からない
なんか前の登録内容が残ってたり
ECSエージェントのデータを消さないとインスタンスタイプを変更できなかったりした

通常のEC2
・ルートボリュームの内容は再起動に引き継がれる。システムログの内容やSSHして手動設定した内容はインスタンスを削除しない限り残る。
・AWS障害時に自動復旧させるのは可能だが、必ず成功するとは限らない。
・AWSと関係ないOS内部の問題はEC2 Rescueで復旧を自動化できるかもしれないが絶対ではない。

ASG
・ルートボリュームは毎回新しく作られる
・データの保存が必要なワークロードの場合、起動後にスクリプトで別のEBSをアタッチする、S3に保存されたバックアップから復元するなどの方法が必要
・ヘルスチェックをEC2にした場合、システムとインスタンスの2つのチェックのどちらかに失敗するとインスタンスは破棄されて再作成される
・ヘルスチェックをELBにした場合、ELBからのリクエストに暫く応答しなかったら破棄される

いずれの場合も、自前のヘルスチェックシステムがあるなら
それを代わりに使う事は可能だが
そんな物はうちにはない

キャパシティプロバイダーでEC2のタスク数とインスタンス数を連動させる場合はASGが必須

キャパシティプロバイダーの登場以前はタスク数と連動させるのは諦めて
EC2の台数もタスク数も固定するか
それぞれバラバラに設定して
高負荷時に両方とも作動するよう神に祈る他なかった

キャパシティプロバイダーが要らない場合でも
ASGにしておけばコケても復旧するという安心感はある
インスタンスを終了すれば必ず同じ設定で起動するからだ

それらが要らないならASG無しでも良いんじゃね？
同じEC2インスタンスだと
インスタンスサイズ変更時に
ECSエージェントが登録失敗する問題は何か解決策があるだろう

ECSについて言えば、3つのネットワークモードが利用可能

bridge
ポートマッピングを設定した場合、
コンテナにランダムなポートが割り当てられ、外部からアクセス可能になる
同じホスト名で外部からアクセス出来るようにしたいなら、ELBやRoute53を併用する

毎回異なるポート番号になるので、デプロイ時、1つのEC2インスタンスに
同じタスクの新旧バージョンを一時的に同時実行する事が出来る

host
ホストOSと同じネットワークに配置する
ポート番号が衝突するので、
デプロイ時に、同じタスクの新旧バージョンを同じEC2インスタンスで同時実行は不可

awsvpc
ホストOSとは異なるENIにタスクを配置する
異なるENIなので、同じEC2インスタンスでも同じポート番号を利用可能な上に
理論上は最高のネットワーク性能を持つモード
ただし、小さめのインスタンスタイプでは
利用できるENIの数が少ないので
配置出来るawsvpcネットワークモードのタスクは少なくなる

俺はGCPメインだからAWSの話はよくわからんなｗ

AGS？ GKEのオートスケーリング機能みたいなもんか？

ASGは多分似たような機能がどのパブリッククラウドにもあるだろう

k8sをAWSで使う場合も
ワーカーノードはASG管理下で、
ルートボリュームはノードを終了する時に捨てるよね
サーバーはいつでも替えの効く家畜だ

k8sでデータベースなどの
ステートフルなワークロードを扱う場合は、
ノードにルートボリュームとは別に
EBSボリュームをアタッチすれば良い

>>583
そもそもASGはオートスケーリンググループの略だから

Kubernetes 航海1日目
https://mao.5ch.net/test/read.cgi/linux/1553389453/

何？よう知らんけどEKSでもインスタンスは見えてるの？
インスタンス（VM）を管理してその上で動くコンテナも管理しろとか
コンテナの意味なくね？

だからコンテナはアプリをデプロイしやすくするためのものだって言ってんだろ

じゃあ、今ここでDocker関連の話題を書き込んでいる連中はもれなく
デプロイに問題があってDocker使ってるという認識なのｗｗ？
デプロイをコンテナ以外で解決するくらいならサービスメッシュだ
オペレータだhelmチャートだと学習したほうが効率が上がると判断しているのｗ？

>>588
は開発どうしてんの？

それぞれバラバラに環境作って開発？

開発、QA環境へのデプロイとテスト
本番環境へのデプロイまで一貫した環境で行えるのがコンテナ技術のメインの魅力だろう

Kubernetesは複雑すぎる気はするが
他に選択肢があまりない

以前、開発も本番も同じ環境においてるという
狂気の環境で開発した事がある
ローカル開発環境はそもそも存在せず

理由は環境の複製が面倒だから
AWSなのにサーバーを家畜のように使い捨てではなく、ペットのように可愛がってた

サーバーに直接Apacheをインストールしており、
基本的にphpをアップグレードする時や
phpの拡張機能を入れるときは
一か八かの賭けに出る必要があった

AMIを複製して他環境で試す？
そんなのやるぐらいならもうDocker使えよ・・・ってなる
それが一番色んな環境に運ぶの楽じゃん

>>586
昔ながらの方法だったらVMインスタンスもアプリのデプロイも管理しなくて良いとでも言ってるのか？
文句あるなら代替案出せや

スペックに応じたインスタンスが必要なのは
昔ながらの方法でも一緒だろ

>>591
代案つーか、コンテナ技術って時期尚早じゃね？サービスを構成する鯖が
10台20台程度なら入れない方が良いと思う。いつの日か>>557が書いたように
完全にコンテナだけ見ていればOKになるなら入れても良い。

例えば10コアのCPUを10台用意して、30個をフロントWEBに、20個をバックエンドに、
30個を同期サーバ、10個をその他、残りはautoscaling用、1CPU=1コンテナとか
このレベルで意思決定が出来て、そのとおり動くならマイクロサービスは素晴らしい
といえるけど、現状そうなってないんだろ？コンテナが物理サーバーに対して透過的
見えるレベルに到達してないつーか。

いつかそうなるんだろうけどね。
今は面倒なだけという気がする。

>>592
それってデメリットか？
算数が出来れば計算出来るだろ
小規模環境なら台数固定で良いし

OSや、ログ、メトリクス用ポッドの分だけ余裕をもたせて空けておけば良い
それぐらい計算できるだろ？

もしかしてワーカーノードは全部同じグループとか思ってる？
データベースはこのラベルが付いてるノードだけに配置とか、出来るだろ
負荷がデータベースに集中しがちなら、データベースだけ大きなノードのグループで構成するとか

1つのグループに
ごった煮にして配置したりすれば
非常にややこしくなるから
誰もやらない

>>593
そういった諸々に対して>>546>>550-555のような問題がありますよ、という話じゃなかったの？

まあ導入前段階で比較したい、という人と既に導入しちゃった人じゃ観点が合わんのはしょうがないけど。
前の人は既存部分との違いを知ることが主な観点になるけど、既に入れちゃった人はその結果起きた問題を
解決することが観点になるからねｗ

なんか話が噛み合わないと思った
ノードを常に余らせている大規模環境じゃないと使えないとか
>>550

あらゆる種類のワークロードを
1つのノードにごった煮だと勘違いしていたなら納得

>>590
これも、そもそもDocker以前の環境すらまともに運用できなかった人と
Dockerを比べてもなぁ？という話で。もしその狂気の環境の人がDocker使って
k8s入れたとしたら、余計酷くなるだけ（使いこなせるわけが無い）

> AWSなのにサーバーを家畜のように使い捨てではなく、ペットのように可愛がってた

こういう言い方もずっと前からあるけど、実際コンテナとしても「家畜のように」は使えんだろ。
本番で運用するときは当たり前だけど一見ごみの様にしか見えないものでもトラブル解決に
役立ったりするからね。/var/log/httpdだけを永続化しときゃ済むって話じゃない。
1ヵ月後に顧客からトラブルの相談があって、既に再デプロイして非永続領域は消えちゃいました、
ですむなら良いけど。
じゃあどこを永続化しておきましょうかなんて、開発前にすぐに決められるものじゃない。

>>596
>じゃあどこを永続化しておきましょうかなんて、開発前にすぐに決められるものじゃない。

本当に全くDocker使ったことないのに批判してるんだなw
説明しよう

ログは標準出力か標準エラー出力に吐くから永続化はしない
必要ならロギングドライバーを設定するなどして
別サービスに転送する
AWS+ECSならCloudWatchに転送が一番楽

k8sは今のところロギングドライバーの設定はできないので、
コンテナのログを集めるDaemonSetがそれぞれのノードにデプロイするのが一般的
これで全ノードのログを残せる

永続化するのは再起動しても絶対残っていなければならない
データベースのデータなどだけ
どこを永続化するかで悩んだことなんてない

>>597
そういやそういう事やってたなとは思うけど、君が説明しているログ収集云々は
汎用的なDockerの話じゃ無くてベンダーが用意している部分ね。

>AWS+ECSならCloudWatchに転送が一番楽

ん？結局こういうことしたらベンダーロックインって事じゃないの？

> どこを永続化するかで悩んだことなんてない

そうなの？
しかしそれはDBとWEBだけの単純サービスだからじゃないの？
ウチのはある領域に一時的なファイルを作って、S3とかにアップするけどそれが
出来てないよ、とかは普通に来るからね。

ベンダーロックインw
あのさ、ECSでコンテナからCloudWatchに出力するのなんて数クリックでできるわけ。
人的なコストなんかほぼゼロ。
ベンダーロックインっていうのはこれまでの投資が無駄になるから他のベンダーへ移れない状態であって、
そもそも投資がゼロなら何の問題もないの。言ってる意味わかる？

>>598
ECS時は最も手軽な選択肢はCloudWatchってだけ
他にも選択肢はあるが
とりあえずAWSで動けば良いなら一番手軽

手間や金がかかっても
とにかくベンダーロックインは嫌だって言うなら
k8sとELKスタックとかになるんでは

ファイルアップロードにS3使えてない場合は
・2台以上でWebサーバーの構成をするのを諦める　
・多少遅くても良いならAmazon EFSに置く
どちらもやらずに解決する銀の弾丸はない

>>599
なんつーかそれを聞いてもやっぱり、10台程度のサービスでEKS、ECS面倒臭いという
のが結論やね。100台なら話は全く違うけど。じゃあ10台〜100台の間のどのへんが
ボーダーなのかって点には関心あるけど。
どこが汎用のDockerの話でどこがベンダーに依存するのかとか、面倒くさすぎ。
質問を568に戻そうぜ。
「ある1つのインスタンス内で、1プロセスでCPUと同数のスレッドと立ち上げる事と、
　CPUと同数のコンテナを立ち上げること」は何が違うの？

そもそも規模小さかったらリソースの割当に悩む事ないから
その批判がそもそも的外れ

>>601
その2つを比べるのはおかしい
1コンテナ内で複数スレッド立ち上げてもいいし、goなどのマルチスレッド前提の言語ならむしろその方が一般的。

>とにかくベンダーロックインは嫌だって言うなら....
>ファイルアップロードにS3使えてない場合は...

こういう所とかも全部「既存システムでは存在しない問題点に対して解決方法を提示している」様に思えてならん。
他の人はそうは思わんのかな？

>>604
全く意味がわからないな
ログ収集もS3へのアップロードの失敗も既存システムで存在するだろう

>>605
VMは再起動しても永続化してるんだから問題調査は可能でしょ。

S3とか使ってないレガシーシステムでも
ECS使うのは可能

可用性が重要じゃない社内用アプリで
インスタンス1台だけのECSクラスターで
データは全てEBSに書いてる物ならある
ログはDocker経由でCloudWatch Logsに出すようにしてるが

時々OSのAMIとか
ECSエージェントを更新すれば
実行環境は最新の状態に保たれる
ログやメトリクスはマネジメントコンソールから見られるし、
デプロイするだけならSSHすら要らないし楽
使わない理由がない

アプリ部分はAWSとか使ってないので、
移そうと思えば他クラウドにも移せる
今の所やる予定ないし今後も無いと思うが

>>606
オートスケーリング使うなら勝手にterminateされて全部消えるよ
大した規模じゃないからオートスケーリングいらないってんなら、君にはコンテナなんて要らないから帰ってね、としか