[過去ﾛｸﾞ] Docker Part2©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
342: 2018/08/08(水)23:10 ID:9RbiD8jy(1) AAS
ケンカはやめて（＞＜）
343(1): 2018/08/09(木)06:19 ID:/JzHzLjB(1) AAS
Docker-composeで使い捨てVMを構築するのが遅いというところがよくわからない。VM(dockerホスト)は一回構築したら終わりで、後はそこにコンテナを作ったり消したりするだけじゃないの？
344: 2018/08/09(木)13:04 ID:xAQpubuL(1) AAS
>>343
今までの話の流れからすると、CIでテスト実行するたびにVMの作成と破棄をしていたってことでしょ？
>>327がVMでも10秒以下の差しか無いから問題ないみたいなことを言ってるから
（VMの中でDocker-Composeが動いてるのは、この話にあまり関係ない）
当たり前だけどDockerコンテナの起動に比べればVMの起動は遅い
起動の差を10秒以下にするには、VMのイメージを作ってないと不可能
あとできればSSDとかクラウド使うとか。それでもDockerの1秒に比べたら遅い
そして肝心のVMのイメージを作成するのに時間がかかるっていうねｗ
Dockerの場合はアプリの実行環境が含まれる。だから構築に時間がかかるVMは
色んな種類のアプリのテストに使い回すことができる。
Dockerを使わないなら、アプリを動かすためにVMのイメージに
実行環境を含めないといけない。当然アプリごとにVMのイメージが必要になる。
DockerでもアプリごとにDockerイメージが必要になるのは同じだが
Dockerはキャッシュがあるから、Dockerイメージの作成は短時間でできる。
VMだとキャッシュはないし起動に10秒かかるし、作成したイメージの
サイズもでかいし頻繁にVMイメージの作成なんかやってられないよ
345(3): 2018/08/09(木)16:12 ID:+YyDvSZH(1) AAS
今までVPSとかで動かしていたものをコンテナ化してGCE辺りに移そうと思うんだけど
DBの保存や出力したファイルの保存はみんなどうやってるの？
結局マウントできるディスクが必要なんじゃないかってところで今頭を抱えてる
346: 2018/08/09(木)17:43 ID:UwrKl0TS(1/3) AAS
>>345
まずアプリサーバーとデータサーバーを分けて考える。
Dockerでやる価値が高いのはアプリ
アプリサーバーには原則としてデータは保存しない
その前提を守っているならば、簡単にスケールできる
（VMインスタンスやDockerコンテナを追加することで性能をあげられる）
という話。
その場合にデータはどうするかと言うと、
データサーバーはアプリサーバーみたいに簡単に
台数を増やしたりできない
一番楽なのは、難しいそれらをクラウドが提供するサービスに置き換えてしまうこと。
つまりGCPであればCloud SQLやCloud Storageを使う
これらは信頼性も性能も（金額次第だが）高くできる。
347: 2018/08/09(木)17:47 ID:UwrKl0TS(2/3) AAS
>>345
どうしても自力でやりたいならば、Dockerのボリュームという
機能を通してホスト上に保存するのが一番手っ取り早い
例えばMySQLであれば データディレクトリである
/var/lib/mysql をホスト上のディレクトリにボリュームで
マッピングさせる
MySQL ぐらいだったらシンプルだし事例も多いので簡単なんだが
何処に何を保存するのかよくわからんようなアプリは
それを把握することに時間を奪われるだろう
348: 2018/08/09(木)17:55 ID:UwrKl0TS(3/3) AAS
>>345
> 結局マウントできるディスクが必要なんじゃないかってところで今頭を抱えてる
結局マウントできるディスクが〜というのは
初心者がよく考えてしまうことなんだけど、
これは当たり前
なぜなら（物理マシン or 仮想マシン上で動く）Dockerコンテナっていうのは
（物理マシン or 仮想マシン上で動く）アプリと同質のものだから。
単にアプリの実行環境が、コンテナとしてアプリに一体化してるに過ぎない
アプリはデータを何処に保存する？
物理マシン or 仮想マシン上のディスクでしょう？
だからDockerコンテナもそれは同じことなんだよ
Dockerコンテナを使った時データの保存先をどうすれば良いのか悩むのは
Dockerコンテナがアプリと同質のものであることを理解してない証拠
349(1): 2018/08/13(月)18:09 ID:v0wq29mQ(1) AAS
最近コンテナってものを知ったんだけど、上の説明だとフラットパックってのとの違いがわからない
スタンダロンなアプリじゃなく、ソフトウェア群の、何かしらのフロントエンドにドッカーが向いてるってこと？
350(2): 2018/08/13(月)21:26 ID:nXCS+eUE(1) AAS
コンテナ自体が非常に難しい概念なんだよ
どうもLinuxの世界で発祥したもので、昔からLinuxやってる人でないとわからないらしい
「最近流行りのDockerなるものをやってみたい」というヤツには到底無理(俺含め)
351: 2018/08/13(月)21:45 ID:xnhwDoUS(1) AAS
Solarisのゾーンがコンテナの先駆けじゃない？
352: 2018/08/13(月)23:10 ID:XRxrVOUh(1) AAS
FreeBSDのjailとか？
cgroupの概念は含まれてないけどね
353: 2018/08/14(火)00:05 ID:kAynbxnX(1/6) AAS
>>350
説明してる奴が「難しいこと理解した俺スゲー」ってのを
自慢げに小難しく語るのが問題なだけ
プロセス分離のためにcloneを拡張して名前空間を追加したよ
cloneだけだと不便だからunshareとsetns追加したよ
cgroupでVMのごとくリソース分配可能にしたよ
コイツラ直接イジるのは面倒だからコンテナエンジン作ったよ
基本この4ステップだけじゃねぇの？
…って言う俺もコンテナのこと全然知らんのだが
354: 2018/08/14(火)00:55 ID:M/lw6/kx(1/3) AAS
>>350
技術を理解するのと目的を理解するのをごっちゃにしてるから
Dockerが解決する問題は（主に自分が作った）アプリをいろんな環境で
動かそうとしたら、アプリをぽんとインストールするだけじゃ動かなくて、
そのアプリが依存してるなにかまで環境を整えなきゃならないだろ？
だから発想の転換でアプリ自体に環境を入れてしまえばいいじゃないかってこと。
外部ライブラリを全部アプリに静的リンクするの発展形だよ
まずそこを理解しないといけない
技術だけ理解すると、やれjailがなんだとかcgroupがなんだとか、
そればっかり言って、なんのために作られたのかという目的を見失う。
その結果、同じ技術を使った応用例のVMの代わりにするのが目的だと勘違いする
コンテナという技術を知るのではなくて、どんな問題があって
それを解決するものがDockerなんだって理解するのが先
355: 2018/08/14(火)01:03 ID:M/lw6/kx(2/3) AAS
補足だが、
> （主に自分が作った）アプリをいろんな環境で
なんで「自分が作った」と書いているのかというと
他人が作って、ディストロに収録されているものは、
それ動かすための、環境もすでに整えてあるから
それがディストロの大変な仕事なわけで。
だから自分が作ってないものを動かしてるだけの人は
（物理マシン or 仮想マシンの上に）ディスロの環境整えられてる
パッケージ入れて使っても同じじゃんって思ってしまう。
技術は理解していても、そもそもの問題を理解していから
Dockerが必要な理由もわからない
356(1): 2018/08/14(火)01:10 ID:M/lw6/kx(3/3) AAS
>>349
フラットパックってのがよくわからない。
一般的な用語？ググっても見つからないんだが。
> スタンダロンなアプリじゃなく、ソフトウェア群の、何かしらのフロントエンドにドッカーが向いてるってこと？
既存のいろんなものをつく合わせて
スタンドアロンなアプリを作りましょうって話。
何かをやるためにDockerを使うと便利なんじゃなくて、
Dockerは「とある物」を作るための道具だよ
その「とある物」っていうのがスタンドアロンなアプリ
動かしたいアプリが、動かすのにアプリ以外の環境を整えることが
必要なアプリであっても、Dockerを使えばアプリに組み込んで
スタンドアロンなアプリに作り変えることができる
Dockerはスタンドアロンなアプリを「作るもの」
であって「動かす環境」ではないんだよ
そこを根本的に間違ってる人がいる。
357: 2018/08/14(火)02:08 ID:kAynbxnX(2/6) AAS
>>356
外部ﾘﾝｸ:flatpak.org
358: 2018/08/14(火)02:29 ID:Ttl7PXT/(1/2) AAS
カタカナでググったから見つからなかったのかｗ
Linuxデスクトップ向けアプリケーション仮想化機構「flatpak 0.6.13」リリース
外部ﾘﾝｸ:mag.osdn.jp
> Linux向けのアプリケーション仮想化技術「flatpak」開発チームは10月25日、
> 最新版「flatpak 0.6.13」を公開した。プロジェクトのWebサイトより入手できる。ライセンスはLGPL。
>
> flatpak（旧名称「xdg-app」）は、Cで実装されたLinuxデスクトップアプリケーション向けの
> 仮想化機構。アプリケーションをOS環境とは切り離されたサンドボックス環境内で
> 実行することでセキュリティを高め、またほかのアプリケーションからの干渉を最小限にできる。
> サンドボックス環境の構築にはcgroupsやseccomp、ネームスペース、バインドマウントなどの
> Linuxカーネル技術やOpen Coutainer InitiativeのOCIフォーマットなどを利用しており、
> 単一のアプリケーションパッケージをさまざまなLinuxディストリビューションで動作させることができるという。
Dockerのアイデアをパクってデスクトップアプリ用にした技術だね
技術的にはかなり近いものを使ってるし、OCIフォーマットは
Docker社 vs CoreOS社の標準化争いで生まれたものだし
違いがわからないというのなら、その言うべき相手は
後から登場したflatpakに言うべき言葉だろう
なんでflatpak作ったの？Dockerでいいじゃない？と。
359: 2018/08/14(火)03:11 ID:Ttl7PXT/(2/2) AAS
> なんでflatpak作ったの？Dockerでいいじゃない？と。
この質問に自己レスする前に
第513回 新しいパッケージの仕組み，Flatpakを使用する
外部ﾘﾝｸ:gihyo.jp
> FlatpakとSnapsの最大の違いは，Flatpakはアプリケーション専用で
> あることでしょう。よって，GUIアプリケーションであれば
> Flatpakのほうが快適に使用できるものが多いのですが，実際はケースバイケースです。
本当にGUIアプリ専用だったのか？
Flatpak・Snaps も Docker も「使う側」の視点と「作る側」の視点がある
Flatpak・Snapsはどちらかといえば「使う側」が焦点となっており
こんなパッケージを用意しましたから使ってくださいって感じだろう。
エンドユーザーがデスクトップPCで使うアプリ用
Dockerはどちらかといえば「作る側」がメインなのでアプリのインストールや実行はCLI、
そしてGUIアプリは作れなくはないがメインのターゲットではない。
主に開発用のツールや自社開発のウェブサービスを構築のためによく使われている
Dockerは「作る側」がメインなので何度も言ってるように、アプリエンジニアにこそ必要なもの。
だからパッケージ入れて（ちょっと設定して）使うだけのインフラエンジニアはVMの役割とごっちゃにしやすい
自分専用にカスタマイズしたアプリを作りたい人はDockerを選ぶのでは？
Flatpakでパッケージの作り方を調べてみたが、
Dockerfile書くだけで作れるDockerよりも大変そうに思える
なんでflatpak作ったの？の答えは、エンドユーザーのために作ったパッケージを、
もっと使いやすく提供したいためだろう。
360(1): 2018/08/14(火)10:08 ID:M6PcTN6D(1/4) AAS
別にコンテナの用途限定する必要は無いと思うけどなぁ。便利に使えたらそれでいいし。Dockerを○○に使うなって言うならその代替案も言って欲しいけど言わないし、仮に言えたとしてもそれはDockerで実現した方が簡単というオチになるのが目に見えてるし。
正しさとは都合。正しさを振りかざすのは自己満足を他人に押しつける行為。
361: 2018/08/14(火)11:51 ID:kAynbxnX(3/6) AAS
ドッカーのスレだから、ドッカー万歳な人がいてもおかしくないよ
362(1): 2018/08/14(火)14:07 ID:ghMKDHT1(1/4) AAS
>>368
> 別にコンテナの用途限定する必要は無いと思うけどなぁ。
制限なんかしてないよ？
コンテナの用途は、アプリケーションコンテナや
システムコンテナといった使い方がある。
だがここはDockerのスレなんだからDockerの話をするべきで、
Dockerはアプリケーションコンテナとして設計されてるのは事実
だからコンテナを違う用途で使いたいなら、
別のスレに行くのが適切ってだけの話
363: 2018/08/14(火)14:12 ID:ghMKDHT1(2/4) AAS
> Dockerを○○に使うなって言うならその代替案も言って欲しいけど言わないし
何に使いたいのか言わないから言いようがない
どうせシステムコンテナなんだろうが、
システムコンテナとして使いたいなら
LXD や OpenVZ を使えばいいだろ？
364: 2018/08/14(火)14:21 ID:ghMKDHT1(3/4) AAS
ほらよ。スレ立ててやったから
コンテナを仮想マシン代わりとして使いたいならそっちに移動しろ
LXD コンテナを仮想マシンとして使う (Not Docker)
2chｽﾚ:linux
365: 2018/08/14(火)14:30 ID:ghMKDHT1(4/4) AAS
>>362は>>360宛て
366(2): 2018/08/14(火)14:37 ID:M6PcTN6D(2/4) AAS
LXDやOpenVZなんて知らんし、もしスレたてるとすれば仮想マシンとしてDockerを使うスレにするべきでしょ？
なんでそんなにDockerを仮想マシンとして使わないように誘導するの？おかしくない？
367(1): 2018/08/14(火)14:42 ID:M6PcTN6D(3/4) AAS
Googleクラウドは仮想化なんか使ってなくて、物理サーバにコンテナ立ち上げてるらしいけど、あなたはGoogleがコンテナ使い方間違ってるからGoogleのインスタンス使うなって言うわけ？
368(2): 2018/08/14(火)14:48 ID:M6PcTN6D(4/4) AAS
Dockerの使い方を縛らないと言いつつサーバ用途には使わせないように誘導するのすごく卑怯だよね。
声がでかくて社内政治だけがうまい奴に似てて、あなたに物凄い嫌悪感を持ったよ。
369: 2018/08/14(火)15:04 ID:kAynbxnX(4/6) AAS
外部ﾘﾝｸ:stackoverflow.com
> Versioning. Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc.
> The history also includes how a container was assembled and by whom, so you get full traceability from the production server all the way back to the upstream developer.
> Docker also implements incremental uploads and downloads, similar to "git pull", so new versions of a container can be transferred by only sending diffs.
サンドボックスとしてDockerを使うメリットってこれかな？
コンテナ知らん俺でも強力だとわかる
370(1): 2018/08/14(火)15:14 ID:kAynbxnX(5/6) AAS
お前ら暑いからってイライラするなよな…
git likeを謳ってるからDocker hubなんかもあるのな
flatpakのflathubよりは随分開発寄りな印象を受ける…サインインしてないけど
ご興味のある方はどーぞ
外部ﾘﾝｸ:hub.docker.com
外部ﾘﾝｸ:flathub.org
371: 2018/08/14(火)18:38 ID:xLHQglRN(1/6) AAS
>>366
> LXDやOpenVZなんて知らんし、
無知を告白されても、勉強したら？で終わる話なんだが
知らないほうが悪いんですよ
372: 2018/08/14(火)18:41 ID:xLHQglRN(2/6) AAS
>>366
> なんでそんなにDockerを仮想マシンとして使わないように誘導するの？おかしくない？
なんで仮想マシンの代わりとしてコンテナ技術を使うものがあるのに
仮想マシンの代わりとして使うことを想定してないDockerを無理やり使うわけ？
その方がおかしいでしょ。
どうせ間違った使い方をして、使いづらいと文句をいうのが目的なんだろう？
373: 2018/08/14(火)18:49 ID:xLHQglRN(3/6) AAS
>>367
> Googleクラウドは仮想化なんか使ってなくて、物理サーバにコンテナ立ち上げてるらしいけど、あなたはGoogleがコンテナ使い方間違ってるからGoogleのインスタンス使うなって言うわけ？
お前用語の使い方めちゃくちゃ。
> Googleクラウドは仮想化なんか使ってなくて
Googleクラウドが何を指しているのか知らないが、
GCPのことであれば、仮想マシンを使ってる。
仮想化というが、ハードウェアを仮想化（＝ハードウェアエミュレータ）したのか
アプリケーションの実行環境を仮想化（＝ハードウェアのエミュレートはしてない）
したのかはっきりしない
> 物理サーバにコンテナ立ち上げてるらしいけど
物理サーバにコンテナを立ち上げるのは間違った使い方ではない
物理サーバーに直接アプリケーションコンテナを立ち上げてもいいし、
物理サーバーにシステムコンテナを立ち上げても良い
間違った使い方と言ってるのは、Dockerをシステムコンテナとして使うこと
Googleがアプリケーションコンテナをシステムコンテナとして使っているなんて
どこを見ても書いてない。
参考 すでにGoogleは全部のソフトウェアをコンテナに乗せており、毎週20億個ものコンテナを起動している
外部ﾘﾝｸ[html]:www.publickey1.jp
> Googleのインスタンス使うなって言うわけ？
やっぱりその言い方をしてる所からすると
GoogleのクラウドとはGCPの事を言っているようだが、
GCPは仮想マシンを使っている
374: 2018/08/14(火)18:53 ID:xLHQglRN(4/6) AAS
>>368
> Dockerの使い方を縛らないと言いつつサーバ用途には使わせないように誘導するのすごく卑怯だよね。
あのさぁ、Dockerとコンテナは別物なんですよー？知ってますかー？小学生ですかー？
コンテナの使い方は色々あるが、
Dockerはアプリケーションコンテナを作るためのものなんだから
システムコンテナとして使うなよ。
コンテナの使い方は縛ってないが、Dockerの使い方は縛ってる
縛ってると言うか、Dockerはアプリケーションコンテナを作るために
作られたんだよ。
何度も言うが、コンテナの使い方は縛ってない。
375(1): 2018/08/14(火)18:59 ID:xLHQglRN(5/6) AAS
>>370
> git likeを謳ってるからDocker hubなんかもあるのな
> flatpakのflathubよりは随分開発寄りな印象を受ける…サインインしてないけど
だからDockerはアプリケーション開発者のためのものなんだよ
Docker hubに置いてるものは、公式のものはそれを利用して
独自のコンテナを作るため、アプリを開発するためな
それ以外の多くは自分や自社専用に開発したアプリ
（公開可能なもの）を置いているのが大半
そしてそのまま使えるアプリが置いてあったりするのは極稀
参考までに言っておくと非公開のDockerイメージを起きたい時は
プライベートリポジトリを使う。
GCPやAWSはDockerのプライベートリポジトリを提供している
376: 2018/08/14(火)19:28 ID:kAynbxnX(6/6) AAS
>>375
ご説明どうも
LXC/LXDと違って配布とバージョニングが肝要なのね
377(2): 2018/08/14(火)20:07 ID:Rn+J0ap2(1) AAS
>>377
シラネーヨバーカ。
お前が自分の正しさ振りかざして好き勝手なこと言ってるのがムカつくって言ってるんだよ。
絶対にお前と一緒の現場で働きたくないし、お前が上司だったら人事に文句言いまくって転職するわ。
378: 2018/08/14(火)20:10 ID:J8E8MYcP(1) AAS
この怒涛の連レスと変な引用がWebやプログラム板の荒らしそっくりだ
379: 2018/08/14(火)20:35 ID:xLHQglRN(6/6) AAS
> 377 名前：login:Penguin[sage] 投稿日：2018/08/14(火) 20:07:26.17 ID:Rn+J0ap2
> >>377
> シラネーヨバーカ。
俺も同意見である
380(2): 2018/08/15(水)01:16 ID:ugls1Kd9(1/2) AAS
Dockerを使うと次のようなことできる？
複数の各Dockerが独立してLANインターフェイスに専用のプライベートIPアドレスを持って、
ホストのルーティング設定とLANインターフェイスを利用してネット側と通信する。
＜Docker＞
□ □ □
| | |
==========⇒ホストのルーティングを使ってネットへ
381: 2018/08/15(水)01:17 ID:ugls1Kd9(2/2) AAS
>>380
自己レス
Dockerコンテナの間違いでした。
382(1): 2018/08/15(水)13:20 ID:uskt4Uvb(1) AAS
>>380
新しいネットワークを作成して使えるよ。これじゃだめ？
各コンテナ間のネットワークの独立性は実現できると思うけど
docker network create net1
docker network create net2
docker run -it --net=net1 debian /bin/bash
docker run -it --net=net2 debian /bin/bash
383: 2018/08/16(木)00:43 ID:kHU6PfSr(1) AAS
>>382
レスありがとうございます。
参考にしたいと思います。
分からないので、ちょっと書籍を読んでいきます。
384(1): 2018/08/17(金)19:01 ID:LyzN7uI2(1) AAS
dockerとちょっとしたサーバーあれば大規模ネットワーク作れそうだね
385: 2018/08/17(金)20:33 ID:x+SQYw9w(1) AAS
大規模ネットワークを作るならkubernetesとか使うべきだよ
386(1): 2018/08/18(土)00:44 ID:bBPq1AA+(1/2) AAS
>>384
大規模ネットワークは単にその手段ではないのか
387: 2018/08/18(土)08:03 ID:o1onkvNG(1) AAS
>>386
レガシーの為にサマータイムを導入し、打ち水を都公認の暑さ対策として導入すべく水まいて地表の温度低下を計測するも湿度や不快指数は見ないこの国で手段とか目的とか言い出すのはナンセンスですよ
388: 2018/08/18(土)10:11 ID:B/BAtWOD(1/2) AAS
国なんかに考え方決められちゃう人って・・・
389(1): 2018/08/18(土)11:00 ID:S06djVVH(1/2) AAS
dockerで大規模ネットワークっていったら
もう考え方から変わってサーバーという概念がなくなる。
複数のサーバーで構成された一つの巨大なOS（クラスタ）があって
そこでdockerコンテナというアプリがあちことのどこかで
起動したり消えたりするイメージになる
それを実現するのがKubernetes
ただ、理屈はそうなんだが現実として
そこまでのスペックは求められていないｗｗｗ
390: 2018/08/18(土)13:41 ID:B/BAtWOD(2/2) AAS
やっぱこのくらいの規模じゃないとあんま意味ないよな
外部ﾘﾝｸ:kubernetes.io
391(1): 2018/08/18(土)14:41 ID:S06djVVH(2/2) AAS
念の為に行っておくと、意味がないのはKubernetesね
Dockerはクラスタにすばやくアプリをデプロイするのに使われるが
Dockerそのものはアプリケーションの仮想化による
可搬性の高さがうりなので違うOSで動かしたりとか
同OSの他のシステムの影響を最小限にできるとかいうメリットが有る
392: 2018/08/18(土)15:46 ID:bBPq1AA+(2/2) AAS
>>391
可搬性の高さのことをすっかり忘れていた。
ネットワーク単位を分けられることのメリットが自分にはおおきくて。
393(1): 2018/08/20(月)12:44 ID:KhDqHNJn(1) AAS
コンテナの台頭で仮想マシンの未来に暗雲--Diamanti調査
外部ﾘﾝｸ:japan.zdnet.com
> 最も広く採用されているコンテナ技術が「Docker」（52％）と「Kubernetes」（30％）と
>なっているのは驚くに値しない。回答者の71％は仮想マシン上でコンテナを配備しているため、
>仮想マシンが姿を消すということはないだろう。仮想マシンの存在価値はあるはずだ。
>しかし、ITリーダーらは仮想マシンのライセンスコストを抑えたいと考えている。
> 興味深いことに、コンテナに向かうこの動きは企業幹部らによって推進されているわけではない。
>同調査によると、コンテナの採用を主に推進しているのは、プラットフォームの設計者（22％）と、
>開発者（22％）だという。これらの後にはIT運用チーム（17％）と、統合DevOpsチーム（17％）が
>続いており、企業幹部はたったの9％となっている。
> コンテナは主に、クラウドネイティブなアプリケーションで使用されている（54％）。
>その後に、ステートレスな軽量アプリケーション（39％）、クラウドへの移行（32％）、
>レガシーアプリケーションの近代化（31％）が続いている。
> また、本番環境でコンテナを稼働させている回答者が考えている「最大の課題」として、
>インフラがトップに挙げられており（30％）、その後にはセキュリティ（22％）、
>配備（22％）、パフォーマンス（19％）、永続的ストレージ（12％）が続いている。
394: 2018/08/22(水)08:59 ID:j+z99P2p(1) AAS
>>393
>企業は仮想マシンのライセンス料金に大きな不満を抱いているという知見を得ている。
>VMwareは自社の利益を追求するうえで、同社の社名に冠された仮想マシン（VM）に依存しなくなっている。
>VMwareがこれまで軸足を置いていた市場が、競合他社のハイパーバイザの台頭によって侵食されたのは事実だが、コンテナの登場によってさらに大きな影響がもたらされている。
>回答者の71％は仮想マシン上でコンテナを配備しているため、仮想マシンが姿を消すということはないだろう。仮想マシンの存在価値はあるはずだ。しかし、ITリーダーらは仮想マシンのライセンスコストを抑えたいと考えている。
この記事のベクトルがはっきりしない。
なにがいいたいのか？
395: 2018/08/22(水)13:19 ID:pivahsct(1) AAS
頭の悪さが滲み出てくる記事だよな。
396: 2018/08/22(水)13:36 ID:SRjEX/kw(1) AAS
自分の頭が悪いだけだろｗ
397: 2018/08/22(水)15:20 ID:sHVRQKWS(1) AAS
18.06.1 が来てた
398(2): 2018/08/23(木)17:03 ID:ZGFS8Yk4(1/3) AAS
試しに、公式のubuntuでコンテナを動かしてみたんだけど、
docker run -it ubuntu bash
プロンプトに、ping , ip a , ifconfig というような基本的なコマンドすら実行できない。
ネットワークの状況も確認できない。
これは、どう使うことが想定されているんでしょうか。
centosのイメージでも、pingコマンドはあったけど、ip a がないので、
ネットワークの調査ができない。
DockerコンテナからIPIPトンネルを構築したいと考えていたんですが、
とりあえずラズパイ並みにつかえるようにするにはどうすればいいでしょうか。
399(1): 2018/08/23(木)17:48 ID:q1z8N/B0(1/5) AAS
>>398
だからさ、Dockerは仮想マシンじゃないって
その中に入って色々作業するものじゃないんだよ
Dockerはアプリケーションコンテナなんだから、
そんなコマンドは必要な場合に入れれば良いんだよ
（必要になることは殆ど無い）
400: 2018/08/23(木)17:49 ID:q1z8N/B0(2/5) AAS
いつになるかわからんが次スレまで行ったら
テンプレにしっかり書いてなきゃいかんな
401(1): 2018/08/23(木)17:55 ID:7FvXZ15y(1/2) AAS
>>398
そいつのDockerfileな
外部ﾘﾝｸ:github.com
他のコンテナ作るときのベースだから本当にミニマムやで
402(2): 2018/08/23(木)18:41 ID:ZGFS8Yk4(2/3) AAS
>>399
>>401
レスありがとうございます。
Dockerfileを見てみると、
ADD ubuntu-bionic-core-cloudimg-amd64-root.tar.gz /
だけがコンテンツみたいに思えます。
一応、ubuntuって書いてありますね。
イメージに、centosとか、ubuntuとか、ありますが、
centos7などとはまったくの別物なんですね。
せめてラズパイみたいに使えるイメージがあればいいんですけど。
実験でホストを汚したくないので。
apt-getとか、yumがつかえるようなやつ。
Docker Hubでなにかオススメあるでしょうか。
環境ができたら、今度はそれを自分用としてイメージ化したい。
403: 2018/08/23(木)18:43 ID:q1z8N/B0(3/5) AAS
>>402
> せめてラズパイみたいに使えるイメージがあればいいんですけど。
だからそういう使い方をするものじゃないから
希望するのが見つからいように思えるんだって
404: 2018/08/23(木)18:52 ID:7FvXZ15y(2/2) AAS
>>402
Hyper-VでもKVMでもVirtualBoxでも好きなのを選べばいいぞ
405: 2018/08/23(木)18:52 ID:AO6wJAqi(1/2) AAS
みた感じ、仮想マシン派もDocker派も両方ディスる猛者現るって感じだな
406: 2018/08/23(木)18:55 ID:q1z8N/B0(4/5) AAS
> せめてラズパイみたいに使えるイメージがあればいいんですけど。
お前が欲しいと思うようなものはない。イメージは原則として自分で作るものだから。
使うイメージはDockerが用意したdebianやubuntuなどの
最低限のイメージのみ。それを元にして自分で作る
> 実験でホストを汚したくないので。
Dockerはそういうものの代わりとして設計されてないので
すぐにお前の実験はできなくなると言っておく。
それはDockerに問題があるのではなく、お前の使い方が間違っている
407: 2018/08/23(木)18:58 ID:q1z8N/B0(5/5) AAS
ラズパイと同じ環境がほしいなら、
仮想マシンでRaspberry Pi Desktop X86でも使えばいいだろ
Dockerはアプリケーションに実行環境を一体化させるものだって
なんど言っても理解しないやつが湧いてくる
408: 2018/08/23(木)19:10 ID:ZGFS8Yk4(3/3) AAS
すみませんでした。
自分でもっと勉強します。
409(1): 2018/08/23(木)20:06 ID:NhXd7pKF(1) AAS
Dockerて、OSやアプリの仮想イメージファイルをコマンドで組み合わせ
メモリ上でつなぎ合わせて一つの仮想ディストリビューションをブートしたように
見せかけるソフトって理解でよい？
410: 2018/08/23(木)20:15 ID:/Er2oz0C(1) AAS
全然違うかなー
411: 2018/08/23(木)20:47 ID:AO6wJAqi(2/2) AAS
使ったこともないのに適当な事書くと常駐のスレ主に怒られちゃうからな
ちょっと調べた感じ、initなしでも動くそうだがゾンビプロセス問題とかめんどくさそうでマニアの領域
initから開始したらそれはそれで、それLXC(LXD)やん！って印象
412: 2018/08/23(木)21:22 ID:jewCS8ED(1) AAS
>>409
WindowsのDLLヘル対策の超強化版って考えればいい。
知らん人は知らんかもしれんがｗ
Windowsでアプリを起動する時、外部DLLを使用していることが多々ある
そうすると、外部DLLのバージョンが変わって互換性がなくなった時、
アプリが動かなくなる可能性がある。
だからアプリのディレクトリに外部DLLを入れてシステムのDLLを
使用しないようにしましょうっていうのがWindowsのDLL対策
Dockerもコレと同じでアプリを起動する時、OSのライブラリなんかを使用してる
そういうのを先にインストールしたりしていなければいけないが
アプリのDockerイメージの中に一切合切入れてしまいましょうっていうのがDockerの考え方
413: 2018/08/23(木)22:53 ID:Rl2wmT+c(1) AAS
視野狭窄の輩がバージョンドシンボルの話と混同しそうな予感
414(1): 2018/08/23(木)23:04 ID:YJtvG1Lc(1/2) AAS
Kubernatesの日本での呼び方って決まってるの？
会うひとみんな違う言い方するし
YouTubeで外国語聴いてもみんな結構違う
415(1): 2018/08/23(木)23:22 ID:igELEe5F(1) AAS
>>414
こっちで
2chｽﾚ:linux
416: 2018/08/23(木)23:42 ID:YJtvG1Lc(2/2) AAS
>>415
誘導ありがとうございます。
向こうに書きました
417: 2018/08/24(金)00:06 ID:wl1baohm(1) AAS
jewCS8ED が、あっちで、くうねるさんだーす と書き込みました。
418(1): 2018/08/31(金)09:43 ID:UOMp0l5m(1) AAS
dock-composeで
全く同じ内容のDockerfileで
追加するファイルの中身だけ異なるイメージを2つビルドしたら
後でビルドした方はキャッシュの影響で先にビルドしたイメージと全く同じ内容になってしまう
イメージに名前付いてないけど
名前付けたら良いのか？
419: 2018/09/03(月)19:27 ID:lFOQrHc5(1) AAS
>>418
名前変えずにbuildしたらキャッシュじゃなくてすでにimageに入ってるんで
作成されたイメージ一回rmiしないとダメなような
420: 2018/09/04(火)11:08 ID:XGRY6CNs(1) AAS
--buildじゃだめ？
421: 2018/09/09(日)06:08 ID:cEYtNNsu(1) AAS
>>389
それ、地震対策になるよね。
物理サーバーをまったく意識しない、
まるで半永久的なベースシステムがあれば、
コンテナをぜひ動かしたい。
422: 2018/09/09(日)09:40 ID:ZTk8dQJu(1/2) AAS
それだけではならないですよ
423: 2018/09/09(日)10:55 ID:e5pDDvY7(1) AAS
そのうちクラウドサービスがコンテナクラスタを用意して
コンテナ毎の課金とかになるんだろうな
424: 2018/09/09(日)11:12 ID:ZTk8dQJu(2/2) AAS
そのうちもクソもコンテナのクラウドホスティングサービスは既にあるじゃん
425: 2018/09/09(日)19:24 ID:Afzp+wKU(1) AAS
大手クラウドはGKE, AKS, EKSと揃い踏みなんだよなぁ
426: 2018/09/13(木)18:00 ID:A2WBsHxK(1) AAS
ubuntu18.04のホスト上で docker17.06.2-ceで動作検証してるんですけど、
質問させてください。
docker-compose.ymlで
volumes:
- /etc/localtime:/etc/localtime:ro
- /usr/local/etc/docker/my.cnf:/etc/my.cnf:ro
- /usr/local/etc/docker/my.cnf.d/:/etc/my.cnf.d:ro
こんな感じにしてbuildやpullを済ませ up -d した時に、
ERROR: for (コンテナ名) Cannot start service (サービス名): error while creating mount source path '/usr/local/etc/docker/my.cnf': mkdir /usr/local/etc/docker: read-only file system
こういうエラーが出ます。
root@docker:~# ls /usr/local/etc/docker/
my.cnf my.cnf.d
この通りマウント元は存在するんですが、
どこ確認したら良いでしょうか…？
427(3): 2018/09/13(木)19:39 ID:5kXiEAIj(1) AAS
ファイルをマウントしようとしているように見えるんだが、そこはディレクトリでないといかんのではないかと
あと何故2017年06月版を使おうとしているのだろう
428: 2018/09/14(金)09:15 ID:O0WiB81l(1) AAS
>>427
あ、変に端折ってしまいましたが、
/usr/local/etc/docker/my.cnf.d/(ディレクトリ)も
全く同じエラーでマウントできていない状態です。
docker-ceが1703なのはsnappy版だからで、
ubuntu1804のOSインストーラーでdocker関連を選んだらそうなったから、です。
別にsnappyが使いたいわけでもない（というかsnappyとか今回初めて知った）ので、
明らかな設定ミスとかが見つからなければ、docke-ceを上げてみるのも手ってことですね。
429: 427 2018/09/14(金)18:06 ID:4XP848iF(1) AAS
- /usr/local/etc/docker/my.cnf.d/:/etc/my.cnf.d:ro
ホスト側ディレクトリ指定の末尾にスラッシュ付いてるけど、Dockerの公式ドキュメント（外部ﾘﾝｸ[html]:docs.docker.jp）だとそういう書き方してる例ないぞ
とりあえずシンプルに
- /usr/local/etc/docker
とだけ書いてマウントできるかどうか確認してから少しずつ設定詰めてみ
あとバージョン気にしたのは単に「セキュリティだの個人情報保護だのが騒がれるこのご時世に1年以上前のバージョンを使わざるを得ない事情でもあるのかなぁ」って思っただけよん
430: 2018/09/15(土)07:01 ID:yI+cCQi1(1) AAS
最新を追いかけてバグにハマる例は後を絶たない
431: 2018/09/24(月)01:08 ID:3WJGu+tF(1) AAS
docker stop container
してから、commit するのはなぜ？
432: 2018/09/24(月)04:53 ID:h/F6DQep(1) AAS
「docker commit」で検索！
433: 427 2018/09/25(火)15:20 ID:zdGJMagM(1) AAS
ファイルを指定しちゃダメだというのと
ホスト側ディレクトリの最期にスラッシュ付けちゃダメだというのはご指摘通りでした。
それらを避ければうまくいく場合もあるんですが、うまくいかない場合もあり
動作ロジックがわかっていないため切り分けられずにいます。
volumes:
- /usr/local/opt/docker:/var/lib/mysql
- /etc/localtime:/etc/localtime:ro
上段はマウントできず、下段はマウントできます。
いずれもホスト側はroot:rootの所有で、全ユーザー読み書き可です。
Cannot start service db_001: error while creating mount source path '/usr/local/opt/docker': mkdir /usr/local/opt: read-only file system
なぜ、/usr/local/opt/dockerディレクトリが存在するのに
わざわざ/usr/local/optをmkdirしようとして失敗してるんでしょうか？
そのあたりの仕組みが理解できれば、解決できそうな気もするんですが…
434(1): 426=433 2018/10/02(火)11:05 ID:MTSGNvvZ(1) AAS
snapのsandboxが原因でした。
snapアプリケーションはスマホアプリみたいなもんで、
ホスト側ディレクトリの参照権限も大幅に制限されるということのようです。
/var/snap/docker配下なら如何様にもマウント可能でした。
お騒がせしました。
(433で名前間違えました。失礼しました）
435: 2018/10/02(火)12:26 ID:ngnCMsef(1) AAS
>>434
おお、解決してよかった
ホストOSの挙動が独特だとトラブルシューティングも難しいね
436: 2018/10/02(火)14:05 ID:jMGWfJIN(1) AAS
あー、そうだったのか。挙動的に誰かが制限かけてる感じだったから
selinuxかな？とは思ったんだが、言っていたらヒントになってたかもな
437(5): 2018/10/05(金)17:28 ID:uwcVKd6M(1) AAS
先に要点を書くと、コンテナにスタティックルートを書く正攻法を知りたいです。
・外部からOpenVPNコンテナ(コンテナA)でVPN接続を受ける
・外部のOpenVPNクライアントと、Dockerの別コンテナ(コンテナB)間で通信する
これがネットワーク構成的に実現できずにいます。
docker network createでbridgeネットワークを作り、
コンテナA,Bには docker run --ip=で固定IPを振っています。
ネットワーク構成で言えば、コンテナAをゲートウェイとすれば良いので
「OpenVPNネットワークへのゲートウェイをコンテナAとする」ルーティングを
コンテナBに書ければ解決する話なんですが、それがどうやっても書けません。
Dockerhubから拾ってきたコンテナBにはrouteコマンドすらないため、
DockerfileでrouteコマンドをRUNすることもできない。
docker network create で--gateway のIPをコンテナAにすればいいのかと思いきや、
試したんですが、どうも--gatewayのIPは即Dockerホストに振られてしまうようで、
コンテナAにそのIPを振ろうとすると「IPが被ってる」エラーになる。
もちろんホスト側にルーティングを書けば解決するんですが、
できればホストはいじらずdocker側だけで解決したいなぁと。
何かご存じの方、教えてください。
438(1): 2018/10/08(月)17:27 ID:+G8YrS7/(1) AAS
docker使わずに仮装マシン使え案件な気がするが
439(1): 2018/10/08(月)18:31 ID:dcwIe0qQ(1) AAS
うん。そう。毎回言ってるんだけどね。
Dockerを仮想マシンの代わりとして使うなと
Dockerコンテナは仮想アプリであって仮想マシンじゃない
440(1): 437 2018/10/09(火)09:49 ID:a4is0HOD(1/4) AAS
>>438-439
確かにdocker触り始めたばっかりなので
使い方とか概念理解がちょっと間違ってるのかもしれないですが、
逆に言うとこういう使い方が適切じゃない理由って何でしょう…？
OpenVPNをコンテナ化できれば（そして各コンテナにルーティングが書ければ）
Dockerfileだけ書いとけばVM同様可搬性も高くていいな、程度なんですが。
441(1): 2018/10/09(火)11:37 ID:UEbDWUsW(1) AAS
>>440
Dockerが仮想マシンの代わりとして設計してないから
だから「これがあれば仮想マシンとして使えるのに」と
思うような機能は意図的に搭載しないので
仮想マシンとしては使いにくいんですよ
なんでもかんでも機能搭載して複雑にしていくのは
アホな日本人ぐらいなもん
442(1): 437 2018/10/09(火)11:45 ID:a4is0HOD(2/4) AAS
ルーティングを書く機能がともかく存在しないってことですね。
コンテナに好きなIPも振れるしゲートウェイも設定できるけど、
スタティックルートだけはあえて書かせないようにしている、と。
>>441
今回の例で言うと、OpenVPNはコンテナじゃなくてVMでやるべきって話ですよね？
設計云々はともかく実際なんで良くないんですか？
443(1): 2018/10/09(火)12:56 ID:J/UkStG7(1) AAS
>>437
コンテナにrouteコマンド入れればいいじゃん
なぜよくわかってない拾いもので特殊なことをしようとするのか
444(1): 2018/10/09(火)14:28 ID:lxGRoqO6(1) AAS
>>442
OpenVPNはDockerコンテナでいいけど、ネットワーク周りは仮想化か実機とかDocker外でやったほうがいいって気がする
445: 437 2018/10/09(火)14:41 ID:a4is0HOD(3/4) AAS
>>443
>>437で書いたコンテナBは、具体的にはZabbix公式のコンテナイメージで、
外部パッケージとかを入れらんないんです。
もちろん公式イメージに強引にrouteコマンドをブチ込むというのも
やってやれないこともないかもしれないですが、
それならコンテナ起動後netnsでrouteを送り込むとか、
諦めてホスト側でルーティングするとかの方がいいような。
446: 437 2018/10/09(火)15:41 ID:a4is0HOD(4/4) AAS
>>444
現実的にもそれしかなさそうですね。
ホストにルートを書いて回避しました。
447: 2018/10/16(火)14:04 ID:JjMfngP+(1) AAS
Dockerのインストールは何でこんなにややこしいのかと
説明文を読み進めたらランチャーとは違うものだった
Dockと勘違いした
448(3): 2018/10/26(金)03:04 ID:UuZWwwD+(1/6) AAS
Dockerがやはりまだ理解しきれておらず、、、
理解が全然違うか教えて欲しいのだけど、
nginx + uwsgi + flaskでサイトを開発したい場合は、ローカルでコードを書いて、
DockerfileにBusyBox + nginx + uwsgi + flaskを入れるように？設定して
docker buildを行うと、書いていたpythonコードと必要なコンポーネントが
まとまったdocker imageがサーバー上に出来上がり
docker runする事によりdocker imageから生成されてインスタンスが立ち上がる
であってる？
docker imageがclassでrunするとオブジェクトが出来上がると理解しているのだけれど、、、
449: 2018/10/26(金)06:35 ID:xzHCVt/i(1) AAS
>>448
なぜあえてクラスとオブジェクトに絡めて理解しようとするのか。
450(1): 2018/10/26(金)07:03 ID:Y5itkZBt(1) AAS
>>448
仕事で必要とかじゃなければ無理して理解する必要ないと思うよ
一般庶民が微分積分を理解できないように、一般プログラマにはDockerは難解過ぎる
451(1): 2018/10/26(金)07:40 ID:S+WdRTJT(1/9) AAS
>>448
なにを一塊のウェブアプリにしたいかだよ。
まず前提としてflaskだけでも、組み込みサーバーを使うことでウェブアプリとして使える
だけど、これは開発用なので公開用としては使わない。なのでflaskだけでは
ウェブアプリにはできないという扱いにする
では、flask + uwsgi ではどうか？ ウェブアプリとして使えるよね
（pythonあんまり詳しくないから間違ってるかもしれないが）
外部ﾘﾝｸ:qiita.com
だから flask + uwsgi で1つのDockerコンテナにするのもあり
この場合、nginxとはhttpでつなぐことになるかな。
socket経由でできるかはわからない。
nginxはnginxで1つのコンテナにして、2コンテナでシステムを構成する
（docker-composeを使えば、複数のdockerコンテナを同時に起動できる）
また flask + uwsgi + nginx まで入れてしまうのも良い
前者との違いとしては、例えば静的ファイルはnginxで配信したい場合に
前者なら別のサーバーで配信することで負荷を下げるという構成が取れる
その反面2コンテナなので少し面倒になる。使うのがお手軽なのは後者
ま、理解できてないのはこの話じゃなさそうだけどねｗｗｗ
452: 2018/10/26(金)07:41 ID:S+WdRTJT(2/9) AAS
>>450
× 一般プログラマにはDockerは難解過ぎる
○ お前にはDockerは難解過ぎる
453: 2018/10/26(金)08:01 ID:BI6ZyjXf(1) AAS
「一般プログラマ」ってのがどのレベルなのかと。
SESの人足なのか、自社開発でCIが文化になってる開発者なのか？
どっちも「一般プログラマ」といえば一般プログラマ（苦笑）
454(2): 2018/10/26(金)09:37 ID:UuZWwwD+(2/6) AAS
>>451
伝わらなくてごめんごめん
たしかにコンテナ分けると負荷が下がるとかは知りたいこととはまったく関係ない
今後職場でDockerを使うかもという話が出てて、
インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
なにか変わるのか事前に理解したくて。
調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが
パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に
コミットしてないとコード消えるのか？？？ってなってしまったわけなのよ
一般プログラマーからしてdocker imageは関係ないのなら調べるのやめるんだけど、
インフラから事前告知があったので影響あるのかと不安になった
455: 2018/10/26(金)09:58 ID:S+WdRTJT(3/9) AAS
>>454
C言語とかコンパイル言語使ったことある？
dockerのbuildは、C言語などのビルド（コンパイル）と同じ
言語はソースコードをビルドして実行バイナリを作成する
Dockerはすでにある複数のバイナリをもとに、Dockerイメージを作成する
さて、実行バイナリは、データを保存したらどこに保存されるか？
実行バイナリの中に埋め込まれるわけじゃないよね。実行バイナリの外のファイルに保存する。
実行バイナリ自体は読み取り専用。ビルドしたときに作成したバイナリから変更することはない
Dockerも同じように考える。Dockerイメージっていうのはビルドして作成した状態から変更しない
内部的には変更されていてそのデータはどこかに残っていたりするが、そういうのは内部の話なんで忘れる
Dockerイメージは読み取り専用で、Dockerイメージをrun（実行）するとプロセスが起動する
あ、ここも実行バイナリと同じだね。バイナリを実行するとプロセスが起動する
Dockerイメージをrunして作ったプロセス（＝Dockerコンテナ）はどこにデータを保存するか？
Dockerイメージは読み取り専用なので、当然Dockerコンテナの外のファイルに保存する。
C言語 ・・・ ソースコード -> [Makefileでビルド] -> 実行バイナリ
Docker・・・ソースコード等 -> [DockerfileでDockerビルド] -> Dockerイメージ
Dockerのソースコード等には本当にいろいろ含まれる
アプリのソースコードだったり、nginxだったり。カーネル以外の全て
で、コード消えるのか？っていう疑問の答えは、実行バイナリ消してもソースコードをビルドすれば作れるでしょう？
Dockerも同じでソースコード等をビルドすれば、Dockerイメージができるんだから何も問題ない
456(1): 2018/10/26(金)10:06 ID:S+WdRTJT(4/9) AAS
で、ウェブ開発の際に使う場合に、これじゃ使いづらい場合がある
C言語の場合、ビルドしないと動く実行バイナリはできないから
これで納得するかもしれないけど、ウェブ開発とかしてると
ビルドしなくてもソースコードを修正したらすぐに反映されるわけだ
毎回Dockerビルドしないといけないのは辛い。こういう場合にボリュームを使う手がある
データはDockerイメージの外に置くといったけど、ソースコードもDockerイメージの外に置けばいい
Dockerイメージの中にはPython実行環境などが入っているけど、ソースコードは含めない
ホームディレクトリ以下のいつもの場所をそのまま参照する
当然エディタもDockerイメージの中に入れない。
今までどおりエディタで編集して、実行環境がDockerイメージなっただけ
ただね。Dockerイメージで作る実行環境は、本番用環境と同じにだいたいするので
デバッグなどはし辛い。だから通常のアプリ開発はDockerを使わないほうが楽だろう
だが、いつでも本番用環境を手元で作り出せると、本番用環境でのみ発生するバグなど避けられる
他の人も誰でも本番用環境で検証できるようになるわけだ
457: 2018/10/26(金)10:18 ID:UuZWwwD+(3/6) AAS
>>456
すごいわかりやすい説明
コンパイラに例えてもらえると分かりやすいわ
ありがとう
458: 2018/10/26(金)10:20 ID:S+WdRTJT(5/9) AAS
>>454
> インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
> なにか変わるのか事前に理解したくて。
インフラが全部やりますっていうのなら、開発側に影響はない。今までどおりだ。
そう今までどおり、開発側で新しいライブラリとか追加や更新しようと思たら
インフラにこれ変えたいんですけどとお伺いを立てたり
本番用環境とバージョンが違うとかでバグがでたり
そういう今ある問題がそのまま残るという意味で開発側に「影響がない」ということだ
Dockerfileはソースコードのリポジトリに追加するのが良い
（もちろん分離することもできるが、いろんな問題は解決するのが難しくなる）
そして開発側で新しいライブラリとか追加するなら、ソースコードのビルドスクリプトと同じように
Dockerfile等をインフラチームではなく開発チームがメンテナンスする。
そして最終的にソースコードのリポジトリから簡単な操作でDockerイメージが作れるようになれば
インフラチームはそのDockerイメージを動かすことだけに集中すれば良くなる
開発チームとインフラチームのやり取りが、Dockerイメージを実行する手順だけを伝えれば良くなる。
（例えば必要な環境変数など）
理想は
開発チーム・・・Dockerfileのメンテナンス（Dockerイメージを作成できるようにする）
インフラチーム・・・Dockerイメージの実行
なのだが、現実としてDockerはインフラチーム主導で導入されることが多いので
インフラチームのサポートでDockerfileを作っていくことになるだろう
459: 2018/10/26(金)10:26 ID:UuZWwwD+(4/6) AAS
今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね
460: 2018/10/26(金)10:29 ID:S+WdRTJT(6/9) AAS
Dockerを仮想マシンの代わりとしてとか考えてると
> 調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが
> パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に
> コミットしてないとコード消えるのか？？？ってなってしまったわけなのよ
↑これとかで、混乱する。
Dockerは仮想マシンじゃないんだよ。
Dockerfileから作成したDockerイメージはビルドした状態から変更しないもの。（もちろん再ビルドはOK）
Dockerコンテナに乗り込んで、中身を書き換えて再イメージ化なんてこともしない。
できるけど、通常の使い方ではやらない
バイナリに例えれば、C言語のプロセスに乗り込んで（デバッガで？）
プロセスのメモリを書き換えて、プロセス部分をディスクに書き出すようなもんだよ
そんなことしないだろ？
461(1): 2018/10/26(金)10:34 ID:S+WdRTJT(7/9) AAS
> 今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね
virtualenvといわれると、少し違和感があるな
VMよりずっとましだけど
virtualenvは実行環境を作るもの
Dockerは実行環境を含めた実行イメージ＝Dockerイメージ＝実行バイナリの凄い版を
作るものだから
462(1): 2018/10/26(金)10:39 ID:UuZWwwD+(5/6) AAS
>>461
やっとそこの理解ができた
インフラがDocker推すのわかるわ
virtualenvのpython周りをなんとなくコンテナ化したのとはちがって、OS含めた実行環境コンテナを作れるとなると、ほんといろいろ解決できるな！
463: 2018/10/26(金)10:44 ID:S+WdRTJT(8/9) AAS
例えばgoで作られたバイナリは、いろんなものがスタティックリンクされるので
単一のバイナリをコピーするだけで、あちこちでそのまま動かすことができる。
それと同じようにDockerもDockerイメージの中に、いろんなものが詰め込まれてるので
あちこちで動かすことができる
ちなみにDockerfileでビルドしたDockerイメージはDockerリポジトリにpushしておける
（パブリックな公式のDocker hubや、各社プライベートリポジトリ等がある）
そうしたイメージは手元でDockerfileからビルドしなくてもpullするだけで使える
バイナリをコピーするだけで動かすことができるように
DockerイメージをDockerリポジトリからpullしてくるだけで動かすことができる
こういうのは開発者にとっても便利だよね。
ウェブアプリだけじゃなくCLIコマンドもDockerイメージ化することができるから
goみたいにスタティックリンクされたバイナリが作れない言語で作ったアプリでも
Dockerだけが入ってるクリーンな環境で、いきなり実行することもできちゃうわけだ
464(1): 2018/10/26(金)10:56 ID:S+WdRTJT(9/9) AAS
>>462
Dockerイメージを新しく（バージョンアップ）したから、
次からこれ使ってーって開発チームはインフラチームに依頼するだけでよくなる
インフラが気にするのはDockerイメージを実行することだけ
だからDockerイメージが起動さえすれば、物理（or 仮想マシン）の
OSを変えることだってできちゃう。
そのDockerイメージが動きさえすれば良いんでしょ？程度の気楽なもん
開発チームは開発チームで、物理（or 仮想マシン）のOSの機能に
（カーネル以外）依存しているわけじゃないので、
Dockerイメージのベースとなるディストリを変更したりなんでもできちゃう
物理（or 仮想マシン）のOSが変更になったって？別にOSのパッケージに
依存してるわけじゃないのでどうでもいいよ。程度の気楽なもん
いままでDebianベースでやってきたけど、ライブラリのバージョンが古いや
Ubuntuに乗り換えよう。なんてことも気楽にできちゃう
客先が使ってるマシンがCentOSだって？ Dockerがあれば関係ない。
UbuntuベースのDockerイメージが、そのまま動く
本気でやれば、いろいろ解決するよ。ただそのためには
インフラチームに丸投げじゃだめだけどね
465: 2018/10/26(金)11:34 ID:UuZWwwD+(6/6) AAS
>>464
ほんとベース理解できたら凄いわこれ
細かいホスト側？の設定はインフラに任せるとして
開発に影響のあるdockerfileの作り方も凝らなければストレートだね
これで環境周りのめんどくささからは解放される！
466: 2018/10/26(金)13:18 ID:4wc3titV(1) AAS
chrootで仮想化するのを全自動で管理できるようにしたのがdocker、chroot以下構築のbashファイルに相当するのがDockerfile。
ツッコミどころ満載の説明だけど、概念はこれでおk.使い方はコマンド覚えろ。
467: 2018/10/27(土)19:48 ID:5pOpML2z(1) AAS
は？
468: 2018/11/01(木)11:02 ID:Ub4h8gMB(1) AAS
クソレスのせいで会話とまったな
466は反省しろよ
上下前次1-新書関写板覧索設栞歴
あと 534 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.036s