Docker Part4

Linuxが持つコンテナ技術を使った、仮想マシン必要ないアプリケーション仮想化技術で
アプリケーションのデプロイが用意になります

Docker（アプリ仮想化）は仮想マシンと併用して使うことで最も効果を発揮し
開発・テストで使ったDockerイメージと全く同じものを本番環境で使えます
さらにWindowsとmacOSでも同じDockerイメージが動きます。
（Linuxは仮想マシンが不要ですが、WindowsとmacOSは仮想マシン技術を併用して実現しています。）

Dockerイメージ（Dockerfile）はアプリケーション開発者が作成します
動かすのに必要なもの全てがDockerイメージに含まれるので
インフラ担当者はそれを動かすだけ、本来のインフラの作業に集中できるようになります

Dockerは主にウェブ業界でサービスのデプロイの必須技術になりました
情報共有しましょう

http://www.docker.io/

前スレ
Docker Part3
https://mao.5ch.net/test/read.cgi/linux/1552023620/


注意　同じコンテナ技術を使うが異なるアプローチで仮想マシンの
代替を目指しているのがLXC。目的が全く異なるので注意
LXC(Linux Containers)
https://mao.5ch.net/test/read.cgi/linux/1330826939/

普通の仮想マシンと同じ扱いなんて書いてないよ

メモリの上限は普通の仮想マシンと同じ方法でやれる
それ以外は仮想マシン使うより格段に便利なんだから
仮想マシンに比べてメリットはあれど欠点はないということになる

論理的思考をしましょうね

欠点はある
WSLはデフォルト設定でメモリ食いつぶす
レガシーAPIコールでクラッシュ
コンフィグ用のクールなUIもない
カスタマイズが前提なのにカスタマイズ方法がわかりにくいというクソ仕様

普通の仮想マシンはデフォルトでいい具合にメモリが制限されている
意味不明なクラッシュもしない
コンフィグ用のUIが用意されてる

はい自滅しました（笑）

仮想マシンのメリットは
それだけなんです

そう
だから仮想マシンなんて使わないほうがいいんだ
最初からLinuxを使うだけ
Docker on WSL2 on Windowsってどんだけ無駄なレイヤー積み重ねるつもりだよ

DOCKER JAPAN

>>362
いくらレイヤーを重ねようが、お前が作ってるわけじゃないんだから
どうせ見てないだろｗ

>>362
原理的にはそうなんだろうけどね。
linuxってそもそも効率的な開発できるもんなの？
excelもwinmergeもないOSで効率的な開発できるとは到底思えん。
ファイルマネージャも使いにくいしな。
同僚でlinuxを開発機にしてる人がいるけどミスが多くて、やはり効率的に仕事しているとは思えない。

用途による
としか言えない話ばっかりだね

>>366
ほんとそれ

開発以外の用途にdockerなんか使うのかよ？

使ってますけど何か

>>369
何にｗ？
エアプなら何にでも使えて便利だよなｗｗｗ

>>370
docker-vpn-browserとかあるんですよ
無知晒しちゃったねw

>>371
その程度の用途ならそもそもdockerのホストがlinuxなのかwinなのかmacなのかなんて
どうでもいいじゃんｗ

>>372
>開発以外の用途にdockerなんか使うのかよ？
これの答えなんだがそれすらも理解できなかったかな?

>>373
その上がDockerはWin/MacかLinux化って話だから、
そんな用途ならホストはどうだっていいよ、って話だね。

今の本番環境といえばクラウドだが
クラウドはDocker対応がかなり進んでいて
Dockerイメージを前提とした本番環境を構築するサービスだってある
本番環境でDockerを使うから、開発でもDockerを使う

imageを上げるだけでサイト公開できるwebサービスありませんか？

>>365
エクセルは使いみちないかな
DiffはVSCodeで見てる
作業中にいちいち外部ツール起動するのは非効率的

>>365
Excelもwinmergeも要らない。
同僚がヘタレなだけ

差分比較ツールなんか、ほかにもある。
Meldもいいし、VSCodeのDiffもいい。
Excelなんか、こだわる必要ない。

テレワークだとエクセルが遅すぎるんだよな
画像満載のブックは特にひどい

>>377
Excelは顧客との仕様確認、テスト仕様書用やな。
最も半分以上googleスプレッドシートに移行してるからだんだん存在感なくなってきてるけど。
今時のクラウドエンジニアってマジでWeb上のサービスしか使わないのね。

winmergeはディレクトリ配下全部の比較が出来るのが良いね。
同じことができるのがMacにもLinuxにもなかなか存在しない。
win10嫌いだからあれば移行するんだけど。

>>378
まあフランス人だからな。
ヘタレなのが日本語不便だからなのか本人の性格（面倒くさいことが大嫌い）
なのかLinux使ってるからなのかわからんのが何とも言えんｗ
でも奴の使いっぷりはイマイチだと思ったね。

diff -r でいいやろ

Markdown等 + テーブルエディタ
これでエクセルの出番はほぼ消えるよね

どうやってグラフにするの？

グラフ作るツールもクラウド上に色々ある。

data visualizationならmatplotlibとかでえんちゃう

じゃあ

Markdown等 + テーブルエディタ＋クラウド上にある色々
これでエクセルの出番はほぼ消えるよね

って言わないと駄目だよねｗ

Excelよりviのほうが使いやすい。

ただしExcelを神エクセルとか単なるデータファイルとして使ってる場合
って言わないと駄目だろｗ

エクセルは表計算ソフトであって
計算するために使うものだからな

表計算ならSQLのほうがいいかな

SQLでどうやってグラフかくの？ｗ　

可視化はmatplotlibとか使えばいいんじゃないの
1つの道具でなにもかもやろうとすると何をやっても中途半端で重いツールになる
だから特定の仕事をよりうまくできる軽いツールを組み合わせるのが正解なんだ

>>391
複数の道具を使うことは論点じゃないよ
エクセルと同じことをするならviみたいな単純な機能のものでできるっていうんじゃなくて
Markdown等 + テーブルエディタ＋matplotlib＋クラウド上にある色々
みたいに多数の道具を使うと言わないと駄目でしょって話

SQLもあったなｗ

Markdown等 + テーブルエディタ＋matplotlib＋SQL＋クラウド上にある色々

>>392
多数の道具を使うとうまく行く
1つの道具で全部やろうとすると失敗する
リモコンと箸と金づちを一体化させたようなものが使いやすいと思うか？

>>394
自動車にはエアコンやカーナビが搭載されていますが？
1つに道具に、それを補う機能を搭載させると使いやすくなりますし、
関連する機能を搭載すると、更に便利になります。

重要なのは「関連する機能」ということです。

関連しない機能を搭載しても使いやすくならないという主張は的外れです。

知り合いにLinux縛りでIDEすら使わないVimmer居るけど馬鹿なんじゃないかと思う

>>395
関連しない機能を詰め込んだから使いにくいのですね
なるほど

volumeの内容をオンラインで共有する方法教えて

>>396
そいつは仕事出来る奴なの？
俺の同僚でlinux使ってて効率的に仕事出来てる奴は知らない。
一方でグーグルは正社員にlinux配ってるらしいから(goobuntu/gLinux)
出来る奴は出来るんだろうけど、winの便利ツールに対応するものが見当たらないんだよなぁ。

>>398
volumeのフォルダをsambaか何かで共有すれば良いだけでは？
httpで見たいならdocumentrootにするとか。

>>398
NASマウント

>>396
Vimは極めるとめちゃ速くなるよ
極めるまでが大変だが
まあ凡人には解らんだろうね
おれもわからん

>>397
エクセルは関連する機能を詰め込んでるので使いやすいんですよ
嘘だと思ったら、エクセル使ってる人に
エクセルを使わないでやらせてみればいいと思います。
もちろんエクセル使ってる人の大半はプログラミングできません。

>>402
へえプログラミングできない人のためのツールをプログラマが使ってるんだ

>>403
そりゃ使うだろｗ
電卓だってプログラミングできない人の
ためのツールだがプログラマも使う
それと同じ

いやープログラマは電卓使わんだろ

dockerでexcel.applicationうごかしたいんですが動きませんなぜですか

>>406
エラーはどんなの？

dockerでは、起動するたびに同じ状態になるけど
docker-composeでは、起動するたびに前回の状態を復元している

という認識であってますか？実装そうなってるような感じなので

>>408
ぜんぜん違う。
docker-composeは、docker起動のオプションがたくさんあって
大変だからYAMLに書いておけるようにしましたってだけ
１つのYAMLで複数のdockerを起動することもできる

コンテナのなかにデータ持たせて(DBなど)新規起動と停止してるのを起動で挙動が違うのを観測して後者をそうとらえたのかもしれんね

コンテナって儚い
変更を保持できるのはボリュームをマウントしたディレクトリだけ

コンテナを削除するとボリュームに加えた変更以外は全て無かったことになる

なかったことになるから嬉しいんだよ
本当に永続化したい部分が明確になって管理しやすくなる

>>411
それがプロセスってもんだよ

nginxを起動すると、nginxがメモリに読み込まれ起動する
終了したらそこまで。メモリに読み込まれたプログラムは儚く消える
変更を保存できるのはディスクのみ

これがnginxをラップしたDockerイメージでも同じこと

>>408
そりゃコンテナをdown/upで停止起動するからだろ。
stop/startで起動すればそうはならない。
普通にVMのshutdown→起動と同じように使える。
ほかの連中は何で無かった事になるのが当たり前、的なレスしてるんだ？

stopは滅多に使わない
containerを止めるのはimageを更新したときが最も多い
その次がnodeが故障したとき
どちらにしてもcontainer内のFSは初期化される

>>415
それは単なる君の好みだろ。
docker自身はコンテナを破棄して起動するコマンドと
単に停止起動するだけのコマンドをちゃんと分けて用意している。

好む好まざる管径泣くstopの使用頻度は低い

単に知らなかっただけでしょ。
この点もずっと前からスレの中でDockerは起動停止で中身破棄されるのが当たり前
とか間違った主張繰り返してたし。

stop使うときって具体的にどんなときだ？

414に書いてるのに気付かないとか
どんだけ日本語不自由なの？

>>420
いや、DockerはVMと同じようには使わないから、VMと同じように使える、と言われたって、それは実質使いどころがない、と言ってるのと大差ないんだが

>>421
外国人？日本語勉強しようね。
それ以外にも情報書いてあるでしょ。
それとも先週か先々週、週明けに病院行けとか言われた人？
行ったの？

>>420

> 414に書いてるのに気付かないとか
> どんだけ日本語不自由なの？


>>414

> >>408
> そりゃコンテナをdown/upで停止起動するからだろ。
> stop/startで起動すればそうはならない。
> 普通にVMのshutdown→起動と同じように使える。
> ほかの連中は何で無かった事になるのが当たり前、的なレスしてるんだ？



VMのshutdown→起動にしか言及してないが、それ以外の情報はどこに書いたんだ？
ひょっとして書いたという幻覚でも見たのかな？

>>423
shutdown→起動と同じように使えるよ、と言っているんだが？>>408が
起動するたびに前回と同じ状態に戻ると言うから、それ以外の仕組みも
用意されている、と言う話をしている筈だが？
本題と関係ない日本語の理解をここまで説明しなければ理解できない君の脳味噌ってマジでどうなってるの？
いい加減にしろよ。

> 普通にVMのshutdown→起動と同じように使える。
サービス動かないのに？

>>425
エアプの人達に説明するのって大変だな！
掲示板なんかに粘着してないで、まあ自分でやってみろよｗ！

>>426
知らないのか？
stopってDockerコンテナの中にあるプロセスを全部停止してるんだぞ
そこから再開してもスタートしない

>>427
そこから再開してもスタートしないというのなら、君がそういうイメージを作ったんだろう、
としか言い様が無いな。

>>427
もう一回ENTRYPOINT等で起動されるだけ

stopで止める理由がねえんだよな
コンテナを一時的に止める時は、潔く破棄して、再作成するのが基本
それで済むのにあえてstopを使わなきゃいけない理由があるとしたら
コンテナがイミュータブルかつ、可変部分をボリューム化していない、ということだから、明らかに設計に欠陥がある

>>430
>コンテナを一時的に止める時は、潔く破棄して、再作成するのが基本

これは、どこにそう書いてあったの？
君は何を読んでこれが、「基本」だと理解したの？
URL（若しくは書籍名）示せよ。

