Docker Part2©2ch.net

1: login:Penguin 転載ダメ©2ch.net 2017/09/28(木) 14:00:45.18 ID:/4TtIqGt

2: login:Penguin 2017/09/28(木) 19:24:33.96 ID:pP51x30K
もうLXCに依存してないんじゃ?

3: login:Penguin 2017/09/29(金) 11:42:26.61 ID:/O2TcHk2
そうだね
前スレからそのまま持ってきてしまったか

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

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

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

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

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

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

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

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

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

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

11: login:Penguin 2017/11/12(日) 21:27:42.49 ID:uiCH3XRM
Linux板で言うことじゃないかもしれないけどWindowsでもHyper-Vで使えるようになってたんだな
Bash on UbuntuにDockerも使えてWindowsPC強制されて虐げられてもなんとかなるぜ

12: login:Penguin 2017/11/12(日) 21:43:45.89 ID:CsnX2d3s
>WindowsでもHyper-Vで使えるようになってた
Windows以外で使えるHyper-Vなんてあるの?

13: login:Penguin 2017/11/12(日) 22:36:56.33 ID:uiCH3XRM
VirtualBoxが不要ってことを言いたかった

17: login:Penguin 2017/12/03(日) 18:48:03.66 ID:zS+bJMf6
docker使うとこ増えたけど
アホって綺麗なサンプルいっぱいあるのになぜか設定ファイルグチャグチャ作るのな
結局構成管理出来ないだろ、あんなんじゃ

21: login:Penguin 2017/12/13(水) 11:04:20.12 ID:ZUZ9fAW9
docker系の技術は日進月歩すぎるのでredhatやcentosのような枯れたOSで使うのはきついですよね?
色々入れたり設定が必要だし。
お勧めなディストリはやはりubuntuやfedoraなどですか?

22: login:Penguin 2017/12/13(水) 16:46:00.16 ID:4HtuxJmh

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

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

30: login:Penguin 2017/12/14(木) 22:49:08.96 ID:j6ffG0Yu
coreosで使ってるっていう生粋のドッカーはいないのか?

32: login:Penguin 2017/12/15(金) 05:01:05.33 ID:gXJiZmqG
coreOSってalpine以上に使いにくくて何が良いの?って感じなんだけど何か取り柄はあるのかね

41: login:Penguin 2017/12/19(火) 12:43:18.15 ID:Unb97h+7
これからはなんでもかんでもコンテナって時代になるのですかね?
自前でリポジトリをシコシコ築いてきたディストリベンダーも
もはややる意義を失っちゃったりするんですかね?

44: login:Penguin 2017/12/19(火) 21:21:37.08 ID:qjPggouG

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

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

50: login:Penguin 2017/12/20(水) 15:46:11.75 ID:ZRehS3G5
コンテナは昔からあっただろ
Linuxに来るのが遅かっただけで

54: login:Penguin 2017/12/24(日) 22:37:12.09 ID:rLGBbeuy
dockerコンテナってホストOSのカーネル使ってるの?
どこもそう説明してるんだけど、ベースイメージにlinuxつかってその上にmysqlとか載せてイメージ化してるって認識だったんだが。

55: login:Penguin 2017/12/24(日) 22:40:54.12 ID:BfGqUwPY
ホストのカーネルを使っているという説明で合っているよカーネルの上で動かすカーネルとかもうそれVMじゃん

59: login:Penguin 2017/12/24(日) 23:52:48.02 ID:FG7A/gM3

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

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

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

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

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

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

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

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

56: login:Penguin 2017/12/24(日) 22:58:36.30 ID:rLGBbeuy

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

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

57: login:Penguin 2017/12/24(日) 23:14:23.88 ID:jQND+IMW

58: login:Penguin 2017/12/24(日) 23:22:26.32 ID:rLGBbeuy

>>57

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

60: login:Penguin 2017/12/24(日) 23:57:01.81 ID:FG7A/gM3

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

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

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

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

それが大変な作業だった

61: login:Penguin 2017/12/25(月) 00:07:51.54 ID:132x0Uuj

さて、ここまではパソコンにインストールされたものがLinuxの場合だけど
WindowsやMacOSはどうなっているのか?

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

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

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

仮想マシンを使っていると言ってもDockerに最適化されており
Windows もしくは MacOS のCUIからdockerコマンドを動かすとちゃんと
使えるように構成されており、まるでLinuxと同じようにOSの上に直接dockerが
起動しているようにみえる。だけど実際は仮想マシン上で動いているので
Dockerの設定画面にはメモリをどれだけ仮想マシンに割り当てるかなどという設定が存在する

62: login:Penguin 2017/12/25(月) 00:11:59.89 ID:132x0Uuj

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

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

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

63: login:Penguin 2017/12/25(月) 11:30:09.88 ID:+uvKLng+
>>62
親切すぎて草
下手な記事よりわかりやすい

65: login:Penguin 2017/12/25(月) 23:01:24.32 ID:gZwRVfZh

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

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

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

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

68: login:Penguin 2017/12/26(火) 03:07:47.91 ID:+n8uGZb5

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

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

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

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

71: login:Penguin 2017/12/26(火) 12:31:53.02 ID:KRPyxQju
俺も最近、Docker for Windows入れてみてたばかりなんで、HyperVが必要な理由とかが分かって参考になった

73: login:Penguin 2017/12/26(火) 23:58:14.94 ID:+n8uGZb5

Dockerっていうのはクライアント・サーバー型の設計になってる
つまり通常端末から実行しているdockerコマンドとサービスとして実行する
dockerサーバーが存在する(紛らわしいことにどちらもdockerコマンド)

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

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

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

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

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

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

もう一つ思い出したが、Docker for WindowsはHyperVで動いているのでVirtualbBoxとは同居できない
vagrantを使うのならVagrant+VirtualBoxではなくVagrant+HyperVで使う必要がある

74: login:Penguin 2017/12/28(木) 15:12:36.60 ID:LWC+fC47

>>73
勉強になります

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

76: login:Penguin 2017/12/28(木) 23:05:22.59 ID:BIGMxhMF

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

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

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

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

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

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

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

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

95: login:Penguin 2018/02/05(月) 13:34:29.22 ID:k5aVtYPL

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

RUN yum list

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

96: login:Penguin 2018/02/07(水) 01:28:24.21 ID:G933ziiv

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

$ cat Dockerfile
FROM centos

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

97: login:Penguin 2018/02/08(木) 17:41:54.10 ID:lNZDnl+7
>>96
便利なやり方が無いかなーと思って。
一度起動してその出力を回収する方法しかないね。

98: login:Penguin 2018/02/14(水) 02:35:31.11 ID:XB7JYlAs

/var/lib/docker/tmp
/var/lib/docker/containers
→単純にtmpfsにできる

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

/var/lib/docker全体をtmpfsにすれば整合性もハードリンク問題も解決するけど
消費メモリが増えるのとanything-sync-daemonとかでバックアップの手間も増える
システム再起動後にコンテナ自動起動しないならsync不要だけどイメージダウンロードからやり直しになって鬱陶しかった

100: login:Penguin 2018/02/15(木) 12:06:04.40 ID:2MLB8/h1

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

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

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

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

104: login:Penguin 2018/03/11(日) 02:47:30.63 ID:FdJN57de

>>101
使っていませんw

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

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

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

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

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

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

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

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

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

103: 塩水 ◆1FrMT.vzQQ 2018/03/11(日) 02:32:17.59 ID:hSBnN7Ry
クリーンな状態からのAnsibleの実行検証がコマンドレベルでできて便利。
昔はVM作り直したり、スナップショットから復元したりしてたけど、今はそのマウス操作すら煩わしくなってしまってる。

105: login:Penguin 2018/03/11(日) 02:55:22.05 ID:FdJN57de

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

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

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

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

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

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

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

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

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

109: login:Penguin 2018/03/11(日) 04:16:58.61 ID:FdJN57de

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

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

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

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

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

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

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

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

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

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

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

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

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

114: login:Penguin 2018/03/11(日) 11:20:29.98 ID:FdJN57de

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

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

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

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

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

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

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

110: login:Penguin 2018/03/11(日) 04:26:48.50 ID:FdJN57de

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

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

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

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

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

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

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

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

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

115: login:Penguin 2018/03/11(日) 11:22:42.29 ID:FdJN57de

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

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

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

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

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

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

128: 塩水 ◆1FrMT.vzQQ 2018/03/11(日) 19:43:24.47 ID:hSBnN7Ry
こういう作業をAnsibleやServerspecでやろうとすると
コマンドが異様に長くなるのでラッパースクリプト書いたりするのですが、
シェルスクリプトはそこで今でも大活躍してます。
なんだかんだで便利なんですよねシェルスクリプト。

129: login:Penguin 2018/03/11(日) 21:42:47.19 ID:yaKRWAT9

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

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

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

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

130: login:Penguin 2018/03/11(日) 23:36:05.79 ID:gLOQBJNa

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

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

131: login:Penguin 2018/03/12(月) 00:00:41.81 ID:iAV7tz/N

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

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

133: login:Penguin 2018/03/12(月) 00:13:02.11 ID:0gO9Md9Y

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

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

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

132: login:Penguin 2018/03/12(月) 00:09:31.95 ID:0gO9Md9Y

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

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

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

135: 129 2018/03/12(月) 01:34:06.50 ID:cIbUTTA5

bash のスクリプトだろうと、Python だろうと golang だろうと関数は普通に使うね。

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

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

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

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

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

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

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

165: login:Penguin 2018/05/28(月) 20:34:50.01 ID:G/OxqctX

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

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

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

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

166: login:Penguin 2018/05/28(月) 21:14:26.05 ID:5P04jZKi
>>165
いや、知らんよ
俺は開発元が進めてきたものを使うだけ

172: login:Penguin 2018/06/24(日) 08:47:17.87 ID:TokMwylE
pullしたubuntuイメージにvimが入っていないんだけど・・・
aptコマンドもないんだけど・・・
docker search ubuntuで出てくるうち全部入りのイメージってどれ?

176: login:Penguin 2018/06/25(月) 09:49:22.67 ID:+pzgGIIi

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

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

177: login:Penguin 2018/07/01(日) 03:55:45.96 ID:+w2giTsy

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

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

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

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

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

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

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

179: login:Penguin 2018/07/01(日) 09:21:20.95 ID:+w2giTsy

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

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

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

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

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

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

180: login:Penguin 2018/07/01(日) 09:23:55.84 ID:+w2giTsy

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

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

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

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

173: login:Penguin 2018/06/24(日) 22:35:20.55 ID:anZc79Me
dockerってコンテナが動いてる途中でdocker終わらせたらコンテナ内に保存してたファイルはなくなるの?

175: login:Penguin 2018/06/25(月) 09:42:17.00 ID:+pzgGIIi

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

How to start a stopped Docker container with a different command?
I would like to start a stopped Docker container with a different command, as the default command crashes - meaning I can't start the container and then use 'do...

231: login:Penguin 2018/07/29(日) 21:48:26.84 ID:PCsU6lV8
本番環境って前提ならそもそも本番で稼働している設定ファイルはみだりに編集しないってのは分かるけど。
単にコンテナ内でvim使うかどうかって話だとしたら本気で意味分からん。

232: login:Penguin 2018/07/29(日) 21:51:36.18 ID:PCsU6lV8
コンテナの中のファイルは絶対編集しないってどういうことなんだろう。良くあるベストプラクティスに書いてあるから盲目的にそうするって事だとしたら、はぁ、そうですかで話終わりにするけど。

