Docker Part3

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

http://www.docker.io/

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

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されて全部消えるよ
大した規模じゃないからオートスケーリングいらないってんなら、君にはコンテナなんて要らないから帰ってね、としか

>>608
オートスケーリングはそういう用途じゃないな。
繁忙期のサーバー落ち＞障害調査
の場合にのみ使用するとしか言えない。
分からないなら答えないでねとしか。

だからログはCloudWatch Logsに送ればいいって話だろ？

コンテナ毎のCPU使用率やメモリー使用量はメトリクスはECSエージェントがCloudWatchに送ってくれる

>>609
そもそもログ収集してないのに問題のインスタンスの特定とかどうすんの？
台数が少けりゃスナップショット撮ってれば努力と根性でなんとかなるかもしれないけど、
うちの場合はその作業が一度発生したら自前でログ収集の仕組みを構築するコストを余裕で上回る工数だねえ

>>607
>ログやメトリクスはマネジメントコンソールから見られるし、

これもね、じゃあ障害解析のために開発者全員がマネジメントコンソール
見れて良いのかとか、微妙で面倒くさい問題が出そうな気がするんですよ･･･。

>>611
自分が携わっている範囲内で言えば、インスタンスが特定できずに問題が解決
しなかったなんてことは無いな。コストがかかりすぎた、という事も無い。
ド素人じゃないんだし、それ位分かるよな？としか･･･。

>>612
ログを取るためだけにSSHするのは良いのかよw

AWSの組織機能で細かくアカウントをアプリ毎に分ける、
IAMロールを最小の権限のみにするなどした方がよほどセキュアだ

Cloudwatch Logsは
ローカルにログをダウンロードせずに
簡単な検索や分析も出来る
これもセキュアだろう

>>613
それインスタンスが数百台以上あっても同じこと言える？
結局何が言いたいのか知らないけど、何が手でSSHして回れる程度の台数でコンテナなんか要らん、と言いたいならまあその通りだと思うよ

>>615
だから結論は>>601だと言っているでしょ。
以後のやり取りのすべてを見てもやはり601やね。
10台以下で運用するのは、まあ、趣味の世界やな。。
悪くは無いけど運用上実利がある訳じゃないよと。
まあ興味があるならやっても良いよ、あるいはもっと大きな
サービス運用業者に転職を視野にいれてしれっとやってみるとか、
そんな感じと思ったね。

結局何が言いたいのかサッパリ分からんやつだったな
小規模だったらそもそも台数の調整とか要らないだろって話は無視か

>>617
君の言っている事こそ意味不明ｗ。
小規模で台数の調整が要らないらならEKSもECSも要らないっしょ。
ちなみに小規模であることと台数の調整が不要であることはイコールではない。
小規模でも繁忙期に台数増やしたいとかは当然ある。

サーバーを家畜化した方が運用が楽で信頼性も高いのは
1台でも100台でも変わらないと思う
総利益が大きいのはそりゃ100台だろうが

そもそもサーバーの家畜化もできてなかったら
どうやって水平スケールするのか

Dockerなしでも家畜化が出来ていたら、Docker導入のハードルは高くないはずだが

Dockerなしでも家畜化出来てたら
それぞれのサーバーにSSHしてログ取ったりなんていらんはずだけど
まさか手作業で環境を複製してASGもどきをやってるのか？
超無駄じゃね？
ASGでやれよ

>>619
>信頼性も高いのは

