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

1 ：デフォルトの名無しさん：2017/02/16(木) 18:01:04.48 ID:rGWDv0Eb.net

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

よろしこ

2 ：デフォルトの名無しさん：2017/02/16(木) 19:00:08.56 ID:h1FUjbuC.net

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

3 ：デフォルトの名無しさん：2017/02/16(木) 23:15:48.11 ID:OkMHwQea.net

dockerは別に重く無いよ

4 ：デフォルトの名無しさん：2017/02/17(金) 04:13:03.89 ID:cVLy1vhF.net

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

5 ：デフォルトの名無しさん：2017/03/11(土) 20:20:37.28 ID:FzwOE8g2.net

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

6 ：デフォルトの名無しさん：2017/03/21(火) 06:14:58.73 ID:8dPbIOy5.net

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

7 ：デフォルトの名無しさん：2017/04/09(日) 21:37:56.06 ID:NCtS/3Z/.net

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 ：デフォルトの名無しさん：2017/04/10(月) 01:53:00.36 ID:gu5n9UXh.net

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

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

9 ：デフォルトの名無しさん：2017/07/08(土) 21:31:32.08 ID:8YhBgLjX.net

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

10 ：デフォルトの名無しさん：2017/07/17(月) 12:58:52.28 ID:FthSMCL/.net

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

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

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

11 ：デフォルトの名無しさん：2017/07/17(月) 13:05:03.20 ID:H+ZLTTJY.net

け

12 ：デフォルトの名無しさん：2017/07/17(月) 16:01:44.76 ID:ka/V7JjN.net

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

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

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

13 ：デフォルトの名無しさん：2017/07/17(月) 18:48:26.26 ID:GUuZ6Fu+.net

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


Docker
アプリのカプセル化

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

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

14 ：デフォルトの名無しさん：2017/07/22(土) 11:45:47.29 ID:S+qzOSdo.net

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

15 ：デフォルトの名無しさん：2017/07/22(土) 11:56:43.12 ID:0lF5kxcx.net

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

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

16 ：デフォルトの名無しさん：2017/07/22(土) 12:40:22.35 ID:S+qzOSdo.net

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

17 ：デフォルトの名無しさん：2017/07/22(土) 12:50:33.24 ID:XLPzVjfx.net

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

18 ：デフォルトの名無しさん：2017/07/22(土) 13:00:52.65 ID:S+qzOSdo.net

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

19 ：デフォルトの名無しさん：2017/07/22(土) 13:12:54.56 ID:0lF5kxcx.net

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

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

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

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

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

20 ：デフォルトの名無しさん：2017/07/22(土) 13:17:14.44 ID:S+qzOSdo.net

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

21 ：デフォルトの名無しさん：2017/07/22(土) 13:55:49.21 ID:XLPzVjfx.net

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

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

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

22 ：デフォルトの名無しさん：2017/07/22(土) 13:58:05.91 ID:XLPzVjfx.net

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

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

そうですね。

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

23 ：デフォルトの名無しさん：2017/07/22(土) 14:08:45.33 ID:S+qzOSdo.net

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

24 ：デフォルトの名無しさん：2017/07/22(土) 14:33:59.09 ID:XLPzVjfx.net

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

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

25 ：デフォルトの名無しさん：2017/07/22(土) 14:47:56.03 ID:HGcWbmUZ.net

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

26 ：デフォルトの名無しさん：2017/07/22(土) 14:54:29.83 ID:XLPzVjfx.net

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

27 ：デフォルトの名無しさん：2017/07/22(土) 20:55:04.47 ID:H9oHkZgf.net

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

28 ：デフォルトの名無しさん：2017/07/23(日) 16:06:57.33 ID:cZonGhlD.net

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

29 ：デフォルトの名無しさん：2017/07/23(日) 16:46:55.90 ID:sdBNAs2V.net

全くの別物

30 ：デフォルトの名無しさん：2017/07/27(木) 01:59:49.19 ID:RnUpnufd.net

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

31 ：デフォルトの名無しさん：2017/08/04(金) 01:35:27.22 ID:75uLMW6l.net

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

32 ：デフォルトの名無しさん：2017/08/04(金) 01:49:36.34 ID:6xnwiv0x.net

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

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

33 ：デフォルトの名無しさん：2017/08/04(金) 02:00:18.03 ID:6xnwiv0x.net

>>30
chmod 777 書けないdir

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

34 ：デフォルトの名無しさん：2017/08/04(金) 03:38:10.97 ID:75uLMW6l.net

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

35 ：デフォルトの名無しさん：2017/08/04(金) 22:21:30.72 ID:vbxnWqhH.net

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

36 ：デフォルトの名無しさん：2017/08/05(土) 01:22:27.06 ID:h+4+UPF9.net

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

37 ：デフォルトの名無しさん：2017/08/05(土) 01:34:07.68 ID:h6kT662o.net

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

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

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

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


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

38 ：デフォルトの名無しさん：2017/08/05(土) 01:44:19.24 ID:h+4+UPF9.net

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

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

39 ：デフォルトの名無しさん：2017/08/05(土) 01:52:14.76 ID:h6kT662o.net

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

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

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


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

40 ：デフォルトの名無しさん：2017/08/05(土) 08:06:56.98 ID:JaoJ8BaU.net

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

41 ：デフォルトの名無しさん：2017/08/05(土) 08:36:07.74 ID:h+4+UPF9.net

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

42 ：デフォルトの名無しさん：2017/08/05(土) 09:04:53.62 ID:P20UcjsV.net

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

43 ：デフォルトの名無しさん：2017/08/07(月) 19:54:24.01 ID:Lakck2FI.net

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

44 ：デフォルトの名無しさん：2017/08/09(水) 02:24:25.40 ID:qd4uHZWe.net

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

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

45 ：デフォルトの名無しさん：2017/08/09(水) 02:34:15.78 ID:6lirvFze.net

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

46 ：デフォルトの名無しさん：2017/08/09(水) 17:22:33.92 ID:+xT3EFIJ.net

>>31,33

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

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

47 ：デフォルトの名無しさん：2017/08/11(金) 09:39:11.19 ID:hDSZxa7t.net

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

48 ：デフォルトの名無しさん：2017/08/12(土) 13:18:10.59 ID:2oFLTBe8.net

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

49 ：デフォルトの名無しさん：2017/08/12(土) 14:19:15.99 ID:2Yw2XYfL.net

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 ：デフォルトの名無しさん：2017/08/13(日) 17:53:13.25 ID:fRo9GRp1.net

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

51 ：デフォルトの名無しさん：2017/08/15(火) 12:57:53.44 ID:HP4MqYNb.net

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

52 ：デフォルトの名無しさん：2017/08/17(木) 19:08:53.78 ID:Hre7EUXe.net

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

53 ：スレチかもだけど：2017/08/17(木) 20:32:05.78 ID:yl5Pdr7V.net

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

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

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

54 ：デフォルトの名無しさん：2017/08/17(木) 22:05:34.29 ID:B6dfKgF4.net

誰かのせいにする技術

55 ：デフォルトの名無しさん：2017/08/21(月) 19:07:05.90 ID:lYWr+wd6.net

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

56 ：デフォルトの名無しさん：2017/08/25(金) 22:22:31.90 ID:/f+10ORp.net

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

57 ：デフォルトの名無しさん：2017/08/25(金) 22:35:38.04 ID:x7mIO/g5.net

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

58 ：デフォルトの名無しさん：2017/08/25(金) 23:02:42.07 ID:/f+10ORp.net

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

59 ：デフォルトの名無しさん：2017/08/25(金) 23:22:19.30 ID:x7mIO/g5.net

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

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

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

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

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

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

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

60 ：デフォルトの名無しさん：2017/08/26(土) 08:37:04.28 ID:BVFxlozH.net

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

61 ：デフォルトの名無しさん：2017/08/26(土) 12:52:59.65 ID:6eLxh+kC.net

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

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

62 ：デフォルトの名無しさん：2017/08/27(日) 05:51:27.92 ID:rl9QFWEb.net

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

63 ：デフォルトの名無しさん：2017/08/27(日) 08:55:46.09 ID:2Uadi5zm.net

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

64 ：デフォルトの名無しさん：2017/08/27(日) 15:03:25.96 ID:sNhXAArf.net

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

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

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

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

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

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

65 ：デフォルトの名無しさん：2017/08/27(日) 16:45:51.14 ID:QpZ6CaB1.net

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

66 ：デフォルトの名無しさん：2017/08/27(日) 17:01:52.72 ID:rl9QFWEb.net

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

67 ：デフォルトの名無しさん：2017/08/27(日) 17:09:12.09 ID:QpZ6CaB1.net

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

68 ：デフォルトの名無しさん：2017/08/27(日) 17:10:33.18 ID:rl9QFWEb.net

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

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

69 ：デフォルトの名無しさん：2017/08/27(日) 17:18:30.76 ID:QpZ6CaB1.net

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

70 ：デフォルトの名無しさん：2017/08/27(日) 20:07:24.33 ID:IIGC9wQX.net

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

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

お前は

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

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

71 ：デフォルトの名無しさん：2017/08/27(日) 20:07:41.75 ID:IIGC9wQX.net

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

72 ：デフォルトの名無しさん：2017/08/27(日) 20:55:27.14 ID:AumSAEcK.net

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

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

73 ：デフォルトの名無しさん：2017/08/27(日) 21:02:37.75 ID:IIGC9wQX.net

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

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

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

74 ：デフォルトの名無しさん：2017/08/27(日) 21:39:03.20 ID:rl9QFWEb.net

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

75 ：デフォルトの名無しさん：2017/09/01(金) 20:50:15.08 ID:ocN7XlE1.net

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

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

76 ：デフォルトの名無しさん：2017/09/01(金) 22:51:41.61 ID:jfA5F5eY.net

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

77 ：デフォルトの名無しさん：2017/09/03(日) 04:17:07.76 ID:V/LSJTV5.net

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

78 ：デフォルトの名無しさん：2017/09/03(日) 06:13:15.18 ID:Xy/hIi2a.net

なるわけない

79 ：デフォルトの名無しさん：2017/09/03(日) 07:06:55.64 ID:e9mk7X/B.net

Chef 社のレシピを使えば？

80 ：デフォルトの名無しさん：2017/09/03(日) 08:05:37.08 ID:V/LSJTV5.net

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

81 ：デフォルトの名無しさん：2017/09/03(日) 08:21:04.81 ID:QlhluFUq.net

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

82 ：デフォルトの名無しさん：2017/09/03(日) 12:48:09.75 ID:e9mk7X/B.net

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

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

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

83 ：デフォルトの名無しさん：2017/09/03(日) 21:34:14.77 ID:QlhluFUq.net

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

84 ：デフォルトの名無しさん：2017/09/03(日) 23:05:16.22 ID:DIhXI1rF.net

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

85 ：デフォルトの名無しさん：2017/09/03(日) 23:06:38.28 ID:DIhXI1rF.net

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

86 ：デフォルトの名無しさん：2017/09/03(日) 23:11:54.10 ID:QlhluFUq.net

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

87 ：デフォルトの名無しさん：2017/09/03(日) 23:29:48.19 ID:DIhXI1rF.net

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

88 ：デフォルトの名無しさん：2017/09/04(月) 06:12:29.90 ID:IbU7wZyf.net

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

89 ：デフォルトの名無しさん：2017/09/04(月) 16:38:39.40 ID:dTsftoJX.net

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

90 ：デフォルトの名無しさん：2017/09/04(月) 17:53:39.35 ID:rV/jE66o.net

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

91 ：デフォルトの名無しさん：2017/09/04(月) 20:29:54.61 ID:KUepcu9z.net

>>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 ：デフォルトの名無しさん：2017/09/04(月) 20:31:41.25 ID:KUepcu9z.net

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

93 ：デフォルトの名無しさん：2017/09/04(月) 22:27:05.73 ID:rV/jE66o.net

HyperVに依存しとるとさ

94 ：デフォルトの名無しさん：2017/09/06(水) 06:40:13.96 ID:uVSfh59G.net

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

95 ：デフォルトの名無しさん：2017/09/06(水) 06:44:51.20 ID:uVSfh59G.net

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

96 ：デフォルトの名無しさん：2017/09/06(水) 07:48:48.09 ID:f+iOByXp.net

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

97 ：デフォルトの名無しさん：2017/09/11(月) 21:00:50.06 ID:zcvLuad8.net

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

98 ：デフォルトの名無しさん：2017/09/11(月) 23:44:54.91 ID:QNy5oHUR.net

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

99 ：デフォルトの名無しさん：2017/09/17(日) 19:14:50.22 ID:g8M9Yunv.net

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

100 ：デフォルトの名無しさん：2017/09/24(日) 21:52:22.92 ID:VAo7cLSP.net

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

101 ：デフォルトの名無しさん：2017/09/28(木) 19:35:59.80 ID:NUvabez2.net

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

102 ：デフォルトの名無しさん：2017/10/11(水) 12:06:18.93 ID:PBPiuL2i.net

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

103 ：デフォルトの名無しさん：2017/10/11(水) 12:12:52.55 ID:vK0AFJGc.net

ない

104 ：デフォルトの名無しさん：2017/10/11(水) 20:32:01.73 ID:M5ki5wzZ.net

DockerってGUIは動かせんの？

105 ：デフォルトの名無しさん：2017/10/11(水) 22:33:04.18 ID:E/JaLO6S.net

動かせるよ

106 ：デフォルトの名無しさん：2017/10/14(土) 15:57:55.21 ID:soixBfvL.net

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

107 ：デフォルトの名無しさん：2017/10/14(土) 17:58:36.49 ID:GDzf5CCz.net

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

108 ：デフォルトの名無しさん：2017/10/14(土) 18:31:29.09 ID:Mpk4ND/s.net

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

109 ：デフォルトの名無しさん：2017/10/14(土) 22:08:55.30 ID:YZBwJ7NO.net

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

110 ：デフォルトの名無しさん：2017/10/15(日) 09:24:22.95 ID:jiVarmiT.net

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

111 ：デフォルトの名無しさん：2017/10/15(日) 09:53:35.93 ID:/8UsyUgn.net

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

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

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

112 ：デフォルトの名無しさん：2017/10/15(日) 10:08:26.53 ID:Ad4/97ip.net

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

113 ：デフォルトの名無しさん：2017/10/15(日) 10:31:02.51 ID:jiVarmiT.net

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

114 ：デフォルトの名無しさん：2017/10/15(日) 10:47:04.11 ID:/8UsyUgn.net

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

115 ：デフォルトの名無しさん：2017/10/15(日) 10:50:45.14 ID:/8UsyUgn.net

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

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

116 ：デフォルトの名無しさん：2017/10/15(日) 10:57:19.24 ID:/8UsyUgn.net

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

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

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

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

117 ：デフォルトの名無しさん：2017/10/15(日) 11:08:18.67 ID:/8UsyUgn.net

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

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

かな？


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

118 ：デフォルトの名無しさん：2017/10/15(日) 11:14:03.69 ID:jiVarmiT.net

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

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

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

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

119 ：デフォルトの名無しさん：2017/10/15(日) 11:15:12.03 ID:jiVarmiT.net

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

120 ：デフォルトの名無しさん：2017/10/15(日) 11:22:49.81 ID:jiVarmiT.net

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

121 ：デフォルトの名無しさん：2017/10/15(日) 11:24:20.20 ID:jiVarmiT.net

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

122 ：デフォルトの名無しさん：2017/10/15(日) 11:27:36.15 ID:/8UsyUgn.net

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 ：デフォルトの名無しさん：2017/10/15(日) 11:29:17.48 ID:/8UsyUgn.net

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

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

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

124 ：デフォルトの名無しさん：2017/10/15(日) 11:30:24.71 ID:jiVarmiT.net

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

125 ：デフォルトの名無しさん：2017/10/15(日) 11:33:31.89 ID:/8UsyUgn.net

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

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

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

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

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

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

126 ：デフォルトの名無しさん：2017/10/15(日) 11:34:05.67 ID:jiVarmiT.net

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

127 ：デフォルトの名無しさん：2017/10/15(日) 11:35:26.06 ID:jiVarmiT.net

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

128 ：デフォルトの名無しさん：2017/10/15(日) 11:36:32.82 ID:jiVarmiT.net

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

129 ：デフォルトの名無しさん：2017/10/15(日) 11:36:53.92 ID:/8UsyUgn.net

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

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

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

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

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

130 ：デフォルトの名無しさん：2017/10/15(日) 11:41:46.66 ID:/8UsyUgn.net

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

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

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

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

131 ：デフォルトの名無しさん：2017/10/15(日) 11:45:54.18 ID:/8UsyUgn.net

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

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

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

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

132 ：デフォルトの名無しさん：2017/10/15(日) 11:49:59.73 ID:Ad4/97ip.net

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

133 ：デフォルトの名無しさん：2017/10/15(日) 11:51:53.70 ID:/8UsyUgn.net

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

134 ：デフォルトの名無しさん：2017/10/15(日) 11:55:03.35 ID:/8UsyUgn.net

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


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

135 ：デフォルトの名無しさん：2017/10/15(日) 11:59:36.35 ID:/8UsyUgn.net

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

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

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

136 ：デフォルトの名無しさん：2017/10/15(日) 12:00:21.34 ID:Ad4/97ip.net

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

137 ：デフォルトの名無しさん：2017/10/15(日) 12:01:19.25 ID:/8UsyUgn.net

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

138 ：デフォルトの名無しさん：2017/10/15(日) 12:11:27.93 ID:/8UsyUgn.net

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

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

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

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

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

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

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

139 ：デフォルトの名無しさん：2017/10/15(日) 12:51:15.75 ID:SUmdrC/e.net

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

140 ：デフォルトの名無しさん：2017/10/15(日) 13:48:47.99 ID:/8UsyUgn.net

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

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

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

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

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

141 ：デフォルトの名無しさん：2017/10/15(日) 14:23:35.60 ID:Ad4/97ip.net

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

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

142 ：デフォルトの名無しさん：2017/10/15(日) 14:40:41.95 ID:/8UsyUgn.net

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

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

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

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

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

143 ：デフォルトの名無しさん：2017/10/15(日) 16:06:17.00 ID:aaEJwvll.net

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

144 ：デフォルトの名無しさん：2017/10/15(日) 16:14:25.83 ID:/8UsyUgn.net

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

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

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

145 ：デフォルトの名無しさん：2017/10/15(日) 16:15:43.59 ID:/8UsyUgn.net

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

146 ：デフォルトの名無しさん：2017/10/15(日) 16:16:17.65 ID:/8UsyUgn.net

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

147 ：デフォルトの名無しさん：2017/10/15(日) 16:27:35.49 ID:SUmdrC/e.net

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

148 ：デフォルトの名無しさん：2017/10/15(日) 16:29:20.49 ID:/8UsyUgn.net

それな、DockerとAnsibleの違い

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

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

149 ：デフォルトの名無しさん：2017/10/15(日) 17:31:51.97 ID:aaEJwvll.net

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

150 ：デフォルトの名無しさん：2017/10/15(日) 17:44:48.24 ID:aaEJwvll.net

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

151 ：デフォルトの名無しさん：2017/10/15(日) 18:06:11.48 ID:HL16aayQ.net

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

152 ：デフォルトの名無しさん：2017/10/15(日) 18:19:59.49 ID:/8UsyUgn.net

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

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

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

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

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

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

153 ：デフォルトの名無しさん：2017/10/15(日) 19:00:33.44 ID:aaEJwvll.net

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

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

154 ：デフォルトの名無しさん：2017/10/15(日) 19:05:19.96 ID:aaEJwvll.net

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

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

155 ：デフォルトの名無しさん：2017/10/15(日) 19:35:47.65 ID:vM8WLXd+.net

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

156 ：デフォルトの名無しさん：2017/10/15(日) 19:37:08.37 ID:/8UsyUgn.net

>>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 ：デフォルトの名無しさん：2017/10/15(日) 19:42:08.08 ID:/8UsyUgn.net

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

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

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

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

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

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

158 ：デフォルトの名無しさん：2017/10/15(日) 20:13:25.63 ID:Ad4/97ip.net

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

159 ：デフォルトの名無しさん：2017/10/16(月) 15:59:08.48 ID:1+BaSHIB.net

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

160 ：デフォルトの名無しさん：2017/10/16(月) 20:48:46.81 ID:rY47nFh2.net

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

161 ：デフォルトの名無しさん：2017/10/16(月) 23:20:32.48 ID:t2YDIrX7.net

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

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

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

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

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

162 ：デフォルトの名無しさん：2017/10/16(月) 23:23:09.34 ID:t2YDIrX7.net

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

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

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

163 ：デフォルトの名無しさん：2017/10/17(火) 03:23:19.58 ID:IfQVHUWW.net

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

164 ：デフォルトの名無しさん：2017/10/17(火) 03:35:54.06 ID:pADXjsAY.net

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

165 ：デフォルトの名無しさん：2017/10/17(火) 04:15:27.00 ID:FGddFR9N.net

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

166 ：デフォルトの名無しさん：2017/10/17(火) 07:59:02.88 ID:7/LKBs88.net

Ansibleは奇形

167 ：デフォルトの名無しさん：2017/10/17(火) 09:37:38.20 ID:0cEpFleP.net

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

168 ：デフォルトの名無しさん：2017/10/17(火) 09:55:50.26 ID:0cEpFleP.net

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

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

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

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

169 ：デフォルトの名無しさん：2017/10/17(火) 11:59:23.93 ID:H3QSh8hS.net

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

170 ：デフォルトの名無しさん：2017/10/17(火) 22:31:09.27 ID:0cEpFleP.net

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

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

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

171 ：デフォルトの名無しさん：2017/10/17(火) 23:27:36.98 ID:YM8Fx9+d.net

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

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

172 ：デフォルトの名無しさん：2017/10/17(火) 23:32:40.82 ID:O+BDW8Aj.net

そうだPowerShellを使おう

173 ：デフォルトの名無しさん：2017/10/17(火) 23:33:06.95 ID:0cEpFleP.net

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

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

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

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


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

174 ：デフォルトの名無しさん：2017/10/17(火) 23:36:11.06 ID:YM8Fx9+d.net

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

175 ：デフォルトの名無しさん：2017/10/17(火) 23:37:48.36 ID:ivyQ9Kui.net

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

176 ：デフォルトの名無しさん：2017/10/17(火) 23:40:13.69 ID:YM8Fx9+d.net

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

177 ：デフォルトの名無しさん：2017/10/17(火) 23:42:10.74 ID:0cEpFleP.net

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

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

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

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

178 ：デフォルトの名無しさん：2017/10/17(火) 23:43:14.37 ID:0cEpFleP.net

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

179 ：デフォルトの名無しさん：2017/10/17(火) 23:43:45.13 ID:UsY1L3by.net

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

180 ：デフォルトの名無しさん：2017/10/17(火) 23:44:56.73 ID:YM8Fx9+d.net

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

181 ：デフォルトの名無しさん：2017/10/17(火) 23:45:01.14 ID:0cEpFleP.net

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

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

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

182 ：デフォルトの名無しさん：2017/10/17(火) 23:46:29.72 ID:YM8Fx9+d.net

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

183 ：デフォルトの名無しさん：2017/10/17(火) 23:46:47.23 ID:0cEpFleP.net

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

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

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

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

184 ：デフォルトの名無しさん：2017/10/17(火) 23:48:43.51 ID:EqLf+bAl.net

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

185 ：デフォルトの名無しさん：2017/10/17(火) 23:49:23.25 ID:0cEpFleP.net

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

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

186 ：デフォルトの名無しさん：2017/10/17(火) 23:51:08.93 ID:YM8Fx9+d.net

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

187 ：デフォルトの名無しさん：2017/10/17(火) 23:56:54.40 ID:0cEpFleP.net

>>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 ：デフォルトの名無しさん：2017/10/17(火) 23:58:23.86 ID:YM8Fx9+d.net

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

189 ：デフォルトの名無しさん：2017/10/18(水) 00:00:38.25 ID:HhDhJUF4.net

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

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

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

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

190 ：デフォルトの名無しさん：2017/10/18(水) 00:02:16.30 ID:5NdiYnkp.net

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

191 ：デフォルトの名無しさん：2017/10/18(水) 00:03:53.87 ID:HhDhJUF4.net

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

192 ：デフォルトの名無しさん：2017/10/18(水) 00:04:52.12 ID:GaIyCTlI.net

>>191
一生やってなさい

193 ：デフォルトの名無しさん：2017/10/18(水) 00:05:23.88 ID:HhDhJUF4.net

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

194 ：デフォルトの名無しさん：2017/10/18(水) 00:05:44.45 ID:HhDhJUF4.net

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

195 ：デフォルトの名無しさん：2017/10/18(水) 00:06:27.78 ID:J5g3uFgF.net

狂気じみてる

196 ：デフォルトの名無しさん：2017/10/18(水) 00:08:45.88 ID:GaIyCTlI.net

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

197 ：デフォルトの名無しさん：2017/10/18(水) 00:10:21.61 ID:YCPgdWPh.net

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

198 ：デフォルトの名無しさん：2017/10/18(水) 00:15:26.03 ID:HhDhJUF4.net

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

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

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

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

199 ：デフォルトの名無しさん：2017/10/18(水) 00:16:26.91 ID:HhDhJUF4.net

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

200 ：デフォルトの名無しさん：2017/10/18(水) 00:24:25.53 ID:HhDhJUF4.net

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

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

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

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

201 ：デフォルトの名無しさん：2017/10/18(水) 21:44:39.96 ID:XAtaZZJd.net

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

202 ：デフォルトの名無しさん：2017/10/18(水) 22:06:41.02 ID:HhDhJUF4.net

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

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

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

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

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

203 ：デフォルトの名無しさん：2017/10/20(金) 00:02:17.81 ID:vd2jZWHS.net

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

204 ：デフォルトの名無しさん：2017/10/20(金) 00:03:11.17 ID:gO2nGHbF.net

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

205 ：デフォルトの名無しさん：2017/10/20(金) 00:10:03.94 ID:pYxyaYmj.net

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

206 ：デフォルトの名無しさん：2017/10/20(金) 06:24:49.56 ID:l3SzA2hH.net

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

207 ：デフォルトの名無しさん：2017/10/20(金) 08:59:58.03 ID:6WjQxFol.net

全部Dockerだよ

208 ：デフォルトの名無しさん：2017/10/20(金) 09:53:29.13 ID:uOisOSsS.net

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

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

209 ：デフォルトの名無しさん：2017/10/21(土) 08:24:25.20 ID:KicYxM26.net

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

210 ：デフォルトの名無しさん：2017/10/21(土) 10:40:49.52 ID:ut7aXw9f.net

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

211 ：デフォルトの名無しさん：2017/10/21(土) 11:40:16.52 ID:Nlq4KP6d.net

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

212 ：デフォルトの名無しさん：2017/10/21(土) 12:02:43.48 ID:1eBICzfj.net

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

213 ：デフォルトの名無しさん：2017/10/21(土) 12:05:31.39 ID:Nlq4KP6d.net

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

214 ：デフォルトの名無しさん：2017/10/21(土) 12:09:01.62 ID:Nlq4KP6d.net

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

215 ：デフォルトの名無しさん：2017/10/21(土) 12:24:34.02 ID:1eBICzfj.net

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

216 ：デフォルトの名無しさん：2017/10/21(土) 12:26:15.36 ID:Nlq4KP6d.net

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

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

217 ：デフォルトの名無しさん：2017/10/21(土) 12:33:36.97 ID:zkU9oivG.net

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

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

という前提において、

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

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

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

218 ：デフォルトの名無しさん：2017/10/21(土) 12:33:57.53 ID:zkU9oivG.net

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

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

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

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

219 ：デフォルトの名無しさん：2017/10/21(土) 12:36:07.71 ID:Nlq4KP6d.net

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

220 ：デフォルトの名無しさん：2017/10/21(土) 12:38:41.42 ID:zkU9oivG.net

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

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

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

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

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

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

221 ：デフォルトの名無しさん：2017/10/21(土) 12:42:02.41 ID:mrPCTHTL.net

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

222 ：デフォルトの名無しさん：2017/10/21(土) 12:45:23.73 ID:zkU9oivG.net

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

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

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

223 ：デフォルトの名無しさん：2017/10/21(土) 12:46:35.39 ID:zkU9oivG.net

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

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

224 ：デフォルトの名無しさん：2017/10/21(土) 12:49:27.16 ID:mrPCTHTL.net

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

225 ：デフォルトの名無しさん：2017/10/21(土) 12:52:16.98 ID:zkU9oivG.net

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

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

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

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

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

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

226 ：デフォルトの名無しさん：2017/10/21(土) 12:53:44.30 ID:Lfp6S+wn.net

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

227 ：デフォルトの名無しさん：2017/10/21(土) 12:53:44.56 ID:zkU9oivG.net

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

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

228 ：デフォルトの名無しさん：2017/10/21(土) 12:59:17.59 ID:zkU9oivG.net

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

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

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

229 ：デフォルトの名無しさん：2017/10/21(土) 12:59:28.60 ID:mrPCTHTL.net

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

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

230 ：デフォルトの名無しさん：2017/10/21(土) 12:59:54.34 ID:mrPCTHTL.net

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

231 ：デフォルトの名無しさん：2017/10/21(土) 13:01:46.72 ID:hXGDex9u.net

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

232 ：デフォルトの名無しさん：2017/10/21(土) 13:02:24.19 ID:zkU9oivG.net

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

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

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

233 ：デフォルトの名無しさん：2017/10/21(土) 13:02:55.54 ID:zkU9oivG.net

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

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

234 ：デフォルトの名無しさん：2017/10/21(土) 13:03:35.60 ID:uF51TTqU.net

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

235 ：デフォルトの名無しさん：2017/10/21(土) 13:04:51.34 ID:lul59eSB.net

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

236 ：デフォルトの名無しさん：2017/10/21(土) 13:06:43.75 ID:zkU9oivG.net

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

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

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

237 ：デフォルトの名無しさん：2017/10/21(土) 13:07:37.66 ID:uF51TTqU.net

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

238 ：デフォルトの名無しさん：2017/10/21(土) 13:09:30.78 ID:zkU9oivG.net

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

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

239 ：デフォルトの名無しさん：2017/10/21(土) 13:10:45.14 ID:uF51TTqU.net

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

240 ：デフォルトの名無しさん：2017/10/21(土) 13:12:34.46 ID:zkU9oivG.net

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

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 ：デフォルトの名無しさん：2017/10/21(土) 13:13:04.58 ID:YCde4Ox3.net

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

242 ：デフォルトの名無しさん：2017/10/21(土) 13:13:53.59 ID:zkU9oivG.net

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

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

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

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

243 ：デフォルトの名無しさん：2017/10/21(土) 13:14:14.77 ID:zkU9oivG.net

>>241

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

244 ：デフォルトの名無しさん：2017/10/21(土) 13:17:10.24 ID:zkU9oivG.net

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

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

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

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

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

245 ：デフォルトの名無しさん：2017/10/21(土) 13:18:45.25 ID:uF51TTqU.net

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

246 ：デフォルトの名無しさん：2017/10/21(土) 13:21:03.22 ID:YCde4Ox3.net

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

247 ：デフォルトの名無しさん：2017/10/21(土) 13:23:50.11 ID:zkU9oivG.net

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

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

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

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

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

248 ：デフォルトの名無しさん：2017/10/21(土) 13:25:22.89 ID:zkU9oivG.net

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

249 ：デフォルトの名無しさん：2017/10/21(土) 13:41:22.32 ID:uF51TTqU.net

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

250 ：デフォルトの名無しさん：2017/10/21(土) 13:42:48.09 ID:zkU9oivG.net

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

251 ：デフォルトの名無しさん：2017/10/21(土) 13:46:47.12 ID:uF51TTqU.net

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

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

252 ：デフォルトの名無しさん：2017/10/21(土) 13:55:29.54 ID:uF51TTqU.net

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

253 ：デフォルトの名無しさん：2017/10/21(土) 14:01:47.02 ID:zkU9oivG.net

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

254 ：デフォルトの名無しさん：2017/10/21(土) 14:06:21.17 ID:uF51TTqU.net

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

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

255 ：デフォルトの名無しさん：2017/10/21(土) 14:18:41.57 ID:zkU9oivG.net

>>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 ：デフォルトの名無しさん：2017/10/21(土) 14:21:12.73 ID:zkU9oivG.net

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

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

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

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

257 ：デフォルトの名無しさん：2017/10/21(土) 14:24:16.29 ID:uF51TTqU.net

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

258 ：デフォルトの名無しさん：2017/10/21(土) 14:31:43.74 ID:zkU9oivG.net

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

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

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

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

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

259 ：デフォルトの名無しさん：2017/10/21(土) 14:33:36.33 ID:zkU9oivG.net

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

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

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

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

260 ：デフォルトの名無しさん：2017/10/21(土) 14:36:58.71 ID:zkU9oivG.net

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

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

261 ：デフォルトの名無しさん：2017/10/21(土) 21:13:10.64 ID:OISii71C.net

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

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

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

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

262 ：デフォルトの名無しさん：2017/10/21(土) 22:19:05.77 ID:01fxNEyn.net

>>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 ：デフォルトの名無しさん：2017/10/21(土) 22:21:53.51 ID:GGRodYi7.net

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

264 ：デフォルトの名無しさん：2017/10/21(土) 22:27:51.08 ID:01fxNEyn.net

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

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

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

265 ：デフォルトの名無しさん：2017/10/22(日) 00:59:52.33 ID:0M1ELFL1.net

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

266 ：デフォルトの名無しさん：2017/10/22(日) 01:00:55.77 ID:0M1ELFL1.net

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

267 ：デフォルトの名無しさん：2017/10/22(日) 01:13:03.22 ID:sDdgCD4Q.net

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

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

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

268 ：デフォルトの名無しさん：2017/10/22(日) 01:14:41.12 ID:sDdgCD4Q.net

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

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

269 ：デフォルトの名無しさん：2017/10/22(日) 01:17:06.88 ID:oq9fIgmy.net

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

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

質問の趣旨は？？

270 ：デフォルトの名無しさん：2017/10/22(日) 01:19:08.12 ID:oq9fIgmy.net

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

271 ：デフォルトの名無しさん：2017/10/22(日) 01:23:02.03 ID:sDdgCD4Q.net

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

272 ：デフォルトの名無しさん：2017/10/22(日) 01:27:52.52 ID:sDdgCD4Q.net

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

そうだよね。

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


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

273 ：デフォルトの名無しさん：2017/10/22(日) 01:29:40.83 ID:oq9fIgmy.net

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

274 ：デフォルトの名無しさん：2017/10/22(日) 01:30:08.38 ID:sDdgCD4Q.net

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

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

275 ：デフォルトの名無しさん：2017/10/22(日) 01:32:10.42 ID:oq9fIgmy.net

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

276 ：デフォルトの名無しさん：2017/10/22(日) 01:34:02.76 ID:oq9fIgmy.net

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

277 ：デフォルトの名無しさん：2017/10/22(日) 01:39:10.45 ID:sDdgCD4Q.net

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

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

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

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

278 ：デフォルトの名無しさん：2017/10/22(日) 01:42:07.34 ID:sDdgCD4Q.net

>>276

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

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

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

279 ：デフォルトの名無しさん：2017/10/22(日) 01:42:40.90 ID:oq9fIgmy.net

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

280 ：デフォルトの名無しさん：2017/10/22(日) 01:45:26.64 ID:sDdgCD4Q.net

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

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

これだけだろ

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

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

281 ：デフォルトの名無しさん：2017/10/22(日) 01:46:45.43 ID:oq9fIgmy.net

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

282 ：デフォルトの名無しさん：2017/10/22(日) 01:50:20.46 ID:oq9fIgmy.net

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

回答は>>281ね

283 ：デフォルトの名無しさん：2017/10/22(日) 01:51:34.75 ID:sDdgCD4Q.net

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

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

ほら、正確じゃない？

284 ：デフォルトの名無しさん：2017/10/22(日) 01:53:08.56 ID:oq9fIgmy.net

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

285 ：デフォルトの名無しさん：2017/10/22(日) 01:53:25.28 ID:sDdgCD4Q.net

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

それが理解できない。

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

286 ：デフォルトの名無しさん：2017/10/22(日) 01:54:37.14 ID:oq9fIgmy.net

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

287 ：デフォルトの名無しさん：2017/10/22(日) 01:54:58.86 ID:sDdgCD4Q.net

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

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

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

288 ：デフォルトの名無しさん：2017/10/22(日) 01:58:28.76 ID:oq9fIgmy.net

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

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

289 ：デフォルトの名無しさん：2017/10/22(日) 02:00:51.58 ID:sDdgCD4Q.net

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

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

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

290 ：デフォルトの名無しさん：2017/10/22(日) 02:00:53.35 ID:oq9fIgmy.net

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

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

291 ：デフォルトの名無しさん：2017/10/22(日) 02:04:02.78 ID:oq9fIgmy.net

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

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

292 ：デフォルトの名無しさん：2017/10/22(日) 02:15:02.98 ID:sDdgCD4Q.net

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

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

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

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

293 ：デフォルトの名無しさん：2017/10/22(日) 02:15:46.33 ID:sDdgCD4Q.net

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

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

294 ：デフォルトの名無しさん：2017/10/22(日) 02:21:35.35 ID:oq9fIgmy.net

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

295 ：デフォルトの名無しさん：2017/10/22(日) 02:22:31.17 ID:sDdgCD4Q.net

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

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


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


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

296 ：デフォルトの名無しさん：2017/10/22(日) 02:23:28.20 ID:sDdgCD4Q.net

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

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

297 ：デフォルトの名無しさん：2017/10/22(日) 02:27:12.80 ID:oq9fIgmy.net

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

298 ：デフォルトの名無しさん：2017/10/22(日) 02:34:15.72 ID:sDdgCD4Q.net

5ちゃんねるな。
間違えんな

299 ：デフォルトの名無しさん：2017/10/22(日) 04:16:07.34 ID:Qk9RzJFk.net

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

300 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 09:20:56.40 ID:HAzBzhoi.net

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

301 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 09:46:37.52 ID:3qPJcamy.net

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

302 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 09:58:24.68 ID:3qPJcamy.net

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

303 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 10:37:36.90 ID:JYWPd5df.net

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

304 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 12:02:17.34 ID:sDdgCD4Q.net

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

305 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 12:05:05.65 ID:sDdgCD4Q.net

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

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

306 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 12:05:10.25 ID:3qPJcamy.net

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

307 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 12:27:30.62 ID:HAzBzhoi.net

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

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

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

308 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 12:32:39.03 ID:sDdgCD4Q.net

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

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

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

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

309 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 12:36:44.25 ID:sDdgCD4Q.net

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

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

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

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

310 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 13:11:45.52 ID:WUuR/hH5.net

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

311 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 13:18:05.46 ID:sDdgCD4Q.net

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

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

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

312 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 13:32:14.70 ID:WUuR/hH5.net

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

313 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 13:33:20.73 ID:sDdgCD4Q.net

>>312

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

314 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 13:34:06.07 ID:WUuR/hH5.net

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

315 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 13:42:05.98 ID:sDdgCD4Q.net

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

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

316 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 13:59:07.78 ID:WUuR/hH5.net

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

317 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 14:38:57.87 ID:sDdgCD4Q.net

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

318 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 15:06:15.12 ID:JYWPd5df.net

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

319 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 15:09:45.98 ID:sDdgCD4Q.net

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

320 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 15:10:57.95 ID:sDdgCD4Q.net

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

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

321 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 15:18:53.39 ID:WUuR/hH5.net

幼稚

322 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 15:20:22.95 ID:sDdgCD4Q.net

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

323 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 15:21:55.05 ID:JYWPd5df.net

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

324 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 15:24:27.36 ID:sDdgCD4Q.net

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

325 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 15:26:10.75 ID:sDdgCD4Q.net

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

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

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

326 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:02:34.59 ID:JxzBgWl2.net

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

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

327 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:25:26.00 ID:sDdgCD4Q.net

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

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

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

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

> 静的な情報からスクリプトへの移行も手間無しでスムーズに行いたい
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 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:27:19.06 ID:JYWPd5df.net

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

329 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:27:50.70 ID:sDdgCD4Q.net

別に？ それぞれ1行〜数行で書ける程度

330 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:29:07.05 ID:JYWPd5df.net

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

331 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:33:25.41 ID:sDdgCD4Q.net

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

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

332 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:35:45.41 ID:JxzBgWl2.net

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

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

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

333 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:36:45.98 ID:sDdgCD4Q.net

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

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

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

334 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:40:24.57 ID:JYWPd5df.net

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

335 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:41:04.63 ID:sDdgCD4Q.net

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

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

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

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

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

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

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

336 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:41:22.04 ID:JxzBgWl2.net

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

337 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:42:13.48 ID:sDdgCD4Q.net

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

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

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

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

338 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:44:19.17 ID:sDdgCD4Q.net

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

そりゃそうだろｗ

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

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

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

339 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:45:00.82 ID:JYWPd5df.net

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

340 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:45:40.96 ID:sDdgCD4Q.net

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

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

341 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:47:41.88 ID:sDdgCD4Q.net

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

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

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

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

342 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:48:03.31 ID:JYWPd5df.net

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

343 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:50:11.92 ID:sDdgCD4Q.net

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

え？

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

344 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:51:57.39 ID:JYWPd5df.net

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

345 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:54:00.10 ID:sDdgCD4Q.net

$ 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 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:55:08.53 ID:JYWPd5df.net

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

347 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:57:38.59 ID:JYWPd5df.net

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

348 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 16:58:06.58 ID:sDdgCD4Q.net

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

349 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:00:00.38 ID:JYWPd5df.net

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

350 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:00:13.97 ID:sDdgCD4Q.net

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

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

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

351 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:02:29.22 ID:+55RNfTl.net

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

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

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

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

352 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:07:01.08 ID:sDdgCD4Q.net

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

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

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

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

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

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

353 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:16:55.75 ID:JYWPd5df.net

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

354 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:22:13.75 ID:sDdgCD4Q.net

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

355 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:28:37.91 ID:mU/kanzH.net

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

356 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:30:01.29 ID:sDdgCD4Q.net

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

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

357 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:30:54.61 ID:sDdgCD4Q.net

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

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

358 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:30:55.70 ID:mU/kanzH.net

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

359 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:34:19.94 ID:mU/kanzH.net

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

360 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:34:46.23 ID:sDdgCD4Q.net

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

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

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

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

361 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:38:08.26 ID:sDdgCD4Q.net

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

362 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:42:02.16 ID:sDdgCD4Q.net

ついこの間読んだ記事

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

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

363 ：名無しさん＠そうだ選挙に行こう！ Go to vote!：2017/10/22(日) 17:56:15.83 ID:mU/kanzH.net

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

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

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

364 ：デフォルトの名無しさん：2017/10/22(日) 20:15:57.81 ID:sDdgCD4Q.net

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

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

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

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

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

365 ：デフォルトの名無しさん：2017/10/22(日) 20:19:24.14 ID:sDdgCD4Q.net

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

366 ：デフォルトの名無しさん：2017/10/22(日) 20:38:19.65 ID:1Ll1E+vW.net

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

367 ：デフォルトの名無しさん：2017/10/22(日) 20:43:45.97 ID:sDdgCD4Q.net

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

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

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

368 ：デフォルトの名無しさん：2017/10/22(日) 20:51:08.10 ID:GMFIfZ60.net

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

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

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

369 ：デフォルトの名無しさん：2017/10/22(日) 20:54:43.66 ID:sDdgCD4Q.net

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

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

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

370 ：デフォルトの名無しさん：2017/10/22(日) 20:57:36.95 ID:sDdgCD4Q.net

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

busybox、alpine、CoreOS、Container-Optimized OS

371 ：デフォルトの名無しさん：2017/10/22(日) 21:00:16.24 ID:sDdgCD4Q.net

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

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

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

372 ：デフォルトの名無しさん：2017/10/23(月) 00:50:40.93 ID:JrZmYN5x.net

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

373 ：デフォルトの名無しさん：2017/10/23(月) 01:04:48.03 ID:JrZmYN5x.net

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

374 ：デフォルトの名無しさん：2017/10/23(月) 01:07:56.87 ID:IfXz4gcp.net

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

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

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

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

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

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

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

375 ：デフォルトの名無しさん：2017/10/23(月) 01:18:21.36 ID:IfXz4gcp.net

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

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

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

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

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

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

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

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

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

376 ：デフォルトの名無しさん：2017/10/23(月) 01:28:14.42 ID:IfXz4gcp.net

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

って言ってる時点で、

システムコンテナ（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 ：デフォルトの名無しさん：2017/10/23(月) 01:32:54.85 ID:JrZmYN5x.net

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

378 ：デフォルトの名無しさん：2017/10/23(月) 02:24:34.18 ID:IfXz4gcp.net

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

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

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

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

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

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

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

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

379 ：デフォルトの名無しさん：2017/10/23(月) 02:33:28.78 ID:IfXz4gcp.net

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

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

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

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

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

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

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

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

380 ：デフォルトの名無しさん：2017/10/23(月) 02:34:50.00 ID:JrZmYN5x.net

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

381 ：デフォルトの名無しさん：2017/10/23(月) 02:38:08.54 ID:IfXz4gcp.net

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

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

382 ：デフォルトの名無しさん：2017/10/23(月) 02:44:12.55 ID:IfXz4gcp.net

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

383 ：デフォルトの名無しさん：2017/10/23(月) 02:46:41.07 ID:IfXz4gcp.net

> 違うかい？

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

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

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

384 ：デフォルトの名無しさん：2017/10/24(火) 00:32:13.24 ID:jO+jDbIG.net

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

385 ：デフォルトの名無しさん：2017/10/24(火) 03:30:56.57 ID:DfsEXCLh.net

Docker、2016、オライリー

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

386 ：デフォルトの名無しさん：2017/10/24(火) 23:00:17.34 ID:zYnBGUyD.net

殆ど同じ内容の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 ：デフォルトの名無しさん：2017/10/24(火) 23:03:45.53 ID:hjkLVxi7.net

>>386
build-argつかえ

388 ：デフォルトの名無しさん：2017/10/24(火) 23:18:00.24 ID:zYnBGUyD.net

>>387
👍

389 ：デフォルトの名無しさん：2017/10/28(土) 09:01:01.81 ID:rZWSN5Vz.net

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

390 ：デフォルトの名無しさん：2017/10/28(土) 14:35:33.70 ID:bXFe772l.net

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

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

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

391 ：デフォルトの名無しさん：2017/10/28(土) 16:01:54.61 ID:rZWSN5Vz.net

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

392 ：デフォルトの名無しさん：2017/10/28(土) 16:44:44.72 ID:EDygjHo8.net

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

393 ：デフォルトの名無しさん：2017/10/29(日) 01:55:08.12 ID:9lQAHngl.net

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

394 ：デフォルトの名無しさん：2017/11/03(金) 10:45:37.59 ID:x2hOB9Es.net

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

395 ：デフォルトの名無しさん：2017/11/06(月) 06:20:20.30 ID:oNlJoXOO.net

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

396 ：デフォルトの名無しさん：2017/11/07(火) 00:11:44.79 ID:DNpGFSnP.net

>>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 ：デフォルトの名無しさん：2017/11/07(火) 08:18:05.50 ID:VuPHC1Hj.net

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

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

398 ：デフォルトの名無しさん：2017/11/07(火) 10:49:12.91 ID:uepCx6fG.net

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 ：デフォルトの名無しさん：2017/11/07(火) 15:43:49.52 ID:DRlk+NZ/.net

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

400 ：デフォルトの名無しさん：2017/11/08(水) 22:22:13.17 ID:9nb3Ik6J.net

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

401 ：デフォルトの名無しさん：2017/11/11(土) 12:30:00.77 ID:AwGKm55U.net

日経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 ：デフォルトの名無しさん：2017/11/12(日) 10:14:04.28 ID:j0JK3XOe.net

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

403 ：デフォルトの名無しさん：2017/11/18(土) 00:17:48.89 ID:VuzSnHPO.net

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

404 ：デフォルトの名無しさん：2017/11/18(土) 20:40:24.58 ID:DGbmO77I.net

暇な人おしえてください

物理マシンで作ったスクリプトファイルを仮想環境で実行したいんだけど
どうやってファイルを仮想ディレクトリにもっていけばいいの？
根本的にわかってないっす・・・

405 ：デフォルトの名無しさん：2017/11/18(土) 20:48:16.87 ID:DGbmO77I.net

自己解決
なるほど共有フォルダを作成すればいいのね

406 ：デフォルトの名無しさん：2017/11/21(火) 22:02:56.50 ID:Dg+h+BIQ.net

最近vagrantを始めたのですが
このソフトがやっていることってもしかして
virtualboxのCLIを叩いてるだけでは？

407 ：デフォルトの名無しさん：2017/11/21(火) 22:24:30.28 ID:H+r6aFWv.net

そうだよ
てかインフラアズコードって全部そうだよ

408 ：デフォルトの名無しさん：2017/11/22(水) 01:35:34.65 ID:8atlH8j3.net

ありがとうございます
やはりそうなんですね
そうなると、「vagrantでないと出来ないこと」は何なのかが気になります
プロビジョニング的なことでしょうか？
プロビジョニングは、
自動的にログインしてコマンドを叩くことで実現してるのでしょうか？
これはあらためて考えるとvirtualboxのCLIで出来ることを超えてる感じがします

409 ：デフォルトの名無しさん：2017/11/22(水) 02:08:02.88 ID:jSD3lLhL.net

時間さえあって自分で作るならアセンブラでできないことは何もない

○○でないとできないこと＝"時間をかけずに"△△をすること
すべてそう。時間をかけないという問題を解決してる。

> これはあらためて考えるとvirtualboxのCLIで出来ることを超えてる感じがします
virtualboxのvboxmanageコマンドでできる

410 ：デフォルトの名無しさん：2017/11/22(水) 07:30:32.21 ID:XGz0BDt0.net

>>408
vagrantはラッパだから、vagrantじゃないとできないことなどない

411 ：デフォルトの名無しさん：2017/11/22(水) 23:58:07.56 ID:jSD3lLhL.net

自転車で行けるなら、歩いていけないことはない
というのと一緒

可能・不可能の話にしてしまうと大事な点が見えなくなる
同じことをするにもコスト・時間が少ないほうが良いだろう？
それはすごく重要な事だよ

412 ：デフォルトの名無しさん：2017/11/23(木) 07:48:28.42 ID:JkIKu46w.net

oracledbの公式イメージないんか
oracleはほんま使えんなぁ

413 ：sage：2017/11/23(木) 10:23:34.07 ID:tzs9JkH9.net

privilegedモードとdocker.sock共有だとどっちか危険ですか？

414 ：デフォルトの名無しさん：2017/12/07(木) 12:39:47.34 ID:NfkoL/Di.net

docker run したときのパラメータ変えたかったら
今のコンテナからイメージつくるか、もとのイメージから、コンテナ作り直すしかないの？

415 ：デフォルトの名無しさん：2017/12/07(木) 21:24:18.91 ID:kyxQutt+.net

>>414
dockerイメージ = exeファイル
dockerコンテナ = exeファイルを実行して作ったプロセス
docker runのパラメータ = exeファイル起動時の引数

と考えればいいよ

起動時の引数を変えたいって変な話だよね
プロセスの状態を外部から変えたいならば、ファイルやネットワークやシグナル
なんかで、プロセスにメッセージを送ることになるでしょう？

416 ：デフォルトの名無しさん：2017/12/07(木) 21:39:08.94 ID:fEi0yHLk.net

entrypointのことだろ
オプションで変えれるぞ

417 ：デフォルトの名無しさん：2017/12/07(木) 21:46:47.50 ID:kyxQutt+.net

>>416
今のコンテナからイメージ作らないで
もしくは
もとのイメージからコンテナ作り直さないで

変えられるって言いたい？

418 ：デフォルトの名無しさん：2017/12/07(木) 21:47:04.44 ID:NfkoL/Di.net

>>415
１回exe起動したらずっとそのままの状態で起動しないとだめってのもおかしな話だよね
なんのために引数取れるようになってるのか考えれば、パラメータ変えて再実行なんてあり得る話
プロセスが継続してる必要はないけど、たとえばポート変えたいとかいくらでもあるだろ

コンテナが単純なexeと違うのは、内部に状態持って永続化してたりするから
まあ、コンテナ内部に永続化させたのが失敗だって話なんだろうけど

419 ：デフォルトの名無しさん：2017/12/07(木) 23:08:10.01 ID:kyxQutt+.net

>>418
だから俺は最初から、exeファイルの引数を変えて
再起動するのが普通だって言ってるだろ

再起動したくないって言ってるのは>>414
俺はそれに対して再起動しないで変えるための案を書いてる


後からやってきたお前のレスは、>>414が再起動したくないと言ってるのに対して
（再起動しないで）entrypointでオプション変えられるって言ってることになってるんだよ
だから俺は、それできんの？ってきてるんだが

ちゃんと文章読め

420 ：デフォルトの名無しさん：2017/12/07(木) 23:09:37.72 ID:kyxQutt+.net

>>418
> コンテナが単純なexeと違うのは、内部に状態持って永続化してたりするから

単純なexeだってビルドする時にソースコードに書かれた
定数やデータやリソースファイルなど、内部に状態を持って永続化するが？

421 ：デフォルトの名無しさん：2017/12/08(金) 03:08:05.72 ID:bFLhaAeC.net

>>420
実行ファイルに埋め込まれた定数やリソースを永続化という用法が一般的かどうかは知らんが
状態のまえに、実行時に変化するってつけといて
あるいは状態もって永続化じゃなくて、データファイルでもいいぞ

422 ：デフォルトの名無しさん：2017/12/08(金) 03:15:52.99 ID:cpGshdOM.net

プロセスだって実行時にメモリ書き換えるだろ
実行時に状態変化してるんだよ

423 ：デフォルトの名無しさん：2017/12/08(金) 05:39:25.87 ID:bFLhaAeC.net

メモリ書き換えるのは普通永続化されてるとは言わんわ
わざと曲解してるのかね

424 ：デフォルトの名無しさん：2017/12/08(金) 09:52:46.11 ID:cpGshdOM.net

>>423
だからdockerコンテナも同じ
基本的にコンテナは終了した後に再利用することはしない
消すのだから永続化していると考えてはいけないんだよ

425 ：デフォルトの名無しさん：2017/12/08(金) 14:21:56.65 ID:IanFvc8O.net

データベースとかリポジトリのコンテナは止めたり再開するだろ？

426 ：デフォルトの名無しさん：2017/12/08(金) 15:05:16.18 ID:Y0XUjRGM.net

まず質問に対してYesかNoで答えろよ。

427 ：デフォルトの名無しさん：2017/12/08(金) 17:43:23.33 ID:bFLhaAeC.net

>>424
だからコンテナ内部に永続化させたのが失敗だって話なんだろうって

ただ、コンテナは中断しても良いけど終了させたいわけでも消したいわけでもないぞ
たとえば　現在のコンテナの内容のまま、　 -p 80:80 から -p 8080:80 にしたいってときにどうするんだって話

428 ：デフォルトの名無しさん：2017/12/08(金) 21:44:10.36 ID:cpGshdOM.net

>>425
しない。それは使い方が間違っている。
データベースに限らないがまずアプリとデータは分離させる
アプリはコンテナ、データはボリュームに保存する。
そしてコンテナは消してもデータは残るように作るのが通常のやり方

429 ：デフォルトの名無しさん：2017/12/08(金) 21:51:28.74 ID:cpGshdOM.net

>>427
> たとえば　現在のコンテナの内容のまま、　 -p 80:80 から -p 8080:80 にしたいってときにどうするんだって話

データはコンテナの中ではなくボリュームに保存する。
だからコンテナは消しても、データはそのまま。

アプリを一旦停止して再起動しても、データはファイルに保存してるだろ。
アプリを止める　＝　コンテナを止める
データをファイルに保存　＝　データをボリュームに保存
こう変わっただけ

これこそが「仮想化」なんだよ。
もし仮にアプリが決め打ちの絶対パスで/var/hogeにデータを書き込むという仕様だとしても、
dockerコンテナに閉じ込めておけば、アプリが/var/hogeに書き込んだとしても
ボリュームを使うことでコンテナの外では好きな場所に変更することができる
仮想メモリのように、アプリから見た書き込む場所とは別の物理的な場所にリマップできる

アプリや一連のシステムを一つのコンテナにパッケージングし
そのコンテナ＝アプリのようにみると、docker runのオプションで自由にポート番号
や書き込みディレクトリを変更できるカスタムアプリが出来上がる。

430 ：デフォルトの名無しさん：2017/12/08(金) 22:29:34.36 ID:3V9S/A/h.net

ドッカスはネットワーキングがクソ
ホストのリゾルバぐらい参照せえや
なに勝手にグーグルにつないどんねん

431 ：デフォルトの名無しさん：2017/12/10(日) 11:56:05.50 ID:fCk6aJzv.net

外部ポート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 ：デフォルトの名無しさん：2017/12/12(火) 23:03:27.06 ID:YAElnGhd.net

ものすごく基本的なことかもしれませんが教えて下さい。
1つの物理マシンに、ubuntuをインストールし、色々な実験家用をdockerコンテナでインストールし、
そのマシンに複数ユーザが接続してdockerコンテナを使用する予定です。
同じコンテナを複数ユーザが使用しても大丈夫でしょうか。
それとも、元々マルチユーザのOSなのでこのような使い方こそが向いているのでしょうか。

433 ：デフォルトの名無しさん：2017/12/12(火) 23:11:29.82 ID:cVmeHUIV.net

Ubuntuはただだからなにやってもいいよｗ

434 ：デフォルトの名無しさん：2017/12/13(水) 08:51:35.45 ID:bj6sPJM2.net

>>432
実験や学習に使うならdockerじゃなくてvagrantの方がいいかな
サーバー共有する必要はないと思うのでローカルにインストールさせれば？

435 ：デフォルトの名無しさん：2017/12/13(水) 20:23:50.84 ID:4MfUhrQZ.net

CentOS7にDocker入れて、
Hass.ioというホームアシスタントのコンテナHass.ioを走らせたのですが
クライアントPCから接続できなくて困っています。
DockerとCentOSの間で外部への橋渡し設定が必要なのか
CentOSのsamba設定がまずいのか
どちらかと考えています。
前者の原因はあるでしょうか？
Dockerをアプリみたいに考えていいなら、前者は考えなくていいと思っています。

本人はDocker初心者でlinuxは数年ぶりに触っています。

436 ：デフォルトの名無しさん：2017/12/13(水) 20:27:41.39 ID:PKyEd910.net

【自然破壊】何百種類ものコンピューターは必要ない
http://lavender.5ch.net/test/read.cgi/kaden/1510387401/l50
世界教師マイトＬーヤ「大暴落は日本からスタート」
http://rio2016.5ch.net/test/read.cgi/2chse/1512813686/l50

【テレパシー】世界教師マイトＬーヤの演説『大宣言』は、１４歳以上、３つの体験、１４名の覚者を紹介
https://rosie.5ch.net/test/read.cgi/liveplus/1513126180/l50
【テレパシー】元国連職員「いきなり声が…『聞こえないフリ、分からぬフリをするな、照れをなくせ』」
http://rosie.5ch.net/test/read.cgi/liveplus/1513067436/l50

437 ：デフォルトの名無しさん：2017/12/13(水) 23:14:09.56 ID:dQY+CYRc.net

>>435
Hass.ioなんてのはしらんのでその説明と構成を言ってくれないと答えられん。
そのHass.ioはサーバーなのかHTTPかなにかで接続するのか、
samba は直接CentOS上で動かしているのか？
それともHass.ioのコンテナに含まれてるのか、別のコンテナなのか
Hass.ioとsambaはどう連携するのか
マシン構成はクライアントPCとサーバーPCの二台なのか
それともクライアントPCとHass.io用PCとsamba用PCの三台なのか

438 ：デフォルトの名無しさん：2017/12/13(水) 23:17:43.29 ID:dQY+CYRc.net

あとDocke（コンテナ）をアプリみたいに考えて良いのはそのとおりだが
何かしらのサービスを提供するアプリは、サービスを提供するための
ポート番号を設定するだろ？（デフォルトで指定されてることも多いが）
Dockerコンテナ＝アプリはそのポート番号を明示的に指定しなければいけない

439 ：435：2017/12/14(木) 00:27:35.30 ID:yKgGSsNL.net

>>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 ：デフォルトの名無しさん：2017/12/14(木) 01:14:17.99 ID:bGPtLfUR.net

>>432-434
漏れの推測だけど、

そのOS に、Docker イメージが1つだけで済む。
各ユーザーは、そのイメージからの差分だけを持てば良いから、効率的

441 ：デフォルトの名無しさん：2017/12/14(木) 06:26:27.54 ID:Cig7NI2g.net

>>435
Hass.ioとやらとsambaの連携は必要なの？
Hass.ioだけ起動して動作するか確かめよう

442 ：435：2017/12/14(木) 09:19:19.05 ID:asDNyaxD.net

>>441
あ、公式ホームページ読むと
Hass.ioでsambaとSSHが使えると書いてあるのかな。
確認してみます。

443 ：デフォルトの名無しさん：2017/12/14(木) 23:12:32.34 ID:COokNIga.net

1つのアプリケーションで複数サービス起動したい場合のベストプラクティス教えて

444 ：デフォルトの名無しさん：2017/12/15(金) 00:56:05.83 ID:L7gVN0RS.net

バッドプラクティスしたい場合の
ベストプラクティスを教えてと言われても・・・

445 ：デフォルトの名無しさん：2017/12/18(月) 19:09:18.62 ID:v15Ah6lj.net

そういう時はdindだな

446 ：デフォルトの名無しさん：2017/12/19(火) 20:09:30.02 ID:ayXhJHgO.net

ジェンキンスでイメージをレジストリにpushするところまで出来たのだけど
pushしたイメージを運用サーバーにpull & restartしてもらうにはどうすればいいの？ssh？

447 ：デフォルトの名無しさん：2017/12/23(土) 21:56:21.95 ID:AW7swrGi.net

人いねえな
日本じゃ仮想環境はまだまだマイナーなのか
大企業でもでっかい社内サーバーにあれこれ同居させてなんてことが未だにあるし
そういう文化なのかなぁ

448 ：デフォルトの名無しさん：2017/12/30(土) 21:53:24.25 ID:DzO+KqCk.net

Dockerのコンテナで開発環境として
いろんなサーバつくる上での「共通素材」が
そろったコンテナ配布していないかな。
プログラミングが学習しにくい内容として
例えばDBを学びたときに「DB内に予め素材データがたくさん詰まっていたら」
それをもとに勉強や試しに動かしやすくなる。
JavaScriptを試したいときにい予めサンプル画像や文言、
試し切り用のHTML構造がたくさん詰まっていてくれたら検証しやすくなる。
テストコードがあらかじめたくさんあったらそれに合わすような
プログラムが作りやすくなる。
開発環境は素材付きで配布するっていいアイデアじゃないか？

449 ：デフォルトの名無しさん：2017/12/30(土) 22:18:10.55 ID:fH0y6h0/.net

Dockerhubに登録すれば良いものなら評価してくてるよ

450 ：デフォルトの名無しさん：2018/01/02(火) 23:07:27.96 ID:puD6FMDA.net

これどういうこと？
Docker死ぬん？　せっかく覚えてきたのに？

Docker, Inc is Dead / Docker社は死んだ
http://itosho525.hatenablog.com/entry/2018/01/01/074358

451 ：デフォルトの名無しさん：2018/01/02(火) 23:52:33.32 ID:VBdeXUJF.net

無問題

452 ：デフォルトの名無しさん：2018/01/03(水) 00:34:25.41 ID:hbEuYwsD.net

>>448
素材データはあちこちでいろんな形で配布してるから実情にあったのを自分で選ぶべきだな

R程度の軽いデータ付属してても問題ないけど重量級のデータが詰まってるのなんて邪魔でしかない

453 ：デフォルトの名無しさん：2018/01/03(水) 11:07:28.11 ID:76Iu3Ukp.net

ねーよ

454 ：デフォルトの名無しさん：2018/01/03(水) 11:33:44.26 ID:FghAOgO2.net

DockerはMSに買収された方がいい方向に進むだろうね

455 ：デフォルトの名無しさん：2018/01/04(木) 00:14:34.87 ID:Db2jLLtK.net

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 ：デフォルトの名無しさん：2018/01/06(土) 08:40:25.60 ID:J/6p70u2.net

dockerでデスクトップ環境とスマホエミュレーター作れる？

457 ：デフォルトの名無しさん：2018/01/06(土) 14:49:48.45 ID:qWm4dftC.net

まーたdockerが何か分かってない奴の質問か

dockerはカスタマイズされたアプリを作るものであって
環境を作るものじゃないんだよ

ここにアプリが有るじゃろ？から始まって
このアプリを動かすにはこのライブラリが必要で
こういう設定ファイルが必要じゃろ？
それらのアプリとそのアプリを動かす環境を
合体させてアプリを作るんだよ

だからデスクトプアプリは作れても
デスクトップ環境はそのそもdockerで作るものじゃない
スマホエミュレータはアプリなんだから作れるだろう

458 ：デフォルトの名無しさん：2018/01/06(土) 15:08:44.43 ID:J/6p70u2.net

クリーンなビルド環境としてのdockerなど、当たり前のように環境として使われてるが?

459 ：デフォルトの名無しさん：2018/01/06(土) 15:57:41.40 ID:qWm4dftC.net

>>458
それはクリーンな環境を作ってるのではなく
作っているのはあくまでビルド生成物
その途中がクリーンな環境になっているってだけの話だな

460 ：デフォルトの名無しさん：2018/01/06(土) 17:02:13.94 ID:J/6p70u2.net

>>459
大丈夫か? あんま無理すんなよ
「その途中がクリーンな環境になっている」の環境はまさにdockerで作ってるんだぞ?

461 ：デフォルトの名無しさん：2018/01/06(土) 17:09:31.21 ID:RuMnMvof.net

ビルド環境だけじゃなくテストを走らせる環境もDockerで作る
Travis CIとか使ったことないんじゃ

462 ：デフォルトの名無しさん：2018/01/07(日) 13:48:14.13 ID:FrONFwW6.net

固定概念でdockerの可能性を絞るのは宜しくないね

463 ：デフォルトの名無しさん：2018/01/07(日) 14:07:30.44 .net

それぞれ
・ビルド生成物を作成するアプリ
・テスト結果を作成するアプリ
だと言いたいんだろう

ていうか、彼の世界観でスマホエミュレータがOKなんだったら
Linuxデスクトップ環境エミュレータだってOKなんだけどなw

464 ：デフォルトの名無しさん：2018/01/07(日) 14:39:34.25 ID:esrWpXaw.net

スマホのエミュレータは、ハードウェアをエミュレートしているアプリを
作るところまでがdockerでやる部分でスマホの環境を作ってるのは
スマホに入れたOSが作ってるものだからね

465 ：デフォルトの名無しさん：2018/01/07(日) 14:52:52.70 ID:yGtHkQv/.net

開発環境を仮想化したいがVagrant+VirtualBoxは重いんだよな

466 ：デフォルトの名無しさん：2018/01/07(日) 15:01:39.57 .net

>>465
you, windows 10にしちゃいなyo!

467 ：デフォルトの名無しさん：2018/01/14(日) 23:05:40.01 ID:ir5vm7iB.net

>>465
/vagrant/ 共有フォルダ下に
プロジェクトのソース、DBディレクトリなど開発環境置いて
ホストマシンから編集すれば万事解決

468 ：デフォルトの名無しさん：2018/01/18(木) 23:50:29.04 ID:XSFRYjak.net

コンテナ内でandroidエミュをヘッドレス起動 OK
エミュブート待機 OK
コンテナ内でadb tcpip 5555 OK
ポートフォワーディング5555:5555 OK
コンテナ内でadb connect localhost:5555 OK
コンテナ外からadb connect localhost:5555 繋がらない

なんでやねん😭

469 ：デフォルトの名無しさん：2018/01/19(金) 00:08:57.82 ID:acEC53C4.net

外から接続できない設定になってるだけだろ

470 ：デフォルトの名無しさん：2018/01/20(土) 17:54:53.60 ID:02tJQvIi.net

dockerの参考書でできるだけ新しく内容が濃いものはどれ？
ネット検索で断片的な情報を集めるのに疲れた

471 ：デフォルトの名無しさん：2018/01/20(土) 18:29:02.75 ID:cgUM+b3j.net

>>470
https://docs.docker.com/engine/reference/builder/

472 ：デフォルトの名無しさん：2018/01/23(火) 13:18:24.35 ID:CDVCaOOu.net

環境構築には、vagrant, chef は、Ruby でレシピ(手順書)を書ける。
Docker もある

仮想環境コンテナ総合スレ Docker、Vagrant等 [無断転載禁止]c2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1487235664/l50

473 ：472：2018/01/23(火) 13:19:10.42 ID:CDVCaOOu.net

472 は、誤爆

474 ：デフォルトの名無しさん：2018/03/07(水) 11:05:45.94 ID:r+VXWfNv.net

ansible絶対殺すおじさんは最近あばれてないの？

475 ：デフォルトの名無しさん：2018/03/15(木) 23:36:12.82 ID:rmXeLovx.net

>>474
暴れてますよ。

476 ：デフォルトの名無しさん：2018/03/24(土) 08:58:04.53 ID:9NxgdLlD.net

ubuntuコンテナにRDP接続したいのですがどうすればいいですか？
Xウィンドウ？とかいうのを使うらしいのですがよくわかりません

477 ：デフォルトの名無しさん：2018/04/20(金) 13:09:59.38 ID:6bRMLqam.net

プロフェッショナルの方、どなたか教えてください(/ω＼)

今、下記内容のdockerimageを作成したいと思っています。
　
　�@　ベースのイメージ：jupyter/datascience-notebook
　�A　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 ：デフォルトの名無しさん：2018/04/25(水) 15:11:44.49 ID:yjbc7H4K.net

質問が続いて申し訳ありません。
もう本当の初心者の初心者で、これからローカル開発環境を構築しようというところで、
Vagrantの初期化に失敗し途方に暮れております。
海外サイト含めいろいろググりましたし、パスやユーザー名の問題もないと思います。
Invalid argument @ dir_s_mkdir - C:/Users/(user)/MyVagrant/MyCentOS/?vagrant_home (Errno::EINVAL)
と出て、初期化（Vagrantfileの作成）に失敗します。

どなたか助けてください・・

479 ：デフォルトの名無しさん：2018/04/25(水) 15:29:10.25 ID:YkxuvCe9.net

>>478
mac買ったらいーよ
私はubuntuユーザーです。
winは色々大変

480 ：デフォルトの名無しさん：2018/05/02(水) 06:04:27.72 ID:hUDFoTxj.net

DockerでLet's encrpt使えますか？

481 ：デフォルトの名無しさん：2018/05/23(水) 19:43:15.85 ID:Au5e7VGg.net

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

AUPZD

482 ：デフォルトの名無しさん：2018/05/24(木) 10:54:24.16 ID:cPlRxlDn.net

AUPZD

483 ：デフォルトの名無しさん：2018/06/12(火) 19:37:05.64 ID:X3Ns4c46.net

windows 10 メモリ4GでDocker動かすテクニック知らん？
こいつリソース食い過ぎなんだけど

484 ：デフォルトの名無しさん：2018/06/12(火) 23:47:07.15 ID:nNHaoP16.net

メインマシンが4GBだったら軽蔑する

485 ：デフォルトの名無しさん：2018/06/13(水) 14:37:25.86 ID:oqJxCeYC.net

メモリ4Gなんて１５年前の標準PCじゃん

486 ：デフォルトの名無しさん：2018/06/13(水) 19:07:24.99 .net

32GBでようやく標準装備といえる

487 ：デフォルトの名無しさん：2018/06/13(水) 19:14:19.13 ID:Jt1XfQ9I.net

>>483
DockerはWindowsとLinuxではLinux仮想マシンを使う
だから設定から仮想マシンに割り当てるメモリを変更すれば良い

WSLのLinux互換機能が高くなれば、仮想マシン使わずに
ネイティブに動くのにな。まだかなー

488 ：デフォルトの名無しさん：2018/06/13(水) 19:22:53.70 ID:MfFyOg3y.net

>>486
おいおいスパコンかよ

489 ：デフォルトの名無しさん：2018/06/13(水) 19:38:30.68 ID:Jt1XfQ9I.net

>>488
スパコンの定義は1.5TFLOPS以上から50TFLOPS以上に変わったらしいで

https://ja.wikipedia.org/wiki/FLOPS
1.5TFLOPSとか発売当時で今なら中古で1万？ぐらいの
GeForce GTX 580で超えるからな

490 ：デフォルトの名無しさん：2018/06/13(水) 19:47:51.58 ID:uyjgxa7r.net

DockerとVagrant両方使ったが、覚えることはVagrantのほうが少ないな
軽さではDockerかな

491 ：デフォルトの名無しさん：2018/06/13(水) 20:05:47.54 ID:MfFyOg3y.net

コンテナ起動した後に初期化スクリプト走るタイプのコンテナが使いにくいんだがどうにかならんのあれ

oracledbコンテナ起動
クエリ通るまでポーリング
スキーマ構築
固定のマスタデータ投入
テスト用のトランザクションデータ投入
UI テスト開始

CIサーバーでテスト開始するまでが長すぎてもったいないと思った
初期データまで込みでイメージにしたい

492 ：デフォルトの名無しさん：2018/06/13(水) 20:22:25.46 ID:Jt1XfQ9I.net

>>491
それは初期化スクリプトが問題なのではなく
データベースサーバーが起動するまで待っているから
データ込みにしてようが結局データベースサーバーが起動するまで待つ

493 ：デフォルトの名無しさん：2018/06/24(日) 10:53:45.00 ID:B69th+8G.net

仮想サーバーがイメージつかめないんだよな
そもそも、vagrantって言葉の意味もわからんしな

494 ：デフォルトの名無しさん：2018/06/24(日) 10:54:03.25 ID:B69th+8G.net

ジェム、ユムとか意味わからん

495 ：デフォルトの名無しさん：2018/06/24(日) 13:03:06.51 ID:/Ut2/nFL.net

Vagrant重すぎ

496 ：デフォルトの名無しさん：2018/06/24(日) 14:01:24.14 ID:bQQqGsfl.net

>>495
スペック

497 ：デフォルトの名無しさん：2018/06/25(月) 00:35:12.17 ID:coa4kaO9.net

>>496
20代独身172cm65kg
石原さとみがタイプだが嫁にはしたくないタイプだな
料理下手そう

498 ：デフォルトの名無しさん：2018/06/28(木) 22:59:23.81 ID:bysnBXSn.net

>>496
Core i5、メモリ4GB
メモリ不足かな？

499 ：デフォルトの名無しさん：2018/06/28(木) 23:56:34.54 ID:N70xoCCv.net

メモリ4GBって10年前から時が止まってんのか

500 ：デフォルトの名無しさん：2018/06/29(金) 07:00:02.38 ID:fLw6tHLK.net

業務系はどこもこんなもんだよ
経営者がITよくわかってないから設備投資には消極的
エクセルとエディタが動けば開発できるだろ贅沢言うな経費削減だって本気で考える

501 ：デフォルトの名無しさん：2018/06/29(金) 17:50:31.79 ID:rf9SvDm4.net

金無いんだから仕方ないだろ
そんなこと言うなら俺にパソコン買ってくれ

502 ：デフォルトの名無しさん：2018/06/29(金) 18:26:52.80 ID:fLw6tHLK.net

アマゾンからインスタンス借りれば？
端末買うよりは安いでしょ

503 ：デフォルトの名無しさん：2018/06/29(金) 19:06:08.95 ID:KCXh18yp.net

Dockerを使っていてもAnsibleのような仕組みはやっぱり必要なんだな
コンテナを起動した後に起動をポーリング待ちして初期設定処理を動かさなきゃならんコンテナが多すぎる
リポジトリからコードcloneしてupすればローカル開発環境のセットアップ完了なんてのは儚い夢だった

504 ：デフォルトの名無しさん：2018/06/29(金) 20:38:57.27 ID:ISSgYOxU.net

Ansibleのようなでかい仕組みはいらないけどね。
シェルスクリプトもしくはシェルスクリプトベースのなにかで良い

あと「ローカル開発環境」の定義がきれいに定まってない気がする。
おそらく、IDEやテキストエディタを含めたものを言ってるのだろうけど
分けて考えないといけないと思う

1. ソースコードを作成する環境
2. 開発したアプリを動かす環境
3. 実行するサーバー相当の環境

505 ：デフォルトの名無しさん：2018/06/29(金) 22:10:23.96 ID:KCXh18yp.net

まあansでもshでもいいけど何れにせよサービス起動前とサービス起動後の設定を一元化して管理したい場合にはDockerは致命的に使いにくいってこと

506 ：デフォルトの名無しさん：2018/06/30(土) 02:41:09.28 ID:UBF/c/En.net

>>505
それは典型的なDockerの使い方の間違いだよ
間違ってるので、何を想定してるのかよくわからない
設定を一元管理？なんの話だそれは

正しいDockerの使い方はアプリとその実行環境を固めたアプリ・サービスを作ること
及び設定内容を埋め込むことで起動するだけで動くアプリ・サービスを作る

1. 新しく物理・仮想サーバーを用意して、
2. 環境ごとのサーバーの設定を行って、
3. アプリ・サービスを動かすのに必要な環境を用意して（必要ライブラリのインストールなど）
4. アプリ・サービスをインストールして
5. アプリ・サービスの設定を行って
6. 環境構築を完成させる

よりも

1. 新しく物理・仮想サーバーを用意して、
2. 環境ごとのサーバー設定を行って、
3. アプリ・サービスをDocker経由でインストール・起動して
4. 環境構築を完成させる

この方が楽でしょ？

特に一つのマシンで複数のアプリ・サービスを動かそうとしたとき、
そのアプリ・サービス毎に必要な環境が異なっていたら大変になる
それぞれが必要なライブラリのバージョンが異なっていて動かないとかね

507 ：デフォルトの名無しさん：2018/06/30(土) 03:33:31.86 ID:izzLzYRX.net

DockerもVagrantもcronが絡むと途端に使えなくなるな
仮想コンテナ系の限界だな

508 ：デフォルトの名無しさん：2018/06/30(土) 04:26:22.48 ID:M0wFt4mj.net

>>503
あの、出来てますよ、それ
初期化待ちって、Dbの構築とかですか？

509 ：デフォルトの名無しさん：2018/06/30(土) 04:29:06.89 ID:M0wFt4mj.net

cronも良く分からないが、使う？
動作確認だけなら、cronで叩く処理を動かせば良いような

510 ：デフォルトの名無しさん：2018/06/30(土) 06:32:44.17 ID:UBF/c/En.net

>>507
普通にcronからDockerコンテナ化した
プログラム実行するだけじゃん
何が使えないの？
使い方が間違ってるだけじゃないの？

511 ：デフォルトの名無しさん：2018/06/30(土) 09:08:24.15 ID:EEI2bAzw.net

>>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 ：デフォルトの名無しさん：2018/06/30(土) 09:32:43.17 ID:EEI2bAzw.net

>>508
うん、主にDB
DBに設定データを保存するパターンのアプリも必然的に同じ状況になる

もちろん自分が作ってるアプリの設定ならDBの初期化スクリプトに追記すればいいと思う
postgresなどは親切にもオフィシャルでスキーマ初期化の機構が用意されてる(oracle公式はなかったけど)

でも他人が作ったアプリではそうもいかない
DBの初期化スクリプトで初期設定データを挿入することはできるだろうけど、なにを入れればいいのかがわからない
手動で設定した後にDBを分析して、入れるべきデータを調べることはできるけど、手間がかかりすぎる
それにアプリが実行してる初期化に割り込んでデータを挿入するというのは行儀が悪い
なのでアプリが起動した後、アプリが用意したインターフェースで設定を行うことになる
管理用のREST APIが整備されてるならそれ、ブラウザでしか動かせないならSelenium、といった具合
docker execでコンテナに入ってコマンドで設定というパターンもあるけど(railsアプリに多い気がする)、設定のためだけに普段使わないフレームワークを覚える気はしない

513 ：デフォルトの名無しさん：2018/06/30(土) 11:28:30.25 ID:sCpaaE3u.net

ドッカーはウェブアプリ専用
基本中の基本やろがい

514 ：デフォルトの名無しさん：2018/06/30(土) 15:23:37.26 ID:UBF/c/En.net

>>511
> ってのは1はともかく2〜5はAnsibleだけで一元管理できる
一人でプログラム作ってんのか？

アプリを動かすのに必要な、OSの環境、入れて置かなければいけないパッケージ
その他必要なライブラリはなんなのか？
それをアプリを作ってない人が把握するのは大変だよね？

それらのバージョンはアプリの開発やセキュリティパッチなどで日々変わっていく
そのたびにAnsibleをメンテナンスするのは大変
物理・仮想サーバーのAnsible構成と一体化してるから、
ローカルで動かしてみるのも大変

サーバーの環境設定と、アプリの実行環境構築は別々の作業で別々の人がやる
アプリを開発してる人は自分の責任でアプリを実行できる環境を用意しないといけない。

サーバーの設定を行ってる人（Ansibleの設定書いてる人）に、
あ、これこれのライブラリ入れてください。バージョンはこれで。
アプリのバージョン更新するんで、Ansibleであれとこれ更新してください。
え？動かない。手元ではちゃんと動いてるんですが？
ライブラリのバージョン違ってるじゃないですかー、ちゃんと入れてくださいよー
あんたのミスですよ。
なんてことあってはならない

515 ：デフォルトの名無しさん：2018/06/30(土) 15:31:35.57 ID:UBF/c/En.net

担当者を明確に分けるとこういうことなんだわ

1. [インフラ] 新しく物理・仮想サーバーを用意して、
2. [インフラ] 環境ごとのサーバーの設定を行って、
3. [アプリ開発] アプリ・サービスを動かすのに必要な環境を用意して（必要ライブラリのインストールなど）
4. [インフラ][アプリ開発] アプリ・サービスをインストールして
5. [アプリ開発] アプリ・サービスの設定を行って
6. [インフラ][アプリ開発] 環境構築を完成させる


担当者ごとに分けると以下のようになる

・Ansibleで設定する部分
1. [インフラ] 新しく物理・仮想サーバーを用意して、
2. [インフラ] 環境ごとのサーバーの設定を行って、
4. [インフラ] アプリ・サービスをインストールして
　（kubernetesのような運用向けオーケストレーション、または単体でDockerコンテナ起動）
6. [インフラ] 運用環境構築を完成させる

・Dockerでコンテナ化する部分
3. [アプリ開発] アプリ・サービスを動かすのに必要な環境を用意して（必要ライブラリのインストールなど）
4. [アプリ開発] アプリ・サービスをインストールして
　（Composeのような開発向けオーケストレーション、または単体でDockerコンテナ起動）
5. [アプリ開発] アプリ・サービスの設定を行って
6. [アプリ開発] 開発環境構築を完成させる

作業は明確に分かれてるんだよ
担当者が違う作業を一緒にしてしまってはいけない

516 ：デフォルトの名無しさん：2018/06/30(土) 15:38:28.48 ID:UBF/c/En.net

>>513
> ドッカーはウェブアプリ専用

違うよ。例えばffmpegのような多くの外部ライブラリに依存し
バージョンの違いの影響も大きくコンパイルオプションも豊富で、
権利関連の問題でどのディストリでも標準パッケージでは満足できず
かと言ってライブラリを自分でビルドすると依存関係が壊れがちになって、
すべての機能をONにしたければ自分でビルドするはめになるようなソフトは
Dockerを使うと、簡単にビルド・実行できるようになる。
自分の好きなディストリを使いつつ、ffmpegは他のディストリベースにすることができる

517 ：デフォルトの名無しさん：2018/06/30(土) 17:59:07.34 ID:dpeJpZ7C.net

サーバの環境をdocker上に作っておく
リプレースが必要になったら新しいサーバにimageを移す

古いけどファミコンのカセットを新しいサーバに刺しなおすだけ

518 ：デフォルトの名無しさん：2018/06/30(土) 18:03:48.84 ID:EEI2bAzw.net

つまり

* Dockerの利点はアプリの依存関係のパッケージングである
　JavaランタイムなしでJavaアプリが動かせますといったことがOSレベルの依存関係でも可能

* Dockerによってパッケージングされたアプリだけではシステムとして成立しない
　Ansibleやオレオレスクリプトで別途環境構成や設定を管理する必要がある

こういうことですか?
DockerはあくまでAnsibleやオレオレスクリプトで管理される取り扱いが容易な部品に徹すると

519 ：デフォルトの名無しさん：2018/06/30(土) 18:55:13.03 ID:HMZbAOjg.net

そもそもAnsibleとDockerって明確にセグメント違うでしょ
優劣がどうこう言うたぐいのものじゃない

520 ：デフォルトの名無しさん：2018/06/30(土) 19:51:53.39 ID:EEI2bAzw.net

AnsibleはAnsibleだけでいいけど
DockerはAnsibleやシェルなど別途構成要素が必要
結局はここに落ち着く
>>503から進展してない

521 ：デフォルトの名無しさん：2018/06/30(土) 20:01:12.07 ID:UBF/c/En.net

> AnsibleはAnsibleだけでいいけど
> DockerはAnsibleやシェルなど別途構成要素が必要

え？ Ansibleでアプリ開発してんの？
普通別の言語を使うよね？
というかAnsibleでどうやってアプリ開発するのか知らんがｗ

なぜそんなに、アプリ開発の一環である
Dockerコンテナの作成を、Ansibleでやることにこだわるのか？
どうせアプリ開発は別言語でやるのに

インフラ担当は、アプリ開発をしなくていいんだよ？

522 ：デフォルトの名無しさん：2018/06/30(土) 20:15:36.27 ID:EEI2bAzw.net

>>521
Ansibleでアプリ開発?
スマンが言ってること意味不明なので解説して欲しい

523 ：デフォルトの名無しさん：2018/06/30(土) 21:01:45.05 ID:EEI2bAzw.net

Docker使わない場合(4step, 2lang)
【Java】 Javaアプリ開発
【Ansible】 Javaランタイムインストール
【Ansible】 Javaアプリデプロイ
【Ansible】 アプリ設定

Docker使う場合(5step, 3lang)
【Java】 Javaアプリ開発
【Docker】 Javaランタイムインストール
【Docker】 Javaアプリデプロイ
【Ansible】 コンテナデプロイ
【Ansible】 アプリ設定

覚えること、仕事増えてるよね?

524 ：デフォルトの名無しさん：2018/06/30(土) 23:50:20.38 ID:HMZbAOjg.net

>>523
ボケはもういいから

525 ：デフォルトの名無しさん：2018/07/01(日) 00:21:42.91 ID:uZDpH5tc.net

>>522
だってすべてAnsibleだけでできるわけないじゃん。
インフラさんはAnsible使ってるだろうけど、
アプリ開発者は別の言語使ってるよね？

インフラさんにとっては、アプリがなんの言語で作られてようが
Dockerコンテナで実行環境毎まとまってようがどうでもいいことじゃん

重要なのはアプリを開発してないインフラさん
（＝どんな実行環境・ライブラリなどで動くかなど知らない）が
アプリに依存したことを意識せず「Dockerコンテナを動かす」という
ただそれだけのことで、サービス運用環境を作れること

専門家に任せましょう。どんな実行環境・ライブラリなどで動くかは
アプリ開発者は知ってます。それで作ってテストしてるんだから
アプリ開発者はAnsibleなんか使いません

526 ：デフォルトの名無しさん：2018/07/01(日) 00:46:26.68 ID:uZDpH5tc.net

あとAnsibleを使えばDockerのようなことができると
思ってるようだけど、できないからな

・Dockerを使うと実行環境をアプリに組み込むことができます
・Dockerはアプリが使用するポート番号を自由に変更することができます
・Dockerは複雑なアプリ設定を単純化し、引数や環境変数で指定可能なアプリに作り変えます

所詮Ansibleは作られたアプリに対して設定を行うだけで、
Dockerのようにアプリ自体を改善・強化することはできない
アプリをDockerコンテナ化するだけでいろんなOSで動かすできるのも
アプリ自体の改善・強化の一つだな

527 ：デフォルトの名無しさん：2018/07/01(日) 01:09:50.12 ID:JvyRKliu.net

>>510
コンテナ内でcron動かせなきゃ意味ない
cronを含めたパッケージングがしたかったんだよぉ

528 ：デフォルトの名無しさん：2018/07/01(日) 03:17:51.52 ID:uZDpH5tc.net

>>527
だから使い方を完全に間違ってる
Dockerはアプリに実行環境を埋め込んで、完全体のアプリを作ること
exeファイルの中にdllなどを埋め込むのと近い

あんたが言ってるのは、C言語でソースコードをビルドしてバイナリを生成して、
バイナリを実行したらcronが動くんじゃなくて、ファイルが存在するだけで
cronを動かすようにしたいって言ってるようなもの

ビルドしただけで動き出すようなプログラムなんてない
意味不明なことを言ってるってわかるだろ？

もちろんDockerコンテナを実行したら内部でcronが実行されてるっていうのなら
簡単にできるが、cronを使うまでもなく実行時間までsleepするだけで十分だな

529 ：デフォルトの名無しさん：2018/07/01(日) 08:10:05.39 ID:Qn9lbnal.net

>>525
＞>>522
＞だってすべてAnsibleだけでできるわけないじゃん。
＞インフラさんはAnsible使ってるだろうけど、
＞アプリ開発者は別の言語使ってるよね？
アプリ開発言語は別に決まってんじゃんって常識的に考えてわからんか？

＞インフラさんにとっては、アプリがなんの言語で作られてようが
＞Dockerコンテナで実行環境毎まとまってようがどうでもいいことじゃん
そのとおり
ドウデモイイんだ
ドウデモイイので使うテクノロジーは減らしたほうがいい

＞重要なのはアプリを開発してないインフラさん
＞（＝どんな実行環境・ライブラリなどで動くかなど知らない）が
＞アプリに依存したことを意識せず「Dockerコンテナを動かす」という
＞ただそれだけのことで、サービス運用環境を作れること
ロールでいいじゃん
ロールの詳細までは別に知らなくていい(知りたければ見ればいい)

＞専門家に任せましょう。どんな実行環境・ライブラリなどで動くかは
＞アプリ開発者は知ってます。それで作ってテストしてるんだから
＞アプリ開発者はAnsibleなんか使いません
クラウドが一般化してきてプログラマでもインフラに関わらなきゃならない機会は増えてる
当然Ansibleも必須科目

530 ：デフォルトの名無しさん：2018/07/01(日) 08:13:01.18 ID:Qn9lbnal.net

>>526
便利っちゃ便利だけど別に必須でもなんでもないよねそれ
それに逆に設定がめんどくさくなることもある(DBとか色々)

531 ：デフォルトの名無しさん：2018/07/01(日) 08:27:59.52 ID:Qn9lbnal.net

>>528
Dockerで作った完全体のアプリ()を誰かがコントロールしてやらなければならないんだどうせなq
exeを作っただけじゃ役に立たないようにイメージを作っただけじゃ役に立たない
サービスとして起動して起動後の設定を行う必要がある
そのための基盤がAnsibleみたいな構成管理ツール
どうせAnsible使うなら最初から全部Ansibleでやりゃいいじゃんってこと
依存関係をDockerfileで解決するかPlaybookで解決するかの違いでしかない
複雑な依存関係がある場合はDockerでカプセル化するメリットがあるかもしれんがそんなのは頻繁に起こることじゃない

532 ：デフォルトの名無しさん：2018/07/01(日) 09:18:18.65 ID:k5uLwq/7.net

bashで全部できるならbashでやるのか？
馬鹿じゃねーの？

Dockerが必要な状況ならDocker入れればいいだけで何のためにDocker使うかわかりもしないのに入れて
手順が増えるとか言う馬鹿

533 ：デフォルトの名無しさん：2018/07/01(日) 09:21:29.18 ID:k5uLwq/7.net

問題解決や利便性のためにDockerが必要な局面もあるだろ
そういうときにDockerが使えればいいだけ

Ansibleしか使えないのに俺スゲーしたいんだろ
俺日本語だけで十分だからなんで英語やフランス語使ってるのかわからんみたいな
低レベルな自慢みたいな浅はかな感じがする

534 ：デフォルトの名無しさん：2018/07/01(日) 09:26:11.80 ID:uZDpH5tc.net

> ドウデモイイので使うテクノロジーは減らしたほうがいい

それならAnsibleをなくしたいねｗ

だってシェルスクリプトは普段からCLIで使ってるけど
Ansibleは使わないじゃん。

シェルスクリプトはなくせないが、Ansible
はシェルスクリプトで置き換えれば無くせる

Dockerはシェルスクリプトベースだしね

535 ：デフォルトの名無しさん：2018/07/01(日) 13:19:42.19 ID:Qn9lbnal.net

そう必要なときに使えばいいんだよ

bashだけで構成管理する大道芸はキツイ
からなんかツールないとやっていけないぞそう世界中のみんなが考えて発明されたのがAnsibleのようなツール
必要性から生まれたツールなんで必要なものなんだね

Dockerは使うと面白いのはわかるけど必要かって言われると正直別に…ってところだな
依存関係？どんだけごった煮のサーバー作る気だ？
ポート変えれます？おめでとさん
引数や環境変数で設定可能？パラメータはファイルに残そうね

536 ：デフォルトの名無しさん：2018/07/01(日) 17:00:28.45 ID:uZDpH5tc.net

>>535
アプリに実行環境を組み込んで可搬性のあるアプリを
作るってところはまだ意味がわかってないのかな？
そこについての言及がないってことはそうなんだろうね

Ansibleで開発したアプリの設定を行うほうが大道芸
だって自社で開発したアプリにAnsibleモジュールは存在しない
自分でモジュール作るか？それともコマンド呼び出しで頑張るか？

自社で開発したアプリを動かすにはあれとこれのインストールが必要です。
バージョンが上がったので今度はそれも追加してください
設定項目が追加されてるので、それを設定するように書き換えてください
冪等性あるように作ってください
アプリのデプロイの前に、Ansibleで環境を更新してください
そうしないとアプリ動きませんから！
絶対にミスしないでくださいよ！！

はい、大道芸ｗ

Dockerを使うとそういう複雑なところが隠蔽されるんだよ
Ansibleで書くのはDockerコンテナを起動する。そのためのモジュールを使うだけ
手元でテストしたDockerコンテナを実環境でも使う。だから実行環境に違いはない。
Ansibleの定義ファイルは単にバージョン番号を変更するだけ

537 ：デフォルトの名無しさん：2018/07/01(日) 17:13:48.82 ID:Qn9lbnal.net

まだわからんかねぇ
Dockerで完結しないってとこからは目をそらし続けるんだ
コンテナ起動するたびシェルで必死に起動後の設定とかアホくさ

そもそもそんな手順はいらない
ロール用意したんでそれ使ってくださいで終わり

538 ：デフォルトの名無しさん：2018/07/01(日) 17:26:44.38 ID:uZDpH5tc.net

> Dockerで完結しないってとこからは目をそらし続けるんだ

どうせアプリはJava使ってありRuby使ったりするんだ、
Ansibleだけで完結することもないよ

それにお前の定義によればDocker使っても「Ansibleだけで完結」してることになるだろ
なぜって？ AnsibleのDockerモジュールを使うからだよ

お前、Ansibleでcronの設定したら「Ansibleだけでは完結しない。cronが必要」って言うか？
言わないよなぁ？ Ansibleでcron設定しようがDockerコンテナ化したアプリの設定しようが
Ansibleだけで完結してることになってるだろ


んで話を戻して、JavaやRubyなどでアプリを開発してるが
Dockerを使おうがAnsibleを使おうが、新たに別のテクノロジーを使ってるのは一緒。
ならDockerのほうが可搬性の点でもシェルスクリプトベースという点でも
メリットがあるので、Dockerを使ったほうがいい

539 ：デフォルトの名無しさん：2018/07/01(日) 17:28:34.87 ID:uZDpH5tc.net

訂正＆補足

んで話を戻して、普段JavaやRubyなどでアプリを開発してる人が
Dockerを使おうがAnsibleを使おうが、新たにアプリ開発言語とは別のテクノロジーを使ってるのは一緒。

540 ：デフォルトの名無しさん：2018/07/01(日) 17:43:06.36 ID:Qn9lbnal.net

必要な環境はロールでカプセル化されっからドッカーでカプセル化して二度手間にする必要はないってことな


つか
「Ansibleで完結」を拡大解釈してねえか？
アプリ開発にジャヴァやらなんやら使うからほれみろAnsibleで完結してませーんってボケにしてもあんまし面白くないぞ


Docker使っても使わなくてもAnsibleで完結してるってのはそうだな
所詮は1モジュールでしかない
逆にDocker視点で見れば全然完結してなくてDockerより大きな他の仕組みが必要になる

541 ：デフォルトの名無しさん：2018/07/01(日) 17:58:47.05 ID:8lx+/MyK.net

kubeと組み合わせるケースはansibleだけではカバー出来んじゃろ

542 ：デフォルトの名無しさん：2018/07/01(日) 18:22:53.11 ID:8PAx412Y.net

Ansibleはwindowsも含めて使ったらPowerShellも覚えないといけない

543 ：デフォルトの名無しさん：2018/07/01(日) 21:27:52.08 ID:JvyRKliu.net

>>528
その通りだとするとcronを使ったwebシステムのパッケージングにはDockerは不向きってことになるが
だとすると俺のイメージと違うな
実行環境を含めたパッケージングの利点はまぁわかるが、ツールレベルのバイナリを使うのにわざわざビルドするのはめんどくさくない？
実行環境をパッケージングできるのはすごいアイデアだと思うよ。でも俺は例えばcatを使うのにわざわざDockerでビルドしたりしないな。そのレベルのバイナリならyumとかapt使うわ

544 ：デフォルトの名無しさん：2018/07/01(日) 22:57:33.50 ID:uZDpH5tc.net

>>543
馬鹿か。だから自分で作ったアプリに実行環境をくっつけるんだよ
ほんとなぁ、開発者のためのツールだってわかっちゃいねぇ

545 ：デフォルトの名無しさん：2018/07/02(月) 16:56:48.08 ID:JP9Qw5xK.net

LXC 生で使ってる人いる?

546 ：デフォルトの名無しさん：2018/07/03(火) 14:33:51.33 ID:lAm6wwJh.net

つかいたくなければ、つかわなければいい
これだけで全部解決できるわけないし

547 ：デフォルトの名無しさん：2018/07/03(火) 16:29:17.64 ID:1jr4H9Em.net

>>544
批判的な俺だが仕事ではDocker使ってるんだよね
小規模webサイト程度ならほんと使い勝手いいわDocker
引っ越しもすげー楽

548 ：デフォルトの名無しさん：2018/07/03(火) 18:13:47.17 ID:Z18rPYuK.net

ウェブサービスや一回走らせて終わりのコマンドと相性が良すぎるんだよなドッカー
それ以外は残念だけど面倒が増えるだけ

549 ：デフォルトの名無しさん：2018/07/04(水) 00:22:44.56 ID:rYQuTGUK.net

> それ以外は残念だけど面倒が増えるだけ

サービスとコマンド以外に世の中に何があるんや？

550 ：デフォルトの名無しさん：2018/07/04(水) 21:54:18.61 ID:gFgZc5FG.net

Q8Y

551 ：デフォルトの名無しさん：2018/07/05(木) 09:11:51.87 ID:s/7ffhjx.net

ウェブアプリテスト環境をmac上のDocker環境で行っているのですが
雨が続くみたいのでリモート作業できるよう自宅のwindowsで同じ環境を構築しようと考えています

Docker上の挙動ってホストOSに依存しますか？
VMならHWレベルでエミュレートしてるので大丈夫そうですけど
Dockerの仮想化ってどのレベルでやってるんでしょうか

動かすのはスクリプト言語なのでバイナリレベルの互換性とかはそれほど影響うけなさそうですけど
通信したときのエンディアンとかはホストに依存したりするんでしょうか

やりとりはjsonのみなのでそのへんもちゃんと吸収されてるとは思うのですが
変なところではまりたくないので事前に確認したいです

552 ：デフォルトの名無しさん：2018/07/05(木) 10:10:29.76 ID:PwFNAHcP.net

>>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 ：デフォルトの名無しさん：2018/07/05(木) 10:12:02.23 ID:PwFNAHcP.net

訂正

Docker for Mac/Windowsのほうが新しく推奨だが、Hyper-VはWindows Pro以上でないと
使えないので、 "Docker for Windowsが使えない場合は" Docker Toolbox（Virtual Box）を使うしかない

554 ：デフォルトの名無しさん：2018/07/05(木) 10:18:19.71 ID:s/7ffhjx.net

環境構築は人にたよってて
その上でjavaやPHPのコーディングするのがメインなのでちゃんと理解できてない…

今の案件がRailsなんですけど
結論からいうとwindows上のDockerでRailsを動かす同じ環境を構築するのは難しい感じでしょうか

555 ：デフォルトの名無しさん：2018/07/05(木) 10:29:08.88 ID:PwFNAHcP.net

>>554
別に？

同じように使える。というか同じように使えるように
Docker社が頑張ってくれてる。

もともとLinuxカーネルでしか動かないのに
よくもまあこんなに頑張って対応したもんだと思うよ
WindowsやMacでも動くことの重要性を強く認識していたんだな

本番環境ではLinuxカーネル上で動かすわけで、Linux上にだけ対応するという道もあったはず。
でもWindowsやMacに対応したのは、多くの開発者の開発マシンはWindowsやMacで
開発者にとってのツールであるDockerはWindowsやMacでも使えることが重要だと考えていたのだろう


上の方にいる、誰かが作ったアプリをパッケージングして配布することだけしか考えてないやつには
わからんだろうね。だから配布するならansibleで十分じゃんという発想になってしまう。
Dockerはアプリ開発者のためのツールですから

556 ：デフォルトの名無しさん：2018/07/05(木) 11:11:14.97 ID:s/7ffhjx.net

丁寧な回答ありがとうございます
構築してみます

557 ：デフォルトの名無しさん：2018/07/05(木) 11:37:29.66 ID:s/7ffhjx.net

何度もすいません

インストールはできてコマンドラインからも動作させることはできたんですけど
ファイルシステムやメモリの設定はどこから行えばいいんでしょうか

mac版はランチャーがあって
Preference > Daemon > Advanced にファイルシステムの設定ファイルがかけたり
Preference > Advanced からメモリの設定ができたりしたんですけど

558 ：デフォルトの名無しさん：2018/07/05(木) 12:38:07.08 ID:ODR9lPch.net

>>554
素直に仮想マシンを立てて、Ansibleなど構成管理ツールを使って、本番と開発環境を可能な限り揃えたほうがいいよ
Dockerはほぼどこでも動くけど、どこでも同じように動作するわけじゃないし、トラブルが発生した時の対処手順がDockerと実機サーバーや仮想マシンとでは大きく異なる
本番も開発環境もDockerで統一するなら許容範囲内だけど、それでも環境差異のリスクはあるね

559 ：デフォルトの名無しさん：2018/07/05(木) 12:51:42.85 ID:PwFNAHcP.net

> 素直に仮想マシンを立てて、Ansibleなど構成管理ツールを使って、本番と開発環境を可能な限り揃えたほうがいいよ

それをやると問題になるのが、（Windows or Macで）ファイルを編集して
すぐにそれを反映させるのが大変になる。いちいちアップロードなんてしてられない
開発時はソースコード書いてテスト実行という流れが1分間に数回のレベルで発生する

また開発時はデバッグ用のモジュールが必要になる。
ログの表示とかデバッガの実行とか。
本番環境と揃えるのは、開発面ですごく効率が悪い
アプリ開発してない、単に配布しかしてないやつにはそれがわからない

560 ：デフォルトの名無しさん：2018/07/05(木) 13:01:45.08 ID:PwFNAHcP.net

>>557
Windowsもタスクトレイのアイコンから設定できるだろ？
Docker Toolboxはどうなってるのかしらんが。

561 ：デフォルトの名無しさん：2018/07/05(木) 13:11:16.62 ID:PwFNAHcP.net

>>558は（Ansibleで構成した）仮想マシンと実機環境が同じだという前提のようだが、
その理屈だと Windows or Mac 上のDockerは仮想マシンで動いてるので
Dockerが動く仮想マシンと、Dockerが動く実機マシンは同じと言える

実際の所、Dockerイメージの中に実行環境が組み込まれているので、
Dockerイメージは、LinuxカーネルとDockerにしか依存しない
Dockerイメージは同じものを使うという前提であれば、
あとはLinuxカーネルとDockerを揃えてしまえばほとんど同じ

たとえ違っていたとしても、Linuxカーネルに関しては高い互換性が
あることが今での実績から明らかで、DockerはDockerコンテナを動かすために
使っているだけで、開発したアプリがDockerに依存しているわけじゃない
なのでLinuxカーネルもDockerもバージョンが変わったところで問題はほとんど発生しない。

環境差異のリスクがあるのはDockerを使わないからなんだ

562 ：デフォルトの名無しさん：2018/07/05(木) 14:32:54.33 ID:1V9Bip0s.net

>>559
大変にならないよ？
もしかしてアプリ開発したことないのかな

563 ：デフォルトの名無しさん：2018/07/05(木) 14:37:12.16 ID:1V9Bip0s.net

>>561
Dockerといえど環境バグは結構あるよ
まあ仮にDocker間で100%互換性があると譲歩したところでテスト、本番が非Dockerなら開発にDockerを使うのはリスクしかない

564 ：デフォルトの名無しさん：2018/07/05(木) 15:02:48.88 ID:PwFNAHcP.net

>>562
じゃあWindows or Macのテキストエディタで
どうやって編集するというのかな？

565 ：デフォルトの名無しさん：2018/07/05(木) 15:03:35.76 ID:PwFNAHcP.net

>>563
本番もDocker使うに決まってるでしょｗ
っていうか、Kubernetesとか使ったことある？
Docker前提だからね。もう大規模はDocker前提の時代になってる

566 ：デフォルトの名無しさん：2018/07/08(日) 20:56:23.28 ID:5iWIGVP9.net

WSLでvagrantを使ってる人いる？
使い心地どうですか？

567 ：デフォルトの名無しさん：2018/07/09(月) 12:21:29.06 ID:7imExrTX.net

WSL上でDocker Engineが動くようになっていたっぽいという話
https://qiita.com/yanoshi/items/dcecbf117d9cbd14af87

568 ：デフォルトの名無しさん：2018/07/10(火) 10:00:57.15 ID:86tCne/Q.net

GKEもECS+Fargateも使える、この世の中でdocker使わない意味もないし、さすがにmanagedに対してansible使う機会は減ってきたと言わざるを得ない

569 ：デフォルトの名無しさん：2018/07/12(木) 00:18:40.48 ID:/Jl9omsJ.net

>>564
ま、それも一理あるね
addじゃなくて、volumeで割り当てれば、host側から編集できる

570 ：デフォルトの名無しさん：2018/07/31(火) 15:12:20.08 ID:Jag0raWy.net

コンテナは上がってるのに

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 ：デフォルトの名無しさん：2018/08/05(日) 16:25:49.27 ID:7Eiwzs5v.net

よく分からんなら問題解決なんてしないでコンテナ作りなおしちゃおーぜってのがdockerの基本中の基本
根本原因を調べないと再発するのでは？って思うかもしれんけどそのたびに作りなおせば問題ないよね

572 ：デフォルトの名無しさん：2018/08/07(火) 08:55:16.65 ID:erAnRa1P.net

ずっと再発してたら進まないじゃん

573 ：デフォルトの名無しさん：2018/08/07(火) 23:32:53.48 ID:WUtnzCvr.net

>>572
だから再発するまでは問題ないんだよ
「昨日までは普通に動いてたのに」ってことはコンテナを立ててからしばらくは正常に動いてるってこと
その間だけサービスを提供してダメになったら(なりそうだったら)予備のコンテナに切り替えるってわけ
コンテナ切り替えたら元のコンテナは破棄して次の予備コンテナをスタンバらせる

574 ：デフォルトの名無しさん：2018/08/08(水) 07:43:28.52 ID:RHurRA8z.net

原因は調べないんでしょう？
ダメじゃん…w

575 ：デフォルトの名無しさん：2018/08/08(水) 15:09:32.22 ID:kiEv2P1b.net

dockerの構築スクリプトも定期的にメンテしないと動かなくなることあるよ

576 ：デフォルトの名無しさん：2018/08/08(水) 15:11:24.15 ID:kiEv2P1b.net

>>570
image-idじゃなくて、container-idをｼﾃｲｼﾅｲﾄ駄目だよ

577 ：デフォルトの名無しさん：2018/08/08(水) 15:11:49.43 ID:FOgunlIR.net

エラーの原因はコンテナと共にバイナリの海の藻屑となる。。。
積み重なったコンテナはやがて墓場を形成し、次第に人々はこう呼ぶようになった。。。
「どっかー(行っちゃった)の墓場」と。。。

578 ：デフォルトの名無しさん：2018/08/09(木) 20:34:37.85 ID:c3U2AhaY.net

docker for winは登録しないとダウンロードできなくなったみたいだ

579 ：デフォルトの名無しさん：2018/08/09(木) 21:19:10.45 ID:s67NkejU.net

そういやWindowsコンテナってあんま話題にならないけどどうなんだろ
XP、.NET 2.0、正体不明の自社・他社COMライブラリ、Excel.Applicationなどが仕事してる古いシステム
まるごとコンテナ化して隔離できんかな

580 ：デフォルトの名無しさん：2018/08/20(月) 20:42:31.73 ID:zEHHSr5C.net

mysqlのdatabaseごとにマウントポイントを変更したい
どうやんの？

581 ：デフォルトの名無しさん：2018/09/24(月) 10:53:33.16 ID:OxVBaH7R.net

Docker Hubから誰でもダウンロードできるコンテナイメージに暗号通貨採掘ボットが潜んでいた
https://jp.techcrunch.com/2018/06/16/2018-06-15-tainted-crypto-mining-containers-pulled-from-docker-hub/

オフィシャルと自作しか信用できんな

582 ：デフォルトの名無しさん：2018/09/24(月) 19:46:38.93 ID:R7V+zLhQ.net

内容読む限りKubernetesクラスタとかDockerサーバのセキュリティ甘いやつ狙ってそいつらにデプロイさせてるんだと思う
まぁ自作と公式以外信頼しないのは重要だと思うけど

583 ：デフォルトの名無しさん：2018/09/25(火) 22:24:47.75 ID:Rh4u2+TF.net

Dockerってデバッグ実行の設定が面倒っすね

584 ：デフォルトの名無しさん：2018/10/10(水) 14:24:27.56 ID:+MpVqK9H.net

virtualboxの上で直接に動いてるLinuxと
virtualboxの上にのってるVagrant上で動いてるLinux

この２つのLinuxって挙動とか変わってきたりしますか？
C言語とかシェルスクリプトのテスト環境として全く等価なんでしょうか？

585 ：デフォルトの名無しさん：2018/10/10(水) 17:09:35.61 ID:az2ldVPt.net

変わるわけねーだろ。仕組みを考えろや

586 ：デフォルトの名無しさん：2018/10/10(水) 17:11:43.59 ID:qywSzTWT.net

>Vagrant上で動いてるLinux
Vagrantは、仮想OS ではないので、Linux は、Vagrant上で動かない

「Vagrant」で検索！

587 ：584：2018/10/10(水) 17:25:45.68 ID:+MpVqK9H.net

>>585
>>586
理解できました
ありがとうございます！

588 ：デフォルトの名無しさん：2018/10/10(水) 19:12:20.57 ID:YG2jN7++.net

>>584
インストールから設定をキッチリ揃えたわけでもなければ当然ながら等価じゃないよ
無視できる差異かどうかってとこが重要
これはDockerでも同じこと
厳密に同じ環境はどうやったって作れない

589 ：デフォルトの名無しさん：2018/10/10(水) 19:32:05.19 ID:az2ldVPt.net

>>588
厳密に同じ環境であるかなんて聞いてないだろ

590 ：デフォルトの名無しさん：2018/10/11(木) 01:15:56.61 ID:BkaQ7NLU.net

>>588
野良boxでなければ等価だと言ってもよいのでは？

591 ：デフォルトの名無しさん：2018/10/11(木) 07:15:08.44 ID:ATTrPfNN.net

何をもって「挙動が同じ」「等価」とするかだよね
スクリプトでハードウェア情報取得しようとすれば環境によって変わってくるだろうし
外部のWebサイトに対して自分で書いたクローラーを実行するとかなら多分「挙動が同じ」になるだろう

592 ：デフォルトの名無しさん：2018/10/12(金) 12:25:02.77 ID:M+u1oV0j.net

コンテナ上で仮想OSは動かないということだけど、例えば「docker pull ubuntu」で取得したubuntu動かすのと仮想マシンでubuntu動かすのとの違いが良くわからない

593 ：デフォルトの名無しさん：2018/10/12(金) 12:45:36.05 ID:vWnsmRfa.net

>>592
dockerにとってubuntuは材料に過ぎない
ubuntuという材料をベースにDockerfileを書いてアプリを作る
そういうことが簡単にできるように作られたのがdocker

594 ：デフォルトの名無しさん：2018/10/12(金) 13:36:53.15 ID:FbxLjgd5.net

つまりubuntuっぽい(というか見た目は変わらない)動作をするアプリが動いてるだけってことか
ありがとう

595 ：デフォルトの名無しさん：2018/10/12(金) 21:21:03.81 ID:mCoAwEvP.net

マイナーなツールでフォアグラウンド起動のしかたがわからない場合どうする？

596 ：デフォルトの名無しさん：2018/10/12(金) 21:45:24.47 ID:sq0JMdbV.net

フォアグラウンド起動の方法がないじゃなくて
わからないだけなら、調べろとしか

597 ：デフォルトの名無しさん：2018/10/13(土) 00:18:26.66 ID:M1XBvJBU.net

所詮はDockerって省エネを目指した仮想環境に過ぎないからね
そんなこと気にしなければVagrantがベスト

598 ：デフォルトの名無しさん：2018/10/13(土) 04:06:41.09 ID:4DTv/biP.net

dockerとvagrantという全く違うものを
比較している人に言われましてもｗ

599 ：デフォルトの名無しさん：2018/10/13(土) 10:23:57.31 ID:YNebL+WU.net

用途がかぶる部分があるので比較する意味は有る

自転車、自動車、鉄道、飛行機は全く違うものだけど、移動するためのものという用途は同じ
旅行や通勤の際にこれらを比較する価値は大いに有る
vagrantとdockerも同様

600 ：デフォルトの名無しさん：2018/10/13(土) 11:20:42.44 ID:yupcnuUE.net

自動車と運転手を比較してもな。

601 ：デフォルトの名無しさん：2018/10/13(土) 11:20:59.09 ID:MAZOR1zR.net

基本的にはファイルシステムだけカプセル化してるんだっけか？
でもportなんかもカプセル化してるし、どこまでを閉じ込めてるか結構微妙。

602 ：デフォルトの名無しさん：2018/10/13(土) 12:11:11.17 ID:4DTv/biP.net

>>601
アプリケーションを動かすのに必要なもののうちOS以外の部分を
アプリケーションに内包させていると考えればいい

603 ：デフォルトの名無しさん：2018/10/13(土) 12:14:09.83 ID:4DTv/biP.net

>>599
なにかアプリを使おうと思った時、わざわざ別マシンを用意して別の環境で動かすのが仮想マシン

今自分が使ってる環境の上でアプリを起動するのがDocker

ぜんぜん違う

604 ：デフォルトの名無しさん：2018/10/13(土) 13:02:00.31 ID:MAZOR1zR.net

>>601
そんな抽象的で意味のない答えは求めてない。

605 ：デフォルトの名無しさん：2018/10/13(土) 21:33:30.23 ID:YNebL+WU.net

>>603
抽象化ができないエンジニアには難しいかも知れないが
ホストと隔離された環境でなんらかのアプリを使うという抽象的な目的は同じなんだよ
基本になってるテクノロジが違うけどそこは同じ
なので比較検討することには意味が有るわけだ

例えばローカル開発環境を構築するという抽象に対してDockerあるいはVagrantという具象が有る
もちろんそういう意味ではホストに必要なパッケージをインストールするだけの素朴な構成も比較検討に値する
完全仮想化とコンテナ仮想化は違う技術だから比較に値しないなんてのは表層しか捉えられないなにもわかってない人の発想なんだね

606 ：デフォルトの名無しさん：2018/10/13(土) 21:48:14.00 ID:An0DfPZD.net

技術が違うんじゃなくて、目的が違う
ここまで理解能力がないと、本当に話にならない。

607 ：デフォルトの名無しさん：2018/10/13(土) 22:12:07.13 ID:An0DfPZD.net

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 ：デフォルトの名無しさん：2018/10/13(土) 23:33:44.26 ID:YNebL+WU.net

>>606
目的なんて無数にあるだろ
自分が考える目的以外の目的が存在するということすら想像できないようじゃ話にならない
本当に話しにならない

609 ：デフォルトの名無しさん：2018/10/13(土) 23:37:37.63 ID:An0DfPZD.net

そうやって一般論でごまかすのやめーや

Dockerが考えてる目的を書いただけの話
別の目的に使おうというのなら、使いにくいのは当然だってことだ
少なくとも仮想マシンやVagrantとDockerの目的は違っている
お前の目的の話はしてない。Dockerの目的の話をしてる。

610 ：デフォルトの名無しさん：2018/10/13(土) 23:44:07.35 ID:YNebL+WU.net

>>607
あらら、まだわからないのか

キミの言うところのDockerの高い可搬性を利用して、例えば開発環境を構築するという目的を達成するんだよ
そして開発環境を構築するという目的を解決する手段はDockerに限らずVagrantでもローカルでも構わない
だから比較検討して目的を達成するのにはどのテクノロジを採用するのがよいかを考えるわけだ

おそらくキミの中ではDockerはこの目的に使うもの、Vagrantはこの目的に使うもの
といったようにただ一つの絶対的な目的があるんだろうな
目的を解決する手段がいくつも有ること、ツールを使う目的はいくつも有ることに気付いていない
最低限そこに気付いてくれないと話しにならないよ

611 ：デフォルトの名無しさん：2018/10/13(土) 23:51:41.18 ID:YNebL+WU.net

>>609
君のレスを引用すると「Dockerは可搬性を高くするもの」
これがDockerが考えている目的なわけだ(というか君の脳内のDocker社の考える目的というべきか)

じゃあ可搬性を高くしてどうするんだ？
その先の目的がまだあるだろ？
その目的は利用者が抱える課題によって様々なんだよ

612 ：デフォルトの名無しさん：2018/10/13(土) 23:52:12.52 ID:An0DfPZD.net

> キミの言うところのDockerの高い可搬性を利用して、例えば開発環境を構築するという目的を達成するんだよ

自分で言ってる通りじゃないかｗ
Dockerの目的は高い可搬性を作る所まで。

Dockerを利用するってことは、別に作業があるんだろ？
その作業の目的が開発環境を構築することであって
Dockerを使う目的ではない


キミ、物事の本質を捉えられるようにならないとダメだよ

613 ：デフォルトの名無しさん：2018/10/13(土) 23:53:24.28 ID:An0DfPZD.net

>>611
> じゃあ可搬性を高くしてどうするんだ？
> その先の目的がまだあるだろ？

その先の目的？ 金を稼ぐってことかいな？
その理屈で言えば、どんな道具も目的は同じになるなｗ

614 ：デフォルトの名無しさん：2018/10/13(土) 23:58:24.68 ID:YNebL+WU.net

今置かれてる状況がある
また解決したい何らかの問題がある
そして解決する手段が複数ある

ここまできて比較検討しないって言っちゃなんだけど技術者失格だろう?

非常に幸運で何らかのテクノロジ一択で業務全部をカバーできる
なんて状況でもなければ必ず比較検討が必要になる

615 ：デフォルトの名無しさん：2018/10/14(日) 00:00:31.63 ID:mBxOrkWE.net

>>614
お前が物事の本質をわかってないだけ。

Dockerの目的は可搬性を上げるためだし、
テキストエディタの目的はテキストファイルを編集するもの

開発環境を作るために、テキストエディタを使うだろと
いくら吠えたって、テキストエディタの目的が開発環境を作ることにはならないのと
同じようにDockerの目的は開発環境の作成ではない

616 ：デフォルトの名無しさん：2018/10/14(日) 00:04:44.32 ID:RzJcTIeH.net

>>612
>Dockerを利用するってことは、別に作業があるんだろ？
>その作業の目的が開発環境を構築することであって
>Dockerを使う目的ではない

開発環境構築は間違いなくDockerを使う目的の1つ

A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」

自然だね

A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「そんなのはDockerの目的じゃない！」

アホかこいつ

617 ：デフォルトの名無しさん：2018/10/14(日) 00:06:49.52 ID:RzJcTIeH.net

>>613
極論すればそうだな

どんな道具にも複数の利用目的が存在する
どんな目的にも解決手段は複数有る

だから比較検討するんだよ

618 ：デフォルトの名無しさん：2018/10/14(日) 00:10:20.62 ID:RzJcTIeH.net

>>615
道具の目的は作成者や利用者の認識によって様々
テキストエディタの主目的は確かにテキストの編集だろう
だが目的はそれだけではなく人によってことなる
"誰か"の目的を押し付けるべきではない
"おまえ"の目的が全てではない
まずはこの基本的な事実から理解してくれ
話しにならないから

619 ：デフォルトの名無しさん：2018/10/14(日) 00:10:43.24 ID:mBxOrkWE.net

> A「なんのためにDockerを採用したの?」
> B「開発環境構築のために採用しました」

採用と目的 は意味が違う
はい論破ｗ

ジョークかよｗ
なんでこんな簡単な指摘をせにゃならんのだ

620 ：デフォルトの名無しさん：2018/10/14(日) 00:11:59.29 ID:mBxOrkWE.net

ほんとさっきからDockerの目的を
違う話にすり替えようとしてるな。
バレバレやで

621 ：デフォルトの名無しさん：2018/10/14(日) 00:13:40.14 ID:RzJcTIeH.net

>>619
「なんのために」って読めなかった？外国人？

622 ：デフォルトの名無しさん：2018/10/14(日) 00:14:12.92 ID:mBxOrkWE.net

A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「開発環境構築してるのは見ればわかる。それを行うに当たって
なんのためにDockerを採用したのか聞いてるんだが？」

普通は後期着替え得される

623 ：デフォルトの名無しさん：2018/10/14(日) 00:15:15.24 ID:RzJcTIeH.net

>>620
すり替えてるのはAn0DfPZDだな
Dockerの利用目的などいくらでもあるのに、開発目的の1つでしかない高い可搬性を唯一絶対の目的のように、こいつはすり替えようとしている

624 ：デフォルトの名無しさん：2018/10/14(日) 00:15:16.71 ID:mBxOrkWE.net

例えて言うなら

A「なんのために○○工法を採用したの?」
B「建造物構築のために採用しました」

こう言ってるようなもん

625 ：デフォルトの名無しさん：2018/10/14(日) 00:21:29.05 ID:RzJcTIeH.net

>>622
A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「開発環境構築してるのは見ればわかる。それを行うに当たって
なんのためにDockerを採用したのか聞いてるんだが？」

B「開発環境構築手段としてはVagrantやローカル環境へのバッチ処理適用などが候補に上がりました。
弊社の置かれる状況を踏まえて、それらを比較検討した上で、これこれこういうメリットがあると判断して、採用しました」

普通はこうなる
比較検討なんかしない、などというバカだったら採用理由にも説得力がなかっただろうね

開発環境に限った話ではないが、何かを決めるにあたって、検討した選択肢と採用した理由は関係者に対して必ず説明するものだ
業務で開発したことが有るならアタリマエのことだと思うが
もしかしてキミ仕事で開発したこと無い？あるいは一人で開発してるとか？

626 ：デフォルトの名無しさん：2018/10/14(日) 00:28:27.93 ID:mBxOrkWE.net

>>625
> 普通はこうなる

前言撤回かよｗｗｗｗ

俺が間違いを指摘した後に慌てて後付して書くなって
ほんと恥ずかしいやつやなｗ
だいたい、その「これこれこういう」の中身が目的やろうが？

ちゃんと書けよ。Dockerを使うことで可搬性が高くなるというメリットがあるので
その目的のためにDockerを採用しましたって

627 ：デフォルトの名無しさん：2018/10/14(日) 00:36:36.30 ID:RzJcTIeH.net

>>626
>「これこれこういう」の中身が目的やろうが？
「これこれこういう」は利用者の状況や課題によって様々
だから比較検討して答えをだすって何度もレスしとるだろうが
いい加減少しは理解してくれ
話しにならないとはまさにこのこと

628 ：デフォルトの名無しさん：2018/10/14(日) 20:01:17.80 ID:TovYdN7f.net

なんか話が難しくなってきましたね
ひとまず、docker軽いですよ、vagrantに比べて
buildはややかかるけど、終わってしまえば、起動もさくっといきますよ

629 ：デフォルトの名無しさん：2018/10/14(日) 22:23:03.56 ID:mBxOrkWE.net

何に使えるかと、何のための道具かってのをごっちゃにしてるやつのたわごとだからな。
Dockerはアプリケーションを仮想化するために作られた道具

その道具を使って金儲けができるからって、
いろんなものをごっちゃにしたらダメだって話

630 ：デフォルトの名無しさん：2018/10/14(日) 22:25:54.86 ID:mBxOrkWE.net

>>628
> ひとまず、docker軽いですよ、vagrantに比べて
vagrantは開発環境を作る道具にすぎない。
Dockerと比べるものじゃない。

比較するならば、ホストマシンでアプリを動かす vs 仮想マシンでアプリを動かすだろ
ホストマシンでアプリを直接実行するほうが、仮想マシン上でアプリを動かすよりも軽い
といわれても当たり前でしか無い

631 ：デフォルトの名無しさん：2018/10/15(月) 00:07:39.55 ID:37aK5NOi.net

うん、だからdockerの方が軽いんだよね？
当たり前でも何でも実際軽くて便利なんだからいいじゃないか

632 ：デフォルトの名無しさん：2018/10/15(月) 00:41:31.13 ID:9UZy+Ppr.net

そりゃ仮想マシン使うよりも仮想マシン使わないほうが軽いだろう。
仮想マシン使わないで、普通にパッケージをインストールすれば良い

普通にパッケージをインストールすればいいのに
なぜDockerを使うのか？それこそがDockerを使う目的

633 ：デフォルトの名無しさん：2018/10/15(月) 18:32:47.56 ID:YtsyH3sD.net

課題を解決する手段が複数ある
それぞれ一長一短で状況により正解は異なる
なので比較検討してどれを採用するか決める
これITに限らず一般常識ね

634 ：デフォルトの名無しさん：2018/10/15(月) 18:36:41.86 ID:9UZy+Ppr.net

んで、今話してるのは手段ではなくて
Dockerは何をする道具かということ
本質をちゃんと見れないと道具は正しく使えない

635 ：デフォルトの名無しさん：2018/10/15(月) 18:41:05.65 ID:YtsyH3sD.net

周回遅れだね

Dockerの特性は正しく理解した上で比較検討しようという段階の話をしてるので付いてきて

636 ：デフォルトの名無しさん：2018/10/15(月) 18:47:15.49 ID:9UZy+Ppr.net

話を逸らすな。
Dockerはアプリケーションを仮想化する道具だって話をしてる

637 ：デフォルトの名無しさん：2018/10/15(月) 18:55:53.84 ID:YtsyH3sD.net

お気の毒ですがそのような話をしているのはあなただけです
あなたはあなたが話ていることをみんなも話ているように錯覚しているようですが実は違うのです
まずは深呼吸して冷静になってください
会話が成立することを期待して待っています

638 ：デフォルトの名無しさん：2018/10/15(月) 19:00:16.10 ID:9UZy+Ppr.net

>>637
お前、自分が一人だってわかってないのか？
誰か他に同調してくれるやついるか？

639 ：デフォルトの名無しさん：2018/10/15(月) 19:06:03.75 ID:YtsyH3sD.net

>>638
dockerとvagrant(あるいは他の方法論)を比較するという文脈のレスは私のレス以外にも幾つもありますね
比較するのはおかしいという主張はどうやらあなただけのようですが

640 ：デフォルトの名無しさん：2018/10/15(月) 19:13:31.78 ID:CIPQcDr6.net

docker vagrant 比較
ぐぐったらたくさん出てきた
ちなみに
docker vagrant 比較するのはおかしい
ぐぐったら”おかしい”が除外されて検索された
こりゃ勝負有ったね

641 ：デフォルトの名無しさん：2018/10/15(月) 19:18:29.88 ID:9UZy+Ppr.net

>>639
それはお前の意見に同調してるわけじゃないだろｗ
頭悪いんちゃうか？

642 ：デフォルトの名無しさん：2018/10/15(月) 19:19:27.50 ID:9UZy+Ppr.net

だいたい、さんざん仮想マシンと比較って言ってくせに
vagrantに言い換えてるし
仮想マシンとvagrantの違いもわかってないようだ

643 ：デフォルトの名無しさん：2018/10/15(月) 20:07:06.98 ID:5g95lVcV.net

間を取ってLXCで

644 ：デフォルトの名無しさん：2018/10/15(月) 20:30:22.20 ID:9UZy+Ppr.net

間っていうか、LXCはシステムコンテナだから、Dockerで仮想マシンのような間違った使い方を
使い方をしようとしている人は、LXCを使うべきだよ

645 ：デフォルトの名無しさん：2018/10/16(火) 00:27:22.18 ID:8ZLfHmC4.net

PythonでJupyter Notebook使ったデータ解析環境をPC変更時に新PC上で手動で再現するのが面倒だからDocker上で動かすようにしてる

646 ：デフォルトの名無しさん：2018/10/16(火) 00:30:53.46 ID:JHQMnpCL.net

Jupyter Notebookというアプリにそのアプリを動かすのに
必要なものを全部まとめてるわけだよね。
それが正しい使い方

647 ：デフォルトの名無しさん：2018/10/16(火) 02:50:30.16 ID:+sj1AQoJ.net

そもそも再現性気にするくらいならjupyter使うのが間違ってるけどな。

648 ：デフォルトの名無しさん：2018/10/16(火) 03:32:28.53 ID:JHQMnpCL.net

また再現性とか誰も必要だと言ってない話をし始めたｗ

649 ：デフォルトの名無しさん：2018/10/16(火) 21:22:37.51 ID:+sj1AQoJ.net

再現性が必要ない？
それはなかなか斬新ですねw
そコマで頭の悪い意見が出るとは思ってなかった。

650 ：デフォルトの名無しさん：2018/10/16(火) 22:04:16.59 ID:BK7j5HGI.net

Jupyter Notebookって試行錯誤を効率化するのが目的なんだから、再現性なんてDockerイメージで担保すればいいというのも、それはそれでありうる判断だろう。

環境独立な再現性があればあった方がいいって点には誰も異論はないと思うが、
それよりも試行錯誤の効率性の方が優先される用途もあるってだけの話だな。

651 ：デフォルトの名無しさん：2018/10/16(火) 22:13:56.47 ID:zWgAqWtj.net

依存性の封じ込めも再現性もvagrantや別の方法でもできるので比較検討が必要

652 ：デフォルトの名無しさん：2018/10/17(水) 01:10:09.91 ID:MUBjx6EB.net

>>649
依存性の封じ込めも再現性もvagrantや別の方法でもできるので
Dockerを使う理由にはならないってことだよ

653 ：デフォルトの名無しさん：2018/10/17(水) 18:08:49.39 ID:QBZICbug.net

複数の方法があるけど一長一短なのでツールの特性と置かれてる状況とを見て比較検討する必要があるんだね

654 ：デフォルトの名無しさん：2018/10/17(水) 19:42:49.89 ID:t+3zMNmx.net

ずーっとってる話だが、
比較検討の話と、ツールが作られた目的を
ごっちゃにするなってことですね

655 ：デフォルトの名無しさん：2018/10/17(水) 20:01:49.11 ID:QBZICbug.net

発端は>>597-599あたりかな
比較検討の意義についての議論だったのだけど、それが理解できない子も居たようだね

656 ：デフォルトの名無しさん：2018/10/17(水) 20:06:17.49 ID:t+3zMNmx.net

比較検討するにあたって、
どの道具の目的をちゃんと理解してないと
正しい検討ができないって話やろが

657 ：デフォルトの名無しさん：2018/10/18(木) 12:14:37.57 ID:tcdN1NJq.net

ここで聞くのが正しいかどうかわからないんですが質問です
やりたいことが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 ：デフォルトの名無しさん：2018/11/28(水) 16:14:53.75 ID:ndifwdFb.net

Dockerって言うのを試したいのだが、
少し調べてみた限りでは、コマンドベースで各種の設定などやるようだが、
Linuxの操作に慣れていない人は使うのは難しい？

659 ：デフォルトの名無しさん：2018/11/29(木) 22:44:08.65 ID:mZclEcbu.net

>>658
やめといた方が方がいい。
本格的にLinuxを勉強するつもりなら話が別だが。

660 ：デフォルトの名無しさん：2018/11/29(木) 22:44:49.67 ID:XxChCmoV.net

>>658
Linux関係なくね？

661 ：デフォルトの名無しさん：2018/11/29(木) 23:34:53.34 ID:gjHip4g7.net

GUIしかやってないなら大抵の仮想化ツールは取っ付きにくいだろうな
CUIの勉強しろよ

662 ：デフォルトの名無しさん：2018/11/30(金) 14:16:12.81 ID:R6/w2EbV.net

>>658
簡単だけどLinuxの操作などを知っているなら簡単という意味。

663 ：デフォルトの名無しさん：2018/11/30(金) 20:19:16.57 ID:S7TbfYM4.net

ターゲットとなる本番環境じゃなくてポータブル開発環境として使ってる人います？
ローリングリリースのLinux選んでずーっとその仮想育てる感じで
PowershellもMsysもWSLもどうやっても馴染めないよう

664 ：デフォルトの名無しさん：2018/11/30(金) 23:53:07.83 ID:VjmtC3o0.net

シェルスクリプト・PowerShell の代わりに、VSCode で、Ruby を使えば？

Windows でも、普通にファイル操作できる。
ただし、irb だけは日本語でバグるから、WSL のirb を使う

日本語では、WSL のirb は、MSYS2 よりも正常に動く

665 ：デフォルトの名無しさん：2018/12/01(土) 07:43:14.49 ID:R+goIYNS.net

うーん正確な用語がわからない・・

そのVSCodeとRubyの方を仮想かしてどこでも同じ使い勝手を味わいたいんだ
そっちの実作業環境を開発環境と呼ぶのは変なのかな

666 ：デフォルトの名無しさん：2018/12/01(土) 14:14:31.04 ID:UYaQWlEF.net

docker へrdpで解決しない？

667 ：デフォルトの名無しさん：2018/12/11(火) 16:27:30.38 ID:3Bi3MN4D.net

サイトの管理を任されたけど、今 vagrant　とdockerとかで
環境構築するのが当たり前なの？
もう、MAMP XAMPでローカルに構築する時代じゃないの？？？

668 ：デフォルトの名無しさん：2018/12/11(火) 16:35:45.97 ID:Hrs/4e8e.net

vagrantは開発専用。これでサイト構築はまず無いだろ

> もう、MAMP XAMPでローカルに構築する時代じゃないの？？？
vagrantかWSLのほうがいいだろ？
実際の動作環境がLinuxなのにWindowsで環境作るほうが面倒

669 ：デフォルトの名無しさん：2018/12/11(火) 22:04:25.79 ID:ihMfYHRY.net

Software Design 12月号の特集は、Python のAnsible

Vagrant, Chef に挑む巨人、Red Hat の猛攻が始まった！

以前は、すべての開発者は、Vagrant の作者で、今世紀最大の創業者、
Mitchell Hashimoto (HashiCorp)を避けて通ることはできないと言われていた

その常識に、赤い巨人が挑む！w

670 ：デフォルトの名無しさん：2018/12/12(水) 00:11:08.47 ID:ygJIxGmd.net

>>667
俺の知ってる現場でもみんなvagrantだな
そういう時代なんだと思う

671 ：デフォルトの名無しさん：2018/12/12(水) 19:59:55.07 ID:02lWEJYc.net

VirtualBoxとVagrant　を使って開発って
WEBアプリケーション以外にも使われることはあるんですか？

例えば、スマホアプリとか。

672 ：デフォルトの名無しさん：2018/12/14(金) 13:43:43.35 ID:/HfC9/Wt.net

>>671
あるよ

673 ：デフォルトの名無しさん：2018/12/14(金) 13:48:00.36 ID:f5Y1ye2A.net

ありまぁす

674 ：デフォルトの名無しさん：2018/12/19(水) 14:49:06.19 ID:QzBRL+7W.net

WindowsでDocker (Hyper-V)とVirtualBoxが共存可能になったってよ　

675 ：デフォルトの名無しさん：2018/12/20(木) 07:07:45.57 ID:S5A+WF/L.net

vagrant/terraform
container linux
ansible
docker
kubernetes
Istio
gcp/aws/azure
この辺のキーワード聞くことが多くなってきたが覚えること大杉てしぬ

676 ：デフォルトの名無しさん：2019/01/22(火) 19:13:09.57 ID:C76SXNc4.net

クラウドでコンテナを運用するとしたら規模の小さめなサービスでもk8sが鉄板なんすか？

677 ：デフォルトの名無しさん：2019/02/01(金) 22:44:34.29 ID:h+AyUO7a.net

Ansible使ったらshellだらけになった

678 ：デフォルトの名無しさん：2019/02/25(月) 14:14:19.25 ID:N3uaxGmA.net

vagrantのguestosをオフライン環境でバージョンアップさせる方法教えてください

679 ：デフォルトの名無しさん：2019/03/01(金) 01:33:46.52 ID:vZN7gNkq.net

本番運用の環境でDockerCE (Docker for Windows) の Linuxコンテナを使ってるんだけど、
たまにポートフォワードがうんとも寸とも言わなくなることがあるんだけど、そういうもん？

具体的にはNGINXのコンテナを作って外からの443をNGINXに向けるようにしてるんだけど、
突然ポートフォワード出来なくなる。TCPパケットダンプしても明らかにコンテナに流れてない。
んでDocker自身を再起動したら復帰する

運用環境としては怖すぎなんだけど・・・

680 ：デフォルトの名無しさん：2019/03/01(金) 08:42:16.02 ID:GsQvlv9z.net

Docker は本家 Linux でも本番環境だとわりとトラブるって話を1年くらい前に聞いたな。
利用は開発環境やステージング環境までにして
本番はネイティブにした方が無難なような。

681 ：デフォルトの名無しさん：2019/03/01(金) 12:21:06.68 ID:gSOngWNj.net

設定ミスの可能性もあるだろう
マネージドのDocker Hostをレンタルして同じ構成で動かしてみたらどうだ

682 ：679：2019/03/01(金) 22:02:26.08 ID:vZN7gNkq.net

設定ミスの可能性は無いです

683 ：デフォルトの名無しさん：2019/03/01(金) 22:40:15.67 ID:jYXMQwAm.net

確認した?
エビデンスとったか？

684 ：デフォルトの名無しさん：2019/03/01(金) 22:55:07.01 ID:GsQvlv9z.net

tcpdumpの結果でわりと十分なエビデンスだろう。
突然パケットが流れなくなるような設定間違いってなかなかできない。

685 ：デフォルトの名無しさん：2019/03/01(金) 23:02:50.07 ID:jYXMQwAm.net

>>684
全く「設定ミスがない」ことのエビデンスになってない
それじゃただ単に現象を確認しただけだ

686 ：デフォルトの名無しさん：2019/03/02(土) 10:11:20.28 ID:Ujga9lQn.net

>>685
｢『全く』設定ミスがない｣ことのエビデンスなんて現実的なコストでは提供不能だよ。
特に設定不足系は無理。
ふつうはそんな効率の悪いやり方をしない。
まあ金融・証券系みたいにコスト無視、かつ顧客が無理難題をふっかけるとこだと、顧客が納得するレベルの嘘をついて誤魔化すことはあるけどさ。

687 ：デフォルトの名無しさん：2019/03/02(土) 10:37:21.55 ID:Ujga9lQn.net

｢Docker network stopped working ｣でググるといっぱい見つかるね。
未解決のも多い。

ttps://github.com/moby/moby/issues/32195
なんかはSolved になってるけど
・(正常なネットワークなら問題ない筈の)先進的なネットワークオプションをとにかくdisableせよ
・Docker のバージョンを上げろ
ってなってて、Docker か、あるいは利用しているネットワーク環境のどちらかに不具合があるっぽい。

688 ：デフォルトの名無しさん：2019/03/02(土) 11:08:33.63 ID:heck9gfN.net

>>686
俺がなんで括弧つけたかわかってないな

「全く設定ミスがない」こと証明してないと言いたいのではない
「設定ミスがない」ことを全く証明してないと言ったのだ

689 ：デフォルトの名無しさん：2019/03/02(土) 11:27:53.49 ID:Ujga9lQn.net

>>688
ふつうは正しく動作することをもって証明とするんだよ。
数学的な意味での証明には全くならんが、現実的なコストでできる証明ってのはそれくらいしかないんだ。

くだんの人の場合、一応正しくは動作してるのに、しばらくすると止まる、しかもtcpダンプしても止まってるんだから、
症状からしてなにか不具合がある可能性が高い。

そうじゃない、証明する方法があるんだっていうのなら、その方法を具体的に書いてやってくれ。

690 ：デフォルトの名無しさん：2019/03/02(土) 11:35:40.93 ID:heck9gfN.net

>>689
もうとっくに書いてんじゃん
マネージドなdockerホスト借りてやってみたらどうだってさ

何も設定項目1つ1つ変更しながらエビデンスとれって言ってるわけじゃないんだよ
適度なサイズのスコープで切り替えながら調査していくの
これって問題調査の基本中の基本だよね？

君が言ってる現実的じゃない方法って
アルゴリズムに例えて言うと線形探索なんだよ
でも俺らは二分探索とか範囲で絞り込むアルゴリズムを知ってるわけだろ？
なんで身につけた知識を応用しないんだ？

691 ：デフォルトの名無しさん：2019/03/02(土) 11:50:11.02 ID:Ujga9lQn.net

>>690
マネージドなDockerホストって書いてた人だったのか。
確かにそれはアリだな。

俺の言葉の使い方だとそれを設定ミスがないことのエビデンスになるとは言わないので
マネージド環境でのテストのことを指してるとは思わなかったよ。
すまんかった。

よくよく考えてみるとアホな顧客にエビデンス要求された時に
有料サービスに丸投げした結果を提供してOKもらうことはたびたびあるので
自分でも似た使い方してたなw
自分でそれがエビデンスという強い言葉に値すると思ってないから思いつかないんだなあ。

692 ：デフォルトの名無しさん：2019/03/03(日) 14:34:26.16 ID:PCCGC897.net

issueだらけだもんなぁ
本番には到底耐えきれないよ
本番で使わないならってんで開発でもDockerを使わなくなる
だから実務で役に立つのはVagrantとAnsibleになる

693 ：デフォルトの名無しさん：2019/03/03(日) 14:43:33.70 ID:LWbZmqMl.net

>>692
issueの数で判断できるなら、世の中のメジャーなライブラリやフレームワークはみな使えないことになる

694 ：デフォルトの名無しさん：2019/03/03(日) 15:04:33.53 ID:PCCGC897.net

ライブラリやフレームワークに不具合があってもアプリケーションとしてのテストを通過すれば問題はない
でもDockerみたいなのになるとテストしきれないから安易に使えない

695 ：デフォルトの名無しさん：2019/03/03(日) 15:07:54.94 ID:UpvIfT49.net

>>694
はいキチガイ

696 ：デフォルトの名無しさん：2019/03/03(日) 15:11:25.80 ID:PCCGC897.net

>>695
いや常識だぞこれ
お前はテストしとらんのか？

697 ：デフォルトの名無しさん：2019/03/03(日) 15:45:08.26 ID:tapoy5qO.net

>>696
ソースは？

698 ：デフォルトの名無しさん：2019/03/27(水) 18:59:14.57 ID:Aic0Wt50.net

>>697
Rubyかな

699 ：デフォルトの名無しさん：2019/03/27(水) 22:21:53.24 ID:jwVZ1lxp.net

ansible-containerってどうなの？

700 ：デフォルトの名無しさん：2019/04/07(日) 22:47:05.10 ID:KmDkztEg.net

初心者なんじゃがコンテナ内のphpmyadminから別コンテナのMySQL叩くの難易度どれくらい？

701 ：デフォルトの名無しさん：2019/04/08(月) 12:14:30.85 ID:flU0/mvo.net

難度Fぐらいかな

702 ：デフォルトの名無しさん：2019/04/08(月) 19:16:29.83 ID:+ZYObKbH.net

USB Type Aが一発で刺さるぐらいの難易度

703 ：デフォルトの名無しさん：2019/04/08(月) 21:09:35.64 ID:SeD3ldgI.net

本当かぁ、？何回かネットや本のコピペしてるけどMySQLとphpmyadmin連携取れないぞ、？

704 ：デフォルトの名無しさん：2019/04/08(月) 21:24:00.34 ID:SqshxjrC.net

composeのサンプルコピペでいけるやろ

705 ：デフォルトの名無しさん：2019/04/08(月) 22:14:51.00 ID:SeD3ldgI.net

>>704
この後またチャレンジするんだけど皆さん普通に連携取れて出来てるのよね？
本の丸コピが何回やっても動かないし何かMySQLの認証系が怪しいんだが

706 ：デフォルトの名無しさん：2019/04/08(月) 23:23:24.47 ID:zFFjnYPT.net

compose見せてみ

707 ：デフォルトの名無しさん：2019/04/09(火) 20:27:46.01 ID:3Wk1Dqbm.net

すまん、、そこまでまだ本を読み進めてないでんねん。。下記が本のソース丸コピなんだが
////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 ：デフォルトの名無しさん：2019/04/09(火) 20:29:44.42 ID:3Wk1Dqbm.net

ちなみにこれも三行丸コピで動くらしいけど失敗したやつでなぁ
https://blog.thenets.org/how-to-install-mysql-and-phpmyadmin-with-docker/

709 ：デフォルトの名無しさん：2019/04/09(火) 21:25:20.32 ID:U1rDoLSZ.net

docker logsは？

710 ：デフォルトの名無しさん：2019/04/09(火) 21:34:32.10 ID:U1rDoLSZ.net

