[過去ﾛｸﾞ] Docker Part3 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
527: 2020/01/29(水)20:57 ID:zxPSLJvv(1) AAS
>>526
インフラエンジニアの雇用を維持するためだよ。マジで。
自社サービス系のインフラエンジニアって基本的にトラブルがなければ仕事ないから、
自然と問題なく動いているもののオーバーエンジニアリングに向かうものだ。
528(2): 2020/01/29(水)21:15 ID:3wP3LyoD(4/4) AAS
オーバーエンジニアリング程度なら良いけどさ
メモリ食い過ぎで前より不便にしてるだけなんだよな
インフラ系って、変わってるだけで、何も良くなってない
529: 2020/01/29(水)21:33 ID:9OcLAXSy(1) AAS
>>528
いや、だからGKE使えよ？
コントローラー無料だろ？
530: 2020/01/29(水)22:10 ID:OCMkZsaj(1/3) AAS
>>526
元々クラウドのための仕様なんだが……。
ノードの数を負荷に応じて変更できるから、処理が多い時間はノード増やして処理し、少ない時間はノードを減らす事でコストを最適化できるのがk8sの売り。
規模が小さいとこの利点（オートスケーリング）が意味をなさなくなる。
531: 2020/01/29(水)22:23 ID:BTLuyg2X(1) AAS
1台しかないならdocker-composeでよくね？
1台しかないなら
532(1): 2020/01/29(水)22:35 ID:OCMkZsaj(2/3) AAS
従来は高価なオンプレを1台買ってスペック余らせるのが普通だったが、今はクラスタにする事で、オートスケーリングによりスペック（≒コスト）を最適化できるようになった。
ハイスペック1台ならdockerで十分だが、コスト面で最適化されてるかな？という話。
533(2): 2020/01/29(水)23:26 ID:K0p5wp9W(1) AAS
>>532
それだけならECSとかで十分でしょ
k8sは決まったサイズのクラスタを効率的に使うにはいいけど、クラスタそのもののスケーリングにはあまり適してないよ
534: 2020/01/29(水)23:50 ID:OCMkZsaj(3/3) AAS
>>533
k8sはECSより高機能で汎用的だが学習コスト高めという印象。ECSはベンダー製なので、クラスタに関してはその通りだろうが、ベンダーロックインの問題がある。
ベンダーロックインの問題を気にせず、ECSで案件が済むならECSだろう。
535(1): 2020/01/30(木)00:20 ID:KTDe4H4D(1) AAS
たかがコンテナ立ち上げるだけのことにベンダーロックインねえ
事業視点で言えば、k8sに習熟した少数のエンジニアにインフラをロックインされることの方がよほどリスクが大きいと思うけどね
536: 2020/01/30(木)00:26 ID:OBlH/P8v(1) AAS
>>528
単に使い所を間違ってるだけとしか思えんが
そもそも別にk8s使わなくてもdockerはある程度規模に応じたオーケストレーションを標準に
近い形で用意しているはずで、それでは管理できないほど巨大な規模のサービスを運用するから
k8sですよ、って事で、当然メモリが食いすぎとか文句言う人が使う物じゃない気はする。
そういう人にはもっと小規模な物あるでしょ？
昔Googleの論文元にHadoop作って訳も分からずに食いついて先進的だカッコいいぜ俺スゲーとか
いって後からやっぱ遅ーえわこれｗとかいってた連中思い出すね。
自分たちが間違った場所に適用してるとは最後まで考えないｗ
537(1): 2020/01/30(木)01:26 ID:pAQXSf/G(1/2) AAS
>>535
Amazonがk8sのサービス始めたのはこの理由らしいから、そういう意見も多いということなのだろう。
個人的にはk8sよりマルチビルドのdocker file の方が難解だな
538(1): 2020/01/30(木)02:46 ID:N78kTYg5(1/6) AAS
>>533
> k8sは決まったサイズのクラスタを効率的に使うにはいいけど、クラスタそのもののスケーリングにはあまり適してないよ
そうだよね？
広大なCPU空間を確保しておいて、自由に使いましょうというのならいいけど
コストの観点から空間自体を減らしたり増やしたりってのは適してないと思う
スケーリングならすでにGCEとかのクラウドの仕組みで実現できたじゃんって思う
そこにGKEを持ってきて使いづらくしたと思ったら、
どうせコンテナベースで課金とかするでしょ？
なんでクラウドの中にさらにクラウド作ってるんだろうって思う
539(1): 2020/01/30(木)02:49 ID:N78kTYg5(2/6) AAS
>>537
> 個人的にはk8sよりマルチビルドのdocker file の方が難解だな
マルチステージビルドの事？ どんだけ複雑なんだよｗ
あんなの、中間ファイルは不要だから
前のイメージでビルドしてできた生成物のみ
コピーして使いましょうってだけじゃんか
540: 2020/01/30(木)03:04 ID:N78kTYg5(3/6) AAS
k8sの嫌なところは短いタイミングで強制アップデートな所だな
これがあるからストレージとしては使えない
データベースは別のサービスを使えってことなんだろうけど、
これがあるからHAの代わりにはならないんだよね
541: 2020/01/30(木)08:22 ID:x2o8za8v(1/2) AAS
自前k8sなら誰も面倒見てくれないので
アップデートもされない
証明書の期限短くすると
期限切れした時にAPIサーバーと通信できなくなるけど
542: 2020/01/30(木)08:57 ID:JRKnodoF(1/3) AAS
APIサーバーの証明書は自動更新機能があった気がする
>>538
ワーカーノードは今まで通り課金される
k8sでのサーバーレス関数の実行は
EKSやGKEで最近できるようになったが
一部機能制限がある上に
確保するリソースが多いと通常通り
ワーカーノードを用意した方が安くなる事がある
サーバーレスはコールドスタートによる遅延の問題なども多分まだある
543(1): 2020/01/30(木)09:18 ID:JRKnodoF(2/3) AAS
サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る
とは言ってもノードの起動は時間がかかるので
すぐには無理だが
544: 2020/01/30(木)09:18 ID:JRKnodoF(3/3) AAS
サーバーレスが利用出来ない場合の次善の策は
Cluster Autoscaler
ポッドの数に応じてノード数を増減出来る
負荷ベースでポッド数を増減する
水平ポッドオートスケーラーと組み合わせる事で、ノード数を負荷に応じて自動で増減出来る
とは言ってもノードの起動は時間がかかるので
すぐには無理だが
545: 2020/01/30(木)11:27 ID:pAQXSf/G(2/2) AAS
>>539
他人が書いたのを検証するのが難しいってことね。他人に依存するかどうかという視点の話。
546(1): 2020/01/30(木)11:44 ID:N78kTYg5(4/6) AAS
>>543
ノードの増減はk8sなくてもできたじゃん？
・負荷の応じてノードが増減できる
だったのが
・負荷に応じてでポットが増減できて、ポットの増減に応じてノードが増減できる
に変わってるじゃん？
二段階になってややこしくなってるし
ノード（課金対象）が増減しない範囲でのポットの増減が存在するわけで、
こんなんで正確な見積もりなんかできるの？
k8sはプロジェクト単位で使うものじゃななくて、
会社として広大なクラスタ空間を予め確保して、その中で複数の異なる
サブプロジェクトをいくつも動かすって使い方をする
Googleぐらいしかまともに使えないよ
547: 2020/01/30(木)11:52 ID:N78kTYg5(5/6) AAS
k8sはノード＝1つないし少数のそれぞれ違うポットを配置するという使い方じゃないんだよね
1つのノードが複数のポットを動かすスペックを持っていて、
多数の小さなポッドをその中で動かすという使い方をする。
1つのノードで同じ種類のポットがたくさん生まれて
消えるような場合じゃないとうまく使えない
自動管理されたHA環境ではないんだよね
548(1): 2020/01/30(木)17:42 ID:IVBe8aPz(1) AAS
ECSは当初タスク数がEC2インスタンス数と連動しない残念仕様だった
こちらもタスク数に応じてインスタンスが生成される
外部ﾘﾝｸ:dev.classmethod.jp
5タスクを同時に動かそうとすると、
5台のEC2インスタンスが生成される
超シンプル
549: 2020/01/30(木)17:44 ID:krDeGaUI(1) AAS
ECSサービス開始当初はEC2の数とタスクの数を連動させる機能が
無かったが、去年追加された
550(2): 2020/01/30(木)18:28 ID:N78kTYg5(6/6) AAS
>>548
それは一般的な使い方としてはわかりやすいし、できるべきだよね。
ただk8sのそもそもの使い方としては、ずれてるんだと思う
その使い方であれば、インスタンスのオートスケールと変わらないわけだし
コンテナが動かせるというメリットはあるけどね
まあ各クラウドの間で共通のインターフェースができて
どこでも動かせるようになるのはいいと思うけど
そのためにもっと大掛かりなシステムのためのk8sを流用してる感が大きい
もっと間を減らしてシンプルに出来なかったのかねぇ
やっぱりクラウドを使ってクラウドを作ってるように見えてしまう
k8sはある程度の空間を確保していて、そこで小さなポッドを多数起動して
全体の○％を超えたり減ったりしたら、クラスタを増減させて
通常はある程度の余力をもたせておく（遊んでるサーバーがある）という使い方なんだろう
インスタンス数を意識して最小の金額にするためのものじゃないかな
551(2): 2020/01/30(木)19:32 ID:RH+cWAif(1/2) AAS
ECSも、タスク数をCPU使用率などのメトリクスと連動させれば、
CPU数に応じて「タスク数とインスタンス数」を同時に増やすことが可能
何が違うと言うのか
ECSも以前から「それぞれ別々に」インスタンス数とタスク数を増減する事は出来たが、
協調せずバラバラに動くので、
負荷の増加に反応してサービスのタスク数は増えたのに、
インスタンス数がちゃんと増えなかった、
あるいはインスタンス数は増えたのにサービス数が増えないとか
そんな動きになる可能性があった
1つのノードに複数のコンテナがあるような状況では
さらに話がややこしくなっていた
ノードのCPU使用率が一時的に増加していても、それはサービスの需要が増えたからではなく、
定期バッチ処理で負荷が一時的に高くなったのが原因だったり
552(1): 2020/01/30(木)19:38 ID:RH+cWAif(2/2) AAS
Kubernetesはずっと前から
ポッド数によるノード増減ができた
パクったのはECS
自動でノード数の増減が要らない、
常に2台で良いって言うなら
Cluster AutoScalerを使わなくても良い
553(1): 2020/01/30(木)20:00 ID:VJ/WHmRQ(1) AAS
そもそもECSって目的毎にクラスタ立てるもんだろ？
何でもかんでも一つのクラスタで済ませようなどと考えなければ従来のインスタンスベースのスケーリングで問題ない
それこそ「クラウドなんだから」だ
ID:RH+cWAifの主張は、クラウドの中にクラウドを作っているという批判に対する反論としては的外れに感じる
554(1): 2020/01/30(木)20:33 ID:rH68C/el(1/3) AAS
RH+cWAifは別にクラウドの中にクラウドが〜に対する回答ではない様な。
クラウドが〜は自分で解答書いてるし。
>そのためにもっと大掛かりなシステムのためのk8sを流用してる感が大きい
結局そういうことだよね。
外部ﾘﾝｸ:aws.アマゾン.com/jp/docker/
Q: Docker Swarm、Kubernetes、Amazon ECS の違いは何ですか?
>多くの Docker コンテナを実行する場合は、Docker Swarm、Kubernetes、Amazon Elastic Container Service (ECS) などの
>オーケストレーションツールを使用することで、何千 (または何百万) ものコンテナの開始、停止、監視が可能になります。
日本は法人向けサービスやったとしても会社の絶対数が少ないしそもそも余程のことが無い限り
1サービスあたりのサーバは10台超えることは無い。じゃあ10台でオートスケールやるコンテナの仕組みは何なのさ？
ってニーズに全然答えようとしていない。
555(1): 2020/01/30(木)20:50 ID:obKqsaeD(1/2) AAS
>>551
一番重要なのはコストの最適化なんだから、タスク数もしくは負荷に応じたインスタンス数の増減なんだよね。
> 負荷の増加に反応してサービスのタスク数は増えたのに、
> インスタンス数がちゃんと増えなかった、
そこな。スケールするのがコンテナとインスタンスの
二重になってるからすごく分かりづらい
そもそも一つのインスタンスの中で動くコンテナを増やしても
並列度は上ががっても処理速度は上がらんのよ
（CPUコアを使い切れるようにはなるだろうけど）
パッチ処理みたいに一つのデータを送ってコンテナで処理して終了みたいのであればわかりやすいけど
ウェブサーバーみたいにそれ自体が並列処理対応になってるものの
コンテナを増やしたって何の意味もない。インスタンスの数を増やすか
インスタンスの性能をあげなきゃならないのに、間にコンテナの話が入り込んでくる
556(1): 2020/01/30(木)21:31 ID:rH68C/el(2/3) AAS
>スケールするのがコンテナとインスタンスの
>二重になってるからすごく分かりづらい
分かりにくいのはそうなんだろうけど、インスタンスを跨ぐコンテナはネットワークに
仕掛けしないと駄目だからしょうがないんじゃないの？それはDockerのあの変な
ネットワークの仕組みの為だろうけど。
>（CPUコアを使い切れるようにはなるだろうけど）
結局インスタンス（VM)の上にコンテナ乗っけてるって時点でハードを使い切る
コンテナ技術のメリットは消えており、AmazonのECSはなんちゃってコンテナで
しかない気はする。
557(1): 2020/01/30(木)22:07 ID:obKqsaeD(2/2) AAS
コンテナベースにするなら、インスタンスの存在は完全に見えなくしないとだめだろうね。
そして「これこれの性能を持ったコンテナ」を「いくつ使用するか」で課金する。
あとやっぱりノードのアップグレードに伴う再起動が大変
コンテナ数ノード数が少ないとサービス停止に陥ってしまう可能性が高くなる
アップグレードを放置するとそのうちバージョン古すぎて非対応になるし
なんでみんなk8s頑張ろうとしてるんだろう
殆どの用途では大変なだけじゃないか？
558(1): 2020/01/30(木)22:14 ID:x2o8za8v(2/2) AAS
Kubernetesの真の価値はそこで利用出来るソフトウェアにあるのでは？
サービスメッシュとかデータベースのオペレーターとか
なんかk8sで動くhelmチャートが動く環境が欲しいのでなければ
ECSとかでも良いし
そっちのほうが簡単と思う
クラウドの中にクラウドとか言うけどさ
サーバーに自分でインストールして
動かすソフトを作る側に取っては
Kubernetesだけ対応すれば
あらゆるクラウドで動くものが作れるようになった
自社のソフトウェアが様々なクラウドで動くのは、
ビジネスチャンスに繋がるんじゃね？
ソフト自体を配布するんじゃなくて
サービスとして売りたいなら
好きな物を使え
559: 2020/01/30(木)22:20 ID:rH68C/el(3/3) AAS
例えて言うなら56コア112スレのXeon買ってきてサーバー作って
そこにESXi入れて、CoreOSを20個インストールしてOS１つあたり
5コンテナ入れてk8s組んで、やったぜ俺スゲーとかｗ
そんな感じやな。
でそこで動く肝心なサービスの保守は完全に片手間で1日16時間労働ｗ
恥づｗｗ
560: 2020/01/30(木)22:28 ID:fl66aBkL(1) AAS
仕事でGKE使ってんだけど世の中の8割のサービスはこんな仕組み要らんだろうなーと思いながら触ってる
561: 2020/01/30(木)23:23 ID:8SEpOjSd(1/3) AAS
>>558
ローカル環境でdockerと比べると、k8sは細やかな制御ができる分やりやすい。
562: 2020/01/30(木)23:26 ID:8SEpOjSd(2/3) AAS
k8sはDockerに比べてIngressとロードバランサが優秀。
563: 2020/01/30(木)23:27 ID:8SEpOjSd(3/3) AAS
替わりにマシンスペックを食うわけだが……。コントローラで2W近く使う
564: 2020/01/30(木)23:32 ID:vPq8TLea(1) AAS
k8sとDockerって比べるものじゃないじゃん
565: 2020/01/31(金)06:06 ID:BYA66tlO(1) AAS
スペックを食うってのもなんだかな
566(1): 2020/01/31(金)09:44 ID:zr53MAqg(1) AAS
swarmの事もたまには思い出してあげてください
567: 2020/01/31(金)21:02 ID:PGkHP1z8(1) AAS
>>566
VMからサービス拡大で手軽なクラスタ使いたいから〜、って理由で
Dockerに移行したらのなら、スケール的には一番しっくり来るんだけどね。
流行の技術じゃないから誰も手を出さんのか？まあDocker Swarmできます！
とかじゃ経歴書にかいても自慢出来んだろうけどね。
568(1): 2020/02/01(土)09:45 ID:rnZpf00g(1/6) AAS
ASGとECS組合せて使ってる奴が要るけど、あれは何の役に立つの？
スケーリングされたインスタンス内でCPUと同数のスレッドでサービス立ち上げる事と
何が違うのか全く分からん。事態を面倒くさくしているだけに見えるｗ
569(1): 2020/02/01(土)09:51 ID:a9slqYuq(1) AAS
>>568
デプロイをECSに任せたいだけだよ
自分でホスト弄りたくない
570: 2020/02/01(土)10:02 ID:rnZpf00g(2/6) AAS
>>569
それはASGでホストが起動したときに、スタートアップか何かでgit pullする事と
何か違うの？
571(1): 2020/02/01(土)10:15 ID:Xk5te6Cy(1) AAS
また仮想マシンイメージ最強おじさん？
老害乙wwwwww
572(1): 2020/02/01(土)10:26 ID:+b4DF/Bv(1) AAS
git pullするって
仮想マシンイメージにアプリの内容を突っ込む訳でも無いのか
goとかJavaだったら毎回ビルド？
老害どころの騒ぎではないな
デプロイ成功するかどうか
同じ結果になるかどうか
毎回やってからのお楽しみって感じ？
時間がいくらでもあるなら
そうすれば良いんじゃない？
573: 2020/02/01(土)12:47 ID:rnZpf00g(3/6) AAS
>>571-572
良くわかんねぇけど、もう少し論理的に説明してくれるかな？
うちのシステムは大体それで大丈夫だからね。
574(1): 2020/02/01(土)12:59 ID:Ps7WDj2g(1/3) AAS
今度はDockerじゃなくてgit使えば良いおじさん登場か
それで困ってないなら別に良いんじゃない？
575(1): 2020/02/01(土)13:07 ID:rnZpf00g(4/6) AAS
>>574
だから「ASGとECS組合せて使ってる奴が要るけど、あれは何の役に立つの？」って聞いてるじゃん。
君の反論は、デプロイが複雑な場合においては、有効なこともありうる、ってことでオッケー？
それは分かったよ。
ただ、>>556にあるようにDocker自身はコンテナシステムとしてはイマイチだと思う。理由は557と同じね。
少なくとも変なホスト単位のブリッジはやめにしてPOD単位とかService単位で内部ネットワークにしないと
インスタンスが全面に出てきちゃ、導入する意味が無い。ストレージなんかも必要な部分を予めマッピングして
永続化しないと駄目とか、制限が多いし。こんな事いっても君には分からんだろうけど。
576: 2020/02/01(土)13:18 ID:Ps7WDj2g(2/3) AAS
じゃあ使わなきゃいいんじゃね？
577: 2020/02/01(土)13:25 ID:rnZpf00g(5/6) AAS
マジ質問読めよ文網ｗ
日本語通じないなんてDocker使う以前の話だよｗ
578(1): 2020/02/01(土)13:30 ID:Ps7WDj2g(3/3) AAS
Docker使わなかったらOSアップデートは要らないとでも？
普通に要るでしょ
セキュリティ考慮しないから要らないって話？
579: 2020/02/01(土)13:45 ID:rnZpf00g(6/6) AAS
>>578
ECSの話してるんじゃないの？
ECSは「インスタンスの上」でコンテナを動かすのだから当然Dockerでも
OSアップグレードは必要で、そういった話をするなら、インスタンスOSと
コンテナ上のOSの両方のセキュリティを考慮しなければならない。
580: 2020/02/01(土)15:00 ID:A9loRdi2(1) AAS
ECSとか関係なく
ASG利用の方が信頼性が高い
ECSはASG無しで使えるように設計されてるのか良く分からない
なんか前の登録内容が残ってたり
ECSエージェントのデータを消さないとインスタンスタイプを変更できなかったりした
通常のEC2
・ルートボリュームの内容は再起動に引き継がれる。システムログの内容やSSHして手動設定した内容はインスタンスを削除しない限り残る。
・AWS障害時に自動復旧させるのは可能だが、必ず成功するとは限らない。
・AWSと関係ないOS内部の問題はEC2 Rescueで復旧を自動化できるかもしれないが絶対ではない。
ASG
・ルートボリュームは毎回新しく作られる
・データの保存が必要なワークロードの場合、起動後にスクリプトで別のEBSをアタッチする、S3に保存されたバックアップから復元するなどの方法が必要
・ヘルスチェックをEC2にした場合、システムとインスタンスの2つのチェックのどちらかに失敗するとインスタンスは破棄されて再作成される
・ヘルスチェックをELBにした場合、ELBからのリクエストに暫く応答しなかったら破棄される
いずれの場合も、自前のヘルスチェックシステムがあるなら
それを代わりに使う事は可能だが
そんな物はうちにはない
581: 2020/02/01(土)15:10 ID:lVg3qEIO(1) AAS
キャパシティプロバイダーでEC2のタスク数とインスタンス数を連動させる場合はASGが必須
キャパシティプロバイダーの登場以前はタスク数と連動させるのは諦めて
EC2の台数もタスク数も固定するか
それぞれバラバラに設定して
高負荷時に両方とも作動するよう神に祈る他なかった
キャパシティプロバイダーが要らない場合でも
ASGにしておけばコケても復旧するという安心感はある
インスタンスを終了すれば必ず同じ設定で起動するからだ
それらが要らないならASG無しでも良いんじゃね？
同じEC2インスタンスだと
インスタンスサイズ変更時に
ECSエージェントが登録失敗する問題は何か解決策があるだろう
582: 2020/02/01(土)15:36 ID:uZkIbDS6(1) AAS
ECSについて言えば、3つのネットワークモードが利用可能
bridge
ポートマッピングを設定した場合、
コンテナにランダムなポートが割り当てられ、外部からアクセス可能になる
同じホスト名で外部からアクセス出来るようにしたいなら、ELBやRoute53を併用する
毎回異なるポート番号になるので、デプロイ時、1つのEC2インスタンスに
同じタスクの新旧バージョンを一時的に同時実行する事が出来る
host
ホストOSと同じネットワークに配置する
ポート番号が衝突するので、
デプロイ時に、同じタスクの新旧バージョンを同じEC2インスタンスで同時実行は不可
awsvpc
ホストOSとは異なるENIにタスクを配置する
異なるENIなので、同じEC2インスタンスでも同じポート番号を利用可能な上に
理論上は最高のネットワーク性能を持つモード
ただし、小さめのインスタンスタイプでは
利用できるENIの数が少ないので
配置出来るawsvpcネットワークモードのタスクは少なくなる
583(1): 2020/02/01(土)18:53 ID:ZdsodL/0(1) AAS
俺はGCPメインだからAWSの話はよくわからんなｗ
AGS？ GKEのオートスケーリング機能みたいなもんか？
584: 2020/02/01(土)19:59 ID:wE2puLwI(1) AAS
ASGは多分似たような機能がどのパブリッククラウドにもあるだろう
k8sをAWSで使う場合も
ワーカーノードはASG管理下で、
ルートボリュームはノードを終了する時に捨てるよね
サーバーはいつでも替えの効く家畜だ
k8sでデータベースなどの
ステートフルなワークロードを扱う場合は、
ノードにルートボリュームとは別に
EBSボリュームをアタッチすれば良い
>>583
そもそもASGはオートスケーリンググループの略だから
585: 2020/02/02(日)01:40 ID:9x081f8g(1) AAS
Kubernetes 航海1日目
2chｽﾚ:linux
586(1): 2020/02/02(日)08:39 ID:cuMP7GqL(1/27) AAS
何？よう知らんけどEKSでもインスタンスは見えてるの？
インスタンス（VM）を管理してその上で動くコンテナも管理しろとか
コンテナの意味なくね？
587: 2020/02/02(日)08:52 ID:vTMq3yW0(1/5) AAS
だからコンテナはアプリをデプロイしやすくするためのものだって言ってんだろ
588(1): 2020/02/02(日)09:08 ID:cuMP7GqL(2/27) AAS
じゃあ、今ここでDocker関連の話題を書き込んでいる連中はもれなく
デプロイに問題があってDocker使ってるという認識なのｗｗ？
デプロイをコンテナ以外で解決するくらいならサービスメッシュだ
オペレータだhelmチャートだと学習したほうが効率が上がると判断しているのｗ？
589: 2020/02/02(日)09:42 ID:TWOzawm+(1/12) AAS
>>588
は開発どうしてんの？
それぞれバラバラに環境作って開発？
開発、QA環境へのデプロイとテスト
本番環境へのデプロイまで一貫した環境で行えるのがコンテナ技術のメインの魅力だろう
Kubernetesは複雑すぎる気はするが
他に選択肢があまりない
590(1): 2020/02/02(日)09:54 ID:TWOzawm+(2/12) AAS
以前、開発も本番も同じ環境においてるという
狂気の環境で開発した事がある
ローカル開発環境はそもそも存在せず
理由は環境の複製が面倒だから
AWSなのにサーバーを家畜のように使い捨てではなく、ペットのように可愛がってた
サーバーに直接Apacheをインストールしており、
基本的にphpをアップグレードする時や
phpの拡張機能を入れるときは
一か八かの賭けに出る必要があった
AMIを複製して他環境で試す？
そんなのやるぐらいならもうDocker使えよ・・・ってなる
それが一番色んな環境に運ぶの楽じゃん
591(1): 2020/02/02(日)10:02 ID:vLvuWMc2(1) AAS
>>586
昔ながらの方法だったらVMインスタンスもアプリのデプロイも管理しなくて良いとでも言ってるのか？
文句あるなら代替案出せや
スペックに応じたインスタンスが必要なのは
昔ながらの方法でも一緒だろ
592(4): 2020/02/02(日)10:31 ID:cuMP7GqL(3/27) AAS
>>591
代案つーか、コンテナ技術って時期尚早じゃね？サービスを構成する鯖が
10台20台程度なら入れない方が良いと思う。いつの日か>>557が書いたように
完全にコンテナだけ見ていればOKになるなら入れても良い。
例えば10コアのCPUを10台用意して、30個をフロントWEBに、20個をバックエンドに、
30個を同期サーバ、10個をその他、残りはautoscaling用、1CPU=1コンテナとか
このレベルで意思決定が出来て、そのとおり動くならマイクロサービスは素晴らしい
といえるけど、現状そうなってないんだろ？コンテナが物理サーバーに対して透過的
見えるレベルに到達してないつーか。
いつかそうなるんだろうけどね。
今は面倒なだけという気がする。
593(1): 2020/02/02(日)11:04 ID:mAYLnTD8(1) AAS
>>592
それってデメリットか？
算数が出来れば計算出来るだろ
小規模環境なら台数固定で良いし
OSや、ログ、メトリクス用ポッドの分だけ余裕をもたせて空けておけば良い
それぐらい計算できるだろ？
もしかしてワーカーノードは全部同じグループとか思ってる？
データベースはこのラベルが付いてるノードだけに配置とか、出来るだろ
負荷がデータベースに集中しがちなら、データベースだけ大きなノードのグループで構成するとか
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ヵ月後に顧客からトラブルの相談があって、既に再デプロイして非永続領域は消えちゃいました、
ですむなら良いけど。
じゃあどこを永続化しておきましょうかなんて、開発前にすぐに決められるものじゃない。
597(1): 2020/02/02(日)12:01 ID:TWOzawm+(3/12) AAS
>>596
>じゃあどこを永続化しておきましょうかなんて、開発前にすぐに決められるものじゃない。
本当に全くDocker使ったことないのに批判してるんだなw
説明しよう
ログは標準出力か標準エラー出力に吐くから永続化はしない
必要ならロギングドライバーを設定するなどして
別サービスに転送する
AWS+ECSならCloudWatchに転送が一番楽
k8sは今のところロギングドライバーの設定はできないので、
コンテナのログを集めるDaemonSetがそれぞれのノードにデプロイするのが一般的
これで全ノードのログを残せる
永続化するのは再起動しても絶対残っていなければならない
データベースのデータなどだけ
どこを永続化するかで悩んだことなんてない
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に置く
どちらもやらずに解決する銀の弾丸はない
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エージェントを更新すれば
実行環境は最新の状態に保たれる
ログやメトリクスはマネジメントコンソールから見られるし、
デプロイするだけならSSHすら要らないし楽
使わない理由がない
アプリ部分はAWSとか使ってないので、
移そうと思えば他クラウドにも移せる
今の所やる予定ないし今後も無いと思うが
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
自分が携わっている範囲内で言えば、インスタンスが特定できずに問題が解決
しなかったなんてことは無いな。コストがかかりすぎた、という事も無い。
ド素人じゃないんだし、それ位分かるよな？としか･･･。
614: 2020/02/02(日)13:27 ID:TWOzawm+(8/12) AAS
>>612
ログを取るためだけにSSHするのは良いのかよw
AWSの組織機能で細かくアカウントをアプリ毎に分ける、
IAMロールを最小の権限のみにするなどした方がよほどセキュアだ
Cloudwatch Logsは
ローカルにログをダウンロードせずに
簡単な検索や分析も出来る
これもセキュアだろう
615(1): 2020/02/02(日)13:59 ID:bYwPQj4X(1) AAS
>>613
それインスタンスが数百台以上あっても同じこと言える？
結局何が言いたいのか知らないけど、何が手でSSHして回れる程度の台数でコンテナなんか要らん、と言いたいならまあその通りだと思うよ
616: 2020/02/02(日)14:05 ID:cuMP7GqL(13/27) AAS
>>615
だから結論は>>601だと言っているでしょ。
以後のやり取りのすべてを見てもやはり601やね。
10台以下で運用するのは、まあ、趣味の世界やな。。
悪くは無いけど運用上実利がある訳じゃないよと。
まあ興味があるならやっても良いよ、あるいはもっと大きな
サービス運用業者に転職を視野にいれてしれっとやってみるとか、
そんな感じと思ったね。
617(1): 2020/02/02(日)14:25 ID:KVZqynku(1) AAS
結局何が言いたいのかサッパリ分からんやつだったな
小規模だったらそもそも台数の調整とか要らないだろって話は無視か
618: 2020/02/02(日)14:34 ID:cuMP7GqL(14/27) AAS
>>617
君の言っている事こそ意味不明ｗ。
小規模で台数の調整が要らないらならEKSもECSも要らないっしょ。
ちなみに小規模であることと台数の調整が不要であることはイコールではない。
小規模でも繁忙期に台数増やしたいとかは当然ある。
619(1): 2020/02/02(日)14:43 ID:TWOzawm+(9/12) AAS
サーバーを家畜化した方が運用が楽で信頼性も高いのは
1台でも100台でも変わらないと思う
総利益が大きいのはそりゃ100台だろうが
そもそもサーバーの家畜化もできてなかったら
どうやって水平スケールするのか
Dockerなしでも家畜化が出来ていたら、Docker導入のハードルは高くないはずだが
620(1): 2020/02/02(日)14:50 ID:TWOzawm+(10/12) AAS
Dockerなしでも家畜化出来てたら
それぞれのサーバーにSSHしてログ取ったりなんていらんはずだけど
まさか手作業で環境を複製してASGもどきをやってるのか？
超無駄じゃね？
ASGでやれよ
621: 2020/02/02(日)15:15 ID:cuMP7GqL(15/27) AAS
>>619
>信頼性も高いのは
信頼性が高いといっているのは何を根拠に言っているのか知らんが、
インスタンスの上にDockerエンジン乗せてその上にサービスを展開している鯖と
インスタンスの上に直接サービス(httpdとか）のせてサービス展開している鯖はどっちが信頼性高いのって話だが？
どっちなのｗ？前者は単純に数が増えているように見えるが？
>1台でも100台でも変わらないと思う
本当にそう思うの？既に「入れてしまった人」は当然操作にも慣れてるだろうし、そもそもコンテナ外して
運用するのは2度手間になるから、1台でもコンテナで、になるんだろうけど本当に1台しか運用していない
会社に自信を持ってそれ、提案できる？1台でもEKS入れましょう、と。
>どうやって水平スケールするのか
つまり君はコンテナ以外じゃやったことが無いって話なんだろ？
>Dockerなしでも家畜化が出来ていたら、Docker導入のハードルは高くないはずだが
俺が直接運用しているサービスはそうやね。例え鯖1台でも「趣味として」EKS化しても全然悪くない
が、世の中にはそうでない人もいるわけよ。500円位の共用WEB鯖＋DBとか。
あるいは2万円の1台2台の専用鯖とか。
そういう人に本当にお勧めできるの？
アマゾンに移行して、コンテナ化してEKSしましょう、とか。
本当に？君は本当にそう思うの？
>>620
この書込みは全く意味不明。
宇宙語話してるの？そもそも「家畜化」ってIT用語なのｗ？
君以外の誰にも通用しない気がするがｗｗ
622(1): 2020/02/02(日)15:28 ID:TWOzawm+(11/12) AAS
1コンテナぐらいしか動いてないならEKSじゃなくてECSで良いと思うし既にやってる
楽だしお金がそんなにかかんない
CloudWatch Logsは無料分を超えると課金があるが、小規模なので無料分で余裕
これで破産する方が難しい
家畜とペットの例えはさっきしてたじゃん
AWSはEC2インスタンスはASGに入れて使い捨てするか、
EC2の上に乗っけたソフトウェアでレプリケーションを行って、1台は死んでも大丈夫にするのがベストプラクティス
それを行ってないインスタンスで動いてるサービスは止まっても知らねってスタイル
AWSではサーバーは家畜のように扱うべき、と言うのはここから来てる
従来のようにSSHして
手でOSにソフトウェアをインストール・アップデートして、
手でデプロイして、手でログ取得して
ってのはサーバーをペットのように可愛がりすぎ
そんな事やってたら家畜のように扱えない
623: 2020/02/02(日)15:41 ID:cuMP7GqL(16/27) AAS
>>622
悪いね、おれエスパーじゃないから、その例えで
「手でOSにソフトウェアをインストール・アップデートして、手でデプロイして、
手でログ取得してってのはサーバーをペットのように可愛がる」
なんてのは全く忖度できんかったわｗｗｗ
兎に角君の言っている事は、どっかしらにおかしな抜けがあるから、あさって
の方向の話にしか聞こえないｗｗ
じゃあなｗ
624: 2020/02/02(日)15:44 ID:031eKof+(1) AAS
外部ﾘﾝｸ:www.no1497.com
このサイトの手順丸パクりしてguiのLinux環境整えようとしたんですが
IPアドレス入力しconnect押すところで繋がらなくなります…
一応ifconfigとdocker内でのhostname -iで出てきたアドレス両方と、
ポート二つの4パターンの組み合わせ全部打ったんですが失敗しました。
これ以外のアドレスとかでしょうか？もし思い当たる方がいたら教えてください。
625: 2020/02/02(日)15:46 ID:TWOzawm+(12/12) AAS
>信頼性が高いといっているのは何を根拠に言っているのか知らんが、
>インスタンスの上にDockerエンジン乗せてその上にサービスを展開している鯖と
>インスタンスの上に直接サービス(httpdとか）のせてサービス展開している鯖はどっちが信頼性高いのって話だが？
>どっちなのｗ？前者は単純に数が増えているように見えるが？
Dockerのオーバーヘッドなど
元々あってないようなものとマジレス
ASGで動くという事はインスタンスを使い捨て出来てるってこと
AWS側の不具合でインスタンスが死んだり、
仮にSSHして変な設定を間違ってしてしまっても
終了するだけで自動的にインスタンスが再作成され
元のAMIから立ち上がって同じ設定がされて、
Dockerイメージも勝手にダウンロードされてまた動き出すので
元に戻る
よって信頼性が高くなる
動作が遅いけど、死んでるかどうか微妙なインスタンスの破棄は流石に無理だが
既存案件でいろいろ制約があるとかならまだしも
そうでなければECSで良くね？と思う
626: 2020/02/02(日)16:26 ID:rlDokdVB(1) AAS
久々にPHPの環境構築をしようと思ったんだが今はXAMPP使わずDocker使うのが主流らしいな
試してみるか
627(4): 2020/02/02(日)17:56 ID:vTMq3yW0(2/5) AAS
俺がいない間に随分と進んでるなｗ
>>592
> 代案つーか、コンテナ技術って時期尚早じゃね？サービスを構成する鯖が
またDocker（コンテナ）とKubernetes（クラスタ）を
ごっちゃにしてるアホがいるのか
サービスでデプロイした経験ないのか？
Wordpressぐらいしたことやるやろ？できるか？何が必要か想像つくか？
PHPだぞ。apache使うとするよな？そうするとmod_phpがいるぞ。
ライブラリ使ってたらPHPモジュールも入れないとだめだぞ
一発勝負で正しく作れるか？んん？
そしたら次は俺が作った動画アップロードとAI機能が充実した独自のスーパーブログだ。
わけって言語は複数使ってる。どうや正しくデプロイできるか？
これ以上の情報は何も教えてやらんぞ。必要な言語、ライブラリ、自分で判断しろよ
一発勝負で正しく作れるか？んん？
コンテナだったら簡単。一発勝負で作れる。
ほらな、デプロイ問題が解決した。
628(1): 2020/02/02(日)18:37 ID:cuMP7GqL(17/27) AAS
>>627
>サービスでデプロイした経験ないのか？
俺が言う台詞だそれはｗｗｗ
コンテナ以外でデプロイした経験無いのか？んん？
apache使うとするな？本当にmod_phpからやったのか？？
んん？？アホかお前は！
629(1): 2020/02/02(日)18:58 ID:vTMq3yW0(3/5) AAS
>>628
お前何も言い返してないやんｗ
俺が言った言葉を復唱しただけやんｗ
630: 2020/02/02(日)19:02 ID:cuMP7GqL(18/27) AAS
>>629
この書き込みから察するにデプロイメントって言葉の意味すら分かってないだろ？
どうしようもないｗｗあまーーーーりの馬鹿っぷりに呆れて物が言えない。
宇宙人と話すことは出来んな。
マジでスゲー呆然としたよまあ、良いから自分の胸に手をあてて、
Docker以外でデプロイしたことあったかな？と自問してみればｗｗ
631(1): 2020/02/02(日)19:04 ID:vTMq3yW0(4/5) AAS
そこでデプロイしたことあるけど？って答えたら
どうレスするんだろうｗ
はい、言い返してみな。
632(1): 2020/02/02(日)19:07 ID:cuMP7GqL(19/27) AAS
>>631
それなら絶対に627のような書き込みはしない。
633(1): 2020/02/02(日)19:16 ID:vTMq3yW0(5/5) AAS
>>632
理由が何も書いてないので、説得力ゼロ
やり直せ
634: 2020/02/02(日)19:26 ID:cuMP7GqL(20/27) AAS
>>633
まあ、分かったよ恥ずかしい奴らｗ
なんかもう、ね･･･Docker村の事情しか分かってなさそうだから
全てがおかしい。ASGの理解もおかしいし「サービス」って言葉の理解もおかしい。
いっとくが俺が>>592でかいた「サービス」ってのはk8s村でいう"サービス"の事ではなく、
世間一般のIT用号で言う「サービス」だからな。592の書き込みにコンテナ技術の一実装
でしかないDockerとかK8sを念頭において書いていないぞ。
･･･それは、理解できるよね？オッケー？
635(1): 2020/02/02(日)19:35 ID:iUJbnHUw(1/10) AAS
はい理解してます。本題をどうぞ
636: 2020/02/02(日)19:37 ID:cuMP7GqL(21/27) AAS
>>635
というわけで>>627の書き込みは意味不明って事で
オッケー？本題はこれね。
637(1): 2020/02/02(日)19:37 ID:iUJbnHUw(2/10) AAS
意味不明の理由が書いてない。やり直し。
638: 2020/02/02(日)19:39 ID:cuMP7GqL(22/27) AAS
>>637
日本語を書くけど日本語は理解できない
宇宙人とは会話は出来ませーーーーんｗ
君馬鹿すぎて話にならんよｗｗ
じゃ、そういう事で！
639(1): 2020/02/02(日)19:49 ID:iUJbnHUw(3/10) AAS
はい、逃げた
640(1): 2020/02/02(日)20:02 ID:cuMP7GqL(23/27) AAS
>>639
じゃあ君に聞くけどさ、>>592でIT一般用語で言う「サービスを構成するサーバーが･･･」という話を振ったら
Dockerのクラスタで言う「サービスのデプロイ」の話を返した奴がいるとする、スーパーブログがどうのこうのと。
君はそれを聞いて、意味不明とは受け取らないのｗｗ？
俺はそれを聞いて、一般用語で言う「デプロイ」の話だと受け取るわけだ。
前の文脈が一般用語だから。するとおかしな事なるよな？だから変な話になっている。
で君はその流れを理解できない訳だ。ｗ
はい、逃げたってｗ
「はい理解してます。本題をどうぞ」ってお前、何にも理解してない東南アジアの通訳みたいなこと言うなよｗ
641: 2020/02/02(日)20:05 ID:iUJbnHUw(4/10) AAS
サービスをデプロイした経験があれば、
wordpress？それはなん言語で動くんですか？php？
え？アプリケーションサーバーが別に必要？
プラグイン使ってるから、追加でPHPモジュールが必要？
とかいう時代から、
wordpressその他で構成したDockerイメージがあるので
そのコンテナを動かすだけだよ。
必要なものは全てDockerイメージに含まれてる。
という時代になって
デプロイが簡単になったってのがわかるはずだけどな。
まあどうせ一人で全部やってるんでしょ？
だから何が必要かは全部俺が知ってる。
Dockerイメージを作る手間もデプロイする手間も変わらない。
どこでやるかが変わっただけで、どうせやるのは全部俺
みたいに思ってるんだろうな
642(1): 2020/02/02(日)20:06 ID:iUJbnHUw(5/10) AAS
>>640
> Dockerのクラスタで言う「サービスのデプロイ」の話を返した奴がいるとする、
そんな奴はどこにもいない。
おまえの思い込み
643: 2020/02/02(日)20:07 ID:iUJbnHUw(6/10) AAS
たとえクラスタなくて、起動するマシンが1台であっても
コンテナがあればデプロイが簡単になるわけだよ
644: 2020/02/02(日)20:13 ID:cuMP7GqL(24/27) AAS
>>642
まあ良いよ俺が戻ってきたのは>>627の書き込みが意味不明に思えたからであって
宇宙人の君と頓珍漢な会話したい訳じゃない。
645: 2020/02/02(日)20:16 ID:iUJbnHUw(7/10) AAS
経験不足の人が理解できず意味不明に思えた
ただそれだけの話です。
646: 2020/02/02(日)20:28 ID:cuMP7GqL(25/27) AAS
もし世間一般のデプロイの話をして返したとして>>627というのなら、それならやはり理解不足
そもそもphpのdeployerつかってもmod_phpのインストールなんかしないし。
・・・と、627と関係ない宇宙人の書込に反応してみる。
スーパーブログがどうのこうのなんてどうでも良い話しだしｗ。
647: 2020/02/02(日)20:39 ID:Q4JuNZ7V(1) AAS
ECSはELBと組み合わせてローリングデプロイが行える
新しいバージョンのECSタスクは
ELBに新しいターゲットとして登録され、一時的に両方が存在する状態になる
新しいバージョンのECSタスクのターゲットが正常と判定されると、
古いバージョンのECSタスクのターゲットへはリクエストが行われなくなり、タスクは終了する
新しいバージョンのタスクに明らかな異常があり、それに気づかないままデプロイ完了するミスを防げる
ECSはCodeDeployと連携したブルー・グリーンデプロイにも対応している
外部ﾘﾝｸ:dev.classmethod.jp
テスト用サイトで確認してから新旧バージョンを入れ替え出来るので、
より安全
648: 2020/02/02(日)20:40 ID:iUJbnHUw(8/10) AAS
> そもそもphpのdeployerつかってもmod_phpのインストールなんかしないし。
なんで？いかなる場合もそうだって言える理由は何？
mod_phpを使わない事例 "一例" を言えって言ってるんじゃないよ。
mod_phpが使わない事例 "しか存在しない" という理由を聞いてる
649: 2020/02/02(日)20:41 ID:iUJbnHUw(9/10) AAS
phpのdeployerっていうのも意味不明だし
どっかのサービスにベンダーロックインでもされてるの？ｗ
自前のサーバーでデプロイした経験ありますか？
650: 2020/02/02(日)21:05 ID:5Cwo7VNY(1) AAS
熱くなりすぎて引くわ
651(7): 2020/02/02(日)21:47 ID:cuMP7GqL(26/27) AAS
ここまでか？ここまで分からんとはね・・・・・･。
DeployerでLaravelをデプロイする
外部ﾘﾝｸ:qiita.com
Capistranoで簡単デプロイ
外部ﾘﾝｸ:qiita.com
DeployerによるPHPデプロイ
外部ﾘﾝｸ:blog.excite.co.jp
Java アプリケーションのデプロイ
外部ﾘﾝｸ[html]:ecl.ntt.com
Force.com開発でGitを使ったデプロイ
外部ﾘﾝｸ[php]:www.terrasky.co.jp
世間一般で多くの場合、「デプロイする」とは
配備指示書にしたがってプログラムを文字通り「配備」（多くの場合はコピー）する事であり、
環境のセットアップは含まない。Docker村ではその特性から含んでいる、というだけ。
652(1): 2020/02/02(日)21:48 ID:iUJbnHUw(10/10) AAS
↑
このようないろんな「デプロイ」が
Dockerの1つのコマンドでできるようになるわけです。
653: 2020/02/02(日)22:07 ID:cuMP7GqL(27/27) AAS
>>652
以上、馬鹿で無知な>>iUJbnHUwに教えてあげました。
マジ感謝しろよｗ。
上下前次1-新書関写板覧索設栞歴
あと 349 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.046s