仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net
レス数が900を超えています。1000を超えると表示できなくなるよ。
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう
よろしこ >>832
根本的な部分を忘れていました・・・全てDocker内のLinuxで完結しているのですね
ちゃんと作れるようになりました
ありがとうございますm(__)m Dockerってcron使えるようになりました?
前使ってた時は相性悪かったんですが 組み込み機能でコンテナ内部で走らせるプロセスをyamlで管理できたら便利だと思う(composeのような雰囲気で)
supervisorは設定ファイルiniでキモいしちょっとしたエントリー拡張のためにsupervisorやentrykitを入れるDockerfile書くのめんどくさいよ なんでもかんでもYAMLってやめてほしいわ
手続き的に処理するものをYAMLで書いて、YAMLで書いた順番通りに実行します。
ifもループも書けますとかYAMLという設定ファイル形式の使い方を間違ってるとしか思えんわ
> ちょっとしたエントリー拡張のためにsupervisorやentrykitを入れるDockerfile書くのめんどくさいよ
お前が必要なのはYAMLじゃない。
YAMLでsupervisorやentrykitを入れるコードを書きたいわけじゃないだろ?
お前が本当に必要としてるのは、1コマンドでsupervisorやentrykitを入れるコードだよ。
コンテナ内部で走らせるプロセスを
YAMLでrun: 'process' と書こうが、Dockerfileで run process と書こうが
どちらも何も変わらんだろ あと supervisor が直接YAMLという設定ファイルに
対応するって話だったらなんの文句もないが、
supervisor開発者と関係ない第三者が、YAMLからiniへの
変換フィルタ作って、ほら、iniをYAMLで書けます。
supervisorのiniのあの項目は、私が作った変換フィルタではコレに対応します。
どれがどれに対応するか覚えて下さい!そうすればYAMLで書けます!
ってアホらしいと思う。supervisorのiniが変われば、
そのどこの馬の骨が作ったかもしれない変換フィルタまで
バージョンアップしないといけないし、変換フィルタの作者が飽きればそこまで
単に設定ファイルの形式を変換するだけの行為に意味ないよ
なんでそうみんなYAMLで書いて第三者が作った変換フィルタのバグや非対応の項目で
悪戦苦闘したがるかね? ネイティブの設定ファイルを使えばいいじゃん。 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がどこの馬の骨かわからん
公式にサポートされるのとサードパーティツールで補完できるのはやっぱ違うよ
公式ならシームレスでコンパクトにまとまるから使いやすくなるしあれもこれもと手を出さずに済む
変換フィルタの利点は抽象化と構文の統一化かな
外部リソースを扱うプログラムを書く時と同じだよ
設定がいろんな形式であちこちに分散するより纏めて同じ形式で書けるほうがいい > これをサポートなしでやろうとしたら結構めんどくさいよ
だから必要なのは「サポート」であってYAML形式じゃないだろ
> 設定がいろんな形式であちこちに分散するより纏めて
設定をまとめたいなら、設定ファイルをディレクトリにまとめればいいだけ
そして適切な場所にコピーするだけだろ。
> 同じ形式で書けるほうがいい
理由は? >>839
まあ形式はyamlでなくてもいいけどyamlが妥当だろ
composeやswarm、k8sでも採用してるしdockerユーザーには馴染み深い
まとめる作業もコピーするのも面倒なので却下
それにまとめてもファイルは分割されてるだろ
suprvisor本体、各プロセス、起動ヘルパースクリプト、その他もろもろ
はぁ…ダルっ
同じ形式で書ければ構文を覚えなくていいから楽だしプログラム的にも扱いやすくなる
広く普及してるフォーマットなら形式が違くてもまだマシだが
たまにオリジナル形式で作っちゃうバカがいるから呆れる >>840
> まあ形式はyamlでなくてもいいけどyamlが妥当だろ
YAMLが妥当かどうかの話じゃなくて、ネイティブの設定ファイル形式を
第三者が作ったツールを使ってYAMLで書くのがアホだっていってるんだよ。
なぜかと言うと信頼性がないから。YAMLで書いたものが
本当に設定ファイルに正しく反映されているのか?
新しい機能に対応できてるのか?トラブルが合ったときその原因はどこにあるのか?
新たな問題が起きる層を増やしているだけ
設定ファイルの形式はなんだって良いだろ。設定項目の意味を覚えるのは
どっちだって同じことで、YAMLかそれ以外かの「形式」を覚えるのはなんの苦労もない
> それにまとめてもファイルは分割されてるだろ
じゃあ一つのファイルに、特定の区切り文字で区切って、結合すれば?
必要なのは、その結合設定ファイルの分割を「サポート」するツールであって
YAML以外の設定ファイル形式を理解できない
(からネイティブの設定ファイルが読み書きできず、トラブルがあってもYAML経由じゃなきゃ対応できない)
ような初心者のためのツールじゃないだろ
> たまにオリジナル形式で作っちゃうバカがいるから呆れる
suprvisorの作者にでも言ったら?僕はYAML形式でしか設定ファイルを読み書きできないので
YAML形式に対応してくださいってw そういうのまだ生き残ってたのか。
新規のDSLは否定しまくるくせにMakefileは不問だったりするんだよな。 1. DSLの話はしていない
2. Makefileは用途が違う
3. お前はMakefileも否定してるのか? >>841
信頼性に対する考察が足りんな
抽象化と記法の統一化で設定が簡単になる
ということはミスが減るんだよ
広く使われるラッパーが間違えるより人が間違える確率の方が高い
トータルで見ると信頼性が上がる
プログラム書いてる人間なら自然とこういう考え方が身につく筈なのだがね?
君はアセンブラで何でも書いてしまうタイプなのかな?
形式を覚えるのは面倒だ
君が何と言おうとね
区切り文字で結合w
勢いで書いちゃったけど流石に自分でもこれはないわーあーやっちゃった、とか今、思ってるでしょ?
オリジナルってのは広く普及してないフォーマットの事な
別にyamlには限らないよ
jsonでもxmlでもね ところで君はネイティヴにこだわってるけど
ということはDockerネイティヴのコンテナ内プロセス管理の仕組みを用意した方が良いということになるな
馬の骨が作ったサードパーティツールよりネイティヴサポートの方が良いのは確かにそうだね > 抽象化と記法の統一化で設定が簡単になる
> ということはミスが減るんだよ
イミフ。アプリが要した設定方法を使うほうが
一番広く使われてる方法で、一番設定が簡単だろ
お前アプリのドキュメント読んでるか?
そのアプリのドキュメントにどういうやり方で
設定しろって書いてあるよ?
> 勢いで書いちゃったけど流石に自分でもこれはないわーあーやっちゃった、とか今、思ってるでしょ?
俺が言ったことを復唱するだけで、何一つ反論しないのなw
> ところで君はネイティヴにこだわってるけど
アプリのドキュメント通り。公式にやり方のことだが?
Dockerで言えばDockerfileを使ったやり方。
一番広く使われてるだろうが。 >>846
イミフというならプログラム書いたことないのだな
アセンブラおじさんと呼ぼう >>846
でそのDockerfile使った方法がクソッタレだから馬の骨がサードパーティツールとか使い出してしまった
これは明らかに公式の失態だな
さっさとマルチプロセス管理の仕組みを提供すべきだった > でそのDockerfile使った方法がクソッタレだから馬の骨がサードパーティツールとか使い出してしまった
あぁ、出すやつは出すだろうな。
んで、使われてるのか?w
誰も使わんだろ >>850
> なんかレスしろよw
お前がなにか意味があることを言ってないのに
何にレスしろと? 結局、YAMLから公式設定ファイルへのコンバーターを使った所で
何もメリット無いわけ
みんな公式の設定ファイルを読み書きできるだろ?
(できなかったらどうやってそのアプリの動作検証をやったというのか?)
公式のドキュメントを見て、使い方を覚えて、
さあ、あとはYAMLから変換するツールの使い方の勉強だ!
対応表見るぞー!あれがこれに対応してぇ、こう書けば、こういう設定ファイルが出力されてぇ
こういう設定するにはYAMLでどう書くんだ!くそーうまく出力されない!
何がしたいのかさっぱりわからない >>852
セルフカウンター乙
>>853
そこから間違ってるよ
公式見なくてもできるのが優れたラッパーだ
1対1で変換しただけのような二流ラッパーの話はしていないので謹め > 公式見なくてもできるのが優れたラッパーだ
お前の言う優れたラッパーってどれよ?w
それは一対一で変換しないんだろ?
そのラッパーにはラッパー特有のトラブルや制限が一切ないんだろう?
さて、優れたラッパーなんて存在するかなーw >>853
某エディタのAnsible拡張を導入したらオートコンプリートが効いてこりゃ便利!と感じたがメリットじゃなかったのかコレ? Dockerfileヤダヤダ。でAnsibleを使うのだろうが、
https://docs.ansible.com/ansible/latest/modules/docker_image_module.html#docker-image-module
ところでマルチステージビルドはどうすればいいのかね?
Dockerfileでマルチステービルドをする方法はいくらでも見つかる。
Ansibleでそれをどうやるのか?を悩むんだろう?w >>857
オートコンプリートなら別にAnsibleとは無関係に使える。
例えばDockerfileのオートコンプリートだって存在する。
まああれも第三者が作ってるから、公式のバージョンアップに
ついていけないところがあったりで不完全なところがあるんだが、
オートコンプリートなら補完されないってだけで別に大きな問題にはならんな >>855
極論マンw
一切ないとか言ったら何も使えんわ
お前本当にエンジニア?
世界中で実践運用耐えうるぐらいには問題なく使えるよ
>>856
お前は全てのバグを踏み抜く奇跡の体現者かよw
実際に遭遇して問題が表面化して解決もできないなんてバグは滅多にない
ラッパーなら迂回路はいくらでもあるからな
お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな > 一切ないとか言ったら何も使えんわ
だからそういう間に入って変換するだけのものは
使わないほうが良いって言ってんだろ
公式が提供している、標準のやり方を使えばいいだけ
> お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな
本家がバグってるのをラッパーで回避できるわけ無いだろw
もし回避する方法があるなら、その方法をラッパーを使わずにやればいいだけだし
俺が言ってるのは公式が提供している標準のやり方をしろというだけ
間に変な変換ツールを入れて、その制限にぶち当たって悩まなくて良くなる そのうちプログラミングもYAMLで書きたいとか言い出しそうなんだよなw >>858
buildargsを使う
修正してモジュールにコミットする
シェル系モジュールを使う
回避する方法がいくらでもあるから安心だなぁ >>859
他のツールは?
カバー範囲狭すぎだろw >>861
飛行機落ちるかも怖いから乗らないって駄々こねる子供と同じだなこりゃ
大人はメリットもリスクも比べて飛行機に乗る
なんかあったら打つ手なしの飛行機じゃねえんだからリスクはさらに安く見積もって良い
ちょっとでもリスクあったら全否定ってw
本当にアセンブラマンなのかこいつ
今はまだある程度正気のようだがそのうちコンパイラも信じないとか言い出しそうだ >>863
お前の仕事は、回避することかw
>>865
間に挟めてトラブルを引き起こすツールに
メリットなんか無いじゃんw なんども言うが、公式のやり方をすれば
間に挟めるツールのトラブルがまるまるなくなる
非公式のやり方じゃなくて、公式のやり方をしろと言ってるだけ あとアセンブラとコンパイラは全然意味が違うので話にならない >>866
仕事は別だ
ごく稀に回避が必要な時にわずかな労力で回避するというだけのことだ
たったそれだけの事を過剰に恐れて便利なツールが中でやってることを全部自前でやるなんてよっぽど暇なのかな
まあ車輪の再発明も仕事といえば仕事か >>867
省力化やメンテナンス性の向上もまるまるなくなるな
>>868
たとえとしては十分だ > たとえとしては十分だ
的外れだからな。
所詮「第三者が作った設定ファイル形式のコンバーター」は
トラブルが起きたら変換後のオリジナルの設定ファイルを見なければ話にならん > たったそれだけの事を過剰に恐れて便利なツールが中でやってることを
ん?それってシェル系モジュール=シェルスクリプトでできる程度のことでしょ?w >>871
外れてないぞ
お前の意見は「データを抽象化、容易化するのは無駄(実際には無駄じゃなくメリットはある)で変換器の変換バグがあるかもだからアトミックなまま使え」だからな
機械語コードとコンパイラにもピタリと当てはまるな >>872
それってアセンブラでもできることでしょう?
ただ出来ると簡単に出来る、うまく出来るは違うことなんだな
だから高級言語が発達した
設定も同じことだ >>873
俺の意見を間違えてるw
「不要な第三者が作った質の悪く機能不足な変換ツールを使わずに
アプリの開発者の想定通りの使い方をしろ」が俺の意見だ >>874
設定ファイルは同じじゃない。
YAMLで設定を書いたら、できることが減ってバグが増えてる。
それに対してメリットがない。 長いので2つに分割します。(1/2)
toolboxからコンテナを作れたまでは良いのですが、共通ファイルを作った上で、
コンテナ内のディレクトリにcreate-react-appでunk20というReactディレクトリを生成しようとしても、エラーが表示されで作れなくなりました。
途中まではWindowsの方の共通フォルダdocker-common内にunk20というフォルダが生成されているのですが、
以下のコードのnpm ERR!が出るとunk20フォルダごと削除され消えてしまいます。
ちなみに、共通フォルダを設定していない状態ですと、create-react-appでReactディレクトリはちゃんと作られ、localhostで接続すると問題なくブラウザにも表示されます。
node.jsとnpmは最新版にしております。 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ディレクトリが削除される) 最後までお読みいただきありがとうございました。
どなたかわかるかたいらしたら宜しくお願い致します・・・。 すごいなWindowsでdocker使う人が居るんか MacのDockerって仮想マシンで動いてるんだなー Docker for windowsは便利だけどwindowsコンテナは全く使ってない helmのテンプレートってすごく汚くて読みにくい
うまくYAMLにするためにインデント数を`Indent 12`みたいにしてテンプレートで指定とか正気かよ
なんか良い代わりのやつ無いの? helmはなんかなじめなくてkustomize使ってる 臨時雇い要員にもdockerを使わせたいのだけどよけいな権限は与えたくない時はどうすればいい?
ホストもコンテナ内も一般ユーザーのみ許可できればいいのだけどそんなことできんのかね >>888
その臨時雇い要員に専用のパソコンを与えれて
そのパソコンは自由に使っていいけど、本番環境へのアクセスは禁止すればいい >>889
仮想端末を含めて専用のPCを用意することが出来ません
複数名でログインする端末です
機密情報を扱う別のユーザーと共有してます > 仮想端末を含めて専用のPCを用意することが出来ません
言い換えると、あなたの会社でまともな開発はできません。ということ
自分で、まともな開発はできないと結論を出してるんだから、そこで終わりだろう。 だいたい、専用のPCを用意できないって
単に金が無いって言ってるだけじゃないか
金がないです。どうしたらいいですかと言われても
借金でもすれば?で終わる話 給料を出だないほど金がないなら話は別だが
パソコンなんて数万円程度で買えるのにのに「できない」
なんてことはありえない。ようするにやる気がないだけ。
言葉は正しく使え。専用のPCを用意することができないんじゃなくて
専用のPCを用意したくない。が正しい言葉だ。
機密情報も、適当でいいって思ってるだろ。
機密情報に関してきっちりしているなら専用のパソコンに物理的に分ける。
パソコンがとても高価だった時代ならまだしも、今の時代に複数で共有なんて危険なことはしない。
個人専用のパソコンを与えてない時点で、セキュリティはザルでしかない。
自己を認識してないようだからはっきり言ってやる。
お前のところは機密情報を扱う資格がないし、守ることすら出来ない。
大切なものを守る意識も欠けてるし、やるべき正しいこともわかっていない。
今何も問題が起きてないのは運がいいだけだ。 あなたの知る限り技術的には不可能ということでしょうか? >>894
例えば10階建てビルを作る技術はある。
みんなそれを作るための技術と道具を持ってる。
お前は、クレーンがないんです。
技術的に不可能ということでしょうか?と聞いてる。
技術的に不可能じゃなくて、クレーンを買うことができないことが
出来ない理由だっていってんの。ちゃんと認識しろって 目的を達成する方法はいくつもあるが
「金が無い」なら、無理じゃねと言うしか無い イキってるくせに質問には答えられないクズってたまに居るよねぇ 個人でDockerを入れてそこで自己完結させればいいだけだろ。サーバーからコンテナのコピーで済む話。
buildをユーザ権限でやるならk8sの使えば行けるが、会社と担当者のITリテラシーレベル低そうだし諦めればw >>902
セキュリティやってる気になってる会社には無理だろ
機密情報を扱う別のユーザーと共用してるパソコンなんて
正気の沙汰じゃない。どうせアップデートもしてないだろうし。
セキュリティ意識ゼロ コンテナ内というのが意味不明だな。
ビルドでユーザー作れば当然管理者権限なしでも入れるが、dockerでやる事なのだろうか。
中に入る→出来る
ビルド→出来る
docker コマンド→別グループ作れば可能だが実質su
dockerはアプリ動かすツールであって、管理者以外が共有PCで立ち上げ必須な用途には向かない。巻き添えで常駐コンテナに影響するからだ。
PCに入ったあと、Dockerコマンドで機密情報を操作するコンテナを動かすルールなのだろうか。
企業によくいる、自分は詳しいと思いたい素人が管理してる感溢れていて良い。 >>904
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」
これだけ >>904
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」
これだけ お前らってわからない時の言い訳はいつも饒舌だよねぇ
質問には答えられないくせにさw 言い訳というのはちょっと違ったか
わからないことを誤魔化すためのマウンティングになると饒舌
これが正確だな >>907
>>904に答え書いたでしょ。
buildの方はk8sやローカルリポジトリがいるのでかなり難易度高め。k8sが管理者権限だと無理だな。
ユーザー作る方は難しくない。
rootが嫌ならユーザーをdockerに入れると良い。実質suだが。他は不可能。
上2つはdockerfile書けるのが前提で、ここに書いて済むレベルの話ではない。
頑張れw 権限ちゃんと分けたかったら
Dockerじゃなくて普通にVM使うべき。
メモリーの必要量は増えちゃうけど。 「VM使ってもroot使ったダメなんですー」
「個人にパソコンを与えたとしてもrootは禁止なんですー」
「うちってセキュリティしっかりしてるでしょ?」 >>909
呆れる
k8sの話はしてないしローカルDockerの話してんの
ユーザーDockerに入れても意味ないだろ
>>910
業務上の都合で使えません
>>911
答えられないなら無理してレスしないでいいぞ?
見ててちょっと気の毒だ × 業務上の都合で使えません
○ 業務改革したくないです。やる気ないです。 新しい道具を入れたら、それだけで改善されるって思ってるバカが多いからな
新しい道具に最適になるように「やり方」を変えないと、何もかも無駄になる。 >>912
dockerでは無理。k8sはコンテナも書き方も同じでdockerの上位互換。しかし、複雑で難易度の高め。 普通、業務で使うならk8sだと思うが。分散や冗長化がdockerではできないからね。インストールがユーザー権限で出来るしdockerfileも使える。
完全な上位互換なんだが、代わりに手軽さは一切無いw そもそも無理な要件を期待してるんだから、要件の方を変えるべきだな。
Dockerでできることのほとんどは、Docker使わなくても手間が違うだけでできるわけだし。
無理だと分かってる要件を押し通そうとするのは無能。
押し通そうとしてるのが自分じゃなく上なら、そんな理不尽な職場は放棄して転職すべき。 macOS版のDockerで、docker buildがたまにフリーズするバグの回避方法ない?
このバグのせいでテストがまともに出来なくて困ってる。
WindowsやLinuxでは発生しない。
タイムアウト仕込んでリトライさせるしか無いかな >>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 いちお捕捉
working directory直下にDockerfile置いてな つうか本当にmac限定バグなのか
単に速度が遅いだけなのではと思った
for Macはディスクアクセスがやけに遅い気がする >>919
やってないけど、関係ないわ
docker clientのバグだから >>921
mac限定のバグ。WindowsとLinuxでは
今まで1セット100ビルドを何十回もやっていて出てなかった >>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回ぐらい流してみてくれ >>925
それはLinux版バイナリだからうまくいくよ。
ただね、100回ビルドするだけで3分もかかるんだよ。普通なら30秒。
「1セット100ビルドを何十回もやる」ような場合はちょっと苦痛
更に言うと「Windows」でもやるのでボリュームは使いづらい
それにしてもなんでmac版だけ壊れてるかな? ビルド100回を何度もするってのがなんか間違いを感じるのだが。 各ディストリ、言語やライブラリのバージョンの違いの
組み合わせでテストしてるから >>928
dockerってそれをしないで済ますための仕組みなんじゃ。。 >>929
いつかhomebrewとかaptとか無くなって
全部docker上で動くようになる時代がくるといいですね^^; レス数が900を超えています。1000を超えると表示できなくなるよ。