Docker Part2

1 ：login:Penguin ：2017/09/28(木) 14:00:45.18 ID:/4TtIqGt.net

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

http://www.docker.io/

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

2 ：login:Penguin：2017/09/28(木) 19:24:33.96 ID:pP51x30K.net

もうLXCに依存してないんじゃ？

3 ：login:Penguin：2017/09/29(金) 11:42:26.61 ID:/O2TcHk2.net

そうだね
前スレからそのまま持ってきてしまったか

4 ：login:Penguin：2017/09/30(土) 13:41:02.45 ID:DWXPURAf.net

>>1
乙

5 ：login:Penguin：2017/10/05(木) 08:50:48.55 ID:i7Czn2dk.net

>>1
乙

6 ：login:Penguin：2017/10/09(月) 14:16:55.78 ID:XfEexTHm.net

本番系のマシンと、Docker動かしてるホストとで、カーネルのバージョンって
みなさんどこまで合わせてます?

うちはRHELで動いてる本番系と、それとコピーの総合試験環境があって、
そいつらはカーネルもパッケージもバージョン揃えてあるんだけど、
その手前の、コーディングとか単体試験とかをやるコンテナ動かすDockerのホストも
やっぱしカーネルのバージョン揃えるべき?

7 ：login:Penguin：2017/10/11(水) 00:31:44.42 ID:pRpQhrR6.net

>>6
うちは本番系から単体試験ホストまですべてカーネル揃えることにしてるよ

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

理想はどうあれ、揃えておきなよ

8 ：login:Penguin：2017/10/12(木) 19:50:29.01 ID:2wGdxaeV.net

本番系と、カーネルだけ揃えておけばいつでもコンテナ作れるっていうのが仮想マシンに対するDockerの大きな利点

カーネルをバージョンアップしてコンテナが壊れたんならさっさと作り直す、さっさと作り直せるように周辺の仕組みを整える、
消されて困るコンテナは作らない、他とカーネルを揃えられないコンテナも作らない、なんてことがDockerカンファレンスでも
強く言われてた

9 ：login:Penguin：2017/10/24(火) 23:51:58.75 ID:dIybMC7m.net

hoshu

10 ：login:Penguin：2017/10/25(水) 00:04:46.37 ID:G0dNcMaK.net

Arukas終わったしもう遊べる場所はないのかな
GCPは制限ありそうだし

11 ：login:Penguin：2017/11/12(日) 21:27:42.49 ID:uiCH3XRM.net

Linux板で言うことじゃないかもしれないけどWindowsでもHyper-Vで使えるようになってたんだな
Bash on UbuntuにDockerも使えてWindowsPC強制されて虐げられてもなんとかなるぜ

12 ：login:Penguin：2017/11/12(日) 21:43:45.89 ID:CsnX2d3s.net

＞WindowsでもHyper-Vで使えるようになってた
Windows以外で使えるHyper-Vなんてあるの？

13 ：login:Penguin：2017/11/12(日) 22:36:56.33 ID:uiCH3XRM.net

VirtualBoxが不要ってことを言いたかった

14 ：login:Penguin：2017/11/13(月) 01:31:56.29 ID:6Li+kjAO.net

HyperV無しのWSLで動くようになる予定はあるのかな
MobyとかLinuxKitとか出てきたし

15 ：login:Penguin：2017/11/25(土) 20:25:09.37 ID:NaxBhckIx

再帰的なmountってどうやればいい？
docker-composeのvolumesでmountすると、直接指定したディレクトリの中身は見れるのだけど、そのサブディレクトリが見れない。

16 ：login:Penguin：2017/11/28(火) 15:53:23.01 ID:79aY/WPA.net

タグが<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"
と出たこともありました。何のコマンドか失念。

このコンテナは起動もできません。
どうやったら削除できるでしょうか？

17 ：login:Penguin：2017/11/28(火) 23:02:15.82 ID:l6qc+Qst.net

docker imagesってやったらどうでるの？

18 ：login:Penguin：2017/12/03(日) 18:48:03.66 ID:zS+bJMf6.net

docker使うとこ増えたけど
アホって綺麗なサンプルいっぱいあるのになぜか設定ファイルグチャグチャ作るのな
結局構成管理出来ないだろ、あんなんじゃ

19 ：login:Penguin：2017/12/03(日) 21:33:00.17 ID:0hG1CDG4.net

Dockerで設定ファイル？何の話だ？
Dockerで構成管理？何の話だ？
お前なんか勘違いしてそうだな

20 ：login:Penguin：2017/12/03(日) 23:00:47.39 ID:+8H++mo7.net

まあ言いたいことはわかるよ
それだって秘伝のシェルスクリプトを書き足すよりはずっといいさ

21 ：login:Penguin：2017/12/04(月) 08:15:53.87 ID:5eeXMq5z.net

AWS Fargateってサービスがアマゾンからリリースされたらしいけど
それってなんなの？

22 ：login:Penguin：2017/12/13(水) 11:04:20.12 ID:ZUZ9fAW9.net

docker系の技術は日進月歩すぎるのでredhatやcentosのような枯れたOSで使うのはきついですよね？
色々入れたり設定が必要だし。
お勧めなディストリはやはりubuntuやfedoraなどですか？

23 ：login:Penguin：2017/12/13(水) 16:46:00.16 ID:4HtuxJmh.net

>>22
docker自体は日進月歩すぎるところがあるので、OSは枯れたモノを使うというのがベストプラクティス

fedoraでdocker運用するのって、fedoraのカーネル自体が不安定すぎて、コンテナ上げすぎると落ちたりするよ

24 ：login:Penguin：2017/12/13(水) 23:30:05.47 ID:CbAdTCk+.net

>>22-23
枯れた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の古いバージョンならもう少し古いディストリでも動くかもな

25 ：login:Penguin：2017/12/14(木) 02:05:22.37 ID:j6ffG0Yu.net

俺、OpenSuseで使ってる変態。

26 ：login:Penguin：2017/12/14(木) 09:58:33.91 ID:RtRhmnJE.net

Redhat/CentOSはカーネル古いから新しいバージョンのdocker composeが使えないよ

27 ：login:Penguin：2017/12/14(木) 13:39:44.17 ID:A3qqyatV.net

>>26
そんな制限あったっけ？
どこかに書いてある？

28 ：login:Penguin：2017/12/14(木) 16:57:21.98 ID:c0bTjVEo.net

GUIいらないからホストOSも軽くて無駄がないalpineにするのが好き
ほとんど何もできないから逆に後腐れなく気軽に捨てて新しくできるし！

29 ：login:Penguin：2017/12/14(木) 18:00:17.09 ID:mi3pWGl2.net

俺はホストにはfedora atomic使ってるぞ

30 ：login:Penguin：2017/12/14(木) 19:26:56.48 ID:xIrkk8hS.net

なんかlinuxがいいものになったかのような錯覚をおこすわ

31 ：login:Penguin：2017/12/14(木) 22:49:08.96 ID:j6ffG0Yu.net

coreosで使ってるっていう生粋のドッカーはいないのか？

32 ：login:Penguin：2017/12/15(金) 00:48:35.66 ID:1RLgszdT.net

CoreOSはもうねぇだろ

33 ：login:Penguin：2017/12/15(金) 05:01:05.33 ID:gXJiZmqG.net

coreOSってalpine以上に使いにくくて何が良いの？って感じなんだけど何か取り柄はあるのかね

34 ：login:Penguin：2017/12/15(金) 10:47:11.13 ID:pk6RU5gE.net

RancherOSが出たときコレは来るかと思ったがそうでもなかった

35 ：login:Penguin：2017/12/15(金) 11:38:23.07 ID:Goys0rX2.net

雨後の筍のようにポコポコ出てくるな
はやく収斂してくれ

36 ：login:Penguin：2017/12/15(金) 21:13:24.95 ID:QXRMWfvA.net

そいつらがいずれ、どうにもつまらない理由で内輪もめを起こしてまとまらなくなり
あの機能はそちらにしかない、その機能はあちらにしかない、なんて状況となってる間に
OracleやMSに持っていかれる、というところまでがテンプレ

37 ：login:Penguin：2017/12/15(金) 22:20:10.00 ID:7toohCc2.net

誰かが早く僕の考えた最強Linuxを発表しないとな。
え、それが乱立してるって？

38 ：login:Penguin：2017/12/17(日) 02:54:12.57 ID:fi9E8CtD.net

BargeっていうのがDockerホスト用で最軽量・高速ブートをうたってるけど
これVirtualBox専用でノートPCとかには直接インスコできないのかな？

更新頻度は高いみたいだから物理マシンでも動けば最強候補じゃないかコレ

39 ：login:Penguin：2017/12/17(日) 03:00:59.83 ID:FdcUbRUW.net

それ完全にvagrant用では？

40 ：login:Penguin：2017/12/18(月) 00:14:34.47 ID:V88qic40.net

RaspberryPiで使えますみたいなことは書いてあるね
普通には使えないっぽいのは何か残念だな

41 ：login:Penguin：2017/12/18(月) 08:24:13.84 ID:5bGVyFGG.net

やっぱubuntu + kubernetesがいいのかな

42 ：login:Penguin：2017/12/19(火) 12:43:18.15 ID:Unb97h+7.net

これからはなんでもかんでもコンテナって時代になるのですかね？
自前でリポジトリをシコシコ築いてきたディストリベンダーも
もはややる意義を失っちゃったりするんですかね？

43 ：login:Penguin：2017/12/19(火) 15:47:37.58 ID:mHmneXcK.net

未だにコンテナとchrootの違いが理解できない

44 ：login:Penguin：2017/12/19(火) 18:27:38.96 ID:JOmZ8i6e.net

chはchangeの頭文字から取っているから
rootの変更って意味だろう
コンテナはOS内にあるけど完全に独立しているから

例えばある家族の家の中で、
親がroot
子供がchroot
ホームスティしてきた外国人娘がコンテナだ

45 ：login:Penguin：2017/12/19(火) 21:21:37.08 ID:qjPggouG.net

>>42
コンテナ使い出すと便利すぎてディストリあれこれこだわってたのが笑えてくるほどだね

そして指摘の通り、独自にバグ潰しとかやってる一番活発なリポジトリ持ってるところと
逆に古いツールを保守し続けてるところはもてはやされてるが、それ以外が意気消沈してる
二極化だな

46 ：login:Penguin：2017/12/19(火) 21:29:10.23 ID:qsrDOXqO.net

リソースが集中するのはいいことではあると思う

47 ：login:Penguin：2017/12/20(水) 01:46:37.73 ID:W5Cyms8a.net

パッケージ管理ツールをLSB前提でpythonやperlで書いてたところは
それが原因でコンテナイメージのサイズをある一定以下に削減できなくてイーッてなってた

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

でもまさかパッケージを単品ごとにインスコする日が来るとは誰も思ってなかったんだよな結局は

48 ：login:Penguin：2017/12/20(水) 08:11:34.55 ID:XbCsAUuJ.net

コンテナってもっと早く登場しても良かった気がするんだが
技術的にはホスト型ハイパーバイザ型の仮想化よりも簡単なんじゃないの？

49 ：login:Penguin：2017/12/20(水) 09:16:28.83 ID:G/qWb3nN.net

そりゃ日本での常識だな、
日本は金持ちだから高性能コンピューターが当たり前だけど
世界的にはようやく高性能コンピューターが普及してきた
ようやっとOS内にOSをおいても通常に使えるぐらいのPCが普及してきたんだ

50 ：login:Penguin：2017/12/20(水) 11:24:05.90 ID:XXomYUaW.net

それはひょっとしてギャグで言ってんのか

51 ：login:Penguin：2017/12/20(水) 15:46:11.75 ID:ZRehS3G5.net

コンテナは昔からあっただろ
Linuxに来るのが遅かっただけで

52 ：login:Penguin：2017/12/21(木) 07:55:01.09 ID:9tWXeT0T.net

user mode linuxはコンテナに入りますか?

53 ：login:Penguin：2017/12/21(木) 20:10:57.04 ID:K3jlwK7o.net

コンテナ内のプロセスがしんで終了しても自動でコンテナ再起動してくれるオプションがあった
コレ使えばわざわざプロセス死活監視用ツール起動しなくて良くなるのか
ちょっとスゴ杉ない？

54 ：login:Penguin：2017/12/21(木) 20:41:31.20 ID:dn2463i7.net

そんなもんsystemdに標準搭載されてる機能だろ

55 ：login:Penguin：2017/12/24(日) 22:37:12.09 ID:rLGBbeuy.net

dockerコンテナってホストOSのカーネル使ってるの？
どこもそう説明してるんだけど、ベースイメージにlinuxつかってその上にmysqlとか載せてイメージ化してるって認識だったんだが。

56 ：login:Penguin：2017/12/24(日) 22:40:54.12 ID:BfGqUwPY.net

ホストのカーネルを使っているという説明で合っているよカーネルの上で動かすカーネルとかもうそれVMじゃん

57 ：login:Penguin：2017/12/24(日) 22:58:36.30 ID:rLGBbeuy.net

>>56
ありがと。
そうなるとwindowsだとdockerインストール出来るけど、エンジンとかに工夫してあるのか

ttps://www.slideshare.net/zembutsu/docker-images-containers-and-lifecycle
ここの19ページめに、ベースイメージにイメージ層を載っけていくて記載あるけど、
これは間違ってるの？

58 ：login:Penguin：2017/12/24(日) 23:14:23.88 ID:jQND+IMW.net

http://www.publickey1.jp/blog/17/dockerlinuxkitlinux_subsystemdockercon_2017.html
こういうのじゃね？

59 ：login:Penguin：2017/12/24(日) 23:22:26.32 ID:rLGBbeuy.net

>>58


https://github.com/docker-library/mysql/blob/6c414e7f38c2079c7193beae5dc7c34ee46cd6e7/8.0/Dockerfile
mysqlのdockerfileだと FROM debian:jessie ってあるけど、
これはどうなの？？
何かこんがらがってきた。
sshで入れるし、やっぱ根底はlinux立ち上がってるのか？

60 ：login:Penguin：2017/12/24(日) 23:52:48.02 ID:FG7A/gM3.net

おい、素人同士で勝手に話をすすめるなｗ

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

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

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

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

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

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

そんなもんだから、Debianをインストールしていたとしても、UbuntuやCentOSのディスクイメージを使うこともできる

61 ：login:Penguin：2017/12/24(日) 23:57:01.81 ID:FG7A/gM3.net

パソコンにインストールしたカーネルを使う。
そこで疑問になるかもしれない。

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

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

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

それが大変な作業だった

62 ：login:Penguin：2017/12/25(月) 00:07:51.54 ID:132x0Uuj.net

さて、ここまではパソコンにインストールされたものが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の設定画面にはメモリをどれだけ仮想マシンに割り当てるかなどという設定が存在する

63 ：login:Penguin：2017/12/25(月) 00:11:59.89 ID:132x0Uuj.net

余談だがWindows 10ではWSLという仕組みによって
LinuxカーネルをNTカーネルでエミュレートしている

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

もしこのWSLがコンテナ機能までエミュレートする完璧なものになったら
その時はWindowsでHyperVを使わずにDockerが動くようになるだろう

64 ：login:Penguin：2017/12/25(月) 11:30:09.88 ID:+uvKLng+.net

>>63
親切すぎて草
下手な記事よりわかりやすい

65 ：login:Penguin：2017/12/25(月) 15:39:08.55 ID:h9oxS0er.net

＞もしこのWSLがコンテナ機能までエミュレートする完璧なものになったら

なるのかね？
最近MSがLinuxに擦り寄ってて気持ち悪い

66 ：login:Penguin：2017/12/25(月) 23:01:24.32 ID:gZwRVfZh.net

>>63
帰ってきたらすごい丁寧なレス来てたっ
ありがとうございます

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

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

windows, macも結局裏では仮想化されてたのね
色々わからなかった所が一遍にわかったわ！

67 ：login:Penguin：2017/12/26(火) 01:41:07.93 ID:SZApAg+E.net

>>60-63
これは永久保存レベル

Github上のissueでもWSLだけでLinuxコンテナ動かしたいって要望はかなり挙げられてて
MSスタッフからみんなの期待は認識してますってレスも付いてた
もしホントに実現したら世界が変わる！みたいな投稿もあって大げさだけどちょっと同意しちゃう

68 ：login:Penguin：2017/12/26(火) 03:02:30.31 ID:+n8uGZb5.net

>>60-63を書いた本人だけど、なんでこんなに喜ばれてるんだろう？ｗ
WindowsやMacOSでDocker使ってる人にとっては常識だと思ったんだけどね

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

あと仮想化という言い方は良くない
色んな意味の仮想化があるから

69 ：login:Penguin：2017/12/26(火) 03:07:47.91 ID:+n8uGZb5.net

WindowsやMacOSで使った時のDockerのボリュームって謎だよね

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

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

まあホストOSのディレクトリを仮想マシンのディレクトリにマッピングしてるんだろうけど
Docker for WindowsやDocker for Macではそういうことを感じさせない作りになってる

70 ：login:Penguin：2017/12/26(火) 10:06:07.39 ID:4aRFRiu5.net

vagrant入れて色々弄ってた後にdockerやったから全然気付かなかった
職場macで家はwindowsで、両方vagrant入れてたしね

ネットで調べても、その手の情報全然見なかったよ
本読んで勉強しろって話なのかな？

71 ：login:Penguin：2017/12/26(火) 11:22:56.05 ID:pkkjJJya.net

>>68
自分は初心者なのでナイスな解説に出会えてラッキーでした
ありがとう

72 ：login:Penguin：2017/12/26(火) 12:31:53.02 ID:KRPyxQju.net

俺も最近、Docker for Windows入れてみてたばかりなんで、HyperVが必要な理由とかが分かって参考になった

73 ：login:Penguin：2017/12/26(火) 23:42:23.56 ID:+n8uGZb5.net

> ネットで調べても、その手の情報全然見なかったよ
> 本読んで勉強しろって話なのかな？
そうなんか？ じゃあなんで俺知ってるんだろう？ｗ
もう3年ぐらい前から触ってるからなぁ。当時はWindows使っていたし（今はMacOS）

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

じゃあおまけでもう少し仕組みの話を。

74 ：login:Penguin：2017/12/26(火) 23:58:14.94 ID:+n8uGZb5.net

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が必要なくなっている
どういう仕組みになってるんだろうね？ｗ
少し前の手順を見ると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で使う必要がある

75 ：login:Penguin：2017/12/28(木) 15:12:36.60 ID:LWC+fC47.net

>>74
勉強になります

最近はOS、仮想化、dockerと色々と入り乱れて全体像を理解するのに苦労するなぁ
ま、所詮パンピーですから

76 ：login:Penguin：2017/12/28(木) 17:00:45.45 ID:+qKarqEU.net

dockerとkubernetes使いこなせないと時代遅れになるぞって言われたけど
一般の開発者がkubernetesを必要とするシーンってどのくらいあるのかな
dockerは問答無用で便利だけど

77 ：login:Penguin：2017/12/28(木) 23:05:22.59 ID:BIGMxhMF.net

dockerとkubernetesの間にクラウド（aws、gcp等）があるね
クラウドを使わなければkubernetesはでてこないだろう
ローカルでのサービス開発用途であればdocker-composeで十分だし

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

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

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

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

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

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

kubernetesはバージョンが勝手にアップグレードする（GCPの場合）ことを考慮しないといけないのと
kubernetesを動かすだけで各VMで1.5GB以上のメモリを使用するのが気に入らない

78 ：login:Penguin：2017/12/29(金) 12:41:26.85 ID:S/CsVkMC.net

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

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

PTHNS6LLYQ

79 ：login:Penguin：2017/12/30(土) 19:21:43.13 ID:kIwYFCo/.net

kubernetesはほぼ全部の業界大手が参画してるけど
そんでもコケるってことあるんかな
いやまぁ莫大な金が動くインフラ業界だからねぇ

80 ：login:Penguin：2017/12/30(土) 21:07:01.76 ID:/wpJUWvV.net

Docker swarmが本命じゃないの？

81 ：login:Penguin：2017/12/30(土) 23:02:49.87 ID:R3GCT2Hw.net

>>80
もうフェードアウトフェーズだよｗ

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

しばらくはswarmでもできる！とかやるだろうけど
次第にフェードアウト

82 ：login:Penguin：2017/12/30(土) 23:41:06.85 ID:4E+qMbRD.net

小規模ではdocker-compose一択って事でおk？

83 ：login:Penguin：2017/12/31(日) 03:26:38.05 ID:AHTq9Vf1.net

小規模っていうか、1台のマシンの場合って考えてるよ
開発用メインでdocker runのオプションを指定するのが
面倒になった時ｗ

84 ：login:Penguin：2018/01/18(木) 10:27:56.69 ID:edyLm1wn.net

Docker toolboxの最新版（18.01.0-ce）を入れたら何故かdockerのデーモンに接続できなくなったけど
VirtualBoxのGUIから仮想マシンを止めたら直った

docker-machine restartは効果がなかった

85 ：login:Penguin：2018/01/18(木) 17:40:21.34 ID:G+DL28hG.net

なんでvirtualbox？

86 ：login:Penguin：2018/01/18(木) 18:22:49.70 ID:HcoLdHLc.net

Docker toolboxってwin/mac上にlinux走らせてその上で更にdockerしてるからね

87 ：login:Penguin：2018/01/18(木) 21:17:36.99 ID:ZKzLgYJR.net

いつの話？

88 ：login:Penguin：2018/01/18(木) 23:21:47.35 ID:oYgm6+gm.net

誰もがWindows Proを使えるわけじゃないからなぁ
VirtualboxベースのDocker toolboxはまだ必要意義は大きい

89 ：login:Penguin：2018/01/30(火) 15:24:33.94 ID:qZpjgluz.net

Hyper-VはProfessional以上必須なのか。
リモートデスクトップサーバ使いたいから、"わざわざ"Professionalのライセンス
にしてるけど、Docker for Windows (Hyper-V)を使うために必要ってのは微妙。

90 ：login:Penguin：2018/01/30(火) 16:34:53.53 ID:VSfpjLUl.net

Docker使ってるとKubernetesしたくなってきてKubernetes on Atomic Host on Hyper-Vとか組みたくなるしへーきへーき

91 ：login:Penguin：2018/01/31(水) 02:46:07.43 ID:Y/TJiD1T.net

>>89
そういう人のためにDocker Toolboxというのがある

92 ：login:Penguin：2018/02/01(木) 04:43:55.93 ID:oMuXW2h/.net

coreOSがRedHatに買収された

93 ：login:Penguin：2018/02/02(金) 08:59:37.20 ID:yFWv8+qQ.net

CoreOSはDocker利用を想定してたけどコレジャナイ残念OSだったので次はRancherOSあたりに期待してる

94 ：login:Penguin：2018/02/03(土) 13:01:31.67 ID:3HQCIEUi.net

>>92
ヤフーの記事が、港のコンテナヤードの画像使ってて混乱したわw

95 ：login:Penguin：2018/02/03(土) 15:14:06.84 ID:TzIPoha8.net

クジラの方のコンテナって言えば通じる

96 ：login:Penguin：2018/02/05(月) 13:34:29.22 ID:k5aVtYPL.net

コンテナをビルドするとき Dockerfile 内で

RUN yum list

した結果を、ホスト側に残したいんだけど、なんか良い方法ないかな？

97 ：login:Penguin：2018/02/07(水) 01:28:24.21 ID:G933ziiv.net

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

98 ：login:Penguin：2018/02/08(木) 17:41:54.10 ID:lNZDnl+7.net

>>97
便利なやり方が無いかなーと思って。
一度起動してその出力を回収する方法しかないね。

99 ：login:Penguin：2018/02/14(水) 02:35:31.11 ID:XB7JYlAs.net

/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不要だけどイメージダウンロードからやり直しになって鬱陶しかった

100 ：login:Penguin：2018/02/15(木) 00:59:03.05 ID:m3isa15O.net

☆ 現在、衆議員と参議院の両院で、改憲議員が３分の２を超えて
おります。総務省の、『憲法改正国民投票法』、でググってみてください。
国会の発議はすでに可能です。日本の、改憲を行いましょう。
平和は勝ち取るものです。お願い致します。☆☆

101 ：login:Penguin：2018/02/15(木) 12:06:04.40 ID:2MLB8/h1.net

>>99
その問題は /var/lib/docker 以下が ext4 なら、fstab でマウントオプションに commit=300 とか付けると結構な対策になる

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

俺は USB メモリだけで運用してると 1 年ちょっとで寿命が来て色々と試行錯誤の後
Arch のフォーラムかどっかに書いてあったこのシンプルな方法に落ち着いた

102 ：塩水 ：2018/03/11(日) 02:24:38.22 ID:hSBnN7Ry.net

dockerfile使わずにAnsibleでコンテナ構築してる人居ます？
物理で構築してたPlaybookのTarget SectionにDocker使うよって一行追加すれば使えるし(厳密には使えるようにするまでに色々設定は必要だけど)、
仮にコンテナのデファクトみたいなものがDockerじゃなくなっても最悪SSHで接続さえ出来れば流用できるからこのやり方良いなと思ってるんどけど。

103 ：塩水 ：2018/03/11(日) 02:25:38.04 ID:hSBnN7Ry.net

スマホのフリック入力慣れないな。。

104 ：塩水 ：2018/03/11(日) 02:32:17.59 ID:hSBnN7Ry.net

クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。
昔はVM作り直したり、スナップショットから復元したりしてたけど、今はそのマウス操作すら煩わしくなってしまってる。

105 ：login:Penguin：2018/03/11(日) 02:47:30.63 ID:FdJN57de.net

>>102
使っていませんｗ

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

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

俺は流用するならばシェルスクリプトが一番だと思ってるよ。
だってansibleで書いたYAMLって、ansible以外に流用できないでしょ？YAML書くのめちゃくちゃ手間だし
Dockerfileはシェルスクリプトにかなり近いので流用したいならDockerfileのままでいい
Dockerのイメージを作る時に限らず、なんでansibleなんか使うのか俺には理解できないよ

106 ：login:Penguin：2018/03/11(日) 02:55:22.05 ID:FdJN57de.net

>>104
> クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。

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

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

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

playbookとして書いたものが、手動でやったことと同様のことを
行ってくれるか？という "二重の検証" は必要なくなるのさ

107 ：塩水 ：2018/03/11(日) 03:31:17.92 ID:hSBnN7Ry.net

すごい煽られててビックリしましたｗ

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

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

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

コンテナのイメージ化という事も検証の一環として行いますが、メインの用途は
コンテナでPlaybookを高速で検証して、検証した構築用Playbookを本番のVMに放つという感じです。
(本番に放つ前に一度は検証用VMにも放って確認はします)

108 ：塩水 ：2018/03/11(日) 03:33:10.76 ID:hSBnN7Ry.net

今度は長文をPCから書き込んだらsage忘れた
2ch書き込みのブランクありすぎて色々ひどい。。

109 ：塩水 ：2018/03/11(日) 03:47:31.86 ID:hSBnN7Ry.net

>>106
私も冪等性なんてあてにするものではないと思ってて、
Ansibleに限らず、そのほかのツールも検証してないものは信頼しないというのが私の基本スタンスです。
(特に、かなり昔に作った構築系スクリプトはそのまま実行して一回で動くとは思ってません。)

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

例えば構築が失敗したとき、シェルスクリプト場合
何でコケたのか、どこでコケたのか、というのを探すところから始める必要がありますが
Ansibleだとコケた場所とコケた原因のコマンドが一目瞭然なのでとてもメンテしやすいのです。

110 ：login:Penguin：2018/03/11(日) 04:16:58.61 ID:FdJN57de.net

あちこちで煽ってるけどようやくまともな意見を返す人が見つかったな

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

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

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

> 2ch書き込みのブランクありすぎて色々ひどい。。
一体いつからここが２ちゃんねるだと錯覚していた？

111 ：login:Penguin：2018/03/11(日) 04:26:48.50 ID:FdJN57de.net

Ansibleがブラックボックスツールということの
意味がわからない人がいるかもしれないから
軽く説明しておいてやろう

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

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

でも本来のお前らの仕事である環境構築は
手作業やシェルスクリプトですぐに解決できるだろ？
Ansibleの範囲でうまくできてりゃいいさ、だが
それができない場合、大きなボトルネックになってんだろ

112 ：塩水 ：2018/03/11(日) 04:40:50.71 ID:hSBnN7Ry.net

なんかアドレスが5chになってる。いつの間に。。

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

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

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

ただ、ベストプラクティスもそのままだと実用としてどうなのというケースも多いので
現場に合わせてアレンジする作業は必須だと思いますが。
(教科書そのままでは現実では役にたたない、とよく言われるアレみたいな感じです)

Ansibleそのものの挙動はブラックボックスなところもあるかもしれませんが、
品質の担保はServerSpecのテストでやってます。
何か問題があったらServerSpecのテストを足せば良かったりします。
手順書に確認手順を追加するよりテスト書いてgitで管理して必要に応じて実行する方が簡単で確実かなと思ってます。

テストや確認事項を手順書に追加するのは手順書のメンテナンスも確認作業も面倒ですが
テストなら足して実行すればよいだけなので、細かすぎるような確認作業も気兼ねなくガンガン追加できます。

113 ：塩水 ：2018/03/11(日) 04:55:20.38 ID:hSBnN7Ry.net

多少はやったことありますが、AnsibleのモジュールそのものをPython書いて修正するというのは敷居がけっこう高いですね。。
確かに、廃止されたりオプションが変わったり、変な挙動のモジュールもあります。
解決策はそのモジュールが使えてるAnsibleのバージョンを固定するか
最悪、shellやcommandモジュールでLinuxコマンドべた書きするかでしょうか。

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

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

そこでdockerコンテナを使ったPlkaybookの高速検証が活きてくるという。

114 ：塩水 ：2018/03/11(日) 05:13:32.25 ID:hSBnN7Ry.net

さらさらっと書いてますが、このようなdocker,ansible,Serverspecの環境を作るのはそれなりに大変だと思うので、
もしやるならばこの辺に詳しいインフラエンジニアに任せた方が良いかも。

115 ：login:Penguin：2018/03/11(日) 11:20:29.98 ID:FdJN57de.net

>>112
> 今書いた複雑なスクリプトを一年後の自分が読めるとは思ってないのです。
環境構築ごときでなんで複雑になるのかそこが不思議。
まず一つだけアドバイスするなら、設定はファイルの項目ごとに変更するのではなく、
設定ファイルをまるごとcopyすること。これで冪等性も担保される。

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

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

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

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

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

あとServerSpecでも同じくブラックボックス問題がある。ServerSpecでは一体何を調べてるんだって話だよ
例えばpackageでパッケージがインストールされているか調べられるが、パッケージの管理方法はディストリで違うはずだ
packageはAlpineのapkでも使えるのか？という質問に自信をもって答えられるのか？すぐにソース読みとけるのか？
（まあそこはコマンドが実行できればOKとするのが、やるべきテストだと思うけどさ）

116 ：login:Penguin：2018/03/11(日) 11:22:42.29 ID:FdJN57de.net

ServerSpec実行してOKがでればOKと信用すりゃいいんだろうけどさ、何をテストしているのかさっぱりわからん。
ServerSpec（というかrspec）というフレームワークはブラックボックスで良いんだが
肝心のテスト内容（matcher）で何をやってるのかは把握してなきゃだめだろ？

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

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

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


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

最初の質問にもう一度答えると
> dockerfile使わずにAnsibleでコンテナ構築してる人居ます？
つかわん。dockerなら冪等性いらないし、1コンテナで動かすものは極力シンプルにするので
構築内容は短くなる。逆にAnsibleを動かすための部分のほうが長くなる

117 ：login:Penguin：2018/03/11(日) 11:30:56.88 ID:FdJN57de.net

>>114
> もしやるならばこの辺に詳しいインフラエンジニアに任せた方が良いかも。
インフラエンジニアじゃないのか？俺も違うけどなｗ

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

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


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

みたいなな。

インフラエンジニアってなんであんなクソなもの平気で使えるの？

118 ：login:Penguin：2018/03/11(日) 11:48:05.06 ID:JbaTrnc+.net

オンプレでウォーターフォール、一度作ったマシンを後生大事に使い続ける、
そんなスタイルならDockerすら不要かと

119 ：塩水 ：2018/03/11(日) 15:33:16.62 ID:hSBnN7Ry.net

> 環境構築ごときでなんで複雑になるのかそこが不思議。
社内のVMwareで作ったイメージを直接客先に入れられるならもっと簡単に作れるんですけどね。。
オンプレ上で直接構築する場合、内部やDMZなど環境毎にproxyやDNS、ntpやファイヤーウォールの設定が違ってたりするのです。
あと、WebサーバでIPアドレスだけ変えて後は全部一緒の設定にしたい場合は
Webサーバ分だけ設定ファイル作るんじゃなくて、テンプレート作ってIPアドレスだけ動的に変えて配布するとか。
便利です。

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

> 細かいファイルに分かれていて、notifyとはhandlersとか使っていて、これどうなってるんだ？って頭を抱えたことが有るんだがｗ
そうですね。サービスが再起動されるのが状態が変更された場合という事ですけど
何をもってサービスが変更されたとするかというのがわかりにくいかもですね。
私はこれ積極的には使ってなくて、serviceモジュールで明示的にサービス再起動してます。
基本的に冪等性は考えないスタンスの一言なのですが、使わない理由をあえて考えると
構築時はいくらどのタイミングでサービスを再起動しても本番に影響は無いのと、
稼働中のサーバのサービスを再起動する場合は明示的に確実に特定のタイミングで一回だけ再起動させたいからでしょうか。

120 ：塩水 ：2018/03/11(日) 15:34:04.20 ID:hSBnN7Ry.net

> テストのためだけにRubyをサーバーに入れなきゃいけないってのもナンセンスだよなｗ
> 入れない方法もあるんだっけ？
Serverspecは私の知ってる限りのやり方ではRuby要りますね。gemですし。
サービスと関係なくある程度裁量で触れるステージング的なサーバがあれば
客に許可をもらってそこに入れるとか。。

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

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

AnsibleやServerspecそのものがどうなってるかではなくて、自分が構築したサービスがちゃんと機能しているかを見ます。
こういう着眼点にすれば、将来もしAnsibleやServerspec以外の便利なソフトができても移行の判断がしやすかったりします。

121 ：login:Penguin：2018/03/11(日) 15:53:28.62 ID:FdJN57de.net

> オンプレ上で直接構築する場合、内部や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() の中身を書き連ねるだけ。

122 ：塩水 ：2018/03/11(日) 16:11:14.24 ID:hSBnN7Ry.net

