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

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

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

よろしこ

2017/10/22(日) 16:33:25.41

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

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

2017/10/22(日) 16:35:45.41

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

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

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

2017/10/22(日) 16:36:45.98

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

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

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

2017/10/22(日) 16:40:24.57

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

2017/10/22(日) 16:41:04.63

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

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

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

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

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

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

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

2017/10/22(日) 16:41:22.04

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

2017/10/22(日) 16:42:13.48

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

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

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

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

2017/10/22(日) 16:44:19.17

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

そりゃそうだろｗ

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

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

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

2017/10/22(日) 16:45:00.82

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

2017/10/22(日) 16:45:40.96

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

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

2017/10/22(日) 16:47:41.88

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

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

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

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

2017/10/22(日) 16:48:03.31

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

2017/10/22(日) 16:50:11.92

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

え？

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

2017/10/22(日) 16:51:57.39

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

2017/10/22(日) 16:54:00.10

$ 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)

2017/10/22(日) 16:55:08.53

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

2017/10/22(日) 16:57:38.59

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

2017/10/22(日) 16:58:06.58

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

2017/10/22(日) 17:00:00.38

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

2017/10/22(日) 17:00:13.97

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

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

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

2017/10/22(日) 17:02:29.22

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

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

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

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

2017/10/22(日) 17:07:01.08

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

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

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

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

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

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

2017/10/22(日) 17:16:55.75

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

2017/10/22(日) 17:22:13.75

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

2017/10/22(日) 17:28:37.91

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

2017/10/22(日) 17:30:01.29

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

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

2017/10/22(日) 17:30:54.61

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

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

2017/10/22(日) 17:30:55.70

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

2017/10/22(日) 17:34:19.94

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

2017/10/22(日) 17:34:46.23

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

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

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

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

2017/10/22(日) 17:38:08.26

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

2017/10/22(日) 17:42:02.16

ついこの間読んだ記事

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

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

2017/10/22(日) 17:56:15.83

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

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

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

**デフォルトの名無しさん** · 2017/10/22(日) 20:15:57.81

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

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

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

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

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

**デフォルトの名無しさん** · 2017/10/22(日) 20:19:24.14

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

**デフォルトの名無しさん** · 2017/10/22(日) 20:38:19.65

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

**デフォルトの名無しさん** · 2017/10/22(日) 20:43:45.97

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

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

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

**デフォルトの名無しさん** · 2017/10/22(日) 20:51:08.10

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

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

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

**デフォルトの名無しさん** · 2017/10/22(日) 20:54:43.66

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

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

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

**デフォルトの名無しさん** · 2017/10/22(日) 20:57:36.95

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

busybox、alpine、CoreOS、Container-Optimized OS

**デフォルトの名無しさん** · 2017/10/22(日) 21:00:16.24

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

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

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

**デフォルトの名無しさん** · 2017/10/23(月) 00:50:40.93

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

**デフォルトの名無しさん** · 2017/10/23(月) 01:04:48.03

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

**デフォルトの名無しさん** · 2017/10/23(月) 01:07:56.87

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2017/10/23(月) 01:18:21.36

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

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2017/10/23(月) 01:28:14.42

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

って言ってる時点で、

システムコンテナ（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 によるアプリケーションの分離に近いです。
> 単一アプリケーションを分離するだけなので、とても軽くシンプルなのが特徴です。

**デフォルトの名無しさん** · 2017/10/23(月) 01:32:54.85

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

**デフォルトの名無しさん** · 2017/10/23(月) 02:24:34.18

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2017/10/23(月) 02:33:28.78

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2017/10/23(月) 02:34:50.00

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

**デフォルトの名無しさん** · 2017/10/23(月) 02:38:08.54

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

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

**デフォルトの名無しさん** · 2017/10/23(月) 02:44:12.55

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

**デフォルトの名無しさん** · 2017/10/23(月) 02:46:41.07

> 違うかい？

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

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

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

**デフォルトの名無しさん** · 2017/10/24(火) 00:32:13.24

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

**デフォルトの名無しさん** · 2017/10/24(火) 03:30:56.57

Docker、2016、オライリー

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

**デフォルトの名無しさん** · 2017/10/24(火) 23:00:17.34

殆ど同じ内容の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"]

似たようなのが沢山ある

**デフォルトの名無しさん** · 2017/10/24(火) 23:03:45.53

>>386
build-argつかえ

**デフォルトの名無しさん** · 2017/10/24(火) 23:18:00.24

>>387
👍

**デフォルトの名無しさん** · 2017/10/28(土) 09:01:01.81

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

**デフォルトの名無しさん** · 2017/10/28(土) 14:35:33.70

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

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

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

**デフォルトの名無しさん** · 2017/10/28(土) 16:01:54.61

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

