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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2017/02/16(木) 18:01:04.48ID:rGWDv0Eb
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう

よろしこ
2019/06/07(金) 00:14:22.59ID:AQMF0uU1
× コンテナは仮想マシンの代替にはなりえない
○ （アプリケーション）コンテナはそもそも仮想マシンの代替として作られたものじゃない
2019/06/07(金) 00:20:56.20ID:ON5ugDpH
>>757
組み合わせて使っても良いが
常に組み合わせて使う前提のものではない

>>758
だから君のDocker万能論はちゃんちゃらおかしいということだよ
開発環境は開発対象をよく理解して適切に選ぶこと
全部DockerでOKなんてことはありえない
2019/06/07(金) 00:32:52.21ID:AQMF0uU1
あぁ、なるほど。素晴らしい気付きがあった。

Ansible（Chefなども同様だろう）を使うといった時、
playbookを作る のと playbookを実行する という2つの段階がある

playbookを作る場合は、当然テストが必要なわけだがVagrantが便利。
なぜならVMを特定の状態にして何度もplaybookをやり直すから。
具体的にはsnapshotの機能を使う（最初からvagrant boxを作り直すのもあり）

でもこれって、Ansibleに内蔵されているべき機能ではないだろうか？
Vagrantで作るVMと本番環境のVMは違っている。
本当は本番環境（を複製して）を何度も同じ状態にしてテストを実行したいはずだ
通常、本番環境のVMの構築にVagrantは使わない。Ansibleを使って構築するだろう。
ならば、Ansibleだけで本番環境のVMのスナップショットを取れたほうが良いだろう。

今はそれが出来ないからVagrantを使っている。
なるほど、これは良い発見だ！

（独り言）
2019/06/07(金) 00:33:40.26ID:AQMF0uU1
>>759
> だから君のDocker万能論はちゃんちゃらおかしいということだよ

何度もDockerとVMは組み合わせて使うって言ってるのに、
なんで俺のことをDocker万能論者に仕立て上げようとすんのさ？
2019/06/07(金) 00:34:23.77ID:AQMF0uU1
> 全部DockerでOKなんてことはありえない

そんなこと言ってない。

何度も何度もVMと組み合わせて使うって言ってるのに
2019/06/07(金) 00:45:32.53ID:ON5ugDpH
そうだな万能論は言いすぎた
しかしそれでも君の主張はDockerありきが前提にっているのは確かだろ
しかし実際にはAnsibleの例のようにDockerを使いにくい環境も存在している
だから君の主張がおかしいということには変わりはない
2019/06/07(金) 00:53:40.24ID:AQMF0uU1
>>763
やっぱり素でDockerを理解してないんだな・・・

> しかし実際にはAnsibleの例のようにDockerを使いにくい環境も存在している
Dockerはアプリケーションとユーザーランドを一体化させて
一つのアプリケーションのように仮想化するためのものであって
Ansible（構成管理ツール）とDocker（アプリ仮想化）を組み合わせて使うことがそもそも間違い。

俺はAnsibleとDockerを組み合わせて使うなんて一言も言ってない。
俺の主張？俺が何を主張したっていうんだ？
2019/06/07(金) 00:57:44.41ID:AQMF0uU1
>>764の組み合わせて使うっていうのは、

DockerをVM（Vagrant）のようの代わりに使って
DockerでAnsibleなど構成管理ツールの開発・テスト環境を作るという使い方

Ansibleを使ってVMの構成管理を行い、その一つとして
Dockerコンテナを起動するっていう使い方は問題ない。


俺は、DockerでAnsibleなど構成管理ツールの開発・テスト環境を作るという使い方をしろなんて
一言も主張していない
2019/06/07(金) 01:00:45.47ID:AQMF0uU1
結局俺じゃなくてお前が

DockerをVM（Vagrant）の代わりに使おうとして
DockerはVM（Vagrant）の代わりとしては使えない！って
独り相撲してるだけじゃんか

俺は最初から組み合わせて使う。両方使う。役割が違うと言ってる。
2019/06/07(金) 01:01:19.38ID:ON5ugDpH
>>764
君の主張は自分のレスを読み返したら？
開発環境はとにかくDocker
Dockerなしなんてありえない
それが世界の常識
君は昨日散々そう主張していたよね
そんな主張をしたら例えばAnsibleの開発環境みたいなDockerに向かない環境もDockerで組むのかなこいつはと解釈されても仕方がないよ
2019/06/07(金) 01:02:31.60ID:AQMF0uU1
>>767
お前が見返して、どこで言ってるのか指摘してくれ
俺はお前が言ってることを何一つ主張してない
2019/06/07(金) 01:03:25.33ID:ON5ugDpH
>>768
ID: XICm〜のレスを読み返して
2019/06/07(金) 01:04:03.86ID:AQMF0uU1
例として一つ出すなら

>>737で
> 開発環境はVagrantで作るが本番環境はAnsibleなどで作る

開発環境はVagrantで作るとはっきり言っている
2019/06/07(金) 01:05:19.99ID:AQMF0uU1
>>769
だからそれをお前がやれって言ってる。
お前嘘つきじゃん。さっきからどれもコレも俺が主張してないことを
俺が言ったことにしようとしてさ
2019/06/07(金) 01:07:46.29ID:ON5ugDpH
>>770
で、そのレスの後半でDockerを使う話に持っていってるよね
とにかくDocker
Dockerありき
それが世界の常識
それが君の主張
2019/06/07(金) 01:09:11.49ID:AQMF0uU1
> で、そのレスの後半でDockerを使う話に持っていってるよね

ぽかーんｗ

スレの前半でDockerを使わない話してるよね？
お前、スレの後半しか読んでないの？
スレの後半だけで判断しちゃった？ｗ
2019/06/07(金) 01:10:05.02ID:ON5ugDpH
>>771
やれもクソも君の目の前のブラウザか専ブラかをちょっとスクロールして見るだけだよ
俺がやることなど何もなく君が自分のレスを見るだけだ
それを俺が代行してやることは物理的にできない
2019/06/07(金) 01:11:18.46ID:AQMF0uU1
>>774
それで？
2019/06/07(金) 01:12:44.93ID:ON5ugDpH
>>773
後半を主張するための前振りだろ？
だって君の主張はDockerありきが世界の常識だもんな
2019/06/07(金) 01:14:11.19ID:AQMF0uU1
>>776
何度も何度も何度もVMとDockerは組み合わせて使うと言ってる

お前が、VMとDockerはどちらか一つを排他的に使うものだって
心の底で思ってるから、俺がDockerを使うという話をすると
VMを使わないと言ってるんだって勘違いしてるんだよ。
2019/06/07(金) 01:17:08.93ID:ON5ugDpH
＞もう今は本番環境でDockerを使うのは常識
＞
＞仮に本番環境でDockerを使わないとしても、
＞本番環境と同じ環境をDocker以外で作るのは困難
＞
＞開発環境用VM（Vagrant）と本番環境用VM（Vagrant）の
＞２つを作るのは重いだけ

ほーん
Ansibleの本番環境と同じ環境もDockerで作るんだ
なんたってDocker以外で作るのは困難だからなー
それが世界の常識ってやつですかそうですか
2019/06/07(金) 01:17:57.25ID:AQMF0uU1
> Ansibleの本番環境と同じ環境もDockerで作るんだ

また俺が言ってないことを言い出した。
2019/06/07(金) 01:19:09.37ID:ON5ugDpH
>>777
VMを使わないことではなくDockerを使うことが前提になっている点がおかしいと言ってる
2019/06/07(金) 01:21:29.74ID:ON5ugDpH
>>779
言っているも同然なんだよね
2019/06/07(金) 01:25:19.32ID:ON5ugDpH
>>778
やっぱりこの辺りは反論不能なんだな
2019/06/07(金) 01:36:24.78ID:AQMF0uU1
>>780
本番環境を同じ環境をローカルに作る場合
Dockerを使った構成にしないと作るのは困難だって言ってる

本番環境（の多くは）ベアメタルもしくは仮想マシンにLinuxを入れる
ローカルの開発環境はベアメタルにLinuxを入れることは少ない

ローカルの開発環境は
1. Linuxを使う
2. macOSを使う
3. Windowsを使う
4. それ以外

この三種類。2と3は確実に本番環境と違う。1はLinuxで同じだが
ローカルの開発環境には開発ツールが必要なので、これも本番環境と同じになることはない

4.のそれ以外として、1〜3の開発環境を使い、それとは別に本番環境"再現用"VMを作る方法
>>742で書いているように、２つを作るのは重いだけ
そして本番環境はVagrantを使って作らないが、本番環境"再現用"VMはVagrantを使って作るという違いがある
本番環境"再現用"VMをVagrantを使って作ると、Vagrantユーザーがいたりして、本番環境とはやっぱり違う
作成した時期によってパッケージのバージョン等が異なる。
本番環境はVagrantじゃないから同じVagrant Boxを使って環境を合わせることも出来ない。

本番環境のベアメタルもしくは仮想マシンにLinuxを入れて作るものに近づけるには
ローカルの開発環境に用意する 本番環境"再現用"VMも（Vagrantを使わずに）
VirtualboxやKVmやHyperVなどの上に直接作る必要がある。
だけどそれをやったとしてもやっぱりパッケージのバージョンを合わせるのは難しい。

その問題をDockerを使った構成にすることで違いをカーネル部分（ここは高い互換性がある）だけに分離することができる。
カーネル以外のアプリケーション＋ユーザーランド、つまりパッケージのバージョンは全く一緒になる
このレベルを実現するにはDockerを使わないと困難だと言ってる
2019/06/07(金) 01:37:41.38ID:AQMF0uU1
>>782
何に反論すれば良いのさ？ｗ
お前の書いた嘘？
785デフォルトの名無しさん
垢版 |
2019/06/07(金) 12:34:44.50ID:Ka/jlwAK
ぬるぽ
2019/06/07(金) 22:36:12.94ID:hLrjlnDV
がっ
2019/06/07(金) 22:55:03.79ID:wtNNzOUb
そのゲームのプロセスID か何かを取得して、

OS・ディスプレイマネージャーに対して、
そのゲームを最前面に表示するように、命令できないの？
788787
垢版 |
2019/06/07(金) 22:56:06.04ID:wtNNzOUb
>>787
誤爆です！
789デフォルトの名無しさん
垢版 |
2019/06/22(土) 17:52:08.66ID:V6ijG4k6
dockerってメモリ4GB だと重いですか？docker使って仮想環境作る勉強したいんですが
2019/06/22(土) 18:00:43.74ID:rnpNzk5p
>>789
Linuxで使えば仮想マシンも不要でネイティブに動く
メモリも数MB程度のオーバーヘッドだけですむだろう
791デフォルトの名無しさん
垢版 |
2019/06/22(土) 18:43:07.03ID:V6ijG4k6
Windows環境なんでwslでubuntuはインストールしたんですけどそのままdocker落として仮想マシン構築する事出来ます？
2019/06/23(日) 08:00:41.13ID:P8H0jYp7
Windows 10デスクトップだと4Gは厳しい
仕事で仕方なく使ってるけどメモリ不足で起動失敗が多発する
Windowsコンテナのプロセス分離だけに限定すればいけるかもしれんが…
Winコンテナは興味なくて検証したこともない

WSLでDockerは動かない
次の大型アップデートでWSL 2が実装されるけどそっちではDockerも簡単に動かせる
Docker for WSL 2のサポートも決定事項
こっちの必要スペックはわからん
2019/06/23(日) 17:24:00.79ID:p0iHiqR8
今のvirtualbox使ったwindows dockerはクソだと思うが
Docker for WSL 2 は期待していいんでないかな。
2019/06/23(日) 18:27:13.63ID:oVYNIjpt
今のDocker for WindowsはVirtualBoxなんざ使ってねぇぞ
2019/06/23(日) 19:06:11.98ID:MSRPr+EY
Docker for Windowsも、Docker for Macも
どちらも仮想マシンを使っています
2019/06/24(月) 09:14:27.09ID:dhWW1aIx
virtualbox使ってるのはdocker toolboxの方
2019/06/26(水) 06:40:02.02ID:LU29nklf
てか現状、hyper-vない環境のが多い訳でwinでdockerいうたらそれだよね。
2019/06/26(水) 10:19:06.41ID:tKP4UJlx
10proに入ってんじゃん
2019/06/28(金) 05:11:22.48ID:tO2lJYIL
なるほど、10pro買えと。
800デフォルトの名無しさん
垢版 |
2019/06/28(金) 07:41:19.81ID:CM5w69Yd
wsl2のアーキテクチャ、hyper-v必須に見えるんだけどhome切り捨てか？
2019/06/28(金) 08:25:14.99ID:gNXTX/eF
はぁ、homeも対応するって発表しただろ
hyper-vのサブセットを提供するって。少しは調べろよ
802デフォルトの名無しさん
垢版 |
2019/06/28(金) 11:26:39.93ID:fSH27hWb
>>801
マジかサンキュー！
俺の調査完了だぜｗ
2019/06/29(土) 14:03:16.24ID:LzChV7lM
Windows10 Home
HP ENVY Ryzen7 3700U を使用しています。

