Docker Part2©2ch.net

**login:Penguin 転載ダメ©2ch.net** · 2017/09/28(木) 14:00:45.18

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

http://www.docker.io/

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

**login:Penguin** · 2017/09/28(木) 19:24:33.96

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

**login:Penguin** · 2017/09/29(金) 11:42:26.61

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

**login:Penguin** · 2017/09/30(土) 13:41:02.45

>>1
乙

**login:Penguin** · 2017/10/05(木) 08:50:48.55

>>1
乙

**login:Penguin** · 2017/10/09(月) 14:16:55.78

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

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

**login:Penguin** · 2017/10/11(水) 00:31:44.42

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

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

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

**login:Penguin** · 2017/10/12(木) 19:50:29.01

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

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

**login:Penguin** · 2017/10/24(火) 23:51:58.75

hoshu

**login:Penguin** · 2017/10/25(水) 00:04:46.37

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

**login:Penguin** · 2017/11/12(日) 21:27:42.49

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

**login:Penguin** · 2017/11/12(日) 21:43:45.89

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

**login:Penguin** · 2017/11/12(日) 22:36:56.33

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

**login:Penguin** · 2017/11/13(月) 01:31:56.29

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

**login:Penguin** · 2017/11/28(火) 15:53:23.01

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

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

**login:Penguin** · 2017/11/28(火) 23:02:15.82

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

**login:Penguin** · 2017/12/03(日) 18:48:03.66

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

**login:Penguin** · 2017/12/03(日) 21:33:00.17

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

**login:Penguin** · 2017/12/03(日) 23:00:47.39

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

**login:Penguin** · 2017/12/04(月) 08:15:53.87

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

**login:Penguin** · 2017/12/13(水) 11:04:20.12

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

**login:Penguin** · 2017/12/13(水) 16:46:00.16

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

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

**login:Penguin** · 2017/12/13(水) 23:30:05.47

>>21-22
枯れたOSでよく話が通じるな？
対応OS書いてあるんだから、それ使うだけじゃん

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

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

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

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

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

Dockerの古いバージョンならもう少し古いディストリでも動くかもな

**login:Penguin** · 2017/12/14(木) 02:05:22.37

俺、OpenSuseで使ってる変態。

**login:Penguin** · 2017/12/14(木) 09:58:33.91

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

**login:Penguin** · 2017/12/14(木) 13:39:44.17

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

**login:Penguin** · 2017/12/14(木) 16:57:21.98

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

**login:Penguin** · 2017/12/14(木) 18:00:17.09

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

**login:Penguin** · 2017/12/14(木) 19:26:56.48

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

**login:Penguin** · 2017/12/14(木) 22:49:08.96

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

**login:Penguin** · 2017/12/15(金) 00:48:35.66

CoreOSはもうねぇだろ

**login:Penguin** · 2017/12/15(金) 05:01:05.33

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

**login:Penguin** · 2017/12/15(金) 10:47:11.13

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

**login:Penguin** · 2017/12/15(金) 11:38:23.07

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

**login:Penguin** · 2017/12/15(金) 21:13:24.95

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

**login:Penguin** · 2017/12/15(金) 22:20:10.00

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

**login:Penguin** · 2017/12/17(日) 02:54:12.57

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

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

**login:Penguin** · 2017/12/17(日) 03:00:59.83

それ完全にvagrant用では？

**login:Penguin** · 2017/12/18(月) 00:14:34.47

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

**login:Penguin** · 2017/12/18(月) 08:24:13.84

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

**login:Penguin** · 2017/12/19(火) 12:43:18.15

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

**login:Penguin** · 2017/12/19(火) 15:47:37.58

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

**login:Penguin** · 2017/12/19(火) 18:27:38.96

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

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

**login:Penguin** · 2017/12/19(火) 21:21:37.08

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

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

**login:Penguin** · 2017/12/19(火) 21:29:10.23

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

**login:Penguin** · 2017/12/20(水) 01:46:37.73

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

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

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

**login:Penguin** · 2017/12/20(水) 08:11:34.55

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

**login:Penguin** · 2017/12/20(水) 09:16:28.83

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

**login:Penguin** · 2017/12/20(水) 11:24:05.90

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

**login:Penguin** · 2017/12/20(水) 15:46:11.75

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

**login:Penguin** · 2017/12/21(木) 07:55:01.09

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

**login:Penguin** · 2017/12/21(木) 20:10:57.04

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

**login:Penguin** · 2017/12/21(木) 20:41:31.20

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

**login:Penguin** · 2017/12/24(日) 22:37:12.09

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

**login:Penguin** · 2017/12/24(日) 22:40:54.12

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

**login:Penguin** · 2017/12/24(日) 22:58:36.30

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

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

**login:Penguin** · 2017/12/24(日) 23:14:23.88

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

**login:Penguin** · 2017/12/24(日) 23:22:26.32

>>57

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

**login:Penguin** · 2017/12/24(日) 23:52:48.02

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

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

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

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

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

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

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

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

**login:Penguin** · 2017/12/24(日) 23:57:01.81

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

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

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

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

それが大変な作業だった

**login:Penguin** · 2017/12/25(月) 00:07:51.54

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

**login:Penguin** · 2017/12/25(月) 00:11:59.89

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

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

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

**login:Penguin** · 2017/12/25(月) 11:30:09.88

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

**login:Penguin** · 2017/12/25(月) 15:39:08.55

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

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

**login:Penguin** · 2017/12/25(月) 23:01:24.32

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

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

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

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

**login:Penguin** · 2017/12/26(火) 01:41:07.93

>>59-62
これは永久保存レベル

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

**login:Penguin** · 2017/12/26(火) 03:02:30.31

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

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

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

**login:Penguin** · 2017/12/26(火) 03:07:47.91

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

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

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

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

**login:Penguin** · 2017/12/26(火) 10:06:07.39

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

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

**login:Penguin** · 2017/12/26(火) 11:22:56.05

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

**login:Penguin** · 2017/12/26(火) 12:31:53.02

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

**login:Penguin** · 2017/12/26(火) 23:42:23.56

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

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

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

**login:Penguin** · 2017/12/26(火) 23:58:14.94

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で使う必要がある

**login:Penguin** · 2017/12/28(木) 15:12:36.60

>>73
勉強になります

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

**login:Penguin** · 2017/12/28(木) 17:00:45.45

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

**login:Penguin** · 2017/12/28(木) 23:05:22.59

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以上のメモリを使用するのが気に入らない

**login:Penguin** · 2017/12/29(金) 12:41:26.85

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

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

PTHNS6LLYQ

**login:Penguin** · 2017/12/30(土) 19:21:43.13

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

**login:Penguin** · 2017/12/30(土) 21:07:01.76

Docker swarmが本命じゃないの？

**login:Penguin** · 2017/12/30(土) 23:02:49.87

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

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

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

**login:Penguin** · 2017/12/30(土) 23:41:06.85

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

**login:Penguin** · 2017/12/31(日) 03:26:38.05

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

**login:Penguin** · 2018/01/18(木) 10:27:56.69

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

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

**login:Penguin** · 2018/01/18(木) 17:40:21.34

なんでvirtualbox？

**login:Penguin** · 2018/01/18(木) 18:22:49.70

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

**login:Penguin** · 2018/01/18(木) 21:17:36.99

いつの話？

**login:Penguin** · 2018/01/18(木) 23:21:47.35

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

**login:Penguin** · 2018/01/30(火) 15:24:33.94

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

**login:Penguin** · 2018/01/30(火) 16:34:53.53

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

**login:Penguin** · 2018/01/31(水) 02:46:07.43

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

**login:Penguin** · 2018/02/01(木) 04:43:55.93

coreOSがRedHatに買収された

**login:Penguin** · 2018/02/02(金) 08:59:37.20

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

**login:Penguin** · 2018/02/03(土) 13:01:31.67

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

**login:Penguin** · 2018/02/03(土) 15:14:06.84

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

**login:Penguin** · 2018/02/05(月) 13:34:29.22

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

RUN yum list

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

**login:Penguin** · 2018/02/07(水) 01:28:24.21

>>95
Debian 使いだから勘違いしてる可能性が高いけどこういう感じで tee とかリダイレクトじゃダメなの？

$ cat Dockerfile
FROM centos

RUN yum list installed | tee yum.list
$ docker build -t yumlist .
~~snip~~
$ docker run --rm yumlist head -n5 /yum.list
Loaded plugins: fastestmirror, ovl
Installed Packages
acl.x86_64 2.2.51-12.el7 @CentOS
audit-libs.x86_64 2.7.6-3.el7 @CentOS
basesystem.noarch 10.0-7.el7.centos @CentOS

**login:Penguin** · 2018/02/08(木) 17:41:54.10

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

**login:Penguin** · 2018/02/14(水) 02:35:31.11

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

**login:Penguin** · 2018/02/15(木) 00:59:03.05

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

**login:Penguin** · 2018/02/15(木) 12:06:04.40

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

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

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 02:24:38.22

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 02:25:38.04

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 02:32:17.59

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

**login:Penguin** · 2018/03/11(日) 02:47:30.63

>>101
使っていませんｗ

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

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

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

**login:Penguin** · 2018/03/11(日) 02:55:22.05

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

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

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

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

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 03:31:17.92

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

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

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

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

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 03:33:10.76

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 03:47:31.86

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

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

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

**login:Penguin** · 2018/03/11(日) 04:16:58.61

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

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

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

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

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

**login:Penguin** · 2018/03/11(日) 04:26:48.50

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

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

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

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 04:40:50.71

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

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

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

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

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

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

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 04:55:20.38

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

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

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

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 05:13:32.25

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

**login:Penguin** · 2018/03/11(日) 11:20:29.98

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

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

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

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

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

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

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

**login:Penguin** · 2018/03/11(日) 11:22:42.29

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

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

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

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

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

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

**login:Penguin** · 2018/03/11(日) 11:30:56.88

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

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

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

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

みたいなな。

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

**login:Penguin** · 2018/03/11(日) 11:48:05.06

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 15:33:16.62

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

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

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 15:34:04.20

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

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

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

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

**login:Penguin** · 2018/03/11(日) 15:53:28.62

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 16:11:14.24

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

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

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

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

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

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

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

**login:Penguin** · 2018/03/11(日) 16:12:01.95

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

そいう話じゃなくて

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

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

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

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

**login:Penguin** · 2018/03/11(日) 16:38:27.85

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

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

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

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

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 16:50:49.20

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

**login:Penguin** · 2018/03/11(日) 16:57:53.92

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

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

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

**login:Penguin** · 2018/03/11(日) 16:59:24.31

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

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 19:29:40.88

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

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

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

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

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

塩水 ◆1FrMT.vzQQ · 2018/03/11(日) 19:43:24.47

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

**login:Penguin** · 2018/03/11(日) 21:42:47.19

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 無しでイメージテストができたり、メンテナの反応も速いしコードも読みやすい。
今後ちゃんと出来上がれば化けるかも

**login:Penguin** · 2018/03/11(日) 23:36:05.79

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

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

**login:Penguin** · 2018/03/12(月) 00:00:41.81

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

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

**login:Penguin** · 2018/03/12(月) 00:09:31.95

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

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

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

**login:Penguin** · 2018/03/12(月) 00:13:02.11

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

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

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

**login:Penguin** · 2018/03/12(月) 01:17:08.47

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

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

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

**129** · 2018/03/12(月) 01:34:06.50

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

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

**login:Penguin** · 2018/03/12(月) 01:36:17.28

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

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

**login:Penguin** · 2018/03/12(月) 01:47:41.96

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

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

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

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

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

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

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

**login:Penguin** · 2018/03/12(月) 13:05:39.78

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

**login:Penguin** · 2018/03/12(月) 21:57:46.32

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

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

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

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

**login:Penguin** · 2018/03/13(火) 06:36:13.77

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

**login:Penguin** · 2018/03/19(月) 12:18:33.64

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

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

**login:Penguin** · 2018/03/21(水) 17:17:07.53

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

**login:Penguin** · 2018/03/26(月) 16:00:04.53

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

**login:Penguin** · 2018/03/26(月) 16:24:25.96

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

**login:Penguin** · 2018/04/03(火) 07:43:27.59

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

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

**login:Penguin** · 2018/04/03(火) 23:16:59.76

随分古いな。

**login:Penguin** · 2018/04/03(火) 23:44:51.96

>>145
従いますよ

**login:Penguin** · 2018/04/20(金) 13:08:52.09

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

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

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

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

■dockerfileの内容
From jupyter/datascience-notebook
RUN pip install --upgrade pip
RUN pip install tensorflow==1.5

**login:Penguin** · 2018/04/20(金) 22:27:51.02

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

**login:Penguin** · 2018/04/21(土) 10:25:09.06

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

**login:Penguin** · 2018/04/21(土) 13:23:47.70

>>150
numpyって知ってる？

**login:Penguin** · 2018/04/21(土) 13:46:33.79

なんぱい？

**login:Penguin** · 2018/04/21(土) 17:21:10.71

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

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

**login:Penguin** · 2018/04/21(土) 19:53:43.47

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

**login:Penguin** · 2018/04/22(日) 09:15:07.32

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

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

**login:Penguin** · 2018/04/22(日) 19:07:10.00

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

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

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

**login:Penguin** · 2018/04/22(日) 19:23:31.15

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

**login:Penguin** · 2018/04/22(日) 23:46:18.23

「docker hub tensorflow」で検索！

**login:Penguin** · 2018/04/23(月) 03:34:29.66

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

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

**login:Penguin** · 2018/04/23(月) 06:37:04.24

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

RUN pip install tensorflow==1.5

**login:Penguin** · 2018/04/23(月) 10:45:26.96

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

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

**login:Penguin** · 2018/05/22(火) 07:23:12.42

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

EAAD8

**login:Penguin** · 2018/05/22(火) 11:47:01.72

EAAD8

**login:Penguin** · 2018/05/27(日) 18:22:16.75

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

**login:Penguin** · 2018/05/28(月) 20:34:50.01

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

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

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

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

**login:Penguin** · 2018/05/28(月) 21:14:26.05

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

**login:Penguin** · 2018/05/28(月) 21:25:11.53

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

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

**login:Penguin** · 2018/05/28(月) 21:47:04.72

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

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

**login:Penguin** · 2018/05/28(月) 22:02:15.83

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

**login:Penguin** · 2018/05/28(月) 22:13:34.15

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

**login:Penguin** · 2018/06/03(日) 15:52:37.21

sage

**login:Penguin** · 2018/06/24(日) 08:47:17.87

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

**login:Penguin** · 2018/06/24(日) 22:35:20.55

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

**login:Penguin** · 2018/06/25(月) 05:44:34.47

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

**login:Penguin** · 2018/06/25(月) 09:42:17.00

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

https://stackoverflow.com/a/39329138

**login:Penguin** · 2018/06/25(月) 09:49:22.67

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

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

**login:Penguin** · 2018/07/01(日) 03:55:45.96

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

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

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

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

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

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

**login:Penguin** · 2018/07/01(日) 09:04:34.19

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

**login:Penguin** · 2018/07/01(日) 09:21:20.95

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

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

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

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

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

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

**login:Penguin** · 2018/07/01(日) 09:23:55.84

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

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

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

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

**login:Penguin** · 2018/07/02(月) 19:23:28.69

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

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

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

**login:Penguin** · 2018/07/02(月) 20:07:43.00

社内の人に聞け

**login:Penguin** · 2018/07/02(月) 20:45:02.37

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

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

**login:Penguin** · 2018/07/03(火) 00:50:17.25

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

**login:Penguin** · 2018/07/03(火) 00:52:28.72

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

**login:Penguin** · 2018/07/03(火) 02:50:11.95

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

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

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

**login:Penguin** · 2018/07/03(火) 05:53:39.58

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

**login:Penguin** · 2018/07/03(火) 06:10:23.01

>>186
なんの苦労もなくhomebrewを使いたいなら
Macを他に人に使わせるな。そしてクリーンインストールして
自分ひとりのものとして使え

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

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

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

homebrewの設計自体はsudoを使わない方針なんだが
https://docs.brew.sh/FAQ#why-does-homebrew-say-sudo-is-bad
じゃあ共有のディレクトリ/usr/localを使うなと

**login:Penguin** · 2018/07/03(火) 06:28:04.40

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

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

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

**login:Penguin** · 2018/07/03(火) 06:35:07.67

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

**login:Penguin** · 2018/07/03(火) 06:54:24.03

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

**login:Penguin** · 2018/07/03(火) 07:12:51.42

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

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

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

**login:Penguin** · 2018/07/03(火) 11:19:37.64

解決しました

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

**login:Penguin** · 2018/07/03(火) 13:54:24.15

何度もすいません

docker-compose up -d

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

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

**login:Penguin** · 2018/07/03(火) 14:20:45.35

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

**login:Penguin** · 2018/07/04(水) 02:14:06.32

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

**login:Penguin** · 2018/07/04(水) 06:04:14.37

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

**login:Penguin** · 2018/07/07(土) 17:30:55.41

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

**login:Penguin** · 2018/07/07(土) 21:06:35.47

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

**login:Penguin** · 2018/07/07(土) 21:59:02.61

イシキダケタカイケイ