Docker Part2©2ch.net

LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker
http://mao.2ch.net/test/read.cgi/linux/1374861492/

>>173
コンテナ起動時にストレージ領域を紐づけてなかったら終了時に綺麗さっぱり消えるようだ

>>173
正確にはコンテナを削除すると無くなる
停止しただけでは無くならない
ゆえに削除するまではdocker logsでログも見れるし
docker commitでイメージ化すれば
docker runで中身を見れる

https://stackoverflow.com/a/39329138

>>172
欲しけりゃ自分のDockerfileに入れるか
全部のコンテナでそれやるのがアレってなら
新しくvimコンテナ作って編集したいファイルだけマウントするか
ホストのファイルをマウントして
ホスト側でvimで編集すれば良い

てか開発環境だよな
本番環境でそれやったら
ちゃんと動く環境を保存出来るっていうDockerの魅力を殺している
場合によっては仕方ない事もあるが

>>172
> pullしたubuntuイメージにvimが入っていないんだけど・・・
Dockerの使い方を間違ってる。

あんたが言ってるのは、pullしてきたffmpegコマンドの中に
vimが埋め込まれてないんだけどって言ってるようなもの
Dockerコンテナ = 実行ファイル

ffmpegの処理にvimなんていらないんだから入っていなくて
当たり前だし入れるべきではない

だがaptコマンドは普通入ってるはずだけどな

>>172
> dockerってコンテナが動いてる途中でdocker終わらせたらコンテナ内に保存してたファイルはなくなるの？
ffmpegコマンドの中で内部的に使用しているファイルはコンテナ削除とともに消える。
Dockerコンテナの中のファイルはメモリと考えればいい。
コマンドを終了するとメモリも解放される

（Dockerコンテナ版の）ffmpegコマンドから書き出したいなら、
ボリュームでコマンド（コンテナ）外部への読み書き場所を指定する

>>177
アドバイスありがとう
ということは、dockerで起動したOS内でvimが使いたければ
vimのコンテナを探してきて追加起動しろってこと？
どこのサイトにどんな名前でvimのコンテナがあるのか調べるみたいなことを
アプリごとにやってたら、環境を作るまでどれだけの手間と時間がかかることやら
このソフトの何が持てはやされているのか全く理解できない

>>178
だから使い方が間違ってる。
全く理解できないのは、あんたが正しい使い方がわかってないからだよ

そもそもDockerコンテナは使うものじゃない。作るものだ。
アプリのビルド・コンパイルと一緒だよ
もちろん誰かが作ったものがそのまま使えるのなら
使っていいんだが、基本はアプリの開発者が作るもの

vimとかそういうのは、どうせあんたUbuntuとか有名所の
ディストリ使ってるんだろ？そういうのはパッケージメンテナが
ちゃんと動くようにメンテしてくれてる。それで満足してるならそれ使えばいい。

Dockerの出番はそれで満足できない場合だよ。
vimにそういうのがあるのかしれないが、独自にビルドしないと使えない機能を使いたいときや
例えばvimの新しいバージョンを使いたい時。ビルドするためにライブラリも新しくしなければいけない
でもOSのライブラリを新しくすると、他のプログラムに影響が出るかもしれない

そういうときにvimのビルドとそれを動かす環境までも一体化させて、独自のvimを作る
ってときに使うんだよ。実行環境まで含まれてるから、OS標準のライブラリなどを
置き換えたりもしないし、どこに持っていってもそのまま使える
オレオレvimバイナリ（=Dockerコンテナ）の出来上がりってわけだ

で、そんなもん普通はやらねーだろ？ だからアプリの開発者が作るものだって言ったわけだ。
vimなどのパッケージはパッケージのメンテナが頑張って動くようにしてくれてる
だけど、自分で作ったアプリは、自分が頑張るしかないだろ？ でも頑張りたくもない
いろんなディストリや、WindowsやMacでも動くようになんかするの大変じゃないか
だからDockerコンテナ化することで、Dockerデーモンさえ動いていれば、
どこに持っていっても同じように動かせるってわけさ
一言で言えば可搬性だな

