Docker Part2©2ch.net

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

http://www.docker.io/

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

> なんでflatpak作ったの？Dockerでいいじゃない？と。
この質問に自己レスする前に

第513回　新しいパッケージの仕組み，Flatpakを使用する
http://gihyo.jp/admin/serial/01/ubuntu-recipe/0513
> FlatpakとSnapsの最大の違いは，Flatpakはアプリケーション専用で
> あることでしょう。よって，GUIアプリケーションであれば
> Flatpakのほうが快適に使用できるものが多いのですが，実際はケースバイケースです。
本当にGUIアプリ専用だったのか？


Flatpak・Snaps も Docker も「使う側」の視点と「作る側」の視点がある

Flatpak・Snapsはどちらかといえば「使う側」が焦点となっており
こんなパッケージを用意しましたから使ってくださいって感じだろう。
エンドユーザーがデスクトップPCで使うアプリ用

Dockerはどちらかといえば「作る側」がメインなのでアプリのインストールや実行はCLI、
そしてGUIアプリは作れなくはないがメインのターゲットではない。
主に開発用のツールや自社開発のウェブサービスを構築のためによく使われている

Dockerは「作る側」がメインなので何度も言ってるように、アプリエンジニアにこそ必要なもの。
だからパッケージ入れて（ちょっと設定して）使うだけのインフラエンジニアはVMの役割とごっちゃにしやすい

自分専用にカスタマイズしたアプリを作りたい人はDockerを選ぶのでは？
Flatpakでパッケージの作り方を調べてみたが、
Dockerfile書くだけで作れるDockerよりも大変そうに思える

なんでflatpak作ったの？の答えは、エンドユーザーのために作ったパッケージを、
もっと使いやすく提供したいためだろう。

別にコンテナの用途限定する必要は無いと思うけどなぁ。便利に使えたらそれでいいし。Dockerを○○に使うなって言うならその代替案も言って欲しいけど言わないし、仮に言えたとしてもそれはDockerで実現した方が簡単というオチになるのが目に見えてるし。
正しさとは都合。正しさを振りかざすのは自己満足を他人に押しつける行為。

ドッカーのスレだから、ドッカー万歳な人がいてもおかしくないよ

>>368
> 別にコンテナの用途限定する必要は無いと思うけどなぁ。

制限なんかしてないよ？

コンテナの用途は、アプリケーションコンテナや
システムコンテナといった使い方がある。

だがここはDockerのスレなんだからDockerの話をするべきで、
Dockerはアプリケーションコンテナとして設計されてるのは事実

だからコンテナを違う用途で使いたいなら、
別のスレに行くのが適切ってだけの話

> Dockerを○○に使うなって言うならその代替案も言って欲しいけど言わないし

何に使いたいのか言わないから言いようがない

どうせシステムコンテナなんだろうが、
システムコンテナとして使いたいなら
LXD や OpenVZ を使えばいいだろ？

ほらよ。スレ立ててやったから
コンテナを仮想マシン代わりとして使いたいならそっちに移動しろ

LXD コンテナを仮想マシンとして使う (Not Docker)
https://mao.5ch.net/test/read.cgi/linux/1534223977/

>>362は>>360宛て

LXDやOpenVZなんて知らんし、もしスレたてるとすれば仮想マシンとしてDockerを使うスレにするべきでしょ？
なんでそんなにDockerを仮想マシンとして使わないように誘導するの？おかしくない？

Googleクラウドは仮想化なんか使ってなくて、物理サーバにコンテナ立ち上げてるらしいけど、あなたはGoogleがコンテナ使い方間違ってるからGoogleのインスタンス使うなって言うわけ？

Dockerの使い方を縛らないと言いつつサーバ用途には使わせないように誘導するのすごく卑怯だよね。
声がでかくて社内政治だけがうまい奴に似てて、あなたに物凄い嫌悪感を持ったよ。

https://stackoverflow.com/questions/17989306/what-does-docker-add-to-lxc-tools-the-userspace-lxc-tools

> 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を使うメリットってこれかな？
コンテナ知らん俺でも強力だとわかる

お前ら暑いからってイライラするなよな…

git likeを謳ってるからDocker hubなんかもあるのな
flatpakのflathubよりは随分開発寄りな印象を受ける…サインインしてないけど

ご興味のある方はどーぞ
https://hub.docker.com/
https://flathub.org/

>>366
> LXDやOpenVZなんて知らんし、

無知を告白されても、勉強したら？で終わる話なんだが
知らないほうが悪いんですよ

>>366
> なんでそんなにDockerを仮想マシンとして使わないように誘導するの？おかしくない？

なんで仮想マシンの代わりとしてコンテナ技術を使うものがあるのに
仮想マシンの代わりとして使うことを想定してないDockerを無理やり使うわけ？
その方がおかしいでしょ。
どうせ間違った使い方をして、使いづらいと文句をいうのが目的なんだろう？

>>367
> Googleクラウドは仮想化なんか使ってなくて、物理サーバにコンテナ立ち上げてるらしいけど、あなたはGoogleがコンテナ使い方間違ってるからGoogleのインスタンス使うなって言うわけ？

お前用語の使い方めちゃくちゃ。

> Googleクラウドは仮想化なんか使ってなくて
Googleクラウドが何を指しているのか知らないが、
GCPのことであれば、仮想マシンを使ってる。

仮想化というが、ハードウェアを仮想化（＝ハードウェアエミュレータ）したのか
アプリケーションの実行環境を仮想化（＝ハードウェアのエミュレートはしてない）
したのかはっきりしない

> 物理サーバにコンテナ立ち上げてるらしいけど
物理サーバにコンテナを立ち上げるのは間違った使い方ではない
物理サーバーに直接アプリケーションコンテナを立ち上げてもいいし、
物理サーバーにシステムコンテナを立ち上げても良い

間違った使い方と言ってるのは、Dockerをシステムコンテナとして使うこと
Googleがアプリケーションコンテナをシステムコンテナとして使っているなんて
どこを見ても書いてない。

参考 すでにGoogleは全部のソフトウェアをコンテナに乗せており、毎週20億個ものコンテナを起動している
https://www.publickey1.jp/blog/14/google20.html


> Googleのインスタンス使うなって言うわけ？
やっぱりその言い方をしてる所からすると
GoogleのクラウドとはGCPの事を言っているようだが、
GCPは仮想マシンを使っている

>>368
> Dockerの使い方を縛らないと言いつつサーバ用途には使わせないように誘導するのすごく卑怯だよね。

あのさぁ、Dockerとコンテナは別物なんですよー？知ってますかー？小学生ですかー？

コンテナの使い方は色々あるが、
Dockerはアプリケーションコンテナを作るためのものなんだから
システムコンテナとして使うなよ。

コンテナの使い方は縛ってないが、Dockerの使い方は縛ってる
縛ってると言うか、Dockerはアプリケーションコンテナを作るために
作られたんだよ。

何度も言うが、コンテナの使い方は縛ってない。

>>370
> git likeを謳ってるからDocker hubなんかもあるのな
> flatpakのflathubよりは随分開発寄りな印象を受ける…サインインしてないけど

だからDockerはアプリケーション開発者のためのものなんだよ

Docker hubに置いてるものは、公式のものはそれを利用して
独自のコンテナを作るため、アプリを開発するためな

それ以外の多くは自分や自社専用に開発したアプリ
（公開可能なもの）を置いているのが大半

そしてそのまま使えるアプリが置いてあったりするのは極稀


参考までに言っておくと非公開のDockerイメージを起きたい時は
プライベートリポジトリを使う。
GCPやAWSはDockerのプライベートリポジトリを提供している

>>375
ご説明どうも
LXC/LXDと違って配布とバージョニングが肝要なのね

>>377
シラネーヨバーカ。
お前が自分の正しさ振りかざして好き勝手なこと言ってるのがムカつくって言ってるんだよ。
絶対にお前と一緒の現場で働きたくないし、お前が上司だったら人事に文句言いまくって転職するわ。

この怒涛の連レスと変な引用がWebやプログラム板の荒らしそっくりだ

> 377 名前：login:Penguin[sage] 投稿日：2018/08/14(火) 20:07:26.17 ID:Rn+J0ap2
> >>377
> シラネーヨバーカ。

俺も同意見である

Dockerを使うと次のようなことできる？

複数の各Dockerが独立してLANインターフェイスに専用のプライベートIPアドレスを持って、
ホストのルーティング設定とLANインターフェイスを利用してネット側と通信する。

＜Docker＞
□ □ □
| | |
==========⇒ホストのルーティングを使ってネットへ

>>380
自己レス

Dockerコンテナの間違いでした。

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

>>382
レスありがとうございます。
参考にしたいと思います。

分からないので、ちょっと書籍を読んでいきます。

dockerとちょっとしたサーバーあれば大規模ネットワーク作れそうだね

大規模ネットワークを作るならkubernetesとか使うべきだよ

>>384
大規模ネットワークは単にその手段ではないのか

>>386
レガシーの為にサマータイムを導入し、打ち水を都公認の暑さ対策として導入すべく水まいて地表の温度低下を計測するも湿度や不快指数は見ないこの国で手段とか目的とか言い出すのはナンセンスですよ

国なんかに考え方決められちゃう人って・・・

dockerで大規模ネットワークっていったら
もう考え方から変わってサーバーという概念がなくなる。

複数のサーバーで構成された一つの巨大なOS（クラスタ）があって
そこでdockerコンテナというアプリがあちことのどこかで
起動したり消えたりするイメージになる

それを実現するのがKubernetes


ただ、理屈はそうなんだが現実として
そこまでのスペックは求められていないｗｗｗ

やっぱこのくらいの規模じゃないとあんま意味ないよな
https://kubernetes.io/blog/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack/

念の為に行っておくと、意味がないのはKubernetesね
Dockerはクラスタにすばやくアプリをデプロイするのに使われるが
Dockerそのものはアプリケーションの仮想化による
可搬性の高さがうりなので違うOSで動かしたりとか
同OSの他のシステムの影響を最小限にできるとかいうメリットが有る

>>391
可搬性の高さのことをすっかり忘れていた。
ネットワーク単位を分けられることのメリットが自分にはおおきくて。

コンテナの台頭で仮想マシンの未来に暗雲--Diamanti調査
https://japan.zdnet.com/article/35123584/

>　最も広く採用されているコンテナ技術が「Docker」（52％）と「Kubernetes」（30％）と
>なっているのは驚くに値しない。回答者の71％は仮想マシン上でコンテナを配備しているため、
>仮想マシンが姿を消すということはないだろう。仮想マシンの存在価値はあるはずだ。
>しかし、ITリーダーらは仮想マシンのライセンスコストを抑えたいと考えている。

>　興味深いことに、コンテナに向かうこの動きは企業幹部らによって推進されているわけではない。
>同調査によると、コンテナの採用を主に推進しているのは、プラットフォームの設計者（22％）と、
>開発者（22％）だという。これらの後にはIT運用チーム（17％）と、統合DevOpsチーム（17％）が
>続いており、企業幹部はたったの9％となっている。

>　コンテナは主に、クラウドネイティブなアプリケーションで使用されている（54％）。
>その後に、ステートレスな軽量アプリケーション（39％）、クラウドへの移行（32％）、
>レガシーアプリケーションの近代化（31％）が続いている。

>　また、本番環境でコンテナを稼働させている回答者が考えている「最大の課題」として、
>インフラがトップに挙げられており（30％）、その後にはセキュリティ（22％）、
>配備（22％）、パフォーマンス（19％）、永続的ストレージ（12％）が続いている。

>>393
>企業は仮想マシンのライセンス料金に大きな不満を抱いているという知見を得ている。
>VMwareは自社の利益を追求するうえで、同社の社名に冠された仮想マシン（VM）に依存しなくなっている。
>VMwareがこれまで軸足を置いていた市場が、競合他社のハイパーバイザの台頭によって侵食されたのは事実だが、コンテナの登場によってさらに大きな影響がもたらされている。
>回答者の71％は仮想マシン上でコンテナを配備しているため、仮想マシンが姿を消すということはないだろう。仮想マシンの存在価値はあるはずだ。しかし、ITリーダーらは仮想マシンのライセンスコストを抑えたいと考えている。