**デフォルトの名無しさん** · 2017/10/28(土) 16:44:44.72

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

**デフォルトの名無しさん** · 2017/10/29(日) 01:55:08.12

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

**デフォルトの名無しさん** · 2017/11/03(金) 10:45:37.59

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

**デフォルトの名無しさん** · 2017/11/06(月) 06:20:20.30

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

**デフォルトの名無しさん** · 2017/11/07(火) 00:11:44.79

>>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ならそれができるように整備されているってわけ

**デフォルトの名無しさん** · 2017/11/07(火) 08:18:05.50

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

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

**デフォルトの名無しさん** · 2017/11/07(火) 10:49:12.91

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

**デフォルトの名無しさん** · 2017/11/07(火) 15:43:49.52

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

**デフォルトの名無しさん** · 2017/11/08(水) 22:22:13.17

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

**デフォルトの名無しさん** · 2017/11/11(土) 12:30:00.77

日経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 ビット版)

**デフォルトの名無しさん** · 2017/11/12(日) 10:14:04.28

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

**デフォルトの名無しさん** · 2017/11/18(土) 00:17:48.89

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

**デフォルトの名無しさん** · 2017/11/18(土) 20:40:24.58

暇な人おしえてください

物理マシンで作ったスクリプトファイルを仮想環境で実行したいんだけど
どうやってファイルを仮想ディレクトリにもっていけばいいの？
根本的にわかってないっす・・・

**デフォルトの名無しさん** · 2017/11/18(土) 20:48:16.87

自己解決
なるほど共有フォルダを作成すればいいのね

**デフォルトの名無しさん** · 2017/11/21(火) 22:02:56.50

最近vagrantを始めたのですが
このソフトがやっていることってもしかして
virtualboxのCLIを叩いてるだけでは？

**デフォルトの名無しさん** · 2017/11/21(火) 22:24:30.28

そうだよ
てかインフラアズコードって全部そうだよ

**デフォルトの名無しさん** · 2017/11/22(水) 01:35:34.65

ありがとうございます
やはりそうなんですね
そうなると、「vagrantでないと出来ないこと」は何なのかが気になります
プロビジョニング的なことでしょうか？
プロビジョニングは、
自動的にログインしてコマンドを叩くことで実現してるのでしょうか？
これはあらためて考えるとvirtualboxのCLIで出来ることを超えてる感じがします

**デフォルトの名無しさん** · 2017/11/22(水) 02:08:02.88

時間さえあって自分で作るならアセンブラでできないことは何もない

○○でないとできないこと＝"時間をかけずに"△△をすること
すべてそう。時間をかけないという問題を解決してる。

> これはあらためて考えるとvirtualboxのCLIで出来ることを超えてる感じがします
virtualboxのvboxmanageコマンドでできる

**デフォルトの名無しさん** · 2017/11/22(水) 07:30:32.21

>>408
vagrantはラッパだから、vagrantじゃないとできないことなどない

**デフォルトの名無しさん** · 2017/11/22(水) 23:58:07.56

自転車で行けるなら、歩いていけないことはない
というのと一緒

可能・不可能の話にしてしまうと大事な点が見えなくなる
同じことをするにもコスト・時間が少ないほうが良いだろう？
それはすごく重要な事だよ

**デフォルトの名無しさん** · 2017/11/23(木) 07:48:28.42

oracledbの公式イメージないんか
oracleはほんま使えんなぁ

**sage** · 2017/11/23(木) 10:23:34.07

privilegedモードとdocker.sock共有だとどっちか危険ですか？

**デフォルトの名無しさん** · 2017/12/07(木) 12:39:47.34

docker run したときのパラメータ変えたかったら
今のコンテナからイメージつくるか、もとのイメージから、コンテナ作り直すしかないの？

**デフォルトの名無しさん** · 2017/12/07(木) 21:24:18.91

>>414
dockerイメージ = exeファイル
dockerコンテナ = exeファイルを実行して作ったプロセス
docker runのパラメータ = exeファイル起動時の引数

と考えればいいよ

起動時の引数を変えたいって変な話だよね
プロセスの状態を外部から変えたいならば、ファイルやネットワークやシグナル
なんかで、プロセスにメッセージを送ることになるでしょう？

**デフォルトの名無しさん** · 2017/12/07(木) 21:39:08.94

entrypointのことだろ
オプションで変えれるぞ

**デフォルトの名無しさん** · 2017/12/07(木) 21:46:47.50

>>416
今のコンテナからイメージ作らないで
もしくは
もとのイメージからコンテナ作り直さないで

変えられるって言いたい？

**デフォルトの名無しさん** · 2017/12/07(木) 21:47:04.44

