[過去ﾛｸﾞ] Docker Part3 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
594: 2020/02/02(日)11:29 ID:cuMP7GqL(4/27) AAS
>>593
そういった諸々に対して>>546>>550-555のような問題がありますよ、という話じゃなかったの？
まあ導入前段階で比較したい、という人と既に導入しちゃった人じゃ観点が合わんのはしょうがないけど。
前の人は既存部分との違いを知ることが主な観点になるけど、既に入れちゃった人はその結果起きた問題を
解決することが観点になるからねｗ
595: 2020/02/02(日)11:43 ID:l4msUzoZ(1) AAS
なんか話が噛み合わないと思った
ノードを常に余らせている大規模環境じゃないと使えないとか
>>550
あらゆる種類のワークロードを
1つのノードにごった煮だと勘違いしていたなら納得
596(1): 2020/02/02(日)11:43 ID:cuMP7GqL(5/27) AAS
>>590
これも、そもそもDocker以前の環境すらまともに運用できなかった人と
Dockerを比べてもなぁ？という話で。もしその狂気の環境の人がDocker使って
k8s入れたとしたら、余計酷くなるだけ（使いこなせるわけが無い）
> AWSなのにサーバーを家畜のように使い捨てではなく、ペットのように可愛がってた
こういう言い方もずっと前からあるけど、実際コンテナとしても「家畜のように」は使えんだろ。
本番で運用するときは当たり前だけど一見ごみの様にしか見えないものでもトラブル解決に
役立ったりするからね。/var/log/httpdだけを永続化しときゃ済むって話じゃない。
1ヵ月後に顧客からトラブルの相談があって、既に再デプロイして非永続領域は消えちゃいました、
ですむなら良いけど。
省1
597(1): 2020/02/02(日)12:01 ID:TWOzawm+(3/12) AAS
>>596
>じゃあどこを永続化しておきましょうかなんて、開発前にすぐに決められるものじゃない。
本当に全くDocker使ったことないのに批判してるんだなw
説明しよう
ログは標準出力か標準エラー出力に吐くから永続化はしない
必要ならロギングドライバーを設定するなどして
別サービスに転送する
AWS+ECSならCloudWatchに転送が一番楽
k8sは今のところロギングドライバーの設定はできないので、
コンテナのログを集めるDaemonSetがそれぞれのノードにデプロイするのが一般的
省4
598(1): 2020/02/02(日)12:12 ID:cuMP7GqL(6/27) AAS
>>597
そういやそういう事やってたなとは思うけど、君が説明しているログ収集云々は
汎用的なDockerの話じゃ無くてベンダーが用意している部分ね。
>AWS+ECSならCloudWatchに転送が一番楽
ん？結局こういうことしたらベンダーロックインって事じゃないの？
> どこを永続化するかで悩んだことなんてない
そうなの？
しかしそれはDBとWEBだけの単純サービスだからじゃないの？
ウチのはある領域に一時的なファイルを作って、S3とかにアップするけどそれが
出来てないよ、とかは普通に来るからね。
599(1): 2020/02/02(日)12:25 ID:LuowLFof(1/5) AAS
ベンダーロックインw
あのさ、ECSでコンテナからCloudWatchに出力するのなんて数クリックでできるわけ。
人的なコストなんかほぼゼロ。
ベンダーロックインっていうのはこれまでの投資が無駄になるから他のベンダーへ移れない状態であって、
そもそも投資がゼロなら何の問題もないの。言ってる意味わかる？
600: 2020/02/02(日)12:29 ID:TWOzawm+(4/12) AAS
>>598
ECS時は最も手軽な選択肢はCloudWatchってだけ
他にも選択肢はあるが
とりあえずAWSで動けば良いなら一番手軽
手間や金がかかっても
とにかくベンダーロックインは嫌だって言うなら
k8sとELKスタックとかになるんでは
ファイルアップロードにS3使えてない場合は
・2台以上でWebサーバーの構成をするのを諦める
・多少遅くても良いならAmazon EFSに置く
省1
601(2): 2020/02/02(日)12:35 ID:cuMP7GqL(7/27) AAS
>>599
なんつーかそれを聞いてもやっぱり、10台程度のサービスでEKS、ECS面倒臭いという
のが結論やね。100台なら話は全く違うけど。じゃあ10台〜100台の間のどのへんが
ボーダーなのかって点には関心あるけど。
どこが汎用のDockerの話でどこがベンダーに依存するのかとか、面倒くさすぎ。
質問を568に戻そうぜ。
「ある1つのインスタンス内で、1プロセスでCPUと同数のスレッドと立ち上げる事と、
CPUと同数のコンテナを立ち上げること」は何が違うの？
602: 2020/02/02(日)12:38 ID:TWOzawm+(5/12) AAS
そもそも規模小さかったらリソースの割当に悩む事ないから
その批判がそもそも的外れ
603: 2020/02/02(日)12:40 ID:LuowLFof(2/5) AAS
>>601
その2つを比べるのはおかしい
1コンテナ内で複数スレッド立ち上げてもいいし、goなどのマルチスレッド前提の言語ならむしろその方が一般的。
604(1): 2020/02/02(日)12:41 ID:cuMP7GqL(8/27) AAS
>とにかくベンダーロックインは嫌だって言うなら....
>ファイルアップロードにS3使えてない場合は...
こういう所とかも全部「既存システムでは存在しない問題点に対して解決方法を提示している」様に思えてならん。
他の人はそうは思わんのかな？
605(1): 2020/02/02(日)12:46 ID:LuowLFof(3/5) AAS
>>604
全く意味がわからないな
ログ収集もS3へのアップロードの失敗も既存システムで存在するだろう
606(1): 2020/02/02(日)12:59 ID:cuMP7GqL(9/27) AAS
>>605
VMは再起動しても永続化してるんだから問題調査は可能でしょ。
607(1): 2020/02/02(日)13:04 ID:TWOzawm+(6/12) AAS
S3とか使ってないレガシーシステムでも
ECS使うのは可能
可用性が重要じゃない社内用アプリで
インスタンス1台だけのECSクラスターで
データは全てEBSに書いてる物ならある
ログはDocker経由でCloudWatch Logsに出すようにしてるが
時々OSのAMIとか
ECSエージェントを更新すれば
実行環境は最新の状態に保たれる
ログやメトリクスはマネジメントコンソールから見られるし、
省5
608(1): 2020/02/02(日)13:05 ID:LuowLFof(4/5) AAS
>>606
オートスケーリング使うなら勝手にterminateされて全部消えるよ
大した規模じゃないからオートスケーリングいらないってんなら、君にはコンテナなんて要らないから帰ってね、としか
609(1): 2020/02/02(日)13:07 ID:cuMP7GqL(10/27) AAS
>>608
オートスケーリングはそういう用途じゃないな。
繁忙期のサーバー落ち＞障害調査
の場合にのみ使用するとしか言えない。
分からないなら答えないでねとしか。
610: 2020/02/02(日)13:17 ID:TWOzawm+(7/12) AAS
だからログはCloudWatch Logsに送ればいいって話だろ？
コンテナ毎のCPU使用率やメモリー使用量はメトリクスはECSエージェントがCloudWatchに送ってくれる
611(1): 2020/02/02(日)13:17 ID:LuowLFof(5/5) AAS
>>609
そもそもログ収集してないのに問題のインスタンスの特定とかどうすんの？
台数が少けりゃスナップショット撮ってれば努力と根性でなんとかなるかもしれないけど、
うちの場合はその作業が一度発生したら自前でログ収集の仕組みを構築するコストを余裕で上回る工数だねえ
612(1): 2020/02/02(日)13:20 ID:cuMP7GqL(11/27) AAS
>>607
>ログやメトリクスはマネジメントコンソールから見られるし、
これもね、じゃあ障害解析のために開発者全員がマネジメントコンソール
見れて良いのかとか、微妙で面倒くさい問題が出そうな気がするんですよ･･･。
613(1): 2020/02/02(日)13:26 ID:cuMP7GqL(12/27) AAS
>>611
自分が携わっている範囲内で言えば、インスタンスが特定できずに問題が解決
しなかったなんてことは無いな。コストがかかりすぎた、という事も無い。
ド素人じゃないんだし、それ位分かるよな？としか･･･。
上下前次1-新書関写板覧索設栞歴
あと 389 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.029s