仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/02/16(木) 18:01:04.48

開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう

よろしこ

**デフォルトの名無しさん** · 2019/07/06(土) 09:17:32.46

小さい組織でやってるとこういう苦労はわからないものさ
責任が小さいから自由もある

**デフォルトの名無しさん** · 2019/07/06(土) 09:23:00.60

だーかーら、上に相談することも出来ないのか？って言ってるんだが

**デフォルトの名無しさん** · 2019/07/06(土) 10:25:15.17

>>813
お前がそれで解決しないという現実を知らんだけ。

**デフォルトの名無しさん** · 2019/07/06(土) 11:40:56.15

解決するかしないかは関係ないんだよ。
上の責任にしろって話。

責任を押し付けないから、上は適当に仕事するんだよ。
おめぇの責任だって言えば上は逃げられなくなるからな。

**デフォルトの名無しさん** · 2019/07/06(土) 11:49:06.19

与えられた裁量の中で成果を出すことが求められている
もっと権限をよこせよこさないならうまくいかないぞそうなったらおまえのせいだかんななどと喚くのは無能だ
組織で働いたことがねえんだろうなあ

**デフォルトの名無しさん** · 2019/07/06(土) 13:09:27.76

> 与えられた裁量の中で成果を出すことが求められている

どんな校則でも絶対に守る生徒 VS 校則の内容に疑問を持つ生徒

ほんとなぁ、日本の学校教育の失敗やで。
意味のないルールでも絶対に守れ。疑問を持つことは許さない
という教育をしてるからこうなる。

**デフォルトの名無しさん** · 2019/07/06(土) 13:18:23.10

末端の開発者が抱くような疑問はとっくに上が検討済み
それ以外の事も諸々含めて選んだ結果が末端の開発者に降りてくる
だから上からしたら責任はあんたにあります(キリッ)とか言われても何を言ってんだこの雑魚はとしか思えんよ
もともと責任ある立場なんだからさ末端の開発者と違って

**デフォルトの名無しさん** · 2019/07/06(土) 13:27:42.39

「末端の開発者が抱くような疑問はとっくに上が検討済み」
という思い込み

そして前提（時代）が変わってるもルールだけを残す。

ルールの存在理由を考えない。
ルールを守ることが目的となってる。

**デフォルトの名無しさん** · 2019/07/06(土) 13:32:36.26

>>821
＞という思い込み
という末端の思い込み

＞ルールの存在理由を考えない。
小さい組織の末端で働くと組織視点でルールの存在理由を考えない
なので自分の都合・不都合だけ考えてルールを否定したがる

**デフォルトの名無しさん** · 2019/07/06(土) 13:43:30.71

> なので自分の都合・不都合だけ考えてルールを否定したがる

当たり前だろｗ
言わなくても、他人が自分の都合をわかってくれるとでも思ってんのか？

**デフォルトの名無しさん** · 2019/07/06(土) 13:58:40.05

上は末端の開発者が考えることぐらいはだいたいわかってるよ
わかった上で様々な要素を検討して
開発者には悪いけど多少苦労してもらい集団としての利を取ろうと決定したの
末端の意見なんてのは上から見るととっくに処理済なんだよ
蒸し返されても困る

**デフォルトの名無しさん** · 2019/07/06(土) 14:51:35.13

> 蒸し返されても困る

理由が書いてないルールは蒸し返されてしかるべきだし
理由が現状とあってないルールは改善すべき

ほんとな。この理由が書いてないのが、ルールだけが残る悪い典型例だよｗ

靴下は白でなければなりません！
（理由は？）

理由が書いてない校則が多い

**デフォルトの名無しさん** · 2019/07/06(土) 14:57:30.90

>>825
理由は上が管理してるから安心しなよ

**デフォルトの名無しさん** · 2019/07/06(土) 15:20:41.61

スレチ

**デフォルトの名無しさん** · 2019/07/06(土) 21:48:53.04

上がそこまで理解力あったら7payみたいなことは起きんわ。
現実見ないと幸せそうでいいよね。

**デフォルトの名無しさん** · 2019/07/06(土) 22:15:52.49

