TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
Androidプログラミング質問スレ revision54
Visual Studio 2017 Part6
コメント研究すれ。
インデントを強制しても綺麗なコードにはなりません
C言語相談室(上級者専用）
ますたーのお勉強中の独り言スレ
プログラム板へのID導入の投票実施中　月曜0:00まで
1行ずつC言語を書いてくスレ（目標なし）
【最強CUI】PowerShell -Part 2
SVG波形ライブラリ

仮想環境コンテナ総合スレ Docker、Vagrant等


1 ：2017/02/16 ～ 最終レス ：2019/08/29
開発に仮想環境やコンテナを使う機会が多くなってきたので、みんなで情報交換しませう

よろしこ

2 ：
dockerとかvagrantってそこそこいいスペックのPCじゃないと重いですか？
Core i3とかメモリ4GBとかオンボードじゃきついですか？

3 ：
dockerは別に重く無いよ

4 ：
vagrantで遊んでて、気づいたらディスク容量が…

5 ：
vagrantはコンテナじゃないよ　ホスト型
スレ立て直し

6 ：
http://www.doraibu.com/
どらいぶ帳よろしく

7 ：
vagrantについて質問です。
ポートフォワーディングで同一LAN内の別端末からhttpアクセスしたいのですが、うまくいきません。
config.vm.network "forwarded_port", guest: 80, host: 8080, host_ip: "127.0.0.1", id: 'http'
これだとvm立ち上げたPCからはlocalhost:8080でアクセスできますが、別端末からアクセスできません。

host_ipを192.168.3.8のように指定すると、別端末から192.168.3.8:8080でアクセスできますが、他のメンバーとvagrantfileを共有する際に編集する必要があります。
host_ipを指定しないと、The requested address is not valid in its context.のエラーが出ます。

どうにかうまく他のメンバーがvagrantfileを編集する必要なく、同一LAN内の別端末からアクセスできるようになりますか？

8 ：
127.0.0.1はローカル・ループバック・アドレスと呼ばれ、
自分自身を指す特別なIPアドレスである。
「localhost」という名前でも参照できる

自分自身の上で動作しているサービスへ接続する場合は、
このIPアドレスを利用できる

9 ：
開発用の低スペックWindowsに1台で完結する環境構築するならDockerがいいんだけど
Dockerfileだとテスト以後のマシンに使えないから困る
結局、同じ構成になるようにAnsibleでplaybookを書く二重管理状態になってしまう

10 ：
dockerですが何をやっても
device or resource busyです。
/var/lib/dockerも削除できません。

どうしたらDockerをリセットできますか？
気になるのは、devicemapper/mntにやたらとコンテナ？があります。
文字の羅列と同じ名称で語尾に-initがついてるもの。

これらすべでumountできません。
い

11 ：
け

12 ：
仕事で使ってる人は、どういう切り分けでツール使ってるの？

vargrant イメージ管理
docker アプリケーション絡みの構成管理
ansible ネットワーク絡みの操作とか色々

dockerってあくまで開発用途？
アプリケーションをデプロイするときに、
docker環境にpushして、そのdockerコンテナを
本番環境にpushするとか冗長化してるの？

13 ：
自分も模索中だけどこんな感じで理解してる


Docker
アプリのカプセル化

Vagrant
仮想環境の新規作成
構成管理の起動

Ansible
すでにある環境の構成管理

14 ：
Docker vagrant Ansible ってプログラミングスキル以外に必要な
インフラスキルってどのへんまで必要なの
Linuxの基本的なディレクトリ体系知ってたり、コマンド使いこなせればOK?
デバイスとかブートレベル、ネットワークのいじり方も必要？
個別のミドルウェアの設定ファイルやいじり方も熟知していないと駄目？

15 ：
環境構築は、プログラマーよりもはるかに難しい

最低でも、LPICレベル1 は必要

16 ：
>>15
じゃあそれできればそこそこ金になる？

17 ：
金とは関係ねーだろ
金っていうのは会社が儲かっているかどうかできまる

18 ：
>>17
いやいや金は大いに関係ある
会社が儲かっていようが無かろうが給料の配分は平等じゃない
会社が必要とするならば給料は高くなる、
上がらないならやめる。習得した技術の内容に需要があるならば
再就職先はあるはずだし、習得した技術の需要が高ければ待遇が
良くなる。だから金は関係ある。
インフラの習得は簡単ではない。しかしビジネスとインフラは直結
しないから、それを評価されうるか、金として還元されるかって超重要じゃね？
めっちゃ頑張って勉強してLPICとかとって、「動いて当たり前。資格なんて意味がない」
とかいわれたら洒落にならないよ。

19 ：
プログラマーで、環境構築・運用ができる人は、まずいない。
だから、プログラマーよりも給料が高い

まず、コマンド・シェルスクリプトを知っている者が、少ない

皆、tmux も知らないだろ。
cron もまともに出来ない。環境変数が異なるから

( ) 内は、サブシェル・子プロセスで実行されるから、
親プロセスと環境変数は共有していないとか

OS・システムの内容は、プログラムよりも、めちゃめちゃ難しいから

20 ：
>>19
OK ありがと。超やる気でたわ

21 ：
>>18
技術力でもらえる金が決まるんじゃないよｗ

極端な例を言えばバスの運転手が
docker使えたって給料は増えない

需要がなければ、何ができたって価値はない。
需要は会社で決まる。

22 ：
>>19
> プログラマーで、環境構築・運用ができる人は、まずいない。

そういうレベルの会社なのに給料が良いとでも？ｗ

そうですね。

結局給料は会社が儲かってるかどうかで決まりますからね
技術力が低くてdockerなど使わないような所でも
会社が儲かっていれば、給料は高くなりますよ。
その人がうまく自分をアピールできればね

23 ：
技術者にも会社を選んだりやめたり、給与交渉したり、
「もうやらないよ？」っていう選択肢があるよ。
俺がいた前の会社には「CSSが書くのがめっちゃ速い」といって評価されている
人がいた。確かにCSSは自己アピールに最適だよ。
見た目ですぐにその人のデザインで主張できるから。ビジネス上の収益に関与できる。
WordPressもそんな感じだ。
JavaScript、サーバ側アプリケーション構築、インフラとなるにつれ
やる内容はマゾくなるわりに、外見上で評価されづらくなるよ。
だからといって「会社が儲かっているかどうかが全て」「ビジネスで成果出せ」
何ていう基準で給料がきまったら技術者なんてたまったもんじゃない。

24 ：
だからたまったもんじゃないという
世の中なんだってｗ

それが嫌なら、会社選ぶしかないよ

25 ：
伸びてると思ったらこれだよ
マ板にいけ

26 ：
使われてるところでは、普通に使われてるから何の評価もないし、
使われてないところでは、そもそも使わないから評価対象にならない

27 ：
データアクセス層のユニットテストにこっそりDocker使ってる
便利だとは思うけどうちはやる気のない会社だからこういう技術を正式に採用することはないだろう

28 ：
GradleもDockerみたいなもんなの？

29 ：
全くの別物

30 ：
vagrant-libvirtでfedora謹製のatom box使って
起動したのは良いけれどvagrant sshで入った後
rootでもuser(vagrant guid)でも読めるが書けないdirがある
結果(sudo) setup.py install 出来ない
こまつた

31 ：
>>30
そのディレクトリ chmodするとどうなるの?

32 ：
>>12
基本的に1プロセスを上げるもの = Docker(Apacheだけとか、MySQLだけとか、そういうこと）
多連装仮想マシンランチャー = vagrants
まっさらのインスタンス(仮想マシンか物理かは知らん）に定型的な設定ファイル入れたり、aptなりyumのパッケージをぶっこむ = ansible(あるいはchef)

いちおうDockerで複数プロセス上げさせることもできるっちゃできるが面倒ではある

33 ：
>>30
chmod 777 書けないdir

でやってみてどうなるかによる
で、chmodがエラーでハネられたらSELinuxRあたりか？　fedoraのatomic試したことないから知らんが

34 ：
>>32
IPとかドメイン、パケットフィルタ関係のマシン外部の
設定までやりたい場合はDockerでいいの?

35 ：
>>34
そういうのはansible
ansibleでやることは
ネットワーク/セキュリティなどホスト設定
Dockerインストール
コンテナ起動

36 ：
Ansibleで冪等性という考え方を知ったときはすげぇと思ったな。
この理論は美しすぎる。

37 ：
>>36
まあ実際には冪等性にはならんけどなｗ

AnsibleだけにかぎらずChefなんかもそうだが、
「○○にする」という形で設定をすることができるが、
ここに書いたこと以外は無頓着

mysqlをインストールするという設定はできるが
PostgreSQLが入っていようが入っていまいが無頓着
PostgreSQLを消すと書かないかぎり、もしPostgreSQLが
入っていたとしてもなにもしない。

だから実行して作られた環境が必ず同じになるとは限らない
単に再度（二回以上）実行しても一回目と状態は変わらないというだけ


んで、最近はImmutable Infrastructureってことで
壊して最初からから設定して、その後変更しないので冪等性は必要なくなっている。
何度実行しても同じ状態になるではなくて一回しか実行しない。

38 ：
>>37
あれ、冪等性とImmutable Infrastructureって違う意味なんだね、
同じことを言ってるんだと思った。いやいや、勉強になりました。
そうか、それでそのImmutable指向なのがDockerやvagrantなんだね。

Ansibleは、「マシン壊さないでスクリプト再実行」
Dockerは、「マシン構築してイメージを固めて、使いたいときはそれを複製
して構築状態を再現する」って感じ？

39 ：
>>38
そう。書こうと思ってたけど他のスレに書き込んでいて遅れたけど、
Dockerでも完全な冪等性はない。

通常はイメージを作り直すたびに最新版として
更新が適用された形でイメージが作られる。
同じ手順でイメージを作るが、全く同じイメージができるわけじゃない。
もちろんそれは意図した動きであるので、問題あるわけじゃない。

そして全く同じものが欲しい場合は、作ったDockerイメージを使用する。


> Ansibleは、「マシン壊さないでスクリプト再実行」
そういうこと。もちろん壊してスクリプトを再実行しても良いが
アピールしている冪等性が有効に働くのは壊さないで再実行するときだけ

40 ：
ベキ等は既存のホストでも使えるって要件とのトレードオフ
気軽に捨てていい端末だらけならこんなものは要らない
既存のマシンは簡単には壊せない
それが客の物ならなおさら

41 ：
>>40
正直それ意味わからん。
客のものだろうがバックアップ取ったら片方は好きにいじればいいだろ。
コピー元が客のものだったとしても、複製したものは自分のものだろ。
個人情報云々も関係ないよ、マシン預けるってことは預けたマシンの中身を
全部知られてもいいってことだから。

42 ：
>>41
そりゃ自社に複製した後なら作るのも捨てるのも自由だろうけど世の中そんな簡単じゃないよ
レガシとの絡みのせいで複製できない(複製するのに多大な工数がかかる)システムは少なくない
技術的には可能でも客のポリシの都合でできないこともある
客か別の企業がインフラの面倒を見てくれるならいいけど
権限を幾らか譲渡するのでうちに来て環境構築してくださいという案件も結構ある
こういう案件では同じ端末にすでに別のアプリが稼働している事が多い
そうなるとリスクが高すぎるからゼロから組み上げましょうなんて提案はできない

43 ：
>>42
いやそれでもおかしい、
結局のところ仕事として請け負っている以上何かを変えなければ
何も達成しないわけで、部分的にディレクトリ構造だけでも切り出して
複製するなりして結局何か変えたり追加したりしなければ仕事に
ならないんだよ。
できない、費用対効果がなさすぎる、リスクが高すぎる或いは見積もり不可ならば
請け負うべきじゃない。
あなたに請け負う決定権がないなら決定した人間の責任。
それで失敗してとやかく言われたりするならば会社を辞めればいい。
上の方でも議論されてたけど。
企業体やビジネスだってImmutabuleでいいじゃんって思うんだよね今の時代。
無責任なこと言ってるみたいだけど最終的にそっちの方が正解なんじゃないかなぁ。

44 ：
・Dockerとシェルスクリプトの違いって
・「コンテナ」「イメージ」「スナップショット」という概念が導入された。
・DockerのためのコマンドAPIが充実しいている。
　くらいなものか？

・AWSと比較したら、AWSよりも使い捨て性がよく、「スクリプト」を作る
　仕組みが整っている。ってな感じかねぇ。

45 ：
シェルスクリプトとは全く関係ない

46 ：
>>31,33

30だけど返事遅れてごめん
chmod 777 dir はread-onlyとか言われて
rwxr-xr-xだっけ？も変わらない
親dirも同じ

ググるとmountナントカをVagrantfileに書けってあって
やってみたけどループとか入れてるので
そのままじゃだめだった
最初からやり直そうかなと思いつつ報知

47 ：
>>44
シェル云々って、もしかしてchrootの事を言いたいのか?

48 ：
DockerってGUIツールとかないの？
GUIは設定した名前や値を覚えてなくていいから便利なんだよなあ
あとスクリプトのテンプレートを生成してくれる支援系ツールとか、
コマンド生成ツールとか充実してるとありがたい。

49 ：
372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているフリーランスのサイトはだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円　平凡な稼働時間の80万円の案件もある。
ユー子も求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ

それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト

473非決定性名無しさん2017/08/03(木) 15:21:30.71

JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる
自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の
間でやらしている。

446非決定性名無しさん2017/08/02(水) 22:12:48.95

JIETに毎月5千円払えば３次から入場できるだろ？
高額をうたうフリーランスのサイトはだいたい５次から４５万円
JIETで閲覧応募できる末端価格からさらに搾取するのが高額をみせつけるフリーランスサイトでした
高額案件をみせつけるフリーランスサイトも案件の取得はJIETでした

自称エージェントはJIETから流れてくる案件を転売してるだけだった。
JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む

50 ：
誰かこのスレでDocker使ってBitCoin掘ってる♂人いる？

51 ：
Moneroなら掘ってるけど・・・・プログラム板と関係なさすぎじゃねえの？

52 ：
インフラの設定ってどう練習すりゃいいのかなって思う。
コンフィグの設定はプログラミングと違って新たな発見とかがないから
苦痛だな。

53 ：
>>52
俺はVM上でテストしてるよ

失敗したり挙動が怪しくなってもスナップショット機能ですぐ元に戻せるから
色んなことを気楽に試せるようになると思う

まあインフラって「動いて当然」だから、必然的に枯れた技術と豊富なノウハウの世界になるのはしゃーない
ただ、“落とさない技術”とか“落ちたときになんとかする技術”とかは、知ってると良いこといっぱいあるよん

54 ：
誰かのせいにする技術

55 ：
データベースコンテナの扱い方がよくわからん
テーブルの作成とデータ投入とマイグレーションってどうすればいいんだ

56 ：
ユーザー単位のプライベート開発環境構築は圧倒的にdockerが楽だな
でもdockerはよくわからんからダメってお客が多くて運用ではイマイチ使えない

57 ：
開発環境と言うからにはGUIのテキストエディタとか
入ってなきゃいけないはずなんだが、それは本当にDockerか？

58 ：
あーうちはそこまで仮想化原理主義的じゃないんだ
エディタとランタイムはローカルの使ってる
ローカルJDK+gradle+好きなエディタ
ローカル.NET+cake+好きなエディタ
サーバーはcomposeでお手軽に構築
ユニットテストはビルドから全部フレッシュなコンテナでやってるよ

59 ：
> あーうちはそこまで仮想化原理主義的じゃないんだ
仮想化原理主義とかいうとVagrantも仮想化なんで
それをいうのならアプリケーションコンテナ原理主義でしょ？

> エディタとランタイムはローカルの使ってる
略
> ユニットテストはビルドから全部フレッシュなコンテナでやってるよ

言葉の定義の問題だけど、それを俺は開発環境とは呼ばないんだよな
だってその環境で開発してるわけじゃないから。
ユニットテストの実行環境

そしてもう一つ。CIとしてコンテナでユニットテストを
動かすってのはありなんだけど、（俺の定義での）開発環境として
ユニットテストを動かすのは大変じゃないか？

俺の定義での開発環境のユニットテストっていうのは
例えばクラスを一ついじった時に、それを保存したタイミングなどで
そのクラスだけのテストを実行したりすること
言い換えるとテキストエディタやIDEからユニットテストを実行するってこと

不可能じゃないと思うけど、そこらへんを整えてくれてるものはないと思うんで
労力を考えるとDockerを使うのは全体のテストを実行するだけでよいCIのユニットテストに限定される

よってユニットテストであっても開発環境としてDockerを使うのは大変であるというのが結論
開発環境だとデバッグのための機能を有効にしたりするしさ。
単に開発で使うサーバーの実行環境として使うのは楽だけどね。

60 ：
>>56
そのお客の感覚はかなり正しいと思うけどな。
少なくとも今のdockerの段階だと。

61 ：
ほぼどんな環境でも動く
デフォルト設定が吟味されてて多くの場合でオプション不要
手軽に細かくカスタマイズもできる
オフィシャルでセキュリティ的に安全
頻繁にメンテナンスされる

そんなRolesが大量に手軽に手に入るなら個人的にはDockerは要らないかな

62 ：
>>60
将来を考えたら根幹に関わる部分で複雑な事はやって欲しくないと思うわな
dockerに限ったことじゃないが、遅かれ早かれ陳腐化する訳だし
枯れた手法と比べて明確なメリットがなきゃ導入しない方が良い

63 ：
そんなのビジネスの内容次第だろ
手早くスタートアップして頻繁にビジネスに変化があると見込まれるなら安定感はそれほど優先度の高い項目じゃない
何でもかんでも枯れてる安定したものがいいってところで思考停止してる人が多すぎる

64 ：
>>62
> 将来を考えたら根幹に関わる部分で複雑な事はやって欲しくないと思うわな

じゃあ、そこで前提として
今より複雑か、簡単かという話が必要になる。

根幹に関わる部分は複雑になっている。
これがDocker使うと複雑なものが簡単になる。

これを否定するならば、なぜDockerを使うと
複雑になるのかを説明しなければいけない。

その時に「俺はDocker知らん。勉強しなければ
いけないから複雑なんだ」では答えになっていない。

もちろんDocker使うと複雑なものが簡単になるというのは説明可能

65 ：
ansibleってなんかめんどくさいな
ベキトウセイとかシェルスクリプトで十分じゃん
apt-get install -y hoge
これだけでもベキトウだよ
なんでわざわざあんなわかりにくい大げさなyml書かなきゃいけないのさ？

66 ：
誰しもがメンテしやすいシェルスクリプトを書ける訳じゃないからね
逆に言えば書けるならそれでいいという話になるが

67 ：
>>66
プレイブックは誰にでもメンテナンスしやすいものだっていうansible側の広告が刷り込まれて先入観があるんじゃないかな？
実際あんなのメンテナンスするのわかりにくいし大変だよ
例えば鍵とかリポジトリ登録するところとかシェルで書くときはこうだなってのわかってないと絶対プレイブックも書けない
シェルがわからない非エンジニアでもプレイブックならわかるって本気でみんな考えてるのかな
その感覚よくわからんわ

68 ：
>>63
自由に導入したらいいよ
明確なメリットがあれば俺も使うし

>>64
複雑というのは習得に掛かった時間と思って貰えたらいい
dockerで用意された環境を立ち上げる事は簡単だが
その用意された環境を構築する作業も簡単とは俺は決して言えない

69 ：
>>68
Dockerを使わずに鯖運用するスキルを身につけるコストのほうが高いと思うぞ

70 ：
>>68
> 複雑というのは習得に掛かった時間と思って貰えたらいい
何を言ってるんだ？

例えば、未経験者にとっては習得に時間がかかると思うが
習得に時間がかかる＝複雑だというのなら、

お前は

未経験者「俺の知らないことだかけ。複雑ですね。導入する価値なし」

って言われて納得するのか？

71 ：
未経験者「俺の知らないことだらけ。複雑ですね。導入する価値なし」

72 ：
>>64
まあ大前提として、一番重要なデータ部分と設定のドキュメント化が
しっかりして残されてる事が最低限だよな。
リポジトリから拾ってきたな様なのにはその辺がブラックボックスなのが
少なくないがw

逆に言えば、それさえ明確にきちんと残されているなら、仮にdockerが
陳腐化して消え去っても移行は全然難しくない。

73 ：
Dockerの素晴らしい点はイメージを作るものは
手順書などというメンテナンスされない傾向にある
ドキュメントではなく、Dockerfileという簡単な
設定ファイルで書くことができるってこと
だからブラックボックスにはならない

でここから二種類の人間に別れる。Dockerfileは
すごく簡単なファイルなんだが、

未経験者の新人ややる気のないSEのような
Dockerfileが読めない人間は、勉強したくないと駄々をこねる
なまじ年を取ったやつが偉そうに複雑だから使えないとか
破綻したことを言い出すわけだ

74 ：
>>69,70
一応言っておくけどdocker不要論者じゃないからね
メリットがあるなら使えばいいと言ってる
要求が上がるにつれて自然と選択肢に上がるんだし

75 ：
windows系がわからん
ssh => winrm
apt/yum => chocolatey
docker => windows server container
ansible => powershell DSC
vagrant => vagrant

これでいいのか？
guiインストーラーしかないマイナーなアプリのインストールとかどうやって自動化するんだ…
誰も使ってなくて相談できねぇ

76 ：
ふつうのWindowsInstallerベースならGUI使わずにインストールできるけどね。
わざわざ独自にGUIインストーラー実装してるような変わり者ならしょうがないが。

77 ：
DockerとかVagrantとかのツールってさ、
例えばLinuxコマンド一切叩け無い人や、
素でサーバ構築した経験がない人がいたとして、
DockerfileやVagrantfileの書き方や、
dockerコマンド、vagrantコマンドだけ覚えた場合でも構築
出来るようになるの？

78 ：
なるわけない

79 ：
Chef 社のレシピを使えば？

80 ：
VagrantfileのRubyの記述苦手、
特にシンボルと配列のキーを指定する記法とがごっちゃになるし、
設定項目と値の間に = 要るのか要らんのかの基準がよくわからない

81 ：
>>77
linux未経験だったけど普通に使えてるよ
プログラムのAPI覚えるのと変わらん

82 ：
Ruby では、= は代入。
変数 = 値

= が無いのは、メソッド名と引数。
puts :abc
#=> abc

メソッド名(引数)の、( ) を省略できる。
常に省略できるかどうかは、知らないけど

83 ：
色々試したけどVagrant+シェルスクリプトがベストだな
AnsibleとDockerはやりたいことに対して実現方法が大げさすぎる

84 ：
Dockerは使う目的が違うから比較するものじゃない。

85 ：
それはそれとして、MacではVagrantを使うまでもなく
実OS上でアプリ開発すればいいし、
Windows もWSLでUbuntuが使えるようになったし、
今の時代でもVagrantを使う必要があるのか悩む

86 ：
環境汚さないためにはVagrantいいんじゃないか
でもMacに慣れた後Linuxやるとめんどくさい
brewだと特に苦労せずサクサク新しいバージョンのパッケージが入る
Linuxはいちいちリポジトリや鍵登録せんとあかん
メンドくさくて環境汚れてもMacでいいやという気持ちになる

87 ：
>>86
だからそこでDockerを使うんだよ。
Docker使えば環境を汚さずに（消したいときはコマンド一つ叩くだけ）
好きなバージョンを入れられる。

88 ：
汚さないって言ってもdocker imageが大量に残るのがなぁ

89 ：
それはもうしょうがない
むしろ docker rmi でいつでも気兼ねなくサクサク消せるのがメリットなんだと割り切っちゃえ

90 ：
windows 7だとdocker machine使わんといかんのがひと手間かかって面倒でなぁ

91 ：
>>90
え？ いらなくね？
普通に最新のDocker for Windowsインストールして
docker ps できたよ。
docker machine使わないといけない技術的な理由思いつかないし


ほら、なにもいない

docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS

docker-machine config
Error: No machine name(s) specified and no "default" machine exists

92 ：
もしかしてWindows 10ならOKで
Windows 7はNGってこと？

93 ：
HyperVに依存しとるとさ

94 ：
DockerってYAMAHA, ciscoのルータとかファイアウォールへのコンフィグ流し込みに
も使えるの？
正直Linuxマシンは手動ゴリ押しでもDockerでも構築できるっちゃできる。
だけどこれらのOSとかAndroidとかLinux以外が簡単に構築できたらめっちゃ
便利やん。
Winはその・・・お察しだな。

95 ：
>>94
補足:
cisco, YAMAHAとかのOS独自のコマンド操作とかGUI操作のものを、
RubyとかYMLとかDockerfileの文法に変換して統一出来たらいいなってこと。

96 ：
Dockerはそもそもそういう用途のものじゃない
AnsibleにIOSのモジュールがあるっぽいよ
https://gblogs.cisco.com/jp/2016/11/ansible-ios-related/
リアリインフラは触らないから使ったことはないが

97 ：
あるサーバを構築したときのコマンド入力作業を
historyからシェルスクリプトにしておけば、
DockerやChefと同じことできるんじゃないの?
全く同じサーバが1枚のフャ@イルで構築でｂｫるじゃん。

98 ：
Dockerの方がパフォーマンスが良いし
レジストリも充実してるよ
あとDockerって慣れてくるとDockerfileは自分では殆ど書かなくなってrunとかcomposeがメインになってくるんだわ
だからシェルスクリプトとじゃ比較にすらならない

99 ：
oracle公式のイメージって無いの？

100 ：
VirtualBoxがDocker意識してUI作り込んだら
便利かもしれん。
ホスト側の管理はUIあったほうがやりやすいからな。

101 ：
GUIが欲しいならKitematicがあるやん
でもコマンドラインに慣れておいた方が自動化の環境構築をパパっと作れて良いぞ

102 ：
Dockerってcronとかバッチみたいなジョブスケジューラ
機能もあるの？

103 ：
ない

104 ：
DockerってGUIは動かせんの？

105 ：
動かせるよ

106 ：
>>102
host側のcronでdockerを叩けば良いんじゃない？ー

107 ：
>>105
マジデ！？
GUIコンテナ絶対便利なのにやってる人見た事ないなぁ
EclipseコンテナとかVisualStudioコンテナとかあれば絶対流行る
必要なもの全部入りで隔離されたクリーンな環境とか最高やろ
しかもコマンド一発でインストールできちゃう

108 ：
>>107
普通に使ってるけど…

109 ：
上司に「Docker使いましょうよ」って提案してみたら、
「Xamppで十分でしょ」って返された。
何か言い返したかったがこれと言って強力な
Xamppに対するアドバンテージが思いつかなかった。

110 ：
え？それってギャグで言ってんの？

111 ：
DockerはXamppじゃない。用途が完全に違う。

というかDockerを使ってXampp相当のものを
作ろうとすると相当大変だぞ

Docker使ってPHP製のアプリを実行する所までならまだわかるが
Xampp＝通常は開発用にするには、更に色んな機能が必要になる。

112 ：
ドライバーと工具箱くらい違うだろ

113 ：
使い捨てしない場面でDocker使う意味あんの？
ビルドとかユニットテストに使うぶんにはDocker軽いし便利だけどね
ビルドサーバー汚さんですむのは嬉しい
でもサービス運用には向いてないでしょ
Dockerでイミュータブルインフラ実現だ～ってエキサイトした時期もあったけど
それはクラウドの仮想化サービス使えって結論でちゃったし

114 ：
>>113
Googleは全てのものがコンテナ上で動いてる

115 ：
>>113のようにDockerを分かってない人の典型例は、
Dockerがアプリデプロイ用のためのものだって
分かってないってことなんだよね。

クラウドの仮想化サービス使え？
その仮想化サービスにお前が作ったアプリを
配布するのはどうするんだよって話

116 ：
次の反論も想定できるから先に行っておくと、

アプリデプロイするなら、デプロイツールを使えばいいだろ？だって？

お前のアプリはどのOSでも同じ手順でデプロイできるのか？
ミドルウェアは何も使わないのか？ライブラリは何もいらないのか？
手元の開発環境（WindowsやMacOS）で動かしていたものが
クラウドの仮想化サービス＝Linuxで動くのか？

Docker使えば手元で動かしたLinux用のDockerイメージを
そのままクラウドの仮想化サービスで動かせるんだよ。

117 ：
もしこのあと反論があるとしたら、

うちはJavaを使ってる。一度プログラムを書けば、どこでも実行できる
Write once, run anywhereだよ

かな？


http://www.wdic.org/w/TECH/Write%20once%2C%20run%20anywhere
> 実際には、バイナリレベルでは仮想計算機の実装のバグ、ソースレベルではAPIの
> 実装バグやそもそも対応するAPI仕様の違いなどにより、どこでも確実に動くと断言できることはあまりない。
> このため、"Write once, test(debug) everywhere"(一度書いて全個所で試験(デバッグ)する)と揶揄されることもある。

118 ：
配布ごときなんでもいいよ
むしろたかがアプリケーションのデプロイにDockerを使うのは過剰すぎる

そもそもどんなOSにも配布する必要がない
他人に使ってもらうためのアプリケーションしか考えられないバカか？

ミドルウェアやライブラリは仮想マシンイメージに入れときゃいい
なんならイメージはまっさらにしてansibleで構成してもいいだろう

手元で動かしていたものがクラウドで動くんだよ
お前はテストしたことないのか？

119 ：
JVMのバグは気にするのにDockerのバグは見て見ぬ振りかよ
お前の環境のDockerとクラウドのDockerが同じ保証はどこにあるんだ？

120 ：
銀の弾丸を手に入れたつもりになってるバカってほんと迷惑だよ
うちにもDocker Dockerうるさい奴がいるけど
そいつはDocker使いたいだけでDockerの事も社の保有するインフラの事情や社内政治のことをなんもわかってない

121 ：
手元で動いてこりゃ便利とか思ってるだけで
実際に大規模なサービスで運用したこともない雑魚なんだろうな
ぶっちゃけ透けて見えるよ

122 ：
JavaのWrite once, run anywhereが失敗したのは、
違うOSなのに、Javaの力だけで同一の実行環境を
作り出そうとしたところなんだよな。

Dockerのアプローチは別で、Linuxという環境のみで
Write once, run anywhereを実現したということ。
Linuxでしか動かないじゃんと思うかもしれないが、
WindowsとMacではすでにある仮想マシン技術を利用することで実現
もっともWindowsとMacは本番用途としては考慮されてないと思うが。

本当に同一環境か？という点で見ると、Linuxのカーネルの違いというものはある
だけどLinuxは元からカーネルが違ってもユーザーランド（カーネル以外）には
100%に近い互換性を持たせる方針なのでそれが問題なることはない。

だからローカルで開発で使用していたDockerイメージをそのまま
クラウドの仮想化サービス上に持っていくことができる。
その作業も単にdocker runするだけ

123 ：
>>118
> そもそもどんなOSにも配布する必要がない
> 他人に使ってもらうためのアプリケーションしか考えられないバカか？

え？ 自分一人で使うアプリケーションしか考慮してないの？

普通は他人に使ってもらうアプリを作りし、開発する人も複数人、デプロイする人も自分以外にいる。
プロジェクト外れて他の誰かに完全に引き渡すことも有るし。

124 ：
所詮は方針だろバカ
テストしろ

125 ：
>>121
> 実際に大規模なサービスで運用したこともない雑魚なんだろうな

実際に大規模なサービスで運用するならまずDockerだよｗ

いろんなクラスタ管理ツールが生まれてきたけど、
今はkubernetesに集約されつつ有るな。
これはDockerイメージを使うことが前提となってる。

知らない人もいそうなので適当に引用すると

https://qiita.com/MahoTakara/items/85096f8b2632c802ab22
> Kubernetes（クーべネティス）を一言で言うと、自動デプロイ、
> スケーリング、アプリ・コンテナの運用自動化のために設計された
> オープンソースのプラットフォームです。
> Kubernetesによって、要求に迅速かつ効率良く対応ができます。

あんた実際に大規模なサービス運用したこと有るんでしょ？
何使ってる？

126 ：
>>123
そこで自分一人で使うって解釈になるのがアスペくさいな
サービス利用者は幾らでもいる
開発運用する側がプロジェクトメンバーと連携するのは当たり前だろ
むしろお前はプロジェクト内でOSも定めずに作業してんのかよ
どんだけ適当な職場なんだ

127 ：
>>125
>まずDocker
ねーよwww
普通にansible使え

128 ：
はぁ
アホの相手は時間の無駄だな
休日に何やってんだろ俺

129 ：
>>124
テストはするだろ？

ローカルのDockerイメージでテストすれば
それがサーバーでも動くことが保証される。

もちろんアプリの話ね。ローカルの開発と実際のサーバーでは
インフラの構成は違うので、その部分はテストが必要。
アプリの部分のテストがローカルでできるって話。

ちなみにローカルであっても実際のクラウドと互換性がある環境を
用意することでテストすることもできる。
その場合はminikubeを使うと良いよ。Kubernetesの公式ツールで
Kubernetesと同等の環境をローカルに作り出すことができる。
もちろんDockerイメージが有ることが前提

大規模開発ってDockerがないと大変だよねｗ

130 ：
>>127
ansibleでどうやってクラスタ組んで自動デプロイやスケーリングやってんの？

ansibleは特定のOSというか異なるディストリどころかディストリのバージョンが
上がった時でさえ使いまわしできないもので、環境ごとに用意するもの。
そして最低限の環境を作るものだよ。
OSとDockerのインストールと簡単なネットワーク設定程度にとどめておいたほうが良い

いちいちansibleでアプリから使用するライブラリのバージョンが
アップデートされたから入れ直しますとかやらないほうがいい。
そんなことやるとトラブルのタネにしかならんよ。

ansible（等）の冪等性は書いて有ることはその通りに設定されるけど
書いてないものに関しては、我関せずだからね。
環境ごとに用意しなければいけないansibleにたくさんのことを書くはめになる。
そしてそれはローカルの開発環境には使用できない

131 ：
>>126
> むしろお前はプロジェクト内でOSも定めずに作業してんのかよ
> どんだけ適当な職場なんだ

実行OSと開発OSが別ってだけですが？

いえ、サーバーと全く同じOS、例えば超軽いが実行専用にカスタマイズされていて
テキストエディタすら入っていない、CoreOSやContainer-Optimized OSを
普段の開発用OSとして使ってるっていうのならいいんですよ？

なぜ開発しやすい環境で開発して、それをそのままサーバー上で動かさないのでしょうか？ｗ
まあそれができるのがDockerというわけ。

132 ：
本番でDockerもAnsibleもautoscalingも全部使うよ
使い方がわからないものは使わないほうがいいよ
便利の定義はスキルセットによるし

133 ：
autoscalingってAWSの機能か？
kubernetesはGoogleが作ったものだけど
GCP上ではなくAWSでも動く
俺はGCP上でしか使ったこと無いけどね。

134 ：
> 121 名前：デフォルトの名無しさん[sage] 投稿日：2017/10/15(日) 11:24:20.20 ID:jiVarmiT [6/10]
> 手元で動いてこりゃ便利とか思ってるだけで
> 実際に大規模なサービスで運用したこともない雑魚なんだろうな
> ぶっちゃけ透けて見えるよ


さて、こいつが大規模サービス運用したことが有るような
発言してくれるのはまだだろうか？ｗ
低いスキルセットしか持ってないのが透けて見えるよ。

135 ：
上の方でDockerの技術がわからないから政治問題にすり替えようとしている人がいたけど、
コンテナ自体はLinuxカーネルの機能で、Dockerはそれをラップしているツール。
代替技術は他にも有る。

例えばrkt。検証はしてないがKubernetesでも対応している。

そしてこういうものも有る。
http://www.publickey1.jp/blog/16/kubernetescri-odocker.html
> Kubernetes、独自のコンテナランタイム「cri-o」開発中。
> コンテナランタイムのインターフェイスを標準化し、
> Dockerだけでなくどんなコンテナランタイムでも対応可能に

136 ：
Dockerは仮想化とコンテナ、AnsibleはDeploy
コンテナはDeployの一手段だから混同してしまうのは仕方ない
ID:/8UsyUgnも煽るような言い方してよくない

137 ：
> ID:/8UsyUgnも煽るような言い方してよくない
良いだろｗ　それが２ちゃんねるだ。

138 ：
Ansibleは構成管理ツールだよ。マシンの構成を管理するだけ
アプリのデプロイは行わない。

もちろん頑張ればデプロイもできるけど、構成管理ツールで現実的なデプロイは
すでに完成されたアプリを動かす程度
いま自分らが開発している真っ最中のアプリは内容が多くなりがちで変更も頻繁に発生するので
Ansibleでやるのは大変。playbookが正しく動くかのテストが必要になる。
作成したplaybookはなるべく変更しないような、そういう使い方にとどめておいたほうが良い

んで、Dockerももちろんデプロイツールではない。デプロイを容易にするために
開発しているアプリとその周辺（ミドルウェアやライブラリ）をひとまとめにするもの。

デプロイする時に細かいコンポーネントに別れていたら、
それらを一つ一つデプロイするものとして書いていかなければいけないけど、
それらがひとまとめになっていれば一つだけデプロイすればすむ
それがDockerイメージ

デプロイするべきものが一つになるので、デプロイはツールを使うまでもないんじゃね？
って言いたくなるほど、シンプルになる。

そこまで来るとAnsibleを使って、Dockerイメージをデプロイするのもありだよｗ
そう。AnsibleとDockerは組み合わせて使うものなんだ。

まあGCPなどのクラウド使っていれば、その基本機能としてDockerイメージを
使う方法があるから、Ansibleを使わなくて良いんだけどね。

139 ：
俺もansibleはゴミって昔から主張してるけど、なぜかありがたがって使う人がいる
互換性酷い、yaml生産性悪い、かゆいとこ手が届かんで最悪
docker & ssh & shell scriptが最強
この組み合わせなら、誰でも使えるし、可能性も無限大
KISSの原則ってやつだな
dockerはどうなるかわからんがssh & shell scriptは長く安心して利用できる点も高評価

140 ：
>>139
> 互換性酷い、yaml生産性悪い、かゆいとこ手が届かんで最悪
それな。

使うために "中間層" が必要なるという仕組みが悪い
アプリのインストールや設定とか普段シェルスクリプトでやってるはず

だけどAnsibleとかそのアプリをインストールするためのプラグイン（中間層）が必要になる。
それをアプリが公式に用意しているならまだマシだけどそれは少数派
Ansibleがどれだけ成長したとしても、アプリに完全対応はできない。
バージョンが変わるたびにこの組み合わせで正しく動くだろうか？って考えなきゃいけない。

そしてプラグインを使うための知識が必要になる。
普段シェルスクリプトでやってるのと同じことをやるだけなのに
別の知識と道具が必要になる。

あとYAMLは本当に設計ミスだと思う。
構成っていうのは一連の流れで作るものなので
スクリプトの方が適切。

141 ：
ansibleはmodule使ってる限り冪等なのがいいんだろ

そして、yamlもそこまで悪くない
docker-composeでも使うし、生産性低いならきちんと訓練すべきだと思う

142 ：
> ansibleはmodule使ってる限り冪等なのがいいんだろ

「使ってる限り」と言ってる時点で駄目なんだよ。
なぜmoduleを使う？ 自分で作ればよかろう？
もちろん作るのが大変だから使うのだろうがそれで起きてるのが互換性問題。

アプリ開発社からすればAnsibleや誰かが作ってる
非公式の質の低いモジュールを使わざるを得ない
ここでいう質の低いっていうのは、アプリのあるバージョンに
完全に対応していなかったり一部の機能が抜けていたりする。
そしてそれを自分で直さないといけなくなる

Dockerの場合はモジュールなどというものはなく自分でDockerfileを作るのが基本
もちろんある程度用意されているがほんの数行のファイルなので自分でメンテナンスできる。

> そして、yamlもそこまで悪くない
YAMLが悪いと言っているのではない。設定として使うのは問題ない。
構成管理のように順番があってその通りに実行していかなければいけないものを
YAMLという順番が関係ないようにみえる形式を使うのがダメだという話
やってることがスクリプト実行ならスクリプトで書けば良いんだよ。
設定とスクリプトは違うもの。

143 ：
まぁ、そんなこと言い始めたらshなんて可読性も低いしpythonのほうがいいとかになるんだよね
少なくとも個人が書いたスクリプトより、ansibleのmoduleのほうが信頼性は高いよ
DockerだってFrom句使うほうが普通だろ
なんで、どっちかはダメと攻撃せずにいられないのか
酸っぱい葡萄が大好きなんだな

144 ：
> まぁ、そんなこと言い始めたらshなんて可読性も低いしpythonのほうがいいとかになるんだよね
> 少なくとも個人が書いたスクリプトより、ansibleのmoduleのほうが信頼性は高いよ

意味が分からん。ごく普通にシェル使ってインストールとかしてるだろ？
もしかして黒い画面恐怖症かなにかか？

スクリプトは単純に何かのインストールコマンドと
ファイルの変更ぐらいしかしないよ。
なんでいつもやってる作業を置き換えないといかんのさ

145 ：
> DockerだってFrom句使うほうが普通だろ
From区にはdebianとかrubyとかしか使わんなぁ。
公式で用意されていればそれ使うけど、
用意されてないならされてないで
自分でDockerfile書くだけだし。

146 ：
っていうかFrom区ってなんだｗ
FROMだろ

147 ：
誰が書いたかも知らないようなmoduleは危険だぞ
人類はnpm left-padで痛い目にあったばかりじゃないか

148 ：
それな、DockerとAnsibleの違い

Ansibleは自分でやるべきことを誰かにやらせて楽をする。
Dockerは自分でやるべきことを自分でやるがその作業が楽になる。

誰かにやらせて楽をする方がいいかもしれんが、
それはその誰かが信用できる場合だけなんやで。

149 ：
>>145
あ、そうなんだ。そういう人にとってはansibleのモジュールは使いにくいかもね。
一般的にはnginxとかフレームワークくらいは使うと思うけど。
てか、yml書くのだってvimが普通なのに、なんでsh書かないとterminal恐怖症なんだよ
意味わからん

150 ：
てか、ansibleもDockerも同じ
なくてもどうにかなるんだけど、使える人は使う
使えない人は使わないし、使いたいとも思わない
そんだけ

151 ：
ansibleは生産性下げてるよ
fabricとかでいいじゃないか
ああいうのでいいんだよ、ああいうので

152 ：
>>149
Ansibleのモジュールはシェルスクリプトでできることの
全てを網羅してないっていうのが一番の問題なんだよ。

nginxがバージョンアップした時、新しく追加された設定項目に
モジュールはすぐに対応してくれない。

シェルを使っていればすぐできることが
Ansibleだと対応する機能をいちいち調べて
シェルとは違う方法で記述しないといけない。

その中間の変換作業が無駄

それに当然の話だけど、Ansibleは自社で開発しているアプリ用の
モジュールが存在しない。作らないといけない。
おかしいと思わないのかね？ シェルですでにやってる作業と同じことを
調べ直す作業を何故やっているのかと

あー、もちろんAnsibleでシェルスクリプトを実行できるのは知ってるよ。
そんなのを使うならシェルスクリプトでいいじゃんって話だからね。

153 ：
それでいいんじゃね？
別に使わないとできないことはないよ
でもそれはshellだろうがDockerだろうがAnsibleだろうが同じ

そもそもAnsibleは環境構築以外だと、デプロイの導火線の発火に使うことが多いだろうから自社アプリ用のモジュールがなぜ必要なのかわからんけど
あなたにとってシェルがベストな選択肢なら、シェルがいいんじゃね？

154 ：
>>151
そこらへんは議論の余地があるかもね
他にもPuppetもあるしChefもある

全部sshとshで実現できるってんなこといったら、その他スクリプト言語もラッパツールも全否定だからな…
彼は一体何と戦ってるのか…

155 ：
たかが数行、長くても数十行の単純なスクリプトでOK
冪等性などという高尚な概念を導入しなくても問題なく運用できる
これでわざわざ構成管理ツールを導入しようって方がどうかしてる

156 ：
>>153
> そもそもAnsibleは環境構築以外だと、デプロイの導火線の発火に使うことが多いだろうから

だろ？ Ansibleでデプロイはしないし、だからデプロイそのものが簡単になるわけじゃない。
デプロイをするのはデプロイツールだが、Dockerを使えばデプロイツールが不要になる。
なぜなら単に1アプリを動かせばいい程度になるから
>>138ですでに書いたことだけどね

> あなたにとってシェルがベストな選択肢なら、シェルがいいんじゃね？

クラウド使って大規模アプリ開発をするようになると必然的にそうなるよ
トラブルを避けるためローカルとサーバーでなるべく同じ環境でやるのが良いんだが、
サーバーと同じOS使って開発するのは現実的ではない。
だからDockerを使ってアプリの実行環境だけを同じにする。

Dockerを使うと冪等性は必要なくなり、デプロイの内容もシンプルになる
一番楽なのがシェルスクリプト。Dockerfileもシェルスクリプトがベースになってる。

>>154
> 彼は一体何と戦ってるのか…

俺？ 俺は↓これと戦ってる。これと

127 返信：デフォルトの名無しさん[sage] 投稿日：2017/10/15(日) 11:35:26.06 ID:jiVarmiT [9/10]
>>125
>まずDocker
ねーよwww
普通にansible使え

157 ：
> 他にもPuppetもあるしChefもある

PuppetもChefも、普段誰もがシェルスクリプトでやってることを
置き換えるには、重すぎる。いつもやってることをやるだけだろ？
本来新しいことは何も覚えなくてすむはずだ。

> 全部sshとshで実現できるってんなこといったら、その他スクリプト言語もラッパツールも全否定だからな…

そんなことは言っていない。
sshとshで実現できると言ってるのは、普段シェルでみんながやってる作業だけだよ。

パッケージのインストールとかその設定ファイルの変更とか、
そんなのその他のスクリプト言語やラッパーツールでやってないでしょｗ

普段やってることは普段やってる方法でやりましょうってこれだけの話だよ。
みんなシェルスクリプトでやってるんだからそれでいいじゃん。アホらしい。

158 ：
俺は逆にクラウド使うって大規模なクラスタ組む時以外はansibleなんて使わんけどな
できることはシェルと同じでもRoleやinventoryパターンに慣れたらsshだのシェルだのなんてやってられんわw

159 ：
可読性とモジュール性とかカプセル化、の問題じゃね?
シェルにはオブジェクトや配列はない。
それどころかまともに型もない。
Ansible Puppet Chefはシェルに型と配列記法を
無名関数なんかを使えるようになっているから付加価値はあるだろ、
1つあれば十分のようには思えるが。
C言語あるからわざわざJava覚える必要ないって
言わないでしょ?

160 ：
インベントリ管理は便利だと思う
Yamlはなぁ…これpythonそのままでよかったんじゃねえか？

161 ：
>>159
DSLって知ってる？ドメイン固有言語。
特定のタスク向けに設計されたコンピュータ言語

シェルというのはユーザーとコンピュータとの対話を行うために作られたもので、
慣れも有るだろうけど日常的な操作（＝特定のタスク）が使いやすいもの
シェルスクリプトはその日常的な操作をスクリプトにしたもの。
言い換えると日常的な操作に特化したDSLなんだよ。

型や配列が使えるからということで、シェルの代わりにプログラム言語使って
system()関数とかでコマンド呼び出しとかしないでしょ？

だからプログラム言語的な能力で比較するのは意味ないんだよ。
一般的な言語の機能を捨ててまで、特定のタスク向けに設計しているわけなんだから。
用途（プロビジョニング）を前提に適しているかどうかって話をしないと

> シェルにはオブジェクトや配列はない。
bashなら配列も連想配列もある。
が、そもそもプロビジョニングという用途で配列とか連想配列は使わん

162 ：
YAMLとかPythonがダメって言ってるんじゃないよ。
普通に何かを作る時は使ってるし。

普段やってる作業を、別のやり方に変えるのが無駄だなぁって話

その別のやり方に大きなメリットが有るならまだしも、
別のやり方に変えるプラグインが必要で、そのプラグインができることしか
できなくなってしまうとか、劣化してるからさ。

163 ：
>>161
プロビジョンで配列や連想配列を使わないんじゃなくて
便利じゃないから誰も使わないだけだよ。
bashに配列があっても集約する対象として複雑な概念が
オブジェクトとして構造化されていないから。
bashがRubyやPythonが出て来る前から設計されていたわけじゃないし
Chefとかはbashよりもさらに進化してオブジェクト指向に対応した
プロビジョン用DSLなわけじゃん。
Chef内でシェルも記述できるんだからシステムコール使いたいなら
そこで使えばいい。
依存関係もbashでInculudeなりラッパーするなりより
プロビジョンツール使ったほうが整理しやすいよ。

164 ：
要る要らないとかどうでもいいわ好きなもん使えよ

165 ：
スレが伸びてると思ったら、奇形児が暴れてたのな

166 ：
Ansibleは奇形

167 ：
>>163
プロビジョンのどこで配列や連想配列を使うんだ？

168 ：
>>163
なんかお前、本末転倒になってるよな。
やりたいことベースじゃなくて
配列が有るから配列使うんだ、
オブジェクト指向だからすごいんだ
みたいな

> Chef内でシェルも記述できるんだからシステムコール使いたいなら
> そこで使えばいい。

ならシェルスクリプトでやればいい。
っていうか普段のセットアップ作業でシステムコールなんか使わない

だから普段の手動のセットアップ作業を思い出せって
そこで必要なものしかいらないんだよ。配列とか使ってないだろ。
（もちろんループなどはシェルスクリプト使える）

169 ：
配列も連想配列も使うだろ
俺はansibleは嫌いだしシェルも可読性ゴミだからpythonで書いてるけど

170 ：
>>169
どういう時に配列や連想配列使う？
何度も言うけどシェルを使っている時という前提は忘れないでね。

シェルを使うの具体的な例は、cdやlsやapt-getやcpやrmなど
CLIコマンドを使って何かしらのアプリのインストール作業
プロビジョニングの話なんだからそれぐらいは前提

あとforで$@をぐるぐると引数を回すのは配列ではない。
だってそれを配列と言ってしまうと、>>159の前提である
> シェルにはオブジェクトや配列はない。
が崩れてしまうから、引数のことではないのは明らか

171 ：
>>170
サブネット全体に同じ設定入れたいときに、CIDR表記からipの配列作って応答あるものだけの配列にして設定ばらまいたりする
あと、mongodbのインストールするときにsource listにおまじない書かなきゃいけないんだけど、
osのversionによって書き方が違うからversionとおまじないを連想配列で持ってるよ

てかお前はシェル使ってりゃいいじゃん、誰も否定してないよ
リッチなスクリプト言語もツールも使わなきゃ死ぬってわけじゃないんだ
シェルだけに一生殻にこもっててくれ

172 ：
そうだPowerShellを使おう

173 ：
>>171
> サブネット全体に同じ設定入れたいときに、CIDR表記からipの配列作って応答あるものだけの配列にして設定ばらまいたりする
それなら別に配列使わなくても可変長引数で良いよね？

> osのversionによって書き方が違うからversionとおまじないを連想配列で持ってるよ
それはcaseでやれる

って感じで使わないと思うわけだよ。

難しく考えすぎじゃね？絶対配列じゃなきゃできないって思い込んでるでしょ？


> シェルだけに一生殻にこもっててくれ
俺は適材適所で使う道具を選んでいるだけ
PerlもPythonもRubyも使う。お前は全部Pythonなんだろ？

174 ：
いやだから好きにしろよ…
shellでcaseなんて普段書かねーからぐぐらねーとswitchなのかcaseなのかもわかんねーよめんどくせー
適材適所で使う道具選ぶ作業にもどれ馬鹿

175 ：
こんなやつ職場にいたら最悪だな
なんでシェル使わねーんだよ！！！とか言ってくるんだろ？

176 ：
てかrubyとPython使い分けるってどんな状況だよ…

177 ：
>>174
> shellでcaseなんて普段書かねーからぐぐらねーとswitchなのかcaseなのかもわかんねーよめんどくせー

その一言でよくわかったよ。

俺はどれが適切かという使う道具の話をしてる。
でもあんたの理由は道具じゃなくて「人」じゃん

まず道具を使えるという前提で話しませんか？

178 ：
>>176
大抵はrubyが多いけど、機械学習系はpythonが強いよ。
あとGAEを使うなら起動が速いgoとかね

179 ：
ansibleもまともに使えないやつがなんか言い出しててワラタ

180 ：
プロビジョニングになぜ機械学習が必要なのか…
プロビジョニングが前提だと言ってたおじさんはどこにいったのか

181 ：
>>175
> なんでシェル使わねーんだよ！！！とか言ってくるんだろ？

普段シェルを使ってセットアップしてるわけで
そのやり方を知っているはずなのに、
なぜわざわざansibleに置き換えるんですか？って

何かのバージョンが上がってansibleのプラグインが
対応してねーとか言ってるのを聞くたびに思ってるよｗ

182 ：
ちなみにそのansibleの対応してないプラグインってのは具体的には何なの？
普通ansibleってプラグインじゃなくてモジュールって言うと思うけど

183 ：
>>180
いや、話を聞けよｗ

俺が適材適所で言語を選んでいるってだけの話だ

> シェルだけに一生殻にこもっててくれ
とか言い出したから、俺はこもってないって話をしただけだ。

ちょっと落ち着こうぜ？ｗ

184 ：
Dockerとansibleのちがいがわかってなかったやつはただの無知だけど
こいつはキチガイだな

185 ：
>>182
正確にはモジュールだっけ？
でも公式でプラグインとも書いてあるよ。これとか

http://docs.ansible.com/ansible/latest/win_rabbitmq_plugin_module.html

186 ：
例としてあがってきたのがインストール以上のことをするモジュールでワラタ
そんなんバージョンあがったら改修しなきゃいけないのはシェルスクリプトでも同じじゃん
ばか？

187 ：
>>182
まあ対応してないモジュールも有るだろうけど、
俺が今いったのは新しい設定にモジュールが対応してないって話

具体的に何？と聞かれたらIssuesみろよ。大量に～って思うだけなんだが
https://github.com/ansible/ansible/issues
https://github.com/ansible/ansible/pulls


まあ例えばこんなのとかわかりやすいかな？
tcpってオプションを選択できるようにするんだろうけど
こういうのだよ。普通にCLIでやってりゃできることなのに、
モジュールを更新しないと使えない。
https://github.com/ansible/ansible/pull/31228/files

ずーっと最新バージョンを追いかけていって大変だなぁとしか思えない

188 ：
おーけーわかった
ぼくもうシェルスクリプトしか使わないよ
みんなもおじさんの言うことを聞くんだぞ！

189 ：
>>186
> そんなんバージョンあがったら改修しなきゃいけないのはシェルスクリプトでも同じじゃん

何度も言うけど、シェルスクリプトは自分で普段使っているわけでやり方知ってる。

シェルスクリプトでのやり方知ってるのに、対応するAnsibleの設定はどれだーって調べて
モジュールが対応していなければ、対応されるのを待たないといけない（自分でPR出してもいいけどさ）

俺が無駄だって思ってるのは、バージョンが上がった時の改修作業じゃない。
CLIなら改修する方法は公式見りゃわかるだろうが、
Ansibleを使ってると、公式で調べた上に、対応するAnsibleの書き方を
調べるという追加作業が増えたり、中間層のモジュール周りでトラブルになるのが無駄だって言ってる。

190 ：
仮想環境とまったく関係ない話してるシェル厨が大暴れしててワラタ
もうシェルスレにしろよｗｗｗ

191 ：
>>188
プロビジョニングに関してはそれが良いと思う。
だってみな手動でのプロビジョニングやってるはずで、
シェルスクリプトでのやり方も知ってるわけだからね。

192 ：
>>191
一生やってなさい

193 ：
>>190
シェルスクリプトはDockerfileやVagrantfileでも使用するよ。
特にDockerfileはシェルスクリプトまんまと言っても過言じゃない。
ENTRYPOINTで呼び出すスクリプトも炊いてはシェルスクリプト
まあ軽いイメージにわざわざプログラム言語入れないしね。

194 ：
>>192
はい。反論が有る限り続けますよ。

195 ：
狂気じみてる

196 ：
ansibleのフォーラムで暴れてこいよ、お前ら全員あしたからシェル使え！！！って
なんで2chでクソ底辺の戯言聞かされなきゃいけねーんだ

197 ：
動かしたいホストで動かしたい処理を動かせるならansibleなんてめんどくさいものをわざわざ使わなくていい
ってことはシェルとSSHで十分なんだよな

198 ：
仮想環境と全く関係ない話だけど、
冪等性が必要だったのはマシンを壊さず使い続けるためで
何度もプロビジョニングを行う必要性から冪等性が必要だった

ここで仮想環境の話に戻すと、仮想環境では壊して作り直せば
いいので、冪等性が必要なくなった。

仮想環境だけで仕事が回ってるって会社は少ないだろうから
仮想環境以外のものにAnsibleを使うのはありだろう。

だけど、このスレ仮想環境だからね。
このスレ的にはAnsibleは不要ってことなんだよ。
（このスレと関係ある話をしてみましたよｗ）

199 ：
>>196
嫌なら見るなって何処かの誰かが言っていたよｗ

200 ：
>>197
それな。Ansibleの問題点の１つとして
リモート先にpythonがインストールされて
いなければいけないって問題が有る。

この制約もあるんでDockerfileでansible（python）は
使わないってのもあるんだろう。ベースとなる
ディストリにpythonが入っていないbusyboxを使う場合もあるしさ

例えpythonが使えたとしてもdockerイメージ作るだけの作業で
Dockerfileの中でansibleをインストールなんてのはやりたくないな。

（これも仮想環境コンテナの話ｗ）

201 ：
Vagrantとかいうゴミはどうなったの？
Dockerに駆逐された？

202 ：
>>201
VagrantはDockerとは別のものだよ。

ただしDockerを使えば物理マシンでも比較的楽に
開発環境を作れるからVagrantを持ち出すまでもなくなってる。

でもそれはMacOSの話でWindowsは少なくともBash for Ubuntu for Windowsが
まともに動き出してからだな。と言ってももうベータ外れるらしいが。

だから（MacOS or Windows）+Dockerで開発するのが実用的と
みなせればVagrantはいらなくなる。

Dockerが駆逐するというより、Dockerの力を借りて
物理マシンでの開発に駆逐される。という感じ

203 ：
このスレはシェル厨に支配されました
以下、シェルで出来る事を他の方法でやる人は粛清されます

204 ：
vagrantとvirtual boxの設定
https://surleconomiejp.blogspot.jp/2017/10/vagrantvirtual-box.html

205 ：
>>107
visual stadioコンテナ欲しいです
ごめん、そもそもdockerでwindowsいけます？

206 ：
Docker原理主義者って全部Dockerでやるの？
フロントのNGINXとかデータベースは普通のサーバーのほうが使いやすくねえか？

207 ：
全部Dockerだよ

208 ：
>>206
Docker原理主義だけど全てDockerで
やるわけじゃないよ。

Docker原理主義っていうのは正しい用途に
Dockerを使うのであって、間違った用途に使うわけじゃない

209 ：
>>201
VagrantとDockerはレイヤーが違う

210 ：
vagrant: 仮想ネットワーク構築
ansible: シェルスクリプトの起動
シェルスクリプト: (初回のみ) install docker、docker pull、docker run

211 ：
Vagrantはクライアント環境の再現にしか使ってない
インスタンスに対するdockerとかpipとかのインストール、ソースとかイメージのビルド、実行環境でのdocker pullとrestartはAnsibleを使ってる
DockerはLB、webアプリケーションなどDBを除く、ほぼ全てに対して適用
だけど最近はLBもELBだけでよくね？的な瞬間もあるので、もはやサーブレットとかIronくるむ以外には、あんまり使ってない
ビルド環境をイメージ化しようかと思うこともなきにしもあらずだけどビルドサーバー立てるほうがメンテが楽なので、今はやってない

212 ：
docker buildすればWebアプリケーションのデプロイが楽とはいうけど
そんなことしなくてもデプロイ簡単だよな
dot netだったらフォルダ同期してプロセス起動するだけだしランタイムのインストールも要らない
dockerだと鯖にdockerを入れなきゃいけないけどそれがコマンド一発ではないからめんどくさい

213 ：
>>212
.Netだと事実上WindowsServerじゃないと動かないじゃん…
デフォルトでsshすらあがってないOSは、さすがに手が出しにくいな

214 ：
そしてフォルダにしちゃうとバージョン管理がしにくそう
ロールバックの仕組みが入れづらくないかい？
てか、.NetならAzureとVS組み合わせれば、同期がどうのとか細かいことは気にせず、めちゃ簡単に最新版をデプロイできるんじゃないの？

215 ：
>>213,214
普通にlinux鯖
バージョン管理とデプロイは別の話

216 ：
バージョン管理とデプロイが別なのは同意
失礼しました

それにしても、今は.Netも普通にLinuxて動くんだね
いろいろと幅が広がるな

217 ：
>>212
いや、根本的に発想が違ってる。
「ランタイムライブラリのインストールはいらない」を前提にしているが、
そもそもの問題は、

1. アプリを開発する
2. そのアプリはいろんなライブラリを使用している

という前提において、

理論的にはライブラリのバージョンが異なっていても互換性が完璧なら動くはずだが、
バージョンが異なると動かなくなることがある。
という現実的な問題を解決するために生まれたんだよ。

アプリを完璧に動かしたいのであれば、開発したアプリだけではなく
アプリが使用しているライブラリなど全てを含めた「パッケージ」を
作らなければいけない。

一つの手としてディレクトリに使用するライブラリを全部入れる
なんて方法もあるだろう。Dockerはその発展系と考えればいい。

218 ：
そして都合がいいことにLinuxではカーネルとユーザーランドという区別の仕方が有る。
例えばディストリが違っていても、カーネルは（バージョンの違いはあれど）同じものを使っている。
だからディストリの差というのは（ドライバなどカーネルレベルのモジュールを除いて）
ユーザーランドの違いといえる。カーネルは共通のものが使える。

カーネルは小さい機能に留めておくことで高い互換性を保っている。
そしてLinuxを構成する大部分はユーザーランドレベルのもの。

Dockerの話に戻すと、Docker（コンテナ）の仕組みっていうのは、
アプリが使用しているライブラリをディレクトリにまとめるなんてちゃちなやり方ではなく、
今、ユーザーランドの説明をしたろ？ なんと大胆にカーネル以外の全てを１つのイメージにまとめてるんだよ。

話をまとめると、Dockerというのは開発したアプリをちゃんと動かすために
動かして検証した環境、小さいカーネル以外をすべてパッケージ化したもの。
だからLinuxのカーネル＋Dockerがあれば、Dockerイメージだけをデプロイする。
デプロイ先の環境を意識する必要ががないから、デプロイが楽なんだよ。
このOSでは動作保証していません。このライブラリのバージョンでは動作保証していません。なんてことがない

219 ：
.Netはそういう難しい話はないでしょ
3系使うか4系か4.x系かの違いくらいで、それはまるっとみんなで揃えましょう精神なんじゃねーの？

220 ：
>>213
> デフォルトでsshすらあがってないOSは、さすがに手が出しにくいな

Dockerだとデプロイ先にSSHなんて不要だからね。
カーネルとDockerサーバーだけあれば動く。

もちろんそのOSに.netのとあるバージョンが
インストールされていることなんて制約はない。

.netがインストールされていることと
dockerがインストールされていることは
一緒ではないか！と思うかもしれないがそれは違う。

テストして動作確認したアプリは、.netの場合
そのインストールされている.netライブラリの機能を利用しているが
dockerの場合は、dockerのライブラリを利用しているわけじゃない。

dockerの場合dockerイメージを起動するのに必要ってだけで、
アプリが利用しているのは、イメージに含まれているライブラリと
小さなLinuxカーネルのみでアプリ自体はdockerには依存していない。
アプリが.netに依存しているのとここは大きな違い

221 ：
ID:zkU9oivGはなんでみんなが知ってる事を、だらだら書いてるの？
せめて、お前がどういうシステムをどういう環境でどう運用してるか書けよ

222 ：
>>219
> 3系使うか4系か4.x系かの違いくらいで、それはまるっとみんなで揃えましょう精神なんじゃねーの？

だから同じ4系でも互換性問題は発生するいう考え方だよ。
それを防ぐためにアプリ自体に.netをまるまる含めたようなもの

アプリに.netが含まれていればアプリを配布するだけでいい。
でも、アプリに含まれていなければ、.netのアップデートをしなければいけなくなる。

223 ：
>>221
知らないからdockerの方がデプロイが楽って分かってないんでしょｗ

誰もがあんたみたいに知ってるわけじゃないんだから
知ってる人は黙ってなさい

224 ：
むしろお前のほうが.Net開発の現場を知らなそうだけど
どんなに便利でも、Dockerなんて使ってないよ

225 ：
>>214
> てか、.NetならAzureとVS組み合わせれば、同期がどうのとか細かいことは気にせず、めちゃ簡単に最新版をデプロイできるんじゃないの？

「AzureとVS組み合わせれば」っていうのがダメだね。
それは「簡単」ではない。

Dockerは「Dockerサーバーがあれば」デプロイできる。
その「AzureとVS組み合わせる」のは大変だが、
「Dockerサーバー」はどこでも存在する。

手元のWindowsマシンだろうが、Linuxマシンだろうが、MacOSマシンだろうが、
「Dockerサーバー」は存在する。

だから手元にデプロイしたものをそのままAzureだろうがAWSだろうがGCPだろうが
オレオレクラウドだろうが、めちゃ簡単にデプロイできる。
こういうレベルのものを「めちゃ簡単」と言うんだよ。

この手元にデプロイしたものをっていうのが本当に便利で、
開発してテストしたら、それは実機環境でテストしてるのほぼ同じなんだよ。
違いは小さなカーネル部分だけ（Dockerサーバーのバージョンには依存していない）

226 ：
>>217
だからその厳密にバージョン指定された依存関係まで含めて簡単にビルドできるんだよ
外部依存を全く無くしてポータブルなバイナリを作るのも簡単
ビルダだけで済む話なのにそのためにdockerを使うのは過剰すぎる

227 ：
>>224
> どんなに便利でも、Dockerなんて使ってないよ

すまんな。Dockerが今は便利かどうかの話をしているんだ。
あんたの現場特有の話はしてない。あんたの会社の話を
したって意味ないじゃないｗ

228 ：
>>226
.net以外のものを組み合わせるときは？

全てのライブラリが.netで作られているならば可能かもしれないけど
それは現実的ではない。Cのライブラリが使われることも有る。
RubyやPythonで作られているかもしれない。
すでに存在するnginxやmysqlなどと組み合わせることも有る。

Javaもそうだけど、.NETやJavaの世界で完結していればできるっていうのは
結局.NETやJavaの世界で完結していなければ出来ないって言ってるのと同じなんだよ。
それは現実的ではないよね。

229 ：
>>226
ほんとこれ
NuGetでそこらへんは用が足りてるんだよね

てかVSとAzureより、Dockerのほうが楽とか狂気すぎ
Windows上でDocker動くようにするほうが大変だろ
そんで得られるメリットがプロセスの仮想化です！ってやってられんわ

230 ：
>>228
.Netで完結します
おつかれ

231 ：
このスレ定期的に長文基地外がわくね

232 ：
.net使うにしても、dockerイメージを使えばデプロイは楽になるだろうね。
なぜなら、そのdockerイメージの中に.netランタイムまで入っているから。

Dockerサーバーがあれば（それはきっと手元のマシンに入っているだろう）
どこぞのdockerイメージを、手元の環境を見直すこと無く直ぐに動かすことができる。

Windows 10で最新の.netがインストールされていること
なんて制約はない。

233 ：
>>230
> .Netで完結します
遠吠えｗｗｗｗ

誰が、そんな説明で納得すると思ってんるんだ。
出直してこい

234 ：
ありとあらゆる条件が全く同等という保証がなければDockerだろうがなんだろうが実機テストは必要
それがテストってものだよ
手元の仮想環境と鯖の仮想環境はおんなじだ(だと思う)からテストはしなくていいなんてのは実社会では通用しないぞ

235 ：
Dockerはwindowsだと10以降しか対応してなくね？
開発環境が窓っていう、かわいそうな現場は大半がまだ7だからdockerなんか動かないだろ

236 ：
>>234
あ、はい、時間とコストの問題です。（言わなきゃ分からんかな？）

手元が実機とほぼ同じであれば、実機で見つかるバグは手元でほとんど再現します。
だからより早く少ないコストで修正できるということです。

可能か不可能かのはないをするのは実社会で通用しないぞ？ｗ
重要なのはどれだけコストが小さくできるかだ。

237 ：
>>235
virtualboxで動くよ
さすがはdockerというほかない
どこでも使える

238 ：
>>235
動くよ？
https://qiita.com/0829/items/d303412b15e8f473f3be

ってか、dockerさえ動けば良いのだからどんな方法でも良い。
アプリ自体はdockerには依存してない。

239 ：
>>236
おやおや
君の発言からはまるで実機テストは必要ないと言っているように聞こえたが？
新しい技術を覚えたてで興奮する気持ちはわかるが発言は冷静になってからにしたほうがいいぞ

240 ：
ふむ。さすがマイクロソフト。
当然だが組み合わせて使うことの意味をちゃんと知ってるな。

NET Core アプリケーションの Docker イメージのビルド
https://docs.microsoft.com/ja-jp/dotnet/core/docker/building-net-docker-images

NET Core と Docker を一緒に使用する方法を理解するには、まず、提供されるさまざまな
Docker イメージと、適切な使用のタイミングを把握する必要があります。
ここでは、提供されるバリエーションを確認し、ASP.NET Core Web API をビルドし、
Yeoman Docker ツールを使用してデバッグ可能なコンテナーを作成し、
さらにプロセスにおいて Visual Studio Code がどのように役立つかを簡単に確認します。

241 ：
長文で暴れてるのって同一人物だろ
コテつけてほしい

242 ：
>>239
> 君の発言からはまるで実機テストは必要ないと言っているように聞こえたが？

ならお前の耳が悪いんでね～の？ｗ

聞こえたのは「お前」の耳（目）
言ったのであれば、それは俺の口（手）だがｗ

いえ「実機テストが必要ない」と書いてある文章を
示せるというのであれば、示して良いんですよ？ｗ

243 ：
>>241

ID変えるようなやつだから無理

244 ：
コンテナー - 従来の .NET アプリを Docker で最新化する
https://msdn.microsoft.com/ja-jp/magazine/mt797650.aspx

> このような従来のアプリケーションでは依然として大きなビジネス価値が提供されていますが、
> その保守、アップグレード、拡張、および管理は難しくなっている可能性があります。

やっぱり.NETでは保守、アップグレード、拡張、および管理は難しくなってるんだね。

> 同時に、このようなアプリケーションをすべて作り直すことも、そのために必要な投資に
> 見合わない場合があります。ただし、軽量なコンテナー内でアプリケーションを実行する
> プラットフォームである Docker と、Windows Server 2016 を併用することで、
> 従来のアプリケーションの寿命を伸ばすことが可能です。つまり、機能を追加し、
> セキュリティとパフォーマンスを向上して、継続的配置に移行します。
> それも、時間がかかるうえにコストが高い再構築プロジェクトを実施する必要はありません。

継続的配置（配置＝デプロイ）がDockerは便利だってMSも認めてるね。

245 ：
>>242
自分のレスを冷静に見つめ直してごらん
あたかもテスト不要であるように取れる発言を何度もしてるよ
これから社会に出るのだろうし反省することも覚えたほうがいい

246 ：
>>243
あなたにコテつけてほしいってことなんだけど…

247 ：
>>245
> あたかもテスト不要であるように取れる発言を何度もしてるよ

引用できない時点で、説得力ゼロ
できないなら、なんなら俺が引用してあげようか？

例えば >>225
> 開発してテストしたら、それは実機環境でテストしてるのほぼ同じなんだよ。
> 違いは小さなカーネル部分だけ（Dockerサーバーのバージョンには依存していない）

「ほぼ」同じと書いて有ることから、全く同じではないということがわかる。
そして「違い」について書いてあるから、違いが有ることも明示されている。
よって実機環境でテストが不要ということにはならない。

さて、次はあんたの番だ。

248 ：
>>246
ID見ればわかるし、俺にコテを付けるメリットがない。
というか、２ちゃんねるでコテはつけないというは
俺の中でとっくの昔に決めたルールなので言うだけムダだｗ

249 ：
>>247
15日あたりのレスとかなぁ

250 ：
そこまで調べて引用できないとか、やっぱりなぁとしか思えんな

251 ：
>>122
＞だからローカルで開発で使用していたDockerイメージをそのまま
＞クラウドの仮想化サービス上に持っていくことができる。
＞その作業も単にdocker runするだけ

JavaのWOTAとの対比で語っちゃってるしこれはそうとしか読めんなぁ

252 ：
どうした？
言い訳が思いつかないのか？

253 ：
>>251
持っていくことができるよ？
持っていってテストするんだろ？
何を言ってるんだとしか思えんわｗ

254 ：
>>253
ん～
ちょっと厳しいなその反論は
じゃあなんでJavaと対比したの？ってなるよね

Javaはwrite once, test everywhereのクソだけどそれに比べてDockerは～
っていう文脈でしょ？

255 ：
>>254
ワロタｗｗｗ
お前バカだわ。うん。バカだわ

Javaが主張した言葉、Write once, run everywhere
で、それがが批判されてるのは、実行できると言うが
そこらじゅうでデバッグ（テスト）しなきゃいけないって批判されているほど、
Javaのrun everywhere「どこでも走るレベル」は"低い"って話だ。
低いから、そこらじゅうでデバッグ（テスト）しなきゃいけない

なぜか？ そりゃそうだ。各OSごとで同じものを使うのではなく
各OS毎にライブラリ側で抽象化レイヤを開発してるからだ。
同じものを使っているんじゃない。違うものを使って同じに見せかけてるから
それじゃ互換性レベルは低くなるよねってことだ。

それに比べてDockerは同じものを使う。ライブラリを各OS毎に用意するのではなく
同じものをイメージに同梱する。だからJavaよりもはるかに高いレベルで
DockerはWrite once, run everywhereを実現している。
違いは高い互換性を持つカーネルのみだからな。
Write once, run everywhereなわけだ。


で、お前は、（Javaが主張した言葉）Write once, run everywhere は
全くテストしなくていいって意味で言ってると思うか？

お前がバカだって言った意味がわかったか？

お前は（Dockerが実現している）Write once, run everywhere を
実機で「全く」テストしなくていいという意味だって勘違してるなってわかったからだよ。

256 ：
結局、.NETも同じことになるんだろうな。

Windows実装版とLinux実装版で違いが有るのなら、
全く同じように動くわけじゃない。

同じものを使わなんと同じようには動かんよ。
理論的には動くだろうけど、違う実装なら違いは出る。

全く同じものを使うDockerの利点はそこに有る。

257 ：
>>255
残念だけどそう考えてるのは君だけだよ
君のレスを読んだ人は
あ、こいつDocker使えばテストいらんと思ってるな
と思うわけだ
社会に出たら人からどう見られるかってのも大切だから覚えておいてね

258 ：
まあ別の言い方で簡単に>>254がバカだって証明するならば

> Javaはwrite once, test everywhereのクソだけどそれに比べてDockerは～
> っていう文脈でしょ？

write onceはJavaもDockerも同じなので省略するとして

Javaは、test everywhere（どこでもテスト）
Dockerは、not test everywhere（not どこでもテスト）

「どこでもテスト」の反対は「テストなし」ではない
「全て」の反対は「一部」であって「無」ではない

259 ：
>>257
> 君のレスを読んだ人は
> あ、こいつDocker使えばテストいらんと思ってるな
> と思うわけだ

だからどこにそう書いてある？引用してみて。

すでに俺は「テストいらないと言ってない所」を引用済み

お前が、他人の説明を間違って解釈して喚いていているやつってのは証明した。
社会に出たら人からどう見られるかってのも大切だから覚えておいてね

260 ：
今回は見事論破（笑）できたから

> ちょっと厳しいなその反論は
と言えなかったんだろうなｗ

261 ：
docker使うケースは頻繁なデプロイが前提だったり迅速なスケールアウトが必要だったりの事情があるはずで、
そういう場合に例えば速度面でVMより起動が速い事が一番のメリットだ、という理由があって使うんじゃねーの？
あと消費リソースがVMより少なくて済むとか。

実行環境のパッケージングだけならVagrantでもansibleでも事足りるわけで、
それこそ全部シェルでやれっつーシェル厨もいるだろうけどw
まぁデプロイ楽にする方法なんて他にもあるし、要求や制約に合わせて選ぶもんだ。

メリットが享受できないユースケース出してきてdocker要らないっつーのも馬鹿だし、
他に方法があるのにdockerをお押しつけるのも馬鹿。

テストにしても、ライブラリのバージョン依存のバグを本番環境でのテストまでに見つけられない方が問題なわけで、
ID:zkU9oivGが言いたいのは、そこのバグはもっと早期に潰してる前提でしょ？
テストなんて工程別に目的持ってやるもんなのに、全部ひっくるめて語るのは暴論だわな。

262 ：
>>261
> 実行環境のパッケージングだけならVagrantでもansibleでも事足りるわけで、
だから全く別のものを混ぜないでくれ。分かってないことがバレバレだろ。

ansibleは構成管理ツール。マシンの環境を構築するツール
無理やりDockerに対応づけるならば、Dockerfileを使ったDockerイメージのビルド作業だよ。
（Dockerイメージのビルド作業にAnsibleを使うようなやつはいないが）
ansibleはDockerと違ってイメージを作るものじゃない。
ただのセットアップ手順書だ

Vagrantは、仮想「開発環境」構築ソフトウェア実機で使うことは想定されていない。
無理やりDockerと関連付けるならば、Vagrantで構築された仮想環境には
Dockerサーバーもインストール済みで、すぐにDockerコマンドが使用できる。
みたいな使い方をするんだ。

例えば開発環境の話をしてるとして、 Vagrantで作った仮想マシン VS 物理マシン（Windows、MacOS、Linux） の
どちらであなたは開発してますか？とかこういう使い方をするんだよ。

仮想マシン上でもDockerは使えるし、物理マシン上でもDockerは使える。
物理マシン上で作成したDockerイメージがVagrant上でも動く
クラウドでもDockerサーバーをインストール済みのVMイメージが公式で用意されているから
同じDockerイメージをそのままクラウドでも使うことができる。

Vagrantで作ったイメージが、クラウド上の仮想マシンで動くことなんてまずないからな。
Nested VMは茨の道だよ。それが出来たとしても起動時間、使用メモリ、ネットワークの点から
デメリットしか存在しない

Vagrantが実行環境のイメージ化（＝実行マシン構成が含まれる）とするならば
Dockerはアプリケーションのイメージ化だ。アプリケーションにはマシンの構成が含まれないから
物理・仮想マシン関係なくどこででも動くんだ。ただの１つのアプリケーションだもの

263 ：
イメージのビルドにAnsible使ってるよー

264 ：
そういやAnsible Containerってのができたんだっけｗ

なんかメリットあんの？
コンテナイメージの作成がDockerfileじゃできないほど
複雑なものでも作るの？

シェルスクリプトが使えない人の救済用以外の
メリットがあるなら教えてください。

265 ：
いや普通にDockerfileのビルドに使ってるでよ
docker_imageってモジュール

266 ：
てかシェルスクリプト使えない人ってどゆこと？
窓ユーザーってこと？質問の意味がよくわからん…

267 ：
>>265
お、おう。
それはdocker buildコマンドを叩く代わりに
ansibleを使っているってだけの話だな。
dockerコンテナへのデプロイではなく

どころで普段、端末からdocker使えるか？
docker build -t tag . とか
docker run -it debian /bin/bash
みたいなのそらで打てるか？

ansible使わないとコマンド打てないっていうんじゃ恥ずかしいぞ

268 ：
>>266
世の中には、ansible経由で設定ファイルを書いて
コマンドを実行している人がいるかもしれない。

dockerに新しいオプションが増えてもすぐに使えずに
http://docs.ansible.com/ansible/latest/docker_image_module.html
このモジュールが対応していることしかできないって人もいるかもしれない

269 ：
buildもpushもpullもrunも全部ansibleでやるときあるよ

dockerの基本的なコマンドそらでうてないやつなんているの？
ローカルでやるときはいちいちansibleなんてつかわんのに

質問の趣旨は？？

270 ：
>>268
え、設定ファイルってDockerfileをってこと？？
それをlineinfileとか使って動的生成する人ってことかな
そんな人いないと思うけど…

271 ：
>>269
そらでうてるものに対して対応するansibleの設定探すの面倒じゃないかなーって思って
それに例えばマイナー（？）なオプションbuild時にラベルつけたくなったらどうするの？とかさ
モジュール対応してないでしょ？

272 ：
ローカルでやるときはいちいちansibleは使わない

そうだよね。

まず最初にansibleを使わないで作業する
コマンドを叩く、やりたいことを実現する。


それをansible言語に翻訳する作業ってすごく無駄な作業だと思う。
しかもローカルでやれることの一部しかできないし。

273 ：
>>271
まぁ面倒っちゃ面倒かもな
俺はもうスニペット用意してるからそこまで手間でもないけど
--labelは使ったことないから、知らんけど、まぁどうしてもそうなったら仕方ないからcommnd module使うんじゃね？

274 ：
もちろんansibleにもメリットは有るよ。
今となってはさほど意味がなくなったが冪等性や
複数台のマシンに対して同じ/異なる 設定を送り込むとか

でもさ、コマンド実行部分をYAMLで書けるようにする
そのためのラッパー（モジュール）が大量に必要。
これは失敗だったね。

275 ：
でも他もそうじゃないか？
ChefとかPuppetはそういうのないの？？

276 ：
てかその設定への翻訳を無駄な作業って、じゃあ毎回コマンド打つのか？？

277 ：
>>273
やっとansible使ったことがありそうな人が来たｗ

手間なんだよ。モジュールが用意されてないこともあるし、
あったとしても、膨大な設定をオプションを
ansible語へ翻訳しないといけない。

あとリモート側にpythonが必要というのも、設計ミスだろうね。
サーバーにはそれぐらい入れとけよと言いたいのかもしれないけど、
軽くするために必要ないものは入れないという文化も有るしね

さらにdockerはsshすら入ってない。（そもそもそういう使い方をするものじゃない）
でもshは入っている。だからDockerfileはシェルコマンドの頭にRUN付けただけ
みたいな、ほぼシェルスクリプトのやり方でイメージを作成する

278 ：
>>276

> てかその設定への翻訳を無駄な作業って、じゃあ毎回コマンド打つのか？？

テキストファイルに、普段あなたが実行しているコマンドを
そのまま羅列していけば、それがそのまま使えるんですよ？

翻訳作業がいらないだけでなく、ansibleで書くよりも短く書けます。
実行するときもスクリプトファイル名を入力するだけです。

279 ：
dockerにssh？？
dockerのイメージをデプロイする先のsshのことを言ったんだが
てか、何を聞きたいのかあまりよくわからないんだけど質問は何？？

280 ：
>>279
sshの話なんて質問してないけど？
何勘違いしてるのさｗｗｗ

質問は
> どころで普段、端末からdocker使えるか？
> docker build -t tag . とか
> docker run -it debian /bin/bash
> みたいなのそらで打てるか？

これだけだろ

意図は>>271に書いたとおりだ

ansibleを使っている人ならわかる。ansible用に翻訳作業が必要で
モジュールが存在しない場合もあるし、オプションに対応してない場合もある。
そこまで苦労してansibleを使うものではない

281 ：
>>278
ああ、シェルスクリプトを保存すれば、ansibleなんて最初からいらんかったんや！ってこと？
シェルスクリプト書くの面倒くさいからansible使うんじゃないの？
なんとなく目先のコスト的には、コマンド直打ち<<<ansibleのplaybook<<<<<シェルスクリプトって感じだが
ワンライナー魔術師とかシェル芸が得意な人はシェルスクリプトのほうがいいんじゃないか？

282 ：
>>280
ごめん
>>264が質問と思ってた
シェルスクリプトの救済がどうのこうのということの意味がわからなくて混乱しただけ

回答は>>281ね

283 ：
思うんだけどansibleって構成管理ツールとかいう名前じゃなくて
リモートコマンドランチャーって呼んだ方が正確なんじゃないだろうか？

リモートマシンでコマンドを実行できます。
コマンドがよくわからない人のために、YAML形式で
コマンドの実行オプションを指定できます。

ほら、正確じゃない？

284 ：
ちなみにansibleはやたらモジュールあるけど、
俺が使うのは、さっきあげたdocker_imageとか、他はapt、pip、npmとかくらいだから、
モジュールが対応してないようなことをしない

285 ：
>>281
> シェルスクリプト書くの面倒くさいからansible使うんじゃないの？

それが理解できない。

シェルスクリプト = 普段実行してるコマンドの羅列
なわけで、誰しもシェルスクリプトに書く内容を
すでにシェル上で実行してるはず。
それをコピペするだけだよ。

286 ：
>>283
リモートコマンドランチャーで、いいんじゃない？
コマンドがわからんけど、playbookは書けますみたいな人はいないと思うが

287 ：
>>284
> 俺が使うのは、さっきあげたdocker_imageとか、他はapt、pip、npmとかくらいだから、
> モジュールが対応してないようなことをしない

それならばなおのことシェルスクリプトで良いと思うけど
ワンライナー魔術師とかシェル芸なんて使う必要ないし。

シェルスクリプト？
「普段あなたが書いていることを書くだけです」

288 ：
>>285
それはちがくね？
ローカルでdockerとかだったら、コンテナが起動済みかどうかしらべてとかするでしょ
それをawkとif文とかを使って書くよりは、state: presentのほうが楽だろ

あと、レビュアーがシェルスクリプトわからんときには、YAMLのほうが読んでもらいやすいかも
どっちでも一緒かもだけど

289 ：
>>286
リモートコマンドランチャーはシェルスクリプトも実行できるから
メインの処理はシェルスクリプトで書くといいだろうね。

そうするとDockerfileでも使えるし、Vagrantでも使える
クラウド上にVMインスタンスを立てるときも
スタートアップスクリプトを設定できて
シェルスクリプトが実行できる。

シェルスクリプトだと応用範囲が広い

290 ：
>>287
まぁシェルスクリプトでかけと言われれば書けるよ
それこそ逆翻訳だから面倒ってだけ

それを踏まえて最初の質問に対する答えだが、どっちにもメリットもデメリットもないよ
できることは同じだから好きな方で書けば良い

291 ：
>>289
いやメインの処理だけスクリプト化ってのはわけわからんから、なるたけどっちかに寄せたほうがいいよ
君の開発環境がわからないのでなんともいえないが、ansibleのモジュールが対応してない複雑なことをすることが多いなら
技術選択としてansibleを選ばないほうがいい

ansibleだとできることが増えるとかじゃないから、気にしないほうがいいんじゃね？
世の中に流される必要もあるまい

292 ：
>>288
> ローカルでdockerとかだったら、コンテナが起動済みかどうかしらべてとかするでしょ
> それをawkとif文とかを使って書くよりは、state: presentのほうが楽だろ

いや別に？ それってstate: presentを誰かが作ってくださってるから
簡単にできますってだけだろ？そこで対応してないのはお手上げだろ。
そういう用意されてるものを使う、自分では作れないっていう精神がだめなんだよ。

awkなんかいらん。docker ps や docker inspect 使えばできるだろ。
そんなコマンド使えませんとか言うのなら話は別だがｗ

よく使うのであれば、自分で新たなコマンドを作れる。
コンテナが起動済みか調べて起動するコマンドだって作れる
普段使ってる言葉で簡単にね。

293 ：
>>291
> いやメインの処理だけスクリプト化ってのはわけわからんから、なるたけどっちかに寄せたほうがいいよ

だからansibleはいらんなーって話

294 ：
お前人にモノ聞く態度と違うぞ
いらんなら使わなきゃいいだけだろ
物議を醸したいのなら質問の体を取るな紛らわしい
夜中に一生懸命説明して損したわ

295 ：
>>291
> ansibleだとできることが増えるとかじゃないから、気にしないほうがいいんじゃね？

逆にできることが減るしねｗ


1. CLIコマンド（普段使用してる）
↑
2. ansibleモジュール（YAMLからCLIコマンドへの変換レイヤー）
↑
3. YAMLファイル（新たに覚える必要があるもの）


3.で無駄な努力をして、2.の機能不足やバグでトラブルにあって、
やっと普段使用してる1.にたどり着く。ムダ以外の何物でもない

296 ：
>>294
> お前人にモノ聞く態度と違うぞ

そりゃ教える方だからね
教授が学生に質問しているのは
わからないから聞いてるんじゃないですよ？ｗ

297 ：
結構スレの前半からいる変わった人なのか
何を教えてるつもりやねん…怖すぎ
2ちゃんで久々に書き込んでつかれた…

298 ：
2ちゃんねるな。
間違えんな

299 ：
Dockerはコンフィグの体じゃなくて
スクリプト化して、プロビジョン機能をもたせるべき
言語はGoがいい。
そしてジョブ管理機能をサポートして、Jenkinsとの親和性
を良くするべき。
つまり、コンテナだけじゃなくてプロビジョン、CI, ジョブ制御
全部Docker基盤でサポートできるようなれば超便利。
JenkinsはそのUI窓口を担当する。

300 ：
>>292
用意されていればそれを使えば簡単、無ければ自分でshellコマンドを書く、でいいんじゃないの？
「そこでshell使うなら最初から全部shellで書けばいいじゃん」てのは極端だと思うが。

301 ：
オープンソースのパッケージはリスクがある(npm left-pad)

302 ：
AnsibleはWindowsにインストールできない
Linux仮想環境にAnsibleを乗せて実行など
やりたいことに対して迂遠すぎる

303 ：
windowsなんてだいぶ前に使うのやめたけど、そもそもpythonまともに使えるようになったのけ？
pyenvすら使えないと聞いて震えた記憶があるが

304 ：
>>300
> 用意されていればそれを使えば簡単、
別に簡単になってないので意味が無いんだよなｗ

305 ：
>>303
> pyenvすら使えないと聞いて震えた記憶があるが

pyenvはPythonで作られていない。
シェルスクリプトで作られたシェル環境を操作するツールだ。

306 ：
なんていうかね茶碗で飯食うのに箸を使うべきなんだけどブルドーザーで食おうとしてる
Ansibleってそんな感じ

307 ：
>>304
言うことがころころ変わると会話にならんなぁ。

>いや別に？ それってstate: presentを誰かが作ってくださってるから
>簡単にできますってだけだろ？そこで対応してないのはお手上げだろ。
>そういう用意されてるものを使う、自分では作れないっていう精神がだめなんだよ。

とりあえず、 ID:sDdgCD4Q はansibleよりshell scriptの方が簡単だと思っているからansibleを使わないわけだな。
で、ansibleを使う人はansibleの方が簡単だと考えているからそれを使うんだと思うよ。
それを「いや違う」と言ってみたところで、その人にとってshell scriptの方が簡単になるわけでもあるまい。

308 ：
>>307
文章を途中だけぶち切って
俺の言いたいことを改変するなって

俺が簡単になってないというのは
シェルスクリプトをYAMLに翻訳しても簡単にはならないという話だ。

誰かが作った「機能」はそりゃ簡単になるだろ。
state: present相当の機能をシェルスクリプトで書けばいい。

それをYAMLに翻訳しても簡単にならないって話だ。

309 ：
>>307
> とりあえず、 ID:sDdgCD4Q はansibleよりshell scriptの方が簡単だと思っているからansibleを使わないわけだな。

違う。シェルスクリプト語をYAML語に翻訳する作業が"無駄"だと言ってるんだよ。
誰しもシェルでコマンドうってやってる作業なんだから、
それを羅列してシェルスクリプトにしたほうが楽

わざわざYAML語に翻訳して、その結果、モジュールが対応してない機能が
使えなくなってモジュールのバージョンアップやバグに翻弄され、
最終的に対応してない機能はcommand moduleを使って
シェルで打ってるコマンドを書くことになる。

無駄な作業以外のなにものでもないよ

310 ：
shellの方が簡単っていうけどインベントリの管理とか出力の整形とかめんどくさいこと結構あるだろ
その辺shellでどうやって解決してんのかね

311 ：
>>310
ここに書いてあるとおり

274 名前：デフォルトの名無しさん[sage] 投稿日：2017/10/22(日) 01:30:08.38 ID:sDdgCD4Q [5/21]
もちろんansibleにもメリットは有るよ。
今となってはさほど意味がなくなったが冪等性や
複数台のマシンに対して同じ/異なる 設定を送り込むとか

でもさ、コマンド実行部分をYAMLで書けるようにする
そのためのラッパー（モジュール）が大量に必要。
これは失敗だったね。

312 ：
>>311
うんだからshellでやるときはどうやってるの？

313 ：
>>312

>>306が書いてくれてる
> なんていうかね茶碗で飯食うのに箸を使うべきなんだけどブルドーザーで食おうとしてる
ブルドーザーはいりません

314 ：
>>313
そうだね
shellでやるときはどうやってるの？
なんで答えてくれないのかな？
できないの？

315 ：
>>314
なんで使わない機能を実装しないといけないの？

まあインベントリなんてホスト名をfor文でぐるぐる回すだけのことだけどｗ
知ってるかい？sshは後ろに実行するコマンドを書けるんだぜ？ｗ

316 ：
>>315
forループぐるぐるって…
その程度の認識なら話にならんな

317 ：
>>316
反論が有るなら、何がダメか言えよｗ

318 ：
インベントリとfor文ぐるぐるは全然違うだろ

319 ：
>>318
その程度の認識なら話にならんなｗｗｗ

320 ：
お前の言った言葉が何の反論にもなってないのがわかったか？

違うなら何が違うのか言えと何度言わせる気だ？

321 ：
幼稚

322 ：
なんで答えてくれないのかな？
できないの？

323 ：
違いすぎて何を書けばいいのか
インベントリはデータベースに近い構造で、配列とは全然違う
あえてかんたんに言うなら配列の要素に複数の属性をもたせたものだから、表現力が全く違う

324 ：
>>323
ファイル形式の話かよｗ 話しにならんな。
本当にやりたいことを書けよ
お前はそのファイル形式じゃなきゃ絶対ダメなのか？

325 ：
当たり前だが、
ホスト名の一覧にオプションをつけることなんざ
シェルスクリプトでも簡単にできる。

hostname1 -a 1 -b 2 -c 3
hostname2 -a 11 -b 22 -c 33

というファイル形式でもそれ以外でもどうにでもなる。

326 ：
グループ分けもしたい
パラメータは外部ファイルで整理したい
スイッチは読みにくい
ホストが増えてきたら動的にホスト情報をスクリプトで取得したい
静的な情報からスクリプトへの移行も手間無しでスムーズに行いたい
セキュリティ情報を扱うので暗号化もサポートしたい
テンプレートエンジンも欲しい
…

あげてくとキリがないな
シェルだけでやってるならたいしたものだよ
実際には要求が簡素なだけなんだろうけど

327 ：
> グループ分けもしたい
ファイル、ディレクトリごとに分ければいい

> パラメータは外部ファイルで整理したい
外部ファイルから読み込めばいいだけ

> スイッチは読みにくい
読みやすい形式に変更すれば良い

> ホストが増えてきたら動的にホスト情報をスクリプトで取得したい
標準入出力で別スクリプトの出力結果を使用すればいいだけ

> 静的な情報からスクリプトへの移行も手間無しでスムーズに行いたい
script.sh hostname1 hostname2 hostname3
↓
script.sh $(dynamic.sh)

> セキュリティ情報を扱うので暗号化もサポートしたい
openssl コマンドと openssh のid_rsa で暗号化と復号化
http://takuya-1st.hatenablog.jp/entry/2015/08/12/002349

> テンプレートエンジンも欲しい
envsubstを使ってShellでテンプレートエンジン的なことをする、
http://blue1st-tech.hateblo.jp/entry/2016/07/25/001123

Bashでテンプレートエンジン{{Mustache}}を使ってみる
https://qiita.com/laqiiz/items/baa87183838351e4778c

他ERBでもなんでも好きなのを使え

328 ：
そこまでいくと逆にシェルにこだわりすぎて、生産性落ちてるだろｗｗｗ

329 ：
別に？ それぞれ1行～数行で書ける程度

330 ：
しかもテンプレートエンジン使うのに他ツール使っちゃだめでしょ？
できることの幅が狭まるし、そのツールの学習コストがあるんだからｗｗｗ
ぜんぶ自分で書いたシェルでやりなさい！ｗｗｗ

331 ：
> しかもテンプレートエンジン使うのに他ツール使っちゃだめでしょ？
シェルスクリプトにこだわるなら普通に
ヒアドキュメントの文字列展開を使えばいいと思うけど？

普段使ってるテンプレートエンジンを使えば良いんやで？
普段やってることをAnsible語に置き換えるのが無駄だって話なんだから

332 ：
ってやるとめんどくさいじゃん

ファイル管理ディレクトリ管理を作らなきゃならない
外部ファイル読みこみも書かなきゃいけない
読みやすい形式を考えて書き換えなきゃいけない
標準出力をパースしなきゃいけない
$(...)にいちいち置き換えなきゃいけない
opensshに明に依存しなきゃいけない(シェルだけでやるんじゃなかったの？)
神社以外の新しいテンプレートエンジンに依存しなきゃならない(シェルだけでやるんじゃなかったの？)

シェルだけでできるって話だったのに
いきなり依存するものが出てきて困惑
シェルだけでできてないじゃん
そんなの覚えるのめんどくさいよね
Ansibleを覚えるのと何が違うんだ？

333 ：
> しかもテンプレートエンジン使うのに他ツール使っちゃだめでしょ？
あとこれは考え方が間違ってる。

シェルスクリプトを使うということは、普段使ってるコマンドを使うということ
他のツールというか普段使ってるツールを使うってことだよ。
シェルスクリプトという言語は外部コマンド呼び出しとその連携に特化した言語なんだか
外部コマンドを使わないのは本末転倒

Ansibleという専用で応用範囲が狭いツールに置き換えるのをやめましょうという話

334 ：
テンプレートエンジンはansibleが解決してくれるから、独自のツール導入したらもはやそれは普段打ってるコマンドでもなんでもないんですがそれは…

335 ：
>>332
> ファイル管理ディレクトリ管理を作らなきゃならない
ディレクトリ作るコマンドはmkdir、ファイル作るコマンドは
適当なテキストエディタでも使えば終わりでしょｗ
普段やってないの？

> 外部ファイル読みこみも書かなきゃいけない
. ./file
一行ｗ

> 読みやすい形式を考えて書き換えなきゃいけない
普通にオプションでいいし、環境変数設定のやり方（AAA=123）で十分だろ
ちょっとしたことにブルドーザーを用意しようとするかなｗ

> 標準出力をパースしなきゃいけない
え？ Linux（Unix）っていうのはリダイレクトなどの機能で
ファイルも標準入出力も同じように扱えるんだよ

> $(...)にいちいち置き換えなきゃいけない
3文字のタイピングに何時間かかるのさｗ

> opensshに明に依存しなきゃいけない(シェルだけでやるんじゃなかったの？)
違いますね。普段シェルでやってることをそのまま使うってことですよ？
言いましたよね。Ansible語に置き換えるのが無駄だと。（何回目だろｗ）

> 神社以外の新しいテンプレートエンジンに依存しなきゃならない(シェルだけでやるんじゃなかったの？)
普段使ってるテンプレートエンジンをどれでも自由に簡単に使える。
Ansible語に置き換えるのが無駄

336 ：
結局ちょっと難しいことしようとするとシェルじゃ太刀打ちできないってことか
シェルで全部やるというかシェルでお気に入りのツールを組み合わせるってだけなのね
んでそれを学習コストなしとみなすいわば屁理屈
少し期待してたけどガッカリ

337 ：
>>332
> シェルだけでできるって話だったのに

普段シェルで叩いてるコマンドをそのまま使えるって話だって
何度も言ってる。

な？ シェルはCLIコマンドなんでも使えるんやで？
Ansibleはモジュールで提供されている機能だけや。

YAMLに置き換えて、普段やってることができなくなるんだよ。
無駄以外のなにものでもない

338 ：
>>336
> んでそれを学習コストなしとみなすいわば屁理屈

そりゃそうだろｗ

シェルは普通誰でも使ってるだろ。
プロビジョン相当のことを、手動（シェルから）でやらないのか？

普段やってることを、単純にYAMLに置き換えるだけだから
無駄な学習コストだよ。それでいてシェルからやってることに比べ
できることが減るんだからな。減るだけじゃない
モジュールの対応してる機能やバグでトラブルが増えてるだけ

何度もその姿見てるわ。無駄なことやってんなーって思ってる。

339 ：
>>337
ansibleはcommndもshellモジュールもあるから、シェルの完全な上位セットだよ
ansibleでできることがシェルでできないことはあるけど逆はない

340 ：
>>339
> ansibleはcommndもshellモジュールもあるから、シェルの完全な上位セットだよ

で、その結論はどうせshellモジュール使うんだから
シェル使えばいい。

341 ：
>>339
> ansibleでできることがシェルでできないことはあるけど逆はない

できるできないじゃなくて、YAMLに置き換えるのが
無駄だって話だからね。何度も言うよ？ｗ

ansibleでできるならそれ相当の機能を作るか持ってくればいいので
シェルでできないことは何もないよ。

それにansibleで "できないこと" はshellモジュール使うんでしょ？ｗ

342 ：
>>338
お前はお前で、ansibleでできることをつらつらshellで書いてることを無駄だと思われてるよｗｗｗ
mkdirひとつとっても、そのディレクトリの存在確認いちいちするのなんて手でコマンド打つときはlsで目で確認だけど、
スクリプト化したらifディレクティブ書かなきゃいけない
普段やってることをシェルスクリプトに翻訳する作業のコストは完全無視なのが笑える
そのままスクリプトにすりゃ動くだろって動かねーっつのｗｗｗ
むしろシェルスクリプトの勉強からやり直しなさい

343 ：
> mkdirひとつとっても、そのディレクトリの存在確認いちいちするのなんて手でコマンド打つときはlsで目で確認だけど、

え？

mkdir -p /foo/bar/baz って書けばいいだけじゃん。
なんでいちいち存在確認なんかしてんのｗｗｗ

344 ：
そのディレクトリがもう存在してたら？
エラー吐くけど無視するってこと？
どんだけー

345 ：
$ mkdir -p /tmp/foo
$ mkdir -p /tmp/foo
$ mkdir -p /tmp/foo
$ mkdir -p /tmp/foo
$ mkdir -p /tmp/foo

何度やってもエラーなんて出ませんねぇｗ 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)

346 ：
ぴゃー！今まで確認してたー！必要なかったんか

347 ：
さすがshell王子やで
これからもシェルで頑張ってくれ！

348 ：
結局シェルスクリプトを過小評価して、簡単にできることをできないと思いこんで
より面倒なAnsibleに置き換えてただけか

349 ：
その思い込みが今この瞬間に消え去ることはないので、これからもansibleで書きます
本当にありがとうございました

350 ：
Ansibleに学習時間が取られるだけじゃなく
シェルの学習時間が減るのも問題だよな。

シェルは応用範囲が広いから（逆の言い方をすると）
デプロイだけじゃなく普段の作業でも使える。

つまりシェルに慣れておくと普段の作業も効率化できるわけだ

351 ：
シェルでツールを組み合わせる
作る方からすると簡単だし柔軟性が高いのは事実だけどとにかくメンテナンスしにくい

シェルスクリプト自体がルーズすぎてメンテナンスしにくいってのもあるけど
それ以上に様々なツールを組み合わせること自体がメンテナンス性の悪化を爆発的に加速させる

普段から使ってるツールセットが関係者全員で同じになるってことはまずない
誰かが普段使ってるツールを使って書いたオレオレスクリプトは他の人からすると学習コストが非常に高い厄介な代物でしかない
それぞれが好き勝手に好きなツールを使うことを許してしまうと人数が増えた時に総学習コストは際限なく増えていく
Web系のルーズな人たちはこの辺に無頓着だよね

そうならないために普通の開発現場では使えるツールを限定する
限定するならアレコレ使うよりAnsibleのような目的に沿った全部入りが良い
その方が最終的に学習コストは低くなる

352 ：
>>351
> 作る方からすると簡単だし柔軟性が高いのは事実だけどとにかくメンテナンスしにくい

ようやく話が戻ってきたかｗ

そのメンテナンス作業でやることがDockerを使うことで殆どなくなってきたんだよ。

デプロイで大変なのは実は構成管理ではなくて、アプリのデプロイ
アプリを動かすための環境づくり（言語やライブラリのインストールなど）が大変だった。

でもそれがDockerを使ってDockerイメージに全部入れ込むことで、
あとはDockerコンテナの機動スをする1行（ないし数行）で完結するようになった。

デプロイでやることが大幅に減ったから、もうシェルスクリプトで十分な時代になってるんだよ。

353 ：
その1行ってのを試しに書いてみて

354 ：
Dockerコンテナを起動する命令？
docker run --restart=always -d myapp
とかそんな感じ

355 ：
>>352
残念だけど、そんな時代はまだ来てない
Dockerを禁止にしてり現場なんていくらでもある
Dockerを使うって発想すらない現場もまだまだ多い
自分のデスクトップが世界標準と考えてしまう視野の狭い若者は少なくないけど
君もそのひとりということだね
今の君のデスクトップが多くの現場で当たり前になる頃には、さらに進んだ技術が君のデスクトップに導入されているんだろう
そりゃ簡単だよな

356 ：
シェルスクリプトで十分ということは否定しないが、

まだ時代が来ていないという話にすり替わったｗ

357 ：
次は仮想環境の時代は来てないとか
クラウドの時代は来てないとか言うのかな？

単に遅れているだけだと思うけどｗｗ

358 ：
>>356
すり替え？？？
時代が来たって言ったのは君だよ
それ否定しただけ

359 ：
本当にあきれるほどに視野狭窄だね
よほど恵まれた環境で飼われているのか
あるいは、もしかして、IT業界の人間じゃない？

360 ：
>>358
いまDockerの時代が来ているかどうかって
話はしてないのでね

Ansibleはいらない。シェルスクリプトで十分って話。

お前が言ったのは
Ansibleはいらない。シェルスクリプトで十分だけど
俺の会社にはDocker導入されとらんのじゃー！
ってこと

それは技術じゃなくてお前の会社の問題

361 ：
docker使うだけで恵まれた環境のなのかｗ
まさか嫉妬されるとは思わなかった。

362 ：
ついこの間読んだ記事

Rocro株式会社の導入事例：GAE + GKE をフル活用し、高品質な開発者向け SaaS サービスをソニーグループである Rocro株式会社が少数精鋭で開発・運用
https://cloudplatform-jp.googleblog.com/2017/10/GoogleCloudPlatform-Rocro-GAE-GKE-SaaS.html

GKEっていうのはdockerを使うのが前提となってるんだけど
こういうのどうするのさ？

363 ：
>>360
君の言う「シェルで十分」はdockerに依存してるんだろ？
まだまだdockerは普及してないのだから君の言う「シェルで十分」の時代も来てないってこと
使われてる現場もあるってだけで時代が来たっていうなら何も言わんが、時代が来たってそういうニュアンスじゃないと思うぞ

>>361
そう
君の知らない世界が無限に広がってる

>>362
その事例も同じ
使われてる現場もあるってだけ
これからじわじわ増えて来て当たり前のように使われる時代くるんだろう
でもそれは未だ来ていない

364 ：
>>363
> 君の言う「シェルで十分」はdockerに依存してるんだろ？
依存はしてない。dockerを使わないシステムは有る
例えばAmazon RDSやGoogle Cloud SQLというデータベースサーバーとか
こういうのはすでにシステムが用意されてるのでそれを使うだけ

なのですでにAnsibleでデータベースサーバーを作るなんてのはやっていない
シェルどころか何も使わない

> 君の知らない世界が無限に広がってる
COBOLみたいなお仕事でしょ。
知ってるｗ

> でもそれは未だ来ていない
うちの会社ではすでに自社サーバーがほぼゼロ状態で
サーバーはクラウド化されてるのですでに来ている。

君の知らない世界に俺はいるようだ（笑）

365 ：
これからじわじわ増えて来て当たり前のように使われる時代くるんだろう
そのときに備えてシェルスクリプトは使えるようになるべきだし、
Ansibleは次第に廃止されていく。
それは未来に生きてる俺が証明している

366 ：
てかansibleの到来でシェルスクリプトが駆逐され、クラウドのAPI充実によってansibleが駆逐されていく感じだろ
俺からすればどっちも糞の山だわ

367 ：
それはないんだわ。なぜならansibleはPythonがリモートに
インストールされていないといけないから。

通常コンテナには必要最小限のものしか入れないので
Python用コンテナでない限りPythonは入っていない。
必然的にシェルスクリプトしか使えない。

またdockerイメージの特徴はローカルでも動かせるという所だから
クラウドのAPIなんてのは意味がない。

368 ：
>>367
うちはサーバーは全部ubuntuだからそこらへんはクリアしてんのかな？
てかpython入ってないサーバーなんて今時あんの？

てかDockerだのシェルだのansibleだのインフラ屋も大変だね
うちは、ビジネスサイドと開発選択して、ユニットテスト書いてコード書いて、pushすればステージ環境に勝手にデプロイされて、
POがステージ環境さわってマージされたら本番に勝手にデプロイされてって感じ
こっちからしたら、それができれば何使ってくれても構わんわ

インフラ屋って地味なイメージあるけど、やっぱ宗教論争があるんだな笑

369 ：
あとAnsibleを死滅させる原因の１つにKubernetesがある。
Kubernetesが事実上の標準の座を手に入れるまでは
Ansibleを使ってオーケストレーションを行おうという動きがあった。

Kubernetesを使うことで簡単にDockerコンテナを実行できるわけだけど、
その方法としてコマンドラインのkubectlとREST APIがある。

Ansibleはまたコマンドランチャーとしての立場として
せっせとラッパーモジュールの開発を行っている

370 ：
>>368
> てかpython入ってないサーバーなんて今時あんの？

busybox、alpine、CoreOS、Container-Optimized OS

371 ：
>>368
> てかDockerだのシェルだのansibleだのインフラ屋も大変だね

勘違いしている人も多いが、Dockerはインフラ屋の道具じゃない。
アプリ開発側が、アプリのイメージ（＝Dockerイメージ）を作って
インフラ屋に「これ起動して」って渡すもの

インフラ屋にいちいち動作するサーバー構成とか
必要な言語、バージョン、ミドルウェア等伝えるの面倒でしょ？

372 ：
sDdgCD4Q
シェルスクリプトは普通に面倒だよ
まず「コマンドベース」なのが可読性が汚くなる。
クォーテーション、オプション、セミコロン、各種コマンド展開
パイプ、リダイレクト記号
さらに「オプション」っていうのはテストコマンド中のオプション
とか普通のコマンドのオプションとか1文字だけで意味を理解するには
「シェルの仕様を暗記」していることが前提になる。
もちろん「シェルを散々やっている人」からすればそんなの身について
当たり前、って思うかもしれないけど、Ruby, Python, YAMLなんかに
比べれば「意味の通りやすさ」が段違い。
自分では当たり前のように書いてるシェルのコードが別の人から見たら
「わけわかんない秘伝のタレ」にしか見えないかもしれない、って
考えたことある?
DockerとかAnsibleみたいなツールは何も「既存で熟練した技術者」
のためにあるわけじゃないんだよ。
難解なコードは技術者が自分の立場を守るための参入障壁でしかない。
古参技術者のATフィールドみたいなもんだよ、そんなものはOSSによって
容易に破られる時代ってこと。

373 ：
あとあれだ、Docker要らない、シェルで十分って言ってる
やつは「コンテナ化」について全く言及してないだろ。
シェルで制御できるのはせいぜい「プロセス」「ジョブ」単位。
Dockerで制御できる「コンテナ」は「沢山のプロセス」をカプセル化
した「マシン」と「プロセス」の粒度の中間にある「サーバ(=コンテナ)」
という粒度が必要になってきたからDockerができたんだよ。
あとGitリポジトリと同じで「過去の状態に復帰できる」
コンテナの設定を「1ファイルとして外部に外出しできる」のも
シェルの守備範囲外。
シェルはどうやっても依存関係が生じてなかなか「1ファイル」とはいかない
だろ?

374 ：
> まず「コマンドベース」なのが可読性が汚くなる。
理由は？

> クォーテーション、オプション、セミコロン、各種コマンド展開
> パイプ、リダイレクト記号
何が問題なのか分からん。やりたいことが実現できれば十分だろ

> さらに「オプション」っていうのはテストコマンド中のオプション
> とか普通のコマンドのオプションとか1文字だけで意味を理解するには
> 「シェルの仕様を暗記」していることが前提になる。
シェルの仕様じゃなくて、普段自分で打ってるコマンドのオプションな。
あまり使わないものは俺はlong optionで書くようにしてるよ？一文字にこだわる必要はない。

> もちろん「シェルを散々やっている人」からすればそんなの身について
> 当たり前、って思うかもしれないけど、Ruby, Python, YAMLなんかに
> 比べれば「意味の通りやすさ」が段違い。
YAMLは形式、そこで使うオプションは結局覚えなきゃいけない。その分手間がかかる。

ってか本気のプログラミングをしないんだから、SQLでプログラムするのは
大変って言ってるようなもんだよ。シェルスクリプトは汎用言語じゃなくて
DSLに近いものなんだから、限られた用途で最高のパフォーマンスを出せばそれで十分

> 自分では当たり前のように書いてるシェルのコードが別の人から見たら
> 「わけわかんない秘伝のタレ」にしか見えないかもしれない、って
> 考えたことある?
それはansibleも一緒。使い込んでいくと結局機能が足りなくて自分でモジュールとか作って
自分で作ったものは冪等性が実現できてなくて～みたいになって苦しんでる姿を見てる。

> DockerとかAnsibleみたいなツールは何も「既存で熟練した技術者」
> のためにあるわけじゃないんだよ。
シェルスクリプトも「既存で熟練した技術者」のためにあるわけじゃないんだよ。
普段シェルで使ってるコマンドそのまま使えるから知識が応用できる

375 ：
>>373
> という粒度が必要になってきたからDockerができたんだよ。
ぜんぜん違うわｗ お前Docker分かってないじゃないかｗ

https://www.docker.com/what-container
ここよめ 面倒だからGoogleで日本語に翻訳したよ

> 開発、出荷、展開のための標準化されたユニットにソフトウェアをパッケージ化する
> コンテナイメージは、実行に必要なすべてのもの（コード、ランタイム、システムツール、
> システムライブラリ、設定）を含む軽量でスタンドアロンの実行可能なパッケージです。

「軽量でスタンドアロンの実行可能なパッケージです。」

ソースコードをコンパイルしてビルドすしたビルド生成物にさらにコード、ランタイム、
システムツール、システムライブラリ、設定をパッケージ化したものだ

複数のプロセスをパッケージ化したものじゃない。
静的リンクをさらに発展させてシステムライブラリまでをもリンクしたようなものだ。

> あとGitリポジトリと同じで「過去の状態に復帰できる」
いや？過去の状態に復帰するために使うことはまれ。
Dockerfileが同じでも全く同じイメージは作れない。
その時点で最新のディストリのパッケージが使われるから。
Makefileと同じで手順が残っていて1コマンド（ないし数コマンド）でビルドできるのが特徴

> コンテナの設定を「1ファイルとして外部に外出しできる」のも
> シェルの守備範囲外。
当たり前だろ・・・コンテナの設定を外出できるのはコンテナの機能だろ
なんでシェルの話とコンテナの話をごっちゃにしてるんだよｗ

> シェルはどうやっても依存関係が生じてなかなか「1ファイル」とはいかない
シェルが1ファイルとか誰も言ってないんだが？

376 ：
> した「マシン」と「プロセス」の粒度の中間にある「サーバ(=コンテナ)」

って言ってる時点で、

システムコンテナ（OpenVZなど） と アプリケーションコンテナ（Dockerなど）の
違いが分かってないとわかるんだよな。
コンテナ上で複数のプロセスを動かすとかさぁｗ

http://tokyodebian.alioth.debian.org/html/debianmeetingresume200912se8.html

> コンテナ型の仮想化技術というと有名なのは、 Solaris Containers や FreeBSD jail がありますが、
> Linux では Linux-VServer, OpenVZ*7 な どがあります。 いずれも既に使ったことがある方が多いのではないのでしょうか。
> lxc で提供されるサービスは、 大きく分類してシステムコンテナと、 アプリケーションコンテナの
> 2 つがあります。 前者は、 いわゆる OS まるごとの仮想化です。 init から起動して、 仮想 OS の空間を提供します。
> 後者は、 chroot によるアプリ ケーションの分離に近いです。
> 単一アプリケーションを分離するだけなので、 とても軽くシンプルなのが特徴 です。

377 ：
>>375
成果物として生成したものから起動する
コンテナは「仮想マシン」みたいなものだから、
そのなかで稼働するプロセスをカプセル化しているって言う
表現は間違っていない。
視野がせまいのはドキュメントの表面的な字面だけを捉えている
お前の方。
使うのが稀だとしても「過去の状態に復帰できる」が担保されているのと
上手く行かないかもしれないというのでは差が大きい。
それに差分抽出、差分吸収もできる。
「1ファイル」であるということは移植性が高いということ。
シェルは内部に多数の外部スクリプト、コマンドなどを読み込むから
1ファイルではなかなか他のマシンに移植しにくい。
因みにシェルが役に立たないとは言っていない。
だけどDockerやプロビジョンツールを否定するのは無理がある。

378 ：
>>377
> コンテナは「仮想マシン」みたいなものだから、

だからそれが間違いだってーのｗ

仮想マシンって何かわかってるか？（物理）マシン、ハードウェアを
ソフトウェアで実装することで仮想的なハードウェアを作り出すものだよ。

コンテナはハードウェアをソフトウェアで実現している
わけじゃないので仮想マシンとは全く違うもの

（アプリケーション）コンテナがやってる仮想化っていうのは
カーネル部分だ。コンテナごとにカーネル部分を仮想的に作り出すことで
アプリケーションごとに独立したユーザーランドを提供することができる
アプリケーション専用に独立した実行環境を持てるんだよ。

同じ「仮想」という言葉が入っているから勘違いしてるのだろうが
コンテナは仮想マシンとは全く違う。「仮想」ではあるが「マシン」じゃない。
仮想メモリと仮想マシンに両方共「仮想」が入っているから
同じようなものだと勘違いしているのと同じレベルの間違いをしてる。

> 表現は間違っていない。
間違っている所は仮想マシンみたいなものと言う所と
複数のプロセスをまとめるというものだ。
やろうと思えばできなくはないが、アプリケーションコンテナであるDockerは
複数のプロセスをまとめたりしない。複数のプロセスを動かすのは
物理・仮想マシンの役目だ。

物理・仮想マシンで複数のプロセスを起動する
Dockerコンテナ１つはその複数のプロセスの１つにすぎない

379 ：
>>377
> 使うのが稀だとしても「過去の状態に復帰できる」が担保されているのと
担保されていない。イメージを消してしまったら二度と同じものは作れない。

> 「1ファイル」であるということは移植性が高いということ。
俺は「1ファイル」なんかにこだわってないが、
なんでお前はそれにこだわってるんだ？

別に「１ファイル」であることは移植性は高くない。
何を根拠にそんなこと言ってるんだろうか？
移植性がないC言語のソースコードを1ファイルにすると
移植性が高くなるとでも？ 意味がわからない。

> シェルは内部に多数の外部スクリプト、コマンドなどを読み込むから
> 1ファイルではなかなか他のマシンに移植しにくい。

移植しにくいのは他の「マシン」ではなくて他のOS（ディストリ）
コンテナはその部分を仮想化して、カーネル以外の部分を
全部アプリケーションにくっつけてしまう。

結局のところ別の実行環境に移植するっていうのは理論上は
互換性があっても完璧とはいえないんだよ。
だからコンテナを使うことで、カーネル以外の部分に同じものを使うことで
移植そのものをなくしてしまった。

DockerコンテナはLinuxカーネルでしか動かないって知ってるか？
使うOSは全部Linuxだ。だから移植しなくて良いんだよ。

なおAnsible使っても移植作業は大変だ。DebianとCentOSでapt-get、yum違いも有るし
パッケージ名の違いも有る。パッケージの中に入っているものも違う。それぞれ用意しないといけない。
Dockerイメージににはカーネルを除いた「Debian」部分も含まれるから
CentOSで、Debianベースのイメージが動かせる。移植作業が不要とはこういうこと

380 ：
>>378
お前は国語が理解できないんだと思う。
「犬は狼みたいなもんだ」といったら
それの違いを生息地帯とか餌の内容とかごちゃごちゃ並べて
批判するタイプ。
つまり、抽象表現とかメタファーを一切受け入れられない。
その証拠に、使っている言葉がどっかのドキュメントに書いてある
文言そのまんまコピってきたような文章書いてるな。
学力テストでは高得点取れそうだが、物事を設計するのは苦手そう
違うかい？

381 ：
>>380
何が言いたいん？言葉遊び？

お前は「猫」と「海猫」は同じようなもんと
言ってるんだが？

382 ：
っていうか言い返したいのはわかるが、
レスの内容に言及しないのは何なんだろうなｗ

383 ：
> 違うかい？

あぁ、そうだ、これ、関係ないくだらない質問ををしてそれに答えなかったら、
否定しなかったから認めたんだ。おまえは認めたんだー。わーって
言うための布石だこれ。見たこと有るｗ

くだらない質問だけど違うって言っておくよ。おまえを黙らせるために。
でも関係ない話だからそれ以外何も言うつもりはないよ。

このスレに関係ある話をしような？

384 ：
...お、おう。
久々に来たら面白い事になってんな。

385 ：
Docker、2016、オライリー

Chef実践入門 - コードによるインフラ構成の自動化、2014

386 ：
殆ど同じ内容のDockerfileなんだけどちょっとだけ変えたい場合ってどう書けばいいの？

FROM me/hoge:debug
COPY . /hoge
WORKDIR /hoge
RUN ./setup.sh --debug
ENTRYPOINT ["run.sh"]

FROM me/hoge:release
COPY . /hoge
WORKDIR /hoge
RUN ./setup.sh
ENTRYPOINT ["run.sh"]

似たようなのが沢山ある

387 ：
>>386
build-argつかえ

388 ：
>>387
👍

389 ：
異なるimageを1つにマージしたい
なんていうか多重継承みたいな事をしたい
dotnetとpythonから派生して両方に依存したアプリを乗っけてビルドしたい的な要件
どちらかをfromにしてもう片方をdockerfileに書けば済む話なんだけどせっかく公式でdocker最適化メンテナンスしてくれてんだから両方ともそっち使いたいよね

390 ：
>>389
あんたも典型的な使い方を間違えてる。
Dockerはアプリケーションコンテナであって
システムコンテナじゃない

システムコンテナじゃないから「アプリを乗っける」なんて
考え方にはならないししてはいけない。

正しくは「アプリケーションをビルドする」だ。
Docker使ってアプリを作るんだよ。

391 ：
>>390
言葉の定義の問題でしょう
ここではwebアプリのリソースファイル一式をアプリと呼んでるだけ
というか質問に答えれないならしゃしゃりでないで黙っててください

392 ：
やめとけ
そいつ多分例のあいつ

393 ：
うんことうんこが激しくうんこを撒き散らしてるが、
自分一人で仕事するのであれば好きにしたらいい
チームでやるならメンバーのスキルセット考慮して選択するだろ
原理主義的にどっちがいいとか言ってる奴等はだいたい職場で浮くよな

394 ：
>>389
>>390
dockerの中でdockerを使うことが、最近のversionだと出来たりしませんか？

395 ：
すみません、教えて下さい
virtualbox+ubuntuで仮装ホストを立てる場合とdocker toolboxの違いってどんな感じなんでしょうか？

396 ：
>>395
docker toolboxの場合dockerが提供するべき機能を
ちゃんと提供している（努力している）って所かな
具体的に言うと起動したコンテナにlocalhostでつなげることができるとか
ボリューム機能が使えるという所。他にも有ると思うけど

コンテナの中は実行環境が隔離されてはいるけど、コンテナ自体は
ホストOS上で直接動かしているように見せられるのが特徴なわけ
つまりWindows上でDockerコンテナを動かしたとき、
Windows上のディレクトリをDockerコンテナは読み書きでき
Dockerコンテナでウェブアプリを起動した時、localhost:8080とかで接続できる

virtualbox+ubuntuだとWindowsがホストだとしてゲストマシンとして別のマシンが
起動するような感じ、ディレクトリとか共有設定していなければ別扱いだし
別のIPアドレスが割り当てられる、ポートフォワーディングの設定をしないとlocalhostで見れない。
Windowsとは別に用意されたubuntuマシンに入ってからubuntuマシン上でdockerを使うのに比べて
docker toolboxだとまるでWindows上で直接Dockerを動かしているよう見える。

まああとは考え方の違いがあるけどね。Windowsは使いづらいから
Windowsを捨てたつもりで、でほぼすべてを仮想マシンの中で過ごしたいっていうのなら
virtualbox+ubuntuでも良いと思う。でも今はWSLも出来たし、Windows上で開発
テキストエディタもWindows用atom。作ったウェブアプリをWindows用のブラウザで確認したい。
みたいな使い方をするのならdocker toolboxならそれができるように整備されているってわけ

397 ：
VirtualBoxでWindowsのファイルシステムをマウントして使うと遅いから
docker-unison使ってたけど
docker-syncの方が良いの？

https://github.com/leighmcculloch/docker-unison
http://docker-sync.io

398 ：
Vagrant.configure("2") do |config|
config.vm.box = "hashicorp/precise64"
config.vm.network "forwarded_port", guest: 80, host: 10080 # HTTP
config.vm.network "forwarded_port", guest: 443, host: 10443 # HTTPS
end

Vagrant, Chef では、Ruby の文法で、設定ファイルを書く

誰も、Vagrant の作者、Mitchell Hashimoto (HashiCorp)を、
避けて通ることはできない、と言われている

Docker、2016、オライリー
実践 Vagrant、Mitchell Hashimoto、2014、オライリー
Chef実践入門 - コードによるインフラ構成の自動化、2014

399 ：
>>397
これ興味あるわ
guardとかめたくさ遅いが改善されますか？

400 ：
>>396
ありがとうございます
ホストのwindows環境を活かしたいならsocker toolboxがいいんですね
勉強になりました

401 ：
日経Linux 11月号
WSL 特集

Docker の記事もある

Ubuntu 側では、Dockerデーモンが動かないため、
Windows 側の、VirtualBox に、Vagrant で、CoreOS を入れて、
その中に、Dockerデーモンをインストール

Ubuntu側から、Dockerコマンドで使う

付録は、サーバーがゼロから分かる本、100ページ。
サーバーでできること、77

付録DVD は、
Ubuntu 17.04 日本語 Remix (64 ビット版)
Ubuntu Server 17.04 (64 & 32 ビット版)
CentOS 7.3 LiveGNOME (64 ビット版)

402 ：
windowsで開発したイメージをraspberry piで動かすことはできますか？

403 ：
手元でビルドテストしたイメージがどこでも動くのがdockerのメリット

404 ：
暇な人おしえてください

物理マシンで作ったスクリプトファイルを仮想環境で実行したいんだけど
どうやってファイルを仮想ディレクトリにもっていけばいいの？
根本的にわかってないっす・・・

405 ：
自己解決
なるほど共有フォルダを作成すればいいのね

406 ：
最近vagrantを始めたのですが
このソフトがやっていることってもしかして
virtualboxのCLIを叩いてるだけでは？

407 ：
そうだよ
てかインフラアズコードって全部そうだよ

408 ：
ありがとうございます
やはりそうなんですね
そうなると、「vagrantでないと出来ないこと」は何なのかが気になります
プロビジョニング的なことでしょうか？
プロビジョニングは、
自動的にログインしてコマンドを叩くことで実現してるのでしょうか？
これはあらためて考えるとvirtualboxのCLIで出来ることを超えてる感じがします

409 ：
時間さえあって自分で作るならアセンブラでできないことは何もない

○○でないとできないこと＝"時間をかけずに"△△をすること
すべてそう。時間をかけないという問題を解決してる。

> これはあらためて考えるとvirtualboxのCLIで出来ることを超えてる感じがします
virtualboxのvboxmanageコマンドでできる

410 ：
>>408
vagrantはラッパだから、vagrantじゃないとできないことなどない

411 ：
自転車で行けるなら、歩いていけないことはない
というのと一緒

可能・不可能の話にしてしまうと大事な点が見えなくなる
同じことをするにもコスト・時間が少ないほうが良いだろう？
それはすごく重要な事だよ

412 ：
oracledbの公式イメージないんか
oracleはほんま使えんなぁ

413 ：
privilegedモードとdocker.sock共有だとどっちか危険ですか？

414 ：
docker run したときのパラメータ変えたかったら
今のコンテナからイメージつくるか、もとのイメージから、コンテナ作り直すしかないの？

415 ：
>>414
dockerイメージ = exeファイル
dockerコンテナ = exeファイルを実行して作ったプロセス
docker runのパラメータ = exeファイル起動時の引数

と考えればいいよ

起動時の引数を変えたいって変な話だよね
プロセスの状態を外部から変えたいならば、ファイルやネットワークやシグナル
なんかで、プロセスにメッセージを送ることになるでしょう？

416 ：
entrypointのことだろ
オプションで変えれるぞ

417 ：
>>416
今のコンテナからイメージ作らないで
もしくは
もとのイメージからコンテナ作り直さないで

変えられるって言いたい？

418 ：
>>415
１回exe起動したらずっとそのままの状態で起動しないとだめってのもおかしな話だよね
なんのために引数取れるようになってるのか考えれば、パラメータ変えて再実行なんてあり得る話
プロセスが継続してる必要はないけど、たとえばポート変えたいとかいくらでもあるだろ

コンテナが単純なexeと違うのは、内部に状態持って永続化してたりするから
まあ、コンテナ内部に永続化させたのが失敗だって話なんだろうけど

419 ：
>>418
だから俺は最初から、exeファイルの引数を変えて
再起動するのが普通だって言ってるだろ

再起動したくないって言ってるのは>>414
俺はそれに対して再起動しないで変えるための案を書いてる


後からやってきたお前のレスは、>>414が再起動したくないと言ってるのに対して
（再起動しないで）entrypointでオプション変えられるって言ってることになってるんだよ
だから俺は、それできんの？ってきてるんだが

ちゃんと文章読め

420 ：
>>418
> コンテナが単純なexeと違うのは、内部に状態持って永続化してたりするから

単純なexeだってビルドする時にソースコードに書かれた
定数やデータやリソースファイルなど、内部に状態を持って永続化するが？

421 ：
>>420
実行ファイルに埋め込まれた定数やリソースを永続化という用法が一般的かどうかは知らんが
状態のまえに、実行時に変化するってつけといて
あるいは状態もって永続化じゃなくて、データファイルでもいいぞ

422 ：
プロセスだって実行時にメモリ書き換えるだろ
実行時に状態変化してるんだよ

423 ：
メモリ書き換えるのは普通永続化されてるとは言わんわ
わざと曲解してるのかね

424 ：
>>423
だからdockerコンテナも同じ
基本的にコンテナは終了した後に再利用することはしない
消すのだから永続化していると考えてはいけないんだよ

425 ：
データベースとかリポジトリのコンテナは止めたり再開するだろ？

426 ：
まず質問に対してYesかNoで答えろよ。

427 ：
>>424
だからコンテナ内部に永続化させたのが失敗だって話なんだろうって

ただ、コンテナは中断しても良いけど終了させたいわけでも消したいわけでもないぞ
たとえば　現在のコンテナの内容のまま、　 -p 80:80 から -p 8080:80 にしたいってときにどうするんだって話

428 ：
>>425
しない。それは使い方が間違っている。
データベースに限らないがまずアプリとデータは分離させる
アプリはコンテナ、データはボリュームに保存する。
そしてコンテナは消してもデータは残るように作るのが通常のやり方

429 ：
>>427
> たとえば　現在のコンテナの内容のまま、　 -p 80:80 から -p 8080:80 にしたいってときにどうするんだって話

データはコンテナの中ではなくボリュームに保存する。
だからコンテナは消しても、データはそのまま。

アプリを一旦停止して再起動しても、データはファイルに保存してるだろ。
アプリを止める　＝　コンテナを止める
データをファイルに保存　＝　データをボリュームに保存
こう変わっただけ

これこそが「仮想化」なんだよ。
もし仮にアプリが決め打ちの絶対パスで/var/hogeにデータを書き込むという仕様だとしても、
dockerコンテナに閉じ込めておけば、アプリが/var/hogeに書き込んだとしても
ボリュームを使うことでコンテナの外では好きな場所に変更することができる
仮想メモリのように、アプリから見た書き込む場所とは別の物理的な場所にリマップできる

アプリや一連のシステムを一つのコンテナにパッケージングし
そのコンテナ＝アプリのようにみると、docker runのオプションで自由にポート番号
や書き込みディレクトリを変更できるカスタムアプリが出来上がる。

430 ：
ドッカスはネットワーキングがクソ
ホストのリゾルバぐらい参照せえや
なに勝手にグーグルにつないどんねん

431 ：
外部ポート5000番で公開してるregistryにloginしようとすると
フロントのnginxが400 bad request返してくるんだがなんとかならん？

おそらく
　docker loginがポート5000だからtlsじゃねーだろって判断する
　→dockerがhttpでregistryにつなぎに行く
　→nginxがhttpsじゃないので400返す
って流れになってるんだと思う
試しにregistryの外部ポートを443に変えてloginするとちゃんと成功する

docker loginで強制的にtls使うオプションとかあれば使うんだけど
docker login --helpしてもそれらしいオプションはなかった

443で公開するしかないのか
insecure-registryは使いたくないし

432 ：
ものすごく基本的なことかもしれませんが教えて下さい。
1つの物理マシンに、ubuntuをインストールし、色々な実験家用をdockerコンテナでインストールし、
そのマシンに複数ユーザが接続してdockerコンテナを使用する予定です。
同じコンテナを複数ユーザが使用しても大丈夫でしょうか。
それとも、元々マルチユーザのOSなのでこのような使い方こそが向いているのでしょうか。

433 ：
Ubuntuはただだからなにやってもいいよｗ

434 ：
>>432
実験や学習に使うならdockerじゃなくてvagrantの方がいいかな
サーバー共有する必要はないと思うのでローカルにインストールさせれば？

435 ：
CentOS7にDocker入れて、
Hass.ioというホームアシスタントのコンテナHass.ioを走らせたのですが
クライアントPCから接続できなくて困っています。
DockerとCentOSの間で外部への橋渡し設定が必要なのか
CentOSのsamba設定がまずいのか
どちらかと考えています。
前者の原因はあるでしょうか？
Dockerをアプリみたいに考えていいなら、前者は考えなくていいと思っています。

本人はDocker初心者でlinuxは数年ぶりに触っています。

436 ：
【自然破壊】何百種類ものコンピューターは必要ない
http://lavender.2ch.sc/test/read.cgi/kaden/1510387401/l50
世界教師マイトＬーヤ「大暴落は日本からスタート」
http://rio2016.2ch.sc/test/read.cgi/2chse/1512813686/l50

【テレパシー】世界教師マイトＬーヤの演説『大宣言』は、１４歳以上、３つの体験、１４名の覚者を紹介
https://rosie.2ch.sc/test/read.cgi/liveplus/1513126180/l50
【テレパシー】元国連職員「いきなり声が…『聞こえないフリ、分からぬフリをするな、照れをなくせ』」
http://rosie.2ch.sc/test/read.cgi/liveplus/1513067436/l50

437 ：
>>435
Hass.ioなんてのはしらんのでその説明と構成を言ってくれないと答えられん。
そのHass.ioはサーバーなのかHTTPかなにかで接続するのか、
samba は直接CentOS上で動かしているのか？
それともHass.ioのコンテナに含まれてるのか、別のコンテナなのか
Hass.ioとsambaはどう連携するのか
マシン構成はクライアントPCとサーバーPCの二台なのか
それともクライアントPCとHass.io用PCとsamba用PCの三台なのか

438 ：
あとDocke（コンテナ）をアプリみたいに考えて良いのはそのとおりだが
何かしらのサービスを提供するアプリは、サービスを提供するための
ポート番号を設定するだろ？（デフォルトで指定されてることも多いが）
Dockerコンテナ＝アプリはそのポート番号を明示的に指定しなければいけない

439 ：
>>437
Hass.ioはhttpの8123ポートへアクセスするとブラウザベースのサービスを提供するもの。
Hass.ioはcentosのdocker上で動かしている。
sambaはcentos上で動かしている。
マシン構成はクライアントPCとサーバーPCのcentosの計2台。
docker0とHass.ioは172.のローカルIPが振られていて、サーバーPCは192.のローカルIPがDHCPで振られている。
サーバーPCはワークグループに表示されているが、ゲストアクセス出来ない。

すみません。分かることを書いてみました。
本人はサーバー立ち上げ経験ありません。

440 ：
>>432-434
漏れの推測だけど、

そのOS に、Docker イメージが1つだけで済む。
各ユーザーは、そのイメージからの差分だけを持てば良いから、効率的

441 ：
>>435
Hass.ioとやらとsambaの連携は必要なの？
Hass.ioだけ起動して動作するか確かめよう

442 ：
>>441
あ、公式ホームページ読むと
Hass.ioでsambaとSSHが使えると書いてあるのかな。
確認してみます。

443 ：
1つのアプリケーションで複数サービス起動したい場合のベストプラクティス教えて

444 ：
バッドプラクティスしたい場合の
ベストプラクティスを教えてと言われても・・・

445 ：
そういう時はdindだな

446 ：
ジェンキンスでイメージをレジストリにpushするところまで出来たのだけど
pushしたイメージを運用サーバーにpull & restartしてもらうにはどうすればいいの？ssh？

447 ：
人いねえな
日本じゃ仮想環境はまだまだマイナーなのか
大企業でもでっかい社内サーバーにあれこれ同居させてなんてことが未だにあるし
そういう文化なのかなぁ

448 ：
Dockerのコンテナで開発環境として
いろんなサーバつくる上での「共通素材」が
そろったコンテナ配布していないかな。
プログラミングが学習しにくい内容として
例えばDBを学びたときに「DB内に予め素材データがたくさん詰まっていたら」
それをもとに勉強や試しに動かしやすくなる。
JavaScriptを試したいときにい予めサンプル画像や文言、
試し切り用のHTML構造がたくさん詰まっていてくれたら検証しやすくなる。
テストコードがあらかじめたくさんあったらそれに合わすような
プログラムが作りやすくなる。
開発環境は素材付きで配布するっていいアイデアじゃないか？

449 ：
Dockerhubに登録すれば良いものなら評価してくてるよ

450 ：
これどういうこと？
Docker死ぬん？　せっかく覚えてきたのに？

Docker, Inc is Dead / Docker社は死んだ
http://itosho525.hatenablog.com/entry/2018/01/01/074358

451 ：
無問題

452 ：
>>448
素材データはあちこちでいろんな形で配布してるから実情にあったのを自分で選ぶべきだな

R程度の軽いデータ付属してても問題ないけど重量級のデータが詰まってるのなんて邪魔でしかない

453 ：
ねーよ

454 ：
DockerはMSに買収された方がいい方向に進むだろうね

455 ：
Docker、2016、オライリー

実践 Vagrant、Mitchell Hashimoto、2014、オライリー

Vagrant, Packer などで有名な、HashiCorp の創始者


Chef実践入門 - コードによるインフラ構成の自動化、2014

cookbookは各社が公開している

Chef社のopscode、Railsを作っている Basecamp社、
Berkshelfを作っている Riot Games社、
Pivotal Trackerを作っている Pivotal Sprout社、
aws, engine yard

456 ：
dockerでデスクトップ環境とスマホエミュレーター作れる？

457 ：
まーたdockerが何か分かってない奴の質問か

dockerはカスタマイズされたアプリを作るものであって
環境を作るものじゃないんだよ

ここにアプリが有るじゃろ？から始まって
このアプリを動かすにはこのライブラリが必要で
こういう設定ファイルが必要じゃろ？
それらのアプリとそのアプリを動かす環境を
合体させてアプリを作るんだよ

だからデスクトプアプリは作れても
デスクトップ環境はそのそもdockerで作るものじゃない
スマホエミュレータはアプリなんだから作れるだろう

458 ：
クリーンなビルド環境としてのdockerなど、当たり前のように環境として使われてるが?

459 ：
>>458
それはクリーンな環境を作ってるのではなく
作っているのはあくまでビルド生成物
その途中がクリーンな環境になっているってだけの話だな

460 ：
>>459
大丈夫か? あんま無理すんなよ
「その途中がクリーンな環境になっている」の環境はまさにdockerで作ってるんだぞ?

461 ：
ビルド環境だけじゃなくテストを走らせる環境もDockerで作る
Travis CIとか使ったことないんじゃ

462 ：
固定概念でdockerの可能性を絞るのは宜しくないね

463 ：
それぞれ
・ビルド生成物を作成するアプリ
・テスト結果を作成するアプリ
だと言いたいんだろう

ていうか、彼の世界観でスマホエミュレータがOKなんだったら
Linuxデスクトップ環境エミュレータだってOKなんだけどなw

464 ：
スマホのエミュレータは、ハードウェアをエミュレートしているアプリを
作るところまでがdockerでやる部分でスマホの環境を作ってるのは
スマホに入れたOSが作ってるものだからね

465 ：
開発環境を仮想化したいがVagrant+VirtualBoxは重いんだよな

466 ：
>>465
you, windows 10にしちゃいなyo!

467 ：
>>465
/vagrant/ 共有フォルダ下に
プロジェクトのソース、DBディレクトリなど開発環境置いて
ホストマシンから編集すれば万事解決

468 ：
コンテナ内でandroidエミュをヘッドレス起動 OK
エミュブート待機 OK
コンテナ内でadb tcpip 5555 OK
ポートフォワーディング5555:5555 OK
コンテナ内でadb connect localhost:5555 OK
コンテナ外からadb connect localhost:5555 繋がらない

なんでやねん😭

469 ：
外から接続できない設定になってるだけだろ

470 ：
dockerの参考書でできるだけ新しく内容が濃いものはどれ？
ネット検索で断片的な情報を集めるのに疲れた

471 ：
>>470
https://docs.docker.com/engine/reference/builder/

472 ：
環境構築には、vagrant, chef は、Ruby でレシピ(手順書)を書ける。
Docker もある

仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]c2ch.sc
https://mevius.2ch.sc/test/read.cgi/tech/1487235664/l50

473 ：
472 は、誤爆

474 ：
ansible絶対Rおじさんは最近あばれてないの？

475 ：
>>474
暴れてますよ。

476 ：
ubuntuコンテナにRDP接続したいのですがどうすればいいですか？
Xウィンドウ？とかいうのを使うらしいのですがよくわかりません

477 ：
プロフェッショナルの方、どなたか教えてください(/ω＼)

今、下記内容のdockerimageを作成したいと思っています。
　
　①　ベースのイメージ：jupyter/datascience-notebook
　②　Tensorflowを使いたい　※①にTensorflowがインストールされていないため

その為にdockerfileを下記の通り作成したのですが、
出来上がったdockerimageから作成したコンテナ上で上手くtensorflowが動きません。
※コンテナ内でpythonを起動し、そこで「import tensorflow as ts」を実行すると以下のエラーが出ます。
RuntimeError: module compiled against API version 0xc but this version of numpy is 0xa
ImportError: numpy.core.multiarray failed to import
ImportError: numpy.core.umath failed to import
ImportError: numpy.core.umath failed to import
2018-04-20 03:56:29.133557: F tensorflow/python/lib/core/bfloat16.cc:664] Check failed: PyBfloat16_Type.tp_base != nullptr
Aborted

dockerfileの内容は以下になりますが、何か間違っていますでしょうか？
もし間違っている場合は、修正内容をお教えください。m(__)m

■dockerfileの内容
From jupyter/datascience-notebook
RUN pip install --upgrade pip
RUN pip install tensorflow==1.5

478 ：
質問が続いて申し訳ありません。
もう本当の初心者の初心者で、これからローカル開発環境を構築しようというところで、
Vagrantの初期化に失敗し途方に暮れております。
海外サイト含めいろいろググりましたし、パスやユーザー名の問題もないと思います。
Invalid argument @ dir_s_mkdir - C:/Users/(user)/MyVagrant/MyCentOS/?vagrant_home (Errno::EINVAL)
と出て、初期化（Vagrantfileの作成）に失敗します。

どなたか助けてください・・

479 ：
>>478
mac買ったらいーよ
私はubuntuユーザーです。
winは色々大変

480 ：
DockerでLet's encrpt使えますか？

481 ：
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

AUPZD

482 ：
AUPZD

483 ：
windows 10 メモリ4GでDocker動かすテクニック知らん？
こいつリソース食い過ぎなんだけど

484 ：
メインマシンが4GBだったら軽蔑する

485 ：
メモリ4Gなんて１５年前の標準PCじゃん

486 ：
32GBでようやく標準装備といえる

487 ：
>>483
DockerはWindowsとLinuxではLinux仮想マシンを使う
だから設定から仮想マシンに割り当てるメモリを変更すれば良い

WSLのLinux互換機能が高くなれば、仮想マシン使わずに
ネイティブに動くのにな。まだかなー

488 ：
>>486
おいおいスパコンかよ

489 ：
>>488
スパコンの定義は1.5TFLOPS以上から50TFLOPS以上に変わったらしいで

https://ja.wikipedia.org/wiki/FLOPS
1.5TFLOPSとか発売当時で今なら中古で1万？ぐらいの
GeForce GTX 580で超えるからな

490 ：
DockerとVagrant両方使ったが、覚えることはVagrantのほうが少ないな
軽さではDockerかな

491 ：
コンテナ起動した後に初期化スクリプト走るタイプのコンテナが使いにくいんだがどうにかならんのあれ

oracledbコンテナ起動
クエリ通るまでポーリング
スキーマ構築
固定のマスタデータ投入
テスト用のトランザクションデータ投入
UI テスト開始

CIサーバーでテスト開始するまでが長すぎてもったいないと思った
初期データまで込みでイメージにしたい

492 ：
>>491
それは初期化スクリプトが問題なのではなく
データベースサーバーが起動するまで待っているから
データ込みにしてようが結局データベースサーバーが起動するまで待つ

493 ：
仮想サーバーがイメージつかめないんだよな
そもそも、vagrantって言葉の意味もわからんしな

494 ：
ジェム、ユムとか意味わからん

495 ：
Vagrant重すぎ

496 ：
>>495
スペック

497 ：
>>496
20代独身172cm65kg
石原さとみがタイプだが嫁にはしたくないタイプだな
料理下手そう

498 ：
>>496
Core i5、メモリ4GB
メモリ不足かな？

499 ：
メモリ4GBって10年前から時が止まってんのか

500 ：
業務系はどこもこんなもんだよ
経営者がITよくわかってないから設備投資には消極的
エクセルとエディタが動けば開発できるだろ贅沢言うな経費削減だって本気で考える

501 ：
金無いんだから仕方ないだろ
そんなこと言うなら俺にパソコン買ってくれ

502 ：
アマゾンからインスタンス借りれば？
端末買うよりは安いでしょ

503 ：
Dockerを使っていてもAnsibleのような仕組みはやっぱり必要なんだな
コンテナを起動した後に起動をポーリング待ちして初期設定処理を動かさなきゃならんコンテナが多すぎる
リポジトリからコードcloneしてupすればローカル開発環境のセットアップ完了なんてのは儚い夢だった

504 ：
Ansibleのようなでかい仕組みはいらないけどね。
シェルスクリプトもしくはシェルスクリプトベースのなにかで良い

あと「ローカル開発環境」の定義がきれいに定まってない気がする。
おそらく、IDEやテキストエディタを含めたものを言ってるのだろうけど
分けて考えないといけないと思う

1. ソースコードを作成する環境
2. 開発したアプリを動かす環境
3. 実行するサーバー相当の環境

505 ：
まあansでもshでもいいけど何れにせよサービス起動前とサービス起動後の設定を一元化して管理したい場合にはDockerは致命的に使いにくいってこと

506 ：
>>505
それは典型的なDockerの使い方の間違いだよ
間違ってるので、何を想定してるのかよくわからない
設定を一元管理？なんの話だそれは

正しいDockerの使い方はアプリとその実行環境を固めたアプリ・サービスを作ること
及び設定内容を埋め込むことで起動するだけで動くアプリ・サービスを作る

1. 新しく物理・仮想サーバーを用意して、
2. 環境ごとのサーバーの設定を行って、
3. アプリ・サービスを動かすのに必要な環境を用意して（必要ライブラリのインストールなど）
4. アプリ・サービスをインストールして
5. アプリ・サービスの設定を行って
6. 環境構築を完成させる

よりも

1. 新しく物理・仮想サーバーを用意して、
2. 環境ごとのサーバー設定を行って、
3. アプリ・サービスをDocker経由でインストール・起動して
4. 環境構築を完成させる