233: login:Penguin 2018/07/29(日) 22:27:59.92 ID:Hv8rsH9m

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

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

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

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

236: login:Penguin 2018/07/29(日) 23:31:49.15 ID:PCsU6lV8

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

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

239: login:Penguin 2018/07/30(月) 01:20:21.45 ID:QZl1Bega

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

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

241: login:Penguin 2018/07/30(月) 06:34:10.24 ID:jEBEwRTJ

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

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

243: login:Penguin 2018/07/30(月) 06:42:13.68 ID:QZl1Bega

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

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

246: login:Penguin 2018/07/30(月) 06:48:28.40 ID:jEBEwRTJ

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

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

248: login:Penguin 2018/07/30(月) 06:52:59.21 ID:QZl1Bega

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

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

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

237: login:Penguin 2018/07/29(日) 23:37:55.72 ID:PCsU6lV8
コンテナでsshd起動してsshでアクセスするなとかいうのも基本としてあるってのは聞いたことある。
けどそんなの関係ねぇ。
実際エンジニアに開発環境としてコンテナ提供するのにsshでアクセスできないって不便でしかない。

240: login:Penguin 2018/07/30(月) 01:23:38.82 ID:QZl1Bega
>>237
関係ないとか言ってないで、自分の解釈が大きくずれているって考えたほうが良いよ
ちょっと間違いレベルじゃなくて、方向性が大きくずれている
変な使い方をしているから、使いづらく感じるんだよ

242: login:Penguin 2018/07/30(月) 06:40:38.62 ID:jEBEwRTJ

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

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

249: login:Penguin 2018/07/30(月) 06:54:15.51 ID:jEBEwRTJ
PMに教科書通りのやり方を強制されて疲弊してる現場を見てきたから経験談として話してるだけ。
教科書通りやって現場がうまくまわってるならそうすればいいよ。
というか、むしろ教科書なぞってうまくいってる現場があるならそれ勉強会とかで話してほしい。見に行くので。

254: login:Penguin 2018/07/30(月) 07:00:14.56 ID:QZl1Bega

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

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

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

263: login:Penguin 2018/07/31(火) 20:23:57.73 ID:GXqvrTdQ

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

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

264: login:Penguin 2018/07/31(火) 20:24:57.09 ID:GXqvrTdQ
と、書き込んでからひらめきました。
WSLで使ってるのはWindows上のDockerなので
パスの指定をC:\~でやらないといけないきがします。

265: login:Penguin 2018/07/31(火) 20:28:45.59 ID:C0KTXAUF

ビンゴでした!

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

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

281: login:Penguin 2018/08/01(水) 07:01:51.20 ID:rxe3lfEn

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

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

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

284: login:Penguin 2018/08/01(水) 07:52:42.75 ID:vZ5iA/aw

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

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

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

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

アプリのコード読んで必要なものを調査するとかやんなくていいよ
俺がコンテナのイメージつくってやっからさ、
お前はそれ動かすだけ。おまえにできないことはやらなくていい
お前はDockerr動くLinuxマシンだけ用意してればいい

288: login:Penguin 2018/08/01(水) 10:07:33.31 ID:oUHlYMq4
それだけDockerの理解・運用は難しいということだな
俺本読んでもさっぱりわからんかったもん
コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
コンテナ=アプリとその動作環境をパックにしたものと
ここで教わったが、アプリがIPアドレスを持つわけないだろう

290: login:Penguin 2018/08/01(水) 10:32:58.00 ID:V8uA/puM
>>288
UNIXソケットを使わない場合にアプリケーション間のデータのやり取りはTCPやUDPで行われることが多いと思うのだけれど, そうするとIPアドレスがないと困るだろう
特にロードバランシングしていると同一ホスト上でないことが普通なので, ソケットが使えないことが多い

292: login:Penguin 2018/08/01(水) 18:21:54.43 ID:vZ5iA/aw

