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/ >>189 だから言ってるだろ 1. Dockerを仮想マシンの代わりとして使おうとする 2. Dockerは仮想マシンの代わりとして使うのは面倒くさいじゃないか! 3. Dockerは仮想マシンの変わりにはならない! 4. つまりDockerはクソ って言ってるのがお前だろ? 俺は最初から言ってるよな? Dockerは仮想マシンじゃない。 (必須ではないが)仮想マシンと組み合わせて使うもの。だと ぶっちゃけ最初からアプリがポーダブルになってればDockerなんて要らんのだよね snapを始めとしたモダンパッケージマネージャのほうが優れてる 依存関係もまとめて全部塊でわたせるって 一見するとスマートに見えるけど実は筋が悪い パッケージの別バージョンのインストールをサポートして実行時に依存関係リストに紐付いてるバージョンを動かすようにしたほうが簡単でサイズ効率も良い >>192 アプリがポータブルってどういう事? 例えば何かをRubyで書いたとしてRubyやRubyの ライブラリのバージョンが違っても動くようにするための 方法が他にあるっていうの? それをやるのは事実上不可能だからDockerがあるんでしょ 本当にアプリをポータブルにしたいなら 外部コマンドやライブラリを一切使わずに Linuxカーネルの機能だけを使ったバイナリを作るしかないな >>193 > パッケージの別バージョンのインストールをサポートして実行時に依存関係リストに紐付いてるバージョンを動かすようにしたほうが簡単でサイズ効率も良い それをやってるのが.NETだけど Linuxの場合、ライブラリを複数バージョンインストールできるようにして それらをアプリごとに切り替えて使う仕組みがないんだよ マニフェストで使うライブラリのバージョンを変更できる機能とかが必要だからな >>192 > snapを始めとしたモダンパッケージマネージャのほうが優れてる snapは誰かが作ったアプリを使うためのもの Dockerは自分でアプリを作るためのもの >>194 いやいや簡単にできるぞ アプリXが言語Aのバージョン1 アプリYが言語Aのバージョン2 アプリZが言語Bのバージョン1 をそれぞれ使ってるとする パッケージX,Y,Zを入れると自動でパッケージX,Y,Z,A1,A2,B1がインストールされる Xを実行するときには隔離された名前空間にX,A1のみがロードされる Yを実行するときには隔離された名前空間にY,A2のみがロードされる Zを実行するときには隔離された名前空間にZ,B1のみがロードされる ぶっちゃけこれだけでいいんだよ イメージに全てを固めて転送するのは無駄が多すぎる 本当に欲しかったものはスマートなパッケージマネージャと実行時の名前空間管理システムであってイメージじゃない >>195 .NETにできるならほかでもやろうと思えばできるわな >>196 お前の定義はどうでもいい >>197 簡単にできるというのなら、それを使えば解決するのでは?w 「それ」が何のことか言えないから、お前はそうして アプリXとか具体的ではない名前しか言えないわけで >>197 それ結局Dockerじゃね? Dockerのやり方に無駄が多い理由は ・複数のイメージが同一のライブラリを使用する場合に重複が生じる ・使われないコンポーネントがイメージに沢山入っている だと思うが、君の挙げた例は上の2つの問題とは無関係で、Dockerによって解決できている問題だ >>197 もう少し具体的な話をしてあげようか? あるPerlスクリプトがあったとして シバンに #!/usr/bin/perl と書いてありました だから/usr/bin/perlが使われます どうやって解決しろと? >>199 俺がやっても意味ない Docker社なり公式がエコシステムとして提供しないと >>200 Dockerは重複を解決できていないよ 単純な構成のアプリならベースイメージを共有することができるが 複数のパッケージに依存するアプリはもうだめだ 個別にDockerfileを書かなきゃならんので重複が生じる >>201 だから名前空間だよ パッケージXがpython:3.1パッケージに依存してたとする パッケージXをインストールするとpython3.1がインストールされる(もし既に在るならスキップ) 実行時にはパッケージXのための名前空間が切られて そこにパッケージXとpython3.1がロードされる パッケージXから見えてるpythonは3.1だけなので/usr/bin/pythonは3.1がうごく >>202 名前空間なんて機能はLinuxにはありません 勝手な機能を作らないでね >>204 docker使っておいてそんなレスしちゃうのはヤヴァイ >>206 えぇ?もしかして名前空間って結局の所 Dockerと同じことをすればいいって意味だったんですか(笑) ならDockerでいいですよね(にっこり 結局アプリケーションの実行環境を仮想化するなら Dockerが最適解だったってことなんだよな >>207 やれやれだ Dockerも名前空間を利用してるがその使い方が下手くそだ よりスマートに使うにはパッケージマネージャ方式が正解 >>209 お前、名前空間の意味わかってないだろw Linuxカーネルの言葉で言ってみ そしてパッケージマネージャーが、どこでその機能を使うんだよ まあ、お前には無理だろうな(笑) >>210 user namespaceも知らんのかお前 パッケージマネージャで依存関係を管理してそれをもとに特典のパッケージとその依存関係を名前空間で隔離して実行すって何度も言ってるが 名前空間も知らん人には理解が追いつかないかな はい、ぼけつほったー(笑) https://gihyo.jp/admin/serial/01/linux_containers/0016 > ユーザ名前空間は3.8カーネルで実装された,現時点では一番新しい名前空間です。 > この機能により名前空間内で独立したUID,GIDを持てるようになります。 > 名前空間内のUID,GIDとホストOS上のUID,GIDの間はマッピングによるひもづけが行われます。 これとファイルシステムに一体何の関係が? /usr/bin/perl という絶対パスしていを UIDとGIDのマッピングでどうやって解決すると? そしてパッケージマネージャーがどうやってUIDとGIDのマッピングをすると? パッケージマネージャー上でアプリでも動かすんか? ファイルを配置するだけのパッケージマネージャーでは無理だよなぁw なんかパッケージマネージャーとかいってるけど こいつのパッケージマネージャーは サービスとして動いていそうだよなw パッケージマネージャーの機能をDockerに対応させると Dockerイメージの作成部分だけの機能で ランタイム部分はないわけだが こいつのパッケージマネージャーはDockerの コンテナランタイムのように、アプリ実行時の プロセス分離やネットワーク分離までやってそうだ >>212 ぷっ 名前空間がUIDGIDだけだと思ってんのかこいつwww >>213 snapd パッケージマネージャがデーモンとして動いてるなんてのはもうすでにあんだよ お前さん取り残されてるぞ >>214 ユーザー名前空間と言った後 しれっと「ユーザー」を消すとか 卑怯ですねぇ(笑) >>215 あれあれ?じゃあお前のいうパッケージマネージャーって Dockerみたいなものだってことですかねぇ snap?登録に数時間かかるようなものがつかえるわけ無いだろ だから言ってるDockerは開発者のためのもので お前のような一般ユーザーはお呼びじゃない コンテナ配布で同じ環境を猿でも容易に作れたり、スケーリングや冗長化や障害発生時の自動回復で 素早くコンテナの停止と起動を行えるような仕組みがないと同等以上とは言えないんじゃないかと 前々から言ってるように アプリ開発者が自分のため(例 自社のサービス運用)に使うのがDockerで エンドユーザーにアプリを配布するのがsnapなどなんだよ その違いがわからない人がいる。 それはアプリを作らず、自分とは関係のない人が作った アプリをただDockerイメージにしてるだけの人 そういう人だから既存のパッケージや仮想イメージを 変換してパッケージにできれば便利だって思ってしまう だって、それらを材料として自分のアプリやシステムを開発してないから インストールだけしたい人だからね エンドユーザーと同じなわけさ じゃあDockerHubに上がっているdocker-composeの公式イメージはどういう扱いになるんだろう 【悲報】 DockerHubのイメージが6か月しか持たなくなった…… dockerは存続できるのか? podmanに移行したほうがいいかもな redhatなら安心だ インスコが面倒くさい人のためにDockerイメージが提供されてることはある php向けの静的解析ツールのphpstanはDockerでも動く シェルのエイリアス使えば普通にインストールしたのと同じ感覚で利用できる https://phpstan.org/user-guide/docker >>221 6ヶ月pullしてないイメージが消えるだけやろ?w 使ってないイメージが消えてなにか問題があるんか? 作り直せばいいだけだし、それができるのがDockerfile >>221 dockerhubは着実にsourceforge化が進んでるな。 そのうち何か月かpullされない物はイメージ内に勝手に広告入れてくるぞw >>226 そうだな。広告が入ったらお前が正しい。入らなかったお前は間違い。 今はまだ入ってないから、お前の予想は現在進行系で間違い続けてるってことだ。 これからずっと何年間もお前は間違い続けるだろうw コミュ障は冗談が通じなくて大変だなw 人付き合いどうしてるのw? 冗談で言ってるといいながらそれが本音だったりするからな だからマジレスすると答えられなくなる そりゃ本音だろ。 どう見ても悪い道歩いてる。 冗談といってるのは、相手を追い込まない会話スキルだろね。 「冗談じゃねーか」 これって逃げゼリフだと思うよw Dockerが消えてもPodmanがあるから安心 レジストリはどこかが引き継ぐでしょ >>215 dockerやってはsnap使ってるって事はmicrok8s使ってるの? このタイミングで…。 September 1, 2020 Introducing GitHub Container Registry ttps://github.blog/2020-09-01-introducing-github-container-registry/ >>240 Dockerhub終了のお知らせって事で良い? こりゃいよいよDockerhubは広告が入りそうだなw >>240 > Docker as the second most popular ecosystem in Packages Dockerってすごいな。パッケージシステムとしての デファクトの1つを確立してるじゃん snapとか言うのオワコン? >>242 >>192 は単に「俺はDockerよりもsnapの考え方の方が気に入っている」 と言っているだけであって、別にシェアのことを言っている訳じゃないね。 話をちゃんと聞き取ろうね。 yumとかaptとかnpmとかが無料ユーザーは 利用回数制限するとか言ったことある? >>243 「Dockerの役割を知らないから、snapが代わりになると思っている」 じゃねーの?w Dockerは開発者のものという意味がわからんのだろうね 自分が開発者じゃないから >>244 Dockerも利用回数制限するとは言ってないですね なにがいいたんでしょーか? >>245 この勘違いくんいつまでこの勘違い続けるんだ? クライアントはDocker使わないとでも思ってんのかね >>247 クライアントだけに限定するなや お前が言ってるのは、ハズレを除けば 全部アタリって言ってるだけだ Docker Hubのプル回数制限の件は 運営側が様子見て まだ行けそうだったら 徐々に緩和する事に期待するしかない プル回数制限ってログインしてないユーザーで6時間で100回だろ? ログインしていれば200回 ローカルにpullしたものはキャッシュされるわけで ビルドするたびにpullしてるわけじゃない 100回で困るんだろうかね? >>250 やべーのはCIだろうな 毎回クリーンな環境作って複数のimageをpullするから100回なんてあっという間だ >>251 なぜ今、6時間で100回のpull制限はキツイかどうかって話をしてるかわかる? 開発者はCIを使ったテストで多数のイメージをpullする必要があるからだよ これがDockerの主なユースケースの1つ 開発者なら容易に思いつくんだが snapが代わりとなると思ってるような奴には理解できない そういうやつがsnapの方が考え方が気に入ってると言ったところで お前はDockerの使い方を知らんのだとしか言いようがないだろ >>252 クラウドのCIを使ってるならクリーンな環境を作るときにIPアドレスが変わるはずだよ IPアドレス固定は有料だから、固定にする必要がないものまで固定にしたりしないだろう 自社でCIサーバー立ててるようなところは苦労するかもしれんがw >>253 本当に意味わからんなお前ちょっと冷静になれ CIもクライアントの1つだ >>254 考えが足りなすぎる 脊髄反射でレスするからレスの内容が薄いか間違いだらけ IPが毎回違うってことは予期せぬ回数制限に引っかかる確率が上がるってことだぞ CIパイプラインでこの仕様は致命的だ 実務者でdockerhubがコンテナレジストリって人居んの? アマゾンかグーグルでしょ。 使ってるのカネのない個人だけ。 >>255 > CIもクライアントの1つだ クライアントの1つだというのなら、 クライアントはCI以外にもあるという話 それ以外のクライアントも考えろと言ってる 例えば開発者だ >>256 > IPが毎回違うってことは予期せぬ回数制限に引っかかる確率が上がるってことだぞ 考えなしに発言してるのはお前だろ クラウドの用途はCIだけじゃない。多数のマシンの中でCIに使ってる確率なんて僅かだ 毎回作り直してる=いろんな用途に使ってるんだから 予期せぬ回数制限(6時間で100回)に引っかかる確率なんてごく僅かだ >>257 ディストリ含めてOSSで使ってるのはほとんどDockerhubだろ >>258 そうだ 沢山のクライアントなかの1つが開発者だ つまりDockerは開発者だけのためのの物じゃない 様々な利用者と利用目的がある 開発者のためのツールなどと言い切るのは見聞が狭すぎる井の中の蛙の意見でしかない >>259 また考えが足りないぞ 膨大な数のインスタンスが生成されてるから再割り当ての数も多い インスタンスのプーリングを行っていることも考えればハズレをひく可能性は十分だ コミュ障患者が一人で延々と会話してるみたいで気味悪い。 コンテナがらみのまともなスレは無いのか? GitHub(Microsoft), CircleCI, Google などが、DockerHub を援助すべき! >>261 snapではDockerの代わりにならないってことが 理解できたようですね 「GitHub Container Registry」パブリックベータとしてサービス開始。無料でコンテナのパブリックイメージ公開可能 https://www.publickey1.jp/blog/20/github_container_registry.html ベータ版のあいだはプライベートなレジストリとしての利用も無料で、正式版となったときには、GitHub Packagesと同じ料金体系が適用される予定です。 ちなみに現在のGitHub Packagesの料金は、無料の「GitHub Free」では500MBストレージ、1カ月あたりのデータ転送料は1GBまで。「GitHub Pro」「GitHub Team」は2GBストレージ、1カ月あたり10GBのデータ転送量まで、など。 まじかよpull回数制限ってもう始まってるのかよ 11月までに対策すればいいやって思ってたのに (対策っていうのは俺がpullで困ることへの対策じゃなくて 俺の作ったイメージを使ってる人のための対策ね) >>271 crontabかなんかで、月1回だけ、認証アカウントからpullすればいいんとちゃうの? >>272 だからpullするのは俺じゃないんだってw 前から思ってたけど、イメージ名が卑怯だよな 例えば debian というイメージはDocker Hubからダウンロードと決め打ち Googleのを使うとイメージ名が変わってしまう わざとそういう設計にしてるんだろうけど 対策って、「空いてそうな時間にpullしてね」って言う以外にどんなのがあるかな ネタというか暇つぶしにおちょくってるとき以外はずっと過疎ってるねここ Macで動かすと遅いって記事をqiitaでみたけどまじなの? ファイルシステムのせいだろ。NFSにしたら直るとか。 まじだよ。osxfsが遅い。 ホストとコンテナ間の一貫性を犠牲にして速くするオプションもあるけど、まぁ遅い。 個人的にはMac捨てたほうが幸せだと思う。 母艦はなんでもよかねえか どうせクラウドに接続して仕事するだろ >>283 gRPC FUSEにしたら、改善はするけどな。 safariがWindowsでもLinuxでも動かせればいいんだけどね Macうぜえ >>286 Apple「Mac買ってください。お願いします。どうかお願いします。助けると思って」 >>285 Docker for MacのEdgeリリースには入ってるんだっけ?試してみるかぁ DockerはもともとLinuxのLXCを使って実現したわけだけど、それ以外の環境だと 何らかの仮想化環境の上でDockerをエミュレートしているような状態だよな。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる