Docker Part6

テンプレとかいらんやろ

>>1
DockerはLinuxが持つコンテナ技術を使ったアプリケーション仮想化技術です。
アプリケーションを動かすために必要な各種ライブラリ等を一つのDockerイメージに
まとめることで、さまざまな環境へのデプロイが容易になります。
例えばWindowsやmacOSを使って開発・テストしたDockerイメージを
そのままクラウド上のLinuxの本番環境で使うことができます。

クラウド上の環境が仮想マシンであるため、Dockerは仮想マシンと併用して使うことが多いですが
仮想マシン技術とは無関係の技術です。実際Linux環境において仮想マシンは必須ではありません。
WindowsとmacOSでは仮想マシンを使いますが、これはOSがLinuxではないからです。

Dockerは主にアプリケーションを動かすために設計されているのでデータを保存するのには適していません。
データはDockerイメージの外部、ボリュームを使ってホスト環境に保存するかネットワーク通信で外部サーバーに保存します。
またDockerコンテナは一つのサービスを実行し、複数のサービスが必要な場合はdocker-composeやk8sなどを使って連携させます。
Dockerを仮想マシンの代替として、コンテナ内で複数のサービスを起動しようとすると困難が待ち受けています。
それはDockerの設計方針とあっていないからです。

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

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

http://www.docker.io/

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

注意　Dockerを仮想マシンの代替として使いたいと考えてる人は、DockerではなくLXCを使いましょう
LXC(Linux Containers)
https://mao.5ch.net/test/read.cgi/linux/1330826939/

>>1-2
乙

docker＆django＆mysqlのハローワールドができない
dockerのdjangoチュートリアルがpostgresでそれは問題ないのにpython固有のmysql接続の問題とかで・・・

じゃあPythonなおせば？

>>5
ども、M1macとdjangoとmysqlの相性が悪かったぽくて、諦めてpostgresにしました。

Ruby on Rails は、開発環境でSQLite。
本番環境では、PostgreSQL, MySQL, AWS Aurora とか

Django のシェアは無いから、おすすめしない

食べチョクみたいな、若い女の子が一人で起業したベンチャーは、Rails

食べチョク開発者ブログ

会社の支給PCがMacBook Pro M1なので、新しく開発環境を構築した話
https://tech.tabechoku.com/entry/2021/01/15/150103

>>7
何だその怪しい日本語は
ヤンキーゴーホームwwwwww