>>178
> ということは、dockerで起動したOS内でvimが使いたければ

それから通常はdockerで起動したOSの中に乗り込んでvim実行して
ファイル修正とかしないからな

独自のDockerイメージを作るときに、デバッグ目的にやることはあるけど
「dockerで起動したOS」なんて考え方を持ってはいけない

なぜなら、何らかのプログラムに実行環境をくっつけただけで、
作られるものは、実行環境付きのなんらかのプログラムなんだから
そこにOSなんてものはないと思え

今日から新しいプロジェクトでmac上でDOCKERを使う事になったんですが

最初の社内のチュートリアルに従ってHOMEBREWからインストールして起動したところ
新しいバージョンがありますって言われたので
アップデート＆ReLunchをしたらそのまま反応がなく
アプリからダブルクリックしても起動しなくなりました

MAC使うのもバージョン管理ツール使うのも初めてだらけで
くだらない質問で申し訳ないんですが
考えられる解決方法はありませんでしょうか

社内の人に聞け

普段サーバーサイドJavaとかPHP JSでウェブアプリかいてて
mac の Ruby on Rails のサーバーサイドの案件が修羅場でヘルプはいったんだけど
分かってる人はみんな忙しくて質問なげてもなかなかかえってこないんですよね

でもこんな情報じゃわかるわけないですよね…
明日また社内できいてみます
すいませんでした…

>>181
dockerは公式サイトのやり方でインストールしたほうがいいんじゃね？

社内のチュートリアルが何年前に書かれたかだな
Docker Toolbox使ってたら古いやり方だな
まあ社内全員やり方が決まってるなら仕方ないが

支給されたmac PCが他の人も使うみたいで
別の人がインストールしたhomebrewが/usr/localにはいってて
権限が変更できないくてホーム以下にインストールしたんだけどそのせいなのかなと…

１日がかりでbrew　rbenv　dockerの３ついれただけなんだけど
どれが原因なのかがぜんぜん分からない…
マックはじめてで最初の１，２時間は日本語変換や窓の最小化やコピペもわからないレベルで作業効率も悪いし

Javaからruby覚えるのはすぐできると思ったけど
OSが違ったりフレームワークの環境構築がこんな大変だと思わなかった

もうmac板で質問したほうがいいのでは

>>186
なんの苦労もなくhomebrewを使いたいなら
Macを他に人に使わせるな。そしてクリーンインストールして
自分ひとりのものとして使え

homebrewはインストールしたユーザー以外がまともに使うことは無理
homebrew自体はsudo使ってインストールするくせに（/usr/localに書き込むから）
パッケージ自体は/usr/local以下に一般ユーザーでインストールするからな
ディレクトリはこんな感じになる

https://github.com/Homebrew/brew/issues/3322#issuecomment-336770069
> -rw-r--r-- 1 weicool admin 3161 Jan 18 2016 /usr/local/CODEOFCONDUCT.md
> drwxr-xr-x 18 weicool admin 576 Oct 8 13:58 /usr/local/Cellar/
> drwxr-xr-x 2 weicool wheel 64 Oct 15 10:57 /usr/local/Frameworks/
> -rw-r--r-- 1 weicool admin 1241 Jan 18 2016 /usr/local/LICENSE.txt

見ての通り、adminグループに書き込み権限がないから、
最初にパッケージをインストールした人以外がいじることはできない。
brew管理用のユーザーを別で作成するとかumaskの設定をいじってたりとか
ちゃんとやってればマルチユーザーで使えるかもしれんがな

homebrewの設計自体はsudoを使わない方針なんだが
https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad
じゃあ共有のディレクトリ/usr/localを使うなと

そうなんですね
クリーンインストールしていいかお願いしてみます
検索するとわりとホーム以下にインストールする方法とかでてきたのでいけるかと思ったんですけど

コーディングスキルかわれて入ったのに初日から環境構築だけでつぶされてストレス
なまじできると思われてるからしょーもない質問もしにくいし

もともと大学院研究室あがりでスクラッチからかくのが好きな
ブラックボックスなツール使うの気持ち悪い
古い人間だから昨今のフレームワークだらけの業界きついなあ…

頭でっかちの使えないやつか現場も大変だな

macやhomebrewがはじめてなのはともかく、バージョン管理ツールはじめてはないわ
それでひとりで環境構築しろってほったらかしなのも普通はありえんと思うけど
仕事ほしくて経験ないのに経験ありとか嘘かいたんじゃねーの

最後にききたいんですけど /usr/local じゃなく
~〜/homeblew に homeblew をいれたんですが
この blew から Docker をインストールした場合実態はどこにあるんでしょうか

チュートリアルにアプリケーションからdockerを起動とあるんですけど
/Application/Docker.app を起動したときにもっと新しいのがありますっていわれて
更新かけたらそれっきりだったので
これが前の人がインストールしたやつだったのかな…

コマンドラインの docker はホーム以下のパスになってたんですけど
アプリケーションからじゃなくコマンドラインからDockerのGUIアプリ起動する方法ってありますか？

解決しました

初回起動時に窓が出たのでずっと窓を探してたんですけど
右上のクジラマークからアクセスするんですね…
おさわがせしました

何度もすいません

docker-compose up -d

で ERROR: manifest for xxx/yyy:2018zzzz not found が出るんですがどこを見ればいいのでしょうか

一応同じディレクトリに docker-compose.yml はあって
yyy:
image: xxx/yyy:2018zzzz
と書かれています

>>194
普通はそうならないので環境の問題です
OSをクリーンインストールしてください

rubyは導入ハードル高すぎ
よっぽど複雑なプロジェクトでもなけりゃこんな開発環境作ってるあ労力で案件終わるわ

利用プロジェクトの多くが低品質だったせいでいわゆるアタリショックみたいな扱い受けてるよな
負の遺産だとかRuby巻き返しの目は潰えてるとまで言われてるし・・・Javaみたいにはならんで欲しいマジで

散々Perlディスっといてこれだもんなm9(^Д^)プギャー

やめて…perlは6を引き伸ばし杉た件のせいで世間との剥離からユーザー離れが尋常じゃなく
引き合いに出されると最底辺の戦いじみて嘲笑の的です…

イシキダケタカイケイ

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

マジかよDockerForWindows消してくる

もしかしてHyperV無しのHome版WSLでも動くようになってるのか

パブリッククラウドやDocker Hubに最適化した「Minimal Ubuntu」がリリース　2018/07/10 12:06:20
https://news.mynavi.jp/article/20180710-662006/

　Canonicalは2018年7月9日(米国時間)、パブリッククラウドおよびDocker Hubに最適したLinux
ディストリビューション「Minimal Ubuntu」をリリースしたことを明らかにした。
AWS(Amazon Web Services)およびGCP(Google Cloud Platform)を推奨パブリッククラウドとし、
イメージファイルはWeb上からダウンロードできる。

ええやん
alpine使いにくいし乗り換えようかな

minidebのUbuntu版みたいなヤツか

ええやん、なんぼなん

展開後のサイズは約80MB前後でminidebのようなコンテナ特化支援コマンドはさすがに無いっぽいな

Ubuntu版の公式slimとしてapt系で最新パッケージ使いたいなら(Debianのslimじゃなくて)こっちでねって感じか
野良イメージじゃない公式スリムに選択肢が増えるのは嬉しい

debianよりも少ないの？

alpineで慣れちゃった。

debian:stretch-slimは55MB
（bitnami/minideb:stretchは54MB）

