17/09/28 14:00:45.18 /4TtIqGt.net
LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。
URLﾘﾝｸ(www.docker.io)
前スレ
Docker
ｽﾚﾘﾝｸ(linux板)
2:login:Penguin
17/09/28 19:24:33.96 pP51x30K.net
もうLXCに依存してないんじゃ？
3:login:Penguin
17/09/29 11:42:26.61 /O2TcHk2.net
そうだね
前スレからそのまま持ってきてしまったか
4:login:Penguin
17/09/30 13:41:02.45 DWXPURAf.net
>>1
乙
5:login:Penguin
17/10/05 08:50:48.55 i7Czn2dk.net
>>1
乙
6:login:Penguin
17/10/09 14:16:55.78 XfEexTHm.net
本番系のマシンと、Docker動かしてるホストとで、カーネルのバージョンって
みなさんどこまで合わせてます?
うちはRHELで動いてる本番系と、それとコピーの総合試験環境があって、
そいつらはカーネルもパッケージもバージョン揃えてあるんだけど、
その手前の、コーディングとか単体試験とかをやるコンテナ動かすDockerのホストも
やっぱしカーネルのバージョン揃えるべき?
7:login:Penguin
17/10/11 00:31:44.42 pRpQhrR6.net
>>6
うちは本番系から単体試験ホストまですべてカーネル揃えることにしてるよ
Docket導入前だったけど、errataレベルの違いでI/Oスケジューラだったかの挙動が変わったことがあってね
理想はどうあれ、揃えておきなよ <
8:login:Penguin
17/10/12 19:50:29.01 2wGdxaeV.net
本番系と、カーネルだけ揃えておけばいつでもコンテナ作れるっていうのが仮想マシンに対するDockerの大きな利点
カーネルをバージョンアップしてコンテナが壊れたんならさっさと作り直す、さっさと作り直せるように周辺の仕組みを整える、
消されて困るコンテナは作らない、他とカーネルを揃えられないコンテナも作らない、なんてことがDockerカンファレンスでも
強く言われてた
9:login:Penguin
17/10/24 23:51:58.75 dIybMC7m.net
hoshu
10:login:Penguin
17/10/25 00:04:46.37 G0dNcMaK.net
Arukas終わったしもう遊べる場所はないのかな
GCPは制限ありそうだし
11:login:Penguin
17/11/12 21:27:42.49 uiCH3XRM.net
Linux板で言うことじゃないかもしれないけどWindowsでもHyper-Vで使えるようになってたんだな
Bash on UbuntuにDockerも使えてWindowsPC強制されて虐げられてもなんとかなるぜ
12:login:Penguin
17/11/12 21:43:45.89 CsnX2d3s.net
＞WindowsでもHyper-Vで使えるようになってた
Windows以外で使えるHyper-Vなんてあるの？
13:login:Penguin
17/11/12 22:36:56.33 uiCH3XRM.net
VirtualBoxが不要ってことを言いたかった
14:login:Penguin
17/11/13 01:31:56.29 6Li+kjAO.net
HyperV無しのWSLで動くようになる予定はあるのかな
MobyとかLinuxKitとか出てきたし
15:login:Penguin
17/11/25 20:25:09.37 NaxBhckIx
再帰的なmountってどうやればいい？
docker-composeのvolumesでmountすると、直接指定したディレクトリの中身は見れるのだけど、そのサブディレクトリが見れない。
16:login:Penguin
17/11/28 15:53:23.01 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
17/11/28 23:02:15.82 l6qc+Qst.net
docker imagesってやったらどうでるの？
18:login:Penguin
17/12/03 18:48:03.66 zS+bJMf6.net
docker使うとこ増えたけど
アホって綺麗なサンプルいっぱいあるのになぜか設定ファイルグチャグチャ作るのな
結局構成管理出来ないだろ、あんなんじゃ
19:login:Penguin
17/12/03 21:33:00.17 0hG1CDG4.net
Dockerで設定ファイル？何の話だ？
Dockerで構成管理？何の話だ？
お前なんか勘違いしてそうだな
20:login:Penguin
17/12/03 23:00:47.39 +8H++mo7.net
まあ言いたいことはわかるよ
それだって秘伝のシェルスクリプトを書き足すよりはずっといいさ
21:login:Penguin
17/12/04 08:15:53.87 5eeXMq5z.net
AWS Fargateってサービスがアマゾンからリリースされたらしいけど
それってなんなの？
22:login:Penguin
17/12/13 11:04:20.12 ZUZ9fAW9.net
docker系の技術は日進月歩すぎるのでredhatやcentosのような枯れたOSで使うのはきついですよね？
色々入れたり設定が必要だし。
お勧めなディストリはやはりubuntuやfedoraなどですか？
23:login:Penguin
17/12/13 16:46:00.16 4HtuxJmh.net
>>22
docker自体は日進月歩すぎるところがあるので、OSは枯れたモノを使うというのがベストプラクティス
fedoraでdocker運用するのって、fedoraのカーネル自体が不安定すぎて、コンテナ上げすぎると落ちたりするよ
24:login:Penguin
17/12/13 23:30:05.47 CbAdTCk+.net
>>22-23
枯れたOSでよく話が通じるな？
対応OS書いてあるんだから、それ使うだけじゃん
URLﾘﾝｸ(docs.docker.com)
Artful 17.10 (Docker CE 17.11 Edge only)
Zesty 17.04
Xenial 16.04 (LTS)
Trusty 14.04 (LTS)
URLﾘﾝｸ(docs.docker.com)
Buster 10 (Docker CE 17.11 Edge only)
Stretch 9 (stable) / Raspbian Stretch
Jessie 8 (LTS) / Raspbian Jessie
Wheezy 7.7 (LTS)
URLﾘﾝｸ(docs.docker.com)
To install Docker CE, you need a maintained version of CentOS 7. Archived versions aren’t supported or tested.
URLﾘﾝｸ(docs.docker.com)
25
26
URLﾘﾝｸ(docs.docker.com)
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
17/12/14 02:05:22.37 j6ffG0Yu.net
俺、OpenSuseで使ってる変態。
26:login:Penguin
17/12/14 09:58:33.91 RtRhmnJE.net
Redhat/CentOSはカーネル古いから新しいバージョンのdocker composeが使えないよ
27:login:Penguin
17/12/14 13:39:44.17 A3qqyatV.net
>>26
そんな制限あったっけ？
どこかに書いてある？
28:login:Penguin
17/12/14 16:57:21.98 c0bTjVEo.net
GUIいらないからホストOSも軽くて無駄がないalpineにするのが好き
ほとんど何もできないから逆に後腐れなく気軽に捨てて新しくできるし！
29:login:Penguin
17/12/14 18:00:17.09 mi3pWGl2.net
俺はホストにはfedora atomic使ってるぞ
30:login:Penguin
17/12/14 19:26:56.48 xIrkk8hS.net
なんかlinuxがいいものになったかのような錯覚をおこすわ
31:login:Penguin
17/12/14 22:49:08.96 j6ffG0Yu.net
coreosで使ってるっていう生粋のドッカーはいないのか？
32:login:Penguin
17/12/15 00:48:35.66 1RLgszdT.net
CoreOSはもうねぇだろ
33:login:Penguin
17/12/15 05:01:05.33 gXJiZmqG.net
coreOSってalpine以上に使いにくくて何が良いの？って感じなんだけど何か取り柄はあるのかね
34:login:Penguin
17/12/15 10:47:11.13 pk6RU5gE.net
RancherOSが出たときコレは来るかと思ったがそうでもなかった
35:login:Penguin
17/12/15 11:38:23.07 Goys0rX2.net
雨後の筍のようにポコポコ出てくるな
はやく収斂してくれ
36:login:Penguin
17/12/15 21:13:24.95 QXRMWfvA.net
そいつらがい�
37:ｸれ、どうにもつまらない理由で内輪もめを起こしてまとまらなくなり あの機能はそちらにしかない、その機能はあちらにしかない、なんて状況となってる間に OracleやMSに持っていかれる、というところまでがテンプレ
38:login:Penguin
17/12/15 22:20:10.00 7toohCc2.net
誰かが早く僕の考えた最強Linuxを発表しないとな。
え、それが乱立してるって？
39:login:Penguin
17/12/17 02:54:12.57 fi9E8CtD.net
BargeっていうのがDockerホスト用で最軽量・高速ブートをうたってるけど
これVirtualBox専用でノートPCとかには直接インスコできないのかな？
更新頻度は高いみたいだから物理マシンでも動けば最強候補じゃないかコレ
40:login:Penguin
17/12/17 03:00:59.83 FdcUbRUW.net
それ完全にvagrant用では？
41:login:Penguin
17/12/18 00:14:34.47 V88qic40.net
RaspberryPiで使えますみたいなことは書いてあるね
普通には使えないっぽいのは何か残念だな
42:login:Penguin
17/12/18 08:24:13.84 5bGVyFGG.net
やっぱubuntu + kubernetesがいいのかな
43:login:Penguin
17/12/19 12:43:18.15 Unb97h+7.net
これからはなんでもかんでもコンテナって時代になるのですかね？
自前でリポジトリをシコシコ築いてきたディストリベンダーも
もはややる意義を失っちゃったりするんですかね？
44:login:Penguin
17/12/19 15:47:37.58 mHmneXcK.net
未だにコンテナとchrootの違いが理解できない
45:login:Penguin
17/12/19 18:27:38.96 JOmZ8i6e.net
chはchangeの頭文字から取っているから
rootの変更って意味だろう
コンテナはOS内にあるけど完全に独立しているから
例えばある家族の家の中で、
親がroot
子供がchroot
ホームスティしてきた外国人娘がコンテナだ
46:login:Penguin
17/12/19 21:21:37.08 qjPggouG.net
>>42
コンテナ使い出すと便利すぎてディストリあれこれこだわってたのが笑えてくるほどだね
そして指摘の通り、独自にバグ潰しとかやってる一番活発なリポジトリ持ってるところと
逆に古いツールを保守し続けてるところはもてはやされてるが、それ以外が意気消沈してる
二極化だな
47:login:Penguin
17/12/19 21:29:10.23 qsrDOXqO.net
リソースが集中するのはいいことではあると思う
48:login:Penguin
17/12/20 01:46:37.73 W5Cyms8a.net
パッケージ管理ツールをLSB前提でpythonやperlで書いてたところは
それが原因でコンテナイメージのサイズをある一定以下に削減できなくてイーッてなってた
かと言ってパッケージマネージャーは各ディストリのシステムに根深く食い込んでるから
切り離そうにも切り離せない・・・最近じゃsystemdの呪縛もあるだろうし
でもまさかパッケージを単品ごとにインスコする日が来るとは誰も思ってなかったんだよな結局は
49:login:Penguin
17/12/20 08:11:34.55 XbCsAUuJ.net
コンテナってもっと早く登場しても良かった気がするんだが
技術的にはホスト型ハイパーバイザ型の仮想化よりも簡単なんじゃないの？
50:login:Penguin
17/12/20 09:16:28.83 G/qWb3nN.net
そりゃ日本での常識だな、
日本は金持ちだから高性能コンピューターが当たり前だけど
世界的にはようやく高性能コンピューターが
51:普及してきた ようやっとOS内にOSをおいても通常に使えるぐらいのPCが普及してきたんだ
52:login:Penguin
17/12/20 11:24:05.90 XXomYUaW.net
それはひょっとしてギャグで言ってんのか
53:login:Penguin
17/12/20 15:46:11.75 ZRehS3G5.net
コンテナは昔からあっただろ
Linuxに来るのが遅かっただけで
54:login:Penguin
17/12/21 07:55:01.09 9tWXeT0T.net
user mode linuxはコンテナに入りますか?
55:login:Penguin
17/12/21 20:10:57.04 K3jlwK7o.net
コンテナ内のプロセスがしんで終了しても自動でコンテナ再起動してくれるオプションがあった
コレ使えばわざわざプロセス死活監視用ツール起動しなくて良くなるのか
ちょっとスゴ杉ない？
56:login:Penguin
17/12/21 20:41:31.20 dn2463i7.net
そんなもんsystemdに標準搭載されてる機能だろ
57:login:Penguin
17/12/24 22:37:12.09 rLGBbeuy.net
dockerコンテナってホストOSのカーネル使ってるの？
どこもそう説明してるんだけど、ベースイメージにlinuxつかってその上にmysqlとか載せてイメージ化してるって認識だったんだが。
58:login:Penguin
17/12/24 22:40:54.12 BfGqUwPY.net
ホストのカーネルを使っているという説明で合っているよカーネルの上で動かすカーネルとかもうそれVMじゃん
59:login:Penguin
17/12/24 22:58:36.30 rLGBbeuy.net
>>56
ありがと。
そうなるとwindowsだとdockerインストール出来るけど、エンジンとかに工夫してあるのか
URLﾘﾝｸ(www.slideshare.net)
ここの19ページめに、ベースイメージにイメージ層を載っけていくて記載あるけど、
これは間違ってるの？
60:login:Penguin
17/12/24 23:14:23.88 jQND+IMW.net
URLﾘﾝｸ(www.publickey1.jp)
こういうのじゃね？
61:login:Penguin
17/12/24 23:22:26.32 rLGBbeuy.net
>>58
URLﾘﾝｸ(github.com)
mysqlのdockerfileだと FROM debian:jessie ってあるけど、
これはどうなの？？
何かこんがらがってきた。
sshで入れるし、やっぱ根底はlinux立ち上がってるのか？
62:login:Penguin
17/12/24 23:52:48.02 FG7A/gM3.net
おい、素人同士で勝手に話をすすめるなｗ
>>56
> カーネルの上で動かすカーネルとかもうそれVMじゃん
VM=仮想マシン＝マシン（ハードウェア）を仮想化してないならVMにはならない
>>55
> dockerコンテナってホストOSのカーネル使ってるの？
そもそもホストとかゲストとかいうものがない
Linuxっていうのはカーネル（URLﾘﾝｸ(www.kernel.org) で配布しているやつ）に
DebianやらUbuntuやらRedhatなんかが、いろんなアプリをセットにして配布してる
カーネルは基本的に汎用。だから同じカーネルを使っても
DebianやCentOSなんていう別のディストリが作れる
さてパソコンにDebianをインストールしたとする。そこにはカーネルといろんなアプリが有るわけだが
Dockerで作ったDockerコンテナはこのうちカーネルだけを利用する。
例えばFROM debian:jessieであれば、debian:jessieのディスクイメージを使うと考える
そのディスクイメージにはもしかしたらカーネルのバイナリも含まれてるかもしれないがそれは使わない。
パソコンにインストールしてあるカーネル + FROMの元になったディスクイメージ を使ってアプリを動かす
そんなもんだから、Debianをインストールしていたとしても、UbuntuやCentOSのディスクイメージを使うこともできる
63:login:Penguin
17/12/24 23:57:01.81 FG7A/gM3.net
パソコンにインストールしたカーネルを使う。
そこで疑問になるかもしれない。
幾つものDockerコンテナが同じカーネルを使っているとしたら
psコマンドでプロセス見た時、他のコンテナのプロセスまで見えてしまわないのか？と
そこで出てくるのがLinuxカーネルに搭載されたコンテナ機能
この機能によって各コンテナは別々に隔離されることになる
同じカーネルを使っているというのに、それぞれ別々の環境を持っているようにみえる
ファイルシステム空間を分離したり、プロセス空間を分離したり、
メモリ空間を分離したり、ネットワーク空間を分離したり
ありとあらゆるものを分離して独立した環境を作り出している
それが大変な作業だった
64:login:Penguin
17/12/25 00:07:51.54 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の設定画面にはメモリをどれだけ仮想マシンに割り当てるかなどという設定が存在する
65:login:Penguin
17/12/25 00:11:59.89 132x0Uuj.net
余談だがWindows 10ではWSLという仕組みによって
LinuxカーネルをNTカーネルでエミュレートしている
今ではLinuxカーネルを使っていないのにUbuntuが
Windows上で動作するようになっている。
もしこのWSLがコンテナ機能までエミュレートする完璧なものになったら
その時はWindowsでHyperVを使わずにDockerが動くようになるだろう
66:login:Penguin
17/12/25 11:30:09.88 +uvKLng+.net
>>63
親切すぎて草
下手な記事よりわかりやすい
67:login:Penguin
17/12/25 15:39:08.55 h9oxS0er.net
＞もしこのWSLがコンテナ機能までエミュレートする完璧なものになったら
なるのかね？
最近MSがLinuxに擦り寄ってて気持ち悪い
68:login:Penguin
17/12/25 23:01:24.32 gZwRVfZh.net
>>63
帰ってきたらすごい丁寧なレス来てたっ
ありがとうございます
> 例えばFROM debian:jessieであれば、debian:jessieのディスクイメージを使うと考える
> そのディスクイメージにはもしかしたらカーネルのバイナリも含まれてるかもしれないがそれは使わない。
URLﾘﾝｸ(github.com)
たしかにamazon linuxの中見ると、コマンドとかは設置してるけど/boot のカーネルとかは置いてなかったわ
windows, macも結局裏では仮想化されてたのね
色々わからなかった所が一遍にわかったわ！
69:login:Penguin
17/12/26 01:41:07.93 SZApAg+E.net
>>60-63
これは永久保存レベル
Github上のissueでもWSLだけでLinuxコンテナ動かしたいって要望はかなり挙げられてて
MSスタッフからみんなの期待は認識してますってレスも付いてた
もしホントに実現したら世界が変わる！みたいな投稿もあって大げさだけどちょっと同意しちゃう
70:login:Penguin
17/12/26 03:02:30.31 +n8uGZb5.net
>>60-63を書いた本人だけど、なんでこんなに喜ばれてるんだろう？ｗ
WindowsやMacOSでDocker使ってる人にとっては常識だと思ったんだけどね
最近MacOSでDocker使ってる人なのかな？
昔はVirtualBoxのインストールが必要だし
今もWindowsならHyperVの有効化が必要
仮想マシンが使われてるのはすぐにわかると思ったんだけど
あと仮想化という言い方は良くない
色んな意味の仮想化があるから
71:login:Penguin
17/12/26 03:07:47.91 +n8uGZb5.net
WindowsやMacOSで使った時のDockerのボリュームって謎だよね
例えばWindowsでdockerコマンド使った時、Windowsのディレクトリを
ボリュームとして指定すれば、dockerコンテナの中から見える
Linuxでは当たり前の動作だけど、WindowsやMacOSでは仮想マシンで
dockerが動いてるのだから、単純に考えれば仮想マシンの中にボリュームができるはず
まあホストOSのディレクトリを仮想マシンのディレクトリにマッピングしてるんだろうけど
Docker for WindowsやDocker for Macではそういうことを感じさせない作りになってる
72:login:Penguin
17/12/26 10:06:07.39 4aRFRiu5.net
vagrant入れて色々弄ってた後にdockerやったから全然気付かなかった
職場macで家はwindowsで、両方vagrant入れてたしね
ネットで調べても、その手の情報全然見なかったよ
本読んで勉強しろって話なのかな？
73:login:Penguin
17/12/26 11:22:56.05 pkkjJJya.net
>>68
自分は初心者なのでナイスな解説に出会えてラッキーでした
ありがとう
74:login:Penguin
17/12/26 12:31:53.02 KRPyxQju.net
俺も最近、Docker for Windows入れてみてたばかりなんで、HyperVが必要な理由とかが分かって参考になった
75:login:Penguin
17/12/26 23:42:23.56 +n8uGZb5.net
> ネットで調べても、その手の情報全然見なかったよ
> 本読んで勉強しろって話なのかな？
そうなんか？ じゃあなんで俺知ってるんだろう？ｗ
もう3年ぐらい前から触ってるからなぁ。当時はWindows使っていたし（今はMacOS）
まあ普通DockerってLinuxで使うもんな。Dockerの解説といったら普通Linux上の話だし
WindowsやMacOSでどうやって使えるようにしているのかまでは関係ないか
じゃあおまけでもう少し仕組みの話を。
76:login:Penguin
17/12/26 23:58:14.94 +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で使う必要がある
77:login:Penguin
17/12/28 15:12:36.60 LWC+fC47.net
>>74
勉強になります
最近はOS、仮想化、dockerと色々と入り乱れて全体像を理解するのに苦労するなぁ
ま、所詮パンピーですから
78:login:Penguin
17/12/28 17:00:45.45 +qKarqEU.net
dockerとkubernetes使いこなせないと時代遅れになるぞって言われたけど
一般の開発者がkubernetesを必要とするシーンってどのくらいあるのかな
dockerは問答無用で便利だけど
79:login:Penguin
17/12/28 23:05:22.59 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以上のメモリを使用するのが気に入らない
80:login:Penguin
17/12/29 12:41:26.85 S/CsVkMC.net
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
PTHNS6LLYQ
81:login:Penguin
17/12/30 19:21:43.13 kIwYFCo/.net
kubernetesはほぼ全部の業界大手が参画してるけど
そんでもコケるってことあるんかな
いやまぁ莫大な金が動くインフラ業界だからねぇ
82:login:Penguin
17/12/30 21:07:01.76 /wpJUWvV.net
Docker swarmが本命じゃないの？
83:login:Penguin
17/12/30 23:02:49.87 R3GCT2Hw.net
>>80
もうフェードアウトフェーズだよｗ
DockerもついにKubernetesをネイティブでサポート、Swarmの併用も可能
URLﾘﾝｸ(jp.techcrunch.com)
しばらくはswarmでもできる！とかやるだろうけど
次第にフェードアウト
84:login:Penguin
17/12/30 23:41:06.85 4E+qMbRD.net
小規模ではdocker-compose一択って事でおk？
85:login:Penguin
17/12/31 03:26:38.05 AHTq9Vf1.net
小規模っていうか、1台のマシンの場合って考えてるよ
開発用メインでdocker runのオプションを指定するのが
面倒になった時ｗ
86:login:Penguin
18/01/18 10:27:56.69 edyLm1wn.net
Docker toolboxの最新版（18.01.0-ce
87:）を入れたら何故かdockerのデーモンに接続できなくなったけど VirtualBoxのGUIから仮想マシンを止めたら直った docker-machine restartは効果がなかった
88:login:Penguin
18/01/18 17:40:21.34 G+DL28hG.net
なんでvirtualbox？
89:login:Penguin
18/01/18 18:22:49.70 HcoLdHLc.net
Docker toolboxってwin/mac上にlinux走らせてその上で更にdockerしてるからね
90:login:Penguin
18/01/18 21:17:36.99 ZKzLgYJR.net
いつの話？
91:login:Penguin
18/01/18 23:21:47.35 oYgm6+gm.net
誰もがWindows Proを使えるわけじゃないからなぁ
VirtualboxベースのDocker toolboxはまだ必要意義は大きい
92:login:Penguin
18/01/30 15:24:33.94 qZpjgluz.net
Hyper-VはProfessional以上必須なのか。
リモートデスクトップサーバ使いたいから、"わざわざ"Professionalのライセンス
にしてるけど、Docker for Windows (Hyper-V)を使うために必要ってのは微妙。
93:login:Penguin
18/01/30 16:34:53.53 VSfpjLUl.net
Docker使ってるとKubernetesしたくなってきてKubernetes on Atomic Host on Hyper-Vとか組みたくなるしへーきへーき
94:login:Penguin
18/01/31 02:46:07.43 Y/TJiD1T.net
>>89
そういう人のためにDocker Toolboxというのがある
95:login:Penguin
18/02/01 04:43:55.93 oMuXW2h/.net
coreOSがRedHatに買収された
96:login:Penguin
18/02/02 08:59:37.20 yFWv8+qQ.net
CoreOSはDocker利用を想定してたけどコレジャナイ残念OSだったので次はRancherOSあたりに期待してる
97:login:Penguin
18/02/03 13:01:31.67 3HQCIEUi.net
>>92
ヤフーの記事が、港のコンテナヤードの画像使ってて混乱したわw
98:login:Penguin
18/02/03 15:14:06.84 TzIPoha8.net
クジラの方のコンテナって言えば通じる
99:login:Penguin
18/02/05 13:34:29.22 k5aVtYPL.net
コンテナをビルドするとき Dockerfile 内で
RUN yum list
した結果を、ホスト側に残したいんだけど、なんか良い方法ないかな？
100:login:Penguin
18/02/07 01:28:24.21 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
101:login:Penguin
18/02/08 17:41:54.10 lNZDnl+7.net
>>97
便利なやり方が無いかなーと思って。
一度起動してその出力を回収する方法しかないね。
102:login:Penguin
18/02/14 02:35:31.11 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不要だけどイメージダウンロードからやり直しになって鬱陶しかった
103:login:Penguin
18/02/15 00:59:03.05 m3is
104:a15O.net
105:login:Penguin
18/02/15 12:06:04.40 2MLB8/h1.net
>>99
その問題は /var/lib/docker 以下が ext4 なら、fstab でマウントオプションに commit=300 とか付けると結構な対策になる
短命コンテナをバンバン使い捨てるケースで .../docker/overlay2 にゴチャゴチャ置かれても
sync 前にすぐ消えたファイルやディレクトリは単に無視されてディスクには書き戻されなくなって安心
デフォの 5 秒だとちょっと早すぎるんだよな
欠点はもちろん不意の電源ダウンで指定秒数ぶんだけデータロストする可能性があることだけど
ノートだったり UPS あったり、吹っ飛んでもいいや的な状況なら sync-daemon 系も不要だから楽
俺は USB メモリだけで運用してると 1 年ちょっとで寿命が来て色々と試行錯誤の後
Arch のフォーラムかどっかに書いてあったこのシンプルな方法に落ち着いた
106:塩水
18/03/11 02:24:38.22 hSBnN7Ry.net
dockerfile使わずにAnsibleでコンテナ構築してる人居ます？
物理で構築してたPlaybookのTarget SectionにDocker使うよって一行追加すれば使えるし(厳密には使えるようにするまでに色々設定は必要だけど)、
仮にコンテナのデファクトみたいなものがDockerじゃなくなっても最悪SSHで接続さえ出来れば流用できるからこのやり方良いなと思ってるんどけど。
107:塩水
18/03/11 02:25:38.04 hSBnN7Ry.net
スマホのフリック入力慣れないな。。
108:塩水
18/03/11 02:32:17.59 hSBnN7Ry.net
クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。
昔はVM作り直したり、スナップショットから復元したりしてたけど、今はそのマウス操作すら煩わしくなってしまってる。
109:login:Penguin
18/03/11 02:47:30.63 FdJN57de.net
>>102
使っていませんｗ
ansibleを使ってDockerイメージを作ると、Dockerのキャッシュが
効かなくてイメージ作るの遅くなるでしょ？その問題もう解決したの？
あとansible使うならイメージにpythonインストールされてないとダメなんだよね？
Dockerはalpineとかpythonすら入ってないイメージをベースとすることも有るからなねぇ
君にとっては役にたたない話かもしれないど、どうしてansible使おうと思ったのか？
質問していい？ >>102にも書いてあるけど他のコンテナに乗り換えたいときのためだけ？
俺は流用するならばシェルスクリプトが一番だと思ってるよ。
だってansibleで書いたYAMLって、ansible以外に流用できないでしょ？YAML書くのめちゃくちゃ手間だし
Dockerfileはシェルスクリプトにかなり近いので流用したいならDockerfileのままでいい
Dockerのイメージを作る時に限らず、なんでansibleなんか使うのか俺には理解できないよ
110:login:Penguin
18/03/11 02:55:22.05 FdJN57de.net
>>104
> クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。
君を煽るわけじゃなく、そういうのをやってる人見てると、ワロスワロスだよｗ
なに無駄に苦労しちゃってるの？って思う
Ansibleは実行検証が必要なほど信頼できないってことだからね
Ansibleは理想としては、クリーンな状態にしなくても、冪等性とやらで
書いてあるとおりになるはずなんだが、その理想は破綻してる。
書いてない部
111:分がどうなるのかは不定だからplaybookを変更した時に クリーンな状態からやったのと同じ状態になるとは限らない いやもちろんシェルスクリプトも同じだよ。でも検証時にサーバーに乗り込んで 手動でやったものがそのままコマンドにできる playbookとして書いたものが、手動でやったことと同様のことを 行ってくれるか？という "二重の検証" は必要なくなるのさ
112:塩水
18/03/11 03:31:17.92 hSBnN7Ry.net
すごい煽られててビックリしましたｗ
>>105
用途は
1. 公式OSイメージからコンテナを作る
2. 良い感じのコンテナになってたらイメージ化する
という感じです。
「2.」のイメージ作るとこは最終段階で、そう頻繁に行う作業ではないの
仮にイメージ一つ作るのに数十分かかったとしても、自分の用途に関してはそれほど問題はないです。
Ansibleを使おうと思ったのは、昔は動いてたけど今は動くなくなっているようなPlaybookでも
失敗した箇所がピンポイントでわかるのでメンテする気が起きるからです。
人のシェルスクリプト読んだり、昔の自分のイキリシェルスクリプトを読解するのに疲れた
というのが大きいですね。
コンテナのイメージ化という事も検証の一環として行いますが、メインの用途は
コンテナでPlaybookを高速で検証して、検証した構築用Playbookを本番のVMに放つという感じです。
(本番に放つ前に一度は検証用VMにも放って確認はします)
113:塩水
18/03/11 03:33:10.76 hSBnN7Ry.net
今度は長文をPCから書き込んだらsage忘れた
2ch書き込みのブランクありすぎて色々ひどい。。
114:塩水
18/03/11 03:47:31.86 hSBnN7Ry.net
>>106
私も冪等性なんてあてにするものではないと思ってて、
Ansibleに限らず、そのほかのツールも検証してないものは信頼しないというのが私の基本スタンスです。
(特に、かなり昔に作った構築系スクリプトはそのまま実行して一回で動くとは思ってません。)
シェルスクリプトは構築コマンドそのまま列挙すればよいので便利なのですが、
例えばCentOSのOS基本設定入れてRuby入れてApache入れてアプリ入れて、
みたいな構築の場合、Role単位で過程を完全に分離できるので、管理がすごく楽なんです。
例えば構築が失敗したとき、シェルスクリプト場合
何でコケたのか、どこでコケたのか、というのを探すところから始める必要がありますが
Ansibleだとコケた場所とコケた原因のコマンドが一目瞭然なのでとてもメンテしやすいのです。
115:login:Penguin
18/03/11 04:16:58.61 FdJN57de.net
あちこちで煽ってるけどようやくまともな意見を返す人が見つかったな
ふぉーん。ってことはシェルスクリプトでもどこで失敗したか
ピンポイントでわかれば問題ないってことじゃねーか。
あとは書き方が統一されていればいい
それなら解決可能な問題だな。っていうか俺の手元ではほぼ解決済みだ
> Role単位で過程を完全に分離できるので、管理がすごく楽なんです。
> Ansibleだとコケた場所とコケた原因のコマンドが一目瞭然なのでとてもメンテしやすいのです。
それもほぼ解決済みだ
シェルスクリプトで解決可能なたったそれだけの問題のために
Ansibleみたいな内部で何が行われているかわからない
重量系なブラックボックスツールをありがたがって使ってんのか
なんであれ（Ansibleとか）が無駄に重いソフトだってみんな気づかないんだろうか
> 2ch書き込みのブランクありすぎて色々ひどい。。
一体いつからここが２ちゃんねるだと錯覚していた？
116:login:Penguin
18/03/11 04:26:48.50 FdJN57de.net
Ansibleがブラックボックスツールということの
意味がわからない人がいるかもしれないから
軽く説明しておいてやろう
まずお前らは環境構築をしているよな？それが仕事だ
その仕事をしている最中に、Ansible関連でバグとか
モジュールが対応してなくてうまく動かない自体が発生した。
それらをお前らすぐになおせるの？
pythonを知っていたとしてもまず無理だろ？
重量級のAnsibleをブラックボックスで使ってるからな
でも本来のお前ら�
117:ﾌ仕事である環境構築は 手作業やシェルスクリプトですぐに解決できるだろ？ Ansibleの範囲でうまくできてりゃいいさ、だが それができない場合、大きなボトルネックになってんだろ
118:塩水
18/03/11 04:40:50.71 hSBnN7Ry.net
なんかアドレスが5chになってる。いつの間に。。
>>110
言ってしまうと、自分のスクリプト力もあまり信頼してなくて、
今書いた複雑なスクリプトを一年後の自分が読めるとは思ってないのです。
ベテランの人が自分で方針を決めて数年後でもメンテできるように書いていれば
その人は問題なく使えると思うのですが、他の人はそれを読めるかどうかというところですね。
Ansibleのベストプラクティスに従っていれば、そんなベテランの腕がなくても
仕組みで自然とそのようなメンテがしやすい形にはなるのです。
ただ、ベストプラクティスもそのままだと実用としてどうなのというケースも多いので
現場に合わせてアレンジする作業は必須だと思いますが。
(教科書そのままでは現実では役にたたない、とよく言われるアレみたいな感じです)
Ansibleそのものの挙動はブラックボックスなところもあるかもしれませんが、
品質の担保はServerSpecのテストでやってます。
何か問題があったらServerSpecのテストを足せば良かったりします。
手順書に確認手順を追加するよりテスト書いてgitで管理して必要に応じて実行する方が簡単で確実かなと思ってます。
テストや確認事項を手順書に追加するのは手順書のメンテナンスも確認作業も面倒ですが
テストなら足して実行すればよいだけなので、細かすぎるような確認作業も気兼ねなくガンガン追加できます。
119:塩水
18/03/11 04:55:20.38 hSBnN7Ry.net
多少はやったことありますが、AnsibleのモジュールそのものをPython書いて修正するというのは敷居がけっこう高いですね。。
確かに、廃止されたりオプションが変わったり、変な挙動のモジュールもあります。
解決策はそのモジュールが使えてるAnsibleのバージョンを固定するか
最悪、shellやcommandモジュールでLinuxコマンドべた書きするかでしょうか。
ただ、shell, commandモジュールを使うと冪等性が担保できないので
非推奨なのですが、そもそも私は冪等性というものを信用してなかったりするので
自分の場合は特に問題なかったり。
Ansibleが用意しているモジュールがあるのにshellやcommandでやろうとすると
こっちのモジュール使えという警告が出て煩わしかったりします。
使えるモジュールは使うとシンプルにかけたり良しなに処理してくれたりと確かに便利ではあるのですが
さっき書いたように廃止や挙動が変更されるリスクもあります。
そこでdockerコンテナを使ったPlkaybookの高速検証が活きてくるという。
120:塩水
18/03/11 05:13:32.25 hSBnN7Ry.net
さらさらっと書いてますが、このようなdocker,ansible,Serverspecの環境を作るのはそれなりに大変だと思うので、
もしやるならばこの辺に詳しいインフラエンジニアに任せた方が良いかも。
121:login:Penguin
18/03/11 11:20:29.98 FdJN57de.net
>>112
> 今書いた複雑なスクリプトを一年後の自分が読めるとは思ってないのです。
環境構築ごときでなんで複雑になるのかそこが不思議。
まず一つだけアドバイスするなら、設定はファイルの項目ごとに変更するのではなく、
設定ファイルをまるごとcopyすること。これで冪等性も担保される。
環境構築なんてファイルおいて数個のコマンド実行して大抵はこれだけで
終わるはずなんだが、なんで複雑になってるのか知りたいよｗ
冪等性を考えると前の状態を考慮する必要がでてくるので条件分岐なんかが出てくるが
Dockerだと最初から作り直しになるので関係ない
あんな大量のモジュールができてしまったのは、冪等性を考慮したことが根本原因かね？
> Ansibleのベストプラクティスに従っていれば、そんなベテランの腕がなくても
> 仕組みで自然とそのようなメンテがしやすい形にはなるのです。
細かいファイルに分かれていて、notifyとはhandlersとか使っていて、これどうなってるんだ？って頭を抱えたことが有るんだがｗ
単純にメンテしやすい形になればいいのかねぇ。詳しくは言えないがそれなら俺の手元では解決済みなんだ。
> Ansibleそのものの挙動はブラックボックスなところもあるかもしれませんが、
> 品質の担保はServerSpecのテストでやってます。
テストのためだけにRubyをサーバーに入れなきゃいけないってのもナンセンスだよなｗ
入れない方法もあるんだっけ？
> 何か問題があったらServerSpecのテストを足せば良かったりします。
> 手順書に確認手順を追加するよりテスト書いてgitで管理して必要に応じて実行する方が簡単で確実かなと思ってます。
俺は一言も手順書なんて言ってないんだよね。テストもシェルスクリプトでやればいいでしょ？当然gitで管理できる。
あとServerSpecでも同じくブラックボックス問題がある。ServerSpecでは一体何を調べてるんだって話だよ
例えばpackageでパッケージがインストールされているか調べられるが、パッケージの管理方法はディストリで違うはずだ
packageはAlpineのapkでも使えるのか？という質問に自信をもって答えられるのか？すぐにソース読みとけるのか？
（まあそこはコマンドが実行できればOKとするのが、やるべきテストだと思うけどさ）
122:login:Penguin
18/03/11 11:22:42.29 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を動かすための部分のほうが長くなる
123:login:Penguin
18/03/11 11:30:56.88 FdJN57de.net
>>114
> もしやるならばこの辺に詳しいインフラエンジニアに任せた方が良いかも。
インフラエンジニアじゃないのか？俺も違うけどなｗ
インフラエンジニアじゃないけど、サーバー構築やらないわけじゃなく
まあやったりする。それぐらいはできる。
問題は、パッケージインストールした。設定ファイルも書いた。こんな感じでいいだろう。
で、自動化？ まあやったほうが良いね。今やったことを自動化するだけだろ？
Ansible？ YAMLで書くのか。
インストールしたパッケージを使うモジュールはどれ？
設定ファイルに書いたことに相当する項目はどれ？
ないんだが？新しい機能だから対応してねーのか？
結局commandでシェルスクリプト書くしかねーじゃねーか
みたいなな。
インフラエンジニアってなんであんなクソなもの平気で使えるの？
124:login:Penguin
18/03/11 11:48:05.06 JbaTrnc+.net
オンプレでウォーターフォール、一度作ったマシンを後生大事に使い続ける、
そんなスタイルならDockerすら不要かと
125:塩水
18/03/11 15:33:16.62 hSBnN7Ry.net
> 環境構築ごときでなんで複雑になるのかそこが不思議。
社内のVMwareで作ったイメージを直接客先に入れられるならもっと簡単に作れるんですけどね。。
オンプレ上で直接構築する場合、内部やDMZなど環境毎にproxyやDNS、ntpやファイヤーウォールの設定が違ってたりするのです。
あと、WebサーバでIPアドレスだけ変えて後は全部一緒の設定にしたい場合は
Webサーバ分だけ設定ファイル作るんじゃなくて、テンプレート作ってIPアドレスだけ動的に変えて配布するとか。
便利です。
> あんな大量のモジュールができてしまったのは、冪等性を考慮したことが根本原因かね？
それも原因の一つかもしれないですが、基本は便利そうだからじゃないですかね？
私はRedHatの人ではないのでなんとも答えられませんが
「何でLinuxにはあんな大量にコマンドがあるんですか？」みたいな質問かなーと。
> 細かいファイルに分かれていて、notifyとはhandlersとか使っていて、これどうなってるんだ？って頭を抱えたことが有るんだがｗ
そうですね。サービスが再起動されるのが状態が変更された場合という事ですけど
何をもってサービスが変更されたとするかというのがわかりにくいかもですね。
私はこれ積極的には使ってなくて、serviceモジュールで明示的にサービス再起動してます。
基本的に冪等性は考えないスタンスの一言なのですが、使わない理由をあえて考えると
構築時はいくらどのタイミングでサービスを再起動しても本番に影響は無いのと、
稼働中のサーバのサービスを再起動する場合は明示的に確実に特定のタイミングで一回だけ再起動させたいからでしょうか。
126:塩水
18/03/11 15:34:04.20 hSBnN7Ry.net
> テストのためだけにRubyをサーバーに入れなきゃいけないってのもナンセンスだよなｗ
> 入れない方法もあるんだっけ？
Serverspecは私の知ってる限りのやり方ではRuby要りますね。gemですし。
サービスと関係なくある程度裁量で触れるステージング的なサーバがあれば
客に許可をもらってそこに入れるとか。。
> テストもシェルスクリプトでやればいいでしょ？当然gitで管理できる。
シェルスクリプトでテストが書けるのであれば良いと思いますが、
例えばリターンコードを確認して成功と失敗を判断して、、みたいなスクリプトを書くとすると
構築系スクリプト以上に大変な気がします。。
> ServerSpecでは一体何を調べてるんだって話だよ
何を調べれば十分かをこちらで定めて、それを満たしていることを確認するというスタンスにすれば良いと思うのです。
例えば「Rubyがインストールされていることを確認する」の場合packageだけで良しとするか、
commandでインストールしたコマンド実行後にあるべき出力結果が出てるかまで確認するかとか。
やろうと思えば手で実行できる範囲のテストはいくらでも追加できるので。
AnsibleやServerspecそのものがどうなってるかではなくて、自分が構築したサービスがちゃんと機能しているかを見ます。
こういう着眼点にすれば、将来もしAnsibleやServerspec以外の便利なソフトができても移行の判断がしやすかったりします。
127:login:Penguin
18/03/11 15:53:28.62 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() の中身を書き連ねるだけ。
128:塩水
18/03/11 16:11:14.24 hSBnN7Ry.net
>>117
>インフラエンジニアじゃないのか？俺も違うけどなｗ
元インフラエンジニアで今の職業は百姓です。田舎で野菜作ってます。
最初はshellやcommandで書いて、使えるモジュールがわかったらあとで修正するという方法もありかなと。
まあ、だいたいそのままで特に問題ないので放置されるのがデフォルトですが。
自動化のところまでは色々できたりするんですけど、
それを他の人に引き継ぐというのがものすごく難しいんですよね。。
k8sも挑戦して、環境構築できるPlaybook作ったりしたのですが
人に引き継ぐという事が難しくて頓挫しました。
自分で管理することはできても人に引き継ぐとなるとAnsibleやServerspecの比じゃなくくらいしんどかったので
k8s環境ぶっ壊してdocker-composeに戻しました。
(そもそも社内の開発環境にk8sは大げさすぎたということもあります)
> Ansible？ YAMLで書くのか。
例えばChefの場合はRubyの知識が必要ですがYAMLは言えば設定ファイルを書くような感覚なので
インフラエンジニアにとっても比較的とっつきやすいかなと思ってます。
AnsibleでPythonを意識するような場合、複雑にやりすぎているケースがほとんどです。
Pythonの制約からなのか、変なところにカンマ入れないと動かないとかあったりしますが。
(インベントリファイルじゃなく直接ホストを一つだけ指定する場合など)
> インフラエンジニアってなんであんなクソなもの平気で使えるの？
Ansibleは自然とメンテナンスしやすい構造になるような仕組みになっているのが便利だからじゃないでしょうか。
学習コストと既存のスキルセットでできることを比較して学習した方がトータルで�
129:ｦ的になると判断したから使うというか。 逆に言うと既存のスキルセットで十分なことができてしまっていると学習コストを払うというほうに舵を切りにくかったりするかもですね。 私はAnsible、dockerは流行ってるから採用したのではなくて、 ある程度プライベートで遊んで便利そうだったから職場にも持ち込んだという流れでした。
130:login:Penguin
18/03/11 16:12:01.95 FdJN57de.net
>>120
> > ServerSpecでは一体何を調べてるんだって話だよ
> 何を調べれば十分かをこちらで定めて、それを満たしていることを確認するというスタンスにすれば良いと思うのです。
> 例えば「Rubyがインストールされていることを確認する」の場合packageだけで良しとするか、
> commandでインストールしたコマンド実行後にあるべき出力結果が出てるかまで確認するかとか。
> やろうと思えば手で実行できる範囲のテストはいくらでも追加できるので。
そいう話じゃなくて
describe package('mysql') do
it { should be_installed }
end
とかやってOKになった、インストールしているらしいことはわかった。
だがこのコードが何を根拠にパッケージがインストールされていると判断したのか？ってことだよ
dpkg -l の結果から判断しているだけなのか、それともパッケージに含まれるファイルが
既定の場所に有ることを確認しているのか、パーミッションまでチェックしているのか
それがわからんってことだよ。
もちろんソースコード見ればわかるだろうけど、Rubyの知識が要求される上に
こういうのって過度に汎用化されていて簡単に読み解けるとは思えないんだが
特に言語がDSLそのものではなく、DSLを作りやすいだけの言語だと、
DSLを作るために通常のプログラミングには用いられない
メタプログラミング的なコードが多用される傾向にある
131:login:Penguin
18/03/11 16:38:27.85 FdJN57de.net
>>122
k8sはクラウドで数台～十数台以上のマシンが常時起動していて
何もしてないのに起動してるのはもったいない。かと言って事情があって落とすことも出来ない。
ってときにそれらの余剰CPUリソースをなにかに使うことは出来ないか？って時に
使うもんだと思うぞ。あと同じサーバーを複数起動させるという前提があってこそ使える
（コスト節約のために）サーバーをオートスケールさせるのはクラウドだけなら
比較的簡単なんだが、その中に更にk8sが入り込むとk8s自体にもオートスケールがあって、
まるでクラウドの中にクラウドが有るような感じで複雑さが増し、
k8sでPod（コンテナ）をオートスケールさせて、サーバーリソースが足りなくなったら
今度は仮想マシンをオートスケールさせるとかなって安定稼働させられる自信がない。
普通に開発環境はdocker-composeがいいよ
> 学習コストと既存のスキルセットでできることを比較して学習した方がトータルで効率的になると判断したから使うというか。
俺からするとAnsibleはChefよりはましだが、それでも学習コストが高くて、（Ansible学習前の）インフラエンジニアが
持っているであろう既存のスキルセットの応用が難しく、Ansibleを覚えてしまったとしても
なおAnsibleモジュールと格闘し続ける、効率的にならない道具だと思ってる。
まあ一言で言うと、もっといい方法が有るって話だ。これ以上はここでは言えないけどｗ
132:塩水
18/03/11 16:50:49.20 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ができて
システムを俯瞰して見ることができるインフラエンジニアが居た方がいいかなーとは思います。。
133:login:Penguin
18/03/11 16:57:53.92 FdJN57de.net
> と書けばファイルの存在や権限、オーナーが確認できます。
それはただ単にメソッド用意されてるからだよねーとしか思えないんだよね
シェルスクリプトだってメソッドあれば
例えばこれみたいに書けるでしょ？
describe file '/user/bin/mysqld \
-- should_exist \
-- should be_mode 770 \
-- should be_owned_by 'mysql' \
end
134:login:Penguin
18/03/11 16:59:24.31 FdJN57de.net
なんか中途半端になったなｗ
135:describe file '/user/bin/mysqld \ --should_exist \ --should_be_mode 770 \ --should_be_owned_by 'mysql' \ end
136:塩水
18/03/11 19:29:40.88 hSBnN7Ry.net
k8sはよっぽど仮想サーバに余剰があるか、もしくはGoogleやFacebookみたいに仮想化ソフトそのものがリソースの無駄と言い切って
物理サーバとコンテナだけでやるというクラスになると意義があるのかなぁとか思ったり。
開発や検証ではコンテナをガンガン使いますが、本番にコンテナ使うというのはどうもまだ怖いですね。。
壊れたら立て直せばよいWebサーバならまだ、、とは思いますがDBにコンテナ使うという事例みたときは
なかなかチャレンジングな事してるなと思いました。。
ただでさえコンテナは障害が発生したときにコンテナ側が悪いのかサーバ側が悪いのかの切り分けが
難しいのに、そこにさらにk8sが絡んでくるとなると。。
> シェルスクリプトだってメソッドあれば
確かにメソッドを自前で用意すればできると思います。
ただ、シェルスクリプトはちょっと記述を間違ったりすると事故になる可能性があるので
テストを流す前のベテランのレビューは必須だと思うんです。
Serverspecは基本的にどんな操作もサーバーの状態は変わらない(はず)なので
ベテランのレビューがなくてもとりあえず流しとく的に実行はしやすいかなと。
(私が今まで使った限りでは変な実行してサーバが壊れた、ということは無いです。
Ctrl+Cでキャンセルしてターミナルの表示がおかしくなるということはままありますが。)
137:塩水
18/03/11 19:43:24.47 hSBnN7Ry.net
こういう作業をAnsibleやServerspecでやろうとすると
コマンドが異様に長くなるのでラッパースクリプト書いたりするのですが、
シェルスクリプトはそこで今でも大活躍してます。
なんだかんだで便利なんですよねシェルスクリプト。
138:login:Penguin
18/03/11 21:42:47.19 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 無しでイメージテストができたり、メンテナの反応も速いしコードも読みやすい。
今後ちゃんと出来上がれば化けるかも
139:login:Penguin
18/03/11 23:36:05.79 gLOQBJNa.net
> 私にとってはトラブル解決時に 1000 行とかの自作のシェルスクリプトなんかより Ansible のコードを読むほうが楽。
> まぁ、自分しか使わないシェルスクリプト100行ぐらいで済むものならどっちでもいいけどね。
俺の観測ではシェルスクリプトが100行だと
Ansibleのコードは1000行って感覚なんだけどね
140:login:Penguin
18/03/12 00:00:41.81 iAV7tz/N.net
大きな会社だと仮想サーバ一つ立てるのにいちいちインフラエンジニアにお伺い
たてないといけないけど、リソース多めのVM一つ作ってもらえばそこにdocker入れて
いろんなコンテナたててやりたい放題できるという。
4vCPU,8GBMem,100GBHDDあればデフォルト設定�
141:ﾅコンテナ5くらいはいける。 もちろん検証用DBコンテナとか立てるときはMySQLのinnodb_buffer_pool_size小さめにしておくとか ちょっとした工夫はいるけど。
142:login:Penguin
18/03/12 00:09:31.95 0gO9Md9Y.net
やっぱりシェルスクリプトだとなんでそんなに
メンテナンス性が悪いものが出来上がるのか？
書くことはAnsibleとかわらんだろ（むしろ短く書ける）
と思ってるわけだが。
ふと気づいたがもしかしてシェルスクリプトで書く時に関数作ってないのか？
ただ単に上から下へとコマンドを書き連ねるだけ？
プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が
高くないように記述するもんなんだが、インフラエンジニアってのは
それができてないレベルだったりするの？
143:login:Penguin
18/03/12 00:13:02.11 0gO9Md9Y.net
>>132
まあ会社が会社だとそういうことなんだろうけど
> 4vCPU,8GBMem,100GBHDDあればデフォルト設定でコンテナ5くらいはいける。
それ個人用に配給されてるPCレベルだよね？って思わなくもないｗ
うちは入社当時のMac Book Proの一番上当たりの性能
CPUは忘れたけど、16GBのメモリと、512GBのSSDだったかな？
144:login:Penguin
18/03/12 01:17:08.47 iAV7tz/N.net
>>134
個人PCレベルというのは否定できないw
社員数多いとリソース配分が大変なんです。
HDDはシンプロでごまかして、vCPUもまあまあ割り当てられるとして、
メモリは慢性的に不足します。
個人のMacでそれだけリソースあるなら
ローカルPCにdocker入れて使えば良いですね。
その場合も個人的にはDocker for Mac使うんじゃなくてVagrantで立ち上げたLinuxVMにdocker入れて使います。
理由は何となくというか、その方が環境が汚れなさそうだからというか。
145:129
18/03/12 01:34:06.50 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 も「どれだけ削るか」などで人によって書き方がまちまちになってしまうんだけど、
普通は大規模にはならないし、出来上がるイメージをバイナリだと思ってちゃんと動けば
中身がどうであれとりあえずは良いのかなと思えたりするので結構好き。
「プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が高くないように記述するもんなんだが」
は可読性、メンテナンス性が高いようにじゃない？
146:login:Penguin
18/03/12 01:36:17.28 0gO9Md9Y.net
> 「プログラマの感覚だとどんな言語であれ可読性・メンテナンス性が高くないように記述するもんなんだが」
> は可読性、メンテナンス性が高いようにじゃない？
そのとおり「高くなるように」と書いたつもりだった
どうもGoogle IMEの調子が良くないんだよ。
特定のアプリで極端に変換が遅くなることが有る。
アプリ再起動したら直ったからメモリリークでもしてんのかな？
147:login:Penguin
18/03/12 01:47:41.96 0gO9Md9Y.net
>>136
やっぱり理解できない。
何かしらの越えられない壁の
あっち側とこっち側にいる気分
> てか、コードが短く "も" 書けるのが嫌なんだけどね。
略
> そういうことをする余地がなければ無いほど良いと思ってる。
コードは曖昧さがなく、削ぎ落とすものが一切ないレベルが良いと思ってる。
だからいろんな書き方があるとは思わず、
それ以外の書き方は「なんでそんな無駄なことすんの？」としか思わない
あと当たり前だけどコードゴルフのような変数名を短くするみたいな
アホなことはしない。無駄を無くすだけ。
俺のプログラミングは関数型の影響は大きいと思ってるので、関数型勉強すると良いよ
と言っても俺、関数型言語あまり知らないけどねｗｗｗ 考え方を理解してるだけ
> あと、shell も perl も（Cも）変数のスコープがデフォルトでグローバルなのが良くない。
それも手元じゃ解決済みなんだよな（苦笑）
感覚的に問題点を潰してる俺偉いｗ
ヒントを言うとサブシェルを使うとその中で定義した変数は中に閉じ込められるので
localを使わなくてもローカル変数相当になる。
148:login:Penguin
18/03/12 13:05:39.78 NF8xf4ym.net
>>138
そういうルールをどうやっていろんなスキルレベルの人と共有するんですかって話
149:login:Penguin
18/03/12 21:57:46.32 0gO9Md9Y.net
>>139
逆に言えば、そういうルールを共有できればOKってことだよね？
みんなありがと。いろいろ言ってみて話を引き伸ばしたけど
もうそろそろ十分かなと思ってる
ansibleではなくシェルスクリプトでやる上で、何が足りなくて
何が必要なのかわかった気がする。
今回はこれぐらいで切り上げるよ
またどこかで違う切り口から探るかもしれないけどｗ
150:login:Penguin
18/03/13 06:36:13.77 w7drUkX+.net
>>140
そう。
その意気で、ぜひ世界に通用するシェルスクリプトフレームワークを作ってくれ。
151:login:Penguin
18/03/19 12:18:33.64 10HKUK+F.net
Dockerfileからラッパースクリプトを呼び出すのは良いとしても、
DockerHubでそのシェルスクリプトを表示させるすべがないのが問題。
結局GitHubに行くことになるならDockerfileの表示ページいらないのでは。
152:login:Penguin
18/03/21 17:17:07.53 6Vet870y.net
Dockerの教科書第二版が4月に出るぞー
153:login:Penguin
18/03/26 16:00:04.53 W/pr8b3f.net
Arukasのβ外れたけど予想以上にコスパ悪いなぁ…
さくらはコンテナホスティングやる気ないのかな
154:login:Penguin
18/03/26 16:24:25.96 bSj5pGXS.net
どんなビジョンであれで世界で戦えると思ったのかご説明いただきたい
155:login:Penguin
18/04/03 07:43:27.59 8ENp9jaE.net
初心者がLinuxとストレスフリーで生きる為の6か条
1．Winをリプレース出来るなどど考えるのはやめましょう。共用しましょう。
2. 印刷はあきらめましょう。
3. Wifiの使用はあきらめましょう。
4. 音楽・動画・画像の編集/制作はあきらめましょう。
5. Nvidia製品の使用は控えましょう。
6. 教本を買いましょう。Linux界に限ってはググレカスは遠回りです。
7. Ubuntuを我慢して使い続けましょう。
156:login:Penguin
18/04/03 23:16:59.76 Ry6Q9joG.net
随分古いな。
157:login:Penguin
18/04/03 23:44:51.96 9r9tHTvx.net
>>146
従いますよ
158:login:Penguin
18/04/20 13:08:52.09 IxQaq2RC.net
プロフェッショナルの方、どなたか教えてください(/ω＼)
今、下記内容の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
159:login:Penguin
18/04/20 22:27:51.02 8yT4IMgr.net
>>149
エラー文ちゃんと読んだんですか？
160:login:Penguin
18/04/21 10:25:09.06 RQ3vsIdh.net
>>150
エラー文が理解できなかったです、、
161:login:Penguin
18/04/21 13:23:47.70 HjK21lH7.net
>>151
numpyって知ってる？
162:login:Penguin
18/04/21 13:46:33.79 HtY0Nuyg.net
なんぱい？
163:login:Penguin
18/04/21 17:21:10.71 5eINoTB9.net
>RuntimeError: module compiled against API version 0xc but this version of numpy is 0xa
0x って、16進数か？
0xc は12、0xa は10 って事か？
164:login:Penguin
18/04/21 19:53:43.47 RQ3vsIdh.net
>>152
はい、知っています。
これはnumpyのversionが古いということですか？
165:login:Penguin
18/04/22 09:15:07.32 uHMnXexw.net
「python module compiled against API version」で検索！
開発者の基本は、エラーメッセージで検索すること
166:login:Penguin
18/04/22 19:07:10.00 2/k4X0Kz.net
>>156
検索しましたが、力不足で分かりませんでした。。
少しやってみたものの、
import tensorflow as ts
しただけで、
「The kernel appears to have died. It will restart automatically.
（カーネルが停止したようです。 自動的に再起動します。）」
が出てしまいました。
どなたかお力をお貸しください(/ω＼)
167:login:Penguin
18/04/22 19:23:31.15 lrjQt1PM.net
いままで偉そうにしてたやつ、ちゃんと答えてあげろや
168:login:Penguin
18/04/22 23:46:18.23 uHMnXexw.net
「docker hub tensorflow」で検索！
169:login:Penguin
18/04/23 03:34:29.66 VkOu3656.net
この手の質問って動作環境が横断的だからdockerスレと言語スレ側でたらい回しにされちゃうんだよな
かと言ってマルチポストはできないし悩ましいところ
エラーメッセージやアドバイス貰ったキーワードをダブルクオートで括ったフレーズ検索も駆使して乗り越えるのだ
今こそ成長の時
170:login:Penguin
18/04/23 06:37:04.24 qKqt8dYQ.net
>>157
tensorflowのバージョンはどうした？numpyのバージョンはどうした？
バージョンがあってないと言われてるんだからtensorflowのバージョンを1.4とか1.3とかに下げてみて試してみたらいいんじゃないでしょうか。
RUN pip install tensorflow==1.5
171:login:Penguin
18/04/23 10:45:26.96 gJ+bJQJv.net
>>161
ありがとうございます！
tensorflowのバージョンを1.3にすることで、エラーも出ず正常にインストールできました。
1.4や1.6では、エラーが出てしまい駄目でした。
皆さん、私の力不足でお手数をおかけ
172:いたしました。 本当にありがとうございました。
173:login:Penguin
18/05/22 07:23:12.42 Czl6p0FW.net
僕の知り合いの知り合いができた副業情報ドットコム
関心がある人だけ見てください。
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
EAAD8
174:login:Penguin
18/05/22 11:47:01.72 NlhYPEMm.net
EAAD8
175:login:Penguin
18/05/27 18:22:16.75 8ka68JJO.net
ディープラーニング ライブラリの管理で混乱しないようにとdockerを導入したけど
今はdockerで混乱してる
開発環境はどうやって整えるんだ、これ
コンテナの外と中は完全に分かれているのかよ
今あるエディタやアナコンダを呼べないぞ
コンテナを作る時に全部詰め込まきゃダメなのか?
NGCをつかっているけど
176:login:Penguin
18/05/28 20:34:50.01 G/OxqctX.net
>>165
はいはい、いつもの仮想マシンの使い方とごっちゃにしてる人ね（笑）
Dockerは環境を作るものじゃなくて、
アプリケーションを作るものです。
ディープラーニングの何をしたいのか知らないけど
コマンドを実行するだろ？
そのコマンドを実行するのにライブラリとか必要だろ？
そのコマンドにライブラリなんか全部くっつけて
一つのDockerコンテナ＝アプリケーションを作るものです。
177:login:Penguin
18/05/28 21:14:26.05 5P04jZKi.net
>>166
いや、知らんよ
俺は開発元が進めてきたものを使うだけ
178:login:Penguin
18/05/28 21:25:11.53 5P04jZKi.net
アプリケーションなら
任意の識別器や分類器を定義しデータを読み込んで学習するアプリケーションが欲しいわ
しかし、環境の切り分けのためじゃないならなんで開発元はdockerを配布しているんだろうね
それも競合を心配する必要ないですよってアピールしながね
179:login:Penguin
18/05/28 21:47:04.72 G/OxqctX.net
> アプリケーションなら
> 任意の識別器や分類器を定義しデータを読み込んで学習するアプリケーションが欲しいわ
それを作るのがDockerを使うお前なんだって
180:login:Penguin
18/05/28 22:02:15.83 5P04jZKi.net
>>169
それを玄人様たちはどうしているのかってこっちは聞いているだが...
181:login:Penguin
18/05/28 22:13:34.15 G/OxqctX.net
普通にコマンド実行に必要なものを
まとめてコンテナにしてるだけだが？
182:login:Penguin
18/06/03 15:52:37.21 4t3nAm6u.net
sage
183:login:Penguin
18/06/24 08:47:17.87 TokMwylE.net
pullしたubuntuイメージにvimが入っていないんだけど・・・
aptコマンドもないんだけど・・・
docker search ubuntuで出てくるうち全部入りのイメージってどれ？
184:login:Penguin
18/06/24 22:35:20.55 anZc79Me.net
dockerってコンテナが動いてる途中でdocker終わらせたらコンテナ内に保存してたファイルはなくなるの？
185:login:Penguin
18/06/25 05:44:34.47 Uuelo8Ok.net
>>174
コンテナ起動時にストレージ領域を紐づけてなかったら終了時に綺麗さっぱり消えるようだ
186:login:Penguin
18/06/25 09:42:17.00 +pzgGIIi.net
>>174
正確にはコンテナを削除すると無くなる
停止しただけでは無くならない
ゆえに削除するまではdocker logsでログも見れるし
docker commitでイメージ化すれば
docker runで中身を見れる
URLﾘﾝｸ(stackoverflow.com)
187:login:Penguin
18/06/25 09:49:22.67 +pzgGIIi.net
>>173
欲しけりゃ自分のDockerfileに入れるか
全部のコンテナでそれやるのがアレってなら
新しくvimコンテナ作って編集したいファイルだけマウントするか
ホストのファイルをマウントして
ホスト側でvimで編集すれば良い
てか開発環境だよな
本番環境でそれやったら
ちゃんと動く環境を保存出来るっていうDockerの魅力を殺している
場合によっては仕方ない事もあるが
188:login:Penguin
18/07/01 03:55:45.96 +w2giTsy.net
>>173
> pullしたubuntuイメージにvimが入っていないんだけど・・・
Dockerの使い方を間違ってる。
あんたが言ってるのは、pullしてきたffmpegコマンドの中に
vimが埋め込まれてないんだけどって言ってるようなもの
Dockerコンテナ = 実行ファイル
ffmpegの処理にvimなんていらないんだから入っていなくて
当たり前だし入れるべきではない
だがaptコマンドは普通入ってるはずだけどな
>>173
> dockerってコンテナが動いてる途中でdocker終わらせたらコンテナ内に保存してたファイルはなくなるの？
ffmpegコマンドの中で内部的に使用しているファイルはコンテナ削除とともに消える。
Dockerコンテナの中のファイルはメモリと考えればいい。
コマンドを終了するとメモリも解放される
（Dockerコンテナ版の）ffmpegコマンドから書き出したいなら、
ボリュームでコマンド（コンテナ）外部への読み書き場所を指定する
189:login:Penguin
18/07/01 09:04:34.19 EBIMlKr7.net
>>178
アドバイスありがとう
ということは、dockerで起動したOS内でvimが使いたければ
vimのコンテナを探してきて追加起動しろってこと？
どこのサイトにどんな名前でvimのコンテナがあるのか調べるみたいなことを
アプリごとにやってたら、環境を作るまでどれだけの手間と時間がかかることやら
このソフトの何が持てはやされているのか全く理解できない
190:login:Penguin
18/07/01 09:21:20.95 +w2giTsy.net
>>179
だから使い方が間違ってる。
全く理解できないのは、あんたが正しい使い方がわかってないからだよ
そもそもDockerコンテナは使うものじゃない。作るものだ。
アプリのビルド・コンパイルと一緒だよ
もちろん誰かが作ったものがそのまま使えるのなら
使っていいんだが、基本はアプリの開発者が作るもの
vimとかそういうのは、どうせあんたUbuntuとか有名所の
ディストリ使ってるんだろ？そういうのはパッケージメンテナが
ちゃんと動くようにメンテしてくれてる。それで満足してるならそれ使えばいい。
Dockerの出番はそれで満足できない場合だよ。
vimにそういうのがあるのかしれないが、独自にビルドしないと使えない機能を使いたいときや
例えばvimの新しいバージョンを使いたい時。ビルドするためにライブラリも新しくしなければいけない
でもOSのライブラリを新しくすると、他のプログラムに影響が出るかもしれない
そういうときにvimのビルドとそれを動かす環境までも一体化させて、独自のvimを作る
ってときに使うんだよ。実行環境まで含まれてるから、OS標準のライブラリなどを
置き換えたりもしないし、どこに持っていってもそのまま使える
オレオレvimバイナリ（=Dockerコンテナ）の出来上がりってわけだ
で、そんなもん普通はやらねーだろ？ だからアプリの開発者が作るものだって言ったわけだ。
vimなどのパッケージはパッケージのメンテナが頑張って動くようにしてくれてる
だけど、自分で作ったアプリは、自分が頑張るしかないだろ？ でも頑張りたくもない
いろんなディストリや、WindowsやMacでも動くようになんかするの大変じゃないか
だからDockerコンテナ化することで、Dockerデーモンさえ動いていれば、
どこに持っていっても同じように動かせるってわけさ
一言で言えば可搬性だな
191:login:Penguin
18/07/01 09:23:55.84 +w2giTsy.net
>>179
> ということは、dockerで起動したOS内でvimが使いたければ
それから通常はdockerで起動したOSの中に乗り込んでvim実行して
ファイル修正とかしないからな
独自のDockerイメージを作るときに、デバッグ目的にやることはあるけど
「dockerで起動したOS」なんて考え方を持ってはいけない
なぜなら、何らかのプログラムに実行環境をくっつけただけで、
作られるものは、実行環境付きのなんらかのプログラムなんだから
そこにOSなんてものはないと思え
192:login:Penguin
18/07/02 19:23:28.69 1jLd0V1g.net
今日から新しいプロジェクトでmac上でDOCKERを使う事になったんですが
最初の社内のチュートリアルに従ってHOMEBREWからインストールして起動したところ
新しいバージョンがありますって言われたので
アップデート＆ReLunchをしたらそのまま反応がなく
アプリからダブルクリックしても起動しなくなりました
MAC使うのもバージョン管理ツール使うのも初めてだらけで
くだらない質問で申し訳ないんですが
考えられる解決方法はありませんでしょうか
193:login:Penguin
18/07/02 20:07:43.00 Eg1cE
194:gm9.net
195:login:Penguin
18/07/02 20:45:02.37 Y1QFiQ2T.net
普段サーバーサイドJavaとかPHP JSでウェブアプリかいてて
mac の Ruby on Rails のサーバーサイドの案件が修羅場でヘルプはいったんだけど
分かってる人はみんな忙しくて質問なげてもなかなかかえってこないんですよね
でもこんな情報じゃわかるわけないですよね…
明日また社内できいてみます
すいませんでした…
196:login:Penguin
18/07/03 00:50:17.25 1PLz+sRr.net
>>182
dockerは公式サイトのやり方でインストールしたほうがいいんじゃね？
197:login:Penguin
18/07/03 00:52:28.72 1PLz+sRr.net
社内のチュートリアルが何年前に書かれたかだな
Docker Toolbox使ってたら古いやり方だな
まあ社内全員やり方が決まってるなら仕方ないが
198:login:Penguin
18/07/03 02:50:11.95 88JNN2bg.net
支給されたmac PCが他の人も使うみたいで
別の人がインストールしたhomebrewが/usr/localにはいってて
権限が変更できないくてホーム以下にインストールしたんだけどそのせいなのかなと…
１日がかりでbrew rbenv dockerの３ついれただけなんだけど
どれが原因なのかがぜんぜん分からない…
マックはじめてで最初の１，２時間は日本語変換や窓の最小化やコピペもわからないレベルで作業効率も悪いし
Javaからruby覚えるのはすぐできると思ったけど
OSが違ったりフレームワークの環境構築がこんな大変だと思わなかった
199:login:Penguin
18/07/03 05:53:39.58 0N07jwhz.net
もうmac板で質問したほうがいいのでは
200:login:Penguin
18/07/03 06:10:23.01 1PLz+sRr.net
>>187
なんの苦労もなくhomebrewを使いたいなら
Macを他に人に使わせるな。そしてクリーンインストールして
自分ひとりのものとして使え
homebrewはインストールしたユーザー以外がまともに使うことは無理
homebrew自体はsudo使ってインストールするくせに（/usr/localに書き込むから）
パッケージ自体は/usr/local以下に一般ユーザーでインストールするからな
ディレクトリはこんな感じになる
URLﾘﾝｸ(github.com)
> -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を使わない方針なんだが
URLﾘﾝｸ(docs.brew.sh)
じゃあ共有のディレクトリ/usr/localを使うなと
201:login:Penguin
18/07/03 06:28:04.40 88JNN2bg.net
そうなんですね
クリーンインストールしていいかお願いしてみます
検索するとわりとホーム以下にインストールする方法とかでてきたのでいけるかと思ったんですけど
コーディングスキルかわれて入ったのに初日から環境構築だけでつぶされてストレス
なまじできると思われてるからしょーもない質問もしにくいし
もともと大学院研究室あがりでスクラッチからかくのが好きな
ブラックボックスなツール使うの気持ち悪い
古い人間だから昨今のフレームワークだらけの業界きついなあ…
202:login:Penguin
18/07/03 06:35:07.67 HvrBhqqa.net
頭でっかちの使えないやつか現場も大変だ�
203:ﾈ
204:login:Penguin
18/07/03 06:54:24.03 B87Zf6Sc.net
macやhomebrewがはじめてなのはともかく、バージョン管理ツールはじめてはないわ
それでひとりで環境構築しろってほったらかしなのも普通はありえんと思うけど
仕事ほしくて経験ないのに経験ありとか嘘かいたんじゃねーの
205:login:Penguin
18/07/03 07:12:51.42 ArJzlEvp.net
最後にききたいんですけど /usr/local じゃなく
~～/homeblew に homeblew をいれたんですが
この blew から Docker をインストールした場合実態はどこにあるんでしょうか
チュートリアルにアプリケーションからdockerを起動とあるんですけど
/Application/Docker.app を起動したときにもっと新しいのがありますっていわれて
更新かけたらそれっきりだったので
これが前の人がインストールしたやつだったのかな…
コマンドラインの docker はホーム以下のパスになってたんですけど
アプリケーションからじゃなくコマンドラインからDockerのGUIアプリ起動する方法ってありますか？
206:login:Penguin
18/07/03 11:19:37.64 oYvmZw+l.net
解決しました
初回起動時に窓が出たのでずっと窓を探してたんですけど
右上のクジラマークからアクセスするんですね…
おさわがせしました
207:login:Penguin
18/07/03 13:54:24.15 oYvmZw+l.net
何度もすいません
docker-compose up -d
で ERROR: manifest for xxx/yyy:2018zzzz not found が出るんですがどこを見ればいいのでしょうか
一応同じディレクトリに docker-compose.yml はあって
yyy:
image: xxx/yyy:2018zzzz
と書かれています
208:login:Penguin
18/07/03 14:20:45.35 1PLz+sRr.net
>>195
普通はそうならないので環境の問題です
OSをクリーンインストールしてください
209:login:Penguin
18/07/04 02:14:06.32 COxRspz9.net
rubyは導入ハードル高すぎ
よっぽど複雑なプロジェクトでもなけりゃこんな開発環境作ってるあ労力で案件終わるわ
210:login:Penguin
18/07/04 06:04:14.37 WJvTzUXE.net
利用プロジェクトの多くが低品質だったせいでいわゆるアタリショックみたいな扱い受けてるよな
負の遺産だとかRuby巻き返しの目は潰えてるとまで言われてるし・・・Javaみたいにはならんで欲しいマジで
211:login:Penguin
18/07/07 17:30:55.41 fg0oR1Sy.net
散々Perlディスっといてこれだもんなm9(^Д^)プギャー
212:login:Penguin
18/07/07 21:06:35.47 1D6mHUpx.net
やめて…perlは6を引き伸ばし杉た件のせいで世間との剥離からユーザー離れが尋常じゃなく
引き合いに出されると最底辺の戦いじみて嘲笑の的です…
213:login:Penguin
18/07/07 21:59:02.61 fg0oR1Sy.net
イシキダケタカイケイ
214:login:Penguin
18/07/09 12:21:03.01 4SJdzKl6.net
WSL上でDocker Engineが動くようになっていたっぽいという話
URLﾘﾝｸ(qiita.com)
215:login:Penguin
18/07/09 12:48:52.62 qh/Cnej+.net
マジかよDockerForWindows消してくる
216:login:Penguin
18/07/09 13:31:43.43 pfSJA2ey.net
もしかしてHyperV無しのHome版WSLでも動くようになってるのか
217:login:Penguin
18/07/10 17:37:18.97 hi/Ud89A.net
パブリッククラウドやDocker Hubに最適化した「Minimal Ubuntu」がリリース 2018/07/10 12:06:20
URLﾘﾝｸ(news.mynavi.jp)
Canonicalは2018年7月9日(米国時間)、パブリッククラウドおよびDocker Hubに最適したLinux
ディストリビューション「Minimal Ubuntu」をリリースしたことを明らかにした。
AWS(Amazon Web Services)およびGCP(Google Cloud Platform)を推奨パブリッククラウドとし、
イメージファイルはWeb上からダウンロ
218:ードできる。
219:login:Penguin
18/07/10 18:37:07.13 TEPxwuu8.net
ええやん
alpine使いにくいし乗り換えようかな
220:login:Penguin
18/07/11 00:29:12.16 dU5xb19g.net
minidebのUbuntu版みたいなヤツか
221:login:Penguin
18/07/11 13:45:07.36 Za+YUtMW.net
ええやん、なんぼなん
222:login:Penguin
18/07/12 01:08:55.93 Spx3HNht.net
展開後のサイズは約80MB前後でminidebのようなコンテナ特化支援コマンドはさすがに無いっぽいな
Ubuntu版の公式slimとしてapt系で最新パッケージ使いたいなら(Debianのslimじゃなくて)こっちでねって感じか
野良イメージじゃない公式スリムに選択肢が増えるのは嬉しい
223:login:Penguin
18/07/12 07:54:44.88 2fRy1rm8.net
debianよりも少ないの？
224:login:Penguin
18/07/12 08:05:41.95 uhTdlutY.net
alpineで慣れちゃった。
225:login:Penguin
18/07/13 09:30:31.30 PFiL2FSs.net
debian:stretch-slimは55MB
（bitnami/minideb:stretchは54MB）
ubuntu:bionicは81MBで去年から変わってないみたいだけど今回発表されたやつは何なんだいったい…
元記事タイトルにDocker Hubとあるが実は関係なくてアマとかGCPで使うimgファイルが小さくなりますたってことか
226:login:Penguin
18/07/15 20:58:09.55 9hWJVlJh.net
ミニマルすぎると一個ゲットした途端大量に依存がやって来る悪寒しかない
227:login:Penguin
18/07/15 21:53:50.81 rnlXfHys.net
ミニマムすき
228:login:Penguin
18/07/15 22:11:32.38 Xmkkcspf.net
エセロリやん
229:login:Penguin
18/07/19 17:07:15.56 4Cjfx+r5.net
「OpenNebula 5.6」公開、Dockerサポートの強化などが加わる 2018年7月18日15:00 末岡洋子
URLﾘﾝｸ(mag.osdn.jp)
クラウドインフラストラクチャ構築・管理プラットフォーム「OpenNebula」の開発チームは7月16日、
最新安定版となる「OpenNebula 5.6」（Blue Flash）を公開した。
Docker管理機能を新たに統合、任意のOpenNebulaクラウドで、Dockerアプリケーション実装の
土台となるDockerエンジンの仮想マシンをMarketplaceよりインポートできるようになった。また、
OpenNebula APIやインターフェイスを経由することなくDockerエンジンをシームレスに管理する
Docker Machineも統合した。
230:login:Penguin
18/07/27 03:51:52.83 6DSLURTJ.net
訳あってソースコードからビルドしないといけない物があるんだけど、
ビルドに必要なパッケージをインストールしたくない。
だからDockerでビルドして、インストール先はDockerの外って
やりたいんだけど、そういう使い方のノウハウって
どこかにまとまってないかなぁ？
ソースコードのディレクトリをボリュームにして
make installだけDockerの外でやるのが一番かなぁ？
231:login:Penguin
18/07/27 04:48:47.30 1joj4I21.net
そういうときはmake install先のディレクトリだけ -v でマウントしとくパターンが簡単で良いね
例えば ./configure --prefix=/usr/local で入れるやつはインスコ先になる/usr/localを
docker runのときに -v "/usr/local:/usr/local" って指定する
コンテナでmake installまでやれるしホストもソースやビルドツールで汚れないから安心
docker公式マニュアルのどっかに書いてあった気がしたが見当たらなくなってた
232:login:Penguin
18/07/27 07:25:43.45 7fogAuN8.net
詳しい解説サンクス
233:login:Penguin
18/07/28 15:41:09.29 0ikx9NUA.net
>>218
もう少しアイデアを発展させてみた。
このアイデアをどうするかは任せる
make install、前々からの問題。何処に何がインストールされるかわからない。
基本的には--prefixで指定した所だろうけれど、確実にそうとは言い切れない
make uninstall、これも前々からの問題。uninstallをサポートしているものが少ない
インストールした後消すのが大変
docker、make installでインストールされるファイルは多分レイヤーの差分を見ればわかる
インストールされるファイルがわかるのだから、それを消せばアンインストールになる
インストールするファイルも残っているのだから、ファイル内容を比較することで
アンインストール時に想定外のファイルを削除しなくてすむかもしれない
234:login:Penguin
18/07/28 16:06:06.83 PwMG08J6.net
今はMulti-stage buildが公式実装されて>>220のアイデアを綺麗に実現できるようになったね！
ビルドコンテナのmake install結果をホスト経由せずに実行用コンテナに簡単に乗せられる
ビルドコンテナも実行用コンテナも使い終わればコンテナごとすべて消せるから
--prefix完全無視の無作法野良ツールにホストのファイルが上書きされることもないし
make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない
235:login:Penguin
18/07/28 19:21:25.29 fgC/Ah69.net
>>221
> make uninstall非対応でもコンテナ消せば良いだけだからゴミが残ったりもしない
なんかちょっと違うｗ
インストール先はコンテナの外よ。だからコンテナ消せば良いだけってことにはならない。
どんなものでもコンテナ化して使えるかっていうと、例えば（独自ビルドの）gitコマンドを
コンテナに入れて使うのは大変だと思う。カレントディレクトリを見るし、
サブコマンド次第ではカレント以外のディレクトリも見るしね
インストールするファイルを知ることができるから、コンテナでビルドして生成したものを
コンテナの外にインストールしてアンインストールもしやすくなるだろうと言う話
236:login:Penguin
18/07/29 00:30:39.68 wo8fIaJv.net
最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな
俺もコンテナ上のgitからホストのカレントディレクトリを見る方法がわからんというごく最初の段階でつまずいた
絶対パス指定ならツールで使う主要ディレクトリを-vに指定しとけば大半普通に開けるけど
カレントを含めた相対パスも単に-v $(pwd):$(pwd) -w $(pwd)を書いておけばいいという基本をDocker Hubのgitイメージページ読んで知った
237:login:Penguin
18/07/29 01:53:02.32 vXZjVBrz.net
>>223
だから大変だからホストに直接おいたほうが良いって話なんだが
例えばgit diff --no-indexでカレント（gitディレクトリ）以外を
比較したくなったら-v $(pwd):$(pwd)じゃ対応できない。
他にもgit applyとかさ
-v $HOME:$HOMEにしたら動くかもしれないけど、
それでもhomeの外では使えないコマンドになってしまう。
（例えば/opt以下にgitリポジトリをcloneするツールとかさ）
コマンド実行した時、特定のファイルはコンテナの外を見ますが、
それ以外はコンテナの中を見てますとかややこしいだけだから
俺は頑張ったんだって自己満足してたいだけでしょ？
そんなのは意味がないから辞めたほうが良い
238:login:Penguin
18/07/29 01:54:06.34 vXZjVBrz.net
あ、そうだ。gitのglobal configがあるから、
絶対HOMEをボリュームにしないとだめなんだ。
239:login:Penguin
18/07/29 01:57:06.96 vXZjVBrz.net
ssh鍵の話もあったな
-v $(pwd):$(pwd) -w $(pwd)を書いておけばって
実際には使ってないだろ。
コンテナ化に適してないアプリをコンテナ化しても使いにくいだけ
240:login:Penguin
18/07/29 02:32:06.22 vXZjVBrz.net
面白い例を思いついた
> 最初のうちはエディタとかgitとかはどうしても大変に思えてホストに直接置きたくなるんだよな
エディタとgitをコンテナにするとどうなるか
環境変数GIT_EDITOR、コミットメッセージなどを編集する時に使用されるエディタをしている。
まあGITが使う多数の環境変数をコンテナの中に渡す。これだけでも面倒くさくてやりたくないが、
gitをコンテナの中で動かしたりすると、エディタがコンテナの中で起動される
つまり、gitコンテナの中にエディタまで入れないといけない。
さてそのエディタ、当然（？）のごとく
241:git連携機能がついている。 エディタからgitを呼び出されるならば、エディタのコンテナの中に、gitを入れないといけない 環境変数？ おっと、gitコンテナの中でエディタを起動するならば、 エディタで使う環境変数も、gitコンテナに渡さないといけないな。 おっと、エディタからgitを呼び出すこともあるから、エディタのコンテナを実行する時も gitの環境変数を渡さないといけないな はは、乾いた嘲笑の笑いしか出てこない。こんなムダでややこしいことやって なんの意味があるんだ。
242:login:Penguin
18/07/29 18:09:34.64 PCsU6lV8.net
長くて全部読んでないけど、ホスト側のgitなりエディタ設定なりに依存するようなコンテナって筋悪くない？
k8sとかでコンテナを別ホストに移動したら使えなくなるような気がする。
243:login:Penguin
18/07/29 18:12:14.75 PCsU6lV8.net
エディタが何かによるけど、vim程度ならコンテナ毎に入っててもいいのでは。有償のIDEでgit連携して使ってる人にとってはちょっとしんどいとかかな。
244:login:Penguin
18/07/29 20:28:18.31 vXZjVBrz.net
そりゃ単に、
普通は使わないけど入っていても良い。イメージのサイズがでかくなるだけ。
程度のことだな
普通はコンテナのイメージはDockerfileで作るし、コンテナの中のファイルを
直接修正することはない。Dockerfileの開発中とかデバッグのために
便利かもーぐらいで入れておいてもいいが、最終的には使わんので消す
コンテナ内のvimは使わない。の意味がわからんやつは
勉強し直したほうが良い
245:login:Penguin
18/07/29 21:46:50.04 PCsU6lV8.net
え、普通にvim使ってるけど。何でなの？
246:login:Penguin
18/07/29 21:48:26.84 PCsU6lV8.net
本番環境って前提ならそもそも本番で稼働している設定ファイルはみだりに編集しないってのは分かるけど。
単にコンテナ内でvim使うかどうかって話だとしたら本気で意味分からん。
247:login:Penguin
18/07/29 21:51:36.18 PCsU6lV8.net
コンテナの中のファイルは絶対編集しないってどういうことなんだろう。良くあるベストプラクティスに書いてあるから盲目的にそうするって事だとしたら、はぁ、そうですかで話終わりにするけど。
248:login:Penguin
18/07/29 22:27:59.92 Hv8rsH9m.net
>>238
Dockerはアプリケーションコンテナと言って、
アプリケーションをコンテナ化するもの
システムコンテナと違って、コンテナの中で作業するためのものじゃない。
だから、vimという手動で作業するツールをコンテナに入れる意味はないし、
vim自体をコンテナ化しても使いづらいことは説明済み
> 良くあるベストプラクティスに書いてあるから
ベストプラクティスレベルの話じゃない。Dockerの使い方の基本の話。
とりあえずアプリケーションコンテナとシステムコンテナの
違いぐらい学習してから出直せ
249:login:Penguin
18/07/29 22:32:59.80 /XpMabXH.net
ドヤ顔で未来にエスパーしてて草
250:login:Penguin
18/07/29 22:49:16.80 Hv8rsH9m.net
内容は間違えてないだろ？ﾆﾔﾘ
251:login:Penguin
18/07/29 23:31:49.15 PCsU6lV8.net
>>234
アプリケーションコンテナとシステムコンテナの違い、ですか。そうですか。
教科書にはきっとそう書いてるんでしょうね。その辺はよく知らないけど、たぶん間違ってないんだと思います。
でも、私はDockerで開発するファイルも編集します。はい。
252:login:Penguin
18/07/29 23:37:55.72 PCsU6lV8.net
コンテナでsshd起動してsshでアクセスするなとかいうのも基本としてあるってのは聞いたことある。
けどそんなの関係ねぇ。
実際エンジニアに開発環境としてコンテナ提供するのにsshでアクセスできないって不便でしかない。
253:login:Penguin
18/07/29 23:54:22.87 PCsU6lV8.net
ちなみにシステムコンテナってSolarisのzoneみたいなものかな。Linuxだと何かあるのだろうか。
254:login:Penguin
18/07/30 01:20:21.45 QZl1Bega.net
>>237
コンテナの中にあるファイルはコンテナ削除すると消えるでしょ？永続化しない。
残っていてほしいファイルはボリュームでコンテナの外にだすわけだから
そのファイルの編集はコンテナの外でやれば良いわけ
中にvimを入れておくのは開発中とかの一時的にしかやらんよ
っていうか使いづらいでしょ？ あんたvimの設定とかしてないの？
デフォルト設定で使いづらいからカスタマイズするのが常識だけど
コンテナの中にあるのはなんの設定もされてないvimじゃん
255:login:Penguin
18/07/30 01:23:38.82 QZl1Bega.net
>>238
関係ないとか言ってないで、自分の
256:解釈が大きくずれているって考えたほうが良いよ ちょっと間違いレベルじゃなくて、方向性が大きくずれている 変な使い方をしているから、使いづらく感じるんだよ
257:login:Penguin
18/07/30 06:34:10.24 jEBEwRTJ.net
>>240
残ってほしい開発後のプログラムがあるならgitでpushしとけば良くない？
設定あんまりシナイ派だけど、仮にするとしても、それこそvimrcとかgitでpushしてるものをcloneで持ってくれば設定なんて一撃で終わらない？それじゃあダメな理由とかある？
258:login:Penguin
18/07/30 06:40:38.62 jEBEwRTJ.net
>>241
解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。
どんなに正しくても実際に使い難ければ正しくてもやらない。
もちろんセキュリティーや影響は考慮するけど、その辺問題なければ基本がどうとか関係ない。
PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。
259:login:Penguin
18/07/30 06:42:13.68 QZl1Bega.net
>>242
gitは作業中断時に一時保存するための道具じゃないし、
設定しないなんて使いづらいだけだし、
いちいちcloneするとか面倒くさいことこの上ないし、
ホストでやれば普通にできることを、いちいちやらないといけないのか？
間違ってる方向に進むとこれから、あれやこれが使いにくいって愚痴るだけだぞ
すでに愚痴ってそうだがｗ その原因はすべて間違った使い方にある
変な癖が付く前に矯正したほうがいい
260:login:Penguin
18/07/30 06:43:07.14 QZl1Bega.net
>>243
> 解釈がどうじゃなくて、実際便利に使えるかどうかが問題なんだけど。
便利に使うための手段を、お前がみんな捨ててるから、
（俺は不便な中で生活してるから）不便に思わないんだって言ってるだけじゃん
261:login:Penguin
18/07/30 06:44:51.91 QZl1Bega.net
>>243
> PMBOKとかAgileとか、基本に忠実にそのままやったら余計効率が悪くなって使えたもんじゃないでしょ。教科書守れば良いって思考は実用的な効率を犠牲にする。
お前のその考え方だと、間違った解釈をして間違ったやり方をやって
余計効率が悪くなった。PMBOKとかAgileはクソって言ってるようにしか見えないね
まず教科書守ってやろう。いまお前は教科書通りのことを守らずに使いづらいと言ってる
262:login:Penguin
18/07/30 06:48:28.40 jEBEwRTJ.net
>>244
一時保存なんて利用用途で言った覚えはないけど、仮にそうだとしても何で一時保存でgit使ったらダメなの？
あなたって基本に従うってことに束縛されて思考が限定されてる気がする。自分だけでそういう方針で進めるのは勝手だけど、人にやり方強制しだすと嫌われるから考え改めた方が良いよ。
新卒ならまだ良いけど。
263:login:Penguin
18/07/30 06:51:41.70 jEBEwRTJ.net
>>245
よくわからんけど、君の言ってるようにアプリケーションコンテナの中のファイルは編集するなって事を守ると何が便利なの？物凄く不便じゃない？
ローカルなホストにファイルを永続化させるよりgitにpushする方が安心感あると思わない？
264:login:Penguin
18/07/30 06:52:59.21 QZl1Bega.net
>>247
gitはバージョン管理するための道具であって、
バージョン管理しないならタダの保存に過ぎないから
それにgit使うなら、コミットする時に、メールアドレスと名前の設定がいるだろ？
gitでpushするならssh鍵が必要だろ？
rootでやるわけないから、自分のhomeディレクトリがいるだろ
お前本当にコンテナの中でgitでpushとかしてるんか？
してねーだろ。使いづらいもんな
お前はまだ初心者で、どうせgitもオープンソースものをcloneするぐらいのことしか
したこと無いんだろ。基礎ができてないんだからまず教科書通りにやれと
265:login:Penguin
18/07/30 06:54:15.51 jEBEwRTJ.net
PMに教科書通りのやり方を強制されて疲弊してる現場を見てきたから経験談として話してるだけ。
教科書通りやって現場がうまくまわってるならそうすればいいよ。
というか、むしろ教科書なぞってうまくいってる現場があるならそれ勉強会とかで話してほしい。見に行くので。