[過去ﾛｸﾞ] Docker Part4 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
633(1): 2020/11/04(水)03:46 ID:QtKCHGIC(1/5) AAS
そういうこと。仮想マシンがあるのに
わざわざDockerでやる必要がない
634(1): 2020/11/04(水)03:47 ID:QtKCHGIC(2/5) AAS
DockerはDockerの目的にために利用するのがいい
635: 2020/11/04(水)03:57 ID:UuvmniCF(1) AAS
でもDockerの方がGUI無い分軽いじゃん
636(3): 2020/11/04(水)04:10 ID:7tuD0WTP(4/4) AAS
>>620
あと、この使い方は最初の一発目位は良いけど、運用が進むとそのうちexportされたetcやvarに
依存するようになって、ホストAで動いていたものがホストBでpullすると動かないとか、
コンテナの最大のウリだった可搬性も消えてなくなる気がする。
・・・まあ、VMで運用してメモリ食うことが問題なら、メモリ増やすことが解決策であって
privilegeにしてシステム全体をリスクに晒してまでコンテナ化して解決しよう、というのは
ちょっと理解し難いな。
637: 2020/11/04(水)08:25 ID:8vCtX8KM(2/10) AAS
>>628
>インフラの構築手順をコード化して共有するという、コンテナ化の元の理念
コード化するということは、意図したとおりにエラーなく進行するかいわばデバッグが必要になると思う。
おっしゃるとおりそれを共有するなら一回のデバッグの努力に意義があるけど、
自分でコンテナとそのイメージを構築するだけなら、
sshログインしてコンテナ内で直接構築作業すれば楽に思う。
共有しない構築手順のコード作成は労力がめんどうくさくなる。
638: 2020/11/04(水)08:30 ID:8vCtX8KM(3/10) AAS
>>636
>運用が進むとそのうちexportされたetcやvarに依存するようになって、ホストAで動いていたものがホストBでpullすると動かない
運用が進む前から、最初から、ボリュームに逃したetcやvarに依存しているよ。
もちろん、別のホストでコンテナを動作させるには、そのコンテナのイメージと、ボリューム内容、そしてrunするためのワンライナーが必要になる。
それでも、ホストマシンに直にシステム構築するよりもはるかに可搬性が高いと思う。
万人向けに共有する場合であればおっしゃるとおり、可搬性は悪いと言えると思うけどね。
コンテナを削除しても残り続けるボリュームという概念が存在するとは、
Dockerはボリュームに逃した内容（etc,varなど）に依存するコンテナがあっても仕方ないと考えているのではないかと思う。
639: 2020/11/04(水)08:33 ID:8vCtX8KM(4/10) AAS
>>633 >>634
Dockerの原理主義ってどうして多いんだろう
仮想マシンも、LCXも、Dockerコンテナに劣るところがたくさんある。
LCXはコンテナの削除などの扱いがディスクコピーにかかる時間を要するために非常に遅いらしい。
640: 2020/11/04(水)08:38 ID:8vCtX8KM(5/10) AAS
>>636
>運用が進む
運用が進むとはいっても、最初に構築したコンテナをイメージに固めるよ。
ただ、アプリのためのコンフィグファイルはコンテナのetcやvarなどに保存されるので、
その書き換えを目的としてそれらのディレクトリはボリュームに逃がしている。
etc全体とか、var全体にするよりも、もっと局所に留めるのが良いかもしれないけどね。
以後は、そのイメージからrunするようにする。>>628さんのいうような構築手順はコード化していないけど、
構築されたアプリケーションはイメージという形で維持しつづけるよ。
641: 2020/11/04(水)09:25 ID:1buxXrD8(1/3) AAS
IaC全くしてないレガシーなPHPのシステムをDocker+ECSに移行なら昔やった
でも、本番でバインドマウントしてるのはアップロードされたファイルだけだな
設定は環境変数から取得するようにして
アップロードされたファイルなど一部だけをバインドマウント経由でEFSに保存する
他は全てnginxやphpのイメージに予め入れておく
ログは標準出力経由で全てコンテナのログへ
DBは元から別サーバー
ローカル開発環境ではUnisonでphpファイルを同期
開発機のphp入ってるディレクトリを丸ごとマウントでも良いか、このシステムは肥大化してて遅いのでUnisonを使用
642: 2020/11/04(水)09:29 ID:sMNwaZ5l(1) AAS
俺は横着なのでDockerfileが構築手順書がわりになる方が便利
それがなけりゃlxc使う（かつては使ってた）
docker runも--rm付けて毎回クリーンに起動するのが性に合う
無論ログやdbファイルはボリュームで外部化するけど
643(1): 2020/11/04(水)10:03 ID:eFolKj+u(1) AAS
>>626
直接マウントするのはハードウェア1つにつきコンテナ1つだけ
マウントしてるコンテナが他のコンテナにサービスとしてファイルアクセスを提供する
排他制御とかもその1つのコンテナが全部引き受ける
644(1): 2020/11/04(水)10:13 ID:c69K63Cq(1) AAS
>>636
dockerに限らずIasCって必ずしもコストパフォーマンスがいいとも限らんからな
自動化の制御が複雑になるなら手作業で設定してコミットしちゃったほうが簡単だって考え方は十分ありだと思うよ
IasCに疲弊してる企業が、よくよく考えたら本当に欲しかったものはサーバーの状態をexp impする機能だった
645(1): 2020/11/04(水)11:06 ID:8vCtX8KM(6/10) AAS
>>643
ホストディレクトリをマウントしているコンテナが、
他のコンテナにサービスとしてファイルアクセスを提供するには、
XFSとか、Sambaとか、排他制御ができるというオンラインファイル共有サービスを公開するということですか。
なるほど、じゃあ、ボリュームをマウントしたコンテナが、
それらの共有サービスを公開すれば、他のコンテナでもボリューム内容を共有できますね。
646(1): 2020/11/04(水)11:10 ID:8vCtX8KM(7/10) AAS
>>644
>IasCに疲弊してる企業
Docker原理主義者の言うことを鵜呑みにしたのかしら
アプリの設定ファイル作成をコード化するなんて頭おかしいとすら思えてしまった。
647(3): 2020/11/04(水)11:13 ID:QtKCHGIC(3/5) AAS
>>645
オンライン共有サービス？ ストレージサービスとかいう名前でいいだろｗ
アプリ用コンテナとデータベース用コンテナは分けて
それぞれコンテナ＝1サービスにしろっていうのはそういうこと
648: 2020/11/04(水)11:14 ID:QtKCHGIC(4/5) AAS
>>646
それはあなたの感想であって、意見や主張は何も含まれてないですね
649: 2020/11/04(水)11:38 ID:g/DLzKYE(1/3) AAS
最初からDocker前提で書いてればそんな難しくはない
レガシーなシステムを大量に抱えてたら大変
650: 2020/11/04(水)12:24 ID:8vCtX8KM(8/10) AAS
>>647
でも、データベースの場合は、SQLコマンドのやり取りだけなので、データベースのデータファイルを直接オンラインストレージサービスで共有する必要はないよな。
排他制御を行うためにストレージサービス（XFS, samba）を使う場合は、ファイルレベルでの取り扱いが必要な場合だけだよね。
651(1): 2020/11/04(水)12:25 ID:mkPVUBW6(1) AAS
レガシーの移行はいっぺんにやろうとするな
VM、LXC、systemdコンテナ、Ansible、Chefなどを使って段階的に移行すべし
そもそもdockerに移行する意味があるのかはよく考えたほうがいい
652(2): 2020/11/04(水)12:31 ID:8vCtX8KM(9/10) AAS
>>647
でも、そもそもどうしてコンテナには1サービスしかおいたら駄目なのか？
例えば、名前解決させるのにdnsmasqデーモンが別途必要だとすると、これで複数サービスになってしまう。
アプリケーションという概念は、様々なサービスの組み合わせが本質だから、可搬性を考えても、それらをワンコンテナに組み込むのが自然だと思う。
即ち、データベースとwebサービスは同一コンテナにしてもよいでしょということになる。
上下前次1-新書関写板覧索設栞歴
あと 350 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.022s