ubuntu:bionicは81MBで去年から変わってないみたいだけど今回発表されたやつは何なんだいったい…
元記事タイトルにDocker Hubとあるが実は関係なくてアマとかGCPで使うimgファイルが小さくなりますたってことか

ミニマルすぎると一個ゲットした途端大量に依存がやって来る悪寒しかない

ミニマムすき

エセロリやん

「OpenNebula 5.6」公開、Dockerサポートの強化などが加わる　2018年7月18日15:00 末岡洋子
https://mag.osdn.jp/18/07/18/150000

　クラウドインフラストラクチャ構築・管理プラットフォーム「OpenNebula」の開発チームは7月16日、
最新安定版となる「OpenNebula 5.6」（Blue Flash）を公開した。

　Docker管理機能を新たに統合、任意のOpenNebulaクラウドで、Dockerアプリケーション実装の
土台となるDockerエンジンの仮想マシンをMarketplaceよりインポートできるようになった。また、
OpenNebula APIやインターフェイスを経由することなくDockerエンジンをシームレスに管理する
Docker Machineも統合した。

訳あってソースコードからビルドしないといけない物があるんだけど、
ビルドに必要なパッケージをインストールしたくない。

だからDockerでビルドして、インストール先はDockerの外って
やりたいんだけど、そういう使い方のノウハウって
どこかにまとまってないかなぁ？

ソースコードのディレクトリをボリュームにして
make installだけDockerの外でやるのが一番かなぁ？

そういうときはmake install先のディレクトリだけ -v でマウントしとくパターンが簡単で良いね

例えば ./configure --prefix=/usr/local で入れるやつはインスコ先になる/usr/localを
docker runのときに -v "/usr/local:/usr/local" って指定する

コンテナでmake installまでやれるしホストもソースやビルドツールで汚れないから安心
docker公式マニュアルのどっかに書いてあった気がしたが見当たらなくなってた

詳しい解説サンクス

>>217
もう少しアイデアを発展させてみた。
このアイデアをどうするかは任せる

make install、前々からの問題。何処に何がインストールされるかわからない。
基本的には--prefixで指定した所だろうけれど、確実にそうとは言い切れない

make uninstall、これも前々からの問題。uninstallをサポートしているものが少ない
インストールした後消すのが大変

docker、make installでインストールされるファイルは多分レイヤーの差分を見ればわかる
インストールされるファイルがわかるのだから、それを消せばアンインストールになる
インストールするファイルも残っているのだから、ファイル内容を比較することで
アンインストール時に想定外のファイルを削除しなくてすむかもしれない

今はMulti-stage buildが公式実装されて>>219のアイデアを綺麗に実現できるようになったね！
ビルドコンテナのmake install結果をホスト経由せずに実行用コンテナに簡単に乗せられる

ビルドコンテナも実行用コンテナも使い終わればコンテナごとすべて消せるから
--prefix完全無視の無作法野良ツールにホストのファイルが上書きされることもないし
make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない

>>220
> make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない
なんかちょっと違うｗ

インストール先はコンテナの外よ。だからコンテナ消せば良いだけってことにはならない。

どんなものでもコンテナ化して使えるかっていうと、例えば（独自ビルドの）gitコマンドを
コンテナに入れて使うのは大変だと思う。カレントディレクトリを見るし、
サブコマンド次第ではカレント以外のディレクトリも見るしね

インストールするファイルを知ることができるから、コンテナでビルドして生成したものを
コンテナの外にインストールしてアンインストールもしやすくなるだろうと言う話

最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな
俺もコンテナ上のgitからホストのカレントディレクトリを見る方法がわからんというごく最初の段階でつまずいた

絶対パス指定ならツールで使う主要ディレクトリを-vに指定しとけば大半普通に開けるけど
カレントを含めた相対パスも単に-v $(pwd):$(pwd) -w $(pwd)を書いておけばいいという基本をDocker Hubのgitイメージページ読んで知った

>>222
だから大変だからホストに直接おいたほうが良いって話なんだが

