[過去ﾛｸﾞ] Docker Part2©2ch.net (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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は反省しろよ
469(1): 2018/11/05(月)05:00 ID:tQ7nIs7Z(1) AAS
シェルのコマンドで-pとか-vとか指定するのと
Dockerfileに書くのと
docker-compose.ymlに書くのと
どこにどうすればいいかがわからんわ
470(1): 2018/11/05(月)08:23 ID:R14xwsxg(1) AAS
Dockerコンテナってラベル付ける機能あったんだ
長い事使ってるがそんな機能がある事自体初耳
TraefikというDockerコンテナを自動的に登録してルーティング出来るリバースプロキシがあるんだが
Dockerのラベルでリバースプロキシの設定が出来る
外部ﾘﾝｸ:docs.traefik.io
以下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"
471: 2018/11/05(月)08:47 ID:Thuf2ewx(1/2) AAS
>>469
docker-compose.yamlはコマンドのオプションで指定するのと同じ
docker-composeコマンドというのはそもそも、
一つのコンテナだけ構成されたものを起動するならdocker runだけでいいけど、
複数のコンテナで構成するときに、docker runで適切なオプションつけて
複数起動するのが面倒って言うときに使うものだから、機能的にはdocker runと同等
run以外にbuildとかもできるけどね。
で、Dockerfileとdocker runの違いだが、Dockerfileはイメージの仕様として
ポートを公開しますよ、ボリュームを使用しますよって、明示するときに使う
docker runの方は公開されたポートをホスト上のどのポートに割り当てるのか
ボリュームをどこのディレクトリに割り当てるのか指定するのに使う
例えば、Dockerイメージとして構成されたものが、どんなポートを公開しているか？
っていうのはDockerfileを見ればわかるわけだ。
で、そのイメージを起動する場合、ポートを変更できる機能がなければ、
同一ホストで複数起動することができなくなるだろ？
実際にどのポートを使用するかは実行時にしか決められない。（ボリュームも同じ）
Dockerfileではそのイメージがどういうものかを書いて、
docker runはイメージを起動するときのオプションというわけ
472: 2018/11/05(月)08:47 ID:Thuf2ewx(2/2) AAS
>>470
> Dockerコンテナってラベル付ける機能あったんだ
ずいぶんと前についた気がするが？
昔docker-composeはラベル使っていなかったが、
途中でラベル使うように変わったよな
473(1): 2018/11/07(水)00:40 ID:JZV5z18S(1/11) AAS
たとえば、あるソースをコンパイルして、
systemctl start serviceができるようにするには、
どうやってコンテナ作りをすればいいんでしょう。
privilegeを与えて、yumで開発環境投入して、
systemctl がつかえるように、serviceファイル設置して、
systemctl enable serviceのあと、shutdown したのち、
docker image化してはダメなんでしょうか？？
474(2): 2018/11/07(水)00:52 ID:v7o9U8jP(1/12) AAS
>>473
なんでソースのコンパイルなんて話が出てくるのかわからん
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のようなアプリケーションコンテナを仮想マシンとかして使うな。
無理やり使おうとしたその結果が、お前のその「どうやればわからない」という状況なんだからな
475(1): 2018/11/07(水)00:57 ID:JZV5z18S(2/11) AAS
>>474
レスありがとうございます。
＞Dockerでサービスが起動するコンテナを作ってあとはDockerに
＞OS起動時に、そのコンテナを起動してもらえばいいだけ
ソースで提供されているプログラムをDockerコンテナで使いたい場合、
具体的にどうすればいいでしょうか。
コンテナに入ってから、
コンパイルすることしか想像できない初心者です。
476(2): 2018/11/07(水)01:11 ID:v7o9U8jP(2/12) AAS
>>475
Dockerfileを使ってビルドするんだよ
コンテナの中に入るのは、ビルドがおかしいが原因がよくわからないとかで
調査するため。手作業でコンパイルとかしない
単純にDockerコンテナ内でビルドすると時間がかかったりイメージサイズが膨れ上がったり
するから工夫が必要なんだが、とりあえずそれは置いといて、一番単純な方法だ。
まずDockerfielを書く。Dockerfileには基本的に次のようなことを書く
・FROMでどのディストリをベースにしたイメージを作るのかを書く
・RUN（RUN yum〜とか）でイメージの中にコンパイルをするのに必要なパッケージを入れていく
・ソースコードをコンテナの中に配置する
（コンテナの外にあるソースをコピーしたりgitでcloneしたり、場合によってはボリュームを使う）
・プログラムをビルドする
・ビルドされたプログラムを起動するためのCMDやENTRYPOINTを書く
これで、ソースコードからビルドしたプログラムが入った
Dockerイメージが出来上がる。
あとは、dockerコマンドやdocker-composeなどでこれらを起動すれば良い
477(1): 2018/11/07(水)01:21 ID:v7o9U8jP(3/12) AAS
>>476で書いたように、単純な方法を取ると、
アプリを起動するのに必要ないビルドツールのせいで
イメージサイズが大きく膨れ上がる。
レイヤー（例えばRUN）毎に差分が保存されるため
ビルドが終わってから削除してもイメージサイズは減らない
（一つのRUNの中ですべてを行う方法があるが、
キャッシュも使われなくなるのでイメージのビルド時間が伸びる）
こういう場合に使うのが multi stage build
アプリを使うためには、アプリの実行ファイル（とランタイム環境）さえあればよいので、
ソースコードから実行ファイルを作る所までをビルド専用イメージで行う
そしてその実行ファイルをコピーして使う別のイメージ（ビルドツールなし）を作るという方法
478(2): 2018/11/07(水)01:21 ID:JZV5z18S(3/11) AAS
>>476
丁寧なレスをいただき、感謝いたします。
ありがとうございます。しかし、疑問が／／／
環境構築は手探りではダメで、
ビルドなどを含む全ての環境構築手順を、
スクリプト化できていないとダメなようですね。
Dockerfileでも、yumコマンドが扱われていることから、
ログインしてビルドコマンドを手打して動作確認するという従来の方法と比べて、
何が本質的に違うのかなと素朴に疑問です。
どうしてわざわざ、Dockerイメージづくりを自動化しなければいけないのですか。
できたイメージはtarで持ち運ぶつもりでいます。
479: 2018/11/07(水)01:25 ID:JZV5z18S(4/11) AAS
>>477
脹れ上がりですね。
＞ビルドが終わってから削除してもイメージサイズは減らない
知りませんでした。ありがとうございます。
英文ですが、さっきこれを見つけたところでした。
外部ﾘﾝｸ:stackoverflow.com
勉強します。丁寧なレス感謝いたします。
脹れ上がり防止と、
dockerfileによるイメージ作成の自動化が焦点になっているという認識であっていますでしょうか。
ありがとうざいました。
480(1): 2018/11/07(水)01:29 ID:v7o9U8jP(4/12) AAS
>>478
> 環境構築は手探りではダメで、
> ビルドなどを含む全ての環境構築手順を、
> スクリプト化できていないとダメなようですね。
Dockerfileを手探りで書けばいいじゃん。
FOROM deban
COPY ソースコード
RUN yum install パッケージ
RUN ./configure
とか書いてビルドして、あれぇ？ビルドできないなぁとかなったら
FOROM deban
COPY ソースコード
RUN yum install パッケージ
RUN yum install 足りないパッケージ
RUN ./configure
とかしていくんだよ。そうすれば、RUN yum install パッケージが
終わった段階のキャッシュの続きから実行されるから、
手探りでやってるのと大差ない作業になる
最後にyumとかでまとめておしまい
481(1): 2018/11/07(水)01:30 ID:v7o9U8jP(5/12) AAS
まあどうしてもわからないなら、コンテナに入りつつ
ビルドしていって試してもいいけど、最終的には
Dockerfileにビルドするためのコマンドを書く
482(1): 2018/11/07(水)01:30 ID:JZV5z18S(5/11) AAS
>>474
＞Dockerでサービスが起動するコンテナを作ってあとはDockerに
＞OS起動時に、そのコンテナを起動してもらえばいいだけ
ソースのreadmeは、Dockerコンテナを想定していないです。
すると、dockerコンテナ内で、systemctl enable serviceをセットして、
コンテナの起動によってそのサービスが起動するようにするしか私には無理そうです。
とすると、privilegeとか、なにか別の特権を与えてコンテナを起動して、
仮想マシンみたいにコンテナを動かすしか手が見つからないんです。
483: 2018/11/07(水)01:34 ID:JZV5z18S(6/11) AAS
>>480
＞そうすれば、RUN yum install パッケージが
＞終わった段階のキャッシュの続きから実行されるから、
＞手探りでやってるのと大差ない作業になる
続きから継続されるという仕組みがいまひとつピンとこないんですが、
知らなかったです。書籍も読んでいるんですが、あまり実践的ではないものが多いように思います。
最後にyumとかでまとめて御仕舞いというのは、
ワンライナーでかけるところはまとめて、dockerfileを作れということですね。
484(2): 2018/11/07(水)01:36 ID:v7o9U8jP(6/12) AAS
>>478
> Dockerfileでも、yumコマンドが扱われていることから、
> ログインしてビルドコマンドを手打して動作確認するという従来の方法と比べて、
> 何が本質的に違うのかなと素朴に疑問です。
Dockerは動作確認するためのツールじゃねーし。何かを作るためのもの。
その何かっていうのはDockerイメージでありそこから起動するDockerコンテナ
そのDockerイメージやDockerコンテナを作るために、最終的にDockerfileを書くんだよ。
Dockerイメージ = 実行ファイル
Dockerコンテナ = 実行ファイルを起動したもの
と考える
アプリの実行ファイルの中にデータファイルを作成しないのと同様に
Dockerコンテナ・Dockerイメージの中にはデータファイルは置かない
つまり、Dockerコンテナ（イメージも）は壊してDockerfileから
作り直してもなんの問題もないわけだ
なんの問題もないし、実際にそうする。
485(1): 2018/11/07(水)01:36 ID:JZV5z18S(7/11) AAS
>>481
ありがとうございます。
ずっと、どうしてコンテナに入って作業してはいけないのかが、
謎だったんですが、入って作業するのもアリなわけですね。
ホッとしました。
486: 2018/11/07(水)01:40 ID:JZV5z18S(8/11) AAS
>>484
なるほど。
＞Dockerイメージ = 実行ファイル
＞Dockerコンテナ = 実行ファイルを起動したもの
とてもわかりやすい喩えです。
＞つまり、Dockerコンテナ（イメージも）は壊してDockerfileから
＞作り直してもなんの問題もないわけだ
＞なんの問題もないし、実際にそうする。
Dockerfileさえあればいいってことがよくわかりました！
＞アプリの実行ファイルの中にデータファイルを作成しないのと同様に
＞Dockerコンテナ・Dockerイメージの中にはデータファイルは置かない
ボリューム（あるいはボリュームを用いたデータ専用コンテナ）を使えってことですね。
487(1): 2018/11/07(水)01:43 ID:v7o9U8jP(7/12) AAS
>>482
> ソースのreadmeは、Dockerコンテナを想定していないです。
> すると、dockerコンテナ内で、systemctl enable serviceをセットして、
> コンテナの起動によってそのサービスが起動するようにするしか私には無理そうです。
無理じゃなくて調べろ。systemdを使わずにアプリを（フォアグラウンドで）
起動するやり方を調べろ。普通はその方法で起動する。
うん、だから、俺はDockerはインフラのためのツールと言うより
アプリ開発者のためのツールだって言ってるんだよ
インフラはアプリを作らない。だからDockerでアプリを起動しようと思ったら
そのアプリの起動方法を調べないといけない。よく知らないアプリの
起動方法やどこにどういうデータが保存されるかなんて調べるのは面倒だろ
仮想マシンでパッケージ使って起動すりゃいいんだよ。
パッケージ使ってりゃ依存関係とかディストリが解決してくれてんだろ
アップデートもやってくれるだろ
アプリ開発者の場合はアプリを作る。アプリ開発者ならsystemd使わない起動方法だって知ってる。
むしろsystemd使うほうが面倒。どこにデータを保存するかもわかってる。
アプリはディストリが用意するパッケージには依存したくない。アプリを動かすのに必要なものは全部管理したい
だからDocker使ってイメージを作るんだよ。あとはインフラにこのイメージ起動してって
ぽんと渡すだけでよくなる。
488(1): 2018/11/07(水)01:45 ID:v7o9U8jP(8/12) AAS
>>485
> ずっと、どうしてコンテナに入って作業してはいけないのかが、
> 謎だったんですが、入って作業するのもアリなわけですね。
> ホッとしました。
それを作業って言うのが謎。調査だよ。作業じゃない。
コンテナでやった作業（ではないもの）は全て破棄されるんだから
コンテナに入るのは調査するためだけ
489: 2018/11/07(水)01:53 ID:JZV5z18S(9/11) AAS
>>487
＞無理じゃなくて調べろ。systemdを使わずにアプリを（フォアグラウンドで）
＞起動するやり方を調べろ。普通はその方法で起動する。
目が覚めました！ありがとうございます。直接起動する方法を調べないと駄目ですね。
Linuxは柔軟ですね。（WindowsならSQL SERVERはフォアグランドで動かせなさそうだもの。）
いわば、クリスマスツリーの電飾から、一つだけ豆球を取り外して、乾電池につないで動かすようなもののように感じます。
＞うん、だから、俺はDockerはインフラのためのツールと言うより
＞アプリ開発者のためのツールだって言ってるんだよ
＞あとはインフラにこのイメージ起動してってぽんと渡すだけでよくなる。
>>484の喩えを使って言えば、
スーパーアプリみたいな感じなのかな。
＞アプリ開発者ならsystemd使わない起動方法だって知ってる。
冒頭でいいましたが、これはDockerと付き合う今の私に必要な言葉でした。
＞アプリはディストリが用意するパッケージには依存したくない。
＞アプリを動かすのに必要なものは全部管理したい
＞だからDocker使ってイメージを作るんだよ。
Dockerとは、解体、原点に戻れですね。
丁寧にご指南いただき、本当にありがとございました。
とても勉強になりました！
490: 2018/11/07(水)01:54 ID:JZV5z18S(10/11) AAS
>>488
よくわかります！
491(1): 2018/11/07(水)01:56 ID:v7o9U8jP(9/12) AAS
> アプリ開発者ならsystemd使わない起動方法だって知ってる。
っていうのは、
自分で開発しているアプリなら、systemd使わない起動方法だって知ってる
っていう意味無
アプリ開発者はすげーから、なんでも知ってるぜーって意味ではないので
492: 2018/11/07(水)01:57 ID:v7o9U8jP(10/12) AAS
訂正（意味無ってなんだよ？）
自分で開発しているアプリなら、systemd使わない起動方法だって知ってる
っていう意味な
493: 2018/11/07(水)01:59 ID:JZV5z18S(11/11) AAS
>>491
＞自分で開発しているアプリなら、systemd使わない起動方法だって知ってるっていう意味な
あー、よかった、そうですか。
ちょっと大変そうだと心折れかかっていました。
自分で作るプログラムならよく把握できていますものね。
494: 2018/11/07(水)02:08 ID:v7o9U8jP(11/12) AAS
MySQLとかデータを大切に扱う必要があるものは
どこにデータが保存されてるかとかもしっかり明記されてるから
（クラウド使えよって思うが）Docker化するのは比較的楽だけど
WordPressとかウェブアプリとか、どこに何を保存しているのか
よくわからんものを、Docker化しようと思うよなって
インフラ屋がせっせと既存アプリをDocker化してるのを見てると思うよ
お前それ、信頼できるの？記事データはデータベースに保存されるから大丈夫みたいだが、
アップロードした画像とかデータベースサーバーじゃなくて
ディレクトリに保存されるじゃん？ ちゃんと共有ストレージ使うようなってんの？
管理画面からプラグインの導入できるけど、プラグインははデータディレクトリじゃない所に
保存されてるよね？そっちの対応は大丈夫？とか気になってしょうがない
495(1): 2018/11/07(水)09:13 ID:MDpN/AEY(1/2) AAS
補足だけど、systemdはパソコンの起動時に自動的に起動させるのが主な役目だからDockerのコンテナでも
起動時に起動させるのにsystemdを使ってもいいんですよ。
そのためには起動コマンドを調べる必要があるってことです。*.serviceのファイルを作成するだけで
systemd管理はできますが、*.serviceには当然起動コマンドを書く必要があるので。
496(1): 2018/11/07(水)11:48 ID:v7o9U8jP(12/12) AAS
>>495
今の話は、Dockerコンテナの中でsystemd使うなって話な
Dockerはそういう用途で使うためのもんじゃないから
そんな事をしようとすると、ハマるんだぞ
追加権限が必要なのが何よりの証拠
497: 2018/11/07(水)12:15 ID:MDpN/AEY(2/2) AAS
>>496
あり、レス読み間違えてたわすまん。
Dockerで中身いじるとしたらgitで遠隔操作するか、DBの永続化ぐらいで対応するのが常套だけど、
コンテナ内ならsystemdじゃなくてSupervisorがdocker公式になかった？
498(2): 2018/11/08(木)00:22 ID:Ueh2RoXc(1) AAS
LXC, LXD（Linux Containers）だと、コンテナ内に入って、
アプリのインストールなど、環境構築できる
AWS でも使っている
499: 2018/11/08(木)03:09 ID:NV3KMhMa(1/2) AAS
>>498
Dockerと、Linux Containerとは、
何が大きく違いますか？
Dockerはネットワークやコンテナの管理が便利だけどなあ。
500: 2018/11/08(木)03:11 ID:NV3KMhMa(2/2) AAS
>>498
DockerもLinux Containerも、共にLinuxの独立分離機能を用いていると言うし。
501(1): 2018/11/08(木)03:29 ID:KwyGHPnO(1/3) AAS
使ってる機能が同じでも、目的のために最適化されたツールになってる
だから、なにが目的かを正しく理解する必要がある。
Dockerはアプリケーションを仮想化することで
アプリケーションに可搬性をもたせるのが目的
Docker化したアプリはどこでも動かせる
その目的のために使う道具
LXCやLXDだとそれをやるのはとても大変だろう？
502(1): 2018/11/08(木)06:56 ID:8m7pC1YT(1) AAS
外部ﾘﾝｸ:qiita.com
503: 2018/11/08(木)08:04 ID:AYcFG6pB(1/2) AAS
ありがとうございます。
>>501
LXCや、LXDだと、別のホストでは動作しないのでしょうか？
>>502
すみません参考になります。
504(1): 2018/11/08(木)08:33 ID:KwyGHPnO(2/3) AAS
> LXCや、LXDだと、別のホストでは動作しないのでしょうか？
頑張ればできるんじゃね？
とてつもなく頑張ればｗ
505: 2018/11/08(木)15:05 ID:Y2MwyzYh(1) AAS
18.09.0 が来た
506(1): 2018/11/08(木)15:36 ID:rbD7hoQI(1) AAS
>>504
とてつもなく頑張ればｗ
条件付きだがライブマイグレーションできる>LXD
507: 2018/11/08(木)18:42 ID:AYcFG6pB(2/2) AAS
>>506
マイグレーションが一番の魅力だから、
やっぱりDockerがいいなあ。
508: 2018/11/08(木)21:55 ID:y26ltpJb(1) AAS
OpenVZでdocker動くかもと見たんだか、ほんと？
上下前次1-新書関写板覧索設栞歴
あと 494 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.032s