これからの動向が気になるところ。
情報共有しましょう。
http://www.docker.io/
前スレ
Docker
http://mao.2ch.net/test/read.cgi/linux/1374861492/
探検
Docker Part2©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
これからの動向が気になるところ。
情報共有しましょう。
http://www.docker.io/
前スレ
Docker
http://mao.2ch.net/test/read.cgi/linux/1374861492/
> Googleクラウドは仮想化なんか使ってなくて、物理サーバにコンテナ立ち上げてるらしいけど、あなたはGoogleがコンテナ使い方間違ってるからGoogleのインスタンス使うなって言うわけ？
お前用語の使い方めちゃくちゃ。
> Googleクラウドは仮想化なんか使ってなくて
Googleクラウドが何を指しているのか知らないが、
GCPのことであれば、仮想マシンを使ってる。
仮想化というが、ハードウェアを仮想化（＝ハードウェアエミュレータ）したのか
アプリケーションの実行環境を仮想化（＝ハードウェアのエミュレートはしてない）
したのかはっきりしない
> 物理サーバにコンテナ立ち上げてるらしいけど
物理サーバにコンテナを立ち上げるのは間違った使い方ではない
物理サーバーに直接アプリケーションコンテナを立ち上げてもいいし、
物理サーバーにシステムコンテナを立ち上げても良い
間違った使い方と言ってるのは、Dockerをシステムコンテナとして使うこと
Googleがアプリケーションコンテナをシステムコンテナとして使っているなんて
どこを見ても書いてない。
参考 すでにGoogleは全部のソフトウェアをコンテナに乗せており、毎週20億個ものコンテナを起動している
https://www.publickey1.jp/blog/14/google20.html
> Googleのインスタンス使うなって言うわけ？
やっぱりその言い方をしてる所からすると
GoogleのクラウドとはGCPの事を言っているようだが、
GCPは仮想マシンを使っている
> Dockerの使い方を縛らないと言いつつサーバ用途には使わせないように誘導するのすごく卑怯だよね。
あのさぁ、Dockerとコンテナは別物なんですよー？知ってますかー？小学生ですかー？
コンテナの使い方は色々あるが、
Dockerはアプリケーションコンテナを作るためのものなんだから
システムコンテナとして使うなよ。
コンテナの使い方は縛ってないが、Dockerの使い方は縛ってる
縛ってると言うか、Dockerはアプリケーションコンテナを作るために
作られたんだよ。
何度も言うが、コンテナの使い方は縛ってない。
> git likeを謳ってるからDocker hubなんかもあるのな
> flatpakのflathubよりは随分開発寄りな印象を受ける…サインインしてないけど
だからDockerはアプリケーション開発者のためのものなんだよ
Docker hubに置いてるものは、公式のものはそれを利用して
独自のコンテナを作るため、アプリを開発するためな
それ以外の多くは自分や自社専用に開発したアプリ
（公開可能なもの）を置いているのが大半
そしてそのまま使えるアプリが置いてあったりするのは極稀
参考までに言っておくと非公開のDockerイメージを起きたい時は
プライベートリポジトリを使う。
GCPやAWSはDockerのプライベートリポジトリを提供している
ご説明どうも
LXC/LXDと違って配布とバージョニングが肝要なのね
シラネーヨバーカ。
お前が自分の正しさ振りかざして好き勝手なこと言ってるのがムカつくって言ってるんだよ。
絶対にお前と一緒の現場で働きたくないし、お前が上司だったら人事に文句言いまくって転職するわ。
> >>377
> シラネーヨバーカ。
俺も同意見である
複数の各Dockerが独立してLANインターフェイスに専用のプライベートIPアドレスを持って、
ホストのルーティング設定とLANインターフェイスを利用してネット側と通信する。
＜Docker＞
□ □ □
| | |
==========⇒ホストのルーティングを使ってネットへ
自己レス
Dockerコンテナの間違いでした。
新しいネットワークを作成して使えるよ。これじゃだめ？
各コンテナ間のネットワークの独立性は実現できると思うけど
docker network create net1
docker network create net2
docker run -it --net=net1 debian /bin/bash
docker run -it --net=net2 debian /bin/bash
レスありがとうございます。
参考にしたいと思います。
分からないので、ちょっと書籍を読んでいきます。
大規模ネットワークは単にその手段ではないのか
レガシーの為にサマータイムを導入し、打ち水を都公認の暑さ対策として導入すべく水まいて地表の温度低下を計測するも湿度や不快指数は見ないこの国で手段とか目的とか言い出すのはナンセンスですよ
もう考え方から変わってサーバーという概念がなくなる。
複数のサーバーで構成された一つの巨大なOS（クラスタ）があって
そこでdockerコンテナというアプリがあちことのどこかで
起動したり消えたりするイメージになる
それを実現するのがKubernetes
ただ、理屈はそうなんだが現実として
そこまでのスペックは求められていないｗｗｗ
https://kubernetes.io/blog/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack/
Dockerはクラスタにすばやくアプリをデプロイするのに使われるが
Dockerそのものはアプリケーションの仮想化による
可搬性の高さがうりなので違うOSで動かしたりとか
同OSの他のシステムの影響を最小限にできるとかいうメリットが有る
可搬性の高さのことをすっかり忘れていた。
ネットワーク単位を分けられることのメリットが自分にはおおきくて。
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％）が続いている。
>企業は仮想マシンのライセンス料金に大きな不満を抱いているという知見を得ている。
>VMwareは自社の利益を追求するうえで、同社の社名に冠された仮想マシン（VM）に依存しなくなっている。
>VMwareがこれまで軸足を置いていた市場が、競合他社のハイパーバイザの台頭によって侵食されたのは事実だが、コンテナの登場によってさらに大きな影響がもたらされている。
>回答者の71％は仮想マシン上でコンテナを配備しているため、仮想マシンが姿を消すということはないだろう。仮想マシンの存在価値はあるはずだ。しかし、ITリーダーらは仮想マシンのライセンスコストを抑えたいと考えている。
この記事のベクトルがはっきりしない。
なにがいいたいのか？
docker run -it ubuntu bash
プロンプトに、ping , ip a , ifconfig というような基本的なコマンドすら実行できない。
ネットワークの状況も確認できない。
これは、どう使うことが想定されているんでしょうか。
centosのイメージでも、pingコマンドはあったけど、ip a がないので、
ネットワークの調査ができない。
DockerコンテナからIPIPトンネルを構築したいと考えていたんですが、
とりあえずラズパイ並みにつかえるようにするにはどうすればいいでしょうか。
だからさ、Dockerは仮想マシンじゃないって
その中に入って色々作業するものじゃないんだよ
Dockerはアプリケーションコンテナなんだから、
そんなコマンドは必要な場合に入れれば良いんだよ
（必要になることは殆ど無い）
テンプレにしっかり書いてなきゃいかんな
そいつのDockerfileな
https://github.com/tianon/docker-brew-ubuntu-core/blob/59aa7dfef17153ecc812adbf26516675ce67e8aa/bionic/Dockerfile
他のコンテナ作るときのベースだから本当にミニマムやで
>>401
レスありがとうございます。
Dockerfileを見てみると、
ADD ubuntu-bionic-core-cloudimg-amd64-root.tar.gz /
だけがコンテンツみたいに思えます。
一応、ubuntuって書いてありますね。
イメージに、centosとか、ubuntuとか、ありますが、
centos7などとはまったくの別物なんですね。
せめてラズパイみたいに使えるイメージがあればいいんですけど。
実験でホストを汚したくないので。
apt-getとか、yumがつかえるようなやつ。
Docker Hubでなにかオススメあるでしょうか。
環境ができたら、今度はそれを自分用としてイメージ化したい。
> せめてラズパイみたいに使えるイメージがあればいいんですけど。
だからそういう使い方をするものじゃないから
希望するのが見つからいように思えるんだって
Hyper-VでもKVMでもVirtualBoxでも好きなのを選べばいいぞ
お前が欲しいと思うようなものはない。イメージは原則として自分で作るものだから。
使うイメージはDockerが用意したdebianやubuntuなどの
最低限のイメージのみ。それを元にして自分で作る
> 実験でホストを汚したくないので。
Dockerはそういうものの代わりとして設計されてないので
すぐにお前の実験はできなくなると言っておく。
それはDockerに問題があるのではなく、お前の使い方が間違っている
仮想マシンでRaspberry Pi Desktop X86でも使えばいいだろ
Dockerはアプリケーションに実行環境を一体化させるものだって
なんど言っても理解しないやつが湧いてくる
自分でもっと勉強します。
メモリ上でつなぎ合わせて一つの仮想ディストリビューションをブートしたように
見せかけるソフトって理解でよい？
ちょっと調べた感じ、initなしでも動くそうだがゾンビプロセス問題とかめんどくさそうでマニアの領域
initから開始したらそれはそれで、それLXC(LXD)やん！って印象
WindowsのDLLヘル対策の超強化版って考えればいい。
知らん人は知らんかもしれんがｗ
Windowsでアプリを起動する時、外部DLLを使用していることが多々ある
そうすると、外部DLLのバージョンが変わって互換性がなくなった時、
アプリが動かなくなる可能性がある。
だからアプリのディレクトリに外部DLLを入れてシステムのDLLを
使用しないようにしましょうっていうのがWindowsのDLL対策
Dockerもコレと同じでアプリを起動する時、OSのライブラリなんかを使用してる
そういうのを先にインストールしたりしていなければいけないが
アプリのDockerイメージの中に一切合切入れてしまいましょうっていうのがDockerの考え方
会うひとみんな違う言い方するし
YouTubeで外国語聴いてもみんな結構違う
こっちで
https://mao.5ch.net/test/read.cgi/linux/1345027528/
誘導ありがとうございます。
向こうに書きました
全く同じ内容のDockerfileで
追加するファイルの中身だけ異なるイメージを2つビルドしたら
後でビルドした方はキャッシュの影響で先にビルドしたイメージと全く同じ内容になってしまう
イメージに名前付いてないけど
名前付けたら良いのか？
名前変えずにbuildしたらキャッシュじゃなくてすでにimageに入ってるんで
作成されたイメージ一回rmiしないとダメなような
それ、地震対策になるよね。
物理サーバーをまったく意識しない、
まるで半永久的なベースシステムがあれば、
コンテナをぜひ動かしたい。
コンテナ毎の課金とかになるんだろうな
質問させてください。
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月版を使おうとしているのだろう
あ、変に端折ってしまいましたが、
/usr/local/etc/docker/my.cnf.d/(ディレクトリ)も
全く同じエラーでマウントできていない状態です。
docker-ceが1703なのはsnappy版だからで、
ubuntu1804のOSインストーラーでdocker関連を選んだらそうなったから、です。
別にsnappyが使いたいわけでもない（というかsnappyとか今回初めて知った）ので、
明らかな設定ミスとかが見つからなければ、docke-ceを上げてみるのも手ってことですね。
ホスト側ディレクトリ指定の末尾にスラッシュ付いてるけど、Dockerの公式ドキュメント（http://docs.docker.jp/compose/compose-file.html#volumes-volume-driver）だとそういう書き方してる例ないぞ
とりあえずシンプルに
- /usr/local/etc/docker
とだけ書いてマウントできるかどうか確認してから少しずつ設定詰めてみ
あとバージョン気にしたのは単に「セキュリティだの個人情報保護だのが騒がれるこのご時世に1年以上前のバージョンを使わざるを得ない事情でもあるのかなぁ」って思っただけよん
してから、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アプリケーションはスマホアプリみたいなもんで、
ホスト側ディレクトリの参照権限も大幅に制限されるということのようです。
/var/snap/docker配下なら如何様にもマウント可能でした。
お騒がせしました。
(433で名前間違えました。失礼しました）
おお、解決してよかった
ホスト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触り始めたばっかりなので
使い方とか概念理解がちょっと間違ってるのかもしれないですが、
逆に言うとこういう使い方が適切じゃない理由って何でしょう…？
OpenVPNをコンテナ化できれば（そして各コンテナにルーティングが書ければ）
Dockerfileだけ書いとけばVM同様可搬性も高くていいな、程度なんですが。
Dockerが仮想マシンの代わりとして設計してないから
だから「これがあれば仮想マシンとして使えるのに」と
思うような機能は意図的に搭載しないので
仮想マシンとしては使いにくいんですよ
なんでもかんでも機能搭載して複雑にしていくのは
アホな日本人ぐらいなもん
コンテナに好きなIPも振れるしゲートウェイも設定できるけど、
スタティックルートだけはあえて書かせないようにしている、と。
>>441
今回の例で言うと、OpenVPNはコンテナじゃなくてVMでやるべきって話ですよね？
設計云々はともかく実際なんで良くないんですか？
コンテナにrouteコマンド入れればいいじゃん
なぜよくわかってない拾いもので特殊なことをしようとするのか
OpenVPNはDockerコンテナでいいけど、ネットワーク周りは仮想化か実機とかDocker外でやったほうがいいって気がする
>>437で書いたコンテナBは、具体的にはZabbix公式のコンテナイメージで、
外部パッケージとかを入れらんないんです。
もちろん公式イメージに強引にrouteコマンドをブチ込むというのも
やってやれないこともないかもしれないですが、
それならコンテナ起動後netnsでrouteを送り込むとか、
諦めてホスト側でルーティングするとかの方がいいような。
現実的にもそれしかなさそうですね。
ホストにルートを書いて回避しました。
説明文を読み進めたらランチャーとは違うものだった
Dockと勘違いした
理解が全然違うか教えて欲しいのだけど、
nginx + uwsgi + flaskでサイトを開発したい場合は、ローカルでコードを書いて、
DockerfileにBusyBox + nginx + uwsgi + flaskを入れるように？設定して
docker buildを行うと、書いていたpythonコードと必要なコンポーネントが
まとまったdocker imageがサーバー上に出来上がり
docker runする事によりdocker imageから生成されてインスタンスが立ち上がる
であってる？
docker imageがclassでrunするとオブジェクトが出来上がると理解しているのだけれど、、、
なぜあえてクラスとオブジェクトに絡めて理解しようとするのか。
仕事で必要とかじゃなければ無理して理解する必要ないと思うよ
一般庶民が微分積分を理解できないように、一般プログラマにはDockerは難解過ぎる
なにを一塊のウェブアプリにしたいかだよ。
まず前提として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コンテナなので少し面倒になる。使うのがお手軽なのは後者
ま、理解できてないのはこの話じゃなさそうだけどねｗｗｗ
× 一般プログラマにはDockerは難解過ぎる
○ お前にはDockerは難解過ぎる
SESの人足なのか、自社開発でCIが文化になってる開発者なのか？
どっちも「一般プログラマ」といえば一般プログラマ（苦笑）
伝わらなくてごめんごめん
たしかにコンテナ分けると負荷が下がるとかは知りたいこととはまったく関係ない
今後職場でDockerを使うかもという話が出てて、
インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
なにか変わるのか事前に理解したくて。
調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが
パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に
コミットしてないとコード消えるのか？？？ってなってしまったわけなのよ
一般プログラマーからしてdocker imageは関係ないのなら調べるのやめるんだけど、
インフラから事前告知があったので影響あるのかと不安になった
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を使わないほうが楽だろう
だが、いつでも本番用環境を手元で作り出せると、本番用環境でのみ発生するバグなど避けられる
他の人も誰でも本番用環境で検証できるようになるわけだ
すごいわかりやすい説明
コンパイラに例えてもらえると分かりやすいわ
ありがとう
> インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
> なにか変わるのか事前に理解したくて。
インフラが全部やりますっていうのなら、開発側に影響はない。今までどおりだ。
そう今までどおり、開発側で新しいライブラリとか追加や更新しようと思たら
インフラにこれ変えたいんですけどとお伺いを立てたり
本番用環境とバージョンが違うとかでバグがでたり
そういう今ある問題がそのまま残るという意味で開発側に「影響がない」ということだ
Dockerfileはソースコードのリポジトリに追加するのが良い
（もちろん分離することもできるが、いろんな問題は解決するのが難しくなる）
そして開発側で新しいライブラリとか追加するなら、ソースコードのビルドスクリプトと同じように
Dockerfile等をインフラチームではなく開発チームがメンテナンスする。
そして最終的にソースコードのリポジトリから簡単な操作でDockerイメージが作れるようになれば
インフラチームはそのDockerイメージを動かすことだけに集中すれば良くなる
開発チームとインフラチームのやり取りが、Dockerイメージを実行する手順だけを伝えれば良くなる。
（例えば必要な環境変数など）
理想は
開発チーム・・・Dockerfileのメンテナンス（Dockerイメージを作成できるようにする）
インフラチーム・・・Dockerイメージの実行
なのだが、現実としてDockerはインフラチーム主導で導入されることが多いので
インフラチームのサポートでDockerfileを作っていくことになるだろう
> 調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが
> パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に
> コミットしてないとコード消えるのか？？？ってなってしまったわけなのよ
↑これとかで、混乱する。
Dockerは仮想マシンじゃないんだよ。
Dockerfileから作成したDockerイメージはビルドした状態から変更しないもの。（もちろん再ビルドはOK）
Dockerコンテナに乗り込んで、中身を書き換えて再イメージ化なんてこともしない。
できるけど、通常の使い方ではやらない
バイナリに例えれば、C言語のプロセスに乗り込んで（デバッガで？）
プロセスのメモリを書き換えて、プロセス部分をディスクに書き出すようなもんだよ
そんなことしないだろ？
virtualenvといわれると、少し違和感があるな
VMよりずっとましだけど
virtualenvは実行環境を作るもの
Dockerは実行環境を含めた実行イメージ＝Dockerイメージ＝実行バイナリの凄い版を
作るものだから
やっとそこの理解ができた
インフラがDocker推すのわかるわ
virtualenvのpython周りをなんとなくコンテナ化したのとはちがって、OS含めた実行環境コンテナを作れるとなると、ほんといろいろ解決できるな！
単一のバイナリをコピーするだけで、あちこちでそのまま動かすことができる。
それと同じようにDockerもDockerイメージの中に、いろんなものが詰め込まれてるので
あちこちで動かすことができる
ちなみにDockerfileでビルドしたDockerイメージはDockerリポジトリにpushしておける
（パブリックな公式のDocker hubや、各社プライベートリポジトリ等がある）
そうしたイメージは手元でDockerfileからビルドしなくてもpullするだけで使える
バイナリをコピーするだけで動かすことができるように
DockerイメージをDockerリポジトリからpullしてくるだけで動かすことができる
こういうのは開発者にとっても便利だよね。
ウェブアプリだけじゃなくCLIコマンドもDockerイメージ化することができるから
goみたいにスタティックリンクされたバイナリが作れない言語で作ったアプリでも
Dockerだけが入ってるクリーンな環境で、いきなり実行することもできちゃうわけだ
Dockerイメージを新しく（バージョンアップ）したから、
次からこれ使ってーって開発チームはインフラチームに依頼するだけでよくなる
インフラが気にするのはDockerイメージを実行することだけ
だからDockerイメージが起動さえすれば、物理（or 仮想マシン）の
OSを変えることだってできちゃう。
そのDockerイメージが動きさえすれば良いんでしょ？程度の気楽なもん
開発チームは開発チームで、物理（or 仮想マシン）のOSの機能に
（カーネル以外）依存しているわけじゃないので、
Dockerイメージのベースとなるディストリを変更したりなんでもできちゃう
物理（or 仮想マシン）のOSが変更になったって？別にOSのパッケージに
依存してるわけじゃないのでどうでもいいよ。程度の気楽なもん
いままでDebianベースでやってきたけど、ライブラリのバージョンが古いや
Ubuntuに乗り換えよう。なんてことも気楽にできちゃう
客先が使ってるマシンがCentOSだって？ Dockerがあれば関係ない。
UbuntuベースのDockerイメージが、そのまま動く
本気でやれば、いろいろ解決するよ。ただそのためには
インフラチームに丸投げじゃだめだけどね
ほんとベース理解できたら凄いわこれ
細かいホスト側？の設定はインフラに任せるとして
開発に影響のあるdockerfileの作り方も凝らなければストレートだね
これで環境周りのめんどくささからは解放される！
ツッコミどころ満載の説明だけど、概念はこれでおk.使い方はコマンド覚えろ。
466は反省しろよ
Dockerfileに書くのと
docker-compose.ymlに書くのと
どこにどうすればいいかがわからんわ
長い事使ってるがそんな機能がある事自体初耳
TraefikというDockerコンテナを自動的に登録してルーティング出来るリバースプロキシがあるんだが
Dockerのラベルでリバースプロキシの設定が出来る
https://docs.traefik.io/v1.7/
以下docker-compose.ymlの抜粋
ホストヘッダーでのルーティングを設定してる
# ...
whoami:
image: containous/whoami # A container that exposes an API to show its IP address
labels:
- "traefik.frontend.rule=Host:whoami.docker.localhost"
docker-compose.yamlはコマンドのオプションで指定するのと同じ
docker-composeコマンドというのはそもそも、
一つのコンテナだけ構成されたものを起動するならdocker runだけでいいけど、
複数のコンテナで構成するときに、docker runで適切なオプションつけて
複数起動するのが面倒って言うときに使うものだから、機能的にはdocker runと同等
run以外にbuildとかもできるけどね。
で、Dockerfileとdocker runの違いだが、Dockerfileはイメージの仕様として
ポートを公開しますよ、ボリュームを使用しますよって、明示するときに使う
docker runの方は公開されたポートをホスト上のどのポートに割り当てるのか
ボリュームをどこのディレクトリに割り当てるのか指定するのに使う
例えば、Dockerイメージとして構成されたものが、どんなポートを公開しているか？
っていうのはDockerfileを見ればわかるわけだ。
で、そのイメージを起動する場合、ポートを変更できる機能がなければ、
同一ホストで複数起動することができなくなるだろ？
実際にどのポートを使用するかは実行時にしか決められない。（ボリュームも同じ）
Dockerfileではそのイメージがどういうものかを書いて、
docker runはイメージを起動するときのオプションというわけ
> Dockerコンテナってラベル付ける機能あったんだ
ずいぶんと前についた気がするが？
昔docker-composeはラベル使っていなかったが、
途中でラベル使うように変わったよな
systemctl start serviceができるようにするには、
どうやってコンテナ作りをすればいいんでしょう。
privilegeを与えて、yumで開発環境投入して、
systemctl がつかえるように、serviceファイル設置して、
systemctl enable serviceのあと、shutdown したのち、
docker image化してはダメなんでしょうか？？
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【社会】はじめしゃちょー、ワクチン推進動画への批判に対し意図を説明「広告案件ではない」 [Gecko★]
- 日銀総裁 「円安で物価高なら、政策変更も、追加利上げにつながる」 [お断り★]
- インドGDP､2025年に日本抜き4位 円安でIMF推計前倒し ★2 [蚤の市★]
- 河野太郎デジタル相「マイナ保険証」使用不可医療機関「通報」要請…の記事に小沢一郎氏がXを更新 [少考さん★]
- アイヌ民族の人権問題解決へ 「人権機関設置が必要」日弁連がシンポ [北海道] [少考さん★]
- 自治体退職者10年で2倍 目立つ若手、待遇不満も [蚤の市★]
- チー牛でも群れるとイキリだすの何故なの？
- 🥺🍱 🤠😎😁「あっ！あいつ１人で弁当食べてるwww」
- 超絶無能俺氏、会社が嫌になって途中で帰宅し退職代行へ依頼を無事完了する
- (´・ω・｀)闇バイトがあるなら 光バイトもあるってことだよね
- スベリ芸ってクソじゃね？スベったのをまわりがフォローして面白い雰囲気にしてくれてるだけじゃん
- 海上自衛隊のヘリ2機、消息を絶つ [271912485]