CMD["mysqld"
とりま要らんやろこの引数

711 ：デフォルトの名無しさん：2019/04/09(火) 22:23:24.21 ID:3Wk1Dqbm.net

すんまへん、、何故かイケました。メモ帳に書いてコピペしてるからそう書き間違えないはずなんだがなぜかこれで
//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 ：デフォルトの名無しさん：2019/04/09(火) 22:24:25.42 ID:3Wk1Dqbm.net

ちなみにこれはなぜか動かなかった
//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 ：デフォルトの名無しさん：2019/04/20(土) 09:43:35.04 ID:4fcRoJkz.net

クラスタ運用だとボリュームの扱いが難しい

ネットワーク経由でストレージをマウントすると遅いし所有権やシンボリックリンクの取り扱いでトラブルが起きやすい
逆にローカルストレージをマウントするとコンテナを特定のホストにピン留めせざるをえなくなって運用性が悪い

どうにかならんかねこのジレンマ

714 ：デフォルトの名無しさん：2019/04/20(土) 10:01:01.50 ID:OSkkX2tB.net

>>713
だからクラウド使うんだよ

ストレージはクラウドサービスが提供しているものを使う
ストレージ用のコンテナは作らない

715 ：デフォルトの名無しさん：2019/04/20(土) 10:02:10.88 ID:OSkkX2tB.net

（ただし開発時にローカルで使うものは別）

716 ：デフォルトの名無しさん：2019/04/20(土) 11:37:12.99 ID:4fcRoJkz.net

クラウドストレージでも結局は同じなのでは？
例としてS3をVolumeとしてマウントしたとして
このVolumeはローカルストレージのVolumeよりも遅いしパーミッションとかで変なトラブルが起きやすい
この性質はイントラのストレージサービスとクラウドのストレージサービスでそう違いがあるとは思えない

717 ：デフォルトの名無しさん：2019/04/20(土) 12:03:01.10 ID:k9t7GC4v.net

S3じゃなくてEBSじゃないのか？

718 ：デフォルトの名無しさん：2019/04/20(土) 12:04:41.14 ID:OSkkX2tB.net

>>716
だからボリュームとしてマウントしたりしない。

アプリはデータをS3に保存するし、S3から取ってくる。
パーミッションとか関係ない。クラウドのセキュリティ機能を使う
クラウドストレージの速度はローカルストレージと遜色ない（コストによるが）

719 ：デフォルトの名無しさん：2019/04/20(土) 12:07:44.19 ID:OSkkX2tB.net

> アプリはデータをS3に保存するし、S3から取ってくる。

補足しておくとアプリはS3のデータを読み書きするとして、

例えばユーザーはファイルをサーバーにアップロードする時、
S3に直接アップロードするしS3から直接ダウンロードする。
アプリを経由してS3のファイルを読み書きしたりしない（してもいいが遅い）

誰でもアップロード・ダウンロードできてしまうことを
防ぐためのセキュリティ機能もS3にある

720 ：デフォルトの名無しさん：2019/04/20(土) 12:13:00.81 ID:OSkkX2tB.net

>>717
EBSを使ってもいいが、アプリの仮想マシンからブロックデバイスとしてマウントはしないんだよ。
EBSをマウントするのは（広い意味での）データベース・サーバーの一台

アプリからは、そのデータベースサーバーに対してネットワークでデータを読み書きする

複数あるアプリの仮想マシンでファイルシステムをマウント（Dockerのボリューム含む）しようという発想が古い
ストレージをマウントするのは仮想マシン1台だし、そこにネットワーク経由でアクセスする。
↑このストレージをバックアップなど含めて適切に管理するのが面倒だから、クラウドストレージを使う

いずれにしろ、アプリからはネットワーク経由でデータの読み書きをする

721 ：デフォルトの名無しさん：2019/04/20(土) 12:16:17.88 ID:4fcRoJkz.net

>>717
例として挙げただけなのでどのストレージサービスでも状況は同じ

>718
ストレージサービスをネイティヴサポートしてない他社製アプリはVolumeマウントするしかないと思うけど違うのかな？
オープンソースならフォークしてファイルアクセスを全てストレージサービスに置き換えることはできなくはないけど労力に到底見合わない
だからどうしてもVolumeマウントに頼らざるをえないケースは多々ある
そういうケースにステートフルコンテナをクラスタに組み込むにはどうするべきか悩ましい

722 ：デフォルトの名無しさん：2019/04/20(土) 12:23:55.77 ID:OSkkX2tB.net

>>721
だからな？ 新しい仕組みを活かそうと思うなら、
設計から見直さなきゃいけないんだよ。

効率化する新しい仕組みを導入したいのですが
今までの効率の悪いやり方まま変えたくないんです。

↑アホみたいだろ？

やり方を変えないなら、今までのやり方をするしか無いんだよ。
諦めな

723 ：デフォルトの名無しさん：2019/04/20(土) 12:44:59.88 ID:4fcRoJkz.net

>>722
設計を見直すと言われても他社製だからな…
従来のようにバックアップとリストアをしっかり整備して多少のリスクを受け入れるぐらいしか思い浮かばん
ダウンタイムはともかく直近のデータロストは怒られそうできつい

724 ：デフォルトの名無しさん：2019/04/27(土) 15:43:09.76 ID:baIKmTTh.net

docker hubがハックされてgitアカウントが１９万ぐらい失効されたらしい？

725 ：デフォルトの名無しさん：2019/04/27(土) 16:16:17.11 ID:yNGf8etV.net

それマ？

726 ：デフォルトの名無しさん：2019/04/27(土) 17:32:00.76 ID:kFhbr7Mc.net

取り急ぎググった結果出てきたものを貼ってみる

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 ：デフォルトの名無しさん：2019/04/28(日) 22:00:11.04 ID:tlREWRu1.net

dockerのGUIでの監視や起動停止とかでまだまともなのないかね？

728 ：デフォルトの名無しさん：2019/04/28(日) 22:10:41.17 ID:JJw12cyB.net

portainer?

729 ：デフォルトの名無しさん：2019/05/02(木) 11:48:40.72 ID:ERhnQ0op.net

DockerってEEにするとなんか嬉しいの？

730 ：デフォルトの名無しさん：2019/05/28(火) 09:41:24.81 ID:6fYBY9pC.net

>>729
サポート

731 ：デフォルトの名無しさん：2019/06/06(木) 12:33:59.71 ID:JqHKbft5.net

5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ？
VagrantfileとDockerfileのどちらが簡単かという話になるのかな？

732 ：デフォルトの名無しさん：2019/06/06(木) 20:02:59.18 ID:CyvVQuy9.net

そりゃあVagrantだろ
変なトラブルが少ない
開発デスクトップも仮想化できる
環境の再現性がたかい
Linux+Windows混在も楽々

ただしターゲットがDockerの場合に限りローカル鯖もDockerにした方がいい
それは当然のことだな
その場合でも開発デスクトップはDockerを使わないほうがいい

733 ：デフォルトの名無しさん：2019/06/06(木) 21:31:04.71 ID:jO1/nBmB.net

開発に使えないものを本番環境に投入とか論外なわけで
Dockerの使いどころが...
(それを言っちゃあおしまい)

734 ：デフォルトの名無しさん：2019/06/06(木) 21:50:38.63 ID:CyvVQuy9.net

使えるか使えないかの問題じゃなく楽かどうか
本番でDockerを使わないなら本番環境はDockerへの配慮なんてしてない構成になってるはず
その構成をローカルに再現するときにDockerを使うかVagrant/Ansible使うのどっちが工数少ないかってことだ
少なくとも本番環境の構築手順書があるのだから完全仮想化環境で同等の環境を再現するのはさほど難しくない
しかしDockerだとどうしても構成の整理と手順書の読み替えと動作確認が求められてくるので面倒だ

735 ：デフォルトの名無しさん：2019/06/06(木) 22:06:41.88 ID:ud71ci3d.net

なるほど

736 ：デフォルトの名無しさん：2019/06/06(木) 22:37:50.73 ID:XICmRaWP.net

>>731
> 5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ？

何度も言ってるが、仮想マシン（Vagrant）とアプリ仮想化（Docker）は
組み合わせて使うものです！

どちらか一方を使うんじゃない。役目が違うんだから両方使う

737 ：デフォルトの名無しさん：2019/06/06(木) 22:53:48.83 ID:XICmRaWP.net

大前提としてな。開発環境と本番環境は同一に出来ないんだよ。
可能不可能の話じゃなくて、そんな事やるやつは馬鹿という意味で同一に出来ない

開発環境はVagrantで作るが本番環境はAnsibleなどで作る
開発環境には便利なテキストエディタやIDE、ヘッダファイル、静的解析ツール
その他便利なコマンドなど、いろんなものを入れる必要がある。


それに対して本番環境はそれらは入れない。セキュリティリスクにつながるし
メンテナンス性も考えなるべく小さなイメージにしておく


開発環境と本番環境は同一でないという前提で、
開発環境でどうやってテストするか？という話が出てくる
本番環境に近い環境でないとテストに自信が持てないのは当然

そこでDockerがでてくるんだよ。開発環境で動かすDockerコンテナと
本番環境で動かすDockerコンテナを同一に（もしくは限りなく近く）することで
開発環境と本番環境が違っていても、信頼性のあるテストが実行できる

そうするとDockerコンテナさえ同じであれば、開発環境を統一する意味もなくなる
開発環境がLinuxであってもWindowsであってもMacであっても、
同一のDockerコンテナを使うのだから、信頼性のあるテストが実行できる

だから今はVagrantを使って開発環境を統一するメリットが減ってる。
統一したいならしてもいいが（それは開発者の自由を奪うというデメリットでもある）
統一しなくても良いのが今の開発

738 ：デフォルトの名無しさん：2019/06/06(木) 22:59:53.57 ID:CyvVQuy9.net

>>737
本番環境が全てDockerという幻想の上でしか成立しないな
本番環境がDockerでないなら開発環境でDockerを使うと逆に再現性が低下する

739 ：デフォルトの名無しさん：2019/06/06(木) 23:00:18.06 ID:XICmRaWP.net

最初の質問に戻るとだな

> 5人のチームのローカル開発環境を同じにしたい場合VagrantとDockerどちらが楽だろ？

「ローカル開発環境を同じにしたいならVagrantを使う」
それと同時にDockerも使う

Dockerを使うなら、ローカル開発環境を同じにする意味はさほどない
同じにしないなら Vagrantを使わなくて良い。Dockerだけ使う

これは「ローカル開発環境を同じにしたい場合にDockerが楽」と言ってるのではなくて
「ローカル開発環境を同じにしないならVagrantはいらない」という意味
だから「ローカル開発環境を同じにしたいならVagrantを使う」ということは否定していない

使う目的が違うのだから、どちらを使うか？っていう話にはならない

740 ：デフォルトの名無しさん：2019/06/06(木) 23:01:01.11 ID:Qxsak61t.net

漏れは、Chef

741 ：デフォルトの名無しさん：2019/06/06(木) 23:02:43.90 ID:XICmRaWP.net

>>738
もう今は本番環境でDockerを使うのは常識

仮に本番環境でDockerを使わないとしても、
本番環境と同じ環境をDocker以外で作るのは困難

開発環境用VM（Vagrant）と本番環境用VM（Vagrant）の
２つを作るのは重いだけ

742 ：デフォルトの名無しさん：2019/06/06(木) 23:04:50.40 ID:XICmRaWP.net

訂正

開発環境用VM（Vagrant）と本番環境"再現用"VM（Vagrant）の
２つを作るのは重いだけ

本番環境用VMといってしまうと、これを本番環境で使うように思えてしまうので訂正
実際の本番環境はVagrantでは作らないので、本番環境そのものにはならない
高い再現性を求めるなら、開発環境でも本番環境でもDockerを使うのがベスト

743 ：デフォルトの名無しさん：2019/06/06(木) 23:07:20.25 ID:XICmRaWP.net

開発環境と本番環境が違っていても
Dockerコンテナは同じですよーっていうのが
Dockerを使うメリットなわけだ

744 ：デフォルトの名無しさん：2019/06/06(木) 23:28:00.71 ID:CyvVQuy9.net

>>741
そんな常識ないよ
あほくさ

745 ：デフォルトの名無しさん：2019/06/06(木) 23:37:25.82 ID:XICmRaWP.net

根拠なく、ないよとか言われてもなｗ

746 ：デフォルトの名無しさん：2019/06/06(木) 23:39:58.31 ID:CyvVQuy9.net

>>745
お前が言うのかそれ

747 ：デフォルトの名無しさん：2019/06/06(木) 23:41:53.19 ID:XICmRaWP.net

kubernetesとかほぼDocker前提だし

748 ：デフォルトの名無しさん：2019/06/06(木) 23:43:28.93 ID:XICmRaWP.net

vagrantは "開発環境を作るためだけ" のものだが
Dockerはソフトウェ開発全般で使う

749 ：デフォルトの名無しさん：2019/06/06(木) 23:45:35.65 ID:P4iafl1G.net

k8sのdocker依存は解消されたって聞いてたんだけど…？

750 ：デフォルトの名無しさん：2019/06/06(木) 23:46:54.32 ID:XICmRaWP.net

Vagrantはこれから使われなくなっていくよ。俺はもう使ってない。
ローカル開発環境を同じにしたい場合にはたしかに便利だが、
ローカル開発環境を同じにする必要がなくなってきてる。
そういう意味ではVagrantを使わないほうが良いと言える。

751 ：デフォルトの名無しさん：2019/06/06(木) 23:47:29.19 ID:XICmRaWP.net

>>749
依存してなくても事実上Dockerを使うのが現時点ではベストという話

752 ：デフォルトの名無しさん：2019/06/06(木) 23:51:42.77 ID:CyvVQuy9.net

>>748
Vagrantは本番環境でも使えるしDockerを使わない開発も未だに無数にある
Dockerのメリットは確かに大きいがそれなりのデメリットも同時に抱え込んでしまう
Dockerでやるべき明確な理由がないなら使う必要はない

753 ：デフォルトの名無しさん：2019/06/06(木) 23:55:24.99 ID:XICmRaWP.net

> Vagrantは本番環境でも使えるし
使えるが使わん。

754 ：デフォルトの名無しさん：2019/06/06(木) 23:56:47.52 ID:XICmRaWP.net

https://www.vagrantup.com/
Development Environments Made Easy
^^^^^^^^^^^^^^^^^^^^^^^^^^^

「開発環境を簡単に」と書いてあるんだから
本番環境で使おうとするな。想定外の使い方だ

755 ：デフォルトの名無しさん：2019/06/07(金) 00:01:11.20 ID:AQMF0uU1.net

Dockerの使い方でも変なやつがいるけど
本来想定してない用途なのに、使えそうだから使おうというのは
その技術を正しく理解してない証拠なんだよな

756 ：デフォルトの名無しさん：2019/06/07(金) 00:04:50.40 ID:ON5ugDpH.net

VagrantにできてDockerではダメな典型例だとAnsibleなど構成管理ツールの開発・テスト環境を作るときなどがあるね
当たり前だけどOSの様々な機能が制限されるコンテナは仮想マシンの代替にはなりえない

757 ：デフォルトの名無しさん：2019/06/07(金) 00:10:21.60 ID:AQMF0uU1.net

だからVagrant（というよりVM）とDockerはどちらかを使うものじゃなくて
両方組み合わせて使うものだという話になる。

AnsibleのテストするならVMを使うのが一番。各クラウドやKVM等ね。

というかAnsibleのテストでVagrantなんて使うか？
Vagrantで作ったらVagrantユーザーがいるわけで、
それは本来のAnsible実行対象マシンとは違うものになる。

758 ：デフォルトの名無しさん：2019/06/07(金) 00:14:22.59 ID:AQMF0uU1.net

× コンテナは仮想マシンの代替にはなりえない
○ （アプリケーション）コンテナはそもそも仮想マシンの代替として作られたものじゃない

759 ：デフォルトの名無しさん：2019/06/07(金) 00:20:56.20 ID:ON5ugDpH.net

>>757
組み合わせて使っても良いが
常に組み合わせて使う前提のものではない

>>758
だから君のDocker万能論はちゃんちゃらおかしいということだよ
開発環境は開発対象をよく理解して適切に選ぶこと
全部DockerでOKなんてことはありえない

760 ：デフォルトの名無しさん：2019/06/07(金) 00:32:52.21 ID:AQMF0uU1.net

あぁ、なるほど。素晴らしい気付きがあった。

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

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

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

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

（独り言）

761 ：デフォルトの名無しさん：2019/06/07(金) 00:33:40.26 ID:AQMF0uU1.net

>>759
> だから君のDocker万能論はちゃんちゃらおかしいということだよ

何度もDockerとVMは組み合わせて使うって言ってるのに、
なんで俺のことをDocker万能論者に仕立て上げようとすんのさ？

762 ：デフォルトの名無しさん：2019/06/07(金) 00:34:23.77 ID:AQMF0uU1.net

> 全部DockerでOKなんてことはありえない

そんなこと言ってない。

何度も何度もVMと組み合わせて使うって言ってるのに

763 ：デフォルトの名無しさん：2019/06/07(金) 00:45:32.53 ID:ON5ugDpH.net

そうだな万能論は言いすぎた
しかしそれでも君の主張はDockerありきが前提にっているのは確かだろ
しかし実際にはAnsibleの例のようにDockerを使いにくい環境も存在している
だから君の主張がおかしいということには変わりはない

764 ：デフォルトの名無しさん：2019/06/07(金) 00:53:40.24 ID:AQMF0uU1.net

>>763
やっぱり素でDockerを理解してないんだな・・・

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

俺はAnsibleとDockerを組み合わせて使うなんて一言も言ってない。
俺の主張？俺が何を主張したっていうんだ？

765 ：デフォルトの名無しさん：2019/06/07(金) 00:57:44.41 ID:AQMF0uU1.net

>>764の組み合わせて使うっていうのは、

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

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


俺は、DockerでAnsibleなど構成管理ツールの開発・テスト環境を作るという使い方をしろなんて
一言も主張していない

766 ：デフォルトの名無しさん：2019/06/07(金) 01:00:45.47 ID:AQMF0uU1.net

結局俺じゃなくてお前が

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

俺は最初から組み合わせて使う。両方使う。役割が違うと言ってる。

767 ：デフォルトの名無しさん：2019/06/07(金) 01:01:19.38 ID:ON5ugDpH.net

>>764
君の主張は自分のレスを読み返したら？
開発環境はとにかくDocker
Dockerなしなんてありえない
それが世界の常識
君は昨日散々そう主張していたよね
そんな主張をしたら例えばAnsibleの開発環境みたいなDockerに向かない環境もDockerで組むのかなこいつはと解釈されても仕方がないよ

768 ：デフォルトの名無しさん：2019/06/07(金) 01:02:31.60 ID:AQMF0uU1.net

>>767
お前が見返して、どこで言ってるのか指摘してくれ
俺はお前が言ってることを何一つ主張してない

769 ：デフォルトの名無しさん：2019/06/07(金) 01:03:25.33 ID:ON5ugDpH.net

>>768
ID: XICm〜のレスを読み返して

770 ：デフォルトの名無しさん：2019/06/07(金) 01:04:03.86 ID:AQMF0uU1.net

例として一つ出すなら

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

開発環境はVagrantで作るとはっきり言っている

771 ：デフォルトの名無しさん：2019/06/07(金) 01:05:19.99 ID:AQMF0uU1.net

>>769
だからそれをお前がやれって言ってる。
お前嘘つきじゃん。さっきからどれもコレも俺が主張してないことを
俺が言ったことにしようとしてさ

772 ：デフォルトの名無しさん：2019/06/07(金) 01:07:46.29 ID:ON5ugDpH.net

>>770
で、そのレスの後半でDockerを使う話に持っていってるよね
とにかくDocker
Dockerありき
それが世界の常識
それが君の主張

773 ：デフォルトの名無しさん：2019/06/07(金) 01:09:11.49 ID:AQMF0uU1.net

> で、そのレスの後半でDockerを使う話に持っていってるよね

ぽかーんｗ

スレの前半でDockerを使わない話してるよね？
お前、スレの後半しか読んでないの？
スレの後半だけで判断しちゃった？ｗ

774 ：デフォルトの名無しさん：2019/06/07(金) 01:10:05.02 ID:ON5ugDpH.net

>>771
やれもクソも君の目の前のブラウザか専ブラかをちょっとスクロールして見るだけだよ
俺がやることなど何もなく君が自分のレスを見るだけだ
それを俺が代行してやることは物理的にできない

775 ：デフォルトの名無しさん：2019/06/07(金) 01:11:18.46 ID:AQMF0uU1.net

>>774
それで？

776 ：デフォルトの名無しさん：2019/06/07(金) 01:12:44.93 ID:ON5ugDpH.net

>>773
後半を主張するための前振りだろ？
だって君の主張はDockerありきが世界の常識だもんな

777 ：デフォルトの名無しさん：2019/06/07(金) 01:14:11.19 ID:AQMF0uU1.net

>>776
何度も何度も何度もVMとDockerは組み合わせて使うと言ってる

お前が、VMとDockerはどちらか一つを排他的に使うものだって
心の底で思ってるから、俺がDockerを使うという話をすると
VMを使わないと言ってるんだって勘違いしてるんだよ。

778 ：デフォルトの名無しさん：2019/06/07(金) 01:17:08.93 ID:ON5ugDpH.net

＞もう今は本番環境でDockerを使うのは常識
＞
＞仮に本番環境でDockerを使わないとしても、
＞本番環境と同じ環境をDocker以外で作るのは困難
＞
＞開発環境用VM（Vagrant）と本番環境用VM（Vagrant）の
＞２つを作るのは重いだけ

ほーん
Ansibleの本番環境と同じ環境もDockerで作るんだ
なんたってDocker以外で作るのは困難だからなー
それが世界の常識ってやつですかそうですか

779 ：デフォルトの名無しさん：2019/06/07(金) 01:17:57.25 ID:AQMF0uU1.net

> Ansibleの本番環境と同じ環境もDockerで作るんだ

また俺が言ってないことを言い出した。

780 ：デフォルトの名無しさん：2019/06/07(金) 01:19:09.37 ID:ON5ugDpH.net

>>777
VMを使わないことではなくDockerを使うことが前提になっている点がおかしいと言ってる

781 ：デフォルトの名無しさん：2019/06/07(金) 01:21:29.74 ID:ON5ugDpH.net

>>779
言っているも同然なんだよね

782 ：デフォルトの名無しさん：2019/06/07(金) 01:25:19.32 ID:ON5ugDpH.net

>>778
やっぱりこの辺りは反論不能なんだな

783 ：デフォルトの名無しさん：2019/06/07(金) 01:36:24.78 ID:AQMF0uU1.net

>>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 ：デフォルトの名無しさん：2019/06/07(金) 01:37:41.38 ID:AQMF0uU1.net

>>782
何に反論すれば良いのさ？ｗ
お前の書いた嘘？

785 ：デフォルトの名無しさん：2019/06/07(金) 12:34:44.50 ID:Ka/jlwAK.net

ぬるぽ

786 ：デフォルトの名無しさん：2019/06/07(金) 22:36:12.94 ID:hLrjlnDV.net

がっ

787 ：デフォルトの名無しさん：2019/06/07(金) 22:55:03.79 ID:wtNNzOUb.net

そのゲームのプロセスID か何かを取得して、

OS・ディスプレイマネージャーに対して、
そのゲームを最前面に表示するように、命令できないの？

788 ：787：2019/06/07(金) 22:56:06.04 ID:wtNNzOUb.net

>>787
誤爆です！

789 ：デフォルトの名無しさん：2019/06/22(土) 17:52:08.66 ID:V6ijG4k6.net

dockerってメモリ4GB だと重いですか？docker使って仮想環境作る勉強したいんですが

790 ：デフォルトの名無しさん：2019/06/22(土) 18:00:43.74 ID:rnpNzk5p.net

>>789
Linuxで使えば仮想マシンも不要でネイティブに動く
メモリも数MB程度のオーバーヘッドだけですむだろう

791 ：デフォルトの名無しさん：2019/06/22(土) 18:43:07.03 ID:V6ijG4k6.net

Windows環境なんでwslでubuntuはインストールしたんですけどそのままdocker落として仮想マシン構築する事出来ます？

792 ：デフォルトの名無しさん：2019/06/23(日) 08:00:41.13 ID:P8H0jYp7.net

Windows 10デスクトップだと4Gは厳しい
仕事で仕方なく使ってるけどメモリ不足で起動失敗が多発する
Windowsコンテナのプロセス分離だけに限定すればいけるかもしれんが…
Winコンテナは興味なくて検証したこともない

WSLでDockerは動かない
次の大型アップデートでWSL 2が実装されるけどそっちではDockerも簡単に動かせる
Docker for WSL 2のサポートも決定事項
こっちの必要スペックはわからん

793 ：デフォルトの名無しさん：2019/06/23(日) 17:24:00.79 ID:p0iHiqR8.net

今のvirtualbox使ったwindows dockerはクソだと思うが
Docker for WSL 2 は期待していいんでないかな。

794 ：デフォルトの名無しさん：2019/06/23(日) 18:27:13.63 ID:oVYNIjpt.net

今のDocker for WindowsはVirtualBoxなんざ使ってねぇぞ

795 ：デフォルトの名無しさん：2019/06/23(日) 19:06:11.98 ID:MSRPr+EY.net

Docker for Windowsも、Docker for Macも
どちらも仮想マシンを使っています

796 ：デフォルトの名無しさん：2019/06/24(月) 09:14:27.09 ID:dhWW1aIx.net

virtualbox使ってるのはdocker toolboxの方

797 ：デフォルトの名無しさん：2019/06/26(水) 06:40:02.02 ID:LU29nklf.net

てか現状、hyper-vない環境のが多い訳でwinでdockerいうたらそれだよね。

798 ：デフォルトの名無しさん：2019/06/26(水) 10:19:06.41 ID:tKP4UJlx.net

10proに入ってんじゃん

799 ：デフォルトの名無しさん：2019/06/28(金) 05:11:22.48 ID:tO2lJYIL.net

なるほど、10pro買えと。

800 ：デフォルトの名無しさん：2019/06/28(金) 07:41:19.81 ID:CM5w69Yd.net

wsl2のアーキテクチャ、hyper-v必須に見えるんだけどhome切り捨てか？

801 ：デフォルトの名無しさん：2019/06/28(金) 08:25:14.99 ID:gNXTX/eF.net

はぁ、homeも対応するって発表しただろ
hyper-vのサブセットを提供するって。少しは調べろよ

802 ：デフォルトの名無しさん：2019/06/28(金) 11:26:39.93 ID:fSH27hWb.net

>>801
マジかサンキュー！
俺の調査完了だぜｗ

803 ：デフォルトの名無しさん：2019/06/29(土) 14:03:16.24 ID:LzChV7lM.net

Windows10 Home
HP ENVY Ryzen7 3700U を使用しています。

https://dotup.org/uploda/dotup.org1884129.png
BIOSの方で仮想化設定をONにして、タスクマネージャーで確認しても「仮想化 有効」に
なっているのにかかわらず、Docker Quickstart Terminal を起動すると
「仮想化がenableになっていません。」とエラーが出て終了してしまいます。
どうすれば通常通り起動できるようになるでしょうか。
どなたか心当たりある方いらしたらお教えいただけないでしょうか・・・。

804 ：デフォルトの名無しさん：2019/06/29(土) 17:19:36.77 ID:/BkVpaGH.net

>>803
Docker Toolboxは古い
Docker Desktop for Windowsを使え

805 ：デフォルトの名無しさん：2019/06/29(土) 18:13:54.06 ID:/KvGohzC.net

HomeじゃHyper-V使えないし

806 ：デフォルトの名無しさん：2019/06/29(土) 19:25:19.90 ID:8bAr7lLW.net

wsl2まで待つかwin10pro買うかどっちかを勧める。

807 ：デフォルトの名無しさん：2019/07/06(土) 00:04:09.57 ID:qTbAmWeM.net

dockerのimageファイルをブラウザからダウンロードできるサイトないですか？

特殊なインターネット接続なし環境で構築しており，インターネット接続環境はブラウザしか起動できない状況です。

808 ：デフォルトの名無しさん：2019/07/06(土) 04:45:25.56 ID:O76mcSig.net

docker pullのプロトコルはhttpやろ

809 ：デフォルトの名無しさん：2019/07/06(土) 04:48:09.21 ID:O76mcSig.net

っていうか、業務に必要なことなら、必要って言えばいいだろ
仕事で苦労してる責任が管理者にあるなら管理者に責任を押し付けろや。
コストがあがったのはあんたが認めないからです。責任はあんたにありますって

810 ：デフォルトの名無しさん：2019/07/06(土) 07:50:05.40 ID:lAN9BSHL.net

小さい組織の末端の開発者ならそれでいいかもしれん
大きな組織だと特定の開発者のコストを下げても必ずしも全体のコストが安くなるわけではない

811 ：デフォルトの名無しさん：2019/07/06(土) 08:21:03.64 ID:O76mcSig.net

大きな組織だと、その判断を末端の開発者がしてはいけない。

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

上に投げつけて、上の責任にするんだよ。

812 ：デフォルトの名無しさん：2019/07/06(土) 08:44:23.73 ID:auWtVfNl.net

>811
理屈はわかるがそんなこと実際にするのはかなり丁寧に組織的根回ししないと無理だろ。
そんなことができるくらいならこんなとこに相談こねーわ。

813 ：デフォルトの名無しさん：2019/07/06(土) 09:12:48.48 ID:O76mcSig.net

イミフ。上に言うだけやろ。こういうことで困ってますって。

814 ：デフォルトの名無しさん：2019/07/06(土) 09:17:32.46 ID:lAN9BSHL.net

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

815 ：デフォルトの名無しさん：2019/07/06(土) 09:23:00.60 ID:O76mcSig.net

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

816 ：デフォルトの名無しさん：2019/07/06(土) 10:25:15.17 ID:auWtVfNl.net

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

817 ：デフォルトの名無しさん：2019/07/06(土) 11:40:56.15 ID:O76mcSig.net

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

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

818 ：デフォルトの名無しさん：2019/07/06(土) 11:49:06.19 ID:lAN9BSHL.net

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

819 ：デフォルトの名無しさん：2019/07/06(土) 13:09:27.76 ID:O76mcSig.net

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

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

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

820 ：デフォルトの名無しさん：2019/07/06(土) 13:18:23.10 ID:lAN9BSHL.net

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

821 ：デフォルトの名無しさん：2019/07/06(土) 13:27:42.39 ID:O76mcSig.net

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

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

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

822 ：デフォルトの名無しさん：2019/07/06(土) 13:32:36.26 ID:lAN9BSHL.net

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

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

823 ：デフォルトの名無しさん：2019/07/06(土) 13:43:30.71 ID:O76mcSig.net

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

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

824 ：デフォルトの名無しさん：2019/07/06(土) 13:58:40.05 ID:lAN9BSHL.net

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

825 ：デフォルトの名無しさん：2019/07/06(土) 14:51:35.13 ID:O76mcSig.net

> 蒸し返されても困る

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

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

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

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

826 ：デフォルトの名無しさん：2019/07/06(土) 14:57:30.90 ID:lAN9BSHL.net

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

827 ：デフォルトの名無しさん：2019/07/06(土) 15:20:41.61 ID:FpOYjoW/.net

スレチ

828 ：デフォルトの名無しさん：2019/07/06(土) 21:48:53.04 ID:auWtVfNl.net

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

829 ：デフォルトの名無しさん：2019/07/06(土) 22:15:52.49 ID:TeKNePWD.net

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

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

830 ：デフォルトの名無しさん：2019/07/06(土) 22:50:33.13 ID:O76mcSig.net

せや、せーや（笑）

831 ：デフォルトの名無しさん：2019/07/17(水) 07:53:46.72 ID:CjuPNITa.net

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 ：デフォルトの名無しさん：2019/07/17(水) 08:54:52.34 ID:ycSiezB+.net

WindowsでVOLUMEは鬼門・・・

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

833 ：デフォルトの名無しさん：2019/07/19(金) 03:11:40.54 ID:X9aaaJRs.net

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

834 ：デフォルトの名無しさん：2019/07/31(水) 22:03:01.15 ID:2Qswnptj.net

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

835 ：デフォルトの名無しさん：2019/08/03(土) 10:08:06.93 ID:CPHAUpDJ.net

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

836 ：デフォルトの名無しさん：2019/08/03(土) 12:03:27.90 ID:eOXqQaf9.net

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

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

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

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

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

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

837 ：デフォルトの名無しさん：2019/08/03(土) 12:10:05.93 ID:eOXqQaf9.net

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

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

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

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

838 ：デフォルトの名無しさん：2019/08/03(土) 14:13:39.93 ID:CPHAUpDJ.net

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 ：デフォルトの名無しさん：2019/08/03(土) 14:32:11.81 ID:eOXqQaf9.net

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

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

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


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

840 ：デフォルトの名無しさん：2019/08/03(土) 14:42:55.01 ID:CPHAUpDJ.net

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

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

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

841 ：デフォルトの名無しさん：2019/08/03(土) 15:03:33.81 ID:eOXqQaf9.net

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

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

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

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

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

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

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

842 ：デフォルトの名無しさん：2019/08/03(土) 17:32:10.41 ID:6VgdIlHS.net

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

843 ：デフォルトの名無しさん：2019/08/03(土) 18:19:12.64 ID:eOXqQaf9.net

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

844 ：デフォルトの名無しさん：2019/08/03(土) 19:02:06.52 ID:+6ISjjVu.net

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

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

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

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

845 ：デフォルトの名無しさん：2019/08/03(土) 19:06:12.83 ID:+6ISjjVu.net

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

846 ：デフォルトの名無しさん：2019/08/03(土) 19:25:54.27 ID:eOXqQaf9.net

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

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

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

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

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

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

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

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

847 ：デフォルトの名無しさん：2019/08/03(土) 20:16:39.33 ID:+6ISjjVu.net

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

848 ：デフォルトの名無しさん：2019/08/03(土) 20:17:37.72 ID:eOXqQaf9.net

>>847
なんかレスしろよｗ

849 ：デフォルトの名無しさん：2019/08/03(土) 20:20:07.16 ID:+6ISjjVu.net

>>846
でそのDockerfile使った方法がクソッタレだから馬の骨がサードパーティツールとか使い出してしまった
これは明らかに公式の失態だな
さっさとマルチプロセス管理の仕組みを提供すべきだった

850 ：デフォルトの名無しさん：2019/08/03(土) 20:20:28.44 ID:+6ISjjVu.net

>>848
なんかレスしろよw

851 ：デフォルトの名無しさん：2019/08/03(土) 20:22:53.38 ID:eOXqQaf9.net

> でそのDockerfile使った方法がクソッタレだから馬の骨がサードパーティツールとか使い出してしまった

あぁ、出すやつは出すだろうな。
んで、使われてるのか？ｗ
誰も使わんだろ

852 ：デフォルトの名無しさん：2019/08/03(土) 20:23:18.20 ID:eOXqQaf9.net

>>850
> なんかレスしろよw
お前がなにか意味があることを言ってないのに
何にレスしろと？

853 ：デフォルトの名無しさん：2019/08/03(土) 20:26:50.56 ID:eOXqQaf9.net

結局、YAMLから公式設定ファイルへのコンバーターを使った所で
何もメリット無いわけ

みんな公式の設定ファイルを読み書きできるだろ？
（できなかったらどうやってそのアプリの動作検証をやったというのか？）

公式のドキュメントを見て、使い方を覚えて、

さあ、あとはYAMLから変換するツールの使い方の勉強だ！
対応表見るぞー！あれがこれに対応してぇ、こう書けば、こういう設定ファイルが出力されてぇ
こういう設定するにはYAMLでどう書くんだ！くそーうまく出力されない！

何がしたいのかさっぱりわからない

854 ：デフォルトの名無しさん：2019/08/03(土) 20:31:39.00 ID:+6ISjjVu.net

>>852
セルフカウンター乙

>>853
そこから間違ってるよ
公式見なくてもできるのが優れたラッパーだ
1対1で変換しただけのような二流ラッパーの話はしていないので謹め

855 ：デフォルトの名無しさん：2019/08/03(土) 21:02:22.94 ID:eOXqQaf9.net

> 公式見なくてもできるのが優れたラッパーだ

お前の言う優れたラッパーってどれよ？ｗ
それは一対一で変換しないんだろ？
そのラッパーにはラッパー特有のトラブルや制限が一切ないんだろう？
さて、優れたラッパーなんて存在するかなーｗ

856 ：デフォルトの名無しさん：2019/08/03(土) 21:06:50.88 ID:eOXqQaf9.net

例えば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 ：デフォルトの名無しさん：2019/08/03(土) 21:06:56.28 ID:k1ZymNgl.net

>>853
某エディタのAnsible拡張を導入したらオートコンプリートが効いてこりゃ便利！と感じたがメリットじゃなかったのかコレ？

858 ：デフォルトの名無しさん：2019/08/03(土) 21:11:51.11 ID:eOXqQaf9.net

Dockerfileヤダヤダ。でAnsibleを使うのだろうが、

https://docs.ansible.com/ansible/latest/modules/docker_image_module.html#docker-image-module

ところでマルチステージビルドはどうすればいいのかね？

Dockerfileでマルチステービルドをする方法はいくらでも見つかる。
Ansibleでそれをどうやるのか？を悩むんだろう？ｗ

859 ：デフォルトの名無しさん：2019/08/03(土) 21:14:05.18 ID:eOXqQaf9.net

>>857
オートコンプリートなら別にAnsibleとは無関係に使える。
例えばDockerfileのオートコンプリートだって存在する。

まああれも第三者が作ってるから、公式のバージョンアップに
ついていけないところがあったりで不完全なところがあるんだが、
オートコンプリートなら補完されないってだけで別に大きな問題にはならんな

860 ：デフォルトの名無しさん：2019/08/03(土) 21:17:17.90 ID:+6ISjjVu.net

>>855
極論マンw
一切ないとか言ったら何も使えんわ
お前本当にエンジニア？
世界中で実践運用耐えうるぐらいには問題なく使えるよ

>>856
お前は全てのバグを踏み抜く奇跡の体現者かよw
実際に遭遇して問題が表面化して解決もできないなんてバグは滅多にない
ラッパーなら迂回路はいくらでもあるからな
お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな

861 ：デフォルトの名無しさん：2019/08/03(土) 21:22:16.09 ID:eOXqQaf9.net

> 一切ないとか言ったら何も使えんわ

だからそういう間に入って変換するだけのものは
使わないほうが良いって言ってんだろ

公式が提供している、標準のやり方を使えばいいだけ


> お前が大好きな本家の設定がバグってたらほとんど打つ手ないけどな
本家がバグってるのをラッパーで回避できるわけ無いだろｗ
もし回避する方法があるなら、その方法をラッパーを使わずにやればいいだけだし

俺が言ってるのは公式が提供している標準のやり方をしろというだけ
間に変な変換ツールを入れて、その制限にぶち当たって悩まなくて良くなる

862 ：デフォルトの名無しさん：2019/08/03(土) 21:26:30.12 ID:eOXqQaf9.net

そのうちプログラミングもYAMLで書きたいとか言い出しそうなんだよなｗ

863 ：デフォルトの名無しさん：2019/08/03(土) 21:31:23.14 ID:+6ISjjVu.net

>>858
buildargsを使う
修正してモジュールにコミットする
シェル系モジュールを使う

回避する方法がいくらでもあるから安心だなぁ

864 ：デフォルトの名無しさん：2019/08/03(土) 21:32:02.04 ID:+6ISjjVu.net

>>859
他のツールは？
カバー範囲狭すぎだろw

865 ：デフォルトの名無しさん：2019/08/03(土) 21:37:49.05 ID:+6ISjjVu.net

>>861
飛行機落ちるかも怖いから乗らないって駄々こねる子供と同じだなこりゃ
大人はメリットもリスクも比べて飛行機に乗る

なんかあったら打つ手なしの飛行機じゃねえんだからリスクはさらに安く見積もって良い
ちょっとでもリスクあったら全否定ってw
本当にアセンブラマンなのかこいつ
今はまだある程度正気のようだがそのうちコンパイラも信じないとか言い出しそうだ

866 ：デフォルトの名無しさん：2019/08/03(土) 22:09:24.60 ID:eOXqQaf9.net

>>863
お前の仕事は、回避することかｗ

>>865
間に挟めてトラブルを引き起こすツールに
メリットなんか無いじゃんｗ

867 ：デフォルトの名無しさん：2019/08/03(土) 22:10:17.26 ID:eOXqQaf9.net

なんども言うが、公式のやり方をすれば
間に挟めるツールのトラブルがまるまるなくなる

非公式のやり方じゃなくて、公式のやり方をしろと言ってるだけ

868 ：デフォルトの名無しさん：2019/08/03(土) 22:10:46.33 ID:eOXqQaf9.net

あとアセンブラとコンパイラは全然意味が違うので話にならない

869 ：デフォルトの名無しさん：2019/08/03(土) 22:26:01.09 ID:+6ISjjVu.net

>>866
仕事は別だ
ごく稀に回避が必要な時にわずかな労力で回避するというだけのことだ
たったそれだけの事を過剰に恐れて便利なツールが中でやってることを全部自前でやるなんてよっぽど暇なのかな
まあ車輪の再発明も仕事といえば仕事か

870 ：デフォルトの名無しさん：2019/08/03(土) 22:27:55.21 ID:+6ISjjVu.net

>>867
省力化やメンテナンス性の向上もまるまるなくなるな

>>868
たとえとしては十分だ

871 ：デフォルトの名無しさん：2019/08/03(土) 22:56:40.59 ID:eOXqQaf9.net

> たとえとしては十分だ

的外れだからな。
所詮「第三者が作った設定ファイル形式のコンバーター」は
トラブルが起きたら変換後のオリジナルの設定ファイルを見なければ話にならん

872 ：デフォルトの名無しさん：2019/08/03(土) 22:57:33.53 ID:eOXqQaf9.net

> たったそれだけの事を過剰に恐れて便利なツールが中でやってることを

ん？それってシェル系モジュール＝シェルスクリプトでできる程度のことでしょ？ｗ

873 ：デフォルトの名無しさん：2019/08/03(土) 23:06:48.06 ID:+6ISjjVu.net

>>871
外れてないぞ
お前の意見は「データを抽象化、容易化するのは無駄(実際には無駄じゃなくメリットはある)で変換器の変換バグがあるかもだからアトミックなまま使え」だからな
機械語コードとコンパイラにもピタリと当てはまるな

874 ：デフォルトの名無しさん：2019/08/03(土) 23:10:57.32 ID:+6ISjjVu.net

>>872
それってアセンブラでもできることでしょう？

ただ出来ると簡単に出来る、うまく出来るは違うことなんだな
だから高級言語が発達した

設定も同じことだ

875 ：デフォルトの名無しさん：2019/08/04(日) 01:24:31.62 ID:2JKmG3Fw.net

>>873
俺の意見を間違えてるｗ

「不要な第三者が作った質の悪く機能不足な変換ツールを使わずに
アプリの開発者の想定通りの使い方をしろ」が俺の意見だ

876 ：デフォルトの名無しさん：2019/08/04(日) 01:25:43.22 ID:2JKmG3Fw.net

>>874
設定ファイルは同じじゃない。

YAMLで設定を書いたら、できることが減ってバグが増えてる。
それに対してメリットがない。

877 ：デフォルトの名無しさん：2019/08/07(水) 02:02:44.08 ID:wfV3IAlm.net

長いので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 ：デフォルトの名無しさん：2019/08/07(水) 02:03:07.70 ID:wfV3IAlm.net

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 ：デフォルトの名無しさん：2019/08/07(水) 02:03:56.17 ID:wfV3IAlm.net

最後までお読みいただきありがとうございました。
どなたかわかるかたいらしたら宜しくお願い致します・・・。

880 ：デフォルトの名無しさん：2019/08/22(木) 22:54:02.06 ID:op2s2rjn.net

すごいなWindowsでdocker使う人が居るんか

881 ：デフォルトの名無しさん：2019/08/22(木) 23:05:23.65 ID:9hkvIicI.net

むしろwindowsだからこそありがたい

882 ：デフォルトの名無しさん：2019/08/22(木) 23:06:47.55 ID:jOmYEIea.net

>>880
普通に使ってるけど？

883 ：デフォルトの名無しさん：2019/08/23(金) 06:33:41.15 ID:CiIDRu0Q.net

MacのDockerって仮想マシンで動いてるんだなー

884 ：デフォルトの名無しさん：2019/08/23(金) 12:03:35.29 ID:sui4vfrR.net

Docker for windowsは便利だけどwindowsコンテナは全く使ってない

885 ：デフォルトの名無しさん：2019/08/24(土) 11:10:34.44 ID:lCI+FPsg.net

helmのテンプレートってすごく汚くて読みにくい
うまくYAMLにするためにインデント数を`Indent 12`みたいにしてテンプレートで指定とか正気かよ
なんか良い代わりのやつ無いの？

886 ：デフォルトの名無しさん：2019/08/25(日) 00:00:48.85 ID:kEZWEDQL.net

helmはなんかなじめなくてkustomize使ってる

887 ：デフォルトの名無しさん：2019/08/25(日) 00:10:10.89 ID:hoACBN+G.net

クソトメライズ？

888 ：デフォルトの名無しさん：2019/08/25(日) 00:58:14.70 ID:VV5KPKj8.net

臨時雇い要員にもdockerを使わせたいのだけどよけいな権限は与えたくない時はどうすればいい？
ホストもコンテナ内も一般ユーザーのみ許可できればいいのだけどそんなことできんのかね

889 ：デフォルトの名無しさん：2019/08/25(日) 03:53:54.44 ID:hoACBN+G.net

>>888
その臨時雇い要員に専用のパソコンを与えれて
そのパソコンは自由に使っていいけど、本番環境へのアクセスは禁止すればいい

890 ：デフォルトの名無しさん：2019/08/25(日) 07:11:30.55 ID:VV5KPKj8.net

>>889
仮想端末を含めて専用のPCを用意することが出来ません
複数名でログインする端末です
機密情報を扱う別のユーザーと共有してます

891 ：デフォルトの名無しさん：2019/08/25(日) 07:27:40.02 ID:G4x5ZGgB.net

> 仮想端末を含めて専用のPCを用意することが出来ません

言い換えると、あなたの会社でまともな開発はできません。ということ
自分で、まともな開発はできないと結論を出してるんだから、そこで終わりだろう。

892 ：デフォルトの名無しさん：2019/08/25(日) 07:29:21.71 ID:G4x5ZGgB.net

だいたい、専用のPCを用意できないって
単に金が無いって言ってるだけじゃないか

金がないです。どうしたらいいですかと言われても
借金でもすれば？で終わる話

893 ：デフォルトの名無しさん：2019/08/25(日) 07:38:33.38 ID:G4x5ZGgB.net

給料を出だないほど金がないなら話は別だが
パソコンなんて数万円程度で買えるのにのに「できない」
なんてことはありえない。ようするにやる気がないだけ。

言葉は正しく使え。専用のPCを用意することができないんじゃなくて
専用のPCを用意したくない。が正しい言葉だ。

機密情報も、適当でいいって思ってるだろ。
機密情報に関してきっちりしているなら専用のパソコンに物理的に分ける。
パソコンがとても高価だった時代ならまだしも、今の時代に複数で共有なんて危険なことはしない。
個人専用のパソコンを与えてない時点で、セキュリティはザルでしかない。

自己を認識してないようだからはっきり言ってやる。
お前のところは機密情報を扱う資格がないし、守ることすら出来ない。
大切なものを守る意識も欠けてるし、やるべき正しいこともわかっていない。
今何も問題が起きてないのは運がいいだけだ。

894 ：デフォルトの名無しさん：2019/08/25(日) 07:42:07.89 ID:VV5KPKj8.net

あなたの知る限り技術的には不可能ということでしょうか？

895 ：デフォルトの名無しさん：2019/08/25(日) 07:45:18.41 ID:G4x5ZGgB.net

>>894
例えば10階建てビルを作る技術はある。
みんなそれを作るための技術と道具を持ってる。

お前は、クレーンがないんです。
技術的に不可能ということでしょうか？と聞いてる。

技術的に不可能じゃなくて、クレーンを買うことができないことが
出来ない理由だっていってんの。ちゃんと認識しろって

896 ：デフォルトの名無しさん：2019/08/25(日) 07:46:47.45 ID:G4x5ZGgB.net

目的を達成する方法はいくつもあるが
「金が無い」なら、無理じゃねと言うしか無い

897 ：デフォルトの名無しさん：2019/08/25(日) 08:00:05.20 ID:VV5KPKj8.net

つまりわからないということですね？

898 ：デフォルトの名無しさん：2019/08/25(日) 12:49:41.65 ID:ssItiA2j.net

何だこいつ

899 ：デフォルトの名無しさん：2019/08/25(日) 12:59:09.23 ID:VV5KPKj8.net

イキってるくせに質問には答えられないクズってたまに居るよねぇ

900 ：デフォルトの名無しさん：2019/08/25(日) 13:30:52.18 ID:ssItiA2j.net

お前のこと云ってんだよ

901 ：デフォルトの名無しさん：2019/08/25(日) 13:35:48.58 ID:VV5KPKj8.net

言われてるぞお前くん

902 ：デフォルトの名無しさん：2019/08/26(月) 00:04:01.79 ID:JShuaBEZ.net

個人でDockerを入れてそこで自己完結させればいいだけだろ。サーバーからコンテナのコピーで済む話。

buildをユーザ権限でやるならk8sの使えば行けるが、会社と担当者のITリテラシーレベル低そうだし諦めればw

903 ：デフォルトの名無しさん：2019/08/26(月) 00:50:09.55 ID:rnlkvQrj.net

>>902
セキュリティやってる気になってる会社には無理だろ
機密情報を扱う別のユーザーと共用してるパソコンなんて
正気の沙汰じゃない。どうせアップデートもしてないだろうし。
セキュリティ意識ゼロ

904 ：デフォルトの名無しさん：2019/08/26(月) 01:31:32.75 ID:JShuaBEZ.net

コンテナ内というのが意味不明だな。
ビルドでユーザー作れば当然管理者権限なしでも入れるが、dockerでやる事なのだろうか。

中に入る→出来る
ビルド→出来る
docker コマンド→別グループ作れば可能だが実質su

dockerはアプリ動かすツールであって、管理者以外が共有PCで立ち上げ必須な用途には向かない。巻き添えで常駐コンテナに影響するからだ。

PCに入ったあと、Dockerコマンドで機密情報を操作するコンテナを動かすルールなのだろうか。

企業によくいる、自分は詳しいと思いたい素人が管理してる感溢れていて良い。

905 ：デフォルトの名無しさん：2019/08/26(月) 02:35:23.25 ID:rnlkvQrj.net

>>904
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」

これだけ

906 ：デフォルトの名無しさん：2019/08/26(月) 02:35:28.97 ID:rnlkvQrj.net

>>904
かんたんなこと。
なんちゃってセキュリティだから決まってるのは
「root権限は禁止」

これだけ

907 ：デフォルトの名無しさん：2019/08/26(月) 06:29:32.37 ID:fuirL3l0.net

お前らってわからない時の言い訳はいつも饒舌だよねぇ
質問には答えられないくせにさw

908 ：デフォルトの名無しさん：2019/08/26(月) 06:47:45.57 ID:fuirL3l0.net

言い訳というのはちょっと違ったか
わからないことを誤魔化すためのマウンティングになると饒舌
これが正確だな

909 ：デフォルトの名無しさん：2019/08/26(月) 08:28:14.69 ID:JShuaBEZ.net

>>907
>>904に答え書いたでしょ。
buildの方はk8sやローカルリポジトリがいるのでかなり難易度高め。k8sが管理者権限だと無理だな。

ユーザー作る方は難しくない。

rootが嫌ならユーザーをdockerに入れると良い。実質suだが。他は不可能。

上2つはdockerfile書けるのが前提で、ここに書いて済むレベルの話ではない。

頑張れw

910 ：デフォルトの名無しさん：2019/08/26(月) 08:43:07.72 ID:UMd5mz1m.net

権限ちゃんと分けたかったら
Dockerじゃなくて普通にVM使うべき。
メモリーの必要量は増えちゃうけど。

911 ：デフォルトの名無しさん：2019/08/26(月) 12:49:17.98 ID:NWn2YSWg.net

「VM使ってもroot使ったダメなんですー」
「個人にパソコンを与えたとしてもrootは禁止なんですー」
「うちってセキュリティしっかりしてるでしょ？」

912 ：デフォルトの名無しさん：2019/08/26(月) 15:55:14.47 ID:aBrnjXrt.net

>>909
呆れる
k8sの話はしてないしローカルDockerの話してんの
ユーザーDockerに入れても意味ないだろ

>>910
業務上の都合で使えません

>>911
答えられないなら無理してレスしないでいいぞ？
見ててちょっと気の毒だ

913 ：デフォルトの名無しさん：2019/08/26(月) 15:58:57.84 ID:NWn2YSWg.net

× 業務上の都合で使えません
○ 業務改革したくないです。やる気ないです。

914 ：デフォルトの名無しさん：2019/08/26(月) 16:03:12.47 ID:NWn2YSWg.net

新しい道具を入れたら、それだけで改善されるって思ってるバカが多いからな
新しい道具に最適になるように「やり方」を変えないと、何もかも無駄になる。

915 ：デフォルトの名無しさん：2019/08/26(月) 22:09:26.41 ID:80nRq+Qr.net

>>912
dockerでは無理。k8sはコンテナも書き方も同じでdockerの上位互換。しかし、複雑で難易度の高め。

916 ：デフォルトの名無しさん：2019/08/26(月) 22:11:49.21 ID:80nRq+Qr.net

普通、業務で使うならk8sだと思うが。分散や冗長化がdockerではできないからね。インストールがユーザー権限で出来るしdockerfileも使える。

完全な上位互換なんだが、代わりに手軽さは一切無いw

917 ：デフォルトの名無しさん：2019/08/26(月) 23:35:27.55 ID:UMd5mz1m.net

そもそも無理な要件を期待してるんだから、要件の方を変えるべきだな。
Dockerでできることのほとんどは、Docker使わなくても手間が違うだけでできるわけだし。
無理だと分かってる要件を押し通そうとするのは無能。

押し通そうとしてるのが自分じゃなく上なら、そんな理不尽な職場は放棄して転職すべき。

918 ：デフォルトの名無しさん：2019/08/28(水) 08:51:22.17 ID:Dqewl7QB.net

macOS版のDockerで、docker buildがたまにフリーズするバグの回避方法ない？
このバグのせいでテストがまともに出来なくて困ってる。
WindowsやLinuxでは発生しない。
タイムアウト仕込んでリトライさせるしか無いかな

919 ：デフォルトの名無しさん：2019/08/28(水) 20:14:43.89 ID:mDli60SR.net

>>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 ：デフォルトの名無しさん：2019/08/28(水) 20:16:24.43 ID:mDli60SR.net

いちお捕捉
working directory直下にDockerfile置いてな

921 ：デフォルトの名無しさん：2019/08/28(水) 20:26:59.23 ID:mDli60SR.net

つうか本当にmac限定バグなのか
単に速度が遅いだけなのではと思った
for Macはディスクアクセスがやけに遅い気がする

922 ：デフォルトの名無しさん：2019/08/28(水) 20:32:44.71 ID:Dqewl7QB.net

>>919
やってないけど、関係ないわ
docker clientのバグだから

923 ：デフォルトの名無しさん：2019/08/28(水) 20:33:17.71 ID:Dqewl7QB.net

あとdocker buildのバグな

924 ：デフォルトの名無しさん：2019/08/28(水) 20:35:18.65 ID:Dqewl7QB.net

>>921
mac限定のバグ。WindowsとLinuxでは
今まで1セット100ビルドを何十回もやっていて出てなかった

925 ：デフォルトの名無しさん：2019/08/28(水) 21:15:43.36 ID:mDli60SR.net

>>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 ：デフォルトの名無しさん：2019/08/28(水) 21:57:22.78 ID:Dqewl7QB.net

>>925
それはLinux版バイナリだからうまくいくよ。
ただね、100回ビルドするだけで3分もかかるんだよ。普通なら30秒。
「1セット100ビルドを何十回もやる」ような場合はちょっと苦痛
更に言うと「Windows」でもやるのでボリュームは使いづらい
それにしてもなんでmac版だけ壊れてるかな？

927 ：デフォルトの名無しさん：2019/08/28(水) 22:01:15.18 ID:4Zzob7TG.net

ビルド100回を何度もするってのがなんか間違いを感じるのだが。

928 ：デフォルトの名無しさん：2019/08/28(水) 22:02:48.52 ID:Dqewl7QB.net

各ディストリ、言語やライブラリのバージョンの違いの
組み合わせでテストしてるから

929 ：デフォルトの名無しさん：2019/08/28(水) 22:27:45.82 ID:4Zzob7TG.net

>>928
dockerってそれをしないで済ますための仕組みなんじゃ。。

930 ：デフォルトの名無しさん：2019/08/28(水) 22:29:52.82 ID:Dqewl7QB.net

>>929
いつかhomebrewとかaptとか無くなって
全部docker上で動くようになる時代がくるといいですね^^;

931 ：デフォルトの名無しさん：2019/08/28(水) 22:32:16.66 ID:OKaAzkiN.net

kibanaで処理したら？

932 ：デフォルトの名無しさん：2019/08/28(水) 22:32:55.74 ID:OKaAzkiN.net

kanikoの間違い

933 ：デフォルトの名無しさん：2019/08/28(水) 22:37:10.79 ID:4Zzob7TG.net

なんか話がおかしい。
確かにホストの方はどうにもならんことはあるだろうが、
ゲストの中身をいろいろなディストリビューションで実装する意味が分からん。

934 ：デフォルトの名無しさん：2019/08/28(水) 22:42:10.97 ID:Dqewl7QB.net

ゲストの中身をいろいろなディストリビューションで実装するなんて言ってないぞ
いろんなディストリビューションで（Dockerを使わずに）動かすんだよ。

例えばいろんなディストリで動くバイナリを生成するコンパイラの開発

935 ：デフォルトの名無しさん：2019/08/28(水) 22:43:42.14 ID:Dqewl7QB.net

「いろんなディストリでビルドできて正常に動くことの確認」の方がわかりやすいか？

936 ：デフォルトの名無しさん：2019/08/28(水) 22:59:13.43 ID:4Zzob7TG.net

だったらホストは無理にmac使う必要ないんでは？

937 ：デフォルトの名無しさん：2019/08/28(水) 23:01:14.04 ID:Dqewl7QB.net

>>936
そうだよ？だからWindowsでもLinuxでも問題なくビルドできたので
今まで気づかなかった。だけど出かける時もありノートでも作業できるようにしたいわけ

それにしてもMac版だけdocker buildがフリーズすることに誰も気づいてないのかな？

938 ：デフォルトの名無しさん：2019/08/28(水) 23:03:54.16 ID:4Zzob7TG.net

いやクラウド環境でも社内サーバーでも勝手に使ってやりゃいいじゃん。。
macにそこまでなんでこだわるかね。。

939 ：デフォルトの名無しさん：2019/08/28(水) 23:24:16.17 ID:OKaAzkiN.net

>>937
githubのissueで調べるか出した方が良いのでは。

windowsとmacだとk8sの不具合が認識されていて、ネットワーク割当が原因と分かっているが、2年経っても治ってない。

dockerやk8sは基本的にLinux用。
後のOSは有志中心の開発だから不具合多い、と思った方が良い。

940 ：デフォルトの名無しさん：2019/08/28(水) 23:32:48.79 ID:OKaAzkiN.net

ただ、ビルドを何周も回して動作確認する用途は明らかに本来の用途外だからどうかな。dockerではなく、メモリなどOSのオーバーヘッドかもしれないし。

941 ：デフォルトの名無しさん：2019/08/28(水) 23:41:21.60 ID:Dqewl7QB.net

> ただ、ビルドを何周も回して動作確認する用途は明らかに本来の用途外だから

CircleCI全否定？（笑）

942 ：デフォルトの名無しさん：2019/08/28(水) 23:45:14.48 ID:Dqewl7QB.net

並列でビルドしているわけじゃないんだからメモリはありえないし、
Mac版のdockerサーバーは仮想マシンのLinux上で動いてるんだから
Mac版のdocker clientの問題だろうね

943 ：デフォルトの名無しさん：2019/08/28(水) 23:52:23.20 ID:mDli60SR.net

マルチプラットフォームで動作保証したいならDockerは使わずに実機か仮想マシン使った方がいいと思うけどな
Dockerで動いても生ホストでの動作保証にはぜんぜんならないでしょう(逆も然り)

944 ：デフォルトの名無しさん：2019/08/28(水) 23:56:02.47 ID:OKaAzkiN.net

>>941
自分がやる時は中で操作して、動作をメモしてCIに移植するから、何周もビルドする事は無いな。遅いし。

945 ：デフォルトの名無しさん：2019/08/28(水) 23:57:25.96 ID:OKaAzkiN.net

>>942
繰り返しになるが、Githubで聞いてくれ。
推論を重ねても意味がない

946 ：デフォルトの名無しさん：2019/08/28(水) 23:58:06.35 ID:Dqewl7QB.net

CIは待ち時間が入るから遅いんだよね

947 ：デフォルトの名無しさん：2019/08/28(水) 23:59:26.35 ID:Dqewl7QB.net

Mac版Docker clientが悪いのは推論じゃなくて事実だよ

948 ：デフォルトの名無しさん：2019/08/29(木) 00:21:40.39 ID:PDsNQoqu.net

Open Stack にも、オーケストレーションのHeat、
コンテナ・オーケストレーションのMagnum とかある

Magnumは、Docker Swarm, k8s, Apache Mesos と連携する

949 ：デフォルトの名無しさん：2019/08/29(木) 00:50:21.95 ID:Kom8vkJp.net

>>947
必要なのは悪者探しではなく、対策でしょ。内容的にstackoverflowでも回答無いと思う。

950 ：デフォルトの名無しさん：2019/08/29(木) 05:29:15.00 ID:IbMmBKe3.net

まあ正直ツマラン流れだったな。情報小出しでもう少しマカがファビョって
荒れると面白かったんだが。面倒になったからさっさと終わらせるわ

再現コード、十数回でフリーズすると思うが、極稀に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 ：デフォルトの名無しさん：2019/08/29(木) 05:32:22.57 ID:IbMmBKe3.net

対策は19.03専用の機能は使ってないのでクライアントだけ18.09を使うことにした。
バイナリ配布されてるから~/binにでも入れるだけ。
世の中がバグに気づいてなおるのを待つことにする
githubへは面倒なので、だれかやって

952 ：デフォルトの名無しさん：2019/08/29(木) 05:34:21.45 ID:PDIn7KyT.net

volume先のゲストのhtmlファイルをホストのブラウザからlocal host 3000で接続して
htmlの内容がブラウザに表示されたまではいいんだけど
htmlを編集してもブラウザが更新されてくれない(リロードしても編集前と同じ画面）
再度npm startするとちゃんと編集後のコードで更新されているんだけど、
少しの編集でも逐一チェックしたいのでとても不便・・・どうすればブラウザでも随時更新されるようになるのかな？？
手探りで、docker build時に -no--chace=trueを付けてみても駄目だった

953 ：デフォルトの名無しさん：2019/08/29(木) 05:37:03.90 ID:IbMmBKe3.net

ふぅ、せっかく荒らして遊ぼうとしてるのに邪魔しないでくれないかな
docker関係ないだろ

954 ：デフォルトの名無しさん：2019/08/29(木) 08:46:05.78 ID:7sVXLGAA.net

言ってることが糞野郎過ぎて話にならん。

955 ：デフォルトの名無しさん：2019/08/29(木) 08:59:52.46 ID:4t3Jo3Qx.net

macOSネイティブ版で苦労するより
VMware Fusionでも買って Ubuntu でも入れて
出先のMacノートではそれで開発すれば？って気がするな。
下手するとネイティブより速かったりして。

956 ：デフォルトの名無しさん：2019/08/29(木) 09:26:46.62 ID:IbMmBKe3.net

>>955
それな。MacのCLIってなんであんなに遅いんだろう？
WSLと大差ない。WSLができてMacで開発するメリット無くなったわ

957 ：デフォルトの名無しさん：2019/08/29(木) 09:37:55.11 ID:PDsNQoqu.net

>>952
HTML を更新後に、ウェブサーバーで再読み込みするとか、再起動すれば？

958 ：デフォルトの名無しさん：2019/08/29(木) 09:42:53.10 ID:4t3Jo3Qx.net

カーネルでのファイルシステムキャッシュとかの性能最適化が遅れてるんじゃない?

Windowsも遅いからクライアントOS志向だとその辺で手を抜くのかね？

959 ：デフォルトの名無しさん：2019/08/31(土) 17:30:46.58 ID:W/+KbOJi.net

>>957
>>958
ありがとう〜
多分npmのキャッシュが原因なのかなぁ
nodemonっての使って更新されるようになったけど
結局はnpm startをリスタートしているだけで待ち時間が少し早くなった程度
dockerはむつかしい＾ｐ＾

960 ：デフォルトの名無しさん：2019/08/31(土) 17:40:51.37 ID:3i1dPJsj.net

docker関係ねーって言ってんだろ

961 ：デフォルトの名無しさん：2019/09/05(木) 06:20:29.29 ID:0FQt0tq4.net

マカーさんの自己顕示欲は異常だわ
Docker以前のおま環のことで荒らすなや
きくちももこ学生です並のウザさは健在

962 ：デフォルトの名無しさん：2019/09/05(木) 06:56:17.02 ID:rtvg+Hab.net

19.03.2がリリースされたけど直ってなかったな
やっぱりMacでdocker buildがフリーズする

963 ：デフォルトの名無しさん：2019/09/19(木) 16:17:59.10 ID:XZ0hpx1V.net

>>962
再現性あるならgithubにでも書いてきたら？

どういう運用かわからんけどcoreutils周りとか
同じコマンド名で挙動が違うのにひっかかってるだけじゃないかって気が

964 ：デフォルトの名無しさん：2019/09/19(木) 18:00:09.96 ID:VYOVEANP.net

>>963

これで再現するっていってんでしょ
for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done


運用が何の関係があるのかさっぱりわからん
（バグを）運用でカバーすれば大丈夫だからバグじゃない！とか言うつもり？
バグはバグだよ

965 ：デフォルトの名無しさん：2019/09/19(木) 20:20:47.02 ID:LMEHm5Z7.net

>>964
こんな便所の落書きでボヤいても直りゃしないからちゃんと報告しろっていう話よ

966 ：デフォルトの名無しさん：2019/09/19(木) 22:11:59.87 ID:VYOVEANP.net

>>965
めんどくさい、だれかやって

967 ：デフォルトの名無しさん：2019/09/20(金) 09:43:47.50 ID:Fc+ApEcD.net

>>966
再現や英語書きで2時間くらいは最低でもいるから
1人月150万円だと2万円は必要な作業なわけだがもしかしてタダで人を使おうってこと？

ホントに仕事として請け負うならやり取りのフォローアップも考慮して10万円コースよ。

968 ：デフォルトの名無しさん：2019/09/20(金) 10:26:53.20 ID:y2zR5WSk.net

>>964
ホントだな15回目で固まるわ

969 ：デフォルトの名無しさん：2019/09/20(金) 10:36:59.64 ID:y2zR5WSk.net

>>964
>バグはバグだよ

とはいえユースケースが想像しにくいテストコードでのバグってのは
みんな対応したくないもんで。

もっと重いコンテナでも同じように落ちる？
特定のコンテナだけだったりする？

970 ：デフォルトの名無しさん：2019/09/20(金) 12:48:13.37 ID:y2zR5WSk.net

https://github.com/docker/for-mac/issues/3873

これのdupeだったりしないかな

971 ：デフォルトの名無しさん：2019/09/20(金) 13:20:41.75 ID:fQRmEVoK.net

>>967
そういうこと。2万円は必要な作業を俺はやりたくないｗ

972 ：デフォルトの名無しさん：2019/09/20(金) 13:22:02.17 ID:fQRmEVoK.net

>>969
> とはいえユースケースが想像しにくいテストコードでのバグってのは

ユースケース？ docker buildのユースケースがわからないの？

docker buildを行うとｎ％の確率で固まるっていう不具合なんだけど
運が悪ければ、1回目で固まる。

973 ：デフォルトの名無しさん：2019/09/20(金) 13:23:14.51 ID:fQRmEVoK.net

>>969
> もっと重いコンテナでも同じように落ちる？
自分で試せよ。どんなイメージも関係ない
docker buildがまれにフリーズするというバグ

974 ：デフォルトの名無しさん：2019/09/20(金) 13:28:01.02 ID:fQRmEVoK.net

お、誰か書き込んでるなｗ

ただクラッシュじゃないんだよね。
おそらく排他制御とかでデッドロック状態にでもなってるんだろう
18.xまでは問題ないから19.xのBuildKit周り（の並列処理）が怪しそう

975 ：デフォルトの名無しさん：2019/09/20(金) 17:21:19.64 ID:y2zR5WSk.net

>>972

docker buildを行うとｎ％の確率で固まる
特定のコンテナに限らない
reprexは
for i in $(seq 100); do echo $i; echo FROM alpine | docker build -; done

と初めからから書くとみんな幸せだと思う

976 ：デフォルトの名無しさん：2019/09/20(金) 22:59:58.79 ID:1PmZKueH.net

>>918で書いてるぞ
> macOS版のDockerで、docker buildがたまにフリーズするバグの回避方法ない？

977 ：デフォルトの名無しさん：2019/09/20(金) 23:28:50.99 ID:+K3cd4WX.net

issue出てるなら一旦待ちだろ。
kubernets関係の起動しないトラブルも2年近く治ってない。

windowsやmac版はそんなもの。

978 ：デフォルトの名無しさん：2019/09/22(日) 12:08:32.64 ID:8mgJSnoC.net

なるほどパイプラインのタイミングの問題とか全く分からず使ってるバカなんだな。

979 ：デフォルトの名無しさん：2019/09/22(日) 12:56:50.94 ID:aP0HRBTF.net

固まったり固まらなかったりすることと
パイプラインの問題（？）と何の関係があるの？

そもそも、お前が知ってるパイプラインの問題って何さ？

980 ：デフォルトの名無しさん：2019/09/25(水) 13:55:55.59 ID:vrhM55u6.net

みんなサーバサイド開発してる人が多いだろうからDockerが人気なんだろうけど、俺的には「macOSコンテナ」が欲しいな
特定のプロジェクトをビルドする環境を構築したり保存したりできたらいいのにな

981 ：デフォルトの名無しさん：2019/09/25(水) 18:21:33.20 ID:wN1JzOl2.net

Windowsは「Windowsコンテナ」があって、DockerもWindowsコンテナに対応してるけど、
macOSにはコンテナってないのか？

曲がりなりにもUnixなんだからchrootはあるはずだが、
プロセス分離するとかそれ以外の機能が足りないのか？

982 ：デフォルトの名無しさん：2019/09/26(木) 22:02:57.78 ID:NGtUWv0T.net

GUI無しで使うメリットがほぼ無いから
作る人が居ないだけなんじゃないかと

983 ：デフォルトの名無しさん：2019/09/26(木) 22:21:01.51 ID:KBLIPb+H.net

正確にはMacはGUIなしじゃ使い物にならない。
LinuxとWindowsはCUIだけでも使いものになるから
コンテナがある。という話？

984 ：デフォルトの名無しさん：2019/09/26(木) 22:40:37.29 ID:1PonavB4.net

いや、WindowsよりmacOSの方がCLIなツールは充実してるよ。
単にAppleにコンテナ技術に関するやる気がないってだけの話。

985 ：デフォルトの名無しさん：2019/09/26(木) 23:03:33.62 ID:GPBrJiCt.net

WinもWSLでLinux用CLIツール使えるようになったし、Macとそう変わらんのでは

986 ：デフォルトの名無しさん：2019/09/26(木) 23:49:38.59 ID:1PonavB4.net

・WSLは追加で入れる必要があるけどmacOSは最初から一通り入ってる
・WindowsのネイティブGUIアプリと
WSLは別のサブシステムで動いていてやり取りに制限があるのに対し、macOSのネイティブGUIアプリとCLIツールは同じ世界で動いてるのでそういう制限がない

のでmacOSの方がまだちょっとCLI環境的には強い

987 ：デフォルトの名無しさん：2019/09/27(金) 00:13:25.85 ID:VsKeB+lq.net

OS本体のコンテナ化に関する話でしょ。Macはブランドに固執してるからOSをコンテナにする事はなさそうだ。同じ理由でOSをPCで動かない設定にしてるわけだし

988 ：デフォルトの名無しさん：2019/09/27(金) 00:16:23.44 ID:gw9G43bu.net

>>986
> ・WSLは追加で入れる必要があるけどmacOSは最初から一通り入ってる

MacのCLIはApple非公式のHomebrewを別途入れないとまったく使い物にならんぞ

989 ：デフォルトの名無しさん：2019/09/27(金) 00:26:49.54 ID:gUp/eX0U.net

今Macで開発してるような技術者はUnixやCUIが好きだからWindowsよりMacを選んでると思うね
となると仮想Linuxベースになろうが抵抗感が無いからMacネイティブへの需要はなかなか少なくんじゃないのかなぁ

990 ：デフォルトの名無しさん：2019/09/27(金) 00:34:34.08 ID:gw9G43bu.net

重要なのはいまMacで開発してる人じゃなくて
今Linux向けアプリ（クラウド関係はゲームも含めてほぼ全て）を
作ってる人はLinuxを選ぶってことだよ。
MacはBSD系だから今の時代少数派に分類される

991 ：デフォルトの名無しさん：2019/09/27(金) 00:36:42.95 ID:gw9G43bu.net

BSD→Linuxは割と簡単
Linux→BSDはストレスが溜まる

なぜならBSDのコマンドはLinuxのものと比べて低機能だから。
さらにLinuxの情報が使えない上にBSDの情報が少ない
BSDといってもFreeBSDとかとも違うから実質Macだけの情報しか使えない

992 ：デフォルトの名無しさん：2019/09/27(金) 01:09:54.72 ID:QYhXKz12.net

>>988
まったくというわけでもない。
WSLなしのWindowsに比べれば、素のmacOSの方が100倍くらいは便利。

993 ：デフォルトの名無しさん：2019/09/27(金) 04:35:44.43 ID:vRUnFoYy.net

>>991
>BSD→Linuxは割と簡単
>Linux→BSDはストレスが溜まる
>
>なぜならBSDのコマンドはLinuxのものと比べて低機能だから。
一丸には言えない

>さらにLinuxの情報が使えない上にBSDの情報が少ない
manが読めない人にはそうかもね

BSD→Linuxソフトウェアが古すぎて腰を抜かす

994 ：デフォルトの名無しさん：2019/09/27(金) 04:48:12.80 ID:JpyEjYqI.net

なんでWSLなしのWindowsと比べるんだろう？

それってエンジンなしの自動車に比べれば
自転車のほうが速いって言ってるようなもんやでｗ

> 一丸には言えない
いえるいえる。全部低性能

> manが読めない人にはそうかもね
manもLinuxの方が多い。それにBSDだと--helpがめっちゃ少ないしｗ

> BSD→Linuxソフトウェアが古すぎて腰を抜かす
古いのって例えば何？

995 ：デフォルトの名無しさん：2019/09/27(金) 05:13:53.10 ID:vRUnFoYy.net

BSDをまともに使ったことがないのはよーくわかった
ssh,nginx,bash,zsh,tmux,mariadb,python,named,postfix,syslogd,clang,h]gccほぼ全部において古い
manが追いついてないコマンドいくつあると思ってんよ

996 ：デフォルトの名無しさん：2019/09/27(金) 05:40:42.04 ID:JpyEjYqI.net

わからないからって俺に聞くな、お前が主張しろ

997 ：デフォルトの名無しさん：2019/09/27(金) 06:05:12.94 ID:JpyEjYqI.net

BSDの何が駄目かって、POSIXで規定されてる
基本コマンドが貧弱なんだよ。
最低限しか実装されていない。
よく使う基本コマンドだから困る

998 ：デフォルトの名無しさん：2019/09/27(金) 06:23:42.35 ID:boczQ2su.net

毎日使うものだから。

999 ：デフォルトの名無しさん：2019/09/27(金) 08:13:23.51 ID:vRUnFoYy.net

busyboxとか使うと発狂すんだろな

1000 ：デフォルトの名無しさん：2019/09/27(金) 08:20:02.99 ID:JpyEjYqI.net

https://ja.wikipedia.org/wiki/BusyBox

> 1996年、ブルース・ペレンズが書いたのが起源である。Debianディストリビューション用の
> レスキューディスクにもインストーラにもなるフロッピーディスク1枚の完全なブート可能システムとして設計した

1. busyboxはLinuxのためのもの
2. BSDはレスキューディスクと比べるぐらい機能が低い

1001 ：2ch.net投稿限界：Over 1000 Thread

2ch.netからのレス数が1000に到達しました。