うちの会社もフィルタリングはされてるけど、
正当な理由つきで解除申請すればホワイトリストに登録してくれて
アクセスできるようになるよ。

合理的判断のできる会社ならこれが当たり前だし
それができない会社にいるなら
奴隷の鎖自慢なんかしてないでさっさと転職した方がいい。
不合理がまかりとおるのが当たり前になった会社なんて
長期的に見れば没落するに決まってるから。

**デフォルトの名無しさん** · 2019/07/06(土) 22:50:33.13

せや、せーや（笑）

**デフォルトの名無しさん** · 2019/07/17(水) 07:53:46.72

Dicjerfileでイメージを作成したいのですが
（コマンドはMacですが、私はWindows10でやっております。）

# alpine(軽量なLinux)をベースイメージとして
FROM alpine

# 作業ディレクトリの名前をreact-appとして
ENV wkdir react-app

# /usr/root/react-app を作業ディレクトリとして
WORKDIR /usr/app/$wkdir

# ディレクトリ"reactAppOnDocker"をボリュームとして
VOLUME reactAppOnDocker

# apk(alpineでのパッケージマネージャー)でnodejsとかインストールして
RUN apk add nodejs
RUN apk add npm
RUN npm i -g create-react-app

# shを実行する
ENTRYPOINT sh

作業ディレクトリを　Windows10 D:/prog/docker/　に指定したい場合は
上記のWORKDIRを　D:/prog/docker/$wkdir　にするで合っていますか？
一応Imageは作成できたのですが、WORKDIRが上手く作られていない気がしまして・・・

**デフォルトの名無しさん** · 2019/07/17(水) 08:54:52.34

WindowsでVOLUMEは鬼門・・・

はいいとしてWORKDIRはDockerコンテナ内のパス。
単にalpineの中でmkdirしてcdしてるようなもんだよ。
だからWindowsなんて関係ない。DockerfileはどのLinuxでもMacでも同じものが
使えるんだから、そんなWindowsの固有の情報なんて出てこない

**デフォルトの名無しさん** · 2019/07/19(金) 03:11:40.54

>>832
根本的な部分を忘れていました・・・全てDocker内のLinuxで完結しているのですね
ちゃんと作れるようになりました
ありがとうございますm(__)m

**デフォルトの名無しさん** · 2019/07/31(水) 22:03:01.15

Dockerってcron使えるようになりました？
前使ってた時は相性悪かったんですが

**デフォルトの名無しさん** · 2019/08/03(土) 10:08:06.93

組み込み機能でコンテナ内部で走らせるプロセスをyamlで管理できたら便利だと思う(composeのような雰囲気で)
supervisorは設定ファイルiniでキモいしちょっとしたエントリー拡張のためにsupervisorやentrykitを入れるDockerfile書くのめんどくさいよ

**デフォルトの名無しさん** · 2019/08/03(土) 12:03:27.90

なんでもかんでもYAMLってやめてほしいわ

手続き的に処理するものをYAMLで書いて、YAMLで書いた順番通りに実行します。
ifもループも書けますとかYAMLという設定ファイル形式の使い方を間違ってるとしか思えんわ

> ちょっとしたエントリー拡張のためにsupervisorやentrykitを入れるDockerfile書くのめんどくさいよ

お前が必要なのはYAMLじゃない。

YAMLでsupervisorやentrykitを入れるコードを書きたいわけじゃないだろ？
お前が本当に必要としてるのは、1コマンドでsupervisorやentrykitを入れるコードだよ。

コンテナ内部で走らせるプロセスを
YAMLでrun: 'process' と書こうが、Dockerfileで run process と書こうが
どちらも何も変わらんだろ

**デフォルトの名無しさん** · 2019/08/03(土) 12:10:05.93

あと supervisor が直接YAMLという設定ファイルに
対応するって話だったらなんの文句もないが、

supervisor開発者と関係ない第三者が、YAMLからiniへの
変換フィルタ作って、ほら、iniをYAMLで書けます。
supervisorのiniのあの項目は、私が作った変換フィルタではコレに対応します。
どれがどれに対応するか覚えて下さい！そうすればYAMLで書けます！