例えばgit diff --no-indexでカレント（gitディレクトリ）以外を
比較したくなったら-v $(pwd):$(pwd)じゃ対応できない。
他にもgit applyとかさ

-v $HOME:$HOMEにしたら動くかもしれないけど、
それでもhomeの外では使えないコマンドになってしまう。
（例えば/opt以下にgitリポジトリをcloneするツールとかさ）

コマンド実行した時、特定のファイルはコンテナの外を見ますが、
それ以外はコンテナの中を見てますとかややこしいだけだから

俺は頑張ったんだって自己満足してたいだけでしょ？
そんなのは意味がないから辞めたほうが良い

あ、そうだ。gitのglobal configがあるから、
絶対HOMEをボリュームにしないとだめなんだ。

ssh鍵の話もあったな
-v $(pwd):$(pwd) -w $(pwd)を書いておけばって
実際には使ってないだろ。

コンテナ化に適してないアプリをコンテナ化しても使いにくいだけ

面白い例を思いついた

> 最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな
エディタとgitをコンテナにするとどうなるか

環境変数GIT_EDITOR、コミットメッセージなどを編集する時に使用されるエディタをしている。
まあGITが使う多数の環境変数をコンテナの中に渡す。これだけでも面倒くさくてやりたくないが、

gitをコンテナの中で動かしたりすると、エディタがコンテナの中で起動される
つまり、gitコンテナの中にエディタまで入れないといけない。
さてそのエディタ、当然（？）のごとくgit連携機能がついている。
エディタからgitを呼び出されるならば、エディタのコンテナの中に、gitを入れないといけない

環境変数？ おっと、gitコンテナの中でエディタを起動するならば、
エディタで使う環境変数も、gitコンテナに渡さないといけないな。
おっと、エディタからgitを呼び出すこともあるから、エディタのコンテナを実行する時も
gitの環境変数を渡さないといけないな

はは、乾いた嘲笑の笑いしか出てこない。こんなムダでややこしいことやって
なんの意味があるんだ。

長くて全部読んでないけど、ホスト側のgitなりエディタ設定なりに依存するようなコンテナって筋悪くない？

k8sとかでコンテナを別ホストに移動したら使えなくなるような気がする。

エディタが何かによるけど、vim程度ならコンテナ毎に入っててもいいのでは。有償のIDEでgit連携して使ってる人にとってはちょっとしんどいとかかな。

そりゃ単に、
　普通は使わないけど入っていても良い。イメージのサイズがでかくなるだけ。
程度のことだな

普通はコンテナのイメージはDockerfileで作るし、コンテナの中のファイルを
直接修正することはない。Dockerfileの開発中とかデバッグのために
便利かもーぐらいで入れておいてもいいが、最終的には使わんので消す

コンテナ内のvimは使わない。の意味がわからんやつは
勉強し直したほうが良い

え、普通にvim使ってるけど。何でなの？

本番環境って前提ならそもそも本番で稼働している設定ファイルはみだりに編集しないってのは分かるけど。
単にコンテナ内でvim使うかどうかって話だとしたら本気で意味分からん。

コンテナの中のファイルは絶対編集しないってどういうことなんだろう。良くあるベストプラクティスに書いてあるから盲目的にそうするって事だとしたら、はぁ、そうですかで話終わりにするけど。

>>238
Dockerはアプリケーションコンテナと言って、
アプリケーションをコンテナ化するもの
システムコンテナと違って、コンテナの中で作業するためのものじゃない。

だから、vimという手動で作業するツールをコンテナに入れる意味はないし、
vim自体をコンテナ化しても使いづらいことは説明済み

> 良くあるベストプラクティスに書いてあるから
ベストプラクティスレベルの話じゃない。Dockerの使い方の基本の話。

とりあえずアプリケーションコンテナとシステムコンテナの
違いぐらい学習してから出直せ

ドヤ顔で未来にエスパーしてて草

