Docker Part3

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

http://www.docker.io/

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

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

動かすのが自作アプリ1個だけで
Goならそれで良いんじゃね？
知らんけど

バックエンドはGoで、
フロントエンドはNodeで、
リバースプロキシにnginxとかやりだしたら
コンテナの方が楽だな

>>690
それはLinuxのカーネル以外を全て一つに外部プロセス呼び出しなしの
スタティックリンクできるって言ってるの同じことだぞ

例えばRubyのスクリプトとgitコマンドとffmpeg実行ファイルを
一つの実行ファイルにまとめれると？

技術的、ライセンス的に可能だと思うか？

>>683の/k/BdpP5氏、逃げちゃったみたいだね。
難しい話語るのは大好きだけど、自分の単純な経験は語れない
可愛そうな人だったｗ

>>694
ヒント　月曜日

ホストのOS上でコンテナのコマンドを実行する方法ってありませんか？
例えばMacにあるelfファイルをDocker内のUbuntuで実行したり
Linux上のexeファイルをDocker内のWindowsで実行するような

docker内のWindows・・・

>>696
ない。ボリュームを使え。

コンテナなら
いちいちインフラチームにNode使えるサーバー用意してとか言って
準備してもらう必要もないからな
最終的にDockerイメージを作りさえすれば良い

>>696
このひとDockerをVirtualBoxか何かと勘違いしてる？
両者は異なる問題を解決するために作られたものだ

>>700
すみません正にその通りです。軽いから簡易的なVirtualBoxのような使い方ができそうとか考えてた初心者です、素直にそっち使うことにします。
所で新たに生じた疑問なんですがよく紹介されてるUbuntuとかのOSイメージって何に使われてるんでしょうか？
色々調べたらアプリとか鯖に使われてることは大半なんですがOSの使用例があまり見つからなくて。

>>695
あいつはたぶんニートか学生だろ。
月曜午前中に連投してたし。
たぶん学生じゃね？

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

俺はこの回答をずっと待っているんだが、
早く答えてくれないかな？
何で時間がかかるのか全く分からんｗ

>>701
サーバやアプリケーションを動かすための最小限のファイルセットが含まれている

OSそのものとしてはあまり使わないのでinit（systemd等）も通常入ってない

>>703
どうやっていたの？って何を聞きたいのかわからん。
Docker以前？ 大昔のデプロイの話か？

今みたいにぽんぽんサーバー作れるわけじゃないから、新しくサーバーをデプロイするのは
たいていサーバーの購入から始まる。サーバーのセットアップは手順書が残ってるからそのとおりやる。
もちろん手順書がない初回は、手順書を書きつつサーバーにセットアップするわけだが。

手順書と言ってもそのハードウェアとかOSのバージョンは変わるわけで、
手順書通りやると言うより記録見ながらその都度対応が必要になる。
アプリ用とか特定のものを動かすのに必要なパッケージを手順書という名の
記録を見ながらインストールしていく

で、パッケージをインストールしただけじゃ終わらない。バージョンが微妙に変わるから
アプリの改修作業が必要になる。大体は言語のライブラリが新しくなってるからそれに合わせてアプリを修正する。
アプリの改修作業まで行ってようやく（例えばアプリケーションサーバーの）一台のデプロイが完了する。

その後はそのサーバーを大事に育てる（笑）上記のようなデプロイ作業をアプリのアップデートのたびにやれるわけがないからね
データベースサーバーとかならセキュリティパッチを当てるぐらいで対して変わらないがアプリケーションサーバーは大変。
ある機能に対応するためにライブラリのアプデートが必要だがそれが標準パッケージで提供されてないから
オレオレでパッケージングする必要がある。当時はperlだったから、dh-make-perlだっけな？それでDebian用のパッケージを作る。
アプリの更新はsvn up（笑）そしてapacheの再起動（笑）手動（笑）当時は便利なツールは何もなかったからな。

今は楽だよ。Dockerさえ動く環境があればいい。アプリのアップデート作業なんてものはない。
サーバーはハードウェア仮想化され消して作り直すことなんて簡単、壊してデプロイすればアプリも新しくなっている。
アプリもコンテナ化され、単一のサーバーだろうがクラスタだろうがどこでも動く

うちは最初はサーバーはSSHしてセットアップし、
phpファイルをSFTPでアップロードしてた
当然ながら要らないファイルをアップしたり、し忘れるミスが多発

次にローカルからのrsyncになったが、
rsyncの無視するファイルのルールを編集し忘れて
ファイルが消えたりした

なお、どちらでも本番環境を直接書き換える模様
ブルー・グリーンデプロイ？なにそれ美味しいの？

次の進化は>>651
みたいなphp専用のデプロイツールとも思ったが、
それを経由せずCIでビルドとAmazon ECSでデプロイに進化した

データベースのマイグレーションを除けば
Dockerイメージの更新だけで
安全にローリングデプロイ可能になった

EC2インスタンスはあるが、
ASGで使い捨てになり
サーバーがキャトルミューティレーションされたみたいに死んでも、
代わりをすぐ作れるようになった

アプデもAmazonの配布するAMIの更新で済む

なんか最近はコンテナランタイム沢山あってよくわからない
どれを使えと
rkt（死亡？）
containerd
podman
lxd
cri-o

基本はDockerを使っていればいい
コンテナランタイムは使える場合があったときに考えればいい
自分から使えるようにするものじゃない

openshiftの話題が全然出てこないけど、まだみんな使ってないのかな

ベースはKubernetesだからなぁ

クーベルネイティスのスレもあるんやけどなあ