[過去ﾛｸﾞ] Docker Part4 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
622(1): 2020/11/03(火)22:16 ID:M5SiUIu9(1) AAS
むしろVMの方が楽まである
623: 2020/11/03(火)23:10 ID:SU13O3bL(7/8) AAS
>>622
メモリ食うから仮想マシンは無理
>>621
Dockerのボリュームとか、イメージとか、
ネットワークとか、便利なのでなあ。
LXCは古い技術でしょ。やりたいことができなかったらと思うとわざわざ使う気になれないなあ。
624: 2020/11/03(火)23:14 ID:SU13O3bL(8/8) AAS
>>621
CentOS7イメージだとprivilegeコンテナにすれば仮想マシンぽく運用できた。
でも、CentOS6イメージだとそういうわけには行かなかった。
こういう場合には、LXCというのを使うのが良いのかなと思っています。
625: 2020/11/04(水)00:26 ID:5EaF6Elr(1) AAS
Dockerのマウント3種類についてわかったことをまとめる
外部ﾘﾝｸ:qiita.com
Volumes、bind mounts、tmpfs mounts について
626(3): 2020/11/04(水)00:46 ID:8vCtX8KM(1/10) AAS
ホストディレクトリをコンテナにマウントする場合も、Dockerボリュームを複数コンテナで共有する場合も、排他同時アクセス機能はないんでしょ？
それができたら、ファイルサーバ機能を別コンテナに切り分けたりできるのになあ。
627(1): 2020/11/04(水)01:03 ID:8GrlF7V6(1) AAS
誰かDocker Certified Associate受けたことある人おらん？
英語あんまり自信ないんだが、問題文の英語どのくらいの難易度か教えて欲しい
628(2): 2020/11/04(水)01:10 ID:7tuD0WTP(1/4) AAS
>>620
便利なんだろうけどIaaCとは全然違うような？
メモリ、ストレージは節約できるだろうけどインフラの構築手順をコード化
して共有するという、コンテナ化の元の理念は死んでる気がする。
別に原理主義ではないけどな。属人化の部分が解消されない気はする。
629(1): 2020/11/04(水)01:23 ID:aRkKqxcc(1/4) AAS
Linuxのシェル変数$USERを
Dockerfileの中でのみ使う方法を教えてください
${USER}とか$USERでは取れませんでした
ARG USER=$USER
とか
ARG USER=${USER}
もだめでした
630(1): 2020/11/04(水)01:37 ID:7tuD0WTP(2/4) AAS
>>629
そもそもここで使いたいと期待するUSER変数がdocker buildを実行するホスト側
のユーザーなのか、コンテナ側なのか分からないんだが・・・
631: 2020/11/04(水)01:37 ID:aRkKqxcc(2/4) AAS
>>630
ホスト側です
632(1): 2020/11/04(水)01:46 ID:7tuD0WTP(3/4) AAS
引数に渡してENVにあげる。
外部ﾘﾝｸ:vsupalov.com
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サービスは同一コンテナにしてもよいでしょということになる。
653: 2020/11/04(水)12:34 ID:8vCtX8KM(10/10) AAS
>>647
ストレージサービスだと、iSCSIも含んでしまう。
排他制御ができるファイル単位サービスということで、オンライン共有サービスと言った。
654(3): 2020/11/04(水)12:38 ID:3mo/cajL(1/4) AAS
>>626
ホストの同一ディレクトリを複数コンテナでマウントするだけでしょ
排他もかかるよ
655: 2020/11/04(水)12:41 ID:5mpefc2R(1/18) AAS
>>652
その考え方で概ね正しいよ
好例としてGitlabのオフィシャルコンテナも1コンテナにすべてのサービスを詰め込んで1コンテナ：マルチサービスで動かしている
そして内部的な構成管理ツールとしてChefを使っている
これは1コンテナ：1プロセスという無意味なプラクティスには反するが現実として非常にうまくいってる
ただしこの構成だと特定のコンテキストやレイヤーを抜き出してそれだけスケールアウトするのが難しくなる
デメリットはせいぜいそれぐらいしかない
656: 2020/11/04(水)12:45 ID:3mo/cajL(2/4) AAS
よく言われるのは1プロセスじゃなく1サービスだろ
WebとDBで完結して1サービスと見なせるなら分ける必要ないよ
Webを複数にして負荷分散等する予定があるとか
DBをデータマート的に多目的に使う奈良分けた方が柔軟だろうが
657(1): 2020/11/04(水)13:10 ID:g/DLzKYE(2/3) AAS
mysqlとかphpmyadminとか既存のDockerイメージあるじゃん？
なのにわざわざ苦労して手動インストールして
1つの複雑なDockerイメージにする理由がない
658: 2020/11/04(水)13:26 ID:QtKCHGIC(5/5) AAS
>>652
> 即ち、データベースとwebサービスは同一コンテナにしてもよいでしょということになる。
する理由がない
複数コンテナを結合できるのに、一体化させる理由がないんだよね
複数コンテナをつなげるのは簡単だが、一つになってるものは分離できない
659(1): 2020/11/04(水)14:17 ID:5mpefc2R(2/18) AAS
・複数のコンテナをオーケストレーションしないと使えないサービス
・コンテナ1個動かせばOKなサービス
どっちが楽なのかは自明だろ
660: 2020/11/04(水)14:18 ID:5mpefc2R(3/18) AAS
更に既存資産があれば作るのも楽々だ
わざわざ労力をかけてDockerfileに書き直す？
ハァト…無駄な努力
661(1): 2020/11/04(水)14:21 ID:1buxXrD8(2/3) AAS
>>659
docker -composeも使えない猿未満の方？
662(1): 2020/11/04(水)14:31 ID:1buxXrD8(3/3) AAS
DBは本番だと別サーバーな事も多い
メインのDockerイメージに含まれてても容量が大きくなって邪魔なだけ
DBは自分で用意するから余計なお節介はやめろ
DBだけAWS RDS使いたければ、
元から別コンテナだったら本番で構成に含めなければ済む話
なぜsupervisordとか使って複雑にする必要がある？
663: 2020/11/04(水)16:03 ID:ZKU6KPhr(1) AAS
流行ってるからでぇ〜すｗｗｗ
たいがいこんなもんだろ
664(1): 2020/11/04(水)17:44 ID:5mpefc2R(4/18) AAS
>>661
なぜ使える使えないという個人のスキルの話に脱線するのか意味不明だよ君
dockercomposeを使わなくても簡単に動かせるならそちらのほうがいい
より簡単な方はどっちなのか？
答えは誰でもわかる、単一コンテナのほうが簡単
665(1): 2020/11/04(水)17:46 ID:5mpefc2R(5/18) AAS
>>662
ケースバイケース
既存資産があるなら1つにまとめてしまったほうが楽な場合がある
Gitlabのように戦略的に単一コンテナを選ぶ場合だってある
何でもかんでも分割すりゃいいってもんじゃない
666(1): 2020/11/04(水)17:49 ID:YAhpIihL(1/12) AAS
>>664
論理的じゃない
簡単に動かせるならそちらのほうがいい・・・とは限らないだろ
667(1): 2020/11/04(水)17:50 ID:YAhpIihL(2/12) AAS
>>665
分割したほうが再利用しやすいという話だ
668: 2020/11/04(水)17:54 ID:5mpefc2R(6/18) AAS
>>666
いやいや
同じ機能が手に入るなら簡単であればあるほどいい
難しい構成が許されるのはそれに見合う目的が必要
つまりデフォルトは限りなくシンプルに簡単に
細かくチューンナップしたいなら難しい構成を許可する
という順番がある
最初から難しい構成を押し付けるのはクソ製品
669(1): 2020/11/04(水)17:55 ID:YAhpIihL(3/12) AAS
> 同じ機能が手に入るなら簡単であればあるほどいい
自分で答え言っちゃってるわなｗ
「同じ機能が手に入らない」ので
言ってることが論理的ではない
670: 2020/11/04(水)17:57 ID:5mpefc2R(7/18) AAS
>>667
そうとも限らない
Gitlabコンテナは世界中で再利用されている
再利用するのにまったく困ることがない
もし仮にGitlabコンテナを構成するサービスが別のコンテナになっていたらオーケストレーション構成を考えるのが面倒で再利用に余計な手間がかかってしまう
671(1): 2020/11/04(水)17:59 ID:YAhpIihL(4/12) AAS
× Gitlabコンテナは世界中で再利用されている
○ GitLabサービスは世界中で利用されている
一番簡単なのは GitLabサービスなのだ
672: 2020/11/04(水)17:59 ID:5mpefc2R(8/18) AAS
>>669
はぁ
くだらない揚げ足取り
673: 2020/11/04(水)17:59 ID:5mpefc2R(9/18) AAS
>>671
話をそらすな
674(1): 2020/11/04(水)18:00 ID:YAhpIihL(5/12) AAS
そらしてないなぁ
データベースが一体化していれば
GitLabサービスの運営は大変だろう
675: 2020/11/04(水)18:03 ID:5mpefc2R(10/18) AAS
Gitlabは本当によくできている
デフォルトでは単一コンテナで最小のパラメーター設定だけで動かせるように作られてる
その上で内部サービスをオミットして別のコンテナに分割することもできる
そうする必要もないのにデフォルトの構成を複雑化させたがるバカはGitlabコンテナを見習ってほしい
676: 2020/11/04(水)18:05 ID:5mpefc2R(11/18) AAS
>>674
そらしてる
今はGitlabコンテナの話をしてる
Gitlab.comのサービスの話はしてない
677(1): 2020/11/04(水)18:15 ID:YAhpIihL(6/12) AAS
だから大抵の人にとって一番簡単なのはGitLabサービスを使うことだろ
それに対してデータベースを別でバックアップしておきたいって人にとっては
データベースは分離されていたほうがいいし
678(1): 2020/11/04(水)18:15 ID:wKYTl7Ay(1/2) AAS
>>654
ボリュームを複数コンテナでマウントするだけでは排他制御されない。
ホストディレクトリをコンテナにマウントしても同様に排他制御はかからないのではないか
679: 2020/11/04(水)18:17 ID:wKYTl7Ay(2/2) AAS
>>657
可搬性が理由だと思う。
680(1): 2020/11/04(水)18:18 ID:YAhpIihL(7/12) AAS
GitLabは全部一緒くたになってるから
間違ってコンテナを消してしまうとデータまで消えてしまう
データのバックアップも大変
安心して運用なんてできないよ
681(1): 2020/11/04(水)18:19 ID:5mpefc2R(12/18) AAS
>>677
またトンチンカンなことを
Gitlabサービスを使う話はしてない
コンテナの構成として1コンテナマルチサービスの是非を議論しているのにマネージドサービスと比較してどうすんだよ
本当に意味不明だよ君
今の話の大前提は「DockerでGitlabをセルフホストする」ことだ
マネージドサービスの話がしたいならスレ違いだからさっさと別のスレにいけ
682(1): 2020/11/04(水)18:19 ID:YAhpIihL(8/12) AAS
>>654
排他制御の意味が違ってる。
例えばMySQLを2つ起動したとして、同じディレクトリを
参照していたらデータが壊れるだろ
ファイルは壊れなくてもデータが壊れる
683: 2020/11/04(水)18:20 ID:i96Niluf(1) AAS
github使わずにgitlab使うのは自社サーバで運用したいケースが多いんじゃね
マイクロソフト資本を嫌悪したケースもあるかも知らんが
あとデータベースのバックアップは基本的にコンテナやボリューム単位ではなくて
データベース純正のバックアップ手段使うケースが多いと思うよ
684(1): 2020/11/04(水)18:21 ID:YAhpIihL(9/12) AAS
>>681
> 今の話の大前提は「DockerでGitlabをセルフホストする」ことだ
ほらなｗ また条件つけた。
つまりこいつにとっての「使いやすい」の基準は
「DockerでGitlabをセルフホストする」場合の話であって
誰かのためにサービスを運営する（つまりGitLabサービス）のようなものには
当てはまらないということだ
開発者なら「誰かのためにサービスを運営する」だろ？
685: 2020/11/04(水)18:24 ID:5mpefc2R(13/18) AAS
>>680
間違って消しちゃたら困るのは纏めてようが分けてようが同じ
バックアップはgitlabのコマンドラインツールを使う方法、ボリュームをバックアップする方法がサポートされている
いずれの場合も、対象が1つのコンテナにまとまってるから簡単にバックアップできる
もし、これが複数のコンテナに分量外していたら、それぞれのコンテナについてバックアップを考えなければならないので大変だ
686(1): 2020/11/04(水)18:25 ID:YAhpIihL(10/12) AAS
> バックアップはgitlabのコマンドラインツールを使う方法、ボリュームをバックアップする方法がサポートされている
はいそれなｗ
「一つにまとめたほうがいい」という方針の結果がそれだよｗ
そういう方法を自分で作らなければいけなくなるということ
データベースが分離されていれば、一般的なやり方がそのまま使える
GitLabに依存してないからだ。しかし一つにまとめた結果そのやり方が使えなくなり
そういうツールを開発しなければいけなくなった
687(1): 2020/11/04(水)18:26 ID:5mpefc2R(14/18) AAS
>>684
条件を付けた？
最初からこの条件で話してたらお前がマネージドサービスとの比較などというズレまくったトピックを持ち込んできたんだろ
いい加減にしろ
688(1): 2020/11/04(水)18:28 ID:YAhpIihL(11/12) AAS
>>687
お前は他人が用意したものを使うだけの話をしてるが
こちとらDockerfileを「作る側」の話をしてるんだよ
それはGitLabサービスと同じ立場だ
一つにまとめれば作るのが簡単？
GitLabのバックアップの件からも特殊なツールの開発が
必要になるってことがわかったよなｗ
689: 2020/11/04(水)18:29 ID:5mpefc2R(15/18) AAS
>>686
考えが浅すぎてため息しかでない
なにが一般的な方法が使えるだよ
Gitlabの管理するデータはDBだけじゃない
リポジトリデータやその他のサービスのデータも管理してる
これらを個別に管理したら大変だよ
個別に簡単に管理できるならGitlabはわざわざバックアップコマンドを用意したりしねーよ
少しは考えろ
690: 2020/11/04(水)18:33 ID:5mpefc2R(16/18) AAS
>>688
作る側ならより慎重に使う側の都合を考えろよ
使う側に知識と労力を期待するのは三流の開発者だ
Gitlabの開発者はdocker runさえ知ってればGitlabを動かせるように整備した
これが一流の開発者だ
691(1): 2020/11/04(水)18:34 ID:YAhpIihL(12/12) AAS
ああ、使う側って自分で開発したアプリでサービスを運営するって考えがないのかｗ
いやはや、考えが浅いなぁ
692: 2020/11/04(水)18:42 ID:5mpefc2R(17/18) AAS
>>691
利用形態は外向けサービス運営だけじゃない
むしろサービス運営のほうが圧倒的に少数派
どんな企業でも開発用の社内システムを持ってるがサービス運営をしているとは限らない
社内システムでは導入の手軽さと運用コストがまっさきに検討される
こんなことにすら考えを巡らせられないのか？
浅い
浅すぎる
693: 2020/11/04(水)18:45 ID:5mpefc2R(18/18) AAS
自分たちで作って自分たちだけで消費してるから不特定多数にイメージを使ってもらうという想定ができないんだろうな
閉じた世界で考えてるからとにかく浅い
694: 2020/11/04(水)19:02 ID:aUQpvtzl(1) AAS
自分が浅いことがバレて必死になってるなｗ
695: 2020/11/04(水)19:05 ID:7ED4Lec/(1) AAS
おや
ついに反論できなくなったようだな
勝負あり
696: 2020/11/04(水)19:14 ID:g/DLzKYE(3/3) AAS
GitLabの公式イメージが気に入らなければ
k8sでHelmチャート版使うか非公式の方入れたら良い
外部ﾘﾝｸ:github.com
既存のPostgreSQLとかRedisを使いたい！って要望に答えられないので
こういうものが作られる当然ではある
SMTPサーバーは流石にごった煮版の方もない
こればかりは一つのコンテナ内でどうにかならないからか
別にSMTPサーバー立てたり外部サービスを利用が必要
697: 2020/11/04(水)19:23 ID:7Ele+Ilf(1) AAS
公式もDB外付けできますよ
698: 2020/11/04(水)21:35 ID:aRkKqxcc(3/4) AAS
番号確認用テスト
699(1): 2020/11/04(水)21:36 ID:aRkKqxcc(4/4) AAS
>>632
ありがとうございます！
ちなみにもう一つ質問なんですが
シェル変数に渡せないことがあるんですが全てのシェル変数には対応できないんでしょうか？
$UIDとか
700: 2020/11/04(水)22:08 ID:3mo/cajL(3/4) AAS
>>678
試して言ってるんだけど
701(1): 2020/11/04(水)22:09 ID:3mo/cajL(4/4) AAS
>>682
排他ロックがかかるという意味で言ってる
702(2): 2020/11/04(水)22:39 ID:PYTTHrMi(1) AAS
>>699
UIDやGIDが何ものであるか、考えてみてください。
703: 2020/11/05(木)00:32 ID:fiw9R+Nw(1/8) AAS
>>701
通常ディレクトリでも、libreOfficeでファイルを開けばロックファイルが作られる。
アプリケーションレベルでのみロックが掛けられると思う。
viでも編集中のファイルは、ロックファイルが作られるよね。
Dockerボリュームとか、ファイルシステムレベルでのロックなんてそもそもなかったのではないか？
704(2): 2020/11/05(木)07:26 ID:I+aaEHF/(1/2) AAS
ボリュームなんてただのディレクトリでしかないのに何いってんだ
カーネルを共有してるにどうやって
ファイルシステムのロックを回避するっていうんだよ
Dockerは仮想マシンじゃねーよアホ
705: 2020/11/05(木)07:27 ID:I+aaEHF/(2/2) AAS
>>702
> UIDやGIDが何ものであるか、考えてみてください。
ただの環境変数です。
706(2): 2020/11/05(木)07:32 ID:3ZkEmE9Q(1) AAS
>>654
何のアプリケーションを試してるんだから知らないが
それDockerとか関係なく複数のプロセスから同じファイルを触らせてるだけだろ？
排他制御がどうなるかは動かしてるアプリケーションの仕様による
Docker関係ない
707: 2020/11/05(木)07:34 ID:PZkmWwSI(1) AAS
>>706
>>626に言えよ
708: 2020/11/05(木)09:30 ID:fiw9R+Nw(2/8) AAS
>>704
ファイルシステムのロックってなんのこと？？
709(2): 2020/11/05(木)09:59 ID:fiw9R+Nw(3/8) AAS
>>706
ボリューム使ってコンテナ間でふを共有しても、
排他制御されないらしい
外部ﾘﾝｸ:www.digitalocean.com
but there’s one critical caveat: at this time, Docker doesn’t handle file locking. If you need multiple containers writing to the volume, the applications running in those containers must be designed to write to shared data stores in order to prevent data corruption.
ファイルオープンしているときに、
別のコンテナからファイルに変更を加えられるということだよね。
コンテナは、確か、同じカーネルで動作しているけど、リソースを分けるように名前をわけているらしい。
ファイルハンドラーも分けられているに違いない。
なので、ローカルマシンで同じファイルシステムに複数プロセスがファイルにアクセスするシナリオとは異なっているのだと思う。
710: 2020/11/05(木)10:00 ID:fiw9R+Nw(4/8) AAS
>>704
>>709を参照してほしい
711: 2020/11/05(木)10:18 ID:fiw9R+Nw(5/8) AAS
>>709
いや、ファイルハンドラーのくだりでおかしいこと言ってるな
勘違いしたわ。
結局、一つのカーネルがファイルシステムをとりあつかっているから、
ボリュームでコンテナ間でファイルを共有しても、
それはコンテナ使わない通常の状況において複数プロセスがファイルにアクセスできるのと同じことになるのかな。
712(1): 2020/11/05(木)12:48 ID:xIltC13o(1/3) AAS
初心者なんだけど、WindowsにDockerインストールして、DockerでCentOSのコンテナを起動、そこから、nginxとかpythonとかのコンテナを使いたいんだけど、そういう事出来るんでしょうか。
CentOSの80番に来たのをnginxのコンテナに飛ばして、更にpythonのコンテナに飛ばして処理、とか。
CentOS上にDockerをインストールして、そこからnginxのコンテナを置くとかの形になるんでしょうか。
713: 2020/11/05(木)12:53 ID:/PyhrE0E(1/4) AAS
> DockerでCentOSのコンテナを起動、そこから、nginxとかpythonとかのコンテナを使いたいんだけど、
意味不明ｗ
Dockerのコンテナ＝アプリ
つまり「Windowsでnginxアプリを使う」だけの話
そのnginxアプリっていうのが、内部でDockerを使ってるかもしれないし使ってないかもしれないが
nginxアプリをつかつ人にとってはどうでもいいことだ
714(1): 2020/11/05(木)13:01 ID:/PyhrE0E(2/4) AAS
Dockerっていうのはな、アプリを作るためのものなんだよ
もちろん誰かが作ったアプリを使うだけのやつも居るが
本来はアプリを開発するために使うもの
例えばお前が作ったアプリがWindows上でそのまま動くか？
Linux上で動かすことを想定して作ったアプリだと動かないだろ？
Dockerを使えば、そういうアプリがWindows上でも動くということ
なぜならアプリを動かすのに必要なものが全てコンテナに含まれているから
コンテナに含まれていないのはLinuxカーネルだけだが、そのLinuxカーネルは
Docker for Windowsが提供している。（WSL2を使う場合はWindowsが提供しているLinuxカーネルを使う）
715: 2020/11/05(木)13:08 ID:PGgKBof2(1/2) AAS
>>712
Docker in dockerかDocker outside of dockerというテクニックを使えばコンテナからコンテナを扱うことができるが
君が本当にやりたかったことはおそらくただのdocker composeだろう
716(2): 2020/11/05(木)13:14 ID:/PyhrE0E(3/4) AAS
いつものDockerを仮想マシンと勘違いしてるやつだろ
Dockerコンテナには原則としてログインしない（デバッグのときぐらい）
アプリにログインとかするか？それぐらい意味不明な行為
717: 2020/11/05(木)13:17 ID:PGgKBof2(2/2) AAS
>>716
devcontainerを使ったことないのか
718: 2020/11/05(木)13:23 ID:fiw9R+Nw(6/8) AAS
>>716
それは言い過ぎ（とうぜん、アプリにsshログインなんてしない。）
アプリを取り巻いている環境がコンテナにあるわけで、
それを調べるためにsshログインすると便利
719(2): 2020/11/05(木)13:27 ID:xIltC13o(2/3) AAS
なるほど。
つまり、全体として一つの目的を果たすアプリを構築するモノであって、細かいコンテナを結合して使うような形はあまり想定されていないと。
やる場合はdocker composeが一番イメージに近そう。
こちらの想定としては、例えばpython2の実行環境が本番で動いているとして、その周りの環境はそのままに、pythonを2から3の実行環境へと入れ替え（ここをコンテナの入れ替えをするイメージでした）して、実際に全体として動くのかと言うような形の検証が出来ればいいなと考えていました。
この場合、python3ではうまく動かないなとなれば、python2のコンテナにつなぎ直せばゴミも残らず即元通りになると思いましたので。
720: 2020/11/05(木)13:29 ID:aPKS8bQV(1) AAS
いつものアレなのでスルー推奨
721: 2020/11/05(木)13:44 ID:0fHUxX44(1) AAS
よく飽きねぇな
722: 2020/11/05(木)13:45 ID:7JWgbSNJ(1) AAS
次スレはワッチョイかip頼む
723: 2020/11/05(木)13:47 ID:fiw9R+Nw(7/8) AAS
>>719
python2用コンテナと、
python3用コンテナを用意する。
というか、paython2も3も同一マシンに同時に導入できたんじゃ？
724(1): 2020/11/05(木)16:43 ID:/PyhrE0E(4/4) AAS
>>719
そういう使い方ではない
Dockerは「実際に全体として動くのか」の「全体」を作るもの
つまり「Python2を使う全体」と「Python3を使う全体」を
Dockerfileの内容を元にそれぞれ作る。
念の為。それぞれの中にはDockerは入ってないぞ。
Dockerfile（手順）を実行してDockerイメージを作るのがDockerで
さらにできたDockerイメージを動かすのがDockerだ
725: 2020/11/05(木)18:56 ID:nb4htb8e(1) AAS
>>702
なぜUIDだとダメなのでしょうか？
726(3): 2020/11/05(木)20:49 ID:JL2sRUYB(1) AAS
>>627だけど、やっぱり誰も受けてない？
727: 2020/11/05(木)21:45 ID:xIltC13o(3/3) AAS
>>724
今やっと(多分)正確に理解出来ました。
つまり、「nginxのコンテナ」や「python2のコンテナ」の中にも、(乱暴な言い方をすれば)CentOSが入っているということですね。
>>714を参考にすれば、kernelだけは含まれず、そこは別でDockerなりWindowsなり、ホスト側の環境に依存する形で利用される、と。
とすると、docker compose等で3306はMySQLコンテナに飛ばす、と言った話は、こちらも乱暴な言い方をすれば、WEBサーバとDBサーバが2つ立っていて、そのサーバ間で通信を行うイメージになるわけですね
728: 2020/11/05(木)22:44 ID:kRAtqvcg(1/2) AAS
>>726
試しに受けてみようかなと思ったら195ダラーに引いたｗ
たった55題でその値段とか冗談でしょ。
729: 2020/11/05(木)22:49 ID:fiw9R+Nw(8/8) AAS
>>726
資格持ってるやつほどできなさそう
発想ゼロで創造性なさそう
730: 2020/11/05(木)22:58 ID:kRAtqvcg(2/2) AAS
外国のベンダー試験は死ぬほど実務的。
勉強して役に立たないという事は基本ない、という印象。高いけど。
ただdocker自体コンテナランタイムとしてどうよ？って気がする。
Docker swarmとか別に知りたくもないし。
731(2): 2020/11/05(木)23:18 ID:zb/W11IL(1) AAS
前から言ってんじゃんこれからはpodmanだって
dockerはレジストリとしての価値も危ぶまれてるまじオワコンよ
732: 2020/11/05(木)23:34 ID:TdGXrpVR(1) AAS
> これからはpodmanだって
podmanになったらまた来てくれ
これからはと言ってるやつの99%は外れだから
733: 2020/11/06(金)00:31 ID:P7wMRRj0(1/6) AAS
Docker は、namespace, cgroup, overlayfs を使っている。
本質は使い捨ての、immutable
仮想OS じゃないし、Docker Compose も、実システムとして使えない。
実システムは、AWS などのKubernetes
734(1): 2020/11/06(金)00:37 ID:s01/YDPr(1/5) AAS
>>731
podmanになるかは知らないけどDockerが何かに置き換えられるの可能性はあるだろうね。
DockeはDockerデーモンがネットワークを奪い取っちゃうのがイマイチなところ。
run -p 80:80 と書けるのは一見便利な様でコンテナランタイムでしかない筈のDockerプロセス
が標準ポートに対する攻撃を一人で引き受けることになる。
オマケにk8sとか上位からコンテナランタイムを制御したいシステムとネットワークが干渉して
邪魔になる。
735: 2020/11/06(金)00:50 ID:P7wMRRj0(2/6) AAS
Python の環境構築なら、YouTube のキノコードの動画を参照！
【Bash】Windows Subsystem for Linux【WSL】8
2chｽﾚ:linux
736(3): 2020/11/06(金)01:48 ID:T6MZgdki(1) AAS
play with dockerで簡易cgiローカルサーバー動かそうと思ったけど
起動はしたもののどこに接続していいのかわからない
$ vim index.html
$ mkdir cgi-bin
$ vim cgi-bin/sample.py
$ docker pull python:3.7-slim
# $ docker images
$ docker run -itd -v /root:/var/www/html [イメージID] bash
# $ docker ps -a
$ docker exec -it [コンテナID] bash
コンテナ内bash
$ cd var/www/html
$ python -m http.server --cgi 8000
これで一応サーバーは動いたっぽいものの
play-with-dockerのOPEN PORTボタンからアクセスしてもページが無かった
（自分のPCからだとコンテナに割り当てられたローカルホストのアドレスからきちんとアクセスできた）
737(3): 2020/11/06(金)02:48 ID:P7wMRRj0(3/6) AAS
Ruby なら、コマンドプロンプト・PowerShell から、1-liner で、
Rubyで作られた遅いウェブサーバー、WEBrick が起動する
ruby -run -e httpd . -p 8080
そのフォルダに、index.html があれば、これでブラウザからアクセスできる
外部ﾘﾝｸ:localhost:8080
ローカル回線だけでしょ。
ひょっとして、外部からアクセスさせるの？
外部なら、AWS のKubernetes, VPC のインターネット・ゲートウェイとか
738: 2020/11/06(金)02:51 ID:W98uQtEe(1) AAS
compose使ってるんだけど毎回cdするの面倒くさい
ymlを登録するなりしてショートカット出来ないの？
739(1): 2020/11/06(金)03:07 ID:s01/YDPr(2/5) AAS
>>737
回答がお門違いやな。"play with docker"って言ってるでしょ。
でも>>736のやり方じゃnginx とpythonを別々に動かしてるだけだから
アクセスは出来んわな。pythonとnginxをセットにしたイメージをdockerhubから
探すしかないんじゃね？
740: 737 2020/11/06(金)03:38 ID:P7wMRRj0(4/6) AAS
外部に公開するのは、
BB ルーターのポートフォワーディング・ポートマッピング・静的IP マスカレードの設定とか、
ファイアウォールのufw, netsh とか
でも、素人が公開すると、すぐに乗っ取られるw
ssh で、リモートログインの方が安全
741: 737 2020/11/06(金)03:43 ID:P7wMRRj0(5/6) AAS
nginx, python の組み合わせは、珍しい。
普通は、web サーバーと、フレームワークの組み合わせ
nginx, Ruby on Rails とか、
Apache, WordPress とか
742(1): 2020/11/06(金)08:55 ID:Xq/Lj6my(1) AAS
>>726
ググってみたが、資格のページ無くないか？
743: 2020/11/06(金)09:35 ID:Pu2vwu4g(1/2) AAS
podman 見た感じだとわるくないんだけど、Red Hat のかじ取りというかやり方が微妙であんまり流行らないだろうなとは思う
744(1): 2020/11/06(金)10:14 ID:p0uOIOHq(1/2) AAS
pythonでdjangoとか使いますし
nginxと組み合わせるなんて珍しいとは思いませんよ
745(1): 2020/11/06(金)10:17 ID:4r/vlmbk(1/3) AAS
>>734
> podmanになるかは知らないけどDockerが何かに置き換えられるの可能性はあるだろうね。
当たり前だろ。「いつまでに」って期限をつけないならいつかは置き換えられる。
Linuxだって置き換わるだろ。100年後、200年後までLinuxのままだとは思えない。
746: 2020/11/06(金)10:32 ID:s01/YDPr(3/5) AAS
>>742
外部ﾘﾝｸ:prod.examity.com
にある。アカウント作ったら入れる。トラブったらチャットの人が即座に解決してくれる。
747(1): 2020/11/06(金)10:35 ID:s01/YDPr(4/5) AAS
>>745
そういう非現実的な話はしてないな。
デーモンじゃマズイ、と言っているんだからその問題が無視できくなれば
置き換わるだろ、と言うか自分たちが作ってるクラスタは置き換わってるし。
（あるバージョンからコンテナランタイムのDockerが消えた）
748: 2020/11/06(金)10:37 ID:s01/YDPr(5/5) AAS
>>744
まあそうだよね。
nginx+pythonで珍しいとか意味が解らんね。
上下前次1-新書関写板覧索設栞歴
あと 254 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.039s