この方が楽でしょ？

特に一つのマシンで複数のアプリ・サービスを動かそうとしたとき、
そのアプリ・サービス毎に必要な環境が異なっていたら大変になる
それぞれが必要なライブラリのバージョンが異なっていて動かないとかね

507 ：
DockerもVagrantもcronが絡むと途端に使えなくなるな
仮想コンテナ系の限界だな

508 ：
>>503
あの、出来てますよ、それ
初期化待ちって、Dbの構築とかですか？

509 ：
cronも良く分からないが、使う？
動作確認だけなら、cronで叩く処理を動かせば良いような

510 ：
>>507
普通にcronからDockerコンテナ化した
プログラム実行するだけじゃん
何が使えないの？
使い方が間違ってるだけじゃないの？

511 ：
>>506
例えばAnsibleだったら

1. 新しく物理・仮想サーバーを用意して、
2. 環境ごとのサーバーの設定を行って、
3. アプリ・サービスを動かすのに必要な環境を用意して（必要ライブラリのインストールなど）
4. アプリ・サービスをインストールして
5. アプリ・サービスの設定を行って
6. 環境構築を完成させる

ってのは1はともかく2〜5はAnsibleだけで一元管理できる

でもDockerだと

1. 新しく物理・仮想サーバーを用意して、
2. 環境ごとのサーバーの設定を行って、
3. アプリ・サービスを動かすのに必要な環境を用意して（必要ライブラリのインストールなど）
4. アプリ・サービスをインストールして
5. アプリ・サービスの設定を行って
6. 環境構築を完成させる

2はシェルスクリプトやAnsibleなど
3はDockerfile
4はComposeやKubernetesなど
5はシェルスクリプトやAnsibleなど

このように色々と使い分けなければならない

どっちにしたって自動化するなら1つのテクノロジで管理できるAnsibleのほうが楽でしょってこと

512 ：
>>508
うん、主にDB
DBに設定データを保存するパターンのアプリも必然的に同じ状況になる

もちろん自分が作ってるアプリの設定ならDBの初期化スクリプトに追記すればいいと思う
postgresなどは親切にもオフィシャルでスキーマ初期化の機構が用意されてる(oracle公式はなかったけど)

でも他人が作ったアプリではそうもいかない
DBの初期化スクリプトで初期設定データを挿入することはできるだろうけど、なにを入れればいいのかがわからない
手動で設定した後にDBを分析して、入れるべきデータを調べることはできるけど、手間がかかりすぎる
それにアプリが実行してる初期化に割り込んでデータを挿入するというのは行儀が悪い
なのでアプリが起動した後、アプリが用意したインターフェースで設定を行うことになる
管理用のREST APIが整備されてるならそれ、ブラウザでしか動かせないならSelenium、といった具合
docker execでコンテナに入ってコマンドで設定というパターンもあるけど(railsアプリに多い気がする)、設定のためだけに普段使わないフレームワークを覚える気はしない

513 ：
ドッカーはウェブアプリ専用
基本中の基本やろがい

514 ：
>>511
> ってのは1はともかく2〜5はAnsibleだけで一元管理できる
一人でプログラム作ってんのか？

アプリを動かすのに必要な、OSの環境、入れて置かなければいけないパッケージ
その他必要なライブラリはなんなのか？
それをアプリを作ってない人が把握するのは大変だよね？

それらのバージョンはアプリの開発やセキュリティパッチなどで日々変わっていく
そのたびにAnsibleをメンテナンスするのは大変
物理・仮想サーバーのAnsible構成と一体化してるから、
ローカルで動かしてみるのも大変

サーバーの環境設定と、アプリの実行環境構築は別々の作業で別々の人がやる
アプリを開発してる人は自分の責任でアプリを実行できる環境を用意しないといけない。

サーバーの設定を行ってる人（Ansibleの設定書いてる人）に、
あ、これこれのライブラリ入れてください。バージョンはこれで。
アプリのバージョン更新するんで、Ansibleであれとこれ更新してください。
え？動かない。手元ではちゃんと動いてるんですが？
ライブラリのバージョン違ってるじゃないですかー、ちゃんと入れてくださいよー
あんたのミスですよ。
なんてことあってはならない

515 ：
担当者を明確に分けるとこういうことなんだわ

1. [インフラ] 新しく物理・仮想サーバーを用意して、
2. [インフラ] 環境ごとのサーバーの設定を行って、
3. [アプリ開発] アプリ・サービスを動かすのに必要な環境を用意して（必要ライブラリのインストールなど）
4. [インフラ][アプリ開発] アプリ・サービスをインストールして
5. [アプリ開発] アプリ・サービスの設定を行って
6. [インフラ][アプリ開発] 環境構築を完成させる


担当者ごとに分けると以下のようになる

・Ansibleで設定する部分
1. [インフラ] 新しく物理・仮想サーバーを用意して、
2. [インフラ] 環境ごとのサーバーの設定を行って、
4. [インフラ] アプリ・サービスをインストールして
　（kubernetesのような運用向けオーケストレーション、または単体でDockerコンテナ起動）
6. [インフラ] 運用環境構築を完成させる

・Dockerでコンテナ化する部分
3. [アプリ開発] アプリ・サービスを動かすのに必要な環境を用意して（必要ライブラリのインストールなど）
4. [アプリ開発] アプリ・サービスをインストールして
　（Composeのような開発向けオーケストレーション、または単体でDockerコンテナ起動）
5. [アプリ開発] アプリ・サービスの設定を行って
6. [アプリ開発] 開発環境構築を完成させる

作業は明確に分かれてるんだよ
担当者が違う作業を一緒にしてしまってはいけない

516 ：
>>513
> ドッカーはウェブアプリ専用

違うよ。例えばffmpegのような多くの外部ライブラリに依存し
バージョンの違いの影響も大きくコンパイルオプションも豊富で、
権利関連の問題でどのディストリでも標準パッケージでは満足できず
かと言ってライブラリを自分でビルドすると依存関係が壊れがちになって、
すべての機能をONにしたければ自分でビルドするはめになるようなソフトは
Dockerを使うと、簡単にビルド・実行できるようになる。
自分の好きなディストリを使いつつ、ffmpegは他のディストリベースにすることができる

517 ：
サーバの環境をdocker上に作っておく
リプレースが必要になったら新しいサーバにimageを移す

古いけどファミコンのカセットを新しいサーバに刺しなおすだけ

518 ：
つまり

* Dockerの利点はアプリの依存関係のパッケージングである
　JavaランタイムなしでJavaアプリが動かせますといったことがOSレベルの依存関係でも可能

* Dockerによってパッケージングされたアプリだけではシステムとして成立しない
　Ansibleやオレオレスクリプトで別途環境構成や設定を管理する必要がある

こういうことですか?
DockerはあくまでAnsibleやオレオレスクリプトで管理される取り扱いが容易な部品に徹すると

519 ：
そもそもAnsibleとDockerって明確にセグメント違うでしょ
優劣がどうこう言うたぐいのものじゃない

520 ：
AnsibleはAnsibleだけでいいけど
DockerはAnsibleやシェルなど別途構成要素が必要
結局はここに落ち着く
>>503から進展してない

521 ：
> AnsibleはAnsibleだけでいいけど
> DockerはAnsibleやシェルなど別途構成要素が必要

え？ Ansibleでアプリ開発してんの？
普通別の言語を使うよね？
というかAnsibleでどうやってアプリ開発するのか知らんがｗ

なぜそんなに、アプリ開発の一環である
Dockerコンテナの作成を、Ansibleでやることにこだわるのか？
どうせアプリ開発は別言語でやるのに

インフラ担当は、アプリ開発をしなくていいんだよ？

522 ：
>>521
Ansibleでアプリ開発?
スマンが言ってること意味不明なので解説して欲しい

523 ：
Docker使わない場合(4step, 2lang)
【Java】 Javaアプリ開発
【Ansible】 Javaランタイムインストール
【Ansible】 Javaアプリデプロイ
【Ansible】 アプリ設定

Docker使う場合(5step, 3lang)
【Java】 Javaアプリ開発
【Docker】 Javaランタイムインストール
【Docker】 Javaアプリデプロイ
【Ansible】 コンテナデプロイ
【Ansible】 アプリ設定

覚えること、仕事増えてるよね?

524 ：
>>523
ボケはもういいから

525 ：
>>522
だってすべてAnsibleだけでできるわけないじゃん。
インフラさんはAnsible使ってるだろうけど、
アプリ開発者は別の言語使ってるよね？

インフラさんにとっては、アプリがなんの言語で作られてようが
Dockerコンテナで実行環境毎まとまってようがどうでもいいことじゃん

重要なのはアプリを開発してないインフラさん
（＝どんな実行環境・ライブラリなどで動くかなど知らない）が
アプリに依存したことを意識せず「Dockerコンテナを動かす」という
ただそれだけのことで、サービス運用環境を作れること

専門家に任せましょう。どんな実行環境・ライブラリなどで動くかは
アプリ開発者は知ってます。それで作ってテストしてるんだから
アプリ開発者はAnsibleなんか使いません

526 ：
あとAnsibleを使えばDockerのようなことができると
思ってるようだけど、できないからな

・Dockerを使うと実行環境をアプリに組み込むことができます
・Dockerはアプリが使用するポート番号を自由に変更することができます
・Dockerは複雑なアプリ設定を単純化し、引数や環境変数で指定可能なアプリに作り変えます

所詮Ansibleは作られたアプリに対して設定を行うだけで、
Dockerのようにアプリ自体を改善・強化することはできない
アプリをDockerコンテナ化するだけでいろんなOSで動かすできるのも
アプリ自体の改善・強化の一つだな

527 ：
>>510
コンテナ内でcron動かせなきゃ意味ない
cronを含めたパッケージングがしたかったんだよぉ

528 ：
>>527
だから使い方を完全に間違ってる
Dockerはアプリに実行環境を埋め込んで、完全体のアプリを作ること
exeファイルの中にdllなどを埋め込むのと近い

あんたが言ってるのは、C言語でソースコードをビルドしてバイナリを生成して、
バイナリを実行したらcronが動くんじゃなくて、ファイルが存在するだけで
cronを動かすようにしたいって言ってるようなもの

ビルドしただけで動き出すようなプログラムなんてない
意味不明なことを言ってるってわかるだろ？

もちろんDockerコンテナを実行したら内部でcronが実行されてるっていうのなら
簡単にできるが、cronを使うまでもなく実行時間までsleepするだけで十分だな

529 ：
>>525
＞>>522
＞だってすべてAnsibleだけでできるわけないじゃん。
＞インフラさんはAnsible使ってるだろうけど、
＞アプリ開発者は別の言語使ってるよね？
アプリ開発言語は別に決まってんじゃんって常識的に考えてわからんか？

＞インフラさんにとっては、アプリがなんの言語で作られてようが
＞Dockerコンテナで実行環境毎まとまってようがどうでもいいことじゃん
そのとおり
ドウデモイイんだ
ドウデモイイので使うテクノロジーは減らしたほうがいい

＞重要なのはアプリを開発してないインフラさん
＞（＝どんな実行環境・ライブラリなどで動くかなど知らない）が
＞アプリに依存したことを意識せず「Dockerコンテナを動かす」という
＞ただそれだけのことで、サービス運用環境を作れること
ロールでいいじゃん
ロールの詳細までは別に知らなくていい(知りたければ見ればいい)

＞専門家に任せましょう。どんな実行環境・ライブラリなどで動くかは
＞アプリ開発者は知ってます。それで作ってテストしてるんだから
＞アプリ開発者はAnsibleなんか使いません
クラウドが一般化してきてプログラマでもインフラに関わらなきゃならない機会は増えてる
当然Ansibleも必須科目

530 ：
>>526
便利っちゃ便利だけど別に必須でもなんでもないよねそれ
それに逆に設定がめんどくさくなることもある(DBとか色々)

531 ：
>>528
Dockerで作った完全体のアプリ()を誰かがコントロールしてやらなければならないんだどうせなq
exeを作っただけじゃ役に立たないようにイメージを作っただけじゃ役に立たない
サービスとして起動して起動後の設定を行う必要がある
そのための基盤がAnsibleみたいな構成管理ツール
どうせAnsible使うなら最初から全部Ansibleでやりゃいいじゃんってこと
依存関係をDockerfileで解決するかPlaybookで解決するかの違いでしかない
複雑な依存関係がある場合はDockerでカプセル化するメリットがあるかもしれんがそんなのは頻繁に起こることじゃない

532 ：
bashで全部できるならbashでやるのか？
馬鹿じゃねーの？

Dockerが必要な状況ならDocker入れればいいだけで何のためにDocker使うかわかりもしないのに入れて
手順が増えるとか言う馬鹿

533 ：
問題解決や利便性のためにDockerが必要な局面もあるだろ
そういうときにDockerが使えればいいだけ

Ansibleしか使えないのに俺スゲーしたいんだろ
俺日本語だけで十分だからなんで英語やフランス語使ってるのかわからんみたいな
低レベルな自慢みたいな浅はかな感じがする

534 ：
> ドウデモイイので使うテクノロジーは減らしたほうがいい

それならAnsibleをなくしたいねｗ

だってシェルスクリプトは普段からCLIで使ってるけど
Ansibleは使わないじゃん。

シェルスクリプトはなくせないが、Ansible
はシェルスクリプトで置き換えれば無くせる

Dockerはシェルスクリプトベースだしね

535 ：
そう必要なときに使えばいいんだよ

bashだけで構成管理する大道芸はキツイ
からなんかツールないとやっていけないぞそう世界中のみんなが考えて発明されたのがAnsibleのようなツール
必要性から生まれたツールなんで必要なものなんだね

Dockerは使うと面白いのはわかるけど必要かって言われると正直別に…ってところだな
依存関係？どんだけごった煮のサーバー作る気だ？
ポート変えれます？おめでとさん
引数や環境変数で設定可能？パラメータはファイルに残そうね

536 ：
>>535
アプリに実行環境を組み込んで可搬性のあるアプリを
作るってところはまだ意味がわかってないのかな？
そこについての言及がないってことはそうなんだろうね

Ansibleで開発したアプリの設定を行うほうが大道芸
だって自社で開発したアプリにAnsibleモジュールは存在しない
自分でモジュール作るか？それともコマンド呼び出しで頑張るか？

自社で開発したアプリを動かすにはあれとこれのインストールが必要です。
バージョンが上がったので今度はそれも追加してください
設定項目が追加されてるので、それを設定するように書き換えてください
冪等性あるように作ってください
アプリのデプロイの前に、Ansibleで環境を更新してください
そうしないとアプリ動きませんから！
絶対にミスしないでくださいよ！！

はい、大道芸ｗ

Dockerを使うとそういう複雑なところが隠蔽されるんだよ
Ansibleで書くのはDockerコンテナを起動する。そのためのモジュールを使うだけ
手元でテストしたDockerコンテナを実環境でも使う。だから実行環境に違いはない。
Ansibleの定義ファイルは単にバージョン番号を変更するだけ

537 ：
まだわからんかねぇ
Dockerで完結しないってとこからは目をそらし続けるんだ
コンテナ起動するたびシェルで必死に起動後の設定とかアホくさ

そもそもそんな手順はいらない
ロール用意したんでそれ使ってくださいで終わり

538 ：
> Dockerで完結しないってとこからは目をそらし続けるんだ

どうせアプリはJava使ってありRuby使ったりするんだ、
Ansibleだけで完結することもないよ

それにお前の定義によればDocker使っても「Ansibleだけで完結」してることになるだろ
なぜって？ AnsibleのDockerモジュールを使うからだよ

お前、Ansibleでcronの設定したら「Ansibleだけでは完結しない。cronが必要」って言うか？
言わないよなぁ？ Ansibleでcron設定しようがDockerコンテナ化したアプリの設定しようが
Ansibleだけで完結してることになってるだろ


んで話を戻して、JavaやRubyなどでアプリを開発してるが
Dockerを使おうがAnsibleを使おうが、新たに別のテクノロジーを使ってるのは一緒。
ならDockerのほうが可搬性の点でもシェルスクリプトベースという点でも
メリットがあるので、Dockerを使ったほうがいい

539 ：
訂正＆補足

んで話を戻して、普段JavaやRubyなどでアプリを開発してる人が
Dockerを使おうがAnsibleを使おうが、新たにアプリ開発言語とは別のテクノロジーを使ってるのは一緒。

540 ：
必要な環境はロールでカプセル化されっからドッカーでカプセル化して二度手間にする必要はないってことな


つか
「Ansibleで完結」を拡大解釈してねえか？
アプリ開発にジャヴァやらなんやら使うからほれみろAnsibleで完結してませーんってボケにしてもあんまし面白くないぞ


Docker使っても使わなくてもAnsibleで完結してるってのはそうだな
所詮は1モジュールでしかない
逆にDocker視点で見れば全然完結してなくてDockerより大きな他の仕組みが必要になる

541 ：
kubeと組み合わせるケースはansibleだけではカバー出来んじゃろ

542 ：
Ansibleはwindowsも含めて使ったらPowerShellも覚えないといけない

543 ：
>>528
その通りだとするとcronを使ったwebシステムのパッケージングにはDockerは不向きってことになるが
だとすると俺のイメージと違うな
実行環境を含めたパッケージングの利点はまぁわかるが、ツールレベルのバイナリを使うのにわざわざビルドするのはめんどくさくない？
実行環境をパッケージングできるのはすごいアイデアだと思うよ。でも俺は例えばcatを使うのにわざわざDockerでビルドしたりしないな。そのレベルのバイナリならyumとかapt使うわ

544 ：
>>543
馬鹿か。だから自分で作ったアプリに実行環境をくっつけるんだよ
ほんとなぁ、開発者のためのツールだってわかっちゃいねぇ

545 ：
LXC 生で使ってる人いる?

546 ：
つかいたくなければ、つかわなければいい
これだけで全部解決できるわけないし

547 ：
>>544
批判的な俺だが仕事ではDocker使ってるんだよね
小規模webサイト程度ならほんと使い勝手いいわDocker
引っ越しもすげー楽

548 ：
ウェブサービスや一回走らせて終わりのコマンドと相性が良すぎるんだよなドッカー
それ以外は残念だけど面倒が増えるだけ

549 ：
> それ以外は残念だけど面倒が増えるだけ

サービスとコマンド以外に世の中に何があるんや？

550 ：
Q8Y

551 ：
ウェブアプリテスト環境をmac上のDocker環境で行っているのですが
雨が続くみたいのでリモート作業できるよう自宅のwindowsで同じ環境を構築しようと考えています

Docker上の挙動ってホストOSに依存しますか？
VMならHWレベルでエミュレートしてるので大丈夫そうですけど
Dockerの仮想化ってどのレベルでやってるんでしょうか

動かすのはスクリプト言語なのでバイナリレベルの互換性とかはそれほど影響うけなさそうですけど
通信したときのエンディアンとかはホストに依存したりするんでしょうか

やりとりはjsonのみなのでそのへんもちゃんと吸収されてるとは思うのですが
変なところではまりたくないので事前に確認したいです

552 ：
>>551
もともとDockerはLinuxカーネル上で動くものとして作られた
今はWindowsやIBM Zなどに対応しているようだが、使用例は少なく
意識して使おうと思わない限り、Linux（x64）のイメージを使ってるはずだ

Linux（x64）のイメージを使っているのだから、
そのDockerコンテナはMacやWindows上でネイティブに動かない。
だからMacやWindowsでは仮想マシンが使われておりVM上でLinuxが動いている
（このLinuxはDockerを動かすためだけの軽量なLinuxで直接使うことはないのでディストリは意識しなくていい）