この記事のベクトルがはっきりしない。
なにがいいたいのか？

頭の悪さが滲み出てくる記事だよな。

自分の頭が悪いだけだろｗ

18.06.1 が来てた

試しに、公式のubuntuでコンテナを動かしてみたんだけど、

docker run -it ubuntu bash

プロンプトに、ping , ip a , ifconfig というような基本的なコマンドすら実行できない。
ネットワークの状況も確認できない。
これは、どう使うことが想定されているんでしょうか。

centosのイメージでも、pingコマンドはあったけど、ip a がないので、
ネットワークの調査ができない。

DockerコンテナからIPIPトンネルを構築したいと考えていたんですが、
とりあえずラズパイ並みにつかえるようにするにはどうすればいいでしょうか。

>>398
だからさ、Dockerは仮想マシンじゃないって
その中に入って色々作業するものじゃないんだよ

Dockerはアプリケーションコンテナなんだから、
そんなコマンドは必要な場合に入れれば良いんだよ
（必要になることは殆ど無い）

いつになるかわからんが次スレまで行ったら
テンプレにしっかり書いてなきゃいかんな

>>398
そいつのDockerfileな
https://github.com/tianon/docker-brew-ubuntu-core/blob/59aa7dfef17153ecc812adbf26516675ce67e8aa/bionic/Dockerfile

他のコンテナ作るときのベースだから本当にミニマムやで

>>399
>>401
レスありがとうございます。
Dockerfileを見てみると、

ADD ubuntu-bionic-core-cloudimg-amd64-root.tar.gz /

だけがコンテンツみたいに思えます。
一応、ubuntuって書いてありますね。

イメージに、centosとか、ubuntuとか、ありますが、
centos7などとはまったくの別物なんですね。


せめてラズパイみたいに使えるイメージがあればいいんですけど。
実験でホストを汚したくないので。

apt-getとか、yumがつかえるようなやつ。
Docker Hubでなにかオススメあるでしょうか。

環境ができたら、今度はそれを自分用としてイメージ化したい。

>>402
> せめてラズパイみたいに使えるイメージがあればいいんですけど。
だからそういう使い方をするものじゃないから
希望するのが見つからいように思えるんだって

>>402
Hyper-VでもKVMでもVirtualBoxでも好きなのを選べばいいぞ

みた感じ、仮想マシン派もDocker派も両方ディスる猛者現るって感じだな

> せめてラズパイみたいに使えるイメージがあればいいんですけど。
お前が欲しいと思うようなものはない。イメージは原則として自分で作るものだから。
使うイメージはDockerが用意したdebianやubuntuなどの
最低限のイメージのみ。それを元にして自分で作る

> 実験でホストを汚したくないので。
Dockerはそういうものの代わりとして設計されてないので
すぐにお前の実験はできなくなると言っておく。
それはDockerに問題があるのではなく、お前の使い方が間違っている

ラズパイと同じ環境がほしいなら、
仮想マシンでRaspberry Pi Desktop X86でも使えばいいだろ

Dockerはアプリケーションに実行環境を一体化させるものだって
なんど言っても理解しないやつが湧いてくる

すみませんでした。
自分でもっと勉強します。

Dockerて、OSやアプリの仮想イメージファイルをコマンドで組み合わせ
メモリ上でつなぎ合わせて一つの仮想ディストリビューションをブートしたように
見せかけるソフトって理解でよい？

全然違うかなー

使ったこともないのに適当な事書くと常駐のスレ主に怒られちゃうからな
ちょっと調べた感じ、initなしでも動くそうだがゾンビプロセス問題とかめんどくさそうでマニアの領域
initから開始したらそれはそれで、それLXC(LXD)やん！って印象

>>409
WindowsのDLLヘル対策の超強化版って考えればいい。
知らん人は知らんかもしれんがｗ

Windowsでアプリを起動する時、外部DLLを使用していることが多々ある
そうすると、外部DLLのバージョンが変わって互換性がなくなった時、
アプリが動かなくなる可能性がある。