ホストのlinuxカーネルを5.13系にしてみたら、デーモン起動時にSEGV起こして起動しなくなったのですが…(´；ω；｀)
5.12系でブートし直すと、問題ない…(´･ω･｀)
どなたか、同じのでハマってる方いませんか？(´・ω・`)

リコンパイルしてみたら？

>>10
ありがとうございます。
Dockerの方はDebianのパッケージ(sid)を使ってるので…。
カーネルは試しにこちらでビルドしたもので、5.12系をほぼ同じconfigでビルドした場合には問題出てなかったので…。

5.13系カーネル自体の設定をチューニングして再ビルドを重ねてますが、うまく行かない…結果しだいでは、どちらかにバグ報告をしないといけないような状況ですし、色々調べてDocker/Containerdの方もビルドしてみます。

【おちんぽ】伊藤忠テクノソリューション(CTC)ってどうよ？【挿入】
ＩＷＧＰ関東連合　椎木、 03-5210-8100

アクセンチュア 伊藤忠商事
ttps://www.dto.jp/shop/17

ＳＥＸしたいぞ、ＣＴＣ

リーダー宣言　敗訴る 金融事業部

お前を部下にもらう前に　言っておきたいことがある
かなり厳しい話もするが　俺の本音を聞いておけ
俺より先に　来てはいけない
俺より先に　帰ってもいけない
飯は一緒に食え　いつも身だしなみを整えろ
出来る範囲で構わないから

忘れてくれるな、仕事も出来ない俺に
お前を守れるはずなどないってこと
お前にはお前にしかできないこともあるから
それ以外は口出しせず黙って俺についてこい！！！！！！！！

>>11 ですが、
昨日と言うか今日、リリースされた 5.13.3で問題が解消したようなので、ビルドして今実際に動かして挙動見ています。

ChangeLog-5.13.3 のこのあたり関連だと思います。
Author: Xie Yongji <xieyongji _at_ bytedance.com>
Date: Mon May 17 16:49:12 2021 +0800
Summery: drm/virtio: Fix double free on probe failure

>>13
あ、リリースされたのは、Linuxカーネルの方ですm(_ _)m
念のために追記しておきますm(_ _)m

https://www.msn.com/en-us/news/technology/install-the-latest-version-of-the-docker-engine-to-avoid-vulnerabilities/ar-AAMrxcE?ocid=msedgdhp

既存のコンテナにbashやaptをインストールしたいのですが、方法がわかりません。
やり方を教えてもらえないでしょうか。

なんでそれインストールしたいの

>>17
中の設定を変更して動作を試すときに、コンテナ内にはshしか実行出来ないからです。

Debian ベースの Docker ベースで作っていく方が早いんじゃないかな

とにかく実行ということなら、インストールパッケージからファイルを抽出して、docker cpでコピーしたら？

あとの管理は事実上ムリやけど。ｗ

方法が分かりませんというのが分かりませんなｗ。
普通にコンテナ入ってやればいいじゃん。

いやあとからapt入れるのはそういえばやったことないな
ディレクトリ構成によっては手間掛かりそうだ

イメージの提供者がaptやbashまで削ぎ落としてるってことなのかね

最初から入れてないだけじゃね

Docker使う以前の問題じゃないの？

それは言えてる 素直に Debian ベースでコンテナ自分で作った方が早いね

>>25
まあDocker使うようになって初めてパッケージマネージャすらまともに使えない最小限のLinuxに触れた人は多いんじゃないかな
まあDocker関係ないのはその通りだが、コンテナ以外でそんなものを弄る機会はなかなか無いだろう
正直、俺もその一人だし気持ちはわかる

オタクってやたらと「まあ」使うよね
まぁ俺は全然オタクじゃないけど

まぁまぁ落ち着いてくれや

思慮深いオタクは断定を避けるためとりあえずまぁとつぶやくのだ

個人で使うのにdockerのメリットって何？
vmwareとかでいい気がするんだけど

リソース消費量が少ない

2021/4

任意のLinuxディストリビューションをWSL2で動かす　Clear Linux OSを動かすまで
https://impsbl.hatena＠blog.jp/entry/ClearLinuxOnWSL2

注意。アク禁にならないように、URL 内に、＠を入れました

Docker Hub からpull したイメージを、tar へexport して、
それをWSLで、D ドライブへimport する

docker export
wsl --import

WSLでカスタマイズしたものを、さらにexport しておく。
wsl --export

>>31
・軽い
・別PCで作業したい場合に環境の再現が容易
・使い捨て的な使い方ができる

ただしカスタマイズをしたり試行錯誤しながら使いたい場合には VM の方が向いているでしょうね

>>35
それでも、Dockerのが便利な気が。
コンテナに環境を入れきったらええで。

>>36
そうだねそれはそれでアリかと
レシピ書かないでスナップショットで管理するってことだよね

まあ、正確に言えば、VSCode で、Docker Compose を使う。
Linux を、AWS のように画面無し・サーバー用途で使う人は、Docker で十分

Vagrant も、使う必要がなくなった

>>37
スナップショットは再現できないからあんまり。
後から適当に、Dockerfileとかソースとかを更新すればええやん？
古いコンテナも残しとけば比較はできるしな。

>>39
そういうことなのね よっぽどきっちり Docker ファイルに記述していく癖を付けとかないと途中の手順が抜け落ちるな
仕事ならともかく趣味だと

>>40
ま、それができなきゃどうせ再現はできないんやからな。
しゃあない。

まれに油断して、コンテナを先に削除してもうて、あとからガッカリするときもあるが。

コンテナのethインターフェイスのMTUを変更したいです。

systemctlのdockerサービスの設定で、execに指定されてるdockerコマンドに--mtuオプションを付けると、
デフォルトのネットワークに接続するコンテナについてはMTUが変更されました。

デフォルト以外のネットワーク（docker create network -d macvlan　で作成したもの）について、
MTUを変更するにはどうすればよいでしょうか。

docker create networkで指定できるものだと考えていたら、どうもそのようなオプションはないようなのです。
ブリッジする親インターフェイスについて、ip link set mtuでmtuを変更しても、
コンテナはmtu 1500のまま変更されませんでした。

リアルのNICですら滅多にやらない事を何でdockerなんかでやろうとするんだ？

Linux側のブリッジに直接オプション追加する必要があるのかも知れないね
Docker側にオプションが無いなら

>>44
Linuxホスト側の親デバイス（docker network create で指定するやつ）で、
MTUを設定したんですが、同dockerネットワークに属すコンテナのMTUは1500のままでした。

結局、ゲートウェイにおいてmssを設定することによって、
コンテナからのインターネットへの通信はできるようになり事なきを得ました

>>43
経路上に狭いところがあったんです

dockerは便利だけどハマると解決が難しくて困る

>>46
もっとコマンドが便利になればいいなと思う

docker connect network　コマンドで、
ipだけでなく、dnsサーバーも指定できるようにしてほしい

物理のサーバーにVM入れてその上で動くDockerにネットワークの経路だ
DNSの設定だのと、すっげー違和感しかない。
同一ホスト内のコンテナなら共有メモリとかIPCとか別の仕組みで十分だったろうに。

インターネットにアクセスするならどうしてもクライアントからDNSへのアクセスは必要だし、
IPCにTCP使うのはDockerでなくてもわりと普通だぞ

Linuxすら触ったことがない奴がDockerガーとか草

Docker入門ならこのUdemyコースがお勧め
https://www.udemy.com/share/103iSk2@FG1jVEtKTVcLdE5BAHJNfj1HSldh/

だけど、この先生は女の子より男の子が好きっぽいwww
https://twitter.com/NomadSashi/status/1424008388183093256
https://twitter.com/5chan_nel (5ch newer account)

環境の再現性はほしいが
コンテナを使うことによる面倒は避けたいなら
nixがおすすめ

NixOS・Nix Package Manager Part1
https://mao.5ch.net/test/read.cgi/linux/1611657545/

DSLが難しい？それは頑張って覚えろ

Docker は開発環境で使う、Disposable・破棄可能なコンテナ。
状態を持ってはいけない

これを、状態を持っている、システムで使おうとするのが、おかしい。
状態は、Docker外に持たないといけない

つまり、AWS, Kubernetes などを使うべき！

以前から、このスレには、

Docker を勉強していなくて、
Dockerをシステムのように使おうとする香具師がいる

何回も、システムじゃない・状態を持つな(Disposable・破棄可能)と言ってるのに

>>53
また日本語不自由な外国人？
半島に帰れ

Rubyの話はするなと何回も言われてる人の言葉とは思えないな

dockerをステートレスにしろというのはあくまである1つの用途に過ぎない
内部データを永続化させて仮想マシン代わりに使うケースも結構あるしそれが便利ならそうすればいい

そのうちボリュームは禁止とか言い出しそうでこわい

>>53
頑張って実務経験積んでね 応援してるよ

>>58
NFSでネットワークストレージを/homeにマウントすれば
ユーザーについてはステートレスになりそう

NFSは、ファイルロックもできないし、信頼性が高くないし、あんまり使いたくないね。

データベースのデータは、Docker 内にあれば、
コンテナが破棄される時に、同時に破棄される。
これが、Disposable・破棄可能

だから永続化するために、Dockerの外に持つ。
これが、volume/bind

システム構築運用では、設定情報・ロギング・監視も考えないといけない。
つまり、AWS, Kubernetes などの知識が必要

Udemy の山浦清透、8/20

【金額公開】Webサービスの運用費用、実際いくらかかっているか1円単位までお見せします
https://www.youtube.com/watch?v=nRO7pFCdM8E

このAWS のシステム構成図を見てみ

ECS on Fargate, Cloud Front で、
コンテナ内には、Laravel, Nginx の2プロセスしかない

こいついろんなスレにいるけど有用な書き込みが一個もないんだよな

頭が少し固いかもしれんね ケースバイケースで使い方が変わっていくもんだからね
教科書通りに住むなら考える必要がないってことだ

30代後半とみた

>>53
しかしな、たとえボリュームを使わなかったとしても、
コンテナ単独だけでデータは全て維持されているぞ。
ホストマシンを再起動しても問題ない。

もちろん、コンテナを破棄したら当然データは消えるけどな。

Dokarとhyper-yをまぜてそれをバーチャルボックスで動かしてみたい

コンテナ内のデータで、外部とバインドしていないデータの、使い方が難しい。
外部環境との整合性が取れない

どういう用途があるかな？

>>69
コンテナというものを正しく理解できてない証拠だよ
例えばコンテナを使わない場合、mysqlのデータとか/var/lib/mysql（？）に保存するだろ
コンテナを使っても保存する場所は同じなんだよ

mysqlというプログラムをコンテナにしただけ
データの保存先は同じディレクトリ

linuxでpostfixやsambaのサーバーを構築しようとしているのですが、それぞれをDockerコンテナで構築して、
あえてlinuxの環境には直接インストールしないようにするかDockerで動かすか迷っています。

postfixやsambaのような環境を構築するのにDocker環境にするのはやめた方がいい、などデメリットはありますか？

Dockerにすることを悩んでいるのは将来サーバーをリプレイスする時にコンテナを移動するだけで移行完了できるから楽になるのかな、という考えからです。

コンテナ＝アプリ

サーバーをリプレイスするのに必要なのは
アプリだけじゃダメ、アプリとデータを移動しなければいけない

それが簡単にできるのがDocker

セキュリティパッチとかどうすんの？しょっちゅうイメージ更新しなきゃいけないしホストにも当てなきゃいけないぞ
ちょっと設定弄るだけでいちいちイメージ作り直すの？それどうやってテストすんの？
そういう、アプリケーションが頻繁に更新されることはないが塩漬け運用というわけにもいかない性質の用途はDockerとの相性最悪
ぶっちゃけ業務のメールやファイルサーバーなんぞ今時Google WorkspaceかOffice365を契約すればよい
その程度のIT判断ができない組織でコンテナなんか導入したところで管理上の余計なオーバーヘッドになるだけだぞ

>>71
DockerとDockerで、二択になってない気が

>>73
そうですね、こういう用途ではやはりDockerはむいてませんかね。postfixやsamba程度ならサーバーリプレイスの度に環境作り直す方が吉ですかね。

今回ちょうどリプレイスのタイミングで現状の環境を調べるのに苦慮したので(色んな環境や設定がごっちゃごちゃに構築されてて)コンテナにして楽しようと考えたのですが、日常の運用が大変になるのはごもっともですね…

>>73
こいつ偉そう

>>74
はっ！本当ですね、失礼しました。
DockerかDocker以外かの意図でした。

>>73
> セキュリティパッチとかどうすんの？しょっちゅうイメージ更新しなきゃいけないしホストにも当てなきゃいけないぞ
> ちょっと設定弄るだけでいちいちイメージ作り直すの？それどうやってテストすんの？

Docker使わない場合のやり方教えて（大爆笑）

ま、答えられなないよね。
だってDocker使わないほうが大変なんだもの

>>72
必要なデータは永続化するためにvolumeにして、イメージとデータをセットでお引越しするつもりでした。

そこをとらえるとDockerのポータビリティ性は楽だなーと。

直接インストールしたアプリのバージョンアップと
コンテナ内のバージョンアップ…
(例えば)ubuntuのイメージを元に自前のイメージ作成して、
必要に応じてイメージをビルドし直せば最新に出来るし、
運用もそんなに大変じゃないのかな…
あぁ優柔不断…

セキュリティのこと考えると大手に丸投げしたくなるくらい面倒な話だからな

>>75
再現性が問題ならAnsibleとかで構成管理したら？
Dockerで再現性を担保できるのは所詮sambaより上だけで、
君が退職したら結局ホストやDockerデーモンの設定などは闇の中だよ
その上で更にDockerを使う必要があるかどうかはともかく、本当にやるべきことはまずはそっちじゃないなな

>>73
CI/CD を知らない…？このスレレベルひっく！

>>83
こいつ偉そう

よく知らんけどdicjerの内部で動いてるアプリのアップデートってどうしてんの

>>83
そのCI/CDの基盤を誰がメンテするの？
どう考えても目的のサーバのメンテより手間かかるだろ

>>80

だから>>2に書いてあるのが正しい使い方なんだよ
自分たちで作った「アプリケーション」を配布する時に使うの

ディストロがパッケージを用意しているものは、
パッケージのメンテナが頑張って依存関係とか解決してメンテナンスしてる
それは大変な作業。でもメンテナが頑張ってくれたおかげでパッケージは利用者は苦労なく使える

一方自分たちが開発したアプリケーションはメンテナなんていない。
自分達で頑張って依存関係とか解決しなきゃいけない
しかもディストロの標準パッケージとバージョンが違ったりすると
正しく動作しない可能性がある。だからディストロと独立させたくなる

自分たちで作ったアプリケーションの依存関係問題を解決するために使うものであっって
その問題が解決されているパッケージを単に入れて使うだけならほとんど意味がない
確かに設定込みでイメージ作れるかもしれないが、設定ファイルを配布すればいいだけなわけで

Dockerはアプリケーション開発者のための配布手段なので
サーバー構築するだけのインフラ屋の道具じゃない
インフラ屋がやることはアプリケーション開発が作ったDockerイメージをただ起動するだけになる

>>87
クラウドだとホストの構築やメンテは丸投げできるから、
ディストロの既製パッケージを運用するだけでもコンテナを使うことには十分なメリットがあるんだけどね
オンプレだと別の用途で既にkubernetesクラスタがあるとかでない限りは余計なオーバーヘッドでしかない

>>8
それって単に公式のDockerイメージを動かすだけでしょ？
自分でディストロのパッケージをDockerイメージ化するだけだと意味がないという話
誰かが作ってくれてるDockerイメージを動かすだけなら別にいいと思うよ
インフラ屋がやることはアプリケーション開発が作ったDockerイメージをただ起動するだけになる

>>86
構築ｗ
SaaS でもあるし、k8s基盤ならマニフェスト流すだけじゃんｗｗ下請けの缶詰めエンジニアには分からないかもねｗ

ここのスレって下請けがでかい口で言ってるだけでクラウドネイティブなこと全く知らないやつしかおらん

質問者の環境がオンプレっぽいからその前提で話してるだけだろう
SaaS使っていいんだったらそれこそGoogleWorkspaceでも契約すりゃ終わる話

docker以外は何もかも考えたくない
連絡先とクレジット登録してクライアントシークレット貰って認証付きdockerソケットにdockerコマンドでリクエスト送るだけ
そんな感じの超シンプルなクラウドサービスってありませんか？

オンプレだからセキュリティパッチは本番環境にログインして
apt-get upgradeするだけとか思ってそうｗ

本番環境と同じテスト環境用意したとしても
全く同じわけじゃないからアップデートは怖いんだよ

Dockerを使えばイメージ更新するだけですむ
もし何かあればそれを旧バージョンに戻すだけ

ホスト環境にごちゃごちゃアプリ入れないから
ホスト環境がテスト環境と大きく異なることがなくなる
>>73って実際にやったことなさそうｗ

Ruby on Rails では、
食べチョクみたいな若い女の子が一人で起業したベンチャーは、Heroku, CircleCI。
ただし、食べチョクはAWS だけど

Railsでは毎週、数万のRuby/JavaScript のOSS モジュールを更新して、CircleCI でテストする

AWSでは、コンテナ on Fargate を使う。
Kubernetes では、rolling update, blue/green deployment など

例えば、サイボウズ のKintone では、
毎日、k8s でコンテナを破棄して作り直している

Docker導入しようとしたら、間に処理入って重くなるって言われてどういうことか聞いたら・・・

普通のソフトは「カーネル - ソフト」という流れだとしたら、Dockerを入れると「カーネル - Docker - ソフト」という流れになって、重くなったりデータ抜かれたりするから駄目ってことらしいんだけど本当？
こんな仕様だったら流行らないんと思うんだけどなー

間にOS入れたら遅くなるしデータ抜かれるかもだからってOSなくしてスクラッチする？

「docker カーネル アクセス オーバーヘッド」などで検索してみましょう

>>96
どこにそんな事が書いてあったのか聞いてみましょう
答えられなかったりはぐらかしたりしたら
それは嘘ということです。まあ嘘ですｗ

>>96
こんなところで聞いてもしゃあない。
自分の頭で理解して、自分の言葉で説明できないと、相手と議論できないやろ。

しかし、そいつは仮想マシンとかスーパーバイザとか知らんのかね。

>>96
VM のオーバーヘッドがかかるのは Linux 以外ではそうだと思う

>>95
こいつのスレ、ネタかマジか分からなくなる

>>96
よく調べてくれ

スレじゃなくてレスな

そりゃ、Docker サーバーが間に入るのだから、少しは遅くなる。
その代わり、破棄可能(Disposable)・可搬性などの利点が、圧倒的に大きい

Kubernetes もそう。
すべての大企業のウェブサービスが使っている。
これも間に入るけど、それよりも圧倒的に利点が大きい

データを抜かれる事は、あちこちに書かれている。
機密情報をDocker に保存したら、削除しても、各レイヤーに残っているから超危険！

利点があるものは何でも、欠点もある。
例えば速くなるものは、キャッシュなどのメモリ使用量が増える。
速度・リソースは反比例する

欠点もなく、利点だけが増えるものは有り得ないから、
常にどちらかの選択になる

例えば、受験勉強している香具師は、
恋愛・青春時代など、何かを失っている

> データを抜かれる事は、あちこちに書かれている。
> 機密情報をDocker に保存したら、削除しても、各レイヤーに残っているから超危険！

それってソースコードの中に機密情報を保存するのと同じことだろ？
保存しねーよで終わりだろ？

Docker に機密情報を保存しても、
削除したら消えるから大丈夫と勘違いしている、香具師が多い

でも実は削除されずに、各レイヤーに残っているので超危険！

この危険性については、あちこちに書いてある

> Docker に機密情報を保存しても、
> 削除したら消えるから大丈夫と勘違いしている、香具師が多い

それはお前の周りの人間の話
低能の周りには低能があつまる

>>71
うちは、メールシステムはコンテナに詰め込んでいるよ。
Asteriskという電話システムもコンテナに詰め込んで運用している。

ホストを変えるときに、コンテナイメージをコピベするだけで、
環境や設定を移動できるからめちゃくちゃ便利。

設定が複雑で面倒くさいほどコンテナであることは嬉しい。

機密情報の件ってdockerの仕組みも理解せず軽量版仮想マシンみたいな感覚で使うのが原因であって単なる無知なのにdockerに文句付けるのはお門違い

正論ですが意識せずに組み込まれて使っている機能ってありますし

dockerにしろ何にしろ何が機密かなんてこちらが教えないと分かるわけないので意識せず機密情報を勝手に守ってくれることは今後もないだろう
レイヤーに情報が残るのは機密情報でない限りメリットが大きいからそんな仕様なわけだし

システムがよくわからないからDocker使うという層がいるからね
間違ってはいない

DockerからLinux入門した

こわしてもすぐつくりなおせるからね。
合理的。

docker desktop 有料化？

DockerHubといい、プロダクト自体に特に差別化要因はなくて無料であることだけがメリットだったのに、相変わらず勘違いしてるなあ
こんなもんMSとかが本気で開発したら一瞬で代替品作られて終わるのに

個人とか非商用とか小規模の企業なら無料

WSL2からdocker使えば大企業でも無料じゃね？
Macはしらん、virtualboxとかつかえば？

Docker HUB ってちょっと謎なんだけど コンテナダウンロードするのに大量の帯域を食うから有料化したんだよね
そもそもDockerのレシピがあればローカルで再構築可能なのになぜコンテナ丸ごとダウンロードする仕組みになっているの？

パッケージ単位で更新かかってくでしょ

サーバー起動するのと
bashに入ってあれこれするのをやりたいとき
docker-compose1.yml
docker-compose2.yml
みたいにサーバー、とそれ以外で分けて起動させればいいのでしょうか？
新しいウィンドウでターミナル開く、みたいなのがあればいいのに

>>120
パッケージについては各 Linux ディストリビューションのサーバーからダウンロードするからローカルでdockrコンテナリビルドする際にはdockerhub には帯域負荷はかからないと思うのよね

>>119
ストレージはタダなのか？
金がかかるのは帯域だけじゃないやろ。

総量はPBレベルで、うち何割かはずっと使われてないとなれば、有料か未使用削除とするのもやむなし。

> そもそもDockerのレシピがあればローカルで再構築可能なのに

間違い。細かいバージョンが異なってる。
Dockerfileから再構築すると最新版になってしまう

> パッケージについては各 Linux ディストリビューションのサーバーからダウンロードするからローカルでdockrコンテナリビルドする際にはdockerhub には帯域負荷はかからないと思うのよね

いちいちベースイメージからパッケージインストールして構築するよりも
パッケージインストール済みのイメージをダウンロードするほうが速い

>>118
小規模でも年間売上が一千万ドルあれば有償な
例えばAWSやGoogleやMSが自社クラウドの顧客に対してアプリのコンテナ化を提案するとき、別途Dockerを有償契約してくださいと言わなきゃいけなくなるのは致命的だ
Docker CLIまで捨てるかは別としても、業界全体として何らかの乗り換えムーブメントが起きるのは不可避だよ

>>122
それだとdocker build時の最新バージョンが入っちゃうでしょ（あえて固定してない限り）
それで大抵は動くけど、イメージ提供者なら自身が検証済のものを公開したいんじゃないの

俺自身はイメージでバックアップせずいつもDockerfileから再構築してるけど、バージョン変わって設定ファイルの仕様が変わって動かないこともあるよ

真面目にやるならウェブUIの管理ツールを作る(adminerやphpmyadminの自作アプリ版みたいな感じ)
雑に運用するならコマンドラインツール作ってMakefileでラッピングするんでいいと思う
composeでイメージと環境変数を定義、Makefileでコマンドを定義

.env
docker-compose.yml
docker-compose.tasks.yml
Makefile

up:
　@docker-compose -f docker-compose.yml up -d

backup:
　@docker-compose -f docker-compose.yml -f docker-compose.tasks.yml run --rm -it myappadmintools backup --param1 foo

あすまん
>>121へのレスね

>>127,128
なるほどーMakefileですか
さっそくやってみます
ありがとうございました

>>126
そうかベースによっては最新版のバイナリしかインストールできないものがあるのか

有料化と聞いて焦ったけどLinuxで開発する分には問題なしでいいのかな
うちは小さい企業だけど教育とOSSにしか使えないんじゃDesktop使えないね

Docker DesktopとDocker Engineの区別もつかない男の人って…

>>118
>>131

WSL2上にインストールしたLinuxでDocker使うならDesktopなしでもいける

macもVagrantでVirtualbox仮想マシンとかで行けるのはいけそうだが面倒そう
あとはmultipassでUbuntu入れるとか？

この方法だとホスト側はdockerコマンド使えないし
ファイル共有の速度がDesktopと比べてどうなるのか不明
遅くなるかね

面倒だからLinuxでいいよ
WindowsはVSCodeとSSHだけ動けばいい

Docker社の凋落が止まらない
これからもマネタイズ策を打つ度に回避・移行されて、Docker社の影響力は低下していくんだろう
今やクラウドではコンテナ実行環境としてほとんどdockerは使われなくなっていて、もはや開発ツールとしての価値しかない
その開発ツールも、本気で代替品へ移行しようと思えばすぐにできるけど無料だからまあいいか、程度のものに過ぎない
売れるうちに大手に売っときゃよかったのにね

まあ、だから俺は言ったよね？
podmanの時代がすぐ来るってさ

コンテナさえあれば何も問題ない

>>136
podmanの時代が来てから言ってくれ
もう5年ぐらい遅れてるだろ？ｗ

>>127
makefile って使ったことなかったけどこういうバッチのメニューみたいな使い方ができるのか
使ってみるわ

>>139
むしろ今の使い方の大半はそれだよｗ
正しいMakefileの使い方を今もしてるのはC言語アプリぐらいなもんだよ

最近のmakeは.PHONYをデフォルトにしてほしいぐらいだよな

docker-comopse -f 【ymlファイル】 exec 【サービス名】 【コマンド】
ってやると
Error: No container found for 【サービス名_1】
ってエラーがでるんだけど
そりゃ【サービス名_1】って名前じゃないもん
【サービス名】だもんってとこで沼にハマりました
なぜか_1を付けられてそんなもん無いって言われるので
じゃあサービス名をサービス名_1に変えてやってみると
サービス名_1_1はありませんって言われます・・

docker container exec

大企業で働く予定ないからdockerでいいや

予定？

大企業でなくても年間売上10億いかないのはゴミやろ
個人かよぼどの零細だろうな

普通まともな企業ならKubernetes使うからそもそも企業でネイティブなDocker使う方が稀でしょ

ローカルでのアプリ開発時にKubernetes使うわけ無いやん
使い方わかってないのか

新しいものがいいと思っているだけじゃないか？
日本は大企業ほど枯れた技術を使う

Kubernetes使ってる所はまとも会社なんだい！
と言いたいんだろう？

新興企業だと流行り技術使ってますって言わないと美味しい仕事取れない時代だからな

k8sもdockerもそれほど最新技術というほどのものではない

docker-composeで動かすコンテナが自分自身のひとつしかない時でも、networks: hoge-netwok のように、
docker networkを作るのにはどんな意味あるのでしょうか？
こういうdocker-compose.ymlがちょくちょく出てきて
メリットがわかりませんのでどなたかレクチャーお願いします！

他のymlで管理されてたり
そもconpose管理下にないコンテナとネットワークを分離できる

分離したくなけりゃ合わせればいいだけだし

本番環境では、ウェブサービス系のほとんどの会社が、Kubernetes じゃないの？

Docker をダウンロードしたら、k8s も付いてるし

コンテナが1つでも、docker-compose を使うのが基本

その設定ファイルの方が、皆が慣れているから

>>155
Kubernetesはクラウドサービスが提供する一つの機能に過ぎない

クラウドサービスがあるのにその上でKubernetesを動かすメリットがない
クラウドサービスを使えばKubernetesを使わなくてもなんでもできる

>>156
慣れているからじゃなくて
オプションを長く書くのが面倒なだけ

docker-composeはdockerのオプション定義ファイル

ペン4の古いパソコンでもドッカー動きますか？？

うーん、どぅかなー？

どうせ本番はk8sなんだから実行環境はminikube
レポジトリはMSマネーで代替つくれば完全脱却

>>155
最後の一文で分かる無能感

>>157
クラウドサービス毎の機能でk8sを代替しようとすると別クラウドに移行したい時に面倒なので余程のメリットがない限りk8sで済ませる

>>163
言うほどか？
全部コンテナで自前運用やるならともかく、クラウドならk8sといえどもDBやメッセージキューやLBはマネージドサービス使うだろ
アプリだけならk8sだろうとECSとかだろうと大差ないわ

うちAWS EKSだけどそのうちやめてECSにするわ
Kubernetesの実運用経験積むのが目的だったようだが
現状の使い方だとデメリット多いって判断

>>163
色々Kubernetesでしか使えないものに依存してない限りそうでもないし
そもそもクラウド移行自体がレア

ステートフルに弱いって時点でk8sべったり依存はありえんしなぁ

k8sが特別ステートフルに弱いというわけではないけど、
コンテナでDBのような永続的な状態を持つサービスを扱おうとするとどうしてもホストに強く依存するから、あえてk8s内で扱うメリットはほとんどないんだよね
運用の面倒臭さと天秤にかけるとマネージドになっちゃう

それを弱いと言うのでは

Kubernetesは何もしないでメリットが得られるんじゃなくて

1. 各サーバーで1GBぐらいメモリを持っていかれる
2. 最低3台サーバーがいる
3. 半強制的で定期的なアップデートが必要で数ヶ月おきにサーバーの再起動が必要
4. サーバーがデータを持っている場合、データが消えないようにする必要がある
5. データベースクラスタを組んでる場合、少なくとも1台落ちる前提で最初からちゃんと設定してないといけない

こんな感じの面倒くささがあるよね

Kubernetesは1台単位で厳密に管理しようと思ったらダメなんだわ
100台ぐらい揃えてもっと大雑把に全体の95%が正常に稼働中
みたいに考えるものだと思ってる

サイボウズのkintone は、Kubernetes で毎日、コンテナを作り直しているとか

CSIによってステートフルが弱いってのは昔の話や
DBだって operator あるし

vittesとかあるよな 最近話し聞かないけど

苦手なことを無理してやらんでいい
コンテナは素直にステートレスなアプリだけ動かしてろ

k8sはころころ仕様変えすぎじゃね？
アップデート追随するのが大変だわ

>>171
ステートフルなサービスのノード依存性を制約として適切に記述、適用する方法があるってだけだ
別にそれによって生VMと比較して運用が楽になるわけではない
敢えてマネージドサービスを捨てて自前で運用する労力に見合うだけのメリットはない

ステートレスはk8sで、ステートフルはマネージドでって棲み分けができてくると
今度はステートレスはFaaSでいいじゃん…ってなるんだよな
間違いなくk8sは将来的に負の遺産になる
しかも莫大な額の借金

インフラ界隈が謎のk8s推しで開発はコンテナベースしか認めんってこと？
ないようなあるような話で笑えんけど
サーバレス勢のプレゼン力にかかってるんじゃないかな

イメージ自体は汎用だしロックインされてる気はせんよね

クラウドの上にクラウドを作ってるのがk8s

もともとクラウドでいろんなサービスを提供していて
それが便利だったのに、その上にクラウドを作り出してる
意味がわからない

自分がk8sを理解できていないだけなのにまるでk8s自体が無意味みたいな言い回しはやめよう

k8sでFaaSより管理楽になる？コスパ超えれる？

k8sは単なるオーケストレーションツールとして使う分にはいいんだけど、アプリがk8sに依存し始めると最悪だね
AWSやGCSへのロックインなんかより遥かに酷いロックイン状態になるしクラスタのアップグレードが恐怖

大企業なら料金払えるし
零細企業なら無料で使えるんだから
お前らが無理して乗り換えする必要はないんだよ

AWS Lambda, Aurora, Elastic Beanstalk, Fargate あたりで作れれば、ベストだけど

>>179
理解できてるというのなら、
お前がそれを証明すればいいんやで

>>181
オーケストレーションツールを要らなくしたのがDockerだと思うけどね
普通に仮想マシンとDocker起動すれば、それで環境の構築完了だし

>>181
> クラスタのアップグレードが恐怖

それな。Kubernetesでミスったら
クラスタ全部が壊れてしまう可能性がある
最悪の場合だとデータ損失

>>175
？
マネージドあるならそっちでいいよ

k8sが今後の負債になるのは間違いない
でもコンテナ化してんだったら逃げ場はたくさんある

そもそもk8sじゃないといけない理由ってほとんどないよな
k8s使ってるプロジェクトの7,8割はk8sじゃなくてもいい

まあ正直なところ「使ってみたかった」が最大の理由

あとは対外アピール k8s使ってるアピールすると新卒採用に有利だよ

>>188
負債になるのは、コンテナ以外の部分
k8sはコンテナ以外が多すぎるんだよ

k8sの一番の問題は、システムを安定させられるか何だよな
適当にやっても安定するのかもしれないが、自信を持って安定していると言うのが難しい

強制的に再起動させられるシステムで、果たしてシステムを
停止せずに動かし続けれられるのだろうか？

>>190
確かに勉強してるな新しい技術吸収に貪欲だなと好ましく感じるわね
ただし最近は本当新しいツールを軽く表面なでるだけの使い方して次々乗り換え使えてる気になってる人も多いという印象があるわ

ただのミーハーかどうか判断することが大事だと感じる昨今です

ライセンス料につられてdockerを捨てる提案しているゴミが早速職場に現れたわ
うちは大企業でもないから払う必要ないし

Linux使えばいいのに

>>193
それもあるけどどっちかというと会社がk8s使ってるアピールすると新卒が寄ってくるんだよ ソースはワイ

>>194
金よりもDocker社の先行きがなあ
大手に売り飛ばすならまだしも、先のDockerHubの件といい明らかに事業成長に対するネガティブインパクトを顧みない方法で資金を回収しようとしてる
ビジネスとして完全に詰んでる

とれるところからとろうとしとるだけや。
Microsoftみたいなことは、ふつうはできん。

負担しないんなら、フリーライダーと言われてもしゃあない。

Ruby/Go の神、Vagrant, Terraform, の作者、
今世紀最大の学生起業家、HashiCorp のMitchell Hashimoto

彼は、OSS を続けるためには、大企業だけが払うモデルが良いと考えた。
一方、中小企業・個人などは、無料で使えるのが望ましい

つまり、担税力に応じての支払い義務

これが支持されて、会社の時価総額は、5千億円とも言われている

dukerはAndroidでも可能ですか？

>>200
Androidで何をするんですか？
あれは組み込み機器と同じ扱いで
ログインして使うようにはできていません。

Docker社を
MicrosoftとかAmazonあたりが買収して
無償化継続してくれんかなぁ。

大手企業に勤務してないのに木にするなよ

docker toolboxに乗り換えたわ

Desktop使えないとなるならどうせ仮想マシンいれるしかないんやし
だったらtoolboxでええわな

>>203
大手でなくても普通に有償だからな？
まさか売上高10億いかないカス企業なのか

バレへんバレへん

儲かっている企業ならたいしたライセンス料じゃないし嫌ならDesktopを使わなければいいだけだろ

dockerって不思議な会社ね。曲がりなりにもデスクトップの分野で大成功して
超大規模なシステム運用以外のプロジェクトではみんなk8s運用嫌がっていて
10台程度のサーバーで運用する本番環境に市場があることが分かりきっているのに
それで成功できないって、なんで？って思うけどね。
いつまで経ってもソリューション提供できないからfaasだかfargateだかベンダー独自の実装に流れちゃうとかｗ

みんなが金を払わんからや！
VMならタダが相場やしな。

いやいやVMもタダじゃないだろ。タダなのは動かす部分だけで、ちょっとバックアップでも取ろうとすると
便利に使うにはライセンス買うしかない。個人事業でも７万のやつ買ってるよ。
Dockerも似たようなソリューションなんだから似たようなビジネスやればいいんだよ。
でコンテナだから上で色々言っている様にステートフル／レスで色々迷うことあるからソリューション部隊立ち上げて
法人サポートしますよとかね。開発の本尊なんだし。素人が考えても色々金儲けのネタ思いつきそうなものだ。

いいね
docker社に転職して救けてあげたら

macはlimaってやつに変えたらいいの？

完全に脱dockerするならpodmanかな
limaはジャップ製なので完全スルーが正解

だから俺はずっと言ってただろ
Podmanの時代がすぐ来るってさ

多分10年後もずっと言ってると思うよ

>>211
Docker Enterpriseってのがあったけど、金策に失敗して法人向けのKubernetesベンダーに売り飛ばされて消えた

>>213-215
茶番劇？

ビジネスで使うとなるとdocker単体で使うことはあまりなくエコシステムも含めて考える必要があるので自分だけが代替ツールに乗り換えても無意味
エコシステムに影響力のない人にとっては世の中の流れに身を任せるしかない

そうか？
そもそもビジネスならdockerなんて手元の開発環境でしか使わないんだから自分だけ代替ツールに乗り換えても何の問題もないぞ

プログラマーとインフラとそれぞれ担当者がいらっしゃるのでね
プログラマーは使いやすい物を使えばいいと思うんですよね VM でも良いわけですし

Podman 2 〜Dr. ワイリーの謎〜

>>221
VMはDockerの変わりにはならんのですよ

>>223
誰かVMがdockerの代わりになるって言ったか？

>>221が言ってる

コンテナ的な運用をvmですれば良いと思うよ
スナップショットも構築ツールもあるのだから
私はそれはvmではしないけどそれはコンテナに慣れているしコンテナのメリットを享受したいからであり

プログラマが開発するのにはどちらでも良くない?

なら作ったVMをクラウドの仮想マシンで動かす方法でも教えてくれ

VMのスナップは構築試験してる時便利よな、ドライバのバージョン違いによる相性テストとかその節はお世話になりました。

>>228を見てもわかるように使い方が全く違う

>>227
qemu
lxdでも最近扱えるようになった

237は言ってることは正しいけど知識量が足りんかったな

>>230
仮想マシンは性能下がるって知らないの？

ただでさえクラウドは仮想マシン使ってるのに
その仮想マシンの上でqemuを動かすとさらに遅いし
ローカルもqemuで作業しなきゃならないじゃん

>>232
オーバヘッドいってもベアメタル比較で9割以上の性能出るよ
最近の技術はすごいね 頭の中の知識アップデートしてったほうがいいよ！

そもそもクラウドは仮想マシンって前提でおかしいわ
勉強してからレスしろ

>>232
あごめん 読んでもらえば分かると思うけどプログラマー向け環境のことね開発環境ね

それでもサーバー側がリソース潤沢なら VM でもなんでもいいんじゃないのかなと思うよ
それこそプロジェクトによって予算は違うんだからね
以前は VM で動かしていたわけですし今でもそういうプロジェクトは存在するでしょう

>>233
それはKVMを使った場合の話
クラウドでKVMは使えないので遅い

どこをソースとしたかちゃんと書こうな

QEMU is very slow
https://forums.gentoo.org/viewtopic-t-1077552-start-0.html

Why VM QEMU is very slow ?
https://superuser.com/questions/1471510/why-vm-qemu-is-very-slow-still-a-newbie-here

>>235
サーバーがリソース贅沢って何いってんだ？
クラウドのことを何もわかってないな

クラウドというのは必要なリソースを必要な時に確保する
リソース＝コストだ。VMを使ったらその分多くのリソース＝コストが必要になる

サーバーだからって贅沢なリソースということにはならない
それはオンプレミスの世界の話
クラウドでは適切なリソースを使う

>>225
言ってないｗ

>>237
まあ多分同じ認識を持っているんだと思うよ
私もコンテナを利用するし

いくらでも財力があれば富豪的プログラミング的な事が出来るって事だよ
実際はないから多くのケースではコンテナを使うでしょう

で何の話からこんな風になったかって言うとDockerつかなきゃいけないのコンテナ使わなきゃいけないの開発者が？という話があって 別に VM でもいいんじゃないそれはて感じの流れだったんじゃないかな

コンテナはLinux上でVMがいらないんだよ
ネイティブに動く

>>236
視野が狭すぎるよ… よくもまあそんな自信満々に言えるよな
下請け客先常駐の人間か？

同情するわ

>>240
> ネイティブに動く
VMかてふつうは「ネイティブ」に動いとる。

>>249
動いてないよ。VMは仮想マシンの中のカーネル経由で動いてる
ホストOSのカーネルを使ってない。
カーネルを二重に使うことになるのがVM

>>244
それは「ネイティブ」に関係ない。
システムコールとかがラップされとるだけ。

>>245
システムコールがラップされてるから遅い
どちらにしろ遅いってちゃんと言うようｗ

qemuのゲストエージェントのインストールが大変というのを付け加えておこう

このスレには素の状態からオンプレにVMを建てて使う可哀想な人と、それ以外が居るから話がごちゃまぜになるね！

オンプレでもLinuxインストール＋DockerサーバーインストールでDockerコンテナが動く

仮想マシンだと何をするんだろうか
サーバーにqemuをインストールするところまでは変わらないが
ネットワークの設定は？ゲストエージェントはどうするのか？
メモリの調整などは？手元で作ったVMをサーバーでそのまま動かすには大変な作業が必要

その辺は自動化ツールがありますしおすし

Windows のコンテナはないんだから Windows のインフラを作りたいときには VM になるんじゃないですか選択肢が

その自動化ツールの名前が言えない時点で嘘

>>250
何度言っても理解できないようだから何度も言うしかないが
Dockerはインフラを作るものじゃない
アプリケーションをデプロイするものだ

あとWindowsのコンテナもあるし
無知も大概にしろ

>>252
コンテナがインフラそのものではないことは確かです
水道管はインフラですが水道管の中を流れる水はインフラではない あなたはそういうことが言いたいのではないでしょうか

Windows のコンテナについて無知ですみません これは VM を介在しないものなんでしょうか？

>>253
Dockerはアプリケーションを配布するもの
理解したか？ YES NO で答えよ

>>254
イエス

Windows のコンテナについて Vm を介在しないかはわからかいですか？

DockerスレなのにVMで戦ってるのなんなん？

データサイエンス分野だとライブラリ等を一式整えた軽量版仮想マシンみたいな感じで使うことも多い
デプロイ用途というのは単によく使われる一つの用途に過ぎない
別の使い方をしたければ好きに使えばいいだけのこと

こわく

ミス すまん

真っ赤なVMおじさんは下請けだからトイレに行かないと5chできない

かわいそうに

平日の真昼間から連投してる連中が何を偉そうに…ｗ
こういう連中の会話って、話のレベルがガタッと落ちるよな。

＞Dockerはアプリケーションを配布するもの
＞理解したか？ YES NO で答えよ

(笑)

また、いつもの、仮想OS とコンテナの違いが分からない、香具師が来ているのか

下の動画の4分ぐらいの所を見てみろ

AWS のECS on Fargate コンテナ内には、2つのアプリしか無いだろ。
永続化するようなOS の機能は、コンテナ外にあるだろ

山浦清透、8/20

【金額公開】Webサービスの運用費用、実際いくらかかっているか1円単位までお見せします
www.youtube.com/watch?v=nRO7pFCdM8E

AWS Solution Architect の資格を勉強しろ。
米国年収では、ついにRuby on Rails を越えて、1,400万円となった！

「こういうDockerの使い方をすると便利ですよ」というだけのことなのに「Dockerはこのように使わなければならない」と履き違えているのはわざとなのかな

単なるコンテナ型の仮想化技術であってそれ以上でもそれ以下でもないのに勝手にデプロイ専用ツール扱いされてもね

>>265
「DockerはVMと同じような使い方をして、VMと比べなければいけない」
と履き違えてるよねｗ

VMと比べてなんかいないんですよ

>>266
Dockerはデプロイ専用じゃなくて
デプロイ機能が強化されたツール

だから単なる仮想マシン技術では、デプロイには適していない
という話をしてるんだよ

Dockerがアプリのデプロイに適しているところはたくさんある
VMの構築なんか数ヶ月に一回やればいい程度だろうが
アプリだと一日に何回もやらないといけない
アプリ更新のたびにイメージの更新の必要がある

そういった超強力なツールが、VMとしても使えるからと言って
Dockerの一部でしかないVMだけの範囲で比較するのはフェアではない

CLIツールの配布手段としても使えるだろ
どんなディストリでもdocker runだけで手軽に使えて便利

>>2は勝手にWebアプリ限定にしてておかしい

>>262
その時間に退勤？かわいそうに

社内向けのちょっとした本番環境作るのにもDocker便利だから別に開発とか社外向けの本番サイトとか規模の差でしかないと思うけど…

>>270
これ嫌い
コマンドラインはシングルバイナリで頼むわ

dockerで個々につくったのが10個、20個同時に組み合わせて使うとか、普通の家庭用PCで大丈夫なの？

家庭用PCてなんや？ｗ
性能にこだわらなきゃなんでもええやないか。
用途次第。

>>274
Dockerは個々に作ったアプリを包むだけのラッパー

普通の家庭用PCで10個、20個のアプリを
お前は組み合わせて使ってるんだろ？
なら動くに決まってるだろ

仮想マシンじゃねーんだからさぁ
仮想化されたハードウェアをいくつも変換かまして
二重にカーネル経由してなんて無駄なことしてないの

Dockerはネイティブに動いてる

家庭用 PC って書いてあるから開発用途なんじゃね
Windows Mac の場合はネイティブに動作しないで乾癬仮想化かませてるんだよね？

いや、ネイティブ。
仮想マシンがあってもネイティブはネイティブ。

非ネイティブで実用的な速度になるわけないやろ。

え
mac → virtualbox → linux → docker
ちゃうの

オーバーヘッドは出てるんちゃう？cuiだから感じにくいだけで

オーバーヘッドとネイティブは関係ない。
別の話。

ネイティブの対義語って何なの？

仮想マシンで動作させる Windows をネイティブに動作する Windows と言いたいのかな

対するのは Windowsのシステムコールを再現しようとするwineなどのエミュレートソフトウェアかね

後述が非ネイティブだとすれば現実的な動作速度とは関係なくね？
>>278

>>279
仮想マシンだとアプリごとにOSイメージが必要となり
仮想マシンの起動が必要になり仮想マシンの数だけメモリが必要になる

DockerはLinuxだと、仮想マシンが0個
WindowsとmacOSだと、たった1個だけで
10個、20個のアプリを動かすことができる
もちろんそれぞれのアプリは隔離されている

>>281
エミュレーション？
でも、そんな簡単でもないなあ。

>>282
そういう環境としてのエミュレーションは、システムコールやAPIの差し替えとかラップとかフックとかやろ。
それだけなら、バイナリの動作自体はネイティブといえる。

何が言いたいかというと、こういう文脈でネイティブ云々は意味がないのでは、と。
オーバーヘッドの重さは、エミュレーションレイヤーのつくりによる。

>>283
その通りや
君の言うネイティブというのはLinuxの透過ファイルシステムと隔離機能を利用するという意味なのだね
それが例え仮想マシンの上で動作していても

>>285
Linuxだと仮想マシン上で動作してないから
ネイティブだって言ってんだろ
頭悪いのか？

>>286
上で仮想マシンがあってもネイティブはネイティブって書いとるの何やねん

勝手な「ネイティブ」

リンドウズでも動かせたら買うのになぁ

>>274
Windows 10, WSL2, Linux, Docker では、8GB メモリじゃキツイ。
最低16GBで、32GBが推奨

例えば、Ruby on Rails なら、

Windows側で、VSCode とブラウザでテストする。
Linux側で、Rails, Node.js、データベース

コンテナが10個とかなら、自動的にコンテナ数を増減する、Kubernetes(k8s)。
Dockerに付いてる

今は、ほとんどの企業がk8s

>>290
日本語でおk

>>290
ユーチューブで勉強した人？
それともしょうもないスクール生？

>>287
Linuxの上で仮想マシンを動かしてるわけじゃないという意味だよ
知らんの？DockerはLinuxの上で直接プログラムが動いている。

・Linux←仮想マシン←Linux←プログラム
プログラムはネイティブで動いていない

・Linux←プログラム
プログラムはネイティブで動いている

>>293
それは当然の認識で前提だった

そこから話が派生して他 OS の話になっていたのだよ流れをもう一度読んでもらえば分かると思うけど

コイツラ何で「コンテナは高機能なchroot」で済む話をダラダラくっちゃべってんの？

ぜんぜんちゃうからや。ｗ
あたりまえやけど。ｗ

chrootもDockerコンテナもOSのプロセス制御の拡張に乗っかってるだけ
活用具合がだんちだけど

chrootって分離してくれるのファイルシステムだけじゃね
イメージレジストリとかボリュームマウントとかの概念もないし

dockerはプロセス・ネットワーク分離とCPU・メモリのリソース制限も出来る

停止しない限り、マシンを再起動したらコンテナも再度立ち上がるプロセス管理機能もある

chrootとcgroupsだな

>>299
リソースの分離はDockerというかcgroupsとかnamespaceに依存した機能
Dockerだから出来るというわけじゃない

え、そこから教えなきゃいけないレヴェルなんか
ツイッタでイキイキしてる奴らの方が上じゃんｗ

最近はマイクロVMによって、仮想マシンとコンテナの境界は曖昧になりつつある
コンテナは分離技術としては不完全で、セキュリティ観点では全く当てにならない
だからVM立ち上げてその中でコンテナを動かすの

またそれか


アプリをデプロイするためにコンテナ作ったでー

分離技術は不完全、セキュリティでは〜

だから、アプリをデプロイするためのものだって言ってんだろ


仮想マシンの代わりとして使おうとしたり
セキュリティのために使おうとしたり
最初っからそんなもののために作ってねーよヴァーカ

>>303
そんなケースバイケースな話されても
セキュリティ要件上オンプレ且つVM不可な案件もあるんだよ
了見の狭い

シングルバイナリのがいいよね

>>306
RubyやPythonをシングルバイナリにできるならね

でも、まあ、仮想マシンみたいに、コンテナという単位で取り扱うことができるから、
内部動作はホストでネイティブで動作しているにせよ、便利だからそれでいい。

まだDスレでVMの話してんのか・・・

Dockerコンテナはそのままで内容を改変する度に、新しくイメージ化（コミット）しています。

縦がコンテナで同じものです。

□→◯イメージ１
↓
コンテナの内容変更
↓
□→◯イメージ２
↓
変更
↓
□

このようにするとき、変更の度合いに比べて、
イメージサイズが大きくなりすぎるのはなぜなのでしょうか。
簡単にサイズを最適化する方法はあるのでしょうか。

何をどう変更したのか書かれてませんが

docker commitは現在のイメージの上に現在のコンテナによる変更内容を差分としてレイヤを追加する
だからcommitするたびにイメージサイズは肥大化する
これ言うとまた荒れそうだけど、dockerを仮想マシンのように使ってはいけないと言われる大きな理由の一つだね

更新の都度buildで構築できるように組むのが一般的
もし動的な更新部分を外部のリポジトリ等から取得できないなら
マルチステージで旧イメージからコピーするとか

>>312
レスありがとうございます。

おっしゃっているのは、コンテナからイメージを作成して、
そのイメージから別のコンテナを作成し、また新たにイメージを作成する場合ですよね。
（ちがっていたらすみません）

□→◯→□→◯・・・


しかし、>>310のように、
同一コンテナから時系列でイメージを作成しているのですが、
コンテナの変更の割に、それらのイメージが大きく膨らむのです。

同一コンテナ上での変更だから、同一レイヤで更新が成されるはずです。
そうやってレイヤの更新の都度、そこからイメージをコミットしても、
無駄に大きくはならないだろうとにらんだのですが。

>>313
buidができるように設定を組めたらよいのですが、まだそこまでシステムが固まっていないんです。

>>314
あのな。お前のそのレスの内容から
Dockerの完全な初心者だってことバレバレなの

お前は知らない単語を聞いた時、その単語の意味から
こういうことだろ？と思い込んで突き進んでるだろ
思い込みを書き込むんじゃなくて
知らない単語をちゃんと調べてDockerを勉強しろ

システムが固まってないんじゃない
お前は>>313が言ってることがわからないだけだ

あーあー確信ついちゃった・・・発狂するぞｗ

○核心

>>317
おい馬鹿ヤメロｗ

>>318
ではではタメ口ならいい？

>>314
コンテナの変更って何したんだ？
commitでイメージに追加される新たなレイヤは元のイメージとの差分だから、
愚かにもdockerを仮想マシンのように使っているならログのローテーションやパッケージの更新などで常に元のイメージとの乖離は拡大し続け、
その乖離の分だけレイヤのサイズは増大する
事実を疑う愚かな悪癖を捨て、まずはそれだけの差分が実際に生じている事実を認め、その差分の内容をdocker diffなどで調べろ

まだシステムが固まってないんなら別に肥大化してていいんでは
fixしたらホスト側からCOPYしてbuildしたらいいだけ

>>310
> Dockerコンテナはそのままで内容を改変する度に、新しくイメージ化（コミット）しています。

そんな使い方はしてはいけません

作るのはイメージだけで、コンテナからイメージ作るとかしないんだわ
してはいけないって言っておこうか？
最終手段として用意してあるだけでdocker commitなんて全く使わない
それが必須な時点で使い方が間違っている

requirements.txtで独自ライブラリをgithubからインストールして
あとからライブラリ更新したとき
その更新は適用されない
適用させるにはまたゼロから（imageから）構築し直さなきゃいけない
って認識でいいでしょうか？

補足
＞requirements.txtで独自ライブラリ
Dockerfileからpip install requirement.txtです

Dockerは更新されたとか関知しないのでrebuild要

そういうときは更新検知用コンテナ入れるけどな

>>324
だからDockerfileでイメージのビルドが簡単にできるようになっていて
レイヤーのキャッシュで高速にリビルドが完了するようになってる

イメージは消してビルドし直すのは当たり前で
それはバイナリの実行コマンドを削除してビルドし直すのと同じこと

実行コマンド（イメージ）の中にデータを入れるな
データが入ってなければ、イメージの削除とリビルドも
何も気にすることがない作業だ

当初の質問から外れてしまっているのですが、
本質的な話だと思います。

ぜーーんぶ、設定に費やしたコマンドを明確に表して、buildせよっていうことですね。
それはつまり、コンテナの中でviでせっせと作成したスクリプトも全部、予め用意してbuildせよってことですよね。
でも、まだやろうと思っていることが試行錯誤で、固まっていないんですよ。

>>326-329
なるほど・・そういうものなんですね
まだよくわかっていませんが勉強してみます

>>330
Docker Hubなんかにあるベースイメージつくるなら最終的にDockerfileに全記載となるけど
試行錯誤中はcommitでも外部ボリュームマウントでもぜんぜんOK
アプリ開発なら特定のディレクトリしか使わないようにし(他には設定ファイルくらい)
開発中はディレクトリ全体をホストに置いてマウントするのが常套
buildではそのディレクトリ全体をCOPY(開発中はマウントで隠れる)
適当なプロジェクトのDockerfile, compose.yamlみたらわかる

>>330
だからDockerは試行錯誤しても時間がかからないように
高速にビルドができるようにレイヤーでキャッシュされてる
ビルドするのにやっていることを固める必要がない
試行錯誤をビルドして行えばいいだけ

つまり不思議システムってことか

また、いつもの、仮想OS とコンテナの違いが分からない、香具師が来ているのか

>>264
に書いただろ

山浦清透の動画内の、AWS の構成を見てみろ

開発中は、Docker 外の共有フォルダへbind しておけばよい

>>332
わかりやすいレスありがとうございました。
なるほど。

コンテナの「ルートディレクトリ」ごと
ホスト側に移してバインドしておいておけば、
そのコンテナで試行錯誤してもコンテナ自体は太りませんね。
必要があれば、変更のきりのよいところで、
ホストに置いている「ルートディレクトリ」ごとバックアップ取ればいいのかもしれない。

というのは、yumとか、外部から落としてきたtarをコンテナ内で使うと、
どのディレクトリに変更が生じるかわからないので、
いっそのことその「ルートディレクトリ」ごとホストに置いてバインドすればいいと思った次第です。

buildのコマンドで「ルートディレクトリ」全体をコンテナにコピーすればいいわけですね。

最後のところは、目からうろこです。
というのはいちいち設定内容をコマンド化（テキスト化）しなければならないと思っていたからです。

ひどいバッドノウハウの誕生を目撃した

>>332はルートディレクトリ以下全部なんて意図してなかろうに

ルートディレクトリでやってみたらいいとおもうよ
パーミッションの問題もあるしchroot環境構築するくらいの難易度で挫折するだろうけど
そこから学べることもある

頑なにテキスト化したくないってことは、buildでステップ的に構築しなくていいんでしょ
ならコンテナ内でvi編集でもyum installでもしたものをexportしてイメージとして使えばいいんじゃないの

1から作り直すことはできないけど、いらないんだろうし

だからコンテナは仮想マシンじゃないと何度も言う必要があるわけだよ
わかった？

月数百円程度でもいいのでplay with dockerみたいにさくっと試せるサイトないかな

なんで自分のマシンに入れないの？

ん？自分のマシンにも入れてるけど？

自分のマシンで試せばいいじゃんDockerなんだから

Dockerなのにそんなサービス欲しい理由が分からない

それはそんなサービス作ったエンジニアかだれかに言えよｗ

>>342
お金はらうなら
VPSかりて、リモート接続できるDocker環境つくればいい

Google Cloud ShellとかGCEの無料インスタンスで似たようなこと出来るんじゃね

docker machineの勉強をしようと思ってネット上の記事を色々読んでいたのですが
公式サイトに飛んだら
Docker Machine has been deprecated. Please use Docker Desktop instead.
とありました
Docker Machineを使うとAWSにDockerホストを展開するようなこともできたようですが
そういうこともDocker Desktopでできるんですか？
何か機能的に重ならない気がするのですが、どうなのでしょうか

Dockerは仮想マシンじゃない

アプリを配布するためのコンテナで
一般的には仮想マシンと一緒に使うもの

WindowsやMacの人はdockerデスクトップより
AWSのlightsailとか安いサーバでdocker-ce入れた方が
色々捗るんじゃ無いかと思う

何も使い勝っては変わらんのだが？

>>350
AWSに展開するならECSかEKSを使用するので、実行環境でDockerコマンドを直接使用することはない
というかDockerエンジン自体もほとんど使用されなくなっている

Dockerはプレハブハウス
VMwareはモデルハウス

モデルハウスの中にプレハブハウス入れるのか？
入れないだろ

例えはやめとけ

分かってないのバレるぞｗｗ

空き地（物理マシン）を借り切って、そこを小さな区画（仮想マシン）切り分けて

そのスペースに在来工法（環境設定）で家を建てるよりも
システム建築（コンテナ）で家を建てた方が早いって感じかな

システム建築と在来工法の違いはこちらｗ
https://www.systematization-building.com/comparison/

>>356
なんで混ぜるんだよｗ
Dockerってプレハブっていうか、工事現場にあるコンテナハウス？みたいなイメージあるんだよな
どこの現場でも速攻で事務所や休憩室になったりとかさ

対してVMは建売みたいに建てては売って(処分して)の繰り返しみたいな感じ

家の中に家を立てるのがVM
家の中にプレハブ置くのがDocker

>>359
> 対してVMは建売みたいに建てては売って(処分して)の繰り返しみたいな感じ

だからVMの中にプレハブを建てては売って(処分して)の繰り返えすんだろ？

ん？まさかVMって設定済みVMイメージの話をしてるのか？

設定済みVMイメージをどうやって作る？
それが大変だからDockerを使うってわかってる？

アホしかいねえ

例え話ってのは有用な時もあるんだけど
「自分が対象を明確に理解している時」に限定しないと
知ったか同士が例え話に例え話返し始めると
収拾つかなくなるよ

桃太郎というのは、例えば鬼のようなものである

鬼というのは、牙が生えていて、上半身裸
しましまのパンツを履いていて、金棒を持っている
悪いやつのことである

なぁ・・・もう疲れた・・・
何をどうやってもoverlay2の配下にデータが保存されるんだが・・・俺は何のために16TBのHDDを買ったんだ・・・もぅ疲れた寝る...zzzZZZ

あっ、言い忘れてたよ・・・誰かタスケテ！！

何をどうやったかを言わなきゃ誰もなんもできねーよ
そうゆうとこだろお前が失敗してんのは

>>368
説明できん・・・のだ

イメージなりボリュームなりをリムーバブルメディアに置きたいんじゃないの

Macだと悩まないのでWindowsなら
ジャンクションつかえばかいけつする

いやさ全録サーバー構築してんだが・・・
SSDの方にLinuxとDockerとコンテナ入れてさ、録画したファイルをHDDの方に保存したかったんだけど・・・どこをどうしてもoverlay2の配下に保存されるんよ・・・

これが昨夜までの状態・・・

で、今帰ってきてLinuxから入れ直したらできたわ！どこが悪かったのか謎のままだが動けばオッケー
まずは地上波全録して何日分録り溜めできるか試さなきゃ

ノシ

きっとお化・・・霊の仕業だと思う

先にコンテナがマウントしたディレクトリかその上位に後からHDDマウントしようとしてnot emptyになってたんじゃないの

ローカル上で動かすとバリ速い処理があるんだけども、EKSで動かすもCPU(limitつけてないのに）使い切ってくれない

何の設定が悪いんだか教えてくれだれか
たすけて

ストレージとかが遅いんやろ？

wordpressをpullして起動するだけでとりあえず使える状態になるのはしびれたけどそれ以上のメリットあんのかって気はするよな
Tensorflowでgpu使うのに便利だって書籍に書いてたからやってみたら必要なものを入れる度にリビルドしろってアホかと
ローカルに入れた方が100倍楽だ

じゃけんローカルに入れたやつを他のサーバーに移動させようや

アホやな
一生レンタルサーバー契約してろ

最初から全部入れとけっていう

でも実際こういうやついるからな 一緒に仕事したくないわ

>>377
デーバーにデプロイの話はなんでしないの？
まだそこまで理解してないから？

訂正

>>377
サーバーにデプロイの話はなんでしないの？
まだそこまで理解してないから？

Docker Hub に、Tensorflow のイメージぐらい、誰か作って公開していないのか？

>>383
サーバーがなにか理解してないだろ
pcと同じものだぞ
自分の家のpcでwordpressを起動して公開するのもvpsに配置するのも同じ事
実機を使うかsshで遠隔操作するかの違いだけだろ
awsのサービスとかの話なら既出だし
なにが言いたいのかわからんw

>>385
俺はサーバーを知ってるんだぞ自慢はいいからさｗ
Dockerが解決してるデプロイの話を
なんでしないの？
デプロイの話をしない理由を言ってみ

そこらへんの話は仕事でやんのか趣味でやんのか違いっしょ
流石に仕事で >>385 みたいなこと言われんやろ 流石にね

>>387
pbxの設置から鯖の設置、基地局設備の設置までやってたけどな

Dockerを軽量版仮想マシンぐらいの理解でいるとこうなるという分かりやすい例だな

>>388
機材の搬入までしていたとか言いそうで草

ソフトウェアのデプロイの話をしろよ

苦労話をすればいいんやで？
サーバーのバージョンが古くてライブラリが古くて
それをインストールしようとしたけど、ビルドが出来なくてーとか
あるやろ？

今はDockerですっかりなくなってしまったがなｗｗｗ

デプロイとかしたことないから
デプロイの苦労話なんてないんだろｗ
Dockerのメリットがわからないやつは所詮素人ということがわかる

老害お得意の苦労話()

5chは老害の巣窟ですよ。
子供は他所で遊んだ方が良いですよ。

デプ＝ロイ
1721-1758

若い衆は他SNSメインですよ＾＾；
老害どうしで喧嘩してるだけ

wordpressが鯖の上で動くアプリって事すら知らないでデプロイの事を話せってw
知恵遅れにもほどがある
というかdockerすら使ったこと無いだろ
dockerの話一つもしてないのはお前だw

>>396
Dockerはデプロイに使う道具なんだが？
わかってないのか？

docker使ってて便利に感じるのは環境差分が吸収されることよねー

>>397
dockerってデプロイしないと使えないんだぞw
お前あれだろ、linux使ったことすらなくてwindows使ったら快適だったスレとかで暴れ回ってるうんこやろうだろ

もうDockerの話題やめようぜ

スレチだろこのスレはPartのスレだぞ