https://dotup.org/uploda/dotup.org1884129.png
BIOSの方で仮想化設定をONにして、タスクマネージャーで確認しても「仮想化 有効」に
なっているのにかかわらず、Docker Quickstart Terminal を起動すると
「仮想化がenableになっていません。」とエラーが出て終了してしまいます。
どうすれば通常通り起動できるようになるでしょうか。
どなたか心当たりある方いらしたらお教えいただけないでしょうか・・・。
2019/06/29(土) 17:19:36.77ID:/BkVpaGH
>>803
Docker Toolboxは古い
Docker Desktop for Windowsを使え
2019/06/29(土) 18:13:54.06ID:/KvGohzC
HomeじゃHyper-V使えないし
2019/06/29(土) 19:25:19.90ID:8bAr7lLW
wsl2まで待つかwin10pro買うかどっちかを勧める。
807デフォルトの名無しさん
垢版 |
2019/07/06(土) 00:04:09.57ID:qTbAmWeM
dockerのimageファイルをブラウザからダウンロードできるサイトないですか？

特殊なインターネット接続なし環境で構築しており，インターネット接続環境はブラウザしか起動できない状況です。
2019/07/06(土) 04:45:25.56ID:O76mcSig
docker pullのプロトコルはhttpやろ
2019/07/06(土) 04:48:09.21ID:O76mcSig
っていうか、業務に必要なことなら、必要って言えばいいだろ
仕事で苦労してる責任が管理者にあるなら管理者に責任を押し付けろや。
コストがあがったのはあんたが認めないからです。責任はあんたにありますって
2019/07/06(土) 07:50:05.40ID:lAN9BSHL
小さい組織の末端の開発者ならそれでいいかもしれん
大きな組織だと特定の開発者のコストを下げても必ずしも全体のコストが安くなるわけではない
2019/07/06(土) 08:21:03.64ID:O76mcSig
大きな組織だと、その判断を末端の開発者がしてはいけない。

つまり、言いたいことは、"上に投げつける前に個人の判断で諦めるな" ということ

上に投げつけて、上の責任にするんだよ。
2019/07/06(土) 08:44:23.73ID:auWtVfNl
>811
理屈はわかるがそんなこと実際にするのはかなり丁寧に組織的根回ししないと無理だろ。
そんなことができるくらいならこんなとこに相談こねーわ。
2019/07/06(土) 09:12:48.48ID:O76mcSig
イミフ。上に言うだけやろ。こういうことで困ってますって。
2019/07/06(土) 09:17:32.46ID:lAN9BSHL
小さい組織でやってるとこういう苦労はわからないものさ
責任が小さいから自由もある
2019/07/06(土) 09:23:00.60ID:O76mcSig
だーかーら、上に相談することも出来ないのか？って言ってるんだが
2019/07/06(土) 10:25:15.17ID:auWtVfNl
>>813
お前がそれで解決しないという現実を知らんだけ。
2019/07/06(土) 11:40:56.15ID:O76mcSig
解決するかしないかは関係ないんだよ。
上の責任にしろって話。

責任を押し付けないから、上は適当に仕事するんだよ。
おめぇの責任だって言えば上は逃げられなくなるからな。
2019/07/06(土) 11:49:06.19ID:lAN9BSHL
与えられた裁量の中で成果を出すことが求められている
もっと権限をよこせよこさないならうまくいかないぞそうなったらおまえのせいだかんななどと喚くのは無能だ
組織で働いたことがねえんだろうなあ
2019/07/06(土) 13:09:27.76ID:O76mcSig
> 与えられた裁量の中で成果を出すことが求められている

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

ほんとなぁ、日本の学校教育の失敗やで。
意味のないルールでも絶対に守れ。疑問を持つことは許さない
という教育をしてるからこうなる。
2019/07/06(土) 13:18:23.10ID:lAN9BSHL
末端の開発者が抱くような疑問はとっくに上が検討済み
それ以外の事も諸々含めて選んだ結果が末端の開発者に降りてくる
だから上からしたら責任はあんたにあります(キリッ)とか言われても何を言ってんだこの雑魚はとしか思えんよ
もともと責任ある立場なんだからさ末端の開発者と違って
2019/07/06(土) 13:27:42.39ID:O76mcSig
「末端の開発者が抱くような疑問はとっくに上が検討済み」
という思い込み

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

ルールの存在理由を考えない。
ルールを守ることが目的となってる。
2019/07/06(土) 13:32:36.26ID:lAN9BSHL
>>821
＞という思い込み
という末端の思い込み