書いてあるかないかは関係ないわな
権威主義は思考停止、エンジニアとしての死に等しい
コンテナを止める時はどんなときか？というのを自分の頭で考えればstopなんて要らないなとわかる

個人的にはdocker runは--rm付きでしかしない
永続化したいデータはボリュームに出す
基本かどうかは知らん

>>432
>stopなんて要らないなとわかる

じゃあ、なんでstopと言うコマンドは実装されたのw？

>権威主義は思考停止、エンジニアとしての死に等しい

お前はニートのニセエンジニアだろ？
ここ迄、理解に難有りの人間に給料払い続ける雇用者はそうは居らんわ。

>>434
startの対として脳停止でstopも作っちゃったんだろうな
本来は要らなかったんだけどDocker開発側も作り始めた頃はDockerを深く理解してなかった
今から再設計するならstopは消えるだろうね

>>435
なるほど
「Dockerを実装したDocker社の正社員は間違っている、
　俺の方がDockerの思想を理解している」
と、こう言いたい訳ですねｗ

>>436
俺、というか今の常識、だね

「俺が常識だ！」ｗ

>>437
その常識は何を根拠に形成されたのか？とさっきから聞いているのだが？
君以外の誰のエンジニアの脳内にも、そんな常識とやらは存在し無いんだが。

>>439
しつけーなー君は
そんなにstopの有用性を示したいなら、君がstopの効果的な使い方挙げてみればいいよ
それができないなら、ま、そういうことだ

便利に使うのが正解
自分にとって不便なら作法に従う必要はない
それを強要する権利もない

さあ一体どんな便利なstopの使い方が出てくるのかな楽しみだ
まさかここまで粘着して思いつきませんでした、なんてこたないだろうけど、まさかねぇ〜

>>440
エッ！？うちのチームはほぼ、start/stopしか使わないけど？
down/up使うのはSREチームから新しいImage作ったよ、と通知が来た時位だが？
だから一連の書込みにずっと違和感があるんだが？

Docker原理主義者のお前が勘違いした思想を元に非効率的な開発を一人で進めるのは一向に
構わない、俺達に被害は無いからな。ただ仕事でやってる俺達は開発効率が第一な訳よ？
1つのIssue消化するのにテストユーザー作ったりコンテナの中身を一時的に設定変更することは良くある。
そんな時にPC立ち上げる度にdown/upされたら毎回同じ作業する羽目になるし馬鹿馬鹿しいだろ？
そんな時にstopさせるだけよ。あー今日の作業終わったdocker-compose stop、
さあ今日も仕事始めよう。docker-compose start　するだけの話。
次のIssue始める時に真っ更に戻したいならdown->up、それだけの話だ。

Docker原理主義者のお前が勘違いした思想をレスの間中うざく書き込まれると、まともなこちらの情報
交換の効率が悪くなるから、黙ってろって事だ。
後、知らないのなら謙虚になれよ。

>>443
あーあ、ほら
Dockerの使い方全くわかってねえのな
起動したコンテナを後から変更するなんて完全なバッドプラクティス
イミュータブルインフラストラクチャの意味を全く理解してないじゃないか

>>443
最後の段落
すげえキレイにブーメランになってて笑う

この前入れたバグ修正がアップデートで消えちゃったんですけど、助けてください〜、って泣きついてくる新人並みｗ

>>444
>>441の通りだね。開発中は「便利に使うのが正解」
イミュータブルインフラストラクチャは本番機で実行される時の話。
開発中は関係ない。
・・・もうね、427以降のニートで実務わかってませんっぷりの酷さは何なのｗ？
何度も「何をもってその理解に到達したのか？」と聞いているのに、そこはスルー。

誰かが以前「Docker使ったからと言ってイミュータブルにできるわけじゃないよ」
と言った書き込みも理解できずに、そのまま来たんだろうね。

初心者くんに教えてやるか

バグの調査などで、一時的にユーザーを作りたいならDockerfileの末尾にユーザー追加のコマンドを書く、それだけだ
さあ仕事を始めよう、up --buildハイ起動おしまい
一時的な変更が確定したらDockerfileをコミット

