Docker Part3

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

http://www.docker.io/

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

>>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に教えてあげました。
マジ感謝しろよｗ。

捨て台詞ｗｗｗ

デプロイに関しては確かにスレッドの最初の頃から理解がおかしい人がいたね。

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

↑ほんとだｗ間違ってるｗ プログラムをコピーすることだって
qiitaの記事持ってきて環境のセットアップが含まないとかｗ


「本当の」世間一般の定義でも貼り付けときますか？

http://e-words.jp/w/%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4.html

ソフトウェアの分野で、開発したソフトウェアを利用できるように実際の運用環境に
展開することをデプロイということがある。インストール（install）に近い意味だが、
サーバコンピュータ上で運用され外部からネットワークを通じて利用されるソフトウェアや、
他のソフトウェアから参照されるコンポーネントなどを、利用可能な状態にする、
アクセス可能にする、といったニュアンスがある。

https://kotobank.jp/word/deploy-1689419
アプリケーションソフトを、利用者の実際の運用環境で利用できるように準備すること。
◇「インストール」がコンピューター上で実行可能なファイルを準備することであるのに対して、
「デプロイ」は実行時に必要なライブラリーやコンポーネントなども含めて
実行可能であるように準備すること。「デプロイメント」ともいう。

大変なデプロイが簡単になるって言う意味がわからんかったのかな？
デプロイ？そんなのファイルコピーするだけじゃん
git使っていれば、git pullするだけ！とか思ってそう

> git使えば良いおじさん登場か
これってそういう意味だったのか

>>657
分かったから涙拭けよｗ
「「本当の」世間一般の定義」を張らなきゃ分からないんだろ？
つまり君自身は「デプロイ作業」を経験したことは無いわけだ。
だから、現場の俺とは全然話が合わないｗ。javaでwarファイルをデプロイした、
とか開発現場でphpでもpythonでも良いけど、本番機にデプロイした、
といった場合、常識的に、mod_phpをインストールするなんてことは無い。

>phpのdeployerっていうのも意味不明だし

phpのdeployerでググったら大量に出ますがな…。

> 「「本当の」世間一般の定義」を張らなきゃ分からないんだろ？

俺がわからないから「「本当の」世間一般の定義」を貼ったんじゃなくて
間違ってるやつがいるから貼ったんだけど？

ともかく「「本当の」世間一般の定義」は
必要なライブラリーやコンポーネントなども含めて
実行可能であるように準備する
ということに異論はないね

>>660
わかったよｗ
君の経験の浅さがめっちゃ出てるよ。
マジで俺にしてみれば、この話題をこんなに教えてあげても全然
理解しないとかって、馬鹿じゃないの？としか思わないんだが。

>>686
デプロイは必要なライブラリーやコンポーネントなども含めて
実行可能であるように準備することなので
mod_phpをインストールすることも含まれる

お前がやってるのはデプロイじゃなくて
デプロイ済みの環境のソフトウェアを
アップデートしてるだけ

つまりデプロイからやったこと無いんやろ？

>>662
もう良いよ、相変わらず宇宙人だなｗ
君は俺とは違う惑星でデプロイ作業してたんだろうなｗ
もう会話してもしょうがない。じゃーなｗ

お前がなんと言おうと

https://kotobank.jp/word/deploy-1689419
アプリケーションソフトを、利用者の実際の運用環境で利用できるように準備すること。
◇「インストール」がコンピューター上で実行可能なファイルを準備することであるのに対して、
「デプロイ」は実行時に必要なライブラリーやコンポーネントなども含めて
実行可能であるように準備すること。「デプロイメント」ともいう。

Dockerイメージは全て
VirtualBoxとかの仮想マシンイメージで代用出来ると豪語するおじさんなら前いたが
それすらやらないおじさん登場か
もうとにかく手作業を増やして
無駄な仕事を増やしたいとしか思えない

>>664-665
こいつらは本当に糞。
自分の無知を、全く認めようとしないのね。
言っとくがお前が何と言おうと普通に現場でデプロイ（リリース）やってる
人が「明日（デプロイヤ使って）リリースします」とかいった場合に、そこに
「mod_phpのインストール」なんて作業は入らない。普通にIT現場で仕事
してりゃ分かるよ。夜間に dep production_web　とかやるだけだ。

どうしようもない馬鹿だな。

>>666
お前、apacheとかmysqlとかのデプロイしたことないだろ？

>>667
馬鹿な君とやり取りすると必ず齟齬るから厳密に言ってくれれないかな？
apacheの何を行うことを持ってデプロイといっているの？
mysqlの何を行うことを持ってデプロイといっているの？
回答はそれ次第。

>>668
https://aws.ama
zon.com/jp/rds/mysql/

> Amazon RDS を使用すると、コスト効率が良く、サイズ変更が可能なハードウェア容量で、
> スケーラブルな MySQL サーバーを数分でデプロイできます。

https://kubernetes.io/ja/docs/tutorials/
例: 永続ボリュームを使ったWordPressとMySQLのデプロイ

https://docs.ansible.com/ansible/latest/user_guide/guide_rolling_upgrade.html
The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers.

>>669-670
この回答の全てにおいてお前の経験の無さと論理的思考の欠如が良く出ているよ。
その2つに関して経験があるかと聞かれれば、「あるよ」で終わり。
が669に関して言えば、その説明に書いてあることは広義の意味で正しいけど、IT現場一般でその作業を「デプロイ」とは言わない。

670はそもそも一般的で言うIT用語のデプロイと、Docker村のデプロイの言葉の差違を今話題にしていて、
「一般的なデプロイとは何か」を語っている何故お前はDocker(k8s)村のデプロイの話を持ってくるの？
経験があるのかと聞かれれば当然あるよ。だがそれは、Docker村の用語でしかない、Dockerの場合はコンテナ破棄するんだから
そうするしかないだろ。でもそれはDocker村の話でDoker村を離れた現場では、>>651がデプロイだ、という話をずっとしている訳だが？
だからデプロイが複雑な場合はDockerが有効なこともありうるよ、と>>575でいったんだが。

ハァ

････お前の馬鹿っぷりは良く分かった。
もう俺にレスするな。俺はお前のような馬鹿と話はしたくない。
お前Docker村の話しか理解できない、自分の能力の無さが色んなところでスゲェ迷惑してるって気付いてないだろ？
620番台（もっと言えばこのスレの2桁番代から）から本来一瞬で終わる話を延々と続けてるんだが？

※ 以下の二つはDockerとは関係ない「デプロイ」であるというのが>>672の笑える点ですw

> Amazon RDS を使用すると、コスト効率が良く、サイズ変更が可能なハードウェア容量で、
> スケーラブルな MySQL サーバーを数分でデプロイできます。

http://docs.ansible.com/ansible/latest/user_guide/guide_rolling_upgrade.html
The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers.

>>673
オッケー、もう話したくは無いというのを反故にするけど、ちょっとじゃあ、君の開発経験を教えてくれ。
俺の話が全く通じないのはその辺に原因があると思う。

君は、Docker以前はどのような言語、フレームワーク、開発体制（人数など）でソフトウェエア開発プロジェクトを行っていた？
それは、プロジェクトの数で言えば幾つ位で年数は何年位？

でその時に、当然、自分とかチームがが開発したものを開発、検証サーバーや本番サーバーに上げたと思うけど、その時の
デプロイはどの様に行っていたの？（ここで言うデプロイはDocker用語じゃなく、>>651的なものね）
当然本番機にあげなきゃ動かないよね？どうやっていたの？

>>674
まずお前がその自分の質問内容に答えろや
揚げ足撮ろうとしてるのバレバレ

あとお前ansibleでMySQLのデプロイしたことあるの？

http://docs.ansible.com/ansible/latest/user_guide/guide_rolling_upgrade.html
The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers.