ってアホらしいと思う。supervisorのiniが変われば、
そのどこの馬の骨が作ったかもしれない変換フィルタまで
バージョンアップしないといけないし、変換フィルタの作者が飽きればそこまで
単に設定ファイルの形式を変換するだけの行為に意味ないよ

なんでそうみんなYAMLで書いて第三者が作った変換フィルタのバグや非対応の項目で
悪戦苦闘したがるかね？ネイティブの設定ファイルを使えばいいじゃん。

**デフォルトの名無しさん** · 2019/08/03(土) 14:13:39.93

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がどこの馬の骨かわからん
公式にサポートされるのとサードパーティツールで補完できるのはやっぱ違うよ
公式ならシームレスでコンパクトにまとまるから使いやすくなるしあれもこれもと手を出さずに済む

変換フィルタの利点は抽象化と構文の統一化かな
外部リソースを扱うプログラムを書く時と同じだよ
設定がいろんな形式であちこちに分散するより纏めて同じ形式で書けるほうがいい

**デフォルトの名無しさん** · 2019/08/03(土) 14:32:11.81

> これをサポートなしでやろうとしたら結構めんどくさいよ

だから必要なのは「サポート」であってYAML形式じゃないだろ

> 設定がいろんな形式であちこちに分散するより纏めて
設定をまとめたいなら、設定ファイルをディレクトリにまとめればいいだけ
そして適切な場所にコピーするだけだろ。

> 同じ形式で書けるほうがいい
理由は？

**デフォルトの名無しさん** · 2019/08/03(土) 14:42:55.01

>>839
まあ形式はyamlでなくてもいいけどyamlが妥当だろ
composeやswarm、k8sでも採用してるしdockerユーザーには馴染み深い

まとめる作業もコピーするのも面倒なので却下
それにまとめてもファイルは分割されてるだろ
suprvisor本体、各プロセス、起動ヘルパースクリプト、その他もろもろ
はぁ…ダルっ

同じ形式で書ければ構文を覚えなくていいから楽だしプログラム的にも扱いやすくなる
広く普及してるフォーマットなら形式が違くてもまだマシだが
たまにオリジナル形式で作っちゃうバカがいるから呆れる

**デフォルトの名無しさん** · 2019/08/03(土) 15:03:33.81

>>840
> まあ形式はyamlでなくてもいいけどyamlが妥当だろ

YAMLが妥当かどうかの話じゃなくて、ネイティブの設定ファイル形式を
第三者が作ったツールを使ってYAMLで書くのがアホだっていってるんだよ。

なぜかと言うと信頼性がないから。YAMLで書いたものが
本当に設定ファイルに正しく反映されているのか？
新しい機能に対応できてるのか？トラブルが合ったときその原因はどこにあるのか？
新たな問題が起きる層を増やしているだけ

設定ファイルの形式はなんだって良いだろ。設定項目の意味を覚えるのは
どっちだって同じことで、YAMLかそれ以外かの「形式」を覚えるのはなんの苦労もない

> それにまとめてもファイルは分割されてるだろ
じゃあ一つのファイルに、特定の区切り文字で区切って、結合すれば？

必要なのは、その結合設定ファイルの分割を「サポート」するツールであって
YAML以外の設定ファイル形式を理解できない
（からネイティブの設定ファイルが読み書きできず、トラブルがあってもYAML経由じゃなきゃ対応できない）
ような初心者のためのツールじゃないだろ

> たまにオリジナル形式で作っちゃうバカがいるから呆れる
suprvisorの作者にでも言ったら？僕はYAML形式でしか設定ファイルを読み書きできないので
YAML形式に対応してくださいってｗ

**デフォルトの名無しさん** · 2019/08/03(土) 17:32:10.41

そういうのまだ生き残ってたのか。
新規のDSLは否定しまくるくせにMakefileは不問だったりするんだよな。

**デフォルトの名無しさん** · 2019/08/03(土) 18:19:12.64

1. DSLの話はしていない
2. Makefileは用途が違う
3. お前はMakefileも否定してるのか？

**デフォルトの名無しさん** · 2019/08/03(土) 19:02:06.52

>>841
信頼性に対する考察が足りんな
抽象化と記法の統一化で設定が簡単になる
ということはミスが減るんだよ
広く使われるラッパーが間違えるより人が間違える確率の方が高い
トータルで見ると信頼性が上がる
プログラム書いてる人間なら自然とこういう考え方が身につく筈なのだがね？
君はアセンブラで何でも書いてしまうタイプなのかな？

形式を覚えるのは面倒だ
君が何と言おうとね

区切り文字で結合w
勢いで書いちゃったけど流石に自分でもこれはないわーあーやっちゃった、とか今、思ってるでしょ？

オリジナルってのは広く普及してないフォーマットの事な
別にyamlには限らないよ
jsonでもxmlでもね

**デフォルトの名無しさん** · 2019/08/03(土) 19:06:12.83

ところで君はネイティヴにこだわってるけど
ということはDockerネイティヴのコンテナ内プロセス管理の仕組みを用意した方が良いということになるな
馬の骨が作ったサードパーティツールよりネイティヴサポートの方が良いのは確かにそうだね

**デフォルトの名無しさん** · 2019/08/03(土) 19:25:54.27

> 抽象化と記法の統一化で設定が簡単になる
> ということはミスが減るんだよ

イミフ。アプリが要した設定方法を使うほうが
一番広く使われてる方法で、一番設定が簡単だろ

お前アプリのドキュメント読んでるか？
そのアプリのドキュメントにどういうやり方で
設定しろって書いてあるよ？

> 勢いで書いちゃったけど流石に自分でもこれはないわーあーやっちゃった、とか今、思ってるでしょ？

俺が言ったことを復唱するだけで、何一つ反論しないのなｗ

> ところで君はネイティヴにこだわってるけど

アプリのドキュメント通り。公式にやり方のことだが？
Dockerで言えばDockerfileを使ったやり方。

一番広く使われてるだろうが。

**デフォルトの名無しさん** · 2019/08/03(土) 20:16:39.33

>>846
イミフというならプログラム書いたことないのだな
アセンブラおじさんと呼ぼう

**デフォルトの名無しさん** · 2019/08/03(土) 20:17:37.72

>>847
なんかレスしろよｗ

**デフォルトの名無しさん** · 2019/08/03(土) 20:20:07.16

>>846
でそのDockerfile使った方法がクソッタレだから馬の骨がサードパーティツールとか使い出してしまった
これは明らかに公式の失態だな
さっさとマルチプロセス管理の仕組みを提供すべきだった

**デフォルトの名無しさん** · 2019/08/03(土) 20:20:28.44

>>848
なんかレスしろよw

**デフォルトの名無しさん** · 2019/08/03(土) 20:22:53.38

> でそのDockerfile使った方法がクソッタレだから馬の骨がサードパーティツールとか使い出してしまった

あぁ、出すやつは出すだろうな。
んで、使われてるのか？ｗ
誰も使わんだろ

**デフォルトの名無しさん** · 2019/08/03(土) 20:23:18.20

>>850
> なんかレスしろよw
お前がなにか意味があることを言ってないのに
何にレスしろと？

**デフォルトの名無しさん** · 2019/08/03(土) 20:26:50.56

結局、YAMLから公式設定ファイルへのコンバーターを使った所で
何もメリット無いわけ

みんな公式の設定ファイルを読み書きできるだろ？
（できなかったらどうやってそのアプリの動作検証をやったというのか？）

公式のドキュメントを見て、使い方を覚えて、

さあ、あとはYAMLから変換するツールの使い方の勉強だ！
対応表見るぞー！あれがこれに対応してぇ、こう書けば、こういう設定ファイルが出力されてぇ
こういう設定するにはYAMLでどう書くんだ！くそーうまく出力されない！

何がしたいのかさっぱりわからない

**デフォルトの名無しさん** · 2019/08/03(土) 20:31:39.00

>>852
セルフカウンター乙

>>853
そこから間違ってるよ
公式見なくてもできるのが優れたラッパーだ
1対1で変換しただけのような二流ラッパーの話はしていないので謹め