だからアプリのディレクトリに外部DLLを入れてシステムのDLLを
使用しないようにしましょうっていうのがWindowsのDLL対策

Dockerもコレと同じでアプリを起動する時、OSのライブラリなんかを使用してる
そういうのを先にインストールしたりしていなければいけないが

アプリのDockerイメージの中に一切合切入れてしまいましょうっていうのがDockerの考え方

視野狭窄の輩がバージョンドシンボルの話と混同しそうな予感

Kubernatesの日本での呼び方って決まってるの？
会うひとみんな違う言い方するし
YouTubeで外国語聴いてもみんな結構違う

>>414
こっちで
https://mao.5ch.net/test/read.cgi/linux/1345027528/

>>415
誘導ありがとうございます。
向こうに書きました

jewCS8ED が、あっちで、くうねるさんだーす と書き込みました。

dock-composeで
全く同じ内容のDockerfileで
追加するファイルの中身だけ異なるイメージを2つビルドしたら
後でビルドした方はキャッシュの影響で先にビルドしたイメージと全く同じ内容になってしまう

イメージに名前付いてないけど
名前付けたら良いのか？

>>418
名前変えずにbuildしたらキャッシュじゃなくてすでにimageに入ってるんで
作成されたイメージ一回rmiしないとダメなような

--buildじゃだめ？

>>389
それ、地震対策になるよね。
物理サーバーをまったく意識しない、
まるで半永久的なベースシステムがあれば、
コンテナをぜひ動かしたい。

それだけではならないですよ

そのうちクラウドサービスがコンテナクラスタを用意して
コンテナ毎の課金とかになるんだろうな

そのうちもクソもコンテナのクラウドホスティングサービスは既にあるじゃん

大手クラウドはGKE, AKS, EKSと揃い踏みなんだよなぁ

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

この通りマウント元は存在するんですが、
どこ確認したら良いでしょうか…？

ファイルをマウントしようとしているように見えるんだが、そこはディレクトリでないといかんのではないかと

あと何故2017年06月版を使おうとしているのだろう

>>427
あ、変に端折ってしまいましたが、
/usr/local/etc/docker/my.cnf.d/(ディレクトリ)も
全く同じエラーでマウントできていない状態です。

docker-ceが1703なのはsnappy版だからで、
ubuntu1804のOSインストーラーでdocker関連を選んだらそうなったから、です。
別にsnappyが使いたいわけでもない（というかsnappyとか今回初めて知った）ので、
明らかな設定ミスとかが見つからなければ、docke-ceを上げてみるのも手ってことですね。

- /usr/local/etc/docker/my.cnf.d/:/etc/my.cnf.d:ro

ホスト側ディレクトリ指定の末尾にスラッシュ付いてるけど、Dockerの公式ドキュメント（http://docs.docker.jp/compose/compose-file.html#volumes-volume-driver）だとそういう書き方してる例ないぞ

とりあえずシンプルに
- /usr/local/etc/docker
とだけ書いてマウントできるかどうか確認してから少しずつ設定詰めてみ

あとバージョン気にしたのは単に「セキュリティだの個人情報保護だのが騒がれるこのご時世に1年以上前のバージョンを使わざるを得ない事情でもあるのかなぁ」って思っただけよん

最新を追いかけてバグにハマる例は後を絶たない

docker stop container
してから、commit するのはなぜ？

「docker commit」で検索！

ファイルを指定しちゃダメだというのと
ホスト側ディレクトリの最期にスラッシュ付けちゃダメだというのはご指摘通りでした。
それらを避ければうまくいく場合もあるんですが、うまくいかない場合もあり
動作ロジックがわかっていないため切り分けられずにいます。

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しようとして失敗してるんでしょうか？
そのあたりの仕組みが理解できれば、解決できそうな気もするんですが…

