Docker Part6

テンプレとかいらんやろ

>>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あたりが買収して
無償化継続してくれんかなぁ。