[過去ﾛｸﾞ] Docker Part3 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
414: 2019/12/01(日)23:20 ID:YiJOHqAn(2/4) AAS
> VMに関する全ての操作はやってられないとｗ。
VMは関係ないと言ってるのに、またVMの話を持ち出す。
全ての操作はやってられないなどと俺は言ってない。全部>>412の思い込み。
415(1): 2019/12/01(日)23:41 ID:Y8NJ61TV(1) AAS
Ruby 製のVagrant の作者、HashiCorp のMitchell Hashimoto は、今世紀最大の起業家！
今は、Go 製のTerraform, Packer を作っている
彼が時代の中心だから、彼についていけばよい
他には、CircleCI, GitHub Actions
416: 2019/12/01(日)23:55 ID:YiJOHqAn(3/4) AAS
> おれはお前以外の人の書き込みからそれを学んで、心から納得したよ。
ようやくVMとDockerは使い方が違う。組み合わせて使うものと理解したようだが
お前のその書き込みは「お前から学んだということは認めたくない」と言うためだけの書き込みだなｗ
「組み合わせて使う」と書き込んでるのはたいてい俺だと思うけど、
俺以外の書き込みから学んだとは、一体どの書き込みから学んだんだろうか？
指摘してみてほしいところだが、ま、いえないよなぁｗ
417(1): 2019/12/01(日)23:59 ID:YiJOHqAn(4/4) AAS
>>415
CircleCIもGitHub ActionsもDockerベース
CircleCIは2.0でDockerベースに変わったし、
GitHub Actionsは以前はDockerfileが必須だった。
Packerも随分前からDockerイメージを作れる
（Packerはしばらく使ってないが、dockerのキャッシュ使うようになった？
正直これができないと、使い物にならないレベルなんだけど）
Terraformはすまんね。知らない。
世の中Dockerだらけｗ
418: 417 2019/12/02(月)00:04 ID:iQ/jQknl(1) AAS
VagrantはVirtualBoxがHyperVと共存できないから使うのやめたな。
Vagrant+HyperVという使い方ができるのは知ってるけど、
WSLができてWindowsがLinux同等に使えるようになったから実機で必要十分になった。
（Macはもとより実機で開発。もちろんDockerはWindowsでもMacでも使える。）
わざわざ開発マシン（実機）の中に、別の開発マシン（VM）を作るという二重構成にする必要がない。
419: 2019/12/02(月)09:24 ID:UZ4iaYjq(1) AAS
Windowsでdocker自体を動かすのには
さすがに仮想マシンが必要
ホストOSもLinuxなら要らない
Docker for WindowsはLinux使うからHyper-Vが必要
WSL2もHyper-Vを利用する
WSL2は必要なHyper-V機能の一部がHome Editionにも配布されるので
Homeでも利用可能になる
仮想マシンを利用する方式に変更した事で
WSL1では動かなかったdockerもWSL2では使えるようになった
420: 2019/12/02(月)15:23 ID:cX5TDnkz(1) AAS
GAFAMは普通にDockerの考え方に順応して使ってるよな
最近出てきた訳でもない
登場してかなり経つ安定した技術なのに
まだ全く使ってないというのは流石に頭硬すぎ
421: 2019/12/02(月)21:16 ID:nGJwV5Oa(1) AAS
GoogleはDockerが登場する前からコンテナ使ってたらしいしな
そういう所は今、一日に何十回（何百回？）もデプロイしてる。
古いやり方、多くても一ヶ月に一回、一週間前までにデプロイ計画立てて
サービス停止して深夜作業でデプロイするようなやり方では到底無理
顧客も賢くなってきてるから、丁寧にやってるから遅いんですよとかいう
言い訳はもう通じなくなってる。
みんながコンテナ使ってる中、あなたはコンテナ使わずに
同じぐらいの速度で開発ができますか？ってことだよ。
422: 2019/12/03(火)00:34 ID:tig7/aUP(1) AAS
オフラインで使う組み込み系だと開発環境構築をちょっと楽するぐらいしか使い道ないわ
423: 2020/01/04(土)16:07 ID:IuViAdEQ(1/2) AAS
1. あるマシンに他ユーザーから隠しておきたい秘密情報のファイルがある
2. rootから隠すことはできない。
3. だから他ユーザーはrootになったりsudoが使えてはいけない。（自分はなって良い）
4. ユーザーがdockerを使えるということはrootの権限があるのと同じことである
（例えばボリュームを使えば、どのディレクトリも読み書きができる。）
5. dockerグループに追加してdockerコマンドの実行にsudoを不要にした所でそれは変わらない
以上のことから、あるマシンに他ユーザーから隠しておきたい秘密情報がある場合は
そのマシンで他にdockerが使えるユーザーがいてはならない
言い換えると、自分以外のdocker使用者がいる場合はそのマシンに秘密情報を置くことができないので
「秘密情報を置いて安全に管理してる」ならば「他に自分以外のdocker使用者がいない」を意味する
省1
424: 2020/01/04(土)16:20 ID:IuViAdEQ(2/2) AAS
dockerサーバーがリモートにある場合がよくわからないんだよな
マシンAとマシンBがあってそれぞれ所有者は異なる。
dockerサーバーがリモートにあって
マシンAとマシンBの両方から接続する
ん？ローカルのディレクトリってリモートマシンのボリュームにできるの？
マシンAがdockerサーバーでコンテナを作ったとして、
マシンBが同じdockerサーバーに接続したらそのコンテナは見えてしまうのか？
つまりdocker execで乗り込めてしまうのか？
もしできてしまったら、マシンAが渡したボリュームにたいして
マシンBから読み書きできてしまう？
省1
425(2): 2020/01/04(土)23:16 ID:4WXnY3BD(1) AAS
ローカルをリモートのボリュームには通常できないでしょう。
426: 2020/01/05(日)09:23 ID:sWW1tNjy(1) AAS
>>425
NFSやらSMBやらで共有するという話ではなくて？
427: 2020/01/05(日)16:26 ID:PM+h1CUF(1) AAS
>>425
そのとおりでした。なんか勘違いしてましたね。
つまりはDockerサーバーにアクセスできるユーザーは
そのDockerサーバーが動いているマシンのroot権限を
持ってるのに等しいと理解しました。
だから例えばCIサービスとかを作るとして、複数の人が同じサーバーで
コンテナを動かす場合、Dockerに直接接続させてはならないわけですね。
ウェブインターフェースやRESTインターフェースをもたせて
そこで認証かけて、やれることも制限しろと
428: 2020/01/05(日)18:41 ID:6QavSJIx(1) AAS
root持ってりゃdocker停止もアンインストールもOSシャットダウンもできるわけなので
429(2): 2020/01/05(日)21:24 ID:p4jkzryR(1/3) AAS
docker composeがルート権限必要だから、AとBでコンテナ作れたらどちらでもなんでもありになる。
430: 2020/01/05(日)22:06 ID:9zcJiqAl(1) AAS
あれ非特権モードでも？
431: 429 2020/01/05(日)22:28 ID:p4jkzryR(2/3) AAS
Docker19.03からルート権限不要モードが追加されたんだな。>>429は誤情報。
432: 2020/01/05(日)22:30 ID:IPuUazgK(1/3) AAS
ルート権限が不要ってだけで
同じdockerサーバーに接続してるユーザー同士で
隠し事はできないよね？
433: 2020/01/05(日)22:44 ID:IPuUazgK(2/3) AAS
あるユーザーがDockerを起動して
同じホストの他のユーザーはそのDockerに接続できるのだろうか？
接続できてしまったら、あるユーザーのファイルは読み書きし放題？
上下前次1-新書関写板覧索設栞歴
あと 569 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.027s