信頼性が高いといっているのは何を根拠に言っているのか知らんが、
インスタンスの上にDockerエンジン乗せてその上にサービスを展開している鯖と
インスタンスの上に直接サービス(httpdとか）のせてサービス展開している鯖はどっちが信頼性高いのって話だが？
どっちなのｗ？前者は単純に数が増えているように見えるが？

>1台でも100台でも変わらないと思う

本当にそう思うの？既に「入れてしまった人」は当然操作にも慣れてるだろうし、そもそもコンテナ外して
運用するのは2度手間になるから、1台でもコンテナで、になるんだろうけど本当に1台しか運用していない
会社に自信を持ってそれ、提案できる？1台でもEKS入れましょう、と。

>どうやって水平スケールするのか

つまり君はコンテナ以外じゃやったことが無いって話なんだろ？

>Dockerなしでも家畜化が出来ていたら、Docker導入のハードルは高くないはずだが

俺が直接運用しているサービスはそうやね。例え鯖1台でも「趣味として」EKS化しても全然悪くない
が、世の中にはそうでない人もいるわけよ。500円位の共用WEB鯖＋DBとか。
あるいは2万円の1台2台の専用鯖とか。
そういう人に本当にお勧めできるの？
アマゾンに移行して、コンテナ化してEKSしましょう、とか。
本当に？君は本当にそう思うの？

>>620
この書込みは全く意味不明。
宇宙語話してるの？そもそも「家畜化」ってIT用語なのｗ？
君以外の誰にも通用しない気がするがｗｗ

1コンテナぐらいしか動いてないならEKSじゃなくてECSで良いと思うし既にやってる
楽だしお金がそんなにかかんない

CloudWatch Logsは無料分を超えると課金があるが、小規模なので無料分で余裕
これで破産する方が難しい

家畜とペットの例えはさっきしてたじゃん

AWSはEC2インスタンスはASGに入れて使い捨てするか、
EC2の上に乗っけたソフトウェアでレプリケーションを行って、1台は死んでも大丈夫にするのがベストプラクティス
それを行ってないインスタンスで動いてるサービスは止まっても知らねってスタイル
AWSではサーバーは家畜のように扱うべき、と言うのはここから来てる

従来のようにSSHして
手でOSにソフトウェアをインストール・アップデートして、
手でデプロイして、手でログ取得して
ってのはサーバーをペットのように可愛がりすぎ
そんな事やってたら家畜のように扱えない

>>622
悪いね、おれエスパーじゃないから、その例えで
「手でOSにソフトウェアをインストール・アップデートして、手でデプロイして、
　手でログ取得してってのはサーバーをペットのように可愛がる」
なんてのは全く忖度できんかったわｗｗｗ

兎に角君の言っている事は、どっかしらにおかしな抜けがあるから、あさって
の方向の話にしか聞こえないｗｗ
じゃあなｗ

http://www.no1497.com/?p=598
このサイトの手順丸パクりしてguiのLinux環境整えようとしたんですが
IPアドレス入力しconnect押すところで繋がらなくなります…
一応ifconfigとdocker内でのhostname -iで出てきたアドレス両方と、
ポート二つの4パターンの組み合わせ全部打ったんですが失敗しました。
これ以外のアドレスとかでしょうか？もし思い当たる方がいたら教えてください。

>信頼性が高いといっているのは何を根拠に言っているのか知らんが、
>インスタンスの上にDockerエンジン乗せてその上にサービスを展開している鯖と
>インスタンスの上に直接サービス(httpdとか）のせてサービス展開している鯖はどっちが信頼性高いのって話だが？
>どっちなのｗ？前者は単純に数が増えているように見えるが？

Dockerのオーバーヘッドなど
元々あってないようなものとマジレス

ASGで動くという事はインスタンスを使い捨て出来てるってこと
AWS側の不具合でインスタンスが死んだり、
仮にSSHして変な設定を間違ってしてしまっても
終了するだけで自動的にインスタンスが再作成され
元のAMIから立ち上がって同じ設定がされて、
Dockerイメージも勝手にダウンロードされてまた動き出すので
元に戻る
よって信頼性が高くなる

動作が遅いけど、死んでるかどうか微妙なインスタンスの破棄は流石に無理だが

既存案件でいろいろ制約があるとかならまだしも
そうでなければECSで良くね？と思う

久々にPHPの環境構築をしようと思ったんだが今はXAMPP使わずDocker使うのが主流らしいな
試してみるか

俺がいない間に随分と進んでるなｗ

>>592
> 代案つーか、コンテナ技術って時期尚早じゃね？サービスを構成する鯖が

またDocker（コンテナ）とKubernetes（クラスタ）を
ごっちゃにしてるアホがいるのか

サービスでデプロイした経験ないのか？
Wordpressぐらいしたことやるやろ？できるか？何が必要か想像つくか？
PHPだぞ。apache使うとするよな？そうするとmod_phpがいるぞ。
ライブラリ使ってたらPHPモジュールも入れないとだめだぞ
一発勝負で正しく作れるか？んん？

そしたら次は俺が作った動画アップロードとAI機能が充実した独自のスーパーブログだ。
わけって言語は複数使ってる。どうや正しくデプロイできるか？
これ以上の情報は何も教えてやらんぞ。必要な言語、ライブラリ、自分で判断しろよ
一発勝負で正しく作れるか？んん？

コンテナだったら簡単。一発勝負で作れる。
ほらな、デプロイ問題が解決した。

>>627
>サービスでデプロイした経験ないのか？

俺が言う台詞だそれはｗｗｗ
コンテナ以外でデプロイした経験無いのか？んん？
apache使うとするな？本当にmod_phpからやったのか？？
んん？？アホかお前は！

>>628
お前何も言い返してないやんｗ
俺が言った言葉を復唱しただけやんｗ

>>629
この書き込みから察するにデプロイメントって言葉の意味すら分かってないだろ？
どうしようもないｗｗあまーーーーりの馬鹿っぷりに呆れて物が言えない。
宇宙人と話すことは出来んな。
マジでスゲー呆然としたよまあ、良いから自分の胸に手をあてて、
Docker以外でデプロイしたことあったかな？と自問してみればｗｗ

そこでデプロイしたことあるけど？って答えたら
どうレスするんだろうｗ

はい、言い返してみな。

>>631
それなら絶対に627のような書き込みはしない。

>>632
理由が何も書いてないので、説得力ゼロ
やり直せ

>>633
まあ、分かったよ恥ずかしい奴らｗ
なんかもう、ね･･･Docker村の事情しか分かってなさそうだから
全てがおかしい。ASGの理解もおかしいし「サービス」って言葉の理解もおかしい。
いっとくが俺が>>592でかいた「サービス」ってのはk8s村でいう"サービス"の事ではなく、
世間一般のIT用号で言う「サービス」だからな。592の書き込みにコンテナ技術の一実装
でしかないDockerとかK8sを念頭において書いていないぞ。
･･･それは、理解できるよね？オッケー？

はい理解してます。本題をどうぞ

>>635
というわけで>>627の書き込みは意味不明って事で
オッケー？本題はこれね。

意味不明の理由が書いてない。やり直し。

>>637
日本語を書くけど日本語は理解できない
宇宙人とは会話は出来ませーーーーんｗ
君馬鹿すぎて話にならんよｗｗ
じゃ、そういう事で！

はい、逃げた

>>639
じゃあ君に聞くけどさ、>>592でIT一般用語で言う「サービスを構成するサーバーが･･･」という話を振ったら
Dockerのクラスタで言う「サービスのデプロイ」の話を返した奴がいるとする、スーパーブログがどうのこうのと。
君はそれを聞いて、意味不明とは受け取らないのｗｗ？
俺はそれを聞いて、一般用語で言う「デプロイ」の話だと受け取るわけだ。
前の文脈が一般用語だから。するとおかしな事なるよな？だから変な話になっている。
で君はその流れを理解できない訳だ。ｗ

はい、逃げたってｗ
「はい理解してます。本題をどうぞ」ってお前、何にも理解してない東南アジアの通訳みたいなこと言うなよｗ

サービスをデプロイした経験があれば、

wordpress？それはなん言語で動くんですか？php？
え？アプリケーションサーバーが別に必要？
プラグイン使ってるから、追加でPHPモジュールが必要？

とかいう時代から、

wordpressその他で構成したDockerイメージがあるので
そのコンテナを動かすだけだよ。
必要なものは全てDockerイメージに含まれてる。

という時代になって

デプロイが簡単になったってのがわかるはずだけどな。
まあどうせ一人で全部やってるんでしょ？

だから何が必要かは全部俺が知ってる。
Dockerイメージを作る手間もデプロイする手間も変わらない。
どこでやるかが変わっただけで、どうせやるのは全部俺
みたいに思ってるんだろうな

>>640
> Dockerのクラスタで言う「サービスのデプロイ」の話を返した奴がいるとする、

そんな奴はどこにもいない。
おまえの思い込み

たとえクラスタなくて、起動するマシンが1台であっても
コンテナがあればデプロイが簡単になるわけだよ

>>642
まあ良いよ俺が戻ってきたのは>>627の書き込みが意味不明に思えたからであって
宇宙人の君と頓珍漢な会話したい訳じゃない。

経験不足の人が理解できず意味不明に思えた
ただそれだけの話です。

もし世間一般のデプロイの話をして返したとして>>627というのなら、それならやはり理解不足
そもそもphpのdeployerつかってもmod_phpのインストールなんかしないし。
・・・と、627と関係ない宇宙人の書込に反応してみる。
スーパーブログがどうのこうのなんてどうでも良い話しだしｗ。

ECSはELBと組み合わせてローリングデプロイが行える
新しいバージョンのECSタスクは
ELBに新しいターゲットとして登録され、一時的に両方が存在する状態になる
新しいバージョンのECSタスクのターゲットが正常と判定されると、
古いバージョンのECSタスクのターゲットへはリクエストが行われなくなり、タスクは終了する
新しいバージョンのタスクに明らかな異常があり、それに気づかないままデプロイ完了するミスを防げる

ECSはCodeDeployと連携したブルー・グリーンデプロイにも対応している

https://dev.classmethod.jp/cloud/aws/ecs-codedeploy-blue-green-deployment/

テスト用サイトで確認してから新旧バージョンを入れ替え出来るので、
より安全

> そもそもphpのdeployerつかってもmod_phpのインストールなんかしないし。

なんで？いかなる場合もそうだって言える理由は何？

mod_phpを使わない事例 "一例" を言えって言ってるんじゃないよ。
mod_phpが使わない事例 "しか存在しない" という理由を聞いてる

phpのdeployerっていうのも意味不明だし
どっかのサービスにベンダーロックインでもされてるの？ｗ
自前のサーバーでデプロイした経験ありますか？

熱くなりすぎて引くわ

ここまでか？ここまで分からんとはね・・・・・･。

DeployerでLaravelをデプロイする
https://qiita.com/sandabu/items/c09eb23137a9d5269f10

Capistranoで簡単デプロイ
https://qiita.com/Esfahan/items/1258d37eb6a85fa35b02

DeployerによるPHPデプロイ
https://blog.excite.co.jp/exdev/27205935/

Java アプリケーションのデプロイ
https://ecl.ntt.com/documents/tutorials/rsts/Paas/deploy/java.html

Force.com開発でGitを使ったデプロイ
https://www.terrasky.co.jp/blog/2016/161028_001862.php

世間一般で多くの場合、「デプロイする」とは
配備指示書にしたがってプログラムを文字通り「配備」（多くの場合はコピー）する事であり、
環境のセットアップは含まない。Docker村ではその特性から含んでいる、というだけ。

↑
このようないろんな「デプロイ」が
Dockerの1つのコマンドでできるようになるわけです。

>>652
以上、馬鹿で無知な>>iUJbnHUwに教えてあげました。
マジ感謝しろよｗ。

捨て台詞ｗｗｗ