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/ 結局アプリケーションの実行環境を仮想化するなら 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をエミュレートしているような状態だよな。 >>288 あぁ、手元は Edge を使っていたので、そのまま書いてもうた、スマン。 あと、VMware FusionをHypervisorにして、 Docker for Macから使うのもいいよ。 オススメは VMware Fusion Proでネットワークまわりをがっちりと作って、 Docker for Macから使うのもいいね。 >>288 んで、そこらへんをサクッとできるのが、 VMware Fusionの Project Nautilus。 VMware Fusionでサクッと、OCI containerを扱えるよ。 >>289 目的と手段の違いだな Dockerの目的は、あらゆるOS上で同じDockerイメージを動かすこと だから最初からWindowsとmacOSにも対応していた LXCを使うのは手段でしか無い 実機はLinuxだから素早く起動できるコンテナを使うという目標はあっただろうけど それと同時にWindowsやmacOSでも動かすという目的もあったのだろう >>292 macにそんな新機能とかご苦労なこったな。 当事者のアップルはintel捨てるっていうのに。 評価するだけバカバカしいわ。 MacみたいなカッコいいハードのLinuxノート売ってくれ >>294 ちなみに、最近、VMware Workstationもできるようになった。 2014〜2016年頃?: DockerはVMより起動がずっと早いです!将来はネイティブで実行が可能となりVMは不要になります! Dockerデスクトップ作ったので今はエンタープライズ向けのツール作って開発機から本番機までをサポートします! その後: 結局はDockerはdocker machineという名のVMの上で動いていただけです。 ネィティブ実行は出来ません(諦めました、CoreOSは離れていきました) エンタープライズ市場はK8sに勝てませんでした(諦めました、作ったツールは他社に売却しました) 今後はVMとコンテナは共存します。わが社は開発者にターゲットを絞ってサポート続けます。 駆逐されるはずだったVMの会社 →えっ?じゃあウチがコンテナランタイム作った方がよくね? 駆逐されるはずだったエンタープライズの会社 →えっ?じゃあウチがコンテナランタイム作った方がよくね? イマココでOK? > DockerはVMより起動がずっと早いです!将来はネイティブで実行が可能となりVMは不要になります! それ言ってたのバカだけ。 Dockerは最初からアプリを配布する他のものだって 公式の情報見てたやつはちゃんとわかってる そして今もバカは同じことを言ってる。 > 結局はDockerはdocker machineという名のVMの上で動いていただけです。 それはmacOSとWindowsの話 お前みたいにLinux使ってないやつだけがそう勘違いする > (諦めました、CoreOSは離れていきました) CoreOSはDockerと全く関係ない。 むしろ競合技術。CoreOSのrktはまさにDockerの代替 CoreOSが消え去ったのはDockerの勝利 Docker vs. CoreOS コンテナ戦争とは何だったのか? https://gihyo.jp/news/report/2016/11/2201 > 駆逐されるはずだったVMの会社 > →えっ?じゃあウチがコンテナランタイム作った方がよくね? VMの会社はMicrosoft、KVM、VirtualBoxのOracle、 VMware、Parallelsなど。どこもコンテナランタイム作っていない >>299 >公式の情報見てたやつはちゃんとわかってる その公式の情報とやらは何処に…? >>301 そのcoreosがrkt作ったことをもって「離れました」と言っているのだが? https://gihyo.jp/admin/column/newyear/2018/container-and-cloud > しかしその一方で,Dockerコンテナを支えていたはずのCoreOSからDockerの対抗技術であるrktがリリースされたり,CoreOSとGoogleが親密な関係を築き >>302 290番台はVMwareがコンテナランタイム作ったよ、 と言う会話をしてるんだが? https://blogs.vmware.com/teamfusion/2020/01/fusion-tp20h1-introducing-nautilus.html Containers on the desktop today -> Nautilus is different >>303 会話についてこれてなくて大爆笑w > その公式の情報とやらは何処に…? Dockerのドキュメント見ろって話 サイト見たこともないだろうなw >>305 いいからURL示せよ。 多分にお前のファンタジー解釈が入ってるだろうからw https://www.docker.com/ > DockerはVMより起動がずっと早いです!将来はネイティブで実行が可能となりVMは不要になります どこにもこんなこと書いてない っていうかさ、お前が書いてある証拠を出さないといけない案件だろ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる