◎正当な理由による書き込みの削除について:      生島英之とみられる方へ:

Docker Part2©2ch.net ->画像>1枚


動画、画像抽出 || この掲示板へ 類似スレ 掲示板一覧 人気スレ 動画人気順

このスレへの固定リンク: http://5chb.net/r/linux/1506574845/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

1login:Penguin 転載ダメ©2ch.net
2017/09/28(木) 14:00:45.18ID:/4TtIqGt
LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker
http://mao.2ch.net/test/read.cgi/linux/1374861492/
2login:Penguin
2017/09/28(木) 19:24:33.96ID:pP51x30K
もうLXCに依存してないんじゃ?
3login:Penguin
2017/09/29(金) 11:42:26.61ID:/O2TcHk2
そうだね
前スレからそのまま持ってきてしまったか
4login:Penguin
2017/09/30(土) 13:41:02.45ID:DWXPURAf
>>1
5login:Penguin
2017/10/05(木) 08:50:48.55ID:i7Czn2dk
>>1
6login:Penguin
2017/10/09(月) 14:16:55.78ID:XfEexTHm
本番系のマシンと、Docker動かしてるホストとで、カーネルのバージョンって
みなさんどこまで合わせてます?

うちはRHELで動いてる本番系と、それとコピーの総合試験環境があって、
そいつらはカーネルもパッケージもバージョン揃えてあるんだけど、
その手前の、コーディングとか単体試験とかをやるコンテナ動かすDockerのホストも
やっぱしカーネルのバージョン揃えるべき?
7login:Penguin
2017/10/11(水) 00:31:44.42ID:pRpQhrR6
>>6
うちは本番系から単体試験ホストまですべてカーネル揃えることにしてるよ

Docket導入前だったけど、errataレベルの違いでI/Oスケジューラだったかの挙動が変わったことがあってね

理想はどうあれ、揃えておきなよ
8login:Penguin
2017/10/12(木) 19:50:29.01ID:2wGdxaeV
本番系と、カーネルだけ揃えておけばいつでもコンテナ作れるっていうのが仮想マシンに対するDockerの大きな利点

カーネルをバージョンアップしてコンテナが壊れたんならさっさと作り直す、さっさと作り直せるように周辺の仕組みを整える、
消されて困るコンテナは作らない、他とカーネルを揃えられないコンテナも作らない、なんてことがDockerカンファレンスでも
強く言われてた
9login:Penguin
2017/10/24(火) 23:51:58.75ID:dIybMC7m
hoshu
10login:Penguin
2017/10/25(水) 00:04:46.37ID:G0dNcMaK
Arukas終わったしもう遊べる場所はないのかな
GCPは制限ありそうだし
11login:Penguin
2017/11/12(日) 21:27:42.49ID:uiCH3XRM
Linux板で言うことじゃないかもしれないけどWindowsでもHyper-Vで使えるようになってたんだな
Bash on UbuntuにDockerも使えてWindowsPC強制されて虐げられてもなんとかなるぜ
12login:Penguin
2017/11/12(日) 21:43:45.89ID:CsnX2d3s
>WindowsでもHyper-Vで使えるようになってた
Windows以外で使えるHyper-Vなんてあるの?
13login:Penguin
2017/11/12(日) 22:36:56.33ID:uiCH3XRM
VirtualBoxが不要ってことを言いたかった
14login:Penguin
2017/11/13(月) 01:31:56.29ID:6Li+kjAO
HyperV無しのWSLで動くようになる予定はあるのかな
MobyとかLinuxKitとか出てきたし
15login:Penguin
2017/11/28(火) 15:53:23.01ID:79aY/WPA
タグが<none>なイメージを削除するにはどうしたら良いですか?
普通に削除しようとすると、
Error response from daemon: conflict: unable to delete XXXXX(image ID) (cannot be forced) - image has dependent child images
※-fを付けても同じ。

docker rmi $(docker images -f dangling=true -q)だと、
"docker rmi" requires at least 1 argument(s).

そもそもdocker images -f dangling=trueは何も引っかからない。

"image name cannot be blank"
と出たこともありました。何のコマンドか失念。

このコンテナは起動もできません。
どうやったら削除できるでしょうか?
16login:Penguin
2017/11/28(火) 23:02:15.82ID:l6qc+Qst
docker imagesってやったらどうでるの?
17login:Penguin
2017/12/03(日) 18:48:03.66ID:zS+bJMf6
docker使うとこ増えたけど
アホって綺麗なサンプルいっぱいあるのになぜか設定ファイルグチャグチャ作るのな
結局構成管理出来ないだろ、あんなんじゃ
18login:Penguin
2017/12/03(日) 21:33:00.17ID:0hG1CDG4
Dockerで設定ファイル?何の話だ?
Dockerで構成管理?何の話だ?
お前なんか勘違いしてそうだな
19login:Penguin
2017/12/03(日) 23:00:47.39ID:+8H++mo7
まあ言いたいことはわかるよ
それだって秘伝のシェルスクリプトを書き足すよりはずっといいさ
20login:Penguin
2017/12/04(月) 08:15:53.87ID:5eeXMq5z
AWS Fargateってサービスがアマゾンからリリースされたらしいけど
それってなんなの?
21login:Penguin
2017/12/13(水) 11:04:20.12ID:ZUZ9fAW9
docker系の技術は日進月歩すぎるのでredhatやcentosのような枯れたOSで使うのはきついですよね?
色々入れたり設定が必要だし。
お勧めなディストリはやはりubuntuやfedoraなどですか?
22login:Penguin
2017/12/13(水) 16:46:00.16ID:4HtuxJmh
>>21
docker自体は日進月歩すぎるところがあるので、OSは枯れたモノを使うというのがベストプラクティス

fedoraでdocker運用するのって、fedoraのカーネル自体が不安定すぎて、コンテナ上げすぎると落ちたりするよ
23login:Penguin
2017/12/13(水) 23:30:05.47ID:CbAdTCk+
>>21-22
枯れたOSでよく話が通じるな?
対応OS書いてあるんだから、それ使うだけじゃん

https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/
Artful 17.10 (Docker CE 17.11 Edge only)
Zesty 17.04
Xenial 16.04 (LTS)
Trusty 14.04 (LTS)

https://docs.docker.com/engine/installation/linux/docker-ce/debian/
Buster 10 (Docker CE 17.11 Edge only)
Stretch 9 (stable) / Raspbian Stretch
Jessie 8 (LTS) / Raspbian Jessie
Wheezy 7.7 (LTS)

https://docs.docker.com/engine/installation/linux/docker-ce/centos/
To install Docker CE, you need a maintained version of CentOS 7. Archived versions aren’t supported or tested.

https://docs.docker.com/engine/installation/linux/docker-ce/fedora/
25
26

https://docs.docker.com/engine/installation/linux/docker-ee/rhel/#prerequisites
To install Docker EE, you need the 64-bit version of Red Hat Enterprise Linux 7 running on an x86 hardware platform, or s390x (IBM Z) architecture.

Dockerの古いバージョンならもう少し古いディストリでも動くかもな
24login:Penguin
2017/12/14(木) 02:05:22.37ID:j6ffG0Yu
俺、OpenSuseで使ってる変態。
25login:Penguin
2017/12/14(木) 09:58:33.91ID:RtRhmnJE
Redhat/CentOSはカーネル古いから新しいバージョンのdocker composeが使えないよ
26login:Penguin
2017/12/14(木) 13:39:44.17ID:A3qqyatV
>>25
そんな制限あったっけ?
どこかに書いてある?
27login:Penguin
2017/12/14(木) 16:57:21.98ID:c0bTjVEo
GUIいらないからホストOSも軽くて無駄がないalpineにするのが好き
ほとんど何もできないから逆に後腐れなく気軽に捨てて新しくできるし!
28login:Penguin
2017/12/14(木) 18:00:17.09ID:mi3pWGl2
俺はホストにはfedora atomic使ってるぞ
29login:Penguin
2017/12/14(木) 19:26:56.48ID:xIrkk8hS
なんかlinuxがいいものになったかのような錯覚をおこすわ
30login:Penguin
2017/12/14(木) 22:49:08.96ID:j6ffG0Yu
coreosで使ってるっていう生粋のドッカーはいないのか?
31login:Penguin
2017/12/15(金) 00:48:35.66ID:1RLgszdT
CoreOSはもうねぇだろ
32login:Penguin
2017/12/15(金) 05:01:05.33ID:gXJiZmqG
coreOSってalpine以上に使いにくくて何が良いの?って感じなんだけど何か取り柄はあるのかね
33login:Penguin
2017/12/15(金) 10:47:11.13ID:pk6RU5gE
RancherOSが出たときコレは来るかと思ったがそうでもなかった
34login:Penguin
2017/12/15(金) 11:38:23.07ID:Goys0rX2
雨後の筍のようにポコポコ出てくるな
はやく収斂してくれ
35login:Penguin
2017/12/15(金) 21:13:24.95ID:QXRMWfvA
そいつらがいずれ、どうにもつまらない理由で内輪もめを起こしてまとまらなくなり
あの機能はそちらにしかない、その機能はあちらにしかない、なんて状況となってる間に
OracleやMSに持っていかれる、というところまでがテンプレ
36login:Penguin
2017/12/15(金) 22:20:10.00ID:7toohCc2
誰かが早く僕の考えた最強Linuxを発表しないとな。
え、それが乱立してるって?
37login:Penguin
2017/12/17(日) 02:54:12.57ID:fi9E8CtD
BargeっていうのがDockerホスト用で最軽量・高速ブートをうたってるけど
これVirtualBox専用でノートPCとかには直接インスコできないのかな?

更新頻度は高いみたいだから物理マシンでも動けば最強候補じゃないかコレ
38login:Penguin
2017/12/17(日) 03:00:59.83ID:FdcUbRUW
それ完全にvagrant用では?
39login:Penguin
2017/12/18(月) 00:14:34.47ID:V88qic40
RaspberryPiで使えますみたいなことは書いてあるね
普通には使えないっぽいのは何か残念だな
40login:Penguin
2017/12/18(月) 08:24:13.84ID:5bGVyFGG
やっぱubuntu + kubernetesがいいのかな
41login:Penguin
2017/12/19(火) 12:43:18.15ID:Unb97h+7
これからはなんでもかんでもコンテナって時代になるのですかね?
自前でリポジトリをシコシコ築いてきたディストリベンダーも
もはややる意義を失っちゃったりするんですかね?
42login:Penguin
2017/12/19(火) 15:47:37.58ID:mHmneXcK
未だにコンテナとchrootの違いが理解できない
43login:Penguin
2017/12/19(火) 18:27:38.96ID:JOmZ8i6e
chはchangeの頭文字から取っているから
rootの変更って意味だろう
コンテナはOS内にあるけど完全に独立しているから

例えばある家族の家の中で、
親がroot
子供がchroot
ホームスティしてきた外国人娘がコンテナだ
44login:Penguin
2017/12/19(火) 21:21:37.08ID:qjPggouG
>>41
コンテナ使い出すと便利すぎてディストリあれこれこだわってたのが笑えてくるほどだね

そして指摘の通り、独自にバグ潰しとかやってる一番活発なリポジトリ持ってるところと
逆に古いツールを保守し続けてるところはもてはやされてるが、それ以外が意気消沈してる
二極化だな
45login:Penguin
2017/12/19(火) 21:29:10.23ID:qsrDOXqO
リソースが集中するのはいいことではあると思う
46login:Penguin
2017/12/20(水) 01:46:37.73ID:W5Cyms8a
パッケージ管理ツールをLSB前提でpythonやperlで書いてたところは
それが原因でコンテナイメージのサイズをある一定以下に削減できなくてイーッてなってた

かと言ってパッケージマネージャーは各ディストリのシステムに根深く食い込んでるから
切り離そうにも切り離せない・・・最近じゃsystemdの呪縛もあるだろうし

でもまさかパッケージを単品ごとにインスコする日が来るとは誰も思ってなかったんだよな結局は
47login:Penguin
2017/12/20(水) 08:11:34.55ID:XbCsAUuJ
コンテナってもっと早く登場しても良かった気がするんだが
技術的にはホスト型ハイパーバイザ型の仮想化よりも簡単なんじゃないの?
48login:Penguin
2017/12/20(水) 09:16:28.83ID:G/qWb3nN
そりゃ日本での常識だな、
日本は金持ちだから高性能コンピューターが当たり前だけど
世界的にはようやく高性能コンピューターが普及してきた
ようやっとOS内にOSをおいても通常に使えるぐらいのPCが普及してきたんだ
49login:Penguin
2017/12/20(水) 11:24:05.90ID:XXomYUaW
それはひょっとしてギャグで言ってんのか
50login:Penguin
2017/12/20(水) 15:46:11.75ID:ZRehS3G5
コンテナは昔からあっただろ
Linuxに来るのが遅かっただけで
51login:Penguin
2017/12/21(木) 07:55:01.09ID:9tWXeT0T
user mode linuxはコンテナに入りますか?
52login:Penguin
2017/12/21(木) 20:10:57.04ID:K3jlwK7o
コンテナ内のプロセスがしんで終了しても自動でコンテナ再起動してくれるオプションがあった
コレ使えばわざわざプロセス死活監視用ツール起動しなくて良くなるのか
ちょっとスゴ杉ない?
53login:Penguin
2017/12/21(木) 20:41:31.20ID:dn2463i7
そんなもんsystemdに標準搭載されてる機能だろ
54login:Penguin
2017/12/24(日) 22:37:12.09ID:rLGBbeuy
dockerコンテナってホストOSのカーネル使ってるの?
どこもそう説明してるんだけど、ベースイメージにlinuxつかってその上にmysqlとか載せてイメージ化してるって認識だったんだが。
55login:Penguin
2017/12/24(日) 22:40:54.12ID:BfGqUwPY
ホストのカーネルを使っているという説明で合っているよカーネルの上で動かすカーネルとかもうそれVMじゃん
56login:Penguin
2017/12/24(日) 22:58:36.30ID:rLGBbeuy
>>55
ありがと。
そうなるとwindowsだとdockerインストール出来るけど、エンジンとかに工夫してあるのか

https://www.slideshare.net/zembutsu/docker-images-containers-and-lifecycle
ここの19ページめに、ベースイメージにイメージ層を載っけていくて記載あるけど、
これは間違ってるの?
57login:Penguin
2017/12/24(日) 23:14:23.88ID:jQND+IMW
http://www.publickey1.jp/blog/17/dockerlinuxkitlinux_subsystemdockercon_2017.html
こういうのじゃね?
58login:Penguin
2017/12/24(日) 23:22:26.32ID:rLGBbeuy
>>57


https://github.com/docker-library/mysql/blob/6c414e7f38c2079c7193beae5dc7c34ee46cd6e7/8.0/Dockerfile
mysqlのdockerfileだと FROM debian:jessie ってあるけど、
これはどうなの??
何かこんがらがってきた。
sshで入れるし、やっぱ根底はlinux立ち上がってるのか?
59login:Penguin
2017/12/24(日) 23:52:48.02ID:FG7A/gM3
おい、素人同士で勝手に話をすすめるなw

>>55
> カーネルの上で動かすカーネルとかもうそれVMじゃん
VM=仮想マシン=マシン(ハードウェア)を仮想化してないならVMにはならない

>>54
> dockerコンテナってホストOSのカーネル使ってるの?
そもそもホストとかゲストとかいうものがない

Linuxっていうのはカーネル(https://www.kernel.org/ で配布しているやつ)に
DebianやらUbuntuやらRedhatなんかが、いろんなアプリをセットにして配布してる

カーネルは基本的に汎用。だから同じカーネルを使っても
DebianやCentOSなんていう別のディストリが作れる

さてパソコンにDebianをインストールしたとする。そこにはカーネルといろんなアプリが有るわけだが
Dockerで作ったDockerコンテナはこのうちカーネルだけを利用する。

例えばFROM debian:jessieであれば、debian:jessieのディスクイメージを使うと考える
そのディスクイメージにはもしかしたらカーネルのバイナリも含まれてるかもしれないがそれは使わない。
パソコンにインストールしてあるカーネル + FROMの元になったディスクイメージ を使ってアプリを動かす

そんなもんだから、Debianをインストールしていたとしても、UbuntuやCentOSのディスクイメージを使うこともできる
60login:Penguin
2017/12/24(日) 23:57:01.81ID:FG7A/gM3
パソコンにインストールしたカーネルを使う。
そこで疑問になるかもしれない。

幾つものDockerコンテナが同じカーネルを使っているとしたら
psコマンドでプロセス見た時、他のコンテナのプロセスまで見えてしまわないのか?と

そこで出てくるのがLinuxカーネルに搭載されたコンテナ機能
この機能によって各コンテナは別々に隔離されることになる

同じカーネルを使っているというのに、それぞれ別々の環境を持っているようにみえる
ファイルシステム空間を分離したり、プロセス空間を分離したり、
メモリ空間を分離したり、ネットワーク空間を分離したり
ありとあらゆるものを分離して独立した環境を作り出している

それが大変な作業だった
61login:Penguin
2017/12/25(月) 00:07:51.54ID:132x0Uuj
さて、ここまではパソコンにインストールされたものがLinuxの場合だけど
WindowsやMacOSはどうなっているのか?

コンテナ機能っていうのはLinuxカーネルが持っている機能だが
WindowsやMacOSはLinuxではない。
どうやってLinuxのカーネルの機能を使っているのか?

答えを言ってしまえばあたり前のことだが、WindowsやMacOSでは
裏で仮想マシンが起動していてLinuxがインストールされている

ちょっと前までの、Docker Toolboxと呼ばれていた時代はVirtualBoxを使っていた。
今のDocker for Windows および Docker for Macでは
WindowsではWindows標準のHyperVを
MacOSではMacOS標準のHypervisor Frameworkを利用したHyperKitを使っている

仮想マシンを使っていると言ってもDockerに最適化されており
Windows もしくは MacOS のCUIからdockerコマンドを動かすとちゃんと
使えるように構成されており、まるでLinuxと同じようにOSの上に直接dockerが
起動しているようにみえる。だけど実際は仮想マシン上で動いているので
Dockerの設定画面にはメモリをどれだけ仮想マシンに割り当てるかなどという設定が存在する
62login:Penguin
2017/12/25(月) 00:11:59.89ID:132x0Uuj
余談だがWindows 10ではWSLという仕組みによって
LinuxカーネルをNTカーネルでエミュレートしている

今ではLinuxカーネルを使っていないのにUbuntuが
Windows上で動作するようになっている。

もしこのWSLがコンテナ機能までエミュレートする完璧なものになったら
その時はWindowsでHyperVを使わずにDockerが動くようになるだろう
63login:Penguin
2017/12/25(月) 11:30:09.88ID:+uvKLng+
>>62
親切すぎて草
下手な記事よりわかりやすい
64login:Penguin
2017/12/25(月) 15:39:08.55ID:h9oxS0er
>もしこのWSLがコンテナ機能までエミュレートする完璧なものになったら

なるのかね?
最近MSがLinuxに擦り寄ってて気持ち悪い
65login:Penguin
2017/12/25(月) 23:01:24.32ID:gZwRVfZh
>>62
帰ってきたらすごい丁寧なレス来てたっ
ありがとうございます

> 例えばFROM debian:jessieであれば、debian:jessieのディスクイメージを使うと考える
> そのディスクイメージにはもしかしたらカーネルのバイナリも含まれてるかもしれないがそれは使わない。

https://github.com/aws/amazon-linux-docker-images/blob/10641478ad16c6f44b691dc41acfc221c7a7594f/Dockerfile
たしかにamazon linuxの中見ると、コマンドとかは設置してるけど/boot のカーネルとかは置いてなかったわ

windows, macも結局裏では仮想化されてたのね
色々わからなかった所が一遍にわかったわ!
66login:Penguin
2017/12/26(火) 01:41:07.93ID:SZApAg+E
>>59-62
これは永久保存レベル

Github上のissueでもWSLだけでLinuxコンテナ動かしたいって要望はかなり挙げられてて
MSスタッフからみんなの期待は認識してますってレスも付いてた
もしホントに実現したら世界が変わる!みたいな投稿もあって大げさだけどちょっと同意しちゃう
67login:Penguin
2017/12/26(火) 03:02:30.31ID:+n8uGZb5
>>59-62を書いた本人だけど、なんでこんなに喜ばれてるんだろう?w
WindowsやMacOSでDocker使ってる人にとっては常識だと思ったんだけどね

最近MacOSでDocker使ってる人なのかな?
昔はVirtualBoxのインストールが必要だし
今もWindowsならHyperVの有効化が必要
仮想マシンが使われてるのはすぐにわかると思ったんだけど

あと仮想化という言い方は良くない
色んな意味の仮想化があるから
68login:Penguin
2017/12/26(火) 03:07:47.91ID:+n8uGZb5
WindowsやMacOSで使った時のDockerのボリュームって謎だよね

例えばWindowsでdockerコマンド使った時、Windowsのディレクトリを
ボリュームとして指定すれば、dockerコンテナの中から見える

Linuxでは当たり前の動作だけど、WindowsやMacOSでは仮想マシンで
dockerが動いてるのだから、単純に考えれば仮想マシンの中にボリュームができるはず

まあホストOSのディレクトリを仮想マシンのディレクトリにマッピングしてるんだろうけど
Docker for WindowsやDocker for Macではそういうことを感じさせない作りになってる
69login:Penguin
2017/12/26(火) 10:06:07.39ID:4aRFRiu5
vagrant入れて色々弄ってた後にdockerやったから全然気付かなかった
職場macで家はwindowsで、両方vagrant入れてたしね

ネットで調べても、その手の情報全然見なかったよ
本読んで勉強しろって話なのかな?
70login:Penguin
2017/12/26(火) 11:22:56.05ID:pkkjJJya
>>67
自分は初心者なのでナイスな解説に出会えてラッキーでした
ありがとう
71login:Penguin
2017/12/26(火) 12:31:53.02ID:KRPyxQju
俺も最近、Docker for Windows入れてみてたばかりなんで、HyperVが必要な理由とかが分かって参考になった
72login:Penguin
2017/12/26(火) 23:42:23.56ID:+n8uGZb5
> ネットで調べても、その手の情報全然見なかったよ
> 本読んで勉強しろって話なのかな?
そうなんか? じゃあなんで俺知ってるんだろう?w
もう3年ぐらい前から触ってるからなぁ。当時はWindows使っていたし(今はMacOS)

まあ普通DockerってLinuxで使うもんな。Dockerの解説といったら普通Linux上の話だし
WindowsやMacOSでどうやって使えるようにしているのかまでは関係ないか

じゃあおまけでもう少し仕組みの話を。
73login:Penguin
2017/12/26(火) 23:58:14.94ID:+n8uGZb5
Dockerっていうのはクライアント・サーバー型の設計になってる
つまり通常端末から実行しているdockerコマンドとサービスとして実行する
dockerサーバーが存在する(紛らわしいことにどちらもdockerコマンド)

サーバーの方のdockerは説明したとおりWindowsやMacOSでは仮想マシンなしには動かない
だけどクライアントはWindowsやMacOSでも動く
(dockerはgoで作られておりマルチプラットフォームになってる)

クライアントーサーバー型ということは、ようするにdockerサーバーを
リモートのLinuxで動かしていて、手元のWindowsでdockerコマンドを叩いて
接続するということができる。ちなみにdocker buildを実行すると手元のDockerfileやDockerfileと
同じディレクトリにあるファイルを全てリモートに送信してDockerイメージをビルドしている
(なので手元にごみファイルがあると遅くなるよ = dockerignoreの話につながるが省略)

使い方の一つとしてあちこちのLinuxサーバーでDockerサービスが動いていて
手元から接続先を切り替えて操作するというものがある
この時に使うのがdocker-machineで環境変数DOCKER_HOSTなどを管理する機能がある

Linuxでローカルのdockerサーバーに接続するときはsocket経由で接続するんだが
Docker Toolboxの時代ではTCPで接続するためにWindowsやMacOSXではdocker-machineが必要だった

でも最新のDocker for WindowsやDocker for Macではdocker-machineが必要なくなっている
どういう仕組みになってるんだろうね?w
少し前の手順を見るとdocker-machineがでてくると思うがローカルのDockerに接続するだけなら忘れていい

今はWindowsでもMacOSでも、ローカルのDockerに接続するときはTCP通信を使っていない(はず)だけど
WSL(Linux用Dockerサーバーは動かない)環境から、dockerクライアントのLinux用バイナリを使って
HyperV上で動いているDockerサーバーに接続するときは、TCPでつなぐ必要がある。その時に必要になるのが
「Expose daemon on tcp://localhost:2375 without TLS」というやつ。詳しくはぐぐってくれ

もう一つ思い出したが、Docker for WindowsはHyperVで動いているのでVirtualbBoxとは同居できない
vagrantを使うのならVagrant+VirtualBoxではなくVagrant+HyperVで使う必要がある
74login:Penguin
2017/12/28(木) 15:12:36.60ID:LWC+fC47
>>73
勉強になります

最近はOS、仮想化、dockerと色々と入り乱れて全体像を理解するのに苦労するなぁ
ま、所詮パンピーですから
75login:Penguin
2017/12/28(木) 17:00:45.45ID:+qKarqEU
dockerとkubernetes使いこなせないと時代遅れになるぞって言われたけど
一般の開発者がkubernetesを必要とするシーンってどのくらいあるのかな
dockerは問答無用で便利だけど
76login:Penguin
2017/12/28(木) 23:05:22.59ID:BIGMxhMF
dockerとkubernetesの間にクラウド(aws、gcp等)があるね
クラウドを使わなければkubernetesはでてこないだろう
ローカルでのサービス開発用途であればdocker-composeで十分だし

kubernetesはなんかクラウドの上でクラウドを作ってる感じで、
将来的には、いろんなクラウド会社の共通インターフェースに
なるんじゃないかって思ってるけど、今は各社のクラウドのサービスに
kubernetesが対応しきれない感じ。だって自社のGCPすら完璧にコントロールできないもの

例えばオートスケールしたいならkubernetesを使わないで直接クラウドの
機能のオートスケールとかした方がいいんじゃないかな

なぜならkubernetesの場合コンテナのオートスケールになるわけだけど
起動しているVMの中でコンテナをオートスケールするだけなので
VMの数もオートスケールしないとコストは下げられないから

kubernetesを使っても頑張ればコストを下げられるオートスケールは
実現できるんだろうけど、コンテナとVMの二重のオートスケールが実行されて
少数のコンテナだと多分不安定になりそう。何十台レベルで常時コンテナが
起動してる状態じゃないと安定させられないんじゃないかな?

それが将来はコンテナのオートスケール = VMのオートスケールになるんじゃないかって思ってる
で最終的にはVMを使う=裏で勝手にkubernetesが動いてる時代になるんじゃないかな
そうなってくるとkubernetesは確かに必須。だけど意識しない状態になってると思う

でも個人的にはkubernetesの方向じゃなくて、クラウド自体がコンテナに
直接対応してくれる方を望んでるけどw(例えばGCEは起動するコンテナをデプロイできるようになった)

kubernetesはバージョンが勝手にアップグレードする(GCPの場合)ことを考慮しないといけないのと
kubernetesを動かすだけで各VMで1.5GB以上のメモリを使用するのが気に入らない
77login:Penguin
2017/12/29(金) 12:41:26.85ID:S/CsVkMC
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

PTHNS6LLYQ
78login:Penguin
2017/12/30(土) 19:21:43.13ID:kIwYFCo/
kubernetesはほぼ全部の業界大手が参画してるけど
そんでもコケるってことあるんかな
いやまぁ莫大な金が動くインフラ業界だからねぇ
79login:Penguin
2017/12/30(土) 21:07:01.76ID:/wpJUWvV
Docker swarmが本命じゃないの?
80login:Penguin
2017/12/30(土) 23:02:49.87ID:R3GCT2Hw
>>79
もうフェードアウトフェーズだよw

DockerもついにKubernetesをネイティブでサポート、Swarmの併用も可能
http://jp.techcrunch.com/2017/10/19/20171017docker-gives-into-invevitable-and-offers-native-kubernetes-support/

しばらくはswarmでもできる!とかやるだろうけど
次第にフェードアウト
81login:Penguin
2017/12/30(土) 23:41:06.85ID:4E+qMbRD
小規模ではdocker-compose一択って事でおk?
82login:Penguin
2017/12/31(日) 03:26:38.05ID:AHTq9Vf1
小規模っていうか、1台のマシンの場合って考えてるよ
開発用メインでdocker runのオプションを指定するのが
面倒になった時w
83login:Penguin
2018/01/18(木) 10:27:56.69ID:edyLm1wn
Docker toolboxの最新版(18.01.0-ce)を入れたら何故かdockerのデーモンに接続できなくなったけど
VirtualBoxのGUIから仮想マシンを止めたら直った

docker-machine restartは効果がなかった
84login:Penguin
2018/01/18(木) 17:40:21.34ID:G+DL28hG
なんでvirtualbox?
85login:Penguin
2018/01/18(木) 18:22:49.70ID:HcoLdHLc
Docker toolboxってwin/mac上にlinux走らせてその上で更にdockerしてるからね
86login:Penguin
2018/01/18(木) 21:17:36.99ID:ZKzLgYJR
いつの話?
87login:Penguin
2018/01/18(木) 23:21:47.35ID:oYgm6+gm
誰もがWindows Proを使えるわけじゃないからなぁ
VirtualboxベースのDocker toolboxはまだ必要意義は大きい
88login:Penguin
2018/01/30(火) 15:24:33.94ID:qZpjgluz
Hyper-VはProfessional以上必須なのか。
リモートデスクトップサーバ使いたいから、"わざわざ"Professionalのライセンス
にしてるけど、Docker for Windows (Hyper-V)を使うために必要ってのは微妙。
89login:Penguin
2018/01/30(火) 16:34:53.53ID:VSfpjLUl
Docker使ってるとKubernetesしたくなってきてKubernetes on Atomic Host on Hyper-Vとか組みたくなるしへーきへーき
90login:Penguin
2018/01/31(水) 02:46:07.43ID:Y/TJiD1T
>>88
そういう人のためにDocker Toolboxというのがある
91login:Penguin
2018/02/01(木) 04:43:55.93ID:oMuXW2h/
coreOSがRedHatに買収された
92login:Penguin
2018/02/02(金) 08:59:37.20ID:yFWv8+qQ
CoreOSはDocker利用を想定してたけどコレジャナイ残念OSだったので次はRancherOSあたりに期待してる
93login:Penguin
2018/02/03(土) 13:01:31.67ID:3HQCIEUi
>>91
ヤフーの記事が、港のコンテナヤードの画像使ってて混乱したわw
94login:Penguin
2018/02/03(土) 15:14:06.84ID:TzIPoha8
クジラの方のコンテナって言えば通じる
95login:Penguin
2018/02/05(月) 13:34:29.22ID:k5aVtYPL
コンテナをビルドするとき Dockerfile 内で

RUN yum list

した結果を、ホスト側に残したいんだけど、なんか良い方法ないかな?
96login:Penguin
2018/02/07(水) 01:28:24.21ID:G933ziiv
>>95
Debian 使いだから勘違いしてる可能性が高いけどこういう感じで tee とかリダイレクトじゃダメなの?

$ cat Dockerfile
FROM centos

RUN yum list installed | tee yum.list
$ docker build -t yumlist .
~~snip~~
$ docker run --rm yumlist head -n5 /yum.list
Loaded plugins: fastestmirror, ovl
Installed Packages
acl.x86_64 2.2.51-12.el7 @CentOS
audit-libs.x86_64 2.7.6-3.el7 @CentOS
basesystem.noarch 10.0-7.el7.centos @CentOS
97login:Penguin
2018/02/08(木) 17:41:54.10ID:lNZDnl+7
>>96
便利なやり方が無いかなーと思って。
一度起動してその出力を回収する方法しかないね。
98login:Penguin
2018/02/14(水) 02:35:31.11ID:XB7JYlAs
/var/lib/docker/tmp
/var/lib/docker/containers
→単純にtmpfsにできる

/var/lib/docker/overlay2
→ここをtmpfsにすると再起動で空になったとき整合性エラーでコンテナが起動できなくなる
→かと言ってtmpfsをupperとしてoverlayfs化しても別エラーが出る(恐らくlower側のハードリンクが作れなくなるため)

/var/lib/docker全体をtmpfsにすれば整合性もハードリンク問題も解決するけど
消費メモリが増えるのとanything-sync-daemonとかでバックアップの手間も増える
システム再起動後にコンテナ自動起動しないならsync不要だけどイメージダウンロードからやり直しになって鬱陶しかった
99login:Penguin
2018/02/15(木) 00:59:03.05ID:m3isa15O
☆ 現在、衆議員と参議院の両院で、改憲議員が3分の2を超えて
おります。総務省の、『憲法改正国民投票法』、でググってみてください。
国会の発議はすでに可能です。日本の、改憲を行いましょう。
平和は勝ち取るものです。お願い致します。☆☆
100login:Penguin
2018/02/15(木) 12:06:04.40ID:2MLB8/h1
>>98
その問題は /var/lib/docker 以下が ext4 なら、fstab でマウントオプションに commit=300 とか付けると結構な対策になる

短命コンテナをバンバン使い捨てるケースで .../docker/overlay2 にゴチャゴチャ置かれても
sync 前にすぐ消えたファイルやディレクトリは単に無視されてディスクには書き戻されなくなって安心
デフォの 5 秒だとちょっと早すぎるんだよな
欠点はもちろん不意の電源ダウンで指定秒数ぶんだけデータロストする可能性があることだけど
ノートだったり UPS あったり、吹っ飛んでもいいや的な状況なら sync-daemon 系も不要だから楽

俺は USB メモリだけで運用してると 1 年ちょっとで寿命が来て色々と試行錯誤の後
Arch のフォーラムかどっかに書いてあったこのシンプルな方法に落ち着いた
101塩水 ◆1FrMT.vzQQ
2018/03/11(日) 02:24:38.22ID:hSBnN7Ry
dockerfile使わずにAnsibleでコンテナ構築してる人居ます?
物理で構築してたPlaybookのTarget SectionにDocker使うよって一行追加すれば使えるし(厳密には使えるようにするまでに色々設定は必要だけど)、
仮にコンテナのデファクトみたいなものがDockerじゃなくなっても最悪SSHで接続さえ出来れば流用できるからこのやり方良いなと思ってるんどけど。
102塩水 ◆1FrMT.vzQQ
2018/03/11(日) 02:25:38.04ID:hSBnN7Ry
スマホのフリック入力慣れないな。。
103塩水 ◆1FrMT.vzQQ
2018/03/11(日) 02:32:17.59ID:hSBnN7Ry
クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。
昔はVM作り直したり、スナップショットから復元したりしてたけど、今はそのマウス操作すら煩わしくなってしまってる。
104login:Penguin
2018/03/11(日) 02:47:30.63ID:FdJN57de
>>101
使っていませんw

ansibleを使ってDockerイメージを作ると、Dockerのキャッシュが
効かなくてイメージ作るの遅くなるでしょ?その問題もう解決したの?
あとansible使うならイメージにpythonインストールされてないとダメなんだよね?
Dockerはalpineとかpythonすら入ってないイメージをベースとすることも有るからなねぇ

君にとっては役にたたない話かもしれないど、どうしてansible使おうと思ったのか?
質問していい? >>101にも書いてあるけど他のコンテナに乗り換えたいときのためだけ?

俺は流用するならばシェルスクリプトが一番だと思ってるよ。
だってansibleで書いたYAMLって、ansible以外に流用できないでしょ?YAML書くのめちゃくちゃ手間だし
Dockerfileはシェルスクリプトにかなり近いので流用したいならDockerfileのままでいい
Dockerのイメージを作る時に限らず、なんでansibleなんか使うのか俺には理解できないよ
105login:Penguin
2018/03/11(日) 02:55:22.05ID:FdJN57de
>>103
> クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。

君を煽るわけじゃなく、そういうのをやってる人見てると、ワロスワロスだよw
なに無駄に苦労しちゃってるの?って思う
Ansibleは実行検証が必要なほど信頼できないってことだからね

Ansibleは理想としては、クリーンな状態にしなくても、冪等性とやらで
書いてあるとおりになるはずなんだが、その理想は破綻してる。
書いてない部分がどうなるのかは不定だからplaybookを変更した時に
クリーンな状態からやったのと同じ状態になるとは限らない

いやもちろんシェルスクリプトも同じだよ。でも検証時にサーバーに乗り込んで
手動でやったものがそのままコマンドにできる

playbookとして書いたものが、手動でやったことと同様のことを
行ってくれるか?という "二重の検証" は必要なくなるのさ
106塩水 ◆1FrMT.vzQQ
2018/03/11(日) 03:31:17.92ID:hSBnN7Ry
すごい煽られててビックリしましたw

>>104
用途は
1. 公式OSイメージからコンテナを作る
2. 良い感じのコンテナになってたらイメージ化する
という感じです。

「2.」のイメージ作るとこは最終段階で、そう頻繁に行う作業ではないの
仮にイメージ一つ作るのに数十分かかったとしても、自分の用途に関してはそれほど問題はないです。

Ansibleを使おうと思ったのは、昔は動いてたけど今は動くなくなっているようなPlaybookでも
失敗した箇所がピンポイントでわかるのでメンテする気が起きるからです。
人のシェルスクリプト読んだり、昔の自分のイキリシェルスクリプトを読解するのに疲れた
というのが大きいですね。

コンテナのイメージ化という事も検証の一環として行いますが、メインの用途は
コンテナでPlaybookを高速で検証して、検証した構築用Playbookを本番のVMに放つという感じです。
(本番に放つ前に一度は検証用VMにも放って確認はします)
107塩水 ◆1FrMT.vzQQ
2018/03/11(日) 03:33:10.76ID:hSBnN7Ry
今度は長文をPCから書き込んだらsage忘れた
2ch書き込みのブランクありすぎて色々ひどい。。
108塩水 ◆1FrMT.vzQQ
2018/03/11(日) 03:47:31.86ID:hSBnN7Ry
>>105
私も冪等性なんてあてにするものではないと思ってて、
Ansibleに限らず、そのほかのツールも検証してないものは信頼しないというのが私の基本スタンスです。
(特に、かなり昔に作った構築系スクリプトはそのまま実行して一回で動くとは思ってません。)

シェルスクリプトは構築コマンドそのまま列挙すればよいので便利なのですが、
例えばCentOSのOS基本設定入れてRuby入れてApache入れてアプリ入れて、
みたいな構築の場合、Role単位で過程を完全に分離できるので、管理がすごく楽なんです。

例えば構築が失敗したとき、シェルスクリプト場合
何でコケたのか、どこでコケたのか、というのを探すところから始める必要がありますが
Ansibleだとコケた場所とコケた原因のコマンドが一目瞭然なのでとてもメンテしやすいのです。
109login:Penguin
2018/03/11(日) 04:16:58.61ID:FdJN57de
あちこちで煽ってるけどようやくまともな意見を返す人が見つかったな

ふぉーん。ってことはシェルスクリプトでもどこで失敗したか
ピンポイントでわかれば問題ないってことじゃねーか。
あとは書き方が統一されていればいい
それなら解決可能な問題だな。っていうか俺の手元ではほぼ解決済みだ

> Role単位で過程を完全に分離できるので、管理がすごく楽なんです。
> Ansibleだとコケた場所とコケた原因のコマンドが一目瞭然なのでとてもメンテしやすいのです。
それもほぼ解決済みだ

シェルスクリプトで解決可能なたったそれだけの問題のために
Ansibleみたいな内部で何が行われているかわからない
重量系なブラックボックスツールをありがたがって使ってんのか
なんであれ(Ansibleとか)が無駄に重いソフトだってみんな気づかないんだろうか

> 2ch書き込みのブランクありすぎて色々ひどい。。
一体いつからここが2ちゃんねるだと錯覚していた?
110login:Penguin
2018/03/11(日) 04:26:48.50ID:FdJN57de
Ansibleがブラックボックスツールということの
意味がわからない人がいるかもしれないから
軽く説明しておいてやろう

まずお前らは環境構築をしているよな?それが仕事だ
その仕事をしている最中に、Ansible関連でバグとか
モジュールが対応してなくてうまく動かない自体が発生した。

それらをお前らすぐになおせるの?
pythonを知っていたとしてもまず無理だろ?
重量級のAnsibleをブラックボックスで使ってるからな

でも本来のお前らの仕事である環境構築は
手作業やシェルスクリプトですぐに解決できるだろ?
Ansibleの範囲でうまくできてりゃいいさ、だが
それができない場合、大きなボトルネックになってんだろ
111塩水 ◆1FrMT.vzQQ
2018/03/11(日) 04:40:50.71ID:hSBnN7Ry
なんかアドレスが5chになってる。いつの間に。。

>>109
言ってしまうと、自分のスクリプト力もあまり信頼してなくて、
今書いた複雑なスクリプトを一年後の自分が読めるとは思ってないのです。

ベテランの人が自分で方針を決めて数年後でもメンテできるように書いていれば
その人は問題なく使えると思うのですが、他の人はそれを読めるかどうかというところですね。

Ansibleのベストプラクティスに従っていれば、そんなベテランの腕がなくても
仕組みで自然とそのようなメンテがしやすい形にはなるのです。

ただ、
112塩水 ◆1FrMT.vzQQ
2018/03/11(日) 04:55:20.38ID:hSBnN7Ry
多少はやったことありますが、AnsibleのモジュールそのものをPython書いて修正するというのは敷居がけっこう高いですね。。
確かに、廃止されたりオプションが変わったり、変な挙動のモジュールもあります。
解決策はそのモジュールが使えてるAnsibleのバージョンを固定するか
最悪、shellやcommandモジュールでLinuxコマンドべた書きするかでしょうか。

ただ、shell, commandモジュールを使うと冪等性が担保できないので
非推奨なのですが、そもそも私は冪等性というものを信用してなかったりするので
自分の場合は特に問題なかったり。

Ansibleが用意しているモジュールがあるのにshellやcommandでやろうとすると
こっちのモジュール使えという警告が出て煩わしかったりします。
使えるモジュールは使うとシンプルにかけたり良しなに処理してくれたりと確かに便利ではあるのですが
さっき書いたように廃止や挙動が変更されるリスクもあります。

そこでdockerコンテナを使ったPlkaybookの高速検証が活きてくるという。
113塩水 ◆1FrMT.vzQQ
2018/03/11(日) 05:13:32.25ID:hSBnN7Ry
さらさらっと書いてますが、このようなdocker,ansible,Serverspecの環境を作るのはそれなりに大変だと思うので、
もしやるならばこの辺に詳しいインフラエンジニアに任せた方が良いかも。
114login:Penguin
2018/03/11(日) 11:20:29.98ID:FdJN57de
>>111
> 今書いた複雑なスクリプトを一年後の自分が読めるとは思ってないのです。
環境構築ごときでなんで複雑になるのかそこが不思議。
まず一つだけアドバイスするなら、設定はファイルの項目ごとに変更するのではなく、
設定ファイルをまるごとcopyすること。これで冪等性も担保される。

環境構築なんてファイルおいて数個のコマンド実行して大抵はこれだけで
終わるはずなんだが、なんで複雑になってるのか知りたいよw

冪等性を考えると前の状態を考慮する必要がでてくるので条件分岐なんかが出てくるが
Dockerだと最初から作り直しになるので関係ない
あんな大量のモジュールができてしまったのは、冪等性を考慮したことが根本原因かね?

> Ansibleのベストプラクティスに従っていれば、そんなベテランの腕がなくても
> 仕組みで自然とそのようなメンテがしやすい形にはなるのです。
細かいファイルに分かれていて、notifyとはhandlersとか使っていて、これどうなってるんだ?って頭を抱えたことが有るんだがw
単純にメンテしやすい形になればいいのかねぇ。詳しくは言えないがそれなら俺の手元では解決済みなんだ。

> Ansibleそのものの挙動はブラックボックスなところもあるかもしれませんが、
> 品質の担保はServerSpecのテストでやってます。
テストのためだけにRubyをサーバーに入れなきゃいけないってのもナンセンスだよなw
入れない方法もあるんだっけ?

> 何か問題があったらServerSpecのテストを足せば良かったりします。
> 手順書に確認手順を追加するよりテスト書いてgitで管理して必要に応じて実行する方が簡単で確実かなと思ってます。
俺は一言も手順書なんて言ってないんだよね。テストもシェルスクリプトでやればいいでしょ?当然gitで管理できる。

あとServerSpecでも同じくブラックボックス問題がある。ServerSpecでは一体何を調べてるんだって話だよ
例えばpackageでパッケージがインストールされているか調べられるが、パッケージの管理方法はディストリで違うはずだ
packageはAlpineのapkでも使えるのか?という質問に自信をもって答えられるのか?すぐにソース読みとけるのか?
(まあそこはコマンドが実行できればOKとするのが、やるべきテストだと思うけどさ)
115login:Penguin
2018/03/11(日) 11:22:42.29ID:FdJN57de
ServerSpec実行してOKがでればOKと信用すりゃいいんだろうけどさ、何をテストしているのかさっぱりわからん。
ServerSpec(というかrspec)というフレームワークはブラックボックスで良いんだが
肝心のテスト内容(matcher)で何をやってるのかは把握してなきゃだめだろ?

>>112
> ただ、shell, commandモジュールを使うと冪等性が担保できないので
Dockerや最近のImmutable Infrastructureではサーバ作ったら変えないので
ありがたいことに冪等性は不要になった。実行前は必ずクリーンな状態なのでね。

俺も冪等性は信頼してない。特にAnsibleとかブラックボックスなので。
ただしここではいわないが、冪等性に変わるアイデアを持ってる

> さらさらっと書いてますが、このようなdocker,ansible,Serverspecの環境を作るのはそれなりに大変だと思うので、
Dockerはともなく、ansible とか Serverspec だから大変なんだよ。
Serverspecとか今度はRubyいるだろ?


参考になった。まあ気にすんなよ。あんたを煽ってるわけじゃなく
ちょうどansible使おうとしてるやつがいたから、なんでか聞きたかっただけだ。
Ansibleとかほんとクソだって思ってるので

最初の質問にもう一度答えると
> dockerfile使わずにAnsibleでコンテナ構築してる人居ます?
つかわん。dockerなら冪等性いらないし、1コンテナで動かすものは極力シンプルにするので
構築内容は短くなる。逆にAnsibleを動かすための部分のほうが長くなる
116login:Penguin
2018/03/11(日) 11:30:56.88ID:FdJN57de
>>113
> もしやるならばこの辺に詳しいインフラエンジニアに任せた方が良いかも。
インフラエンジニアじゃないのか?俺も違うけどなw

インフラエンジニアじゃないけど、サーバー構築やらないわけじゃなく
まあやったりする。それぐらいはできる。

問題は、パッケージインストールした。設定ファイルも書いた。こんな感じでいいだろう。
で、自動化? まあやったほうが良いね。今やったことを自動化するだけだろ?


Ansible? YAMLで書くのか。
インストールしたパッケージを使うモジュールはどれ?
設定ファイルに書いたことに相当する項目はどれ?
ないんだが?新しい機能だから対応してねーのか?
結局commandでシェルスクリプト書くしかねーじゃねーか

みたいなな。

インフラエンジニアってなんであんなクソなもの平気で使えるの?
117login:Penguin
2018/03/11(日) 11:48:05.06ID:JbaTrnc+
オンプレでウォーターフォール、一度作ったマシンを後生大事に使い続ける、
そんなスタイルならDockerすら不要かと
118塩水 ◆1FrMT.vzQQ
2018/03/11(日) 15:33:16.62ID:hSBnN7Ry
> 環境構築ごときでなんで複雑になるのかそこが不思議。
社内のVMwareで作ったイメージを直接客先に入れられるならもっと簡単に作れるんですけどね。。
オンプレ上で直接構築する場合、内部やDMZなど環境毎にproxyやDNS、ntpやファイヤーウォールの設定が違ってたりするのです。
あと、WebサーバでIPアドレスだけ変えて後は全部一緒の設定にしたい場合は
Webサーバ分だけ設定ファイル作るんじゃなくて、テンプレート作ってIPアドレスだけ動的に変えて配布するとか。
便利です。

> あんな大量のモジュールができてしまったのは、冪等性を考慮したことが根本原因かね?
それも原因の一つかもしれないですが、基本は便利そうだからじゃないですかね?
私はRedHatの人ではないのでなんとも答えられませんが
「何でLinuxにはあんな大量にコマンドがあるんですか?」みたいな質問かなーと。

> 細かいファイルに分かれていて、notifyとはhandlersとか使っていて、これどうなってるんだ?って頭を抱えたことが有るんだがw
そうですね。サービスが再起動されるのが状態が変更された場合という事ですけど
何をもってサービスが変更されたとするかというのがわかりにくいかもですね。
私はこれ積極的には使ってなくて、serviceモジュールで明示的にサービス再起動してます。
基本的に冪等性は考えないスタンスの一言なのですが、使わない理由をあえて考えると
構築時はいくらどのタイミングでサービスを再起動しても本番に影響は無いのと、
稼働中のサーバのサービスを再起動する場合は明示的に確実に特定のタイミングで一回だけ再起動させたいからでしょうか。
119塩水 ◆1FrMT.vzQQ
2018/03/11(日) 15:34:04.20ID:hSBnN7Ry
> テストのためだけにRubyをサーバーに入れなきゃいけないってのもナンセンスだよなw
> 入れない方法もあるんだっけ?
Serverspecは私の知ってる限りのやり方ではRuby要りますね。gemですし。
サービスと関係なくある程度裁量で触れるステージング的なサーバがあれば
客に許可をもらってそこに入れるとか。。

> テストもシェルスクリプトでやればいいでしょ?当然gitで管理できる。
シェルスクリプトでテストが書けるのであれば良いと思いますが、
例えばリターンコードを確認して成功と失敗を判断して、、みたいなスクリプトを書くとすると
構築系スクリプト以上に大変な気がします。。

> ServerSpecでは一体何を調べてるんだって話だよ
何を調べれば十分かをこちらで定めて、それを満たしていることを確認するというスタンスにすれば良いと思うのです。
例えば「Rubyがインストールされていることを確認する」の場合packageだけで良しとするか、
commandでインストールしたコマンド実行後にあるべき出力結果が出てるかまで確認するかとか。
やろうと思えば手で実行できる範囲のテストはいくらでも追加できるので。

AnsibleやServerspecそのものがどうなってるかではなくて、自分が構築したサービスがちゃんと機能しているかを見ます。
こういう着眼点にすれば、将来もしAnsibleやServerspec以外の便利なソフトができても移行の判断がしやすかったりします。
120login:Penguin
2018/03/11(日) 15:53:28.62ID:FdJN57de
> オンプレ上で直接構築する場合、内部やDMZなど環境毎にproxyやDNS、ntpやファイヤーウォールの設定が違ってたりするのです。
> あと、WebサーバでIPアドレスだけ変えて後は全部一緒の設定にしたい場合は
> Webサーバ分だけ設定ファイル作るんじゃなくて、テンプレート作ってIPアドレスだけ動的に変えて配布するとか。
> 便利です。

それはAnsibleじゃないとできないことではないからなぁ


> 例えばリターンコードを確認して成功と失敗を判断して、、みたいなスクリプトを書くとすると
> 構築系スクリプト以上に大変な気がします。。

set -e
exists_file() {
 [ -f "$1" ]
}

check() {
 exists_file /var/file1
 package_installed mysql
 some_check
}

リターンコードの確認なんていらない。set -eしてるからリターンコードが0以外だとそこでストップする
(どこでストップするかがわかるようにしたいなら、単に関数の中でメッセージを出せばいい)
あとはこんな感じでいろいろヘルパー関数を作っていけばいいだけだと思うんだが?
ヘルパー関数は再利用できるから実質check() の中身を書き連ねるだけ。
121塩水 ◆1FrMT.vzQQ
2018/03/11(日) 16:11:14.24ID:hSBnN7Ry
>>116
>インフラエンジニアじゃないのか?俺も違うけどなw
元インフラエンジニアで今の職業は百姓です。田舎で野菜作ってます。

最初はshellやcommandで書いて、使えるモジュールがわかったらあとで修正するという方法もありかなと。
まあ、だいたいそのままで特に問題ないので放置されるのがデフォルトですが。

自動化のところまでは色々できたりするんですけど、
それを他の人に引き継ぐというのがものすごく難しいんですよね。。

k8sも挑戦して、環境構築できるPlaybook作ったりしたのですが
人に引き継ぐという事が難しくて頓挫しました。
自分で管理することはできても人に引き継ぐとなるとAnsibleやServerspecの比じゃなくくらいしんどかったので
k8s環境ぶっ壊してdocker-composeに戻しました。
(そもそも社内の開発環境にk8sは大げさすぎたということもあります)

> Ansible? YAMLで書くのか。
例えばChefの場合はRubyの知識が必要ですがYAMLは言えば設定ファイルを書くような感覚なので
インフラエンジニアにとっても比較的とっつきやすいかなと思ってます。
AnsibleでPythonを意識するような場合、複雑にやりすぎているケースがほとんどです。
Pythonの制約からなのか、変なところにカンマ入れないと動かないとかあったりしますが。
(インベントリファイルじゃなく直接ホストを一つだけ指定する場合など)

> インフラエンジニアってなんであんなクソなもの平気で使えるの?
Ansibleは自然とメンテナンスしやすい構造になるような仕組みになっているのが便利だからじゃないでしょうか。
学習コストと既存のスキルセットでできることを比較して学習した方がトータルで効率的になると判断したから使うというか。
逆に言うと既存のスキルセットで十分なことができてしまっていると学習コストを払うというほうに舵を切りにくかったりするかもですね。

私はAnsible、dockerは流行ってるから採用したのではなくて、
ある程度プライベートで遊んで便利そうだったから職場にも持ち込んだという流れでした。
122login:Penguin
2018/03/11(日) 16:12:01.95ID:FdJN57de
>>119
> > ServerSpecでは一体何を調べてるんだって話だよ
> 何を調べれば十分かをこちらで定めて、それを満たしていることを確認するというスタンスにすれば良いと思うのです。
> 例えば「Rubyがインストールされていることを確認する」の場合packageだけで良しとするか、
> commandでインストールしたコマンド実行後にあるべき出力結果が出てるかまで確認するかとか。
> やろうと思えば手で実行できる範囲のテストはいくらでも追加できるので。

そいう話じゃなくて

describe package('mysql') do
 it { should be_installed }
end

とかやってOKになった、インストールしているらしいことはわかった。

だがこのコードが何を根拠にパッケージがインストールされていると判断したのか?ってことだよ
dpkg -l の結果から判断しているだけなのか、それともパッケージに含まれるファイルが
既定の場所に有ることを確認しているのか、パーミッションまでチェックしているのか
それがわからんってことだよ。

もちろんソースコード見ればわかるだろうけど、Rubyの知識が要求される上に
こういうのって過度に汎用化されていて簡単に読み解けるとは思えないんだが
特に言語がDSLそのものではなく、DSLを作りやすいだけの言語だと、
DSLを作るために通常のプログラミングには用いられない
メタプログラミング的なコードが多用される傾向にある
123login:Penguin
2018/03/11(日) 16:38:27.85ID:FdJN57de
>>121
k8sはクラウドで数台~十数台以上のマシンが常時起動していて
何もしてないのに起動してるのはもったいない。かと言って事情があって落とすことも出来ない。
ってときにそれらの余剰CPUリソースをなにかに使うことは出来ないか?って時に
使うもんだと思うぞ。あと同じサーバーを複数起動させるという前提があってこそ使える

(コスト節約のために)サーバーをオートスケールさせるのはクラウドだけなら
比較的簡単なんだが、その中に更にk8sが入り込むとk8s自体にもオートスケールがあって、
まるでクラウドの中にクラウドが有るような感じで複雑さが増し、
k8sでPod(コンテナ)をオートスケールさせて、サーバーリソースが足りなくなったら
今度は仮想マシンをオートスケールさせるとかなって安定稼働させられる自信がない。

普通に開発環境はdocker-composeがいいよ

> 学習コストと既存のスキルセットでできることを比較して学習した方がトータルで効率的になると判断したから使うというか。
俺からするとAnsibleはChefよりはましだが、それでも学習コストが高くて、(Ansible学習前の)インフラエンジニアが
持っているであろう既存のスキルセットの応用が難しく、Ansibleを覚えてしまったとしても
なおAnsibleモジュールと格闘し続ける、効率的にならない道具だと思ってる。

まあ一言で言うと、もっといい方法が有るって話だ。これ以上はここでは言えないけどw
124塩水 ◆1FrMT.vzQQ
2018/03/11(日) 16:50:49.20ID:hSBnN7Ry
>> 122
今のmysqlがどんなpathにあって権限がどうなっているのかは知らないので
仮の設定確認ですが

describe package('mysql') do
 it { should be_installed }
end

に続けて

describe file('/user/bin/mysqld') do
it { should exist }
it { should be_mode 770 }
it { should be_owned_by 'mysql' }
end

と書けばファイルの存在や権限、オーナーが確認できます。
さらにグループも確認したい場合はbe_grouped_intoを追加するなどで
いくらでも細かなチェックは追加できるかなと思います。

確かにAnsibleと比べてServerspecはRuby色が強くて
とっつきにくいかもしれませんが、そういう書き方を覚えてしまえばあとは慣れるかなぁと。

そこまでの学習コストは確かにそこそこあるので、
Rubyとシェルスクリプトと、ちょっとPythonができて
システムを俯瞰して見ることができるインフラエンジニアが居た方がいいかなーとは思います。。
125login:Penguin
2018/03/11(日) 16:57:53.92ID:FdJN57de
> と書けばファイルの存在や権限、オーナーが確認できます。
それはただ単にメソッド用意されてるからだよねーとしか思えないんだよね

シェルスクリプトだってメソッドあれば
例えばこれみたいに書けるでしょ?

describe file '/user/bin/mysqld \
 -- should_exist \
 -- should be_mode 770 \
 -- should be_owned_by 'mysql' \
end
126login:Penguin
2018/03/11(日) 16:59:24.31ID:FdJN57de
なんか中途半端になったなw

describe file '/user/bin/mysqld \
 --should_exist \
 --should_be_mode 770 \
 --should_be_owned_by 'mysql' \
end
127塩水 ◆1FrMT.vzQQ
2018/03/11(日) 19:29:40.88ID:hSBnN7Ry
k8sはよっぽど仮想サーバに余剰があるか、もしくはGoogleやFacebookみたいに仮想化ソフトそのものがリソースの無駄と言い切って
物理サーバとコンテナだけでやるというクラスになると意義があるのかなぁとか思ったり。

開発や検証ではコンテナをガンガン使いますが、本番にコンテナ使うというのはどうもまだ怖いですね。。
壊れたら立て直せばよいWebサーバならまだ、、とは思いますがDBにコンテナ使うという事例みたときは
なかなかチャレンジングな事してるなと思いました。。

ただでさえコンテナは障害が発生したときにコンテナ側が悪いのかサーバ側が悪いのかの切り分けが
難しいのに、そこにさらにk8sが絡んでくるとなると。。

> シェルスクリプトだってメソッドあれば
確かにメソッドを自前で用意すればできると思います。
ただ、シェルスクリプトはちょっと記述を間違ったりすると事故になる可能性があるので
テストを流す前のベテランのレビューは必須だと思うんです。

Serverspecは基本的にどんな操作もサーバーの状態は変わらない(はず)なので
ベテランのレビューがなくてもとりあえず流しとく的に実行はしやすいかなと。
(私が今まで使った限りでは変な実行してサーバが壊れた、ということは無いです。
Ctrl+Cでキャンセルしてターミナルの表示がおかしくなるということはままありますが。)
128塩水 ◆1FrMT.vzQQ
2018/03/11(日) 19:43:24.47ID:hSBnN7Ry
こういう作業をAnsibleやServerspecでやろうとすると
コマンドが異様に長くなるのでラッパースクリプト書いたりするのですが、
シェルスクリプトはそこで今でも大活躍してます。
なんだかんだで便利なんですよねシェルスクリプト。
129login:Penguin
2018/03/11(日) 21:42:47.19ID:yaKRWAT9
Dockerfile に関しては冪等性なんていらないのでそのまま使う派
Ansible が便利なのはわかるけど、Dockerfile に関しては 1 のことをするのに
10 できる道具で頑張る感じがつらい。

Dockerfile 以外のセットアップに関してはマニュアルとか書き方とか面倒すぎるので
学習コスト払ってもシェルスクリプトは使わないで Ansible でも良いんじゃねって思う。
私にとってはトラブル解決時に 1000 行とかの自作のシェルスクリプトなんかより Ansible のコードを読むほうが楽。
まぁ、自分しか使わないシェルスクリプト100行ぐらいで済むものならどっちでもいいけどね。

インフラテストに関しては goss 使ってるな~。Rspec の記述や Ruby 入れるのだるいので。
goss は golang 製だからバイナリ置くだけだし、stdin つないでテスト渡せるので実行が簡単。
Yaml でかけて、機能が多すぎないのでテスト書くのもむっちゃ楽。
欠点は PullRequest などへの反応が鈍い、もともと作者が golang の勉強で作ったものなので設計が気になる(特に比較方法とか)

DockerImage のみのテストならば countainer-stracuture-test という google 製のものが出てきたのでこれも面白い
これに関しては、できたてなのでバグがかなり多い。新たなコミットのたびにバグができるw
テストできる機能は少ないが、docker engine 無しでイメージテストができたり、メンテナの反応も速いしコードも読みやすい。
今後ちゃんと出来上がれば化けるかも
130login:Penguin
2018/03/11(日) 23:36:05.79ID:gLOQBJNa
> 私にとってはトラブル解決時に 1000 行とかの自作のシェルスクリプトなんかより Ansible のコードを読むほうが楽。
> まぁ、自分しか使わないシェルスクリプト100行ぐらいで済むものならどっちでもいいけどね。

俺の観測ではシェルスクリプトが100行だと
Ansibleのコードは1000行って感覚なんだけどね
131login:Penguin
2018/03/12(月) 00:00:41.81ID:iAV7tz/N
大きな会社だと仮想サーバ一つ立てるのにいちいちインフラエンジニアにお伺い
たてないといけないけど、リソース多めのVM一つ作ってもらえばそこにdocker入れて
いろんなコンテナたててやりたい放題できるという。

4vCPU,8GBMem,100GBHDDあればデフォルト設定でコンテナ5くらいはいける。
もちろん検証用DBコンテナとか立てるときはMySQLのinnodb_buffer_pool_size小さめにしておくとか
ちょっとした工夫はいるけど。
132login:Penguin
2018/03/12(月) 00:09:31.95ID:0gO9Md9Y
やっぱりシェルスクリプトだとなんでそんなに
メンテナンス性が悪いものが出来上がるのか?
書くことはAnsibleとかわらんだろ(むしろ短く書ける)
と思ってるわけだが。

ふと気づいたがもしかしてシェルスクリプトで書く時に関数作ってないのか?
ただ単に上から下へとコマンドを書き連ねるだけ?

プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が
高くないように記述するもんなんだが、インフラエンジニアってのは
それができてないレベルだったりするの?
133login:Penguin
2018/03/12(月) 00:13:02.11ID:0gO9Md9Y
>>131
まあ会社が会社だとそういうことなんだろうけど

> 4vCPU,8GBMem,100GBHDDあればデフォルト設定でコンテナ5くらいはいける。
それ個人用に配給されてるPCレベルだよね?って思わなくもないw

うちは入社当時のMac Book Proの一番上当たりの性能
CPUは忘れたけど、16GBのメモリと、512GBのSSDだったかな?
134login:Penguin
2018/03/12(月) 01:17:08.47ID:iAV7tz/N
>>133
個人PCレベルというのは否定できないw
社員数多いとリソース配分が大変なんです。
HDDはシンプロでごまかして、vCPUもまあまあ割り当てられるとして、
メモリは慢性的に不足します。

個人のMacでそれだけリソースあるなら
ローカルPCにdocker入れて使えば良いですね。

その場合も個人的にはDocker for Mac使うんじゃなくてVagrantで立ち上げたLinuxVMにdocker入れて使います。
理由は何となくというか、その方が環境が汚れなさそうだからというか。
135129
2018/03/12(月) 01:34:06.50ID:cIbUTTA5
bash のスクリプトだろうと、Python だろうと golang だろうと関数は普通に使うね。

で、シェルスクリプト 100 行だと Ansible のコード1000 行ぐらいという感覚も正しいと思うよ。
実際は、500とか600 ぐらいだと思うけど。
Ansible の yaml だと 30 行くらいかな。

てか、コードが短く "も" 書けるのが嫌なんだけどね。
例えば、2つまでつなげるなら期待通りに動くから if を使わずに || や && でつないだりとかね。

私自身はもともと Perl からの出身だから、色々な書き方があって(TIMTOWTDI)
書き方によっては短く書けるのが楽しいとか良いと思う面はある。
ただ、コードゴルフをやるならまだしも、自分以外が見るコードは
そういうことをする余地がなければ無いほど良いと思ってる。

あと、shell も perl も(Cも)変数のスコープがデフォルトでグローバルなのが良くない。
ちゃんと動くからって、スコープ意識しない使い方のコード書かれてそれをレビューで指摘したり
そのために CI を準備したりとか考えたくない。
そういう点では python の pep とか golang の fmt/lint とか最高だと思ってる。

Dockerfile も「どれだけ削るか」などで人によって書き方がまちまちになってしまうんだけど、
普通は大規模にはならないし、出来上がるイメージをバイナリだと思ってちゃんと動けば
中身がどうであれとりあえずは良いのかなと思えたりするので結構好き。

「プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が高くないように記述するもんなんだが」
は可読性、メンテナンス性が高いようにじゃない?
136login:Penguin
2018/03/12(月) 01:36:17.28ID:0gO9Md9Y
> 「プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が高くないように記述するもんなんだが」
> は可読性、メンテナンス性が高いようにじゃない?

そのとおり「高くなるように」と書いたつもりだった
どうもGoogle IMEの調子が良くないんだよ。
特定のアプリで極端に変換が遅くなることが有る。
アプリ再起動したら直ったからメモリリークでもしてんのかな?
137login:Penguin
2018/03/12(月) 01:47:41.96ID:0gO9Md9Y
>>135
やっぱり理解できない。
何かしらの越えられない壁の
あっち側とこっち側にいる気分

> てか、コードが短く "も" 書けるのが嫌なんだけどね。

> そういうことをする余地がなければ無いほど良いと思ってる。

コードは曖昧さがなく、削ぎ落とすものが一切ないレベルが良いと思ってる。
だからいろんな書き方があるとは思わず、
それ以外の書き方は「なんでそんな無駄なことすんの?」としか思わない

あと当たり前だけどコードゴルフのような変数名を短くするみたいな
アホなことはしない。無駄を無くすだけ。

俺のプログラミングは関数型の影響は大きいと思ってるので、関数型勉強すると良いよ
と言っても俺、関数型言語あまり知らないけどねwww 考え方を理解してるだけ

> あと、shell も perl も(Cも)変数のスコープがデフォルトでグローバルなのが良くない。
それも手元じゃ解決済みなんだよな(苦笑)
感覚的に問題点を潰してる俺偉いw

ヒントを言うとサブシェルを使うとその中で定義した変数は中に閉じ込められるので
localを使わなくてもローカル変数相当になる。
138login:Penguin
2018/03/12(月) 13:05:39.78ID:NF8xf4ym
>>137
そういうルールをどうやっていろんなスキルレベルの人と共有するんですかって話
139login:Penguin
2018/03/12(月) 21:57:46.32ID:0gO9Md9Y
>>138
逆に言えば、そういうルールを共有できればOKってことだよね?

みんなありがと。いろいろ言ってみて話を引き伸ばしたけど
もうそろそろ十分かなと思ってる

ansibleではなくシェルスクリプトでやる上で、何が足りなくて
何が必要なのかわかった気がする。

今回はこれぐらいで切り上げるよ
またどこかで違う切り口から探るかもしれないけどw
140login:Penguin
2018/03/13(火) 06:36:13.77ID:w7drUkX+
>>139
そう。
その意気で、ぜひ世界に通用するシェルスクリプトフレームワークを作ってくれ。
141login:Penguin
2018/03/19(月) 12:18:33.64ID:10HKUK+F
Dockerfileからラッパースクリプトを呼び出すのは良いとしても、
DockerHubでそのシェルスクリプトを表示させるすべがないのが問題。

結局GitHubに行くことになるならDockerfileの表示ページいらないのでは。
142login:Penguin
2018/03/21(水) 17:17:07.53ID:6Vet870y
Dockerの教科書第二版が4月に出るぞー
143login:Penguin
2018/03/26(月) 16:00:04.53ID:W/pr8b3f
Arukasのβ外れたけど予想以上にコスパ悪いなぁ…
さくらはコンテナホスティングやる気ないのかな
144login:Penguin
2018/03/26(月) 16:24:25.96ID:bSj5pGXS
どんなビジョンであれで世界で戦えると思ったのかご説明いただきたい
145login:Penguin
2018/04/03(火) 07:43:27.59ID:8ENp9jaE
初心者がLinuxとストレスフリーで生きる為の6か条

1.Winをリプレース出来るなどど考えるのはやめましょう。共用しましょう。
2. 印刷はあきらめましょう。
3. Wifiの使用はあきらめましょう。
4. 音楽・動画・画像の編集/制作はあきらめましょう。
5. Nvidia製品の使用は控えましょう。
6. 教本を買いましょう。Linux界に限ってはググレカスは遠回りです。
7. Ubuntuを我慢して使い続けましょう。
146login:Penguin
2018/04/03(火) 23:16:59.76ID:Ry6Q9joG
随分古いな。
147login:Penguin
2018/04/03(火) 23:44:51.96ID:9r9tHTvx
>>145
従いますよ
148login:Penguin
2018/04/20(金) 13:08:52.09ID:IxQaq2RC
プロフェッショナルの方、どなたか教えてください(/ω\)

今、下記内容のdockerimageを作成したいと思っています。
 
 ① ベースのイメージ:jupyter/datascience-notebook
 ② Tensorflowを使いたい ※①にTensorflowがインストールされていないため

その為にdockerfileを下記の通り作成したのですが、
出来上がったdockerimageから作成したコンテナ上で上手くtensorflowが動きません。
※コンテナ内でpythonを起動し、そこで「import tensorflow as ts」を実行すると以下のエラーが出ます。
RuntimeError: module compiled against API version 0xc but this version of numpy is 0xa
ImportError: numpy.core.multiarray failed to import
ImportError: numpy.core.umath failed to import
ImportError: numpy.core.umath failed to import
2018-04-20 03:56:29.133557: F tensorflow/python/lib/core/bfloat16.cc:664] Check failed: PyBfloat16_Type.tp_base != nullptr
Aborted

dockerfileの内容は以下になりますが、何か間違っていますでしょうか?
もし間違っている場合は、修正内容をお教えください。m(__)m

■dockerfileの内容
From jupyter/datascience-notebook
RUN pip install --upgrade pip
RUN pip install tensorflow==1.5
149login:Penguin
2018/04/20(金) 22:27:51.02ID:8yT4IMgr
>>148
エラー文ちゃんと読んだんですか?
150login:Penguin
2018/04/21(土) 10:25:09.06ID:RQ3vsIdh
>>149
エラー文が理解できなかったです、、
151login:Penguin
2018/04/21(土) 13:23:47.70ID:HjK21lH7
>>150
numpyって知ってる?
152login:Penguin
2018/04/21(土) 13:46:33.79ID:HtY0Nuyg
なんぱい?
153login:Penguin
2018/04/21(土) 17:21:10.71ID:5eINoTB9
>RuntimeError: module compiled against API version 0xc but this version of numpy is 0xa

0x って、16進数か?
0xc は12、0xa は10 って事か?
154login:Penguin
2018/04/21(土) 19:53:43.47ID:RQ3vsIdh
>>151
はい、知っています。
これはnumpyのversionが古いということですか?
155login:Penguin
2018/04/22(日) 09:15:07.32ID:uHMnXexw
「python module compiled against API version」で検索!

開発者の基本は、エラーメッセージで検索すること
156login:Penguin
2018/04/22(日) 19:07:10.00ID:2/k4X0Kz
>>155
検索しましたが、力不足で分かりませんでした。。
少しやってみたものの、

import tensorflow as ts
しただけで、
「The kernel appears to have died. It will restart automatically.
(カーネルが停止したようです。 自動的に再起動します。)」
が出てしまいました。

どなたかお力をお貸しください(/ω\)
157login:Penguin
2018/04/22(日) 19:23:31.15ID:lrjQt1PM
いままで偉そうにしてたやつ、ちゃんと答えてあげろや
158login:Penguin
2018/04/22(日) 23:46:18.23ID:uHMnXexw
「docker hub tensorflow」で検索!
159login:Penguin
2018/04/23(月) 03:34:29.66ID:VkOu3656
この手の質問って動作環境が横断的だからdockerスレと言語スレ側でたらい回しにされちゃうんだよな
かと言ってマルチポストはできないし悩ましいところ

エラーメッセージやアドバイス貰ったキーワードをダブルクオートで括ったフレーズ検索も駆使して乗り越えるのだ
今こそ成長の時
160login:Penguin
2018/04/23(月) 06:37:04.24ID:qKqt8dYQ
>>156
tensorflowのバージョンはどうした?numpyのバージョンはどうした?
バージョンがあってないと言われてるんだからtensorflowのバージョンを1.4とか1.3とかに下げてみて試してみたらいいんじゃないでしょうか。

RUN pip install tensorflow==1.5
161login:Penguin
2018/04/23(月) 10:45:26.96ID:gJ+bJQJv
>>160
ありがとうございます!
tensorflowのバージョンを1.3にすることで、エラーも出ず正常にインストールできました。
1.4や1.6では、エラーが出てしまい駄目でした。

皆さん、私の力不足でお手数をおかけいたしました。
本当にありがとうございました。
162login:Penguin
2018/05/22(火) 07:23:12.42ID:Czl6p0FW
僕の知り合いの知り合いができた副業情報ドットコム
関心がある人だけ見てください。
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

EAAD8
163login:Penguin
2018/05/22(火) 11:47:01.72ID:NlhYPEMm
EAAD8
164login:Penguin
2018/05/27(日) 18:22:16.75ID:8ka68JJO
ディープラーニング ライブラリの管理で混乱しないようにとdockerを導入したけど
今はdockerで混乱してる
開発環境はどうやって整えるんだ、これ
コンテナの外と中は完全に分かれているのかよ
今あるエディタやアナコンダを呼べないぞ
コンテナを作る時に全部詰め込まきゃダメなのか?
NGCをつかっているけど
165login:Penguin
2018/05/28(月) 20:34:50.01ID:G/OxqctX
>>164
はいはい、いつもの仮想マシンの使い方とごっちゃにしてる人ね(笑)

Dockerは環境を作るものじゃなくて、
アプリケーションを作るものです。

ディープラーニングの何をしたいのか知らないけど
コマンドを実行するだろ?
そのコマンドを実行するのにライブラリとか必要だろ?

そのコマンドにライブラリなんか全部くっつけて
一つのDockerコンテナ=アプリケーションを作るものです。
166login:Penguin
2018/05/28(月) 21:14:26.05ID:5P04jZKi
>>165
いや、知らんよ
俺は開発元が進めてきたものを使うだけ
167login:Penguin
2018/05/28(月) 21:25:11.53ID:5P04jZKi
アプリケーションなら
任意の識別器や分類器を定義しデータを読み込んで学習するアプリケーションが欲しいわ

しかし、環境の切り分けのためじゃないならなんで開発元はdockerを配布しているんだろうね
それも競合を心配する必要ないですよってアピールしながね
168login:Penguin
2018/05/28(月) 21:47:04.72ID:G/OxqctX
> アプリケーションなら
> 任意の識別器や分類器を定義しデータを読み込んで学習するアプリケーションが欲しいわ

それを作るのがDockerを使うお前なんだって
169login:Penguin
2018/05/28(月) 22:02:15.83ID:5P04jZKi
>>168
それを玄人様たちはどうしているのかってこっちは聞いているだが...
170login:Penguin
2018/05/28(月) 22:13:34.15ID:G/OxqctX
普通にコマンド実行に必要なものを
まとめてコンテナにしてるだけだが?
171login:Penguin
2018/06/03(日) 15:52:37.21ID:4t3nAm6u
sage
172login:Penguin
2018/06/24(日) 08:47:17.87ID:TokMwylE
pullしたubuntuイメージにvimが入っていないんだけど・・・
aptコマンドもないんだけど・・・
docker search ubuntuで出てくるうち全部入りのイメージってどれ?
173login:Penguin
2018/06/24(日) 22:35:20.55ID:anZc79Me
dockerってコンテナが動いてる途中でdocker終わらせたらコンテナ内に保存してたファイルはなくなるの?
174login:Penguin
2018/06/25(月) 05:44:34.47ID:Uuelo8Ok
>>173
コンテナ起動時にストレージ領域を紐づけてなかったら終了時に綺麗さっぱり消えるようだ
175login:Penguin
2018/06/25(月) 09:42:17.00ID:+pzgGIIi
>>173
正確にはコンテナを削除すると無くなる
停止しただけでは無くならない
ゆえに削除するまではdocker logsでログも見れるし
docker commitでイメージ化すれば
docker runで中身を見れる

https://stackoverflow.com/a/39329138
176login:Penguin
2018/06/25(月) 09:49:22.67ID:+pzgGIIi
>>172
欲しけりゃ自分のDockerfileに入れるか
全部のコンテナでそれやるのがアレってなら
新しくvimコンテナ作って編集したいファイルだけマウントするか
ホストのファイルをマウントして
ホスト側でvimで編集すれば良い

てか開発環境だよな
本番環境でそれやったら
ちゃんと動く環境を保存出来るっていうDockerの魅力を殺している
場合によっては仕方ない事もあるが
177login:Penguin
2018/07/01(日) 03:55:45.96ID:+w2giTsy
>>172
> pullしたubuntuイメージにvimが入っていないんだけど・・・
Dockerの使い方を間違ってる。

あんたが言ってるのは、pullしてきたffmpegコマンドの中に
vimが埋め込まれてないんだけどって言ってるようなもの
Dockerコンテナ = 実行ファイル

ffmpegの処理にvimなんていらないんだから入っていなくて
当たり前だし入れるべきではない

だがaptコマンドは普通入ってるはずだけどな

>>172
> dockerってコンテナが動いてる途中でdocker終わらせたらコンテナ内に保存してたファイルはなくなるの?
ffmpegコマンドの中で内部的に使用しているファイルはコンテナ削除とともに消える。
Dockerコンテナの中のファイルはメモリと考えればいい。
コマンドを終了するとメモリも解放される

(Dockerコンテナ版の)ffmpegコマンドから書き出したいなら、
ボリュームでコマンド(コンテナ)外部への読み書き場所を指定する
178login:Penguin
2018/07/01(日) 09:04:34.19ID:EBIMlKr7
>>177
アドバイスありがとう
ということは、dockerで起動したOS内でvimが使いたければ
vimのコンテナを探してきて追加起動しろってこと?
どこのサイトにどんな名前でvimのコンテナがあるのか調べるみたいなことを
アプリごとにやってたら、環境を作るまでどれだけの手間と時間がかかることやら
このソフトの何が持てはやされているのか全く理解できない
179login:Penguin
2018/07/01(日) 09:21:20.95ID:+w2giTsy
>>178
だから使い方が間違ってる。
全く理解できないのは、あんたが正しい使い方がわかってないからだよ

そもそもDockerコンテナは使うものじゃない。作るものだ。
アプリのビルド・コンパイルと一緒だよ
もちろん誰かが作ったものがそのまま使えるのなら
使っていいんだが、基本はアプリの開発者が作るもの

vimとかそういうのは、どうせあんたUbuntuとか有名所の
ディストリ使ってるんだろ?そういうのはパッケージメンテナが
ちゃんと動くようにメンテしてくれてる。それで満足してるならそれ使えばいい。

Dockerの出番はそれで満足できない場合だよ。
vimにそういうのがあるのかしれないが、独自にビルドしないと使えない機能を使いたいときや
例えばvimの新しいバージョンを使いたい時。ビルドするためにライブラリも新しくしなければいけない
でもOSのライブラリを新しくすると、他のプログラムに影響が出るかもしれない

そういうときにvimのビルドとそれを動かす環境までも一体化させて、独自のvimを作る
ってときに使うんだよ。実行環境まで含まれてるから、OS標準のライブラリなどを
置き換えたりもしないし、どこに持っていってもそのまま使える
オレオレvimバイナリ(=Dockerコンテナ)の出来上がりってわけだ

で、そんなもん普通はやらねーだろ? だからアプリの開発者が作るものだって言ったわけだ。
vimなどのパッケージはパッケージのメンテナが頑張って動くようにしてくれてる
だけど、自分で作ったアプリは、自分が頑張るしかないだろ? でも頑張りたくもない
いろんなディストリや、WindowsやMacでも動くようになんかするの大変じゃないか
だからDockerコンテナ化することで、Dockerデーモンさえ動いていれば、
どこに持っていっても同じように動かせるってわけさ
一言で言えば可搬性だな
180login:Penguin
2018/07/01(日) 09:23:55.84ID:+w2giTsy
>>178
> ということは、dockerで起動したOS内でvimが使いたければ

それから通常はdockerで起動したOSの中に乗り込んでvim実行して
ファイル修正とかしないからな

独自のDockerイメージを作るときに、デバッグ目的にやることはあるけど
「dockerで起動したOS」なんて考え方を持ってはいけない

なぜなら、何らかのプログラムに実行環境をくっつけただけで、
作られるものは、実行環境付きのなんらかのプログラムなんだから
そこにOSなんてものはないと思え
181login:Penguin
2018/07/02(月) 19:23:28.69ID:1jLd0V1g
今日から新しいプロジェクトでmac上でDOCKERを使う事になったんですが

最初の社内のチュートリアルに従ってHOMEBREWからインストールして起動したところ
新しいバージョンがありますって言われたので
アップデート&ReLunchをしたらそのまま反応がなく
アプリからダブルクリックしても起動しなくなりました

MAC使うのもバージョン管理ツール使うのも初めてだらけで
くだらない質問で申し訳ないんですが
考えられる解決方法はありませんでしょうか
182login:Penguin
2018/07/02(月) 20:07:43.00ID:Eg1cEgm9
社内の人に聞け
183login:Penguin
2018/07/02(月) 20:45:02.37ID:Y1QFiQ2T
普段サーバーサイドJavaとかPHP JSでウェブアプリかいてて
mac の Ruby on Rails のサーバーサイドの案件が修羅場でヘルプはいったんだけど
分かってる人はみんな忙しくて質問なげてもなかなかかえってこないんですよね

でもこんな情報じゃわかるわけないですよね…
明日また社内できいてみます
すいませんでした…
184login:Penguin
2018/07/03(火) 00:50:17.25ID:1PLz+sRr
>>181
dockerは公式サイトのやり方でインストールしたほうがいいんじゃね?
185login:Penguin
2018/07/03(火) 00:52:28.72ID:1PLz+sRr
社内のチュートリアルが何年前に書かれたかだな
Docker Toolbox使ってたら古いやり方だな
まあ社内全員やり方が決まってるなら仕方ないが
186login:Penguin
2018/07/03(火) 02:50:11.95ID:88JNN2bg
支給されたmac PCが他の人も使うみたいで
別の人がインストールしたhomebrewが/usr/localにはいってて
権限が変更できないくてホーム以下にインストールしたんだけどそのせいなのかなと…

1日がかりでbrew rbenv dockerの3ついれただけなんだけど
どれが原因なのかがぜんぜん分からない…
マックはじめてで最初の1,2時間は日本語変換や窓の最小化やコピペもわからないレベルで作業効率も悪いし

Javaからruby覚えるのはすぐできると思ったけど
OSが違ったりフレームワークの環境構築がこんな大変だと思わなかった
187login:Penguin
2018/07/03(火) 05:53:39.58ID:0N07jwhz
もうmac板で質問したほうがいいのでは
188login:Penguin
2018/07/03(火) 06:10:23.01ID:1PLz+sRr
>>186
なんの苦労もなくhomebrewを使いたいなら
Macを他に人に使わせるな。そしてクリーンインストールして
自分ひとりのものとして使え

homebrewはインストールしたユーザー以外がまともに使うことは無理
homebrew自体はsudo使ってインストールするくせに(/usr/localに書き込むから)
パッケージ自体は/usr/local以下に一般ユーザーでインストールするからな
ディレクトリはこんな感じになる

https://github.com/Homebrew/brew/issues/3322#issuecomment-336770069
> -rw-r--r-- 1 weicool admin 3161 Jan 18 2016 /usr/local/CODEOFCONDUCT.md
> drwxr-xr-x 18 weicool admin 576 Oct 8 13:58 /usr/local/Cellar/
> drwxr-xr-x 2 weicool wheel 64 Oct 15 10:57 /usr/local/Frameworks/
> -rw-r--r-- 1 weicool admin 1241 Jan 18 2016 /usr/local/LICENSE.txt

見ての通り、adminグループに書き込み権限がないから、
最初にパッケージをインストールした人以外がいじることはできない。
brew管理用のユーザーを別で作成するとかumaskの設定をいじってたりとか
ちゃんとやってればマルチユーザーで使えるかもしれんがな

homebrewの設計自体はsudoを使わない方針なんだが
https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad
じゃあ共有のディレクトリ/usr/localを使うなと
189login:Penguin
2018/07/03(火) 06:28:04.40ID:88JNN2bg
そうなんですね
クリーンインストールしていいかお願いしてみます
検索するとわりとホーム以下にインストールする方法とかでてきたのでいけるかと思ったんですけど

コーディングスキルかわれて入ったのに初日から環境構築だけでつぶされてストレス
なまじできると思われてるからしょーもない質問もしにくいし

もともと大学院研究室あがりでスクラッチからかくのが好きな
ブラックボックスなツール使うの気持ち悪い
古い人間だから昨今のフレームワークだらけの業界きついなあ…
190login:Penguin
2018/07/03(火) 06:35:07.67ID:HvrBhqqa
頭でっかちの使えないやつか現場も大変だな
191login:Penguin
2018/07/03(火) 06:54:24.03ID:B87Zf6Sc
macやhomebrewがはじめてなのはともかく、バージョン管理ツールはじめてはないわ
それでひとりで環境構築しろってほったらかしなのも普通はありえんと思うけど
仕事ほしくて経験ないのに経験ありとか嘘かいたんじゃねーの
192login:Penguin
2018/07/03(火) 07:12:51.42ID:ArJzlEvp
最後にききたいんですけど /usr/local じゃなく
~~/homeblew に homeblew をいれたんですが
この blew から Docker をインストールした場合実態はどこにあるんでしょうか

チュートリアルにアプリケーションからdockerを起動とあるんですけど
/Application/Docker.app を起動したときにもっと新しいのがありますっていわれて
更新かけたらそれっきりだったので
これが前の人がインストールしたやつだったのかな…

コマンドラインの docker はホーム以下のパスになってたんですけど
アプリケーションからじゃなくコマンドラインからDockerのGUIアプリ起動する方法ってありますか?
193login:Penguin
2018/07/03(火) 11:19:37.64ID:oYvmZw+l
解決しました

初回起動時に窓が出たのでずっと窓を探してたんですけど
右上のクジラマークからアクセスするんですね…
おさわがせしました
194login:Penguin
2018/07/03(火) 13:54:24.15ID:oYvmZw+l
何度もすいません

docker-compose up -d

で ERROR: manifest for xxx/yyy:2018zzzz not found が出るんですがどこを見ればいいのでしょうか

一応同じディレクトリに docker-compose.yml はあって
yyy:
image: xxx/yyy:2018zzzz
と書かれています
195login:Penguin
2018/07/03(火) 14:20:45.35ID:1PLz+sRr
>>194
普通はそうならないので環境の問題です
OSをクリーンインストールしてください
196login:Penguin
2018/07/04(水) 02:14:06.32ID:COxRspz9
rubyは導入ハードル高すぎ
よっぽど複雑なプロジェクトでもなけりゃこんな開発環境作ってるあ労力で案件終わるわ
197login:Penguin
2018/07/04(水) 06:04:14.37ID:WJvTzUXE
利用プロジェクトの多くが低品質だったせいでいわゆるアタリショックみたいな扱い受けてるよな
負の遺産だとかRuby巻き返しの目は潰えてるとまで言われてるし・・・Javaみたいにはならんで欲しいマジで
198login:Penguin
2018/07/07(土) 17:30:55.41ID:fg0oR1Sy
散々Perlディスっといてこれだもんなm9(^Д^)プギャー
199login:Penguin
2018/07/07(土) 21:06:35.47ID:1D6mHUpx
やめて…perlは6を引き伸ばし杉た件のせいで世間との剥離からユーザー離れが尋常じゃなく
引き合いに出されると最底辺の戦いじみて嘲笑の的です…
200login:Penguin
2018/07/07(土) 21:59:02.61ID:fg0oR1Sy
イシキダケタカイケイ
201login:Penguin
2018/07/09(月) 12:21:03.01ID:4SJdzKl6
WSL上でDocker Engineが動くようになっていたっぽいという話
https://qiita.com/yanoshi/items/dcecbf117d9cbd14af87
202login:Penguin
2018/07/09(月) 12:48:52.62ID:qh/Cnej+
マジかよDockerForWindows消してくる
203login:Penguin
2018/07/09(月) 13:31:43.43ID:pfSJA2ey
もしかしてHyperV無しのHome版WSLでも動くようになってるのか
204login:Penguin
2018/07/10(火) 17:37:18.97ID:hi/Ud89A
パブリッククラウドやDocker Hubに最適化した「Minimal Ubuntu」がリリース 2018/07/10 12:06:20
https://news.mynavi.jp/article/20180710-662006/

 Canonicalは2018年7月9日(米国時間)、パブリッククラウドおよびDocker Hubに最適したLinux
ディストリビューション「Minimal Ubuntu」をリリースしたことを明らかにした。
AWS(Amazon Web Services)およびGCP(Google Cloud Platform)を推奨パブリッククラウドとし、
イメージファイルはWeb上からダウンロードできる。
205login:Penguin
2018/07/10(火) 18:37:07.13ID:TEPxwuu8
ええやん
alpine使いにくいし乗り換えようかな
206login:Penguin
2018/07/11(水) 00:29:12.16ID:dU5xb19g
minidebのUbuntu版みたいなヤツか
207login:Penguin
2018/07/11(水) 13:45:07.36ID:Za+YUtMW
ええやん、なんぼなん
208login:Penguin
2018/07/12(木) 01:08:55.93ID:Spx3HNht
展開後のサイズは約80MB前後でminidebのようなコンテナ特化支援コマンドはさすがに無いっぽいな

Ubuntu版の公式slimとしてapt系で最新パッケージ使いたいなら(Debianのslimじゃなくて)こっちでねって感じか
野良イメージじゃない公式スリムに選択肢が増えるのは嬉しい
209login:Penguin
2018/07/12(木) 07:54:44.88ID:2fRy1rm8
debianよりも少ないの?
210login:Penguin
2018/07/12(木) 08:05:41.95ID:uhTdlutY
alpineで慣れちゃった。
211login:Penguin
2018/07/13(金) 09:30:31.30ID:PFiL2FSs
debian:stretch-slimは55MB
(bitnami/minideb:stretchは54MB)

ubuntu:bionicは81MBで去年から変わってないみたいだけど今回発表されたやつは何なんだいったい…
元記事タイトルにDocker Hubとあるが実は関係なくてアマとかGCPで使うimgファイルが小さくなりますたってことか
212login:Penguin
2018/07/15(日) 20:58:09.55ID:9hWJVlJh
ミニマルすぎると一個ゲットした途端大量に依存がやって来る悪寒しかない
213login:Penguin
2018/07/15(日) 21:53:50.81ID:rnlXfHys
ミニマムすき
214login:Penguin
2018/07/15(日) 22:11:32.38ID:Xmkkcspf
エセロリやん
215login:Penguin
2018/07/19(木) 17:07:15.56ID:4Cjfx+r5
「OpenNebula 5.6」公開、Dockerサポートの強化などが加わる 2018年7月18日15:00 末岡洋子
https://mag.osdn.jp/18/07/18/150000

 クラウドインフラストラクチャ構築・管理プラットフォーム「OpenNebula」の開発チームは7月16日、
最新安定版となる「OpenNebula 5.6」(Blue Flash)を公開した。

 Docker管理機能を新たに統合、任意のOpenNebulaクラウドで、Dockerアプリケーション実装の
土台となるDockerエンジンの仮想マシンをMarketplaceよりインポートできるようになった。また、
OpenNebula APIやインターフェイスを経由することなくDockerエンジンをシームレスに管理する
Docker Machineも統合した。
216login:Penguin
2018/07/27(金) 03:51:52.83ID:6DSLURTJ
訳あってソースコードからビルドしないといけない物があるんだけど、
ビルドに必要なパッケージをインストールしたくない。

だからDockerでビルドして、インストール先はDockerの外って
やりたいんだけど、そういう使い方のノウハウって
どこかにまとまってないかなぁ?

ソースコードのディレクトリをボリュームにして
make installだけDockerの外でやるのが一番かなぁ?
217login:Penguin
2018/07/27(金) 04:48:47.30ID:1joj4I21
そういうときはmake install先のディレクトリだけ -v でマウントしとくパターンが簡単で良いね

例えば ./configure --prefix=/usr/local で入れるやつはインスコ先になる/usr/localを
docker runのときに -v "/usr/local:/usr/local" って指定する

コンテナでmake installまでやれるしホストもソースやビルドツールで汚れないから安心
docker公式マニュアルのどっかに書いてあった気がしたが見当たらなくなってた
218login:Penguin
2018/07/27(金) 07:25:43.45ID:7fogAuN8
詳しい解説サンクス
219login:Penguin
2018/07/28(土) 15:41:09.29ID:0ikx9NUA
>>217
もう少しアイデアを発展させてみた。
このアイデアをどうするかは任せる

make install、前々からの問題。何処に何がインストールされるかわからない。
基本的には--prefixで指定した所だろうけれど、確実にそうとは言い切れない

make uninstall、これも前々からの問題。uninstallをサポートしているものが少ない
インストールした後消すのが大変

docker、make installでインストールされるファイルは多分レイヤーの差分を見ればわかる
インストールされるファイルがわかるのだから、それを消せばアンインストールになる
インストールするファイルも残っているのだから、ファイル内容を比較することで
アンインストール時に想定外のファイルを削除しなくてすむかもしれない
220login:Penguin
2018/07/28(土) 16:06:06.83ID:PwMG08J6
今はMulti-stage buildが公式実装されて>>219のアイデアを綺麗に実現できるようになったね!
ビルドコンテナのmake install結果をホスト経由せずに実行用コンテナに簡単に乗せられる

ビルドコンテナも実行用コンテナも使い終わればコンテナごとすべて消せるから
--prefix完全無視の無作法野良ツールにホストのファイルが上書きされることもないし
make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない
221login:Penguin
2018/07/28(土) 19:21:25.29ID:fgC/Ah69
>>220
> make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない
なんかちょっと違うw

インストール先はコンテナの外よ。だからコンテナ消せば良いだけってことにはならない。

どんなものでもコンテナ化して使えるかっていうと、例えば(独自ビルドの)gitコマンドを
コンテナに入れて使うのは大変だと思う。カレントディレクトリを見るし、
サブコマンド次第ではカレント以外のディレクトリも見るしね

インストールするファイルを知ることができるから、コンテナでビルドして生成したものを
コンテナの外にインストールしてアンインストールもしやすくなるだろうと言う話
222login:Penguin
2018/07/29(日) 00:30:39.68ID:wo8fIaJv
最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな
俺もコンテナ上のgitからホストのカレントディレクトリを見る方法がわからんというごく最初の段階でつまずいた

絶対パス指定ならツールで使う主要ディレクトリを-vに指定しとけば大半普通に開けるけど
カレントを含めた相対パスも単に-v $(pwd):$(pwd) -w $(pwd)を書いておけばいいという基本をDocker Hubのgitイメージページ読んで知った
223login:Penguin
2018/07/29(日) 01:53:02.32ID:vXZjVBrz
>>222
だから大変だからホストに直接おいたほうが良いって話なんだが

例えばgit diff --no-indexでカレント(gitディレクトリ)以外を
比較したくなったら-v $(pwd):$(pwd)じゃ対応できない。
他にもgit applyとかさ

-v $HOME:$HOMEにしたら動くかもしれないけど、
それでもhomeの外では使えないコマンドになってしまう。
(例えば/opt以下にgitリポジトリをcloneするツールとかさ)

コマンド実行した時、特定のファイルはコンテナの外を見ますが、
それ以外はコンテナの中を見てますとかややこしいだけだから

俺は頑張ったんだって自己満足してたいだけでしょ?
そんなのは意味がないから辞めたほうが良い
224login:Penguin
2018/07/29(日) 01:54:06.34ID:vXZjVBrz
あ、そうだ。gitのglobal configがあるから、
絶対HOMEをボリュームにしないとだめなんだ。
225login:Penguin
2018/07/29(日) 01:57:06.96ID:vXZjVBrz
ssh鍵の話もあったな
-v $(pwd):$(pwd) -w $(pwd)を書いておけばって
実際には使ってないだろ。

コンテナ化に適してないアプリをコンテナ化しても使いにくいだけ
226login:Penguin
2018/07/29(日) 02:32:06.22ID:vXZjVBrz
面白い例を思いついた

> 最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな
エディタとgitをコンテナにするとどうなるか

環境変数GIT_EDITOR、コミットメッセージなどを編集する時に使用されるエディタをしている。
まあGITが使う多数の環境変数をコンテナの中に渡す。これだけでも面倒くさくてやりたくないが、

gitをコンテナの中で動かしたりすると、エディタがコンテナの中で起動される
つまり、gitコンテナの中にエディタまで入れないといけない。
さてそのエディタ、当然(?)のごとくgit連携機能がついている。
エディタからgitを呼び出されるならば、エディタのコンテナの中に、gitを入れないといけない

環境変数? おっと、gitコンテナの中でエディタを起動するならば、
エディタで使う環境変数も、gitコンテナに渡さないといけないな。
おっと、エディタからgitを呼び出すこともあるから、エディタのコンテナを実行する時も
gitの環境変数を渡さないといけないな

はは、乾いた嘲笑の笑いしか出てこない。こんなムダでややこしいことやって
なんの意味があるんだ。
227login:Penguin
2018/07/29(日) 18:09:34.64ID:PCsU6lV8
長くて全部読んでないけど、ホスト側のgitなりエディタ設定なりに依存するようなコンテナって筋悪くない?

k8sとかでコンテナを別ホストに移動したら使えなくなるような気がする。
228login:Penguin
2018/07/29(日) 18:12:14.75ID:PCsU6lV8
エディタが何かによるけど、vim程度ならコンテナ毎に入っててもいいのでは。有償のIDEでgit連携して使ってる人にとってはちょっとしんどいとかかな。
229login:Penguin
2018/07/29(日) 20:28:18.31ID:vXZjVBrz
そりゃ単に、
 普通は使わないけど入っていても良い。イメージのサイズがでかくなるだけ。
程度のことだな

普通はコンテナのイメージはDockerfileで作るし、コンテナの中のファイルを
直接修正することはない。Dockerfileの開発中とかデバッグのために
便利かもーぐらいで入れておいてもいいが、最終的には使わんので消す

コンテナ内のvimは使わない。の意味がわからんやつは
勉強し直したほうが良い
230login:Penguin
2018/07/29(日) 21:46:50.04ID:PCsU6lV8
え、普通にvim使ってるけど。何でなの?
231login:Penguin
2018/07/29(日) 21:48:26.84ID:PCsU6lV8
本番環境って前提ならそもそも本番で稼働している設定ファイルはみだりに編集しないってのは分かるけど。
単にコンテナ内でvim使うかどうかって話だとしたら本気で意味分からん。
232login:Penguin
2018/07/29(日) 21:51:36.18ID:PCsU6lV8
コンテナの中のファイルは絶対編集しないってどういうことなんだろう。良くあるベストプラクティスに書いてあるから盲目的にそうするって事だとしたら、はぁ、そうですかで話終わりにするけど。
233login:Penguin
2018/07/29(日) 22:27:59.92ID:Hv8rsH9m
>>238
Dockerはアプリケーションコンテナと言って、
アプリケーションをコンテナ化するもの
システムコンテナと違って、コンテナの中で作業するためのものじゃない。

だから、vimという手動で作業するツールをコンテナに入れる意味はないし、
vim自体をコンテナ化しても使いづらいことは説明済み

> 良くあるベストプラクティスに書いてあるから
ベストプラクティスレベルの話じゃない。Dockerの使い方の基本の話。

とりあえずアプリケーションコンテナとシステムコンテナの
違いぐらい学習してから出直せ
234login:Penguin
2018/07/29(日) 22:32:59.80ID:/XpMabXH
ドヤ顔で未来にエスパーしてて草
235login:Penguin
2018/07/29(日) 22:49:16.80ID:Hv8rsH9m
内容は間違えてないだろ?ニヤリ
236login:Penguin
2018/07/29(日) 23:31:49.15ID:PCsU6lV8
>>233
アプリケーションコンテナとシステムコンテナの違い、ですか。そうですか。
教科書にはきっとそう書いてるんでしょうね。その辺はよく知らないけど、たぶん間違ってないんだと思います。

でも、私はDockerで開発するファイルも編集します。はい。
237login:Penguin
2018/07/29(日) 23:37:55.72ID:PCsU6lV8
コンテナでsshd起動してsshでアクセスするなとかいうのも基本としてあるってのは聞いたことある。
けどそんなの関係ねぇ。
実際エンジニアに開発環境としてコンテナ提供するのにsshでアクセスできないって不便でしかない。
238login:Penguin
2018/07/29(日) 23:54:22.87ID:PCsU6lV8
ちなみにシステムコンテナってSolarisのzoneみたいなものかな。Linuxだと何かあるのだろうか。
239login:Penguin
2018/07/30(月) 01:20:21.45ID:QZl1Bega
>>236
コンテナの中にあるファイルはコンテナ削除すると消えるでしょ?永続化しない。
残っていてほしいファイルはボリュームでコンテナの外にだすわけだから
そのファイルの編集はコンテナの外でやれば良いわけ
中にvimを入れておくのは開発中とかの一時的にしかやらんよ

っていうか使いづらいでしょ? あんたvimの設定とかしてないの?
デフォルト設定で使いづらいからカスタマイズするのが常識だけど
コンテナの中にあるのはなんの設定もされてないvimじゃん
240login:Penguin
2018/07/30(月) 01:23:38.82ID:QZl1Bega
>>237
関係ないとか言ってないで、自分の解釈が大きくずれているって考えたほうが良いよ
ちょっと間違いレベルじゃなくて、方向性が大きくずれている
変な使い方をしているから、使いづらく感じるんだよ
241login:Penguin
2018/07/30(月) 06:34:10.24ID:jEBEwRTJ
>>239
残ってほしい開発後のプログラムがあるならgitでpushしとけば良くない?

設定あんまりシナイ派だけど、仮にするとしても、それこそvimrcとかgitでpushしてるものをcloneで持ってくれば設定なんて一撃で終わらない?それじゃあダメな理由とかある?
242login:Penguin
2018/07/30(月) 06:40:38.62ID:jEBEwRTJ
>>240
解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。
どんなに正しくても実際に使い難ければ正しくてもやらない。
もちろんセキュリティーや影響は考慮するけど、その辺問題なければ基本がどうとか関係ない。

PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。
243login:Penguin
2018/07/30(月) 06:42:13.68ID:QZl1Bega
>>241
gitは作業中断時に一時保存するための道具じゃないし、
設定しないなんて使いづらいだけだし、
いちいちcloneするとか面倒くさいことこの上ないし、

ホストでやれば普通にできることを、いちいちやらないといけないのか?
間違ってる方向に進むとこれから、あれやこれが使いにくいって愚痴るだけだぞ
すでに愚痴ってそうだがw その原因はすべて間違った使い方にある
変な癖が付く前に矯正したほうがいい
244login:Penguin
2018/07/30(月) 06:43:07.14ID:QZl1Bega
>>242
> 解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。

便利に使うための手段を、お前がみんな捨ててるから、
(俺は不便な中で生活してるから)不便に思わないんだって言ってるだけじゃん
245login:Penguin
2018/07/30(月) 06:44:51.91ID:QZl1Bega
>>242
> PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。

お前のその考え方だと、間違った解釈をして間違ったやり方をやって
余計効率が悪くなった。PMBOKとかAgileはクソって言ってるようにしか見えないね

まず教科書守ってやろう。いまお前は教科書通りのことを守らずに使いづらいと言ってる
246login:Penguin
2018/07/30(月) 06:48:28.40ID:jEBEwRTJ
>>243
一時保存なんて利用用途で言った覚えはないけど、仮にそうだとしても何で一時保存でgit使ったらダメなの?

あなたって基本に従うってことに束縛されて思考が限定されてる気がする。自分だけでそういう方針で進めるのは勝手だけど、人にやり方強制しだすと嫌われるから考え改めた方が良いよ。
新卒ならまだ良いけど。
247login:Penguin
2018/07/30(月) 06:51:41.70ID:jEBEwRTJ
>>244
よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの?物凄く不便じゃない?

ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない?
248login:Penguin
2018/07/30(月) 06:52:59.21ID:QZl1Bega
>>246
gitはバージョン管理するための道具であって、
バージョン管理しないならタダの保存に過ぎないから

それにgit使うなら、コミットする時に、メールアドレスと名前の設定がいるだろ?
gitでpushするならssh鍵が必要だろ?
rootでやるわけないから、自分のhomeディレクトリがいるだろ
お前本当にコンテナの中でgitでpushとかしてるんか?
してねーだろ。使いづらいもんな

お前はまだ初心者で、どうせgitもオープンソースものをcloneするぐらいのことしか
したこと無いんだろ。基礎ができてないんだからまず教科書通りにやれと
249login:Penguin
2018/07/30(月) 06:54:15.51ID:jEBEwRTJ
PMに教科書通りのやり方を強制されて疲弊してる現場を見てきたから経験談として話してるだけ。
教科書通りやって現場がうまくまわってるならそうすればいいよ。
というか、むしろ教科書なぞってうまくいってる現場があるならそれ勉強会とかで話してほしい。見に行くので。
250login:Penguin
2018/07/30(月) 06:55:30.13ID:QZl1Bega
>>247
> よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの?物凄く不便じゃない?
ホストに置いたファイルを編集すればいいだけだろ。
それがコンテナの中にボリュームを通して見えてるんだから
コンテナの中に入って編集する必要がない。
コンテナの中の環境を整える必要もない

もっと便利なものが俺には見えてるんだが、
お前のやり方は何が便利なの?

できるといってるだけで便利なんてお前は一言も言ってないよね?
お前のやり方が俺は不便だと言ってる。反論は?
できる、やったらだめなの?は不便であることの反論にはならない
251login:Penguin
2018/07/30(月) 06:55:41.00ID:jEBEwRTJ
ということで、あなたのやり方を変えさせるつもりもないし、自分のやり方を変えるつもりもありません。
以上終わり。
252login:Penguin
2018/07/30(月) 06:57:17.09ID:QZl1Bega
>>247
> ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない?

ホストにあればgitにpushしたいと思ったタイミングでpushできるんだが

コンテナ消すと中で編集したファイルが消える。不便だからgit入れて忘れずにpushしなきゃって
コンテナのファイルを直接編集すると不便だと言ってなかったか?w
253login:Penguin
2018/07/30(月) 06:58:17.45ID:QZl1Bega
>>251
俺はやり方をお前に押し付けてるんじゃなくて、

正しいやり方にしないとお前が困るという事実を言ってるだけ
お前はその事実に反論してない。困るのは自分だけだから
良いじゃないかって逃げてるだけだ。
254login:Penguin
2018/07/30(月) 07:00:14.56ID:QZl1Bega
>>249
そのPMが教科書通りにやってないだけだよw
教科書通りにやることが簡単だと思ってはいけない

教科書に反論するときは、教科書の場合と何が違っているかまで
理解してからじゃないといけない。

教科書になってるぐらいだから基本的には正しいんだよ。
それが当てはまらない理由を見つけない限り、教科書に反論してはいけない。
当てはまらない理由がわからないのは、理解してないってことになるんだから。
255login:Penguin
2018/07/30(月) 07:08:27.71ID:QZl1Bega
ほんとね。反論の一つでもできればまだいいんだが、
回避策はあるというだけじゃ、その方が良いってことにはならないんだよ。
全部回避策を入れないとやっていけないってことになってるんだから、

優れた方法っていうのは、回避策を使わずとも自然な形で実現できる
いちいち回避策を考えなきゃやってられないってのは、
やり方が間違ってる証拠でしか無いんだよ


余談だが、アメリカではツールをただ導入するのではなく、そのツールが
想定している使い方を学習して、やり方をツールにあわせるから効率的になるらしい。

日本だとツールを導入して、自分のやり方にカスタマイズさせる。
やり方を変えようとしないから生産性も変わらないし、
ツールのカスタマイズにコストも掛かるとのこと。それと同じだ
256login:Penguin
2018/07/30(月) 09:12:18.18ID:2DtBR6Mw
アプリケーションコンテナはyum, aptのパッケージ相当だと思ってるなぁ
基本的に使い捨てて常にクリーンなコンテナに出来るのがいいし, だからこそkubernetesとかで高い自己修復性を持てる
257login:Penguin
2018/07/30(月) 09:22:21.96ID:IG0rWwn1
すると、Vimのような手動カスタマイズほぼ必須のアプリは
コンテナ化には適さないのか
docker searchしてもVimが出てこないのが不思議だったがそういうことか
258login:Penguin
2018/07/30(月) 09:55:24.40ID:2DtBR6Mw
そのカスタマイズ部分を, プラグインならホストからマップするか別コンテナで, 設定ファイルはホストからマウントする必要があるだろう
259login:Penguin
2018/07/30(月) 16:34:35.00ID:QZl1Bega
>>257
手動カスタマイズの有無じゃないな。
プログラム本体がコンテナに隔離されているので、
コンテナの外に自由にアクセスするものは適さない

もちろんプログラム本体がコンテナに隔離されているおかげで
コンテナの外がどうなっていようがいろんな環境に持っていける

コンテナと外部との通信は基本的にネットワーク通信で行うか
ボリュームとしてマウントしたディレクトリ経由で行う

ボリュームとしてマウントするから、コンテナの外がどのような
OSやディレクトリ構造であっても、コンテナの中からは同じよう見える
コンテナの外がどうなっていても中からは同じように見える。
Dockerの "仮想化" というのはこういう意味
(ハードウェアをソフトウェアで仮想的に作り出すという意味じゃない)

もちろん不可能ではないが面倒なだけ
260login:Penguin
2018/07/30(月) 19:40:21.56ID:vC8FJAc3
これいわゆるイキリstaticおじさんが駄々こねて屁理屈連投してるいつもの案件じゃなくて
もしかして今回に限っては、Docker業界的にも、回避策やカスタマイズの工夫するくらいなら
コンテナはそぐわないからツールの使い方としてもやめてねって方向性にいつの間にか大勢が傾いてるのか
261login:Penguin
2018/07/30(月) 19:45:58.92ID:QZl1Bega
エクセルで小説書くなってだけの話
262login:Penguin
2018/07/31(火) 19:28:27.70ID:9kOFb8Cb
docker-tramp.el 便利だー。この機能使うためだけにemacs使いになっても良いと
思うくらい。コンテナにvimやsshdインストールする必要がありません。
263login:Penguin
2018/07/31(火) 20:23:57.73ID:GXqvrTdQ
いまWSL使ってDockerを使っているんですが、atomでホストに置いたファイルを修正して
それをイメージに反映させたいのですが、修正するたびにビルドするのが面倒です。

なのでボリュームを使ってホストのディレクトリをコンテナ内に共有しようと思っています。
Linuxではうまく動いているのですが、WSLだとうまく動かないのですが、
何が問題だと考えられますか?
264login:Penguin
2018/07/31(火) 20:24:57.09ID:GXqvrTdQ
と、書き込んでからひらめきました。
WSLで使ってるのはWindows上のDockerなので
パスの指定をC:\~でやらないといけないきがします。
265login:Penguin
2018/07/31(火) 20:28:45.59ID:C0KTXAUF
ビンゴでした!
 

こんな感じでホストのディレクトリがコンテナから見えました。
これでWindowsのatomを使って簡単に編集できそうです。

スレ汚し申し訳ありません
266login:Penguin
2018/07/31(火) 20:30:02.34ID:C0KTXAUF
↑なぜかコマンドを書き込んだらエラーになったので怪しそうな所を大文字で書きます。

docker run -p80:80 -v"$(wslpath -wa www):/var/www" -d httpd
267login:Penguin
2018/07/31(火) 20:33:08.23ID:PupCkl8+
>>262
もとからvimもsshdも入れたりなんかしてないよ。
入れるもんでもないしね。

docker-tramp.elも別にいらないかな。
ファイルを修正したいならボリュームにすればいいだけだし、
sshdはdocker execを使えばいいので、
268login:Penguin
2018/07/31(火) 20:50:25.97ID:PXAb2zrY
>>267
定位置にあるconfファイル等を色々いじってテストしたい時はどうしているの?
269login:Penguin
2018/07/31(火) 20:52:18.71ID:WDZkbP+f
>>267
コンテナ提供するアプリエンジニアにdocker exec使えって言うの?
270login:Penguin
2018/07/31(火) 20:54:37.84ID:WDZkbP+f
大した負荷のかからないコンテナをサーバーって言ってアプリエンジニアに提供するときある。ポート番号ちょっと変わってるサーバだと思って使ってくれてるよ。
本人はdockerだのコンテナだのを使ってる事に気づいてない。
271login:Penguin
2018/07/31(火) 21:27:30.82ID:PupCkl8+
>>268
だからボリューム使えばいいじゃない?

$ docker run -it debian cat /etc/debian_version
9.5

# ホスト上のファイルにすげかえ
$ docker run -it -v/etc/hosts:/etc/debian_version debian cat /etc/debian_version
127.0.0.1 localhost


>>269
普通に使ってるからなぁ。
アプリエンジニアがDockerfileを書かないで誰が書くというの?
アプリを動かすのに何が必要かを知ってるのはアプリエンジニアだけなんだが。

build, run, exec などを使って正しく動くコンテナのイメージを作るまでがアプリエンジニアの仕事で
コンテナを動かす環境を作って指定されたイメージを起動するのがインフラエンジニアの仕事

>>270
アプリエンジニアがDockerイメージを作ってないのはおかしい。
アプリを作ってる人でないと、アプリを動かすのに必要なものは知らないんだから
「手元のマシンだと動きました」「ライブラリのバージョンが違ってるんですねー」
これをなくすためにDockerがあるというのに。仕事の分担が間違ってる。
272login:Penguin
2018/08/01(水) 05:48:16.53ID:rxe3lfEn
動くコンテナのイメージ作るのがアプリエンジニアの仕事なら、結局必要なミドルをアプリエンジニアが入れる事になってそれこそインフラエンジニアの作った本番環境と差異が出てしまうと思うのですが。

まあ新規や中小規模のサービスならそれでも問題無いと思うけど。
273login:Penguin
2018/08/01(水) 05:52:39.03ID:rxe3lfEn
大きい会社だとIDEしか使ったことがない、CUI触ったこと無いアプリエンジニアとか普通に居りましてですね

まあその程度のアプリエンジニアはいずれ淘汰されると切り捨てるなら問題無いんですけどね。
274login:Penguin
2018/08/01(水) 06:00:09.93ID:rxe3lfEn
アプリ動かすのに必要なミドルウェアをバージョンも含めて熟知してるアプリエンジニアって相当優秀だと思う。

取りあえずアプリ動く程度に適当にミドル入れまくるアプリエンジニアいるけど、それができるアプリエンジニアすらそこそこ出来る評価なんだけど。
275login:Penguin
2018/08/01(水) 06:12:59.68ID:eV7ibk3+
>>272
やっぱお前使い方間違ってるわ

答えだけ言っておくね。本番環境と全く同じ環境になる
276login:Penguin
2018/08/01(水) 06:13:53.34ID:eV7ibk3+
>>274
> アプリ動かすのに必要なミドルウェアをバージョンも含めて熟知してるアプリエンジニアって相当優秀だと思う。

お前の会社の人間が馬鹿だってことかな?
そうなんだろうな。

ミドルウェアのバージョンを把握してないで
どうやってアプリが正しく動くことを保証するのか?

言ってみ
277login:Penguin
2018/08/01(水) 06:15:57.48ID:eV7ibk3+
コンテナの中にミドルウェアが入ってしまってるのに
どうやってインフラエンジニアがミドルウェアを入れ替えるんだ?
コンテナに手を入れてミドルウェアを差し替えるんか?w
278login:Penguin
2018/08/01(水) 06:18:28.58ID:eV7ibk3+
というかミドルウェアがなにかもわかってなさそうw
279login:Penguin
2018/08/01(水) 06:57:46.82ID:rxe3lfEn
え、もしかして自分でミドル入れずにDockerhubに落ちてるミドル入りコンテナ使ってるクチだったりするの?
280login:Penguin
2018/08/01(水) 06:59:30.64ID:rxe3lfEn
コンテナの中庭ミドルが入ってしまっているのにって、じゃあそのミドルは誰が入れるの?

アプリエンジニアが適当に入れたミドルをそのまま本番に使ってたりするんですか?
281login:Penguin
2018/08/01(水) 07:01:51.20ID:rxe3lfEn
インフラエンジニアの居ない規模の企業でアプリエンジニアが勉強して開発から本番運用までやってるって言うなら分かるけど。

インフラエンジニアいるのにミドル部分までアプリエンジニアが制御するって問題無いの?

部署をまたいだアプリエンジニア同士で宗教論争はじまってまとまらないと思うんだけど。。
282login:Penguin
2018/08/01(水) 07:06:15.76ID:rxe3lfEn
最終的にはインフラ分からないアプリはフェードアウトするって意見に異論はないけど、まだその時ではないと思ってる。中小規模やベンチャーは知らない。
283login:Penguin
2018/08/01(水) 07:40:52.95ID:vZ5iA/aw
>>280
> アプリエンジニアが適当に入れたミドルをそのまま本番に使ってたりするんですか?

なんで適当に入れるんですか?
お前じゃあるまいしw
284login:Penguin
2018/08/01(水) 07:52:42.75ID:vZ5iA/aw
>>281
お前さ、アプリケーションが動くサーバー作ったことないだろ?
どうせデータベースサーバーのセットアップぐらいしかしてねーだろ?

データベースサーバーのセットアップなんて簡単だもんな
設定ファイルをいじるだけ。そんな簡単な仕事はお前にやらせるよ

で、アプリ開発してないやつが、どうやってアプリケーションが
動くサーバーを作れるっていうの?
あぁ、どうせお前、オープンソースのアプリ動かしてるだけだっけ?w

俺が作ったアプリ、そのアプリが動くのになんのライブラリが必要か言ってみ?
アプリを開発してる俺は当然わかるが、教えないからなw

アプリのコード読んで必要なものを調査するとかやんなくていいよ
俺がコンテナのイメージつくってやっからさ、
お前はそれ動かすだけ。おまえにできないことはやらなくていい
お前はDockerr動くLinuxマシンだけ用意してればいい
285login:Penguin
2018/08/01(水) 08:09:10.69ID:rxe3lfEn
何をそんなに怒っているの?
286login:Penguin
2018/08/01(水) 08:12:05.32ID:rxe3lfEn
あなたがよくても他のアプリエンジニアから不満でたりしないの?
あなたのレスみる限り大きな声で周りねじ伏せて自分凄いって思ってるタイプの人に見えますが。
周りは従ってるんじゃなくて腫れ物には触らないようにしてるだけっていうオチじゃないですか?
287login:Penguin
2018/08/01(水) 09:24:20.09ID:rSD2s4kw
マウント合戦はお腹いっぱい
288login:Penguin
2018/08/01(水) 10:07:33.31ID:oUHlYMq4
それだけDockerの理解・運用は難しいということだな
俺本読んでもさっぱりわからんかったもん
コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
コンテナ=アプリとその動作環境をパックにしたものと
ここで教わったが、アプリがIPアドレスを持つわけないだろう
289login:Penguin
2018/08/01(水) 10:18:41.57ID:V8uA/puM
containerizedされたアプリケーションならdocker-composeなりkubernetesなりでミドルウェアごと構成管理するのが普通
この場合はインフラ屋の役割は主としてdockerなりkubernetesクラスタの管理になると思うのだけれど

単に共通テスト環境としてコンテナを使っていて, アプリケーションをcontainerizedせずにリリースするとか単体のコンテナとして配布して使う側で上手に組み合わせてねってものならインフラ屋が実動環境に合わせてコンテナ構成をすることもある
Travis CIとかGitLab CIでビルド環境として使うコンテナはこっちの場合が多そう
テスト/開発環境でもdocker-composeかVagrantした方がいいと思うけども
290login:Penguin
2018/08/01(水) 10:32:58.00ID:V8uA/puM
>>288
UNIXソケットを使わない場合にアプリケーション間のデータのやり取りはTCPやUDPで行われることが多いと思うのだけれど, そうするとIPアドレスがないと困るだろう
特にロードバランシングしていると同一ホスト上でないことが普通なので, ソケットが使えないことが多い
291login:Penguin
2018/08/01(水) 18:16:15.55ID:vZ5iA/aw
>>286
人間の問題と技術の問題は切り離して考えましょう

俺の周りがどうこうとか聞く必要ないだろ?
お前には関係ない話なんだから。俺の周りが凄くて
全員がDockerを使いこなしていて、誰も文句言わなくても、

「お前の」周りではそうじゃないんだろ?

なら、それはお前の周りでの問題であって。
その問題の原因は人間だって素直に認めればいいじゃないか?

下には下なんていくらでもいるんだから、素人集団には
使えませんと言われても、それ技術となんの関係もないやん
292login:Penguin
2018/08/01(水) 18:21:54.43ID:vZ5iA/aw
>>288
> コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
> コンテナ=アプリとその動作環境をパックにしたものと
> ここで教わったが、アプリがIPアドレスを持つわけないだろう

そう。認識としてはIPアドレスを持ってないと考えていい。
内部の仕組みの話だから。

コンテナ = アプリで、環境の仮想化を行っているため、
そのコンテナ(=アプリ)は自由にサービスを提供するポートを変更できる。

仮にコンテナの中で80番ポートでアクセスを受け付けているからって、
コンテナ(=アプリ)は80番ポートでアクセスを受け付ける必要はない。
コンテナが受け付けるポートは自由に変更できる。
それが「仮想化」で実現している機能の一つ

それを実装するために、内部的にルーティングしているというわけ

Dockerの仕組みに詳しい人はネットワークについても勉強するだろうけど
Dockerを使っている段階では、コンテナがどのIPアドレスを
持ってるかなんて意識していない
293login:Penguin
2018/08/01(水) 18:23:53.95ID:vZ5iA/aw
>>288
> それだけDockerの理解・運用は難しいということだな

技術職っていうのはそういうもんだよ。
ソフトウェアにおいて技術=知識
知識を得て楽をするか、知識ない人は力ずくで頑張れと
294login:Penguin
2018/08/01(水) 21:17:15.65ID:rxe3lfEn
>>291
いや、関係あるでしょ。
元々ある程度のリテラシーのエンジニアに使ってもらうこと前提の話をしてるのに、あなたは俺が俺がばっかりで使い手に対する配慮がほとんど感じられない。

さっきもいったようにあなたは腫れ物か、もしくは本当に周りがDockerくらい使いこなせるみたいな優秀なエンジニアばかりの職場で働いてるからそういう考えになるんでしょうね。

せいぜいその職場から振り落とされないようにしてくださいね。
普通の職場で働くと、たぶんあなたは腫れ物扱いされます。
295login:Penguin
2018/08/01(水) 21:18:23.05ID:/ajt4qwz
なんで喧嘩腰なの?
296login:Penguin
2018/08/01(水) 21:22:54.23ID:vZ5iA/aw
>>294
> 元々ある程度のリテラシーのエンジニアに使ってもらうこと前提の話をしてるのに、

だから、それ、人間の話ですよね?

技術の話をしてください
297login:Penguin
2018/08/01(水) 21:27:17.86ID:vZ5iA/aw
ほんとDockerの話しろっていってるのに、
俺の周りの人間は~馬鹿ばかりだから~
人間の話ばっかりw
298login:Penguin
2018/08/01(水) 22:48:53.21ID:gpg7eCuF
なんでこのスレこんなに荒れてるの
299login:Penguin
2018/08/02(木) 01:28:49.77ID:NqqEoGeq
全く興味ない第三者だが、いちおう荒れた懲罰としてうんこ置いとくな?

    _人
   (  )
   (へ ノ)
 ヽ( ´ 」`)ノ
  (  `ー  )
【いけめんウンコ】
300login:Penguin
2018/08/02(木) 06:34:51.81ID:rhKXtEAo
そこで働く人間無視して仕事できる訳ないし、やってるつもりなら大した仕事してない。

勝手なことやるなら本当にインフラも含めて別予算で独自にやってほしい。
えらそうな事言って勝手な事やって、結局尻拭いはインフラ側に押し付ける勝手なアプリエンジニア見ると文句の一つも言いたくなる気持ち分かるでしょ。

インフラエンジニア要らないってのは理想。ただ、その理想を妨げる事が多いのが声がでかいアプリエンジニア。
大概やりたいようにやって自分では運用回らなくなって、別の誰かに運用を押し付けて自分はフェードアウトするってのがお決まりのパターン。
301login:Penguin
2018/08/02(木) 07:40:01.26ID:a1K3N0Xu
>>300
そういう話じゃねーよ

人を持ち出してきたら、どんな結論でも覆せるんだからここで話す意味ないだろってこと

例えばウェブサーバー運用するのにLinuxが適しているとなっても
うちではLinux使える人がいないので、Linuxはだめなんですってなるだろ
Javaが適していてもうちではJava使える人がいないでJavaだめなんです。
COBOL使ってください。ってなるだろーが。

もはや適しているかどうかの話じゃなくなるんだよ。

「Dockerの適している使い方は○○です」って結論した後
心の中で「でもうちでは技術者のスキルが低くて使えるやついないんだよ。」って泣けばいいだろ
他の人には関係ない話だ
302login:Penguin
2018/08/02(木) 08:13:38.44ID:a1K3N0Xu
>>300
> インフラエンジニア要らないってのは理想。

そんなこと言ってない。アプリエンジニアがやるべきことはアプリエンジニアがやって
インフラエンジニアがやるべきことはインフラエンジニアがやれってだけ

アプリがなんの言語で使ってるかなんて、アプリエンジニアが知っていればいい情報だろ
言語もそうだしアプリ動かすのにインストールしなきゃいけないライブラリやパッケージを、
アプリエンジニアに聞かないでわかると思うか?

インフラエンジニアにはコンテナのイメージ渡すから、それを動かす環境を作ってくれればいい
中が何で動いているかなんか、知ったこっちゃねーだろ?
それとも勝手にディストリやパッケージを適当に入れた挙げ句、ライブラリのバージョンの違いで
動かなかくて、その責任をとってくれんのか?

どうせこういうことすら思いつかなかったんだろ?
だからお前がアプリケーションが動くサーバー作ったことねーだろってわかるんだよ。
303login:Penguin
2018/08/03(金) 23:40:03.86ID:1yCRuO5i
数日かけてDocker使って個人用のミニアプリ書いたぜ

内容はサーバーのとある情報を、別のマシンからブラウザで
グラフで見れるようにする一種の監視ツール
zabbix や nagios みたいに本格的な物はいらない。むしろおもすぎて邪魔

先に結論から言うと、このアプリを新しいサーバーで動かすには

docker run -d -p80:80 -vなどのオプション --restart=always コンテナ名

とdockerサーバーが動くマシンで、たった一行実行するだけでデプロイは完了する
(docker hubにイメージ置けるのであれば、本当にこの一行で終わり。
置けないならばプライベートレジストリから取ってくるように少し準備がいるだろう)

これは個人用のアプリで1人でやっているが、もしインフラエンジニアに伝えるとすれば、
このコマンドとどんなオプション(環境変数)があるかを伝えるだけで終わり
あとは必要なサーバーにデプロイしてくれるだろう

もしDockerを使わずにインフラエンジニアがデプロイをしようとしたら大変なことになるだろう。

なぜかって?だってこれだけの情報じゃ、どんなサーバーを構築すればいいか
インフラエンジニアにはわからないでしょ?何をインストールする必要があるのか?
なんの言語が必要でどのパッケージを入れておかないといけないのか?
スクリプトのパスは?どんなコマンドが必要なのか?などなど

docker使えば、さっき書いたdocker run~のコマンドだけで構築できるというのに。
304login:Penguin
2018/08/05(日) 08:47:03.44ID:t1pjwXO7
すごいドヤ顔w
305login:Penguin
2018/08/05(日) 13:08:10.87ID:FlnPtVfq
>>304
めちゃくちゃ便利やでw

今(個人的に)作ってるのはアプリじゃないんだけど
とあるサービスを特定の用途向けにカスタマイズしたもの

起動時に自作スクリプトで独自フォーマットの簡易な設定ァイルを解析して
サービス本来の設定ファイルを生成してから起動する仕組みで、通常なら/etc/以下にある
設定ファイルをいじらなきゃならないのが、簡易な設定ファイルを書くだけでよくなる

中身は既存のプログラムの組み合わせだけど、同じサービスを提供する
別のプログラムを作ったかのように使える
306login:Penguin
2018/08/05(日) 16:28:15.92ID:t1pjwXO7
そうですね
307login:Penguin
2018/08/05(日) 21:35:59.80ID:t4Ako3RB
Docker使いこなせる人ってすごいな(皮肉ではなく)
308login:Penguin
2018/08/05(日) 21:53:21.43ID:9sU0s1Rh
わざわざdocker使わんでもchrootでいいことにdocker使ってる人が結構いる
309login:Penguin
2018/08/05(日) 22:01:32.35ID:yAw8KkqM
chrootの親戚のGUIなし仮想アプライアンスに情熱を燃やせる謎
別スレではviの話で盛り上がるし日本人はビルジョイが好きなんだな
310login:Penguin
2018/08/05(日) 22:05:09.77ID:yAw8KkqM
あーGUIまでいってるのか、なるほど
311login:Penguin
2018/08/05(日) 23:04:52.65ID:NroY7Fy3
>>308
chroot使うぐらいならDocker使うなー

chroot用のディレクトリを準備するのでさえめんどくさい
debootstrapだっけ、懐かしいな。
/procや/devのマウントとかも必要だし。

同じdebianでもDockerだと最小構成で用意されてるから
ダウンロードの時間からして差があるし
誰かがDockerfileのようなものを公開してくれてるわけでもないし

懐かしくてちょっとググってみたけど、
あんな面倒なことやってたのかって思った
312login:Penguin
2018/08/05(日) 23:08:47.08ID:NroY7Fy3
>>309
自分だけの仮想アプライアンスを簡単に自作できるからねー
同じものを何度もセットアップしてるなら
それが簡単になるので楽だよ

せっかく頑張って構築したサーバーも
HDDが壊れたとかOSのアップデートでおかしくなったとか
古くなってリプレイスで再インストールとかで
やり直しになってしまうのはダルい

一度Dockerでイメージ作ってると
同じことを何度もやらなくてすむようになるからね
313login:Penguin
2018/08/07(火) 07:54:03.45ID:shK4WVTS
それだけのことならVMや自作rpmでもあんま変わらん…
314login:Penguin
2018/08/07(火) 08:50:58.74ID:FmqfeUYE
あんまり変わらないから、何倍も簡単なDockerの方が良いよね
315login:Penguin
2018/08/07(火) 09:01:08.27ID:FmqfeUYE
まあ一応VMや自作PRMが何故Dockerに太刀打ち出来ないかと言うと、

まずVMは仮想マシンなんだ。だから既存のマシンに導入することが難しい
既存のマシン上で動いても、仮想マシン故にネットワークに新たなマシンが登場するのと一緒だし、
NATで動かすならDockerに近い形状になるがメモリリソースを無駄に消費するし起動が遅い。
Dockerみたいにコマンド実行の速度で起動できない

自作RPMはDockerと真逆の考え方だな。実行環境を含めて依存しないようにしてるのに
頑張って他のパッケージとの依存関係を解決しないといけない
適切な依存関係になるように自作PRMを作る大変な作業が待ってる。
316login:Penguin
2018/08/07(火) 09:01:35.38ID:FmqfeUYE
自作PRMは可搬性がないからWindowsで動かせないってのもあるな
317login:Penguin
2018/08/07(火) 09:03:06.65ID:FmqfeUYE
ようするに、
1. 既存の○○と同じことができる
2. かつ既存の○○の問題を解決できる
これがセットになってるのがDockerなわけで

1.の既存の○○でもあんま変わらんと言われても
既存の○○は2.の問題があるでしょって話
318login:Penguin
2018/08/07(火) 09:43:33.53ID:svderS3e
ドヤ顔w
319login:Penguin
2018/08/07(火) 11:13:12.25ID:KYfMTuuE
             ___
            / ノ '' ⌒\  
          / ( ● ) (● )\
ドヤーーーーー / :::::⌒,   ゝ⌒:::::\ ーーーーーーー!!!!
        |      ト==ィ'     |
  _,rーく´\ \,--、  `ー'    /
. ,-く ヽ.\ ヽ Y´ /    ー   ´ノ ` ー-、
 { -! l _」_ノ‐′/\― 、  ,-/_|    ∧
. ヽ ゙ー'´ ヽ  / フ \     /ヽ     /ハ
 `ゝ、  ノ ノ  \   ヽ  / /
     _|\∧∧∧MMMM∧∧∧/|_
     >                  <
. | ヽヽ |   _/_ヽヽ |  ヽ|  |ヽ  ム ヒ | |
. ├─  ̄T ̄/  / /  ̄フ| ̄  | ̄| ̄ 月 ヒ | |
. |.     \  / ノ   / |  / | ノ \ ノ L_い o o
320login:Penguin
2018/08/07(火) 14:30:15.46ID:kww6lavE
一生懸命に覚えたことをレポートにまとめてるんだよ。
見守ってやろうぜ。
321login:Penguin
2018/08/07(火) 19:30:53.54ID:/C7ROP+b
なんかワロタ
322login:Penguin
2018/08/07(火) 20:10:59.70ID:QJmmm+eF
自分で書かなくてもMuninとかあるで。
323login:Penguin
2018/08/07(火) 20:28:26.91ID:KYfMTuuE
>>322
知ってる。昔会社で使ってた。
だけどあれじゃ俺がやりたいことを満たせないんだよ
機能は高機能だけど、あそこまでいらない
324login:Penguin
2018/08/07(火) 20:39:58.40ID:QJmmm+eF
Qiitaにでも書いとけ
325login:Penguin
2018/08/07(火) 20:42:05.65ID:KYfMTuuE
いわゆるインフラ屋はDockerを使って
ディストリによってパッケージが用意されてるようなものを
Dockerイメージ化するという発想になりがちに思える

つまりDocker使わなくても、普通にパッケージ入れたり
VM使えばいいだろという発想

違うんだよね。Dockerは独自に開発したアプリのために使う
独自に開発したアプリは、誰かが依存関係を
解決したりしてくれないからね

だからアプリが動く環境も含めてDockerイメージにする
そうすりゃDockerさえ動いていれば、簡単にどこでも動くものが作れる
326login:Penguin
2018/08/07(火) 20:42:24.72ID:KYfMTuuE
>>324  
             ___
            / ノ '' ⌒\  
          / ( ● ) (● )\
ドヤーーーーー / :::::⌒,   ゝ⌒:::::\ ーーーーーーー!!!!
        |      ト==ィ'     |
  _,rーく´\ \,--、  `ー'    /
. ,-く ヽ.\ ヽ Y´ /    ー   ´ノ ` ー-、
 { -! l _」_ノ‐′/\― 、  ,-/_|    ∧
. ヽ ゙ー'´ ヽ  / フ \     /ヽ     /ハ
 `ゝ、  ノ ノ  \   ヽ  / /
     _|\∧∧∧MMMM∧∧∧/|_
     >                  <
. | ヽヽ |   _/_ヽヽ |  ヽ|  |ヽ  ム ヒ | |
. ├─  ̄T ̄/  / /  ̄フ| ̄  | ̄| ̄ 月 ヒ | |
. |.     \  / ノ   / |  / | ノ \ ノ L_い o o
327login:Penguin
2018/08/08(水) 01:40:00.74ID:H2RB231p
VMはカーネルやデバイスノードがゲストに独立して用意されているからサンドボックスとして安心できる
これらをホストゲストで共有してるDockerは、ライフラインを共有しているゲストハウスみたいなもの
カーネルぶんのメモリ(敷金礼金)は浮くがinit以降のメモリ(賃料)は当然払わなければならない
起動も10秒以下の差
つまりデスクトップならVM常道
328login:Penguin
2018/08/08(水) 03:48:30.48ID:tyC3gFls
あぁ、またこれな

> 1. 既存の○○と同じことができる
> 2. かつ既存の○○の問題を解決できる
> これがセットになってるのがDockerなわけで

VMでもDockerでもサンドボックスとして安心できる
その上で、VMよりも軽いのがメリットなわけで
329login:Penguin
2018/08/08(水) 04:00:13.46ID:tyC3gFls
起動も10秒以下の差とかそれで勝負になると思ってるのか?

Dockerは1秒以下
$ time docker run -it alpine echo ok
ok

real 0m0.924s
user 0m0.046s
sys 0m0.031s


メモリ使用量はこんなもん
$ docker stats
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
d68483bb9e21 vibrant_raman 0.00% 868KiB / 30.38GiB 0.00% 5.89kB / 0B 0B / 0B 1

$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d68483bb9e21 alpine "sleep 1000" About a minute ago Up About a minute vibrant_raman


ディスク使用量も少ない
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
alpine latest 11cd0b38bc3c 4 weeks ago 4.41MB


マシンリソースを無駄にすること無く、サンドボックスを動かせる
330login:Penguin
2018/08/08(水) 04:18:39.40ID:tyC3gFls
> CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
> d68483bb9e21 vibrant_raman 0.00% 868KiB / 30.38GiB 0.00% 5.89kB / 0B 0B / 0B 1

ちなみにこれ、メモリリミットが30.38GiBとなってる
GPUメモリに1GB使ってて、つまり32GBのメモリを搭載したマシンなんだ

なんで(個人PCなのに)こんなにあるのかと言うと、
6年ぐらい前にOpenStack使ってプライベートクラウドを作るために
たくさんの仮想マシンを起動できるようにとMAXまで積んだんだ
(ちなみにDockerの登場は5年前の2013年)

仮想マシンだと、最低でも1台で数GBは欲しいでしょ?
VM1台で平均2~4GB割り当てるとして、約10台分。
プライベートといってもクラウドならこれぐらいほしいよね。

でもDockerが登場してプライベートクラウドの熱も冷めた
(本物のクラウドを使うようにしたのでもはやプライベートで作る気はない)
DockerならVM単位での起動じゃなくて、アプリ単位での起動になるので、
メモリは実際に使用した分しか使わず必要なメモリ量もぐんと減った
用途に対してかなりオーバースペックなPCになってしまったよw
331login:Penguin
2018/08/08(水) 04:26:57.73ID:tyC3gFls
> カーネルぶんのメモリ(敷金礼金)は浮くがinit以降のメモリ(賃料)は当然払わなければならない
あ、ちなみにこれ間違い

仮想メモリ間でのメモリ共有は一部のVMに搭載されているが(セキュリティのためにデフォルトは無効のようだね)
https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-F9111E35-E197-46EC-8350-77827A5A2DEC.html#GUID-F9111E35-E197-46EC-8350-77827A5A2DEC
基本的に仮想メモリ間でメモリは共有されないし、
当然空きメモリも共有されない

2GBのメモリを割り当てたVMは、その中でどんなに小さいプログラムを
実行しようがメモリは2GB使用する

VM(カーネルメモリ + プロセスメモリ + 空きメモリ) VS Docker(プロセスメモリ)

という比較になる。

Dockerだってカーネルメモリ使用するじゃん、なんで右側に書いてないのか?と
思うかもしれないが、ホストのカーネルを共有してるんだからこれで良い。
VMだって同じようにホストのカーネルメモリ書いてないだろ?
332login:Penguin
2018/08/08(水) 04:28:44.09ID:tyC3gFls
             ___
            / ノ '' ⌒\  
          / ( ● ) (● )\
ドヤーーーーー / :::::⌒,   ゝ⌒:::::\ ーーーーーーー!!!!
        |      ト==ィ'     |
  _,rーく´\ \,--、  `ー'    /
. ,-く ヽ.\ ヽ Y´ /    ー   ´ノ ` ー-、
 { -! l _」_ノ‐′/\― 、  ,-/_|    ∧
. ヽ ゙ー'´ ヽ  / フ \     /ヽ     /ハ
 `ゝ、  ノ ノ  \   ヽ  / /
     _|\∧∧∧MMMM∧∧∧/|_
     >                  <
. | ヽヽ |   _/_ヽヽ |  ヽ|  |ヽ  ム ヒ | |
. ├─  ̄T ̄/  / /  ̄フ| ̄  | ̄| ̄ 月 ヒ | |
. |.     \  / ノ   / |  / | ノ \ ノ L_い o o
333login:Penguin
2018/08/08(水) 04:40:02.13ID:tyC3gFls
ま、そもそもVMとDockerは違うもので、両方を組み合わせて使うものなんだけどね

クラウドを使っていればわかるはず。
VMを増やすと金はかかるが、新しいスペックのマシンを
手に入れることで、クラスタの合計性能が増える

Dockerコンテナを増やすだけじゃ、クラスタの合計性能は増えない
Dockerコンテナは一つの(仮想)マシンの中でCPUやメモリを
無駄にすることなく(サンドボックス化された)プロセスを複数起動したり
アプリのデプロイを用意(手元で動いたイメージをそのまま使うとか)にするために使う

目的が違うものなんで、Dockerの代わりにVMを使うとか
VMの代わりにDockerを使うとかいう発想がそもそもズレてる
334327
2018/08/08(水) 05:36:35.37ID:H2RB231p
>目的が違うものなんで、Dockerの代わりにVMを使うとか
>VMの代わりにDockerを使うとかいう発想がそもそもズレてる

そこだけは同意だな
そこまで理解できたなら賢いじゃないか
335login:Penguin
2018/08/08(水) 07:17:02.14ID:25daI1mK
序論、本論、結論まで到達?
336login:Penguin
2018/08/08(水) 10:38:16.92ID:tyC3gFls
>>334
何年も前から理解してるぞw

VMとコンテナをごっちゃにするなって書いたのは、違うスレだったか?

例えば>>76とか書いたの俺だが

> なぜならkubernetesの場合コンテナのオートスケールになるわけだけど
> 起動しているVMの中でコンテナをオートスケールするだけなので
> VMの数もオートスケールしないとコストは下げられないから

VMとコンテナは使い方が明確に違う(ことを理解してなきゃこんなこと書けない)
337login:Penguin
2018/08/08(水) 10:57:28.63ID:tyC3gFls
物理マシンもVM(仮想マシン)も、俺にとっては同じマシン扱いなんだわ
形あるハードウェアで形作られてるかそうでないかの違い。

そのマシンにアプリをデプロイする時にDockerを使えば、
そのアプリは同じマシンの他の環境の影響を受けないので
簡単にデプロイできる。

Dockerのメリットはアプリの配布と実行環境なんだよ
「アプリ+実行環境」でコンテナ化されるから、
LinuxやMacやWindowsに持っていっても動く。


簡単にまとめるなら、
 マシン(物理 or 仮想)の中 に
 アプリ(パッケージ or Dockerイメージ)をインストール

ってこと。

アプリをサンドボックス化するためにマシンを作るとか重すぎでしょw
まさに牛刀割鶏、鶏をさばくのに大きな牛刀を使うようなもの
338login:Penguin
2018/08/08(水) 11:01:18.07ID:tyC3gFls
それから「デスクトップ環境」の話
これはアプリか?って問われれば、アプリだと思う人はいないよね
複数のアプリを連携して作られた環境

仮にデスクトップ環境を作るならば、Dockerコンテナはアプリに相当するのだから、
複数のDockerコンテナを連携させるという話になる。
デスクトップ環境を構成する複数のアプリを一つ一つDockerコンテナ化していって
連携させるとか、大変なだけの環境の再発明でしか無い

ここからもわかるように、デスクトップ環境(=複数のアプリ+連携)なので
Dockerコンテナ(=アプリ)と比べるものでないのは言うまでもない話。

デスクトップ環境は誰かが大変な思いをして構成したものを使っていればいい。

物理マシン or 仮想マシン で動いてるデスクトップ環境やらCLIやらsystemdやら。
そこから起動する一つのアプリ、それがDockerコンテナ相当なんだよ
339login:Penguin
2018/08/08(水) 17:56:23.41ID:8+YiPWG6
GitLab運用してるんだが, CIで使うビルド環境とかは明らかにDockerないしはKubernetesが優秀
一時Docker-Compose on VMでやってたけど使い捨てVMを構築する処理が重くてしょうがなかった(しかも遅い)
スタンバイ状態のビルド環境VMを2つも作るともう限界だが, Kubernetesなら5個くらいPodをスタンバイさせてても余裕だし新規Pod作成も早い(Docker単体なら10コンテナ並走でもいける)
340login:Penguin
2018/08/08(水) 18:46:47.42ID:Gp7Qfh6x
夏休みだな
お前らが当たり前過ぎて書かないこともこうやって書いてあれば誰かの役に立つのだろう
341login:Penguin
2018/08/08(水) 23:00:30.67ID:tyC3gFls
>>339
Kubernetesって使用メモリ多くない?1GBぐらい使ってた気がするんだが
だから使わないってわけじゃなく、もうデファクトスタンダードに
なりつつあるから避けようがないと思ってるけど

Docker-Composeは開発者用だと思ってるよ。
ローカルマシンで複数コンテナを組み合わせる時の面倒さを解決するもの

>>340
お前のその書き込みは誰の役にも立たんけどなw
342login:Penguin
2018/08/08(水) 23:10:50.30ID:9RbiD8jy
ケンカはやめて(><)
343login:Penguin
2018/08/09(木) 06:19:00.25ID:/JzHzLjB
Docker-composeで使い捨てVMを構築するのが遅いというところがよくわからない。VM(dockerホスト)は一回構築したら終わりで、後はそこにコンテナを作ったり消したりするだけじゃないの?
344login:Penguin
2018/08/09(木) 13:04:39.32ID:xAQpubuL
>>343
今までの話の流れからすると、CIでテスト実行するたびにVMの作成と破棄をしていたってことでしょ?
>>327がVMでも10秒以下の差しか無いから問題ないみたいなことを言ってるから
(VMの中でDocker-Composeが動いてるのは、この話にあまり関係ない)


当たり前だけどDockerコンテナの起動に比べればVMの起動は遅い
起動の差を10秒以下にするには、VMのイメージを作ってないと不可能
あとできればSSDとかクラウド使うとか。それでもDockerの1秒に比べたら遅い


そして肝心のVMのイメージを作成するのに時間がかかるっていうねw
Dockerの場合はアプリの実行環境が含まれる。だから構築に時間がかかるVMは
色んな種類のアプリのテストに使い回すことができる。

Dockerを使わないなら、アプリを動かすためにVMのイメージに
実行環境を含めないといけない。当然アプリごとにVMのイメージが必要になる。

DockerでもアプリごとにDockerイメージが必要になるのは同じだが
Dockerはキャッシュがあるから、Dockerイメージの作成は短時間でできる。
VMだとキャッシュはないし起動に10秒かかるし、作成したイメージの
サイズもでかいし頻繁にVMイメージの作成なんかやってられないよ
345login:Penguin
2018/08/09(木) 16:12:56.70ID:+YyDvSZH
今までVPSとかで動かしていたものをコンテナ化してGCE辺りに移そうと思うんだけど
DBの保存や出力したファイルの保存はみんなどうやってるの?
結局マウントできるディスクが必要なんじゃないかってところで今頭を抱えてる
346login:Penguin
2018/08/09(木) 17:43:56.11ID:UwrKl0TS
>>345
まずアプリサーバーとデータサーバーを分けて考える。
Dockerでやる価値が高いのはアプリ

アプリサーバーには原則としてデータは保存しない
その前提を守っているならば、簡単にスケールできる
(VMインスタンスやDockerコンテナを追加することで性能をあげられる)

という話。


その場合にデータはどうするかと言うと、
データサーバーはアプリサーバーみたいに簡単に
台数を増やしたりできない

一番楽なのは、難しいそれらをクラウドが提供するサービスに置き換えてしまうこと。
つまりGCPであればCloud SQLやCloud Storageを使う
これらは信頼性も性能も(金額次第だが)高くできる。
347login:Penguin
2018/08/09(木) 17:47:52.88ID:UwrKl0TS
>>345
どうしても自力でやりたいならば、Dockerのボリュームという
機能を通してホスト上に保存するのが一番手っ取り早い

例えばMySQLであれば データディレクトリである
/var/lib/mysql をホスト上のディレクトリにボリュームで
マッピングさせる

MySQL ぐらいだったらシンプルだし事例も多いので簡単なんだが
何処に何を保存するのかよくわからんようなアプリは
それを把握することに時間を奪われるだろう
348login:Penguin
2018/08/09(木) 17:55:09.12ID:UwrKl0TS
>>345
> 結局マウントできるディスクが必要なんじゃないかってところで今頭を抱えてる

結局マウントできるディスクが~というのは
初心者がよく考えてしまうことなんだけど、
これは当たり前

なぜなら(物理マシン or 仮想マシン上で動く)Dockerコンテナっていうのは
(物理マシン or 仮想マシン上で動く)アプリと同質のものだから。
単にアプリの実行環境が、コンテナとしてアプリに一体化してるに過ぎない


アプリはデータを何処に保存する?
物理マシン or 仮想マシン上のディスクでしょう?
だからDockerコンテナもそれは同じことなんだよ

Dockerコンテナを使った時データの保存先をどうすれば良いのか悩むのは
Dockerコンテナがアプリと同質のものであることを理解してない証拠
349login:Penguin
2018/08/13(月) 18:09:32.79ID:v0wq29mQ
最近コンテナってものを知ったんだけど、上の説明だとフラットパックってのとの違いがわからない
スタンダロンなアプリじゃなく、ソフトウェア群の、何かしらのフロントエンドにドッカーが向いてるってこと?
350login:Penguin
2018/08/13(月) 21:26:12.80ID:nXCS+eUE
コンテナ自体が非常に難しい概念なんだよ
どうもLinuxの世界で発祥したもので、昔からLinuxやってる人でないとわからないらしい
「最近流行りのDockerなるものをやってみたい」というヤツには到底無理(俺含め)
351login:Penguin
2018/08/13(月) 21:45:54.13ID:xnhwDoUS
Solarisのゾーンがコンテナの先駆けじゃない?
352login:Penguin
2018/08/13(月) 23:10:29.77ID:XRxrVOUh
FreeBSDのjailとか?
cgroupの概念は含まれてないけどね
353login:Penguin
2018/08/14(火) 00:05:12.50ID:kAynbxnX
>>350
説明してる奴が「難しいこと理解した俺スゲー」ってのを
自慢げに小難しく語るのが問題なだけ

プロセス分離のためにcloneを拡張して名前空間を追加したよ
cloneだけだと不便だからunshareとsetns追加したよ
cgroupでVMのごとくリソース分配可能にしたよ
コイツラ直接イジるのは面倒だからコンテナエンジン作ったよ

基本この4ステップだけじゃねぇの?





…って言う俺もコンテナのこと全然知らんのだが
354login:Penguin
2018/08/14(火) 00:55:59.54ID:M/lw6/kx
>>350
技術を理解するのと目的を理解するのをごっちゃにしてるから

Dockerが解決する問題は(主に自分が作った)アプリをいろんな環境で
動かそうとしたら、アプリをぽんとインストールするだけじゃ動かなくて、
そのアプリが依存してるなにかまで環境を整えなきゃならないだろ?
だから発想の転換でアプリ自体に環境を入れてしまえばいいじゃないかってこと。
外部ライブラリを全部アプリに静的リンクするの発展形だよ
まずそこを理解しないといけない


技術だけ理解すると、やれjailがなんだとかcgroupがなんだとか、
そればっかり言って、なんのために作られたのかという目的を見失う。
その結果、同じ技術を使った応用例のVMの代わりにするのが目的だと勘違いする

コンテナという技術を知るのではなくて、どんな問題があって
それを解決するものがDockerなんだって理解するのが先
355login:Penguin
2018/08/14(火) 01:03:03.69ID:M/lw6/kx
補足だが、
> (主に自分が作った)アプリをいろんな環境で

なんで「自分が作った」と書いているのかというと
他人が作って、ディストロに収録されているものは、
それ動かすための、環境もすでに整えてあるから
それがディストロの大変な仕事なわけで。

だから自分が作ってないものを動かしてるだけの人は
(物理マシン or 仮想マシンの上に)ディスロの環境整えられてる
パッケージ入れて使っても同じじゃんって思ってしまう。
技術は理解していても、そもそもの問題を理解していから
Dockerが必要な理由もわからない
356login:Penguin
2018/08/14(火) 01:10:25.09ID:M/lw6/kx
>>349
フラットパックってのがよくわからない。
一般的な用語?ググっても見つからないんだが。

> スタンダロンなアプリじゃなく、ソフトウェア群の、何かしらのフロントエンドにドッカーが向いてるってこと?

既存のいろんなものをつく合わせて
スタンドアロンなアプリを作りましょうって話。

何かをやるためにDockerを使うと便利なんじゃなくて、
Dockerは「とある物」を作るための道具だよ

その「とある物」っていうのがスタンドアロンなアプリ
動かしたいアプリが、動かすのにアプリ以外の環境を整えることが
必要なアプリであっても、Dockerを使えばアプリに組み込んで
スタンドアロンなアプリに作り変えることができる

Dockerはスタンドアロンなアプリを「作るもの」
であって「動かす環境」ではないんだよ
そこを根本的に間違ってる人がいる。
357login:Penguin
2018/08/14(火) 02:08:41.28ID:kAynbxnX
>>356
https://flatpak.org/
358login:Penguin
2018/08/14(火) 02:29:21.54ID:Ttl7PXT/
カタカナでググったから見つからなかったのかw

Linuxデスクトップ向けアプリケーション仮想化機構「flatpak 0.6.13」リリース
https://mag.osdn.jp/16/10/26/153000

>  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でいいじゃない?と。
359login:Penguin
2018/08/14(火) 03:11:38.19ID:Ttl7PXT/
> なんで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作ったの?の答えは、エンドユーザーのために作ったパッケージを、
もっと使いやすく提供したいためだろう。
360login:Penguin
2018/08/14(火) 10:08:37.26ID:M6PcTN6D
別にコンテナの用途限定する必要は無いと思うけどなぁ。便利に使えたらそれでいいし。Dockerを○○に使うなって言うならその代替案も言って欲しいけど言わないし、仮に言えたとしてもそれはDockerで実現した方が簡単というオチになるのが目に見えてるし。
正しさとは都合。正しさを振りかざすのは自己満足を他人に押しつける行為。
361login:Penguin
2018/08/14(火) 11:51:58.01ID:kAynbxnX
ドッカーのスレだから、ドッカー万歳な人がいてもおかしくないよ
362login:Penguin
2018/08/14(火) 14:07:10.96ID:ghMKDHT1
>>368
> 別にコンテナの用途限定する必要は無いと思うけどなぁ。

制限なんかしてないよ?

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

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

だからコンテナを違う用途で使いたいなら、
別のスレに行くのが適切ってだけの話
363login:Penguin
2018/08/14(火) 14:12:08.48ID:ghMKDHT1
> Dockerを○○に使うなって言うならその代替案も言って欲しいけど言わないし

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

どうせシステムコンテナなんだろうが、
システムコンテナとして使いたいなら
LXD や OpenVZ を使えばいいだろ?
364login:Penguin
2018/08/14(火) 14:21:37.56ID:ghMKDHT1
ほらよ。スレ立ててやったから
コンテナを仮想マシン代わりとして使いたいならそっちに移動しろ

LXD コンテナを仮想マシンとして使う (Not Docker)
http://2chb.net/r/linux/1534223977/
365login:Penguin
2018/08/14(火) 14:30:00.78ID:ghMKDHT1
>>362>>360宛て
366login:Penguin
2018/08/14(火) 14:37:27.72ID:M6PcTN6D
LXDやOpenVZなんて知らんし、もしスレたてるとすれば仮想マシンとしてDockerを使うスレにするべきでしょ?
なんでそんなにDockerを仮想マシンとして使わないように誘導するの?おかしくない?
367login:Penguin
2018/08/14(火) 14:42:46.76ID:M6PcTN6D
Googleクラウドは仮想化なんか使ってなくて、物理サーバにコンテナ立ち上げてるらしいけど、あなたはGoogleがコンテナ使い方間違ってるからGoogleのインスタンス使うなって言うわけ?
368login:Penguin
2018/08/14(火) 14:48:15.40ID:M6PcTN6D
Dockerの使い方を縛らないと言いつつサーバ用途には使わせないように誘導するのすごく卑怯だよね。
声がでかくて社内政治だけがうまい奴に似てて、あなたに物凄い嫌悪感を持ったよ。
369login:Penguin
2018/08/14(火) 15:04:52.25ID:kAynbxnX
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を使うメリットってこれかな?
コンテナ知らん俺でも強力だとわかる
370login:Penguin
2018/08/14(火) 15:14:48.58ID:kAynbxnX
お前ら暑いからってイライラするなよな…

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

ご興味のある方はどーぞ
https://hub.docker.com/
https://flathub.org/
371login:Penguin
2018/08/14(火) 18:38:55.14ID:xLHQglRN
>>366
> LXDやOpenVZなんて知らんし、

無知を告白されても、勉強したら?で終わる話なんだが
知らないほうが悪いんですよ
372login:Penguin
2018/08/14(火) 18:41:22.43ID:xLHQglRN
>>366
> なんでそんなにDockerを仮想マシンとして使わないように誘導するの?おかしくない?

なんで仮想マシンの代わりとしてコンテナ技術を使うものがあるのに
仮想マシンの代わりとして使うことを想定してないDockerを無理やり使うわけ?
その方がおかしいでしょ。
どうせ間違った使い方をして、使いづらいと文句をいうのが目的なんだろう?
373login:Penguin
2018/08/14(火) 18:49:48.39ID:xLHQglRN
>>367
> Googleクラウドは仮想化なんか使ってなくて、物理サーバにコンテナ立ち上げてるらしいけど、あなたはGoogleがコンテナ使い方間違ってるからGoogleのインスタンス使うなって言うわけ?

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

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

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

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

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

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


> Googleのインスタンス使うなって言うわけ?
やっぱりその言い方をしてる所からすると
GoogleのクラウドとはGCPの事を言っているようだが、
GCPは仮想マシンを使っている
374login:Penguin
2018/08/14(火) 18:53:45.18ID:xLHQglRN
>>368
> Dockerの使い方を縛らないと言いつつサーバ用途には使わせないように誘導するのすごく卑怯だよね。

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

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

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

何度も言うが、コンテナの使い方は縛ってない。
375login:Penguin
2018/08/14(火) 18:59:38.16ID:xLHQglRN
>>370
> git likeを謳ってるからDocker hubなんかもあるのな
> flatpakのflathubよりは随分開発寄りな印象を受ける…サインインしてないけど

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

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

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

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


参考までに言っておくと非公開のDockerイメージを起きたい時は
プライベートリポジトリを使う。
GCPやAWSはDockerのプライベートリポジトリを提供している
376login:Penguin
2018/08/14(火) 19:28:34.72ID:kAynbxnX
>>375
ご説明どうも
LXC/LXDと違って配布とバージョニングが肝要なのね
377login:Penguin
2018/08/14(火) 20:07:26.17ID:Rn+J0ap2
>>377
シラネーヨバーカ。
お前が自分の正しさ振りかざして好き勝手なこと言ってるのがムカつくって言ってるんだよ。
絶対にお前と一緒の現場で働きたくないし、お前が上司だったら人事に文句言いまくって転職するわ。
378login:Penguin
2018/08/14(火) 20:10:09.80ID:J8E8MYcP
この怒涛の連レスと変な引用がWebやプログラム板の荒らしそっくりだ
379login:Penguin
2018/08/14(火) 20:35:54.31ID:xLHQglRN
> 377 名前:login:Penguin[sage] 投稿日:2018/08/14(火) 20:07:26.17 ID:Rn+J0ap2
> >>377
> シラネーヨバーカ。

俺も同意見である
380login:Penguin
2018/08/15(水) 01:16:08.69ID:ugls1Kd9
Dockerを使うと次のようなことできる?

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

<Docker>
□ □ □
| | |
==========⇒ホストのルーティングを使ってネットへ
381login:Penguin
2018/08/15(水) 01:17:35.73ID:ugls1Kd9
>>380
自己レス

Dockerコンテナの間違いでした。
382login:Penguin
2018/08/15(水) 13:20:10.69ID:uskt4Uvb
>>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
383login:Penguin
2018/08/16(木) 00:43:29.60ID:kHU6PfSr
>>382
レスありがとうございます。
参考にしたいと思います。

分からないので、ちょっと書籍を読んでいきます。
384login:Penguin
2018/08/17(金) 19:01:16.67ID:LyzN7uI2
dockerとちょっとしたサーバーあれば大規模ネットワーク作れそうだね
385login:Penguin
2018/08/17(金) 20:33:23.06ID:x+SQYw9w
大規模ネットワークを作るならkubernetesとか使うべきだよ
386login:Penguin
2018/08/18(土) 00:44:21.73ID:bBPq1AA+
>>384
大規模ネットワークは単にその手段ではないのか
387login:Penguin
2018/08/18(土) 08:03:42.49ID:o1onkvNG
>>386
レガシーの為にサマータイムを導入し、打ち水を都公認の暑さ対策として導入すべく水まいて地表の温度低下を計測するも湿度や不快指数は見ないこの国で手段とか目的とか言い出すのはナンセンスですよ
388login:Penguin
2018/08/18(土) 10:11:41.60ID:B/BAtWOD
国なんかに考え方決められちゃう人って・・・
389login:Penguin
2018/08/18(土) 11:00:32.73ID:S06djVVH
dockerで大規模ネットワークっていったら
もう考え方から変わってサーバーという概念がなくなる。

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

それを実現するのがKubernetes


ただ、理屈はそうなんだが現実として
そこまでのスペックは求められていないwww
390login:Penguin
2018/08/18(土) 13:41:20.07ID:B/BAtWOD
やっぱこのくらいの規模じゃないとあんま意味ないよな
https://kubernetes.io/blog/2017/02/inside-jd-com-shift-to-kubernetes-from-openstack/
391login:Penguin
2018/08/18(土) 14:41:29.39ID:S06djVVH
念の為に行っておくと、意味がないのはKubernetesね
Dockerはクラスタにすばやくアプリをデプロイするのに使われるが
Dockerそのものはアプリケーションの仮想化による
可搬性の高さがうりなので違うOSで動かしたりとか
同OSの他のシステムの影響を最小限にできるとかいうメリットが有る
392login:Penguin
2018/08/18(土) 15:46:56.84ID:bBPq1AA+
>>391
可搬性の高さのことをすっかり忘れていた。
ネットワーク単位を分けられることのメリットが自分にはおおきくて。
393login:Penguin
2018/08/20(月) 12:44:26.66ID:KhDqHNJn
コンテナの台頭で仮想マシンの未来に暗雲--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%)が続いている。
394login:Penguin
2018/08/22(水) 08:59:48.33ID:j+z99P2p
>>393
>企業は仮想マシンのライセンス料金に大きな不満を抱いているという知見を得ている。
>VMwareは自社の利益を追求するうえで、同社の社名に冠された仮想マシン(VM)に依存しなくなっている。
>VMwareがこれまで軸足を置いていた市場が、競合他社のハイパーバイザの台頭によって侵食されたのは事実だが、コンテナの登場によってさらに大きな影響がもたらされている。
>回答者の71%は仮想マシン上でコンテナを配備しているため、仮想マシンが姿を消すということはないだろう。仮想マシンの存在価値はあるはずだ。しかし、ITリーダーらは仮想マシンのライセンスコストを抑えたいと考えている。

この記事のベクトルがはっきりしない。
なにがいいたいのか?
395login:Penguin
2018/08/22(水) 13:19:31.20ID:pivahsct
頭の悪さが滲み出てくる記事だよな。
396login:Penguin
2018/08/22(水) 13:36:22.02ID:SRjEX/kw
自分の頭が悪いだけだろw
397login:Penguin
2018/08/22(水) 15:20:11.01ID:sHVRQKWS
18.06.1 が来てた
398login:Penguin
2018/08/23(木) 17:03:41.25ID:ZGFS8Yk4
試しに、公式のubuntuでコンテナを動かしてみたんだけど、

docker run -it ubuntu bash

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

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

DockerコンテナからIPIPトンネルを構築したいと考えていたんですが、
とりあえずラズパイ並みにつかえるようにするにはどうすればいいでしょうか。
399login:Penguin
2018/08/23(木) 17:48:33.28ID:q1z8N/B0
>>398
だからさ、Dockerは仮想マシンじゃないって
その中に入って色々作業するものじゃないんだよ

Dockerはアプリケーションコンテナなんだから、
そんなコマンドは必要な場合に入れれば良いんだよ
(必要になることは殆ど無い)
400login:Penguin
2018/08/23(木) 17:49:50.48ID:q1z8N/B0
いつになるかわからんが次スレまで行ったら
テンプレにしっかり書いてなきゃいかんな
401login:Penguin
2018/08/23(木) 17:55:02.79ID:7FvXZ15y
>>398
そいつのDockerfileな
https://github.com/tianon/docker-brew-ubuntu-core/blob/59aa7dfef17153ecc812adbf26516675ce67e8aa/bionic/Dockerfile

他のコンテナ作るときのベースだから本当にミニマムやで
402login:Penguin
2018/08/23(木) 18:41:12.97ID:ZGFS8Yk4
>>399
>>401
レスありがとうございます。
Dockerfileを見てみると、

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

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

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


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

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

環境ができたら、今度はそれを自分用としてイメージ化したい。
403login:Penguin
2018/08/23(木) 18:43:04.38ID:q1z8N/B0
>>402
> せめてラズパイみたいに使えるイメージがあればいいんですけど。
だからそういう使い方をするものじゃないから
希望するのが見つからいように思えるんだって
404login:Penguin
2018/08/23(木) 18:52:04.65ID:7FvXZ15y
>>402
Hyper-VでもKVMでもVirtualBoxでも好きなのを選べばいいぞ
405login:Penguin
2018/08/23(木) 18:52:37.87ID:AO6wJAqi
みた感じ、仮想マシン派もDocker派も両方ディスる猛者現るって感じだな
406login:Penguin
2018/08/23(木) 18:55:26.07ID:q1z8N/B0
> せめてラズパイみたいに使えるイメージがあればいいんですけど。
お前が欲しいと思うようなものはない。イメージは原則として自分で作るものだから。
使うイメージはDockerが用意したdebianやubuntuなどの
最低限のイメージのみ。それを元にして自分で作る

> 実験でホストを汚したくないので。
Dockerはそういうものの代わりとして設計されてないので
すぐにお前の実験はできなくなると言っておく。
それはDockerに問題があるのではなく、お前の使い方が間違っている
407login:Penguin
2018/08/23(木) 18:58:58.10ID:q1z8N/B0
ラズパイと同じ環境がほしいなら、
仮想マシンでRaspberry Pi Desktop X86でも使えばいいだろ

Dockerはアプリケーションに実行環境を一体化させるものだって
なんど言っても理解しないやつが湧いてくる
408login:Penguin
2018/08/23(木) 19:10:58.17ID:ZGFS8Yk4
すみませんでした。
自分でもっと勉強します。
409login:Penguin
2018/08/23(木) 20:06:23.78ID:NhXd7pKF
Dockerて、OSやアプリの仮想イメージファイルをコマンドで組み合わせ
メモリ上でつなぎ合わせて一つの仮想ディストリビューションをブートしたように
見せかけるソフトって理解でよい?
410login:Penguin
2018/08/23(木) 20:15:56.51ID:/Er2oz0C
全然違うかなー
411login:Penguin
2018/08/23(木) 20:47:22.20ID:AO6wJAqi
使ったこともないのに適当な事書くと常駐のスレ主に怒られちゃうからな
ちょっと調べた感じ、initなしでも動くそうだがゾンビプロセス問題とかめんどくさそうでマニアの領域
initから開始したらそれはそれで、それLXC(LXD)やん!って印象
412login:Penguin
2018/08/23(木) 21:22:51.21ID:jewCS8ED
>>409
WindowsのDLLヘル対策の超強化版って考えればいい。
知らん人は知らんかもしれんがw

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

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

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

アプリのDockerイメージの中に一切合切入れてしまいましょうっていうのがDockerの考え方
413login:Penguin
2018/08/23(木) 22:53:16.60ID:Rl2wmT+c
視野狭窄の輩がバージョンドシンボルの話と混同しそうな予感
414login:Penguin
2018/08/23(木) 23:04:39.22ID:YJtvG1Lc
Kubernatesの日本での呼び方って決まってるの?
会うひとみんな違う言い方するし
YouTubeで外国語聴いてもみんな結構違う
415login:Penguin
2018/08/23(木) 23:22:07.73ID:igELEe5F
>>414
こっちで
http://2chb.net/r/linux/1345027528/
416login:Penguin
2018/08/23(木) 23:42:56.02ID:YJtvG1Lc
>>415
誘導ありがとうございます。
向こうに書きました
417login:Penguin
2018/08/24(金) 00:06:45.21ID:wl1baohm
jewCS8ED が、あっちで、くうねるさんだーす と書き込みました。
418login:Penguin
2018/08/31(金) 09:43:02.97ID:UOMp0l5m
dock-composeで
全く同じ内容のDockerfileで
追加するファイルの中身だけ異なるイメージを2つビルドしたら
後でビルドした方はキャッシュの影響で先にビルドしたイメージと全く同じ内容になってしまう

イメージに名前付いてないけど
名前付けたら良いのか?
419login:Penguin
2018/09/03(月) 19:27:51.75ID:lFOQrHc5
>>418
名前変えずにbuildしたらキャッシュじゃなくてすでにimageに入ってるんで
作成されたイメージ一回rmiしないとダメなような
420login:Penguin
2018/09/04(火) 11:08:31.46ID:XGRY6CNs
--buildじゃだめ?
421login:Penguin
2018/09/09(日) 06:08:55.90ID:cEYtNNsu
>>389
それ、地震対策になるよね。
物理サーバーをまったく意識しない、
まるで半永久的なベースシステムがあれば、
コンテナをぜひ動かしたい。
422login:Penguin
2018/09/09(日) 09:40:19.57ID:ZTk8dQJu
それだけではならないですよ
423login:Penguin
2018/09/09(日) 10:55:56.07ID:e5pDDvY7
そのうちクラウドサービスがコンテナクラスタを用意して
コンテナ毎の課金とかになるんだろうな
424login:Penguin
2018/09/09(日) 11:12:04.98ID:ZTk8dQJu
そのうちもクソもコンテナのクラウドホスティングサービスは既にあるじゃん
425login:Penguin
2018/09/09(日) 19:24:56.20ID:Afzp+wKU
大手クラウドはGKE, AKS, EKSと揃い踏みなんだよなぁ
426login:Penguin
2018/09/13(木) 18:00:19.97ID:A2WBsHxK
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

この通りマウント元は存在するんですが、
どこ確認したら良いでしょうか…?
427login:Penguin
2018/09/13(木) 19:39:40.56ID:5kXiEAIj
ファイルをマウントしようとしているように見えるんだが、そこはディレクトリでないといかんのではないかと

あと何故2017年06月版を使おうとしているのだろう
428login:Penguin
2018/09/14(金) 09:15:35.43ID:O0WiB81l
>>427
あ、変に端折ってしまいましたが、
/usr/local/etc/docker/my.cnf.d/(ディレクトリ)も
全く同じエラーでマウントできていない状態です。

docker-ceが1703なのはsnappy版だからで、
ubuntu1804のOSインストーラーでdocker関連を選んだらそうなったから、です。
別にsnappyが使いたいわけでもない(というかsnappyとか今回初めて知った)ので、
明らかな設定ミスとかが見つからなければ、docke-ceを上げてみるのも手ってことですね。
429427
2018/09/14(金) 18:06:45.51ID:4XP848iF
- /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年以上前のバージョンを使わざるを得ない事情でもあるのかなぁ」って思っただけよん
430login:Penguin
2018/09/15(土) 07:01:30.83ID:yI+cCQi1
最新を追いかけてバグにハマる例は後を絶たない
431login:Penguin
2018/09/24(月) 01:08:42.35ID:3WJGu+tF
docker stop container
してから、commit するのはなぜ?
432login:Penguin
2018/09/24(月) 04:53:27.83ID:h/F6DQep
「docker commit」で検索!
433427
2018/09/25(火) 15:20:50.57ID:zdGJMagM
ファイルを指定しちゃダメだというのと
ホスト側ディレクトリの最期にスラッシュ付けちゃダメだというのはご指摘通りでした。
それらを避ければうまくいく場合もあるんですが、うまくいかない場合もあり
動作ロジックがわかっていないため切り分けられずにいます。

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しようとして失敗してるんでしょうか?
そのあたりの仕組みが理解できれば、解決できそうな気もするんですが…
434426=433
2018/10/02(火) 11:05:27.29ID:MTSGNvvZ
snapのsandboxが原因でした。
snapアプリケーションはスマホアプリみたいなもんで、
ホスト側ディレクトリの参照権限も大幅に制限されるということのようです。
/var/snap/docker配下なら如何様にもマウント可能でした。
お騒がせしました。
(433で名前間違えました。失礼しました)
435login:Penguin
2018/10/02(火) 12:26:31.40ID:ngnCMsef
>>434
おお、解決してよかった
ホストOSの挙動が独特だとトラブルシューティングも難しいね
436login:Penguin
2018/10/02(火) 14:05:12.80ID:jMGWfJIN
あー、そうだったのか。挙動的に誰かが制限かけてる感じだったから
selinuxかな?とは思ったんだが、言っていたらヒントになってたかもな
437login:Penguin
2018/10/05(金) 17:28:47.41ID:uwcVKd6M
先に要点を書くと、コンテナにスタティックルートを書く正攻法を知りたいです。

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

何かご存じの方、教えてください。
438login:Penguin
2018/10/08(月) 17:27:52.77ID:+G8YrS7/
docker使わずに仮装マシン使え案件な気がするが
439login:Penguin
2018/10/08(月) 18:31:01.90ID:dcwIe0qQ
うん。そう。毎回言ってるんだけどね。
Dockerを仮想マシンの代わりとして使うなと
Dockerコンテナは仮想アプリであって仮想マシンじゃない
440437
2018/10/09(火) 09:49:23.16ID:a4is0HOD
>>438-439
確かにdocker触り始めたばっかりなので
使い方とか概念理解がちょっと間違ってるのかもしれないですが、
逆に言うとこういう使い方が適切じゃない理由って何でしょう…?

OpenVPNをコンテナ化できれば(そして各コンテナにルーティングが書ければ)
Dockerfileだけ書いとけばVM同様可搬性も高くていいな、程度なんですが。
441login:Penguin
2018/10/09(火) 11:37:32.24ID:UEbDWUsW
>>440
Dockerが仮想マシンの代わりとして設計してないから
だから「これがあれば仮想マシンとして使えるのに」と
思うような機能は意図的に搭載しないので
仮想マシンとしては使いにくいんですよ

なんでもかんでも機能搭載して複雑にしていくのは
アホな日本人ぐらいなもん
442437
2018/10/09(火) 11:45:22.31ID:a4is0HOD
ルーティングを書く機能がともかく存在しないってことですね。
コンテナに好きなIPも振れるしゲートウェイも設定できるけど、
スタティックルートだけはあえて書かせないようにしている、と。

>>441
今回の例で言うと、OpenVPNはコンテナじゃなくてVMでやるべきって話ですよね?
設計云々はともかく実際なんで良くないんですか?
443login:Penguin
2018/10/09(火) 12:56:46.60ID:J/UkStG7
>>437
コンテナにrouteコマンド入れればいいじゃん
なぜよくわかってない拾いもので特殊なことをしようとするのか
444login:Penguin
2018/10/09(火) 14:28:29.84ID:lxGRoqO6
>>442
OpenVPNはDockerコンテナでいいけど、ネットワーク周りは仮想化か実機とかDocker外でやったほうがいいって気がする
445437
2018/10/09(火) 14:41:21.41ID:a4is0HOD
>>443

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

もちろん公式イメージに強引にrouteコマンドをブチ込むというのも
やってやれないこともないかもしれないですが、
それならコンテナ起動後netnsでrouteを送り込むとか、
諦めてホスト側でルーティングするとかの方がいいような。
446437
2018/10/09(火) 15:41:05.80ID:a4is0HOD
>>444
現実的にもそれしかなさそうですね。
ホストにルートを書いて回避しました。
447login:Penguin
2018/10/16(火) 14:04:47.68ID:JjMfngP+
Dockerのインストールは何でこんなにややこしいのかと
説明文を読み進めたらランチャーとは違うものだった
Dockと勘違いした
448login:Penguin
2018/10/26(金) 03:04:33.03ID:UuZWwwD+
Dockerがやはりまだ理解しきれておらず、、、

理解が全然違うか教えて欲しいのだけど、
nginx + uwsgi + flaskでサイトを開発したい場合は、ローカルでコードを書いて、
DockerfileにBusyBox + nginx + uwsgi + flaskを入れるように?設定して
docker buildを行うと、書いていたpythonコードと必要なコンポーネントが
まとまったdocker imageがサーバー上に出来上がり
docker runする事によりdocker imageから生成されてインスタンスが立ち上がる
であってる?
docker imageがclassでrunするとオブジェクトが出来上がると理解しているのだけれど、、、
449login:Penguin
2018/10/26(金) 06:35:45.90ID:xzHCVt/i
>>448
なぜあえてクラスとオブジェクトに絡めて理解しようとするのか。
450login:Penguin
2018/10/26(金) 07:03:02.70ID:Y5itkZBt
>>448
仕事で必要とかじゃなければ無理して理解する必要ないと思うよ
一般庶民が微分積分を理解できないように、一般プログラマにはDockerは難解過ぎる
451login:Penguin
2018/10/26(金) 07:40:58.49ID:S+WdRTJT
>>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コンテナなので少し面倒になる。使うのがお手軽なのは後者

ま、理解できてないのはこの話じゃなさそうだけどねwww
452login:Penguin
2018/10/26(金) 07:41:20.37ID:S+WdRTJT
>>450
× 一般プログラマにはDockerは難解過ぎる
○ お前にはDockerは難解過ぎる
453login:Penguin
2018/10/26(金) 08:01:47.31ID:BI6ZyjXf
「一般プログラマ」ってのがどのレベルなのかと。

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

どっちも「一般プログラマ」といえば一般プログラマ(苦笑)
454login:Penguin
2018/10/26(金) 09:37:10.67ID:UuZWwwD+
>>451
伝わらなくてごめんごめん
たしかにコンテナ分けると負荷が下がるとかは知りたいこととはまったく関係ない

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

一般プログラマーからしてdocker imageは関係ないのなら調べるのやめるんだけど、
インフラから事前告知があったので影響あるのかと不安になった
455login:Penguin
2018/10/26(金) 09:58:02.43ID:S+WdRTJT
>>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イメージができるんだから何も問題ない
456login:Penguin
2018/10/26(金) 10:06:27.87ID:S+WdRTJT
で、ウェブ開発の際に使う場合に、これじゃ使いづらい場合がある

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

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

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

ただね。Dockerイメージで作る実行環境は、本番用環境と同じにだいたいするので
デバッグなどはし辛い。だから通常のアプリ開発はDockerを使わないほうが楽だろう
だが、いつでも本番用環境を手元で作り出せると、本番用環境でのみ発生するバグなど避けられる
他の人も誰でも本番用環境で検証できるようになるわけだ
457login:Penguin
2018/10/26(金) 10:18:44.97ID:UuZWwwD+
>>456
すごいわかりやすい説明
コンパイラに例えてもらえると分かりやすいわ
ありがとう
458login:Penguin
2018/10/26(金) 10:20:16.70ID:S+WdRTJT
>>454
> インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
> なにか変わるのか事前に理解したくて。

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

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


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

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

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

理想は
 開発チーム・・・Dockerfileのメンテナンス(Dockerイメージを作成できるようにする)
 インフラチーム・・・Dockerイメージの実行
なのだが、現実としてDockerはインフラチーム主導で導入されることが多いので
インフラチームのサポートでDockerfileを作っていくことになるだろう
459login:Penguin
2018/10/26(金) 10:26:18.88ID:UuZWwwD+
今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね
460login:Penguin
2018/10/26(金) 10:29:10.46ID:S+WdRTJT
Dockerを仮想マシンの代わりとしてとか考えてると

> 調べていくとdocker runした後にdocker container pruneすると実行して終了したcontainerが
> パージされて変更内容がリセットされると書いてあったので、コードはdocker image作成時に
> コミットしてないとコード消えるのか???ってなってしまったわけなのよ

↑これとかで、混乱する。

Dockerは仮想マシンじゃないんだよ。

Dockerfileから作成したDockerイメージはビルドした状態から変更しないもの。(もちろん再ビルドはOK)
Dockerコンテナに乗り込んで、中身を書き換えて再イメージ化なんてこともしない。
できるけど、通常の使い方ではやらない

バイナリに例えれば、C言語のプロセスに乗り込んで(デバッガで?)
プロセスのメモリを書き換えて、プロセス部分をディスクに書き出すようなもんだよ
そんなことしないだろ?
461login:Penguin
2018/10/26(金) 10:34:41.20ID:S+WdRTJT
> 今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね

virtualenvといわれると、少し違和感があるな
VMよりずっとましだけど

virtualenvは実行環境を作るもの
Dockerは実行環境を含めた実行イメージ=Dockerイメージ=実行バイナリの凄い版を
作るものだから
462login:Penguin
2018/10/26(金) 10:39:21.79ID:UuZWwwD+
>>461
やっとそこの理解ができた
インフラがDocker推すのわかるわ

virtualenvのpython周りをなんとなくコンテナ化したのとはちがって、OS含めた実行環境コンテナを作れるとなると、ほんといろいろ解決できるな!
463login:Penguin
2018/10/26(金) 10:44:35.53ID:S+WdRTJT
例えばgoで作られたバイナリは、いろんなものがスタティックリンクされるので
単一のバイナリをコピーするだけで、あちこちでそのまま動かすことができる。
それと同じようにDockerもDockerイメージの中に、いろんなものが詰め込まれてるので
あちこちで動かすことができる

ちなみにDockerfileでビルドしたDockerイメージはDockerリポジトリにpushしておける
(パブリックな公式のDocker hubや、各社プライベートリポジトリ等がある)
そうしたイメージは手元でDockerfileからビルドしなくてもpullするだけで使える

バイナリをコピーするだけで動かすことができるように
DockerイメージをDockerリポジトリからpullしてくるだけで動かすことができる
こういうのは開発者にとっても便利だよね。

ウェブアプリだけじゃなくCLIコマンドもDockerイメージ化することができるから
goみたいにスタティックリンクされたバイナリが作れない言語で作ったアプリでも
Dockerだけが入ってるクリーンな環境で、いきなり実行することもできちゃうわけだ
464login:Penguin
2018/10/26(金) 10:56:20.22ID:S+WdRTJT
>>462
Dockerイメージを新しく(バージョンアップ)したから、
次からこれ使ってーって開発チームはインフラチームに依頼するだけでよくなる

インフラが気にするのはDockerイメージを実行することだけ
だからDockerイメージが起動さえすれば、物理(or 仮想マシン)の
OSを変えることだってできちゃう。
そのDockerイメージが動きさえすれば良いんでしょ?程度の気楽なもん


開発チームは開発チームで、物理(or 仮想マシン)のOSの機能に
(カーネル以外)依存しているわけじゃないので、
Dockerイメージのベースとなるディストリを変更したりなんでもできちゃう
物理(or 仮想マシン)のOSが変更になったって?別にOSのパッケージに
依存してるわけじゃないのでどうでもいいよ。程度の気楽なもん


いままでDebianベースでやってきたけど、ライブラリのバージョンが古いや
Ubuntuに乗り換えよう。なんてことも気楽にできちゃう

客先が使ってるマシンがCentOSだって? Dockerがあれば関係ない。
UbuntuベースのDockerイメージが、そのまま動く

本気でやれば、いろいろ解決するよ。ただそのためには
インフラチームに丸投げじゃだめだけどね
465login:Penguin
2018/10/26(金) 11:34:43.60ID:UuZWwwD+
>>464
ほんとベース理解できたら凄いわこれ
細かいホスト側?の設定はインフラに任せるとして
開発に影響のあるdockerfileの作り方も凝らなければストレートだね
これで環境周りのめんどくささからは解放される!
466login:Penguin
2018/10/26(金) 13:18:37.63ID:4wc3titV
chrootで仮想化するのを全自動で管理できるようにしたのがdocker、chroot以下構築のbashファイルに相当するのがDockerfile。
ツッコミどころ満載の説明だけど、概念はこれでおk.使い方はコマンド覚えろ。
467login:Penguin
2018/10/27(土) 19:48:50.40ID:5pOpML2z
は?
468login:Penguin
2018/11/01(木) 11:02:05.82ID:Ub4h8gMB
クソレスのせいで会話とまったな
466は反省しろよ
469login:Penguin
2018/11/05(月) 05:00:26.04ID:tQ7nIs7Z
シェルのコマンドで-pとか-vとか指定するのと
Dockerfileに書くのと
docker-compose.ymlに書くのと
どこにどうすればいいかがわからんわ
470login:Penguin
2018/11/05(月) 08:23:33.46ID:R14xwsxg
Dockerコンテナってラベル付ける機能あったんだ
長い事使ってるがそんな機能がある事自体初耳

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"
471login:Penguin
2018/11/05(月) 08:47:09.36ID:Thuf2ewx
>>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はイメージを起動するときのオプションというわけ
472login:Penguin
2018/11/05(月) 08:47:55.99ID:Thuf2ewx
>>470
> Dockerコンテナってラベル付ける機能あったんだ
ずいぶんと前についた気がするが?

昔docker-composeはラベル使っていなかったが、
途中でラベル使うように変わったよな
473login:Penguin
2018/11/07(水) 00:40:27.75ID:JZV5z18S
たとえば、あるソースをコンパイルして、
systemctl start serviceができるようにするには、
どうやってコンテナ作りをすればいいんでしょう。

privilegeを与えて、yumで開発環境投入して、
systemctl がつかえるように、serviceファイル設置して、
systemctl enable serviceのあと、shutdown したのち、
docker image化してはダメなんでしょうか??
474login:Penguin
2018/11/07(水) 00:52:45.66ID:v7o9U8jP
>>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のようなアプリケーションコンテナを仮想マシンとかして使うな。
無理やり使おうとしたその結果が、お前のその「どうやればわからない」という状況なんだからな
475login:Penguin
2018/11/07(水) 00:57:39.50ID:JZV5z18S
>>474
レスありがとうございます。

>Dockerでサービスが起動するコンテナを作ってあとはDockerに
>OS起動時に、そのコンテナを起動してもらえばいいだけ

ソースで提供されているプログラムをDockerコンテナで使いたい場合、
具体的にどうすればいいでしょうか。

コンテナに入ってから、
コンパイルすることしか想像できない初心者です。
476login:Penguin
2018/11/07(水) 01:11:12.42ID:v7o9U8jP
>>475
Dockerfileを使ってビルドするんだよ

コンテナの中に入るのは、ビルドがおかしいが原因がよくわからないとかで
調査するため。手作業でコンパイルとかしない

単純にDockerコンテナ内でビルドすると時間がかかったりイメージサイズが膨れ上がったり
するから工夫が必要なんだが、とりあえずそれは置いといて、一番単純な方法だ。

まずDockerfielを書く。Dockerfileには基本的に次のようなことを書く

・FROMでどのディストリをベースにしたイメージを作るのかを書く
・RUN(RUN yum~とか)でイメージの中にコンパイルをするのに必要なパッケージを入れていく
・ソースコードをコンテナの中に配置する
 (コンテナの外にあるソースをコピーしたりgitでcloneしたり、場合によってはボリュームを使う)
・プログラムをビルドする
・ビルドされたプログラムを起動するためのCMDやENTRYPOINTを書く

これで、ソースコードからビルドしたプログラムが入った
Dockerイメージが出来上がる。


あとは、dockerコマンドやdocker-composeなどでこれらを起動すれば良い
477login:Penguin
2018/11/07(水) 01:21:22.84ID:v7o9U8jP
>>476で書いたように、単純な方法を取ると、
アプリを起動するのに必要ないビルドツールのせいで
イメージサイズが大きく膨れ上がる。

レイヤー(例えばRUN)毎に差分が保存されるため
ビルドが終わってから削除してもイメージサイズは減らない

(一つのRUNの中ですべてを行う方法があるが、
キャッシュも使われなくなるのでイメージのビルド時間が伸びる)

こういう場合に使うのが multi stage build

アプリを使うためには、アプリの実行ファイル(とランタイム環境)さえあればよいので、
ソースコードから実行ファイルを作る所までをビルド専用イメージで行う
そしてその実行ファイルをコピーして使う別のイメージ(ビルドツールなし)を作るという方法
478login:Penguin
2018/11/07(水) 01:21:25.66ID:JZV5z18S
>>476
丁寧なレスをいただき、感謝いたします。
ありがとうございます。しかし、疑問が///

環境構築は手探りではダメで、
ビルドなどを含む全ての環境構築手順を、
スクリプト化できていないとダメなようですね。

Dockerfileでも、yumコマンドが扱われていることから、
ログインしてビルドコマンドを手打して動作確認するという従来の方法と比べて、
何が本質的に違うのかなと素朴に疑問です。

どうしてわざわざ、Dockerイメージづくりを自動化しなければいけないのですか。
できたイメージはtarで持ち運ぶつもりでいます。
479login:Penguin
2018/11/07(水) 01:25:02.67ID:JZV5z18S
>>477
脹れ上がりですね。
>ビルドが終わってから削除してもイメージサイズは減らない
知りませんでした。ありがとうございます。

英文ですが、さっきこれを見つけたところでした。
https://stackoverflow.com/questions/41688748/should-i-compile-my-application-inside-of-a-docker-image

勉強します。丁寧なレス感謝いたします。


脹れ上がり防止と、
dockerfileによるイメージ作成の自動化が焦点になっているという認識であっていますでしょうか。

ありがとうざいました。
480login:Penguin
2018/11/07(水) 01:29:04.85ID:v7o9U8jP
>>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とかでまとめておしまい
481login:Penguin
2018/11/07(水) 01:30:07.71ID:v7o9U8jP
まあどうしてもわからないなら、コンテナに入りつつ
ビルドしていって試してもいいけど、最終的には
Dockerfileにビルドするためのコマンドを書く
482login:Penguin
2018/11/07(水) 01:30:23.27ID:JZV5z18S
>>474
>Dockerでサービスが起動するコンテナを作ってあとはDockerに
>OS起動時に、そのコンテナを起動してもらえばいいだけ

ソースのreadmeは、Dockerコンテナを想定していないです。
すると、dockerコンテナ内で、systemctl enable serviceをセットして、
コンテナの起動によってそのサービスが起動するようにするしか私には無理そうです。

とすると、privilegeとか、なにか別の特権を与えてコンテナを起動して、
仮想マシンみたいにコンテナを動かすしか手が見つからないんです。
483login:Penguin
2018/11/07(水) 01:34:57.16ID:JZV5z18S
>>480
>そうすれば、RUN yum install パッケージが
>終わった段階のキャッシュの続きから実行されるから、
>手探りでやってるのと大差ない作業になる

続きから継続されるという仕組みがいまひとつピンとこないんですが、
知らなかったです。書籍も読んでいるんですが、あまり実践的ではないものが多いように思います。

最後にyumとかでまとめて御仕舞いというのは、
ワンライナーでかけるところはまとめて、dockerfileを作れということですね。
484login:Penguin
2018/11/07(水) 01:36:09.53ID:v7o9U8jP
>>478
> Dockerfileでも、yumコマンドが扱われていることから、
> ログインしてビルドコマンドを手打して動作確認するという従来の方法と比べて、
> 何が本質的に違うのかなと素朴に疑問です。

Dockerは動作確認するためのツールじゃねーし。何かを作るためのもの。
その何かっていうのはDockerイメージでありそこから起動するDockerコンテナ

そのDockerイメージやDockerコンテナを作るために、最終的にDockerfileを書くんだよ。

Dockerイメージ = 実行ファイル
Dockerコンテナ = 実行ファイルを起動したもの
と考える

アプリの実行ファイルの中にデータファイルを作成しないのと同様に
Dockerコンテナ・Dockerイメージの中にはデータファイルは置かない

つまり、Dockerコンテナ(イメージも)は壊してDockerfileから
作り直してもなんの問題もないわけだ
なんの問題もないし、実際にそうする。
485login:Penguin
2018/11/07(水) 01:36:15.87ID:JZV5z18S
>>481
ありがとうございます。

ずっと、どうしてコンテナに入って作業してはいけないのかが、
謎だったんですが、入って作業するのもアリなわけですね。
ホッとしました。
486login:Penguin
2018/11/07(水) 01:40:32.26ID:JZV5z18S
>>484
なるほど。

>Dockerイメージ = 実行ファイル
>Dockerコンテナ = 実行ファイルを起動したもの

とてもわかりやすい喩えです。

>つまり、Dockerコンテナ(イメージも)は壊してDockerfileから
>作り直してもなんの問題もないわけだ
>なんの問題もないし、実際にそうする。

Dockerfileさえあればいいってことがよくわかりました!


>アプリの実行ファイルの中にデータファイルを作成しないのと同様に
>Dockerコンテナ・Dockerイメージの中にはデータファイルは置かない

ボリューム(あるいはボリュームを用いたデータ専用コンテナ)を使えってことですね。
487login:Penguin
2018/11/07(水) 01:43:35.19ID:v7o9U8jP
>>482

> ソースのreadmeは、Dockerコンテナを想定していないです。
> すると、dockerコンテナ内で、systemctl enable serviceをセットして、
> コンテナの起動によってそのサービスが起動するようにするしか私には無理そうです。

無理じゃなくて調べろ。systemdを使わずにアプリを(フォアグラウンドで)
起動するやり方を調べろ。普通はその方法で起動する。


うん、だから、俺はDockerはインフラのためのツールと言うより
アプリ開発者のためのツールだって言ってるんだよ

インフラはアプリを作らない。だからDockerでアプリを起動しようと思ったら
そのアプリの起動方法を調べないといけない。よく知らないアプリの
起動方法やどこにどういうデータが保存されるかなんて調べるのは面倒だろ
仮想マシンでパッケージ使って起動すりゃいいんだよ。
パッケージ使ってりゃ依存関係とかディストリが解決してくれてんだろ
アップデートもやってくれるだろ

アプリ開発者の場合はアプリを作る。アプリ開発者ならsystemd使わない起動方法だって知ってる。
むしろsystemd使うほうが面倒。どこにデータを保存するかもわかってる。
アプリはディストリが用意するパッケージには依存したくない。アプリを動かすのに必要なものは全部管理したい
だからDocker使ってイメージを作るんだよ。あとはインフラにこのイメージ起動してって
ぽんと渡すだけでよくなる。
488login:Penguin
2018/11/07(水) 01:45:23.17ID:v7o9U8jP
>>485
> ずっと、どうしてコンテナに入って作業してはいけないのかが、
> 謎だったんですが、入って作業するのもアリなわけですね。
> ホッとしました。

それを作業って言うのが謎。調査だよ。作業じゃない。
コンテナでやった作業(ではないもの)は全て破棄されるんだから

コンテナに入るのは調査するためだけ
489login:Penguin
2018/11/07(水) 01:53:42.95ID:JZV5z18S
>>487
>無理じゃなくて調べろ。systemdを使わずにアプリを(フォアグラウンドで)
>起動するやり方を調べろ。普通はその方法で起動する。

目が覚めました!ありがとうございます。直接起動する方法を調べないと駄目ですね。
Linuxは柔軟ですね。(WindowsならSQL SERVERはフォアグランドで動かせなさそうだもの。)
いわば、クリスマスツリーの電飾から、一つだけ豆球を取り外して、乾電池につないで動かすようなもののように感じます。


>うん、だから、俺はDockerはインフラのためのツールと言うより
>アプリ開発者のためのツールだって言ってるんだよ
>あとはインフラにこのイメージ起動してってぽんと渡すだけでよくなる。

>>484の喩えを使って言えば、
スーパーアプリみたいな感じなのかな。


>アプリ開発者ならsystemd使わない起動方法だって知ってる。

冒頭でいいましたが、これはDockerと付き合う今の私に必要な言葉でした。


>アプリはディストリが用意するパッケージには依存したくない。
>アプリを動かすのに必要なものは全部管理したい
>だからDocker使ってイメージを作るんだよ。

Dockerとは、解体、原点に戻れですね。


丁寧にご指南いただき、本当にありがとございました。
とても勉強になりました!
490login:Penguin
2018/11/07(水) 01:54:23.86ID:JZV5z18S
>>488
よくわかります!
491login:Penguin
2018/11/07(水) 01:56:23.49ID:v7o9U8jP
> アプリ開発者ならsystemd使わない起動方法だって知ってる。
っていうのは、

自分で開発しているアプリなら、systemd使わない起動方法だって知ってる
っていう意味無

アプリ開発者はすげーから、なんでも知ってるぜーって意味ではないので
492login:Penguin
2018/11/07(水) 01:57:11.36ID:v7o9U8jP
訂正(意味無ってなんだよ?)

自分で開発しているアプリなら、systemd使わない起動方法だって知ってる
っていう意味な
493login:Penguin
2018/11/07(水) 01:59:57.97ID:JZV5z18S
>>491
>自分で開発しているアプリなら、systemd使わない起動方法だって知ってるっていう意味な

あー、よかった、そうですか。
ちょっと大変そうだと心折れかかっていました。
自分で作るプログラムならよく把握できていますものね。
494login:Penguin
2018/11/07(水) 02:08:54.57ID:v7o9U8jP
MySQLとかデータを大切に扱う必要があるものは
どこにデータが保存されてるかとかもしっかり明記されてるから
(クラウド使えよって思うが)Docker化するのは比較的楽だけど

WordPressとかウェブアプリとか、どこに何を保存しているのか
よくわからんものを、Docker化しようと思うよなって
インフラ屋がせっせと既存アプリをDocker化してるのを見てると思うよ

お前それ、信頼できるの?記事データはデータベースに保存されるから大丈夫みたいだが、
アップロードした画像とかデータベースサーバーじゃなくて
ディレクトリに保存されるじゃん? ちゃんと共有ストレージ使うようなってんの?
管理画面からプラグインの導入できるけど、プラグインははデータディレクトリじゃない所に
保存されてるよね?そっちの対応は大丈夫?とか気になってしょうがない
495login:Penguin
2018/11/07(水) 09:13:06.91ID:MDpN/AEY
補足だけど、systemdはパソコンの起動時に自動的に起動させるのが主な役目だからDockerのコンテナでも
起動時に起動させるのにsystemdを使ってもいいんですよ。
そのためには起動コマンドを調べる必要があるってことです。*.serviceのファイルを作成するだけで
systemd管理はできますが、*.serviceには当然起動コマンドを書く必要があるので。
496login:Penguin
2018/11/07(水) 11:48:41.20ID:v7o9U8jP
>>495
今の話は、Dockerコンテナの中でsystemd使うなって話な

Dockerはそういう用途で使うためのもんじゃないから
そんな事をしようとすると、ハマるんだぞ
追加権限が必要なのが何よりの証拠
497login:Penguin
2018/11/07(水) 12:15:05.51ID:MDpN/AEY
>>496
あり、レス読み間違えてたわすまん。
Dockerで中身いじるとしたらgitで遠隔操作するか、DBの永続化ぐらいで対応するのが常套だけど、
コンテナ内ならsystemdじゃなくてSupervisorがdocker公式になかった?
498login:Penguin
2018/11/08(木) 00:22:57.37ID:Ueh2RoXc
LXC, LXD(Linux Containers)だと、コンテナ内に入って、
アプリのインストールなど、環境構築できる

AWS でも使っている
499login:Penguin
2018/11/08(木) 03:09:23.40ID:NV3KMhMa
>>498
Dockerと、Linux Containerとは、
何が大きく違いますか?
Dockerはネットワークやコンテナの管理が便利だけどなあ。
500login:Penguin
2018/11/08(木) 03:11:15.01ID:NV3KMhMa
>>498
DockerもLinux Containerも、共にLinuxの独立分離機能を用いていると言うし。
501login:Penguin
2018/11/08(木) 03:29:19.31ID:KwyGHPnO
使ってる機能が同じでも、目的のために最適化されたツールになってる
だから、なにが目的かを正しく理解する必要がある。

Dockerはアプリケーションを仮想化することで
アプリケーションに可搬性をもたせるのが目的
Docker化したアプリはどこでも動かせる
その目的のために使う道具

LXCやLXDだとそれをやるのはとても大変だろう?
502login:Penguin
2018/11/08(木) 06:56:36.33ID:8m7pC1YT
https://qiita.com/Surgo/items/709a07d68c6eafbad267
503login:Penguin
2018/11/08(木) 08:04:08.58ID:AYcFG6pB
ありがとうございます。

>>501
LXCや、LXDだと、別のホストでは動作しないのでしょうか?

>>502
すみません参考になります。
504login:Penguin
2018/11/08(木) 08:33:22.59ID:KwyGHPnO
> LXCや、LXDだと、別のホストでは動作しないのでしょうか?

頑張ればできるんじゃね?
とてつもなく頑張ればw
505login:Penguin
2018/11/08(木) 15:05:12.27ID:Y2MwyzYh
18.09.0 が来た
506login:Penguin
2018/11/08(木) 15:36:35.47ID:rbD7hoQI
>>504
とてつもなく頑張ればw
条件付きだがライブマイグレーションできる>LXD
507login:Penguin
2018/11/08(木) 18:42:28.72ID:AYcFG6pB
>>506
マイグレーションが一番の魅力だから、
やっぱりDockerがいいなあ。
508login:Penguin
2018/11/08(木) 21:55:42.35ID:y26ltpJb
OpenVZでdocker動くかもと見たんだか、ほんと?
509login:Penguin
2018/11/08(木) 22:37:13.81ID:KwyGHPnO
Linuxカーネルに互換性があるなら動くんじゃないの?
510login:Penguin
2018/11/09(金) 00:00:17.07ID:0q/3jACl
6使ってたら2.6で当然動かないよ
見たことないけど7使ってるとこなら動くはず
511login:Penguin
2018/11/09(金) 08:00:07.01ID:XRMQbvdS
>>510
仮想マシンとは違うものね
512login:Penguin
2018/11/10(土) 17:54:47.28ID:ZYfU+HA8
7ですね
あまり需要ないかと思いますが、格安vpsで動くと嬉しい
513login:Penguin
2018/11/10(土) 19:16:43.39ID:2zo/Zkkd
格安VPSで7ってどこ?
普通に知りたい
514login:Penguin
2018/11/11(日) 14:14:06.80ID:6/dIT6k3
テケトーにググったら
>NTTPCコミュニケーションズ WebARENA VPSクラウド プラン10
https://web.arena.ne.jp/pdf/vpscloud_spec.pdf
コレでcentos7動いてるみたいだが
月額\360~
515login:Penguin
2018/11/11(日) 14:29:07.06ID:r372XCNT
>>514
その表を見る限りCentOS7が動いてるのはKVMだけ見たいだしホストがRHEL6なOpenVZでもCentOS7は動くよ(kernelに実装されてない機能は使えないが
516login:Penguin
2018/11/11(日) 14:34:03.19ID:r372XCNT
最新のstable採用してるとこんな感じでもちろんdockerは動かない
3.10ベースのtesting使ってサービス提供してるとこがあれば使えるはず
Ubuntu 16.04.5 LTS
Linux 2.6.32-042stab134.3 #1 SMP Sun Oct 14 12:26:01 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux
517login:Penguin
2018/11/11(日) 19:52:17.92ID:QlLSzGzd
KVMやXenはデバイスまで分離されてるからいいが、コンテナ環境を他人に貸すってすげぇな
518login:Penguin
2018/11/12(月) 04:52:51.03ID:i5PNL/7Q
>>517
共有サーバーだって貸していただろw
519login:Penguin
2018/11/13(火) 00:31:59.15ID:7b8arQTr
>>514
国内で360は安い、ありがとー
520login:Penguin
2018/11/13(火) 23:30:40.07ID:7+h48abB
>>519
安過ぎて、客が殺到して、
詰め詰めのサーバーのために性能が悪いとかないのかな?
521login:Penguin
2018/11/14(水) 00:18:45.33ID:f9otbk49
>>520
あるかもだけど、サービスの初期開発、プログラムの練習には持ってこいじゃないですか?
もしかして、time4vpsより安い?これ
522login:Penguin
2018/11/14(水) 07:34:31.11ID:hsvM7qsm
そういう用途ならvps使うよりクラウドのほうが安く抑えられると思うけど
523login:Penguin
2018/11/14(水) 07:42:38.54ID:Lj6Hvi7X
少し分かった
https://blog.arena.ne.jp/vps/891
524login:Penguin
2018/11/14(水) 12:18:34.69ID:fhtTOY8i
使う時だけ起動する感じなら、GoogleComputeEngineのプリエンプティブインスタンスが安く上がりそう
525login:Penguin
2018/11/21(水) 00:13:59.09ID:QNDci5dR
Docker上で仮想マシンを動かせるって本当?
526login:Penguin
2018/11/21(水) 04:02:22.73ID:GJ1WusOb
そりゃまあ仮想マシンなんてアプリに過ぎないので動くやろうな
527login:Penguin
2018/11/22(木) 04:54:44.46ID:Scei2IS6
>>526
動くやろうなじゃなくて、
これから主流になるらしいよ
528login:Penguin
2018/11/22(木) 06:02:39.07ID:3AQeAHWO
Dockerの上で仮想マシンとか
これもうわけわかんねえな
529login:Penguin
2018/11/22(木) 10:20:20.53ID:QKQbQ2kX
>>527
ならんよ。嘘ついてもバレる(嘲笑)

仮想マシンをアプリケーション化する意味がない

仮想マシンによって、仮想マシンの中のアプリと外のアプリの
連携が分断されるから、やる価値がない
530login:Penguin
2018/11/23(金) 13:00:20.01ID:76ZWcvaP
Dockerって、勝手にiptablesの設定を変更するのが気に入らない。
安易に使うとセキュリティーホールだらけになると思う。
531login:Penguin
2018/11/23(金) 14:12:16.80ID:AJrIkRMM
Xen+libvirtやLXCもiptablesの設定を勝手に変更するよ(deb系しか試してないけど)
でも合ってる設定だし、ポリシーがACCEPTのままなので自分でも設定しなればならないのに変わりがないから異論は無いけど
532login:Penguin
2018/11/23(金) 14:33:29.51ID:76ZWcvaP
>>531
レスありがとう。

どうせなら、docker runコマンドのポート解放のところで、
パス可能なソースIPでも指定できるようにすればいいのにと思う。
533login:Penguin
2018/11/23(金) 15:44:21.35ID:nUe3TP+/
>>532
それはファイアウォールの仕事
Dockerの仕事ではない
534login:Penguin
2018/11/23(金) 22:17:06.85ID:76ZWcvaP
>>533
だけど、ポートの解放はdocker runで行うよね
535login:Penguin
2018/11/23(金) 22:31:08.18ID:Oz3vE0x/
だけどやっぱりフィルタリングはDockerの仕事じゃないよね。
536login:Penguin
2018/11/23(金) 23:09:43.20ID:76ZWcvaP
>>535
せめて、デフォルトで外部から接続させないようにファイアホールを構成していればいいのにと思う。
ユーザーが必要に応じてフィルタリングルールを調整してはじめて、
外部からアクセスできるようにすればいいのにと思う。
フィルタリングが分かっている人が明示的にパスするようにするのがいい。

docker runでポート解放したら無条件でどこからでも通すなんて変だと思う。
537login:Penguin
2018/11/24(土) 00:32:00.55ID:6DgweZjB
>>536
Dockerは仮想マシンじゃないと何度言ったらわかるんだ?

Linuxでウェブサーバー起動したら、外部から接続できるのは
当たり前の話だろ
538login:Penguin
2018/11/24(土) 05:41:46.81ID:IIX6QWPN
>>530
>Dockerって、勝手にiptablesの設定を変更するのが気に入らない。

オプション付けろよ
539login:Penguin
2018/11/24(土) 06:20:40.88ID:bwmQjudn
>>538
ん?どんなオプションだったっけ。
iptablesのNAT設定を変更しないやつってあるの?
540login:Penguin
2018/11/24(土) 06:42:42.90ID:6DgweZjB
>>539
サーバー系の設定したこと無いんか?

MySQLのbind-addressはなんのためにあるのか知らないのか?
127.0.0.1 と 0.0.0.0 の違いを言えるか?
541login:Penguin
2018/11/24(土) 09:54:12.75ID:bwmQjudn
>>540
コンテナをホストのプライベートIPに結合するやつかな?
542login:Penguin
2018/11/24(土) 10:00:28.87ID:6DgweZjB
>>541
Dockerはシステムコンテナじゃなくて
アプリケーションコンテナなんだから、

普通のアプリを起動したのと同じ挙動をするのが一番正しい姿なんだよ
543login:Penguin
2018/11/25(日) 11:38:02.57ID:RawJ9w06
やっとコンテナできた。疲れた。12時間ぶっとおし、徹夜した。
544login:Penguin
2018/11/25(日) 13:33:06.09ID:i2El4ps2
同じ挙動ってなんだ?
iptablesいじられるのは無しってこと?
545login:Penguin
2018/11/25(日) 14:01:08.16ID:9lJSkKkT
>>537
ネットワーク繋がなきゃつながらないのが当たり前だろw

>>542
「同じ挙動」がどういう挙動か言ってみろよ。 ポート競合するのが正しいと思ってんのか?
546login:Penguin
2018/11/25(日) 16:47:54.23ID:AAm1jywp
>>545
> ネットワーク繋がなきゃつながらないのが当たり前だろw
デフォルトだと、どのポートでも受け付けてないはずだが?

> 「同じ挙動」がどういう挙動か言ってみろよ。 ポート競合するのが正しいと思ってんのか?
同一マシンでポート80で起動するサービスが複数あったら競合するのが正しいですが?
547login:Penguin
2018/11/25(日) 17:03:00.01ID:sYWkBqhY
最近俺が見たのはこんな奴だった

公式ドキュメント読まない
ヘルプ読まない
ぐぐらない
ぐぐれない
とりあえずやってみない
手順に書いてあることをなぞるだけ
コンテナとVMの区別がつかない
Docker無しでLA(E)MP環境が建てらんない
iptablesを手動でいじれない
548login:Penguin
2018/11/25(日) 17:19:54.21ID:yqgxEHl5
どうやってDockerを知って、動かすことができたんだ?
549login:Penguin
2018/11/25(日) 17:33:32.99ID:HRiXHrNh
>手順に書いてあることをなぞるだけ

多分ハケンか何かの業務でとか…
550login:Penguin
2018/11/28(水) 08:05:07.28ID:YBsTKCUy
[速報]AWS、独自のセキュアなコンテナ実行用マイクロVM「Firecracker」、オープンソースで公開。AWS re:Invent 2018
https://www.publickey1.jp/blog/18/awsvmfirecrackeraws_reinvent_2018.html
551login:Penguin
2018/11/28(水) 10:22:44.67ID:yT+2b7xe
>>550
なにがすごいのか?
552login:Penguin
2018/11/28(水) 15:28:42.96ID:7rRS23JC
>>551
コンテナがrootkitなウイルスにやられても
他のコンテナに侵入できない
なのに仮想マシンより軽量

普通のコンテナはroot取れば脱出出来る可能性はある
仮想マシンの脱出はそれよりは困難
553login:Penguin
2018/11/28(水) 16:22:47.55ID:LPYNLhdF
これぐらいなら馬鹿は出てこないと思って放置していたが
ほんとなんにでもくだらないレスするやつ来るな
まじでやってるなら本当の馬鹿だな
554login:Penguin
2018/11/28(水) 16:37:46.37ID:h8Zt5+LC
>>550
とりまビルドしてみたらサクっと通った
今時のツールはdockerでビルドなんだな…時代が進んで色々凄いコトになってる
つか使い方がよく分からんがw
555login:Penguin
2018/11/28(水) 16:42:44.50ID:/w7pvHqb
>>554
Dockerねぇぞって弾かれるよなワロタ
大容量のダウソ始まったからビルドやめたわ
556login:Penguin
2018/11/29(木) 14:41:36.81ID:nYOTnVc6
>>552
それはいいですね。
ハニーポットも運用できる?
557login:Penguin
2018/11/30(金) 16:24:21.34ID:wtQkclkF
>>555
つか何をするにもひたすらDLやでw

quickstart guide見ながらやってるけどうまく動かんわ
>set the guest kernel:
ココでハマってる
誰か上手く動かせたヤシ居る?
hello-rootfs.ext4 hello-vmlinux.binはDLしたし
AppendixにあるKVM Accessのチェックも全部パスした

エラーメッセージは↓
HTTP/1.1 400 Bad Request
Content-Type: application/json
Transfer-Encoding: chunked
Date: Fri, 30 Nov 2018 07:20:20 GMT

{
"fault_message": "The kernel file cannot be opened due to invalid kernel path or invalid permissions."
558login:Penguin
2018/11/30(金) 16:31:31.23ID:wtQkclkF
kernelは4.19
559login:Penguin
2018/11/30(金) 16:45:28.65ID:wtQkclkF
releaseからバイナリ落としてもダメなんで今回は諦めるワ
コッチはローカルビルドと違ったメッセージ出てたんでイケそうだったんだが
腐ってやがる早すぎたんだ

HTTP/1.1 204 No Content
Date: Fri, 30 Nov 2018 07:45:56 GMT
560login:Penguin
2018/11/30(金) 19:18:46.43ID:wtQkclkF
つか尼損犬糞でしか動きま千円って書いとけやヴォケ害人どもガイジか?
>Linux 4.14+
>KVM

動作環境とは何の関係もありませんが何か?w
561login:Penguin
2018/11/30(金) 23:24:39.25ID:/aBXqI4i
いまKVMでDocker動くようになったん?
562login:Penguin
2018/11/30(金) 23:54:35.49ID:49XVRgzf
>>561
今KVM上でDockerホスト運用しているけど。
両方CentOS7でね。
563login:Penguin
2018/12/01(土) 01:27:09.66ID:8oh/wD5x
DockerはKVMなどの仮想マシンと組み合わせて
使うのが想定される使い方なんだから最初から動いて当然

KVMなどの仮想マシンで、コンテナ専用の軽いディストリを起動して
その上で、Dockerコンテナを起動するんだよ。

Dockerコンテナ(=アプリ)にカーネル以外の動作に必要なものが
全てまとまっており、ディストリ自体にパッケージが不要になることで
実現できる設計
564login:Penguin
2018/12/01(土) 11:51:45.49ID:KGwrmve6
>>563
なるほど。
そのうちDockerホスト専用のディス鳥がでるかもね
565login:Penguin
2018/12/01(土) 12:24:30.22ID:5wSHzPIO
そんなもんとっくの昔からあるよ
で最近になってKVMの上でコンテナ動かすのがバズってきたのは、AWSがコンテナ専用の "KVMホスト" OSをリリースしたことに端を発している
これは小数の大きな仮想マシンでクラスタを組んでその上で沢山のコンテナを動かすという従来のやり方とは考え方が大きく違っていて、
コンテナの数だけKVM上で軽量なVMを立ち上げてその中でコンテナを隔離して動かすの
でコンテナは本当に単なるパッケージ化技術と成り下がる
コンテナによる分離はセキュリティ面でガバガバであり使い物にならない玩具である、というのがITビジネス界の結論というわけ
566login:Penguin
2018/12/01(土) 12:47:23.68ID:8oh/wD5x
> というのがITビジネス界の結論というわけ

という結論を語ってる所はITビジネス界には無いんで
安心して、生暖かく見てやってくださいw
567login:Penguin
2018/12/01(土) 12:52:02.59ID:M+reOwB1
コンテナごとにセキュリティソフト入れてますます重くなる未来
568login:Penguin
2018/12/01(土) 13:08:15.41ID:8oh/wD5x
そういや仮想マシンごとにセキュリティソフト買ってるらしいな
569login:Penguin
2018/12/01(土) 13:28:23.82ID:5wSHzPIO
パッケージソフトをウッキウキでクラウドで動かそうとしたら、
ライセンスがコピー単位でオンプレと何ら変わらない運用をするしかないというのはよくある話
570login:Penguin
2018/12/01(土) 13:55:02.53ID:dMaA0+/B
だからソフトウェア自体を売るんじゃなくて
クラウドサービスとして売る方向になってるのでは?
571login:Penguin
2018/12/01(土) 13:57:46.54ID:8oh/wD5x
そしてそれにはコンテナが適してるわけだよね
572login:Penguin
2018/12/01(土) 18:48:38.56ID:KGwrmve6
>>565
>パッケージ化技術と成り下がる

いいたい事はわかるが、成り下がってはないと思う。
573login:Penguin
2018/12/01(土) 18:50:29.39ID:KGwrmve6
>>570
自分で構築、保守してこそのコンテナの有難味だと思う
574login:Penguin
2018/12/02(日) 17:00:47.15ID:U/VULGsP
だからDockerはアプリ開発者が
自分のアプリを配布するのに使うものなんだよ

アプリ開発してないやつにとっては豚に真珠
575login:Penguin
2018/12/02(日) 17:30:21.64ID:MF2FYgWw
>>574
えー俺にも技術分けて下さいよ
dockerでドヤ顔したい
576login:Penguin
2018/12/02(日) 17:49:48.80ID:6ZB8i84m
仮想化環境であるが、仮想マシンではない。
仮想化環境であるが、アプリではない。
dockerはコンテナ型の仮想化環境を作成するソフトです。
それ以上でもそれ以下でもないだろ。
577login:Penguin
2018/12/02(日) 21:03:03.94ID:4PfKxqKJ
>>576
アプリの組み合わせ(=環境)をコンテナにまとめるのもありですよね
その場合、127.0.0.1で内部でアプリを連携させるのも良いですよね。
578login:Penguin
2018/12/02(日) 23:08:22.72ID:6ZB8i84m
>>577
そうそう、VMみたいにして使うときは目的に合わせてカスタムすればいい。
目的を定めて既存のサービスに組み合わせてdockerファイルを書く。
例えば開発環境にするなら同期をとファイル群をローカルネットワークのgitにするとかね。
dockerはクラウドと連携すると割と柔軟に何でもできる。
環境依存のファイルをクラウドに置いておく発想で。
579login:Penguin
2018/12/02(日) 23:27:57.41ID:uZcYlCvj
dockerは本来はアイソレーションやシステムリソース有効活用も担ってたはずでしょ
例のFirecracker的な思想だとそこはコンテナから切り離そうってことだよね
ここまでくると仮想化環境というより単なるポータブルなVMのディスクイメージと考えたほうが素直だと思うわ
580login:Penguin
2018/12/02(日) 23:35:52.62ID:6ZB8i84m
>>579
いや、環境だよ。どのPCでも同じ環境を再現できるってこと。javaの発想に近い。
静的なファイルだけ突っ込むってとこはいい理解だけど、それが環境なんだよ。
581login:Penguin
2018/12/03(月) 01:21:03.69ID:Yzd5rcYM
dockerfileって環境構築用のバッチファイルみたいなものだと理解しても良い?

コンテナのコンソールを使って順に環境構築したものをコミットしてイメージ作る場合と比べてどんなメリットがあるかな。
仕上がりのイメージファイルの容量が少なくなったりする?
582login:Penguin
2018/12/03(月) 01:24:29.67ID:tyMBE38T
>>581
chrootに依存してるって意味なら同じだろうけど、ディストリのパッケージに依存してるからそれが違うかな。
コマンド手打ちでも構築できるけど、不便だろ。
583login:Penguin
2018/12/03(月) 08:42:16.28ID:JGjM/vH1
マイクロVMが主流になるならもうコンテナいらなくね?
カーネルだけホストのものを使うことって無駄な環境依存を増やしてるだけで、従来のコンテナ技術との互換性以外にはもはやメリットがないような
環境依存部分を吸収するのはそれこそ本質的にはハイパーバイザー型仮想化の方が遥かに得意なわけだし
584login:Penguin
2018/12/03(月) 10:23:09.87ID:aEVyNKj/
そういうの解決するために各企業が新しいコンテナ技術生み出してる
gvisorみたいにコンテナとVMの中間みたいな物とかね
585login:Penguin
2018/12/03(月) 10:34:42.23ID:fAbMU4i+
KataContainersもgvisorと似たような思想だな
やり方はだいぶ違うみたいだが
586login:Penguin
2018/12/03(月) 13:07:27.92ID:gIBU2CPq
コンテナ型仮想化は初詮は捻じ曲がった過渡期のワークアラウンドだったってことだな
VMが重いのが問題なら軽くすればよい、それができないのは技術が未熟だっただけ
浸透し切る前に正しい方向に戻ってくれそうでよかった
587login:Penguin
2018/12/03(月) 14:55:45.66ID:Yzd5rcYM
>>582
dockerfile作る時も手打では?
しかもレスポンスが直ちに得られないので、
試行錯誤に時間がかかりそうに思う。

いまば、プログラム買いてその場で実行できるBASICインタプリタと、
cコンパイラを通す必要のあるC言語みたいな違いがあると思うんだけど。
一度完璧に書いてしまえば、後者の方がいいに決まっているけどね。
588login:Penguin
2018/12/03(月) 14:57:12.63ID:Yzd5rcYM
>>583
各VMごとにOSレベルのメモリ割り当てがいるから、
大量のメモリを消費するのでは?
589login:Penguin
2018/12/03(月) 15:10:08.50ID:3GtjRSNh
コンテナを動かすためのサーバーを管理したくないけど
AWS Fargateはまだまだ高い
590login:Penguin
2018/12/03(月) 15:33:23.06ID:zLBh6ucn
Lambdaで無理やりやるとか
つか安ければイイならSpotFleet以外の選択肢が(ry
591login:Penguin
2018/12/03(月) 15:49:40.97ID:ZaL3qC8p
Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある
592login:Penguin
2018/12/03(月) 19:18:38.19ID:zLBh6ucn
CRIだよね?>ORI
593login:Penguin
2018/12/03(月) 20:16:02.49ID:FS5rZSi9
>>588
firecrackerの場合1VMあたり5MBらしい。
594login:Penguin
2018/12/03(月) 20:32:01.47ID:tyMBE38T
>>587
あー、そういう見方あるか。chroot手打ちしなくていいってことだよ。
言いたいことはjvmとlinuxカーネルが実行環境に含まれてるってことよ。
linux環境じゃなくてもdockerは公式環境があるから。
595login:Penguin
2018/12/03(月) 22:26:31.99ID:n05/OnLG
>>591
やっとdocker-composeわかりかけて
きたとこなのに(>_<)
596login:Penguin
2018/12/03(月) 23:40:38.53ID:fVhmASLK
>>595
いやいや、docker理解できないと使えないから安心して
そもそも、個人開発でkuburnetes必要なくない?
597login:Penguin
2018/12/03(月) 23:52:43.40ID:fSc1+0qL
なんで個人開発限定?
そもそも個人開発でdockerなんか何に使うの?
コンテナ仮想化って個別にインフラを面倒見れないほどアプリがポコポコ作られるような組織で使うもんだろ
PaaSへのデプロイに使うくらいか?
598login:Penguin
2018/12/04(火) 00:19:15.25ID:ZNa428EC
>>591
> Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある

KubernetsってDockerを使うんだけど、なんで役割終えたの?
599login:Penguin
2018/12/04(火) 00:22:17.42ID:ZNa428EC
>583
> マイクロVMが主流になるならもうコンテナいらなくね?

またいつもの仮想マシンとアプリケーションコンテナをごっちゃにしてるやつだなw

マイクロVMが主流になったとして、じゃあどうやってこそにアプリをデプロイするんだ?
マイクロVMにRailsの実行環境入れ込むんか?
ローカルの開発マシンで動いているものを、そのままマイクロVMで動かすにはどうするんだ?
そういった問題が解決できてないだろ

コンテナは仮想マシンと組みあわせて使うということが全くわかってない
コンテナがあるからこそ、VMはマイクロで十分になったというのに
コンテナのおかげやで?マイクロVMが登場したのは
600login:Penguin
2018/12/04(火) 00:26:56.99ID:ZNa428EC
>>581
> コンテナのコンソールを使って順に環境構築したものをコミットしてイメージ作る場合と比べてどんなメリットがあるかな。

依存パッケージの更新とか手動でやりたくなくないだろ
お前は旧式のやり方しかしてないかもしれんがな、
こちとらDockerfileで1日に何度もイメージをビルドしてるんや
アプリが更新するたびにイメージ作り直してるし
カーネルや依存パッケージにセキュリティ対応が入ったら、
それを取り入れてまたアプリのイメージを作り直すんだよ
601login:Penguin
2018/12/04(火) 00:32:34.85ID:ZNa428EC
>>586
> コンテナ型仮想化は初詮は捻じ曲がった過渡期のワークアラウンドだったってことだな

マイクロVMがなにをそぎ落としてるのか知らんの?
様々なコマンドが入ってないんだが。
各言語の実行環境はもちろんのことpsコマンドすら入ってないだろうな
マイクロVMではサーバーは起動していない。NFSサーバーになる機能すらないだろう
パッケージマネージャーもないだろう。必要ないからね

マイクロVMはDockerコンテナを動かすのに必要な
最小限の機能まで縮小しているし、Dockerコンテナを動かすこと以外を
やることを想定してないから、単体では何も使えない

それわかってるのか?
602login:Penguin
2018/12/04(火) 00:35:04.84ID:GLtMD4eM
>>599
君こそコンテナ仮想化とパッケージとしてのコンテナを混同してない?
>>583は前者のことを言っていて、従来のLinuxカーネルを共有したハック(現在一般的にコンテナ仮想化と呼ばれるもの)がもはや役割を終えつつあるのは事実だ
一方でパッケージとしてのコンテナはもちろん必要だけど、それ自体はもはや仮想化技術でも何でもなく、文字通り単なるアーカイブだ
603login:Penguin
2018/12/04(火) 00:36:34.96ID:ZNa428EC
>>602
> それ自体はもはや仮想化技術でも何でもなく

「仮想化技術ではない」というのは具体的に
何ができないっていってんの?

それをお前が言えば、お前が間違ってることがはっきりするよ
604login:Penguin
2018/12/04(火) 00:38:18.61ID:ZNa428EC
「仮想化」という言葉の正しい意味をわかってないやつは、
仮想メモリと聞くと、ソフトウェアでメモリを作ることだって勘違いするからな
>>602はそのパターン
605login:Penguin
2018/12/04(火) 00:41:39.09ID:ZNa428EC
パッケージとしてのコンテナとか意味不明だし
仮想化しなければ、可搬性は実現できないだろうが
仮想化せずにどうやって、他のマシンで動かすことができるというのか

っていっても理解できないんだろうなw
606login:Penguin
2018/12/04(火) 00:56:48.20ID:ZNa428EC
>>583
> マイクロVMが主流になるならもうコンテナいらなくね?

apt-getもyumもついてこないよ
systemdも入ってないよ
libなんたらパッケージも入ってないよ
例えばnginxを動かそうと思っても、パッケージないし
パッケージの依存関係を解決してくれたりしないよ

コンテナ使わないでどうやってサービス動かす気?
苦労する気?
607login:Penguin
2018/12/04(火) 01:06:48.04ID:GLtMD4eM
だからパッケージングとしてのコンテナを否定してるわけじゃないんだけど、そんなに難しいこと言ってるかなあ
少なくともマイクロVMでコンテナを実行するのは従来の定義上はコンテナ仮想化とは呼べないでしょ
そして、せっかくマイクロVMによって遥かに高度な仮想化が実現可能になったのに、
依然としてホストのカーネルを使っていたのでは可搬性はdockerと同程度の低い水準のままだ
従来のコンテナ仮想化の仕組みを大きく見直す時期に来てるんだよ
608login:Penguin
2018/12/04(火) 02:12:00.01ID:HWYOaTBW
>>599
マイクロVMって普通の仮想マシンとどう違うの?
>>593
OSは入れなくていいのか?
609login:Penguin
2018/12/04(火) 06:51:27.56ID:ZNa428EC
>>607
> 少なくともマイクロVMでコンテナを実行するのは従来の定義上はコンテナ仮想化とは呼べないでしょ
呼べるんだけど?

仮想化したコンテナを動かしてるんだから
コンテナ仮想化に決まってる

仮想化しなかったら、その仮想マシンでしか動かないものになるんだけど?
やっぱり仮想化の意味を知らないようだね
610login:Penguin
2018/12/04(火) 06:57:34.00ID:ZNa428EC
>>608
> http://www.atmarkit.co.jp/ait/articles/1811/27/news146.html
ここに簡潔に書いてある

> Firecrackerは最低限の機能だけを搭載したマイクロVM
>  FirecrackerはKVM上で動作。その上で動くコンテナなどのために、
> ネットワーク/ストレージを中心としたシンプルなI/Oインタフェースを提供する。


> OSは入れなくていいのか?
通常のディストリではカーネルとユーザーランドを含めてOSとなるのだが
マイクロVMはカーネル(とメンテナンス用のわずかなツール)のみの提供と考えていい。

コンテナを動かすことしかしないのだから、
マイクロVMに(コンテナ以外)のものを入れる必要がない
逆に言えば、コンテナ以外を動かすのは不可能に近い。
611login:Penguin
2018/12/04(火) 07:01:33.17ID:ZNa428EC
>>607
> そして、せっかくマイクロVMによって遥かに高度な仮想化が実現可能になったのに、
> 依然としてホストのカーネルを使っていたのでは可搬性はdockerと同程度の低い水準のままだ

意味不明。マイクロVMはKVM(仮想マシンエミュレータ)で動く
コンテナ専用のディストリの一種に過ぎない

マイクロVMのカーネル=ホストのカーネル
マイクロVM上のコンテナ=マイクロVMのカーネルを使う

どちらも同じカーネルを使うことにななってるんだが?

ホストのカーネルってなんだよ?
612login:Penguin
2018/12/04(火) 07:07:21.45ID:ZNa428EC
マイクロVMは可搬性が高いわけじゃない
これは単なるディストリの過ぎないんだから

マイクロVMを他のPCで動かそうと思ったら
仮想マシンエミュレータが必要になる

Dockerコンテナは仮想化されてるから、
マイクロVMでも通常のLinuxでも動かすことができる。
コンテナ(=アプリ)が仮想化されてるから、
例えばローカルのLinuxマシンで複数のコンテナを起動することだってできる
そしてそのコンテナをそのまま変更せずに、マイクロVMで動かすこともできる。
"コンテナをそのまま変更せずに" ってところが重要。

マイクロVMで動かす時は、ポート番号を変更したり、
CPUの割り当て数を変更したりできる
"コンテナをそのまま変更せずに"
これができるのは、"仮想化されている"から
613login:Penguin
2018/12/04(火) 07:18:25.60ID:ZNa428EC
>>607は仮想化をプロセス分離の技術の名前だとでも思っているかのようだw

"メモリの"仮想化は、ハードウェアのメモリをエミュレータで
エミュレートするものでもないし、プロセス分離の技術でもない
メモリの仮想化は物理的なメモリ配置を隠して、どういうハードウェアでも同じように見せることを言う

もちろん"PCの"仮想化はハードウェアをソフトウェアでエミュレートすること
同じ仮想化でも、"何の"仮想化であるかで意味が違う。

マイクロVMというのはディストリの名前なので何も仮想化してない
仮想化しているのはエミュレータ(KVM)の方
もちろんこの場合の仮想化とは"PCの"仮想化

そして(Dockerの)コンテナが提供するのは、アプリケーション実行環境の仮想化

UbuntuでもマイクロVMでもCentOSでも同じLinuxであれば
どこでも同じように動かせるようにするアプリケーション実行環境の仮想化は
コンテナが提供している。このアプリケーションの仮想化がなければ
ディストリごとに専用に、セットアップ手順を書かないといけない、
aptを使ったりyumを使ったり。コンテナでアプリケーション実行環境の仮想化を手に入れたことで
Dockerを使うだけで簡単にコンテナを動かせるようになった。
そうすることで、ディストリ専用(例マイクロVM専用)のセットアップ手順を
作らなくて良くなったからこそ、マイクロVMという軽量のディストリができたんだよ
614login:Penguin
2018/12/04(火) 07:24:02.44ID:CnqUMfCF
>>598
KubernetsでDockerは使えるけど必須ではなくなったからな
将来的には使われなくなるでしょ
615login:Penguin
2018/12/04(火) 08:08:38.84ID:uhjJ5Me8
VM+カーネルの上でコンテナ(アプリケーション+ユーザーランド)が動くような形になっていくのかな。
616login:Penguin
2018/12/04(火) 08:43:23.80ID:N+FrKnXk
>>615
マイクロVMが一般的になれば次第にカーネルはコンテナ側に寄っていく形になるよ
VMベースの仮想化に移行すれば、特殊なバージョンのカーネルやLinux以外のコンテナを動かそうという試みはビジネスの要請によって確実に出てくる
ちょうど言語処理系が辿った道と同じで、最初は完全にホスト側によって使用するランタイムが決められていたのが
アプリ側の設定ファイルに基いてランタイムを選択するようになり、最終的にはアプリケーションに吸収される
617login:Penguin
2018/12/04(火) 09:23:15.31ID:ZrKf0azW
そんな銀の弾丸があるなら
もっとAWS Fargateを安くしろや!
618login:Penguin
2018/12/04(火) 11:01:16.91ID:vxBcBg/P
めんどくさいから結論が出て使いやすいソリューションが出てきたらでいいや
619login:Penguin
2018/12/04(火) 12:30:26.40ID:CvuFkzaO
まーたいつものガイジ2匹がレスバ繰り返してたのかよ
よく飽きねぇなぁ
620login:Penguin
2018/12/04(火) 16:39:04.08ID:ZNa428EC
>>614
知ってる知ってる。rktとかいうやつな
あれどうなったんだ?w

結局、Docker以外も使えると言う状況に満足して
終わりなんだよ。本気出してないからDocker以外普及しない
621login:Penguin
2018/12/04(火) 16:40:44.20ID:ZNa428EC
>>615

> VM+カーネルの上でコンテナ(アプリケーション+ユーザーランド)が動くような形になっていくのかな。

そういうこと、マイクロVMは何かの機能を搭載するのではなく
コンテナに任せることで限りなく機能を削減する方向を目指してる。

だからマイクロVMがコンテナになることはありえない。
マイクロVMはコンテナを使うという前提
622login:Penguin
2018/12/04(火) 16:53:36.87ID:ZNa428EC
>>616って結局コンテナを使いますって言ってるだけだよ。
マイクロVM関係ない。だってマイクロじゃないVMでもできることなんだから
マイクロVMは単に今のVMを置き換えるもので軽いってだけでしかない。

それ以外は今と全く変わないわけだから、コンテナ使いますよねって話
623login:Penguin
2018/12/04(火) 16:59:38.16ID:Yd5Bzjb0
「Kubernetes」に深刻な脆弱性
https://japan.zdnet.com/article/35129584/
> この脆弱性は深刻なものであり、共通脆弱性評価システム(CVSS)による深刻度は9.8(最大値は10.0)となっている。
624login:Penguin
2018/12/04(火) 19:13:19.70ID:ZpO6Qfl5
dockerの特色はリソースを節約しつつ環境を切り分けて管理しやすくするってことだから
docker動かすだけの鯖やVMならカーネルだけ乗っててdockerの依存関係だけインスコできるパッケージがあればいいって発想から
ディストリとかvmも小さいものや、専用のものを使いましょうってだけの話だろ。
リソースを気にしなくてすむのなら普通のlinux鯖で動かせばいい。
625login:Penguin
2018/12/04(火) 21:18:35.08ID:xoni3AYF
>>620
rktは違うわ
626login:Penguin
2018/12/05(水) 11:56:39.53ID:MMUcdQBe
>>624
それな。WinnyとかP2P世代のバカは仮想マシンを
「ウイルスに感染しても安全」な技術だと思ってる。(もちろん間違い)
ここで仮想化をセキュリティのためのものと思ってる奴がそうだろう

仮想マシン(VM)と仮想化は別のもの
仮想マシンは"ハードウェアを"仮想化したもの
コンテナはハードウェアを仮想化してないので、明らかに違うものを仮想化してるんだが
仮想マシンで仮想化してるから、コンテナで仮想化する意味がないという理屈のようだ
627login:Penguin
2018/12/05(水) 13:31:31.41ID:Z6qmzPvB
マルチテナントを考慮せよ
やり直し
628login:Penguin
2018/12/05(水) 13:49:10.40ID:p9AkVBP+
>>626
お前も、Docker世代のバカと呼ばれるんだろうな
629login:Penguin
2018/12/05(水) 13:56:57.76ID:Uz1/zr33
>>626
さすがに頭悪すぎ
どんなハッカーやウィルスをもってしても、VM内から同一ホスト上の別の客のVMに正当な方法を介さずにアクセスできてはならない
これがAWSが仮想化技術に対して要求する最低限のセキュリティだよ
クラウドベンダー各社がDockerをサポートし始めてもなかなかFargateのようなサーバーレスサービスが出なかった理由もそこにある
つまり、Dockerだけでは従来のハイパーバイザー型仮想化と同等の分離水準を実現できなかったんだよ
FaaSやCaaSの先駆者であるAWSがマイクロVMを必要としたのはそういう背景がある
630login:Penguin
2018/12/05(水) 14:36:07.36ID:t6HAOGba
>どんなハッカーやウィルスをもってしても、VM内から同一ホスト上の別の客のVMに正当な方法を介さずにアクセスできてはならない
こういうのまるっとガン無視して犬糞の鳥間バージョン間各種パッチ適用ごとの糞そのものの互換性のなさを
思考停止してとりまお気楽極楽に乗り越えて便利に使いましょいっていうのがドッカー()だと思ってたんだがw
631login:Penguin
2018/12/05(水) 14:37:16.80ID:t6HAOGba
>FaaSやCaaSの先駆者であるAWSがマイクロVMを必要
どこまでいっても業者のツゴーってコトだよなwww
632login:Penguin
2018/12/05(水) 15:10:55.91ID:Uz1/zr33
>>631
企業内の専有クラスタでもコンテナが乗っ取られたときの影響範囲とか部門間のアクセス制御とかあるからね
ウェーイwww系Webからビジネスへと足を踏み入れた途端に、Docker世代のバカには想像もできない複雑で広大な世界が広がっている
633login:Penguin
2018/12/05(水) 16:13:21.16ID:MMUcdQBe
頭の悪さは

> つまり、Dockerだけでは従来のハイパーバイザー型仮想化と同等の分離水準を実現できなかったんだよ

この一文に集約されてる。

Dockerはもともとハイパーバイザー型仮想化と同等の分離水準を
実現するためのものではない。それがわかってないと自白したようなもんだ
634login:Penguin
2018/12/05(水) 16:15:40.45ID:MMUcdQBe
それからもう一つ言うと、コンテナ間の分離機能というのは
カーネルが搭載しているコンテナの機能を使ってるだけなので
Dockerの問題じゃないんだわ。カーネルの問題
635login:Penguin
2018/12/05(水) 16:17:51.91ID:MMUcdQBe
最初から俺が言ってるように「Dockerは仮想マシンと組み合わせて使うもの」
なんだから、そういう分離は仮想マシンでやるからいいんだよ。

DockerはDockerの本質であるアプリケーション実行環境の仮想化に
特化すれば良い。こればかりは仮想マシンでは実現できないんだから。
636login:Penguin
2018/12/05(水) 16:19:30.90ID:MMUcdQBe
結局いつもの、Dockerを理解してない or 仮想マシンの代わりだと思ってる
理解の浅いやつが叫んでるだけでしたね。
637login:Penguin
2018/12/05(水) 16:23:38.48ID:t6HAOGba
>>632
solarisはdockerやるって言ってたけど今のところ見送りだからな
流石に長くOSやってるトコロはセキュリティに関する意識が全然違う
>>633
>Dockerはもともとハイパーバイザー型仮想化と同等の分離水準を
>実現するためのものではない。
ありとあらゆるトコロに地雷のように埋まってる腐れOSSの非互換性を解決するための
単なるお遊びレベルのコンテナシェア取り合戦なんだよなw
分かる分かるww
>>634
>カーネルが搭載しているコンテナの機能を使ってるだけなので
>Dockerの問題じゃないんだわ。カーネルの問題

いやいやいや下のレイヤに何を選ぶかはドッカ~の実装の問題だろw
カーネルの責任に転嫁するのはさすがに無責任極まりないwww
まぁOSS界隈のやり取りらしくて大変結構なんだがwww
638login:Penguin
2018/12/05(水) 16:26:06.60ID:MMUcdQBe
>>637
だから下のレイヤー(コンテナ機能)に問題があるってことですよねw
639login:Penguin
2018/12/05(水) 16:28:42.27ID:MMUcdQBe
Linuxカーネル標準のコンテナ機能以外に
コンテナってありましたっけ?
それともDockerが選んだLinuxに問題があると言いたいのかな?w
640login:Penguin
2018/12/05(水) 16:30:34.29ID:MMUcdQBe
Solarisはもう未来ないから・・・

米オラクルがSolaris関連の従業員をほぼ全員レイオフしたとの報道(追記あり)
https://www.publickey1.jp/blog/17/solaris.html
641login:Penguin
2018/12/05(水) 16:34:31.77ID:t6HAOGba
>>638
分離したいなら仮想マシン使えは現状そうするしかないんだが
>FaaSやCaaSの先駆者であるAWSがマイクロVMを必要としたのはそういう背景がある
何度も言うように業者のツゴーでそう言ってるバヤイじゃないってコトだろ
課金も絡むだろうからクラウド()に縛られてる情弱貧乏ユーザーどもにとっても死活問題だろうし
>>638>>639
>Dockerが選んだLinuxに問題があると言いたいのかな
問題アリアリだからドッカ~が必要になったんだろwww
つかソコをトボケてどうしたいのさ
犬糞ageっすか?w
642login:Penguin
2018/12/05(水) 16:36:34.75ID:t6HAOGba
>>640
安価なゴミ産廃で置き換えられていくのがITの歴史そのものだからやむを得んだろうな
まぁ今でもボラクルだけではなく不治痛からも買えるのでレガシーユーザーは困らん>solaris
643login:Penguin
2018/12/05(水) 16:42:04.53ID:t6HAOGba
つかドッカーのコンテナランタイムってドッカーさんちの自作ちゃうの?
644login:Penguin
2018/12/05(水) 16:53:03.46ID:MMUcdQBe
>>641
だからさ、なんで分離するとか言う話してんの?

Dockerは分離するためのものじゃないんだが?
やっぱりわかってないよね
645login:Penguin
2018/12/05(水) 16:53:44.57ID:MMUcdQBe
>>641
> 問題アリアリだからドッカ~が必要になったんだろwww

違うよ? やっぱりわかってないね。お前の書き込みが証拠だよ。
646login:Penguin
2018/12/05(水) 17:01:10.40ID:MMUcdQBe
仮想マシンとか分離の話なんか一言も出てこないからさw

「コンテナはデプロイと運用を再発明する」、レッドハットがコンテナ戦略を説明
https://cloud.watch.impress.co.jp/docs/news/1013903.html

 Dockerは、アプリケーション単位でコンテナを作ってパッケージ化する技術だ。
アプリケーションに状態を持たせずにスケールさせるクラウドネィテイブな手法や、
1つのシステムを単機能のサービスの組合せで作るマイクロサービス、
開発・デプロイ・運用のサイクルを早くまわすDevOpsといった、
新しい方式と特に相性がいいと言われている。

 アプリケーションをコンテナ化する価値として岡下氏は、アプリのデプロイと
運用に統一手法がとれ、シンプルにできることを挙げた。
647login:Penguin
2018/12/05(水) 17:04:35.60ID:MMUcdQBe
>>642
> 安価なゴミ産廃で置き換えられていくのがITの歴史そのものだからやむを得んだろうな

その理屈で言うとSolarisもその「安価なゴミ産廃」として
作られたものですからねw
いままでSolarisというゴミ産廃に置き換えられていった。

えぇ、お前の理屈だとそうなるって話です。
648login:Penguin
2018/12/05(水) 18:03:44.43ID:MMUcdQBe
>>643を読む限りコンテナランタイムの機能もどうせわかってないんだろうな
プロセスの分離とかをしてるのはコンテナランタイムではない
カーネルの機能を呼び出しているだけ
649login:Penguin
2018/12/05(水) 18:57:50.08ID:t6HAOGba
>>644
だから業者のツゴーだって言ってるじゃん
客がソレに全力で振り回されてる状況なんだが
まぁ尼損は今のところ王様の商売やってんなとは思うね
>>645
少なくとも数ある商用UNIXにはドッカーみたいなゴミはどこにも存在しない
犬糞のお陰で今までなかった問題が発生したのでそれを解決するやむを得ない戯術偽術の類だよ
>>647
>その理屈で言うとSolarisもその「安価なゴミ産廃」として
>作られたものですからねw
そらそうよw
ただ犬糞よりは断然筋がイイ
出自を見れば分かるだろ
>>644
>プロセスの分離とかをしてるのはコンテナランタイムではない
そりゃそーだろ
つかドッカーで全部のプロセスがルート扱いで動いちゃってるのはカーネルの責任!とかいう言い分かよw
650login:Penguin
2018/12/05(水) 19:25:01.48ID:MMUcdQBe
> つかドッカーで全部のプロセスがルート扱いで動いちゃってるのはカーネルの責任!とかいう言い分かよw

普通に実行ユーザーを指定すればそのユーザーでコンテナが動作しますが?
651login:Penguin
2018/12/05(水) 19:28:12.86ID:t6HAOGba
どーせソコまで安全側に倒しておかずに動かすこと優先でやってんだろ
ルートでは動かないように小細工されてるツールだけやむを得ず一般ユーザーで動かすとかさぁ
動いたらハイ!終わり!w
コレが一般的なデブオプス()のスタイルだろ
652login:Penguin
2018/12/05(水) 19:28:24.14ID:MMUcdQBe
>>649
> そらそうよw
> ただ犬糞よりは断然筋がイイ

Solarisはクソでした。あなたの理屈通りでした。
でもあんたの理屈は、あんたには適用されるが、
俺には適用されない。LinuxよりもSolarisはクソ
653login:Penguin
2018/12/05(水) 19:29:34.90ID:MMUcdQBe
>>649
> だから業者のツゴーだって言ってるじゃん
> 客がソレに全力で振り回されてる状況なんだが

お前が振り回されてるのはわかったが、
俺は別に振り回されてない。

Solarisの先行きが不安定なのに焦ってるのか?
654login:Penguin
2018/12/05(水) 19:30:17.66ID:t6HAOGba
>LinuxよりもSolarisはクソ
まぁその気持ちも分からんではないね
初心者ほどとっつきやすいモノがよく見える
デパートで売ってる服よかユニクロの服の方が好きなタイプだろ?w
655login:Penguin
2018/12/05(水) 19:30:31.18ID:MMUcdQBe
>>651
お前が適当な知識でやってるから、
それしかできないと思ってるのでは?w
656login:Penguin
2018/12/05(水) 19:31:40.16ID:MMUcdQBe
>>654
いいものが好きなんでLinuxが好きなんですよ。それだけです。
言われてみれば服もブランドに限らずいいものが好きだし、それと同じなんだろうな。
657login:Penguin
2018/12/05(水) 19:31:53.18ID:t6HAOGba
>>653
>Solarisの先行きが不安定なのに焦ってるのか?
ソコも業者のツゴーゆえ割り切らざるを得ない
筋の悪いドッカーも犬糞とクラウド延命のための一環だ
精々頑張ってくれw
658login:Penguin
2018/12/05(水) 19:33:26.29ID:MMUcdQBe
Solarisでびっくりしたのがようやく11になってから
ksh93が標準になったこと

それまでksh88やそれよりも古いBourne Shellがデフォルト
今2018年やで1988年って
659login:Penguin
2018/12/05(水) 19:34:08.37ID:MMUcdQBe
>>675
お前大変やな。
全部業者に依存してるからそうなるんやで
660login:Penguin
2018/12/05(水) 19:36:22.29ID:t6HAOGba
>>656
イイモノじゃなくて道に落ちてる出所不明なモノを拾い食いして
腹に当たったか平気だったかレポしてるのに近いなと思うねw
まぁコレはOSS全般に言えることだけどな
多数が狂ってればマトモな感覚のヤツがキチガイ扱いされても当然ではある
661login:Penguin
2018/12/05(水) 19:37:52.80ID:MMUcdQBe
業者の都合でLinux導入できないんだよ。でもそれがいいんだよ。
クラウドも導入できないんだよ。でもそのほうがいいんだよ
あのぶどうは酸っぱくてまずいんだよ

こんなところかね
662login:Penguin
2018/12/05(水) 19:44:58.18ID:t6HAOGba
>>658
フツーにユーザー作ったら標準でbashが動いたと思ったけど>solaris 11.4
今useradd試してみたけど間違いなく/usr/bin/bashが入ってきた
つかユーザーが過去に書いたスクリプトの互換性まで考えれば
下手にシステム付属のシェルは弄れない
>>659
オレに向けたレスか?ちょっと落ち着けよw
自分でコンテナ仮想化からOSカーネルまで全部書いてるのかね
凄い労力だなw
つかOSSの中身が業者がかりじゃないと思ってるとか何か純粋な人なんだなw
663login:Penguin
2018/12/05(水) 19:46:32.90ID:t6HAOGba
>>661
心配しなくても大丈夫
ちゃんと犬糞も使ってるからw
ただ檻に入れた上でごく限定的な用途でしか使う気しねえけどな
664login:Penguin
2018/12/05(水) 19:58:04.75ID:MMUcdQBe
>>662
それはログインシェル
まったく基本的なことすら知らないんだな

そんな奴が言ったってなんの説得力もねーわ
665login:Penguin
2018/12/05(水) 19:59:04.87ID:MMUcdQBe
最初から限定意的な用途でしか使ってないやつに、
深い知識を求めても無駄だな

Linuxインストールして満足しているやつらと変わらん
666login:Penguin
2018/12/05(水) 20:04:00.13ID:t6HAOGba
>>664
システム付属のシェルが古かろうと特に困らんてことを実例上げて説明したんだが
667login:Penguin
2018/12/05(水) 20:10:10.73ID:t6HAOGba
ちなみに古いバージョンのsolarisもコンテナとしてsolaris11上で動く
だから何の問題もない
668login:Penguin
2018/12/05(水) 20:45:44.47ID:MMUcdQBe
>>667
OSだけ動かしたってしょうがないだろうに・・・
本当に使いたいのはOSじゃなくてアプリ
669login:Penguin
2018/12/06(木) 00:39:07.15ID:YfDLncl6
ドカアッー!
670login:Penguin
2018/12/06(木) 16:29:06.10ID:0H7DsjYT
どっかアーッ!
671login:Penguin
2018/12/06(木) 19:29:31.33ID:A7t9PKkR
話の流れとは関係ないが、なんか一部で勘違いしている人が
いるようだから書いておくわ

俺はコンテナを仮想マシンの代わりではないと言ってるんじゃなくて
Dockerコンテナ = アプリケーションコンテナが仮想マシンの代わりじゃないと言ってる。
システムコンテナは仮想マシンの代わりになる

(Linuxの)コンテナ技術はカーネルが提供するものだが、
それ単体では、アプリケーションコンテナとしても
システムコンテナとしても使いにくい。

それをアプリケーションコンテナとして使いやすくしたのがDocker
アプリケーションコンテナとして使いやすくしているものを
システムコンテナとして使うとかネタでしょレベルだから

コンテナを仮想マシンの代わりとして使いたいなら
システムコンテナを使えばいい。俺はアプリ開発者だから
アプリのデプロイを簡単にしてくれるアプリケーションコンテナには興味があるが
仮想マシンの代替でしかないシステムコンテナは興味はそれほどない
672login:Penguin
2018/12/06(木) 19:39:15.11ID:52R6P0bW
>>671
の指摘する基本的な知識不足のやつと結局アプリケーションを使いたいだけってところのやつが入り混じってややこしくなってる。
仮想マシン立ち上げて単一アプリだけ動かしてるやつかもそうだし、
linux以外でdockerインスコするのにVMを知らずに入れてるやつとかもそう。
基本知識がないのに議論を始めるやつ多すぎ。
673login:Penguin
2018/12/06(木) 22:07:11.61ID:W7CcIDZc
>>671
privilegeを与えると、Dockerもシステムコンテナみたいになるという理解をしてもいいですか?
systemdが使えるので、けっこう便利にそうやってつかっているんだけど。
674login:Penguin
2018/12/06(木) 23:20:08.28ID:CjmGCUkG
>>673
そういう使い方もできるだろうけど、それなら lxc とか、lxd の方が
扱いやすいんじゃないかと思われ。
675login:Penguin
2018/12/07(金) 00:24:19.67ID:r4h+jkYy
システムコンテナとかいう謎用語はともかく、どんな用途のコンテナだろうが同一ホストでマルチテナントをやるなら高度な分離は必須だよ
クラウドベンダーが考えるコンテナ技術ってのは、デプロイや運用がPaaS並に手軽である一方で、
従来のPaaSのように特定のランタイムに縛られることがなく開発者の自由度が高い便利なプラットフォームを提供するための技術だ
どうしてもGoogleだのAWSだのクラウドベンダー発の技術には注目が集まりがちだけど、
そこには我々使う側ではなくプラットフォームを作る側の視点が強く反映されていることを理解しておかないといけない
そこを勘違いすると上で発狂してる子みたいな混乱に陥ることになる
676login:Penguin
2018/12/07(金) 00:40:32.21ID:JClhMg58
>>672
WindowsでわざわざVM動かしてLinuxもどきをうごかして、
そうしてからDockerを動かすなんて気持ち悪い。
677login:Penguin
2018/12/07(金) 00:45:22.04ID:Tm9Vcqu0
比較的安定したwinのGUIとコマンドの類が同時に手に入る
何も悪いことがない
678login:Penguin
2018/12/07(金) 00:55:25.89ID:tqGO7pdw
>>675
> どんな用途のコンテナだろうが同一ホストでマルチテナントをやるなら高度な分離は必須だよ

つまり、同一ホストでなく、またマルチテナントをやらないなら
高度な分離は必須じゃないってことですよね

それは「必須」という用語を使ってまで言わないといけないことなんですか?w
679login:Penguin
2018/12/07(金) 00:59:19.39ID:tqGO7pdw
>>676
別にw
Dockerの目的はアプリケーションの可搬性なんだから
VMを使っていようが、WindowsやMac上でアプリが動いて
まるでOS上で直接動いているかのように、localhost:ポートで接続できるなら
Dockerの目的は達成できてるんだよ

そしてWindows上でもMac上でもDockerイメージを作れて
それをLinux上でも動かせる。

アプリケーションの可搬性がDockerの目的(コンテナの目的なんていってない)
680login:Penguin
2018/12/07(金) 01:00:42.60ID:tqGO7pdw
>>675
> どうしてもGoogleだのAWSだのクラウドベンダー発の技術には注目が集まりがちだけど、

Dockerはクラウドベンダーとは一切関係ないよ
681login:Penguin
2018/12/07(金) 01:04:47.37ID:tqGO7pdw
どんな用途のコンテナだろうが同一ホストでマルチテナントをやるなら高度な分離は必須だよ
高度な分離を行うときは仮想マシンで分離したほうがいいよ
そしてDockerでその仮想マシンに簡単にアプリをデプロイ

このスレはDockerのスレなんだから、1行目と2行目はスレ違いなんだよね。
Dockerの目的は物理マシン、仮想マシン問わず簡単にアプリをデプロイすることだから
WindowsでもMacでもアプリをデプロイ出来る。もっともこの二つの目的は
アプリの開発だけど、WindowsやMacで開発してそのイメージを
Linuxでそのまま動かせるっていうのもDockerの目的の一つだからね
682login:Penguin
2018/12/07(金) 05:54:32.56ID:3ISGbBV6
Hyper-Vでドカッたらブルスク出た
683login:Penguin
2018/12/07(金) 09:16:55.56ID:YIG0ITu+
>>681
今更すぎて指摘するのもアホらしいが、LinuxコンテナはLinux上でないとビルドも実行も不可能
いずれはマイクロVM向けにカーネルも同梱したコンテナが標準化されて
ホストOSに依存せずにWindowsコンテナもSolarisコンテナも統一的に扱えるようになるだろうけど、
まだまだ先の話だね
684login:Penguin
2018/12/07(金) 09:51:15.00ID:tqGO7pdw
>>683
> 今更すぎて指摘するのもアホらしいが、LinuxコンテナはLinux上でないとビルドも実行も不可能

仮想マシン技術と併用すれば、Windows上でLinuxコンテナを動かせる
(ずーっと言ってるが、仮想マシンとDockerコンテナは使う目的が違っていて
併用して使うのは想定されているユースケースの一つ)

単なる仮想マシンと違うのは、仮想マシンが単なるマシンであり
その中にアプリをセットアップするのが大変で、ボリューム(仮想マシンで言う共有フォルダ機能を利用する)の
設定やまたlocalhost:ポート番号で接続できるようにネットワーク設定を行うのが大変ということ

これができてないのと、LinuxでLinuxコンテナを動かしているのと同じよう使うことは出来ないわけで
Windows(仮想マシンを使う)でもMac(仮想マシンを使う)でも
同じように使えるという環境をDockerは提供している

Dockerが背景の仕組みを解決してくれてるおかげで、
Docker buildするとDockerfileから同じようにアプリのイメージが作れ
Docker runをするとそのアプリが起動する。
そしてLinuxで動かしたのと何ら変わらず、localhost:ポート番号で接続できる

これがDockerが提供している機能の本質だよ
685login:Penguin
2018/12/07(金) 10:51:56.04ID:TC0/u8V/
仮想マシンの設定が面倒?そんな低レベルなことを問題にしてたのか
そんなもんコンテナだって本質的には違いはないわけで、Dockerがやったような適切な標準化さえなされていればどうとでもなる
必死に仮想マシンはアプリではないとの主張を曲げない君の姿、
Dockerが生まれたばかりの頃にこんなもんどこがアプリやねん仮想マシンやないかと言ってた老害と同じだよ
686login:Penguin
2018/12/07(金) 10:59:18.45ID:tqGO7pdw
> 仮想マシンの設定が面倒?そんな低レベルなことを問題にしてたのか

仮想マシンの設定じゃなくて、仮想マシンに入れるアプリの設定だよ
いつもどおり話が通じないな

で、ここでインフラ馬鹿は、パッケージ入れれば終わりじゃんとか
いうんだよなw

そうじゃなくて、自分たちで開発したアプリの設定(環境構築)だ
ずーっといってる。Dockerはアプリ開発者のためのものだって

アプリ開発にともなって、アプリが必要とするモジュール・ライブラリも変わってくる
アプリの高速なアップデートのたびに、今回新しくしたモジュールはないか?
あるならそれをどうやってインストールするか?OS標準のパッケージの更新が必要か?
更新して大丈夫か? ローカルの開発環境とバージョンはちゃんと揃ってるか?
テストもちゃんとそのバージョンで行ってるか?

そういったことを細かく把握しなきゃいけないのが大変だって話だ。
Dockerを使えば、開発マシンがWindowsであってもDockerfileという
誰でも同じやり方でイメージを作る方法があって、そのイメージをそのまま
実環境でも使える。そういった仕組みやツールを提供してるのがDockerなんだよ

ほんと、仮想マシンの設定レベルしか思いつかないんだからだめなやつだ
687login:Penguin
2018/12/07(金) 11:00:55.95ID:tqGO7pdw
> 必死に仮想マシンはアプリではないとの主張を曲げない君の姿、
仮想マシンをぽんと用意した所で、開発したRailsアプリは動かないからねw
仮想マシンはアプリじゃない。当たり前だ。
688login:Penguin
2018/12/07(金) 11:05:36.14ID:TC0/u8V/
だからOSのセットアップや運用管理が必要なのはコンテナだって同じだ
それを簡単にしたのはDockerが頑張ってそれを実装したからであり、コンテナだから楽になった訳ではない
Dockerと同等の簡便なワークフローをVMで実現することは技術的には普通に可能だ
689login:Penguin
2018/12/07(金) 11:12:21.01ID:tqGO7pdw
>>688
> Dockerと同等の簡便なワークフローをVMで実現することは技術的には普通に可能だ

そりゃ、 仮想マシンにDockerを入れれば可能だろうねw

もしかしてVMだけでコンテナを使わないで可能だって言ってる?
Linux上に仮想マシンを使わないで動かせるのがコンテナなのに
仮想マシンを使って作るとか、仮想マシンを使わないという条件を満たしてないんだがw
690login:Penguin
2018/12/07(金) 11:19:44.15ID:tqGO7pdw
マイクロVMはコンテナを動かすという前提があるから
あれだけ早く起動できる。
コンテナを使わないと仮想マシンは相当重くなる
691login:Penguin
2018/12/07(金) 11:21:03.34ID:tqGO7pdw
そういやSolarisってなんであんなに起動が遅いの?って思ったな。
VMだけ起動が早くても、そこで動かすSolarisがあんなに遅いんじゃ
使いものにならないだろうね。
692login:Penguin
2018/12/07(金) 11:32:05.74ID:JKnE+2X0
>>676
気持ち悪い云々は自由だけど、公式からもそういうツールがでてるし、一般的な運用なんだな、これが。
特に開発環境ではね。あとVMはWSLみたいなLinuxもどきではないぞ。
693login:Penguin
2018/12/07(金) 12:14:23.46ID:4ybr+TT5
そうそうVMはWSLみたいなLinuxもどきじゃない
エミュレートされるハードウェアは古いけどメジャーどころなのでそこらへんのノートPCよりも相性いい
694login:Penguin
2018/12/07(金) 12:15:26.87ID:tqGO7pdw
だからそのVMとDockerを組み合わせて使うんだよ
695login:Penguin
2018/12/07(金) 12:48:37.28ID:JKnE+2X0
dockerにセキュリティ不安があるのに流行るのは必要なリソースが少なくてすんで、環境を切り分けできるから。
dockerはlinuxネイティブに動作するから実機にするか、VMにするかはどっちが使いたいかぐらいの意味しかない。
とはいえ、一般的なネイティブアプリよりはdockerにはコストがかかるので単一のアプリじゃなくて環境そのものを扱うような場合がいいんだよ。
パッケージさえ揃えれば古い環境も再現できるし、保守はしやすいんだ。
マイクロVMのおもろいところは発展すればWSLなんかより遥かにいいから将来性はある。
それもソフトの発展じゃなくて仮想化支援のハードが出ればの話。
intelが仮想化に全力出せばOSを選択する意味はなくなっちゃう。
696login:Penguin
2018/12/07(金) 12:52:38.28ID:tqGO7pdw
> dockerにセキュリティ不安があるのに流行るのは必要なリソースが少なくてすんで、環境を切り分けできるから。

可搬性が高くなってデプロイが簡単になるからだよ。
環境が分離されるのは、可搬性を上げるためにそうういう機能が必要になるってだけ
697login:Penguin
2018/12/07(金) 13:00:01.85ID:tqGO7pdw
いくらいってもVMと比べることしか出来ないよなw

マイクロVMのだめなところは、別にOSをインストールしなければつかない所
698login:Penguin
2018/12/07(金) 13:05:33.68ID:JKnE+2X0
dockerと比べるならVMなんかじゃなくてsnapとかだよ。snapなんかの後継に根こそぎやられる可能性はある。
699login:Penguin
2018/12/07(金) 13:07:19.36ID:tqGO7pdw
dockerはアプリ開発者が、自分のアプリのデプロイのために使うもので、
snapとはまったく用途がかぶらない
700login:Penguin
2018/12/07(金) 13:08:59.77ID:tqGO7pdw
> intelが仮想化に全力出せばOSを選択する意味はなくなっちゃう。

OS使わないとアプリ動かないやんw
701login:Penguin
2018/12/07(金) 13:10:41.56ID:tqGO7pdw
どのOSでも使える。ということと、OSを選ぶ必要がないかは話が別だからな
702login:Penguin
2018/12/07(金) 15:44:32.66ID:Tm9Vcqu0
>>691
使ってる途中でユーザーの意思に反して勝手にOSにリセットが掛ったり
OSがフリーズして無反応になったのでサポに連絡すると
再起動しときましたー原因不明ですーというウェーイ系awsだと
そらOSの起動速度()は超重要なんだろうなwww
>>696
>可搬性が高くなって
犬糞はバイナリ互換性ガチ無視だからドッカ~みたいなキワモノに依存せざるを得ないんだろ
パッチ当てるたびOS更新するたびにアッチ動かなくなりましたコッチ動かなくなりましたと情弱どもが大騒ぎ
>>701
犬糞はドッカーが必要になるぐらいすぐにドコでも動かなくなる可能性が高い不安定なOS環境ってコトだろ
コトバを飾るなや
703login:Penguin
2018/12/07(金) 15:52:05.55ID:tqGO7pdw
>>702
OSの起動速度が重要なのは、一時的なアクセス数増加に
迅速に対応するためだろ

> 犬糞はバイナリ互換性ガチ無視だからドッカ~みたいなキワモノに依存せざるを得ないんだろ
バイナリ互換性があれば、デプロイが簡単になるという理屈をどうぞ
やっぱりDockerの目的がわかっちゃいねぇw

> 犬糞はドッカーが必要になるぐらいすぐにドコでも動かなくなる可能性が高い不安定なOS環境ってコトだろ
Dockerがあれば不安定なOS環境でも安定できるって
それ逆にすごくねw

Dockerの凄さをまざまざと見せつけられたw
704login:Penguin
2018/12/07(金) 19:38:05.59ID:Tm9Vcqu0
>>703
>OSの起動速度が重要なのは、一時的なアクセス数増加に
>迅速に対応するためだろ

awsでも客数の増減でイチイチ鯖をageたり落としたりしてんのかよ
連中のやってんのは課金上げて乞食ユーザーをスポットインスタンスから振り落とすコトだけだろうがw

>バイナリ互換性があれば、デプロイが簡単になる
バイナリ互換性がないからデプロイするたびにドッカーが必要になるってコトだろ

>Dockerがあれば不安定なOS環境でも安定できるって
ドッカーによって稼働中のシステム全体がコケるってオチだろw
まさにそびえ立つクソの山
705login:Penguin
2018/12/07(金) 21:48:15.71ID:JKnE+2X0
論理展開ができない人間と真面目に議論しても得るものなんかないぞ。さわるなさわるな。
706login:Penguin
2018/12/07(金) 21:59:50.50ID:tqGO7pdw
>>705
ホントだなw
707login:Penguin
2018/12/08(土) 12:31:08.24ID:jLrx7HKQ
What is the runtime performance cost of a Docker container?
https://stackoverflow.com/questions/21889053/what-is-the-runtime-performance-cost-of-a-docker-container

It doesn't work with Docker, K8s right now, but everyone's going nuts anyway for AWS's Firecracker microVMs
https://www.theregister.co.uk/2018/11/27/aws_sets_firecracker/

Firecrackerは今までのVMより速くなったとは言え、ベアメタルの95%を超える程度のCPUパフォーマンス
たかが5%されど5%

コンテナはCPUのオーバーヘッドはほぼ0
セキュリティよりパフォーマンスを優先したい場合や
セキュリティが必要ない開発環境では
今まで通りコンテナが使われるだろう
708login:Penguin
2018/12/08(土) 12:45:37.18ID:dieSV16U
FirecrakerはKVMベースで、それぞれのVMにカーネルが必要だが、
先の記事によればエミュレートする周辺機器を4つに限定してオーバーヘッドを削減している

ブロックデバイス
ネットワークインターフェイス
シリアルコンソール
VMを停止するためのボタンとして使うキーボードコントローラー
709login:Penguin
2018/12/08(土) 13:33:41.63ID:+Jbcoor3
またVMの話か。何度言っても理解できないようだな

Dockerが解決するのはアプリのデプロイであ
そのためにコンテナという技術を使い、
アプリケーション実行環境を仮想化することで
実現してるんだよ。

VMとDockerコンテナはそれぞれ役目が違うから
組み合わせて使うのがよくあるユースケースだ
Dockerコンテナ(=アプリケーションコンテナ)の有用性が
明らかになったから、コンテナ専用のマイクロVMが作られたわけだが
このマイクロVMで通常のOSを動かすのは難しいだろうな

Firecrackerで果たしてSolarisが動くかどうか
Linuxしか動かないVMになるだろう
710login:Penguin
2018/12/08(土) 13:38:22.40ID:+Jbcoor3
やっぱり想像通りだった。現状ではLinuxしか対応してない。
Linuxは組み込みとかにも対応してるから、最小限そういった
限られたハードウェアでも動く実績があるんだよ

でもSolarisのようなサーバー向けOSは、一定レベルのハードウェアを
前提にしてるから、いろんなところが依存してるんだろうな

https://firecracker-microvm.github.io/

What operating systems are supported by Firecracker?
Firecracker supports Linux host and guest operating systems with kernel versions 4.14 and above.
The long-term support plan is still under discussion. A leading option is
to support Firecracker for the last two Linux stable branch releases.
711login:Penguin
2018/12/08(土) 14:29:10.10ID:BjNmMfF8
Solarisとか言うオワコンwwwwww
あんたいつの時代から来たの?
712login:Penguin
2018/12/08(土) 14:43:53.94ID:L5TbyMsj
>>705
オマエは論理的なのではなく単に長い物に巻かれるのを良しとしているダケだろうがw
713login:Penguin
2018/12/08(土) 14:55:41.74ID:rWi9h0wU
>>712
悲しいかな、長いものが何一つ登場していないが、意味わかって使ってるか?
714login:Penguin
2018/12/08(土) 15:11:44.95ID:L5TbyMsj
>>713
自分が何をやってるのか(やらされてるのか)すら分かってないんだなw
アワレなやっちゃな
715login:Penguin
2018/12/08(土) 15:12:58.65ID:+Jbcoor3
>>711
だってUnix系ってSolaris以外オワコンじゃんw
716login:Penguin
2018/12/08(土) 15:23:23.21ID:L5TbyMsj
痛ニウム(とhp-ux)は無事死亡
ヨゴレIBMのキモイAIXは確実に客に避けられるのでエサ撒いたうえでRHを買収
バカを見たのは血道上げてRHのバグ潰しやってた不治痛とボラクルかw
あと散々販促活動してた五橋研究所www
717login:Penguin
2018/12/08(土) 15:27:36.57ID:BjNmMfF8
Solarisは既にOracleに殺された
もう先はない
718login:Penguin
2018/12/08(土) 15:32:43.14ID:L5TbyMsj
hp-uxはCiRCUSであんなに大成功したのに
それをシステムとして売り込んでも
ワールドワイドでの採用実績がほとんどゼロだったというのは逆に凄いと言えば凄い
日本的なITモノって白豚どもの拒否反応を引き出す何かがあるというか
ぶっちゃけどっかコワレてるんだろうな
やってる連中が島国根性だからなのか知らんがw
この辺のネット系サービスはチョンコや支那畜も成功例聞かないので
アジア系全体の問題かもだが
719login:Penguin
2018/12/08(土) 15:35:01.94ID:L5TbyMsj
ボラクルに頃されたというよりはいわゆるリーマンショックに頃された>Sun
中の人が言うには突然カネ入ってこなくなったらしいからな
ボラクルは一式揃って案外安かったので拾ったダケと言ってるな
まぁそれでも買ったのだからどうしようが連中の自由ってこった
720login:Penguin
2018/12/08(土) 15:37:14.59ID:+Jbcoor3
>>717
知ってる。採用候補になり得る最後のUNIXだった
あとはベンダーロックインされてしまって
抜け出せない所がUNIXを使ってる

わざわざクラウド移行時にUNIXを採用することもないし
そもそも大半のクラウドはIntel互換CPUなので
Solaris以外のUnixが動かないというのもある

結果、マイクロVMもLinuxに対応すれば十分という考えに行き着く
721login:Penguin
2018/12/08(土) 15:40:19.17ID:L5TbyMsj
>あとはベンダーロックインされてしまって
>抜け出せない所がUNIXを使ってる

それはLinuxを採用しても同じコト
RHと糞淫にベンダーロックインされてるダケ
それこそまさにawsにベンダーロックインされたがってるトコロすらあるw
722login:Penguin
2018/12/08(土) 15:43:59.74ID:L5TbyMsj
自分ダケはベンダーロックインから逃れられていると思ってる痛いコは居るかな?w

http://www.eweek.com/security/linux-kernel-developer-criticizes-intel-for-meltdown-spectre-response

"Intel siloed SUSE, they siloed Red Hat, they siloed Canonical. They never told Oracle, and they wouldn't let us talk to each other."
723login:Penguin
2018/12/08(土) 15:49:20.78ID:L5TbyMsj
ググるもPOWER採用でキモイやつら(666)のお仲間だってのはトックにバレちゃってるから
そっこらじゅうユダ公の息のかかったキモイ汚いモノだらけw
724login:Penguin
2018/12/08(土) 15:57:43.92ID:dieSV16U
Firecrackerってオンプレミスでも無い限り
自分で使う事は無いよな
FargateかLambdaを通して使うスタイル
725login:Penguin
2018/12/08(土) 16:14:26.42ID:+Jbcoor3
>>724
使う流れとしては

デプロイをもっと簡単にしたい
1. Dockerコンテナ化する

それを動かすディストリは、コンテナさえ動けばいいよね
2. コンテナ専用の軽量ディストリ採用

VMもコンテナ動けば十分だよね
3. FirecrackerなどのマイクロVM採用

という流れだよ。

Dockerコンテナ化は目的があって行うことだが、
それ以外は、必要ないから減らすという考え
726login:Penguin
2018/12/08(土) 16:18:36.37ID:L5TbyMsj
ドッカー野郎がPC使って調子こいてられるのもSunがvboxに投資してたからだろ
docker toolboxなんてまさにまんまそれだ
MySQLもそうだ
イケてないライセンスのvmware(player含む)だと何もできない
翻ってRHはどうだ?win上で動く実用的なx86仮想化の技術なんて何も持たねえだろ
これだけ見てもSunがドンだけ先見て投資してたのかってハナシだよ
自社開発したチップの外販すらできんグズで消費するしか能のないググるとは比較にならない
727login:Penguin
2018/12/08(土) 16:22:32.04ID:+Jbcoor3
なんでvbox? LinuxでDocker使うのに仮想マシンはいらないし、
WindowsとmacOSでは仮想マシン使ってるけど
もうvboxは使ってないくて、両方共OS標準の仮想マシン使ってるし
特にWindowsではvboxはDockerと同居できなくなったんで
もう数年使ってないよ。
728login:Penguin
2018/12/08(土) 17:01:23.32ID:ctzZZ9Ht
口だけのエアプだから知らないんだろう
729login:Penguin
2018/12/08(土) 17:17:22.07ID:dieSV16U
Fargateは自動的にVMを確保してくれて
便利だが比較的高い
従来からあるEC2の方が安いが、コンテナを動かすVMは自分で管理する必要がある
ジレンマ
730login:Penguin
2018/12/08(土) 18:23:26.70ID:L5TbyMsj
>WindowsではvboxはDockerと同居できなくなったんで
フツーに同居してるけどな
問題なくdocker machineも動いてるし
何かの間違いなのかな
731login:Penguin
2018/12/08(土) 18:37:17.06ID:L5TbyMsj
Solaris同梱のkshのバージョンがが古いとのたまい乍ら
サポ切れバージョンの犬糞をドッカープル()することにはダンマリ
こういう手合いをダブスタ野郎と言うw
732login:Penguin
2018/12/08(土) 18:53:52.19ID:dieSV16U
Hyper-Vを利用しているとVT-xは利用出来ない
同時に利用はできず、片方だけ使える
そしてVT-xはVirtualBoxに必要

>>731
意味不明
ちゃんと更新すれば良いだけだろ?
733login:Penguin
2018/12/08(土) 19:01:40.23ID:PaHNzXQu
もう相手にするなよマジで
734login:Penguin
2018/12/08(土) 19:14:36.46ID:dieSV16U
Docker for WindowsはHyper-Vを利用し
Docker ToolboxはVirtualBoxを利用する

さらに、最近ではWindows Subsystem for LinuxでVMなしで動かせるようになったようだ
WSLのcgroupsやiptablesなどのサポートが改善された事による成果だ

https://github.com/Microsoft/WSL/issues/2291#issuecomment-438388987
735login:Penguin
2018/12/08(土) 19:44:38.54ID:+Jbcoor3
「pullして使う」っていうのも発想が
アプリ開発者じゃないって感じるよな

dockerはビルドして使うものだからね
そもそもアプリ開発者が、自分で開発したアプリをデプロイするために
アプリと実行環境をイメージとしてまとめるっていうのが主な使い方なんだから

ベースとなるディストリは、更新すりゃいいだけ
それがすぐに簡単にできるようにDockerfileがあって
新しいディストリへの更新は数分程度で終わってしまう

それがVMやコンテナ単体では出来ないことで、Dockerが解決している問題
736login:Penguin
2018/12/08(土) 19:50:23.58ID:rWi9h0wU
アプリ開発者のためだけのものではないぞ。念の為に言っておくが。
737login:Penguin
2018/12/08(土) 19:50:40.18ID:+Jbcoor3
>>734
WSL凄いよな。パフォーマンスの点でDocker for Windowsを(WSLから)使うけど
その問題が解決するならば、仮想マシンで動かさなくて良くなるからもっと便利になる

具体的には仮想マシンにメモリを割り当てなくて良くなるから、アプリが使用する
必要最小限のメモリだけで良くなる

macOSもそうなってほしいね。macOSはUNIXだけどLinuxではないので
仮想マシンを使わないとDockerが使えない
738login:Penguin
2018/12/08(土) 19:56:23.54ID:L5TbyMsj
>>734
>Windows Subsystem for Linux
動作が遅いんだよなソレ
739login:Penguin
2018/12/08(土) 20:46:45.10ID:2GxAzxkY
>>738
エアプ乙wwwwwwwww
740login:Penguin
2018/12/08(土) 21:11:29.00ID:dieSV16U
WSLはCPU速度はVMと同等かそれ以上に速いが
I/OはNTFSを使う都合上遅い
後一年も経てば解決するかも
741login:Penguin
2018/12/08(土) 21:14:37.86ID:rWi9h0wU
>>740
なんで一年なの?もしよかったら。
742login:Penguin
2018/12/08(土) 21:29:09.06ID:dieSV16U
>>741
一応問題視はしてるらしいので
https://news.mynavi.jp/article/20180815-676572/

いつまで掛かるかは分からん
1年?2年?3年?
743login:Penguin
2018/12/09(日) 00:10:57.54ID:cc85A2e8
cygwinの時も同じ問題があって、それは解決できなかったんだけど、
MSの場合はカーネルやファイルシステムに手を入れることも視野に入れられるからな

これまでWindowsのアップデートのたびにWSLの互換性は上がっていってるので
MSの本気度はかなり高いことがわかってる。例えばこれとか

マイクロソフト、Windows 10にUNIX系OSと似た擬似コンソール実装
https://news.mynavi.jp/article/20180817-679662/

パフォーマンスを上げるためにカーネルに手を入れる可能性も十分あると思うわ
744login:Penguin
2018/12/09(日) 00:12:49.28ID:cc85A2e8
> I/OはNTFSを使う都合上遅い
NTFSが遅いんじゃなくて、NTFSでLinuxのファイルシステムに求められる機能
(パーミッションなど)をエミュレートするから遅いんだけどな

NTFSのファイルシステム自体は高速
Windowsから触ってる時、何も遅く無いだろ?
745login:Penguin
2018/12/09(日) 01:14:22.47ID:HpkcVb/n
ちょっとドッカ行ってくる!
746login:Penguin
2018/12/09(日) 02:07:56.20ID:To7rhTt4
>>737
>>737
Windowsという再起動OSなんて使いたくない。
勝手に通信するし、あんなものをLinuxの代わりなどならない。

どうせ、終コンになる。
Edgeなんて使わなくて良かった。

生のLinux使えばいい。
747login:Penguin
2018/12/09(日) 10:31:38.95ID:EY4Hdmdj
最近のM$のLinuxへの擦り寄り方が気持ち悪い・・
748login:Penguin
2018/12/09(日) 11:58:40.20ID:lnGs3c0o
EdgeもChromiumベースになるらしい
もともとユーザー数少ないし、下手に独自のエンジン作られても非互換の部分が増えるだけだし
良いんじゃね?
もっとOSSに擦り寄れよ
749login:Penguin
2018/12/09(日) 13:16:03.28ID:y11hLOEC
>>742
ニュースなってたんだ。ありがと。あとはデーモン管理できるようになれば実用段階だね。
750login:Penguin
2018/12/09(日) 13:28:40.17ID:THytfEd4
>>747
Windowsはクラウドでの運用に適さないからね
Azure使ってみたらよく分かるけど、MSのAzureチームもWindows使うの苦痛なんだろう
751login:Penguin
2018/12/09(日) 13:29:50.96ID:krBcsUKs
>>747
クラウドの客が犬糞使いたがってる影響だな
まぁ色々やむを得ずなんだろ
752login:Penguin
2018/12/09(日) 22:54:59.88ID:To7rhTt4
>>750
そもそもライセンスが面倒
753login:Penguin
2018/12/10(月) 00:04:12.08ID:SK07uHh5
>>752
だから必然的にクラウドを使うんだよ
AzureもAWSもGCPもWindowsインスタンスが用意されていて
そこにライセンスも使用料も含まれてる

もしかして知らなかった?
オンプレで自前サーバーとかて立ててる
時代のやり方してる所は知らなそうだよね
754login:Penguin
2018/12/10(月) 00:39:51.48ID:J1i/Nso2
windowsを使おうと思わないから、インスタンスがあっても知らんよ。。
755login:Penguin
2018/12/10(月) 01:05:32.56ID:7TlUMjqb
awsとか使ったことあるならwindows使わなくてもインスタンスあることくらい知ってるだろ
756login:Penguin
2018/12/10(月) 10:47:43.06ID:dQ2JA6Qk
クラウド使ってないのがバレた瞬間w
757login:Penguin
2018/12/10(月) 11:12:08.35ID:NeKVBZE8
インスタンス料金表とか見たらデカデカと載ってるからね
知らないのはさすがにありえないわ
758login:Penguin
2018/12/11(火) 00:50:36.92ID:4E+hOthN
ふとAWSのダッシュボードみてみたら、Linuxなんかよりも先にあるねWindows
759login:Penguin
2018/12/11(火) 01:41:37.66ID:fnQebX3c
アイウエオ順だからね
760login:Penguin
2018/12/11(火) 03:32:26.01ID:uPmSs8pv
ダッシュボードほとんどつかわねーもん。
761login:Penguin
2018/12/11(火) 06:39:42.41ID:TdDwAL/l
そりゃクラウド使ってなきゃ、
「必ず使わないとその他のメニューに行けないダッシュボード」を
使わないことだってあるだろうなぁw
762login:Penguin
2018/12/11(火) 08:35:26.14ID:ckB4u5dR
えっ、お前マネージメントコンソールやリファレンスを一切見ることなくCLIを使いこなし、
適切なインスタンスタイプ名を一発で引き当てることができないの?w
763login:Penguin
2018/12/11(火) 11:41:27.35ID:TdDwAL/l
何にいくらコストがかかるって
CLIで見れたっけ?
764login:Penguin
2018/12/11(火) 11:56:58.01ID:TdDwAL/l
引き当てるって書いてあるし、ガチャ方式でやるってことか
使ったことがないからネタに走ったってことね
765login:Penguin
2018/12/11(火) 12:48:42.72ID:zSz5aCBW
クラウドのインスタンスって、最初からOSが組み込まれているのか?
どんな設定されているかわからないものを使うって不安でない?
最初からiptableが開かれているとかさ?
766login:Penguin
2018/12/11(火) 12:59:53.39ID:TdDwAL/l
根本的なところがずれてるな

自分でOSを組み込んだら、どんな設定になるのかわかるのか?
iptableの状態がどうなってるのか、安心できるのか?
767login:Penguin
2018/12/11(火) 13:44:58.63ID:jw9Lxp3n
>>765
そもそもクラウドにiptableの設定なんか必要ない
そういうのはインフラ側の設定で制御するんだよ
オンプレ脳の人間はインフラを「容易には弄れないもの」と考えて何でもサーバー内で完結しようとする
しかしクラウドにおいてはむしろそれは逆で、サーバーよりもインフラの設定の方が柔軟に変更でき、構成管理も極めて容易だ
iptableのような脆弱な仕組みに頼ることなくデザインによってセキュリティ等の要件を担保できる
これがクラウドの強みだ
768login:Penguin
2018/12/11(火) 13:57:03.24ID:TdDwAL/l
説明下手だなw

デザインによってセキュリティ等の要件を担保できるとか
意味不明な説明じゃなくて単純に言えばいいだけだろ

クラウドではサーバーの外にあるファイアウォールで制御する
そのファイアウォールは、設定画面やCLIコマンドやAPIから設定できる
769login:Penguin
2018/12/11(火) 18:55:36.03ID:vSSmL6HQ
多層防御やんないの?
770login:Penguin
2018/12/11(火) 18:57:19.35ID:RFWXoMiO
>>768
わかりやすい。

でも、手作業による設定と違って、
柔軟な設定はできなさそう。

Dockerならフォワードチェインから、
サブチェインに飛ばして、そこでフィルタやパケットの統計をとったり、
あるいは、ポート開放のために、-t nat にフォワードの設定が必要になるだろうけど、
クラウドはそういうのは使わないの?
771login:Penguin
2018/12/11(火) 19:01:33.77ID:TdDwAL/l
> でも、手作業による設定と違って、
> 柔軟な設定はできなさそう。

手作業ってなんだ? どうせコマンドうつだけだろ

> Dockerならフォワードチェインから、
Dockerコンテナ = アプリ

お前、アプリの中に、ファイアウォールの設定入れるのか?
Dockerコンテナは仮想マシンじゃないって言ってるだろ
772login:Penguin
2018/12/11(火) 19:02:07.57ID:TdDwAL/l
>>770
> クラウドはそういうのは使わないの?
だからそれらは全てサーバーの外にあるファイアウォールで設定できる
773login:Penguin
2018/12/11(火) 19:02:50.71ID:YQlb17UG
実際はiptableなんかに頼ることなく、ハード込みで売ってるファイヤウォール使ってるってことだろ。
774login:Penguin
2018/12/11(火) 19:02:59.55ID:TdDwAL/l
>>769
やりたいならやればいいのでは?
775login:Penguin
2018/12/11(火) 20:20:08.70ID:aNKr+Tu5
>>769
お前はリスクマネジメントというものを分かってない
AWSが俺を信じて任せろと言ってるんだからリスクは完全にAWSに転嫁されていて、それで十分なんだよ
もしもAWSの不具合で事故るようなことがあれば、そのときはAWSに損害賠償請求すればよい
776login:Penguin
2018/12/11(火) 20:39:50.12ID:TdDwAL/l
>>775への反論は

そんな無責任が通用するわけがないだろう

自前で実装して、不具合で事故るようなことがあれば、損害賠償してやる!と
男らしく言うべきだ。

自前で実装する=事故る可能性が高い わけだけど、
損害賠償するのが男らしいんだ!

という感じでお願いねw
777login:Penguin
2018/12/11(火) 20:50:55.90ID:wGD7MWoB
AWSのインフラはCloudFormationかTerraformを使って設定するのが今どき

全てGitリポジトリに入れて管理すれば誰が何を変えたか分からないって事はなくなる

AWSの場合、接続出来るIPやポートの制限はセキュリティグループで行う

手動で変更されてもEvident.ioを使えば自動で検出して修復できる

Evident.ioを使ってセキュリティオートメーションしてみた
https://dev.classmethod.jp/cloud/aws/security-automation-using-evident-io/

Evident.io使わなくても
CloudTrailとSNS、Lambdaを使えば同じことできそうだが
めんどい
778login:Penguin
2018/12/11(火) 21:01:01.62ID:hpl/6PSX
http://connect.uh-oh.jp/

現実の人の繋がりに疲れた人に

宣伝です。
779login:Penguin
2018/12/12(水) 00:19:12.15ID:0hXJnkj2
コンテナとJSフロント関係は
進歩早すぎてついていけん...
780login:Penguin
2018/12/12(水) 00:40:57.10ID:JHof8k11
>>771
でも、Dockerコンテナ起動したら、
ポートが開くじゃない?
たとえば、ソースIPアドレスで絞り込んだり、
iptablesが必要だと思うけど?
そういうこともawsセンター側できるの?
781login:Penguin
2018/12/12(水) 00:43:06.20ID:Zb7agEVB
> でも、Dockerコンテナ起動したら、
> ポートが開くじゃない?

開かないが?
782login:Penguin
2018/12/12(水) 00:43:48.96ID:Zb7agEVB
>>780
例えば、nginxを起動するとポート80番が開く
って話してるのか?

Dockerと関係ない話だよね
783login:Penguin
2018/12/12(水) 02:56:29.06ID:JHof8k11
>>771

コンテナはアプリを動作させるための環境であって、
コンテナ=アプリという式は間違っている。
784login:Penguin
2018/12/12(水) 02:57:03.71ID:oUbBeYcM
>>775
まあ大抵にわかのセキュリティエンジニア(笑)が設定ミスってノーガードになるのが事故の原因なんだけどな
オンプレでもFWで守られてるから大丈夫なんて余裕ぶっこいてるサーバーほどよく侵入されてる
785login:Penguin
2018/12/12(水) 10:49:09.21ID:Zb7agEVB
>>783
コンテナ=アプリ と言ってない
Dockerコンテナ=アプリ と言ってる
正確に言うならアプリ相当として考えろってことだが
786login:Penguin
2018/12/12(水) 10:51:05.96ID:Zb7agEVB
>>784
なんでデフォルトでポート塞がないの?って話だな

クラウドならサーバー外部にある、ファイアウォール相当のものがデフォルトで塞いでいるから
いくらサーバー側で設定ミスっても接続できない。

意図的にファイアウォールの設定をしない限り接続できないように
安全な状態になっている。
787login:Penguin
2018/12/12(水) 12:46:39.18ID:rkj8vXTd
>>784
それはいったんFWの内側のネットワークに侵入されたらノーガードのサーバーに入り放題ってことだろ?
クラウドだとFW相当の設定はサーバー単位だし、その上で仮想ネットワークの出入口に更に強力なFWを設けるのが一般的だ
その上で更にサーバ内でポート閉じる設定するなんて明らかに冗長なだけ
788login:Penguin
2018/12/12(水) 12:53:29.02ID:JHof8k11
>>786
デフォで、オールリジェクト?ポリシーはどうなっているの?

awsでもDockerコンテナ使えますか。
使えるなら、Dockerホストと、その外部ファイアウォールの両方でポート開放が必要ということですよね。
いわば、サーバーの先にブロードバンドルータがあるみたいな感じですよね。
789login:Penguin
2018/12/12(水) 13:33:11.96ID:Zb7agEVB
>>787
> それはいったんFWの内側のネットワークに侵入されたらノーガードのサーバーに入り放題ってことだろ?
セキュリティ突破できたらやり放題って当たり前だろ
何を言ってるのかわからん。

> クラウドだとFW相当の設定はサーバー単位だし
普通はネットワーク単位だが?

> その上で仮想ネットワークの出入口に更に強力なFWを設けるのが一般的だ
だからそれがデフォルトなのがクライド
790login:Penguin
2018/12/12(水) 13:34:32.04ID:Zb7agEVB
>>788
> awsでもDockerコンテナ使えますか。
今の話にDockerコンテナは関係ないから
(パッケージでインストールする)nginxに置き換えるね

> nginxのホストとその外部ファイアウォールの両方でポート開放が必要ということですよね。
> いわば、サーバーの先にブロードバンドルータがあるみたいな感じですよね。

だからなに?
791login:Penguin
2018/12/12(水) 14:03:28.23ID:rkj8vXTd
>>789
いやセキュリティグループはサーバー単位だろ
本当にAWS使ってるのか?
792login:Penguin
2018/12/12(水) 14:18:50.62ID:LrMZOP1V
>>791
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Security.html

この下の図を見ろ。
インスタンスの外にセキュリティグループが存在している
793login:Penguin
2018/12/12(水) 14:20:39.26ID:JHof8k11
>>790
0点

>>788をよく読んで答えなさい
794login:Penguin
2018/12/12(水) 14:34:36.22ID:LrMZOP1V
>>793
反論できないならレスすんなよw
795login:Penguin
2018/12/12(水) 14:53:24.26ID:rkj8vXTd
>>792がAWSを使ったことがないことはわかった
796login:Penguin
2018/12/12(水) 15:21:10.76ID:kA2tO+1p
セキュリティグループは作ってからEC2インスタンスやロードバランサー、データベースにくっつける

IPアドレスの範囲に加え、
特定のセキュリティグループを持ったインスタンスの接続のみを許可する使い方も出来て便利
797login:Penguin
2018/12/12(水) 15:21:58.33ID:afrcY71M
AWS使ったことないんだけど、ポートを塞ぐだけでセキュリティ云々言うのは間違ってるよ。
webなんかで言われるセキュリティホールは80とか443を使って侵入するから通信の中身やURLを解析して弾かなきゃいけない。
こんなのは自前で実装するのが普通。
798login:Penguin
2018/12/12(水) 15:24:04.80ID:LrMZOP1V
>>797
URLを解析って何すんの?
言ってみ
799login:Penguin
2018/12/12(水) 15:25:51.40ID:LrMZOP1V
オンプレの場合、一旦納品したサーバーは
脆弱性があろうともバージョンアップしないんだろう

だから脆弱性があるサーバーを守るために
ファイアウォールを使う。

馬鹿としか言いようがないw
800login:Penguin
2018/12/12(水) 15:26:01.33ID:kA2tO+1p
自分のアプリのバグで大穴を開けなきゃ普通は大丈夫
801login:Penguin
2018/12/12(水) 15:32:49.47ID:afrcY71M
>>798
jsが仕込まれたURLじゃないかとか色々
802login:Penguin
2018/12/12(水) 15:39:58.21ID:JHof8k11
>>794
反論を煽るようなレスをわざわざするなよ
803login:Penguin
2018/12/12(水) 15:41:21.13ID:JHof8k11
>>798
ストリングクエリとか
804login:Penguin
2018/12/12(水) 15:43:22.45ID:LrMZOP1V
>>801
え?なに? クライアントからサーバーに
jsが仕込まれたURLが送られてくんの?

>>803
え?なに?ストリングクエリに細工されていたら
サーバーに侵入される脆弱性があるの?
805login:Penguin
2018/12/12(水) 15:44:35.32ID:JHof8k11
>>804
最初からわかっていたら苦労しない。
806login:Penguin
2018/12/12(水) 15:50:02.78ID:LrMZOP1V
>>805
テストもレビューもしないってこと?
細工したクエリストリング流してテストすればわかることだよね?
807login:Penguin
2018/12/12(水) 15:50:03.76ID:afrcY71M
可能性を言えばきりがないが、URL依存の攻撃なんか腐るほどパターンがあるから限られたURLだけ通してあげて、
それ以外は404とかに出すに限る。404も別サーバーでいい。
bashショックもURLだったろ。あれはパッチをできるだけ速く当てるしかないが。
808login:Penguin
2018/12/12(水) 15:51:25.13ID:afrcY71M
テストとレビューで事足りるならセキュリティは苦労しない。
809login:Penguin
2018/12/12(水) 15:55:21.74ID:LrMZOP1V
でもセキュリティあってもテストとレビューで
事足りないものはセキュリティでも漏れるから
意味ないよね
810login:Penguin
2018/12/12(水) 15:56:29.43ID:LrMZOP1V
> 可能性を言えばきりがないが、URL依存の攻撃なんか腐るほどパターンがあるから限られたURLだけ通してあげて、

だから限られたURLってなんだ?
お前のサーバーは、自分以外のURLで接続できるのか?
811login:Penguin
2018/12/12(水) 16:02:48.99ID:afrcY71M
>>810
普通いくらでも通るぞ。getも知らないのか?
812login:Penguin
2018/12/12(水) 16:14:58.97ID:LrMZOP1V
>>811
どこのサーバーからgetするの?
813login:Penguin
2018/12/13(木) 01:38:07.71ID:eanokFZt
>>810
たとえば、基本的なところでは、クエリストリングで、
アプリケーション側で対応するフィールド以外のものは、
排除するとか。
814login:Penguin
2018/12/13(木) 08:28:12.43ID:WRDxjQMU
>>797
>webなんかで言われるセキュリティホールは、80とか443を使って侵入するから、
通信の中身やURLを解析して弾かなきゃいけない。
こんなのは自前で実装するのが普通

アプリ製作者が素人で、アプリにバグがあるから、こいつらの技術では自前で実装できないw

SQL 文を文字列でつないで作って、問い合わせる奴。
place holder を使っていない奴は、SQL インジェクションされる

sql文 = "SELECT 列名 FROM 表名 WHERE user_id='$userid';";

この変数に、1 だけなら良いけど、
クラッカーは「1; 文」のように、; を打って、クラッキングする文をつなげてくる

資格も持ってない・勉強していない奴は、当たり前の事も知らない。
place holder を使っていないアプリは、損害賠償請求できる

こういう奴らは、アプリを作っちゃいけない!
815login:Penguin
2018/12/13(木) 08:31:23.97ID:+yv1dYA8
>>813
そんなもんWAFで弾ける
クラウドならそれこそ画面でポチるだけ
816login:Penguin
2018/12/13(木) 08:35:16.32ID:WRDxjQMU
>>788
>awsでもDockerコンテナ使えますか

aws は、Docker だろ。
CoreOS, Kubernetes とか
817login:Penguin
2018/12/13(木) 14:47:58.45ID:XsbRAMI5
コンテナってクラウドに熟達した人が究極のdeployabilityを追求した末に行き着くものだと思ってたけど、意外とそうでもないんだね
クラウドには手が出ないけどなんか新しそうなもの触ってみたいだけな人が多いのかな
818login:Penguin
2018/12/13(木) 15:26:06.24ID:j2qkztX7
マネージドKubernetesサービス対決

比較表見るとアマゾンのEKSはGoogleのGKEと比較してコスト高いだけの劣化版に見える
そしてMSのAKSはどちらにも及ばないクソ
https://kubedex.com/google-gke-vs-microsoft-aks-vs-amazon-eks/
819login:Penguin
2018/12/14(金) 00:56:30.76ID:yXt9E1ve
>>815
httpsの場合は?
中間者攻撃が成立しないと解読できないと思うけど。
820login:Penguin
2018/12/14(金) 08:26:23.33ID:E4qeknD0
>>819
wafはCloudFrontやALBと組み合わせて使うよ。
それらはSSLアクセラレーターの機能も兼ねてるのでwafやwebサーバ側に来る時点ではhttp平文状態になります。
この場合、サーバー証明書はCloudFrontやALBに組み込むだけで済みます。AWSはドメイン発行やルート局も持ってるので証明書関連はAWSだけで完結できます。
スレチだけどEntity Framework等の昨今のO/Rマッパーを使っていればSQLインジェクション対応してくれるから余り神経質になる事はないよ。自身でSQL文を組み上げる事はしません。
821login:Penguin
2018/12/14(金) 11:45:24.57ID:BtHCLjdt
>>819はまさかコンテナにSSL喋らせてるのか?
そんな足回りの関心は丸投げできるようなインフラでないと上で喚いてる「アプリとしてのコンテナ」なんか程遠いだろ
822login:Penguin
2018/12/14(金) 11:50:21.23ID:Wd54hADz
もうそろそろ飽きてきたな。
インフラ周りの話はDockerコンテナと関係ないし
823login:Penguin
2018/12/14(金) 12:17:11.80ID:BtHCLjdt
今時オーケストレーションやインフラの技術を抜きにしてコンテナを語るのは無理があるだろ
ホビーストがチマチマrunして遊ぶ時代はとうの昔に終わったんだよ
824login:Penguin
2018/12/14(金) 12:28:41.19ID:Wd54hADz
>>823
レイヤーが違うんだよ。

Dockerはコンテナに動かすのに必要なものがカーネル以外全て入っている
逆に言えばDockerを動かすものは何でもいい。

Kubernetes使おうがsystemdから起動しようがコマンドで実行しようが関係ない

アプリの話をしているときにOSの話をするのは関係ないだろ?
OSとアプリの連携の話をするならまだわかるけど、
OSそのものの話は関係ないじゃん?今の話はそういうレベル。

インフラそのものの話になってしまって、アプリは全く関係ない話になってる。

アプリとインフラの機能を密結合させるという発想しか持ち合わせてないから
こういう話を続けるのだろうけど
825login:Penguin
2018/12/14(金) 23:41:13.97ID:94bz9H8n
>>824
大いに関係あるよ
なぜコンテナにTLSが必要ないのか?
それは暗にインフラに対してCloudFrontやALB的なものが存在するという前提を設けているからだろう
レイヤが違う、故に高レベルのレイヤの設計は低レイヤの性質に依存するんだよ
コンテナを単なるVMというならともかく、そうじゃないと主張しているんだろ?
だったらそのためのインフラに対する条件は明確にしておかなければ机上の空論でしかないぞ
826login:Penguin
2018/12/15(土) 00:12:19.93ID:AVLQNiPu
>>825
お前が言ってるのコンテナと関係ない話じゃん

> なぜウェブアプリにTLSが必要ないのか?
> それは暗にインフラに対してCloudFrontやALB的なものが存在するという前提を設けているからだろう
> レイヤが違う、故に高レベルのレイヤの設計は低レイヤの性質に依存するんだよ

昔からウェブアプリ自身にTLS(SSL)を解く機能は持たせず、
その前に設置しているリバースプロキシ等にやらせるだろ。

例えばRailsを使うにしてもRails自身でSSLを処理するのではなく、
リバースプロキシ等(例 nginx)で行わせる。

このnginxはRailsのプリコンパイルしたCSSやJavaScript等の
静的ファイルの配信でも利用される。静的ファイルの配信は
それが得意なnginxにやらせてRailsはアプリの処理のみを行う。

そういったすみ分けが昔から出来てるわけで、Dockerコンテナだからそうするいう話ではない
827login:Penguin
2018/12/15(土) 15:15:31.44ID:cWutNvKe
>>826
証明書ゲートウェイですね
大手でも、そういう名前のサイトで最初で認証させられるわ。
828login:Penguin
2018/12/15(土) 15:44:52.42ID:K1K5tkNg
>>827
なんかそれ違う気がする。
>>826のはSSLアクセラレータとかの方でねぇか?
829login:Penguin
2018/12/15(土) 15:46:43.03ID:K1K5tkNg
訂正:SSLアクセラレータとかSSLオフロードとかの方でねか?
830login:Penguin
2018/12/19(水) 14:48:40.71ID:MXoPEPIu
WindowsでDocker (Hyper-V)とVirtualBoxが共存可能になったってよ
831login:Penguin
2018/12/19(水) 15:26:42.72ID:ChoPuE2E
>>830
そうなんだ
又試してみるかな
832login:Penguin
2018/12/19(水) 16:34:42.32ID:RugaoNC3
>>830
バーチャルマシンつかった段階で、負けた感がある。

そこはLinuxをちゃんとつかって、生でDockerしないと。
833login:Penguin
2018/12/20(木) 23:54:36.14ID:XN4/V/I5
>>830
何が凄いのか、分からない、良かったら教えてくだしあ
個人的には、Linuxでdocker派です
834login:Penguin
2018/12/21(金) 01:14:23.43ID:Nv7/v6TH
Dockerって、可搬性
>>833
これまでHyper-VをオンにするとVirtualBoxが使えなかった。
それが6.0から共存して使えるようになると騒いでいる。
でも自分も含め動いていない人も居て、本当に動くのか議論されている。
835login:Penguin
2018/12/21(金) 01:15:42.66ID:Nv7/v6TH
最初に変な文入った。すまん。
836login:Penguin
2018/12/21(金) 01:24:14.44ID:XG5mmZ9I
ひょっとしてVMWareとも共存できるようになった?
837login:Penguin
2018/12/21(金) 01:53:16.38ID:uGD7jju5
>>834
公式にはできるってアナウンスないって事?
838login:Penguin
2018/12/21(金) 06:49:12.33ID:Nv7/v6TH
>>837
公式にアナウンスされているけど、動かない。でも動いてる人も居るんですよね。きっと。
839login:Penguin
2018/12/21(金) 11:28:49.25ID:gbcTPeq+
>>838
Windows ハイパーバイザープラットフォームをオンにしたら動いた
https://superuser.com/questions/1208850/why-vitualbox-or-vmware-can-not-run-with-hyper-v-enabled-windows-10
840login:Penguin
2018/12/21(金) 13:33:22.49ID:l/z2KMXK
>>839
QEMUの話。動いたとは書かれていない
841login:Penguin
2018/12/21(金) 17:10:41.60ID:uGD7jju5
>>838
Vrtual Boxの方をアプデするのね
Dockerの公式ブログとか見てたw
842login:Penguin
2018/12/21(金) 17:47:57.10ID:gbcTPeq+
>>841
6.0にしてWindows ハイパーバイザープラットフォームをオンにし、再起動。
843login:Penguin
2018/12/22(土) 09:20:27.59ID:XGn7oEU9
>>842
ありがと
やってみます
844login:Penguin
2018/12/23(日) 05:24:15.15ID:qY0IrDwI
素人ながらubuntu16.04にdockerを入れたらネットに接続できなくなりました。ブリッジが勝手にかかっててwifiがつながらない症状が出ています。
操作しようとしたらgot permission denied while trying to connect to the Docker daemon socket at unix ~~~と出てきました
この状態からdockerを削除して元の状態に戻す方法を教えていただけないでしょうか。
sodo gpasswd -a username dockerでグループには追加しました。
845login:Penguin
2018/12/23(日) 05:53:03.36ID:HJ+H2evR
>>844
dockerを消す前に、再起動しろ
再起動したら動く
846login:Penguin
2018/12/23(日) 06:59:26.01ID:qY0IrDwI
接続できるようになりました。とんだお騒がせをいたしました。
847login:Penguin
2018/12/23(日) 07:11:20.54ID:HJ+H2evR
ま、再起動しなくてもネットワークサービスを再起動して
ログインしなおせば動くんだけどなwww
848login:Penguin
2018/12/23(日) 14:58:25.06ID:yfLE2NmO
今更ながらdocker勉強し始めました
KVMみたいにOSから作るのは理解できるけど、例えばDockerHubからNginxイメージをpullする時は、dockerをインストOS環境に依存するの?
Debian使ってたらDebian環境用のNginx環境ができるの?
849login:Penguin
2018/12/23(日) 15:09:29.69ID:HJ+H2evR
そのnginxイメージを作ってるDockerfileを読めばわかることだろ

dockerを使う = Dockerfileを読み書きするってことなんだからな
850login:Penguin
2018/12/23(日) 15:11:09.75ID:Sp1piTzY
使用しているベースイメージ次第。環境は関係ない。
dockerは実運用するなら素のベースイメージから上は自分で作るのが基本だから、そのへんの考え方は一度自分でやってみればすぐに理解できる。
出来合いのものはあくまでサンプル。
851login:Penguin
2018/12/23(日) 15:18:02.54ID:nk+HmfrL
ありがとう
むぅ理解できないわ
取り敢えず触ってみる
852login:Penguin
2018/12/23(日) 15:20:33.05ID:nk+HmfrL
んっnginxより上、ベースイメージでの動作はdockerが担保してくれるってことなのかな

触ってみる
853login:Penguin
2018/12/23(日) 15:23:14.74ID:B+bc3dl4
カーネルは共有されるけどそれくらい
854login:Penguin
2018/12/23(日) 20:16:44.66ID:JFyTQrTf
LinuxカーネルのABIは安定しているので
カーネルより上の層(libc)とかは
基本どのディストリビューションでも動作する

go言語は他のライブラリが必要ない実行ファイルを作れる
scratchイメージにgoの実行ファイルだけ入ったものを作れば
僅か数MBのDockerイメージすら作れる
855login:Penguin
2018/12/23(日) 20:27:41.62ID:QVRCwsb4
>>854
何ヶ月か前に別スレでその最初の3行にまつわる話したら袋叩き似合った
856login:Penguin
2018/12/23(日) 20:28:40.54ID:a3X0TqIZ
だってウソだもんで>LinuxカーネルのABIは安定している
857login:Penguin
2018/12/23(日) 20:53:37.68ID:HJ+H2evR
>>854
> go言語は他のライブラリが必要ない実行ファイルを作れる

でもライブラリ相当の機能が実行ファイルに含まれてるから、
goのバイナリはサイズがデカイんだよね
858login:Penguin
2018/12/23(日) 20:56:40.02ID:HJ+H2evR
お、あったw やっぱりでかい
http://d.hatena.ne.jp/eel3/20150627/1435402293

言語 ファイル名 大きさ(byte)
C言語 hello_c 5516
C++ hello_cpp 5588
D言語 hello_d 360500
Go言語 hello_go 1091428
859login:Penguin
2018/12/23(日) 21:00:54.59ID:QVRCwsb4
goはでかいよ
Archやってるとでかいサイズのgoの更新が頻繁に来るからうざい
860login:Penguin
2018/12/23(日) 22:03:58.19ID:jSNMCGZQ
Linux/UNIX文化では動作が変わっても名前は変わらないので必ずリンクできる。
つまり安定性が高い。
一方、Windowsは動作が変わると名前にサフィックスが付く。
従って新しいAPIに自動的にリンクされることはないし、APIの数はドンドン増え続ける。
861login:Penguin
2018/12/23(日) 22:06:43.39ID:UzZijvxD
>>860


Linux/UNIX文化では動作が変わっても名前は変わらないので必ずリンクできる。
Windowsは動作が変わると名前にサフィックスが付く。
以前の名前は変わらないので必ずリンクができるし、以前の名前の動作が変わることがない
だから高い互換性が保てる

といいたいのかな

Linuxはカーネルのシステムコールの数が増えなくても
ライブラリとは関係ない話なので、APIの数の代わりにライブラリの関数が増え続けるよ
862login:Penguin
2018/12/23(日) 22:39:22.84ID:5Q1rOqA5
>>855
読んでみたい、どこか覚えてる?
863login:Penguin
2018/12/24(月) 11:43:32.49ID:ZQ/dJl6b
Debianにインスコ開始ー
864login:Penguin
2018/12/24(月) 12:15:04.63ID:wEpk+PBH
GoのシングルバイナリってGPL汚染はないの?
というかDocker自体、上の方で猿が喚いてる「コンテナはアプリだ!」との主張がもし世間一般に通るなら、
単なる集積物であってアプリにGPLは感染しない理論はかなり無理があるんじゃないかな
865login:Penguin
2018/12/24(月) 12:32:06.34ID:3ljC1xCs
自分で入れた癖して汚染したとか騒ぐのは笑えるぜ
866login:Penguin
2018/12/24(月) 12:37:46.46ID:3ljC1xCs
>>864
そもそもGoはBSDライセンスだし

gccgoを使う場合はGPLのコンポーネント(gcc)を含むが
生成したバイナリはGPLの対象外

gccのランタイムライブラリは例外にしないと
Linuxにクローズドソースのソフトウェアが一切存在出来なくなるから
まさかクローズドソースのは一切無いと思ってた?
867login:Penguin
2018/12/24(月) 12:54:07.75ID:FVAjhLvH
>>866
LinuxのアプリがGPLに感染しないのは、GPLの「単なる集積」と「システムコール」の例外条項による
自分で条項を読んでみたらいい
Dockerコンテナを単なるアプリケーションパッケージと解釈するなら、これらの例外が適用されるかはかなり怪しいよ
まあGoの場合は解釈論を云々するまでもなくGPLライブラリをスタティックリンクした時点で完全アウトだが
868login:Penguin
2018/12/24(月) 13:26:23.88ID:n0J+hQ60
>>867
意味不明
Dockerで使う時だけ対象になるとか何処に書いてある?
869login:Penguin
2018/12/24(月) 13:36:26.71ID:n0J+hQ60
>>867はDockerイメージは全てオープンソースにしないと違法って言ってんのか?
そんなこと言ってんのお前だけだろw
870login:Penguin
2018/12/24(月) 14:05:57.51ID:sB1miyd2
Linuxはソース文化なのでコンテナがないとアプリケーションの配布がきつい。
871login:Penguin
2018/12/24(月) 16:44:22.21ID:0ONmT3Cp
>>867
お前、その主張は、DVDにGPLとそうでないものを
一緒に焼いたら(つまりRedHat Linux状態)
ライセンス違反になると言ってることになってるんだが
気づいているか?
872login:Penguin
2018/12/24(月) 16:46:03.80ID:0ONmT3Cp
>>867じゃなくて>>864あて
873login:Penguin
2018/12/24(月) 18:34:55.08ID:sB1miyd2
Redhatは倫理規定違反で死刑になってもおかしくないけどな。
874login:Penguin
2018/12/24(月) 19:52:46.56ID:fOFd4UE9
そもヨゴレのIBMと喜んでくっつかってんだから相当なド底辺クズ野郎どもだろ>RH
大喜びで開発協力してきた日本の大手ITベンダのアホ情弱どもはそれ以下のマヌケだろうけどな
875login:Penguin
2018/12/24(月) 22:18:39.83ID:Hg8v6tOU
>>871
>>871
それがいわゆる「単なる集積」
特定のアプリのために同梱してるんじゃなくて本当に単なる寄せ集めだから派生物と見做されない
一方Dockerは特定のアプリのためにコンポーネントを事実上スタティックリンクしているわけで、例外条項の趣旨を考えれば完全にアウトだ
だからDocker使うなら間違っても「コンテナはアプリだ」なんて言っちゃいけない
876login:Penguin
2018/12/24(月) 23:37:40.13ID:0ONmT3Cp
> 一方Dockerは特定のアプリのためにコンポーネントを事実上スタティックリンクしているわけで

事実上スタティックリンクってことは
本質上スタティックリンクじゃないってことだよね
877login:Penguin
2018/12/24(月) 23:39:40.35ID:0ONmT3Cp
Dockerコンテナはスタティックリンクしてないからアプリと言えるわけである
スタティックリンクしていれば1バイナリになる。
878login:Penguin
2018/12/24(月) 23:52:53.20ID:Y3lrr8FC
>>877
GPLはスタティックリンクか動的リンクかに関わらず感染するよ
879login:Penguin
2018/12/24(月) 23:54:33.16ID:sB1miyd2
LGPLなら良かったのにな。
880login:Penguin
2018/12/25(火) 00:01:42.31ID:XGHDmrXH
ちなみにAndroidアプリだと、LGPLライブラリ(.so)をアプリのパッケージ(ZIP形式)に入れて配布するのはスタティックリンクに該当し、
アプリがLGPLに感染するという解釈が一般的だ
Dockerイメージは言うまでもないよね
881login:Penguin
2018/12/25(火) 00:04:53.08ID:MqCJ7mUS
いつのまに、アプリと呼ぶだけでGPLに感染することになったんだ?w
本質的にアプリだが、アプリと呼ばなければOKって意味不明

俺が「あれ」と「これ」を含んだDockerコンテナ=アプリを作ったとして
他人が作った「あれ」と「これ」のライセンスを、赤の他人の俺がGPLに変更できるわけないし

Dockerfileはただの数行のファイルでしか無いし、
俺がGPLのものを作ってなにか作ったからと言って、それを不特定の人に公開する義務もない

Docker=アプリに反論したいができなくて、とりあえず言ってみたんだろうが
穴がありすぎて、大丈夫かこいつ?
882login:Penguin
2018/12/25(火) 00:05:50.27ID:MqCJ7mUS
>>880
良い皮肉だw
Googleストアにあるやつは全部GPLになっちゃうよなw
883login:Penguin
2018/12/25(火) 00:09:26.36ID:MqCJ7mUS
Dockerイメージを配布せずに、
Dockerfileだけ配布すれば
完全にGPL(LGPL)を回避できる

Dockerは素晴らしいですな!
884login:Penguin
2018/12/25(火) 00:10:23.19ID:MqCJ7mUS
ということで、DockerがGPL違反になるとか言ってるアホは徹底的にコテンパンにされました。おしまい。
885login:Penguin
2018/12/25(火) 00:11:46.93ID:XGHDmrXH
いやイメージを配布するのは普通にGPL違反よ
配布しなけりゃいいだけだし、誰もそれは否定してないでしょ
886login:Penguin
2018/12/25(火) 00:23:34.90ID:FPaj6kyi
まあ確かに、LGPLはシステムライブラリとのリンクを想定してるから、一緒に配布するのはGPLの精神からすると感染だろな。
887login:Penguin
2018/12/25(火) 00:24:24.73ID:DAdBnaIi
> いやイメージを配布するのは普通にGPL違反よ

1. そもそもイメージ配布しなければGPL違反でないし
イメージ配布する人を社内に限れば、社内の人だけにソースを配布すれば良い

2. GPLはバイナリを入手した人がソースを入手できればいいので
バイナリを手に入れてない人にソースを配布する必要はない

3. DockerイメージのソースとはDockerfileのこと

4. もちろんDockerイメージの不特定の人に配布したら、
その中に入っているバイナリのソースも渡さないといけない
888login:Penguin
2018/12/25(火) 00:25:07.05ID:DAdBnaIi
> まあ確かに、LGPLはシステムライブラリとのリンクを想定してるから、一緒に配布するのはGPLの精神からすると感染だろな。

その理屈だと、ISOイメージにして配布しているRedHatなんかも
ライセンス違反ということになってしまうので、間違ってるのは明らか
889login:Penguin
2018/12/25(火) 00:26:04.73ID:DAdBnaIi
一言で言うならば、GPL感染した所で、プライベートイメージなら
何ら問題ないってことよ。
890login:Penguin
2018/12/25(火) 00:26:15.33ID:FPaj6kyi
>>888
Redhatは裁判になったら死刑判決受けるだろ。
891login:Penguin
2018/12/25(火) 00:26:43.00ID:3aFn9L6f
>>888
だからそれは単なる集積
DockerもVMだから単なる集積だと強弁してしまえばイメージの配布も限りなく黒に近いグレーにできなくもない
892login:Penguin
2018/12/25(火) 00:27:32.15ID:DAdBnaIi
>>891
Dockerのイメージも単なる集積だけど?
893login:Penguin
2018/12/25(火) 00:28:13.95ID:FPaj6kyi
見る人が見れば真っ黒に近い黒だろうな。
例えばGNUの尊師が見たら完全にアウツだろ。
894login:Penguin
2018/12/25(火) 00:29:54.04ID:DAdBnaIi
Dockerのイメージがどういうふうに展開されてるのか知らないのかな?
単なるファイルとしてディスクに展開されてるんだけど

最終的にはLinuxのコンテナとして動いていて、コンテナがchrootを発展させたものって知っていれば
以下のリンク先の説明にあるように、とあるディレクトリ以下に展開されてるファイルを実行するだけって
わかるはずなんだが?

https://deeeet.com/writing/2013/12/16/where-are-docker-images-storede/
895login:Penguin
2018/12/25(火) 00:32:10.44ID:3aFn9L6f
>>894
仮にスタティックリンクではないと解釈できたとしても、実際に実行時には動的リンクしてるんでしょ
誰がどう見ても派生物だよ
896login:Penguin
2018/12/25(火) 00:33:09.86ID:DAdBnaIi
> 仮にスタティックリンクではないと解釈できたとしても、実際に実行時には動的リンクしてるんでしょ

だからその理屈を言ってしまうと、RedHatのISOイメージも
同じことになってしまうので、その矛盾を解決してから出直してきなって話
897login:Penguin
2018/12/25(火) 00:33:40.09ID:3aFn9L6f
>>896
だからGPLの「単なる集積」の条項を読んできなさい
898login:Penguin
2018/12/25(火) 00:34:25.34ID:DAdBnaIi
そもそもLinuxでパッケージが提供されているものだけを
使用すればGPL違反になりようがないんだよね

だからDockerコンテナ=アプリ
899login:Penguin
2018/12/25(火) 00:34:48.59ID:DAdBnaIi
>>897
読んで問題がないことがはっきりしている
900login:Penguin
2018/12/25(火) 00:38:53.20ID:DAdBnaIi
はいどうぞ

「集積物」とそのほかの種類の「改変されたバージョン」の違いは何ですか?
https://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation

「集積物」はいくつかの別々のプログラムからなり、それらは同じCD-ROMやそのほかのメディアや "Dockerイメージ" に
いっしょに入れられて配布されます。GPLは集積物を作成し配布することを認めています。
たとえ、ほかのソフトウェアが不自由あるいはGPLと両立しないものである場合でもです。
ただ一つの条件は、あなたは、それぞれのプログラムの個別のライセンスが許す権限を
ユーザが行使することを妨げるような、あるライセンスのもとで集積物をリリースすることはできないということです。

二つの別々のプログラムと二つの部分の一つのプログラムを分ける線はどこにあるでしょうか?
これは法的な問題であり、最終的には裁判官が決めることです。わたしたちは、
適切な基準はコミュニケーションのメカニズム(exec、パイプ、rpc、共有アドレス空間での関数呼び出し、など)と
コミュニケーションのセマンティクス(どのような種の情報が相互交換されるか)の両方によると考えています。

モジュールが同じ実行ファイルに含まれている場合、それらは言うまでもなく一つのプログラムに結合されています。
CD-ROMやそのほかのメディアやDockerイメージは実行ファイルではありません
もしモジュールが共有アドレス空間でいっしょにリンクされて実行されるよう設計されているならば、
それらが一つのプログラムに結合されているのはほぼ間違いないでしょう。

逆に、パイプ、ソケット、コマンドライン引数は通常二つの分離したプログラムの間で
使われるコミュニケーションメカニズムです。ですからそれらがコミュニケーションの
ために使われるときには、モジュールは通常別々のプログラムです。
しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、
それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。
901login:Penguin
2018/12/25(火) 00:42:14.19ID:DAdBnaIi
個々のファイルをあつめて、Dockerイメージにするだけでは
単なる集積物だろう。
902login:Penguin
2018/12/25(火) 00:43:21.84ID:3aFn9L6f
>>900
えっと、君のアプリはDockerイメージ内のGPLライブラリと動的リンクしてないの?w
903login:Penguin
2018/12/25(火) 00:46:00.22ID:DAdBnaIi
>>902
GPLライブラリとは動的リンクしてないけど?
動的リンクが許されるLGPLライセンスのものばかりだなぁ

GPLのものとは以下の分離したプログラム間でのコミュニケーションメカニズムを使うから問題ないし
> 逆に、パイプ、ソケット、コマンドライン引数は通常二つの分離した
> プログラムの間で使われるコミュニケーションメカニズムです。

これで結論出たよね?
904login:Penguin
2018/12/25(火) 00:51:02.18ID:DAdBnaIi
そもそもGPLのものを作ってるのであれば
別にGPLに感染した所で何の問題もないよね。

それから本当の目的は「Dockerコンテナ=アプリ」を否定したかったんじゃなかったの?
Dockerコンテナをアプリと読んでしまったらGPL感染する!とかいう謎理論でさ
905login:Penguin
2018/12/25(火) 00:57:24.87ID:DAdBnaIi
Dockerコンテナ=アプリが気に食わなかったんだろうけど

結局、DockerイメージにするだけでGPL感染させられるか?という
話にしかなってなくて、そんなもんGPLライセンス読めば単なる集積物でしかない
Dockerイメージ(Linuxの機能のコンテナを実行するのに必要なファイルをまとめたもの)は
集積物として扱われるに決まってるし

最初のDockerコンテナ=アプリと何の関係もないし

どんな結論を目指したくてこの話を持ち出してきたのかわからんわ
┐(´ー`)┌ヤレヤレ
906login:Penguin
2018/12/25(火) 01:05:56.07ID:XGHDmrXH
>>900
そのDockerイメージについての言及がリンク先に見当たらないんだけど、参考までにどこにあるか教えてほしい
907login:Penguin
2018/12/25(火) 01:12:36.77ID:DAdBnaIi
>>906
じゃあ君は、Dockerイメージがリンクに相当する言及するところを持ってきてくれ。
言い出しっぺなのだから、それぐらいやってから言うべきことだからな。
908login:Penguin
2018/12/25(火) 01:32:32.10ID:XGHDmrXH
>>907
あなたの提示した捏造元のFAQがコンテナを想定して書かれたものではない以上、可能性は排除できないでしょ
モジュール同士の結合が強すぎる場合は通信方式に関わらず単一の大きなプログラムを構成していると見做されるとも書いてあるよね
Dockerは単一の大きなアプリじゃなかったのかな
909login:Penguin
2018/12/25(火) 01:35:15.16ID:DAdBnaIi
Dockerは単一の大きなアプリだよ?

そしてスタティックリンクしてないし、動的リンクは
LGPLのものだけだからGPLの話と何の関係もないけど

二つの無関係な話をごっちゃにして何が目的なの?
910login:Penguin
2018/12/25(火) 01:54:39.64ID:FPaj6kyi
おまえらはGNUの精神を誤解してるよ。
お前のものは俺のもの、俺のものは俺のもの。
それがGNUだろ。
911login:Penguin
2018/12/25(火) 01:58:42.97ID:DAdBnaIi
GPLは俺のもの、バイナリ渡さなければソース公開の義務もないので
ウェブアプリでとっても便利に使えるもの

GPL感染を免れるためにリンクを行わずに
パイプでやり取りするのもよく使うテクニック
912login:Penguin
2018/12/25(火) 04:04:44.72ID:FPaj6kyi
秋元はAKBがオープンソースとか言ってたのに、AKBは全然GNUじゃないんだよな。
握手券をCDと偽って売りつけるのがオープンソースっぽいと言われれば、確かにそんな感じもするが。
913login:Penguin
2018/12/25(火) 04:05:04.80ID:WaQT3x/c
>>911
GPL感染を防ぐのにパイプでなんか渡す必要ないよ。アプリとして独立していればいいだけ。
914login:Penguin
2018/12/25(火) 04:58:45.55ID:DAdBnaIi
>>913
アプリじゃなくてプログラムな。↓こうかいてあるだろ

https://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation
> しかし多くの場合、GPLの及ぶソフトウェアをプロプライエタリ・システムと一緒に
> 配布することは可能です。これを妥当な形で行うには、自由なプログラムと
> 自由ではないプログラムとがそれぞれ独立を保った形でコミュニケートし、
> それらが事実上単一のプログラムとなってしまうような方法で結合されていないことを確認しなければなりません。

そして「プログラムとして独立」していると見なして良いものの一つが
(GPLのものと)パイプでやり取りするってことだろ
915login:Penguin
2018/12/25(火) 05:10:28.17ID:DAdBnaIi
あー、言っとくけど、ばれてないだろうと考えての無駄な努力はしなくていい。
「Dockerコンテナ = アプリ」をどうにか崩そうとして
なにかを「アプリ」に結びつけようとしてるのには気づいてるから
バレてる時点でその努力は無駄よ。
916login:Penguin
2018/12/25(火) 19:02:35.08ID:FPaj6kyi
GPLに感染したら村ごと焼き払わないと人類滅亡するからな。
917login:Penguin
2018/12/25(火) 19:09:11.04ID:3rvgWFVu
もうボケナスと腐れIBMのお陰で滅亡し掛かってるじゃん>人類
918login:Penguin
2018/12/25(火) 21:14:50.48ID:51aJ/wRC
焼き払え!
どうした!それでも世界で最も邪悪な一族の末裔か!
919login:Penguin
2018/12/25(火) 23:30:47.40ID:p7mFW/Iu
なりきりトークはしんどい
920login:Penguin
2018/12/26(水) 11:17:09.66ID:g9SnL/ls
( ゚д゚)====>☆
921login:Penguin
2018/12/27(木) 14:19:41.89ID:DBCGqnM6
Docker周りを調べてからWebサービス作ってみようかと思ってたけど後回しにする
小規模だし最初サービス作ってからでも遅くない気がしてきた
922login:Penguin
2018/12/27(木) 14:20:31.02ID:DBCGqnM6
ても開発環境だけでも幸せになれるかなぁ
まぁ後にしよう
923login:Penguin
2018/12/27(木) 15:52:15.98ID:eJNw9M2G
同時にすれば?
今日はこれ、明日はこれ。
924login:Penguin
2018/12/27(木) 21:59:03.61ID:yY7ptEAF
いっちょまえに開発開発いわないでWebページ制作といえ
それしかやってないんだからお前らわ
925login:Penguin
2018/12/27(木) 22:24:05.54ID:BHF4hV0J
Webページ制作なら大企業でもやるでしょう?
926login:Penguin
2018/12/27(木) 22:34:07.05ID:gPaHe1Uf
いやWebサイトなんか外部委託が普通だろ
自社でWebサービスやってる会社ですら、Webサイト制作などという底辺仕事を自社エンジニアにやらせるのは損失だから外部委託してたりするぞ
927login:Penguin
2018/12/27(木) 22:36:55.93ID:BHF4hV0J
ん? お前の会社はエンジニアしかいない小さい会社なの?
928login:Penguin
2018/12/27(木) 22:45:44.71ID:gPaHe1Uf
500人くらいの会社だけど、コアでない業務を外部委託するのなんて普通だろ?
前にいた1000人くらいのSIerも当然外部委託だったよ
929login:Penguin
2018/12/27(木) 22:54:57.99ID:BHF4hV0J
ほーら言ってることが変わったw

Webサイトなんか外部委託が普通だろ

コアでない業務を外部委託するのなんて普通だろ?


> それしかやってないんだからお前らわ
それしかやってないというのなら、それがコア業務ってことだよねw
矛盾している
930login:Penguin
2018/12/27(木) 23:36:35.52ID:gPaHe1Uf
>>929
そりゃWeb制作がコア業務の会社もあるだろう
で、Web制作を主業とする大企業ってどこ?
931login:Penguin
2018/12/28(金) 00:01:03.25ID:Xnr1TmZq
Web制作を主業とする大企業が今の話とどうつながるの?
932login:Penguin
2018/12/28(金) 01:13:40.95ID:VhG75zia
webサイトとwebサービスを一緒くたにしてると底辺と思われても仕方ないぞ。
webサイトにしても外注ですますって事は諸々の技術が賄えないってことだからwebサイト職人は高年収なんだなこれが。
ちなみにどこにでも底辺がある業界なのでブラックで雇われてるタイプ打ちの事は知らん。
933login:Penguin
2018/12/28(金) 01:22:56.10ID:R0nxxDdF
Web制作業界はゴミみたいな単価の案件を奪い合う地獄絵図やぞ
典型的なSIerのブラックなんかとは次元が違う
934login:Penguin
2018/12/28(金) 17:09:23.59ID:qmD+abh2
キノトロープ。
935login:Penguin
2018/12/28(金) 17:22:03.84ID:Xnr1TmZq
あなたが落としたのは、
キンノロープ ですか?それとも
キノロープですか?
936login:Penguin
2018/12/31(月) 07:02:53.54ID:Mnpi3suq
>>935
人月100万のゆるゆる案件です!
937login:Penguin
2019/01/22(火) 06:03:33.55ID:Xadxz8jN
Redhat製のdocker互換
rootやデーモン無しで動く
https://github.com/containers/libpod
938login:Penguin
2019/01/22(火) 15:57:47.18ID:a+JKiGWw
>>937
コレってRH系ならyumで入れられんだな
939login:Penguin
2019/01/22(火) 16:29:21.28ID:mcX40V8j
>>937
いきなりKubernetesにも対応してるのか
さようならDocker
このスレもこれで終わりだな
940login:Penguin
2019/01/24(木) 21:26:05.75ID:ILT9+sql
>>937
これってCoreOSの系譜?
941login:Penguin
2019/01/24(木) 21:43:23.54ID:ce56jNa3
>>940
違う
cri-oから分離したプロジェクト
942login:Penguin
2019/01/24(木) 21:51:18.82ID:ILT9+sql
じゃあCoreOSチームはよくて合流悪くて放逐か
浮かばれねえな
943login:Penguin
2019/01/25(金) 10:41:56.04ID:zAxqTMny
Dockerは売り時を逃したな
もう二束三文でMSに買収されてWindowsのコンポーネントになるしかない
944login:Penguin
2019/01/25(金) 16:26:23.99ID:pYl8jJjD
どっかー買いたいって言ってたトコあったんか?
945login:Penguin
2019/01/25(金) 18:06:35.14ID:zAxqTMny
買えるならAWSでもGoogleでもMSでもIBMでもどこでも買ってたでしょ
今となっては地獄の値下がりチキンレース不可避
946login:Penguin
2019/01/25(金) 18:14:42.49ID:Cp/Uwjnb
コンテナはdocker以外にも沢山あるからな
docker社の価値のメインはdockerよりdocker hubだろう
947login:Penguin
2019/01/26(土) 20:34:37.29ID:VvGtKHT8
>>945
MSは自社鯖製品にドッカー組み込んでるみたいだから買収するとしたら合理的かもだな
ホストwinなら他社と違ってかならずこの手のグルーコードが必要になるし
948login:Penguin
2019/01/27(日) 11:43:05.14ID:dbxVWXi/
デーモンを使わずにコンテナやポッドを実行可能:
Docker互換のオープンソースコンテナエンジン「Podman 1.0.0」が公開
http://www.atmarkit.co.jp/ait/articles/1901/25/news055.html

podmanってrktとはどう違うの?
949login:Penguin
2019/01/27(日) 14:53:42.52ID:fUS4TOTI
>>948
どっかのオタクが気紛れにつくったものなんてビジネスでは使い物になりません
その点、RedHat(IBM)ならエンタープライズクォリティの長期的なサポートが期待できます
950login:Penguin
2019/01/27(日) 15:47:54.73ID:00Tq2Umc
>>949
自分の責任では調査も満足にできず、
ベンダサポートが無いとダメなんでしょうね。
951login:Penguin
2019/01/27(日) 15:53:07.04ID:xXmMwFbM
>>948
>>937と同じモノだぬ
つかrktはKubernetes1.10でDeprecatedらしんで(ry
952login:Penguin
2019/01/27(日) 19:07:09.00ID:y2jdcPb5
>>937
rootなしで、privilleged できるのか?
953login:Penguin
2019/01/28(月) 15:28:20.98ID:syBmrriY
>>950
まさに給料ドロボーだなw
954login:Penguin
2019/01/28(月) 22:36:41.23ID:icVasB2F
>>950
自己責任で済む業態ならいいが、不具合起こしたときに客に損害賠償請求される仕事もあるんやで
ベンダーサポートを利用するのは、自分で調べればいいとかそういう問題ではなくてリスク移転が目的
955login:Penguin
2019/01/29(火) 17:07:51.00ID:Fyrpy00V
>>954
それはありますね。
ただ、ベンダを最初から持ち出す輩は、
ソースを調べようともせず、丸投げしているのがほとんどだとおもわれ。
956login:Penguin
2019/01/29(火) 19:00:11.23ID:hDvTFAkf
>>955
スレチだが、ベンダーに投げれば済むことをアホみたいに時間かけて自分で調査することが許されるのは相当恵まれた環境だと思うぞ
客に工数で金貰ってる仕事ならそんなの夢物語
957login:Penguin
2019/01/30(水) 17:08:21.07ID:njtuMnhH
>>954
ストレージでハマったさくらのクラウドはベンダにリスク移転できたか?
958login:Penguin
2019/01/30(水) 18:23:41.63ID:uRxIiy3K
費用って面ならあとから損害賠償請求すればいいだけでしょ?
959login:Penguin
2019/01/30(水) 18:50:29.28ID:njtuMnhH
すべてasisで提供されているのに損害賠償請求できるの?
んで実際ソレやったのか?
960login:Penguin
2019/01/30(水) 21:14:55.35ID:F5bN5PPB
そんなもん契約書次第だろ
議論の余地はない
961login:Penguin
2019/01/30(水) 21:20:58.33ID:F5bN5PPB
あとリスクって何も損害賠償だけじゃないぞ?
深刻な不具合が発生したときに自分で調査する羽目になった場合の所要工数もリスクだ
それをベンダーに丸投げできるならそれも正真正銘リスク移転だよ
962login:Penguin
2019/01/30(水) 21:27:21.06ID:gO6HjhZU
にじさんじの瀬戸メッチァ喋るやん
963login:Penguin
2019/01/31(木) 19:04:28.51ID:SEt2rCFr
>>960
結局損害賠償請求はできないってコトじゃん
ダメな時はダメ
そもリスク移転はできないとw
上っ面ダケのカッコつけマンばっかだなココwww
964login:Penguin
2019/01/31(木) 19:22:34.87ID:oJr/deB/
実例とごちゃまぜにして語るキチガイがいるからなぁ
965login:Penguin
2019/02/01(金) 16:12:43.36ID:veleUfqn
オマエもパッチ当ててwinが腐ったトキはブツブツ言いながらOS再インスコしてんだろ?w
毎回MSに損害賠償請求してんのか?そも出来んのか?
リスク転移はできない実例だらけじゃねえかw
966login:Penguin
2019/02/02(土) 05:09:18.32ID:qweRvoG8
サポートなんて問い合わせ先があるってだけ。責任転嫁なんてできるわけないんじゃん。
自分で調べられるんならいらないよ。
967login:Penguin
2019/02/02(土) 07:18:16.99ID:JrArb2fP
MSのサポートはすごいよな。
客「XXすると、こういう不具合が起きちゃうんだけど?」
MS「そういうことはしないでください。別の方法で実現してください。」
ごめん。元組み込み屋の愚痴でした。
968login:Penguin
2019/02/02(土) 07:52:41.66ID:3XhPu4nr
俺 バグがあるんだけど
MS 再現プログラム出してください
俺 はいこれ
MS お問い合わせの製品バージョンはサポート終了です
俺 再現プログラムは最新バージョンで再現するんだけど
969login:Penguin
2019/02/02(土) 10:05:27.09ID:cQdbYG8P
で最後の「俺」の発言に対する返答はどうなったんだよ
970login:Penguin
2019/02/02(土) 13:06:15.28ID:pCnn3K+7
最新版で出してくれとか、弊社側では再現しませんでしたと切られるのがオチでね
971login:Penguin
2019/02/02(土) 16:43:13.68ID:jUrf+AdQ
もしくはメール返答なしでバックレ
972login:Penguin
2019/02/02(土) 16:47:04.08ID:jUrf+AdQ
>>967
戴爾も笑えるぞ
viivロゴ貼ってるならHDDがNCQ対応じゃねえとダメじゃねえの?という質問に調査中のまま逃げ切りw
973login:Penguin
2019/02/02(土) 16:57:43.71ID:h6ieGB3B
>>970
再現しないとしたら誰がどうやって対応するの
「再現しませんでした」は「こっちとは無関係なお前独自の環境が原因なので何とかできるのはお前だけだ、俺に聞いてどうする?」を優しく言ってるだけ
974login:Penguin
2019/02/02(土) 18:31:37.38ID:dk7sB3r7
MS、Officeの不具合パッチ流すのやめてくれ
975login:Penguin
2019/02/03(日) 05:44:12.80ID:koSKauE2
>>969
最新版でも再現することをMSも確認した
そして最新版の修正もなく打ち切られた
976login:Penguin
2019/02/03(日) 10:25:58.68ID:dS0GyCMA
>>975
打ち切られた理由は?
977login:Penguin
2019/02/03(日) 15:46:13.79ID:kN2VjkXf
そらMSのツゴーだろうよw
聞くだけヤボってもんよ
978login:Penguin
2019/02/19(火) 21:57:46.73ID:U4Prz7TT
セキュアなコンテナランタイム「Kata Container」が、AWSのマイクロVM「Firecracker」をサポート。アプリごとに適切なコンテナランタイムを選ぶ時代へ
https://www.publickey1.jp/blog/19/kata_containerawsvmfirecracker.html
979login:Penguin
2019/02/19(火) 23:02:10.34ID:FQ6sC9Tr
kata containerってFirecrackerと同じレイヤーのランタイムだと思ってたけど違うのか
980login:Penguin
2019/02/24(日) 20:56:46.61ID:UW23N+WY
社内にswarmクラスタを組んだのですがvolumeはどのように扱うべきなのでしょうか
node1にappをdeployした場合appはnode1のvolumeをマウントます
ここでなんらかの理由でnode1がクラッシュしnode2でappが再起動した場合node1のvolumeはマウントできないので初期状態でappが起動してしまいます
981login:Penguin
2019/02/25(月) 00:40:10.33ID:BnMI4WRV
どこかしらの共有ストレージをマウントするようには設定できねえの?
982login:Penguin
2019/02/25(月) 00:45:58.13ID:BnMI4WRV
あとはどこかしらのオブジェクトストアを指定して初期化するような動作を組み込むとか
983login:Penguin
2019/03/01(金) 15:29:53.96ID:xrG1UD6E
swarmってオワコンじゃないの?
984login:Penguin
2019/03/01(金) 16:24:25.69ID:hJmOve+b
ドッカーだけでコンテナクラスタ構築するならswarmの方がとっつきやすくね
985login:Penguin
2019/03/01(金) 17:48:52.38ID:u7yAg4zl
クラスタ構築は楽だと思う
あとcomposeを再利用できる
986login:Penguin
2019/03/02(土) 09:47:08.79ID:hHUXJebU
https://www.atmarkit.co.jp/ait/articles/1902/27/news062.html

「サイズ約40MBの単一バイナリ」:
Rancher Labs、エッジ向けKubernetes軽量ディストリビューションOSSプロジェクト「k3s」を開始

Rancher Labsは2019年2月26日(米国時間)、IoTなど、コンピューティングリソースへの制限が厳しい環境で動かすためのKubernetesディストリビューションを開発するオープンソースプロジェクト、「k3s」を開始した。
987login:Penguin
2019/03/02(土) 13:32:23.42ID:HhtvgbJA
> 「Dockerを使った単一ノードのKubernetes v1.13.3クラスタは1GBを少し超える程度のメモリを使う。k3sの同一構成では260MBを少し超える程度で、これにはアップストリームのクラスタに含まれないingressコントローラーやサービスロードバランサーが含まれている」

260MBのメモリを積んでるIoT()なの?w
988login:Penguin
2019/03/02(土) 14:03:16.12ID:hHUXJebU
IoTってラズベリーパイとか?
512MB~1GBはあるみたいだから余裕じゃね?
989login:Penguin
2019/03/02(土) 14:45:17.96ID:HhtvgbJA
なるほどな
最低でもラズπレベルがターゲットなんだな
990login:Penguin
2019/03/03(日) 21:03:54.85ID:V2hHzaOy
Kubernetesのmanifestの管理ツール「ksonnet」を使ってみた
https://qiita.com/inajob/items/7abe753a7c2c828230f9

これ何?くそねっと?
991login:Penguin
2019/03/04(月) 06:10:55.52ID:ncGnte76
ひでー名前だな
992login:Penguin
2019/03/04(月) 16:35:31.51ID:Bzh6FZoE
害人はマイナー言語つかう極東の住民になんか忖度しねえからな
993login:Penguin
2019/03/04(月) 21:16:51.60ID:wlTL6r9s
ケーソネットと読めばセーフ
994login:Penguin
2019/03/07(木) 08:52:57.92ID:8bFI1LrB
>>987
それはmaster/worker混在構成だからでしょ。
workerだけならもっと少ない。
995login:Penguin
2019/03/07(木) 23:32:51.30ID:iQ4RAsdJ
くそねっと
996login:Penguin
2019/03/08(金) 08:09:45.99ID:YU/9ulof
Docker RegistryをP2Pでスケーラブルに再構築した「Kraken」、Uberがオープンソースで公開
https://www.publickey1.jp/blog/19/docker_registryp2pkrakenuber.html
997login:Penguin
2019/03/08(金) 10:18:13.00ID:X6Yaxopy
>>939
> さようならDocker

その言葉、何年も前に聞いた気がする。
Dockerの代わりとなる、あれなんだっけ?
消えたのはあっちだったよなぁw
998login:Penguin
2019/03/08(金) 10:20:52.92ID:X6Yaxopy
>>987
> 「Dockerを使った単一ノードのKubernetes v1.13.3クラスタは1GBを少し超える程度のメモリを使う。

やっとメモリ使用量の問題についての話題が出たなーって感じ。
kubernetesをGCPの4GBぐらいもVMで使って、
おいおい、1/4もメモリ持っていくのかよ。
そこにサーバーいれなきゃいけないんだぞって呆れてた
999login:Penguin
2019/03/08(金) 10:23:07.74ID:X6Yaxopy
訂正 kubernetesをGCPの4GBぐらい"の"VMで使って、
正確には3.75GBだっけな?
1000login:Penguin
2019/03/08(金) 14:40:54.40ID:VDOvuQ0J
Docker Part3
http://2chb.net/r/linux/1552023620/
10011001
Over 1000Thread
このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 526日 0時間 40分 9秒
10021002
Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php

ニューススポーツなんでも実況



lud20250529165102ca
このスレへの固定リンク: http://5chb.net/r/linux/1506574845/
ヒント:5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。

TOPへ TOPへ  

このエントリをはてなブックマークに追加現在登録者数177 ブックマークへ


全掲示板一覧 この掲示板へ 人気スレ | Youtube 動画 >50 >100 >200 >300 >500 >1000枚 新着画像

 ↓「Docker Part2©2ch.net ->画像>1枚 」を見た人も見ています:
280blocker Part20
280blocker Part22
280blocker Part19
【◆AppliliZ/.】280blocker Part16【広告非表示】
Rocket League Part3
ANA Pocket Part1.5くらい
Socket AM3/AM3+マザー総合 Part11
【ポケカ】Pokémon TCG Pocket part1
【広告除去】Adguard Part3【280blocker】
【広告除去】AdGuard Part39【280blocker】
【広告除去】AdGuard Part31【280blocker】
【広告除去】AdGuard Part17【280blocker】
Warlock - Master of the Arcane 総合 Part2
【Fullfull☆Pocket】フルフル☆ポケット Part6
【広告除去】AdGuard Part40【280blocker】
【広告除去】Adguard Part5【280blocker】
【広告除去】AdGuard Part8【280blocker】
【広告除去】AdGuard Part33【280blocker】
【広告除去】AdGuard Part11【280blocker】
【広告除去】AdGuard Part17【281blocker】
DJI Osmo Pocket 1,2,3 Part44 【本スレ/ワッチョイ】
EMOBILE SoftBank回線 Pocket WiFi(GL09P~)Part3
ROCKET LEAGUE ロケットリーグ総合スレ part51
クロケット&ジョーンズ CROCKETT&JONES Part22
ROCKET LEAGUE ロケットリーグ総合スレ part41
【LGA1200】Intel Rocket Lake Part13【14nm++】
【COJP】コード・オブ・ジョーカーPocket part57
【Fullfull☆Pocket】フルフル☆ポケット Part8
【LGA1200】Intel Rocket Lake Part10【14nm++】
【LGA1200】Intel Rocket Lake Part19【14nm++】
【LGA1200】Intel Rocket Lake Part11【14nm++】
【LGA1200】Intel Rocket Lake Part20【14nm++】
【COJP】コード・オブ・ジョーカーPocket part81
【COJP】コード・オブ・ジョーカーPocket part50
【COJP】コード・オブ・ジョーカーPocket part84
【COJP】コード・オブ・ジョーカーPocket part64
【COJP】コード・オブ・ジョーカーPocket part67
【COJP】コード・オブ・ジョーカーPocket part65
【ポケポケ】Pokémon Trading Card Game Pocket Part7
【ポケポケ】Pokémon Trading Card Game Pocket Part8
【次スレくらい】ROCKET LEAGUE ロケットリーグ総合スレ part60【立てろ高卒】
ポケモンGo ポケットオートキャッチ GO-TCHA pocket egg総合スレ Part.14
GEZAN×PKer Part.10
ClockLauncher part6
ジョーカー/JOKER part01
ジョーカー/JOKER part9
ジョーカー/JOKER part23
ジョーカー/JOKER part18
ジョーカー/JOKER part31
鉄拳7FR ~TEKKEN7FR~ part20
Fender Stratocaster Part91
鉄拳7FR ~TEKKEN7FR~ part219
鉄拳7FR ~TEKKEN7FR~ part49
docomo AQUOS R SH-03J Part6
docomo AQUOS R SH-03J Part9
docomo AQUOS R SH-03J Part7
鉄拳7FR ~TEKKEN7FR~ part55
鉄拳7FR ~TEKKEN7FR~ part72
鉄拳7FR ~TEKKEN7FR~ part221
鉄拳7FR ~TEKKEN7FR~ part139
鉄拳7FR ~TEKKEN7FR~ part115
鉄拳7FR ~TEKKEN7FR~ part161
FAT WRECKED FOR 25 YEARS part4
【VW】シロッコ Part15【SCIROCCO】
【SW】 SoulWorker ソウルワーカー Part93
【不要!?】 PLEXTOR AS-Striker Part.01

人気検索: Olivia model 昔のロリ女子小学生マン 洋ロリ画像 繝代う繝代Φ ショタ 画像 女子高生 女子小学生のパンツ 小学生のマンコ画像 中学生 mouse 水着
13:36:34 up 96 days, 14:35, 0 users, load average: 7.92, 8.47, 8.25

in 1.2370798587799 sec @1.2370798587799@0b7 on 072302