>>288
> コンテナがIPアドレスを持つって聞いて、ファッ?ってなったわ
> コンテナ=アプリとその動作環境をパックにしたものと
> ここで教わったが、アプリがIPアドレスを持つわけないだろう

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

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

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

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

Dockerの仕組みに詳しい人はネットワークについても勉強するだろうけど
Dockerを使っている段階では、コンテナがどのIPアドレスを
持ってるかなんて意識していない

293: login:Penguin 2018/08/01(水) 18:23:53.95 ID:vZ5iA/aw

>>288
> それだけDockerの理解・運用は難しいということだな

技術職っていうのはそういうもんだよ。
ソフトウェアにおいて技術=知識
知識を得て楽をするか、知識ない人は力ずくで頑張れと

300: login:Penguin 2018/08/02(木) 06:34:51.81 ID:rhKXtEAo

そこで働く人間無視して仕事できる訳ないし、やってるつもりなら大した仕事してない。

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

インフラエンジニア要らないってのは理想。ただ、その理想を妨げる事が多いのが声がでかいアプリエンジニア。
大概やりたいようにやって自分では運用回らなくなって、別の誰かに運用を押し付けて自分はフェードアウトするってのがお決まりのパターン。

301: login:Penguin 2018/08/02(木) 07:40:01.26 ID:a1K3N0Xu

>>300
そういう話じゃねーよ

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

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

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

「Dockerの適している使い方は○○です」って結論した後
心の中で「でもうちでは技術者のスキルが低くて使えるやついないんだよ。」って泣けばいいだろ
他の人には関係ない話だ

302: login:Penguin 2018/08/02(木) 08:13:38.44 ID:a1K3N0Xu

>>300
> インフラエンジニア要らないってのは理想。

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

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

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

どうせこういうことすら思いつかなかったんだろ?
だからお前がアプリケーションが動くサーバー作ったことねーだろってわかるんだよ。

303: login:Penguin 2018/08/03(金) 23:40:03.86 ID:1yCRuO5i

数日かけてDocker使って個人用のミニアプリ書いたぜ

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

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

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

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

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

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

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

docker使えば、さっき書いたdocker run~のコマンドだけで構築できるというのに。

304: login:Penguin 2018/08/05(日) 08:47:03.44 ID:t1pjwXO7
すごいドヤ顔w

308: login:Penguin 2018/08/05(日) 21:53:21.43 ID:9sU0s1Rh
わざわざdocker使わんでもchrootでいいことにdocker使ってる人が結構いる

311: login:Penguin 2018/08/05(日) 23:04:52.65 ID:NroY7Fy3

>>308
chroot使うぐらいならDocker使うなー

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

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

懐かしくてちょっとググってみたけど、
あんな面倒なことやってたのかって思った

325: login:Penguin 2018/08/07(火) 20:42:05.65 ID:KYfMTuuE

いわゆるインフラ屋はDockerを使って
ディストリによってパッケージが用意されてるようなものを
Dockerイメージ化するという発想になりがちに思える

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

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

だからアプリが動く環境も含めてDockerイメージにする
そうすりゃDockerさえ動いていれば、簡単にどこでも動くものが作れる

327: login:Penguin 2018/08/08(水) 01:40:00.74 ID:H2RB231p
VMはカーネルやデバイスノードがゲストに独立して用意されているからサンドボックスとして安心できる
これらをホストゲストで共有してるDockerは、ライフラインを共有しているゲストハウスみたいなもの
カーネルぶんのメモリ(敷金礼金)は浮くがinit以降のメモリ(賃料)は当然払わなければならない
起動も10秒以下の差
つまりデスクトップならVM常道

344: login:Penguin 2018/08/09(木) 13:04:39.32 ID:xAQpubuL

>>343
今までの話の流れからすると、CIでテスト実行するたびにVMの作成と破棄をしていたってことでしょ?
>>327がVMでも10秒以下の差しか無いから問題ないみたいなことを言ってるから
(VMの中でDocker-Composeが動いてるのは、この話にあまり関係ない)

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

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

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

