[過去ﾛｸﾞ] 仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net (962ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1: 2017/02/16(木)18:01 ID:rGWDv0Eb(1) AAS
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう
よろしこ
836: 2019/08/03(土)12:03 ID:eOXqQaf9(1/21) AAS
なんでもかんでもYAMLってやめてほしいわ
手続き的に処理するものをYAMLで書いて、YAMLで書いた順番通りに実行します。
ifもループも書けますとかYAMLという設定ファイル形式の使い方を間違ってるとしか思えんわ
> ちょっとしたエントリー拡張のためにsupervisorやentrykitを入れるDockerfile書くのめんどくさいよ
お前が必要なのはYAMLじゃない。
YAMLでsupervisorやentrykitを入れるコードを書きたいわけじゃないだろ？
お前が本当に必要としてるのは、1コマンドでsupervisorやentrykitを入れるコードだよ。
コンテナ内部で走らせるプロセスを
YAMLでrun: 'process' と書こうが、Dockerfileで run process と書こうが
どちらも何も変わらんだろ
837: 2019/08/03(土)12:10 ID:eOXqQaf9(2/21) AAS
あと supervisor が直接YAMLという設定ファイルに
対応するって話だったらなんの文句もないが、
supervisor開発者と関係ない第三者が、YAMLからiniへの
変換フィルタ作って、ほら、iniをYAMLで書けます。
supervisorのiniのあの項目は、私が作った変換フィルタではコレに対応します。
どれがどれに対応するか覚えて下さい！そうすればYAMLで書けます！
ってアホらしいと思う。supervisorのiniが変われば、
そのどこの馬の骨が作ったかもしれない変換フィルタまで
バージョンアップしないといけないし、変換フィルタの作者が飽きればそこまで
単に設定ファイルの形式を変換するだけの行為に意味ないよ
なんでそうみんなYAMLで書いて第三者が作った変換フィルタのバグや非対応の項目で
悪戦苦闘したがるかね？ ネイティブの設定ファイルを使えばいいじゃん。
838: 2019/08/03(土)14:13 ID:CPHAUpDJ(2/3) AAS
yamlで書ければ複数プロセスの設定が書きやすくなるだろうな
イメージ的にはこういうの
run:
..foo:
....command: foo a b
....restart: always
....after: bar
..bar:
....commad: init c d
....once: true
..baz:
....command: backup e f g
....when: 00 00 * * *
これをサポートなしでやろうとしたら結構めんどくさいよ
サポートあれば簡単だし起動関連の設定が同じ所に集まるから可読性も上がる
docker中心にみたらsupervisorがどこの馬の骨かわからん
公式にサポートされるのとサードパーティツールで補完できるのはやっぱ違うよ
公式ならシームレスでコンパクトにまとまるから使いやすくなるしあれもこれもと手を出さずに済む
変換フィルタの利点は抽象化と構文の統一化かな
外部リソースを扱うプログラムを書く時と同じだよ
設定がいろんな形式であちこちに分散するより纏めて同じ形式で書けるほうがいい
839(1): 2019/08/03(土)14:32 ID:eOXqQaf9(3/21) AAS
> これをサポートなしでやろうとしたら結構めんどくさいよ
だから必要なのは「サポート」であってYAML形式じゃないだろ
> 設定がいろんな形式であちこちに分散するより纏めて
設定をまとめたいなら、設定ファイルをディレクトリにまとめればいいだけ
そして適切な場所にコピーするだけだろ。
> 同じ形式で書けるほうがいい
理由は？
840(1): 2019/08/03(土)14:42 ID:CPHAUpDJ(3/3) AAS
>>839
まあ形式はyamlでなくてもいいけどyamlが妥当だろ
composeやswarm、k8sでも採用してるしdockerユーザーには馴染み深い
まとめる作業もコピーするのも面倒なので却下
それにまとめてもファイルは分割されてるだろ
suprvisor本体、各プロセス、起動ヘルパースクリプト、その他もろもろ
はぁ…ダルっ
同じ形式で書ければ構文を覚えなくていいから楽だしプログラム的にも扱いやすくなる
広く普及してるフォーマットなら形式が違くてもまだマシだが
たまにオリジナル形式で作っちゃうバカがいるから呆れる
841(1): 2019/08/03(土)15:03 ID:eOXqQaf9(4/21) AAS
>>840
> まあ形式はyamlでなくてもいいけどyamlが妥当だろ
YAMLが妥当かどうかの話じゃなくて、ネイティブの設定ファイル形式を
第三者が作ったツールを使ってYAMLで書くのがアホだっていってるんだよ。
なぜかと言うと信頼性がないから。YAMLで書いたものが
本当に設定ファイルに正しく反映されているのか？
新しい機能に対応できてるのか？トラブルが合ったときその原因はどこにあるのか？
新たな問題が起きる層を増やしているだけ
設定ファイルの形式はなんだって良いだろ。設定項目の意味を覚えるのは
どっちだって同じことで、YAMLかそれ以外かの「形式」を覚えるのはなんの苦労もない
> それにまとめてもファイルは分割されてるだろ
じゃあ一つのファイルに、特定の区切り文字で区切って、結合すれば？
必要なのは、その結合設定ファイルの分割を「サポート」するツールであって
YAML以外の設定ファイル形式を理解できない
（からネイティブの設定ファイルが読み書きできず、トラブルがあってもYAML経由じゃなきゃ対応できない）
ような初心者のためのツールじゃないだろ
> たまにオリジナル形式で作っちゃうバカがいるから呆れる
suprvisorの作者にでも言ったら？僕はYAML形式でしか設定ファイルを読み書きできないので
YAML形式に対応してくださいってｗ
842: 2019/08/03(土)17:32 ID:6VgdIlHS(1) AAS
そういうのまだ生き残ってたのか。
新規のDSLは否定しまくるくせにMakefileは不問だったりするんだよな。
843: 2019/08/03(土)18:19 ID:eOXqQaf9(5/21) AAS
1. DSLの話はしていない
2. Makefileは用途が違う
3. お前はMakefileも否定してるのか？
844: 2019/08/03(土)19:02 ID:+6ISjjVu(1/14) AAS
>>841
信頼性に対する考察が足りんな
抽象化と記法の統一化で設定が簡単になる
ということはミスが減るんだよ
広く使われるラッパーが間違えるより人が間違える確率の方が高い
トータルで見ると信頼性が上がる
プログラム書いてる人間なら自然とこういう考え方が身につく筈なのだがね？
君はアセンブラで何でも書いてしまうタイプなのかな？
形式を覚えるのは面倒だ
君が何と言おうとね
区切り文字で結合w
勢いで書いちゃったけど流石に自分でもこれはないわーあーやっちゃった、とか今、思ってるでしょ？
オリジナルってのは広く普及してないフォーマットの事な
別にyamlには限らないよ
jsonでもxmlでもね
845: 2019/08/03(土)19:06 ID:+6ISjjVu(2/14) AAS
ところで君はネイティヴにこだわってるけど
ということはDockerネイティヴのコンテナ内プロセス管理の仕組みを用意した方が良いということになるな
馬の骨が作ったサードパーティツールよりネイティヴサポートの方が良いのは確かにそうだね
846(2): 2019/08/03(土)19:25 ID:eOXqQaf9(6/21) AAS
> 抽象化と記法の統一化で設定が簡単になる
> ということはミスが減るんだよ
イミフ。アプリが要した設定方法を使うほうが
一番広く使われてる方法で、一番設定が簡単だろ
お前アプリのドキュメント読んでるか？
そのアプリのドキュメントにどういうやり方で
設定しろって書いてあるよ？
> 勢いで書いちゃったけど流石に自分でもこれはないわーあーやっちゃった、とか今、思ってるでしょ？
俺が言ったことを復唱するだけで、何一つ反論しないのなｗ
> ところで君はネイティヴにこだわってるけど
アプリのドキュメント通り。公式にやり方のことだが？
Dockerで言えばDockerfileを使ったやり方。
一番広く使われてるだろうが。
847(1): 2019/08/03(土)20:16 ID:+6ISjjVu(3/14) AAS
>>846
イミフというならプログラム書いたことないのだな
アセンブラおじさんと呼ぼう
848(1): 2019/08/03(土)20:17 ID:eOXqQaf9(7/21) AAS
>>847
なんかレスしろよｗ
849: 2019/08/03(土)20:20 ID:+6ISjjVu(4/14) AAS
>>846
でそのDockerfile使った方法がクソッタレだから馬の骨がサードパーティツールとか使い出してしまった
これは明らかに公式の失態だな
さっさとマルチプロセス管理の仕組みを提供すべきだった
850(1): 2019/08/03(土)20:20 ID:+6ISjjVu(5/14) AAS
>>848
なんかレスしろよw
851: 2019/08/03(土)20:22 ID:eOXqQaf9(8/21) AAS
> でそのDockerfile使った方法がクソッタレだから馬の骨がサードパーティツールとか使い出してしまった
あぁ、出すやつは出すだろうな。
んで、使われてるのか？ｗ
誰も使わんだろ
852(1): 2019/08/03(土)20:23 ID:eOXqQaf9(9/21) AAS
>>850
> なんかレスしろよw
お前がなにか意味があることを言ってないのに
何にレスしろと？
853(2): 2019/08/03(土)20:26 ID:eOXqQaf9(10/21) AAS
結局、YAMLから公式設定ファイルへのコンバーターを使った所で
何もメリット無いわけ
みんな公式の設定ファイルを読み書きできるだろ？
（できなかったらどうやってそのアプリの動作検証をやったというのか？）
公式のドキュメントを見て、使い方を覚えて、
さあ、あとはYAMLから変換するツールの使い方の勉強だ！
対応表見るぞー！あれがこれに対応してぇ、こう書けば、こういう設定ファイルが出力されてぇ
こういう設定するにはYAMLでどう書くんだ！くそーうまく出力されない！
何がしたいのかさっぱりわからない
854: 2019/08/03(土)20:31 ID:+6ISjjVu(6/14) AAS
>>852
セルフカウンター乙
>>853
そこから間違ってるよ
公式見なくてもできるのが優れたラッパーだ
1対1で変換しただけのような二流ラッパーの話はしていないので謹め
855(1): 2019/08/03(土)21:02 ID:eOXqQaf9(11/21) AAS
> 公式見なくてもできるのが優れたラッパーだ
お前の言う優れたラッパーってどれよ？ｗ
それは一対一で変換しないんだろ？
そのラッパーにはラッパー特有のトラブルや制限が一切ないんだろう？
さて、優れたラッパーなんて存在するかなーｗ
856(1): 2019/08/03(土)21:06 ID:eOXqQaf9(12/21) AAS
例えばAnsibleの酷さは、これを見れば一目瞭然
外部ﾘﾝｸ:github.com
3959 Open 19874 closed
バグのみに限ってもこんなにある
外部ﾘﾝｸ:github.com
2451 Open 12250 Closed
こういうのと戦っていなくてはいけないわけだ
857(1): 2019/08/03(土)21:06 ID:k1ZymNgl(1) AAS
>>853
某エディタのAnsible拡張を導入したらオートコンプリートが効いてこりゃ便利！と感じたがメリットじゃなかったのかコレ？
858(1): 2019/08/03(土)21:11 ID:eOXqQaf9(13/21) AAS
Dockerfileヤダヤダ。でAnsibleを使うのだろうが、
外部ﾘﾝｸ[html]:docs.ansible.com
ところでマルチステージビルドはどうすればいいのかね？
Dockerfileでマルチステービルドをする方法はいくらでも見つかる。
Ansibleでそれをどうやるのか？を悩むんだろう？ｗ
859(1): 2019/08/03(土)21:14 ID:eOXqQaf9(14/21) AAS
>>857
オートコンプリートなら別にAnsibleとは無関係に使える。
例えばDockerfileのオートコンプリートだって存在する。
まああれも第三者が作ってるから、公式のバージョンアップに
ついていけないところがあったりで不完全なところがあるんだが、
オートコンプリートなら補完されないってだけで別に大きな問題にはならんな
860: 2019/08/03(土)21:17 ID:+6ISjjVu(7/14) AAS
>>855
極論マンw
一切ないとか言ったら何も使えんわ
お前本当にエンジニア？
世界中で実践運用耐えうるぐらいには問題なく使えるよ
>>856
お前は全てのバグを踏み抜く奇跡の体現者かよw
実際に遭遇して問題が表面化して解決もできないなんてバグは滅多にない
ラッパーなら迂回路はいくらでもあるからな
お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな
861(1): 2019/08/03(土)21:22 ID:eOXqQaf9(15/21) AAS
> 一切ないとか言ったら何も使えんわ
だからそういう間に入って変換するだけのものは
使わないほうが良いって言ってんだろ
公式が提供している、標準のやり方を使えばいいだけ
> お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな
本家がバグってるのをラッパーで回避できるわけ無いだろｗ
もし回避する方法があるなら、その方法をラッパーを使わずにやればいいだけだし
俺が言ってるのは公式が提供している標準のやり方をしろというだけ
間に変な変換ツールを入れて、その制限にぶち当たって悩まなくて良くなる
862: 2019/08/03(土)21:26 ID:eOXqQaf9(16/21) AAS
そのうちプログラミングもYAMLで書きたいとか言い出しそうなんだよなｗ
863(1): 2019/08/03(土)21:31 ID:+6ISjjVu(8/14) AAS
>>858
buildargsを使う
修正してモジュールにコミットする
シェル系モジュールを使う
回避する方法がいくらでもあるから安心だなぁ
864: 2019/08/03(土)21:32 ID:+6ISjjVu(9/14) AAS
>>859
他のツールは？
カバー範囲狭すぎだろw
865(1): 2019/08/03(土)21:37 ID:+6ISjjVu(10/14) AAS
>>861
飛行機落ちるかも怖いから乗らないって駄々こねる子供と同じだなこりゃ
大人はメリットもリスクも比べて飛行機に乗る
なんかあったら打つ手なしの飛行機じゃねえんだからリスクはさらに安く見積もって良い
ちょっとでもリスクあったら全否定ってw
本当にアセンブラマンなのかこいつ
今はまだある程度正気のようだがそのうちコンパイラも信じないとか言い出しそうだ
866(1): 2019/08/03(土)22:09 ID:eOXqQaf9(17/21) AAS
>>863
お前の仕事は、回避することかｗ
>>865
間に挟めてトラブルを引き起こすツールに
メリットなんか無いじゃんｗ
867(1): 2019/08/03(土)22:10 ID:eOXqQaf9(18/21) AAS
なんども言うが、公式のやり方をすれば
間に挟めるツールのトラブルがまるまるなくなる
非公式のやり方じゃなくて、公式のやり方をしろと言ってるだけ
868(1): 2019/08/03(土)22:10 ID:eOXqQaf9(19/21) AAS
あとアセンブラとコンパイラは全然意味が違うので話にならない
869: 2019/08/03(土)22:26 ID:+6ISjjVu(11/14) AAS
>>866
仕事は別だ
ごく稀に回避が必要な時にわずかな労力で回避するというだけのことだ
たったそれだけの事を過剰に恐れて便利なツールが中でやってることを全部自前でやるなんてよっぽど暇なのかな
まあ車輪の再発明も仕事といえば仕事か
870: 2019/08/03(土)22:27 ID:+6ISjjVu(12/14) AAS
>>867
省力化やメンテナンス性の向上もまるまるなくなるな
>>868
たとえとしては十分だ
871(1): 2019/08/03(土)22:56 ID:eOXqQaf9(20/21) AAS
> たとえとしては十分だ
的外れだからな。
所詮「第三者が作った設定ファイル形式のコンバーター」は
トラブルが起きたら変換後のオリジナルの設定ファイルを見なければ話にならん
872(1): 2019/08/03(土)22:57 ID:eOXqQaf9(21/21) AAS
> たったそれだけの事を過剰に恐れて便利なツールが中でやってることを
ん？それってシェル系モジュール＝シェルスクリプトでできる程度のことでしょ？ｗ
873(1): 2019/08/03(土)23:06 ID:+6ISjjVu(13/14) AAS
>>871
外れてないぞ
お前の意見は「データを抽象化、容易化するのは無駄(実際には無駄じゃなくメリットはある)で変換器の変換バグがあるかもだからアトミックなまま使え」だからな
機械語コードとコンパイラにもピタリと当てはまるな
874(1): 2019/08/03(土)23:10 ID:+6ISjjVu(14/14) AAS
>>872
それってアセンブラでもできることでしょう？
ただ出来ると簡単に出来る、うまく出来るは違うことなんだな
だから高級言語が発達した
設定も同じことだ
875: 2019/08/04(日)01:24 ID:2JKmG3Fw(1/2) AAS
>>873
俺の意見を間違えてるｗ
「不要な第三者が作った質の悪く機能不足な変換ツールを使わずに
アプリの開発者の想定通りの使い方をしろ」が俺の意見だ
876: 2019/08/04(日)01:25 ID:2JKmG3Fw(2/2) AAS
>>874
設定ファイルは同じじゃない。
YAMLで設定を書いたら、できることが減ってバグが増えてる。
それに対してメリットがない。
877: 2019/08/07(水)02:02 ID:wfV3IAlm(1/3) AAS
長いので2つに分割します。(1/2)
toolboxからコンテナを作れたまでは良いのですが、共通ファイルを作った上で、
コンテナ内のディレクトリにcreate-react-appでunk20というReactディレクトリを生成しようとしても、エラーが表示されで作れなくなりました。
途中まではWindowsの方の共通フォルダdocker-common内にunk20というフォルダが生成されているのですが、
以下のコードのnpm ERR!が出るとunk20フォルダごと削除され消えてしまいます。
ちなみに、共通フォルダを設定していない状態ですと、create-react-appでReactディレクトリはちゃんと作られ、localhostで接続すると問題なくブラウザにも表示されます。
node.jsとnpmは最新版にしております。
878: 2019/08/07(水)02:03 ID:wfV3IAlm(2/3) AAS
PS D:\programming\docker> docker run -it --name my-first-docker-app-20 -p 3000:3000 -v //d/programming/docker-common:/docker-common react-env-2/docker-common
(コンテナ作成 & コンテナ内に入る）
create-react-app unk20(create-react-app コマンドでunk20というReactディレクトリを作る）
Creating a new React app in /docker-common/unk20.
(ここで、Windows側のdocker-commonファイル内にもunk20というファイルが生成される）
(Reactを生成中）
Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...
(ここら辺りまで順調に進んでいたのですが、以下でエラーメッセージが表示される）
npm ERR! path /docker-common/unk20/node_modules/@hapi/topo/node_modules/@hapi/hoek/package.json.769352676
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall open
npm ERR! enoent ENOENT: no such file or directory, open '/docker-common/unk20/node_modules/@hapi/topo/node_modules/@hapi/hoek/package.json.769352676'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2019-08-06T16_31_06_826Z-debug.log
Aborting installation.
npm install --save --save-exact --loglevel error react react-dom react-scripts has failed.
Deleting generated file... node_modules
Deleting generated file... package.json
Deleting unk20/ from /docker-common
Done.
(unk20ディレクトリが削除される）
879: 2019/08/07(水)02:03 ID:wfV3IAlm(3/3) AAS
最後までお読みいただきありがとうございました。
どなたかわかるかたいらしたら宜しくお願い致します・・・。
880(1): 2019/08/22(木)22:54 ID:op2s2rjn(1) AAS
すごいなWindowsでdocker使う人が居るんか
881: 2019/08/22(木)23:05 ID:9hkvIicI(1) AAS
むしろwindowsだからこそありがたい
882: 2019/08/22(木)23:06 ID:jOmYEIea(1) AAS
>>880
普通に使ってるけど？
883: 2019/08/23(金)06:33 ID:CiIDRu0Q(1) AAS
MacのDockerって仮想マシンで動いてるんだなー
884: 2019/08/23(金)12:03 ID:sui4vfrR(1) AAS
Docker for windowsは便利だけどwindowsコンテナは全く使ってない
885: 2019/08/24(土)11:10 ID:lCI+FPsg(1) AAS
helmのテンプレートってすごく汚くて読みにくい
うまくYAMLにするためにインデント数を`Indent 12`みたいにしてテンプレートで指定とか正気かよ
なんか良い代わりのやつ無いの？
886: 2019/08/25(日)00:00 ID:kEZWEDQL(1) AAS
helmはなんかなじめなくてkustomize使ってる
887: 2019/08/25(日)00:10 ID:hoACBN+G(1/2) AAS
クソトメライズ？
888(1): 2019/08/25(日)00:58 ID:VV5KPKj8(1/6) AAS
臨時雇い要員にもdockerを使わせたいのだけどよけいな権限は与えたくない時はどうすればいい？
ホストもコンテナ内も一般ユーザーのみ許可できればいいのだけどそんなことできんのかね
889(1): 2019/08/25(日)03:53 ID:hoACBN+G(2/2) AAS
>>888
その臨時雇い要員に専用のパソコンを与えれて
そのパソコンは自由に使っていいけど、本番環境へのアクセスは禁止すればいい
890: 2019/08/25(日)07:11 ID:VV5KPKj8(2/6) AAS
>>889
仮想端末を含めて専用のPCを用意することが出来ません
複数名でログインする端末です
機密情報を扱う別のユーザーと共有してます
891: 2019/08/25(日)07:27 ID:G4x5ZGgB(1/5) AAS
> 仮想端末を含めて専用のPCを用意することが出来ません
言い換えると、あなたの会社でまともな開発はできません。ということ
自分で、まともな開発はできないと結論を出してるんだから、そこで終わりだろう。
892: 2019/08/25(日)07:29 ID:G4x5ZGgB(2/5) AAS
だいたい、専用のPCを用意できないって
単に金が無いって言ってるだけじゃないか
金がないです。どうしたらいいですかと言われても
借金でもすれば？で終わる話
893: 2019/08/25(日)07:38 ID:G4x5ZGgB(3/5) AAS
給料を出だないほど金がないなら話は別だが
パソコンなんて数万円程度で買えるのにのに「できない」
なんてことはありえない。ようするにやる気がないだけ。
言葉は正しく使え。専用のPCを用意することができないんじゃなくて
専用のPCを用意したくない。が正しい言葉だ。
機密情報も、適当でいいって思ってるだろ。
機密情報に関してきっちりしているなら専用のパソコンに物理的に分ける。
パソコンがとても高価だった時代ならまだしも、今の時代に複数で共有なんて危険なことはしない。
個人専用のパソコンを与えてない時点で、セキュリティはザルでしかない。
自己を認識してないようだからはっきり言ってやる。
お前のところは機密情報を扱う資格がないし、守ることすら出来ない。
大切なものを守る意識も欠けてるし、やるべき正しいこともわかっていない。
今何も問題が起きてないのは運がいいだけだ。
894(1): 2019/08/25(日)07:42 ID:VV5KPKj8(3/6) AAS
あなたの知る限り技術的には不可能ということでしょうか？
895: 2019/08/25(日)07:45 ID:G4x5ZGgB(4/5) AAS
>>894
例えば10階建てビルを作る技術はある。
みんなそれを作るための技術と道具を持ってる。
お前は、クレーンがないんです。
技術的に不可能ということでしょうか？と聞いてる。
技術的に不可能じゃなくて、クレーンを買うことができないことが
出来ない理由だっていってんの。ちゃんと認識しろって
896: 2019/08/25(日)07:46 ID:G4x5ZGgB(5/5) AAS
目的を達成する方法はいくつもあるが
「金が無い」なら、無理じゃねと言うしか無い
897: 2019/08/25(日)08:00 ID:VV5KPKj8(4/6) AAS
つまりわからないということですね？
898: 2019/08/25(日)12:49 ID:ssItiA2j(1/2) AAS
何だこいつ
899: 2019/08/25(日)12:59 ID:VV5KPKj8(5/6) AAS
イキってるくせに質問には答えられないクズってたまに居るよねぇ
900: 2019/08/25(日)13:30 ID:ssItiA2j(2/2) AAS
お前のこと云ってんだよ
901: 2019/08/25(日)13:35 ID:VV5KPKj8(6/6) AAS
言われてるぞお前くん
902(1): 2019/08/26(月)00:04 ID:JShuaBEZ(1/3) AAS
個人でDockerを入れてそこで自己完結させればいいだけだろ。サーバーからコンテナのコピーで済む話。
buildをユーザ権限でやるならk8sの使えば行けるが、会社と担当者のITリテラシーレベル低そうだし諦めればw
903: 2019/08/26(月)00:50 ID:rnlkvQrj(1/3) AAS
>>902
セキュリティやってる気になってる会社には無理だろ
機密情報を扱う別のユーザーと共用してるパソコンなんて
正気の沙汰じゃない。どうせアップデートもしてないだろうし。
セキュリティ意識ゼロ
904(3): 2019/08/26(月)01:31 ID:JShuaBEZ(2/3) AAS
コンテナ内というのが意味不明だな。
ビルドでユーザー作れば当然管理者権限なしでも入れるが、dockerでやる事なのだろうか。
中に入る→出来る
ビルド→出来る
docker コマンド→別グループ作れば可能だが実質su
dockerはアプリ動かすツールであって、管理者以外が共有PCで立ち上げ必須な用途には向かない。巻き添えで常駐コンテナに影響するからだ。
PCに入ったあと、Dockerコマンドで機密情報を操作するコンテナを動かすルールなのだろうか。
企業によくいる、自分は詳しいと思いたい素人が管理してる感溢れていて良い。
905: 2019/08/26(月)02:35 ID:rnlkvQrj(2/3) AAS
>>904
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」
これだけ
906: 2019/08/26(月)02:35 ID:rnlkvQrj(3/3) AAS
>>904
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」
これだけ
907(1): 2019/08/26(月)06:29 ID:fuirL3l0(1/2) AAS
お前らってわからない時の言い訳はいつも饒舌だよねぇ
質問には答えられないくせにさw
908: 2019/08/26(月)06:47 ID:fuirL3l0(2/2) AAS
言い訳というのはちょっと違ったか
わからないことを誤魔化すためのマウンティングになると饒舌
これが正確だな
909(1): 2019/08/26(月)08:28 ID:JShuaBEZ(3/3) AAS
>>907
>>904に答え書いたでしょ。
buildの方はk8sやローカルリポジトリがいるのでかなり難易度高め。k8sが管理者権限だと無理だな。
ユーザー作る方は難しくない。
rootが嫌ならユーザーをdockerに入れると良い。実質suだが。他は不可能。
上2つはdockerfile書けるのが前提で、ここに書いて済むレベルの話ではない。
頑張れw
910(1): 2019/08/26(月)08:43 ID:UMd5mz1m(1/2) AAS
権限ちゃんと分けたかったら
Dockerじゃなくて普通にVM使うべき。
メモリーの必要量は増えちゃうけど。
911(1): 2019/08/26(月)12:49 ID:NWn2YSWg(1/3) AAS
「VM使ってもroot使ったダメなんですー」
「個人にパソコンを与えたとしてもrootは禁止なんですー」
「うちってセキュリティしっかりしてるでしょ？」
912(1): 2019/08/26(月)15:55 ID:aBrnjXrt(1) AAS
>>909
呆れる
k8sの話はしてないしローカルDockerの話してんの
ユーザーDockerに入れても意味ないだろ
>>910
業務上の都合で使えません
>>911
答えられないなら無理してレスしないでいいぞ？
見ててちょっと気の毒だ
913: 2019/08/26(月)15:58 ID:NWn2YSWg(2/3) AAS
× 業務上の都合で使えません
○ 業務改革したくないです。やる気ないです。
914: 2019/08/26(月)16:03 ID:NWn2YSWg(3/3) AAS
新しい道具を入れたら、それだけで改善されるって思ってるバカが多いからな
新しい道具に最適になるように「やり方」を変えないと、何もかも無駄になる。
915: 2019/08/26(月)22:09 ID:80nRq+Qr(1/2) AAS
>>912
dockerでは無理。k8sはコンテナも書き方も同じでdockerの上位互換。しかし、複雑で難易度の高め。
916: 2019/08/26(月)22:11 ID:80nRq+Qr(2/2) AAS
普通、業務で使うならk8sだと思うが。分散や冗長化がdockerではできないからね。インストールがユーザー権限で出来るしdockerfileも使える。
完全な上位互換なんだが、代わりに手軽さは一切無いw
917: 2019/08/26(月)23:35 ID:UMd5mz1m(2/2) AAS
そもそも無理な要件を期待してるんだから、要件の方を変えるべきだな。
Dockerでできることのほとんどは、Docker使わなくても手間が違うだけでできるわけだし。
無理だと分かってる要件を押し通そうとするのは無能。
押し通そうとしてるのが自分じゃなく上なら、そんな理不尽な職場は放棄して転職すべき。
918(1): 2019/08/28(水)08:51 ID:Dqewl7QB(1/14) AAS
macOS版のDockerで、docker buildがたまにフリーズするバグの回避方法ない？
このバグのせいでテストがまともに出来なくて困ってる。
WindowsやLinuxでは発生しない。
タイムアウト仕込んでリトライさせるしか無いかな
919(1): 2019/08/28(水)20:14 ID:mDli60SR(1/5) AAS
>>918
これでどや？
docker run --rm -d --name build-reg -p 55555:5000 registry:latest
docker run --rm -d --name build-dind --link build-reg --privileged \
docker:dind dockerd --host tcp://0.0.0.0:2375 --insecure-registry build-reg:5000
docker run -it --rm --name build-docker --link build-dind \
-v $PWD:/build \
-w /build \
-e DOCKER_HOST=tcp://build-dind:2375 \
docker:latest sh -c 'docker build -t build-reg:5000/test:latest . && docker push build-reg:5000/test:latest'
docker pull localhost:55555/test:latest
docker stop build-dind
docker stop build-reg
docker run --rm localhost:55555/test:latest
920: 2019/08/28(水)20:16 ID:mDli60SR(2/5) AAS
いちお捕捉
working directory直下にDockerfile置いてな
921(1): 2019/08/28(水)20:26 ID:mDli60SR(3/5) AAS
つうか本当にmac限定バグなのか
単に速度が遅いだけなのではと思った
for Macはディスクアクセスがやけに遅い気がする
922(1): 2019/08/28(水)20:32 ID:Dqewl7QB(2/14) AAS
>>919
やってないけど、関係ないわ
docker clientのバグだから
923: 2019/08/28(水)20:33 ID:Dqewl7QB(3/14) AAS
あとdocker buildのバグな
924: 2019/08/28(水)20:35 ID:Dqewl7QB(4/14) AAS
>>921
mac限定のバグ。WindowsとLinuxでは
今まで1セット100ビルドを何十回もやっていて出てなかった
925(1): 2019/08/28(水)21:15 ID:mDli60SR(4/5) AAS
>>922
だとするとclientだけコンテナにすりゃいんじゃね？
docker run --rm -v $PWD:/build -w /build \
-v /var/run/docker.sock:/var/run/docker.sock \
docker:latest build -tag test .
これ100回ぐらい流してみてくれ
926: 2019/08/28(水)21:57 ID:Dqewl7QB(5/14) AAS
>>925
それはLinux版バイナリだからうまくいくよ。
ただね、100回ビルドするだけで3分もかかるんだよ。普通なら30秒。
「1セット100ビルドを何十回もやる」ような場合はちょっと苦痛
更に言うと「Windows」でもやるのでボリュームは使いづらい
それにしてもなんでmac版だけ壊れてるかな？
927: 2019/08/28(水)22:01 ID:4Zzob7TG(1/5) AAS
ビルド100回を何度もするってのがなんか間違いを感じるのだが。
928(1): 2019/08/28(水)22:02 ID:Dqewl7QB(6/14) AAS
各ディストリ、言語やライブラリのバージョンの違いの
組み合わせでテストしてるから
929(1): 2019/08/28(水)22:27 ID:4Zzob7TG(2/5) AAS
>>928
dockerってそれをしないで済ますための仕組みなんじゃ。。
930: 2019/08/28(水)22:29 ID:Dqewl7QB(7/14) AAS
>>929
いつかhomebrewとかaptとか無くなって
全部docker上で動くようになる時代がくるといいですね^^;
931: 2019/08/28(水)22:32 ID:OKaAzkiN(1/6) AAS
kibanaで処理したら？
932: 2019/08/28(水)22:32 ID:OKaAzkiN(2/6) AAS
kanikoの間違い
933: 2019/08/28(水)22:37 ID:4Zzob7TG(3/5) AAS
なんか話がおかしい。
確かにホストの方はどうにもならんことはあるだろうが、
ゲストの中身をいろいろなディストリビューションで実装する意味が分からん。
934: 2019/08/28(水)22:42 ID:Dqewl7QB(8/14) AAS
ゲストの中身をいろいろなディストリビューションで実装するなんて言ってないぞ
いろんなディストリビューションで（Dockerを使わずに）動かすんだよ。
例えばいろんなディストリで動くバイナリを生成するコンパイラの開発
935: 2019/08/28(水)22:43 ID:Dqewl7QB(9/14) AAS
「いろんなディストリでビルドできて正常に動くことの確認」の方がわかりやすいか？
936(1): 2019/08/28(水)22:59 ID:4Zzob7TG(4/5) AAS
だったらホストは無理にmac使う必要ないんでは？
937(1): 2019/08/28(水)23:01 ID:Dqewl7QB(10/14) AAS
>>936
そうだよ？だからWindowsでもLinuxでも問題なくビルドできたので
今まで気づかなかった。だけど出かける時もありノートでも作業できるようにしたいわけ
それにしてもMac版だけdocker buildがフリーズすることに誰も気づいてないのかな？
938: 2019/08/28(水)23:03 ID:4Zzob7TG(5/5) AAS
いやクラウド環境でも社内サーバーでも勝手に使ってやりゃいいじゃん。。
macにそこまでなんでこだわるかね。。
939: 2019/08/28(水)23:24 ID:OKaAzkiN(3/6) AAS
>>937
githubのissueで調べるか出した方が良いのでは。
windowsとmacだとk8sの不具合が認識されていて、ネットワーク割当が原因と分かっているが、2年経っても治ってない。
dockerやk8sは基本的にLinux用。
後のOSは有志中心の開発だから不具合多い、と思った方が良い。
940: 2019/08/28(水)23:32 ID:OKaAzkiN(4/6) AAS
ただ、ビルドを何周も回して動作確認する用途は明らかに本来の用途外だからどうかな。dockerではなく、メモリなどOSのオーバーヘッドかもしれないし。
941(1): 2019/08/28(水)23:41 ID:Dqewl7QB(11/14) AAS
> ただ、ビルドを何周も回して動作確認する用途は明らかに本来の用途外だから
CircleCI全否定？（笑）
942(1): 2019/08/28(水)23:45 ID:Dqewl7QB(12/14) AAS
並列でビルドしているわけじゃないんだからメモリはありえないし、
Mac版のdockerサーバーは仮想マシンのLinux上で動いてるんだから
Mac版のdocker clientの問題だろうね
943: 2019/08/28(水)23:52 ID:mDli60SR(5/5) AAS
マルチプラットフォームで動作保証したいならDockerは使わずに実機か仮想マシン使った方がいいと思うけどな
Dockerで動いても生ホストでの動作保証にはぜんぜんならないでしょう(逆も然り)
944: 2019/08/28(水)23:56 ID:OKaAzkiN(5/6) AAS
>>941
自分がやる時は中で操作して、動作をメモしてCIに移植するから、何周もビルドする事は無いな。遅いし。
945: 2019/08/28(水)23:57 ID:OKaAzkiN(6/6) AAS
>>942
繰り返しになるが、Githubで聞いてくれ。
推論を重ねても意味がない
946: 2019/08/28(水)23:58 ID:Dqewl7QB(13/14) AAS
CIは待ち時間が入るから遅いんだよね
947(1): 2019/08/28(水)23:59 ID:Dqewl7QB(14/14) AAS
Mac版Docker clientが悪いのは推論じゃなくて事実だよ
948: 2019/08/29(木)00:21 ID:PDsNQoqu(1/2) AAS
Open Stack にも、オーケストレーションのHeat、
コンテナ・オーケストレーションのMagnum とかある
Magnumは、Docker Swarm, k8s, Apache Mesos と連携する
949: 2019/08/29(木)00:50 ID:Kom8vkJp(1) AAS
>>947
必要なのは悪者探しではなく、対策でしょ。内容的にstackoverflowでも回答無いと思う。
950: 2019/08/29(木)05:29 ID:IbMmBKe3(1/4) AAS
まあ正直ツマラン流れだったな。情報小出しでもう少しマカがファビョって
荒れると面白かったんだが。面倒になったからさっさと終わらせるわ
再現コード、十数回でフリーズすると思うが、極稀に100回通ることもある
for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done
Mac版docker cilent 19.03系のみでフリーズする。18.09系なら問題なし。
Macで動かしてるdocker server 19.03に外部のLinuxのdocker client 19.03で
やった場合は問題なしだからどうみてもMac版docker clientの問題
951: 2019/08/29(木)05:32 ID:IbMmBKe3(2/4) AAS
対策は19.03専用の機能は使ってないのでクライアントだけ18.09を使うことにした。
バイナリ配布されてるから~/binにでも入れるだけ。
世の中がバグに気づいてなおるのを待つことにする
githubへは面倒なので、だれかやって
952(1): 2019/08/29(木)05:34 ID:PDIn7KyT(1) AAS
volume先のゲストのhtmlファイルをホストのブラウザからlocal host 3000で接続して
htmlの内容がブラウザに表示されたまではいいんだけど
htmlを編集してもブラウザが更新されてくれない(リロードしても編集前と同じ画面）
再度npm startするとちゃんと編集後のコードで更新されているんだけど、
少しの編集でも逐一チェックしたいのでとても不便・・・どうすればブラウザでも随時更新されるようになるのかな？？
手探りで、docker build時に -no--chace=trueを付けてみても駄目だった
953: 2019/08/29(木)05:37 ID:IbMmBKe3(3/4) AAS
ふぅ、せっかく荒らして遊ぼうとしてるのに邪魔しないでくれないかな
docker関係ないだろ
954: 2019/08/29(木)08:46 ID:7sVXLGAA(1) AAS
言ってることが糞野郎過ぎて話にならん。
955(1): 2019/08/29(木)08:59 ID:4t3Jo3Qx(1/2) AAS
macOSネイティブ版で苦労するより
VMware Fusionでも買って Ubuntu でも入れて
出先のMacノートではそれで開発すれば？って気がするな。
下手するとネイティブより速かったりして。
956: 2019/08/29(木)09:26 ID:IbMmBKe3(4/4) AAS
>>955
それな。MacのCLIってなんであんなに遅いんだろう？
WSLと大差ない。WSLができてMacで開発するメリット無くなったわ
957(1): 2019/08/29(木)09:37 ID:PDsNQoqu(2/2) AAS
>>952
HTML を更新後に、ウェブサーバーで再読み込みするとか、再起動すれば？
958(1): 2019/08/29(木)09:42 ID:4t3Jo3Qx(2/2) AAS
カーネルでのファイルシステムキャッシュとかの性能最適化が遅れてるんじゃない?
Windowsも遅いからクライアントOS志向だとその辺で手を抜くのかね？
959: 2019/08/31(土)17:30 ID:W/+KbOJi(1) AAS
>>957
>>958
ありがとう〜
多分npmのキャッシュが原因なのかなぁ
nodemonっての使って更新されるようになったけど
結局はnpm startをリスタートしているだけで待ち時間が少し早くなった程度
dockerはむつかしい＾ｐ＾
960: 2019/08/31(土)17:40 ID:3i1dPJsj(1) AAS
docker関係ねーって言ってんだろ
961: 2019/09/05(木)06:20 ID:0FQt0tq4(1) AAS
マカーさんの自己顕示欲は異常だわ
Docker以前のおま環のことで荒らすなや
きくちももこ学生です並のウザさは健在
962: 2019/09/05(木)06:56 ID:rtvg+Hab(1) AAS
19.03.2がリリースされたけど直ってなかったな
やっぱりMacでdocker buildがフリーズする
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.282s*