snapのsandboxが原因でした。
snapアプリケーションはスマホアプリみたいなもんで、
ホスト側ディレクトリの参照権限も大幅に制限されるということのようです。
/var/snap/docker配下なら如何様にもマウント可能でした。
お騒がせしました。
(433で名前間違えました。失礼しました）

>>434
おお、解決してよかった
ホストOSの挙動が独特だとトラブルシューティングも難しいね

あー、そうだったのか。挙動的に誰かが制限かけてる感じだったから
selinuxかな？とは思ったんだが、言っていたらヒントになってたかもな

先に要点を書くと、コンテナにスタティックルートを書く正攻法を知りたいです。

・外部から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側だけで解決したいなぁと。

何かご存じの方、教えてください。

docker使わずに仮装マシン使え案件な気がするが

うん。そう。毎回言ってるんだけどね。
Dockerを仮想マシンの代わりとして使うなと
Dockerコンテナは仮想アプリであって仮想マシンじゃない

>>438-439
確かにdocker触り始めたばっかりなので
使い方とか概念理解がちょっと間違ってるのかもしれないですが、
逆に言うとこういう使い方が適切じゃない理由って何でしょう…？

OpenVPNをコンテナ化できれば（そして各コンテナにルーティングが書ければ）
Dockerfileだけ書いとけばVM同様可搬性も高くていいな、程度なんですが。

>>440
Dockerが仮想マシンの代わりとして設計してないから
だから「これがあれば仮想マシンとして使えるのに」と
思うような機能は意図的に搭載しないので
仮想マシンとしては使いにくいんですよ

なんでもかんでも機能搭載して複雑にしていくのは
アホな日本人ぐらいなもん

ルーティングを書く機能がともかく存在しないってことですね。
コンテナに好きなIPも振れるしゲートウェイも設定できるけど、
スタティックルートだけはあえて書かせないようにしている、と。

>>441
今回の例で言うと、OpenVPNはコンテナじゃなくてVMでやるべきって話ですよね？
設計云々はともかく実際なんで良くないんですか？

>>437
コンテナにrouteコマンド入れればいいじゃん
なぜよくわかってない拾いもので特殊なことをしようとするのか

>>442
OpenVPNはDockerコンテナでいいけど、ネットワーク周りは仮想化か実機とかDocker外でやったほうがいいって気がする

>>443

>>437で書いたコンテナBは、具体的にはZabbix公式のコンテナイメージで、
外部パッケージとかを入れらんないんです。

もちろん公式イメージに強引にrouteコマンドをブチ込むというのも
やってやれないこともないかもしれないですが、
それならコンテナ起動後netnsでrouteを送り込むとか、
諦めてホスト側でルーティングするとかの方がいいような。

>>444
現実的にもそれしかなさそうですね。
ホストにルートを書いて回避しました。

Dockerのインストールは何でこんなにややこしいのかと
説明文を読み進めたらランチャーとは違うものだった
Dockと勘違いした

Dockerがやはりまだ理解しきれておらず、、、

理解が全然違うか教えて欲しいのだけど、
nginx + uwsgi + flaskでサイトを開発したい場合は、ローカルでコードを書いて、
DockerfileにBusyBox + nginx + uwsgi + flaskを入れるように？設定して
docker buildを行うと、書いていたpythonコードと必要なコンポーネントが
まとまったdocker imageがサーバー上に出来上がり
docker runする事によりdocker imageから生成されてインスタンスが立ち上がる
であってる？
docker imageがclassでrunするとオブジェクトが出来上がると理解しているのだけれど、、、

>>448
なぜあえてクラスとオブジェクトに絡めて理解しようとするのか。

>>448
仕事で必要とかじゃなければ無理して理解する必要ないと思うよ
一般庶民が微分積分を理解できないように、一般プログラマにはDockerは難解過ぎる

>>448
なにを一塊のウェブアプリにしたいかだよ。

まず前提としてflaskだけでも、組み込みサーバーを使うことでウェブアプリとして使える
だけど、これは開発用なので公開用としては使わない。なのでflaskだけでは
ウェブアプリにはできないという扱いにする

では、flask + uwsgi ではどうか？ ウェブアプリとして使えるよね
（pythonあんまり詳しくないから間違ってるかもしれないが）
https://qiita.com/ekzemplaro/items/7757a6544205384e40ad

だから flask + uwsgi で1つのDockerコンテナにするのもあり
この場合、nginxとはhttpでつなぐことになるかな。
socket経由でできるかはわからない。
nginxはnginxで1つのコンテナにして、2コンテナでシステムを構成する
（docker-composeを使えば、複数のdockerコンテナを同時に起動できる）

また flask + uwsgi + nginx まで入れてしまうのも良い
前者との違いとしては、例えば静的ファイルはnginxで配信したい場合に
前者なら別のサーバーで配信することで負荷を下げるという構成が取れる
その反面2コンテナなので少し面倒になる。使うのがお手軽なのは後者

ま、理解できてないのはこの話じゃなさそうだけどねｗｗｗ

>>450
× 一般プログラマにはDockerは難解過ぎる
○ お前にはDockerは難解過ぎる

「一般プログラマ」ってのがどのレベルなのかと。

SESの人足なのか、自社開発でCIが文化になってる開発者なのか？

どっちも「一般プログラマ」といえば一般プログラマ（苦笑）

>>451
伝わらなくてごめんごめん
たしかにコンテナ分けると負荷が下がるとかは知りたいこととはまったく関係ない

今後職場でDockerを使うかもという話が出てて、
インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
なにか変わるのか事前に理解したくて。
調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが
パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に
コミットしてないとコード消えるのか？？？ってなってしまったわけなのよ

一般プログラマーからしてdocker imageは関係ないのなら調べるのやめるんだけど、
インフラから事前告知があったので影響あるのかと不安になった

>>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イメージができるんだから何も問題ない

で、ウェブ開発の際に使う場合に、これじゃ使いづらい場合がある

C言語の場合、ビルドしないと動く実行バイナリはできないから
これで納得するかもしれないけど、ウェブ開発とかしてると
ビルドしなくてもソースコードを修正したらすぐに反映されるわけだ

毎回Dockerビルドしないといけないのは辛い。こういう場合にボリュームを使う手がある

データはDockerイメージの外に置くといったけど、ソースコードもDockerイメージの外に置けばいい
Dockerイメージの中にはPython実行環境などが入っているけど、ソースコードは含めない
ホームディレクトリ以下のいつもの場所をそのまま参照する
当然エディタもDockerイメージの中に入れない。
今までどおりエディタで編集して、実行環境がDockerイメージなっただけ

ただね。Dockerイメージで作る実行環境は、本番用環境と同じにだいたいするので
デバッグなどはし辛い。だから通常のアプリ開発はDockerを使わないほうが楽だろう
だが、いつでも本番用環境を手元で作り出せると、本番用環境でのみ発生するバグなど避けられる
他の人も誰でも本番用環境で検証できるようになるわけだ

>>456
すごいわかりやすい説明
コンパイラに例えてもらえると分かりやすいわ
ありがとう

>>454
> インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
> なにか変わるのか事前に理解したくて。

インフラが全部やりますっていうのなら、開発側に影響はない。今までどおりだ。

そう今までどおり、開発側で新しいライブラリとか追加や更新しようと思たら
インフラにこれ変えたいんですけどとお伺いを立てたり
本番用環境とバージョンが違うとかでバグがでたり
そういう今ある問題がそのまま残るという意味で開発側に「影響がない」ということだ


Dockerfileはソースコードのリポジトリに追加するのが良い
（もちろん分離することもできるが、いろんな問題は解決するのが難しくなる）

そして開発側で新しいライブラリとか追加するなら、ソースコードのビルドスクリプトと同じように
Dockerfile等をインフラチームではなく開発チームがメンテナンスする。

そして最終的にソースコードのリポジトリから簡単な操作でDockerイメージが作れるようになれば
インフラチームはそのDockerイメージを動かすことだけに集中すれば良くなる
開発チームとインフラチームのやり取りが、Dockerイメージを実行する手順だけを伝えれば良くなる。
（例えば必要な環境変数など）

理想は
　開発チーム・・・Dockerfileのメンテナンス（Dockerイメージを作成できるようにする）
　インフラチーム・・・Dockerイメージの実行
なのだが、現実としてDockerはインフラチーム主導で導入されることが多いので
インフラチームのサポートでDockerfileを作っていくことになるだろう