仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう よろしこ 例として一つ出すなら >>737 で > 開発環境はVagrantで作るが本番環境はAnsibleなどで作る 開発環境はVagrantで作るとはっきり言っている >>769 だからそれをお前がやれって言ってる。 お前嘘つきじゃん。さっきからどれもコレも俺が主張してないことを 俺が言ったことにしようとしてさ >>770 で、そのレスの後半でDockerを使う話に持っていってるよね とにかくDocker Dockerありき それが世界の常識 それが君の主張 > で、そのレスの後半でDockerを使う話に持っていってるよね ぽかーんw スレの前半でDockerを使わない話してるよね? お前、スレの後半しか読んでないの? スレの後半だけで判断しちゃった?w >>771 やれもクソも君の目の前のブラウザか専ブラかをちょっとスクロールして見るだけだよ 俺がやることなど何もなく君が自分のレスを見るだけだ それを俺が代行してやることは物理的にできない >>773 後半を主張するための前振りだろ? だって君の主張はDockerありきが世界の常識だもんな >>776 何度も何度も何度もVMとDockerは組み合わせて使うと言ってる お前が、VMとDockerはどちらか一つを排他的に使うものだって 心の底で思ってるから、俺がDockerを使うという話をすると VMを使わないと言ってるんだって勘違いしてるんだよ。 >もう今は本番環境でDockerを使うのは常識 > >仮に本番環境でDockerを使わないとしても、 >本番環境と同じ環境をDocker以外で作るのは困難 > >開発環境用VM(Vagrant)と本番環境用VM(Vagrant)の >2つを作るのは重いだけ ほーん Ansibleの本番環境と同じ環境もDockerで作るんだ なんたってDocker以外で作るのは困難だからなー それが世界の常識ってやつですかそうですか > Ansibleの本番環境と同じ環境もDockerで作るんだ また俺が言ってないことを言い出した。 >>777 VMを使わないことではなくDockerを使うことが前提になっている点がおかしいと言ってる >>780 本番環境を同じ環境をローカルに作る場合 Dockerを使った構成にしないと作るのは困難だって言ってる 本番環境(の多くは)ベアメタルもしくは仮想マシンにLinuxを入れる ローカルの開発環境はベアメタルにLinuxを入れることは少ない ローカルの開発環境は 1. Linuxを使う 2. macOSを使う 3. Windowsを使う 4. それ以外 この三種類。2と3は確実に本番環境と違う。1はLinuxで同じだが ローカルの開発環境には開発ツールが必要なので、これも本番環境と同じになることはない 4.のそれ以外として、1〜3の開発環境を使い、それとは別に本番環境"再現用"VMを作る方法 >>742 で書いているように、2つを作るのは重いだけ そして本番環境はVagrantを使って作らないが、本番環境"再現用"VMはVagrantを使って作るという違いがある 本番環境"再現用"VMをVagrantを使って作ると、Vagrantユーザーがいたりして、本番環境とはやっぱり違う 作成した時期によってパッケージのバージョン等が異なる。 本番環境はVagrantじゃないから同じVagrant Boxを使って環境を合わせることも出来ない。 本番環境のベアメタルもしくは仮想マシンにLinuxを入れて作るものに近づけるには ローカルの開発環境に用意する 本番環境"再現用"VMも(Vagrantを使わずに) VirtualboxやKVmやHyperVなどの上に直接作る必要がある。 だけどそれをやったとしてもやっぱりパッケージのバージョンを合わせるのは難しい。 その問題をDockerを使った構成にすることで違いをカーネル部分(ここは高い互換性がある)だけに分離することができる。 カーネル以外のアプリケーション+ユーザーランド、つまりパッケージのバージョンは全く一緒になる このレベルを実現するにはDockerを使わないと困難だと言ってる >>782 何に反論すれば良いのさ?w お前の書いた嘘? そのゲームのプロセスID か何かを取得して、 OS・ディスプレイマネージャーに対して、 そのゲームを最前面に表示するように、命令できないの? dockerってメモリ4GB だと重いですか?docker使って仮想環境作る勉強したいんですが >>789 Linuxで使えば仮想マシンも不要でネイティブに動く メモリも数MB程度のオーバーヘッドだけですむだろう Windows環境なんでwslでubuntuはインストールしたんですけどそのままdocker落として仮想マシン構築する事出来ます? Windows 10デスクトップだと4Gは厳しい 仕事で仕方なく使ってるけどメモリ不足で起動失敗が多発する Windowsコンテナのプロセス分離だけに限定すればいけるかもしれんが… Winコンテナは興味なくて検証したこともない WSLでDockerは動かない 次の大型アップデートでWSL 2が実装されるけどそっちではDockerも簡単に動かせる Docker for WSL 2のサポートも決定事項 こっちの必要スペックはわからん 今のvirtualbox使ったwindows dockerはクソだと思うが Docker for WSL 2 は期待していいんでないかな。 今のDocker for WindowsはVirtualBoxなんざ使ってねぇぞ Docker for Windowsも、Docker for Macも どちらも仮想マシンを使っています virtualbox使ってるのはdocker toolboxの方 てか現状、hyper-vない環境のが多い訳でwinでdockerいうたらそれだよね。 wsl2のアーキテクチャ、hyper-v必須に見えるんだけどhome切り捨てか? はぁ、homeも対応するって発表しただろ hyper-vのサブセットを提供するって。少しは調べろよ >>801 マジかサンキュー! 俺の調査完了だぜw Windows10 Home HP ENVY Ryzen7 3700U を使用しています。 https://dotup.org/uploda/dotup.org1884129.png BIOSの方で仮想化設定をONにして、タスクマネージャーで確認しても「仮想化 有効」に なっているのにかかわらず、Docker Quickstart Terminal を起動すると 「仮想化がenableになっていません。」とエラーが出て終了してしまいます。 どうすれば通常通り起動できるようになるでしょうか。 どなたか心当たりある方いらしたらお教えいただけないでしょうか・・・。 >>803 Docker Toolboxは古い Docker Desktop for Windowsを使え wsl2まで待つかwin10pro買うかどっちかを勧める。 dockerのimageファイルをブラウザからダウンロードできるサイトないですか? 特殊なインターネット接続なし環境で構築しており,インターネット接続環境はブラウザしか起動できない状況です。 っていうか、業務に必要なことなら、必要って言えばいいだろ 仕事で苦労してる責任が管理者にあるなら管理者に責任を押し付けろや。 コストがあがったのはあんたが認めないからです。責任はあんたにありますって 小さい組織の末端の開発者ならそれでいいかもしれん 大きな組織だと特定の開発者のコストを下げても必ずしも全体のコストが安くなるわけではない 大きな組織だと、その判断を末端の開発者がしてはいけない。 つまり、言いたいことは、"上に投げつける前に個人の判断で諦めるな" ということ 上に投げつけて、上の責任にするんだよ。 >811 理屈はわかるがそんなこと実際にするのはかなり丁寧に組織的根回ししないと無理だろ。 そんなことができるくらいならこんなとこに相談こねーわ。 イミフ。上に言うだけやろ。こういうことで困ってますって。 小さい組織でやってるとこういう苦労はわからないものさ 責任が小さいから自由もある だーかーら、上に相談することも出来ないのか?って言ってるんだが >>813 お前がそれで解決しないという現実を知らんだけ。 解決するかしないかは関係ないんだよ。 上の責任にしろって話。 責任を押し付けないから、上は適当に仕事するんだよ。 おめぇの責任だって言えば上は逃げられなくなるからな。 与えられた裁量の中で成果を出すことが求められている もっと権限をよこせよこさないならうまくいかないぞそうなったらおまえのせいだかんななどと喚くのは無能だ 組織で働いたことがねえんだろうなあ > 与えられた裁量の中で成果を出すことが求められている どんな校則でも絶対に守る生徒 VS 校則の内容に疑問を持つ生徒 ほんとなぁ、日本の学校教育の失敗やで。 意味のないルールでも絶対に守れ。疑問を持つことは許さない という教育をしてるからこうなる。 末端の開発者が抱くような疑問はとっくに上が検討済み それ以外の事も諸々含めて選んだ結果が末端の開発者に降りてくる だから上からしたら責任はあんたにあります(キリッ)とか言われても何を言ってんだこの雑魚はとしか思えんよ もともと責任ある立場なんだからさ末端の開発者と違って 「末端の開発者が抱くような疑問はとっくに上が検討済み」 という思い込み そして前提(時代)が変わってるもルールだけを残す。 ルールの存在理由を考えない。 ルールを守ることが目的となってる。 >>821 >という思い込み という末端の思い込み >ルールの存在理由を考えない。 小さい組織の末端で働くと組織視点でルールの存在理由を考えない なので自分の都合・不都合だけ考えてルールを否定したがる > なので自分の都合・不都合だけ考えてルールを否定したがる 当たり前だろw 言わなくても、他人が自分の都合をわかってくれるとでも思ってんのか? 上は末端の開発者が考えることぐらいはだいたいわかってるよ わかった上で様々な要素を検討して 開発者には悪いけど多少苦労してもらい集団としての利を取ろうと決定したの 末端の意見なんてのは上から見るととっくに処理済なんだよ 蒸し返されても困る > 蒸し返されても困る 理由が書いてないルールは蒸し返されてしかるべきだし 理由が現状とあってないルールは改善すべき ほんとな。この理由が書いてないのが、ルールだけが残る悪い典型例だよw 靴下は白でなければなりません! (理由は?) 理由が書いてない校則が多い 上がそこまで理解力あったら7payみたいなことは起きんわ。 現実見ないと幸せそうでいいよね。 うちの会社もフィルタリングはされてるけど、 正当な理由つきで解除申請すればホワイトリストに登録してくれて アクセスできるようになるよ。 合理的判断のできる会社ならこれが当たり前だし それができない会社にいるなら 奴隷の鎖自慢なんかしてないでさっさと転職した方がいい。 不合理がまかりとおるのが当たり前になった会社なんて 長期的に見れば没落するに決まってるから。 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が上手く作られていない気がしまして・・・ WindowsでVOLUMEは鬼門・・・ はいいとしてWORKDIRはDockerコンテナ内のパス。 単にalpineの中でmkdirしてcdしてるようなもんだよ。 だからWindowsなんて関係ない。DockerfileはどのLinuxでもMacでも同じものが 使えるんだから、そんなWindowsの固有の情報なんて出てこない >>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 仕事は別だ ごく稀に回避が必要な時にわずかな労力で回避するというだけのことだ たったそれだけの事を過剰に恐れて便利なツールが中でやってることを全部自前でやるなんてよっぽど暇なのかな まあ車輪の再発明も仕事といえば仕事か ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる