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

**デフォルトの名無しさん** · 2017/02/16(木) 18:01:04.48

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

よろしこ

**デフォルトの名無しさん** · 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
目的なんて無数にあるだろ
自分が考える目的以外の目的が存在するということすら想像できないようじゃ話にならない
本当に話しにならない