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/

>>332
podmanを消してDockerの話題だけをすればいい

>>334
全く意味のない情報になるね。
>>1には「情報共有しましょう」と書いてるのに。
俺はその話に興味があるんだから、お前が勝手に排除するなよ。
dockerとpodmanを比較したい？
話したいなら話せば良いじゃねーか。
比較の一方がDockerならスレチでもない。
お前が興味ないだけなんだろ？じゃあ２、３日PC閉じてろよ。
話し終わってるから。

韓国「日本が〜、日本が〜」
日本「韓国？興味ない」

>>336
まんまお前じゃねーかｗ
お前「Dockerが〜、Dockerが〜」
ほかの皆さん「Docker？コンテナ技術の１つですね。」
ｗｗｗ

ほかの皆さんって誰のことだ？

>>338
podmanの話をしようとした人はそうだろ。
ほかにNautilus の話しようとした人も。

>>333
すいません、理解できる日本語で書き直していただけますか

>>340
何で君は自分の問題が解決した喜ぶべきタイミングで
君の問題と全く関係ない話をしている、他の人を排除しようとするの？
別にスレチって事も無いよな？

mysqlはmysqlのスレに行けよ
関係ない話されっとマジ迷惑

じゃあpodmanは別ツールですから移動してくださいね
迷惑ですよ

>>343
dockerとpodmanの比較の話をしてたはずだが？
俺は続きに興味があるんだが？
何処に優位性があるのか、思わずggちまった。
mysqlへの興味は10年前に終わった。mysqldumpとか初心者かよｗ

dockerはpodmanのエイリアスだぞ
dockerを語るということはpodmanを語るということだ

じゃあDockerだけ語ればいいなｗ

誰もpodmanに興味が内容であっちのスレは落ちそう

podmanは引き続きこっちでやればいい

MacでDockerはむいてないのか

Linux使え
MacもWindowsも一般ユーザー向け

会社だとMacかWindowsが支給されるがLinuxは支給されない
だからMacかWindowsでやったほうがいいのかなと思って

>>351
会社支給品で開発するなら普通はMacでは？
WindowsのDockerはまだこれからと言う気がする。
とはいえMacはARMに移行するから、近い将来買い替えなければならなくなる。
ARM CPUで開発して本番機はx86(Xeon)ってのも色々リスクがあるから会社の方針を変える必要があるかもね。
（本番機もArmのlinux使う検討するとか）

最近のWindowsUpdateの更新でWSLがバグってるらしいけどDockerは普通に動くの？

WSLのバグは大きな問題じゃないから
ほとんど問題なく動いてる

>>354
サンクス

メモリ食いつぶしたり古いカーネルAPIの互換性でクラッシュしたりするけど仕様なんだってな
バグじゃないってよ
WSL2ってそういうとこだよ

メモリは上限を決めれば問題ないだろ
普通の仮想マシンと同じ扱いになる

そして絶賛対応中。今のWindowsはマジで改善しまくってるから
どんどん使いやすくなってる

普通の仮想マシンと同じ扱いならトラブル少ない普通の仮想マシンを使うわ
改善たってもとがアレじゃいつまでかかることやら…
最終的にMicrosoft Linuxまで改善が進んだらようやっと乗り換えを検討してもいいかなってところかな

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

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

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

欠点はある
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付きでしかしない
永続化したいデータはボリュームに出す
基本かどうかは知らん