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

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

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

よろしこ

**デフォルトの名無しさん** · 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は使いたくないし

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

ものすごく基本的なことかもしれませんが教えて下さい。
1つの物理マシンに、ubuntuをインストールし、色々な実験家用をdockerコンテナでインストールし、
そのマシンに複数ユーザが接続してdockerコンテナを使用する予定です。
同じコンテナを複数ユーザが使用しても大丈夫でしょうか。
それとも、元々マルチユーザのOSなのでこのような使い方こそが向いているのでしょうか。

**デフォルトの名無しさん** · 2017/12/12(火) 23:11:29.82

Ubuntuはただだからなにやってもいいよｗ

**デフォルトの名無しさん** · 2017/12/13(水) 08:51:35.45

>>432
実験や学習に使うならdockerじゃなくてvagrantの方がいいかな
サーバー共有する必要はないと思うのでローカルにインストールさせれば？

**デフォルトの名無しさん** · 2017/12/13(水) 20:23:50.84

CentOS7にDocker入れて、
Hass.ioというホームアシスタントのコンテナHass.ioを走らせたのですが
クライアントPCから接続できなくて困っています。
DockerとCentOSの間で外部への橋渡し設定が必要なのか
CentOSのsamba設定がまずいのか
どちらかと考えています。
前者の原因はあるでしょうか？
Dockerをアプリみたいに考えていいなら、前者は考えなくていいと思っています。

本人はDocker初心者でlinuxは数年ぶりに触っています。

**デフォルトの名無しさん** · 2017/12/13(水) 20:27:41.39

【自然破壊】何百種類ものコンピューターは必要ない
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

**デフォルトの名無しさん** · 2017/12/13(水) 23:14:09.56

>>435
Hass.ioなんてのはしらんのでその説明と構成を言ってくれないと答えられん。
そのHass.ioはサーバーなのかHTTPかなにかで接続するのか、
samba は直接CentOS上で動かしているのか？
それともHass.ioのコンテナに含まれてるのか、別のコンテナなのか
Hass.ioとsambaはどう連携するのか
マシン構成はクライアントPCとサーバーPCの二台なのか
それともクライアントPCとHass.io用PCとsamba用PCの三台なのか

**デフォルトの名無しさん** · 2017/12/13(水) 23:17:43.29

あとDocke（コンテナ）をアプリみたいに考えて良いのはそのとおりだが
何かしらのサービスを提供するアプリは、サービスを提供するための
ポート番号を設定するだろ？（デフォルトで指定されてることも多いが）
Dockerコンテナ＝アプリはそのポート番号を明示的に指定しなければいけない

**435** · 2017/12/14(木) 00:27:35.30

>>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はワークグループに表示されているが、ゲストアクセス出来ない。

すみません。分かることを書いてみました。
本人はサーバー立ち上げ経験ありません。

**デフォルトの名無しさん** · 2017/12/14(木) 01:14:17.99

>>432-434
漏れの推測だけど、

そのOS に、Docker イメージが1つだけで済む。
各ユーザーは、そのイメージからの差分だけを持てば良いから、効率的

**デフォルトの名無しさん** · 2017/12/14(木) 06:26:27.54

>>435
Hass.ioとやらとsambaの連携は必要なの？
Hass.ioだけ起動して動作するか確かめよう

**435** · 2017/12/14(木) 09:19:19.05

>>441
あ、公式ホームページ読むと
Hass.ioでsambaとSSHが使えると書いてあるのかな。
確認してみます。

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

1つのアプリケーションで複数サービス起動したい場合のベストプラクティス教えて

**デフォルトの名無しさん** · 2017/12/15(金) 00:56:05.83

バッドプラクティスしたい場合の
ベストプラクティスを教えてと言われても・・・

**デフォルトの名無しさん** · 2017/12/18(月) 19:09:18.62

そういう時はdindだな

**デフォルトの名無しさん** · 2017/12/19(火) 20:09:30.02

ジェンキンスでイメージをレジストリにpushするところまで出来たのだけど
pushしたイメージを運用サーバーにpull & restartしてもらうにはどうすればいいの？ssh？

**デフォルトの名無しさん** · 2017/12/23(土) 21:56:21.95

人いねえな
日本じゃ仮想環境はまだまだマイナーなのか
大企業でもでっかい社内サーバーにあれこれ同居させてなんてことが未だにあるし
そういう文化なのかなぁ

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

Dockerのコンテナで開発環境として
いろんなサーバつくる上での「共通素材」が
そろったコンテナ配布していないかな。
プログラミングが学習しにくい内容として
例えばDBを学びたときに「DB内に予め素材データがたくさん詰まっていたら」
それをもとに勉強や試しに動かしやすくなる。
JavaScriptを試したいときにい予めサンプル画像や文言、
試し切り用のHTML構造がたくさん詰まっていてくれたら検証しやすくなる。
テストコードがあらかじめたくさんあったらそれに合わすような
プログラムが作りやすくなる。
開発環境は素材付きで配布するっていいアイデアじゃないか？

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

Dockerhubに登録すれば良いものなら評価してくてるよ

**デフォルトの名無しさん** · 2018/01/02(火) 23:07:27.96

これどういうこと？
Docker死ぬん？　せっかく覚えてきたのに？

Docker, Inc is Dead / Docker社は死んだ
http://itosho525.hatenablog.com/entry/2018/01/01/074358

**デフォルトの名無しさん** · 2018/01/02(火) 23:52:33.32

無問題

**デフォルトの名無しさん** · 2018/01/03(水) 00:34:25.41

>>448
素材データはあちこちでいろんな形で配布してるから実情にあったのを自分で選ぶべきだな

R程度の軽いデータ付属してても問題ないけど重量級のデータが詰まってるのなんて邪魔でしかない

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

ねーよ

**デフォルトの名無しさん** · 2018/01/03(水) 11:33:44.26

DockerはMSに買収された方がいい方向に進むだろうね

**デフォルトの名無しさん** · 2018/01/04(木) 00:14:34.87

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

**デフォルトの名無しさん** · 2018/01/06(土) 08:40:25.60

dockerでデスクトップ環境とスマホエミュレーター作れる？

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

まーたdockerが何か分かってない奴の質問か

dockerはカスタマイズされたアプリを作るものであって
環境を作るものじゃないんだよ

ここにアプリが有るじゃろ？から始まって
このアプリを動かすにはこのライブラリが必要で
こういう設定ファイルが必要じゃろ？
それらのアプリとそのアプリを動かす環境を
合体させてアプリを作るんだよ

だからデスクトプアプリは作れても
デスクトップ環境はそのそもdockerで作るものじゃない
スマホエミュレータはアプリなんだから作れるだろう

**デフォルトの名無しさん** · 2018/01/06(土) 15:08:44.43

クリーンなビルド環境としてのdockerなど、当たり前のように環境として使われてるが?

**デフォルトの名無しさん** · 2018/01/06(土) 15:57:41.40

>>458
それはクリーンな環境を作ってるのではなく
作っているのはあくまでビルド生成物
その途中がクリーンな環境になっているってだけの話だな

**デフォルトの名無しさん** · 2018/01/06(土) 17:02:13.94

>>459
大丈夫か? あんま無理すんなよ
「その途中がクリーンな環境になっている」の環境はまさにdockerで作ってるんだぞ?

**デフォルトの名無しさん** · 2018/01/06(土) 17:09:31.21

ビルド環境だけじゃなくテストを走らせる環境もDockerで作る
Travis CIとか使ったことないんじゃ

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

固定概念でdockerの可能性を絞るのは宜しくないね

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

それぞれ
・ビルド生成物を作成するアプリ
・テスト結果を作成するアプリ
だと言いたいんだろう

ていうか、彼の世界観でスマホエミュレータがOKなんだったら
Linuxデスクトップ環境エミュレータだってOKなんだけどなw