DockerでもアプリごとにDockerイメージが必要になるのは同じだが
Dockerはキャッシュがあるから、Dockerイメージの作成は短時間でできる。
VMだとキャッシュはないし起動に10秒かかるし、作成したイメージの
サイズもでかいし頻繁にVMイメージの作成なんかやってられないよ

333: login:Penguin 2018/08/08(水) 04:40:02.13 ID:tyC3gFls

ま、そもそもVMとDockerは違うもので、両方を組み合わせて使うものなんだけどね

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

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

目的が違うものなんで、Dockerの代わりにVMを使うとか
VMの代わりにDockerを使うとかいう発想がそもそもズレてる

337: login:Penguin 2018/08/08(水) 10:57:28.63 ID:tyC3gFls

物理マシンもVM(仮想マシン)も、俺にとっては同じマシン扱いなんだわ
形あるハードウェアで形作られてるかそうでないかの違い。

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

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

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

ってこと。

アプリをサンドボックス化するためにマシンを作るとか重すぎでしょw
まさに牛刀割鶏、鶏をさばくのに大きな牛刀を使うようなもの

448: login:Penguin 2018/10/26(金) 03:04:33.03 ID:UuZWwwD+

Dockerがやはりまだ理解しきれておらず、、、

理解が全然違うか教えて欲しいのだけど、
nginx + uwsgi + flaskでサイトを開発したい場合は、ローカルでコードを書いて、
DockerfileにBusyBox + nginx + uwsgi + flaskを入れるように?設定して
docker buildを行うと、書いていたpythonコードと必要なコンポーネントが
まとまったdocker imageがサーバー上に出来上がり
docker runする事によりdocker imageから生成されてインスタンスが立ち上がる
であってる?
docker imageがclassでrunするとオブジェクトが出来上がると理解しているのだけれど、、、

449: login:Penguin 2018/10/26(金) 06:35:45.90 ID:xzHCVt/i
>>448
なぜあえてクラスとオブジェクトに絡めて理解しようとするのか。

450: login:Penguin 2018/10/26(金) 07:03:02.70 ID:Y5itkZBt
>>448
仕事で必要とかじゃなければ無理して理解する必要ないと思うよ
一般庶民が微分積分を理解できないように、一般プログラマにはDockerは難解過ぎる

452: login:Penguin 2018/10/26(金) 07:41:20.37 ID:S+WdRTJT
>>450
× 一般プログラマにはDockerは難解過ぎる
○ お前にはDockerは難解過ぎる

451: login:Penguin 2018/10/26(金) 07:40:58.49 ID:S+WdRTJT

>>448
なにを一塊のウェブアプリにしたいかだよ。

まず前提としてflaskだけでも、組み込みサーバーを使うことでウェブアプリとして使える
だけど、これは開発用なので公開用としては使わない。なのでflaskだけでは
ウェブアプリにはできないという扱いにする

では、flask + uwsgi ではどうか? ウェブアプリとして使えるよね
(pythonあんまり詳しくないから間違ってるかもしれないが)
https://qiita.com/ekzemplaro/items/7757a6544205384e40ad

だから flask + uwsgi で1つのDockerコンテナにするのもあり
この場合、nginxとはhttpでつなぐことになるかな。
socket経由でできるかはわからない。
nginxはnginxで1つのコンテナにして、2コンテナでシステムを構成する
(docker-composeを使えば、複数のdockerコンテナを同時に起動できる)

また flask + uwsgi + nginx まで入れてしまうのも良い
前者との違いとしては、例えば静的ファイルはnginxで配信したい場合に
前者なら別のサーバーで配信することで負荷を下げるという構成が取れる
その反面2コンテナなので少し面倒になる。使うのがお手軽なのは後者

ま、理解できてないのはこの話じゃなさそうだけどねwww