>>676
ansibleでデプロイ？そんな事はしないよ。で>>674に答えてくれるかな。

>>674
まずお前がその自分の質問内容に答えろや
揚げ足撮ろうとしてるのバレバレ

>>677
やっぱりansibleでMySQLのデプロイとかしたことないのねw

>>675
>※ 以下の二つはDockerとは関係ない「デプロイ」であるというのが>>672の笑える点ですw

こういう点ね。「本番システムにデプロイする」とか、そういった単語が使われるようになったのは
俺の経験じJavaあたりからで、（war/earファイルをデプロイする、とか）、それは十数年前のことで、その
当時から、「デプロイする」といえば、>>651のような作業で、RDS作ることをデプロイするとは言わなかった。
あくまで経験でしか答えられないからね。君が俺と同じ位の経験値を持って話をするなら、俺の話に
抵抗するなんて事は無い。皆そういってたから。

で、その話とは関係無しに、Docker以前の開発現場で場数を踏んでいれば、
「当然本番機にあげなきゃ動かないよね？どうやっていたの？」に対して何らかの解決策を行っていたはずなんだか？
君の場合、それは何だったの？

>>678
答えたろ。君の経験を教えてくれよ。
逃げるなよｗ

>>679はひたすら「自分の（少ない）経験では〜」と繰り返してるだけ
現実見せても、俺の！俺の！というだけ
哀れやのうw

>>681
いや！
分かったから君の豊富な経験を語ってくれよ、是非！

>>682
語る意味がないので（笑）

それよりかお前が語れよ。

>「当然本番機にあげなきゃ動かないよね？どうやっていたの？」

こんなの、現場入ったら直ぐ直面する問題だし簡単な話だよな？
まじで、どうやっていたの？

>>683
だから>>651だって！俺はこれ以外の解決策を知らんよｗ！
君に通じないから不思議でしょうがないんだろｗ

>>683
意味が無いことは無い！>>651以外の解決策を君が知っているなら、
結構凄い事だ。俺が知らないんだし。
拝聴するから早く語ってくれよ！

おいおいレス止まってるよ！
ググったりするなよ！自分の経験から「俺はこうやってた」と言うだけだ。
1分で答えられるよなｗ？

ECS使った現代的なスタックなら
全部Terraformで済むから
Ansibleとかは要らない
ECSはTerraformのAWSプロバイダーで操作できる

ビルドはCIパイプライン内でだけ実行する
JavaやGoのアプリのビルドはここでする
JavaScriptのような動的言語でも、npmからパッケージ取ってきたり、Webpackを使うのにビルドする

本番環境でパッケージの取得やビルドはしない

開発用PCでは試しにビルドはするが、
自動テストを行うのと、
統一した環境でビルドするために
本番環境やQA環境に持っていくやつは必ずCIでビルドする
開発環境でビルトしたのを本番機に送る事はない

ECSの場合、
本番環境からSSHを完全排除も
やろうと思えば可能だな

本番環境の構成を考える時は
開発環境に同じ構成を作ってSSHして、
EC2を初期化するスクリプトのデバッグをやっても良いけど、
ECSのタスクはマネジメントコンソール等から一回限りの実行も可能だし、CI/CD環境で
ECSサービスの更新前にマイグレーションするようにしても良いので
SSHなしの運用も可能

コンテナのログはCloudWatchに送るようにして、
コンテナ以外のログはCloudWatch Agentとかを入れて取る

Goアプリを>>688みたいにビルド&デプロイしてるけど、正直もうホストに実行バイナリ置くだけでいいんじゃないか感は否めないな
結局ホストは多少なりとも意識しなきゃいけないんだから、本質的には余計なレイヤーは無い方が楽だと思うわ
デプロイとプロセスのライフサイクルの管理が楽というだけでなんとなくコンテナ使ってるが、
たかがそれだけのためにコンテナのような複雑で大袈裟なものが本当に必要なのだろうかとたまに感じる