>>117
>インフラエンジニアじゃないのか？俺も違うけどなｗ
元インフラエンジニアで今の職業は百姓です。田舎で野菜作ってます。

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

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

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

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

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

私はAnsible、dockerは流行ってるから採用したのではなくて、
ある程度プライベートで遊んで便利そうだったから職場にも持ち込んだという流れでした。

123 ：login:Penguin：2018/03/11(日) 16:12:01.95 ID:FdJN57de.net

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

そいう話じゃなくて

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

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

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

もちろんソースコード見ればわかるだろうけど、Rubyの知識が要求される上に
こういうのって過度に汎用化されていて簡単に読み解けるとは思えないんだが
特に言語がDSLそのものではなく、DSLを作りやすいだけの言語だと、
DSLを作るために通常のプログラミングには用いられない
メタプログラミング的なコードが多用される傾向にある

124 ：login:Penguin：2018/03/11(日) 16:38:27.85 ID:FdJN57de.net

>>122
k8sはクラウドで数台〜十数台以上のマシンが常時起動していて
何もしてないのに起動してるのはもったいない。かと言って事情があって落とすことも出来ない。
ってときにそれらの余剰CPUリソースをなにかに使うことは出来ないか？って時に
使うもんだと思うぞ。あと同じサーバーを複数起動させるという前提があってこそ使える

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

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

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

まあ一言で言うと、もっといい方法が有るって話だ。これ以上はここでは言えないけどｗ

125 ：塩水 ：2018/03/11(日) 16:50:49.20 ID:hSBnN7Ry.net

>> 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ができて
システムを俯瞰して見ることができるインフラエンジニアが居た方がいいかなーとは思います。。

126 ：login:Penguin：2018/03/11(日) 16:57:53.92 ID:FdJN57de.net

> と書けばファイルの存在や権限、オーナーが確認できます。
それはただ単にメソッド用意されてるからだよねーとしか思えないんだよね

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

describe file '/user/bin/mysqld \
　-- should_exist \
　-- should be_mode 770 \
　-- should be_owned_by 'mysql' \
end

127 ：login:Penguin：2018/03/11(日) 16:59:24.31 ID:FdJN57de.net

なんか中途半端になったなｗ

describe file '/user/bin/mysqld \
　--should_exist \
　--should_be_mode 770 \
　--should_be_owned_by 'mysql' \
end

128 ：塩水 ：2018/03/11(日) 19:29:40.88 ID:hSBnN7Ry.net

k8sはよっぽど仮想サーバに余剰があるか、もしくはGoogleやFacebookみたいに仮想化ソフトそのものがリソースの無駄と言い切って
物理サーバとコンテナだけでやるというクラスになると意義があるのかなぁとか思ったり。

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

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

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

Serverspecは基本的にどんな操作もサーバーの状態は変わらない(はず)なので
ベテランのレビューがなくてもとりあえず流しとく的に実行はしやすいかなと。
(私が今まで使った限りでは変な実行してサーバが壊れた、ということは無いです。
Ctrl+Cでキャンセルしてターミナルの表示がおかしくなるということはままありますが。)

129 ：塩水 ：2018/03/11(日) 19:43:24.47 ID:hSBnN7Ry.net

こういう作業をAnsibleやServerspecでやろうとすると
コマンドが異様に長くなるのでラッパースクリプト書いたりするのですが、
シェルスクリプトはそこで今でも大活躍してます。
なんだかんだで便利なんですよねシェルスクリプト。

130 ：login:Penguin：2018/03/11(日) 21:42:47.19 ID:yaKRWAT9.net

Dockerfile に関しては冪等性なんていらないのでそのまま使う派
Ansible が便利なのはわかるけど、Dockerfile に関しては 1 のことをするのに
10 できる道具で頑張る感じがつらい。

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

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

DockerImage のみのテストならば countainer-stracuture-test という google 製のものが出てきたのでこれも面白い
これに関しては、できたてなのでバグがかなり多い。新たなコミットのたびにバグができるｗ
テストできる機能は少ないが、docker engine 無しでイメージテストができたり、メンテナの反応も速いしコードも読みやすい。
今後ちゃんと出来上がれば化けるかも

131 ：login:Penguin：2018/03/11(日) 23:36:05.79 ID:gLOQBJNa.net

> 私にとってはトラブル解決時に 1000 行とかの自作のシェルスクリプトなんかより Ansible のコードを読むほうが楽。
> まぁ、自分しか使わないシェルスクリプト100行ぐらいで済むものならどっちでもいいけどね。

俺の観測ではシェルスクリプトが100行だと
Ansibleのコードは1000行って感覚なんだけどね

132 ：login:Penguin：2018/03/12(月) 00:00:41.81 ID:iAV7tz/N.net

大きな会社だと仮想サーバ一つ立てるのにいちいちインフラエンジニアにお伺い
たてないといけないけど、リソース多めのVM一つ作ってもらえばそこにdocker入れて
いろんなコンテナたててやりたい放題できるという。

4vCPU,8GBMem,100GBHDDあればデフォルト設定でコンテナ5くらいはいける。
もちろん検証用DBコンテナとか立てるときはMySQLのinnodb_buffer_pool_size小さめにしておくとか
ちょっとした工夫はいるけど。

133 ：login:Penguin：2018/03/12(月) 00:09:31.95 ID:0gO9Md9Y.net

やっぱりシェルスクリプトだとなんでそんなに
メンテナンス性が悪いものが出来上がるのか？
書くことはAnsibleとかわらんだろ（むしろ短く書ける）
と思ってるわけだが。

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

プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が
高くないように記述するもんなんだが、インフラエンジニアってのは
それができてないレベルだったりするの？

134 ：login:Penguin：2018/03/12(月) 00:13:02.11 ID:0gO9Md9Y.net

>>132
まあ会社が会社だとそういうことなんだろうけど

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

うちは入社当時のMac Book Proの一番上当たりの性能
CPUは忘れたけど、16GBのメモリと、512GBのSSDだったかな？

135 ：login:Penguin：2018/03/12(月) 01:17:08.47 ID:iAV7tz/N.net

>>134
個人PCレベルというのは否定できないw
社員数多いとリソース配分が大変なんです。
HDDはシンプロでごまかして、vCPUもまあまあ割り当てられるとして、
メモリは慢性的に不足します。

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

その場合も個人的にはDocker for Mac使うんじゃなくてVagrantで立ち上げたLinuxVMにdocker入れて使います。
理由は何となくというか、その方が環境が汚れなさそうだからというか。

136 ：129：2018/03/12(月) 01:34:06.50 ID:cIbUTTA5.net

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

「プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が高くないように記述するもんなんだが」
は可読性、メンテナンス性が高いようにじゃない？

137 ：login:Penguin：2018/03/12(月) 01:36:17.28 ID:0gO9Md9Y.net

> 「プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が高くないように記述するもんなんだが」
> は可読性、メンテナンス性が高いようにじゃない？

そのとおり「高くなるように」と書いたつもりだった
どうもGoogle IMEの調子が良くないんだよ。
特定のアプリで極端に変換が遅くなることが有る。
アプリ再起動したら直ったからメモリリークでもしてんのかな？

138 ：login:Penguin：2018/03/12(月) 01:47:41.96 ID:0gO9Md9Y.net

>>136
やっぱり理解できない。
何かしらの越えられない壁の
あっち側とこっち側にいる気分

> てか、コードが短く "も" 書けるのが嫌なんだけどね。
略
> そういうことをする余地がなければ無いほど良いと思ってる。

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

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

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

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

ヒントを言うとサブシェルを使うとその中で定義した変数は中に閉じ込められるので
localを使わなくてもローカル変数相当になる。

139 ：login:Penguin：2018/03/12(月) 13:05:39.78 ID:NF8xf4ym.net

>>138
そういうルールをどうやっていろんなスキルレベルの人と共有するんですかって話

140 ：login:Penguin：2018/03/12(月) 21:57:46.32 ID:0gO9Md9Y.net

>>139
逆に言えば、そういうルールを共有できればOKってことだよね？

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

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

今回はこれぐらいで切り上げるよ
またどこかで違う切り口から探るかもしれないけどｗ

141 ：login:Penguin：2018/03/13(火) 06:36:13.77 ID:w7drUkX+.net

>>140
そう。
その意気で、ぜひ世界に通用するシェルスクリプトフレームワークを作ってくれ。

142 ：login:Penguin：2018/03/19(月) 12:18:33.64 ID:10HKUK+F.net

Dockerfileからラッパースクリプトを呼び出すのは良いとしても、
DockerHubでそのシェルスクリプトを表示させるすべがないのが問題。

結局GitHubに行くことになるならDockerfileの表示ページいらないのでは。

143 ：login:Penguin：2018/03/21(水) 17:17:07.53 ID:6Vet870y.net

Dockerの教科書第二版が4月に出るぞー

144 ：login:Penguin：2018/03/26(月) 16:00:04.53 ID:W/pr8b3f.net

Arukasのβ外れたけど予想以上にコスパ悪いなぁ…
さくらはコンテナホスティングやる気ないのかな

145 ：login:Penguin：2018/03/26(月) 16:24:25.96 ID:bSj5pGXS.net

どんなビジョンであれで世界で戦えると思ったのかご説明いただきたい

146 ：login:Penguin：2018/04/03(火) 07:43:27.59 ID:8ENp9jaE.net

初心者がLinuxとストレスフリーで生きる為の6か条

1．Winをリプレース出来るなどど考えるのはやめましょう。共用しましょう。
2. 印刷はあきらめましょう。
3. Wifiの使用はあきらめましょう。
4. 音楽・動画・画像の編集/制作はあきらめましょう。
5. Nvidia製品の使用は控えましょう。
6. 教本を買いましょう。Linux界に限ってはググレカスは遠回りです。
7. Ubuntuを我慢して使い続けましょう。

147 ：login:Penguin：2018/04/03(火) 23:16:59.76 ID:Ry6Q9joG.net

随分古いな。

148 ：login:Penguin：2018/04/03(火) 23:44:51.96 ID:9r9tHTvx.net

>>146
従いますよ

149 ：login:Penguin：2018/04/20(金) 13:08:52.09 ID:IxQaq2RC.net

プロフェッショナルの方、どなたか教えてください(/ω＼)

今、下記内容のdockerimageを作成したいと思っています。
　
　�@　ベースのイメージ：jupyter/datascience-notebook
　�A　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

150 ：login:Penguin：2018/04/20(金) 22:27:51.02 ID:8yT4IMgr.net

>>149
エラー文ちゃんと読んだんですか？

151 ：login:Penguin：2018/04/21(土) 10:25:09.06 ID:RQ3vsIdh.net

>>150
エラー文が理解できなかったです、、

152 ：login:Penguin：2018/04/21(土) 13:23:47.70 ID:HjK21lH7.net

>>151
numpyって知ってる？

153 ：login:Penguin：2018/04/21(土) 13:46:33.79 ID:HtY0Nuyg.net

なんぱい？

154 ：login:Penguin：2018/04/21(土) 17:21:10.71 ID:5eINoTB9.net

>RuntimeError: module compiled against API version 0xc but this version of numpy is 0xa

0x って、16進数か？
0xc は12、0xa は10 って事か？

155 ：login:Penguin：2018/04/21(土) 19:53:43.47 ID:RQ3vsIdh.net

>>152
はい、知っています。
これはnumpyのversionが古いということですか？

156 ：login:Penguin：2018/04/22(日) 09:15:07.32 ID:uHMnXexw.net

「python module compiled against API version」で検索！

開発者の基本は、エラーメッセージで検索すること

157 ：login:Penguin：2018/04/22(日) 19:07:10.00 ID:2/k4X0Kz.net

>>156
検索しましたが、力不足で分かりませんでした。。
少しやってみたものの、

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

どなたかお力をお貸しください(/ω＼)

158 ：login:Penguin：2018/04/22(日) 19:23:31.15 ID:lrjQt1PM.net

いままで偉そうにしてたやつ、ちゃんと答えてあげろや

159 ：login:Penguin：2018/04/22(日) 23:46:18.23 ID:uHMnXexw.net

「docker hub tensorflow」で検索！

160 ：login:Penguin：2018/04/23(月) 03:34:29.66 ID:VkOu3656.net

この手の質問って動作環境が横断的だからdockerスレと言語スレ側でたらい回しにされちゃうんだよな
かと言ってマルチポストはできないし悩ましいところ

エラーメッセージやアドバイス貰ったキーワードをダブルクオートで括ったフレーズ検索も駆使して乗り越えるのだ
今こそ成長の時

161 ：login:Penguin：2018/04/23(月) 06:37:04.24 ID:qKqt8dYQ.net

>>157
tensorflowのバージョンはどうした？numpyのバージョンはどうした？
バージョンがあってないと言われてるんだからtensorflowのバージョンを1.4とか1.3とかに下げてみて試してみたらいいんじゃないでしょうか。

RUN pip install tensorflow==1.5

162 ：login:Penguin：2018/04/23(月) 10:45:26.96 ID:gJ+bJQJv.net

>>161
ありがとうございます！
tensorflowのバージョンを1.3にすることで、エラーも出ず正常にインストールできました。
1.4や1.6では、エラーが出てしまい駄目でした。

皆さん、私の力不足でお手数をおかけいたしました。
本当にありがとうございました。

163 ：login:Penguin：2018/05/22(火) 07:23:12.42 ID:Czl6p0FW.net

僕の知り合いの知り合いができた副業情報ドットコム
関心がある人だけ見てください。
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

EAAD8

164 ：login:Penguin：2018/05/22(火) 11:47:01.72 ID:NlhYPEMm.net

EAAD8

165 ：login:Penguin：2018/05/27(日) 18:22:16.75 ID:8ka68JJO.net

ディープラーニング ライブラリの管理で混乱しないようにとdockerを導入したけど
今はdockerで混乱してる
開発環境はどうやって整えるんだ、これ
コンテナの外と中は完全に分かれているのかよ
今あるエディタやアナコンダを呼べないぞ
コンテナを作る時に全部詰め込まきゃダメなのか?
NGCをつかっているけど

166 ：login:Penguin：2018/05/28(月) 20:34:50.01 ID:G/OxqctX.net

>>165
はいはい、いつもの仮想マシンの使い方とごっちゃにしてる人ね（笑）

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

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

そのコマンドにライブラリなんか全部くっつけて
一つのDockerコンテナ＝アプリケーションを作るものです。

167 ：login:Penguin：2018/05/28(月) 21:14:26.05 ID:5P04jZKi.net

>>166
いや、知らんよ
俺は開発元が進めてきたものを使うだけ

168 ：login:Penguin：2018/05/28(月) 21:25:11.53 ID:5P04jZKi.net

アプリケーションなら
任意の識別器や分類器を定義しデータを読み込んで学習するアプリケーションが欲しいわ

しかし、環境の切り分けのためじゃないならなんで開発元はdockerを配布しているんだろうね
それも競合を心配する必要ないですよってアピールしながね

169 ：login:Penguin：2018/05/28(月) 21:47:04.72 ID:G/OxqctX.net

> アプリケーションなら
> 任意の識別器や分類器を定義しデータを読み込んで学習するアプリケーションが欲しいわ

それを作るのがDockerを使うお前なんだって

170 ：login:Penguin：2018/05/28(月) 22:02:15.83 ID:5P04jZKi.net

>>169
それを玄人様たちはどうしているのかってこっちは聞いているだが...

171 ：login:Penguin：2018/05/28(月) 22:13:34.15 ID:G/OxqctX.net

普通にコマンド実行に必要なものを
まとめてコンテナにしてるだけだが？

172 ：login:Penguin：2018/06/03(日) 15:52:37.21 ID:4t3nAm6u.net

sage

173 ：login:Penguin：2018/06/24(日) 08:47:17.87 ID:TokMwylE.net

pullしたubuntuイメージにvimが入っていないんだけど・・・
aptコマンドもないんだけど・・・
docker search ubuntuで出てくるうち全部入りのイメージってどれ？

174 ：login:Penguin：2018/06/24(日) 22:35:20.55 ID:anZc79Me.net

dockerってコンテナが動いてる途中でdocker終わらせたらコンテナ内に保存してたファイルはなくなるの？

175 ：login:Penguin：2018/06/25(月) 05:44:34.47 ID:Uuelo8Ok.net

>>174
コンテナ起動時にストレージ領域を紐づけてなかったら終了時に綺麗さっぱり消えるようだ

176 ：login:Penguin：2018/06/25(月) 09:42:17.00 ID:+pzgGIIi.net

>>174
正確にはコンテナを削除すると無くなる
停止しただけでは無くならない
ゆえに削除するまではdocker logsでログも見れるし
docker commitでイメージ化すれば
docker runで中身を見れる

https://stackoverflow.com/a/39329138

177 ：login:Penguin：2018/06/25(月) 09:49:22.67 ID:+pzgGIIi.net

>>173
欲しけりゃ自分のDockerfileに入れるか
全部のコンテナでそれやるのがアレってなら
新しくvimコンテナ作って編集したいファイルだけマウントするか
ホストのファイルをマウントして
ホスト側でvimで編集すれば良い

てか開発環境だよな
本番環境でそれやったら
ちゃんと動く環境を保存出来るっていうDockerの魅力を殺している
場合によっては仕方ない事もあるが

178 ：login:Penguin：2018/07/01(日) 03:55:45.96 ID:+w2giTsy.net

>>173
> pullしたubuntuイメージにvimが入っていないんだけど・・・
Dockerの使い方を間違ってる。

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

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

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

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

（Dockerコンテナ版の）ffmpegコマンドから書き出したいなら、
ボリュームでコマンド（コンテナ）外部への読み書き場所を指定する

179 ：login:Penguin：2018/07/01(日) 09:04:34.19 ID:EBIMlKr7.net

>>178
アドバイスありがとう
ということは、dockerで起動したOS内でvimが使いたければ
vimのコンテナを探してきて追加起動しろってこと？
どこのサイトにどんな名前でvimのコンテナがあるのか調べるみたいなことを
アプリごとにやってたら、環境を作るまでどれだけの手間と時間がかかることやら
このソフトの何が持てはやされているのか全く理解できない

180 ：login:Penguin：2018/07/01(日) 09:21:20.95 ID:+w2giTsy.net

>>179
だから使い方が間違ってる。
全く理解できないのは、あんたが正しい使い方がわかってないからだよ

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

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

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

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

で、そんなもん普通はやらねーだろ？ だからアプリの開発者が作るものだって言ったわけだ。
vimなどのパッケージはパッケージのメンテナが頑張って動くようにしてくれてる
だけど、自分で作ったアプリは、自分が頑張るしかないだろ？ でも頑張りたくもない
いろんなディストリや、WindowsやMacでも動くようになんかするの大変じゃないか
だからDockerコンテナ化することで、Dockerデーモンさえ動いていれば、
どこに持っていっても同じように動かせるってわけさ
一言で言えば可搬性だな

181 ：login:Penguin：2018/07/01(日) 09:23:55.84 ID:+w2giTsy.net

>>179
> ということは、dockerで起動したOS内でvimが使いたければ

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

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

なぜなら、何らかのプログラムに実行環境をくっつけただけで、
作られるものは、実行環境付きのなんらかのプログラムなんだから
そこにOSなんてものはないと思え

182 ：login:Penguin：2018/07/02(月) 19:23:28.69 ID:1jLd0V1g.net

今日から新しいプロジェクトでmac上でDOCKERを使う事になったんですが

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

MAC使うのもバージョン管理ツール使うのも初めてだらけで
くだらない質問で申し訳ないんですが
考えられる解決方法はありませんでしょうか

183 ：login:Penguin：2018/07/02(月) 20:07:43.00 ID:Eg1cEgm9.net

社内の人に聞け

184 ：login:Penguin：2018/07/02(月) 20:45:02.37 ID:Y1QFiQ2T.net

普段サーバーサイドJavaとかPHP JSでウェブアプリかいてて
mac の Ruby on Rails のサーバーサイドの案件が修羅場でヘルプはいったんだけど
分かってる人はみんな忙しくて質問なげてもなかなかかえってこないんですよね

でもこんな情報じゃわかるわけないですよね…
明日また社内できいてみます
すいませんでした…

185 ：login:Penguin：2018/07/03(火) 00:50:17.25 ID:1PLz+sRr.net

>>182
dockerは公式サイトのやり方でインストールしたほうがいいんじゃね？

186 ：login:Penguin：2018/07/03(火) 00:52:28.72 ID:1PLz+sRr.net

社内のチュートリアルが何年前に書かれたかだな
Docker Toolbox使ってたら古いやり方だな
まあ社内全員やり方が決まってるなら仕方ないが

187 ：login:Penguin：2018/07/03(火) 02:50:11.95 ID:88JNN2bg.net

支給されたmac PCが他の人も使うみたいで
別の人がインストールしたhomebrewが/usr/localにはいってて
権限が変更できないくてホーム以下にインストールしたんだけどそのせいなのかなと…

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

Javaからruby覚えるのはすぐできると思ったけど
OSが違ったりフレームワークの環境構築がこんな大変だと思わなかった

188 ：login:Penguin：2018/07/03(火) 05:53:39.58 ID:0N07jwhz.net

もうmac板で質問したほうがいいのでは

189 ：login:Penguin：2018/07/03(火) 06:10:23.01 ID:1PLz+sRr.net

>>187
なんの苦労もなく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を使うなと

190 ：login:Penguin：2018/07/03(火) 06:28:04.40 ID:88JNN2bg.net

そうなんですね
クリーンインストールしていいかお願いしてみます
検索するとわりとホーム以下にインストールする方法とかでてきたのでいけるかと思ったんですけど

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

もともと大学院研究室あがりでスクラッチからかくのが好きな
ブラックボックスなツール使うの気持ち悪い
古い人間だから昨今のフレームワークだらけの業界きついなあ…

191 ：login:Penguin：2018/07/03(火) 06:35:07.67 ID:HvrBhqqa.net

頭でっかちの使えないやつか現場も大変だな

192 ：login:Penguin：2018/07/03(火) 06:54:24.03 ID:B87Zf6Sc.net

macやhomebrewがはじめてなのはともかく、バージョン管理ツールはじめてはないわ
それでひとりで環境構築しろってほったらかしなのも普通はありえんと思うけど
仕事ほしくて経験ないのに経験ありとか嘘かいたんじゃねーの

193 ：login:Penguin：2018/07/03(火) 07:12:51.42 ID:ArJzlEvp.net

最後にききたいんですけど /usr/local じゃなく
~〜/homeblew に homeblew をいれたんですが
この blew から Docker をインストールした場合実態はどこにあるんでしょうか

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

コマンドラインの docker はホーム以下のパスになってたんですけど
アプリケーションからじゃなくコマンドラインからDockerのGUIアプリ起動する方法ってありますか？

194 ：login:Penguin：2018/07/03(火) 11:19:37.64 ID:oYvmZw+l.net

解決しました

初回起動時に窓が出たのでずっと窓を探してたんですけど
右上のクジラマークからアクセスするんですね…
おさわがせしました

195 ：login:Penguin：2018/07/03(火) 13:54:24.15 ID:oYvmZw+l.net

何度もすいません

docker-compose up -d

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

一応同じディレクトリに docker-compose.yml はあって
yyy:
image: xxx/yyy:2018zzzz
と書かれています

196 ：login:Penguin：2018/07/03(火) 14:20:45.35 ID:1PLz+sRr.net

>>195
普通はそうならないので環境の問題です
OSをクリーンインストールしてください

197 ：login:Penguin：2018/07/04(水) 02:14:06.32 ID:COxRspz9.net

rubyは導入ハードル高すぎ
よっぽど複雑なプロジェクトでもなけりゃこんな開発環境作ってるあ労力で案件終わるわ

198 ：login:Penguin：2018/07/04(水) 06:04:14.37 ID:WJvTzUXE.net

利用プロジェクトの多くが低品質だったせいでいわゆるアタリショックみたいな扱い受けてるよな
負の遺産だとかRuby巻き返しの目は潰えてるとまで言われてるし・・・Javaみたいにはならんで欲しいマジで

199 ：login:Penguin：2018/07/07(土) 17:30:55.41 ID:fg0oR1Sy.net

散々Perlディスっといてこれだもんなm9(^Д^)プギャー

200 ：login:Penguin：2018/07/07(土) 21:06:35.47 ID:1D6mHUpx.net

やめて…perlは6を引き伸ばし杉た件のせいで世間との剥離からユーザー離れが尋常じゃなく
引き合いに出されると最底辺の戦いじみて嘲笑の的です…

201 ：login:Penguin：2018/07/07(土) 21:59:02.61 ID:fg0oR1Sy.net

イシキダケタカイケイ

202 ：login:Penguin：2018/07/09(月) 12:21:03.01 ID:4SJdzKl6.net

WSL上でDocker Engineが動くようになっていたっぽいという話
https://qiita.com/yanoshi/items/dcecbf117d9cbd14af87

203 ：login:Penguin：2018/07/09(月) 12:48:52.62 ID:qh/Cnej+.net

マジかよDockerForWindows消してくる

204 ：login:Penguin：2018/07/09(月) 13:31:43.43 ID:pfSJA2ey.net

もしかしてHyperV無しのHome版WSLでも動くようになってるのか

205 ：login:Penguin：2018/07/10(火) 17:37:18.97 ID:hi/Ud89A.net

パブリッククラウドや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上からダウンロードできる。

206 ：login:Penguin：2018/07/10(火) 18:37:07.13 ID:TEPxwuu8.net

ええやん
alpine使いにくいし乗り換えようかな

207 ：login:Penguin：2018/07/11(水) 00:29:12.16 ID:dU5xb19g.net

minidebのUbuntu版みたいなヤツか

208 ：login:Penguin：2018/07/11(水) 13:45:07.36 ID:Za+YUtMW.net

ええやん、なんぼなん

209 ：login:Penguin：2018/07/12(木) 01:08:55.93 ID:Spx3HNht.net

展開後のサイズは約80MB前後でminidebのようなコンテナ特化支援コマンドはさすがに無いっぽいな

Ubuntu版の公式slimとしてapt系で最新パッケージ使いたいなら(Debianのslimじゃなくて)こっちでねって感じか
野良イメージじゃない公式スリムに選択肢が増えるのは嬉しい

210 ：login:Penguin：2018/07/12(木) 07:54:44.88 ID:2fRy1rm8.net

debianよりも少ないの？

211 ：login:Penguin：2018/07/12(木) 08:05:41.95 ID:uhTdlutY.net

alpineで慣れちゃった。

212 ：login:Penguin：2018/07/13(金) 09:30:31.30 ID:PFiL2FSs.net

debian:stretch-slimは55MB
（bitnami/minideb:stretchは54MB）

ubuntu:bionicは81MBで去年から変わってないみたいだけど今回発表されたやつは何なんだいったい…
元記事タイトルにDocker Hubとあるが実は関係なくてアマとかGCPで使うimgファイルが小さくなりますたってことか

213 ：login:Penguin：2018/07/15(日) 20:58:09.55 ID:9hWJVlJh.net

ミニマルすぎると一個ゲットした途端大量に依存がやって来る悪寒しかない

214 ：login:Penguin：2018/07/15(日) 21:53:50.81 ID:rnlXfHys.net

ミニマムすき

215 ：login:Penguin：2018/07/15(日) 22:11:32.38 ID:Xmkkcspf.net

エセロリやん

216 ：login:Penguin：2018/07/19(木) 17:07:15.56 ID:4Cjfx+r5.net

「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も統合した。

217 ：login:Penguin：2018/07/27(金) 03:51:52.83 ID:6DSLURTJ.net

訳あってソースコードからビルドしないといけない物があるんだけど、
ビルドに必要なパッケージをインストールしたくない。

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

ソースコードのディレクトリをボリュームにして
make installだけDockerの外でやるのが一番かなぁ？

218 ：login:Penguin：2018/07/27(金) 04:48:47.30 ID:1joj4I21.net

そういうときはmake install先のディレクトリだけ -v でマウントしとくパターンが簡単で良いね

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

コンテナでmake installまでやれるしホストもソースやビルドツールで汚れないから安心
docker公式マニュアルのどっかに書いてあった気がしたが見当たらなくなってた

219 ：login:Penguin：2018/07/27(金) 07:25:43.45 ID:7fogAuN8.net

詳しい解説サンクス

220 ：login:Penguin：2018/07/28(土) 15:41:09.29 ID:0ikx9NUA.net

>>218
もう少しアイデアを発展させてみた。
このアイデアをどうするかは任せる

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

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

docker、make installでインストールされるファイルは多分レイヤーの差分を見ればわかる
インストールされるファイルがわかるのだから、それを消せばアンインストールになる
インストールするファイルも残っているのだから、ファイル内容を比較することで
アンインストール時に想定外のファイルを削除しなくてすむかもしれない

221 ：login:Penguin：2018/07/28(土) 16:06:06.83 ID:PwMG08J6.net

今はMulti-stage buildが公式実装されて>>220のアイデアを綺麗に実現できるようになったね！
ビルドコンテナのmake install結果をホスト経由せずに実行用コンテナに簡単に乗せられる

ビルドコンテナも実行用コンテナも使い終わればコンテナごとすべて消せるから
--prefix完全無視の無作法野良ツールにホストのファイルが上書きされることもないし
make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない

222 ：login:Penguin：2018/07/28(土) 19:21:25.29 ID:fgC/Ah69.net

>>221
> make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない
なんかちょっと違うｗ

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

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

インストールするファイルを知ることができるから、コンテナでビルドして生成したものを
コンテナの外にインストールしてアンインストールもしやすくなるだろうと言う話

223 ：login:Penguin：2018/07/29(日) 00:30:39.68 ID:wo8fIaJv.net

最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな
俺もコンテナ上のgitからホストのカレントディレクトリを見る方法がわからんというごく最初の段階でつまずいた

絶対パス指定ならツールで使う主要ディレクトリを-vに指定しとけば大半普通に開けるけど
カレントを含めた相対パスも単に-v $(pwd):$(pwd) -w $(pwd)を書いておけばいいという基本をDocker Hubのgitイメージページ読んで知った

224 ：login:Penguin：2018/07/29(日) 01:53:02.32 ID:vXZjVBrz.net

>>223
だから大変だからホストに直接おいたほうが良いって話なんだが

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

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

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

俺は頑張ったんだって自己満足してたいだけでしょ？
そんなのは意味がないから辞めたほうが良い

225 ：login:Penguin：2018/07/29(日) 01:54:06.34 ID:vXZjVBrz.net

あ、そうだ。gitのglobal configがあるから、
絶対HOMEをボリュームにしないとだめなんだ。

226 ：login:Penguin：2018/07/29(日) 01:57:06.96 ID:vXZjVBrz.net

ssh鍵の話もあったな
-v $(pwd):$(pwd) -w $(pwd)を書いておけばって
実際には使ってないだろ。

コンテナ化に適してないアプリをコンテナ化しても使いにくいだけ

227 ：login:Penguin：2018/07/29(日) 02:32:06.22 ID:vXZjVBrz.net

面白い例を思いついた

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

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

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

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

はは、乾いた嘲笑の笑いしか出てこない。こんなムダでややこしいことやって
なんの意味があるんだ。

228 ：login:Penguin：2018/07/29(日) 18:09:34.64 ID:PCsU6lV8.net

長くて全部読んでないけど、ホスト側のgitなりエディタ設定なりに依存するようなコンテナって筋悪くない？

k8sとかでコンテナを別ホストに移動したら使えなくなるような気がする。

229 ：login:Penguin：2018/07/29(日) 18:12:14.75 ID:PCsU6lV8.net

エディタが何かによるけど、vim程度ならコンテナ毎に入っててもいいのでは。有償のIDEでgit連携して使ってる人にとってはちょっとしんどいとかかな。

230 ：login:Penguin：2018/07/29(日) 20:28:18.31 ID:vXZjVBrz.net

そりゃ単に、
　普通は使わないけど入っていても良い。イメージのサイズがでかくなるだけ。
程度のことだな

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

コンテナ内のvimは使わない。の意味がわからんやつは
勉強し直したほうが良い

231 ：login:Penguin：2018/07/29(日) 21:46:50.04 ID:PCsU6lV8.net

え、普通にvim使ってるけど。何でなの？

232 ：login:Penguin：2018/07/29(日) 21:48:26.84 ID:PCsU6lV8.net

本番環境って前提ならそもそも本番で稼働している設定ファイルはみだりに編集しないってのは分かるけど。
単にコンテナ内でvim使うかどうかって話だとしたら本気で意味分からん。

233 ：login:Penguin：2018/07/29(日) 21:51:36.18 ID:PCsU6lV8.net

コンテナの中のファイルは絶対編集しないってどういうことなんだろう。良くあるベストプラクティスに書いてあるから盲目的にそうするって事だとしたら、はぁ、そうですかで話終わりにするけど。

234 ：login:Penguin：2018/07/29(日) 22:27:59.92 ID:Hv8rsH9m.net

>>238
Dockerはアプリケーションコンテナと言って、
アプリケーションをコンテナ化するもの
システムコンテナと違って、コンテナの中で作業するためのものじゃない。

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

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

とりあえずアプリケーションコンテナとシステムコンテナの
違いぐらい学習してから出直せ

235 ：login:Penguin：2018/07/29(日) 22:32:59.80 ID:/XpMabXH.net

ドヤ顔で未来にエスパーしてて草

236 ：login:Penguin：2018/07/29(日) 22:49:16.80 ID:Hv8rsH9m.net

内容は間違えてないだろ？ﾆﾔﾘ

237 ：login:Penguin：2018/07/29(日) 23:31:49.15 ID:PCsU6lV8.net

>>234
アプリケーションコンテナとシステムコンテナの違い、ですか。そうですか。
教科書にはきっとそう書いてるんでしょうね。その辺はよく知らないけど、たぶん間違ってないんだと思います。

でも、私はDockerで開発するファイルも編集します。はい。

238 ：login:Penguin：2018/07/29(日) 23:37:55.72 ID:PCsU6lV8.net

コンテナでsshd起動してsshでアクセスするなとかいうのも基本としてあるってのは聞いたことある。
けどそんなの関係ねぇ。
実際エンジニアに開発環境としてコンテナ提供するのにsshでアクセスできないって不便でしかない。

239 ：login:Penguin：2018/07/29(日) 23:54:22.87 ID:PCsU6lV8.net

ちなみにシステムコンテナってSolarisのzoneみたいなものかな。Linuxだと何かあるのだろうか。

240 ：login:Penguin：2018/07/30(月) 01:20:21.45 ID:QZl1Bega.net

>>237
コンテナの中にあるファイルはコンテナ削除すると消えるでしょ？永続化しない。
残っていてほしいファイルはボリュームでコンテナの外にだすわけだから
そのファイルの編集はコンテナの外でやれば良いわけ
中にvimを入れておくのは開発中とかの一時的にしかやらんよ