内容は間違えてないだろ？ﾆﾔﾘ

>>233
アプリケーションコンテナとシステムコンテナの違い、ですか。そうですか。
教科書にはきっとそう書いてるんでしょうね。その辺はよく知らないけど、たぶん間違ってないんだと思います。

でも、私はDockerで開発するファイルも編集します。はい。

コンテナでsshd起動してsshでアクセスするなとかいうのも基本としてあるってのは聞いたことある。
けどそんなの関係ねぇ。
実際エンジニアに開発環境としてコンテナ提供するのにsshでアクセスできないって不便でしかない。

ちなみにシステムコンテナってSolarisのzoneみたいなものかな。Linuxだと何かあるのだろうか。

>>236
コンテナの中にあるファイルはコンテナ削除すると消えるでしょ？永続化しない。
残っていてほしいファイルはボリュームでコンテナの外にだすわけだから
そのファイルの編集はコンテナの外でやれば良いわけ
中にvimを入れておくのは開発中とかの一時的にしかやらんよ

っていうか使いづらいでしょ？　あんたvimの設定とかしてないの？
デフォルト設定で使いづらいからカスタマイズするのが常識だけど
コンテナの中にあるのはなんの設定もされてないvimじゃん

>>237
関係ないとか言ってないで、自分の解釈が大きくずれているって考えたほうが良いよ
ちょっと間違いレベルじゃなくて、方向性が大きくずれている
変な使い方をしているから、使いづらく感じるんだよ

>>239
残ってほしい開発後のプログラムがあるならgitでpushしとけば良くない？

設定あんまりシナイ派だけど、仮にするとしても、それこそvimrcとかgitでpushしてるものをcloneで持ってくれば設定なんて一撃で終わらない？それじゃあダメな理由とかある？

>>240
解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。
どんなに正しくても実際に使い難ければ正しくてもやらない。
もちろんセキュリティーや影響は考慮するけど、その辺問題なければ基本がどうとか関係ない。

PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。

>>241
gitは作業中断時に一時保存するための道具じゃないし、
設定しないなんて使いづらいだけだし、
いちいちcloneするとか面倒くさいことこの上ないし、

ホストでやれば普通にできることを、いちいちやらないといけないのか？
間違ってる方向に進むとこれから、あれやこれが使いにくいって愚痴るだけだぞ
すでに愚痴ってそうだがｗ　その原因はすべて間違った使い方にある
変な癖が付く前に矯正したほうがいい

>>242
> 解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。

便利に使うための手段を、お前がみんな捨ててるから、
（俺は不便な中で生活してるから）不便に思わないんだって言ってるだけじゃん

>>242
> PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。

お前のその考え方だと、間違った解釈をして間違ったやり方をやって
余計効率が悪くなった。PMBOKとかAgileはクソって言ってるようにしか見えないね

まず教科書守ってやろう。いまお前は教科書通りのことを守らずに使いづらいと言ってる

>>243
一時保存なんて利用用途で言った覚えはないけど、仮にそうだとしても何で一時保存でgit使ったらダメなの？

あなたって基本に従うってことに束縛されて思考が限定されてる気がする。自分だけでそういう方針で進めるのは勝手だけど、人にやり方強制しだすと嫌われるから考え改めた方が良いよ。
新卒ならまだ良いけど。

>>244
よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの？物凄く不便じゃない？

ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない？

>>246
gitはバージョン管理するための道具であって、
バージョン管理しないならタダの保存に過ぎないから

それにgit使うなら、コミットする時に、メールアドレスと名前の設定がいるだろ？
gitでpushするならssh鍵が必要だろ？
rootでやるわけないから、自分のhomeディレクトリがいるだろ
お前本当にコンテナの中でgitでpushとかしてるんか？
してねーだろ。使いづらいもんな

お前はまだ初心者で、どうせgitもオープンソースものをcloneするぐらいのことしか
したこと無いんだろ。基礎ができてないんだからまず教科書通りにやれと

PMに教科書通りのやり方を強制されて疲弊してる現場を見てきたから経験談として話してるだけ。
教科書通りやって現場がうまくまわってるならそうすればいいよ。
というか、むしろ教科書なぞってうまくいってる現場があるならそれ勉強会とかで話してほしい。見に行くので。

>>247
> よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの？物凄く不便じゃない？
ホストに置いたファイルを編集すればいいだけだろ。
それがコンテナの中にボリュームを通して見えてるんだから
コンテナの中に入って編集する必要がない。
コンテナの中の環境を整える必要もない

もっと便利なものが俺には見えてるんだが、
お前のやり方は何が便利なの？

できるといってるだけで便利なんてお前は一言も言ってないよね？
お前のやり方が俺は不便だと言ってる。反論は？
できる、やったらだめなの？は不便であることの反論にはならない

ということで、あなたのやり方を変えさせるつもりもないし、自分のやり方を変えるつもりもありません。
以上終わり。

>>247
> ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない？

ホストにあればgitにpushしたいと思ったタイミングでpushできるんだが

コンテナ消すと中で編集したファイルが消える。不便だからgit入れて忘れずにpushしなきゃって
コンテナのファイルを直接編集すると不便だと言ってなかったか？ｗ

>>251
俺はやり方をお前に押し付けてるんじゃなくて、

正しいやり方にしないとお前が困るという事実を言ってるだけ
お前はその事実に反論してない。困るのは自分だけだから
良いじゃないかって逃げてるだけだ。

>>249
そのPMが教科書通りにやってないだけだよｗ
教科書通りにやることが簡単だと思ってはいけない

教科書に反論するときは、教科書の場合と何が違っているかまで
理解してからじゃないといけない。

教科書になってるぐらいだから基本的には正しいんだよ。
それが当てはまらない理由を見つけない限り、教科書に反論してはいけない。
当てはまらない理由がわからないのは、理解してないってことになるんだから。

ほんとね。反論の一つでもできればまだいいんだが、
回避策はあるというだけじゃ、その方が良いってことにはならないんだよ。
全部回避策を入れないとやっていけないってことになってるんだから、

優れた方法っていうのは、回避策を使わずとも自然な形で実現できる
いちいち回避策を考えなきゃやってられないってのは、
やり方が間違ってる証拠でしか無いんだよ


余談だが、アメリカではツールをただ導入するのではなく、そのツールが
想定している使い方を学習して、やり方をツールにあわせるから効率的になるらしい。

日本だとツールを導入して、自分のやり方にカスタマイズさせる。
やり方を変えようとしないから生産性も変わらないし、
ツールのカスタマイズにコストも掛かるとのこと。それと同じだ

アプリケーションコンテナはyum, aptのパッケージ相当だと思ってるなぁ
基本的に使い捨てて常にクリーンなコンテナに出来るのがいいし, だからこそkubernetesとかで高い自己修復性を持てる

すると、Vimのような手動カスタマイズほぼ必須のアプリは
コンテナ化には適さないのか
docker searchしてもVimが出てこないのが不思議だったがそういうことか

そのカスタマイズ部分を, プラグインならホストからマップするか別コンテナで, 設定ファイルはホストからマウントする必要があるだろう

>>257
手動カスタマイズの有無じゃないな。
プログラム本体がコンテナに隔離されているので、
コンテナの外に自由にアクセスするものは適さない

もちろんプログラム本体がコンテナに隔離されているおかげで
コンテナの外がどうなっていようがいろんな環境に持っていける

コンテナと外部との通信は基本的にネットワーク通信で行うか
ボリュームとしてマウントしたディレクトリ経由で行う

ボリュームとしてマウントするから、コンテナの外がどのような
OSやディレクトリ構造であっても、コンテナの中からは同じよう見える
コンテナの外がどうなっていても中からは同じように見える。
Dockerの "仮想化" というのはこういう意味
（ハードウェアをソフトウェアで仮想的に作り出すという意味じゃない）

もちろん不可能ではないが面倒なだけ

これいわゆるイキリstaticおじさんが駄々こねて屁理屈連投してるいつもの案件じゃなくて
もしかして今回に限っては、Docker業界的にも、回避策やカスタマイズの工夫するくらいなら
コンテナはそぐわないからツールの使い方としてもやめてねって方向性にいつの間にか大勢が傾いてるのか

エクセルで小説書くなってだけの話

docker-tramp.el 便利だー。この機能使うためだけにemacs使いになっても良いと
思うくらい。コンテナにvimやsshdインストールする必要がありません。

いまWSL使ってDockerを使っているんですが、atomでホストに置いたファイルを修正して
それをイメージに反映させたいのですが、修正するたびにビルドするのが面倒です。

なのでボリュームを使ってホストのディレクトリをコンテナ内に共有しようと思っています。
Linuxではうまく動いているのですが、WSLだとうまく動かないのですが、
何が問題だと考えられますか？

と、書き込んでからひらめきました。
WSLで使ってるのはWindows上のDockerなので
パスの指定をC:\〜でやらないといけないきがします。

ビンゴでした！
　

こんな感じでホストのディレクトリがコンテナから見えました。
これでWindowsのatomを使って簡単に編集できそうです。

スレ汚し申し訳ありません

↑なぜかコマンドを書き込んだらエラーになったので怪しそうな所を大文字で書きます。

docker run -p80:80 -v"$(wslpath -wa www):/var/ｗｗｗ" -d ｈｔｔｐｄ

>>262
もとからvimもsshdも入れたりなんかしてないよ。
入れるもんでもないしね。

docker-tramp.elも別にいらないかな。
ファイルを修正したいならボリュームにすればいいだけだし、
sshdはdocker execを使えばいいので、

>>267
定位置にあるconfファイル等を色々いじってテストしたい時はどうしているの？

>>267
コンテナ提供するアプリエンジニアにdocker exec使えって言うの？

大した負荷のかからないコンテナをサーバーって言ってアプリエンジニアに提供するときある。ポート番号ちょっと変わってるサーバだと思って使ってくれてるよ。
本人はdockerだのコンテナだのを使ってる事に気づいてない。

>>268
だからボリューム使えばいいじゃない？

$ docker run -it debian cat /ｅｔｃ/debian_version
9.5

# ホスト上のファイルにすげかえ
$ docker run -it -v/ｅｔｃ/hosts:/ｅｔｃ/debian_version debian cat /ｅｔｃ/debian_version
127.0.0.1 localhost
略

>>269
普通に使ってるからなぁ。
アプリエンジニアがDockerfileを書かないで誰が書くというの？
アプリを動かすのに何が必要かを知ってるのはアプリエンジニアだけなんだが。

build, run, exec などを使って正しく動くコンテナのイメージを作るまでがアプリエンジニアの仕事で
コンテナを動かす環境を作って指定されたイメージを起動するのがインフラエンジニアの仕事

>>270
アプリエンジニアがDockerイメージを作ってないのはおかしい。
アプリを作ってる人でないと、アプリを動かすのに必要なものは知らないんだから
「手元のマシンだと動きました」「ライブラリのバージョンが違ってるんですねー」
これをなくすためにDockerがあるというのに。仕事の分担が間違ってる。

動くコンテナのイメージ作るのがアプリエンジニアの仕事なら、結局必要なミドルをアプリエンジニアが入れる事になってそれこそインフラエンジニアの作った本番環境と差異が出てしまうと思うのですが。

まあ新規や中小規模のサービスならそれでも問題無いと思うけど。

大きい会社だとIDEしか使ったことがない、CUI触ったこと無いアプリエンジニアとか普通に居りましてですね

まあその程度のアプリエンジニアはいずれ淘汰されると切り捨てるなら問題無いんですけどね。