コンテナに入ってコマンドうったら、ソースに残らねえから、変更が確定したあとに自分がどんなコマンドを打ってきたか思い出して、Dockerfileに書き出さなきゃならねーだろ
書き出したDockerfileが正しいか、また動作確認作業やり直しかよ
こんな非効率的なバカバカしい開発フローじゃ、いつまで立っても仕事おわんねえよ

>>448
DockerfileはSREの責務だから触れないよ。

一連のDocker原理主義者のおかしな書き込みを見直して、なんとなくわかったわ。
アプリに対するステートレスなつくり、イミュータブルインフラ、永続化する場所の選定、
ログの一元管理、それらは確かに必要だけど、それは本番機を運用するときの話だ。
本番機じゃコンテナ自体がでデプロイする度に破棄されるし、いくつのreplicaで動くかわからないからね。

それと、開発中の話がゴチャになってるから、話の展開がおかしいんだね。最初に相談する人は
立場がそれぞれなのに、自分が理解したものでしか返せないから、会話がおかしくなっている

開発中は>>441が正義。
開発効率が高ければ、やりたい様にやれば良いし、自分のやり方を他人に強要する権利も無い。
開発者としてアプリを作るときはStatelessに作ること自体は気にかけるけど、そこで動くDockerに気を配ることは無い。
便利で軽いVMとして使いたい？全く問題ないよ。

>>449
やりたいようにやりたいってのは逃げの議論だな
stopを使うような非効率的な開発方法も、僕がそうやりたいんだからしょうがないだろ、開発効率なんて知ったことか、とそういうことだろ

>>450
ん？話の発端は>>408以外にも方法はあるよ、って話をしただけだが？
君の話を俺が非効率だと感じるのはウチのチームでそうしている奴が誰も居ないからだが？
開発機のコンテナだけで10個あるのにDockerfile弄って毎回コンテナの破棄→構築なんて、やってられんわ。
まるきりDocker原理主義的だし。
stopの話自体は、「起動するたびに同じ状態」以外にあるよって例を示したに過ぎない。
多分単に君が知らなかったのであろう、stopコマンドに>>430とか>>440でやたら噛み付いてきたから、
言い方が酷くなったに過ぎない。

>>451
コンテナが何個あろうが、Dockerfileとマニフェストを書いて、適用するだけ
つーか、コンテナ数が増えたら余計に、コンテナに入ってコマンド実行なんて、やってらんねえわ
それぞれのコンテナに、どんなコマンドで、どんな変更を施してきたか、把握すんの大変だろーが
そういうのもうやめよーぜ、ってんで出てきた考え方がIaaCであって、その実装の１つがDockerなんだよ
なあんで、そこまで進歩したのに、昔の非効率的なやり方に退化してんだよ

>>452
いやだから、そういう話をしたんじゃないっていってるでしょｗ。
非効率で退化しているというなら、Docker社にメッセージ入れてコマンド消して貰えよｗ
もしくは君が入社して消してしまえよｗｗｗ

俺にとっちゃどうでも良い話しだし。君以外のすべての掲示板参加者にとってもそうだろうよ。
Aだけのやり方しか知らなかった人にAとBの道がある、現場で効率が高いほうを選べば良いよって話ね。

>>453
効率の悪いstopはやめようねって話ね

>>454
またまたｗ使った事無い癖にｗｗ

使ったことはあるが、使う必要はない

>>449
> DockerfileはSREの責務だから触れないよ。
お前の会社の話なんか知らんがなｗ
Dockerfileだけじゃなくて色んなものに制限があって
開発効率下げてるやろ？お前の会社の問題だ。

伸びすぎｗ

いやーコミュ障のニートって本当、大変だよな。
14：37に俺がコマンドを提示してから、この話題（コンテナの状態、起動、停止）を発展させるような
話題はゼロｗｗｗこの間10時間。B2Bのエンジニア価格なら、五万円いってるよ。

できるエンジニアならその時点で知ってた、知ってないに関わらず
「なるほど、そんなやり方もあるんですね、教えていただいて、ありがとうございます！」
の一言で次に行く話を、顔真っ赤にしてそれは非効率だDockerの原理主義に反する！
と話題を延々と繰り返す。この間わかった事実は、どうやらDocker原理主義者は
開発環境と本番環境をゴチャにして考えているようだ、という事実のみｗ。

・・・誰も雇わんわな、これじゃ・・・