454: login:Penguin 2018/10/26(金) 09:37:10.67 ID:UuZWwwD+

>>451
伝わらなくてごめんごめん
たしかにコンテナ分けると負荷が下がるとかは知りたいこととはまったく関係ない

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

一般プログラマーからしてdocker imageは関係ないのなら調べるのやめるんだけど、
インフラから事前告知があったので影響あるのかと不安になった

455: login:Penguin 2018/10/26(金) 09:58:02.43 ID:S+WdRTJT

>>454
C言語とかコンパイル言語使ったことある?
dockerのbuildは、C言語などのビルド(コンパイル)と同じ

言語はソースコードをビルドして実行バイナリを作成する
Dockerはすでにある複数のバイナリをもとに、Dockerイメージを作成する

さて、実行バイナリは、データを保存したらどこに保存されるか?
実行バイナリの中に埋め込まれるわけじゃないよね。実行バイナリの外のファイルに保存する。
実行バイナリ自体は読み取り専用。ビルドしたときに作成したバイナリから変更することはない

Dockerも同じように考える。Dockerイメージっていうのはビルドして作成した状態から変更しない
内部的には変更されていてそのデータはどこかに残っていたりするが、そういうのは内部の話なんで忘れる
Dockerイメージは読み取り専用で、Dockerイメージをrun(実行)するとプロセスが起動する
あ、ここも実行バイナリと同じだね。バイナリを実行するとプロセスが起動する

Dockerイメージをrunして作ったプロセス(=Dockerコンテナ)はどこにデータを保存するか?
Dockerイメージは読み取り専用なので、当然Dockerコンテナの外のファイルに保存する。

C言語 ・・・ ソースコード -> [Makefileでビルド] -> 実行バイナリ
Docker・・・ソースコード等 -> [DockerfileでDockerビルド] -> Dockerイメージ

Dockerのソースコード等には本当にいろいろ含まれる
アプリのソースコードだったり、nginxだったり。カーネル以外の全て

で、コード消えるのか?っていう疑問の答えは、実行バイナリ消してもソースコードをビルドすれば作れるでしょう?
Dockerも同じでソースコード等をビルドすれば、Dockerイメージができるんだから何も問題ない

458: login:Penguin 2018/10/26(金) 10:20:16.70 ID:S+WdRTJT

>>454
> インフラチームではないから詳しい構造とか構成は知らなくていいんだけど、開発側からして
> なにか変わるのか事前に理解したくて。

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

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

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

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

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

理想は
開発チーム・・・Dockerfileのメンテナンス(Dockerイメージを作成できるようにする)
インフラチーム・・・Dockerイメージの実行
なのだが、現実としてDockerはインフラチーム主導で導入されることが多いので
インフラチームのサポートでDockerfileを作っていくことになるだろう

456: login:Penguin 2018/10/26(金) 10:06:27.87 ID:S+WdRTJT

で、ウェブ開発の際に使う場合に、これじゃ使いづらい場合がある

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

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

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

ただね。Dockerイメージで作る実行環境は、本番用環境と同じにだいたいするので
デバッグなどはし辛い。だから通常のアプリ開発はDockerを使わないほうが楽だろう
だが、いつでも本番用環境を手元で作り出せると、本番用環境でのみ発生するバグなど避けられる
他の人も誰でも本番用環境で検証できるようになるわけだ

457: login:Penguin 2018/10/26(金) 10:18:44.97 ID:UuZWwwD+
>>456
すごいわかりやすい説明
コンパイラに例えてもらえると分かりやすいわ
ありがとう

460: login:Penguin 2018/10/26(金) 10:29:10.46 ID:S+WdRTJT

Dockerを仮想マシンの代わりとしてとか考えてると

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

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

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

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

バイナリに例えれば、C言語のプロセスに乗り込んで(デバッガで?)
プロセスのメモリを書き換えて、プロセス部分をディスクに書き出すようなもんだよ
そんなことしないだろ?

461: login:Penguin 2018/10/26(金) 10:34:41.20 ID:S+WdRTJT

> 今までdocker = vmと考えてたのでファイルの保存などが混乱してたけど、virtualenvの凄い版と考えた方がいいのね

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

virtualenvは実行環境を作るもの
Dockerは実行環境を含めた実行イメージ=Dockerイメージ=実行バイナリの凄い版を
作るものだから

462: login:Penguin 2018/10/26(金) 10:39:21.79 ID:UuZWwwD+

>>461
やっとそこの理解ができた
インフラがDocker推すのわかるわ

virtualenvのpython周りをなんとなくコンテナ化したのとはちがって、OS含めた実行環境コンテナを作れるとなると、ほんといろいろ解決できるな!

464: login:Penguin 2018/10/26(金) 10:56:20.22 ID:S+WdRTJT

>>462
Dockerイメージを新しく(バージョンアップ)したから、
次からこれ使ってーって開発チームはインフラチームに依頼するだけでよくなる

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

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

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

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

本気でやれば、いろいろ解決するよ。ただそのためには
インフラチームに丸投げじゃだめだけどね

591: login:Penguin 2018/12/03(月) 15:49:40.97 ID:ZaL3qC8p
Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある

595: login:Penguin 2018/12/03(月) 22:26:31.99 ID:n05/OnLG
>>591
やっとdocker-composeわかりかけて
きたとこなのに(>_<)

596: login:Penguin 2018/12/03(月) 23:40:38.53 ID:fVhmASLK
>>595
いやいや、docker理解できないと使えないから安心して
そもそも、個人開発でkuburnetes必要なくない?

598: login:Penguin 2018/12/04(火) 00:19:15.25 ID:ZNa428EC

>>591
> Kubernetesが登場してORIとOCIが標準化された時点でdockerは役割終えた感ある

KubernetsってDockerを使うんだけど、なんで役割終えたの?

614: login:Penguin 2018/12/04(火) 07:24:02.44 ID:CnqUMfCF
>>598
KubernetsでDockerは使えるけど必須ではなくなったからな
将来的には使われなくなるでしょ

620: login:Penguin 2018/12/04(火) 16:39:04.08 ID:ZNa428EC

>>614
知ってる知ってる。rktとかいうやつな
あれどうなったんだ?w

結局、Docker以外も使えると言う状況に満足して
終わりなんだよ。本気出してないからDocker以外普及しない

625: login:Penguin 2018/12/04(火) 21:18:35.08 ID:xoni3AYF
>>620
rktは違うわ

597: login:Penguin 2018/12/03(月) 23:52:43.40 ID:fSc1+0qL
なんで個人開発限定?
そもそも個人開発でdockerなんか何に使うの?
コンテナ仮想化って個別にインフラを面倒見れないほどアプリがポコポコ作られるような組織で使うもんだろ
PaaSへのデプロイに使うくらいか?

624: login:Penguin 2018/12/04(火) 19:13:19.70 ID:ZpO6Qfl5
dockerの特色はリソースを節約しつつ環境を切り分けて管理しやすくするってことだから
docker動かすだけの鯖やVMならカーネルだけ乗っててdockerの依存関係だけインスコできるパッケージがあればいいって発想から
ディストリとかvmも小さいものや、専用のものを使いましょうってだけの話だろ。
リソースを気にしなくてすむのなら普通のlinux鯖で動かせばいい。

863: login:Penguin 2018/12/24(月) 11:43:32.49 ID:ZQ/dJl6b
Debianにインスコ開始ー

引用元

Docker Part2

管理人からひと言

便利だけどむつかしいんですよ

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

Docker/Kubernetes実践コンテナ開発入門 [ 山田明憲 ]
価格:3650円(税込、送料無料) (2019/1/22時点)

スポンサーリンク
スポンサーリンク
スポンサーリンク

シェアする

フォローする

スポンサーリンク
スポンサーリンク