っていうか使いづらいでしょ？　あんたvimの設定とかしてないの？
デフォルト設定で使いづらいからカスタマイズするのが常識だけど
コンテナの中にあるのはなんの設定もされてないvimじゃん

241 ：login:Penguin：2018/07/30(月) 01:23:38.82 ID:QZl1Bega.net

>>238
関係ないとか言ってないで、自分の解釈が大きくずれているって考えたほうが良いよ
ちょっと間違いレベルじゃなくて、方向性が大きくずれている
変な使い方をしているから、使いづらく感じるんだよ

242 ：login:Penguin：2018/07/30(月) 06:34:10.24 ID:jEBEwRTJ.net

>>240
残ってほしい開発後のプログラムがあるならgitでpushしとけば良くない？

設定あんまりシナイ派だけど、仮にするとしても、それこそvimrcとかgitでpushしてるものをcloneで持ってくれば設定なんて一撃で終わらない？それじゃあダメな理由とかある？

243 ：login:Penguin：2018/07/30(月) 06:40:38.62 ID:jEBEwRTJ.net

>>241
解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。
どんなに正しくても実際に使い難ければ正しくてもやらない。
もちろんセキュリティーや影響は考慮するけど、その辺問題なければ基本がどうとか関係ない。

PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。

244 ：login:Penguin：2018/07/30(月) 06:42:13.68 ID:QZl1Bega.net

>>242
gitは作業中断時に一時保存するための道具じゃないし、
設定しないなんて使いづらいだけだし、
いちいちcloneするとか面倒くさいことこの上ないし、

ホストでやれば普通にできることを、いちいちやらないといけないのか？
間違ってる方向に進むとこれから、あれやこれが使いにくいって愚痴るだけだぞ
すでに愚痴ってそうだがｗ　その原因はすべて間違った使い方にある
変な癖が付く前に矯正したほうがいい

245 ：login:Penguin：2018/07/30(月) 06:43:07.14 ID:QZl1Bega.net

>>243
> 解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。

便利に使うための手段を、お前がみんな捨ててるから、
（俺は不便な中で生活してるから）不便に思わないんだって言ってるだけじゃん

246 ：login:Penguin：2018/07/30(月) 06:44:51.91 ID:QZl1Bega.net

>>243
> PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。

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

まず教科書守ってやろう。いまお前は教科書通りのことを守らずに使いづらいと言ってる

247 ：login:Penguin：2018/07/30(月) 06:48:28.40 ID:jEBEwRTJ.net

>>244
一時保存なんて利用用途で言った覚えはないけど、仮にそうだとしても何で一時保存でgit使ったらダメなの？

あなたって基本に従うってことに束縛されて思考が限定されてる気がする。自分だけでそういう方針で進めるのは勝手だけど、人にやり方強制しだすと嫌われるから考え改めた方が良いよ。
新卒ならまだ良いけど。

248 ：login:Penguin：2018/07/30(月) 06:51:41.70 ID:jEBEwRTJ.net

>>245
よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの？物凄く不便じゃない？

ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない？

249 ：login:Penguin：2018/07/30(月) 06:52:59.21 ID:QZl1Bega.net

>>247
gitはバージョン管理するための道具であって、
バージョン管理しないならタダの保存に過ぎないから

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

お前はまだ初心者で、どうせgitもオープンソースものをcloneするぐらいのことしか
したこと無いんだろ。基礎ができてないんだからまず教科書通りにやれと

250 ：login:Penguin：2018/07/30(月) 06:54:15.51 ID:jEBEwRTJ.net

PMに教科書通りのやり方を強制されて疲弊してる現場を見てきたから経験談として話してるだけ。
教科書通りやって現場がうまくまわってるならそうすればいいよ。
というか、むしろ教科書なぞってうまくいってる現場があるならそれ勉強会とかで話してほしい。見に行くので。

251 ：login:Penguin：2018/07/30(月) 06:55:30.13 ID:QZl1Bega.net

>>248
> よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの？物凄く不便じゃない？
ホストに置いたファイルを編集すればいいだけだろ。
それがコンテナの中にボリュームを通して見えてるんだから
コンテナの中に入って編集する必要がない。
コンテナの中の環境を整える必要もない

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

できるといってるだけで便利なんてお前は一言も言ってないよね？
お前のやり方が俺は不便だと言ってる。反論は？
できる、やったらだめなの？は不便であることの反論にはならない

252 ：login:Penguin：2018/07/30(月) 06:55:41.00 ID:jEBEwRTJ.net

ということで、あなたのやり方を変えさせるつもりもないし、自分のやり方を変えるつもりもありません。
以上終わり。

253 ：login:Penguin：2018/07/30(月) 06:57:17.09 ID:QZl1Bega.net

>>248
> ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない？

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

コンテナ消すと中で編集したファイルが消える。不便だからgit入れて忘れずにpushしなきゃって
コンテナのファイルを直接編集すると不便だと言ってなかったか？ｗ

254 ：login:Penguin：2018/07/30(月) 06:58:17.45 ID:QZl1Bega.net

>>252
俺はやり方をお前に押し付けてるんじゃなくて、

正しいやり方にしないとお前が困るという事実を言ってるだけ
お前はその事実に反論してない。困るのは自分だけだから
良いじゃないかって逃げてるだけだ。

255 ：login:Penguin：2018/07/30(月) 07:00:14.56 ID:QZl1Bega.net

>>250
そのPMが教科書通りにやってないだけだよｗ
教科書通りにやることが簡単だと思ってはいけない

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

教科書になってるぐらいだから基本的には正しいんだよ。
それが当てはまらない理由を見つけない限り、教科書に反論してはいけない。
当てはまらない理由がわからないのは、理解してないってことになるんだから。

256 ：login:Penguin：2018/07/30(月) 07:08:27.71 ID:QZl1Bega.net

ほんとね。反論の一つでもできればまだいいんだが、
回避策はあるというだけじゃ、その方が良いってことにはならないんだよ。
全部回避策を入れないとやっていけないってことになってるんだから、

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


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

日本だとツールを導入して、自分のやり方にカスタマイズさせる。
やり方を変えようとしないから生産性も変わらないし、
ツールのカスタマイズにコストも掛かるとのこと。それと同じだ

257 ：login:Penguin：2018/07/30(月) 09:12:18.18 ID:2DtBR6Mw.net

アプリケーションコンテナはyum, aptのパッケージ相当だと思ってるなぁ
基本的に使い捨てて常にクリーンなコンテナに出来るのがいいし, だからこそkubernetesとかで高い自己修復性を持てる

258 ：login:Penguin：2018/07/30(月) 09:22:21.96 ID:IG0rWwn1.net

すると、Vimのような手動カスタマイズほぼ必須のアプリは
コンテナ化には適さないのか
docker searchしてもVimが出てこないのが不思議だったがそういうことか

259 ：login:Penguin：2018/07/30(月) 09:55:24.40 ID:2DtBR6Mw.net

そのカスタマイズ部分を, プラグインならホストからマップするか別コンテナで, 設定ファイルはホストからマウントする必要があるだろう

260 ：login:Penguin：2018/07/30(月) 16:34:35.00 ID:QZl1Bega.net

>>258
手動カスタマイズの有無じゃないな。
プログラム本体がコンテナに隔離されているので、
コンテナの外に自由にアクセスするものは適さない

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

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

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

もちろん不可能ではないが面倒なだけ

261 ：login:Penguin：2018/07/30(月) 19:40:21.56 ID:vC8FJAc3.net

これいわゆるイキリstaticおじさんが駄々こねて屁理屈連投してるいつもの案件じゃなくて
もしかして今回に限っては、Docker業界的にも、回避策やカスタマイズの工夫するくらいなら
コンテナはそぐわないからツールの使い方としてもやめてねって方向性にいつの間にか大勢が傾いてるのか

262 ：login:Penguin：2018/07/30(月) 19:45:58.92 ID:QZl1Bega.net

エクセルで小説書くなってだけの話

263 ：login:Penguin：2018/07/31(火) 19:28:27.70 ID:9kOFb8Cb.net

docker-tramp.el 便利だー。この機能使うためだけにemacs使いになっても良いと
思うくらい。コンテナにvimやsshdインストールする必要がありません。

264 ：login:Penguin：2018/07/31(火) 20:23:57.73 ID:GXqvrTdQ.net

いまWSL使ってDockerを使っているんですが、atomでホストに置いたファイルを修正して
それをイメージに反映させたいのですが、修正するたびにビルドするのが面倒です。

なのでボリュームを使ってホストのディレクトリをコンテナ内に共有しようと思っています。
Linuxではうまく動いているのですが、WSLだとうまく動かないのですが、
何が問題だと考えられますか？

265 ：login:Penguin：2018/07/31(火) 20:24:57.09 ID:GXqvrTdQ.net

と、書き込んでからひらめきました。
WSLで使ってるのはWindows上のDockerなので
パスの指定をC:\〜でやらないといけないきがします。

266 ：login:Penguin：2018/07/31(火) 20:28:45.59 ID:C0KTXAUF.net

ビンゴでした！
　

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

スレ汚し申し訳ありません

267 ：login:Penguin：2018/07/31(火) 20:30:02.34 ID:C0KTXAUF.net

↑なぜかコマンドを書き込んだらエラーになったので怪しそうな所を大文字で書きます。

docker run -p80:80 -v"$(wslpath -wa www):/var/ｗｗｗ" -d ｈｔｔｐｄ

268 ：login:Penguin：2018/07/31(火) 20:33:08.23 ID:PupCkl8+.net

>>263
もとからvimもsshdも入れたりなんかしてないよ。
入れるもんでもないしね。

docker-tramp.elも別にいらないかな。
ファイルを修正したいならボリュームにすればいいだけだし、
sshdはdocker execを使えばいいので、

269 ：login:Penguin：2018/07/31(火) 20:50:25.97 ID:PXAb2zrY.net

>>268
定位置にあるconfファイル等を色々いじってテストしたい時はどうしているの？

270 ：login:Penguin：2018/07/31(火) 20:52:18.71 ID:WDZkbP+f.net

>>268
コンテナ提供するアプリエンジニアにdocker exec使えって言うの？

271 ：login:Penguin：2018/07/31(火) 20:54:37.84 ID:WDZkbP+f.net

大した負荷のかからないコンテナをサーバーって言ってアプリエンジニアに提供するときある。ポート番号ちょっと変わってるサーバだと思って使ってくれてるよ。
本人はdockerだのコンテナだのを使ってる事に気づいてない。

272 ：login:Penguin：2018/07/31(火) 21:27:30.82 ID:PupCkl8+.net

>>269
だからボリューム使えばいいじゃない？

$ docker run -it debian cat /ｅｔｃ/debian_version
9.5

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

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

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

>>271
アプリエンジニアがDockerイメージを作ってないのはおかしい。
アプリを作ってる人でないと、アプリを動かすのに必要なものは知らないんだから
「手元のマシンだと動きました」「ライブラリのバージョンが違ってるんですねー」
これをなくすためにDockerがあるというのに。仕事の分担が間違ってる。

273 ：login:Penguin：2018/08/01(水) 05:48:16.53 ID:rxe3lfEn.net

動くコンテナのイメージ作るのがアプリエンジニアの仕事なら、結局必要なミドルをアプリエンジニアが入れる事になってそれこそインフラエンジニアの作った本番環境と差異が出てしまうと思うのですが。

まあ新規や中小規模のサービスならそれでも問題無いと思うけど。

274 ：login:Penguin：2018/08/01(水) 05:52:39.03 ID:rxe3lfEn.net

大きい会社だとIDEしか使ったことがない、CUI触ったこと無いアプリエンジニアとか普通に居りましてですね

まあその程度のアプリエンジニアはいずれ淘汰されると切り捨てるなら問題無いんですけどね。

275 ：login:Penguin：2018/08/01(水) 06:00:09.93 ID:rxe3lfEn.net

アプリ動かすのに必要なミドルウェアをバージョンも含めて熟知してるアプリエンジニアって相当優秀だと思う。

取りあえずアプリ動く程度に適当にミドル入れまくるアプリエンジニアいるけど、それができるアプリエンジニアすらそこそこ出来る評価なんだけど。

276 ：login:Penguin：2018/08/01(水) 06:12:59.68 ID:eV7ibk3+.net

>>273
やっぱお前使い方間違ってるわ

答えだけ言っておくね。本番環境と全く同じ環境になる

277 ：login:Penguin：2018/08/01(水) 06:13:53.34 ID:eV7ibk3+.net

>>275
> アプリ動かすのに必要なミドルウェアをバージョンも含めて熟知してるアプリエンジニアって相当優秀だと思う。

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

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

言ってみ

278 ：login:Penguin：2018/08/01(水) 06:15:57.48 ID:eV7ibk3+.net

コンテナの中にミドルウェアが入ってしまってるのに
どうやってインフラエンジニアがミドルウェアを入れ替えるんだ？
コンテナに手を入れてミドルウェアを差し替えるんか？ｗ

279 ：login:Penguin：2018/08/01(水) 06:18:28.58 ID:eV7ibk3+.net

というかミドルウェアがなにかもわかってなさそうｗ

280 ：login:Penguin：2018/08/01(水) 06:57:46.82 ID:rxe3lfEn.net

え、もしかして自分でミドル入れずにDockerhubに落ちてるミドル入りコンテナ使ってるクチだったりするの？

281 ：login:Penguin：2018/08/01(水) 06:59:30.64 ID:rxe3lfEn.net

コンテナの中庭ミドルが入ってしまっているのにって、じゃあそのミドルは誰が入れるの？

アプリエンジニアが適当に入れたミドルをそのまま本番に使ってたりするんですか？

282 ：login:Penguin：2018/08/01(水) 07:01:51.20 ID:rxe3lfEn.net

インフラエンジニアの居ない規模の企業でアプリエンジニアが勉強して開発から本番運用までやってるって言うなら分かるけど。

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

部署をまたいだアプリエンジニア同士で宗教論争はじまってまとまらないと思うんだけど。。

283 ：login:Penguin：2018/08/01(水) 07:06:15.76 ID:rxe3lfEn.net

最終的にはインフラ分からないアプリはフェードアウトするって意見に異論はないけど、まだその時ではないと思ってる。中小規模やベンチャーは知らない。

284 ：login:Penguin：2018/08/01(水) 07:40:52.95 ID:vZ5iA/aw.net

>>281
> アプリエンジニアが適当に入れたミドルをそのまま本番に使ってたりするんですか？

なんで適当に入れるんですか？
お前じゃあるまいしｗ

285 ：login:Penguin：2018/08/01(水) 07:52:42.75 ID:vZ5iA/aw.net

>>282
お前さ、アプリケーションが動くサーバー作ったことないだろ？
どうせデータベースサーバーのセットアップぐらいしかしてねーだろ？

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

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

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

アプリのコード読んで必要なものを調査するとかやんなくていいよ
俺がコンテナのイメージつくってやっからさ、
お前はそれ動かすだけ。おまえにできないことはやらなくていい
お前はDockerr動くLinuxマシンだけ用意してればいい

286 ：login:Penguin：2018/08/01(水) 08:09:10.69 ID:rxe3lfEn.net

何をそんなに怒っているの？

287 ：login:Penguin：2018/08/01(水) 08:12:05.32 ID:rxe3lfEn.net

あなたがよくても他のアプリエンジニアから不満でたりしないの？
あなたのレスみる限り大きな声で周りねじ伏せて自分凄いって思ってるタイプの人に見えますが。
周りは従ってるんじゃなくて腫れ物には触らないようにしてるだけっていうオチじゃないですか？

288 ：login:Penguin：2018/08/01(水) 09:24:20.09 ID:rSD2s4kw.net

マウント合戦はお腹いっぱい

289 ：login:Penguin：2018/08/01(水) 10:07:33.31 ID:oUHlYMq4.net

それだけDockerの理解・運用は難しいということだな
俺本読んでもさっぱりわからんかったもん
コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
コンテナ=アプリとその動作環境をパックにしたものと
ここで教わったが、アプリがIPアドレスを持つわけないだろう

290 ：login:Penguin：2018/08/01(水) 10:18:41.57 ID:V8uA/puM.net

containerizedされたアプリケーションならdocker-composeなりkubernetesなりでミドルウェアごと構成管理するのが普通
この場合はインフラ屋の役割は主としてdockerなりkubernetesクラスタの管理になると思うのだけれど

単に共通テスト環境としてコンテナを使っていて, アプリケーションをcontainerizedせずにリリースするとか単体のコンテナとして配布して使う側で上手に組み合わせてねってものならインフラ屋が実動環境に合わせてコンテナ構成をすることもある
Travis CIとかGitLab CIでビルド環境として使うコンテナはこっちの場合が多そう
テスト/開発環境でもdocker-composeかVagrantした方がいいと思うけども

291 ：login:Penguin：2018/08/01(水) 10:32:58.00 ID:V8uA/puM.net

>>289
UNIXソケットを使わない場合にアプリケーション間のデータのやり取りはTCPやUDPで行われることが多いと思うのだけれど, そうするとIPアドレスがないと困るだろう
特にロードバランシングしていると同一ホスト上でないことが普通なので, ソケットが使えないことが多い

292 ：login:Penguin：2018/08/01(水) 18:16:15.55 ID:vZ5iA/aw.net

>>287
人間の問題と技術の問題は切り離して考えましょう

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

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

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

下には下なんていくらでもいるんだから、素人集団には
使えませんと言われても、それ技術となんの関係もないやん

293 ：login:Penguin：2018/08/01(水) 18:21:54.43 ID:vZ5iA/aw.net

>>289
> コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
> コンテナ=アプリとその動作環境をパックにしたものと
> ここで教わったが、アプリがIPアドレスを持つわけないだろう

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

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

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

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

Dockerの仕組みに詳しい人はネットワークについても勉強するだろうけど
Dockerを使っている段階では、コンテナがどのIPアドレスを
持ってるかなんて意識していない

294 ：login:Penguin：2018/08/01(水) 18:23:53.95 ID:vZ5iA/aw.net

>>289
> それだけDockerの理解・運用は難しいということだな

技術職っていうのはそういうもんだよ。
ソフトウェアにおいて技術=知識
知識を得て楽をするか、知識ない人は力ずくで頑張れと

295 ：login:Penguin：2018/08/01(水) 21:17:15.65 ID:rxe3lfEn.net

>>292
いや、関係あるでしょ。
元々ある程度のリテラシーのエンジニアに使ってもらうこと前提の話をしてるのに、あなたは俺が俺がばっかりで使い手に対する配慮がほとんど感じられない。

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

せいぜいその職場から振り落とされないようにしてくださいね。
普通の職場で働くと、たぶんあなたは腫れ物扱いされます。

296 ：login:Penguin：2018/08/01(水) 21:18:23.05 ID:/ajt4qwz.net

なんで喧嘩腰なの？

297 ：login:Penguin：2018/08/01(水) 21:22:54.23 ID:vZ5iA/aw.net

>>295
> 元々ある程度のリテラシーのエンジニアに使ってもらうこと前提の話をしてるのに、

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

技術の話をしてください

298 ：login:Penguin：2018/08/01(水) 21:27:17.86 ID:vZ5iA/aw.net

ほんとDockerの話しろっていってるのに、
俺の周りの人間は〜馬鹿ばかりだから〜
人間の話ばっかりｗ

299 ：login:Penguin：2018/08/01(水) 22:48:53.21 ID:gpg7eCuF.net

なんでこのスレこんなに荒れてるの

300 ：login:Penguin：2018/08/02(木) 01:28:49.77 ID:NqqEoGeq.net

全く興味ない第三者だが、いちおう荒れた懲罰としてうんこ置いとくな？

　　　 _人
　　　(　 )
　　 (へ ノ)
　ヽ( ´ 」`)ノ
　 (　 `ー　 )
【いけめんｳﾝｺ】

301 ：login:Penguin：2018/08/02(木) 06:34:51.81 ID:rhKXtEAo.net

そこで働く人間無視して仕事できる訳ないし、やってるつもりなら大した仕事してない。

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

インフラエンジニア要らないってのは理想。ただ、その理想を妨げる事が多いのが声がでかいアプリエンジニア。
大概やりたいようにやって自分では運用回らなくなって、別の誰かに運用を押し付けて自分はフェードアウトするってのがお決まりのパターン。

302 ：login:Penguin：2018/08/02(木) 07:40:01.26 ID:a1K3N0Xu.net

>>301
そういう話じゃねーよ

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

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

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

「Dockerの適している使い方は○○です」って結論した後
心の中で「でもうちでは技術者のスキルが低くて使えるやついないんだよ。」って泣けばいいだろ
他の人には関係ない話だ

303 ：login:Penguin：2018/08/02(木) 08:13:38.44 ID:a1K3N0Xu.net

>>301
> インフラエンジニア要らないってのは理想。

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

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

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

どうせこういうことすら思いつかなかったんだろ？
だからお前がアプリケーションが動くサーバー作ったことねーだろってわかるんだよ。

304 ：login:Penguin：2018/08/03(金) 23:40:03.86 ID:1yCRuO5i.net

数日かけてDocker使って個人用のミニアプリ書いたぜ

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

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

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

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

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

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

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

docker使えば、さっき書いたdocker run〜のコマンドだけで構築できるというのに。

305 ：login:Penguin：2018/08/05(日) 08:47:03.44 ID:t1pjwXO7.net

すごいドヤ顔w

306 ：login:Penguin：2018/08/05(日) 13:08:10.87 ID:FlnPtVfq.net

>>305
めちゃくちゃ便利やでw

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

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

中身は既存のプログラムの組み合わせだけど、同じサービスを提供する
別のプログラムを作ったかのように使える

307 ：login:Penguin：2018/08/05(日) 16:28:15.92 ID:t1pjwXO7.net

そうですね

308 ：login:Penguin：2018/08/05(日) 21:35:59.80 ID:t4Ako3RB.net

Docker使いこなせる人ってすごいな（皮肉ではなく）

309 ：login:Penguin：2018/08/05(日) 21:53:21.43 ID:9sU0s1Rh.net

わざわざdocker使わんでもchrootでいいことにdocker使ってる人が結構いる

310 ：login:Penguin：2018/08/05(日) 22:01:32.35 ID:yAw8KkqM.net

chrootの親戚のGUIなし仮想アプライアンスに情熱を燃やせる謎
別スレではviの話で盛り上がるし日本人はビルジョイが好きなんだな

311 ：login:Penguin：2018/08/05(日) 22:05:09.77 ID:yAw8KkqM.net

あーGUIまでいってるのか、なるほど

312 ：login:Penguin：2018/08/05(日) 23:04:52.65 ID:NroY7Fy3.net

>>309
chroot使うぐらいならDocker使うなー

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

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

懐かしくてちょっとググってみたけど、
あんな面倒なことやってたのかって思った

313 ：login:Penguin：2018/08/05(日) 23:08:47.08 ID:NroY7Fy3.net

>>310
自分だけの仮想アプライアンスを簡単に自作できるからねー
同じものを何度もセットアップしてるなら
それが簡単になるので楽だよ

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

一度Dockerでイメージ作ってると
同じことを何度もやらなくてすむようになるからね

314 ：login:Penguin：2018/08/07(火) 07:54:03.45 ID:shK4WVTS.net

それだけのことならVMや自作rpmでもあんま変わらん…

315 ：login:Penguin：2018/08/07(火) 08:50:58.74 ID:FmqfeUYE.net

あんまり変わらないから、何倍も簡単なDockerの方が良いよね

316 ：login:Penguin：2018/08/07(火) 09:01:08.27 ID:FmqfeUYE.net

まあ一応VMや自作PRMが何故Dockerに太刀打ち出来ないかと言うと、

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

自作RPMはDockerと真逆の考え方だな。実行環境を含めて依存しないようにしてるのに
頑張って他のパッケージとの依存関係を解決しないといけない
適切な依存関係になるように自作PRMを作る大変な作業が待ってる。

317 ：login:Penguin：2018/08/07(火) 09:01:35.38 ID:FmqfeUYE.net

自作PRMは可搬性がないからWindowsで動かせないってのもあるな

318 ：login:Penguin：2018/08/07(火) 09:03:06.65 ID:FmqfeUYE.net

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

1.の既存の○○でもあんま変わらんと言われても
既存の○○は2.の問題があるでしょって話

319 ：login:Penguin：2018/08/07(火) 09:43:33.53 ID:svderS3e.net

ドヤ顔w

320 ：login:Penguin：2018/08/07(火) 11:13:12.25 ID:KYfMTuuE.net

