探検
仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
環境構築するのが当たり前なの？
もう、MAMP XAMPでローカルに構築する時代じゃないの？？？
> もう、MAMP XAMPでローカルに構築する時代じゃないの？？？
vagrantかWSLのほうがいいだろ？
実際の動作環境がLinuxなのにWindowsで環境作るほうが面倒
Vagrant, Chef に挑む巨人、Red Hat の猛攻が始まった！
以前は、すべての開発者は、Vagrant の作者で、今世紀最大の創業者、
Mitchell Hashimoto (HashiCorp)を避けて通ることはできないと言われていた
その常識に、赤い巨人が挑む！w
俺の知ってる現場でもみんなvagrantだな
そういう時代なんだと思う
WEBアプリケーション以外にも使われることはあるんですか？
例えば、スマホアプリとか。
あるよ
container linux
ansible
docker
kubernetes
Istio
gcp/aws/azure
この辺のキーワード聞くことが多くなってきたが覚えること大杉てしぬ
たまにポートフォワードがうんとも寸とも言わなくなることがあるんだけど、そういうもん？
具体的にはNGINXのコンテナを作って外からの443をNGINXに向けるようにしてるんだけど、
突然ポートフォワード出来なくなる。TCPパケットダンプしても明らかにコンテナに流れてない。
んでDocker自身を再起動したら復帰する
運用環境としては怖すぎなんだけど・・・
利用は開発環境やステージング環境までにして
本番はネイティブにした方が無難なような。
マネージドのDocker Hostをレンタルして同じ構成で動かしてみたらどうだ
エビデンスとったか？
突然パケットが流れなくなるような設定間違いってなかなかできない。
全く「設定ミスがない」ことのエビデンスになってない
それじゃただ単に現象を確認しただけだ
｢『全く』設定ミスがない｣ことのエビデンスなんて現実的なコストでは提供不能だよ。
特に設定不足系は無理。
ふつうはそんな効率の悪いやり方をしない。
まあ金融・証券系みたいにコスト無視、かつ顧客が無理難題をふっかけるとこだと、顧客が納得するレベルの嘘をついて誤魔化すことはあるけどさ。
未解決のも多い。
ttps://github.com/moby/moby/issues/32195
なんかはSolved になってるけど
・(正常なネットワークなら問題ない筈の)先進的なネットワークオプションをとにかくdisableせよ
・Docker のバージョンを上げろ
ってなってて、Docker か、あるいは利用しているネットワーク環境のどちらかに不具合があるっぽい。
俺がなんで括弧つけたかわかってないな
「全く設定ミスがない」こと証明してないと言いたいのではない
「設定ミスがない」ことを全く証明してないと言ったのだ
ふつうは正しく動作することをもって証明とするんだよ。
数学的な意味での証明には全くならんが、現実的なコストでできる証明ってのはそれくらいしかないんだ。
くだんの人の場合、一応正しくは動作してるのに、しばらくすると止まる、しかもtcpダンプしても止まってるんだから、
症状からしてなにか不具合がある可能性が高い。
そうじゃない、証明する方法があるんだっていうのなら、その方法を具体的に書いてやってくれ。
もうとっくに書いてんじゃん
マネージドなdockerホスト借りてやってみたらどうだってさ
何も設定項目1つ1つ変更しながらエビデンスとれって言ってるわけじゃないんだよ
適度なサイズのスコープで切り替えながら調査していくの
これって問題調査の基本中の基本だよね？
君が言ってる現実的じゃない方法って
アルゴリズムに例えて言うと線形探索なんだよ
でも俺らは二分探索とか範囲で絞り込むアルゴリズムを知ってるわけだろ？
なんで身につけた知識を応用しないんだ？
マネージドなDockerホストって書いてた人だったのか。
確かにそれはアリだな。
俺の言葉の使い方だとそれを設定ミスがないことのエビデンスになるとは言わないので
マネージド環境でのテストのことを指してるとは思わなかったよ。
すまんかった。
よくよく考えてみるとアホな顧客にエビデンス要求された時に
有料サービスに丸投げした結果を提供してOKもらうことはたびたびあるので
自分でも似た使い方してたなw
自分でそれがエビデンスという強い言葉に値すると思ってないから思いつかないんだなあ。
本番には到底耐えきれないよ
本番で使わないならってんで開発でもDockerを使わなくなる
だから実務で役に立つのはVagrantとAnsibleになる
issueの数で判断できるなら、世の中のメジャーなライブラリやフレームワークはみな使えないことになる
でもDockerみたいなのになるとテストしきれないから安易に使えない
はいキチガイ
いや常識だぞこれ
お前はテストしとらんのか？
ソースは？
Rubyかな
この後またチャレンジするんだけど皆さん普通に連携取れて出来てるのよね？
本の丸コピが何回やっても動かないし何かMySQLの認証系が怪しいんだが
////phpmyadmin編
//_mysqlとphpmyadminのDockerfile用の２つのフォルダ作成
sudo docker network create mysql-nw
sudo docker volume create --name=db-volume
sudo docker run -v db-volume:/var/lib/mysql/ --name=db-container busybox
//////mysql/Dockerfile
#イメージ取得
FROM mysql
#mysqlのrootパスワード設定
ENV MYSQL_ROOT_PASSWORD=dbpass01
#文字コードにutf8mb4をセット
CMD ["mysqld","--character-set-server=utf8mb4","--collation-server=utf8mb4_unicode_ci"]
//////
sudo docker build -t mysql-image .
sudo docker run --volumes-from=db-container --name=mysql-container --net=mysql-nw -d mysql-image
//////phpmyadmin/Dockerfile
#イメージ取得
FROM phpmyadmin/phpmyadmin
#
ENV PMA_HOST=mysql-container PMA_USER=root PMA_PASSWORD=dbpass01
//////
sudo docker build -t pma-image .
sudo docker run --net=mysql-nw --name=pma-container -p 83:80 -d pma-image
https://blog.thenets.org/how-to-install-mysql-and-phpmyadmin-with-docker/
とりま要らんやろこの引数
//phpmyadmin再度
sudo docker pull mysql:5.7.24
sudo docker pull phpmyadmin/phpmyadmin
sudo docker network create mysql-network
sudo docker run --name=aa-mysql --net=mysql-network -p 3306:3306 -e MYSQL_ROOT_PASSWORD=password -v $(pwd)/database:/var/lib/mysql -d mysql:5.7.24
sudo docker run --name=a-mysql-admin --net=mysql-network -e MYSQL_ROOT_PASSWORD=password -e PMA_HOST="aa-mysql" -e PMA_PORT=3306 -p 8081:80 -d phpmyadmin/phpmyadmin
//1
sudo docker network create -d bridge my-bridge-network
//2
sudo docker run --name mysql -e MYSQL_ROOT_PASSWORD=secret -d mysql/mysql-server
sudo docker network connect my-bridge-network mysql
sudo docker inspect mysql//次のhostに付けるip確認
//3
sudo docker run --name phpmyadmin -d -e PMA_HOST=(さっきのIP) -p 808:80 phpmyadmin/phpmyadmin
ネットワーク経由でストレージをマウントすると遅いし所有権やシンボリックリンクの取り扱いでトラブルが起きやすい
逆にローカルストレージをマウントするとコンテナを特定のホストにピン留めせざるをえなくなって運用性が悪い
どうにかならんかねこのジレンマ
だからクラウド使うんだよ
ストレージはクラウドサービスが提供しているものを使う
ストレージ用のコンテナは作らない
例としてS3をVolumeとしてマウントしたとして
このVolumeはローカルストレージのVolumeよりも遅いしパーミッションとかで変なトラブルが起きやすい
この性質はイントラのストレージサービスとクラウドのストレージサービスでそう違いがあるとは思えない
だからボリュームとしてマウントしたりしない。
アプリはデータをS3に保存するし、S3から取ってくる。
パーミッションとか関係ない。クラウドのセキュリティ機能を使う
クラウドストレージの速度はローカルストレージと遜色ない（コストによるが）
補足しておくとアプリはS3のデータを読み書きするとして、
例えばユーザーはファイルをサーバーにアップロードする時、
S3に直接アップロードするしS3から直接ダウンロードする。
アプリを経由してS3のファイルを読み書きしたりしない（してもいいが遅い）
誰でもアップロード・ダウンロードできてしまうことを
防ぐためのセキュリティ機能もS3にある
EBSを使ってもいいが、アプリの仮想マシンからブロックデバイスとしてマウントはしないんだよ。
EBSをマウントするのは（広い意味での）データベース・サーバーの一台
アプリからは、そのデータベースサーバーに対してネットワークでデータを読み書きする
複数あるアプリの仮想マシンでファイルシステムをマウント（Dockerのボリューム含む）しようという発想が古い
ストレージをマウントするのは仮想マシン1台だし、そこにネットワーク経由でアクセスする。
↑このストレージをバックアップなど含めて適切に管理するのが面倒だから、クラウドストレージを使う
いずれにしろ、アプリからはネットワーク経由でデータの読み書きをする
例として挙げただけなのでどのストレージサービスでも状況は同じ
>718
ストレージサービスをネイティヴサポートしてない他社製アプリはVolumeマウントするしかないと思うけど違うのかな？
オープンソースならフォークしてファイルアクセスを全てストレージサービスに置き換えることはできなくはないけど労力に到底見合わない
だからどうしてもVolumeマウントに頼らざるをえないケースは多々ある
そういうケースにステートフルコンテナをクラスタに組み込むにはどうするべきか悩ましい
だからな？ 新しい仕組みを活かそうと思うなら、
設計から見直さなきゃいけないんだよ。
効率化する新しい仕組みを導入したいのですが
今までの効率の悪いやり方まま変えたくないんです。
↑アホみたいだろ？
やり方を変えないなら、今までのやり方をするしか無いんだよ。
諦めな
設計を見直すと言われても他社製だからな…
従来のようにバックアップとリストアをしっかり整備して多少のリスクを受け入れるぐらいしか思い浮かばん
ダウンタイムはともかく直近のデータロストは怒られそうできつい
https://www.bleepingcomputer.com/news/security/docker-hub-database-hack-exposes-sensitive-data-of-190k-users/
By Lawrence Abrams
April 26, 2019 11:30 PM
サポート
VagrantfileとDockerfileのどちらが簡単かという話になるのかな？
変なトラブルが少ない
開発デスクトップも仮想化できる
環境の再現性がたかい
Linux+Windows混在も楽々
ただしターゲットがDockerの場合に限りローカル鯖もDockerにした方がいい
それは当然のことだな
その場合でも開発デスクトップはDockerを使わないほうがいい
Dockerの使いどころが...
(それを言っちゃあおしまい)
本番でDockerを使わないなら本番環境はDockerへの配慮なんてしてない構成になってるはず
その構成をローカルに再現するときにDockerを使うかVagrant/Ansible使うのどっちが工数少ないかってことだ
少なくとも本番環境の構築手順書があるのだから完全仮想化環境で同等の環境を再現するのはさほど難しくない
しかしDockerだとどうしても構成の整理と手順書の読み替えと動作確認が求められてくるので面倒だ
> 5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ？
何度も言ってるが、仮想マシン（Vagrant）とアプリ仮想化（Docker）は
組み合わせて使うものです！
どちらか一方を使うんじゃない。役目が違うんだから両方使う
可能不可能の話じゃなくて、そんな事やるやつは馬鹿という意味で同一に出来ない
開発環境はVagrantで作るが本番環境はAnsibleなどで作る
開発環境には便利なテキストエディタやIDE、ヘッダファイル、静的解析ツール
その他便利なコマンドなど、いろんなものを入れる必要がある。
それに対して本番環境はそれらは入れない。セキュリティリスクにつながるし
メンテナンス性も考えなるべく小さなイメージにしておく
開発環境と本番環境は同一でないという前提で、
開発環境でどうやってテストするか？という話が出てくる
本番環境に近い環境でないとテストに自信が持てないのは当然
そこでDockerがでてくるんだよ。開発環境で動かすDockerコンテナと
本番環境で動かすDockerコンテナを同一に（もしくは限りなく近く）することで
開発環境と本番環境が違っていても、信頼性のあるテストが実行できる
そうするとDockerコンテナさえ同じであれば、開発環境を統一する意味もなくなる
開発環境がLinuxであってもWindowsであってもMacであっても、
同一のDockerコンテナを使うのだから、信頼性のあるテストが実行できる
だから今はVagrantを使って開発環境を統一するメリットが減ってる。
統一したいならしてもいいが（それは開発者の自由を奪うというデメリットでもある）
統一しなくても良いのが今の開発
本番環境が全てDockerという幻想の上でしか成立しないな
本番環境がDockerでないなら開発環境でDockerを使うと逆に再現性が低下する
> 5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ？
「ローカル開発環境を同じにしたいならVagrantを使う」
それと同時にDockerも使う
Dockerを使うなら、ローカル開発環境を同じにする意味はさほどない
同じにしないなら Vagrantを使わなくて良い。Dockerだけ使う
これは「ローカル開発環境を同じにしたい場合にDockerが楽」と言ってるのではなくて
「ローカル開発環境を同じにしないならVagrantはいらない」という意味
だから「ローカル開発環境を同じにしたいならVagrantを使う」ということは否定していない
使う目的が違うのだから、どちらを使うか？っていう話にはならない
もう今は本番環境でDockerを使うのは常識
仮に本番環境でDockerを使わないとしても、
本番環境と同じ環境をDocker以外で作るのは困難
開発環境用VM（Vagrant）と本番環境用VM（Vagrant）の
２つを作るのは重いだけ
開発環境用VM（Vagrant）と本番環境"再現用"VM（Vagrant）の
２つを作るのは重いだけ
本番環境用VMといってしまうと、これを本番環境で使うように思えてしまうので訂正
実際の本番環境はVagrantでは作らないので、本番環境そのものにはならない
高い再現性を求めるなら、開発環境でも本番環境でもDockerを使うのがベスト
Dockerコンテナは同じですよーっていうのが
Dockerを使うメリットなわけだ
そんな常識ないよ
あほくさ
お前が言うのかそれ
Dockerはソフトウェ開発全般で使う
ローカル開発環境を同じにしたい場合にはたしかに便利だが、
ローカル開発環境を同じにする必要がなくなってきてる。
そういう意味ではVagrantを使わないほうが良いと言える。
依存してなくても事実上Dockerを使うのが現時点ではベストという話
Vagrantは本番環境でも使えるしDockerを使わない開発も未だに無数にある
Dockerのメリットは確かに大きいがそれなりのデメリットも同時に抱え込んでしまう
Dockerでやるべき明確な理由がないなら使う必要はない
使えるが使わん。
Development Environments Made Easy
^^^^^^^^^^^^^^^^^^^^^^^^^^^
「開発環境を簡単に」と書いてあるんだから
本番環境で使おうとするな。想定外の使い方だ
本来想定してない用途なのに、使えそうだから使おうというのは
その技術を正しく理解してない証拠なんだよな
当たり前だけどOSの様々な機能が制限されるコンテナは仮想マシンの代替にはなりえない
両方組み合わせて使うものだという話になる。
AnsibleのテストするならVMを使うのが一番。各クラウドやKVM等ね。
というかAnsibleのテストでVagrantなんて使うか？
Vagrantで作ったらVagrantユーザーがいるわけで、
それは本来のAnsible実行対象マシンとは違うものになる。
○ （アプリケーション）コンテナはそもそも仮想マシンの代替として作られたものじゃない
組み合わせて使っても良いが
常に組み合わせて使う前提のものではない
>>758
だから君のDocker万能論はちゃんちゃらおかしいということだよ
開発環境は開発対象をよく理解して適切に選ぶこと
全部DockerでOKなんてことはありえない
Ansible（Chefなども同様だろう）を使うといった時、
playbookを作る のと playbookを実行する という2つの段階がある
playbookを作る場合は、当然テストが必要なわけだがVagrantが便利。
なぜならVMを特定の状態にして何度もplaybookをやり直すから。
具体的にはsnapshotの機能を使う（最初からvagrant boxを作り直すのもあり）
でもこれって、Ansibleに内蔵されているべき機能ではないだろうか？
Vagrantで作るVMと本番環境のVMは違っている。
本当は本番環境（を複製して）を何度も同じ状態にしてテストを実行したいはずだ
通常、本番環境のVMの構築にVagrantは使わない。Ansibleを使って構築するだろう。
ならば、Ansibleだけで本番環境のVMのスナップショットを取れたほうが良いだろう。
今はそれが出来ないからVagrantを使っている。
なるほど、これは良い発見だ！
（独り言）
> だから君のDocker万能論はちゃんちゃらおかしいということだよ
何度もDockerとVMは組み合わせて使うって言ってるのに、
なんで俺のことをDocker万能論者に仕立て上げようとすんのさ？
そんなこと言ってない。
何度も何度もVMと組み合わせて使うって言ってるのに
しかしそれでも君の主張はDockerありきが前提にっているのは確かだろ
しかし実際にはAnsibleの例のようにDockerを使いにくい環境も存在している
だから君の主張がおかしいということには変わりはない
やっぱり素でDockerを理解してないんだな・・・
> しかし実際にはAnsibleの例のようにDockerを使いにくい環境も存在している
Dockerはアプリケーションとユーザーランドを一体化させて
一つのアプリケーションのように仮想化するためのものであって
Ansible（構成管理ツール）とDocker（アプリ仮想化）を組み合わせて使うことがそもそも間違い。
俺はAnsibleとDockerを組み合わせて使うなんて一言も言ってない。
俺の主張？俺が何を主張したっていうんだ？
DockerをVM（Vagrant）のようの代わりに使って
DockerでAnsibleなど構成管理ツールの開発・テスト環境を作るという使い方
Ansibleを使ってVMの構成管理を行い、その一つとして
Dockerコンテナを起動するっていう使い方は問題ない。
俺は、DockerでAnsibleなど構成管理ツールの開発・テスト環境を作るという使い方をしろなんて
一言も主張していない
DockerをVM（Vagrant）の代わりに使おうとして
DockerはVM（Vagrant）の代わりとしては使えない！って
独り相撲してるだけじゃんか
俺は最初から組み合わせて使う。両方使う。役割が違うと言ってる。
君の主張は自分のレスを読み返したら？
開発環境はとにかくDocker
Dockerなしなんてありえない
それが世界の常識
君は昨日散々そう主張していたよね
そんな主張をしたら例えばAnsibleの開発環境みたいなDockerに向かない環境もDockerで組むのかなこいつはと解釈されても仕方がないよ
お前が見返して、どこで言ってるのか指摘してくれ
俺はお前が言ってることを何一つ主張してない
ID: XICm〜のレスを読み返して
>>737で
> 開発環境はVagrantで作るが本番環境はAnsibleなどで作る
開発環境はVagrantで作るとはっきり言っている
だからそれをお前がやれって言ってる。
お前嘘つきじゃん。さっきからどれもコレも俺が主張してないことを
俺が言ったことにしようとしてさ
で、そのレスの後半でDockerを使う話に持っていってるよね
とにかくDocker
Dockerありき
それが世界の常識
それが君の主張
ぽかーんｗ
スレの前半でDockerを使わない話してるよね？
お前、スレの後半しか読んでないの？
スレの後半だけで判断しちゃった？ｗ
やれもクソも君の目の前のブラウザか専ブラかをちょっとスクロールして見るだけだよ
俺がやることなど何もなく君が自分のレスを見るだけだ
それを俺が代行してやることは物理的にできない
それで？
後半を主張するための前振りだろ？
だって君の主張はDockerありきが世界の常識だもんな
何度も何度も何度もVMとDockerは組み合わせて使うと言ってる
お前が、VMとDockerはどちらか一つを排他的に使うものだって
心の底で思ってるから、俺がDockerを使うという話をすると
VMを使わないと言ってるんだって勘違いしてるんだよ。
＞
＞仮に本番環境でDockerを使わないとしても、
＞本番環境と同じ環境をDocker以外で作るのは困難
＞
＞開発環境用VM（Vagrant）と本番環境用VM（Vagrant）の
＞２つを作るのは重いだけ
ほーん
Ansibleの本番環境と同じ環境もDockerで作るんだ
なんたってDocker以外で作るのは困難だからなー
それが世界の常識ってやつですかそうですか
また俺が言ってないことを言い出した。
VMを使わないことではなくDockerを使うことが前提になっている点がおかしいと言ってる
言っているも同然なんだよね
やっぱりこの辺りは反論不能なんだな
本番環境を同じ環境をローカルに作る場合
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を使わないと困難だと言ってる
何に反論すれば良いのさ？ｗ
お前の書いた嘘？
OS・ディスプレイマネージャーに対して、
そのゲームを最前面に表示するように、命令できないの？
誤爆です！
Linuxで使えば仮想マシンも不要でネイティブに動く
メモリも数MB程度のオーバーヘッドだけですむだろう
仕事で仕方なく使ってるけどメモリ不足で起動失敗が多発する
Windowsコンテナのプロセス分離だけに限定すればいけるかもしれんが…
Winコンテナは興味なくて検証したこともない
WSLでDockerは動かない
次の大型アップデートでWSL 2が実装されるけどそっちではDockerも簡単に動かせる
Docker for WSL 2のサポートも決定事項
こっちの必要スペックはわからん
Docker for WSL 2 は期待していいんでないかな。
どちらも仮想マシンを使っています
hyper-vのサブセットを提供するって。少しは調べろよ
マジかサンキュー！
俺の調査完了だぜｗ
HP ENVY Ryzen7 3700U を使用しています。
https://dotup.org/uploda/dotup.org1884129.png
BIOSの方で仮想化設定をONにして、タスクマネージャーで確認しても「仮想化 有効」に
なっているのにかかわらず、Docker Quickstart Terminal を起動すると
「仮想化がenableになっていません。」とエラーが出て終了してしまいます。
どうすれば通常通り起動できるようになるでしょうか。
どなたか心当たりある方いらしたらお教えいただけないでしょうか・・・。
Docker Toolboxは古い
Docker Desktop for Windowsを使え
特殊なインターネット接続なし環境で構築しており，インターネット接続環境はブラウザしか起動できない状況です。
仕事で苦労してる責任が管理者にあるなら管理者に責任を押し付けろや。
コストがあがったのはあんたが認めないからです。責任はあんたにありますって
大きな組織だと特定の開発者のコストを下げても必ずしも全体のコストが安くなるわけではない
つまり、言いたいことは、"上に投げつける前に個人の判断で諦めるな" ということ
上に投げつけて、上の責任にするんだよ。
理屈はわかるがそんなこと実際にするのはかなり丁寧に組織的根回ししないと無理だろ。
そんなことができるくらいならこんなとこに相談こねーわ。
責任が小さいから自由もある
お前がそれで解決しないという現実を知らんだけ。
上の責任にしろって話。
責任を押し付けないから、上は適当に仕事するんだよ。
おめぇの責任だって言えば上は逃げられなくなるからな。
もっと権限をよこせよこさないならうまくいかないぞそうなったらおまえのせいだかんななどと喚くのは無能だ
組織で働いたことがねえんだろうなあ
どんな校則でも絶対に守る生徒 VS 校則の内容に疑問を持つ生徒
ほんとなぁ、日本の学校教育の失敗やで。
意味のないルールでも絶対に守れ。疑問を持つことは許さない
という教育をしてるからこうなる。
それ以外の事も諸々含めて選んだ結果が末端の開発者に降りてくる
だから上からしたら責任はあんたにあります(キリッ)とか言われても何を言ってんだこの雑魚はとしか思えんよ
もともと責任ある立場なんだからさ末端の開発者と違って
という思い込み
そして前提（時代）が変わってるもルールだけを残す。
ルールの存在理由を考えない。
ルールを守ることが目的となってる。
＞という思い込み
という末端の思い込み
＞ルールの存在理由を考えない。
小さい組織の末端で働くと組織視点でルールの存在理由を考えない
なので自分の都合・不都合だけ考えてルールを否定したがる
当たり前だろｗ
言わなくても、他人が自分の都合をわかってくれるとでも思ってんのか？
わかった上で様々な要素を検討して
開発者には悪いけど多少苦労してもらい集団としての利を取ろうと決定したの
末端の意見なんてのは上から見るととっくに処理済なんだよ
蒸し返されても困る
理由が書いてないルールは蒸し返されてしかるべきだし
理由が現状とあってないルールは改善すべき
ほんとな。この理由が書いてないのが、ルールだけが残る悪い典型例だよｗ
靴下は白でなければなりません！
（理由は？）
理由が書いてない校則が多い
理由は上が管理してるから安心しなよ
現実見ないと幸せそうでいいよね。
正当な理由つきで解除申請すればホワイトリストに登録してくれて
アクセスできるようになるよ。
合理的判断のできる会社ならこれが当たり前だし
それができない会社にいるなら
奴隷の鎖自慢なんかしてないでさっさと転職した方がいい。
不合理がまかりとおるのが当たり前になった会社なんて
長期的に見れば没落するに決まってるから。
（コマンドは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が上手く作られていない気がしまして・・・
はいいとしてWORKDIRはDockerコンテナ内のパス。
単にalpineの中でmkdirしてcdしてるようなもんだよ。
だからWindowsなんて関係ない。DockerfileはどのLinuxでもMacでも同じものが
使えるんだから、そんなWindowsの固有の情報なんて出てこない
根本的な部分を忘れていました・・・全てDocker内のLinuxで完結しているのですね
ちゃんと作れるようになりました
ありがとうございますm(__)m
前使ってた時は相性悪かったんですが
supervisorは設定ファイルiniでキモいしちょっとしたエントリー拡張のためにsupervisorやentrykitを入れるDockerfile書くのめんどくさいよ
手続き的に処理するものをYAMLで書いて、YAMLで書いた順番通りに実行します。
ifもループも書けますとかYAMLという設定ファイル形式の使い方を間違ってるとしか思えんわ
> ちょっとしたエントリー拡張のためにsupervisorやentrykitを入れるDockerfile書くのめんどくさいよ
お前が必要なのはYAMLじゃない。
YAMLでsupervisorやentrykitを入れるコードを書きたいわけじゃないだろ？
お前が本当に必要としてるのは、1コマンドでsupervisorやentrykitを入れるコードだよ。
コンテナ内部で走らせるプロセスを
YAMLでrun: 'process' と書こうが、Dockerfileで run process と書こうが
どちらも何も変わらんだろ
対応するって話だったらなんの文句もないが、
supervisor開発者と関係ない第三者が、YAMLからiniへの
変換フィルタ作って、ほら、iniをYAMLで書けます。
supervisorのiniのあの項目は、私が作った変換フィルタではコレに対応します。
どれがどれに対応するか覚えて下さい！そうすればYAMLで書けます！
ってアホらしいと思う。supervisorのiniが変われば、
そのどこの馬の骨が作ったかもしれない変換フィルタまで
バージョンアップしないといけないし、変換フィルタの作者が飽きればそこまで
単に設定ファイルの形式を変換するだけの行為に意味ないよ
なんでそうみんな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形式じゃないだろ
> 設定がいろんな形式であちこちに分散するより纏めて
設定をまとめたいなら、設定ファイルをディレクトリにまとめればいいだけ
そして適切な場所にコピーするだけだろ。
> 同じ形式で書けるほうがいい
理由は？
まあ形式はyamlでなくてもいいけどyamlが妥当だろ
composeやswarm、k8sでも採用してるしdockerユーザーには馴染み深い
まとめる作業もコピーするのも面倒なので却下
それにまとめてもファイルは分割されてるだろ
suprvisor本体、各プロセス、起動ヘルパースクリプト、その他もろもろ
はぁ…ダルっ
同じ形式で書ければ構文を覚えなくていいから楽だしプログラム的にも扱いやすくなる
広く普及してるフォーマットなら形式が違くてもまだマシだが
たまにオリジナル形式で作っちゃうバカがいるから呆れる
> まあ形式はyamlでなくてもいいけどyamlが妥当だろ
YAMLが妥当かどうかの話じゃなくて、ネイティブの設定ファイル形式を
第三者が作ったツールを使ってYAMLで書くのがアホだっていってるんだよ。
なぜかと言うと信頼性がないから。YAMLで書いたものが
本当に設定ファイルに正しく反映されているのか？
新しい機能に対応できてるのか？トラブルが合ったときその原因はどこにあるのか？
新たな問題が起きる層を増やしているだけ
設定ファイルの形式はなんだって良いだろ。設定項目の意味を覚えるのは
どっちだって同じことで、YAMLかそれ以外かの「形式」を覚えるのはなんの苦労もない
> それにまとめてもファイルは分割されてるだろ
じゃあ一つのファイルに、特定の区切り文字で区切って、結合すれば？
必要なのは、その結合設定ファイルの分割を「サポート」するツールであって
YAML以外の設定ファイル形式を理解できない
（からネイティブの設定ファイルが読み書きできず、トラブルがあってもYAML経由じゃなきゃ対応できない）
ような初心者のためのツールじゃないだろ
> たまにオリジナル形式で作っちゃうバカがいるから呆れる
suprvisorの作者にでも言ったら？僕はYAML形式でしか設定ファイルを読み書きできないので
YAML形式に対応してくださいってｗ
新規のDSLは否定しまくるくせにMakefileは不問だったりするんだよな。
2. Makefileは用途が違う
3. お前はMakefileも否定してるのか？
信頼性に対する考察が足りんな
抽象化と記法の統一化で設定が簡単になる
ということはミスが減るんだよ
広く使われるラッパーが間違えるより人が間違える確率の方が高い
トータルで見ると信頼性が上がる
プログラム書いてる人間なら自然とこういう考え方が身につく筈なのだがね？
君はアセンブラで何でも書いてしまうタイプなのかな？
形式を覚えるのは面倒だ
君が何と言おうとね
区切り文字で結合w
勢いで書いちゃったけど流石に自分でもこれはないわーあーやっちゃった、とか今、思ってるでしょ？
オリジナルってのは広く普及してないフォーマットの事な
別にyamlには限らないよ
jsonでもxmlでもね
ということはDockerネイティヴのコンテナ内プロセス管理の仕組みを用意した方が良いということになるな
馬の骨が作ったサードパーティツールよりネイティヴサポートの方が良いのは確かにそうだね
> ということはミスが減るんだよ
イミフ。アプリが要した設定方法を使うほうが
一番広く使われてる方法で、一番設定が簡単だろ
お前アプリのドキュメント読んでるか？
そのアプリのドキュメントにどういうやり方で
設定しろって書いてあるよ？
> 勢いで書いちゃったけど流石に自分でもこれはないわーあーやっちゃった、とか今、思ってるでしょ？
俺が言ったことを復唱するだけで、何一つ反論しないのなｗ
> ところで君はネイティヴにこだわってるけど
アプリのドキュメント通り。公式にやり方のことだが？
Dockerで言えばDockerfileを使ったやり方。
一番広く使われてるだろうが。
イミフというならプログラム書いたことないのだな
アセンブラおじさんと呼ぼう
なんかレスしろよｗ
でそのDockerfile使った方法がクソッタレだから馬の骨がサードパーティツールとか使い出してしまった
これは明らかに公式の失態だな
さっさとマルチプロセス管理の仕組みを提供すべきだった
なんかレスしろよw
あぁ、出すやつは出すだろうな。
んで、使われてるのか？ｗ
誰も使わんだろ
> なんかレスしろよw
お前がなにか意味があることを言ってないのに
何にレスしろと？
何もメリット無いわけ
みんな公式の設定ファイルを読み書きできるだろ？
（できなかったらどうやってそのアプリの動作検証をやったというのか？）
公式のドキュメントを見て、使い方を覚えて、
さあ、あとはYAMLから変換するツールの使い方の勉強だ！
対応表見るぞー！あれがこれに対応してぇ、こう書けば、こういう設定ファイルが出力されてぇ
こういう設定するにはYAMLでどう書くんだ！くそーうまく出力されない！
何がしたいのかさっぱりわからない
セルフカウンター乙
>>853
そこから間違ってるよ
公式見なくてもできるのが優れたラッパーだ
1対1で変換しただけのような二流ラッパーの話はしていないので謹め
お前の言う優れたラッパーってどれよ？ｗ
それは一対一で変換しないんだろ？
そのラッパーにはラッパー特有のトラブルや制限が一切ないんだろう？
さて、優れたラッパーなんて存在するかなーｗ
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
こういうのと戦っていなくてはいけないわけだ
某エディタのAnsible拡張を導入したらオートコンプリートが効いてこりゃ便利！と感じたがメリットじゃなかったのかコレ？
https://docs.ansible.com/ansible/latest/modules/docker_image_module.html#docker-image-module
ところでマルチステージビルドはどうすればいいのかね？
Dockerfileでマルチステービルドをする方法はいくらでも見つかる。
Ansibleでそれをどうやるのか？を悩むんだろう？ｗ
オートコンプリートなら別にAnsibleとは無関係に使える。
例えばDockerfileのオートコンプリートだって存在する。
まああれも第三者が作ってるから、公式のバージョンアップに
ついていけないところがあったりで不完全なところがあるんだが、
オートコンプリートなら補完されないってだけで別に大きな問題にはならんな
極論マンw
一切ないとか言ったら何も使えんわ
お前本当にエンジニア？
世界中で実践運用耐えうるぐらいには問題なく使えるよ
>>856
お前は全てのバグを踏み抜く奇跡の体現者かよw
実際に遭遇して問題が表面化して解決もできないなんてバグは滅多にない
ラッパーなら迂回路はいくらでもあるからな
お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな
だからそういう間に入って変換するだけのものは
使わないほうが良いって言ってんだろ
公式が提供している、標準のやり方を使えばいいだけ
> お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな
本家がバグってるのをラッパーで回避できるわけ無いだろｗ
もし回避する方法があるなら、その方法をラッパーを使わずにやればいいだけだし
俺が言ってるのは公式が提供している標準のやり方をしろというだけ
間に変な変換ツールを入れて、その制限にぶち当たって悩まなくて良くなる
buildargsを使う
修正してモジュールにコミットする
シェル系モジュールを使う
回避する方法がいくらでもあるから安心だなぁ
他のツールは？
カバー範囲狭すぎだろw
飛行機落ちるかも怖いから乗らないって駄々こねる子供と同じだなこりゃ
大人はメリットもリスクも比べて飛行機に乗る
なんかあったら打つ手なしの飛行機じゃねえんだからリスクはさらに安く見積もって良い
ちょっとでもリスクあったら全否定ってw
本当にアセンブラマンなのかこいつ
今はまだある程度正気のようだがそのうちコンパイラも信じないとか言い出しそうだ
お前の仕事は、回避することかｗ
>>865
間に挟めてトラブルを引き起こすツールに
メリットなんか無いじゃんｗ
間に挟めるツールのトラブルがまるまるなくなる
非公式のやり方じゃなくて、公式のやり方をしろと言ってるだけ
仕事は別だ
ごく稀に回避が必要な時にわずかな労力で回避するというだけのことだ
たったそれだけの事を過剰に恐れて便利なツールが中でやってることを全部自前でやるなんてよっぽど暇なのかな
まあ車輪の再発明も仕事といえば仕事か
省力化やメンテナンス性の向上もまるまるなくなるな
>>868
たとえとしては十分だ
的外れだからな。
所詮「第三者が作った設定ファイル形式のコンバーター」は
トラブルが起きたら変換後のオリジナルの設定ファイルを見なければ話にならん
ん？それってシェル系モジュール＝シェルスクリプトでできる程度のことでしょ？ｗ
外れてないぞ
お前の意見は「データを抽象化、容易化するのは無駄(実際には無駄じゃなくメリットはある)で変換器の変換バグがあるかもだからアトミックなまま使え」だからな
機械語コードとコンパイラにもピタリと当てはまるな
それってアセンブラでもできることでしょう？
ただ出来ると簡単に出来る、うまく出来るは違うことなんだな
だから高級言語が発達した
設定も同じことだ
俺の意見を間違えてるｗ
「不要な第三者が作った質の悪く機能不足な変換ツールを使わずに
アプリの開発者の想定通りの使い方をしろ」が俺の意見だ
設定ファイルは同じじゃない。
YAMLで設定を書いたら、できることが減ってバグが増えてる。
それに対してメリットがない。
toolboxからコンテナを作れたまでは良いのですが、共通ファイルを作った上で、
コンテナ内のディレクトリにcreate-react-appでunk20というReactディレクトリを生成しようとしても、エラーが表示されで作れなくなりました。
途中まではWindowsの方の共通フォルダdocker-common内にunk20というフォルダが生成されているのですが、
以下のコードのnpm ERR!が出るとunk20フォルダごと削除され消えてしまいます。
ちなみに、共通フォルダを設定していない状態ですと、create-react-appでReactディレクトリはちゃんと作られ、localhostで接続すると問題なくブラウザにも表示されます。
node.jsとnpmは最新版にしております。
(コンテナ作成 & コンテナ内に入る）
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ディレクトリが削除される）
どなたかわかるかたいらしたら宜しくお願い致します・・・。
普通に使ってるけど？
うまくYAMLにするためにインデント数を`Indent 12`みたいにしてテンプレートで指定とか正気かよ
なんか良い代わりのやつ無いの？
ホストもコンテナ内も一般ユーザーのみ許可できればいいのだけどそんなことできんのかね
その臨時雇い要員に専用のパソコンを与えれて
そのパソコンは自由に使っていいけど、本番環境へのアクセスは禁止すればいい
仮想端末を含めて専用のPCを用意することが出来ません
複数名でログインする端末です
機密情報を扱う別のユーザーと共有してます
言い換えると、あなたの会社でまともな開発はできません。ということ
自分で、まともな開発はできないと結論を出してるんだから、そこで終わりだろう。
単に金が無いって言ってるだけじゃないか
金がないです。どうしたらいいですかと言われても
借金でもすれば？で終わる話
パソコンなんて数万円程度で買えるのにのに「できない」
なんてことはありえない。ようするにやる気がないだけ。
言葉は正しく使え。専用のPCを用意することができないんじゃなくて
専用のPCを用意したくない。が正しい言葉だ。
機密情報も、適当でいいって思ってるだろ。
機密情報に関してきっちりしているなら専用のパソコンに物理的に分ける。
パソコンがとても高価だった時代ならまだしも、今の時代に複数で共有なんて危険なことはしない。
個人専用のパソコンを与えてない時点で、セキュリティはザルでしかない。
自己を認識してないようだからはっきり言ってやる。
お前のところは機密情報を扱う資格がないし、守ることすら出来ない。
大切なものを守る意識も欠けてるし、やるべき正しいこともわかっていない。
今何も問題が起きてないのは運がいいだけだ。
例えば10階建てビルを作る技術はある。
みんなそれを作るための技術と道具を持ってる。
お前は、クレーンがないんです。
技術的に不可能ということでしょうか？と聞いてる。
技術的に不可能じゃなくて、クレーンを買うことができないことが
出来ない理由だっていってんの。ちゃんと認識しろって
「金が無い」なら、無理じゃねと言うしか無い
buildをユーザ権限でやるならk8sの使えば行けるが、会社と担当者のITリテラシーレベル低そうだし諦めればw
セキュリティやってる気になってる会社には無理だろ
機密情報を扱う別のユーザーと共用してるパソコンなんて
正気の沙汰じゃない。どうせアップデートもしてないだろうし。
セキュリティ意識ゼロ
ビルドでユーザー作れば当然管理者権限なしでも入れるが、dockerでやる事なのだろうか。
中に入る→出来る
ビルド→出来る
docker コマンド→別グループ作れば可能だが実質su
dockerはアプリ動かすツールであって、管理者以外が共有PCで立ち上げ必須な用途には向かない。巻き添えで常駐コンテナに影響するからだ。
PCに入ったあと、Dockerコマンドで機密情報を操作するコンテナを動かすルールなのだろうか。
企業によくいる、自分は詳しいと思いたい素人が管理してる感溢れていて良い。
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」
これだけ
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」
これだけ
質問には答えられないくせにさw
わからないことを誤魔化すためのマウンティングになると饒舌
これが正確だな
>>904に答え書いたでしょ。
buildの方はk8sやローカルリポジトリがいるのでかなり難易度高め。k8sが管理者権限だと無理だな。
ユーザー作る方は難しくない。
rootが嫌ならユーザーをdockerに入れると良い。実質suだが。他は不可能。
上2つはdockerfile書けるのが前提で、ここに書いて済むレベルの話ではない。
頑張れw
Dockerじゃなくて普通にVM使うべき。
メモリーの必要量は増えちゃうけど。
「個人にパソコンを与えたとしてもrootは禁止なんですー」
「うちってセキュリティしっかりしてるでしょ？」
呆れる
k8sの話はしてないしローカルDockerの話してんの
ユーザーDockerに入れても意味ないだろ
>>910
業務上の都合で使えません
>>911
答えられないなら無理してレスしないでいいぞ？
見ててちょっと気の毒だ
○ 業務改革したくないです。やる気ないです。
新しい道具に最適になるように「やり方」を変えないと、何もかも無駄になる。
dockerでは無理。k8sはコンテナも書き方も同じでdockerの上位互換。しかし、複雑で難易度の高め。
完全な上位互換なんだが、代わりに手軽さは一切無いw
Dockerでできることのほとんどは、Docker使わなくても手間が違うだけでできるわけだし。
無理だと分かってる要件を押し通そうとするのは無能。
押し通そうとしてるのが自分じゃなく上なら、そんな理不尽な職場は放棄して転職すべき。
このバグのせいでテストがまともに出来なくて困ってる。
WindowsやLinuxでは発生しない。
タイムアウト仕込んでリトライさせるしか無いかな
これでどや？
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置いてな
単に速度が遅いだけなのではと思った
for Macはディスクアクセスがやけに遅い気がする
やってないけど、関係ないわ
docker clientのバグだから
mac限定のバグ。WindowsとLinuxでは
今まで1セット100ビルドを何十回もやっていて出てなかった
だとするとclientだけコンテナにすりゃいんじゃね？
docker run --rm -v $PWD:/build -w /build \
-v /var/run/docker.sock:/var/run/docker.sock \
docker:latest build -tag test .
これ100回ぐらい流してみてくれ
それはLinux版バイナリだからうまくいくよ。
ただね、100回ビルドするだけで3分もかかるんだよ。普通なら30秒。
「1セット100ビルドを何十回もやる」ような場合はちょっと苦痛
更に言うと「Windows」でもやるのでボリュームは使いづらい
それにしてもなんでmac版だけ壊れてるかな？
組み合わせでテストしてるから
dockerってそれをしないで済ますための仕組みなんじゃ。。
いつかhomebrewとかaptとか無くなって
全部docker上で動くようになる時代がくるといいですね^^;
確かにホストの方はどうにもならんことはあるだろうが、
ゲストの中身をいろいろなディストリビューションで実装する意味が分からん。
いろんなディストリビューションで（Dockerを使わずに）動かすんだよ。
例えばいろんなディストリで動くバイナリを生成するコンパイラの開発
そうだよ？だからWindowsでもLinuxでも問題なくビルドできたので
今まで気づかなかった。だけど出かける時もありノートでも作業できるようにしたいわけ
それにしてもMac版だけdocker buildがフリーズすることに誰も気づいてないのかな？
macにそこまでなんでこだわるかね。。
githubのissueで調べるか出した方が良いのでは。
windowsとmacだとk8sの不具合が認識されていて、ネットワーク割当が原因と分かっているが、2年経っても治ってない。
dockerやk8sは基本的にLinux用。
後のOSは有志中心の開発だから不具合多い、と思った方が良い。
CircleCI全否定？（笑）
Mac版のdockerサーバーは仮想マシンのLinux上で動いてるんだから
Mac版のdocker clientの問題だろうね
Dockerで動いても生ホストでの動作保証にはぜんぜんならないでしょう(逆も然り)
自分がやる時は中で操作して、動作をメモしてCIに移植するから、何周もビルドする事は無いな。遅いし。
繰り返しになるが、Githubで聞いてくれ。
推論を重ねても意味がない
コンテナ・オーケストレーションのMagnum とかある
Magnumは、Docker Swarm, k8s, Apache Mesos と連携する
必要なのは悪者探しではなく、対策でしょ。内容的にstackoverflowでも回答無いと思う。
荒れると面白かったんだが。面倒になったからさっさと終わらせるわ
再現コード、十数回でフリーズすると思うが、極稀に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の問題
バイナリ配布されてるから~/binにでも入れるだけ。
世の中がバグに気づいてなおるのを待つことにする
githubへは面倒なので、だれかやって
htmlの内容がブラウザに表示されたまではいいんだけど
htmlを編集してもブラウザが更新されてくれない(リロードしても編集前と同じ画面）
再度npm startするとちゃんと編集後のコードで更新されているんだけど、
少しの編集でも逐一チェックしたいのでとても不便・・・どうすればブラウザでも随時更新されるようになるのかな？？
手探りで、docker build時に -no--chace=trueを付けてみても駄目だった
docker関係ないだろ
VMware Fusionでも買って Ubuntu でも入れて
出先のMacノートではそれで開発すれば？って気がするな。
下手するとネイティブより速かったりして。
それな。MacのCLIってなんであんなに遅いんだろう？
WSLと大差ない。WSLができてMacで開発するメリット無くなったわ
HTML を更新後に、ウェブサーバーで再読み込みするとか、再起動すれば？
Windowsも遅いからクライアントOS志向だとその辺で手を抜くのかね？
>>958
ありがとう〜
多分npmのキャッシュが原因なのかなぁ
nodemonっての使って更新されるようになったけど
結局はnpm startをリスタートしているだけで待ち時間が少し早くなった程度
dockerはむつかしい＾ｐ＾
Docker以前のおま環のことで荒らすなや
きくちももこ学生です並のウザさは健在
やっぱりMacでdocker buildがフリーズする
再現性あるならgithubにでも書いてきたら？
どういう運用かわからんけどcoreutils周りとか
同じコマンド名で挙動が違うのにひっかかってるだけじゃないかって気が
これで再現するっていってんでしょ
for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done
運用が何の関係があるのかさっぱりわからん
（バグを）運用でカバーすれば大丈夫だからバグじゃない！とか言うつもり？
バグはバグだよ
こんな便所の落書きでボヤいても直りゃしないからちゃんと報告しろっていう話よ
めんどくさい、だれかやって
再現や英語書きで2時間くらいは最低でもいるから
1人月150万円だと2万円は必要な作業なわけだがもしかしてタダで人を使おうってこと？
ホントに仕事として請け負うならやり取りのフォローアップも考慮して10万円コースよ。
ホントだな15回目で固まるわ
>バグはバグだよ
とはいえユースケースが想像しにくいテストコードでのバグってのは
みんな対応したくないもんで。
もっと重いコンテナでも同じように落ちる？
特定のコンテナだけだったりする？
これのdupeだったりしないかな
そういうこと。2万円は必要な作業を俺はやりたくないｗ
> とはいえユースケースが想像しにくいテストコードでのバグってのは
ユースケース？ docker buildのユースケースがわからないの？
docker buildを行うとｎ％の確率で固まるっていう不具合なんだけど
運が悪ければ、1回目で固まる。
> もっと重いコンテナでも同じように落ちる？
自分で試せよ。どんなイメージも関係ない
docker buildがまれにフリーズするというバグ
ただクラッシュじゃないんだよね。
おそらく排他制御とかでデッドロック状態にでもなってるんだろう
18.xまでは問題ないから19.xのBuildKit周り（の並列処理）が怪しそう
docker buildを行うとｎ％の確率で固まる
特定のコンテナに限らない
reprexは
for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done
と初めからから書くとみんな幸せだと思う
> macOS版のDockerで、docker buildがたまにフリーズするバグの回避方法ない？
kubernets関係の起動しないトラブルも2年近く治ってない。
windowsやmac版はそんなもの。
パイプラインの問題（？）と何の関係があるの？
そもそも、お前が知ってるパイプラインの問題って何さ？
特定のプロジェクトをビルドする環境を構築したり保存したりできたらいいのにな
macOSにはコンテナってないのか？
曲がりなりにもUnixなんだからchrootはあるはずだが、
プロセス分離するとかそれ以外の機能が足りないのか？
作る人が居ないだけなんじゃないかと
LinuxとWindowsはCUIだけでも使いものになるから
コンテナがある。という話？
単にAppleにコンテナ技術に関するやる気がないってだけの話。
・WindowsのネイティブGUIアプリと
WSLは別のサブシステムで動いていてやり取りに制限があるのに対し、macOSのネイティブGUIアプリとCLIツールは同じ世界で動いてるのでそういう制限がない
のでmacOSの方がまだちょっとCLI環境的には強い
> ・WSLは追加で入れる必要があるけどmacOSは最初から一通り入ってる
MacのCLIはApple非公式のHomebrewを別途入れないとまったく使い物にならんぞ
となると仮想Linuxベースになろうが抵抗感が無いからMacネイティブへの需要はなかなか少なくんじゃないのかなぁ
今Linux向けアプリ（クラウド関係はゲームも含めてほぼ全て）を
作ってる人はLinuxを選ぶってことだよ。
MacはBSD系だから今の時代少数派に分類される
Linux→BSDはストレスが溜まる
なぜならBSDのコマンドはLinuxのものと比べて低機能だから。
さらにLinuxの情報が使えない上にBSDの情報が少ない
BSDといってもFreeBSDとかとも違うから実質Macだけの情報しか使えない
まったくというわけでもない。
WSLなしのWindowsに比べれば、素のmacOSの方が100倍くらいは便利。
>BSD→Linuxは割と簡単
>Linux→BSDはストレスが溜まる
>
>なぜならBSDのコマンドはLinuxのものと比べて低機能だから。
一丸には言えない
>さらにLinuxの情報が使えない上にBSDの情報が少ない
manが読めない人にはそうかもね
BSD→Linuxソフトウェアが古すぎて腰を抜かす
それってエンジンなしの自動車に比べれば
自転車のほうが速いって言ってるようなもんやでｗ
> 一丸には言えない
いえるいえる。全部低性能
> manが読めない人にはそうかもね
manもLinuxの方が多い。それにBSDだと--helpがめっちゃ少ないしｗ
> BSD→Linuxソフトウェアが古すぎて腰を抜かす
古いのって例えば何？
ssh,nginx,bash,zsh,tmux,mariadb,python,named,postfix,syslogd,clang,h]gccほぼ全部において古い
manが追いついてないコマンドいくつあると思ってんよ
基本コマンドが貧弱なんだよ。
最低限しか実装されていない。
よく使う基本コマンドだから困る
> 1996年、ブルース・ペレンズが書いたのが起源である。Debianディストリビューション用の
> レスキューディスクにもインストーラにもなるフロッピーディスク1枚の完全なブート可能システムとして設計した
1. busyboxはLinuxのためのもの
2. BSDはレスキューディスクと比べるぐらい機能が低い
新しいスレッドを立ててください。
life time: 952日 14時間 18分 59秒
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
レス数が1000を超えています。これ以上書き込みはできません。
ニュース
- 埼玉の在日クルド人に差別や攻撃 県外からも電話「SNSで見た」 [少考さん★]
- 慶應義塾長が国立大の学費増額を提言「年55万→150万に」 文科省の会合で [少考さん★]
- 【サッカー】U-23日本代表、UAE代表に完封勝ちで2連勝！日韓戦を前に決勝トーナメント進出を決める [久太郎★]
- 【理研】日本人の祖先は「縄文系」「関西系」「東北系」の３系統か、ゲノム分析で従来の説「縄文と弥生」に疑問 ★2 [樽悶★]
- ロシア出身YouTuber、経済的困窮で「国ガチャ失敗」？嘆く日本人を一喝「給料13万？自分のせいやん」日本を「大当たり」とする理由は [muffin★]
- 築地市場跡地に5万人規模スタジアム建設へ 事業者は三井不動産など ★２ [ぐれ★]
- AFC U23アジアカップ カタール2024★8
- AFC U23アジアカップ カタール2024★9
- AFC U23アジアカップ カタール2024★10
- 【酒】日本vsUAE【U23アジアカップ】
- 【フジテレビ】2024 FORMULA 1【NEXT】Lap269
- とらせん祝勝会 ★2
- スピードランニングってあれ効果あるの！？
- お前らいつから自分のこと「僕」って言うようになった？社会人で俺とか言ってるやつおらんよな？
- このおばさんとセックスできる？
- 昼休みに話しかけてくる上司、先輩
- 今年のフジ新人アナがこちら🌸※画像あり [786835273]
- ちんちん見たいから銭湯行ってこようかな