**デフォルトの名無しさん** · 2019/08/03(土) 21:02:22.94

> 公式見なくてもできるのが優れたラッパーだ

お前の言う優れたラッパーってどれよ？ｗ
それは一対一で変換しないんだろ？
そのラッパーにはラッパー特有のトラブルや制限が一切ないんだろう？
さて、優れたラッパーなんて存在するかなーｗ

**デフォルトの名無しさん** · 2019/08/03(土) 21:06:50.88

例えばAnsibleの酷さは、これを見れば一目瞭然

https://github.com/ansible/ansible/issues
3959 Open 19874 closed

バグのみに限ってもこんなにある
https://github.com/ansible/ansible/issues?q=is%3Aissue+is%3Aopen+label%3Abug
2451 Open 12250 Closed

こういうのと戦っていなくてはいけないわけだ

**デフォルトの名無しさん** · 2019/08/03(土) 21:06:56.28

>>853
某エディタのAnsible拡張を導入したらオートコンプリートが効いてこりゃ便利！と感じたがメリットじゃなかったのかコレ？

**デフォルトの名無しさん** · 2019/08/03(土) 21:11:51.11

Dockerfileヤダヤダ。でAnsibleを使うのだろうが、

https://docs.ansible.com/ansible/latest/modules/docker_image_module.html#docker-image-module

ところでマルチステージビルドはどうすればいいのかね？

Dockerfileでマルチステービルドをする方法はいくらでも見つかる。
Ansibleでそれをどうやるのか？を悩むんだろう？ｗ

**デフォルトの名無しさん** · 2019/08/03(土) 21:14:05.18

>>857
オートコンプリートなら別にAnsibleとは無関係に使える。
例えばDockerfileのオートコンプリートだって存在する。

まああれも第三者が作ってるから、公式のバージョンアップに
ついていけないところがあったりで不完全なところがあるんだが、
オートコンプリートなら補完されないってだけで別に大きな問題にはならんな

**デフォルトの名無しさん** · 2019/08/03(土) 21:17:17.90

>>855
極論マンw
一切ないとか言ったら何も使えんわ
お前本当にエンジニア？
世界中で実践運用耐えうるぐらいには問題なく使えるよ

>>856
お前は全てのバグを踏み抜く奇跡の体現者かよw
実際に遭遇して問題が表面化して解決もできないなんてバグは滅多にない
ラッパーなら迂回路はいくらでもあるからな
お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな

**デフォルトの名無しさん** · 2019/08/03(土) 21:22:16.09

> 一切ないとか言ったら何も使えんわ

だからそういう間に入って変換するだけのものは
使わないほうが良いって言ってんだろ

公式が提供している、標準のやり方を使えばいいだけ

> お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな
本家がバグってるのをラッパーで回避できるわけ無いだろｗ
もし回避する方法があるなら、その方法をラッパーを使わずにやればいいだけだし

俺が言ってるのは公式が提供している標準のやり方をしろというだけ
間に変な変換ツールを入れて、その制限にぶち当たって悩まなくて良くなる

**デフォルトの名無しさん** · 2019/08/03(土) 21:26:30.12

そのうちプログラミングもYAMLで書きたいとか言い出しそうなんだよなｗ

**デフォルトの名無しさん** · 2019/08/03(土) 21:31:23.14

>>858
buildargsを使う
修正してモジュールにコミットする
シェル系モジュールを使う

回避する方法がいくらでもあるから安心だなぁ

**デフォルトの名無しさん** · 2019/08/03(土) 21:32:02.04

>>859
他のツールは？
カバー範囲狭すぎだろw

**デフォルトの名無しさん** · 2019/08/03(土) 21:37:49.05

>>861
飛行機落ちるかも怖いから乗らないって駄々こねる子供と同じだなこりゃ
大人はメリットもリスクも比べて飛行機に乗る

なんかあったら打つ手なしの飛行機じゃねえんだからリスクはさらに安く見積もって良い
ちょっとでもリスクあったら全否定ってw
本当にアセンブラマンなのかこいつ
今はまだある程度正気のようだがそのうちコンパイラも信じないとか言い出しそうだ

