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

**472** · 2018/01/23(火) 13:19:10.42

472 は、誤爆

**デフォルトの名無しさん** · 2018/03/07(水) 11:05:45.94

ansible絶対殺すおじさんは最近あばれてないの？

**デフォルトの名無しさん** · 2018/03/15(木) 23:36:12.82

>>474
暴れてますよ。

**デフォルトの名無しさん** · 2018/03/24(土) 08:58:04.53

ubuntuコンテナにRDP接続したいのですがどうすればいいですか？
Xウィンドウ？とかいうのを使うらしいのですがよくわかりません

**デフォルトの名無しさん** · 2018/04/20(金) 13:09:59.38

プロフェッショナルの方、どなたか教えてください(/ω＼)

今、下記内容のdockerimageを作成したいと思っています。
　
　①　ベースのイメージ：jupyter/datascience-notebook
　②　Tensorflowを使いたい　※①にTensorflowがインストールされていないため

その為にdockerfileを下記の通り作成したのですが、
出来上がったdockerimageから作成したコンテナ上で上手くtensorflowが動きません。
※コンテナ内でpythonを起動し、そこで「import tensorflow as ts」を実行すると以下のエラーが出ます。
RuntimeError: module compiled against API version 0xc but this version of numpy is 0xa
ImportError: numpy.core.multiarray failed to import
ImportError: numpy.core.umath failed to import
ImportError: numpy.core.umath failed to import
2018-04-20 03:56:29.133557: F tensorflow/python/lib/core/bfloat16.cc:664] Check failed: PyBfloat16_Type.tp_base != nullptr
Aborted

dockerfileの内容は以下になりますが、何か間違っていますでしょうか？
もし間違っている場合は、修正内容をお教えください。m(__)m

■dockerfileの内容
From jupyter/datascience-notebook
RUN pip install --upgrade pip
RUN pip install tensorflow==1.5

**デフォルトの名無しさん** · 2018/04/25(水) 15:11:44.49

質問が続いて申し訳ありません。
もう本当の初心者の初心者で、これからローカル開発環境を構築しようというところで、
Vagrantの初期化に失敗し途方に暮れております。
海外サイト含めいろいろググりましたし、パスやユーザー名の問題もないと思います。
Invalid argument @ dir_s_mkdir - C:/Users/(user)/MyVagrant/MyCentOS/?vagrant_home (Errno::EINVAL)
と出て、初期化（Vagrantfileの作成）に失敗します。

どなたか助けてください・・

**デフォルトの名無しさん** · 2018/04/25(水) 15:29:10.25

>>478
mac買ったらいーよ
私はubuntuユーザーです。
winは色々大変

**デフォルトの名無しさん** · 2018/05/02(水) 06:04:27.72

DockerでLet's encrpt使えますか？

**デフォルトの名無しさん** · 2018/05/23(水) 19:43:15.85

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

AUPZD

**デフォルトの名無しさん** · 2018/05/24(木) 10:54:24.16

AUPZD

**デフォルトの名無しさん** · 2018/06/12(火) 19:37:05.64

windows 10 メモリ4GでDocker動かすテクニック知らん？
こいつリソース食い過ぎなんだけど

**デフォルトの名無しさん** · 2018/06/12(火) 23:47:07.15

メインマシンが4GBだったら軽蔑する

**デフォルトの名無しさん** · 2018/06/13(水) 14:37:25.86

メモリ4Gなんて１５年前の標準PCじゃん

**デフォルトの名無しさん** · 2018/06/13(水) 19:07:24.99

32GBでようやく標準装備といえる

**デフォルトの名無しさん** · 2018/06/13(水) 19:14:19.13

>>483
DockerはWindowsとLinuxではLinux仮想マシンを使う
だから設定から仮想マシンに割り当てるメモリを変更すれば良い

WSLのLinux互換機能が高くなれば、仮想マシン使わずに
ネイティブに動くのにな。まだかなー

**デフォルトの名無しさん** · 2018/06/13(水) 19:22:53.70

>>486
おいおいスパコンかよ

**デフォルトの名無しさん** · 2018/06/13(水) 19:38:30.68

>>488
スパコンの定義は1.5TFLOPS以上から50TFLOPS以上に変わったらしいで

https://ja.wikipedia.org/wiki/FLOPS
1.5TFLOPSとか発売当時で今なら中古で1万？ぐらいの
GeForce GTX 580で超えるからな

**デフォルトの名無しさん** · 2018/06/13(水) 19:47:51.58

DockerとVagrant両方使ったが、覚えることはVagrantのほうが少ないな
軽さではDockerかな

**デフォルトの名無しさん** · 2018/06/13(水) 20:05:47.54

コンテナ起動した後に初期化スクリプト走るタイプのコンテナが使いにくいんだがどうにかならんのあれ

oracledbコンテナ起動
クエリ通るまでポーリング
スキーマ構築
固定のマスタデータ投入
テスト用のトランザクションデータ投入
UI テスト開始

CIサーバーでテスト開始するまでが長すぎてもったいないと思った
初期データまで込みでイメージにしたい

**デフォルトの名無しさん** · 2018/06/13(水) 20:22:25.46

>>491
それは初期化スクリプトが問題なのではなく
データベースサーバーが起動するまで待っているから
データ込みにしてようが結局データベースサーバーが起動するまで待つ

**デフォルトの名無しさん** · 2018/06/24(日) 10:53:45.00

仮想サーバーがイメージつかめないんだよな
そもそも、vagrantって言葉の意味もわからんしな

**デフォルトの名無しさん** · 2018/06/24(日) 10:54:03.25

ジェム、ユムとか意味わからん

**デフォルトの名無しさん** · 2018/06/24(日) 13:03:06.51

Vagrant重すぎ

**デフォルトの名無しさん** · 2018/06/24(日) 14:01:24.14

>>495
スペック

**デフォルトの名無しさん** · 2018/06/25(月) 00:35:12.17

>>496
20代独身172cm65kg
石原さとみがタイプだが嫁にはしたくないタイプだな
料理下手そう

**デフォルトの名無しさん** · 2018/06/28(木) 22:59:23.81

>>496
Core i5、メモリ4GB
メモリ不足かな？

**デフォルトの名無しさん** · 2018/06/28(木) 23:56:34.54

メモリ4GBって10年前から時が止まってんのか

**デフォルトの名無しさん** · 2018/06/29(金) 07:00:02.38

業務系はどこもこんなもんだよ
経営者がITよくわかってないから設備投資には消極的
エクセルとエディタが動けば開発できるだろ贅沢言うな経費削減だって本気で考える

**デフォルトの名無しさん** · 2018/06/29(金) 17:50:31.79

金無いんだから仕方ないだろ
そんなこと言うなら俺にパソコン買ってくれ

**デフォルトの名無しさん** · 2018/06/29(金) 18:26:52.80

アマゾンからインスタンス借りれば？
端末買うよりは安いでしょ

**デフォルトの名無しさん** · 2018/06/29(金) 19:06:08.95

Dockerを使っていてもAnsibleのような仕組みはやっぱり必要なんだな
コンテナを起動した後に起動をポーリング待ちして初期設定処理を動かさなきゃならんコンテナが多すぎる
リポジトリからコードcloneしてupすればローカル開発環境のセットアップ完了なんてのは儚い夢だった

**デフォルトの名無しさん** · 2018/06/29(金) 20:38:57.27

Ansibleのようなでかい仕組みはいらないけどね。
シェルスクリプトもしくはシェルスクリプトベースのなにかで良い

あと「ローカル開発環境」の定義がきれいに定まってない気がする。
おそらく、IDEやテキストエディタを含めたものを言ってるのだろうけど
分けて考えないといけないと思う

1. ソースコードを作成する環境
2. 開発したアプリを動かす環境
3. 実行するサーバー相当の環境

**デフォルトの名無しさん** · 2018/06/29(金) 22:10:23.96

まあansでもshでもいいけど何れにせよサービス起動前とサービス起動後の設定を一元化して管理したい場合にはDockerは致命的に使いにくいってこと

**デフォルトの名無しさん** · 2018/06/30(土) 02:41:09.28

>>505
それは典型的なDockerの使い方の間違いだよ
間違ってるので、何を想定してるのかよくわからない
設定を一元管理？なんの話だそれは

正しいDockerの使い方はアプリとその実行環境を固めたアプリ・サービスを作ること
及び設定内容を埋め込むことで起動するだけで動くアプリ・サービスを作る

1. 新しく物理・仮想サーバーを用意して、
2. 環境ごとのサーバーの設定を行って、
3. アプリ・サービスを動かすのに必要な環境を用意して（必要ライブラリのインストールなど）
4. アプリ・サービスをインストールして
5. アプリ・サービスの設定を行って
6. 環境構築を完成させる

よりも

1. 新しく物理・仮想サーバーを用意して、
2. 環境ごとのサーバー設定を行って、
3. アプリ・サービスをDocker経由でインストール・起動して
4. 環境構築を完成させる

この方が楽でしょ？

特に一つのマシンで複数のアプリ・サービスを動かそうとしたとき、
そのアプリ・サービス毎に必要な環境が異なっていたら大変になる
それぞれが必要なライブラリのバージョンが異なっていて動かないとかね

**デフォルトの名無しさん** · 2018/06/30(土) 03:33:31.86

DockerもVagrantもcronが絡むと途端に使えなくなるな
仮想コンテナ系の限界だな

**デフォルトの名無しさん** · 2018/06/30(土) 04:26:22.48

>>503
あの、出来てますよ、それ
初期化待ちって、Dbの構築とかですか？

**デフォルトの名無しさん** · 2018/06/30(土) 04:29:06.89

cronも良く分からないが、使う？
動作確認だけなら、cronで叩く処理を動かせば良いような

**デフォルトの名無しさん** · 2018/06/30(土) 06:32:44.17

>>507
普通にcronからDockerコンテナ化した
プログラム実行するだけじゃん
何が使えないの？
使い方が間違ってるだけじゃないの？

**デフォルトの名無しさん** · 2018/06/30(土) 09:08:24.15

>>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のほうが楽でしょってこと

**デフォルトの名無しさん** · 2018/06/30(土) 09:32:43.17

>>508
うん、主にDB
DBに設定データを保存するパターンのアプリも必然的に同じ状況になる

もちろん自分が作ってるアプリの設定ならDBの初期化スクリプトに追記すればいいと思う
postgresなどは親切にもオフィシャルでスキーマ初期化の機構が用意されてる(oracle公式はなかったけど)

でも他人が作ったアプリではそうもいかない
DBの初期化スクリプトで初期設定データを挿入することはできるだろうけど、なにを入れればいいのかがわからない
手動で設定した後にDBを分析して、入れるべきデータを調べることはできるけど、手間がかかりすぎる
それにアプリが実行してる初期化に割り込んでデータを挿入するというのは行儀が悪い
なのでアプリが起動した後、アプリが用意したインターフェースで設定を行うことになる
管理用のREST APIが整備されてるならそれ、ブラウザでしか動かせないならSelenium、といった具合
docker execでコンテナに入ってコマンドで設定というパターンもあるけど(railsアプリに多い気がする)、設定のためだけに普段使わないフレームワークを覚える気はしない

**デフォルトの名無しさん** · 2018/06/30(土) 11:28:30.25

ドッカーはウェブアプリ専用
基本中の基本やろがい

**デフォルトの名無しさん** · 2018/06/30(土) 15:23:37.26

>>511
> ってのは1はともかく2〜5はAnsibleだけで一元管理できる
一人でプログラム作ってんのか？

アプリを動かすのに必要な、OSの環境、入れて置かなければいけないパッケージ
その他必要なライブラリはなんなのか？
それをアプリを作ってない人が把握するのは大変だよね？

それらのバージョンはアプリの開発やセキュリティパッチなどで日々変わっていく
そのたびにAnsibleをメンテナンスするのは大変
物理・仮想サーバーのAnsible構成と一体化してるから、
ローカルで動かしてみるのも大変

サーバーの環境設定と、アプリの実行環境構築は別々の作業で別々の人がやる
アプリを開発してる人は自分の責任でアプリを実行できる環境を用意しないといけない。

サーバーの設定を行ってる人（Ansibleの設定書いてる人）に、
あ、これこれのライブラリ入れてください。バージョンはこれで。
アプリのバージョン更新するんで、Ansibleであれとこれ更新してください。
え？動かない。手元ではちゃんと動いてるんですが？
ライブラリのバージョン違ってるじゃないですかー、ちゃんと入れてくださいよー
あんたのミスですよ。
なんてことあってはならない

**デフォルトの名無しさん** · 2018/06/30(土) 15:31:35.57

担当者を明確に分けるとこういうことなんだわ

1. [インフラ] 新しく物理・仮想サーバーを用意して、
2. [インフラ] 環境ごとのサーバーの設定を行って、
3. [アプリ開発] アプリ・サービスを動かすのに必要な環境を用意して（必要ライブラリのインストールなど）
4. [インフラ][アプリ開発] アプリ・サービスをインストールして
5. [アプリ開発] アプリ・サービスの設定を行って
6. [インフラ][アプリ開発] 環境構築を完成させる

担当者ごとに分けると以下のようになる

・Ansibleで設定する部分
1. [インフラ] 新しく物理・仮想サーバーを用意して、
2. [インフラ] 環境ごとのサーバーの設定を行って、
4. [インフラ] アプリ・サービスをインストールして
　（kubernetesのような運用向けオーケストレーション、または単体でDockerコンテナ起動）
6. [インフラ] 運用環境構築を完成させる

・Dockerでコンテナ化する部分
3. [アプリ開発] アプリ・サービスを動かすのに必要な環境を用意して（必要ライブラリのインストールなど）
4. [アプリ開発] アプリ・サービスをインストールして
　（Composeのような開発向けオーケストレーション、または単体でDockerコンテナ起動）
5. [アプリ開発] アプリ・サービスの設定を行って
6. [アプリ開発] 開発環境構築を完成させる

作業は明確に分かれてるんだよ
担当者が違う作業を一緒にしてしまってはいけない

**デフォルトの名無しさん** · 2018/06/30(土) 15:38:28.48

>>513
> ドッカーはウェブアプリ専用

違うよ。例えばffmpegのような多くの外部ライブラリに依存し
バージョンの違いの影響も大きくコンパイルオプションも豊富で、
権利関連の問題でどのディストリでも標準パッケージでは満足できず
かと言ってライブラリを自分でビルドすると依存関係が壊れがちになって、
すべての機能をONにしたければ自分でビルドするはめになるようなソフトは
Dockerを使うと、簡単にビルド・実行できるようになる。
自分の好きなディストリを使いつつ、ffmpegは他のディストリベースにすることができる

**デフォルトの名無しさん** · 2018/06/30(土) 17:59:07.34

サーバの環境をdocker上に作っておく
リプレースが必要になったら新しいサーバにimageを移す

古いけどファミコンのカセットを新しいサーバに刺しなおすだけ

**デフォルトの名無しさん** · 2018/06/30(土) 18:03:48.84

つまり

* Dockerの利点はアプリの依存関係のパッケージングである
　JavaランタイムなしでJavaアプリが動かせますといったことがOSレベルの依存関係でも可能

* Dockerによってパッケージングされたアプリだけではシステムとして成立しない
　Ansibleやオレオレスクリプトで別途環境構成や設定を管理する必要がある

こういうことですか?
DockerはあくまでAnsibleやオレオレスクリプトで管理される取り扱いが容易な部品に徹すると

**デフォルトの名無しさん** · 2018/06/30(土) 18:55:13.03

そもそもAnsibleとDockerって明確にセグメント違うでしょ
優劣がどうこう言うたぐいのものじゃない

**デフォルトの名無しさん** · 2018/06/30(土) 19:51:53.39

AnsibleはAnsibleだけでいいけど
DockerはAnsibleやシェルなど別途構成要素が必要
結局はここに落ち着く
>>503から進展してない

**デフォルトの名無しさん** · 2018/06/30(土) 20:01:12.07

> AnsibleはAnsibleだけでいいけど
> DockerはAnsibleやシェルなど別途構成要素が必要

え？ Ansibleでアプリ開発してんの？
普通別の言語を使うよね？
というかAnsibleでどうやってアプリ開発するのか知らんがｗ

なぜそんなに、アプリ開発の一環である
Dockerコンテナの作成を、Ansibleでやることにこだわるのか？
どうせアプリ開発は別言語でやるのに

インフラ担当は、アプリ開発をしなくていいんだよ？

**デフォルトの名無しさん** · 2018/06/30(土) 20:15:36.27

>>521
Ansibleでアプリ開発?
スマンが言ってること意味不明なので解説して欲しい

**デフォルトの名無しさん** · 2018/06/30(土) 21:01:45.05

Docker使わない場合(4step, 2lang)
【Java】 Javaアプリ開発
【Ansible】 Javaランタイムインストール
【Ansible】 Javaアプリデプロイ
【Ansible】アプリ設定

Docker使う場合(5step, 3lang)
【Java】 Javaアプリ開発
【Docker】 Javaランタイムインストール
【Docker】 Javaアプリデプロイ
【Ansible】コンテナデプロイ
【Ansible】アプリ設定

覚えること、仕事増えてるよね?

**デフォルトの名無しさん** · 2018/06/30(土) 23:50:20.38

>>523
ボケはもういいから

**デフォルトの名無しさん** · 2018/07/01(日) 00:21:42.91

>>522
だってすべてAnsibleだけでできるわけないじゃん。
インフラさんはAnsible使ってるだろうけど、
アプリ開発者は別の言語使ってるよね？

インフラさんにとっては、アプリがなんの言語で作られてようが
Dockerコンテナで実行環境毎まとまってようがどうでもいいことじゃん

重要なのはアプリを開発してないインフラさん
（＝どんな実行環境・ライブラリなどで動くかなど知らない）が
アプリに依存したことを意識せず「Dockerコンテナを動かす」という
ただそれだけのことで、サービス運用環境を作れること

専門家に任せましょう。どんな実行環境・ライブラリなどで動くかは
アプリ開発者は知ってます。それで作ってテストしてるんだから
アプリ開発者はAnsibleなんか使いません

**デフォルトの名無しさん** · 2018/07/01(日) 00:46:26.68

あとAnsibleを使えばDockerのようなことができると
思ってるようだけど、できないからな

・Dockerを使うと実行環境をアプリに組み込むことができます
・Dockerはアプリが使用するポート番号を自由に変更することができます
・Dockerは複雑なアプリ設定を単純化し、引数や環境変数で指定可能なアプリに作り変えます

所詮Ansibleは作られたアプリに対して設定を行うだけで、
Dockerのようにアプリ自体を改善・強化することはできない
アプリをDockerコンテナ化するだけでいろんなOSで動かすできるのも
アプリ自体の改善・強化の一つだな

**デフォルトの名無しさん** · 2018/07/01(日) 01:09:50.12

>>510
コンテナ内でcron動かせなきゃ意味ない
cronを含めたパッケージングがしたかったんだよぉ

**デフォルトの名無しさん** · 2018/07/01(日) 03:17:51.52

>>527
だから使い方を完全に間違ってる
Dockerはアプリに実行環境を埋め込んで、完全体のアプリを作ること
exeファイルの中にdllなどを埋め込むのと近い

あんたが言ってるのは、C言語でソースコードをビルドしてバイナリを生成して、
バイナリを実行したらcronが動くんじゃなくて、ファイルが存在するだけで
cronを動かすようにしたいって言ってるようなもの

ビルドしただけで動き出すようなプログラムなんてない
意味不明なことを言ってるってわかるだろ？

もちろんDockerコンテナを実行したら内部でcronが実行されてるっていうのなら
簡単にできるが、cronを使うまでもなく実行時間までsleepするだけで十分だな

**デフォルトの名無しさん** · 2018/07/01(日) 08:10:05.39

>>525
＞>>522
＞だってすべてAnsibleだけでできるわけないじゃん。
＞インフラさんはAnsible使ってるだろうけど、
＞アプリ開発者は別の言語使ってるよね？
アプリ開発言語は別に決まってんじゃんって常識的に考えてわからんか？

＞インフラさんにとっては、アプリがなんの言語で作られてようが
＞Dockerコンテナで実行環境毎まとまってようがどうでもいいことじゃん
そのとおり
ドウデモイイんだ
ドウデモイイので使うテクノロジーは減らしたほうがいい

＞重要なのはアプリを開発してないインフラさん
＞（＝どんな実行環境・ライブラリなどで動くかなど知らない）が
＞アプリに依存したことを意識せず「Dockerコンテナを動かす」という
＞ただそれだけのことで、サービス運用環境を作れること
ロールでいいじゃん
ロールの詳細までは別に知らなくていい(知りたければ見ればいい)

＞専門家に任せましょう。どんな実行環境・ライブラリなどで動くかは
＞アプリ開発者は知ってます。それで作ってテストしてるんだから
＞アプリ開発者はAnsibleなんか使いません
クラウドが一般化してきてプログラマでもインフラに関わらなきゃならない機会は増えてる
当然Ansibleも必須科目

**デフォルトの名無しさん** · 2018/07/01(日) 08:13:01.18

>>526
便利っちゃ便利だけど別に必須でもなんでもないよねそれ
それに逆に設定がめんどくさくなることもある(DBとか色々)

**デフォルトの名無しさん** · 2018/07/01(日) 08:27:59.52

>>528
Dockerで作った完全体のアプリ()を誰かがコントロールしてやらなければならないんだどうせなq
exeを作っただけじゃ役に立たないようにイメージを作っただけじゃ役に立たない
サービスとして起動して起動後の設定を行う必要がある
そのための基盤がAnsibleみたいな構成管理ツール
どうせAnsible使うなら最初から全部Ansibleでやりゃいいじゃんってこと
依存関係をDockerfileで解決するかPlaybookで解決するかの違いでしかない
複雑な依存関係がある場合はDockerでカプセル化するメリットがあるかもしれんがそんなのは頻繁に起こることじゃない

**デフォルトの名無しさん** · 2018/07/01(日) 09:18:18.65

bashで全部できるならbashでやるのか？
馬鹿じゃねーの？

Dockerが必要な状況ならDocker入れればいいだけで何のためにDocker使うかわかりもしないのに入れて
手順が増えるとか言う馬鹿

**デフォルトの名無しさん** · 2018/07/01(日) 09:21:29.18

問題解決や利便性のためにDockerが必要な局面もあるだろ
そういうときにDockerが使えればいいだけ

Ansibleしか使えないのに俺スゲーしたいんだろ
俺日本語だけで十分だからなんで英語やフランス語使ってるのかわからんみたいな
低レベルな自慢みたいな浅はかな感じがする

**デフォルトの名無しさん** · 2018/07/01(日) 09:26:11.80

> ドウデモイイので使うテクノロジーは減らしたほうがいい

それならAnsibleをなくしたいねｗ

だってシェルスクリプトは普段からCLIで使ってるけど
Ansibleは使わないじゃん。

シェルスクリプトはなくせないが、Ansible
はシェルスクリプトで置き換えれば無くせる

Dockerはシェルスクリプトベースだしね

**デフォルトの名無しさん** · 2018/07/01(日) 13:19:42.19

そう必要なときに使えばいいんだよ

bashだけで構成管理する大道芸はキツイ
からなんかツールないとやっていけないぞそう世界中のみんなが考えて発明されたのがAnsibleのようなツール
必要性から生まれたツールなんで必要なものなんだね

Dockerは使うと面白いのはわかるけど必要かって言われると正直別に…ってところだな
依存関係？どんだけごった煮のサーバー作る気だ？
ポート変えれます？おめでとさん
引数や環境変数で設定可能？パラメータはファイルに残そうね

**デフォルトの名無しさん** · 2018/07/01(日) 17:00:28.45

>>535
アプリに実行環境を組み込んで可搬性のあるアプリを
作るってところはまだ意味がわかってないのかな？
そこについての言及がないってことはそうなんだろうね

Ansibleで開発したアプリの設定を行うほうが大道芸
だって自社で開発したアプリにAnsibleモジュールは存在しない
自分でモジュール作るか？それともコマンド呼び出しで頑張るか？

自社で開発したアプリを動かすにはあれとこれのインストールが必要です。
バージョンが上がったので今度はそれも追加してください
設定項目が追加されてるので、それを設定するように書き換えてください
冪等性あるように作ってください
アプリのデプロイの前に、Ansibleで環境を更新してください
そうしないとアプリ動きませんから！
絶対にミスしないでくださいよ！！

はい、大道芸ｗ

Dockerを使うとそういう複雑なところが隠蔽されるんだよ
Ansibleで書くのはDockerコンテナを起動する。そのためのモジュールを使うだけ
手元でテストしたDockerコンテナを実環境でも使う。だから実行環境に違いはない。
Ansibleの定義ファイルは単にバージョン番号を変更するだけ

**デフォルトの名無しさん** · 2018/07/01(日) 17:13:48.82

まだわからんかねぇ
Dockerで完結しないってとこからは目をそらし続けるんだ
コンテナ起動するたびシェルで必死に起動後の設定とかアホくさ

そもそもそんな手順はいらない
ロール用意したんでそれ使ってくださいで終わり

**デフォルトの名無しさん** · 2018/07/01(日) 17:26:44.38

> Dockerで完結しないってとこからは目をそらし続けるんだ

どうせアプリはJava使ってありRuby使ったりするんだ、
Ansibleだけで完結することもないよ

それにお前の定義によればDocker使っても「Ansibleだけで完結」してることになるだろ
なぜって？ AnsibleのDockerモジュールを使うからだよ

お前、Ansibleでcronの設定したら「Ansibleだけでは完結しない。cronが必要」って言うか？
言わないよなぁ？ Ansibleでcron設定しようがDockerコンテナ化したアプリの設定しようが
Ansibleだけで完結してることになってるだろ

んで話を戻して、JavaやRubyなどでアプリを開発してるが
Dockerを使おうがAnsibleを使おうが、新たに別のテクノロジーを使ってるのは一緒。
ならDockerのほうが可搬性の点でもシェルスクリプトベースという点でも
メリットがあるので、Dockerを使ったほうがいい

**デフォルトの名無しさん** · 2018/07/01(日) 17:28:34.87

訂正＆補足

んで話を戻して、普段JavaやRubyなどでアプリを開発してる人が
Dockerを使おうがAnsibleを使おうが、新たにアプリ開発言語とは別のテクノロジーを使ってるのは一緒。

**デフォルトの名無しさん** · 2018/07/01(日) 17:43:06.36

必要な環境はロールでカプセル化されっからドッカーでカプセル化して二度手間にする必要はないってことな

つか
「Ansibleで完結」を拡大解釈してねえか？
アプリ開発にジャヴァやらなんやら使うからほれみろAnsibleで完結してませーんってボケにしてもあんまし面白くないぞ

Docker使っても使わなくてもAnsibleで完結してるってのはそうだな
所詮は1モジュールでしかない
逆にDocker視点で見れば全然完結してなくてDockerより大きな他の仕組みが必要になる

**デフォルトの名無しさん** · 2018/07/01(日) 17:58:47.05

kubeと組み合わせるケースはansibleだけではカバー出来んじゃろ

**デフォルトの名無しさん** · 2018/07/01(日) 18:22:53.11

Ansibleはwindowsも含めて使ったらPowerShellも覚えないといけない

**デフォルトの名無しさん** · 2018/07/01(日) 21:27:52.08

>>528
その通りだとするとcronを使ったwebシステムのパッケージングにはDockerは不向きってことになるが
だとすると俺のイメージと違うな
実行環境を含めたパッケージングの利点はまぁわかるが、ツールレベルのバイナリを使うのにわざわざビルドするのはめんどくさくない？
実行環境をパッケージングできるのはすごいアイデアだと思うよ。でも俺は例えばcatを使うのにわざわざDockerでビルドしたりしないな。そのレベルのバイナリならyumとかapt使うわ

**デフォルトの名無しさん** · 2018/07/01(日) 22:57:33.50

>>543
馬鹿か。だから自分で作ったアプリに実行環境をくっつけるんだよ
ほんとなぁ、開発者のためのツールだってわかっちゃいねぇ

**デフォルトの名無しさん** · 2018/07/02(月) 16:56:48.08

LXC 生で使ってる人いる?

**デフォルトの名無しさん** · 2018/07/03(火) 14:33:51.33

つかいたくなければ、つかわなければいい
これだけで全部解決できるわけないし

**デフォルトの名無しさん** · 2018/07/03(火) 16:29:17.64

>>544
批判的な俺だが仕事ではDocker使ってるんだよね
小規模webサイト程度ならほんと使い勝手いいわDocker
引っ越しもすげー楽

**デフォルトの名無しさん** · 2018/07/03(火) 18:13:47.17

ウェブサービスや一回走らせて終わりのコマンドと相性が良すぎるんだよなドッカー
それ以外は残念だけど面倒が増えるだけ

**デフォルトの名無しさん** · 2018/07/04(水) 00:22:44.56

> それ以外は残念だけど面倒が増えるだけ

サービスとコマンド以外に世の中に何があるんや？

**デフォルトの名無しさん** · 2018/07/04(水) 21:54:18.61

Q8Y

**デフォルトの名無しさん** · 2018/07/05(木) 09:11:51.87

ウェブアプリテスト環境をmac上のDocker環境で行っているのですが
雨が続くみたいのでリモート作業できるよう自宅のwindowsで同じ環境を構築しようと考えています

Docker上の挙動ってホストOSに依存しますか？
VMならHWレベルでエミュレートしてるので大丈夫そうですけど
Dockerの仮想化ってどのレベルでやってるんでしょうか

動かすのはスクリプト言語なのでバイナリレベルの互換性とかはそれほど影響うけなさそうですけど
通信したときのエンディアンとかはホストに依存したりするんでしょうか

やりとりはjsonのみなのでそのへんもちゃんと吸収されてるとは思うのですが
変なところではまりたくないので事前に確認したいです

**デフォルトの名無しさん** · 2018/07/05(木) 10:10:29.76

>>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やライブラリなど）を抽象化して見せているだけ

**デフォルトの名無しさん** · 2018/07/05(木) 10:12:02.23

訂正

Docker for Mac/Windowsのほうが新しく推奨だが、Hyper-VはWindows Pro以上でないと
使えないので、 "Docker for Windowsが使えない場合は" Docker Toolbox（Virtual Box）を使うしかない

**デフォルトの名無しさん** · 2018/07/05(木) 10:18:19.71

環境構築は人にたよってて
その上でjavaやPHPのコーディングするのがメインなのでちゃんと理解できてない…

今の案件がRailsなんですけど
結論からいうとwindows上のDockerでRailsを動かす同じ環境を構築するのは難しい感じでしょうか

**デフォルトの名無しさん** · 2018/07/05(木) 10:29:08.88

>>554
別に？

同じように使える。というか同じように使えるように
Docker社が頑張ってくれてる。

もともとLinuxカーネルでしか動かないのに
よくもまあこんなに頑張って対応したもんだと思うよ
WindowsやMacでも動くことの重要性を強く認識していたんだな

本番環境ではLinuxカーネル上で動かすわけで、Linux上にだけ対応するという道もあったはず。
でもWindowsやMacに対応したのは、多くの開発者の開発マシンはWindowsやMacで
開発者にとってのツールであるDockerはWindowsやMacでも使えることが重要だと考えていたのだろう

上の方にいる、誰かが作ったアプリをパッケージングして配布することだけしか考えてないやつには
わからんだろうね。だから配布するならansibleで十分じゃんという発想になってしまう。
Dockerはアプリ開発者のためのツールですから

**デフォルトの名無しさん** · 2018/07/05(木) 11:11:14.97

丁寧な回答ありがとうございます
構築してみます

**デフォルトの名無しさん** · 2018/07/05(木) 11:37:29.66

何度もすいません

インストールはできてコマンドラインからも動作させることはできたんですけど
ファイルシステムやメモリの設定はどこから行えばいいんでしょうか

mac版はランチャーがあって
Preference > Daemon > Advanced にファイルシステムの設定ファイルがかけたり
Preference > Advanced からメモリの設定ができたりしたんですけど

**デフォルトの名無しさん** · 2018/07/05(木) 12:38:07.08

>>554
素直に仮想マシンを立てて、Ansibleなど構成管理ツールを使って、本番と開発環境を可能な限り揃えたほうがいいよ
Dockerはほぼどこでも動くけど、どこでも同じように動作するわけじゃないし、トラブルが発生した時の対処手順がDockerと実機サーバーや仮想マシンとでは大きく異なる
本番も開発環境もDockerで統一するなら許容範囲内だけど、それでも環境差異のリスクはあるね

**デフォルトの名無しさん** · 2018/07/05(木) 12:51:42.85

> 素直に仮想マシンを立てて、Ansibleなど構成管理ツールを使って、本番と開発環境を可能な限り揃えたほうがいいよ

それをやると問題になるのが、（Windows or Macで）ファイルを編集して
すぐにそれを反映させるのが大変になる。いちいちアップロードなんてしてられない
開発時はソースコード書いてテスト実行という流れが1分間に数回のレベルで発生する

また開発時はデバッグ用のモジュールが必要になる。
ログの表示とかデバッガの実行とか。
本番環境と揃えるのは、開発面ですごく効率が悪い
アプリ開発してない、単に配布しかしてないやつにはそれがわからない

**デフォルトの名無しさん** · 2018/07/05(木) 13:01:45.08

>>557
Windowsもタスクトレイのアイコンから設定できるだろ？
Docker Toolboxはどうなってるのかしらんが。

**デフォルトの名無しさん** · 2018/07/05(木) 13:11:16.62

>>558は（Ansibleで構成した）仮想マシンと実機環境が同じだという前提のようだが、
その理屈だと Windows or Mac 上のDockerは仮想マシンで動いてるので
Dockerが動く仮想マシンと、Dockerが動く実機マシンは同じと言える

実際の所、Dockerイメージの中に実行環境が組み込まれているので、
Dockerイメージは、LinuxカーネルとDockerにしか依存しない
Dockerイメージは同じものを使うという前提であれば、
あとはLinuxカーネルとDockerを揃えてしまえばほとんど同じ

たとえ違っていたとしても、Linuxカーネルに関しては高い互換性が
あることが今での実績から明らかで、DockerはDockerコンテナを動かすために
使っているだけで、開発したアプリがDockerに依存しているわけじゃない
なのでLinuxカーネルもDockerもバージョンが変わったところで問題はほとんど発生しない。

環境差異のリスクがあるのはDockerを使わないからなんだ

**デフォルトの名無しさん** · 2018/07/05(木) 14:32:54.33

>>559
大変にならないよ？
もしかしてアプリ開発したことないのかな

**デフォルトの名無しさん** · 2018/07/05(木) 14:37:12.16

>>561
Dockerといえど環境バグは結構あるよ
まあ仮にDocker間で100%互換性があると譲歩したところでテスト、本番が非Dockerなら開発にDockerを使うのはリスクしかない

**デフォルトの名無しさん** · 2018/07/05(木) 15:02:48.88

>>562
じゃあWindows or Macのテキストエディタで
どうやって編集するというのかな？

**デフォルトの名無しさん** · 2018/07/05(木) 15:03:35.76

>>563
本番もDocker使うに決まってるでしょｗ
っていうか、Kubernetesとか使ったことある？
Docker前提だからね。もう大規模はDocker前提の時代になってる

**デフォルトの名無しさん** · 2018/07/08(日) 20:56:23.28

WSLでvagrantを使ってる人いる？
使い心地どうですか？

**デフォルトの名無しさん** · 2018/07/09(月) 12:21:29.06

WSL上でDocker Engineが動くようになっていたっぽいという話
https://qiita.com/yanoshi/items/dcecbf117d9cbd14af87

**デフォルトの名無しさん** · 2018/07/10(火) 10:00:57.15

GKEもECS+Fargateも使える、この世の中でdocker使わない意味もないし、さすがにmanagedに対してansible使う機会は減ってきたと言わざるを得ない

**デフォルトの名無しさん** · 2018/07/12(木) 00:18:40.48

>>564
ま、それも一理あるね
addじゃなくて、volumeで割り当てれば、host側から編集できる

**デフォルトの名無しさん** · 2018/07/31(火) 15:12:20.08

コンテナは上がってるのに

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は便利だけどブラックボックスすぎて一度問題起きると自分で全く解決できないのが辛い

**デフォルトの名無しさん** · 2018/08/05(日) 16:25:49.27

よく分からんなら問題解決なんてしないでコンテナ作りなおしちゃおーぜってのがdockerの基本中の基本
根本原因を調べないと再発するのでは？って思うかもしれんけどそのたびに作りなおせば問題ないよね

**デフォルトの名無しさん** · 2018/08/07(火) 08:55:16.65

ずっと再発してたら進まないじゃん

**デフォルトの名無しさん** · 2018/08/07(火) 23:32:53.48

>>572
だから再発するまでは問題ないんだよ
「昨日までは普通に動いてたのに」ってことはコンテナを立ててからしばらくは正常に動いてるってこと
その間だけサービスを提供してダメになったら(なりそうだったら)予備のコンテナに切り替えるってわけ
コンテナ切り替えたら元のコンテナは破棄して次の予備コンテナをスタンバらせる

**デフォルトの名無しさん** · 2018/08/08(水) 07:43:28.52

原因は調べないんでしょう？
ダメじゃん…w

**デフォルトの名無しさん** · 2018/08/08(水) 15:09:32.22

dockerの構築スクリプトも定期的にメンテしないと動かなくなることあるよ

**デフォルトの名無しさん** · 2018/08/08(水) 15:11:24.15

>>570
image-idじゃなくて、container-idをｼﾃｲｼﾅｲﾄ駄目だよ

**デフォルトの名無しさん** · 2018/08/08(水) 15:11:49.43

エラーの原因はコンテナと共にバイナリの海の藻屑となる。。。
積み重なったコンテナはやがて墓場を形成し、次第に人々はこう呼ぶようになった。。。
「どっかー(行っちゃった)の墓場」と。。。

**デフォルトの名無しさん** · 2018/08/09(木) 20:34:37.85

docker for winは登録しないとダウンロードできなくなったみたいだ

**デフォルトの名無しさん** · 2018/08/09(木) 21:19:10.45

そういやWindowsコンテナってあんま話題にならないけどどうなんだろ
XP、.NET 2.0、正体不明の自社・他社COMライブラリ、Excel.Applicationなどが仕事してる古いシステム
まるごとコンテナ化して隔離できんかな

**デフォルトの名無しさん** · 2018/08/20(月) 20:42:31.73

mysqlのdatabaseごとにマウントポイントを変更したい
どうやんの？

**デフォルトの名無しさん** · 2018/09/24(月) 10:53:33.16

Docker Hubから誰でもダウンロードできるコンテナイメージに暗号通貨採掘ボットが潜んでいた
https://jp.techcrunch.com/2018/06/16/2018-06-15-tainted-crypto-mining-containers-pulled-from-docker-hub/

オフィシャルと自作しか信用できんな

**デフォルトの名無しさん** · 2018/09/24(月) 19:46:38.93

内容読む限りKubernetesクラスタとかDockerサーバのセキュリティ甘いやつ狙ってそいつらにデプロイさせてるんだと思う
まぁ自作と公式以外信頼しないのは重要だと思うけど

**デフォルトの名無しさん** · 2018/09/25(火) 22:24:47.75

Dockerってデバッグ実行の設定が面倒っすね

**デフォルトの名無しさん** · 2018/10/10(水) 14:24:27.56

virtualboxの上で直接に動いてるLinuxと
virtualboxの上にのってるVagrant上で動いてるLinux

この２つのLinuxって挙動とか変わってきたりしますか？
C言語とかシェルスクリプトのテスト環境として全く等価なんでしょうか？

**デフォルトの名無しさん** · 2018/10/10(水) 17:09:35.61

変わるわけねーだろ。仕組みを考えろや

**デフォルトの名無しさん** · 2018/10/10(水) 17:11:43.59

>Vagrant上で動いてるLinux
Vagrantは、仮想OS ではないので、Linux は、Vagrant上で動かない

「Vagrant」で検索！

**584** · 2018/10/10(水) 17:25:45.68

>>585
>>586
理解できました
ありがとうございます！

**デフォルトの名無しさん** · 2018/10/10(水) 19:12:20.57

>>584
インストールから設定をキッチリ揃えたわけでもなければ当然ながら等価じゃないよ
無視できる差異かどうかってとこが重要
これはDockerでも同じこと
厳密に同じ環境はどうやったって作れない

**デフォルトの名無しさん** · 2018/10/10(水) 19:32:05.19

>>588
厳密に同じ環境であるかなんて聞いてないだろ

**デフォルトの名無しさん** · 2018/10/11(木) 01:15:56.61

>>588
野良boxでなければ等価だと言ってもよいのでは？

**デフォルトの名無しさん** · 2018/10/11(木) 07:15:08.44

何をもって「挙動が同じ」「等価」とするかだよね
スクリプトでハードウェア情報取得しようとすれば環境によって変わってくるだろうし
外部のWebサイトに対して自分で書いたクローラーを実行するとかなら多分「挙動が同じ」になるだろう

**デフォルトの名無しさん** · 2018/10/12(金) 12:25:02.77

コンテナ上で仮想OSは動かないということだけど、例えば「docker pull ubuntu」で取得したubuntu動かすのと仮想マシンでubuntu動かすのとの違いが良くわからない

**デフォルトの名無しさん** · 2018/10/12(金) 12:45:36.05

>>592
dockerにとってubuntuは材料に過ぎない
ubuntuという材料をベースにDockerfileを書いてアプリを作る
そういうことが簡単にできるように作られたのがdocker

**デフォルトの名無しさん** · 2018/10/12(金) 13:36:53.15

つまりubuntuっぽい(というか見た目は変わらない)動作をするアプリが動いてるだけってことか
ありがとう

**デフォルトの名無しさん** · 2018/10/12(金) 21:21:03.81

マイナーなツールでフォアグラウンド起動のしかたがわからない場合どうする？

**デフォルトの名無しさん** · 2018/10/12(金) 21:45:24.47

フォアグラウンド起動の方法がないじゃなくて
わからないだけなら、調べろとしか

**デフォルトの名無しさん** · 2018/10/13(土) 00:18:26.66

所詮はDockerって省エネを目指した仮想環境に過ぎないからね
そんなこと気にしなければVagrantがベスト

**デフォルトの名無しさん** · 2018/10/13(土) 04:06:41.09

dockerとvagrantという全く違うものを
比較している人に言われましてもｗ

**デフォルトの名無しさん** · 2018/10/13(土) 10:23:57.31

用途がかぶる部分があるので比較する意味は有る

自転車、自動車、鉄道、飛行機は全く違うものだけど、移動するためのものという用途は同じ
旅行や通勤の際にこれらを比較する価値は大いに有る
vagrantとdockerも同様

**デフォルトの名無しさん** · 2018/10/13(土) 11:20:42.44

自動車と運転手を比較してもな。

**デフォルトの名無しさん** · 2018/10/13(土) 11:20:59.09

基本的にはファイルシステムだけカプセル化してるんだっけか？
でもportなんかもカプセル化してるし、どこまでを閉じ込めてるか結構微妙。

**デフォルトの名無しさん** · 2018/10/13(土) 12:11:11.17

>>601
アプリケーションを動かすのに必要なもののうちOS以外の部分を
アプリケーションに内包させていると考えればいい

**デフォルトの名無しさん** · 2018/10/13(土) 12:14:09.83

>>599
なにかアプリを使おうと思った時、わざわざ別マシンを用意して別の環境で動かすのが仮想マシン

今自分が使ってる環境の上でアプリを起動するのがDocker

ぜんぜん違う

**デフォルトの名無しさん** · 2018/10/13(土) 13:02:00.31

>>601
そんな抽象的で意味のない答えは求めてない。

**デフォルトの名無しさん** · 2018/10/13(土) 21:33:30.23

>>603
抽象化ができないエンジニアには難しいかも知れないが
ホストと隔離された環境でなんらかのアプリを使うという抽象的な目的は同じなんだよ
基本になってるテクノロジが違うけどそこは同じ
なので比較検討することには意味が有るわけだ

例えばローカル開発環境を構築するという抽象に対してDockerあるいはVagrantという具象が有る
もちろんそういう意味ではホストに必要なパッケージをインストールするだけの素朴な構成も比較検討に値する
完全仮想化とコンテナ仮想化は違う技術だから比較に値しないなんてのは表層しか捉えられないなにもわかってない人の発想なんだね

**デフォルトの名無しさん** · 2018/10/13(土) 21:48:14.00

技術が違うんじゃなくて、目的が違う
ここまで理解能力がないと、本当に話にならない。

**デフォルトの名無しさん** · 2018/10/13(土) 22:12:07.13

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は環境構築ツールでしかない
目的が全然違っている。

**デフォルトの名無しさん** · 2018/10/13(土) 23:33:44.26

>>606
目的なんて無数にあるだろ
自分が考える目的以外の目的が存在するということすら想像できないようじゃ話にならない
本当に話しにならない

**デフォルトの名無しさん** · 2018/10/13(土) 23:37:37.63

そうやって一般論でごまかすのやめーや

Dockerが考えてる目的を書いただけの話
別の目的に使おうというのなら、使いにくいのは当然だってことだ
少なくとも仮想マシンやVagrantとDockerの目的は違っている
お前の目的の話はしてない。Dockerの目的の話をしてる。

**デフォルトの名無しさん** · 2018/10/13(土) 23:44:07.35

>>607
あらら、まだわからないのか

キミの言うところのDockerの高い可搬性を利用して、例えば開発環境を構築するという目的を達成するんだよ
そして開発環境を構築するという目的を解決する手段はDockerに限らずVagrantでもローカルでも構わない
だから比較検討して目的を達成するのにはどのテクノロジを採用するのがよいかを考えるわけだ

おそらくキミの中ではDockerはこの目的に使うもの、Vagrantはこの目的に使うもの
といったようにただ一つの絶対的な目的があるんだろうな
目的を解決する手段がいくつも有ること、ツールを使う目的はいくつも有ることに気付いていない
最低限そこに気付いてくれないと話しにならないよ

**デフォルトの名無しさん** · 2018/10/13(土) 23:51:41.18

>>609
君のレスを引用すると「Dockerは可搬性を高くするもの」
これがDockerが考えている目的なわけだ(というか君の脳内のDocker社の考える目的というべきか)

じゃあ可搬性を高くしてどうするんだ？
その先の目的がまだあるだろ？
その目的は利用者が抱える課題によって様々なんだよ

**デフォルトの名無しさん** · 2018/10/13(土) 23:52:12.52

> キミの言うところのDockerの高い可搬性を利用して、例えば開発環境を構築するという目的を達成するんだよ

自分で言ってる通りじゃないかｗ
Dockerの目的は高い可搬性を作る所まで。

Dockerを利用するってことは、別に作業があるんだろ？
その作業の目的が開発環境を構築することであって
Dockerを使う目的ではない