＞ルールの存在理由を考えない。
小さい組織の末端で働くと組織視点でルールの存在理由を考えない
なので自分の都合・不都合だけ考えてルールを否定したがる
2019/07/06(土) 13:43:30.71ID:O76mcSig
> なので自分の都合・不都合だけ考えてルールを否定したがる

当たり前だろｗ
言わなくても、他人が自分の都合をわかってくれるとでも思ってんのか？
2019/07/06(土) 13:58:40.05ID:lAN9BSHL
上は末端の開発者が考えることぐらいはだいたいわかってるよ
わかった上で様々な要素を検討して
開発者には悪いけど多少苦労してもらい集団としての利を取ろうと決定したの
末端の意見なんてのは上から見るととっくに処理済なんだよ
蒸し返されても困る
2019/07/06(土) 14:51:35.13ID:O76mcSig
> 蒸し返されても困る

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

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

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

理由が書いてない校則が多い
2019/07/06(土) 14:57:30.90ID:lAN9BSHL
>>825
理由は上が管理してるから安心しなよ
2019/07/06(土) 15:20:41.61ID:FpOYjoW/
スレチ
2019/07/06(土) 21:48:53.04ID:auWtVfNl
上がそこまで理解力あったら7payみたいなことは起きんわ。
現実見ないと幸せそうでいいよね。
2019/07/06(土) 22:15:52.49ID:TeKNePWD
うちの会社もフィルタリングはされてるけど、
正当な理由つきで解除申請すればホワイトリストに登録してくれて
アクセスできるようになるよ。

合理的判断のできる会社ならこれが当たり前だし
それができない会社にいるなら
奴隷の鎖自慢なんかしてないでさっさと転職した方がいい。
不合理がまかりとおるのが当たり前になった会社なんて
長期的に見れば没落するに決まってるから。
2019/07/06(土) 22:50:33.13ID:O76mcSig
せや、せーや（笑）
2019/07/17(水) 07:53:46.72ID:CjuPNITa
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.34ID:ycSiezB+
WindowsでVOLUMEは鬼門・・・

はいいとしてWORKDIRはDockerコンテナ内のパス。
単にalpineの中でmkdirしてcdしてるようなもんだよ。
だからWindowsなんて関係ない。DockerfileはどのLinuxでもMacでも同じものが
使えるんだから、そんなWindowsの固有の情報なんて出てこない
2019/07/19(金) 03:11:40.54ID:X9aaaJRs
>>832
根本的な部分を忘れていました・・・全てDocker内のLinuxで完結しているのですね
ちゃんと作れるようになりました
ありがとうございますm(__)m
2019/07/31(水) 22:03:01.15ID:2Qswnptj
Dockerってcron使えるようになりました？
前使ってた時は相性悪かったんですが
2019/08/03(土) 10:08:06.93ID:CPHAUpDJ
組み込み機能でコンテナ内部で走らせるプロセスをyamlで管理できたら便利だと思う(composeのような雰囲気で)
supervisorは設定ファイルiniでキモいしちょっとしたエントリー拡張のためにsupervisorやentrykitを入れるDockerfile書くのめんどくさいよ
2019/08/03(土) 12:03:27.90ID:eOXqQaf9
なんでもかんでも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.93ID:eOXqQaf9
あと supervisor が直接YAMLという設定ファイルに
対応するって話だったらなんの文句もないが、

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

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

なんでそうみんなYAMLで書いて第三者が作った変換フィルタのバグや非対応の項目で
悪戦苦闘したがるかね？ ネイティブの設定ファイルを使えばいいじゃん。
2019/08/03(土) 14:13:39.93ID:CPHAUpDJ
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.81ID:eOXqQaf9
> これをサポートなしでやろうとしたら結構めんどくさいよ

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

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


> 同じ形式で書けるほうがいい
理由は？
2019/08/03(土) 14:42:55.01ID:CPHAUpDJ
>>839
まあ形式はyamlでなくてもいいけどyamlが妥当だろ
composeやswarm、k8sでも採用してるしdockerユーザーには馴染み深い

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

同じ形式で書ければ構文を覚えなくていいから楽だしプログラム的にも扱いやすくなる
広く普及してるフォーマットなら形式が違くてもまだマシだが
たまにオリジナル形式で作っちゃうバカがいるから呆れる
2019/08/03(土) 15:03:33.81ID:eOXqQaf9
>>840
> まあ形式はyamlでなくてもいいけどyamlが妥当だろ

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

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

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

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

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

> たまにオリジナル形式で作っちゃうバカがいるから呆れる
suprvisorの作者にでも言ったら？僕はYAML形式でしか設定ファイルを読み書きできないので
YAML形式に対応してくださいってｗ
2019/08/03(土) 17:32:10.41ID:6VgdIlHS
そういうのまだ生き残ってたのか。
新規のDSLは否定しまくるくせにMakefileは不問だったりするんだよな。
2019/08/03(土) 18:19:12.64ID:eOXqQaf9
1. DSLの話はしていない
2. Makefileは用途が違う
3. お前はMakefileも否定してるのか？
2019/08/03(土) 19:02:06.52ID:+6ISjjVu
>>841
信頼性に対する考察が足りんな
抽象化と記法の統一化で設定が簡単になる
ということはミスが減るんだよ
広く使われるラッパーが間違えるより人が間違える確率の方が高い
トータルで見ると信頼性が上がる
プログラム書いてる人間なら自然とこういう考え方が身につく筈なのだがね？
君はアセンブラで何でも書いてしまうタイプなのかな？

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

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

オリジナルってのは広く普及してないフォーマットの事な
別にyamlには限らないよ
jsonでもxmlでもね
2019/08/03(土) 19:06:12.83ID:+6ISjjVu
ところで君はネイティヴにこだわってるけど
ということはDockerネイティヴのコンテナ内プロセス管理の仕組みを用意した方が良いということになるな
馬の骨が作ったサードパーティツールよりネイティヴサポートの方が良いのは確かにそうだね
2019/08/03(土) 19:25:54.27ID:eOXqQaf9
> 抽象化と記法の統一化で設定が簡単になる
> ということはミスが減るんだよ

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

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

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

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

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

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

一番広く使われてるだろうが。
2019/08/03(土) 20:16:39.33ID:+6ISjjVu
>>846
イミフというならプログラム書いたことないのだな
アセンブラおじさんと呼ぼう
2019/08/03(土) 20:17:37.72ID:eOXqQaf9
>>847
なんかレスしろよｗ
2019/08/03(土) 20:20:07.16ID:+6ISjjVu
>>846
でそのDockerfile使った方法がクソッタレだから馬の骨がサードパーティツールとか使い出してしまった
これは明らかに公式の失態だな
さっさとマルチプロセス管理の仕組みを提供すべきだった
2019/08/03(土) 20:20:28.44ID:+6ISjjVu
>>848
なんかレスしろよw
2019/08/03(土) 20:22:53.38ID:eOXqQaf9
> でそのDockerfile使った方法がクソッタレだから馬の骨がサードパーティツールとか使い出してしまった

あぁ、出すやつは出すだろうな。
んで、使われてるのか？ｗ
誰も使わんだろ
2019/08/03(土) 20:23:18.20ID:eOXqQaf9
>>850
> なんかレスしろよw
お前がなにか意味があることを言ってないのに
何にレスしろと？
2019/08/03(土) 20:26:50.56ID:eOXqQaf9
結局、YAMLから公式設定ファイルへのコンバーターを使った所で
何もメリット無いわけ

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

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

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

何がしたいのかさっぱりわからない
2019/08/03(土) 20:31:39.00ID:+6ISjjVu
>>852
セルフカウンター乙

>>853
そこから間違ってるよ
公式見なくてもできるのが優れたラッパーだ
1対1で変換しただけのような二流ラッパーの話はしていないので謹め
2019/08/03(土) 21:02:22.94ID:eOXqQaf9
> 公式見なくてもできるのが優れたラッパーだ

お前の言う優れたラッパーってどれよ？ｗ
それは一対一で変換しないんだろ？
そのラッパーにはラッパー特有のトラブルや制限が一切ないんだろう？
さて、優れたラッパーなんて存在するかなーｗ
2019/08/03(土) 21:06:50.88ID:eOXqQaf9
例えば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.28ID:k1ZymNgl
>>853
某エディタのAnsible拡張を導入したらオートコンプリートが効いてこりゃ便利！と感じたがメリットじゃなかったのかコレ？
2019/08/03(土) 21:11:51.11ID:eOXqQaf9
Dockerfileヤダヤダ。でAnsibleを使うのだろうが、

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

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

Dockerfileでマルチステービルドをする方法はいくらでも見つかる。
Ansibleでそれをどうやるのか？を悩むんだろう？ｗ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況