**デフォルトの名無しさん** · 2019/08/03(土) 22:09:24.60

>>863
お前の仕事は、回避することかｗ

>>865
間に挟めてトラブルを引き起こすツールに
メリットなんか無いじゃんｗ

**デフォルトの名無しさん** · 2019/08/03(土) 22:10:17.26

なんども言うが、公式のやり方をすれば
間に挟めるツールのトラブルがまるまるなくなる

非公式のやり方じゃなくて、公式のやり方をしろと言ってるだけ

**デフォルトの名無しさん** · 2019/08/03(土) 22:10:46.33

あとアセンブラとコンパイラは全然意味が違うので話にならない

**デフォルトの名無しさん** · 2019/08/03(土) 22:26:01.09

>>866
仕事は別だ
ごく稀に回避が必要な時にわずかな労力で回避するというだけのことだ
たったそれだけの事を過剰に恐れて便利なツールが中でやってることを全部自前でやるなんてよっぽど暇なのかな
まあ車輪の再発明も仕事といえば仕事か

**デフォルトの名無しさん** · 2019/08/03(土) 22:27:55.21

>>867
省力化やメンテナンス性の向上もまるまるなくなるな

>>868
たとえとしては十分だ

**デフォルトの名無しさん** · 2019/08/03(土) 22:56:40.59

> たとえとしては十分だ

的外れだからな。
所詮「第三者が作った設定ファイル形式のコンバーター」は
トラブルが起きたら変換後のオリジナルの設定ファイルを見なければ話にならん

**デフォルトの名無しさん** · 2019/08/03(土) 22:57:33.53

> たったそれだけの事を過剰に恐れて便利なツールが中でやってることを

ん？それってシェル系モジュール＝シェルスクリプトでできる程度のことでしょ？ｗ

**デフォルトの名無しさん** · 2019/08/03(土) 23:06:48.06

>>871
外れてないぞ
お前の意見は「データを抽象化、容易化するのは無駄(実際には無駄じゃなくメリットはある)で変換器の変換バグがあるかもだからアトミックなまま使え」だからな
機械語コードとコンパイラにもピタリと当てはまるな

**デフォルトの名無しさん** · 2019/08/03(土) 23:10:57.32

>>872
それってアセンブラでもできることでしょう？

ただ出来ると簡単に出来る、うまく出来るは違うことなんだな
だから高級言語が発達した

設定も同じことだ

**デフォルトの名無しさん** · 2019/08/04(日) 01:24:31.62

>>873
俺の意見を間違えてるｗ

「不要な第三者が作った質の悪く機能不足な変換ツールを使わずに
アプリの開発者の想定通りの使い方をしろ」が俺の意見だ

**デフォルトの名無しさん** · 2019/08/04(日) 01:25:43.22

>>874
設定ファイルは同じじゃない。

YAMLで設定を書いたら、できることが減ってバグが増えてる。
それに対してメリットがない。

**デフォルトの名無しさん** · 2019/08/07(水) 02:02:44.08

長いので2つに分割します。(1/2)

toolboxからコンテナを作れたまでは良いのですが、共通ファイルを作った上で、
コンテナ内のディレクトリにcreate-react-appでunk20というReactディレクトリを生成しようとしても、エラーが表示されで作れなくなりました。
途中まではWindowsの方の共通フォルダdocker-common内にunk20というフォルダが生成されているのですが、
以下のコードのnpm ERR!が出るとunk20フォルダごと削除され消えてしまいます。
ちなみに、共通フォルダを設定していない状態ですと、create-react-appでReactディレクトリはちゃんと作られ、localhostで接続すると問題なくブラウザにも表示されます。
node.jsとnpmは最新版にしております。

**デフォルトの名無しさん** · 2019/08/07(水) 02:03:07.70

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ディレクトリが削除される）

**デフォルトの名無しさん** · 2019/08/07(水) 02:03:56.17

最後までお読みいただきありがとうございました。
どなたかわかるかたいらしたら宜しくお願い致します・・・。

**デフォルトの名無しさん** · 2019/08/22(木) 22:54:02.06

すごいなWindowsでdocker使う人が居るんか

**デフォルトの名無しさん** · 2019/08/22(木) 23:05:23.65

むしろwindowsだからこそありがたい

**デフォルトの名無しさん** · 2019/08/22(木) 23:06:47.55

>>880
普通に使ってるけど？

**デフォルトの名無しさん** · 2019/08/23(金) 06:33:41.15

MacのDockerって仮想マシンで動いてるんだなー

**デフォルトの名無しさん** · 2019/08/23(金) 12:03:35.29

Docker for windowsは便利だけどwindowsコンテナは全く使ってない

**デフォルトの名無しさん** · 2019/08/24(土) 11:10:34.44

helmのテンプレートってすごく汚くて読みにくい
うまくYAMLにするためにインデント数を`Indent 12`みたいにしてテンプレートで指定とか正気かよ
なんか良い代わりのやつ無いの？

**デフォルトの名無しさん** · 2019/08/25(日) 00:00:48.85

helmはなんかなじめなくてkustomize使ってる

**デフォルトの名無しさん** · 2019/08/25(日) 00:10:10.89

クソトメライズ？

**デフォルトの名無しさん** · 2019/08/25(日) 00:58:14.70

臨時雇い要員にもdockerを使わせたいのだけどよけいな権限は与えたくない時はどうすればいい？
ホストもコンテナ内も一般ユーザーのみ許可できればいいのだけどそんなことできんのかね

**デフォルトの名無しさん** · 2019/08/25(日) 03:53:54.44

>>888
その臨時雇い要員に専用のパソコンを与えれて
そのパソコンは自由に使っていいけど、本番環境へのアクセスは禁止すればいい

**デフォルトの名無しさん** · 2019/08/25(日) 07:11:30.55

>>889
仮想端末を含めて専用のPCを用意することが出来ません
複数名でログインする端末です
機密情報を扱う別のユーザーと共有してます

**デフォルトの名無しさん** · 2019/08/25(日) 07:27:40.02

> 仮想端末を含めて専用のPCを用意することが出来ません

言い換えると、あなたの会社でまともな開発はできません。ということ
自分で、まともな開発はできないと結論を出してるんだから、そこで終わりだろう。

**デフォルトの名無しさん** · 2019/08/25(日) 07:29:21.71

だいたい、専用のPCを用意できないって
単に金が無いって言ってるだけじゃないか

金がないです。どうしたらいいですかと言われても
借金でもすれば？で終わる話

**デフォルトの名無しさん** · 2019/08/25(日) 07:38:33.38

給料を出だないほど金がないなら話は別だが
パソコンなんて数万円程度で買えるのにのに「できない」
なんてことはありえない。ようするにやる気がないだけ。

言葉は正しく使え。専用のPCを用意することができないんじゃなくて
専用のPCを用意したくない。が正しい言葉だ。

機密情報も、適当でいいって思ってるだろ。
機密情報に関してきっちりしているなら専用のパソコンに物理的に分ける。
パソコンがとても高価だった時代ならまだしも、今の時代に複数で共有なんて危険なことはしない。
個人専用のパソコンを与えてない時点で、セキュリティはザルでしかない。

自己を認識してないようだからはっきり言ってやる。
お前のところは機密情報を扱う資格がないし、守ることすら出来ない。
大切なものを守る意識も欠けてるし、やるべき正しいこともわかっていない。
今何も問題が起きてないのは運がいいだけだ。

**デフォルトの名無しさん** · 2019/08/25(日) 07:42:07.89

あなたの知る限り技術的には不可能ということでしょうか？

**デフォルトの名無しさん** · 2019/08/25(日) 07:45:18.41

>>894
例えば10階建てビルを作る技術はある。
みんなそれを作るための技術と道具を持ってる。

お前は、クレーンがないんです。
技術的に不可能ということでしょうか？と聞いてる。

技術的に不可能じゃなくて、クレーンを買うことができないことが
出来ない理由だっていってんの。ちゃんと認識しろって

**デフォルトの名無しさん** · 2019/08/25(日) 07:46:47.45