キミ、物事の本質を捉えられるようにならないとダメだよ

**デフォルトの名無しさん** · 2018/10/13(土) 23:53:24.28

>>611
> じゃあ可搬性を高くしてどうするんだ？
> その先の目的がまだあるだろ？

その先の目的？金を稼ぐってことかいな？
その理屈で言えば、どんな道具も目的は同じになるなｗ

**デフォルトの名無しさん** · 2018/10/13(土) 23:58:24.68

今置かれてる状況がある
また解決したい何らかの問題がある
そして解決する手段が複数ある

ここまできて比較検討しないって言っちゃなんだけど技術者失格だろう?

非常に幸運で何らかのテクノロジ一択で業務全部をカバーできる
なんて状況でもなければ必ず比較検討が必要になる

**デフォルトの名無しさん** · 2018/10/14(日) 00:00:31.63

>>614
お前が物事の本質をわかってないだけ。

Dockerの目的は可搬性を上げるためだし、
テキストエディタの目的はテキストファイルを編集するもの

開発環境を作るために、テキストエディタを使うだろと
いくら吠えたって、テキストエディタの目的が開発環境を作ることにはならないのと
同じようにDockerの目的は開発環境の作成ではない

**デフォルトの名無しさん** · 2018/10/14(日) 00:04:44.32

>>612
>Dockerを利用するってことは、別に作業があるんだろ？
>その作業の目的が開発環境を構築することであって
>Dockerを使う目的ではない

開発環境構築は間違いなくDockerを使う目的の1つ

A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」

自然だね

A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「そんなのはDockerの目的じゃない！」

アホかこいつ

**デフォルトの名無しさん** · 2018/10/14(日) 00:06:49.52

>>613
極論すればそうだな

どんな道具にも複数の利用目的が存在する
どんな目的にも解決手段は複数有る

だから比較検討するんだよ

**デフォルトの名無しさん** · 2018/10/14(日) 00:10:20.62

>>615
道具の目的は作成者や利用者の認識によって様々
テキストエディタの主目的は確かにテキストの編集だろう
だが目的はそれだけではなく人によってことなる
"誰か"の目的を押し付けるべきではない
"おまえ"の目的が全てではない
まずはこの基本的な事実から理解してくれ
話しにならないから

**デフォルトの名無しさん** · 2018/10/14(日) 00:10:43.24

> A「なんのためにDockerを採用したの?」
> B「開発環境構築のために採用しました」

採用と目的は意味が違う
はい論破ｗ

ジョークかよｗ
なんでこんな簡単な指摘をせにゃならんのだ

**デフォルトの名無しさん** · 2018/10/14(日) 00:11:59.29

ほんとさっきからDockerの目的を
違う話にすり替えようとしてるな。
バレバレやで

**デフォルトの名無しさん** · 2018/10/14(日) 00:13:40.14

>>619
「なんのために」って読めなかった？外国人？

**デフォルトの名無しさん** · 2018/10/14(日) 00:14:12.92

A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「開発環境構築してるのは見ればわかる。それを行うに当たって
なんのためにDockerを採用したのか聞いてるんだが？」

普通は後期着替え得される

**デフォルトの名無しさん** · 2018/10/14(日) 00:15:15.24

>>620
すり替えてるのはAn0DfPZDだな
Dockerの利用目的などいくらでもあるのに、開発目的の1つでしかない高い可搬性を唯一絶対の目的のように、こいつはすり替えようとしている

**デフォルトの名無しさん** · 2018/10/14(日) 00:15:16.71

例えて言うなら

A「なんのために○○工法を採用したの?」
B「建造物構築のために採用しました」

こう言ってるようなもん

**デフォルトの名無しさん** · 2018/10/14(日) 00:21:29.05

>>622
A「なんのためにDockerを採用したの?」
B「開発環境構築のために採用しました」
A「開発環境構築してるのは見ればわかる。それを行うに当たって
なんのためにDockerを採用したのか聞いてるんだが？」

B「開発環境構築手段としてはVagrantやローカル環境へのバッチ処理適用などが候補に上がりました。
弊社の置かれる状況を踏まえて、それらを比較検討した上で、これこれこういうメリットがあると判断して、採用しました」

普通はこうなる
比較検討なんかしない、などというバカだったら採用理由にも説得力がなかっただろうね

開発環境に限った話ではないが、何かを決めるにあたって、検討した選択肢と採用した理由は関係者に対して必ず説明するものだ
業務で開発したことが有るならアタリマエのことだと思うが
もしかしてキミ仕事で開発したこと無い？あるいは一人で開発してるとか？

**デフォルトの名無しさん** · 2018/10/14(日) 00:28:27.93

>>625
> 普通はこうなる

前言撤回かよｗｗｗｗ

俺が間違いを指摘した後に慌てて後付して書くなって
ほんと恥ずかしいやつやなｗ
だいたい、その「これこれこういう」の中身が目的やろうが？

ちゃんと書けよ。Dockerを使うことで可搬性が高くなるというメリットがあるので
その目的のためにDockerを採用しましたって

**デフォルトの名無しさん** · 2018/10/14(日) 00:36:36.30

>>626
>「これこれこういう」の中身が目的やろうが？
「これこれこういう」は利用者の状況や課題によって様々
だから比較検討して答えをだすって何度もレスしとるだろうが
いい加減少しは理解してくれ
話しにならないとはまさにこのこと

**デフォルトの名無しさん** · 2018/10/14(日) 20:01:17.80

なんか話が難しくなってきましたね
ひとまず、docker軽いですよ、vagrantに比べて
buildはややかかるけど、終わってしまえば、起動もさくっといきますよ

**デフォルトの名無しさん** · 2018/10/14(日) 22:23:03.56

何に使えるかと、何のための道具かってのをごっちゃにしてるやつのたわごとだからな。
Dockerはアプリケーションを仮想化するために作られた道具

その道具を使って金儲けができるからって、
いろんなものをごっちゃにしたらダメだって話

**デフォルトの名無しさん** · 2018/10/14(日) 22:25:54.86

>>628
> ひとまず、docker軽いですよ、vagrantに比べて
vagrantは開発環境を作る道具にすぎない。
Dockerと比べるものじゃない。

比較するならば、ホストマシンでアプリを動かす vs 仮想マシンでアプリを動かすだろ
ホストマシンでアプリを直接実行するほうが、仮想マシン上でアプリを動かすよりも軽い
といわれても当たり前でしか無い

**デフォルトの名無しさん** · 2018/10/15(月) 00:07:39.55

うん、だからdockerの方が軽いんだよね？
当たり前でも何でも実際軽くて便利なんだからいいじゃないか

**デフォルトの名無しさん** · 2018/10/15(月) 00:41:31.13

そりゃ仮想マシン使うよりも仮想マシン使わないほうが軽いだろう。
仮想マシン使わないで、普通にパッケージをインストールすれば良い

普通にパッケージをインストールすればいいのに
なぜDockerを使うのか？それこそがDockerを使う目的

**デフォルトの名無しさん** · 2018/10/15(月) 18:32:47.56

課題を解決する手段が複数ある
それぞれ一長一短で状況により正解は異なる
なので比較検討してどれを採用するか決める
これITに限らず一般常識ね

**デフォルトの名無しさん** · 2018/10/15(月) 18:36:41.86

んで、今話してるのは手段ではなくて
Dockerは何をする道具かということ
本質をちゃんと見れないと道具は正しく使えない

**デフォルトの名無しさん** · 2018/10/15(月) 18:41:05.65

周回遅れだね

Dockerの特性は正しく理解した上で比較検討しようという段階の話をしてるので付いてきて

**デフォルトの名無しさん** · 2018/10/15(月) 18:47:15.49

話を逸らすな。
Dockerはアプリケーションを仮想化する道具だって話をしてる

**デフォルトの名無しさん** · 2018/10/15(月) 18:55:53.84

お気の毒ですがそのような話をしているのはあなただけです
あなたはあなたが話ていることをみんなも話ているように錯覚しているようですが実は違うのです
まずは深呼吸して冷静になってください
会話が成立することを期待して待っています

**デフォルトの名無しさん** · 2018/10/15(月) 19:00:16.10

>>637
お前、自分が一人だってわかってないのか？
誰か他に同調してくれるやついるか？

**デフォルトの名無しさん** · 2018/10/15(月) 19:06:03.75

>>638
dockerとvagrant(あるいは他の方法論)を比較するという文脈のレスは私のレス以外にも幾つもありますね
比較するのはおかしいという主張はどうやらあなただけのようですが

**デフォルトの名無しさん** · 2018/10/15(月) 19:13:31.78

docker vagrant 比較
ぐぐったらたくさん出てきた
ちなみに
docker vagrant 比較するのはおかしい
ぐぐったら”おかしい”が除外されて検索された
こりゃ勝負有ったね

**デフォルトの名無しさん** · 2018/10/15(月) 19:18:29.88

>>639
それはお前の意見に同調してるわけじゃないだろｗ
頭悪いんちゃうか？

**デフォルトの名無しさん** · 2018/10/15(月) 19:19:27.50

だいたい、さんざん仮想マシンと比較って言ってくせに
vagrantに言い換えてるし
仮想マシンとvagrantの違いもわかってないようだ

**デフォルトの名無しさん** · 2018/10/15(月) 20:07:06.98

間を取ってLXCで

**デフォルトの名無しさん** · 2018/10/15(月) 20:30:22.20

間っていうか、LXCはシステムコンテナだから、Dockerで仮想マシンのような間違った使い方を
使い方をしようとしている人は、LXCを使うべきだよ

**デフォルトの名無しさん** · 2018/10/16(火) 00:27:22.18

PythonでJupyter Notebook使ったデータ解析環境をPC変更時に新PC上で手動で再現するのが面倒だからDocker上で動かすようにしてる

**デフォルトの名無しさん** · 2018/10/16(火) 00:30:53.46

Jupyter Notebookというアプリにそのアプリを動かすのに
必要なものを全部まとめてるわけだよね。
それが正しい使い方

**デフォルトの名無しさん** · 2018/10/16(火) 02:50:30.16

そもそも再現性気にするくらいならjupyter使うのが間違ってるけどな。

**デフォルトの名無しさん** · 2018/10/16(火) 03:32:28.53

また再現性とか誰も必要だと言ってない話をし始めたｗ

**デフォルトの名無しさん** · 2018/10/16(火) 21:22:37.51

再現性が必要ない？
それはなかなか斬新ですねw
そコマで頭の悪い意見が出るとは思ってなかった。

**デフォルトの名無しさん** · 2018/10/16(火) 22:04:16.59

Jupyter Notebookって試行錯誤を効率化するのが目的なんだから、再現性なんてDockerイメージで担保すればいいというのも、それはそれでありうる判断だろう。

環境独立な再現性があればあった方がいいって点には誰も異論はないと思うが、
それよりも試行錯誤の効率性の方が優先される用途もあるってだけの話だな。

**デフォルトの名無しさん** · 2018/10/16(火) 22:13:56.47

依存性の封じ込めも再現性もvagrantや別の方法でもできるので比較検討が必要

**デフォルトの名無しさん** · 2018/10/17(水) 01:10:09.91

>>649
依存性の封じ込めも再現性もvagrantや別の方法でもできるので
Dockerを使う理由にはならないってことだよ

**デフォルトの名無しさん** · 2018/10/17(水) 18:08:49.39

複数の方法があるけど一長一短なのでツールの特性と置かれてる状況とを見て比較検討する必要があるんだね

**デフォルトの名無しさん** · 2018/10/17(水) 19:42:49.89

ずーっとってる話だが、
比較検討の話と、ツールが作られた目的を
ごっちゃにするなってことですね

**デフォルトの名無しさん** · 2018/10/17(水) 20:01:49.11

発端は>>597-599あたりかな
比較検討の意義についての議論だったのだけど、それが理解できない子も居たようだね

**デフォルトの名無しさん** · 2018/10/17(水) 20:06:17.49

比較検討するにあたって、
どの道具の目的をちゃんと理解してないと
正しい検討ができないって話やろが

**デフォルトの名無しさん** · 2018/10/18(木) 12:14:37.57

ここで聞くのが正しいかどうかわからないんですが質問です
やりたいことが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)です

なにかわかる方いらっしゃいましたら、よろおねです

**デフォルトの名無しさん** · 2018/11/28(水) 16:14:53.75

Dockerって言うのを試したいのだが、
少し調べてみた限りでは、コマンドベースで各種の設定などやるようだが、
Linuxの操作に慣れていない人は使うのは難しい？

**デフォルトの名無しさん** · 2018/11/29(木) 22:44:08.65

>>658
やめといた方が方がいい。
本格的にLinuxを勉強するつもりなら話が別だが。

**デフォルトの名無しさん** · 2018/11/29(木) 22:44:49.67

>>658
Linux関係なくね？

**デフォルトの名無しさん** · 2018/11/29(木) 23:34:53.34

GUIしかやってないなら大抵の仮想化ツールは取っ付きにくいだろうな
CUIの勉強しろよ

**デフォルトの名無しさん** · 2018/11/30(金) 14:16:12.81

>>658
簡単だけどLinuxの操作などを知っているなら簡単という意味。

**デフォルトの名無しさん** · 2018/11/30(金) 20:19:16.57

ターゲットとなる本番環境じゃなくてポータブル開発環境として使ってる人います？
ローリングリリースのLinux選んでずーっとその仮想育てる感じで
PowershellもMsysもWSLもどうやっても馴染めないよう

**デフォルトの名無しさん** · 2018/11/30(金) 23:53:07.83

シェルスクリプト・PowerShell の代わりに、VSCode で、Ruby を使えば？

Windows でも、普通にファイル操作できる。
ただし、irb だけは日本語でバグるから、WSL のirb を使う

日本語では、WSL のirb は、MSYS2 よりも正常に動く

**デフォルトの名無しさん** · 2018/12/01(土) 07:43:14.49

うーん正確な用語がわからない・・

そのVSCodeとRubyの方を仮想かしてどこでも同じ使い勝手を味わいたいんだ
そっちの実作業環境を開発環境と呼ぶのは変なのかな

**デフォルトの名無しさん** · 2018/12/01(土) 14:14:31.04

docker へrdpで解決しない？

**デフォルトの名無しさん** · 2018/12/11(火) 16:27:30.38

サイトの管理を任されたけど、今 vagrant　とdockerとかで
環境構築するのが当たり前なの？
もう、MAMP XAMPでローカルに構築する時代じゃないの？？？

**デフォルトの名無しさん** · 2018/12/11(火) 16:35:45.97

vagrantは開発専用。これでサイト構築はまず無いだろ

> もう、MAMP XAMPでローカルに構築する時代じゃないの？？？
vagrantかWSLのほうがいいだろ？
実際の動作環境がLinuxなのにWindowsで環境作るほうが面倒

**デフォルトの名無しさん** · 2018/12/11(火) 22:04:25.79

Software Design 12月号の特集は、Python のAnsible

Vagrant, Chef に挑む巨人、Red Hat の猛攻が始まった！

以前は、すべての開発者は、Vagrant の作者で、今世紀最大の創業者、
Mitchell Hashimoto (HashiCorp)を避けて通ることはできないと言われていた

その常識に、赤い巨人が挑む！w

**デフォルトの名無しさん** · 2018/12/12(水) 00:11:08.47

>>667
俺の知ってる現場でもみんなvagrantだな
そういう時代なんだと思う

**デフォルトの名無しさん** · 2018/12/12(水) 19:59:55.07

VirtualBoxとVagrant　を使って開発って
WEBアプリケーション以外にも使われることはあるんですか？

例えば、スマホアプリとか。

**デフォルトの名無しさん** · 2018/12/14(金) 13:43:43.35

>>671
あるよ