　　　　　　　　　　　　 ＿＿＿
　　　　　　　 　　　 ／　ノ '' ⌒＼ 　
　　　　　　　 　　／　（ ● ) (● )＼
ﾄﾞﾔｰｰｰｰｰ ／　:::::⌒,　　　ゝ⌒:::::＼ ｰｰｰｰｰｰｰ!!!!
　　　　　　　　|　　　　　 ﾄ==ｨ'　　　　　|
　　_,rｰく´＼　＼,--､　　`ー'　　　　／
. ,-く ヽ.＼ ヽ Y´　／ 　　 ー　　　´ﾉ ｀ ｰ-､
　{　-!　l _｣_ﾉ‐′/＼― 、　　,−/＿|　　　 ∧
. ヽ　ﾞｰ'´ ヽ　　/　フ ＼　　　　 /ヽ　　　　 /ハ
　｀ゝ、　　ﾉ　ノ　　＼ 　 ヽ　　/ ／
　　　　　＿|＼∧∧∧ＭＭＭＭ∧∧∧／|＿
　　　　　＞　　　　　　　　　　　　　　　　　　＜
.　|　ヽヽ ｜　　 ＿/＿ヽヽ　|　　ヽ|　 |ヽ　 ム ヒ　|　|
. ├─ ￣Ｔ￣/　 /　/　￣フ|￣　 |￣|￣　月 ヒ　|　|
.　|.　　　 　＼　　/ ノ 　 ／　| 　/ | ノ ＼ ﾉ Ｌ_い o o

321 ：login:Penguin：2018/08/07(火) 14:30:15.46 ID:kww6lavE.net

一生懸命に覚えたことをレポートにまとめてるんだよ。
見守ってやろうぜ。

322 ：login:Penguin：2018/08/07(火) 19:30:53.54 ID:/C7ROP+b.net

なんかワロタ

323 ：login:Penguin：2018/08/07(火) 20:10:59.70 ID:QJmmm+eF.net

自分で書かなくてもMuninとかあるで。

324 ：login:Penguin：2018/08/07(火) 20:28:26.91 ID:KYfMTuuE.net

>>323
知ってる。昔会社で使ってた。
だけどあれじゃ俺がやりたいことを満たせないんだよ
機能は高機能だけど、あそこまでいらない

325 ：login:Penguin：2018/08/07(火) 20:39:58.40 ID:QJmmm+eF.net

Qiitaにでも書いとけ

326 ：login:Penguin：2018/08/07(火) 20:42:05.65 ID:KYfMTuuE.net

いわゆるインフラ屋はDockerを使って
ディストリによってパッケージが用意されてるようなものを
Dockerイメージ化するという発想になりがちに思える

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

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

だからアプリが動く環境も含めてDockerイメージにする
そうすりゃDockerさえ動いていれば、簡単にどこでも動くものが作れる

327 ：login:Penguin：2018/08/07(火) 20:42:24.72 ID:KYfMTuuE.net

>>325　　
　　　　　　　　　　　　 ＿＿＿
　　　　　　　 　　　 ／　ノ '' ⌒＼ 　
　　　　　　　 　　／　（ ● ) (● )＼
ﾄﾞﾔｰｰｰｰｰ ／　:::::⌒,　　　ゝ⌒:::::＼ ｰｰｰｰｰｰｰ!!!!
　　　　　　　　|　　　　　 ﾄ==ｨ'　　　　　|
　　_,rｰく´＼　＼,--､　　`ー'　　　　／
. ,-く ヽ.＼ ヽ Y´　／ 　　 ー　　　´ﾉ ｀ ｰ-､
　{　-!　l _｣_ﾉ‐′/＼― 、　　,−/＿|　　　 ∧
. ヽ　ﾞｰ'´ ヽ　　/　フ ＼　　　　 /ヽ　　　　 /ハ
　｀ゝ、　　ﾉ　ノ　　＼ 　 ヽ　　/ ／
　　　　　＿|＼∧∧∧ＭＭＭＭ∧∧∧／|＿
　　　　　＞　　　　　　　　　　　　　　　　　　＜
.　|　ヽヽ ｜　　 ＿/＿ヽヽ　|　　ヽ|　 |ヽ　 ム ヒ　|　|
. ├─ ￣Ｔ￣/　 /　/　￣フ|￣　 |￣|￣　月 ヒ　|　|
.　|.　　　 　＼　　/ ノ 　 ／　| 　/ | ノ ＼ ﾉ Ｌ_い o o

328 ：login:Penguin：2018/08/08(水) 01:40:00.74 ID:H2RB231p.net

VMはカーネルやデバイスノードがゲストに独立して用意されているからサンドボックスとして安心できる
これらをホストゲストで共有してるDockerは、ライフラインを共有しているゲストハウスみたいなもの
カーネルぶんのメモリ(敷金礼金)は浮くがinit以降のメモリ(賃料)は当然払わなければならない
起動も10秒以下の差
つまりデスクトップならVM常道

329 ：login:Penguin：2018/08/08(水) 03:48:30.48 ID:tyC3gFls.net

あぁ、またこれな

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

VMでもDockerでもサンドボックスとして安心できる
その上で、VMよりも軽いのがメリットなわけで

330 ：login:Penguin：2018/08/08(水) 04:00:13.46 ID:tyC3gFls.net

起動も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


マシンリソースを無駄にすること無く、サンドボックスを動かせる

331 ：login:Penguin：2018/08/08(水) 04:18:39.40 ID:tyC3gFls.net

> 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になってしまったよｗ

332 ：login:Penguin：2018/08/08(水) 04:26:57.73 ID:tyC3gFls.net

> カーネルぶんのメモリ(敷金礼金)は浮くが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だって同じようにホストのカーネルメモリ書いてないだろ？

333 ：login:Penguin：2018/08/08(水) 04:28:44.09 ID:tyC3gFls.net

　　　　　　　　　　　　 ＿＿＿
　　　　　　　 　　　 ／　ノ '' ⌒＼ 　
　　　　　　　 　　／　（ ● ) (● )＼
ﾄﾞﾔｰｰｰｰｰ ／　:::::⌒,　　　ゝ⌒:::::＼ ｰｰｰｰｰｰｰ!!!!
　　　　　　　　|　　　　　 ﾄ==ｨ'　　　　　|
　　_,rｰく´＼　＼,--､　　`ー'　　　　／
. ,-く ヽ.＼ ヽ Y´　／ 　　 ー　　　´ﾉ ｀ ｰ-､
　{　-!　l _｣_ﾉ‐′/＼― 、　　,−/＿|　　　 ∧
. ヽ　ﾞｰ'´ ヽ　　/　フ ＼　　　　 /ヽ　　　　 /ハ
　｀ゝ、　　ﾉ　ノ　　＼ 　 ヽ　　/ ／
　　　　　＿|＼∧∧∧ＭＭＭＭ∧∧∧／|＿
　　　　　＞　　　　　　　　　　　　　　　　　　＜
.　|　ヽヽ ｜　　 ＿/＿ヽヽ　|　　ヽ|　 |ヽ　 ム ヒ　|　|
. ├─ ￣Ｔ￣/　 /　/　￣フ|￣　 |￣|￣　月 ヒ　|　|
.　|.　　　 　＼　　/ ノ 　 ／　| 　/ | ノ ＼ ﾉ Ｌ_い o o

334 ：login:Penguin：2018/08/08(水) 04:40:02.13 ID:tyC3gFls.net

ま、そもそもVMとDockerは違うもので、両方を組み合わせて使うものなんだけどね

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

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

目的が違うものなんで、Dockerの代わりにVMを使うとか
VMの代わりにDockerを使うとかいう発想がそもそもズレてる

335 ：327：2018/08/08(水) 05:36:35.37 ID:H2RB231p.net

＞目的が違うものなんで、Dockerの代わりにVMを使うとか
＞VMの代わりにDockerを使うとかいう発想がそもそもズレてる

そこだけは同意だな
そこまで理解できたなら賢いじゃないか

336 ：login:Penguin：2018/08/08(水) 07:17:02.14 ID:25daI1mK.net

序論、本論、結論まで到達？

337 ：login:Penguin：2018/08/08(水) 10:38:16.92 ID:tyC3gFls.net

>>335
何年も前から理解してるぞw

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

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

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

VMとコンテナは使い方が明確に違う（ことを理解してなきゃこんなこと書けない）

338 ：login:Penguin：2018/08/08(水) 10:57:28.63 ID:tyC3gFls.net

物理マシンもVM（仮想マシン）も、俺にとっては同じマシン扱いなんだわ
形あるハードウェアで形作られてるかそうでないかの違い。

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

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


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

ってこと。

アプリをサンドボックス化するためにマシンを作るとか重すぎでしょｗ
まさに牛刀割鶏、鶏をさばくのに大きな牛刀を使うようなもの

339 ：login:Penguin：2018/08/08(水) 11:01:18.07 ID:tyC3gFls.net

それから「デスクトップ環境」の話
これはアプリか？って問われれば、アプリだと思う人はいないよね
複数のアプリを連携して作られた環境

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

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

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

物理マシン or 仮想マシン で動いてるデスクトップ環境やらCLIやらsystemdやら。
そこから起動する一つのアプリ、それがDockerコンテナ相当なんだよ

340 ：login:Penguin：2018/08/08(水) 17:56:23.41 ID:8+YiPWG6.net

GitLab運用してるんだが, CIで使うビルド環境とかは明らかにDockerないしはKubernetesが優秀
一時Docker-Compose on VMでやってたけど使い捨てVMを構築する処理が重くてしょうがなかった(しかも遅い)
スタンバイ状態のビルド環境VMを2つも作るともう限界だが, Kubernetesなら5個くらいPodをスタンバイさせてても余裕だし新規Pod作成も早い(Docker単体なら10コンテナ並走でもいける)

341 ：login:Penguin：2018/08/08(水) 18:46:47.42 ID:Gp7Qfh6x.net

夏休みだな
お前らが当たり前過ぎて書かないこともこうやって書いてあれば誰かの役に立つのだろう

342 ：login:Penguin：2018/08/08(水) 23:00:30.67 ID:tyC3gFls.net

>>340
Kubernetesって使用メモリ多くない？1GBぐらい使ってた気がするんだが
だから使わないってわけじゃなく、もうデファクトスタンダードに
なりつつあるから避けようがないと思ってるけど

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

>>341
お前のその書き込みは誰の役にも立たんけどなｗ

343 ：login:Penguin：2018/08/08(水) 23:10:50.30 ID:9RbiD8jy.net

ケンカはやめて（＞＜）

344 ：login:Penguin：2018/08/09(木) 06:19:00.25 ID:/JzHzLjB.net

Docker-composeで使い捨てVMを構築するのが遅いというところがよくわからない。VM(dockerホスト)は一回構築したら終わりで、後はそこにコンテナを作ったり消したりするだけじゃないの？

345 ：login:Penguin：2018/08/09(木) 13:04:39.32 ID:xAQpubuL.net

>>344
今までの話の流れからすると、CIでテスト実行するたびにVMの作成と破棄をしていたってことでしょ？
>>328がVMでも10秒以下の差しか無いから問題ないみたいなことを言ってるから
（VMの中でDocker-Composeが動いてるのは、この話にあまり関係ない）


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


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

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

DockerでもアプリごとにDockerイメージが必要になるのは同じだが
Dockerはキャッシュがあるから、Dockerイメージの作成は短時間でできる。
VMだとキャッシュはないし起動に10秒かかるし、作成したイメージの
サイズもでかいし頻繁にVMイメージの作成なんかやってられないよ

346 ：login:Penguin：2018/08/09(木) 16:12:56.70 ID:+YyDvSZH.net

今までVPSとかで動かしていたものをコンテナ化してGCE辺りに移そうと思うんだけど
DBの保存や出力したファイルの保存はみんなどうやってるの？
結局マウントできるディスクが必要なんじゃないかってところで今頭を抱えてる

347 ：login:Penguin：2018/08/09(木) 17:43:56.11 ID:UwrKl0TS.net

>>346
まずアプリサーバーとデータサーバーを分けて考える。
Dockerでやる価値が高いのはアプリ

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

という話。


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

一番楽なのは、難しいそれらをクラウドが提供するサービスに置き換えてしまうこと。
つまりGCPであればCloud SQLやCloud Storageを使う
これらは信頼性も性能も（金額次第だが）高くできる。

348 ：login:Penguin：2018/08/09(木) 17:47:52.88 ID:UwrKl0TS.net

>>346
どうしても自力でやりたいならば、Dockerのボリュームという
機能を通してホスト上に保存するのが一番手っ取り早い

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

MySQL ぐらいだったらシンプルだし事例も多いので簡単なんだが
何処に何を保存するのかよくわからんようなアプリは
それを把握することに時間を奪われるだろう

349 ：login:Penguin：2018/08/09(木) 17:55:09.12 ID:UwrKl0TS.net

>>346
> 結局マウントできるディスクが必要なんじゃないかってところで今頭を抱えてる

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

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


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

Dockerコンテナを使った時データの保存先をどうすれば良いのか悩むのは
Dockerコンテナがアプリと同質のものであることを理解してない証拠

350 ：login:Penguin：2018/08/13(月) 18:09:32.79 ID:v0wq29mQ.net

最近コンテナってものを知ったんだけど、上の説明だとフラットパックってのとの違いがわからない
スタンダロンなアプリじゃなく、ソフトウェア群の、何かしらのフロントエンドにドッカーが向いてるってこと？

351 ：login:Penguin：2018/08/13(月) 21:26:12.80 ID:nXCS+eUE.net

コンテナ自体が非常に難しい概念なんだよ
どうもLinuxの世界で発祥したもので、昔からLinuxやってる人でないとわからないらしい
「最近流行りのDockerなるものをやってみたい」というヤツには到底無理(俺含め)

352 ：login:Penguin：2018/08/13(月) 21:45:54.13 ID:xnhwDoUS.net

Solarisのゾーンがコンテナの先駆けじゃない？

353 ：login:Penguin：2018/08/13(月) 23:10:29.77 ID:XRxrVOUh.net

FreeBSDのjailとか？
cgroupの概念は含まれてないけどね

354 ：login:Penguin：2018/08/14(火) 00:05:12.50 ID:kAynbxnX.net

>>351
説明してる奴が「難しいこと理解した俺スゲー」ってのを
自慢げに小難しく語るのが問題なだけ

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

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





…って言う俺もコンテナのこと全然知らんのだが

355 ：login:Penguin：2018/08/14(火) 00:55:59.54 ID:M/lw6/kx.net

>>351
技術を理解するのと目的を理解するのをごっちゃにしてるから

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


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

コンテナという技術を知るのではなくて、どんな問題があって
それを解決するものがDockerなんだって理解するのが先

356 ：login:Penguin：2018/08/14(火) 01:03:03.69 ID:M/lw6/kx.net

補足だが、
> （主に自分が作った）アプリをいろんな環境で

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

だから自分が作ってないものを動かしてるだけの人は
（物理マシン or 仮想マシンの上に）ディスロの環境整えられてる
パッケージ入れて使っても同じじゃんって思ってしまう。
技術は理解していても、そもそもの問題を理解していから
Dockerが必要な理由もわからない

357 ：login:Penguin：2018/08/14(火) 01:10:25.09 ID:M/lw6/kx.net

>>350
フラットパックってのがよくわからない。
一般的な用語？ググっても見つからないんだが。

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

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

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

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

Dockerはスタンドアロンなアプリを「作るもの」
であって「動かす環境」ではないんだよ
そこを根本的に間違ってる人がいる。

358 ：login:Penguin：2018/08/14(火) 02:08:41.28 ID:kAynbxnX.net

>>357
https://flatpak.org/

359 ：login:Penguin：2018/08/14(火) 02:29:21.54 ID:Ttl7PXT/.net

カタカナでググったから見つからなかったのかｗ

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でいいじゃない？と。

360 ：login:Penguin：2018/08/14(火) 03:11:38.19 ID:Ttl7PXT/.net

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

361 ：login:Penguin：2018/08/14(火) 10:08:37.26 ID:M6PcTN6D.net

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

362 ：login:Penguin：2018/08/14(火) 11:51:58.01 ID:kAynbxnX.net

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

363 ：login:Penguin：2018/08/14(火) 14:07:10.96 ID:ghMKDHT1.net

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

制限なんかしてないよ？

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

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

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

364 ：login:Penguin：2018/08/14(火) 14:12:08.48 ID:ghMKDHT1.net

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

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

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

365 ：login:Penguin：2018/08/14(火) 14:21:37.56 ID:ghMKDHT1.net

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

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

366 ：login:Penguin：2018/08/14(火) 14:30:00.78 ID:ghMKDHT1.net

>>363は>>361宛て

367 ：login:Penguin：2018/08/14(火) 14:37:27.72 ID:M6PcTN6D.net

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

368 ：login:Penguin：2018/08/14(火) 14:42:46.76 ID:M6PcTN6D.net

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

369 ：login:Penguin：2018/08/14(火) 14:48:15.40 ID:M6PcTN6D.net

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

370 ：login:Penguin：2018/08/14(火) 15:04:52.25 ID:kAynbxnX.net

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

371 ：login:Penguin：2018/08/14(火) 15:14:48.58 ID:kAynbxnX.net

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

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

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

372 ：login:Penguin：2018/08/14(火) 18:38:55.14 ID:xLHQglRN.net

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

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

373 ：login:Penguin：2018/08/14(火) 18:41:22.43 ID:xLHQglRN.net

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

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

374 ：login:Penguin：2018/08/14(火) 18:49:48.39 ID:xLHQglRN.net

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

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

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

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

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

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

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


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

375 ：login:Penguin：2018/08/14(火) 18:53:45.18 ID:xLHQglRN.net

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

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

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

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

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

376 ：login:Penguin：2018/08/14(火) 18:59:38.16 ID:xLHQglRN.net

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

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

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

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

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


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

377 ：login:Penguin：2018/08/14(火) 19:28:34.72 ID:kAynbxnX.net

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

378 ：login:Penguin：2018/08/14(火) 20:07:26.17 ID:Rn+J0ap2.net

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

379 ：login:Penguin：2018/08/14(火) 20:10:09.80 ID:J8E8MYcP.net

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

380 ：login:Penguin：2018/08/14(火) 20:35:54.31 ID:xLHQglRN.net

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

俺も同意見である

381 ：login:Penguin：2018/08/15(水) 01:16:08.69 ID:ugls1Kd9.net

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

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

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

382 ：login:Penguin：2018/08/15(水) 01:17:35.73 ID:ugls1Kd9.net

>>381
自己レス

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

383 ：login:Penguin：2018/08/15(水) 13:20:10.69 ID:uskt4Uvb.net

>>381
新しいネットワークを作成して使えるよ。これじゃだめ？
各コンテナ間のネットワークの独立性は実現できると思うけど

docker network create net1
docker network create net2

docker run -it --net=net1 debian /bin/bash
docker run -it --net=net2 debian /bin/bash

384 ：login:Penguin：2018/08/16(木) 00:43:29.60 ID:kHU6PfSr.net

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

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

385 ：login:Penguin：2018/08/17(金) 19:01:16.67 ID:LyzN7uI2.net

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

386 ：login:Penguin：2018/08/17(金) 20:33:23.06 ID:x+SQYw9w.net

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

387 ：login:Penguin：2018/08/18(土) 00:44:21.73 ID:bBPq1AA+.net

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

388 ：login:Penguin：2018/08/18(土) 08:03:42.49 ID:o1onkvNG.net

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

389 ：login:Penguin：2018/08/18(土) 10:11:41.60 ID:B/BAtWOD.net

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

390 ：login:Penguin：2018/08/18(土) 11:00:32.73 ID:S06djVVH.net

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

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

それを実現するのがKubernetes


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

391 ：login:Penguin：2018/08/18(土) 13:41:20.07 ID:B/BAtWOD.net

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

392 ：login:Penguin：2018/08/18(土) 14:41:29.39 ID:S06djVVH.net

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

393 ：login:Penguin：2018/08/18(土) 15:46:56.84 ID:bBPq1AA+.net

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

394 ：login:Penguin：2018/08/20(月) 12:44:26.66 ID:KhDqHNJn.net

コンテナの台頭で仮想マシンの未来に暗雲--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％）が続いている。

395 ：login:Penguin：2018/08/22(水) 08:59:48.33 ID:j+z99P2p.net

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

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

396 ：login:Penguin：2018/08/22(水) 13:19:31.20 ID:pivahsct.net

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

397 ：login:Penguin：2018/08/22(水) 13:36:22.02 ID:SRjEX/kw.net

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

398 ：login:Penguin：2018/08/22(水) 15:20:11.01 ID:sHVRQKWS.net

18.06.1 が来てた

399 ：login:Penguin：2018/08/23(木) 17:03:41.25 ID:ZGFS8Yk4.net

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

docker run -it ubuntu bash

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

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

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

400 ：login:Penguin：2018/08/23(木) 17:48:33.28 ID:q1z8N/B0.net

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

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

401 ：login:Penguin：2018/08/23(木) 17:49:50.48 ID:q1z8N/B0.net

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

402 ：login:Penguin：2018/08/23(木) 17:55:02.79 ID:7FvXZ15y.net

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

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

403 ：login:Penguin：2018/08/23(木) 18:41:12.97 ID:ZGFS8Yk4.net

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

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

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

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


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

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

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

404 ：login:Penguin：2018/08/23(木) 18:43:04.38 ID:q1z8N/B0.net

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

405 ：login:Penguin：2018/08/23(木) 18:52:04.65 ID:7FvXZ15y.net

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

406 ：login:Penguin：2018/08/23(木) 18:52:37.87 ID:AO6wJAqi.net

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

407 ：login:Penguin：2018/08/23(木) 18:55:26.07 ID:q1z8N/B0.net

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

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

408 ：login:Penguin：2018/08/23(木) 18:58:58.10 ID:q1z8N/B0.net

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

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

409 ：login:Penguin：2018/08/23(木) 19:10:58.17 ID:ZGFS8Yk4.net

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

410 ：login:Penguin：2018/08/23(木) 20:06:23.78 ID:NhXd7pKF.net

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

411 ：login:Penguin：2018/08/23(木) 20:15:56.51 ID:/Er2oz0C.net

全然違うかなー

412 ：login:Penguin：2018/08/23(木) 20:47:22.20 ID:AO6wJAqi.net

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

413 ：login:Penguin：2018/08/23(木) 21:22:51.21 ID:jewCS8ED.net

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

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

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

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

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

414 ：login:Penguin：2018/08/23(木) 22:53:16.60 ID:Rl2wmT+c.net

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

415 ：login:Penguin：2018/08/23(木) 23:04:39.22 ID:YJtvG1Lc.net

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

416 ：login:Penguin：2018/08/23(木) 23:22:07.73 ID:igELEe5F.net

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

417 ：login:Penguin：2018/08/23(木) 23:42:56.02 ID:YJtvG1Lc.net

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

418 ：login:Penguin：2018/08/24(金) 00:06:45.21 ID:wl1baohm.net

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

419 ：login:Penguin：2018/08/31(金) 09:43:02.97 ID:UOMp0l5m.net

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

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

420 ：login:Penguin：2018/09/03(月) 19:27:51.75 ID:lFOQrHc5.net

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

421 ：login:Penguin：2018/09/04(火) 11:08:31.46 ID:XGRY6CNs.net

--buildじゃだめ？

422 ：login:Penguin：2018/09/09(日) 06:08:55.90 ID:cEYtNNsu.net

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

423 ：login:Penguin：2018/09/09(日) 09:40:19.57 ID:ZTk8dQJu.net

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

424 ：login:Penguin：2018/09/09(日) 10:55:56.07 ID:e5pDDvY7.net

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

425 ：login:Penguin：2018/09/09(日) 11:12:04.98 ID:ZTk8dQJu.net

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

426 ：login:Penguin：2018/09/09(日) 19:24:56.20 ID:Afzp+wKU.net

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

427 ：login:Penguin：2018/09/13(木) 18:00:19.97 ID:A2WBsHxK.net

ubuntu18.04のホスト上で docker17.06.2-ceで動作検証してるんですけど、
質問させてください。

docker-compose.ymlで
volumes:
- /etc/localtime:/etc/localtime:ro
- /usr/local/etc/docker/my.cnf:/etc/my.cnf:ro
- /usr/local/etc/docker/my.cnf.d/:/etc/my.cnf.d:ro
こんな感じにしてbuildやpullを済ませ up -d した時に、

ERROR: for (コンテナ名) Cannot start service (サービス名): error while creating mount source path '/usr/local/etc/docker/my.cnf': mkdir /usr/local/etc/docker: read-only file system

こういうエラーが出ます。
root@docker:~# ls /usr/local/etc/docker/
my.cnf my.cnf.d

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

428 ：login:Penguin：2018/09/13(木) 19:39:40.56 ID:5kXiEAIj.net

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

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

429 ：login:Penguin：2018/09/14(金) 09:15:35.43 ID:O0WiB81l.net

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

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

430 ：427：2018/09/14(金) 18:06:45.51 ID:4XP848iF.net

- /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年以上前のバージョンを使わざるを得ない事情でもあるのかなぁ」って思っただけよん

431 ：login:Penguin：2018/09/15(土) 07:01:30.83 ID:yI+cCQi1.net

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

432 ：login:Penguin：2018/09/24(月) 01:08:42.35 ID:3WJGu+tF.net

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

433 ：login:Penguin：2018/09/24(月) 04:53:27.83 ID:h/F6DQep.net

「docker commit」で検索！

434 ：427：2018/09/25(火) 15:20:50.57 ID:zdGJMagM.net

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

volumes:
- /usr/local/opt/docker:/var/lib/mysql
- /etc/localtime:/etc/localtime:ro

上段はマウントできず、下段はマウントできます。
いずれもホスト側はroot:rootの所有で、全ユーザー読み書き可です。

Cannot start service db_001: error while creating mount source path '/usr/local/opt/docker': mkdir /usr/local/opt: read-only file system

なぜ、/usr/local/opt/dockerディレクトリが存在するのに
わざわざ/usr/local/optをmkdirしようとして失敗してるんでしょうか？
そのあたりの仕組みが理解できれば、解決できそうな気もするんですが…

435 ：426=433：2018/10/02(火) 11:05:27.29 ID:MTSGNvvZ.net

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

436 ：login:Penguin：2018/10/02(火) 12:26:31.40 ID:ngnCMsef.net

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

437 ：login:Penguin：2018/10/02(火) 14:05:12.80 ID:jMGWfJIN.net

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

438 ：login:Penguin：2018/10/05(金) 17:28:47.41 ID:uwcVKd6M.net

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

・外部からOpenVPNコンテナ(コンテナA)でVPN接続を受ける
・外部のOpenVPNクライアントと、Dockerの別コンテナ(コンテナB)間で通信する

これがネットワーク構成的に実現できずにいます。

docker network createでbridgeネットワークを作り、
コンテナA,Bには docker run --ip=で固定IPを振っています。

ネットワーク構成で言えば、コンテナAをゲートウェイとすれば良いので
「OpenVPNネットワークへのゲートウェイをコンテナAとする」ルーティングを
コンテナBに書ければ解決する話なんですが、それがどうやっても書けません。

Dockerhubから拾ってきたコンテナBにはrouteコマンドすらないため、
DockerfileでrouteコマンドをRUNすることもできない。

docker network create で--gateway のIPをコンテナAにすればいいのかと思いきや、
試したんですが、どうも--gatewayのIPは即Dockerホストに振られてしまうようで、
コンテナAにそのIPを振ろうとすると「IPが被ってる」エラーになる。

もちろんホスト側にルーティングを書けば解決するんですが、
できればホストはいじらずdocker側だけで解決したいなぁと。

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

439 ：login:Penguin：2018/10/08(月) 17:27:52.77 ID:+G8YrS7/.net

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

440 ：login:Penguin：2018/10/08(月) 18:31:01.90 ID:dcwIe0qQ.net

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

441 ：437：2018/10/09(火) 09:49:23.16 ID:a4is0HOD.net

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

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

442 ：login:Penguin：2018/10/09(火) 11:37:32.24 ID:UEbDWUsW.net

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

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

443 ：437：2018/10/09(火) 11:45:22.31 ID:a4is0HOD.net

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

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

444 ：login:Penguin：2018/10/09(火) 12:56:46.60 ID:J/UkStG7.net

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

445 ：login:Penguin：2018/10/09(火) 14:28:29.84 ID:lxGRoqO6.net

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

446 ：437：2018/10/09(火) 14:41:21.41 ID:a4is0HOD.net

>>444

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

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

447 ：437：2018/10/09(火) 15:41:05.80 ID:a4is0HOD.net

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

448 ：login:Penguin：2018/10/16(火) 14:04:47.68 ID:JjMfngP+.net

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

449 ：login:Penguin：2018/10/26(金) 03:04:33.03 ID:UuZWwwD+.net

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

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

450 ：login:Penguin：2018/10/26(金) 06:35:45.90 ID:xzHCVt/i.net

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

451 ：login:Penguin：2018/10/26(金) 07:03:02.70 ID:Y5itkZBt.net

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

452 ：login:Penguin：2018/10/26(金) 07:40:58.49 ID:S+WdRTJT.net

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

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

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

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

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

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

453 ：login:Penguin：2018/10/26(金) 07:41:20.37 ID:S+WdRTJT.net

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

454 ：login:Penguin：2018/10/26(金) 08:01:47.31 ID:BI6ZyjXf.net

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

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

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

455 ：login:Penguin：2018/10/26(金) 09:37:10.67 ID:UuZWwwD+.net

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

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

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

456 ：login:Penguin：2018/10/26(金) 09:58:02.43 ID:S+WdRTJT.net

>>455
C言語とかコンパイル言語使ったことある？
dockerのbuildは、C言語などのビルド（コンパイル）と同じ

言語はソースコードをビルドして実行バイナリを作成する
Dockerはすでにある複数のバイナリをもとに、Dockerイメージを作成する


さて、実行バイナリは、データを保存したらどこに保存されるか？
実行バイナリの中に埋め込まれるわけじゃないよね。実行バイナリの外のファイルに保存する。
実行バイナリ自体は読み取り専用。ビルドしたときに作成したバイナリから変更することはない

Dockerも同じように考える。Dockerイメージっていうのはビルドして作成した状態から変更しない
内部的には変更されていてそのデータはどこかに残っていたりするが、そういうのは内部の話なんで忘れる
Dockerイメージは読み取り専用で、Dockerイメージをrun（実行）するとプロセスが起動する
あ、ここも実行バイナリと同じだね。バイナリを実行するとプロセスが起動する

Dockerイメージをrunして作ったプロセス（＝Dockerコンテナ）はどこにデータを保存するか？
Dockerイメージは読み取り専用なので、当然Dockerコンテナの外のファイルに保存する。


C言語 ・・・ ソースコード -> [Makefileでビルド] -> 実行バイナリ
Docker・・・ソースコード等 -> [DockerfileでDockerビルド] -> Dockerイメージ

Dockerのソースコード等には本当にいろいろ含まれる
アプリのソースコードだったり、nginxだったり。カーネル以外の全て

で、コード消えるのか？っていう疑問の答えは、実行バイナリ消してもソースコードをビルドすれば作れるでしょう？
Dockerも同じでソースコード等をビルドすれば、Dockerイメージができるんだから何も問題ない

457 ：login:Penguin：2018/10/26(金) 10:06:27.87 ID:S+WdRTJT.net

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

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

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

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

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

458 ：login:Penguin：2018/10/26(金) 10:18:44.97 ID:UuZWwwD+.net

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

459 ：login:Penguin：2018/10/26(金) 10:20:16.70 ID:S+WdRTJT.net

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

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

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


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

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

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

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

460 ：login:Penguin：2018/10/26(金) 10:26:18.88 ID:UuZWwwD+.net

今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね

461 ：login:Penguin：2018/10/26(金) 10:29:10.46 ID:S+WdRTJT.net

Dockerを仮想マシンの代わりとしてとか考えてると

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

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

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

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

バイナリに例えれば、C言語のプロセスに乗り込んで（デバッガで？）
プロセスのメモリを書き換えて、プロセス部分をディスクに書き出すようなもんだよ
そんなことしないだろ？

462 ：login:Penguin：2018/10/26(金) 10:34:41.20 ID:S+WdRTJT.net

> 今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね

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

virtualenvは実行環境を作るもの
Dockerは実行環境を含めた実行イメージ＝Dockerイメージ＝実行バイナリの凄い版を
作るものだから

463 ：login:Penguin：2018/10/26(金) 10:39:21.79 ID:UuZWwwD+.net

>>462
やっとそこの理解ができた
インフラがDocker推すのわかるわ

virtualenvのpython周りをなんとなくコンテナ化したのとはちがって、OS含めた実行環境コンテナを作れるとなると、ほんといろいろ解決できるな！

464 ：login:Penguin：2018/10/26(金) 10:44:35.53 ID:S+WdRTJT.net

例えばgoで作られたバイナリは、いろんなものがスタティックリンクされるので
単一のバイナリをコピーするだけで、あちこちでそのまま動かすことができる。
それと同じようにDockerもDockerイメージの中に、いろんなものが詰め込まれてるので
あちこちで動かすことができる

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

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

ウェブアプリだけじゃなくCLIコマンドもDockerイメージ化することができるから
goみたいにスタティックリンクされたバイナリが作れない言語で作ったアプリでも
Dockerだけが入ってるクリーンな環境で、いきなり実行することもできちゃうわけだ

465 ：login:Penguin：2018/10/26(金) 10:56:20.22 ID:S+WdRTJT.net

>>463
Dockerイメージを新しく（バージョンアップ）したから、
次からこれ使ってーって開発チームはインフラチームに依頼するだけでよくなる

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


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


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

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

本気でやれば、いろいろ解決するよ。ただそのためには
インフラチームに丸投げじゃだめだけどね

466 ：login:Penguin：2018/10/26(金) 11:34:43.60 ID:UuZWwwD+.net

>>465
ほんとベース理解できたら凄いわこれ
細かいホスト側？の設定はインフラに任せるとして
開発に影響のあるdockerfileの作り方も凝らなければストレートだね
これで環境周りのめんどくささからは解放される！

467 ：login:Penguin：2018/10/26(金) 13:18:37.63 ID:4wc3titV.net

chrootで仮想化するのを全自動で管理できるようにしたのがdocker、chroot以下構築のbashファイルに相当するのがDockerfile。
ツッコミどころ満載の説明だけど、概念はこれでおk.使い方はコマンド覚えろ。

468 ：login:Penguin：2018/10/27(土) 19:48:50.40 ID:5pOpML2z.net

は？

469 ：login:Penguin：2018/11/01(木) 11:02:05.82 ID:Ub4h8gMB.net

クソレスのせいで会話とまったな
466は反省しろよ

470 ：login:Penguin：2018/11/05(月) 05:00:26.04 ID:tQ7nIs7Z.net

シェルのコマンドで-pとか-vとか指定するのと
Dockerfileに書くのと
docker-compose.ymlに書くのと
どこにどうすればいいかがわからんわ

471 ：login:Penguin：2018/11/05(月) 08:23:33.46 ID:R14xwsxg.net

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"

472 ：login:Penguin：2018/11/05(月) 08:47:09.36 ID:Thuf2ewx.net

>>470
docker-compose.yamlはコマンドのオプションで指定するのと同じ

docker-composeコマンドというのはそもそも、
一つのコンテナだけ構成されたものを起動するならdocker runだけでいいけど、
複数のコンテナで構成するときに、docker runで適切なオプションつけて
複数起動するのが面倒って言うときに使うものだから、機能的にはdocker runと同等
run以外にbuildとかもできるけどね。


で、Dockerfileとdocker runの違いだが、Dockerfileはイメージの仕様として
ポートを公開しますよ、ボリュームを使用しますよって、明示するときに使う

docker runの方は公開されたポートをホスト上のどのポートに割り当てるのか
ボリュームをどこのディレクトリに割り当てるのか指定するのに使う

例えば、Dockerイメージとして構成されたものが、どんなポートを公開しているか？
っていうのはDockerfileを見ればわかるわけだ。

で、そのイメージを起動する場合、ポートを変更できる機能がなければ、
同一ホストで複数起動することができなくなるだろ？
実際にどのポートを使用するかは実行時にしか決められない。（ボリュームも同じ）

Dockerfileではそのイメージがどういうものかを書いて、
docker runはイメージを起動するときのオプションというわけ

473 ：login:Penguin：2018/11/05(月) 08:47:55.99 ID:Thuf2ewx.net

>>471
> Dockerコンテナってラベル付ける機能あったんだ
ずいぶんと前についた気がするが？

昔docker-composeはラベル使っていなかったが、
途中でラベル使うように変わったよな

474 ：login:Penguin：2018/11/07(水) 00:40:27.75 ID:JZV5z18S.net

たとえば、あるソースをコンパイルして、
systemctl start serviceができるようにするには、
どうやってコンテナ作りをすればいいんでしょう。

privilegeを与えて、yumで開発環境投入して、
systemctl がつかえるように、serviceファイル設置して、
systemctl enable serviceのあと、shutdown したのち、
docker image化してはダメなんでしょうか？？

475 ：login:Penguin：2018/11/07(水) 00:52:45.66 ID:v7o9U8jP.net

>>474
なんでソースのコンパイルなんて話が出てくるのかわからん

Dockerのコンテナはsystemctl start serviceから起動する必要はない
通常はDockerそのものがsystemctl start serviceで起動するようになってるから
Dockerでサービスが起動するコンテナを作ってあとはDockerに
OS起動時に、そのコンテナを起動してもらえばいいだけ

どうしても特定のDockerコンテナだけsystemdで制御したければ、
dockerコマンドを実行するserviceファイル書けばいいだけだが

> privilegeを与えて、yumで開発環境投入して、
？？？
意味がわからんが、Dockerの中に入って開発しようとしてないか？
systemctlコマンドを使うのは、もちろんDockerコンテナの外だよな？
通常はDockerコンテナの中で、systemdなんか使わないからな

Dockerの中に開発環境入れて、Dockerの中で開発なんてことはしねーからな
そういうのは仮想マシンとかシステムコンテナでやれ
Dockerのようなアプリケーションコンテナを仮想マシンとかして使うな。
無理やり使おうとしたその結果が、お前のその「どうやればわからない」という状況なんだからな

476 ：login:Penguin：2018/11/07(水) 00:57:39.50 ID:JZV5z18S.net

>>475
レスありがとうございます。

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

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

コンテナに入ってから、
コンパイルすることしか想像できない初心者です。

477 ：login:Penguin：2018/11/07(水) 01:11:12.42 ID:v7o9U8jP.net

>>476
Dockerfileを使ってビルドするんだよ

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

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

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

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

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


あとは、dockerコマンドやdocker-composeなどでこれらを起動すれば良い

478 ：login:Penguin：2018/11/07(水) 01:21:22.84 ID:v7o9U8jP.net

>>477で書いたように、単純な方法を取ると、
アプリを起動するのに必要ないビルドツールのせいで
イメージサイズが大きく膨れ上がる。

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

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

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

アプリを使うためには、アプリの実行ファイル（とランタイム環境）さえあればよいので、
ソースコードから実行ファイルを作る所までをビルド専用イメージで行う
そしてその実行ファイルをコピーして使う別のイメージ（ビルドツールなし）を作るという方法

479 ：login:Penguin：2018/11/07(水) 01:21:25.66 ID:JZV5z18S.net

>>477
丁寧なレスをいただき、感謝いたします。
ありがとうございます。しかし、疑問が／／／

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

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

どうしてわざわざ、Dockerイメージづくりを自動化しなければいけないのですか。
できたイメージはtarで持ち運ぶつもりでいます。

480 ：login:Penguin：2018/11/07(水) 01:25:02.67 ID:JZV5z18S.net

>>478
脹れ上がりですね。
＞ビルドが終わってから削除してもイメージサイズは減らない
知りませんでした。ありがとうございます。

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

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


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

ありがとうざいました。

481 ：login:Penguin：2018/11/07(水) 01:29:04.85 ID:v7o9U8jP.net

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

Dockerfileを手探りで書けばいいじゃん。

FOROM deban
COPY ソースコード
RUN yum install パッケージ
RUN ./configure
とか書いてビルドして、あれぇ？ビルドできないなぁとかなったら

FOROM deban
COPY ソースコード
RUN yum install パッケージ
RUN yum install 足りないパッケージ
RUN ./configure

とかしていくんだよ。そうすれば、RUN yum install パッケージが
終わった段階のキャッシュの続きから実行されるから、
手探りでやってるのと大差ない作業になる

最後にyumとかでまとめておしまい

482 ：login:Penguin：2018/11/07(水) 01:30:07.71 ID:v7o9U8jP.net

まあどうしてもわからないなら、コンテナに入りつつ
ビルドしていって試してもいいけど、最終的には
Dockerfileにビルドするためのコマンドを書く

483 ：login:Penguin：2018/11/07(水) 01:30:23.27 ID:JZV5z18S.net

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

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

とすると、privilegeとか、なにか別の特権を与えてコンテナを起動して、
仮想マシンみたいにコンテナを動かすしか手が見つからないんです。

484 ：login:Penguin：2018/11/07(水) 01:34:57.16 ID:JZV5z18S.net

>>481
＞そうすれば、RUN yum install パッケージが
＞終わった段階のキャッシュの続きから実行されるから、
＞手探りでやってるのと大差ない作業になる

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

最後にyumとかでまとめて御仕舞いというのは、
ワンライナーでかけるところはまとめて、dockerfileを作れということですね。

485 ：login:Penguin：2018/11/07(水) 01:36:09.53 ID:v7o9U8jP.net

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

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

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

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

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

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

486 ：login:Penguin：2018/11/07(水) 01:36:15.87 ID:JZV5z18S.net

>>482
ありがとうございます。

ずっと、どうしてコンテナに入って作業してはいけないのかが、
謎だったんですが、入って作業するのもアリなわけですね。
ホッとしました。

487 ：login:Penguin：2018/11/07(水) 01:40:32.26 ID:JZV5z18S.net

>>485
なるほど。

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

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

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

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


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

ボリューム（あるいはボリュームを用いたデータ専用コンテナ）を使えってことですね。

488 ：login:Penguin：2018/11/07(水) 01:43:35.19 ID:v7o9U8jP.net

>>483

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

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


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

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

アプリ開発者の場合はアプリを作る。アプリ開発者ならsystemd使わない起動方法だって知ってる。
むしろsystemd使うほうが面倒。どこにデータを保存するかもわかってる。
アプリはディストリが用意するパッケージには依存したくない。アプリを動かすのに必要なものは全部管理したい
だからDocker使ってイメージを作るんだよ。あとはインフラにこのイメージ起動してって
ぽんと渡すだけでよくなる。

489 ：login:Penguin：2018/11/07(水) 01:45:23.17 ID:v7o9U8jP.net

>>486
> ずっと、どうしてコンテナに入って作業してはいけないのかが、
> 謎だったんですが、入って作業するのもアリなわけですね。
> ホッとしました。

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

コンテナに入るのは調査するためだけ

490 ：login:Penguin：2018/11/07(水) 01:53:42.95 ID:JZV5z18S.net

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

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


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

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


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

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


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

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


丁寧にご指南いただき、本当にありがとございました。
とても勉強になりました！

491 ：login:Penguin：2018/11/07(水) 01:54:23.86 ID:JZV5z18S.net

>>489
よくわかります！

492 ：login:Penguin：2018/11/07(水) 01:56:23.49 ID:v7o9U8jP.net

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

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

アプリ開発者はすげーから、なんでも知ってるぜーって意味ではないので

493 ：login:Penguin：2018/11/07(水) 01:57:11.36 ID:v7o9U8jP.net

訂正（意味無ってなんだよ？）

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

494 ：login:Penguin：2018/11/07(水) 01:59:57.97 ID:JZV5z18S.net

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

あー、よかった、そうですか。
ちょっと大変そうだと心折れかかっていました。
自分で作るプログラムならよく把握できていますものね。

495 ：login:Penguin：2018/11/07(水) 02:08:54.57 ID:v7o9U8jP.net

MySQLとかデータを大切に扱う必要があるものは
どこにデータが保存されてるかとかもしっかり明記されてるから
（クラウド使えよって思うが）Docker化するのは比較的楽だけど

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

お前それ、信頼できるの？記事データはデータベースに保存されるから大丈夫みたいだが、
アップロードした画像とかデータベースサーバーじゃなくて
ディレクトリに保存されるじゃん？ ちゃんと共有ストレージ使うようなってんの？
管理画面からプラグインの導入できるけど、プラグインははデータディレクトリじゃない所に
保存されてるよね？そっちの対応は大丈夫？とか気になってしょうがない

496 ：login:Penguin：2018/11/07(水) 09:13:06.91 ID:MDpN/AEY.net

補足だけど、systemdはパソコンの起動時に自動的に起動させるのが主な役目だからDockerのコンテナでも
起動時に起動させるのにsystemdを使ってもいいんですよ。
そのためには起動コマンドを調べる必要があるってことです。*.serviceのファイルを作成するだけで
systemd管理はできますが、*.serviceには当然起動コマンドを書く必要があるので。

497 ：login:Penguin：2018/11/07(水) 11:48:41.20 ID:v7o9U8jP.net

>>496
今の話は、Dockerコンテナの中でsystemd使うなって話な

Dockerはそういう用途で使うためのもんじゃないから
そんな事をしようとすると、ハマるんだぞ
追加権限が必要なのが何よりの証拠

498 ：login:Penguin：2018/11/07(水) 12:15:05.51 ID:MDpN/AEY.net

>>497
あり、レス読み間違えてたわすまん。
Dockerで中身いじるとしたらgitで遠隔操作するか、DBの永続化ぐらいで対応するのが常套だけど、
コンテナ内ならsystemdじゃなくてSupervisorがdocker公式になかった？

499 ：login:Penguin：2018/11/08(木) 00:22:57.37 ID:Ueh2RoXc.net

LXC, LXD（Linux Containers）だと、コンテナ内に入って、
アプリのインストールなど、環境構築できる

AWS でも使っている

500 ：login:Penguin：2018/11/08(木) 03:09:23.40 ID:NV3KMhMa.net

>>499
Dockerと、Linux Containerとは、
何が大きく違いますか？
Dockerはネットワークやコンテナの管理が便利だけどなあ。

501 ：login:Penguin：2018/11/08(木) 03:11:15.01 ID:NV3KMhMa.net

>>499
DockerもLinux Containerも、共にLinuxの独立分離機能を用いていると言うし。

502 ：login:Penguin：2018/11/08(木) 03:29:19.31 ID:KwyGHPnO.net

使ってる機能が同じでも、目的のために最適化されたツールになってる
だから、なにが目的かを正しく理解する必要がある。

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

LXCやLXDだとそれをやるのはとても大変だろう？

503 ：login:Penguin：2018/11/08(木) 06:56:36.33 ID:8m7pC1YT.net

https://qiita.com/Surgo/items/709a07d68c6eafbad267

504 ：login:Penguin：2018/11/08(木) 08:04:08.58 ID:AYcFG6pB.net

ありがとうございます。

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

>>503
すみません参考になります。

505 ：login:Penguin：2018/11/08(木) 08:33:22.59 ID:KwyGHPnO.net

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

頑張ればできるんじゃね？
とてつもなく頑張ればｗ

506 ：login:Penguin：2018/11/08(木) 15:05:12.27 ID:Y2MwyzYh.net

18.09.0 が来た

507 ：login:Penguin：2018/11/08(木) 15:36:35.47 ID:rbD7hoQI.net

>>505
とてつもなく頑張ればｗ
条件付きだがライブマイグレーションできる>LXD

508 ：login:Penguin：2018/11/08(木) 18:42:28.72 ID:AYcFG6pB.net

>>507
マイグレーションが一番の魅力だから、
やっぱりDockerがいいなあ。

509 ：login:Penguin：2018/11/08(木) 21:55:42.35 ID:y26ltpJb.net

OpenVZでdocker動くかもと見たんだか、ほんと？

510 ：login:Penguin：2018/11/08(木) 22:37:13.81 ID:KwyGHPnO.net

Linuxカーネルに互換性があるなら動くんじゃないの？

511 ：login:Penguin：2018/11/09(金) 00:00:17.07 ID:0q/3jACl.net

6使ってたら2.6で当然動かないよ
見たことないけど7使ってるとこなら動くはず

512 ：login:Penguin：2018/11/09(金) 08:00:07.01 ID:XRMQbvdS.net

>>511
仮想マシンとは違うものね

513 ：login:Penguin：2018/11/10(土) 17:54:47.28 ID:ZYfU+HA8.net

7ですね
あまり需要ないかと思いますが、格安vpsで動くと嬉しい

514 ：login:Penguin：2018/11/10(土) 19:16:43.39 ID:2zo/Zkkd.net

格安VPSで7ってどこ？
普通に知りたい

515 ：login:Penguin：2018/11/11(日) 14:14:06.80 ID:6/dIT6k3.net

テケトーにググったら
>NTTPCコミュニケーションズ WebARENA VPSクラウド プラン10
ttps://web.arena.ne.jp/pdf/vpscloud_spec.pdf
コレでcentos7動いてるみたいだが
月額\360〜

516 ：login:Penguin：2018/11/11(日) 14:29:07.06 ID:r372XCNT.net

>>515
その表を見る限りCentOS7が動いてるのはKVMだけ見たいだしホストがRHEL6なOpenVZでもCentOS7は動くよ(kernelに実装されてない機能は使えないが

517 ：login:Penguin：2018/11/11(日) 14:34:03.19 ID:r372XCNT.net

最新の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

518 ：login:Penguin：2018/11/11(日) 19:52:17.92 ID:QlLSzGzd.net

KVMやXenはデバイスまで分離されてるからいいが、コンテナ環境を他人に貸すってすげぇな

519 ：login:Penguin：2018/11/12(月) 04:52:51.03 ID:i5PNL/7Q.net

>>518
共有サーバーだって貸していただろｗ

520 ：login:Penguin：2018/11/13(火) 00:31:59.15 ID:7b8arQTr.net

>>515
国内で360は安い、ありがとー

521 ：login:Penguin：2018/11/13(火) 23:30:40.07 ID:7+h48abB.net

>>520
安過ぎて、客が殺到して、
詰め詰めのサーバーのために性能が悪いとかないのかな？

522 ：login:Penguin：2018/11/14(水) 00:18:45.33 ID:f9otbk49.net

>>521
あるかもだけど、サービスの初期開発、プログラムの練習には持ってこいじゃないですか？
もしかして、time4vpsより安い？これ

523 ：login:Penguin：2018/11/14(水) 07:34:31.11 ID:hsvM7qsm.net

そういう用途ならvps使うよりクラウドのほうが安く抑えられると思うけど

524 ：login:Penguin：2018/11/14(水) 07:42:38.54 ID:Lj6Hvi7X.net

少し分かった
https://blog.arena.ne.jp/vps/891

525 ：login:Penguin：2018/11/14(水) 12:18:34.69 ID:fhtTOY8i.net

使う時だけ起動する感じなら、GoogleComputeEngineのプリエンプティブインスタンスが安く上がりそう

526 ：login:Penguin：2018/11/21(水) 00:13:59.09 ID:QNDci5dR.net

Docker上で仮想マシンを動かせるって本当？

527 ：login:Penguin：2018/11/21(水) 04:02:22.73 ID:GJ1WusOb.net

そりゃまあ仮想マシンなんてアプリに過ぎないので動くやろうな

528 ：login:Penguin：2018/11/22(木) 04:54:44.46 ID:Scei2IS6.net

>>527
動くやろうなじゃなくて、
これから主流になるらしいよ

529 ：login:Penguin：2018/11/22(木) 06:02:39.07 ID:3AQeAHWO.net

Dockerの上で仮想マシンとか
これもうわけわかんねえな

530 ：login:Penguin：2018/11/22(木) 10:20:20.53 ID:QKQbQ2kX.net

>>528
ならんよ。嘘ついてもバレる（嘲笑）

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

仮想マシンによって、仮想マシンの中のアプリと外のアプリの
連携が分断されるから、やる価値がない

531 ：login:Penguin：2018/11/23(金) 13:00:20.01 ID:76ZWcvaP.net

Dockerって、勝手にiptablesの設定を変更するのが気に入らない。
安易に使うとセキュリティーホールだらけになると思う。

532 ：login:Penguin：2018/11/23(金) 14:12:16.80 ID:AJrIkRMM.net

Xen+libvirtやLXCもiptablesの設定を勝手に変更するよ(deb系しか試してないけど)
でも合ってる設定だし、ポリシーがACCEPTのままなので自分でも設定しなればならないのに変わりがないから異論は無いけど

533 ：login:Penguin：2018/11/23(金) 14:33:29.51 ID:76ZWcvaP.net

>>532
レスありがとう。

どうせなら、docker runコマンドのポート解放のところで、
パス可能なソースIPでも指定できるようにすればいいのにと思う。

534 ：login:Penguin：2018/11/23(金) 15:44:21.35 ID:nUe3TP+/.net

>>533
それはファイアウォールの仕事
Dockerの仕事ではない

535 ：login:Penguin：2018/11/23(金) 22:17:06.85 ID:76ZWcvaP.net

>>534
だけど、ポートの解放はdocker runで行うよね

536 ：login:Penguin：2018/11/23(金) 22:31:08.18 ID:Oz3vE0x/.net

だけどやっぱりフィルタリングはDockerの仕事じゃないよね。

537 ：login:Penguin：2018/11/23(金) 23:09:43.20 ID:76ZWcvaP.net

>>536
せめて、デフォルトで外部から接続させないようにファイアホールを構成していればいいのにと思う。
ユーザーが必要に応じてフィルタリングルールを調整してはじめて、
外部からアクセスできるようにすればいいのにと思う。
フィルタリングが分かっている人が明示的にパスするようにするのがいい。

docker runでポート解放したら無条件でどこからでも通すなんて変だと思う。

538 ：login:Penguin：2018/11/24(土) 00:32:00.55 ID:6DgweZjB.net

>>537
Dockerは仮想マシンじゃないと何度言ったらわかるんだ？

Linuxでウェブサーバー起動したら、外部から接続できるのは
当たり前の話だろ

539 ：login:Penguin：2018/11/24(土) 05:41:46.81 ID:IIX6QWPN.net

>>531
＞Dockerって、勝手にiptablesの設定を変更するのが気に入らない。

オプション付けろよ

540 ：login:Penguin：2018/11/24(土) 06:20:40.88 ID:bwmQjudn.net

>>539
ん？どんなオプションだったっけ。
iptablesのNAT設定を変更しないやつってあるの？

541 ：login:Penguin：2018/11/24(土) 06:42:42.90 ID:6DgweZjB.net

>>540
サーバー系の設定したこと無いんか？

MySQLのbind-addressはなんのためにあるのか知らないのか？
127.0.0.1 と 0.0.0.0 の違いを言えるか？

542 ：login:Penguin：2018/11/24(土) 09:54:12.75 ID:bwmQjudn.net

>>541
コンテナをホストのプライベートIPに結合するやつかな？

543 ：login:Penguin：2018/11/24(土) 10:00:28.87 ID:6DgweZjB.net

>>542
Dockerはシステムコンテナじゃなくて
アプリケーションコンテナなんだから、

普通のアプリを起動したのと同じ挙動をするのが一番正しい姿なんだよ

544 ：login:Penguin：2018/11/25(日) 11:38:02.57 ID:RawJ9w06.net

やっとコンテナできた。疲れた。12時間ぶっとおし、徹夜した。

545 ：login:Penguin：2018/11/25(日) 13:33:06.09 ID:i2El4ps2.net

同じ挙動ってなんだ？
iptablesいじられるのは無しってこと?

546 ：login:Penguin：2018/11/25(日) 14:01:08.16 ID:9lJSkKkT.net

>>538
ネットワーク繋がなきゃつながらないのが当たり前だろｗ

>>543
「同じ挙動」がどういう挙動か言ってみろよ。　ポート競合するのが正しいと思ってんのか？

547 ：login:Penguin：2018/11/25(日) 16:47:54.23 ID:AAm1jywp.net

>>546
> ネットワーク繋がなきゃつながらないのが当たり前だろｗ
デフォルトだと、どのポートでも受け付けてないはずだが？

> 「同じ挙動」がどういう挙動か言ってみろよ。　ポート競合するのが正しいと思ってんのか？
同一マシンでポート80で起動するサービスが複数あったら競合するのが正しいですが？

548 ：login:Penguin：2018/11/25(日) 17:03:00.01 ID:sYWkBqhY.net

最近俺が見たのはこんな奴だった

公式ドキュメント読まない
ヘルプ読まない
ぐぐらない
ぐぐれない
とりあえずやってみない
手順に書いてあることをなぞるだけ
コンテナとVMの区別がつかない
Docker無しでLA(E)MP環境が建てらんない
iptablesを手動でいじれない

549 ：login:Penguin：2018/11/25(日) 17:19:54.21 ID:yqgxEHl5.net

どうやってDockerを知って、動かすことができたんだ？

550 ：login:Penguin：2018/11/25(日) 17:33:32.99 ID:HRiXHrNh.net

>手順に書いてあることをなぞるだけ

多分ハケンか何かの業務でとか…

551 ：login:Penguin：2018/11/28(水) 08:05:07.28 ID:YBsTKCUy.net

［速報］AWS、独自のセキュアなコンテナ実行用マイクロVM「Firecracker」、オープンソースで公開。AWS re:Invent 2018
https://www.publickey1.jp/blog/18/awsvmfirecrackeraws_reinvent_2018.html

552 ：login:Penguin：2018/11/28(水) 10:22:44.67 ID:yT+2b7xe.net

>>551
なにがすごいのか？

553 ：login:Penguin：2018/11/28(水) 15:28:42.96 ID:7rRS23JC.net

>>552
コンテナがrootkitなウイルスにやられても
他のコンテナに侵入できない
なのに仮想マシンより軽量

普通のコンテナはroot取れば脱出出来る可能性はある
仮想マシンの脱出はそれよりは困難

554 ：login:Penguin：2018/11/28(水) 16:22:47.55 ID:LPYNLhdF.net

これぐらいなら馬鹿は出てこないと思って放置していたが
ほんとなんにでもくだらないレスするやつ来るな
まじでやってるなら本当の馬鹿だな

555 ：login:Penguin：2018/11/28(水) 16:37:46.37 ID:h8Zt5+LC.net

>>551
とりまビルドしてみたらサクっと通った
今時のツールはdockerでビルドなんだな…時代が進んで色々凄いコトになってる
つか使い方がよく分からんがｗ

556 ：login:Penguin：2018/11/28(水) 16:42:44.50 ID:/w7pvHqb.net

>>555
Dockerねぇぞって弾かれるよなワロタ
大容量のダウソ始まったからビルドやめたわ

557 ：login:Penguin：2018/11/29(木) 14:41:36.81 ID:nYOTnVc6.net

>>553
それはいいですね。
ハニーポットも運用できる？

558 ：login:Penguin：2018/11/30(金) 16:24:21.34 ID:wtQkclkF.net

>>556
つか何をするにもひたすらDLやでｗ

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

559 ：login:Penguin：2018/11/30(金) 16:31:31.23 ID:wtQkclkF.net

kernelは4.19

560 ：login:Penguin：2018/11/30(金) 16:45:28.65 ID:wtQkclkF.net

releaseからバイナリ落としてもダメなんで今回は諦めるワ
コッチはローカルビルドと違ったメッセージ出てたんでイケそうだったんだが
腐ってやがる早すぎたんだ

HTTP/1.1 204 No Content
Date: Fri, 30 Nov 2018 07:45:56 GMT

561 ：login:Penguin：2018/11/30(金) 19:18:46.43 ID:wtQkclkF.net

つか尼損犬糞でしか動きま千円って書いとけやヴォケ害人どもガイジか？
>Linux 4.14+
>KVM

動作環境とは何の関係もありませんが何か？ｗ

562 ：login:Penguin：2018/11/30(金) 23:24:39.25 ID:/aBXqI4i.net

いまKVMでDocker動くようになったん？

563 ：login:Penguin：2018/11/30(金) 23:54:35.49 ID:49XVRgzf.net

>>562
今KVM上でDockerホスト運用しているけど。
両方CentOS7でね。

564 ：login:Penguin：2018/12/01(土) 01:27:09.66 ID:8oh/wD5x.net

DockerはKVMなどの仮想マシンと組み合わせて
使うのが想定される使い方なんだから最初から動いて当然

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

Dockerコンテナ（＝アプリ）にカーネル以外の動作に必要なものが
全てまとまっており、ディストリ自体にパッケージが不要になることで
実現できる設計

565 ：login:Penguin：2018/12/01(土) 11:51:45.49 ID:KGwrmve6.net

>>564
なるほど。
そのうちDockerホスト専用のディス鳥がでるかもね

566 ：login:Penguin：2018/12/01(土) 12:24:30.22 ID:5wSHzPIO.net

そんなもんとっくの昔からあるよ
で最近になってKVMの上でコンテナ動かすのがバズってきたのは、AWSがコンテナ専用の "KVMホスト" OSをリリースしたことに端を発している
これは小数の大きな仮想マシンでクラスタを組んでその上で沢山のコンテナを動かすという従来のやり方とは考え方が大きく違っていて、
コンテナの数だけKVM上で軽量なVMを立ち上げてその中でコンテナを隔離して動かすの
でコンテナは本当に単なるパッケージ化技術と成り下がる
コンテナによる分離はセキュリティ面でガバガバであり使い物にならない玩具である、というのがITビジネス界の結論というわけ

567 ：login:Penguin：2018/12/01(土) 12:47:23.68 ID:8oh/wD5x.net

> というのがITビジネス界の結論というわけ

という結論を語ってる所はITビジネス界には無いんで
安心して、生暖かく見てやってくださいｗ

568 ：login:Penguin：2018/12/01(土) 12:52:02.59 ID:M+reOwB1.net

コンテナごとにセキュリティソフト入れてますます重くなる未来

569 ：login:Penguin：2018/12/01(土) 13:08:15.41 ID:8oh/wD5x.net

そういや仮想マシンごとにセキュリティソフト買ってるらしいな

570 ：login:Penguin：2018/12/01(土) 13:28:23.82 ID:5wSHzPIO.net

パッケージソフトをウッキウキでクラウドで動かそうとしたら、
ライセンスがコピー単位でオンプレと何ら変わらない運用をするしかないというのはよくある話

571 ：login:Penguin：2018/12/01(土) 13:55:02.53 ID:dMaA0+/B.net

だからソフトウェア自体を売るんじゃなくて
クラウドサービスとして売る方向になってるのでは？

572 ：login:Penguin：2018/12/01(土) 13:57:46.54 ID:8oh/wD5x.net

そしてそれにはコンテナが適してるわけだよね

573 ：login:Penguin：2018/12/01(土) 18:48:38.56 ID:KGwrmve6.net

>>566
>パッケージ化技術と成り下がる

いいたい事はわかるが、成り下がってはないと思う。

574 ：login:Penguin：2018/12/01(土) 18:50:29.39 ID:KGwrmve6.net

>>571
自分で構築、保守してこそのコンテナの有難味だと思う

575 ：login:Penguin：2018/12/02(日) 17:00:47.15 ID:U/VULGsP.net

だからDockerはアプリ開発者が
自分のアプリを配布するのに使うものなんだよ

アプリ開発してないやつにとっては豚に真珠

576 ：login:Penguin：2018/12/02(日) 17:30:21.64 ID:MF2FYgWw.net

>>575
えー俺にも技術分けて下さいよ
dockerでドヤ顔したい

577 ：login:Penguin：2018/12/02(日) 17:49:48.80 ID:6ZB8i84m.net

仮想化環境であるが、仮想マシンではない。
仮想化環境であるが、アプリではない。
dockerはコンテナ型の仮想化環境を作成するソフトです。
それ以上でもそれ以下でもないだろ。

578 ：login:Penguin：2018/12/02(日) 21:03:03.94 ID:4PfKxqKJ.net

>>577
アプリの組み合わせ（=環境）をコンテナにまとめるのもありですよね
その場合、127.0.0.1で内部でアプリを連携させるのも良いですよね。

579 ：login:Penguin：2018/12/02(日) 23:08:22.72 ID:6ZB8i84m.net

>>578
そうそう、VMみたいにして使うときは目的に合わせてカスタムすればいい。
目的を定めて既存のサービスに組み合わせてdockerファイルを書く。
例えば開発環境にするなら同期をとファイル群をローカルネットワークのgitにするとかね。
dockerはクラウドと連携すると割と柔軟に何でもできる。
環境依存のファイルをクラウドに置いておく発想で。

580 ：login:Penguin：2018/12/02(日) 23:27:57.41 ID:uZcYlCvj.net

dockerは本来はアイソレーションやシステムリソース有効活用も担ってたはずでしょ
例のFirecracker的な思想だとそこはコンテナから切り離そうってことだよね
ここまでくると仮想化環境というより単なるポータブルなVMのディスクイメージと考えたほうが素直だと思うわ

581 ：login:Penguin：2018/12/02(日) 23:35:52.62 ID:6ZB8i84m.net

>>580
いや、環境だよ。どのPCでも同じ環境を再現できるってこと。javaの発想に近い。
静的なファイルだけ突っ込むってとこはいい理解だけど、それが環境なんだよ。

582 ：login:Penguin：2018/12/03(月) 01:21:03.69 ID:Yzd5rcYM.net

dockerfileって環境構築用のバッチファイルみたいなものだと理解しても良い？

コンテナのコンソールを使って順に環境構築したものをコミットしてイメージ作る場合と比べてどんなメリットがあるかな。
仕上がりのイメージファイルの容量が少なくなったりする？

583 ：login:Penguin：2018/12/03(月) 01:24:29.67 ID:tyMBE38T.net

>>582
chrootに依存してるって意味なら同じだろうけど、ディストリのパッケージに依存してるからそれが違うかな。
コマンド手打ちでも構築できるけど、不便だろ。

584 ：login:Penguin：2018/12/03(月) 08:42:16.28 ID:JGjM/vH1.net

マイクロVMが主流になるならもうコンテナいらなくね？
カーネルだけホストのものを使うことって無駄な環境依存を増やしてるだけで、従来のコンテナ技術との互換性以外にはもはやメリットがないような
環境依存部分を吸収するのはそれこそ本質的にはハイパーバイザー型仮想化の方が遥かに得意なわけだし

585 ：login:Penguin：2018/12/03(月) 10:23:09.87 ID:aEVyNKj/.net

そういうの解決するために各企業が新しいコンテナ技術生み出してる
gvisorみたいにコンテナとVMの中間みたいな物とかね

586 ：login:Penguin：2018/12/03(月) 10:34:42.23 ID:fAbMU4i+.net

KataContainersもgvisorと似たような思想だな
やり方はだいぶ違うみたいだが

587 ：login:Penguin：2018/12/03(月) 13:07:27.92 ID:gIBU2CPq.net

コンテナ型仮想化は初詮は捻じ曲がった過渡期のワークアラウンドだったってことだな
VMが重いのが問題なら軽くすればよい、それができないのは技術が未熟だっただけ
浸透し切る前に正しい方向に戻ってくれそうでよかった

588 ：login:Penguin：2018/12/03(月) 14:55:45.66 ID:Yzd5rcYM.net

>>583
dockerfile作る時も手打では？
しかもレスポンスが直ちに得られないので、
試行錯誤に時間がかかりそうに思う。

いまば、プログラム買いてその場で実行できるBASICインタプリタと、
cコンパイラを通す必要のあるC言語みたいな違いがあると思うんだけど。
一度完璧に書いてしまえば、後者の方がいいに決まっているけどね。

589 ：login:Penguin：2018/12/03(月) 14:57:12.63 ID:Yzd5rcYM.net

>>584
各VMごとにOSレベルのメモリ割り当てがいるから、
大量のメモリを消費するのでは？

590 ：login:Penguin：2018/12/03(月) 15:10:08.50 ID:3GtjRSNh.net

コンテナを動かすためのサーバーを管理したくないけど
AWS Fargateはまだまだ高い

591 ：login:Penguin：2018/12/03(月) 15:33:23.06 ID:zLBh6ucn.net

Lambdaで無理やりやるとか
つか安ければイイならSpotFleet以外の選択肢が（ｒｙ

592 ：login:Penguin：2018/12/03(月) 15:49:40.97 ID:ZaL3qC8p.net

Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある

593 ：login:Penguin：2018/12/03(月) 19:18:38.19 ID:zLBh6ucn.net

CRIだよね？>ORI

594 ：login:Penguin：2018/12/03(月) 20:16:02.49 ID:FS5rZSi9.net

>>589
firecrackerの場合1VMあたり5MBらしい。

595 ：login:Penguin：2018/12/03(月) 20:32:01.47 ID:tyMBE38T.net

>>588
あー、そういう見方あるか。chroot手打ちしなくていいってことだよ。
言いたいことはjvmとlinuxカーネルが実行環境に含まれてるってことよ。
linux環境じゃなくてもdockerは公式環境があるから。

596 ：login:Penguin：2018/12/03(月) 22:26:31.99 ID:n05/OnLG.net

>>592
やっとdocker-composeわかりかけて
きたとこなのに(>_<)

597 ：login:Penguin：2018/12/03(月) 23:40:38.53 ID:fVhmASLK.net

>>596
いやいや、docker理解できないと使えないから安心して
そもそも、個人開発でkuburnetes必要なくない？

598 ：login:Penguin：2018/12/03(月) 23:52:43.40 ID:fSc1+0qL.net

なんで個人開発限定？
そもそも個人開発でdockerなんか何に使うの？
コンテナ仮想化って個別にインフラを面倒見れないほどアプリがポコポコ作られるような組織で使うもんだろ
PaaSへのデプロイに使うくらいか？

599 ：login:Penguin：2018/12/04(火) 00:19:15.25 ID:ZNa428EC.net

>>592
> Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある

KubernetsってDockerを使うんだけど、なんで役割終えたの？

600 ：login:Penguin：2018/12/04(火) 00:22:17.42 ID:ZNa428EC.net

>584
> マイクロVMが主流になるならもうコンテナいらなくね？

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

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

コンテナは仮想マシンと組みあわせて使うということが全くわかってない
コンテナがあるからこそ、VMはマイクロで十分になったというのに
コンテナのおかげやで？マイクロVMが登場したのは

601 ：login:Penguin：2018/12/04(火) 00:26:56.99 ID:ZNa428EC.net

>>582
> コンテナのコンソールを使って順に環境構築したものをコミットしてイメージ作る場合と比べてどんなメリットがあるかな。

依存パッケージの更新とか手動でやりたくなくないだろ
お前は旧式のやり方しかしてないかもしれんがな、
こちとらDockerfileで1日に何度もイメージをビルドしてるんや
アプリが更新するたびにイメージ作り直してるし
カーネルや依存パッケージにセキュリティ対応が入ったら、
それを取り入れてまたアプリのイメージを作り直すんだよ

602 ：login:Penguin：2018/12/04(火) 00:32:34.85 ID:ZNa428EC.net

>>587
> コンテナ型仮想化は初詮は捻じ曲がった過渡期のワークアラウンドだったってことだな

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

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

それわかってるのか？

603 ：login:Penguin：2018/12/04(火) 00:35:04.84 ID:GLtMD4eM.net

>>600
君こそコンテナ仮想化とパッケージとしてのコンテナを混同してない？
>>584は前者のことを言っていて、従来のLinuxカーネルを共有したハック(現在一般的にコンテナ仮想化と呼ばれるもの)がもはや役割を終えつつあるのは事実だ
一方でパッケージとしてのコンテナはもちろん必要だけど、それ自体はもはや仮想化技術でも何でもなく、文字通り単なるアーカイブだ

604 ：login:Penguin：2018/12/04(火) 00:36:34.96 ID:ZNa428EC.net

>>603
> それ自体はもはや仮想化技術でも何でもなく

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

それをお前が言えば、お前が間違ってることがはっきりするよ

605 ：login:Penguin：2018/12/04(火) 00:38:18.61 ID:ZNa428EC.net

「仮想化」という言葉の正しい意味をわかってないやつは、
仮想メモリと聞くと、ソフトウェアでメモリを作ることだって勘違いするからな
>>603はそのパターン

606 ：login:Penguin：2018/12/04(火) 00:41:39.09 ID:ZNa428EC.net

パッケージとしてのコンテナとか意味不明だし
仮想化しなければ、可搬性は実現できないだろうが
仮想化せずにどうやって、他のマシンで動かすことができるというのか

っていっても理解できないんだろうなw

607 ：login:Penguin：2018/12/04(火) 00:56:48.20 ID:ZNa428EC.net

>>584
> マイクロVMが主流になるならもうコンテナいらなくね？

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

コンテナ使わないでどうやってサービス動かす気？
苦労する気？

608 ：login:Penguin：2018/12/04(火) 01:06:48.04 ID:GLtMD4eM.net

だからパッケージングとしてのコンテナを否定してるわけじゃないんだけど、そんなに難しいこと言ってるかなあ
少なくともマイクロVMでコンテナを実行するのは従来の定義上はコンテナ仮想化とは呼べないでしょ
そして、せっかくマイクロVMによって遥かに高度な仮想化が実現可能になったのに、
依然としてホストのカーネルを使っていたのでは可搬性はdockerと同程度の低い水準のままだ
従来のコンテナ仮想化の仕組みを大きく見直す時期に来てるんだよ

609 ：login:Penguin：2018/12/04(火) 02:12:00.01 ID:HWYOaTBW.net

>>600
マイクロVMって普通の仮想マシンとどう違うの？
>>594
OSは入れなくていいのか？

610 ：login:Penguin：2018/12/04(火) 06:51:27.56 ID:ZNa428EC.net

>>608
> 少なくともマイクロVMでコンテナを実行するのは従来の定義上はコンテナ仮想化とは呼べないでしょ
呼べるんだけど？

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

仮想化しなかったら、その仮想マシンでしか動かないものになるんだけど？
やっぱり仮想化の意味を知らないようだね

611 ：login:Penguin：2018/12/04(火) 06:57:34.00 ID:ZNa428EC.net

>>609
> http://www.atmarkit.co.jp/ait/articles/1811/27/news146.html
ここに簡潔に書いてある

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


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

コンテナを動かすことしかしないのだから、
マイクロVMに（コンテナ以外）のものを入れる必要がない
逆に言えば、コンテナ以外を動かすのは不可能に近い。

612 ：login:Penguin：2018/12/04(火) 07:01:33.17 ID:ZNa428EC.net

>>608
> そして、せっかくマイクロVMによって遥かに高度な仮想化が実現可能になったのに、
> 依然としてホストのカーネルを使っていたのでは可搬性はdockerと同程度の低い水準のままだ

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

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

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

ホストのカーネルってなんだよ？

613 ：login:Penguin：2018/12/04(火) 07:07:21.45 ID:ZNa428EC.net

マイクロVMは可搬性が高いわけじゃない
これは単なるディストリの過ぎないんだから

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

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

マイクロVMで動かす時は、ポート番号を変更したり、
CPUの割り当て数を変更したりできる
"コンテナをそのまま変更せずに"
これができるのは、"仮想化されている"から

614 ：login:Penguin：2018/12/04(火) 07:18:25.60 ID:ZNa428EC.net

>>608は仮想化をプロセス分離の技術の名前だとでも思っているかのようだw

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

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

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

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

UbuntuでもマイクロVMでもCentOSでも同じLinuxであれば
どこでも同じように動かせるようにするアプリケーション実行環境の仮想化は
コンテナが提供している。このアプリケーションの仮想化がなければ
ディストリごとに専用に、セットアップ手順を書かないといけない、
aptを使ったりyumを使ったり。コンテナでアプリケーション実行環境の仮想化を手に入れたことで
Dockerを使うだけで簡単にコンテナを動かせるようになった。
そうすることで、ディストリ専用（例マイクロVM専用）のセットアップ手順を
作らなくて良くなったからこそ、マイクロVMという軽量のディストリができたんだよ

615 ：login:Penguin：2018/12/04(火) 07:24:02.44 ID:CnqUMfCF.net

>>599
KubernetsでDockerは使えるけど必須ではなくなったからな
将来的には使われなくなるでしょ

616 ：login:Penguin：2018/12/04(火) 08:08:38.84 ID:uhjJ5Me8.net

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

617 ：login:Penguin：2018/12/04(火) 08:43:23.80 ID:N+FrKnXk.net

>>616
マイクロVMが一般的になれば次第にカーネルはコンテナ側に寄っていく形になるよ
VMベースの仮想化に移行すれば、特殊なバージョンのカーネルやLinux以外のコンテナを動かそうという試みはビジネスの要請によって確実に出てくる
ちょうど言語処理系が辿った道と同じで、最初は完全にホスト側によって使用するランタイムが決められていたのが
アプリ側の設定ファイルに基いてランタイムを選択するようになり、最終的にはアプリケーションに吸収される

618 ：login:Penguin：2018/12/04(火) 09:23:15.31 ID:ZrKf0azW.net

そんな銀の弾丸があるなら
もっとAWS Fargateを安くしろや！

619 ：login:Penguin：2018/12/04(火) 11:01:16.91 ID:vxBcBg/P.net

めんどくさいから結論が出て使いやすいソリューションが出てきたらでいいや

620 ：login:Penguin：2018/12/04(火) 12:30:26.40 ID:CvuFkzaO.net

まーたいつものガイジ2匹がレスバ繰り返してたのかよ
よく飽きねぇなぁ

621 ：login:Penguin：2018/12/04(火) 16:39:04.08 ID:ZNa428EC.net

>>615
知ってる知ってる。rktとかいうやつな
あれどうなったんだ？w

結局、Docker以外も使えると言う状況に満足して
終わりなんだよ。本気出してないからDocker以外普及しない

622 ：login:Penguin：2018/12/04(火) 16:40:44.20 ID:ZNa428EC.net

>>616

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

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

だからマイクロVMがコンテナになることはありえない。
マイクロVMはコンテナを使うという前提

623 ：login:Penguin：2018/12/04(火) 16:53:36.87 ID:ZNa428EC.net

>>617って結局コンテナを使いますって言ってるだけだよ。
マイクロVM関係ない。だってマイクロじゃないVMでもできることなんだから
マイクロVMは単に今のVMを置き換えるもので軽いってだけでしかない。

それ以外は今と全く変わないわけだから、コンテナ使いますよねって話

624 ：login:Penguin：2018/12/04(火) 16:59:38.16 ID:Yd5Bzjb0.net

「Kubernetes」に深刻な脆弱性
https://japan.zdnet.com/article/35129584/
> この脆弱性は深刻なものであり、共通脆弱性評価システム（CVSS）による深刻度は9.8（最大値は10.0）となっている。

625 ：login:Penguin：2018/12/04(火) 19:13:19.70 ID:ZpO6Qfl5.net

dockerの特色はリソースを節約しつつ環境を切り分けて管理しやすくするってことだから
docker動かすだけの鯖やVMならカーネルだけ乗っててdockerの依存関係だけインスコできるパッケージがあればいいって発想から
ディストリとかvmも小さいものや、専用のものを使いましょうってだけの話だろ。
リソースを気にしなくてすむのなら普通のlinux鯖で動かせばいい。

626 ：login:Penguin：2018/12/04(火) 21:18:35.08 ID:xoni3AYF.net

>>621
rktは違うわ

627 ：login:Penguin：2018/12/05(水) 11:56:39.53 ID:MMUcdQBe.net

>>625
それな。WinnyとかP2P世代のバカは仮想マシンを
「ウイルスに感染しても安全」な技術だと思ってる。（もちろん間違い）
ここで仮想化をセキュリティのためのものと思ってる奴がそうだろう

仮想マシン（VM）と仮想化は別のもの
仮想マシンは"ハードウェアを"仮想化したもの
コンテナはハードウェアを仮想化してないので、明らかに違うものを仮想化してるんだが
仮想マシンで仮想化してるから、コンテナで仮想化する意味がないという理屈のようだ

628 ：login:Penguin：2018/12/05(水) 13:31:31.41 ID:Z6qmzPvB.net

マルチテナントを考慮せよ
やり直し

629 ：login:Penguin：2018/12/05(水) 13:49:10.40 ID:p9AkVBP+.net

>>627
お前も、Docker世代のバカと呼ばれるんだろうな

630 ：login:Penguin：2018/12/05(水) 13:56:57.76 ID:Uz1/zr33.net

>>627
さすがに頭悪すぎ
どんなハッカーやウィルスをもってしても、VM内から同一ホスト上の別の客のVMに正当な方法を介さずにアクセスできてはならない
これがAWSが仮想化技術に対して要求する最低限のセキュリティだよ
クラウドベンダー各社がDockerをサポートし始めてもなかなかFargateのようなサーバーレスサービスが出なかった理由もそこにある
つまり、Dockerだけでは従来のハイパーバイザー型仮想化と同等の分離水準を実現できなかったんだよ
FaaSやCaaSの先駆者であるAWSがマイクロVMを必要としたのはそういう背景がある

631 ：login:Penguin：2018/12/05(水) 14:36:07.36 ID:t6HAOGba.net

>どんなハッカーやウィルスをもってしても、VM内から同一ホスト上の別の客のVMに正当な方法を介さずにアクセスできてはならない
こういうのまるっとガン無視して犬糞の鳥間バージョン間各種パッチ適用ごとの糞そのものの互換性のなさを
思考停止してとりまお気楽極楽に乗り越えて便利に使いましょいっていうのがドッカー（）だと思ってたんだがｗ

632 ：login:Penguin：2018/12/05(水) 14:37:16.80 ID:t6HAOGba.net

>FaaSやCaaSの先駆者であるAWSがマイクロVMを必要
どこまでいっても業者のツゴーってコトだよなｗｗｗ

633 ：login:Penguin：2018/12/05(水) 15:10:55.91 ID:Uz1/zr33.net

>>632
企業内の専有クラスタでもコンテナが乗っ取られたときの影響範囲とか部門間のアクセス制御とかあるからね
ｳｪｰｲwww系Webからビジネスへと足を踏み入れた途端に、Docker世代のバカには想像もできない複雑で広大な世界が広がっている

634 ：login:Penguin：2018/12/05(水) 16:13:21.16 ID:MMUcdQBe.net

頭の悪さは

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

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

Dockerはもともとハイパーバイザー型仮想化と同等の分離水準を
実現するためのものではない。それがわかってないと自白したようなもんだ

635 ：login:Penguin：2018/12/05(水) 16:15:40.45 ID:MMUcdQBe.net

それからもう一つ言うと、コンテナ間の分離機能というのは
カーネルが搭載しているコンテナの機能を使ってるだけなので
Dockerの問題じゃないんだわ。カーネルの問題

636 ：login:Penguin：2018/12/05(水) 16:17:51.91 ID:MMUcdQBe.net

最初から俺が言ってるように「Dockerは仮想マシンと組み合わせて使うもの」
なんだから、そういう分離は仮想マシンでやるからいいんだよ。

DockerはDockerの本質であるアプリケーション実行環境の仮想化に
特化すれば良い。こればかりは仮想マシンでは実現できないんだから。

637 ：login:Penguin：2018/12/05(水) 16:19:30.90 ID:MMUcdQBe.net

結局いつもの、Dockerを理解してない or 仮想マシンの代わりだと思ってる
理解の浅いやつが叫んでるだけでしたね。

638 ：login:Penguin：2018/12/05(水) 16:23:38.48 ID:t6HAOGba.net

>>633
solarisはdockerやるって言ってたけど今のところ見送りだからな
流石に長くOSやってるトコロはセキュリティに関する意識が全然違う
>>634
>Dockerはもともとハイパーバイザー型仮想化と同等の分離水準を
>実現するためのものではない。
ありとあらゆるトコロに地雷のように埋まってる腐れOSSの非互換性を解決するための
単なるお遊びレベルのコンテナシェア取り合戦なんだよなｗ
分かる分かるｗｗ
>>635
>カーネルが搭載しているコンテナの機能を使ってるだけなので
>Dockerの問題じゃないんだわ。カーネルの問題

いやいやいや下のレイヤに何を選ぶかはドッカ〜の実装の問題だろｗ
カーネルの責任に転嫁するのはさすがに無責任極まりないｗｗｗ
まぁOSS界隈のやり取りらしくて大変結構なんだがｗｗｗ

639 ：login:Penguin：2018/12/05(水) 16:26:06.60 ID:MMUcdQBe.net

>>638
だから下のレイヤー（コンテナ機能）に問題があるってことですよねw

640 ：login:Penguin：2018/12/05(水) 16:28:42.27 ID:MMUcdQBe.net

Linuxカーネル標準のコンテナ機能以外に
コンテナってありましたっけ？
それともDockerが選んだLinuxに問題があると言いたいのかな？w

641 ：login:Penguin：2018/12/05(水) 16:30:34.29 ID:MMUcdQBe.net

Solarisはもう未来ないから・・・

米オラクルがSolaris関連の従業員をほぼ全員レイオフしたとの報道（追記あり）
https://www.publickey1.jp/blog/17/solaris.html

642 ：login:Penguin：2018/12/05(水) 16:34:31.77 ID:t6HAOGba.net

>>639
分離したいなら仮想マシン使えは現状そうするしかないんだが
>FaaSやCaaSの先駆者であるAWSがマイクロVMを必要としたのはそういう背景がある
何度も言うように業者のツゴーでそう言ってるバヤイじゃないってコトだろ
課金も絡むだろうからクラウド（）に縛られてる情弱貧乏ユーザーどもにとっても死活問題だろうし
>>639>>640
>Dockerが選んだLinuxに問題があると言いたいのかな
問題アリアリだからドッカ〜が必要になったんだろｗｗｗ
つかソコをトボケてどうしたいのさ
犬糞ageっすか？ｗ

643 ：login:Penguin：2018/12/05(水) 16:36:34.75 ID:t6HAOGba.net

>>641
安価なゴミ産廃で置き換えられていくのがITの歴史そのものだからやむを得んだろうな
まぁ今でもボラクルだけではなく不治痛からも買えるのでレガシーユーザーは困らん>solaris

644 ：login:Penguin：2018/12/05(水) 16:42:04.53 ID:t6HAOGba.net

つかドッカーのコンテナランタイムってドッカーさんちの自作ちゃうの？

645 ：login:Penguin：2018/12/05(水) 16:53:03.46 ID:MMUcdQBe.net

>>642
だからさ、なんで分離するとか言う話してんの？

Dockerは分離するためのものじゃないんだが？
やっぱりわかってないよね

646 ：login:Penguin：2018/12/05(水) 16:53:44.57 ID:MMUcdQBe.net

>>642
> 問題アリアリだからドッカ〜が必要になったんだろｗｗｗ

違うよ？ やっぱりわかってないね。お前の書き込みが証拠だよ。

647 ：login:Penguin：2018/12/05(水) 17:01:10.40 ID:MMUcdQBe.net

仮想マシンとか分離の話なんか一言も出てこないからさw

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

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

　アプリケーションをコンテナ化する価値として岡下氏は、アプリのデプロイと
運用に統一手法がとれ、シンプルにできることを挙げた。

648 ：login:Penguin：2018/12/05(水) 17:04:35.60 ID:MMUcdQBe.net

>>643
> 安価なゴミ産廃で置き換えられていくのがITの歴史そのものだからやむを得んだろうな

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

えぇ、お前の理屈だとそうなるって話です。

649 ：login:Penguin：2018/12/05(水) 18:03:44.43 ID:MMUcdQBe.net

>>644を読む限りコンテナランタイムの機能もどうせわかってないんだろうな
プロセスの分離とかをしてるのはコンテナランタイムではない
カーネルの機能を呼び出しているだけ

650 ：login:Penguin：2018/12/05(水) 18:57:50.08 ID:t6HAOGba.net

>>645
だから業者のツゴーだって言ってるじゃん
客がソレに全力で振り回されてる状況なんだが
まぁ尼損は今のところ王様の商売やってんなとは思うね
>>646
少なくとも数ある商用UNIXにはドッカーみたいなゴミはどこにも存在しない
犬糞のお陰で今までなかった問題が発生したのでそれを解決するやむを得ない戯術偽術の類だよ
>>648
>その理屈で言うとSolarisもその「安価なゴミ産廃」として
>作られたものですからねw
そらそうよｗ
ただ犬糞よりは断然筋がイイ
出自を見れば分かるだろ
>>645
>プロセスの分離とかをしてるのはコンテナランタイムではない
そりゃそーだろ
つかドッカーで全部のプロセスがルート扱いで動いちゃってるのはカーネルの責任！とかいう言い分かよｗ

651 ：login:Penguin：2018/12/05(水) 19:25:01.48 ID:MMUcdQBe.net

> つかドッカーで全部のプロセスがルート扱いで動いちゃってるのはカーネルの責任！とかいう言い分かよｗ

普通に実行ユーザーを指定すればそのユーザーでコンテナが動作しますが？

652 ：login:Penguin：2018/12/05(水) 19:28:12.86 ID:t6HAOGba.net

どーせソコまで安全側に倒しておかずに動かすこと優先でやってんだろ
ルートでは動かないように小細工されてるツールだけやむを得ず一般ユーザーで動かすとかさぁ
動いたらハイ！終わり！ｗ
コレが一般的なデブオプス（）のスタイルだろ

653 ：login:Penguin：2018/12/05(水) 19:28:24.14 ID:MMUcdQBe.net

>>650
> そらそうよｗ
> ただ犬糞よりは断然筋がイイ

Solarisはクソでした。あなたの理屈通りでした。
でもあんたの理屈は、あんたには適用されるが、
俺には適用されない。LinuxよりもSolarisはクソ

654 ：login:Penguin：2018/12/05(水) 19:29:34.90 ID:MMUcdQBe.net

>>650
> だから業者のツゴーだって言ってるじゃん
> 客がソレに全力で振り回されてる状況なんだが

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

Solarisの先行きが不安定なのに焦ってるのか？

655 ：login:Penguin：2018/12/05(水) 19:30:17.66 ID:t6HAOGba.net

>LinuxよりもSolarisはクソ
まぁその気持ちも分からんではないね
初心者ほどとっつきやすいモノがよく見える
デパートで売ってる服よかユニクロの服の方が好きなタイプだろ？ｗ

656 ：login:Penguin：2018/12/05(水) 19:30:31.18 ID:MMUcdQBe.net

>>652
お前が適当な知識でやってるから、
それしかできないと思ってるのでは？w

657 ：login:Penguin：2018/12/05(水) 19:31:40.16 ID:MMUcdQBe.net

>>655
いいものが好きなんでLinuxが好きなんですよ。それだけです。
言われてみれば服もブランドに限らずいいものが好きだし、それと同じなんだろうな。

658 ：login:Penguin：2018/12/05(水) 19:31:53.18 ID:t6HAOGba.net

>>654
>Solarisの先行きが不安定なのに焦ってるのか？
ソコも業者のツゴーゆえ割り切らざるを得ない
筋の悪いドッカーも犬糞とクラウド延命のための一環だ
精々頑張ってくれｗ

659 ：login:Penguin：2018/12/05(水) 19:33:26.29 ID:MMUcdQBe.net

Solarisでびっくりしたのがようやく11になってから
ksh93が標準になったこと

それまでksh88やそれよりも古いBourne Shellがデフォルト
今2018年やで1988年って

660 ：login:Penguin：2018/12/05(水) 19:34:08.37 ID:MMUcdQBe.net

>>675
お前大変やな。
全部業者に依存してるからそうなるんやで

661 ：login:Penguin：2018/12/05(水) 19:36:22.29 ID:t6HAOGba.net

>>657
イイモノじゃなくて道に落ちてる出所不明なモノを拾い食いして
腹に当たったか平気だったかレポしてるのに近いなと思うねｗ
まぁコレはOSS全般に言えることだけどな
多数が狂ってればマトモな感覚のヤツがキチガイ扱いされても当然ではある

662 ：login:Penguin：2018/12/05(水) 19:37:52.80 ID:MMUcdQBe.net

業者の都合でLinux導入できないんだよ。でもそれがいいんだよ。
クラウドも導入できないんだよ。でもそのほうがいいんだよ
あのぶどうは酸っぱくてまずいんだよ

こんなところかね

663 ：login:Penguin：2018/12/05(水) 19:44:58.18 ID:t6HAOGba.net

>>659
フツーにユーザー作ったら標準でbashが動いたと思ったけど>solaris 11.4
今useradd試してみたけど間違いなく/usr/bin/bashが入ってきた
つかユーザーが過去に書いたスクリプトの互換性まで考えれば
下手にシステム付属のシェルは弄れない
>>660
オレに向けたレスか？ちょっと落ち着けよｗ
自分でコンテナ仮想化からOSカーネルまで全部書いてるのかね
凄い労力だなｗ
つかOSSの中身が業者がかりじゃないと思ってるとか何か純粋な人なんだなｗ

664 ：login:Penguin：2018/12/05(水) 19:46:32.90 ID:t6HAOGba.net

>>662
心配しなくても大丈夫
ちゃんと犬糞も使ってるからｗ
ただ檻に入れた上でごく限定的な用途でしか使う気しねえけどな

665 ：login:Penguin：2018/12/05(水) 19:58:04.75 ID:MMUcdQBe.net

>>663
それはログインシェル
まったく基本的なことすら知らないんだな

そんな奴が言ったってなんの説得力もねーわ

666 ：login:Penguin：2018/12/05(水) 19:59:04.87 ID:MMUcdQBe.net

最初から限定意的な用途でしか使ってないやつに、
深い知識を求めても無駄だな

Linuxインストールして満足しているやつらと変わらん

667 ：login:Penguin：2018/12/05(水) 20:04:00.13 ID:t6HAOGba.net

>>665
システム付属のシェルが古かろうと特に困らんてことを実例上げて説明したんだが

668 ：login:Penguin：2018/12/05(水) 20:10:10.73 ID:t6HAOGba.net

ちなみに古いバージョンのsolarisもコンテナとしてsolaris11上で動く
だから何の問題もない

669 ：login:Penguin：2018/12/05(水) 20:45:44.47 ID:MMUcdQBe.net

>>668
OSだけ動かしたってしょうがないだろうに・・・
本当に使いたいのはOSじゃなくてアプリ

670 ：login:Penguin：2018/12/06(木) 00:39:07.15 ID:YfDLncl6.net

ドカアッー！

671 ：login:Penguin：2018/12/06(木) 16:29:06.10 ID:0H7DsjYT.net

どっかｱｰｯ!

672 ：login:Penguin：2018/12/06(木) 19:29:31.33 ID:A7t9PKkR.net

話の流れとは関係ないが、なんか一部で勘違いしている人が
いるようだから書いておくわ

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

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

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

コンテナを仮想マシンの代わりとして使いたいなら
システムコンテナを使えばいい。俺はアプリ開発者だから
アプリのデプロイを簡単にしてくれるアプリケーションコンテナには興味があるが
仮想マシンの代替でしかないシステムコンテナは興味はそれほどない

673 ：login:Penguin：2018/12/06(木) 19:39:15.11 ID:52R6P0bW.net

>>672
の指摘する基本的な知識不足のやつと結局アプリケーションを使いたいだけってところのやつが入り混じってややこしくなってる。
仮想マシン立ち上げて単一アプリだけ動かしてるやつかもそうだし、
linux以外でdockerインスコするのにVMを知らずに入れてるやつとかもそう。
基本知識がないのに議論を始めるやつ多すぎ。

674 ：login:Penguin：2018/12/06(木) 22:07:11.61 ID:W7CcIDZc.net

>>672
privilegeを与えると、Dockerもシステムコンテナみたいになるという理解をしてもいいですか？
systemdが使えるので、けっこう便利にそうやってつかっているんだけど。

675 ：login:Penguin：2018/12/06(木) 23:20:08.28 ID:CjmGCUkG.net

>>674
そういう使い方もできるだろうけど、それなら lxc とか、lxd の方が
扱いやすいんじゃないかと思われ。

676 ：login:Penguin：2018/12/07(金) 00:24:19.67 ID:r4h+jkYy.net

システムコンテナとかいう謎用語はともかく、どんな用途のコンテナだろうが同一ホストでマルチテナントをやるなら高度な分離は必須だよ
クラウドベンダーが考えるコンテナ技術ってのは、デプロイや運用がPaaS並に手軽である一方で、
従来のPaaSのように特定のランタイムに縛られることがなく開発者の自由度が高い便利なプラットフォームを提供するための技術だ
どうしてもGoogleだのAWSだのクラウドベンダー発の技術には注目が集まりがちだけど、
そこには我々使う側ではなくプラットフォームを作る側の視点が強く反映されていることを理解しておかないといけない
そこを勘違いすると上で発狂してる子みたいな混乱に陥ることになる

677 ：login:Penguin：2018/12/07(金) 00:40:32.21 ID:JClhMg58.net

>>673
WindowsでわざわざVM動かしてLinuxもどきをうごかして、
そうしてからDockerを動かすなんて気持ち悪い。

678 ：login:Penguin：2018/12/07(金) 00:45:22.04 ID:Tm9Vcqu0.net

比較的安定したwinのGUIとコマンドの類が同時に手に入る
何も悪いことがない

679 ：login:Penguin：2018/12/07(金) 00:55:25.89 ID:tqGO7pdw.net

>>676
> どんな用途のコンテナだろうが同一ホストでマルチテナントをやるなら高度な分離は必須だよ

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

それは「必須」という用語を使ってまで言わないといけないことなんですか？ｗ

680 ：login:Penguin：2018/12/07(金) 00:59:19.39 ID:tqGO7pdw.net

>>677
別にｗ
Dockerの目的はアプリケーションの可搬性なんだから
VMを使っていようが、WindowsやMac上でアプリが動いて
まるでOS上で直接動いているかのように、localhost:ポートで接続できるなら
Dockerの目的は達成できてるんだよ

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

アプリケーションの可搬性がDockerの目的（コンテナの目的なんていってない）

681 ：login:Penguin：2018/12/07(金) 01:00:42.60 ID:tqGO7pdw.net

>>676
> どうしてもGoogleだのAWSだのクラウドベンダー発の技術には注目が集まりがちだけど、

Dockerはクラウドベンダーとは一切関係ないよ

682 ：login:Penguin：2018/12/07(金) 01:04:47.37 ID:tqGO7pdw.net

どんな用途のコンテナだろうが同一ホストでマルチテナントをやるなら高度な分離は必須だよ
高度な分離を行うときは仮想マシンで分離したほうがいいよ
そしてDockerでその仮想マシンに簡単にアプリをデプロイ

このスレはDockerのスレなんだから、1行目と2行目はスレ違いなんだよね。
Dockerの目的は物理マシン、仮想マシン問わず簡単にアプリをデプロイすることだから
WindowsでもMacでもアプリをデプロイ出来る。もっともこの二つの目的は
アプリの開発だけど、WindowsやMacで開発してそのイメージを
Linuxでそのまま動かせるっていうのもDockerの目的の一つだからね

683 ：login:Penguin：2018/12/07(金) 05:54:32.56 ID:3ISGbBV6.net

Hyper-Vでドカッたらブルスク出た

684 ：login:Penguin：2018/12/07(金) 09:16:55.56 ID:YIG0ITu+.net

>>682
今更すぎて指摘するのもアホらしいが、LinuxコンテナはLinux上でないとビルドも実行も不可能
いずれはマイクロVM向けにカーネルも同梱したコンテナが標準化されて
ホストOSに依存せずにWindowsコンテナもSolarisコンテナも統一的に扱えるようになるだろうけど、
まだまだ先の話だね

685 ：login:Penguin：2018/12/07(金) 09:51:15.00 ID:tqGO7pdw.net

>>684
> 今更すぎて指摘するのもアホらしいが、LinuxコンテナはLinux上でないとビルドも実行も不可能

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

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

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

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

これがDockerが提供している機能の本質だよ

686 ：login:Penguin：2018/12/07(金) 10:51:56.04 ID:TC0/u8V/.net

仮想マシンの設定が面倒?そんな低レベルなことを問題にしてたのか
そんなもんコンテナだって本質的には違いはないわけで、Dockerがやったような適切な標準化さえなされていればどうとでもなる
必死に仮想マシンはアプリではないとの主張を曲げない君の姿、
Dockerが生まれたばかりの頃にこんなもんどこがアプリやねん仮想マシンやないかと言ってた老害と同じだよ

687 ：login:Penguin：2018/12/07(金) 10:59:18.45 ID:tqGO7pdw.net

> 仮想マシンの設定が面倒?そんな低レベルなことを問題にしてたのか

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

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

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

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

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

ほんと、仮想マシンの設定レベルしか思いつかないんだからだめなやつだ

688 ：login:Penguin：2018/12/07(金) 11:00:55.95 ID:tqGO7pdw.net

> 必死に仮想マシンはアプリではないとの主張を曲げない君の姿、
仮想マシンをぽんと用意した所で、開発したRailsアプリは動かないからねｗ
仮想マシンはアプリじゃない。当たり前だ。

689 ：login:Penguin：2018/12/07(金) 11:05:36.14 ID:TC0/u8V/.net

だからOSのセットアップや運用管理が必要なのはコンテナだって同じだ
それを簡単にしたのはDockerが頑張ってそれを実装したからであり、コンテナだから楽になった訳ではない
Dockerと同等の簡便なワークフローをVMで実現することは技術的には普通に可能だ

690 ：login:Penguin：2018/12/07(金) 11:12:21.01 ID:tqGO7pdw.net

>>689
> Dockerと同等の簡便なワークフローをVMで実現することは技術的には普通に可能だ

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

もしかしてVMだけでコンテナを使わないで可能だって言ってる？
Linux上に仮想マシンを使わないで動かせるのがコンテナなのに
仮想マシンを使って作るとか、仮想マシンを使わないという条件を満たしてないんだがｗ

691 ：login:Penguin：2018/12/07(金) 11:19:44.15 ID:tqGO7pdw.net

マイクロVMはコンテナを動かすという前提があるから
あれだけ早く起動できる。
コンテナを使わないと仮想マシンは相当重くなる

692 ：login:Penguin：2018/12/07(金) 11:21:03.34 ID:tqGO7pdw.net

そういやSolarisってなんであんなに起動が遅いの？って思ったな。
VMだけ起動が早くても、そこで動かすSolarisがあんなに遅いんじゃ
使いものにならないだろうね。

693 ：login:Penguin：2018/12/07(金) 11:32:05.74 ID:JKnE+2X0.net

>>677
気持ち悪い云々は自由だけど、公式からもそういうツールがでてるし、一般的な運用なんだな、これが。
特に開発環境ではね。あとVMはWSLみたいなLinuxもどきではないぞ。

694 ：login:Penguin：2018/12/07(金) 12:14:23.46 ID:4ybr+TT5.net

そうそうVMはWSLみたいなLinuxもどきじゃない
エミュレートされるハードウェアは古いけどメジャーどころなのでそこらへんのノートPCよりも相性いい

695 ：login:Penguin：2018/12/07(金) 12:15:26.87 ID:tqGO7pdw.net

だからそのVMとDockerを組み合わせて使うんだよ

696 ：login:Penguin：2018/12/07(金) 12:48:37.28 ID:JKnE+2X0.net

dockerにセキュリティ不安があるのに流行るのは必要なリソースが少なくてすんで、環境を切り分けできるから。
dockerはlinuxネイティブに動作するから実機にするか、VMにするかはどっちが使いたいかぐらいの意味しかない。
とはいえ、一般的なネイティブアプリよりはdockerにはコストがかかるので単一のアプリじゃなくて環境そのものを扱うような場合がいいんだよ。
パッケージさえ揃えれば古い環境も再現できるし、保守はしやすいんだ。
マイクロVMのおもろいところは発展すればWSLなんかより遥かにいいから将来性はある。
それもソフトの発展じゃなくて仮想化支援のハードが出ればの話。
intelが仮想化に全力出せばOSを選択する意味はなくなっちゃう。

697 ：login:Penguin：2018/12/07(金) 12:52:38.28 ID:tqGO7pdw.net

> dockerにセキュリティ不安があるのに流行るのは必要なリソースが少なくてすんで、環境を切り分けできるから。

可搬性が高くなってデプロイが簡単になるからだよ。
環境が分離されるのは、可搬性を上げるためにそうういう機能が必要になるってだけ

698 ：login:Penguin：2018/12/07(金) 13:00:01.85 ID:tqGO7pdw.net

いくらいってもVMと比べることしか出来ないよなｗ

マイクロVMのだめなところは、別にOSをインストールしなければつかない所

699 ：login:Penguin：2018/12/07(金) 13:05:33.68 ID:JKnE+2X0.net

dockerと比べるならVMなんかじゃなくてsnapとかだよ。snapなんかの後継に根こそぎやられる可能性はある。

700 ：login:Penguin：2018/12/07(金) 13:07:19.36 ID:tqGO7pdw.net

dockerはアプリ開発者が、自分のアプリのデプロイのために使うもので、
snapとはまったく用途がかぶらない

701 ：login:Penguin：2018/12/07(金) 13:08:59.77 ID:tqGO7pdw.net

> intelが仮想化に全力出せばOSを選択する意味はなくなっちゃう。

OS使わないとアプリ動かないやんｗ

702 ：login:Penguin：2018/12/07(金) 13:10:41.56 ID:tqGO7pdw.net

どのOSでも使える。ということと、OSを選ぶ必要がないかは話が別だからな

703 ：login:Penguin：2018/12/07(金) 15:44:32.66 ID:Tm9Vcqu0.net

>>692
使ってる途中でユーザーの意思に反して勝手にOSにリセットが掛ったり
OSがフリーズして無反応になったのでサポに連絡すると
再起動しときましたー原因不明ですーというウェーイ系awsだと
そらOSの起動速度（）は超重要なんだろうなｗｗｗ
>>697
>可搬性が高くなって
犬糞はバイナリ互換性ガチ無視だからドッカ〜みたいなキワモノに依存せざるを得ないんだろ
パッチ当てるたびOS更新するたびにアッチ動かなくなりましたコッチ動かなくなりましたと情弱どもが大騒ぎ
>>702
犬糞はドッカーが必要になるぐらいすぐにドコでも動かなくなる可能性が高い不安定なOS環境ってコトだろ
コトバを飾るなや

704 ：login:Penguin：2018/12/07(金) 15:52:05.55 ID:tqGO7pdw.net

>>703
OSの起動速度が重要なのは、一時的なアクセス数増加に
迅速に対応するためだろ

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

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

Dockerの凄さをまざまざと見せつけられたｗ

705 ：login:Penguin：2018/12/07(金) 19:38:05.59 ID:Tm9Vcqu0.net

>>704
>OSの起動速度が重要なのは、一時的なアクセス数増加に
>迅速に対応するためだろ

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

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

>Dockerがあれば不安定なOS環境でも安定できるって
ドッカーによって稼働中のシステム全体がコケるってオチだろｗ
まさにそびえ立つクソの山

706 ：login:Penguin：2018/12/07(金) 21:48:15.71 ID:JKnE+2X0.net

論理展開ができない人間と真面目に議論しても得るものなんかないぞ。さわるなさわるな。

707 ：login:Penguin：2018/12/07(金) 21:59:50.50 ID:tqGO7pdw.net

>>706
ホントだなｗ

708 ：login:Penguin：2018/12/08(土) 12:31:08.24 ID:jLrx7HKQ.net

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
セキュリティよりパフォーマンスを優先したい場合や
セキュリティが必要ない開発環境では
今まで通りコンテナが使われるだろう

709 ：login:Penguin：2018/12/08(土) 12:45:37.18 ID:dieSV16U.net

FirecrakerはKVMベースで、それぞれのVMにカーネルが必要だが、
先の記事によればエミュレートする周辺機器を4つに限定してオーバーヘッドを削減している

ブロックデバイス
ネットワークインターフェイス
シリアルコンソール
VMを停止するためのボタンとして使うキーボードコントローラー

710 ：login:Penguin：2018/12/08(土) 13:33:41.63 ID:+Jbcoor3.net

またVMの話か。何度言っても理解できないようだな

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

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

Firecrackerで果たしてSolarisが動くかどうか
Linuxしか動かないVMになるだろう

711 ：login:Penguin：2018/12/08(土) 13:38:22.40 ID:+Jbcoor3.net

やっぱり想像通りだった。現状では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.

712 ：login:Penguin：2018/12/08(土) 14:29:10.10 ID:BjNmMfF8.net

Solarisとか言うオワコンwwwwww
あんたいつの時代から来たの？

713 ：login:Penguin：2018/12/08(土) 14:43:53.94 ID:L5TbyMsj.net

>>706
オマエは論理的なのではなく単に長い物に巻かれるのを良しとしているダケだろうがｗ

714 ：login:Penguin：2018/12/08(土) 14:55:41.74 ID:rWi9h0wU.net

>>713
悲しいかな、長いものが何一つ登場していないが、意味わかって使ってるか？

715 ：login:Penguin：2018/12/08(土) 15:11:44.95 ID:L5TbyMsj.net

>>714
自分が何をやってるのか(やらされてるのか)すら分かってないんだなｗ
アワレなやっちゃな

716 ：login:Penguin：2018/12/08(土) 15:12:58.65 ID:+Jbcoor3.net

>>712
だってUnix系ってSolaris以外オワコンじゃんｗ

717 ：login:Penguin：2018/12/08(土) 15:23:23.21 ID:L5TbyMsj.net

痛ニウム(とhp-ux)は無事死亡
ヨゴレIBMのキモイAIXは確実に客に避けられるのでエサ撒いたうえでRHを買収
バカを見たのは血道上げてRHのバグ潰しやってた不治痛とボラクルかｗ
あと散々販促活動してた五橋研究所ｗｗｗ

718 ：login:Penguin：2018/12/08(土) 15:27:36.57 ID:BjNmMfF8.net

Solarisは既にOracleに殺された
もう先はない

719 ：login:Penguin：2018/12/08(土) 15:32:43.14 ID:L5TbyMsj.net

hp-uxはCiRCUSであんなに大成功したのに
それをシステムとして売り込んでも
ワールドワイドでの採用実績がほとんどゼロだったというのは逆に凄いと言えば凄い
日本的なITモノって白豚どもの拒否反応を引き出す何かがあるというか
ぶっちゃけどっかコワレてるんだろうな
やってる連中が島国根性だからなのか知らんがｗ
この辺のネット系サービスはチョンコや支那畜も成功例聞かないので
アジア系全体の問題かもだが

720 ：login:Penguin：2018/12/08(土) 15:35:01.94 ID:L5TbyMsj.net

ボラクルに頃されたというよりはいわゆるリーマンショックに頃された＞Sun
中の人が言うには突然カネ入ってこなくなったらしいからな
ボラクルは一式揃って案外安かったので拾ったダケと言ってるな
まぁそれでも買ったのだからどうしようが連中の自由ってこった

721 ：login:Penguin：2018/12/08(土) 15:37:14.59 ID:+Jbcoor3.net

>>718
知ってる。採用候補になり得る最後のUNIXだった
あとはベンダーロックインされてしまって
抜け出せない所がUNIXを使ってる

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

結果、マイクロVMもLinuxに対応すれば十分という考えに行き着く

722 ：login:Penguin：2018/12/08(土) 15:40:19.17 ID:L5TbyMsj.net

>あとはベンダーロックインされてしまって
>抜け出せない所がUNIXを使ってる

それはLinuxを採用しても同じコト
RHと糞淫にベンダーロックインされてるダケ
それこそまさにawsにベンダーロックインされたがってるトコロすらあるｗ

723 ：login:Penguin：2018/12/08(土) 15:43:59.74 ID:L5TbyMsj.net

自分ダケはベンダーロックインから逃れられていると思ってる痛いコは居るかな？ｗ

ttp://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."

724 ：login:Penguin：2018/12/08(土) 15:49:20.78 ID:L5TbyMsj.net

ググるもPOWER採用でキモイやつら(666)のお仲間だってのはトックにバレちゃってるから
そっこらじゅうユダ公の息のかかったキモイ汚いモノだらけｗ

725 ：login:Penguin：2018/12/08(土) 15:57:43.92 ID:dieSV16U.net

Firecrackerってオンプレミスでも無い限り
自分で使う事は無いよな
FargateかLambdaを通して使うスタイル

726 ：login:Penguin：2018/12/08(土) 16:14:26.42 ID:+Jbcoor3.net

>>725
使う流れとしては

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

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

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

という流れだよ。

Dockerコンテナ化は目的があって行うことだが、
それ以外は、必要ないから減らすという考え

727 ：login:Penguin：2018/12/08(土) 16:18:36.37 ID:L5TbyMsj.net

ドッカー野郎がPC使って調子こいてられるのもSunがvboxに投資してたからだろ
docker toolboxなんてまさにまんまそれだ
MySQLもそうだ
イケてないライセンスのvmware(player含む)だと何もできない
翻ってRHはどうだ？win上で動く実用的なx86仮想化の技術なんて何も持たねえだろ
これだけ見てもSunがドンだけ先見て投資してたのかってハナシだよ
自社開発したチップの外販すらできんグズで消費するしか能のないググるとは比較にならない

728 ：login:Penguin：2018/12/08(土) 16:22:32.04 ID:+Jbcoor3.net

なんでvbox？ LinuxでDocker使うのに仮想マシンはいらないし、
WindowsとmacOSでは仮想マシン使ってるけど
もうvboxは使ってないくて、両方共OS標準の仮想マシン使ってるし
特にWindowsではvboxはDockerと同居できなくなったんで
もう数年使ってないよ。

729 ：login:Penguin：2018/12/08(土) 17:01:23.32 ID:ctzZZ9Ht.net

口だけのエアプだから知らないんだろう

730 ：login:Penguin：2018/12/08(土) 17:17:22.07 ID:dieSV16U.net

Fargateは自動的にVMを確保してくれて
便利だが比較的高い
従来からあるEC2の方が安いが、コンテナを動かすVMは自分で管理する必要がある
ジレンマ

731 ：login:Penguin：2018/12/08(土) 18:23:26.70 ID:L5TbyMsj.net

>WindowsではvboxはDockerと同居できなくなったんで
フツーに同居してるけどな
問題なくdocker machineも動いてるし
何かの間違いなのかな

732 ：login:Penguin：2018/12/08(土) 18:37:17.06 ID:L5TbyMsj.net

Solaris同梱のkshのバージョンがが古いとのたまい乍ら
サポ切れバージョンの犬糞をドッカープル（）することにはダンマリ
こういう手合いをダブスタ野郎と言うｗ

733 ：login:Penguin：2018/12/08(土) 18:53:52.19 ID:dieSV16U.net

Hyper-Vを利用しているとVT-xは利用出来ない
同時に利用はできず、片方だけ使える
そしてVT-xはVirtualBoxに必要

>>732
意味不明
ちゃんと更新すれば良いだけだろ？

734 ：login:Penguin：2018/12/08(土) 19:01:40.23 ID:PaHNzXQu.net

もう相手にするなよマジで

735 ：login:Penguin：2018/12/08(土) 19:14:36.46 ID:dieSV16U.net

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

736 ：login:Penguin：2018/12/08(土) 19:44:38.54 ID:+Jbcoor3.net

「pullして使う」っていうのも発想が
アプリ開発者じゃないって感じるよな

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

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

それがVMやコンテナ単体では出来ないことで、Dockerが解決している問題

737 ：login:Penguin：2018/12/08(土) 19:50:23.58 ID:rWi9h0wU.net

アプリ開発者のためだけのものではないぞ。念の為に言っておくが。

738 ：login:Penguin：2018/12/08(土) 19:50:40.18 ID:+Jbcoor3.net

>>735
WSL凄いよな。パフォーマンスの点でDocker for Windowsを（WSLから）使うけど
その問題が解決するならば、仮想マシンで動かさなくて良くなるからもっと便利になる

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

macOSもそうなってほしいね。macOSはUNIXだけどLinuxではないので
仮想マシンを使わないとDockerが使えない

739 ：login:Penguin：2018/12/08(土) 19:56:23.54 ID:L5TbyMsj.net

>>735
>Windows Subsystem for Linux
動作が遅いんだよなソレ

740 ：login:Penguin：2018/12/08(土) 20:46:45.10 ID:2GxAzxkY.net

>>739
エアプ乙wwwwwwwww

741 ：login:Penguin：2018/12/08(土) 21:11:29.00 ID:dieSV16U.net

WSLはCPU速度はVMと同等かそれ以上に速いが
I/OはNTFSを使う都合上遅い
後一年も経てば解決するかも

742 ：login:Penguin：2018/12/08(土) 21:14:37.86 ID:rWi9h0wU.net

>>741
なんで一年なの？もしよかったら。

743 ：login:Penguin：2018/12/08(土) 21:29:09.06 ID:dieSV16U.net

>>742
一応問題視はしてるらしいので
https://news.mynavi.jp/article/20180815-676572/

いつまで掛かるかは分からん
1年？2年？3年？

744 ：login:Penguin：2018/12/09(日) 00:10:57.54 ID:cc85A2e8.net

cygwinの時も同じ問題があって、それは解決できなかったんだけど、
MSの場合はカーネルやファイルシステムに手を入れることも視野に入れられるからな

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

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

パフォーマンスを上げるためにカーネルに手を入れる可能性も十分あると思うわ

745 ：login:Penguin：2018/12/09(日) 00:12:49.28 ID:cc85A2e8.net

> I/OはNTFSを使う都合上遅い
NTFSが遅いんじゃなくて、NTFSでLinuxのファイルシステムに求められる機能
（パーミッションなど）をエミュレートするから遅いんだけどな

NTFSのファイルシステム自体は高速
Windowsから触ってる時、何も遅く無いだろ？

746 ：login:Penguin：2018/12/09(日) 01:14:22.47 ID:HpkcVb/n.net

ちょっとドッカ行ってくる！

747 ：login:Penguin：2018/12/09(日) 02:07:56.20 ID:To7rhTt4.net

>>738
>>738
Windowsという再起動OSなんて使いたくない。
勝手に通信するし、あんなものをLinuxの代わりなどならない。

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

生のLinux使えばいい。

748 ：login:Penguin：2018/12/09(日) 10:31:38.95 ID:EY4Hdmdj.net

最近のM$のLinuxへの擦り寄り方が気持ち悪い・・

749 ：login:Penguin：2018/12/09(日) 11:58:40.20 ID:lnGs3c0o.net

EdgeもChromiumベースになるらしい
もともとユーザー数少ないし、下手に独自のエンジン作られても非互換の部分が増えるだけだし
良いんじゃね？
もっとOSSに擦り寄れよ

750 ：login:Penguin：2018/12/09(日) 13:16:03.28 ID:y11hLOEC.net

>>743
ニュースなってたんだ。ありがと。あとはデーモン管理できるようになれば実用段階だね。

751 ：login:Penguin：2018/12/09(日) 13:28:40.17 ID:THytfEd4.net

>>748
Windowsはクラウドでの運用に適さないからね
Azure使ってみたらよく分かるけど、MSのAzureチームもWindows使うの苦痛なんだろう

752 ：login:Penguin：2018/12/09(日) 13:29:50.96 ID:krBcsUKs.net

>>748
クラウドの客が犬糞使いたがってる影響だな
まぁ色々やむを得ずなんだろ

753 ：login:Penguin：2018/12/09(日) 22:54:59.88 ID:To7rhTt4.net

>>751
そもそもライセンスが面倒

754 ：login:Penguin：2018/12/10(月) 00:04:12.08 ID:SK07uHh5.net

>>753
だから必然的にクラウドを使うんだよ
AzureもAWSもGCPもWindowsインスタンスが用意されていて
そこにライセンスも使用料も含まれてる

もしかして知らなかった？
オンプレで自前サーバーとかて立ててる
時代のやり方してる所は知らなそうだよね

755 ：login:Penguin：2018/12/10(月) 00:39:51.48 ID:J1i/Nso2.net

windowsを使おうと思わないから、インスタンスがあっても知らんよ。。

756 ：login:Penguin：2018/12/10(月) 01:05:32.56 ID:7TlUMjqb.net

awsとか使ったことあるならwindows使わなくてもインスタンスあることくらい知ってるだろ

757 ：login:Penguin：2018/12/10(月) 10:47:43.06 ID:dQ2JA6Qk.net

クラウド使ってないのがバレた瞬間w

758 ：login:Penguin：2018/12/10(月) 11:12:08.35 ID:NeKVBZE8.net

インスタンス料金表とか見たらデカデカと載ってるからね
知らないのはさすがにありえないわ

759 ：login:Penguin：2018/12/11(火) 00:50:36.92 ID:4E+hOthN.net

ふとAWSのダッシュボードみてみたら、Linuxなんかよりも先にあるねWindows

760 ：login:Penguin：2018/12/11(火) 01:41:37.66 ID:fnQebX3c.net

アイウエオ順だからね

761 ：login:Penguin：2018/12/11(火) 03:32:26.01 ID:uPmSs8pv.net

ダッシュボードほとんどつかわねーもん。

762 ：login:Penguin：2018/12/11(火) 06:39:42.41 ID:TdDwAL/l.net

そりゃクラウド使ってなきゃ、
「必ず使わないとその他のメニューに行けないダッシュボード」を
使わないことだってあるだろうなぁｗ

763 ：login:Penguin：2018/12/11(火) 08:35:26.14 ID:ckB4u5dR.net

えっ、お前マネージメントコンソールやリファレンスを一切見ることなくCLIを使いこなし、
適切なインスタンスタイプ名を一発で引き当てることができないの？w

764 ：login:Penguin：2018/12/11(火) 11:41:27.35 ID:TdDwAL/l.net

何にいくらコストがかかるって
CLIで見れたっけ？

765 ：login:Penguin：2018/12/11(火) 11:56:58.01 ID:TdDwAL/l.net

引き当てるって書いてあるし、ガチャ方式でやるってことか
使ったことがないからネタに走ったってことね

766 ：login:Penguin：2018/12/11(火) 12:48:42.72 ID:zSz5aCBW.net

クラウドのインスタンスって、最初からOSが組み込まれているのか？
どんな設定されているかわからないものを使うって不安でない？
最初からiptableが開かれているとかさ？

767 ：login:Penguin：2018/12/11(火) 12:59:53.39 ID:TdDwAL/l.net

根本的なところがずれてるな

自分でOSを組み込んだら、どんな設定になるのかわかるのか？
iptableの状態がどうなってるのか、安心できるのか？

768 ：login:Penguin：2018/12/11(火) 13:44:58.63 ID:jw9Lxp3n.net

>>766
そもそもクラウドにiptableの設定なんか必要ない
そういうのはインフラ側の設定で制御するんだよ
オンプレ脳の人間はインフラを「容易には弄れないもの」と考えて何でもサーバー内で完結しようとする
しかしクラウドにおいてはむしろそれは逆で、サーバーよりもインフラの設定の方が柔軟に変更でき、構成管理も極めて容易だ
iptableのような脆弱な仕組みに頼ることなくデザインによってセキュリティ等の要件を担保できる
これがクラウドの強みだ

769 ：login:Penguin：2018/12/11(火) 13:57:03.24 ID:TdDwAL/l.net

説明下手だなｗ

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

クラウドではサーバーの外にあるファイアウォールで制御する
そのファイアウォールは、設定画面やCLIコマンドやAPIから設定できる

770 ：login:Penguin：2018/12/11(火) 18:55:36.03 ID:vSSmL6HQ.net

多層防御やんないの？

771 ：login:Penguin：2018/12/11(火) 18:57:19.35 ID:RFWXoMiO.net

>>769
わかりやすい。

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

Dockerならフォワードチェインから、
サブチェインに飛ばして、そこでフィルタやパケットの統計をとったり、
あるいは、ポート開放のために、-t nat にフォワードの設定が必要になるだろうけど、
クラウドはそういうのは使わないの？

772 ：login:Penguin：2018/12/11(火) 19:01:33.77 ID:TdDwAL/l.net

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

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

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

お前、アプリの中に、ファイアウォールの設定入れるのか？
Dockerコンテナは仮想マシンじゃないって言ってるだろ

773 ：login:Penguin：2018/12/11(火) 19:02:07.57 ID:TdDwAL/l.net

>>771
> クラウドはそういうのは使わないの？
だからそれらは全てサーバーの外にあるファイアウォールで設定できる

774 ：login:Penguin：2018/12/11(火) 19:02:50.71 ID:YQlb17UG.net

実際はiptableなんかに頼ることなく、ハード込みで売ってるファイヤウォール使ってるってことだろ。

775 ：login:Penguin：2018/12/11(火) 19:02:59.55 ID:TdDwAL/l.net

>>770
やりたいならやればいいのでは？

776 ：login:Penguin：2018/12/11(火) 20:20:08.70 ID:aNKr+Tu5.net

>>770
お前はリスクマネジメントというものを分かってない
AWSが俺を信じて任せろと言ってるんだからリスクは完全にAWSに転嫁されていて、それで十分なんだよ
もしもAWSの不具合で事故るようなことがあれば、そのときはAWSに損害賠償請求すればよい

777 ：login:Penguin：2018/12/11(火) 20:39:50.12 ID:TdDwAL/l.net

>>776への反論は

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

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

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

という感じでお願いねｗ

778 ：login:Penguin：2018/12/11(火) 20:50:55.90 ID:wGD7MWoB.net

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を使えば同じことできそうだが
めんどい

779 ：login:Penguin：2018/12/11(火) 21:01:01.62 ID:hpl/6PSX.net

http://connect.uh-oh.jp/

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

宣伝です。

780 ：login:Penguin：2018/12/12(水) 00:19:12.15 ID:0hXJnkj2.net

コンテナとJSフロント関係は
進歩早すぎてついていけん...

781 ：login:Penguin：2018/12/12(水) 00:40:57.10 ID:JHof8k11.net

>>772
でも、Dockerコンテナ起動したら、
ポートが開くじゃない？
たとえば、ソースIPアドレスで絞り込んだり、
iptablesが必要だと思うけど？
そういうこともawsセンター側できるの？

782 ：login:Penguin：2018/12/12(水) 00:43:06.20 ID:Zb7agEVB.net

> でも、Dockerコンテナ起動したら、
> ポートが開くじゃない？

開かないが？

783 ：login:Penguin：2018/12/12(水) 00:43:48.96 ID:Zb7agEVB.net

>>781
例えば、nginxを起動するとポート80番が開く
って話してるのか？

Dockerと関係ない話だよね

784 ：login:Penguin：2018/12/12(水) 02:56:29.06 ID:JHof8k11.net

>>772

コンテナはアプリを動作させるための環境であって、
コンテナ＝アプリという式は間違っている。

785 ：login:Penguin：2018/12/12(水) 02:57:03.71 ID:oUbBeYcM.net

>>776
まあ大抵にわかのセキュリティエンジニア（笑）が設定ミスってノーガードになるのが事故の原因なんだけどな
オンプレでもFWで守られてるから大丈夫なんて余裕ぶっこいてるサーバーほどよく侵入されてる

786 ：login:Penguin：2018/12/12(水) 10:49:09.21 ID:Zb7agEVB.net

>>784
コンテナ＝アプリ と言ってない
Dockerコンテナ=アプリ と言ってる
正確に言うならアプリ相当として考えろってことだが

787 ：login:Penguin：2018/12/12(水) 10:51:05.96 ID:Zb7agEVB.net

>>785
なんでデフォルトでポート塞がないの？って話だな

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

意図的にファイアウォールの設定をしない限り接続できないように
安全な状態になっている。

788 ：login:Penguin：2018/12/12(水) 12:46:39.18 ID:rkj8vXTd.net

>>785
それはいったんFWの内側のネットワークに侵入されたらノーガードのサーバーに入り放題ってことだろ？
クラウドだとFW相当の設定はサーバー単位だし、その上で仮想ネットワークの出入口に更に強力なFWを設けるのが一般的だ
その上で更にサーバ内でポート閉じる設定するなんて明らかに冗長なだけ

789 ：login:Penguin：2018/12/12(水) 12:53:29.02 ID:JHof8k11.net

>>787
デフォで、オールリジェクト？ポリシーはどうなっているの？

awsでもDockerコンテナ使えますか。
使えるなら、Dockerホストと、その外部ファイアウォールの両方でポート開放が必要ということですよね。
いわば、サーバーの先にブロードバンドルータがあるみたいな感じですよね。

790 ：login:Penguin：2018/12/12(水) 13:33:11.96 ID:Zb7agEVB.net

>>788
> それはいったんFWの内側のネットワークに侵入されたらノーガードのサーバーに入り放題ってことだろ？
セキュリティ突破できたらやり放題って当たり前だろ
何を言ってるのかわからん。

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

> その上で仮想ネットワークの出入口に更に強力なFWを設けるのが一般的だ
だからそれがデフォルトなのがクライド

791 ：login:Penguin：2018/12/12(水) 13:34:32.04 ID:Zb7agEVB.net

>>789
> awsでもDockerコンテナ使えますか。
今の話にDockerコンテナは関係ないから
（パッケージでインストールする）nginxに置き換えるね

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

だからなに？

792 ：login:Penguin：2018/12/12(水) 14:03:28.23 ID:rkj8vXTd.net

>>790
いやセキュリティグループはサーバー単位だろ
本当にAWS使ってるのか？

793 ：login:Penguin：2018/12/12(水) 14:18:50.62 ID:LrMZOP1V.net

>>792
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Security.html

この下の図を見ろ。
インスタンスの外にセキュリティグループが存在している

794 ：login:Penguin：2018/12/12(水) 14:20:39.26 ID:JHof8k11.net

>>791
0点

>>789をよく読んで答えなさい

795 ：login:Penguin：2018/12/12(水) 14:34:36.22 ID:LrMZOP1V.net

>>794
反論できないならレスすんなよｗ

796 ：login:Penguin：2018/12/12(水) 14:53:24.26 ID:rkj8vXTd.net

>>793がAWSを使ったことがないことはわかった

797 ：login:Penguin：2018/12/12(水) 15:21:10.76 ID:kA2tO+1p.net

セキュリティグループは作ってからEC2インスタンスやロードバランサー、データベースにくっつける

IPアドレスの範囲に加え、
特定のセキュリティグループを持ったインスタンスの接続のみを許可する使い方も出来て便利

798 ：login:Penguin：2018/12/12(水) 15:21:58.33 ID:afrcY71M.net

AWS使ったことないんだけど、ポートを塞ぐだけでセキュリティ云々言うのは間違ってるよ。
webなんかで言われるセキュリティホールは80とか443を使って侵入するから通信の中身やURLを解析して弾かなきゃいけない。
こんなのは自前で実装するのが普通。

799 ：login:Penguin：2018/12/12(水) 15:24:04.80 ID:LrMZOP1V.net

>>798
URLを解析って何すんの？
言ってみ

800 ：login:Penguin：2018/12/12(水) 15:25:51.40 ID:LrMZOP1V.net

オンプレの場合、一旦納品したサーバーは
脆弱性があろうともバージョンアップしないんだろう

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

馬鹿としか言いようがないｗ

801 ：login:Penguin：2018/12/12(水) 15:26:01.33 ID:kA2tO+1p.net

自分のアプリのバグで大穴を開けなきゃ普通は大丈夫

802 ：login:Penguin：2018/12/12(水) 15:32:49.47 ID:afrcY71M.net

>>799
jsが仕込まれたURLじゃないかとか色々

803 ：login:Penguin：2018/12/12(水) 15:39:58.21 ID:JHof8k11.net

>>795
反論を煽るようなレスをわざわざするなよ

804 ：login:Penguin：2018/12/12(水) 15:41:21.13 ID:JHof8k11.net

>>799
ストリングクエリとか

805 ：login:Penguin：2018/12/12(水) 15:43:22.45 ID:LrMZOP1V.net

>>802
え？なに？ クライアントからサーバーに
jsが仕込まれたURLが送られてくんの？

>>804
え？なに？ストリングクエリに細工されていたら
サーバーに侵入される脆弱性があるの？

806 ：login:Penguin：2018/12/12(水) 15:44:35.32 ID:JHof8k11.net

>>805
最初からわかっていたら苦労しない。

807 ：login:Penguin：2018/12/12(水) 15:50:02.78 ID:LrMZOP1V.net

>>806
テストもレビューもしないってこと？
細工したクエリストリング流してテストすればわかることだよね？

808 ：login:Penguin：2018/12/12(水) 15:50:03.76 ID:afrcY71M.net

可能性を言えばきりがないが、URL依存の攻撃なんか腐るほどパターンがあるから限られたURLだけ通してあげて、
それ以外は404とかに出すに限る。404も別サーバーでいい。
bashショックもURLだったろ。あれはパッチをできるだけ速く当てるしかないが。

809 ：login:Penguin：2018/12/12(水) 15:51:25.13 ID:afrcY71M.net

テストとレビューで事足りるならセキュリティは苦労しない。

810 ：login:Penguin：2018/12/12(水) 15:55:21.74 ID:LrMZOP1V.net

でもセキュリティあってもテストとレビューで
事足りないものはセキュリティでも漏れるから
意味ないよね

811 ：login:Penguin：2018/12/12(水) 15:56:29.43 ID:LrMZOP1V.net

> 可能性を言えばきりがないが、URL依存の攻撃なんか腐るほどパターンがあるから限られたURLだけ通してあげて、

だから限られたURLってなんだ？
お前のサーバーは、自分以外のURLで接続できるのか？

812 ：login:Penguin：2018/12/12(水) 16:02:48.99 ID:afrcY71M.net

>>811
普通いくらでも通るぞ。getも知らないのか？

813 ：login:Penguin：2018/12/12(水) 16:14:58.97 ID:LrMZOP1V.net

>>812
どこのサーバーからgetするの？

814 ：login:Penguin：2018/12/13(木) 01:38:07.71 ID:eanokFZt.net

>>811
たとえば、基本的なところでは、クエリストリングで、
アプリケーション側で対応するフィールド以外のものは、
排除するとか。

815 ：login:Penguin：2018/12/13(木) 08:28:12.43 ID:WRDxjQMU.net

>>798
>webなんかで言われるセキュリティホールは、80とか443を使って侵入するから、
通信の中身やURLを解析して弾かなきゃいけない。
こんなのは自前で実装するのが普通

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

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

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

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

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

こういう奴らは、アプリを作っちゃいけない！

816 ：login:Penguin：2018/12/13(木) 08:31:23.97 ID:+yv1dYA8.net

>>814
そんなもんWAFで弾ける
クラウドならそれこそ画面でポチるだけ

817 ：login:Penguin：2018/12/13(木) 08:35:16.32 ID:WRDxjQMU.net

>>789
>awsでもDockerコンテナ使えますか

aws は、Docker だろ。
CoreOS, Kubernetes とか

818 ：login:Penguin：2018/12/13(木) 14:47:58.45 ID:XsbRAMI5.net

コンテナってクラウドに熟達した人が究極のdeployabilityを追求した末に行き着くものだと思ってたけど、意外とそうでもないんだね
クラウドには手が出ないけどなんか新しそうなもの触ってみたいだけな人が多いのかな

819 ：login:Penguin：2018/12/13(木) 15:26:06.24 ID:j2qkztX7.net

マネージドKubernetesサービス対決

比較表見るとアマゾンのEKSはGoogleのGKEと比較してコスト高いだけの劣化版に見える
そしてMSのAKSはどちらにも及ばないクソ
https://kubedex.com/google-gke-vs-microsoft-aks-vs-amazon-eks/

820 ：login:Penguin：2018/12/14(金) 00:56:30.76 ID:yXt9E1ve.net

>>816
httpsの場合は？
中間者攻撃が成立しないと解読できないと思うけど。

821 ：login:Penguin：2018/12/14(金) 08:26:23.33 ID:E4qeknD0.net

>>820
wafはCloudFrontやALBと組み合わせて使うよ。
それらはSSLアクセラレーターの機能も兼ねてるのでwafやwebサーバ側に来る時点ではhttp平文状態になります。
この場合、サーバー証明書はCloudFrontやALBに組み込むだけで済みます。AWSはドメイン発行やルート局も持ってるので証明書関連はAWSだけで完結できます。
スレチだけどEntity Framework等の昨今のO/Rマッパーを使っていればSQLインジェクション対応してくれるから余り神経質になる事はないよ。自身でSQL文を組み上げる事はしません。

822 ：login:Penguin：2018/12/14(金) 11:45:24.57 ID:BtHCLjdt.net

>>820はまさかコンテナにSSL喋らせてるのか?
そんな足回りの関心は丸投げできるようなインフラでないと上で喚いてる「アプリとしてのコンテナ」なんか程遠いだろ

823 ：login:Penguin：2018/12/14(金) 11:50:21.23 ID:Wd54hADz.net

もうそろそろ飽きてきたな。
インフラ周りの話はDockerコンテナと関係ないし

824 ：login:Penguin：2018/12/14(金) 12:17:11.80 ID:BtHCLjdt.net

今時オーケストレーションやインフラの技術を抜きにしてコンテナを語るのは無理があるだろ
ホビーストがチマチマrunして遊ぶ時代はとうの昔に終わったんだよ

825 ：login:Penguin：2018/12/14(金) 12:28:41.19 ID:Wd54hADz.net

>>824
レイヤーが違うんだよ。

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

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

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

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

アプリとインフラの機能を密結合させるという発想しか持ち合わせてないから
こういう話を続けるのだろうけど

826 ：login:Penguin：2018/12/14(金) 23:41:13.97 ID:94bz9H8n.net

>>825
大いに関係あるよ
なぜコンテナにTLSが必要ないのか?
それは暗にインフラに対してCloudFrontやALB的なものが存在するという前提を設けているからだろう
レイヤが違う、故に高レベルのレイヤの設計は低レイヤの性質に依存するんだよ
コンテナを単なるVMというならともかく、そうじゃないと主張しているんだろ？
だったらそのためのインフラに対する条件は明確にしておかなければ机上の空論でしかないぞ

827 ：login:Penguin：2018/12/15(土) 00:12:19.93 ID:AVLQNiPu.net

>>826
お前が言ってるのコンテナと関係ない話じゃん

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

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

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

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

そういったすみ分けが昔から出来てるわけで、Dockerコンテナだからそうするいう話ではない

828 ：login:Penguin：2018/12/15(土) 15:15:31.44 ID:cWutNvKe.net

>>827
証明書ゲートウェイですね
大手でも、そういう名前のサイトで最初で認証させられるわ。

829 ：login:Penguin：2018/12/15(土) 15:44:52.42 ID:K1K5tkNg.net

>>828
なんかそれ違う気がする。
>>827のはSSLアクセラレータとかの方でねぇか？

830 ：login:Penguin：2018/12/15(土) 15:46:43.03 ID:K1K5tkNg.net

訂正：SSLアクセラレータとかSSLオフロードとかの方でねか？

831 ：login:Penguin：2018/12/19(水) 14:48:40.71 ID:MXoPEPIu.net

WindowsでDocker (Hyper-V)とVirtualBoxが共存可能になったってよ

832 ：login:Penguin：2018/12/19(水) 15:26:42.72 ID:ChoPuE2E.net

>>831
そうなんだ
又試してみるかな

833 ：login:Penguin：2018/12/19(水) 16:34:42.32 ID:RugaoNC3.net

>>831
バーチャルマシンつかった段階で、負けた感がある。

そこはLinuxをちゃんとつかって、生でDockerしないと。

834 ：login:Penguin：2018/12/20(木) 23:54:36.14 ID:XN4/V/I5.net

>>831
何が凄いのか、分からない、良かったら教えてくだしあ
個人的には、Linuxでdocker派です

835 ：login:Penguin：2018/12/21(金) 01:14:23.43 ID:Nv7/v6TH.net

Dockerって、可搬性
>>834
これまでHyper-VをオンにするとVirtualBoxが使えなかった。
それが6.0から共存して使えるようになると騒いでいる。
でも自分も含め動いていない人も居て、本当に動くのか議論されている。

836 ：login:Penguin：2018/12/21(金) 01:15:42.66 ID:Nv7/v6TH.net

最初に変な文入った。すまん。

837 ：login:Penguin：2018/12/21(金) 01:24:14.44 ID:XG5mmZ9I.net

ひょっとしてVMWareとも共存できるようになった？

838 ：login:Penguin：2018/12/21(金) 01:53:16.38 ID:uGD7jju5.net

>>835
公式にはできるってアナウンスないって事？

839 ：login:Penguin：2018/12/21(金) 06:49:12.33 ID:Nv7/v6TH.net

>>838
公式にアナウンスされているけど、動かない。でも動いてる人も居るんですよね。きっと。

840 ：login:Penguin：2018/12/21(金) 11:28:49.25 ID:gbcTPeq+.net

>>839
Windows ハイパーバイザープラットフォームをオンにしたら動いた
https://superuser.com/questions/1208850/why-vitualbox-or-vmware-can-not-run-with-hyper-v-enabled-windows-10

841 ：login:Penguin：2018/12/21(金) 13:33:22.49 ID:l/z2KMXK.net

>>840
QEMUの話。動いたとは書かれていない

842 ：login:Penguin：2018/12/21(金) 17:10:41.60 ID:uGD7jju5.net

>>839
Vrtual Boxの方をアプデするのね
Dockerの公式ブログとか見てたw

843 ：login:Penguin：2018/12/21(金) 17:47:57.10 ID:gbcTPeq+.net

>>842
6.0にしてWindows ハイパーバイザープラットフォームをオンにし、再起動。

844 ：login:Penguin：2018/12/22(土) 09:20:27.59 ID:XGn7oEU9.net

>>843
ありがと
やってみます

845 ：login:Penguin：2018/12/23(日) 05:24:15.15 ID:qY0IrDwI.net

素人ながらubuntu16.04にdockerを入れたらネットに接続できなくなりました。ブリッジが勝手にかかっててwifiがつながらない症状が出ています。
操作しようとしたらgot permission denied while trying to connect to the Docker daemon socket at unix 〜〜〜と出てきました
この状態からdockerを削除して元の状態に戻す方法を教えていただけないでしょうか。
sodo gpasswd -a username dockerでグループには追加しました。

846 ：login:Penguin：2018/12/23(日) 05:53:03.36 ID:HJ+H2evR.net

>>845
dockerを消す前に、再起動しろ
再起動したら動く

847 ：login:Penguin：2018/12/23(日) 06:59:26.01 ID:qY0IrDwI.net

接続できるようになりました。とんだお騒がせをいたしました。

848 ：login:Penguin：2018/12/23(日) 07:11:20.54 ID:HJ+H2evR.net

ま、再起動しなくてもネットワークサービスを再起動して
ログインしなおせば動くんだけどなｗｗｗ

849 ：login:Penguin：2018/12/23(日) 14:58:25.06 ID:yfLE2NmO.net

今更ながらdocker勉強し始めました
KVMみたいにOSから作るのは理解できるけど、例えばDockerHubからNginxイメージをpullする時は、dockerをインストOS環境に依存するの？
Debian使ってたらDebian環境用のNginx環境ができるの？

850 ：login:Penguin：2018/12/23(日) 15:09:29.69 ID:HJ+H2evR.net

そのnginxイメージを作ってるDockerfileを読めばわかることだろ

dockerを使う = Dockerfileを読み書きするってことなんだからな

851 ：login:Penguin：2018/12/23(日) 15:11:09.75 ID:Sp1piTzY.net

使用しているベースイメージ次第。環境は関係ない。
dockerは実運用するなら素のベースイメージから上は自分で作るのが基本だから、そのへんの考え方は一度自分でやってみればすぐに理解できる。
出来合いのものはあくまでサンプル。

852 ：login:Penguin：2018/12/23(日) 15:18:02.54 ID:nk+HmfrL.net

ありがとう
むぅ理解できないわ
取り敢えず触ってみる

853 ：login:Penguin：2018/12/23(日) 15:20:33.05 ID:nk+HmfrL.net

んっnginxより上、ベースイメージでの動作はdockerが担保してくれるってことなのかな

触ってみる

854 ：login:Penguin：2018/12/23(日) 15:23:14.74 ID:B+bc3dl4.net

カーネルは共有されるけどそれくらい

855 ：login:Penguin：2018/12/23(日) 20:16:44.66 ID:JFyTQrTf.net

LinuxカーネルのABIは安定しているので
カーネルより上の層（libc）とかは
基本どのディストリビューションでも動作する

go言語は他のライブラリが必要ない実行ファイルを作れる
scratchイメージにgoの実行ファイルだけ入ったものを作れば
僅か数MBのDockerイメージすら作れる

856 ：login:Penguin：2018/12/23(日) 20:27:41.62 ID:QVRCwsb4.net

>>855
何ヶ月か前に別スレでその最初の3行にまつわる話したら袋叩き似合った

857 ：login:Penguin：2018/12/23(日) 20:28:40.54 ID:a3X0TqIZ.net

だってウソだもんで>LinuxカーネルのABIは安定している

858 ：login:Penguin：2018/12/23(日) 20:53:37.68 ID:HJ+H2evR.net

>>855
> go言語は他のライブラリが必要ない実行ファイルを作れる

でもライブラリ相当の機能が実行ファイルに含まれてるから、
goのバイナリはサイズがデカイんだよね

859 ：login:Penguin：2018/12/23(日) 20:56:40.02 ID:HJ+H2evR.net

お、あったｗ やっぱりでかい
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

860 ：login:Penguin：2018/12/23(日) 21:00:54.59 ID:QVRCwsb4.net

goはでかいよ
Archやってるとでかいサイズのgoの更新が頻繁に来るからうざい

861 ：login:Penguin：2018/12/23(日) 22:03:58.19 ID:jSNMCGZQ.net

Linux/UNIX文化では動作が変わっても名前は変わらないので必ずリンクできる。
つまり安定性が高い。
一方、Windowsは動作が変わると名前にサフィックスが付く。
従って新しいAPIに自動的にリンクされることはないし、APIの数はドンドン増え続ける。

862 ：login:Penguin：2018/12/23(日) 22:06:43.39 ID:UzZijvxD.net

>>861
？

Linux/UNIX文化では動作が変わっても名前は変わらないので必ずリンクできる。
Windowsは動作が変わると名前にサフィックスが付く。
以前の名前は変わらないので必ずリンクができるし、以前の名前の動作が変わることがない
だから高い互換性が保てる

といいたいのかな

Linuxはカーネルのシステムコールの数が増えなくても
ライブラリとは関係ない話なので、APIの数の代わりにライブラリの関数が増え続けるよ

863 ：login:Penguin：2018/12/23(日) 22:39:22.84 ID:5Q1rOqA5.net

>>856
読んでみたい、どこか覚えてる？

864 ：login:Penguin：2018/12/24(月) 11:43:32.49 ID:ZQ/dJl6b.net

Debianにインスコ開始ー

865 ：login:Penguin：2018/12/24(月) 12:15:04.63 ID:wEpk+PBH.net

GoのシングルバイナリってGPL汚染はないの？
というかDocker自体、上の方で猿が喚いてる「コンテナはアプリだ！」との主張がもし世間一般に通るなら、
単なる集積物であってアプリにGPLは感染しない理論はかなり無理があるんじゃないかな

866 ：login:Penguin：2018/12/24(月) 12:32:06.34 ID:3ljC1xCs.net

自分で入れた癖して汚染したとか騒ぐのは笑えるぜ

867 ：login:Penguin：2018/12/24(月) 12:37:46.46 ID:3ljC1xCs.net

>>865
そもそもGoはBSDライセンスだし

gccgoを使う場合はGPLのコンポーネント（gcc）を含むが
生成したバイナリはGPLの対象外

gccのランタイムライブラリは例外にしないと
Linuxにクローズドソースのソフトウェアが一切存在出来なくなるから
まさかクローズドソースのは一切無いと思ってた？

868 ：login:Penguin：2018/12/24(月) 12:54:07.75 ID:FVAjhLvH.net

>>867
LinuxのアプリがGPLに感染しないのは、GPLの「単なる集積」と「システムコール」の例外条項による
自分で条項を読んでみたらいい
Dockerコンテナを単なるアプリケーションパッケージと解釈するなら、これらの例外が適用されるかはかなり怪しいよ
まあGoの場合は解釈論を云々するまでもなくGPLライブラリをスタティックリンクした時点で完全アウトだが

869 ：login:Penguin：2018/12/24(月) 13:26:23.88 ID:n0J+hQ60.net

>>868
意味不明
Dockerで使う時だけ対象になるとか何処に書いてある？

870 ：login:Penguin：2018/12/24(月) 13:36:26.71 ID:n0J+hQ60.net

>>868はDockerイメージは全てオープンソースにしないと違法って言ってんのか？
そんなこと言ってんのお前だけだろw

871 ：login:Penguin：2018/12/24(月) 14:05:57.51 ID:sB1miyd2.net

Linuxはソース文化なのでコンテナがないとアプリケーションの配布がきつい。

872 ：login:Penguin：2018/12/24(月) 16:44:22.21 ID:0ONmT3Cp.net

>>868
お前、その主張は、DVDにGPLとそうでないものを
一緒に焼いたら（つまりRedHat Linux状態）
ライセンス違反になると言ってることになってるんだが
気づいているか？

873 ：login:Penguin：2018/12/24(月) 16:46:03.80 ID:0ONmT3Cp.net

>>868じゃなくて>>865あて

874 ：login:Penguin：2018/12/24(月) 18:34:55.08 ID:sB1miyd2.net

Redhatは倫理規定違反で死刑になってもおかしくないけどな。

875 ：login:Penguin：2018/12/24(月) 19:52:46.56 ID:fOFd4UE9.net

そもヨゴレのIBMと喜んでくっつかってんだから相当なド底辺クズ野郎どもだろ>RH
大喜びで開発協力してきた日本の大手ITベンダのアホ情弱どもはそれ以下のマヌケだろうけどな

876 ：login:Penguin：2018/12/24(月) 22:18:39.83 ID:Hg8v6tOU.net

>>872
>>872
それがいわゆる「単なる集積」
特定のアプリのために同梱してるんじゃなくて本当に単なる寄せ集めだから派生物と見做されない
一方Dockerは特定のアプリのためにコンポーネントを事実上スタティックリンクしているわけで、例外条項の趣旨を考えれば完全にアウトだ
だからDocker使うなら間違っても「コンテナはアプリだ」なんて言っちゃいけない

877 ：login:Penguin：2018/12/24(月) 23:37:40.13 ID:0ONmT3Cp.net

> 一方Dockerは特定のアプリのためにコンポーネントを事実上スタティックリンクしているわけで

事実上スタティックリンクってことは
本質上スタティックリンクじゃないってことだよね

878 ：login:Penguin：2018/12/24(月) 23:39:40.35 ID:0ONmT3Cp.net

Dockerコンテナはスタティックリンクしてないからアプリと言えるわけである
スタティックリンクしていれば1バイナリになる。

879 ：login:Penguin：2018/12/24(月) 23:52:53.20 ID:Y3lrr8FC.net

>>878
GPLはスタティックリンクか動的リンクかに関わらず感染するよ

880 ：login:Penguin：2018/12/24(月) 23:54:33.16 ID:sB1miyd2.net

LGPLなら良かったのにな。

881 ：login:Penguin：2018/12/25(火) 00:01:42.31 ID:XGHDmrXH.net

ちなみにAndroidアプリだと、LGPLライブラリ(.so)をアプリのパッケージ(ZIP形式)に入れて配布するのはスタティックリンクに該当し、
アプリがLGPLに感染するという解釈が一般的だ
Dockerイメージは言うまでもないよね

882 ：login:Penguin：2018/12/25(火) 00:04:53.08 ID:MqCJ7mUS.net

いつのまに、アプリと呼ぶだけでGPLに感染することになったんだ？ｗ
本質的にアプリだが、アプリと呼ばなければOKって意味不明

俺が「あれ」と「これ」を含んだDockerコンテナ=アプリを作ったとして
他人が作った「あれ」と「これ」のライセンスを、赤の他人の俺がGPLに変更できるわけないし

Dockerfileはただの数行のファイルでしか無いし、
俺がGPLのものを作ってなにか作ったからと言って、それを不特定の人に公開する義務もない

Docker=アプリに反論したいができなくて、とりあえず言ってみたんだろうが
穴がありすぎて、大丈夫かこいつ？

883 ：login:Penguin：2018/12/25(火) 00:05:50.27 ID:MqCJ7mUS.net

>>881
良い皮肉だｗ
Googleストアにあるやつは全部GPLになっちゃうよなｗ

884 ：login:Penguin：2018/12/25(火) 00:09:26.36 ID:MqCJ7mUS.net

Dockerイメージを配布せずに、
Dockerfileだけ配布すれば
完全にGPL（LGPL）を回避できる

Dockerは素晴らしいですな！

885 ：login:Penguin：2018/12/25(火) 00:10:23.19 ID:MqCJ7mUS.net

ということで、DockerがGPL違反になるとか言ってるアホは徹底的にコテンパンにされました。おしまい。

886 ：login:Penguin：2018/12/25(火) 00:11:46.93 ID:XGHDmrXH.net

いやイメージを配布するのは普通にGPL違反よ
配布しなけりゃいいだけだし、誰もそれは否定してないでしょ

887 ：login:Penguin：2018/12/25(火) 00:23:34.90 ID:FPaj6kyi.net

まあ確かに、LGPLはシステムライブラリとのリンクを想定してるから、一緒に配布するのはGPLの精神からすると感染だろな。

888 ：login:Penguin：2018/12/25(火) 00:24:24.73 ID:DAdBnaIi.net

> いやイメージを配布するのは普通にGPL違反よ

1. そもそもイメージ配布しなければGPL違反でないし
イメージ配布する人を社内に限れば、社内の人だけにソースを配布すれば良い

2. GPLはバイナリを入手した人がソースを入手できればいいので
バイナリを手に入れてない人にソースを配布する必要はない

3. DockerイメージのソースとはDockerfileのこと

4. もちろんDockerイメージの不特定の人に配布したら、
その中に入っているバイナリのソースも渡さないといけない

889 ：login:Penguin：2018/12/25(火) 00:25:07.05 ID:DAdBnaIi.net

> まあ確かに、LGPLはシステムライブラリとのリンクを想定してるから、一緒に配布するのはGPLの精神からすると感染だろな。

その理屈だと、ISOイメージにして配布しているRedHatなんかも
ライセンス違反ということになってしまうので、間違ってるのは明らか

890 ：login:Penguin：2018/12/25(火) 00:26:04.73 ID:DAdBnaIi.net

一言で言うならば、GPL感染した所で、プライベートイメージなら
何ら問題ないってことよ。

891 ：login:Penguin：2018/12/25(火) 00:26:15.33 ID:FPaj6kyi.net

>>889
Redhatは裁判になったら死刑判決受けるだろ。

892 ：login:Penguin：2018/12/25(火) 00:26:43.00 ID:3aFn9L6f.net

>>889
だからそれは単なる集積
DockerもVMだから単なる集積だと強弁してしまえばイメージの配布も限りなく黒に近いグレーにできなくもない

893 ：login:Penguin：2018/12/25(火) 00:27:32.15 ID:DAdBnaIi.net

>>892
Dockerのイメージも単なる集積だけど？

894 ：login:Penguin：2018/12/25(火) 00:28:13.95 ID:FPaj6kyi.net

見る人が見れば真っ黒に近い黒だろうな。
例えばGNUの尊師が見たら完全にアウツだろ。

895 ：login:Penguin：2018/12/25(火) 00:29:54.04 ID:DAdBnaIi.net

Dockerのイメージがどういうふうに展開されてるのか知らないのかな？
単なるファイルとしてディスクに展開されてるんだけど

最終的にはLinuxのコンテナとして動いていて、コンテナがchrootを発展させたものって知っていれば
以下のリンク先の説明にあるように、とあるディレクトリ以下に展開されてるファイルを実行するだけって
わかるはずなんだが？

https://deeeet.com/writing/2013/12/16/where-are-docker-images-storede/

896 ：login:Penguin：2018/12/25(火) 00:32:10.44 ID:3aFn9L6f.net

>>895
仮にスタティックリンクではないと解釈できたとしても、実際に実行時には動的リンクしてるんでしょ
誰がどう見ても派生物だよ

897 ：login:Penguin：2018/12/25(火) 00:33:09.86 ID:DAdBnaIi.net

> 仮にスタティックリンクではないと解釈できたとしても、実際に実行時には動的リンクしてるんでしょ

だからその理屈を言ってしまうと、RedHatのISOイメージも
同じことになってしまうので、その矛盾を解決してから出直してきなって話

898 ：login:Penguin：2018/12/25(火) 00:33:40.09 ID:3aFn9L6f.net

>>897
だからGPLの「単なる集積」の条項を読んできなさい

899 ：login:Penguin：2018/12/25(火) 00:34:25.34 ID:DAdBnaIi.net

そもそもLinuxでパッケージが提供されているものだけを
使用すればGPL違反になりようがないんだよね

だからDockerコンテナ＝アプリ

900 ：login:Penguin：2018/12/25(火) 00:34:48.59 ID:DAdBnaIi.net

>>898
読んで問題がないことがはっきりしている

901 ：login:Penguin：2018/12/25(火) 00:38:53.20 ID:DAdBnaIi.net

はいどうぞ

「集積物」とそのほかの種類の「改変されたバージョン」の違いは何ですか?
https://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation

「集積物」はいくつかの別々のプログラムからなり、それらは同じCD-ROMやそのほかのメディアや "Dockerイメージ" に
いっしょに入れられて配布されます。GPLは集積物を作成し配布することを認めています。
たとえ、ほかのソフトウェアが不自由あるいはGPLと両立しないものである場合でもです。
ただ一つの条件は、あなたは、それぞれのプログラムの個別のライセンスが許す権限を
ユーザが行使することを妨げるような、あるライセンスのもとで集積物をリリースすることはできないということです。

二つの別々のプログラムと二つの部分の一つのプログラムを分ける線はどこにあるでしょうか?
これは法的な問題であり、最終的には裁判官が決めることです。わたしたちは、
適切な基準はコミュニケーションのメカニズム(exec、パイプ、rpc、共有アドレス空間での関数呼び出し、など)と
コミュニケーションのセマンティクス(どのような種の情報が相互交換されるか)の両方によると考えています。

モジュールが同じ実行ファイルに含まれている場合、それらは言うまでもなく一つのプログラムに結合されています。
CD-ROMやそのほかのメディアやDockerイメージは実行ファイルではありません
もしモジュールが共有アドレス空間でいっしょにリンクされて実行されるよう設計されているならば、
それらが一つのプログラムに結合されているのはほぼ間違いないでしょう。

逆に、パイプ、ソケット、コマンドライン引数は通常二つの分離したプログラムの間で
使われるコミュニケーションメカニズムです。ですからそれらがコミュニケーションの
ために使われるときには、モジュールは通常別々のプログラムです。
しかしコミュニケーションのセマンティクスが親密であったり、複雑な内部データ構造を交換したりする場合は、
それらも二つの部分がより大規模なプログラムに結合されていると考える基準となりうるでしょう。

902 ：login:Penguin：2018/12/25(火) 00:42:14.19 ID:DAdBnaIi.net

個々のファイルをあつめて、Dockerイメージにするだけでは
単なる集積物だろう。

903 ：login:Penguin：2018/12/25(火) 00:43:21.84 ID:3aFn9L6f.net

>>901
えっと、君のアプリはDockerイメージ内のGPLライブラリと動的リンクしてないの?w

904 ：login:Penguin：2018/12/25(火) 00:46:00.22 ID:DAdBnaIi.net

>>903
GPLライブラリとは動的リンクしてないけど？
動的リンクが許されるLGPLライセンスのものばかりだなぁ

GPLのものとは以下の分離したプログラム間でのコミュニケーションメカニズムを使うから問題ないし
> 逆に、パイプ、ソケット、コマンドライン引数は通常二つの分離した
> プログラムの間で使われるコミュニケーションメカニズムです。

これで結論出たよね？

905 ：login:Penguin：2018/12/25(火) 00:51:02.18 ID:DAdBnaIi.net

そもそもGPLのものを作ってるのであれば
別にGPLに感染した所で何の問題もないよね。

それから本当の目的は「Dockerコンテナ=アプリ」を否定したかったんじゃなかったの？
Dockerコンテナをアプリと読んでしまったらGPL感染する！とかいう謎理論でさ

906 ：login:Penguin：2018/12/25(火) 00:57:24.87 ID:DAdBnaIi.net

Dockerコンテナ＝アプリが気に食わなかったんだろうけど

結局、DockerイメージにするだけでGPL感染させられるか？という
話にしかなってなくて、そんなもんGPLライセンス読めば単なる集積物でしかない
Dockerイメージ（Linuxの機能のコンテナを実行するのに必要なファイルをまとめたもの）は
集積物として扱われるに決まってるし

最初のDockerコンテナ=アプリと何の関係もないし

どんな結論を目指したくてこの話を持ち出してきたのかわからんわ
┐(´ー｀)┌ﾔﾚﾔﾚ

907 ：login:Penguin：2018/12/25(火) 01:05:56.07 ID:XGHDmrXH.net

>>901
そのDockerイメージについての言及がリンク先に見当たらないんだけど、参考までにどこにあるか教えてほしい

908 ：login:Penguin：2018/12/25(火) 01:12:36.77 ID:DAdBnaIi.net

>>907
じゃあ君は、Dockerイメージがリンクに相当する言及するところを持ってきてくれ。
言い出しっぺなのだから、それぐらいやってから言うべきことだからな。

909 ：login:Penguin：2018/12/25(火) 01:32:32.10 ID:XGHDmrXH.net

>>908
あなたの提示した捏造元のFAQがコンテナを想定して書かれたものではない以上、可能性は排除できないでしょ
モジュール同士の結合が強すぎる場合は通信方式に関わらず単一の大きなプログラムを構成していると見做されるとも書いてあるよね
Dockerは単一の大きなアプリじゃなかったのかな

910 ：login:Penguin：2018/12/25(火) 01:35:15.16 ID:DAdBnaIi.net

Dockerは単一の大きなアプリだよ？

そしてスタティックリンクしてないし、動的リンクは
LGPLのものだけだからGPLの話と何の関係もないけど

二つの無関係な話をごっちゃにして何が目的なの？

911 ：login:Penguin：2018/12/25(火) 01:54:39.64 ID:FPaj6kyi.net

おまえらはGNUの精神を誤解してるよ。
お前のものは俺のもの、俺のものは俺のもの。
それがGNUだろ。

912 ：login:Penguin：2018/12/25(火) 01:58:42.97 ID:DAdBnaIi.net

GPLは俺のもの、バイナリ渡さなければソース公開の義務もないので
ウェブアプリでとっても便利に使えるもの

GPL感染を免れるためにリンクを行わずに
パイプでやり取りするのもよく使うテクニック

913 ：login:Penguin：2018/12/25(火) 04:04:44.72 ID:FPaj6kyi.net

秋元はAKBがオープンソースとか言ってたのに、AKBは全然GNUじゃないんだよな。
握手券をCDと偽って売りつけるのがオープンソースっぽいと言われれば、確かにそんな感じもするが。

914 ：login:Penguin：2018/12/25(火) 04:05:04.80 ID:WaQT3x/c.net

>>912
GPL感染を防ぐのにパイプでなんか渡す必要ないよ。アプリとして独立していればいいだけ。

915 ：login:Penguin：2018/12/25(火) 04:58:45.55 ID:DAdBnaIi.net

>>914
アプリじゃなくてプログラムな。↓こうかいてあるだろ

https://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation
> しかし多くの場合、GPLの及ぶソフトウェアをプロプライエタリ・システムと一緒に
> 配布することは可能です。これを妥当な形で行うには、自由なプログラムと
> 自由ではないプログラムとがそれぞれ独立を保った形でコミュニケートし、
> それらが事実上単一のプログラムとなってしまうような方法で結合されていないことを確認しなければなりません。

そして「プログラムとして独立」していると見なして良いものの一つが
（GPLのものと）パイプでやり取りするってことだろ

916 ：login:Penguin：2018/12/25(火) 05:10:28.17 ID:DAdBnaIi.net

あー、言っとくけど、ばれてないだろうと考えての無駄な努力はしなくていい。
「Dockerコンテナ = アプリ」をどうにか崩そうとして
なにかを「アプリ」に結びつけようとしてるのには気づいてるから
バレてる時点でその努力は無駄よ。

917 ：login:Penguin：2018/12/25(火) 19:02:35.08 ID:FPaj6kyi.net

GPLに感染したら村ごと焼き払わないと人類滅亡するからな。

918 ：login:Penguin：2018/12/25(火) 19:09:11.04 ID:3rvgWFVu.net

もうボケナスと腐れIBMのお陰で滅亡し掛かってるじゃん＞人類

919 ：login:Penguin：2018/12/25(火) 21:14:50.48 ID:51aJ/wRC.net

焼き払え！
どうした！それでも世界で最も邪悪な一族の末裔か！

920 ：login:Penguin：2018/12/25(火) 23:30:47.40 ID:p7mFW/Iu.net

なりきりトークはしんどい

921 ：login:Penguin：2018/12/26(水) 11:17:09.66 ID:g9SnL/ls.net

( ﾟдﾟ)====>☆

922 ：login:Penguin：2018/12/27(木) 14:19:41.89 ID:DBCGqnM6.net

Docker周りを調べてからWebサービス作ってみようかと思ってたけど後回しにする
小規模だし最初サービス作ってからでも遅くない気がしてきた

923 ：login:Penguin：2018/12/27(木) 14:20:31.02 ID:DBCGqnM6.net

ても開発環境だけでも幸せになれるかなぁ
まぁ後にしよう

924 ：login:Penguin：2018/12/27(木) 15:52:15.98 ID:eJNw9M2G.net

同時にすれば？
今日はこれ、明日はこれ。

925 ：login:Penguin：2018/12/27(木) 21:59:03.61 ID:yY7ptEAF.net

いっちょまえに開発開発いわないでWebページ制作といえ
それしかやってないんだからお前らわ

926 ：login:Penguin：2018/12/27(木) 22:24:05.54 ID:BHF4hV0J.net

Webページ制作なら大企業でもやるでしょう？

927 ：login:Penguin：2018/12/27(木) 22:34:07.05 ID:gPaHe1Uf.net

いやWebサイトなんか外部委託が普通だろ
自社でWebサービスやってる会社ですら、Webサイト制作などという底辺仕事を自社エンジニアにやらせるのは損失だから外部委託してたりするぞ

928 ：login:Penguin：2018/12/27(木) 22:36:55.93 ID:BHF4hV0J.net

ん？ お前の会社はエンジニアしかいない小さい会社なの？

929 ：login:Penguin：2018/12/27(木) 22:45:44.71 ID:gPaHe1Uf.net

500人くらいの会社だけど、コアでない業務を外部委託するのなんて普通だろ?
前にいた1000人くらいのSIerも当然外部委託だったよ

930 ：login:Penguin：2018/12/27(木) 22:54:57.99 ID:BHF4hV0J.net

ほーら言ってることが変わったｗ

Webサイトなんか外部委託が普通だろ
↓
コアでない業務を外部委託するのなんて普通だろ?


> それしかやってないんだからお前らわ
それしかやってないというのなら、それがコア業務ってことだよねｗ
矛盾している

931 ：login:Penguin：2018/12/27(木) 23:36:35.52 ID:gPaHe1Uf.net

>>930
そりゃWeb制作がコア業務の会社もあるだろう
で、Web制作を主業とする大企業ってどこ?

932 ：login:Penguin：2018/12/28(金) 00:01:03.25 ID:Xnr1TmZq.net

Web制作を主業とする大企業が今の話とどうつながるの？

933 ：login:Penguin：2018/12/28(金) 01:13:40.95 ID:VhG75zia.net

webサイトとwebサービスを一緒くたにしてると底辺と思われても仕方ないぞ。
webサイトにしても外注ですますって事は諸々の技術が賄えないってことだからwebサイト職人は高年収なんだなこれが。
ちなみにどこにでも底辺がある業界なのでブラックで雇われてるタイプ打ちの事は知らん。

934 ：login:Penguin：2018/12/28(金) 01:22:56.10 ID:R0nxxDdF.net

Web制作業界はゴミみたいな単価の案件を奪い合う地獄絵図やぞ
典型的なSIerのブラックなんかとは次元が違う

935 ：login:Penguin：2018/12/28(金) 17:09:23.59 ID:qmD+abh2.net

キノトロープ。

936 ：login:Penguin：2018/12/28(金) 17:22:03.84 ID:Xnr1TmZq.net

あなたが落としたのは、
キンノロープ ですか？それとも
キノロープですか？

937 ：login:Penguin：2018/12/31(月) 07:02:53.54 ID:Mnpi3suq.net

>>936
人月100万のゆるゆる案件です！

938 ：login:Penguin：2019/01/22(火) 06:03:33.55 ID:Xadxz8jN.net

Redhat製のdocker互換
rootやデーモン無しで動く
https://github.com/containers/libpod

939 ：login:Penguin：2019/01/22(火) 15:57:47.18 ID:a+JKiGWw.net

>>938
コレってRH系ならyumで入れられんだな

940 ：login:Penguin：2019/01/22(火) 16:29:21.28 ID:mcX40V8j.net

>>938
いきなりKubernetesにも対応してるのか
さようならDocker
このスレもこれで終わりだな

941 ：login:Penguin：2019/01/24(木) 21:26:05.75 ID:ILT9+sql.net

>>938
これってCoreOSの系譜？

942 ：login:Penguin：2019/01/24(木) 21:43:23.54 ID:ce56jNa3.net

>>941
違う
cri-oから分離したプロジェクト

943 ：login:Penguin：2019/01/24(木) 21:51:18.82 ID:ILT9+sql.net

じゃあCoreOSチームはよくて合流悪くて放逐か
浮かばれねえな

944 ：login:Penguin：2019/01/25(金) 10:41:56.04 ID:zAxqTMny.net

Dockerは売り時を逃したな
もう二束三文でMSに買収されてWindowsのコンポーネントになるしかない

945 ：login:Penguin：2019/01/25(金) 16:26:23.99 ID:pYl8jJjD.net

どっかー買いたいって言ってたトコあったんか？

946 ：login:Penguin：2019/01/25(金) 18:06:35.14 ID:zAxqTMny.net

買えるならAWSでもGoogleでもMSでもIBMでもどこでも買ってたでしょ
今となっては地獄の値下がりチキンレース不可避

947 ：login:Penguin：2019/01/25(金) 18:14:42.49 ID:Cp/Uwjnb.net

コンテナはdocker以外にも沢山あるからな
docker社の価値のメインはdockerよりdocker hubだろう

948 ：login:Penguin：2019/01/26(土) 20:34:37.29 ID:VvGtKHT8.net

>>946
MSは自社鯖製品にドッカー組み込んでるみたいだから買収するとしたら合理的かもだな
ホストwinなら他社と違ってかならずこの手のグルーコードが必要になるし

949 ：login:Penguin：2019/01/27(日) 11:43:05.14 ID:dbxVWXi/.net

デーモンを使わずにコンテナやポッドを実行可能：
Docker互換のオープンソースコンテナエンジン「Podman 1.0.0」が公開
http://www.atmarkit.co.jp/ait/articles/1901/25/news055.html

podmanってrktとはどう違うの？

950 ：login:Penguin：2019/01/27(日) 14:53:42.52 ID:fUS4TOTI.net

>>949
どっかのオタクが気紛れにつくったものなんてビジネスでは使い物になりません
その点、RedHat(IBM)ならエンタープライズクォリティの長期的なサポートが期待できます

951 ：login:Penguin：2019/01/27(日) 15:47:54.73 ID:00Tq2Umc.net

>>950
自分の責任では調査も満足にできず、
ベンダサポートが無いとダメなんでしょうね。

952 ：login:Penguin：2019/01/27(日) 15:53:07.04 ID:xXmMwFbM.net

>>949
>>938と同じモノだぬ
つかrktはKubernetes1.10でDeprecatedらしんで（ｒｙ

953 ：login:Penguin：2019/01/27(日) 19:07:09.00 ID:y2jdcPb5.net

>>938
rootなしで、privilleged できるのか？

954 ：login:Penguin：2019/01/28(月) 15:28:20.98 ID:syBmrriY.net

>>951
まさに給料ドロボーだなｗ

955 ：login:Penguin：2019/01/28(月) 22:36:41.23 ID:icVasB2F.net

>>951
自己責任で済む業態ならいいが、不具合起こしたときに客に損害賠償請求される仕事もあるんやで
ベンダーサポートを利用するのは、自分で調べればいいとかそういう問題ではなくてリスク移転が目的

956 ：login:Penguin：2019/01/29(火) 17:07:51.00 ID:Fyrpy00V.net

>>955
それはありますね。
ただ、ベンダを最初から持ち出す輩は、
ソースを調べようともせず、丸投げしているのがほとんどだとおもわれ。

957 ：login:Penguin：2019/01/29(火) 19:00:11.23 ID:hDvTFAkf.net

>>956
スレチだが、ベンダーに投げれば済むことをアホみたいに時間かけて自分で調査することが許されるのは相当恵まれた環境だと思うぞ
客に工数で金貰ってる仕事ならそんなの夢物語

958 ：login:Penguin：2019/01/30(水) 17:08:21.07 ID:njtuMnhH.net

>>955
ストレージでハマったさくらのクラウドはベンダにリスク移転できたか？

959 ：login:Penguin：2019/01/30(水) 18:23:41.63 ID:uRxIiy3K.net

費用って面ならあとから損害賠償請求すればいいだけでしょ？

960 ：login:Penguin：2019/01/30(水) 18:50:29.28 ID:njtuMnhH.net

すべてasisで提供されているのに損害賠償請求できるの？
んで実際ソレやったのか？

961 ：login:Penguin：2019/01/30(水) 21:14:55.35 ID:F5bN5PPB.net

そんなもん契約書次第だろ
議論の余地はない

962 ：login:Penguin：2019/01/30(水) 21:20:58.33 ID:F5bN5PPB.net

あとリスクって何も損害賠償だけじゃないぞ？
深刻な不具合が発生したときに自分で調査する羽目になった場合の所要工数もリスクだ
それをベンダーに丸投げできるならそれも正真正銘リスク移転だよ

963 ：login:Penguin：2019/01/30(水) 21:27:21.06 ID:gO6HjhZU.net

にじさんじの瀬戸メッチァ喋るやん

964 ：login:Penguin：2019/01/31(木) 19:04:28.51 ID:SEt2rCFr.net

>>961
結局損害賠償請求はできないってコトじゃん
ダメな時はダメ
そもリスク移転はできないとｗ
上っ面ダケのカッコつけマンばっかだなココｗｗｗ

965 ：login:Penguin：2019/01/31(木) 19:22:34.87 ID:oJr/deB/.net

実例とごちゃまぜにして語るキチガイがいるからなぁ

966 ：login:Penguin：2019/02/01(金) 16:12:43.36 ID:veleUfqn.net

オマエもパッチ当ててwinが腐ったトキはブツブツ言いながらOS再インスコしてんだろ？ｗ
毎回MSに損害賠償請求してんのか？そも出来んのか？
リスク転移はできない実例だらけじゃねえかｗ

967 ：login:Penguin：2019/02/02(土) 05:09:18.32 ID:qweRvoG8.net

サポートなんて問い合わせ先があるってだけ。責任転嫁なんてできるわけないんじゃん。
自分で調べられるんならいらないよ。

968 ：login:Penguin：2019/02/02(土) 07:18:16.99 ID:JrArb2fP.net

MSのサポートはすごいよな。
客「XXすると、こういう不具合が起きちゃうんだけど？」
MS「そういうことはしないでください。別の方法で実現してください。」
ごめん。元組み込み屋の愚痴でした。

969 ：login:Penguin：2019/02/02(土) 07:52:41.66 ID:3XhPu4nr.net

俺 バグがあるんだけど
MS 再現プログラム出してください
俺 はいこれ
MS お問い合わせの製品バージョンはサポート終了です
俺 再現プログラムは最新バージョンで再現するんだけど

970 ：login:Penguin：2019/02/02(土) 10:05:27.09 ID:cQdbYG8P.net

で最後の「俺」の発言に対する返答はどうなったんだよ

971 ：login:Penguin：2019/02/02(土) 13:06:15.28 ID:pCnn3K+7.net

最新版で出してくれとか、弊社側では再現しませんでしたと切られるのがオチでね

972 ：login:Penguin：2019/02/02(土) 16:43:13.68 ID:jUrf+AdQ.net

もしくはメール返答なしでバックレ

973 ：login:Penguin：2019/02/02(土) 16:47:04.08 ID:jUrf+AdQ.net

>>968
戴爾も笑えるぞ
viivロゴ貼ってるならHDDがNCQ対応じゃねえとダメじゃねえの？という質問に調査中のまま逃げ切りｗ

974 ：login:Penguin：2019/02/02(土) 16:57:43.71 ID:h6ieGB3B.net

>>971
再現しないとしたら誰がどうやって対応するの
「再現しませんでした」は「こっちとは無関係なお前独自の環境が原因なので何とかできるのはお前だけだ、俺に聞いてどうする？」を優しく言ってるだけ

975 ：login:Penguin：2019/02/02(土) 18:31:37.38 ID:dk7sB3r7.net

MS、Officeの不具合パッチ流すのやめてくれ

976 ：login:Penguin：2019/02/03(日) 05:44:12.80 ID:koSKauE2.net

>>970
最新版でも再現することをMSも確認した
そして最新版の修正もなく打ち切られた

977 ：login:Penguin：2019/02/03(日) 10:25:58.68 ID:dS0GyCMA.net

>>976
打ち切られた理由は？

978 ：login:Penguin：2019/02/03(日) 15:46:13.79 ID:kN2VjkXf.net

そらMSのツゴーだろうよｗ
聞くだけヤボってもんよ

979 ：login:Penguin：2019/02/19(火) 21:57:46.73 ID:U4Prz7TT.net

セキュアなコンテナランタイム「Kata Container」が、AWSのマイクロVM「Firecracker」をサポート。アプリごとに適切なコンテナランタイムを選ぶ時代へ
https://www.publickey1.jp/blog/19/kata_containerawsvmfirecracker.html

980 ：login:Penguin：2019/02/19(火) 23:02:10.34 ID:FQ6sC9Tr.net

kata containerってFirecrackerと同じレイヤーのランタイムだと思ってたけど違うのか

981 ：login:Penguin：2019/02/24(日) 20:56:46.61 ID:UW23N+WY.net

社内にswarmクラスタを組んだのですがvolumeはどのように扱うべきなのでしょうか
node1にappをdeployした場合appはnode1のvolumeをマウントます
ここでなんらかの理由でnode1がクラッシュしnode2でappが再起動した場合node1のvolumeはマウントできないので初期状態でappが起動してしまいます

982 ：login:Penguin：2019/02/25(月) 00:40:10.33 ID:BnMI4WRV.net

どこかしらの共有ストレージをマウントするようには設定できねえの？

983 ：login:Penguin：2019/02/25(月) 00:45:58.13 ID:BnMI4WRV.net

あとはどこかしらのオブジェクトストアを指定して初期化するような動作を組み込むとか

984 ：login:Penguin：2019/03/01(金) 15:29:53.96 ID:xrG1UD6E.net

swarmってオワコンじゃないの？

985 ：login:Penguin：2019/03/01(金) 16:24:25.69 ID:hJmOve+b.net

ドッカーだけでコンテナクラスタ構築するならswarmの方がとっつきやすくね

986 ：login:Penguin：2019/03/01(金) 17:48:52.38 ID:u7yAg4zl.net

クラスタ構築は楽だと思う
あとcomposeを再利用できる

987 ：login:Penguin：2019/03/02(土) 09:47:08.79 ID:hHUXJebU.net

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」を開始した。

988 ：login:Penguin：2019/03/02(土) 13:32:23.42 ID:HhtvgbJA.net

>　「Dockerを使った単一ノードのKubernetes v1.13.3クラスタは1GBを少し超える程度のメモリを使う。k3sの同一構成では260MBを少し超える程度で、これにはアップストリームのクラスタに含まれないingressコントローラーやサービスロードバランサーが含まれている」

260MBのメモリを積んでるIoT（）なの？ｗ

989 ：login:Penguin：2019/03/02(土) 14:03:16.12 ID:hHUXJebU.net

IoTってラズベリーパイとか？
512MB〜1GBはあるみたいだから余裕じゃね？

990 ：login:Penguin：2019/03/02(土) 14:45:17.96 ID:HhtvgbJA.net

なるほどな
最低でもラズπレベルがターゲットなんだな

991 ：login:Penguin：2019/03/03(日) 21:03:54.85 ID:V2hHzaOy.net

Kubernetesのmanifestの管理ツール「ksonnet」を使ってみた
https://qiita.com/inajob/items/7abe753a7c2c828230f9

これ何？くそねっと？

992 ：login:Penguin：2019/03/04(月) 06:10:55.52 ID:ncGnte76.net

ひでー名前だな

993 ：login:Penguin：2019/03/04(月) 16:35:31.51 ID:Bzh6FZoE.net

害人はマイナー言語つかう極東の住民になんか忖度しねえからな

994 ：login:Penguin：2019/03/04(月) 21:16:51.60 ID:wlTL6r9s.net

ケーソネットと読めばセーフ

995 ：login:Penguin：2019/03/07(木) 08:52:57.92 ID:8bFI1LrB.net

>>988
それはmaster/worker混在構成だからでしょ。
workerだけならもっと少ない。

996 ：login:Penguin：2019/03/07(木) 23:32:51.30 ID:iQ4RAsdJ.net

くそねっと

997 ：login:Penguin：2019/03/08(金) 08:09:45.99 ID:YU/9ulof.net

Docker RegistryをP2Pでスケーラブルに再構築した「Kraken」、Uberがオープンソースで公開
https://www.publickey1.jp/blog/19/docker_registryp2pkrakenuber.html

998 ：login:Penguin：2019/03/08(金) 10:18:13.00 ID:X6Yaxopy.net

>>940
> さようならDocker

その言葉、何年も前に聞いた気がする。
Dockerの代わりとなる、あれなんだっけ？
消えたのはあっちだったよなぁｗ

999 ：login:Penguin：2019/03/08(金) 10:20:52.92 ID:X6Yaxopy.net

>>988
>　「Dockerを使った単一ノードのKubernetes v1.13.3クラスタは1GBを少し超える程度のメモリを使う。

やっとメモリ使用量の問題についての話題が出たなーって感じ。
kubernetesをGCPの4GBぐらいもVMで使って、
おいおい、1/4もメモリ持っていくのかよ。
そこにサーバーいれなきゃいけないんだぞって呆れてた

1000 ：login:Penguin：2019/03/08(金) 10:23:07.74 ID:X6Yaxopy.net

訂正 kubernetesをGCPの4GBぐらい"の"VMで使って、
正確には3.75GBだっけな？

1001 ：login:Penguin：2019/03/08(金) 14:40:54.40 ID:VDOvuQ0J.net

Docker Part3
https://mao.5ch.net/test/read.cgi/linux/1552023620/

1002 ：2ch.net投稿限界：Over 1000 Thread

2ch.netからのレス数が1000に到達しました。