>>415
１回exe起動したらずっとそのままの状態で起動しないとだめってのもおかしな話だよね
なんのために引数取れるようになってるのか考えれば、パラメータ変えて再実行なんてあり得る話
プロセスが継続してる必要はないけど、たとえばポート変えたいとかいくらでもあるだろ

コンテナが単純なexeと違うのは、内部に状態持って永続化してたりするから
まあ、コンテナ内部に永続化させたのが失敗だって話なんだろうけど

**デフォルトの名無しさん** · 2017/12/07(木) 23:08:10.01

>>418
だから俺は最初から、exeファイルの引数を変えて
再起動するのが普通だって言ってるだろ

再起動したくないって言ってるのは>>414
俺はそれに対して再起動しないで変えるための案を書いてる

後からやってきたお前のレスは、>>414が再起動したくないと言ってるのに対して
（再起動しないで）entrypointでオプション変えられるって言ってることになってるんだよ
だから俺は、それできんの？ってきてるんだが

ちゃんと文章読め

**デフォルトの名無しさん** · 2017/12/07(木) 23:09:37.72

>>418
> コンテナが単純なexeと違うのは、内部に状態持って永続化してたりするから

単純なexeだってビルドする時にソースコードに書かれた
定数やデータやリソースファイルなど、内部に状態を持って永続化するが？

**デフォルトの名無しさん** · 2017/12/08(金) 03:08:05.72

>>420
実行ファイルに埋め込まれた定数やリソースを永続化という用法が一般的かどうかは知らんが
状態のまえに、実行時に変化するってつけといて
あるいは状態もって永続化じゃなくて、データファイルでもいいぞ

**デフォルトの名無しさん** · 2017/12/08(金) 03:15:52.99

プロセスだって実行時にメモリ書き換えるだろ
実行時に状態変化してるんだよ

**デフォルトの名無しさん** · 2017/12/08(金) 05:39:25.87

メモリ書き換えるのは普通永続化されてるとは言わんわ
わざと曲解してるのかね

**デフォルトの名無しさん** · 2017/12/08(金) 09:52:46.11

>>423
だからdockerコンテナも同じ
基本的にコンテナは終了した後に再利用することはしない
消すのだから永続化していると考えてはいけないんだよ

**デフォルトの名無しさん** · 2017/12/08(金) 14:21:56.65

データベースとかリポジトリのコンテナは止めたり再開するだろ？

**デフォルトの名無しさん** · 2017/12/08(金) 15:05:16.18

まず質問に対してYesかNoで答えろよ。

**デフォルトの名無しさん** · 2017/12/08(金) 17:43:23.33

>>424
だからコンテナ内部に永続化させたのが失敗だって話なんだろうって

ただ、コンテナは中断しても良いけど終了させたいわけでも消したいわけでもないぞ
たとえば　現在のコンテナの内容のまま、　 -p 80:80 から -p 8080:80 にしたいってときにどうするんだって話

**デフォルトの名無しさん** · 2017/12/08(金) 21:44:10.36

>>425
しない。それは使い方が間違っている。
データベースに限らないがまずアプリとデータは分離させる
アプリはコンテナ、データはボリュームに保存する。
そしてコンテナは消してもデータは残るように作るのが通常のやり方

**デフォルトの名無しさん** · 2017/12/08(金) 21:51:28.74

>>427
> たとえば　現在のコンテナの内容のまま、　 -p 80:80 から -p 8080:80 にしたいってときにどうするんだって話

データはコンテナの中ではなくボリュームに保存する。
だからコンテナは消しても、データはそのまま。

アプリを一旦停止して再起動しても、データはファイルに保存してるだろ。
アプリを止める　＝　コンテナを止める
データをファイルに保存　＝　データをボリュームに保存
こう変わっただけ

これこそが「仮想化」なんだよ。
もし仮にアプリが決め打ちの絶対パスで/var/hogeにデータを書き込むという仕様だとしても、
dockerコンテナに閉じ込めておけば、アプリが/var/hogeに書き込んだとしても
ボリュームを使うことでコンテナの外では好きな場所に変更することができる
仮想メモリのように、アプリから見た書き込む場所とは別の物理的な場所にリマップできる

アプリや一連のシステムを一つのコンテナにパッケージングし
そのコンテナ＝アプリのようにみると、docker runのオプションで自由にポート番号
や書き込みディレクトリを変更できるカスタムアプリが出来上がる。

**デフォルトの名無しさん** · 2017/12/08(金) 22:29:34.36

ドッカスはネットワーキングがクソ
ホストのリゾルバぐらい参照せえや
なに勝手にグーグルにつないどんねん

**デフォルトの名無しさん** · 2017/12/10(日) 11:56:05.50

外部ポート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は使いたくないし