目的を達成する方法はいくつもあるが
「金が無い」なら、無理じゃねと言うしか無い

**デフォルトの名無しさん** · 2019/08/25(日) 08:00:05.20

つまりわからないということですね？

**デフォルトの名無しさん** · 2019/08/25(日) 12:49:41.65

何だこいつ

**デフォルトの名無しさん** · 2019/08/25(日) 12:59:09.23

イキってるくせに質問には答えられないクズってたまに居るよねぇ

**デフォルトの名無しさん** · 2019/08/25(日) 13:30:52.18

お前のこと云ってんだよ

**デフォルトの名無しさん** · 2019/08/25(日) 13:35:48.58

言われてるぞお前くん

**デフォルトの名無しさん** · 2019/08/26(月) 00:04:01.79

個人でDockerを入れてそこで自己完結させればいいだけだろ。サーバーからコンテナのコピーで済む話。

buildをユーザ権限でやるならk8sの使えば行けるが、会社と担当者のITリテラシーレベル低そうだし諦めればw

**デフォルトの名無しさん** · 2019/08/26(月) 00:50:09.55

>>902
セキュリティやってる気になってる会社には無理だろ
機密情報を扱う別のユーザーと共用してるパソコンなんて
正気の沙汰じゃない。どうせアップデートもしてないだろうし。
セキュリティ意識ゼロ

**デフォルトの名無しさん** · 2019/08/26(月) 01:31:32.75

コンテナ内というのが意味不明だな。
ビルドでユーザー作れば当然管理者権限なしでも入れるが、dockerでやる事なのだろうか。

中に入る→出来る
ビルド→出来る
docker コマンド→別グループ作れば可能だが実質su

dockerはアプリ動かすツールであって、管理者以外が共有PCで立ち上げ必須な用途には向かない。巻き添えで常駐コンテナに影響するからだ。

PCに入ったあと、Dockerコマンドで機密情報を操作するコンテナを動かすルールなのだろうか。

企業によくいる、自分は詳しいと思いたい素人が管理してる感溢れていて良い。

**デフォルトの名無しさん** · 2019/08/26(月) 02:35:23.25

>>904
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」

これだけ

**デフォルトの名無しさん** · 2019/08/26(月) 02:35:28.97

>>904
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」

これだけ

**デフォルトの名無しさん** · 2019/08/26(月) 06:29:32.37

お前らってわからない時の言い訳はいつも饒舌だよねぇ
質問には答えられないくせにさw

**デフォルトの名無しさん** · 2019/08/26(月) 06:47:45.57

言い訳というのはちょっと違ったか
わからないことを誤魔化すためのマウンティングになると饒舌
これが正確だな

**デフォルトの名無しさん** · 2019/08/26(月) 08:28:14.69

>>907
>>904に答え書いたでしょ。
buildの方はk8sやローカルリポジトリがいるのでかなり難易度高め。k8sが管理者権限だと無理だな。

ユーザー作る方は難しくない。

rootが嫌ならユーザーをdockerに入れると良い。実質suだが。他は不可能。

上2つはdockerfile書けるのが前提で、ここに書いて済むレベルの話ではない。

頑張れw

**デフォルトの名無しさん** · 2019/08/26(月) 08:43:07.72

権限ちゃんと分けたかったら
Dockerじゃなくて普通にVM使うべき。
メモリーの必要量は増えちゃうけど。

**デフォルトの名無しさん** · 2019/08/26(月) 12:49:17.98

「VM使ってもroot使ったダメなんですー」
「個人にパソコンを与えたとしてもrootは禁止なんですー」
「うちってセキュリティしっかりしてるでしょ？」

**デフォルトの名無しさん** · 2019/08/26(月) 15:55:14.47

>>909
呆れる
k8sの話はしてないしローカルDockerの話してんの
ユーザーDockerに入れても意味ないだろ

>>910
業務上の都合で使えません

>>911
答えられないなら無理してレスしないでいいぞ？
見ててちょっと気の毒だ

**デフォルトの名無しさん** · 2019/08/26(月) 15:58:57.84

× 業務上の都合で使えません
○ 業務改革したくないです。やる気ないです。