Docker Part6

テンプレとかいらんやろ

>>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使うという層がいるからね
間違ってはいない