Docker Part6

テンプレとかいらんやろ

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

>>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のオプション定義ファイル