Docker for Mac では xhyve (Mac純正仮想マシン）が使われている
Docker for Windows では Hyper-V（Windows純正仮想マシン）が使われている
Docker for Mac/Windowsのほうが新しく推奨だが、Hyper-VはWindows Pro以上でないと
使えないので、Docker Toolbox（Virtual Box）を使うしかない

仮想マシンを使用しているということを意識しないように、うまく設定されてはいるが、
それでも仮想マシンであるがゆえに、CPUやメモリの使用する量を仮想マシンに割り当てるしかなく
その範囲でしか使うことができない。これらはDockerの常駐アイコンから設定できる

> Dockerの仮想化ってどのレベルでやってるんでしょうか
勘違いしている人が多いが、仮想化 = ハードウェアエミュレーションという意味ではない
仮想化というのは単に物理的なものを切り離して抽象化するという意味なだけだ

仮想マシンは、マシンを仮想化したものだが、Dockerが提供しているものは、
（実行環境の）仮想化であって仮想マシンではない。ハードウェアを抽象化して
見せているのではなく実行環境（カーネル以外のOSやライブラリなど）を抽象化して見せているだけ

553 ：
訂正

Docker for Mac/Windowsのほうが新しく推奨だが、Hyper-VはWindows Pro以上でないと
使えないので、 "Docker for Windowsが使えない場合は" Docker Toolbox（Virtual Box）を使うしかない

554 ：
環境構築は人にたよってて
その上でjavaやPHPのコーディングするのがメインなのでちゃんと理解できてない…

今の案件がRailsなんですけど
結論からいうとwindows上のDockerでRailsを動かす同じ環境を構築するのは難しい感じでしょうか

555 ：
>>554
別に？

同じように使える。というか同じように使えるように
Docker社が頑張ってくれてる。

もともとLinuxカーネルでしか動かないのに
よくもまあこんなに頑張って対応したもんだと思うよ
WindowsやMacでも動くことの重要性を強く認識していたんだな

本番環境ではLinuxカーネル上で動かすわけで、Linux上にだけ対応するという道もあったはず。
でもWindowsやMacに対応したのは、多くの開発者の開発マシンはWindowsやMacで
開発者にとってのツールであるDockerはWindowsやMacでも使えることが重要だと考えていたのだろう


上の方にいる、誰かが作ったアプリをパッケージングして配布することだけしか考えてないやつには
わからんだろうね。だから配布するならansibleで十分じゃんという発想になってしまう。
Dockerはアプリ開発者のためのツールですから

556 ：
丁寧な回答ありがとうございます
構築してみます

557 ：
何度もすいません

インストールはできてコマンドラインからも動作させることはできたんですけど
ファイルシステムやメモリの設定はどこから行えばいいんでしょうか

mac版はランチャーがあって
Preference > Daemon > Advanced にファイルシステムの設定ファイルがかけたり
Preference > Advanced からメモリの設定ができたりしたんですけど

558 ：
>>554
素直に仮想マシンを立てて、Ansibleなど構成管理ツールを使って、本番と開発環境を可能な限り揃えたほうがいいよ
Dockerはほぼどこでも動くけど、どこでも同じように動作するわけじゃないし、トラブルが発生した時の対処手順がDockerと実機サーバーや仮想マシンとでは大きく異なる
本番も開発環境もDockerで統一するなら許容範囲内だけど、それでも環境差異のリスクはあるね

559 ：
> 素直に仮想マシンを立てて、Ansibleなど構成管理ツールを使って、本番と開発環境を可能な限り揃えたほうがいいよ

それをやると問題になるのが、（Windows or Macで）ファイルを編集して
すぐにそれを反映させるのが大変になる。いちいちアップロードなんてしてられない
開発時はソースコード書いてテスト実行という流れが1分間に数回のレベルで発生する

また開発時はデバッグ用のモジュールが必要になる。
ログの表示とかデバッガの実行とか。
本番環境と揃えるのは、開発面ですごく効率が悪い
アプリ開発してない、単に配布しかしてないやつにはそれがわからない

560 ：
>>557
Windowsもタスクトレイのアイコンから設定できるだろ？
Docker Toolboxはどうなってるのかしらんが。

561 ：
>>558は（Ansibleで構成した）仮想マシンと実機環境が同じだという前提のようだが、
その理屈だと Windows or Mac 上のDockerは仮想マシンで動いてるので
Dockerが動く仮想マシンと、Dockerが動く実機マシンは同じと言える

実際の所、Dockerイメージの中に実行環境が組み込まれているので、
Dockerイメージは、LinuxカーネルとDockerにしか依存しない
Dockerイメージは同じものを使うという前提であれば、
あとはLinuxカーネルとDockerを揃えてしまえばほとんど同じ

たとえ違っていたとしても、Linuxカーネルに関しては高い互換性が
あることが今での実績から明らかで、DockerはDockerコンテナを動かすために
使っているだけで、開発したアプリがDockerに依存しているわけじゃない
なのでLinuxカーネルもDockerもバージョンが変わったところで問題はほとんど発生しない。

環境差異のリスクがあるのはDockerを使わないからなんだ

562 ：
>>559
大変にならないよ？
もしかしてアプリ開発したことないのかな

563 ：
>>561
Dockerといえど環境バグは結構あるよ
まあ仮にDocker間で100%互換性があると譲歩したところでテスト、本番が非Dockerなら開発にDockerを使うのはリスクしかない

564 ：
>>562
じゃあWindows or Macのテキストエディタで
どうやって編集するというのかな？

565 ：
>>563
本番もDocker使うに決まってるでしょｗ
っていうか、Kubernetesとか使ったことある？
Docker前提だからね。もう大規模はDocker前提の時代になってる

566 ：
WSLでvagrantを使ってる人いる？
使い心地どうですか？

567 ：
WSL上でDocker Engineが動くようになっていたっぽいという話
https://qiita.com/yanoshi/items/dcecbf117d9cbd14af87

568 ：
GKEもECS+Fargateも使える、この世の中でdocker使わない意味もないし、さすがにmanagedに対してansible使う機会は減ってきたと言わざるを得ない

569 ：
>>564
ま、それも一理あるね
addじゃなくて、volumeで割り当てれば、host側から編集できる

570 ：
コンテナは上がってるのに

docker exec -it xxxxx /bin/bash
Error: No such container: xxxxx

になったんですけど原因わかりませんか？

ymlファイルはいじってなくて

xxxxx:
image: yyyyyyyyyyyyyy
container_name: xxxxx

docker ps の結果は普通に起動してる
zzzzzzzzzzzz yyyyyyyyyy "/bin/bash" 4 days ago Up 23 minutes 0.0.0.0:nnnn->nnnn/tcp

昨日までは普通に動いてたのに
設定ファイルは色々いじったんですがコンテナに関係する部分は触ってないはずなのに…

dockerは便利だけどブラックボックスすぎて一度問題起きると自分で全く解決できないのが辛い

571 ：
よく分からんなら問題解決なんてしないでコンテナ作りなおしちゃおーぜってのがdockerの基本中の基本
根本原因を調べないと再発するのでは？って思うかもしれんけどそのたびに作りなおせば問題ないよね

572 ：
ずっと再発してたら進まないじゃん

573 ：
>>572
だから再発するまでは問題ないんだよ
「昨日までは普通に動いてたのに」ってことはコンテナを立ててからしばらくは正常に動いてるってこと
その間だけサービスを提供してダメになったら(なりそうだったら)予備のコンテナに切り替えるってわけ
コンテナ切り替えたら元のコンテナは破棄して次の予備コンテナをスタンバらせる

574 ：
原因は調べないんでしょう？
ダメじゃん…w

575 ：
dockerの構築スクリプトも定期的にメンテしないと動かなくなることあるよ

576 ：
>>570
image-idじゃなくて、container-idをｼﾃｲｼﾅｲﾄ駄目だよ

577 ：
エラーの原因はコンテナと共にバイナリの海の藻屑となる。。。
積み重なったコンテナはやがて墓場を形成し、次第に人々はこう呼ぶようになった。。。
「どっかー(行っちゃった)の墓場」と。。。

578 ：
docker for winは登録しないとダウンロードできなくなったみたいだ

579 ：
そういやWindowsコンテナってあんま話題にならないけどどうなんだろ
XP、.NET 2.0、正体不明の自社・他社COMライブラリ、Excel.Applicationなどが仕事してる古いシステム
まるごとコンテナ化して隔離できんかな

580 ：
mysqlのdatabaseごとにマウントポイントを変更したい
どうやんの？

581 ：
Docker Hubから誰でもダウンロードできるコンテナイメージに暗号通貨採掘ボットが潜んでいた
https://jp.techcrunch.com/2018/06/16/2018-06-15-tainted-crypto-mining-containers-pulled-from-docker-hub/

オフィシャルと自作しか信用できんな

582 ：
内容読む限りKubernetesクラスタとかDockerサーバのセキュリティ甘いやつ狙ってそいつらにデプロイさせてるんだと思う
まぁ自作と公式以外信頼しないのは重要だと思うけど

583 ：
Dockerってデバッグ実行の設定が面倒っすね

584 ：
virtualboxの上で直接に動いてるLinuxと
virtualboxの上にのってるVagrant上で動いてるLinux

この２つのLinuxって挙動とか変わってきたりしますか？
C言語とかシェルスクリプトのテスト環境として全く等価なんでしょうか？

585 ：
変わるわけねーだろ。仕組みを考えろや

586 ：
>Vagrant上で動いてるLinux
Vagrantは、仮想OS ではないので、Linux は、Vagrant上で動かない

「Vagrant」で検索！

587 ：
>>585
>>586
理解できました
ありがとうございます！

588 ：
>>584
インストールから設定をキッチリ揃えたわけでもなければ当然ながら等価じゃないよ
無視できる差異かどうかってとこが重要
これはDockerでも同じこと
厳密に同じ環境はどうやったって作れない

589 ：
>>588
厳密に同じ環境であるかなんて聞いてないだろ

590 ：
>>588
野良boxでなければ等価だと言ってもよいのでは？

591 ：
何をもって「挙動が同じ」「等価」とするかだよね
スクリプトでハードウェア情報取得しようとすれば環境によって変わってくるだろうし
外部のWebサイトに対して自分で書いたクローラーを実行するとかなら多分「挙動が同じ」になるだろう

592 ：
コンテナ上で仮想OSは動かないということだけど、例えば「docker pull ubuntu」で取得したubuntu動かすのと仮想マシンでubuntu動かすのとの違いが良くわからない

593 ：
>>592
dockerにとってubuntuは材料に過ぎない
ubuntuという材料をベースにDockerfileを書いてアプリを作る
そういうことが簡単にできるように作られたのがdocker

594 ：
つまりubuntuっぽい(というか見た目は変わらない)動作をするアプリが動いてるだけってことか
ありがとう

595 ：
マイナーなツールでフォアグラウンド起動のしかたがわからない場合どうする？

596 ：
フォアグラウンド起動の方法がないじゃなくて
わからないだけなら、調べろとしか

597 ：
所詮はDockerって省エネを目指した仮想環境に過ぎないからね
そんなこと気にしなければVagrantがベスト

598 ：
dockerとvagrantという全く違うものを
比較している人に言われましてもｗ

599 ：
用途がかぶる部分があるので比較する意味は有る

自転車、自動車、鉄道、飛行機は全く違うものだけど、移動するためのものという用途は同じ
旅行や通勤の際にこれらを比較する価値は大いに有る
vagrantとdockerも同様

600 ：
自動車と運転手を比較してもな。

601 ：
基本的にはファイルシステムだけカプセル化してるんだっけか？
でもportなんかもカプセル化してるし、どこまでを閉じ込めてるか結構微妙。

602 ：
>>601
アプリケーションを動かすのに必要なもののうちOS以外の部分を
アプリケーションに内包させていると考えればいい

603 ：
>>599
なにかアプリを使おうと思った時、わざわざ別マシンを用意して別の環境で動かすのが仮想マシン

今自分が使ってる環境の上でアプリを起動するのがDocker

ぜんぜん違う

604 ：
>>601
そんな抽象的で意味のない答えは求めてない。

605 ：
>>603
抽象化ができないエンジニアには難しいかも知れないが
ホストと隔離された環境でなんらかのアプリを使うという抽象的な目的は同じなんだよ
基本になってるテクノロジが違うけどそこは同じ
なので比較検討することには意味が有るわけだ

例えばローカル開発環境を構築するという抽象に対してDockerあるいはVagrantという具象が有る
もちろんそういう意味ではホストに必要なパッケージをインストールするだけの素朴な構成も比較検討に値する
完全仮想化とコンテナ仮想化は違う技術だから比較に値しないなんてのは表層しか捉えられないなにもわかってない人の発想なんだね

606 ：
技術が違うんじゃなくて、目的が違う
ここまで理解能力がないと、本当に話にならない。

607 ：
Dockerの典型的な利用例の一つは仮想マシン上でDockerコンテナを動かすこと
仮想マシンとDockerをごっちゃにしているやつはなんでそうするかを理解できない
目的が同じものなのになぜ2つのツールを同時に使うんだ？と思ってる

答えははっきりしてる。それこそ目的が違うものである証拠
Dockerを使うとアプリにそれを動かすのに必要なものがOS以外すべてバンドルされる。
それによってDockerさえ動いていれば、どこの環境にも同じDockerイメージを
持っていって使うことができる。この可搬性こそがDockerの目的

単純にVagrantを使うと特定のOS、ディストリ専用にVagrantfileを書かないといけなくなる
各OSでパッケージ名やデフォルト設定やパスなどが違ってるからだ。

そこで可搬性が高いDockerを併用すると、DockerのインストールまではOS、ディストリ依存に
なってしまうが、それ以降は全く同じ手順でDockerコンテナを起動することができる
Vagrantfileでいろいろ書く必要はないし、VagrantをAnsibleやChefと併用する必要もなくなる

もちろんVagrantを使わない環境、例えばAWSやGCPなどのクラウドでもあっても
今は直接Dockerイメージをサポートしてるのもあって、Dockerイメージを指定するだけでいい

Dockerは可搬性を高くするためのもの
仮想マシンはただのマシンでしか無いし、Vagrantは環境構築ツールでしかない
目的が全然違っている。

608 ：
>>606
目的なんて無数にあるだろ
自分が考える目的以外の目的が存在するということすら想像できないようじゃ話にならない
本当に話しにならない

609 ：
そうやって一般論でごまかすのやめーや

Dockerが考えてる目的を書いただけの話
別の目的に使おうというのなら、使いにくいのは当然だってことだ
少なくとも仮想マシンやVagrantとDockerの目的は違っている
お前の目的の話はしてない。Dockerの目的の話をしてる。

610 ：
>>607
あらら、まだわからないのか

キミの言うところのDockerの高い可搬性を利用して、例えば開発環境を構築するという目的を達成するんだよ
そして開発環境を構築するという目的を解決する手段はDockerに限らずVagrantでもローカルでも構わない
だから比較検討して目的を達成するのにはどのテクノロジを採用するのがよいかを考えるわけだ

おそらくキミの中ではDockerはこの目的に使うもの、Vagrantはこの目的に使うもの
といったようにただ一つの絶対的な目的があるんだろうな
目的を解決する手段がいくつも有ること、ツールを使う目的はいくつも有ることに気付いていない
最低限そこに気付いてくれないと話しにならないよ

611 ：
>>609
君のレスを引用すると「Dockerは可搬性を高くするもの」
これがDockerが考えている目的なわけだ(というか君の脳内のDocker社の考える目的というべきか)

じゃあ可搬性を高くしてどうするんだ？
その先の目的がまだあるだろ？
その目的は利用者が抱える課題によって様々なんだよ

612 ：
> キミの言うところのDockerの高い可搬性を利用して、例えば開発環境を構築するという目的を達成するんだよ

自分で言ってる通りじゃないかｗ
Dockerの目的は高い可搬性を作る所まで。

Dockerを利用するってことは、別に作業があるんだろ？
その作業の目的が開発環境を構築することであって
Dockerを使う目的ではない


キミ、物事の本質を捉えられるようにならないとダメだよ

613 ：
>>611
> じゃあ可搬性を高くしてどうするんだ？
> その先の目的がまだあるだろ？

その先の目的？ 金を稼ぐってことかいな？
その理屈で言えば、どんな道具も目的は同じになるなｗ

614 ：
今置かれてる状況がある
また解決したい何らかの問題がある
そして解決する手段が複数ある

ここまできて比較検討しないって言っちゃなんだけど技術者失格だろう?

非常に幸運で何らかのテクノロジ一択で業務全部をカバーできる
なんて状況でもなければ必ず比較検討が必要になる

615 ：
>>614
お前が物事の本質をわかってないだけ。

Dockerの目的は可搬性を上げるためだし、
テキストエディタの目的はテキストファイルを編集するもの

開発環境を作るために、テキストエディタを使うだろと
いくら吠えたって、テキストエディタの目的が開発環境を作ることにはならないのと
同じようにDockerの目的は開発環境の作成ではない

616 ：
>>612
>Dockerを利用するってことは、別に作業があるんだろ？
>その作業の目的が開発環境を構築することであって
>Dockerを使う目的ではない

開発環境構築は間違いなくDockerを使う目的の1つ

A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」

自然だね

A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「そんなのはDockerの目的じゃない！」

アホかこいつ

617 ：
>>613
極論すればそうだな

どんな道具にも複数の利用目的が存在する
どんな目的にも解決手段は複数有る

だから比較検討するんだよ

618 ：
>>615
道具の目的は作成者や利用者の認識によって様々
テキストエディタの主目的は確かにテキストの編集だろう
だが目的はそれだけではなく人によってことなる
"誰か"の目的を押し付けるべきではない
"おまえ"の目的が全てではない
まずはこの基本的な事実から理解してくれ
話しにならないから

619 ：
> A「なんのためにDockerを採用したの?」
> B「開発環境構築のために採用しました」

採用と目的 は意味が違う
はい論破ｗ

ジョークかよｗ
なんでこんな簡単な指摘をせにゃならんのだ

620 ：
ほんとさっきからDockerの目的を
違う話にすり替えようとしてるな。
バレバレやで

621 ：
>>619
「なんのために」って読めなかった？外国人？

622 ：
A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「開発環境構築してるのは見ればわかる。それを行うに当たって
なんのためにDockerを採用したのか聞いてるんだが？」

普通は後期着替え得される

623 ：
>>620
すり替えてるのはAn0DfPZDだな
Dockerの利用目的などいくらでもあるのに、開発目的の1つでしかない高い可搬性を唯一絶対の目的のように、こいつはすり替えようとしている

624 ：
例えて言うなら

A「なんのために○○工法を採用したの?」
B「建造物構築のために採用しました」

こう言ってるようなもん

625 ：
>>622
A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「開発環境構築してるのは見ればわかる。それを行うに当たって
なんのためにDockerを採用したのか聞いてるんだが？」

B「開発環境構築手段としてはVagrantやローカル環境へのバッチ処理適用などが候補に上がりました。
弊社の置かれる状況を踏まえて、それらを比較検討した上で、これこれこういうメリットがあると判断して、採用しました」

普通はこうなる
比較検討なんかしない、などというバカだったら採用理由にも説得力がなかっただろうね

開発環境に限った話ではないが、何かを決めるにあたって、検討した選択肢と採用した理由は関係者に対して必ず説明するものだ
業務で開発したことが有るならアタリマエのことだと思うが
もしかしてキミ仕事で開発したこと無い？あるいは一人で開発してるとか？

626 ：
>>625
> 普通はこうなる

前言撤回かよｗｗｗｗ

俺が間違いを指摘した後に慌てて後付して書くなって
ほんと恥ずかしいやつやなｗ
だいたい、その「これこれこういう」の中身が目的やろうが？

ちゃんと書けよ。Dockerを使うことで可搬性が高くなるというメリットがあるので
その目的のためにDockerを採用しましたって

627 ：
>>626
>「これこれこういう」の中身が目的やろうが？
「これこれこういう」は利用者の状況や課題によって様々
だから比較検討して答えをだすって何度もレスしとるだろうが
いい加減少しは理解してくれ
話しにならないとはまさにこのこと

628 ：
なんか話が難しくなってきましたね
ひとまず、docker軽いですよ、vagrantに比べて
buildはややかかるけど、終わってしまえば、起動もさくっといきますよ

629 ：
何に使えるかと、何のための道具かってのをごっちゃにしてるやつのたわごとだからな。
Dockerはアプリケーションを仮想化するために作られた道具

その道具を使って金儲けができるからって、
いろんなものをごっちゃにしたらダメだって話

630 ：
>>628
> ひとまず、docker軽いですよ、vagrantに比べて
vagrantは開発環境を作る道具にすぎない。
Dockerと比べるものじゃない。

比較するならば、ホストマシンでアプリを動かす vs 仮想マシンでアプリを動かすだろ
ホストマシンでアプリを直接実行するほうが、仮想マシン上でアプリを動かすよりも軽い
といわれても当たり前でしか無い

631 ：
うん、だからdockerの方が軽いんだよね？
当たり前でも何でも実際軽くて便利なんだからいいじゃないか

632 ：
そりゃ仮想マシン使うよりも仮想マシン使わないほうが軽いだろう。
仮想マシン使わないで、普通にパッケージをインストールすれば良い

普通にパッケージをインストールすればいいのに
なぜDockerを使うのか？それこそがDockerを使う目的

633 ：
課題を解決する手段が複数ある
それぞれ一長一短で状況により正解は異なる
なので比較検討してどれを採用するか決める
これITに限らず一般常識ね

634 ：
んで、今話してるのは手段ではなくて
Dockerは何をする道具かということ
本質をちゃんと見れないと道具は正しく使えない

635 ：
周回遅れだね

Dockerの特性は正しく理解した上で比較検討しようという段階の話をしてるので付いてきて

636 ：
話を逸らすな。
Dockerはアプリケーションを仮想化する道具だって話をしてる

637 ：
お気の毒ですがそのような話をしているのはあなただけです
あなたはあなたが話ていることをみんなも話ているように錯覚しているようですが実は違うのです
まずは深呼吸して冷静になってください
会話が成立することを期待して待っています

638 ：
>>637
お前、自分が一人だってわかってないのか？
誰か他に同調してくれるやついるか？

639 ：
>>638
dockerとvagrant(あるいは他の方法論)を比較するという文脈のレスは私のレス以外にも幾つもありますね
比較するのはおかしいという主張はどうやらあなただけのようですが

640 ：
docker vagrant 比較
ぐぐったらたくさん出てきた
ちなみに
docker vagrant 比較するのはおかしい
ぐぐったら”おかしい”が除外されて検索された
こりゃ勝負有ったね

641 ：
>>639
それはお前の意見に同調してるわけじゃないだろｗ
頭悪いんちゃうか？

642 ：
だいたい、さんざん仮想マシンと比較って言ってくせに
vagrantに言い換えてるし
仮想マシンとvagrantの違いもわかってないようだ

643 ：
間を取ってLXCで

644 ：
間っていうか、LXCはシステムコンテナだから、Dockerで仮想マシンのような間違った使い方を
使い方をしようとしている人は、LXCを使うべきだよ

645 ：
PythonでJupyter Notebook使ったデータ解析環境をPC変更時に新PC上で手動で再現するのが面倒だからDocker上で動かすようにしてる

646 ：
Jupyter Notebookというアプリにそのアプリを動かすのに
必要なものを全部まとめてるわけだよね。
それが正しい使い方

647 ：
そもそも再現性気にするくらいならjupyter使うのが間違ってるけどな。

648 ：
また再現性とか誰も必要だと言ってない話をし始めたｗ

649 ：
再現性が必要ない？
それはなかなか斬新ですねw
そコマで頭の悪い意見が出るとは思ってなかった。

650 ：
Jupyter Notebookって試行錯誤を効率化するのが目的なんだから、再現性なんてDockerイメージで担保すればいいというのも、それはそれでありうる判断だろう。

環境独立な再現性があればあった方がいいって点には誰も異論はないと思うが、
それよりも試行錯誤の効率性の方が優先される用途もあるってだけの話だな。

651 ：
依存性の封じ込めも再現性もvagrantや別の方法でもできるので比較検討が必要

652 ：
>>649
依存性の封じ込めも再現性もvagrantや別の方法でもできるので
Dockerを使う理由にはならないってことだよ

653 ：
複数の方法があるけど一長一短なのでツールの特性と置かれてる状況とを見て比較検討する必要があるんだね

654 ：
ずーっとってる話だが、
比較検討の話と、ツールが作られた目的を
ごっちゃにするなってことですね

655 ：
発端は>>597-599あたりかな
比較検討の意義についての議論だったのだけど、それが理解できない子も居たようだね

656 ：
比較検討するにあたって、
どの道具の目的をちゃんと理解してないと
正しい検討ができないって話やろが

657 ：
ここで聞くのが正しいかどうかわからないんですが質問です
やりたいことが2つありまして

1. Vagrantでバーチャルマシン使って開発
2. VPNでリモート環境に接続、そこにあるコンピュータにSSH

この2つは特に関係ない作業です
で、それぞれ単独では出来てるんですが

Vagrantでバーチャルマシンを立ち上げ
192.168.10.10のIPを与えて開発する（LaravelのHomesteadです）
↓
開発終えてvagrant halt（1の作業はここまで）
↓
リモート環境にVPN接続（2の作業開始）
↓
そこにあるコンピュータ192.168.10.14にSSH

としようとすると接続できない、pingも通らない、となっており解決方法を探しております
OSを再起動すると接続出来ます
macOS10.11(El Capitan)です

なにかわかる方いらっしゃいましたら、よろおねです

658 ：
Dockerって言うのを試したいのだが、
少し調べてみた限りでは、コマンドベースで各種の設定などやるようだが、
Linuxの操作に慣れていない人は使うのは難しい？

659 ：
>>658
やめといた方が方がいい。
本格的にLinuxを勉強するつもりなら話が別だが。

660 ：
>>658
Linux関係なくね？

661 ：
GUIしかやってないなら大抵の仮想化ツールは取っ付きにくいだろうな
CUIの勉強しろよ

662 ：
>>658
簡単だけどLinuxの操作などを知っているなら簡単という意味。

663 ：
ターゲットとなる本番環境じゃなくてポータブル開発環境として使ってる人います？
ローリングリリースのLinux選んでずーっとその仮想育てる感じで
PowershellもMsysもWSLもどうやっても馴染めないよう

664 ：
シェルスクリプト・PowerShell の代わりに、VSCode で、Ruby を使えば？

Windows でも、普通にファイル操作できる。
ただし、irb だけは日本語でバグるから、WSL のirb を使う

日本語では、WSL のirb は、MSYS2 よりも正常に動く

665 ：
うーん正確な用語がわからない・・

そのVSCodeとRubyの方を仮想かしてどこでも同じ使い勝手を味わいたいんだ
そっちの実作業環境を開発環境と呼ぶのは変なのかな

666 ：
docker へrdpで解決しない？

667 ：
サイトの管理を任されたけど、今 vagrant　とdockerとかで
環境構築するのが当たり前なの？
もう、MAMP XAMPでローカルに構築する時代じゃないの？？？

668 ：
vagrantは開発専用。これでサイト構築はまず無いだろ

> もう、MAMP XAMPでローカルに構築する時代じゃないの？？？
vagrantかWSLのほうがいいだろ？
実際の動作環境がLinuxなのにWindowsで環境作るほうが面倒

669 ：
Software Design 12月号の特集は、Python のAnsible

Vagrant, Chef に挑む巨人、Red Hat の猛攻が始まった！

以前は、すべての開発者は、Vagrant の作者で、今世紀最大の創業者、
Mitchell Hashimoto (HashiCorp)を避けて通ることはできないと言われていた

その常識に、赤い巨人が挑む！w

670 ：
>>667
俺の知ってる現場でもみんなvagrantだな
そういう時代なんだと思う

671 ：
VirtualBoxとVagrant　を使って開発って
WEBアプリケーション以外にも使われることはあるんですか？

例えば、スマホアプリとか。

672 ：
>>671
あるよ

673 ：
ありまぁす

674 ：
WindowsでDocker (Hyper-V)とVirtualBoxが共存可能になったってよ　

675 ：
vagrant/terraform
container linux
ansible
docker
kubernetes
Istio
gcp/aws/azure
この辺のキーワード聞くことが多くなってきたが覚えること大杉てしぬ

676 ：
クラウドでコンテナを運用するとしたら規模の小さめなサービスでもk8sが鉄板なんすか？

677 ：
Ansible使ったらshellだらけになった

678 ：
vagrantのguestosをオフライン環境でバージョンアップさせる方法教えてください

679 ：
本番運用の環境でDockerCE (Docker for Windows) の Linuxコンテナを使ってるんだけど、
たまにポートフォワードがうんとも寸とも言わなくなることがあるんだけど、そういうもん？

具体的にはNGINXのコンテナを作って外からの443をNGINXに向けるようにしてるんだけど、
突然ポートフォワード出来なくなる。TCPパケットダンプしても明らかにコンテナに流れてない。
んでDocker自身を再起動したら復帰する

運用環境としては怖すぎなんだけど・・・

680 ：
Docker は本家 Linux でも本番環境だとわりとトラブるって話を1年くらい前に聞いたな。
利用は開発環境やステージング環境までにして
本番はネイティブにした方が無難なような。

681 ：
設定ミスの可能性もあるだろう
マネージドのDocker Hostをレンタルして同じ構成で動かしてみたらどうだ

682 ：
設定ミスの可能性は無いです

683 ：
確認した?
エビデンスとったか？

684 ：
tcpdumpの結果でわりと十分なエビデンスだろう。
突然パケットが流れなくなるような設定間違いってなかなかできない。

685 ：
>>684
全く「設定ミスがない」ことのエビデンスになってない
それじゃただ単に現象を確認しただけだ

686 ：
>>685
｢『全く』設定ミスがない｣ことのエビデンスなんて現実的なコストでは提供不能だよ。
特に設定不足系は無理。
ふつうはそんな効率の悪いやり方をしない。
まあ金融・証券系みたいにコスト無視、かつ顧客が無理難題をふっかけるとこだと、顧客が納得するレベルの嘘をついて誤魔化すことはあるけどさ。

687 ：
｢Docker network stopped working ｣でググるといっぱい見つかるね。
未解決のも多い。

ttps://github.com/moby/moby/issues/32195
なんかはSolved になってるけど
・(正常なネットワークなら問題ない筈の)先進的なネットワークオプションをとにかくdisableせよ
・Docker のバージョンを上げろ
ってなってて、Docker か、あるいは利用しているネットワーク環境のどちらかに不具合があるっぽい。

688 ：
>>686
俺がなんで括弧つけたかわかってないな

「全く設定ミスがない」こと証明してないと言いたいのではない
「設定ミスがない」ことを全く証明してないと言ったのだ

689 ：
>>688
ふつうは正しく動作することをもって証明とするんだよ。
数学的な意味での証明には全くならんが、現実的なコストでできる証明ってのはそれくらいしかないんだ。

くだんの人の場合、一応正しくは動作してるのに、しばらくすると止まる、しかもtcpダンプしても止まってるんだから、
症状からしてなにか不具合がある可能性が高い。

そうじゃない、証明する方法があるんだっていうのなら、その方法を具体的に書いてやってくれ。

690 ：
>>689
もうとっくに書いてんじゃん
マネージドなdockerホスト借りてやってみたらどうだってさ

何も設定項目1つ1つ変更しながらエビデンスとれって言ってるわけじゃないんだよ
適度なサイズのスコープで切り替えながら調査していくの
これって問題調査の基本中の基本だよね？

君が言ってる現実的じゃない方法って
アルゴリズムに例えて言うと線形探索なんだよ
でも俺らは二分探索とか範囲で絞り込むアルゴリズムを知ってるわけだろ？
なんで身につけた知識を応用しないんだ？

691 ：
>>690
マネージドなDockerホストって書いてた人だったのか。
確かにそれはアリだな。

俺の言葉の使い方だとそれを設定ミスがないことのエビデンスになるとは言わないので
マネージド環境でのテストのことを指してるとは思わなかったよ。
すまんかった。

よくよく考えてみるとアホな顧客にエビデンス要求された時に
有料サービスに丸投げした結果を提供してOKもらうことはたびたびあるので
自分でも似た使い方してたなw
自分でそれがエビデンスという強い言葉に値すると思ってないから思いつかないんだなあ。

692 ：
issueだらけだもんなぁ
本番には到底耐えきれないよ
本番で使わないならってんで開発でもDockerを使わなくなる
だから実務で役に立つのはVagrantとAnsibleになる

693 ：
>>692
issueの数で判断できるなら、世の中のメジャーなライブラリやフレームワークはみな使えないことになる

694 ：
ライブラリやフレームワークに不具合があってもアプリケーションとしてのテストを通過すれば問題はない
でもDockerみたいなのになるとテストしきれないから安易に使えない

695 ：
>>694
はいキチガイ

696 ：
>>695
いや常識だぞこれ
お前はテストしとらんのか？

697 ：
>>696
ソースは？

698 ：
>>697
Rubyかな

699 ：
ansible-containerってどうなの？

700 ：
初心者なんじゃがコンテナ内のphpmyadminから別コンテナのMySQL叩くの難易度どれくらい？

701 ：
難度Fぐらいかな

702 ：
USB Type Aが一発で刺さるぐらいの難易度

703 ：
本当かぁ、？何回かネットや本のコピペしてるけどMySQLとphpmyadmin連携取れないぞ、？

704 ：
composeのサンプルコピペでいけるやろ

705 ：
>>704
この後またチャレンジするんだけど皆さん普通に連携取れて出来てるのよね？
本の丸コピが何回やっても動かないし何かMySQLの認証系が怪しいんだが

706 ：
compose見せてみ

707 ：
すまん、、そこまでまだ本を読み進めてないでんねん。。下記が本のソース丸コピなんだが
////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

708 ：
ちなみにこれも三行丸コピで動くらしいけど失敗したやつでなぁ
https://blog.thenets.org/how-to-install-mysql-and-phpmyadmin-with-docker/

709 ：
docker logsは？

710 ：
CMD["mysqld"
とりま要らんやろこの引数

711 ：
すんまへん、、何故かイケました。メモ帳に書いてコピペしてるからそう書き間違えないはずなんだがなぜかこれで
//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

712 ：
ちなみにこれはなぜか動かなかった
//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

713 ：
クラスタ運用だとボリュームの扱いが難しい

ネットワーク経由でストレージをマウントすると遅いし所有権やシンボリックリンクの取り扱いでトラブルが起きやすい
逆にローカルストレージをマウントするとコンテナを特定のホストにピン留めせざるをえなくなって運用性が悪い

どうにかならんかねこのジレンマ

714 ：
>>713
だからクラウド使うんだよ

ストレージはクラウドサービスが提供しているものを使う
ストレージ用のコンテナは作らない

715 ：
（ただし開発時にローカルで使うものは別）

716 ：
クラウドストレージでも結局は同じなのでは？
例としてS3をVolumeとしてマウントしたとして
このVolumeはローカルストレージのVolumeよりも遅いしパーミッションとかで変なトラブルが起きやすい
この性質はイントラのストレージサービスとクラウドのストレージサービスでそう違いがあるとは思えない

717 ：
S3じゃなくてEBSじゃないのか？

718 ：
>>716
だからボリュームとしてマウントしたりしない。

アプリはデータをS3に保存するし、S3から取ってくる。
パーミッションとか関係ない。クラウドのセキュリティ機能を使う
クラウドストレージの速度はローカルストレージと遜色ない（コストによるが）

719 ：
> アプリはデータをS3に保存するし、S3から取ってくる。

補足しておくとアプリはS3のデータを読み書きするとして、

例えばユーザーはファイルをサーバーにアップロードする時、
S3に直接アップロードするしS3から直接ダウンロードする。
アプリを経由してS3のファイルを読み書きしたりしない（してもいいが遅い）

誰でもアップロード・ダウンロードできてしまうことを
防ぐためのセキュリティ機能もS3にある

720 ：
>>717
EBSを使ってもいいが、アプリの仮想マシンからブロックデバイスとしてマウントはしないんだよ。
EBSをマウントするのは（広い意味での）データベース・サーバーの一台

アプリからは、そのデータベースサーバーに対してネットワークでデータを読み書きする

複数あるアプリの仮想マシンでファイルシステムをマウント（Dockerのボリューム含む）しようという発想が古い
ストレージをマウントするのは仮想マシン1台だし、そこにネットワーク経由でアクセスする。
↑このストレージをバックアップなど含めて適切に管理するのが面倒だから、クラウドストレージを使う

いずれにしろ、アプリからはネットワーク経由でデータの読み書きをする

721 ：
>>717
例として挙げただけなのでどのストレージサービスでも状況は同じ

>718
ストレージサービスをネイティヴサポートしてない他社製アプリはVolumeマウントするしかないと思うけど違うのかな？
オープンソースならフォークしてファイルアクセスを全てストレージサービスに置き換えることはできなくはないけど労力に到底見合わない
だからどうしてもVolumeマウントに頼らざるをえないケースは多々ある
そういうケースにステートフルコンテナをクラスタに組み込むにはどうするべきか悩ましい

722 ：
>>721
だからな？ 新しい仕組みを活かそうと思うなら、
設計から見直さなきゃいけないんだよ。

効率化する新しい仕組みを導入したいのですが
今までの効率の悪いやり方まま変えたくないんです。

↑アホみたいだろ？

やり方を変えないなら、今までのやり方をするしか無いんだよ。
諦めな

723 ：
>>722
設計を見直すと言われても他社製だからな…
従来のようにバックアップとリストアをしっかり整備して多少のリスクを受け入れるぐらいしか思い浮かばん
ダウンタイムはともかく直近のデータロストは怒られそうできつい

724 ：
docker hubがハックされてgitアカウントが１９万ぐらい失効されたらしい？

725 ：
それマ？

726 ：
取り急ぎググった結果出てきたものを貼ってみる

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

727 ：
dockerのGUIでの監視や起動停止とかでまだまともなのないかね？

728 ：
portainer?

729 ：
DockerってEEにするとなんか嬉しいの？

730 ：
>>729
サポート

731 ：
5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ？
VagrantfileとDockerfileのどちらが簡単かという話になるのかな？

732 ：
そりゃあVagrantだろ
変なトラブルが少ない
開発デスクトップも仮想化できる
環境の再現性がたかい
Linux+Windows混在も楽々

ただしターゲットがDockerの場合に限りローカル鯖もDockerにした方がいい
それは当然のことだな
その場合でも開発デスクトップはDockerを使わないほうがいい

733 ：
開発に使えないものを本番環境に投入とか論外なわけで
Dockerの使いどころが...
(それを言っちゃあおしまい)

734 ：
使えるか使えないかの問題じゃなく楽かどうか
本番でDockerを使わないなら本番環境はDockerへの配慮なんてしてない構成になってるはず
その構成をローカルに再現するときにDockerを使うかVagrant/Ansible使うのどっちが工数少ないかってことだ
少なくとも本番環境の構築手順書があるのだから完全仮想化環境で同等の環境を再現するのはさほど難しくない
しかしDockerだとどうしても構成の整理と手順書の読み替えと動作確認が求められてくるので面倒だ

735 ：
なるほど

736 ：
>>731
> 5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ？

何度も言ってるが、仮想マシン（Vagrant）とアプリ仮想化（Docker）は
組み合わせて使うものです！

どちらか一方を使うんじゃない。役目が違うんだから両方使う

737 ：
大前提としてな。開発環境と本番環境は同一に出来ないんだよ。
可能不可能の話じゃなくて、そんな事やるやつは馬鹿という意味で同一に出来ない

開発環境はVagrantで作るが本番環境はAnsibleなどで作る
開発環境には便利なテキストエディタやIDE、ヘッダファイル、静的解析ツール
その他便利なコマンドなど、いろんなものを入れる必要がある。


それに対して本番環境はそれらは入れない。セキュリティリスクにつながるし
メンテナンス性も考えなるべく小さなイメージにしておく


開発環境と本番環境は同一でないという前提で、
開発環境でどうやってテストするか？という話が出てくる
本番環境に近い環境でないとテストに自信が持てないのは当然

そこでDockerがでてくるんだよ。開発環境で動かすDockerコンテナと
本番環境で動かすDockerコンテナを同一に（もしくは限りなく近く）することで
開発環境と本番環境が違っていても、信頼性のあるテストが実行できる

そうするとDockerコンテナさえ同じであれば、開発環境を統一する意味もなくなる
開発環境がLinuxであってもWindowsであってもMacであっても、
同一のDockerコンテナを使うのだから、信頼性のあるテストが実行できる

だから今はVagrantを使って開発環境を統一するメリットが減ってる。
統一したいならしてもいいが（それは開発者の自由を奪うというデメリットでもある）
統一しなくても良いのが今の開発

738 ：
>>737
本番環境が全てDockerという幻想の上でしか成立しないな
本番環境がDockerでないなら開発環境でDockerを使うと逆に再現性が低下する

739 ：
最初の質問に戻るとだな

> 5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ？

「ローカル開発環境を同じにしたいならVagrantを使う」
それと同時にDockerも使う

Dockerを使うなら、ローカル開発環境を同じにする意味はさほどない
同じにしないなら Vagrantを使わなくて良い。Dockerだけ使う

これは「ローカル開発環境を同じにしたい場合にDockerが楽」と言ってるのではなくて
「ローカル開発環境を同じにしないならVagrantはいらない」という意味
だから「ローカル開発環境を同じにしたいならVagrantを使う」ということは否定していない

使う目的が違うのだから、どちらを使うか？っていう話にはならない

740 ：
漏れは、Chef

741 ：
>>738
もう今は本番環境でDockerを使うのは常識

仮に本番環境でDockerを使わないとしても、
本番環境と同じ環境をDocker以外で作るのは困難

開発環境用VM（Vagrant）と本番環境用VM（Vagrant）の
２つを作るのは重いだけ

742 ：
訂正

開発環境用VM（Vagrant）と本番環境"再現用"VM（Vagrant）の
２つを作るのは重いだけ

本番環境用VMといってしまうと、これを本番環境で使うように思えてしまうので訂正
実際の本番環境はVagrantでは作らないので、本番環境そのものにはならない
高い再現性を求めるなら、開発環境でも本番環境でもDockerを使うのがベスト

743 ：
開発環境と本番環境が違っていても
Dockerコンテナは同じですよーっていうのが
Dockerを使うメリットなわけだ

744 ：
>>741
そんな常識ないよ
あほくさ

745 ：
根拠なく、ないよとか言われてもなｗ

746 ：
>>745
お前が言うのかそれ

747 ：
kubernetesとかほぼDocker前提だし

748 ：
vagrantは "開発環境を作るためだけ" のものだが
Dockerはソフトウェ開発全般で使う

749 ：
k8sのdocker依存は解消されたって聞いてたんだけど…？

750 ：
Vagrantはこれから使われなくなっていくよ。俺はもう使ってない。
ローカル開発環境を同じにしたい場合にはたしかに便利だが、
ローカル開発環境を同じにする必要がなくなってきてる。
そういう意味ではVagrantを使わないほうが良いと言える。

751 ：
>>749
依存してなくても事実上Dockerを使うのが現時点ではベストという話

752 ：
>>748
Vagrantは本番環境でも使えるしDockerを使わない開発も未だに無数にある
Dockerのメリットは確かに大きいがそれなりのデメリットも同時に抱え込んでしまう
Dockerでやるべき明確な理由がないなら使う必要はない

753 ：
> Vagrantは本番環境でも使えるし
使えるが使わん。

754 ：
https://www.vagrantup.com/
Development Environments Made Easy
^^^^^^^^^^^^^^^^^^^^^^^^^^^

「開発環境を簡単に」と書いてあるんだから
本番環境で使おうとするな。想定外の使い方だ

755 ：
Dockerの使い方でも変なやつがいるけど
本来想定してない用途なのに、使えそうだから使おうというのは
その技術を正しく理解してない証拠なんだよな

756 ：
VagrantにできてDockerではダメな典型例だとAnsibleなど構成管理ツールの開発・テスト環境を作るときなどがあるね
当たり前だけどOSの様々な機能が制限されるコンテナは仮想マシンの代替にはなりえない

757 ：
だからVagrant（というよりVM）とDockerはどちらかを使うものじゃなくて
両方組み合わせて使うものだという話になる。

AnsibleのテストするならVMを使うのが一番。各クラウドやKVM等ね。

というかAnsibleのテストでVagrantなんて使うか？
Vagrantで作ったらVagrantユーザーがいるわけで、
それは本来のAnsible実行対象マシンとは違うものになる。

758 ：
× コンテナは仮想マシンの代替にはなりえない
○ （アプリケーション）コンテナはそもそも仮想マシンの代替として作られたものじゃない

759 ：
>>757
組み合わせて使っても良いが
常に組み合わせて使う前提のものではない

>>758
だから君のDocker万能論はちゃんちゃらおかしいということだよ
開発環境は開発対象をよく理解して適切に選ぶこと
全部DockerでOKなんてことはありえない

760 ：
あぁ、なるほど。素晴らしい気付きがあった。

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

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

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

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

（独り言）

761 ：
>>759
> だから君のDocker万能論はちゃんちゃらおかしいということだよ

何度もDockerとVMは組み合わせて使うって言ってるのに、
なんで俺のことをDocker万能論者に仕立て上げようとすんのさ？

762 ：
> 全部DockerでOKなんてことはありえない

そんなこと言ってない。

何度も何度もVMと組み合わせて使うって言ってるのに

763 ：
そうだな万能論は言いすぎた
しかしそれでも君の主張はDockerありきが前提にっているのは確かだろ
しかし実際にはAnsibleの例のようにDockerを使いにくい環境も存在している
だから君の主張がおかしいということには変わりはない

764 ：
>>763
やっぱり素でDockerを理解してないんだな・・・

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

俺はAnsibleとDockerを組み合わせて使うなんて一言も言ってない。
俺の主張？俺が何を主張したっていうんだ？

765 ：
>>764の組み合わせて使うっていうのは、

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

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


俺は、DockerでAnsibleなど構成管理ツールの開発・テスト環境を作るという使い方をしろなんて
一言も主張していない

766 ：
結局俺じゃなくてお前が

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

俺は最初から組み合わせて使う。両方使う。役割が違うと言ってる。

767 ：
>>764
君の主張は自分のレスを読み返したら？
開発環境はとにかくDocker
Dockerなしなんてありえない
それが世界の常識
君は昨日散々そう主張していたよね
そんな主張をしたら例えばAnsibleの開発環境みたいなDockerに向かない環境もDockerで組むのかなこいつはと解釈されても仕方がないよ

768 ：
>>767
お前が見返して、どこで言ってるのか指摘してくれ
俺はお前が言ってることを何一つ主張してない

769 ：
>>768
ID: XICm～のレスを読み返して

770 ：
例として一つ出すなら

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

開発環境はVagrantで作るとはっきり言っている

771 ：
>>769
だからそれをお前がやれって言ってる。
お前嘘つきじゃん。さっきからどれもコレも俺が主張してないことを
俺が言ったことにしようとしてさ

772 ：
>>770
で、そのレスの後半でDockerを使う話に持っていってるよね
とにかくDocker
Dockerありき
それが世界の常識
それが君の主張

773 ：
> で、そのレスの後半でDockerを使う話に持っていってるよね

ぽかーんｗ

スレの前半でDockerを使わない話してるよね？
お前、スレの後半しか読んでないの？
スレの後半だけで判断しちゃった？ｗ

774 ：
>>771
やれもクソも君の目の前のブラウザか専ブラかをちょっとスクロールして見るだけだよ
俺がやることなど何もなく君が自分のレスを見るだけだ
それを俺が代行してやることは物理的にできない

775 ：
>>774
それで？

776 ：
>>773
後半を主張するための前振りだろ？
だって君の主張はDockerありきが世界の常識だもんな

777 ：
>>776
何度も何度も何度もVMとDockerは組み合わせて使うと言ってる

お前が、VMとDockerはどちらか一つを排他的に使うものだって
心の底で思ってるから、俺がDockerを使うという話をすると
VMを使わないと言ってるんだって勘違いしてるんだよ。

778 ：
＞もう今は本番環境でDockerを使うのは常識
＞
＞仮に本番環境でDockerを使わないとしても、
＞本番環境と同じ環境をDocker以外で作るのは困難
＞
＞開発環境用VM（Vagrant）と本番環境用VM（Vagrant）の
＞２つを作るのは重いだけ

ほーん
Ansibleの本番環境と同じ環境もDockerで作るんだ
なんたってDocker以外で作るのは困難だからなー
それが世界の常識ってやつですかそうですか

779 ：
> Ansibleの本番環境と同じ環境もDockerで作るんだ

また俺が言ってないことを言い出した。

780 ：
>>777
VMを使わないことではなくDockerを使うことが前提になっている点がおかしいと言ってる

781 ：
>>779
言っているも同然なんだよね

782 ：
>>778
やっぱりこの辺りは反論不能なんだな

783 ：
>>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を使わないと困難だと言ってる

784 ：
>>782
何に反論すれば良いのさ？ｗ
お前の書いた嘘？

785 ：
ぬるぽ

786 ：
がっ

787 ：
そのゲームのプロセスID か何かを取得して、

OS・ディスプレイマネージャーに対して、
そのゲームを最前面に表示するように、命令できないの？

788 ：
>>787
誤爆です！

789 ：
dockerってメモリ4GB だと重いですか？docker使って仮想環境作る勉強したいんですが

790 ：
>>789
Linuxで使えば仮想マシンも不要でネイティブに動く
メモリも数MB程度のオーバーヘッドだけですむだろう

791 ：
Windows環境なんでwslでubuntuはインストールしたんですけどそのままdocker落として仮想マシン構築する事出来ます？

792 ：
Windows 10デスクトップだと4Gは厳しい
仕事で仕方なく使ってるけどメモリ不足で起動失敗が多発する
Windowsコンテナのプロセス分離だけに限定すればいけるかもしれんが…
Winコンテナは興味なくて検証したこともない

WSLでDockerは動かない
次の大型アップデートでWSL 2が実装されるけどそっちではDockerも簡単に動かせる
Docker for WSL 2のサポートも決定事項
こっちの必要スペックはわからん

793 ：
今のvirtualbox使ったwindows dockerはクソだと思うが
Docker for WSL 2 は期待していいんでないかな。

794 ：
今のDocker for WindowsはVirtualBoxなんざ使ってねぇぞ

795 ：
Docker for Windowsも、Docker for Macも
どちらも仮想マシンを使っています

796 ：
virtualbox使ってるのはdocker toolboxの方

797 ：
てか現状、hyper-vない環境のが多い訳でwinでdockerいうたらそれだよね。

798 ：
10proに入ってんじゃん

799 ：
なるほど、10pro買えと。

800 ：
wsl2のアーキテクチャ、hyper-v必須に見えるんだけどhome切り捨てか？

801 ：
はぁ、homeも対応するって発表しただろ
hyper-vのサブセットを提供するって。少しは調べろよ

802 ：
>>801
マジかサンキュー！
俺の調査完了だぜｗ

803 ：
Windows10 Home
HP ENVY Ryzen7 3700U を使用しています。

https://dotup.org/uploda/dotup.org1884129.png
BIOSの方で仮想化設定をONにして、タスクマネージャーで確認しても「仮想化 有効」に
なっているのにかかわらず、Docker Quickstart Terminal を起動すると
「仮想化がenableになっていません。」とエラーが出て終了してしまいます。
どうすれば通常通り起動できるようになるでしょうか。
どなたか心当たりある方いらしたらお教えいただけないでしょうか・・・。

804 ：
>>803
Docker Toolboxは古い
Docker Desktop for Windowsを使え

805 ：
HomeじゃHyper-V使えないし

806 ：
wsl2まで待つかwin10pro買うかどっちかを勧める。

807 ：
dockerのimageファイルをブラウザからダウンロードできるサイトないですか？

特殊なインターネット接続なし環境で構築しており，インターネット接続環境はブラウザしか起動できない状況です。

808 ：
docker pullのプロトコルはhttpやろ

809 ：
っていうか、業務に必要なことなら、必要って言えばいいだろ
仕事で苦労してる責任が管理者にあるなら管理者に責任を押し付けろや。
コストがあがったのはあんたが認めないからです。責任はあんたにありますって

810 ：
小さい組織の末端の開発者ならそれでいいかもしれん
大きな組織だと特定の開発者のコストを下げても必ずしも全体のコストが安くなるわけではない

811 ：
大きな組織だと、その判断を末端の開発者がしてはいけない。

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

上に投げつけて、上の責任にするんだよ。

812 ：
>811
理屈はわかるがそんなこと実際にするのはかなり丁寧に組織的根回ししないと無理だろ。
そんなことができるくらいならこんなとこに相談こねーわ。

813 ：
イミフ。上に言うだけやろ。こういうことで困ってますって。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

825 ：
> 蒸し返されても困る

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

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

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

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

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

827 ：
スレチ

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

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

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

830 ：
せや、せーや（笑）

831 ：
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が上手く作られていない気がしまして・・・

832 ：
WindowsでVOLUMEは鬼門・・・

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

856 ：
例えば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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

871 ：
> たとえとしては十分だ

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

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

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

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

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

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

設定も同じことだ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

887 ：
クソトメライズ？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

898 ：
何だこいつ

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

900 ：
お前のこと云ってんだよ

901 ：
言われてるぞお前くん

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

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

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

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

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

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

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

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

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

これだけ

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

これだけ

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

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

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

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

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

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

頑張れw

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

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

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

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

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

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

914 ：
新しい道具を入れたら、それだけで改善されるって思ってるバカが多いからな
新しい道具に最適になるように「やり方」を変えないと、何もかも無駄になる。

915 ：
>>912
dockerでは無理。k8sはコンテナも書き方も同じでdockerの上位互換。しかし、複雑で難易度の高め。

916 ：
普通、業務で使うならk8sだと思うが。分散や冗長化がdockerではできないからね。インストールがユーザー権限で出来るしdockerfileも使える。

完全な上位互換なんだが、代わりに手軽さは一切無いw

917 ：
そもそも無理な要件を期待してるんだから、要件の方を変えるべきだな。
Dockerでできることのほとんどは、Docker使わなくても手間が違うだけでできるわけだし。
無理だと分かってる要件を押し通そうとするのは無能。

押し通そうとしてるのが自分じゃなく上なら、そんな理不尽な職場は放棄して転職すべき。

918 ：
macOS版のDockerで、docker buildがたまにフリーズするバグの回避方法ない？
このバグのせいでテストがまともに出来なくて困ってる。
WindowsやLinuxでは発生しない。
タイムアウト仕込んでリトライさせるしか無いかな

919 ：
>>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

920 ：
いちお捕捉
working directory直下にDockerfile置いてな

921 ：
つうか本当にmac限定バグなのか
単に速度が遅いだけなのではと思った
for Macはディスクアクセスがやけに遅い気がする

922 ：
>>919
やってないけど、関係ないわ
docker clientのバグだから

923 ：
あとdocker buildのバグな

924 ：
>>921
mac限定のバグ。WindowsとLinuxでは
今まで1セット100ビルドを何十回もやっていて出てなかった

925 ：
>>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回ぐらい流してみてくれ

926 ：
>>925
それはLinux版バイナリだからうまくいくよ。
ただね、100回ビルドするだけで3分もかかるんだよ。普通なら30秒。
「1セット100ビルドを何十回もやる」ような場合はちょっと苦痛
更に言うと「Windows」でもやるのでボリュームは使いづらい
それにしてもなんでmac版だけ壊れてるかな？

927 ：
ビルド100回を何度もするってのがなんか間違いを感じるのだが。

928 ：
各ディストリ、言語やライブラリのバージョンの違いの
組み合わせでテストしてるから

929 ：
>>928
dockerってそれをしないで済ますための仕組みなんじゃ。。

930 ：
>>929
いつかhomebrewとかaptとか無くなって
全部docker上で動くようになる時代がくるといいですね^^;

931 ：
kibanaで処理したら？

932 ：
kanikoの間違い

933 ：
なんか話がおかしい。
確かにホストの方はどうにもならんことはあるだろうが、
ゲストの中身をいろいろなディストリビューションで実装する意味が分からん。

934 ：
ゲストの中身をいろいろなディストリビューションで実装するなんて言ってないぞ
いろんなディストリビューションで（Dockerを使わずに）動かすんだよ。

例えばいろんなディストリで動くバイナリを生成するコンパイラの開発

935 ：
「いろんなディストリでビルドできて正常に動くことの確認」の方がわかりやすいか？

936 ：
だったらホストは無理にmac使う必要ないんでは？

937 ：
>>936
そうだよ？だからWindowsでもLinuxでも問題なくビルドできたので
今まで気づかなかった。だけど出かける時もありノートでも作業できるようにしたいわけ

それにしてもMac版だけdocker buildがフリーズすることに誰も気づいてないのかな？

938 ：
いやクラウド環境でも社内サーバーでも勝手に使ってやりゃいいじゃん。。
macにそこまでなんでこだわるかね。。

939 ：
>>937
githubのissueで調べるか出した方が良いのでは。

windowsとmacだとk8sの不具合が認識されていて、ネットワーク割当が原因と分かっているが、2年経っても治ってない。

dockerやk8sは基本的にLinux用。
後のOSは有志中心の開発だから不具合多い、と思った方が良い。

940 ：
ただ、ビルドを何周も回して動作確認する用途は明らかに本来の用途外だからどうかな。dockerではなく、メモリなどOSのオーバーヘッドかもしれないし。

941 ：
> ただ、ビルドを何周も回して動作確認する用途は明らかに本来の用途外だから

CircleCI全否定？（笑）

942 ：
並列でビルドしているわけじゃないんだからメモリはありえないし、
Mac版のdockerサーバーは仮想マシンのLinux上で動いてるんだから
Mac版のdocker clientの問題だろうね

943 ：
マルチプラットフォームで動作保証したいならDockerは使わずに実機か仮想マシン使った方がいいと思うけどな
Dockerで動いても生ホストでの動作保証にはぜんぜんならないでしょう(逆も然り)

944 ：
>>941
自分がやる時は中で操作して、動作をメモしてCIに移植するから、何周もビルドする事は無いな。遅いし。

945 ：
>>942
繰り返しになるが、Githubで聞いてくれ。
推論を重ねても意味がない

946 ：
CIは待ち時間が入るから遅いんだよね

947 ：
Mac版Docker clientが悪いのは推論じゃなくて事実だよ

948 ：
Open Stack にも、オーケストレーションのHeat、
コンテナ・オーケストレーションのMagnum とかある

Magnumは、Docker Swarm, k8s, Apache Mesos と連携する

949 ：
>>947
必要なのは悪者探しではなく、対策でしょ。内容的にstackoverflowでも回答無いと思う。

950 ：
まあ正直ツマラン流れだったな。情報小出しでもう少しマカがファビョって
荒れると面白かったんだが。面倒になったからさっさと終わらせるわ

再現コード、十数回でフリーズすると思うが、極稀に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の問題

951 ：
対策は19.03専用の機能は使ってないのでクライアントだけ18.09を使うことにした。
バイナリ配布されてるから~/binにでも入れるだけ。
世の中がバグに気づいてなおるのを待つことにする
githubへは面倒なので、だれかやって

952 ：
volume先のゲストのhtmlファイルをホストのブラウザからlocal host 3000で接続して
htmlの内容がブラウザに表示されたまではいいんだけど
htmlを編集してもブラウザが更新されてくれない(リロードしても編集前と同じ画面）
再度npm startするとちゃんと編集後のコードで更新されているんだけど、
少しの編集でも逐一チェックしたいのでとても不便・・・どうすればブラウザでも随時更新されるようになるのかな？？
手探りで、docker build時に -no--chace=trueを付けてみても駄目だった

953 ：2019/08/29
ふぅ、せっかく荒らして遊ぼうとしてるのに邪魔しないでくれないかな
docker関係ないだろ

文字コード総合スレ Part12
Android Studio 2
sizeof(char)が必ず1でも、省略すべきではない
師匠！1週間よろしくお願いするぞ！
■特許庁新システムを作る■
【Win/Mac/Linux/Android/iOS】 Qt 総合スレ 18
小学生プログラマだけど質問ある
[RPA]PC自動化技術総合スレ[効率化] Part.7
C#, C♯, C＃相談室 Part95
将来的にPGになりたいんだが、やっぱCから？
--------------------
ライノセラスでつくりたい！　Degree4
***こんにゃく***
【日テレ】辛斤 シ写 糸冬 単戈【イ憂 月券w】
対面人狼全般★11日目
・・★　スペクター　★・・
【CB】自治会長★お役目ご苦労様でした　変なスレ・困った★ 報告処 雑談ok ★258
【池袋店舗型リフレ】キャンパリ常設スレ39【他店の荒らし禁止】
【キャリアウーマン】ブルゾンちえみ Part 2
【スパコン・スペック】「2位でもいい」次世代スパコン「富岳」の第一筐体が理研に向けて出荷[12/04]
【火を】手作りキャンドル【燈しましょ♪】
歌馬雑
長内【名門 文京学院大女】レラ
“ケンシロウ”知らないけど…ゲバラ「必ず明確な勝ち方をする」
☆サイレントテロ宣言
2019年3月開始　どんなときもWiFi part 29
日蓮ってver.50
教えてちゃんの行き先相談 10
【屁理屈名人】軍事転用可能な物質「フッ化水素」など韓国から違法輸出・フジテレビが資料入手の後、韓国政府発表[7/11]
【植村隆氏】「慰安婦」報道めぐり元朝日記者が櫻井よしこ氏らを訴えた裁判で新証拠
ﾏｳｽｺﾝﾋﾟｭｰﾀｰ 8インチタブレット WN801-BK
TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