Docker Part2

1 名前：login:Penguin mailto:sageteoff [2017/09/28(木) 14:00:45.18 ID:/4TtIqGt.net] LXCを使った軽量仮想環境。 これからの動向が気になるところ。 情報共有しましょう。 www.docker.io/ 前スレ Docker mao.2ch.net/test/read.cgi/linux/1374861492/ 449 名前：login:Penguin mailto:sage [2018/09/04(火) 11:08:31.46 ID:XGRY6CNs.net] --buildじゃだめ？ 450 名前：login:Penguin [2018/09/09(日) 06:08:55.90 ID:cEYtNNsu.net] >>390 それ、地震対策になるよね。 物理サーバーをまったく意識しない、 まるで半永久的なベースシステムがあれば、 コンテナをぜひ動かしたい。 451 名前：login:Penguin mailto:sage [2018/09/09(日) 09:40:19.57 ID:ZTk8dQJu.net] それだけではならないですよ 452 名前：login:Penguin mailto:sage [2018/09/09(日) 10:55:56.07 ID:e5pDDvY7.net] そのうちクラウドサービスがコンテナクラスタを用意して コンテナ毎の課金とかになるんだろうな 453 名前：login:Penguin mailto:sage [2018/09/09(日) 11:12:04.98 ID:ZTk8dQJu.net] そのうちもクソもコンテナのクラウドホスティングサービスは既にあるじゃん 454 名前：login:Penguin mailto:sage [2018/09/09(日) 19:24:56.20 ID:Afzp+wKU.net] 大手クラウドはGKE, AKS, EKSと揃い踏みなんだよなぁ 455 名前：login:Penguin mailto:sage [2018/09/13(木) 18:00:19.97 ID:A2WBsHxK.net] 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 この通りマウント元は存在するんですが、 どこ確認したら良いでしょうか…？ 456 名前：login:Penguin mailto:sage [2018/09/13(木) 19:39:40.56 ID:5kXiEAIj.net] ファイルをマウントしようとしているように見えるんだが、そこはディレクトリでないといかんのではないかと あと何故2017年06月版を使おうとしているのだろう 457 名前：login:Penguin mailto:sage [2018/09/14(金) 09:15:35.43 ID:O0WiB81l.net] >>428 あ、変に端折ってしまいましたが、 /usr/local/etc/docker/my.cnf.d/(ディレクトリ)も 全く同じエラーでマウントできていない状態です。 docker-ceが1703なのはsnappy版だからで、 ubuntu1804のOSインストーラーでdocker関連を選んだらそうなったから、です。 別にsnappyが使いたいわけでもない（というかsnappyとか今回初めて知った）ので、 明らかな設定ミスとかが見つからなければ、docke-ceを上げてみるのも手ってことですね。 458 名前：427 mailto:sage [2018/09/14(金) 18:06:45.51 ID:4XP848iF.net] - /usr/local/etc/docker/my.cnf.d/:/etc/my.cnf.d:ro ホスト側ディレクトリ指定の末尾にスラッシュ付いてるけど、Dockerの公式ドキュメント（docs.docker.jp/compose/compose-file.html#volumes-volume-driver）だとそういう書き方してる例ないぞ とりあえずシンプルに - /usr/local/etc/docker とだけ書いてマウントできるかどうか確認してから少しずつ設定詰めてみ あとバージョン気にしたのは単に「セキュリティだの個人情報保護だのが騒がれるこのご時世に1年以上前のバージョンを使わざるを得ない事情でもあるのかなぁ」って思っただけよん 459 名前：login:Penguin mailto:sage [2018/09/15(土) 07:01:30.83 ID:yI+cCQi1.net] 最新を追いかけてバグにハマる例は後を絶たない 460 名前：login:Penguin [2018/09/24(月) 01:08:42.35 ID:3WJGu+tF.net] docker stop container してから、commit するのはなぜ？ 461 名前：login:Penguin mailto:sage [2018/09/24(月) 04:53:27.83 ID:h/F6DQep.net] 「docker commit」で検索！ 462 名前：427 mailto:sage [2018/09/25(火) 15:20:50.57 ID:zdGJMagM.net] ファイルを指定しちゃダメだというのと ホスト側ディレクトリの最期にスラッシュ付けちゃダメだというのはご指摘通りでした。 それらを避ければうまくいく場合もあるんですが、うまくいかない場合もあり 動作ロジックがわかっていないため切り分けられずにいます。 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しようとして失敗してるんでしょうか？ そのあたりの仕組みが理解できれば、解決できそうな気もするんですが… 463 名前：426=433 mailto:sage [2018/10/02(火) 11:05:27.29 ID:MTSGNvvZ.net] snapのsandboxが原因でした。 snapアプリケーションはスマホアプリみたいなもんで、 ホスト側ディレクトリの参照権限も大幅に制限されるということのようです。 /var/snap/docker配下なら如何様にもマウント可能でした。 お騒がせしました。 (433で名前間違えました。失礼しました） 464 名前：login:Penguin mailto:sage [2018/10/02(火) 12:26:31.40 ID:ngnCMsef.net] >>435 おお、解決してよかった ホストOSの挙動が独特だとトラブルシューティングも難しいね 465 名前：login:Penguin mailto:sage [2018/10/02(火) 14:05:12.80 ID:jMGWfJIN.net] あー、そうだったのか。挙動的に誰かが制限かけてる感じだったから selinuxかな？とは思ったんだが、言っていたらヒントになってたかもな 466 名前：login:Penguin mailto:sage [2018/10/05(金) 17:28:47.41 ID:uwcVKd6M.net] 先に要点を書くと、コンテナにスタティックルートを書く正攻法を知りたいです。 ・外部から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側だけで解決したいなぁと。 何かご存じの方、教えてください。 467 名前：login:Penguin mailto:sage [2018/10/08(月) 17:27:52.77 ID:+G8YrS7/.net] docker使わずに仮装マシン使え案件な気がするが 468 名前：login:Penguin mailto:sage [2018/10/08(月) 18:31:01.90 ID:dcwIe0qQ.net] うん。そう。毎回言ってるんだけどね。 Dockerを仮想マシンの代わりとして使うなと Dockerコンテナは仮想アプリであって仮想マシンじゃない 469 名前：437 mailto:sage [2018/10/09(火) 09:49:23.16 ID:a4is0HOD.net] >>439-440 確かにdocker触り始めたばっかりなので 使い方とか概念理解がちょっと間違ってるのかもしれないですが、 逆に言うとこういう使い方が適切じゃない理由って何でしょう…？ OpenVPNをコンテナ化できれば（そして各コンテナにルーティングが書ければ） Dockerfileだけ書いとけばVM同様可搬性も高くていいな、程度なんですが。 470 名前：login:Penguin mailto:sage [2018/10/09(火) 11:37:32.24 ID:UEbDWUsW.net] >>441 Dockerが仮想マシンの代わりとして設計してないから だから「これがあれば仮想マシンとして使えるのに」と 思うような機能は意図的に搭載しないので 仮想マシンとしては使いにくいんですよ なんでもかんでも機能搭載して複雑にしていくのは アホな日本人ぐらいなもん 471 名前：437 mailto:sage [2018/10/09(火) 11:45:22.31 ID:a4is0HOD.net] ルーティングを書く機能がともかく存在しないってことですね。 コンテナに好きなIPも振れるしゲートウェイも設定できるけど、 スタティックルートだけはあえて書かせないようにしている、と。 >>442 今回の例で言うと、OpenVPNはコンテナじゃなくてVMでやるべきって話ですよね？ 設計云々はともかく実際なんで良くないんですか？ 472 名前：login:Penguin mailto:sage [2018/10/09(火) 12:56:46.60 ID:J/UkStG7.net] >>438 コンテナにrouteコマンド入れればいいじゃん なぜよくわかってない拾いもので特殊なことをしようとするのか 473 名前：login:Penguin mailto:sage [2018/10/09(火) 14:28:29.84 ID:lxGRoqO6.net] >>443 OpenVPNはDockerコンテナでいいけど、ネットワーク周りは仮想化か実機とかDocker外でやったほうがいいって気がする 474 名前：437 mailto:sage [2018/10/09(火) 14:41:21.41 ID:a4is0HOD.net] >>444 >>438で書いたコンテナBは、具体的にはZabbix公式のコンテナイメージで、 外部パッケージとかを入れらんないんです。 もちろん公式イメージに強引にrouteコマンドをブチ込むというのも やってやれないこともないかもしれないですが、 それならコンテナ起動後netnsでrouteを送り込むとか、 諦めてホスト側でルーティングするとかの方がいいような。 475 名前：437 mailto:sage [2018/10/09(火) 15:41:05.80 ID:a4is0HOD.net] >>445 現実的にもそれしかなさそうですね。 ホストにルートを書いて回避しました。 476 名前：login:Penguin mailto:sage [2018/10/16(火) 14:04:47.68 ID:JjMfngP+.net] Dockerのインストールは何でこんなにややこしいのかと 説明文を読み進めたらランチャーとは違うものだった Dockと勘違いした 477 名前：login:Penguin mailto:sage [2018/10/26(金) 03:04:33.03 ID:UuZWwwD+.net] Dockerがやはりまだ理解しきれておらず、、、 理解が全然違うか教えて欲しいのだけど、 nginx + uwsgi + flaskでサイトを開発したい場合は、ローカルでコードを書いて、 DockerfileにBusyBox + nginx + uwsgi + flaskを入れるように？設定して docker buildを行うと、書いていたpythonコードと必要なコンポーネントが まとまったdocker imageがサーバー上に出来上がり docker runする事によりdocker imageから生成されてインスタンスが立ち上がる であってる？ docker imageがclassでrunするとオブジェクトが出来上がると理解しているのだけれど、、、 478 名前：login:Penguin mailto:sage [2018/10/26(金) 06:35:45.90 ID:xzHCVt/i.net] >>449 なぜあえてクラスとオブジェクトに絡めて理解しようとするのか。 479 名前：login:Penguin mailto:sage [2018/10/26(金) 07:03:02.70 ID:Y5itkZBt.net] >>449 仕事で必要とかじゃなければ無理して理解する必要ないと思うよ 一般庶民が微分積分を理解できないように、一般プログラマにはDockerは難解過ぎる 480 名前：login:Penguin mailto:sage [2018/10/26(金) 07:40:58.49 ID:S+WdRTJT.net] >>449 なにを一塊のウェブアプリにしたいかだよ。 まず前提として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コンテナなので少し面倒になる。使うのがお手軽なのは後者 ま、理解できてないのはこの話じゃなさそうだけどねｗｗｗ 481 名前：login:Penguin mailto:sage [2018/10/26(金) 07:41:20.37 ID:S+WdRTJT.net] >>451 × 一般プログラマにはDockerは難解過ぎる ○ お前にはDockerは難解過ぎる 482 名前：login:Penguin mailto:sage [2018/10/26(金) 08:01:47.31 ID:BI6ZyjXf.net] 「一般プログラマ」ってのがどのレベルなのかと。 SESの人足なのか、自社開発でCIが文化になってる開発者なのか？ どっちも「一般プログラマ」といえば一般プログラマ（苦笑） 483 名前：login:Penguin mailto:sage [2018/10/26(金) 09:37:10.67 ID:UuZWwwD+.net] >>452 伝わらなくてごめんごめん たしかにコンテナ分けると負荷が下がるとかは知りたいこととはまったく関係ない 今後職場でDockerを使うかもという話が出てて、 インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして なにか変わるのか事前に理解したくて。 調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に コミットしてないとコード消えるのか？？？ってなってしまったわけなのよ 一般プログラマーからしてdocker imageは関係ないのなら調べるのやめるんだけど、 インフラから事前告知があったので影響あるのかと不安になった 484 名前：login:Penguin mailto:sage [2018/10/26(金) 09:58:02.43 ID:S+WdRTJT.net] >>455 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イメージができるんだから何も問題ない 485 名前：login:Penguin mailto:sage [2018/10/26(金) 10:06:27.87 ID:S+WdRTJT.net] で、ウェブ開発の際に使う場合に、これじゃ使いづらい場合がある C言語の場合、ビルドしないと動く実行バイナリはできないから これで納得するかもしれないけど、ウェブ開発とかしてると ビルドしなくてもソースコードを修正したらすぐに反映されるわけだ 毎回Dockerビルドしないといけないのは辛い。こういう場合にボリュームを使う手がある データはDockerイメージの外に置くといったけど、ソースコードもDockerイメージの外に置けばいい Dockerイメージの中にはPython実行環境などが入っているけど、ソースコードは含めない ホームディレクトリ以下のいつもの場所をそのまま参照する 当然エディタもDockerイメージの中に入れない。 今までどおりエディタで編集して、実行環境がDockerイメージなっただけ ただね。Dockerイメージで作る実行環境は、本番用環境と同じにだいたいするので デバッグなどはし辛い。だから通常のアプリ開発はDockerを使わないほうが楽だろう だが、いつでも本番用環境を手元で作り出せると、本番用環境でのみ発生するバグなど避けられる 他の人も誰でも本番用環境で検証できるようになるわけだ 486 名前：login:Penguin mailto:sage [2018/10/26(金) 10:18:44.97 ID:UuZWwwD+.net] >>457 すごいわかりやすい説明 コンパイラに例えてもらえると分かりやすいわ ありがとう 487 名前：login:Penguin mailto:sage [2018/10/26(金) 10:20:16.70 ID:S+WdRTJT.net] >>455 > インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして > なにか変わるのか事前に理解したくて。 インフラが全部やりますっていうのなら、開発側に影響はない。今までどおりだ。 そう今までどおり、開発側で新しいライブラリとか追加や更新しようと思たら インフラにこれ変えたいんですけどとお伺いを立てたり 本番用環境とバージョンが違うとかでバグがでたり そういう今ある問題がそのまま残るという意味で開発側に「影響がない」ということだ Dockerfileはソースコードのリポジトリに追加するのが良い （もちろん分離することもできるが、いろんな問題は解決するのが難しくなる） そして開発側で新しいライブラリとか追加するなら、ソースコードのビルドスクリプトと同じように Dockerfile等をインフラチームではなく開発チームがメンテナンスする。 そして最終的にソースコードのリポジトリから簡単な操作でDockerイメージが作れるようになれば インフラチームはそのDockerイメージを動かすことだけに集中すれば良くなる 開発チームとインフラチームのやり取りが、Dockerイメージを実行する手順だけを伝えれば良くなる。 （例えば必要な環境変数など） 理想は 　開発チーム・・・Dockerfileのメンテナンス（Dockerイメージを作成できるようにする） 　インフラチーム・・・Dockerイメージの実行 なのだが、現実としてDockerはインフラチーム主導で導入されることが多いので インフラチームのサポートでDockerfileを作っていくことになるだろう 488 名前：login:Penguin mailto:sage [2018/10/26(金) 10:26:18.88 ID:UuZWwwD+.net] 今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね 489 名前：login:Penguin mailto:sage [2018/10/26(金) 10:29:10.46 ID:S+WdRTJT.net] Dockerを仮想マシンの代わりとしてとか考えてると > 調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが > パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に > コミットしてないとコード消えるのか？？？ってなってしまったわけなのよ ↑これとかで、混乱する。 Dockerは仮想マシンじゃないんだよ。 Dockerfileから作成したDockerイメージはビルドした状態から変更しないもの。（もちろん再ビルドはOK） Dockerコンテナに乗り込んで、中身を書き換えて再イメージ化なんてこともしない。 できるけど、通常の 490 名前：使い方ではやらない バイナリに例えれば、C言語のプロセスに乗り込んで（デバッガで？） プロセスのメモリを書き換えて、プロセス部分をディスクに書き出すようなもんだよ そんなことしないだろ？ [] [ここ壊れてます] 491 名前：login:Penguin mailto:sage [2018/10/26(金) 10:34:41.20 ID:S+WdRTJT.net] > 今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね virtualenvといわれると、少し違和感があるな VMよりずっとましだけど virtualenvは実行環境を作るもの Dockerは実行環境を含めた実行イメージ＝Dockerイメージ＝実行バイナリの凄い版を 作るものだから 492 名前：login:Penguin mailto:sage [2018/10/26(金) 10:39:21.79 ID:UuZWwwD+.net] >>462 やっとそこの理解ができた インフラがDocker推すのわかるわ virtualenvのpython周りをなんとなくコンテナ化したのとはちがって、OS含めた実行環境コンテナを作れるとなると、ほんといろいろ解決できるな！ 493 名前：login:Penguin mailto:sage [2018/10/26(金) 10:44:35.53 ID:S+WdRTJT.net] 例えばgoで作られたバイナリは、いろんなものがスタティックリンクされるので 単一のバイナリをコピーするだけで、あちこちでそのまま動かすことができる。 それと同じようにDockerもDockerイメージの中に、いろんなものが詰め込まれてるので あちこちで動かすことができる ちなみにDockerfileでビルドしたDockerイメージはDockerリポジトリにpushしておける （パブリックな公式のDocker hubや、各社プライベートリポジトリ等がある） そうしたイメージは手元でDockerfileからビルドしなくてもpullするだけで使える バイナリをコピーするだけで動かすことができるように DockerイメージをDockerリポジトリからpullしてくるだけで動かすことができる こういうのは開発者にとっても便利だよね。 ウェブアプリだけじゃなくCLIコマンドもDockerイメージ化することができるから goみたいにスタティックリンクされたバイナリが作れない言語で作ったアプリでも Dockerだけが入ってるクリーンな環境で、いきなり実行することもできちゃうわけだ 494 名前：login:Penguin mailto:sage [2018/10/26(金) 10:56:20.22 ID:S+WdRTJT.net] >>463 Dockerイメージを新しく（バージョンアップ）したから、 次からこれ使ってーって開発チームはインフラチームに依頼するだけでよくなる インフラが気にするのはDockerイメージを実行することだけ だからDockerイメージが起動さえすれば、物理（or 仮想マシン）の OSを変えることだってできちゃう。 そのDockerイメージが動きさえすれば良いんでしょ？程度の気楽なもん 開発チームは開発チームで、物理（or 仮想マシン）のOSの機能に （カーネル以外）依存しているわけじゃないので、 Dockerイメージのベースとなるディストリを変更したりなんでもできちゃう 物理（or 仮想マシン）のOSが変更になったって？別にOSのパッケージに 依存してるわけじゃないのでどうでもいいよ。程度の気楽なもん いままでDebianベースでやってきたけど、ライブラリのバージョンが古いや Ubuntuに乗り換えよう。なんてことも気楽にできちゃう 客先が使ってるマシンがCentOSだって？ Dockerがあれば関係ない。 UbuntuベースのDockerイメージが、そのまま動く 本気でやれば、いろいろ解決するよ。ただそのためには インフラチームに丸投げじゃだめだけどね 495 名前：login:Penguin mailto:sage [2018/10/26(金) 11:34:43.60 ID:UuZWwwD+.net] >>465 ほんとベース理解できたら凄いわこれ 細かいホスト側？の設定はインフラに任せるとして 開発に影響のあるdockerfileの作り方も凝らなければストレートだね これで環境周りのめんどくささからは解放される！ 496 名前：login:Penguin mailto:sage [2018/10/26(金) 13:18:37.63 ID:4wc3titV.net] chrootで仮想化するのを全自動で管理できるようにしたのがdocker、chroot以下構築のbashファイルに相当するのがDockerfile。 ツッコミどころ満載の説明だけど、概念はこれでおk.使い方はコマンド覚えろ。 497 名前：login:Penguin mailto:sage [2018/10/27(土) 19:48:50.40 ID:5pOpML2z.net] は？ 498 名前：login:Penguin mailto:sage [2018/11/01(木) 11:02:05.82 ID:Ub4h8gMB.net] クソレスのせいで会話とまったな 466は反省しろよ 499 名前：login:Penguin mailto:sage [2018/11/05(月) 05:00:26.04 ID:tQ7nIs7Z.net] シェルのコマンドで-pとか-vとか指定するのと Dockerfileに書くのと docker-compose.ymlに書くのと どこにどうすればいいかがわからんわ 500 名前：login:Penguin [2018/11/05(月) 08:23:33.46 ID:R14xwsxg.net] Dockerコンテナってラベル付ける機能あったんだ 長い事使ってるがそんな機能がある事自体初耳 TraefikというDockerコンテナを 501 名前：自動的に登録してルーティング出来るリバースプロキシがあるんだが 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" [] [ここ壊れてます] 502 名前：login:Penguin mailto:sage [2018/11/05(月) 08:47:09.36 ID:Thuf2ewx.net] >>470 docker-compose.yamlはコマンドのオプションで指定するのと同じ docker-composeコマンドというのはそもそも、 一つのコンテナだけ構成されたものを起動するならdocker runだけでいいけど、 複数のコンテナで構成するときに、docker runで適切なオプションつけて 複数起動するのが面倒って言うときに使うものだから、機能的にはdocker runと同等 run以外にbuildとかもできるけどね。 で、Dockerfileとdocker runの違いだが、Dockerfileはイメージの仕様として ポートを公開しますよ、ボリュームを使用しますよって、明示するときに使う docker runの方は公開されたポートをホスト上のどのポートに割り当てるのか ボリュームをどこのディレクトリに割り当てるのか指定するのに使う 例えば、Dockerイメージとして構成されたものが、どんなポートを公開しているか？ っていうのはDockerfileを見ればわかるわけだ。 で、そのイメージを起動する場合、ポートを変更できる機能がなければ、 同一ホストで複数起動することができなくなるだろ？ 実際にどのポートを使用するかは実行時にしか決められない。（ボリュームも同じ） Dockerfileではそのイメージがどういうものかを書いて、 docker runはイメージを起動するときのオプションというわけ 503 名前：login:Penguin mailto:sage [2018/11/05(月) 08:47:55.99 ID:Thuf2ewx.net] >>471 > Dockerコンテナってラベル付ける機能あったんだ ずいぶんと前についた気がするが？ 昔docker-composeはラベル使っていなかったが、 途中でラベル使うように変わったよな 504 名前：login:Penguin [2018/11/07(水) 00:40:27.75 ID:JZV5z18S.net] たとえば、あるソースをコンパイルして、 systemctl start serviceができるようにするには、 どうやってコンテナ作りをすればいいんでしょう。 privilegeを与えて、yumで開発環境投入して、 systemctl がつかえるように、serviceファイル設置して、 systemctl enable serviceのあと、shutdown したのち、 docker image化してはダメなんでしょうか？？ 505 名前：login:Penguin mailto:sage [2018/11/07(水) 00:52:45.66 ID:v7o9U8jP.net] >>474 なんでソースのコンパイルなんて話が出てくるのかわからん Dockerのコンテナはsystemctl start serviceから起動する必要はない 通常はDockerそのものがsystemctl start serviceで起動するようになってるから Dockerでサービスが起動するコンテナを作ってあとはDockerに OS起動時に、そのコンテナを起動してもらえばいいだけ どうしても特定のDockerコンテナだけsystemdで制御したければ、 dockerコマンドを実行するserviceファイル書けばいいだけだが > privilegeを与えて、yumで開発環境投入して、 ？？？ 意味がわからんが、Dockerの中に入って開発しようとしてないか？ systemctlコマンドを使うのは、もちろんDockerコンテナの外だよな？ 通常はDockerコンテナの中で、systemdなんか使わないからな Dockerの中に開発環境入れて、Dockerの中で開発なんてことはしねーからな そういうのは仮想マシンとかシステムコンテナでやれ Dockerのようなアプリケーションコンテナを仮想マシンとかして使うな。 無理やり使おうとしたその結果が、お前のその「どうやればわからない」という状況なんだからな 506 名前：login:Penguin [2018/11/07(水) 00:57:39.50 ID:JZV5z18S.net] >>475 レスありがとうございます。 ＞Dockerでサービスが起動するコンテナを作ってあとはDockerに ＞OS起動時に、そのコンテナを起動してもらえばいいだけ ソースで提供されているプログラムをDockerコンテナで使いたい場合、 具体的にどうすればいいでしょうか。 コンテナに入ってから、 コンパイルすることしか想像できない初心者です。 507 名前：login:Penguin mailto:sage [2018/11/07(水) 01:11:12.42 ID:v7o9U8jP.net] >>476 Dockerfileを使ってビルドするんだよ コンテナの中に入るのは、ビルドがおかしいが原因がよくわからないとかで 調査するため。手作業でコンパイルとかしない 単純にDockerコンテナ内でビルドすると時間がかかったりイメージサイズが膨れ上がっ 508 名前：たり するから工夫が必要なんだが、とりあえずそれは置いといて、一番単純な方法だ。 まずDockerfielを書く。Dockerfileには基本的に次のようなことを書く ・FROMでどのディストリをベースにしたイメージを作るのかを書く ・RUN（RUN yum〜とか）でイメージの中にコンパイルをするのに必要なパッケージを入れていく ・ソースコードをコンテナの中に配置する 　（コンテナの外にあるソースをコピーしたりgitでcloneしたり、場合によってはボリュームを使う） ・プログラムをビルドする ・ビルドされたプログラムを起動するためのCMDやENTRYPOINTを書く これで、ソースコードからビルドしたプログラムが入った Dockerイメージが出来上がる。 あとは、dockerコマンドやdocker-composeなどでこれらを起動すれば良い [] [ここ壊れてます] 509 名前：login:Penguin mailto:sage [2018/11/07(水) 01:21:22.84 ID:v7o9U8jP.net] >>477で書いたように、単純な方法を取ると、 アプリを起動するのに必要ないビルドツールのせいで イメージサイズが大きく膨れ上がる。 レイヤー（例えばRUN）毎に差分が保存されるため ビルドが終わってから削除してもイメージサイズは減らない （一つのRUNの中ですべてを行う方法があるが、 キャッシュも使われなくなるのでイメージのビルド時間が伸びる） こういう場合に使うのが multi stage build アプリを使うためには、アプリの実行ファイル（とランタイム環境）さえあればよいので、 ソースコードから実行ファイルを作る所までをビルド専用イメージで行う そしてその実行ファイルをコピーして使う別のイメージ（ビルドツールなし）を作るという方法 510 名前：login:Penguin [2018/11/07(水) 01:21:25.66 ID:JZV5z18S.net] >>477 丁寧なレスをいただき、感謝いたします。 ありがとうございます。しかし、疑問が／／／ 環境構築は手探りではダメで、 ビルドなどを含む全ての環境構築手順を、 スクリプト化できていないとダメなようですね。 Dockerfileでも、yumコマンドが扱われていることから、 ログインしてビルドコマンドを手打して動作確認するという従来の方法と比べて、 何が本質的に違うのかなと素朴に疑問です。 どうしてわざわざ、Dockerイメージづくりを自動化しなければいけないのですか。 できたイメージはtarで持ち運ぶつもりでいます。 511 名前：login:Penguin [2018/11/07(水) 01:25:02.67 ID:JZV5z18S.net] >>478 脹れ上がりですね。 ＞ビルドが終わってから削除してもイメージサイズは減らない 知りませんでした。ありがとうございます。 英文ですが、さっきこれを見つけたところでした。 https://stackoverflow.com/questions/41688748/should-i-compile-my-application-inside-of-a-docker-image 勉強します。丁寧なレス感謝いたします。 脹れ上がり防止と、 dockerfileによるイメージ作成の自動化が焦点になっているという認識であっていますでしょうか。 ありがとうざいました。 512 名前：login:Penguin mailto:sage [2018/11/07(水) 01:29:04.85 ID:v7o9U8jP.net] >>479 > 環境構築は手探りではダメで、 > ビルドなどを含む全ての環境構築手順を、 > スクリプト化できていないとダメなようですね。 Dockerfileを手探りで書けばいいじゃん。 FOROM deban COPY ソースコード RUN yum install パッケージ RUN ./configure とか書いてビルドして、あれぇ？ビルドできないなぁとかなったら FOROM deban COPY ソースコード RUN yum install パッケージ RUN yum install 足りないパッケージ RUN ./configure とかしていくんだよ。そうすれば、RUN yum install パッケージが 終わった段階のキャッシュの続きから実行されるから、 手探りでやってるのと大差ない作業になる 最後にyumとかでまとめておしまい 513 名前：login:Penguin mailto:sage [2018/11/07(水) 01:30:07.71 ID:v7o9U8jP.net] まあどうしてもわからないなら、コンテナに入りつつ ビルドしていって試してもいいけど、最終的には Dockerfileにビルドするためのコマンドを書く 514 名前：login:Penguin mailto:sage [2018/11/07(水) 01:30:23.27 ID:JZV5z18S.net] >>475 ＞Dockerでサービスが起動するコンテナを作ってあとはDockerに ＞OS起動時に、そのコンテナを起動してもらえばいいだけ ソースのreadmeは、Dockerコンテナを想定していないです。 すると、dockerコンテナ内で、systemctl enable serviceをセットして、 コンテナの起動によってそのサービスが起動するようにするしか私には無理そうです。 とすると、privilegeとか、なにか別の特権を与えてコンテナを起動して、 仮想マシンみたいにコンテナを動かすしか手が見つからないんです。 515 名前：login:Penguin [2018/11/07(水) 01:34:57.16 ID:JZV5z18S.net] >>481 ＞そうすれば、RUN yum install パッケージが ＞終わった段階のキャッシュの続きから実行されるから、 ＞手探りでやってるのと大差ない作業になる 続きから継続されるという仕組みがいまひとつピンとこないんですが、 知らなかったです。書籍も読んでいるんですが、あまり実践的ではないものが多いように思います。 最後にyumとかでまとめて御仕舞いというのは、 ワンライナーでかけるところはまとめて、dockerfileを作れということですね。 516 名前：login:Penguin mailto:sage [2018/11/07(水) 01:36:09.53 ID:v7o9U8jP.net] >>479 > Dockerfileでも、yumコマンドが扱われていることから、 > ログインしてビルドコマンドを手打して動作確認するという従来の方法と比べて、 > 何が本質的に違うのかなと素朴に疑問です。 Dockerは動作確認するためのツールじゃねーし。何かを作るためのもの。 その何かっていうのはDockerイメージでありそこから起動するDockerコンテナ そのDockerイメージやDockerコンテナを作るために、最終的にDockerfileを書くんだよ。 Dockerイメージ = 実行ファイル Dockerコンテナ = 実行ファイルを起動したもの と考える アプリの実行ファイルの中にデータファイルを作成しないのと同様に Dockerコンテナ・Dockerイメージの中にはデータファイルは置かない つまり、Dockerコンテナ（イメージも）は壊してDockerfileから 作り直してもなんの問題もないわけだ なんの問題もないし、実際にそうする。 517 名前：login:Penguin [2018/11/07(水) 01:36:15.87 ID:JZV5z18S.net] >>482 ありがとうございます。 ずっと、どうしてコンテナに入って作業してはいけないのかが、 謎だったんですが、入って作業するのもアリなわけですね。 ホッとしました。 518 名前：login:Penguin [2018/11/07(水) 01:40:32.26 ID:JZV5z18S.net] >>485 なるほど。 ＞Dockerイメージ = 実行ファイル ＞Dockerコンテナ = 実行ファイルを起動したもの とてもわかりやすい喩えです。 ＞つまり、Dockerコンテナ（イメージも）は壊してDockerfileから ＞作り直してもなんの問題もないわけだ ＞なんの問題もないし、実際にそうする。 Dockerfileさえあればいいってことがよくわかりました！ ＞アプリの実行ファイルの中にデータファイルを作成しないのと同様に ＞Dockerコンテナ・Dockerイメージの中にはデータファイルは置かない ボリューム（あるいはボリュームを用いたデータ専用コンテナ）を使えってことですね。 519 名前：login:Penguin mailto:sage [2018/11/07(水) 01:43:35.19 ID:v7o9U8jP.net] >>483 > ソースのreadmeは、Dockerコンテナを想定していないです。 > すると、dockerコンテナ内で、systemctl enable serviceをセットして、 > コンテナの起動によってそのサービスが起動するようにするしか私には無理そうです。 無理じゃなくて調べろ。systemdを使わずにアプリを（フォアグラウンドで） 起動するやり方を調べろ。普通はその方法で起動する。 うん、だから、俺はDockerはインフラのためのツールと言うより アプリ開発者のためのツールだって言ってるんだよ インフラはアプリを作らない。だからDockerでアプリを起動しようと思ったら そのアプリの起動方法を調べないといけない。よく知らないアプリの 起動方法やどこにどういうデータが保存されるかなんて調べるのは面倒だろ 仮想マシンでパッケージ使って起動すりゃいいんだよ。 パッケージ使ってりゃ依存関係とかディストリが解決してくれてんだろ アップデートもやってくれるだろ アプリ開発者の場合はアプリを作る。アプリ開発者ならsystemd使わない起動方法だって知ってる。 むしろsystemd使うほうが面倒。どこにデータを保存するかもわかってる。 アプリはディストリが用意するパッケージには依存したくない。アプリを動かすのに必要なものは全部管理したい だからDocker使ってイメージを作るんだよ。あとはインフラにこのイメージ起動してって ぽんと渡すだけでよくなる。 520 名前：login:Penguin mailto:sage [2018/11/07(水) 01:45:23.17 ID:v7o9U8jP.net] >>486 > ずっと、どうしてコンテナに入って作業してはいけないのかが、 > 謎だったんですが、入って作業するのもアリなわけですね。 > ホッとしました。 それを作業って言うのが謎。調査だよ。作業じゃない。 コンテナでやった作業（ではないもの）は全て破棄されるんだから コンテナに入るのは調査するためだけ 521 名前：login:Penguin [2018/11/07(水) 01:53:42.95 ID:JZV5z18S.net] >>488 ＞無理じゃなくて調べろ。systemdを使わずにアプリを（フォアグラウンドで） ＞起動するやり方を調べろ。普通はその方法で起動する。 目が覚めました！ありがとうございます。直接起動する方法を調べないと駄目ですね。 Linuxは柔軟ですね。（WindowsならSQL SERVERはフォアグランドで動かせなさそうだもの。） いわば、クリスマスツリーの電飾から、一つだけ豆球を取り外して、乾電池につないで動かすようなもののように感じます。 ＞うん、だから、俺はDockerはインフラのためのツールと言うより ＞アプリ開発者のためのツールだって言ってるんだよ ＞あとはインフラにこのイメージ起動してってぽんと渡すだけでよくなる。 >>485の喩えを使って言えば、 スーパーアプリみたいな感じなのかな。 ＞アプリ開発者ならsystemd使わない起動方法だって知ってる。 冒頭でいいましたが、これはDockerと付き合う今の私に必要な言葉でした。 ＞アプリはディストリが用意するパッケージには依存したくない。 ＞アプリを動かすのに必要なものは全部管理したい ＞だからDocker使ってイメージを作るんだよ。 Dockerとは、解体、原点に戻れですね。 丁寧にご指南いただき、本当にありがとございました。 とても勉強になりました！ 522 名前：login:Penguin [2018/11/07(水) 01:54:23.86 ID:JZV5z18S.net] >>489 よくわかります！ 523 名前：login:Penguin mailto:sage [2018/11/07(水) 01:56:23.49 ID:v7o9U8jP.net] > アプリ開発者ならsystemd使わない起動方法だって知ってる。 っていうのは、 自分で開発しているアプリなら、systemd使わない起動方法だって知ってる っていう意味無 アプリ開発者はすげーから、なんでも知ってる 524 名前：ぜーって意味ではないので [] [ここ壊れてます] 525 名前：login:Penguin mailto:sage [2018/11/07(水) 01:57:11.36 ID:v7o9U8jP.net] 訂正（意味無ってなんだよ？） 自分で開発しているアプリなら、systemd使わない起動方法だって知ってる っていう意味な 526 名前：login:Penguin [2018/11/07(水) 01:59:57.97 ID:JZV5z18S.net] >>492 ＞自分で開発しているアプリなら、systemd使わない起動方法だって知ってるっていう意味な あー、よかった、そうですか。 ちょっと大変そうだと心折れかかっていました。 自分で作るプログラムならよく把握できていますものね。 527 名前：login:Penguin mailto:sage [2018/11/07(水) 02:08:54.57 ID:v7o9U8jP.net] MySQLとかデータを大切に扱う必要があるものは どこにデータが保存されてるかとかもしっかり明記されてるから （クラウド使えよって思うが）Docker化するのは比較的楽だけど WordPressとかウェブアプリとか、どこに何を保存しているのか よくわからんものを、Docker化しようと思うよなって インフラ屋がせっせと既存アプリをDocker化してるのを見てると思うよ お前それ、信頼できるの？記事データはデータベースに保存されるから大丈夫みたいだが、 アップロードした画像とかデータベースサーバーじゃなくて ディレクトリに保存されるじゃん？ ちゃんと共有ストレージ使うようなってんの？ 管理画面からプラグインの導入できるけど、プラグインははデータディレクトリじゃない所に 保存されてるよね？そっちの対応は大丈夫？とか気になってしょうがない 528 名前：login:Penguin mailto:sage [2018/11/07(水) 09:13:06.91 ID:MDpN/AEY.net] 補足だけど、systemdはパソコンの起動時に自動的に起動させるのが主な役目だからDockerのコンテナでも 起動時に起動させるのにsystemdを使ってもいいんですよ。 そのためには起動コマンドを調べる必要があるってことです。*.serviceのファイルを作成するだけで systemd管理はできますが、*.serviceには当然起動コマンドを書く必要があるので。 529 名前：login:Penguin mailto:sage [2018/11/07(水) 11:48:41.20 ID:v7o9U8jP.net] >>496 今の話は、Dockerコンテナの中でsystemd使うなって話な Dockerはそういう用途で使うためのもんじゃないから そんな事をしようとすると、ハマるんだぞ 追加権限が必要なのが何よりの証拠 530 名前：login:Penguin mailto:sage [2018/11/07(水) 12:15:05.51 ID:MDpN/AEY.net] >>497 あり、レス読み間違えてたわすまん。 Dockerで中身いじるとしたらgitで遠隔操作するか、DBの永続化ぐらいで対応するのが常套だけど、 コンテナ内ならsystemdじゃなくてSupervisorがdocker公式になかった？ 531 名前：login:Penguin mailto:sage [2018/11/08(木) 00:22:57.37 ID:Ueh2RoXc.net] LXC, LXD（Linux Containers）だと、コンテナ内に入って、 アプリのインストールなど、環境構築できる AWS でも使っている 532 名前：login:Penguin [2018/11/08(木) 03:09:23.40 ID:NV3KMhMa.net] >>499 Dockerと、Linux Containerとは、 何が大きく違いますか？ Dockerはネットワークやコンテナの管理が便利だけどなあ。 533 名前：login:Penguin [2018/11/08(木) 03:11:15.01 ID:NV3KMhMa.net] >>499 DockerもLinux Containerも、共にLinuxの独立分離機能を用いていると言うし。 534 名前：login:Penguin mailto:sage [2018/11/08(木) 03:29:19.31 ID:KwyGHPnO.net] 使ってる機能が同じでも、目的のために最適化されたツールになってる だから、なにが目的かを正しく理解する必要がある。 Dockerはアプリケーションを仮想化することで アプリケーションに可搬性をもたせるのが目的 Docker化したアプリはどこでも動かせる その目的のために使う道具 LXCやLXDだとそれをやるのはとても大変だろう？ 535 名前：login:Penguin mailto:sage [2018/11/08(木) 06:56:36.33 ID:8m7pC1YT.net] https://qiita.com/Surgo/items/709a07d68c6eafbad267 536 名前：login:Penguin mailto:sage [2018/11/08(木) 08:04:08.58 ID:AYcFG6pB.net] ありがとうございます。 >>502 LXCや、LXDだと、別のホストでは動作しないのでしょうか？ >>503 すみません参考になります。 537 名前：login:Penguin mailto:sage [2018/11/08(木) 08:33:22.59 ID:KwyGHPnO.net] > LXCや、LXDだと、別のホストでは動作しないのでしょうか？ 頑張ればできるんじゃね？ とてつもなく頑張ればｗ 538 名前：login:Penguin mailto:sage [2018/11/08(木) 15:05:12.27 ID:Y2MwyzYh.net] 18.09.0 が来た 539 名前：login:Penguin mailto:sage [2018/11/08(木) 15:36:35.47 ID:rbD7hoQI.net] >>505 � 540 名前：ﾆてつもなく頑張ればｗ 条件付きだがライブマイグレーションできる>LXD [] [ここ壊れてます] 541 名前：login:Penguin [2018/11/08(木) 18:42:28.72 ID:AYcFG6pB.net] >>507 マイグレーションが一番の魅力だから、 やっぱりDockerがいいなあ。 542 名前：login:Penguin mailto:sage [2018/11/08(木) 21:55:42.35 ID:y26ltpJb.net] OpenVZでdocker動くかもと見たんだか、ほんと？ 543 名前：login:Penguin mailto:sage [2018/11/08(木) 22:37:13.81 ID:KwyGHPnO.net] Linuxカーネルに互換性があるなら動くんじゃないの？ 544 名前：login:Penguin mailto:sage [2018/11/09(金) 00:00:17.07 ID:0q/3jACl.net] 6使ってたら2.6で当然動かないよ 見たことないけど7使ってるとこなら動くはず 545 名前：login:Penguin [2018/11/09(金) 08:00:07.01 ID:XRMQbvdS.net] >>511 仮想マシンとは違うものね 546 名前：login:Penguin mailto:sage [2018/11/10(土) 17:54:47.28 ID:ZYfU+HA8.net] 7ですね あまり需要ないかと思いますが、格安vpsで動くと嬉しい 547 名前：login:Penguin mailto:sage [2018/11/10(土) 19:16:43.39 ID:2zo/Zkkd.net] 格安VPSで7ってどこ？ 普通に知りたい 548 名前：login:Penguin mailto:sage [2018/11/11(日) 14:14:06.80 ID:6/dIT6k3.net] テケトーにググったら >NTTPCコミュニケーションズ WebARENA VPSクラウド プラン10 ttps://web.arena.ne.jp/pdf/vpscloud_spec.pdf コレでcentos7動いてるみたいだが 月額\360〜 549 名前：login:Penguin mailto:sage [2018/11/11(日) 14:29:07.06 ID:r372XCNT.net] >>515 その表を見る限りCentOS7が動いてるのはKVMだけ見たいだしホストがRHEL6なOpenVZでもCentOS7は動くよ(kernelに実装されてない機能は使えないが

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef