◎正当な理由による書き込みの削除について: 生島英之 とみられる方へ:Docker Part4 YouTube動画>4本 ->画像>1枚
動画、画像抽出 ||
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク: http://5chb.net/r/linux/1597591176/ ヒント: 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
Linuxが持つコンテナ技術を使った、仮想マシン必要ないアプリケーション仮想化技術で
アプリケーションのデプロイが用意になります
Docker(アプリ仮想化)は仮想マシンと併用して使うことで最も効果を発揮し
開発・テストで使ったDockerイメージと全く同じものを本番環境で使えます
さらにWindowsとmacOSでも同じDockerイメージが動きます。
(Linuxは仮想マシンが不要ですが、WindowsとmacOSは仮想マシン技術を併用して実現しています。)
Dockerイメージ(Dockerfile)はアプリケーション開発者が作成します
動かすのに必要なもの全てがDockerイメージに含まれるので
インフラ担当者はそれを動かすだけ、本来のインフラの作業に集中できるようになります
Dockerは主にウェブ業界でサービスのデプロイの必須技術になりました
情報共有しましょう
http://www.docker.io/ 前スレ
Docker Part3
http://2chb.net/r/linux/1552023620/ 注意 同じコンテナ技術を使うが異なるアプローチで仮想マシンの
代替を目指しているのがLXC。目的が全く異なるので注意
LXC(Linux Containers)
http://2chb.net/r/linux/1330826939/ >Dockerは主にウェブ業界でサービスのデプロイの必須技術になりました
>>1 は何も理解してない馬鹿。
すっげー前にDeployerを教えてあげて、それを納得したはずなのに何も理解していない。
マジでお前は、いつ学習が完了するんだよ。
http://2chb.net/r/linux/1552023620/ >>651 何故話をこんなレベルまで戻すのか
> すっげー前にDeployerを教えてあげて、それを納得したはずなのに何も理解していない。 手動でデプロイしてんのか? オートスケールどうするんだ? Docker使わないと構築に時間がかかるだろ Dockerはイメージのrun(内部で自動的にpullする)だけで構築が完了する アプリが動く状態として完成された物が手に入る Deployer?運用のことを全くやってないか 数台規模で夜間メンテナンスなんてのを いまどきやってる程度の小さいレベルんだろうな
> すっげー前にDeployerを教えてあげて、それを納得したはずなのに何も理解していない。 なんだこれ?妄想世界の住民か? 「すっげー前にDeployerを教えてあげて」 なぜ同じ人だと思ってるのか? 「それを納得したはずなのに」 納得したという妄想だろう 納得させたというレスがあるなら持ってきてみてくれ 妄想世界の住民だろうから、絶対に無理だろう おそらく俺の予想は的中する 絶対に持ってこない
buildkitっていうのがあるんだってな 環境変数で指定しなくてもデフォルトで利用できるようにしたほうがメリットないだろうか
>>5 設計や動作が大きく変わってるから
長い検証期間を設けてるだけ
そのうちデフォルトになるだろうがすぐは無理
俺が知っている事例で言えばマルチステージビルドで
必要ない場合にビルドされなくなることがある
通常は問題がないだろうがビルドされているという
前提があったりすると問題が発生するだろう
buildpacksって OSやプログラミング言語のランタイムの更新があった時に 開発者は何もしなくても運用者側だけでアップデート出来るのが長所? しかし、package.json内の依存ライブラリの更新はそれで対応できるのか? 出来ないなら結局Dependabotみたいのは必要そう 微妙に互換性崩れてて OSや言語のバージョン上げたら動かないとかもありそう
運用者なんていない。あるのはシステムだけだ。 開発者が開発し、それを配布するときの面倒なごたごたを システムが勝手ににやるだけだろう 開発者が楽になるためのツールだ
いや、Dockerfileを書かなくていいのが最大のbuildpacksの長所か Dockerfileを書かなくていいので、プロジェクト間のコピペを抑止出来る OSイメージやプログラミング言語のランタイム更新だけなら、リビルドしないことも可能らしい CIでのビルドに焦点を当ててるように見えるが、 アプリケーションコードを含んでないイメージでローカル開発も可能なんだろうか?
> アプリケーションコードを含んでないイメージで なんだそりゃ? Dockerイメージは(自分で開発している)アプリケーションコードを含むものだろ 自分で開発したイメージを配布・デプロイするためにDockerは使うんだぞ
自分で開発してないイメージはDocker pullして使うものだ 例えばMySQLとかnginxイメージとか ああいうのは、本来はMySQLとかnginxの開発者が 作ってイメージとして提供するもの 実際にはDocker社が提供しているがね
>>10 PHPでの開発の時
ローカル開発の時はphpのコードはボリュームマウントして入れるが
本番環境で使う時は予めphpのコードが入ったイメージをCIで作っておいて
それをプルしてきて動かす
>>10 アマチュアっぽい
開発中も無駄にdocker buildしてそう
またキチくん暴れてるのか 頼むからコテハンつけてくれ
同じベースイメージでローカルqgp環境の開発を行い 本番環境ではベース+アプリケーションのコードが入ったイメージを使う ローカルと本番環境との差異が無くなるし サーバーが何台に増えようとも 各サーバーはビルド済みイメージをプルして実行するだけで済む
ローカルのphp開発環境だった 12 factor apps的には本番環境のサーバーでビルドするのはご法度 ビルドはCIでやっとけ
>>13 なぜ開発環境と本番環境を基本的に同一にしない?
Dockerなら、developmentもproductionも同じにできる。
同じにするということはイメージにソースコードを含めるということだな
>>15 開発中はDockerを使わない
テストで使えば良いのだ
新人「せんぱぁ~い。バグ報告書どおりにやったのに違うエラーがでるっス!助けてくださいよ~(´;ω;`)」 べテラン「どれどれ…おいなんでDockerがあるのに使わないんだ!お前のとこだけ依存ツールのバージョンが違うじゃないか!」 新人「テストだけDocker使えばいいと思ったんスよぉ~(´;ω;`)」 ベテラン「そもそも開発環境作るの手間だろ。なんで手間かけてトラブルの可能性を増やしてんだお前。マゾか?」 新人「いや~苦行インストールしたほうがなんかやった感あるじゃないッスか😁いひひ」 ベテラン「はぁ…お前今日アサインしたタスク終わるまで帰るなよ」 新人「そんなあああああああ。゚(゚´Д`゚)゚。」 これ半年ぐらい前の出来事
>>23 そういうことを防ぐために例えばRubyでは
Gemfileという仕組みがある
Dockerを使った所でバージョンの固定なんかできんよ
ディストロに入っているライブラリだけを使って開発するんじゃないんだから
むしろディストロに入ってないライブラリを使うことが多い
Dockerの中でGemfileを使ってバージョンを指定しているのであれば、
同じようにDockerを使わない場合もGemfile使ってバージョン指定をするだけの話
Rubyのバージョンも.ruby-versionでしていする
もちろん他の言語でも同様の仕組みがある
> ベテラン「そもそも開発環境作るの手間だろ。なんで手間かけてトラブルの可能性を増やしてんだお前。マゾか?」 Dockerは開発環境を作るためのものじゃない 何度もいわれていること
開発環境を作るためのものでもあるし他のためのものでもある 自分の狭い見識だけで道具の目的を決めつけようとすることは愚かだ
環境を作るとかいって仮想マシンの代わりだと思ってるやつの発言はこんなに間抜け
コンテナ型仮想化Dockerスレ その2
http://2chb.net/r/tech/1569542871/416- 正しい使い方を知らないやつが開発環境とか言うんじゃねーよ
>>28 VSCode Remote Containersという拡張機能がVSCodeにある
Microsoftは間違っていたとでも言うのかwwwwwwww
https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers The Remote - Containers extension lets you use a Docker container as a full-featured development environment. Whether you deploy to containers or not, containers make a great development environment because you can:
* Develop with a consistent, easily reproducible toolchain on the same operating system you deploy to.
* Quickly swap between different, isolated development environments and safely make updates without worrying about impacting your local machine.
* Make it easy for new team members / contributors to get up and running in a consistent development environment.
* Try out new technologies or clone a copy of a code base without impacting your local setup.
仮想マシンはDockerと同じっていう別なキチガイと Dockerは開発環境に使えないってキチガイの夢の共演 両方とも寝言は寝て言えっつーのw そんなの言ってるのお前だけだから
実装~単体まではローカル端末上のDockerにコード置いたディレクトリマウントして使って、内結以降はイメージビルドして商用相当の開発環境にデプロイしてテスト、そのイメージをリポジトリにあげといて商用からはそれpullするだけって使い方が普通じゃないの?
> 実装~単体まではローカル端末上のDockerにコード置いたディレクトリマウントして使って、 デバッグどうするの? デバッグ用のパッケージを入れるの? そうすると本番環境とは厳密には違う状態になるよね? どっちみち開発では便利さのために本番環境とは違う環境になるんだから Docker使わずに開発しても同じことじゃない?
できるだけ寄せていくだけだ Alpineで動かすならAlpineで開発したい でも支給マシンはubuntu、windows、mac、、、
開発環境を汚したくないんですよ dockerの特性上、1つのプロジェクトで様々な言語、言語バージョン、ミドルウェア、ツール、サービス、それらに依存するパッケージ、OSレベルの設定、、、 とまあとにかく多くのものに依存してしまう そして開発者が従事するプロジェクトは1つじゃない 開発マシンにこれらを直接インストールして管理するのは大変だ dockerならソースをpullしてコマンド打つだけ 別のプロジェクトが干渉する可能性も極めて低くなる アマチュアさんみたいにAPPとDBのシンプル構成、別プロジェクトは無し みたいな状況なら直接インストールでもいいかもしれんがね
>>35 開発はディストリ依存にするべきじゃないよ
変更しづらくなる
>>36 > 開発環境を汚したくないんですよ
汚す必要ないのでは?
> dockerの特性上、1つのプロジェクトで
Dockerの性質のものは一つもないね
> 開発マシンにこれらを直接インストールして管理するのは大変だ
全然大変じゃないよ。
そのためにrbenvなどの仕組みが普及してる
アプリを動かす環境は特定のディレクトリ以下にすべて入る
もう随分と前から一つのマシン上に 複数の環境を同居させる方法がかくりつされてるんだがな
>>37 クロスプラットフォームで動かす予定のないものをクロスプラットフォームで開発する予算は君が出すのかね?
>>38 rbenvのようなちゃちな仕組みではいずれ限界が来る
君のところは構成がシンプルなのでなんとかなっているのだろうね
>>40 クロスプラットフォーム?何を言ってるの?
どちらも同じLinuxなんだが
> rbenvのようなちゃちな仕組みではいずれ限界が来る ああ、知らないのか 無知はかわいそう
>>42 Linuxにも様々なディストリがあることを知らないと晒してしまったね
>>43 しょぼい構成の案件に従事してる人は気楽そうでいいね
Vagrantで十分って老害かと思ったら その手の構成管理ツールも使えない老害が現れたのか mysqlとかnginxとかmailcatcherとかminioとかは? 全部手作業でセットアップかよ? CIはどうする? 老害だからCI知らないのか
QA環境作らないの? ローカル環境で動かしたら即本番? そんな訳あるまい
1つイメージを利用して、名前の違う2つの内容同じコンテナを実行したら メモリは2倍消費されますか?
>>53 それは同じプロセスを2つ起動したらメモリは
2倍消費されますか?と言ってるのと同じ
Dockerの話とは関係ない
>>53 2倍になるよ
ただLinuxにはKSMという仕組みがある
それで消費を削減できる
そうなんですね 今はnginxとapacheでリバースプロキシでマルチサイトを構築してるんですが dockerのほうがPC移行したときにすぐ構築できるので楽だと思ったんですよね
apacheってオワコンじゃないの? PHP動かす用ならnginxとphp-fpmの方が良い
メモリーの少ないサーバーで動かしたいのなら ますますnginxの方がよい 速いしメモリー消費が少ない
nginxをフロントに置いてPHPはapacheで動かすのがいいらしいっすよ リバースプロキシていうみたいです
うちは本番環境がAWS ECSだからELBをリバースプロキシとして使ってる nginx+php-fpmはその背後に配置 ECSはランダムなポート番号を自動的に選択して ELBのターゲットグループにタスクを登録してくれる 新しいバージョンをデプロイする時も徐々に新しいバージョンに流す通信を増やして切り替えてくれる いきなりブチッ!て切るようなことはしない パスやドメインに応じたルーティングも可能 ELBじゃなくてnginxでも対応出来るが nginx単体でちゃんと高可用性でやるのはたぶんむり ELBの方が金が掛かるが便利
Docker Hubがコンテナイメージの保存期間に加えてPull回数にも上限を設定すると発表
https://gigazine.net/news/20200826-docker-hub-update-policy/ 容量に関わらず100回固定?
複数IPを使うヘビーユーザーが出てきて
結局一般ユーザーが割りを食うだけになりそう
docker-compose.ymlで十分だから今の所イメージを保存する必要がこない
>>62 100回ってびっくりしたわ
6時間あたり100回か
それに「Pull回数の制限はイメージのPullを行う側が利用する」と書いてある
イメージごとじゃないな
どうやって判断してるんだろう?
> 匿名ユーザーの場合はIPアドレスをもとに制限されるとのこと。 書いてあったw
そんなケチるほど金ないのか マイクロソフトに買い取って貰えばいいのに
pullしようとしたけどすでに最新だった場合ってどうなるんだろうか? pullチェック時点でカウントされるのか それとも実際にpullした場合でカウントされるのか 大企業とかではキャッシュサーバーが必要になるかもしれんな
>>69 というか、自前でレジストリ作れってことだよ。
Circle CIとかGitHub ActionsとかのSaaSは 仮想マシンは同じIPを再利用する事ある? 同じユーザー扱いになってCIが急に失敗するようになりそう レジストリのミラー作るのって なんか難しそう
>>70 レジストリをメンテするぐらいなら金払うよ
たった月5ドルだろ?
>>71 別のユーザーによるpullでCIがこける可能性があるんだよな
でもそれはCIサービス側が対応する問題になるだろう
その対応の内容には安定したpullがしたければ
金払えっていうのも含まれるけどw
ちなみにオープンソースでツール公開してるんだけど、この間から
おそらく誰かがCIに組み込んだようでGitHubのGit Clone数が跳ね上がった
その数が大体1日500~600cloneで、ユニーククローン数が300~400clone
つまりGitHub側から見れば1日300~400人が来て2回pullしてるように見えてる
このデータから一概に言えるわけじゃないけど、同じIPアドレスを使われる可能性は低いと思う
CI実行するたびにクラウドの仮想マシン作り直してるだろうし、クラウドの仮想マシンは
固定にしない限り作り直せば変わるわけで、問題が発生することは殆どないと考えてる
>>68 Docker社はずっと大赤字だろうけど、GitHub のようにプラットフォームとして成長していればいずれエンプラで黒字化するだろうという目論見だったのが、
KubeやECS等にエコシステムを乗っ取られエンプラ事業が大失敗に終わったことで完全に収益化の望みが断たれた
Docker Hubはプラットフォームといえども所詮はいくらでも替えのきくストレージに過ぎず、タダ乗りベンダー連中との間の差別化要因も乏しいためGitHubのような赤字を余裕で帳消しにするレベルの大型買収にも期待できない
もう焼畑しかないというわけだ
ふーん Docker終わったな これからはpodmanが勝つるか
Dockerがエンプラで黒字なんて無理だろ。 そもそも本番機で使えるエコシステムがECSであれEKSであれ他社の製品だし。 しかも本命は不在だし。 問題がはっきりしているのに何でこの分野でDocker社は何も提供しないの? 個人的にはECSであれEKSであれ下で動くインスタンス(VM)がサービスの前面に 出てきている時点でDockerは本番機には使いたくない。 VM管理とコンテナ管理の二度手間以外の何物でもないからね。 アマゾンはよく理解してる様でAWS Fargateでインスタンス隠しているけど、普及しているかどうかは知らない。 Docker社とも関係ない
何を言ってんだ ホスト管理がいやだからクラウドのコンテナサービを使うんだろうが
dockerを使わないと逆にインスタンス管理が大変になると思うが
>>77 https://vmware-juku.jp/whatsvm/containers-benefits-why-kubernetes/2/ >Kubernetesは外部のOSSと連携することによってNATを経由することなく
>別のホストのコンテナ同士の通信を実現しています。
>OSSを利用する場合のいくつか選択肢がありますが、
>flannelを採用した場合はオーバーレイによるカプセリングを行うことで、
>従来の仮想マシンのようにIPアドレスを割り当てることが出来るようになります。
こういう単語が出ている時点でホストの管理もしなければならないのは明かだろ。
AWS Fargateで「ホスト」と言う単語が一切なくなるのなら、標準になるかもしれないけど
そうなるとコンテナランタイムがdockerである必要もない。
dockerを採用するとhost machineの管理が単純化されるので全体としての管理が楽になるということですね
>>80 > こういう単語が出ている時点でホストの管理もしなければならないのは明かだろ。
どういう理屈?
1. Kubernetesは別ホストと通信できます
2. しかもホストを管理しなくていいです
こういう話だよね?
どこからホストを管理しなければならないなんて話が出てきたの?
>>82 いやいや意味が分からない。
ホストの管理をしなくていい→「ホスト」と言う単語は出てこない。
でなければならないって話だが。
何でDockerだとホストの管理をする必要が無いと思うの?
>>84 それはDockerじゃなくても同じだねw。
最初からそう言ってる いったいどっからホストの管理が必要なんて話になったんだ?
いやもう日本語通じない通じないw
このトピずーとそうだけどw
>>77 ホスト管理がいやだからクラウドのコンテナサービを使う
>>78 インスタンス管理が大変
>>84 クラウドだからホストは管理不要w←Now!
>>83 お前がホストって言葉を知らんだけじゃね?w
わかりやすくパソコンにしようか?w
息子がやってくれるからパソコンの管理はしなくていい
パソコンの管理をしなくていいが、パソコンという単語はでてくる。
例えば「パソコンを使う」「パソコンの電源を入れる」とかね
「(ホストの)管理しない」という話と「(ホストという)単語が出てこない」には
まったく繋がりがない
ホストの管理をしなくても、ホストという単語は出てくる
>>83 > 何でDockerだとホストの管理をする必要が無いと思うの?
Kubernetesだからホストの管理をする必要がないって話だろ
話をすり替えんなって
Kubernetesはノードを意識した細かい制御ができすぎてな ホストに強く依存した変なオーバーエンジニアリングをやりだす問題児が必ず出てくる ECSより遥かにホストを意識してるわ
>>88 そんなレベルの話をするなよ初心者くんw
君の言う「パソコン」=物理サーバは
完全に抽象化されててこのスレ内では全くでないだろw
Dockerの中で「ホスト」と言っているのはDockerが動く基盤であってそれが物理サーバであるかVMであるかは問わない。
非常に多くの場合はVMであり、それは「インスタンス」と言う名前で出ている。
つまりこの文脈ではホスト=インスタンスって事
で何でk8sだからホスト管理しなくて良いの?
https://knowledge.sakura.ad.jp/3681/ 例えば、上記の構成で本番機を作ったとして、192.168.0.50が死んだらどうするの?
「ホスト管理しなくていい」と言っているのは生存管理すら必要ないと言っているんだよね?
>>92 > 例えば、上記の構成で本番機を作ったとして、192.168.0.50が死んだらどうするの?
ああ、おまえ、GKEとかEKSというサービスを知らんのかw
上記の構成を作って"管理"するのはクラウドサービス側なんで
”お前がやらなければいけないと思ってること”を全部クラウドサービス側がやってくれるんだよ
>>93 いやマジ君の言っている(言わんとする事)の意味がつかめないんだがw
君の説明はどうでも良いよ。君の行動を話してくれ。
192.168.0.50が死んだとしよう、君はどうする?
お前らよくこんなニッチなものでいつまでも言い争いできるな 素直に感心するわ
>>94 サーバーの管理って何のことかわかってる?
サーバーが死んだら新しいインスタンス起動して自動的に再起動やろ
やらなくていいのはサーバーの管理だってわかってる?
FargateってEBSはマウント出来ないよな データベースとかはFargateで動かせないね EFSとか言うネットワークファイルシステムはマウント出来るが 複数マシンで同期を取るために速度は遅い コンテナに確保するリソースは0.25vCPU、0.5GB未満は選択出来ないので これ未満の能力しかいらない場合は EC2に詰め込んだほうが安い Fargate自体が同等のEC2と比べると少し高い Fargateはサーバーレスと言っても 管理の手間が少ないだけでサーバーは存在するので セキュリティパッチを当てるためにサービスの再起動が必要な場合はある
イメージのマージ機能はいつになったらサポートされんだ devcontainer作るときいちいちインストール方法調べてDockerfile書くの不便なんだが
インストール方法? 自分で開発したアプリのインストール方法もわからんのか?
そりゃチームの人が作ったら他人だろうけどそういう話じゃないだろw
いやいやそうじゃなくてオープンソースのツールとかあるだろ ネット遮断でもしてんのかお前んとこ
>>102 オープンソースのものを自分でDockerfile作る意味は?
殆どのものは公式が用意してるでしょ
>>104 公式サポートない物もいくらでもある
それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
なんでこんな基本的なこと説明してやらんといかんのだ?
いや、自分で「マージしたDockerfile」作れよ それが自動でできなくてゴネてるの?
go製ツールならバイナリ落としてくればすぐ動くが Pvthonとかのスクリプト言語を使う系や C/C++で書かれている物はそうも行かない パッケージマネージャにあれば良いが あっても古い、このパッケージもインストール必要とか面倒 glibc使ってるC/C++製ツールで動的リンクしてたら alpineにそのまま持って行っても動かない muslで再コンパイルするか イメージサイズの肥大化を覚悟でglibcを入れる必要がある
OSに最初から入ってるツールの扱いはどうするのか?とか考えたら 自動的にマージできるとか思うわけない Dockerからしたら全てただのファイルであり 依存関係も把握してないし区別もしない
結局のところ必要だったのはdockerじゃなくてより賢いパッケージマネージャだったんだよな 方向性としてはsnapなどのほうが正しかった
>>105 > それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
docker-compose使えよ
1つのコンテナに複数のサービスを入れ込もうとしているからそうなるんやで?
ベストプラクティス通り1コンテナ1サービスにすれば
既存のものをそのままつかえるのに
ベストプラクティスから外れることを自分でしておいて
自分が苦労してるのって間抜けじゃねーか?w
>>110 Dockerはパッケージマネージャーが対応してないような
自分(自社)で開発したアプリケーションを使って
自分でサービスを運営するためのパッケージマネージャーです
開発者向けのツールです。
snapはアプリ開発者がエンドユーザーにアプリケーションを
提供するためのもの。用途が全く違います。
apacheのバーチャルホストで20個のサイトを運営するのと 1つのイメージを使って1コンテナ1サイトを作るのでは どっちがメモリとCPU使用率が高いですか?
メモリとCPU使用率が重要なら、 1つのイメージを使って1コンテナ20サイトを作れば?
1コンテナ1サイトって発想が出るのもやっぱりいつもの Dockerを仮想マシンの代わりだと思ってるからなんだろうか? Dockerはアプリの代わりと考えれば、この場合apacheだとわかる 1つのapacheアプリでバーチャルホストをするのであれば Dockerの1つのapacheアプリでバーチャルホストをすればいいだけ そのバーチャルホストの設定を予め終わらせておいた カスタマイズ済みapacheを簡単にデプロできるのが Dockerのメリットなわけで
1サイトをバックエンドとフロントエンドとDBに分けても良いよ?
>>112 アホか
何でもかんでもサービスにしたら効率が悪いこともある
メインの言語でwebアプリを作って内部で別言語製のCLIツールを呼び出すようなシステム 業務システムなら普通にあるよなあ 別言語でapi鯖構築してメイン言語と別言語の2コンテナ構成にするって手もないこたないけど そのためにワザワザ別言語とそのweb apiフレームワークを習得するのはコスパ悪いだろ こういうときは1つのコンテナに複数の言語ランタイムやパッケージをまとめちゃって素直にサブプロセス呼んだほうが製造コスパがいい んでそういうときに公式イメージのマージができたら便利なんだがサポートされてないからDockerfileをワザワザ書かなきゃならん コンテナを分離する間抜けなアイデアよりは遥かに楽だけどそれでもDockerfileを書く手間は残る
>>112 ベストプラクティスは1コンテナ1責務だ
素人は1コンテナ1プロセスと間違って覚える
脱初心者を目指してるぐらいのレベルだと1コンテナ1サービスとか言い始める
docker-in-dockerとかdocker-outside-of- dockerをやれば良いんじゃね?
セキュリティについては知らん
Dockerコンテナ内からDockerを使うことについて
https://esakat.github.io/esakat-blog/posts/docker-in-docker/ Dockerだけで云々言っている人は、 オーケストレーションまで頭がまわらないだろうし、 どないしようもないと思う。 CRIだけの世界でせいぜいがんばってください。
COPY --from=some/image /source/path /dest/path Docddkerfileにこれを書いておけば some/imageという既存Dockerイメージからファイルをコピー出来るぞ 依存関係が色々あって何をコピーしたいかわからない場合は知らん
マージ君は自動でやってほしいんだからそんなもんお呼びでないだろう
>>125 マージには役に立たんわ
そもそも必要なファイルがどこにあるか探すのめんどくせぇーだろ
欲しいのはレイヤーをコピペする機能だよ
それかdocker最適化されたパッケージマネージャでもいいかな
俺たちが本当に欲しかったのってこれな FROM alpine:latest # ディストリ差異対応とか依存関係解決とか環境変数とかボリュームとかキャッシュクリアとかよしなにやってくれる素晴らしいdockerfile専用パッケージマネージャ PACKAGE openjdk:11 somevendor/somepythonclitool:latest COPY bin /myapp ENTRYPOINT /myapp/entrypoint.sh openjdkイメージとsomepythonclitoolイメージって形式でリリースしちゃったら再利用性が低すぎるんだわ
>>128 Dockerは○○専用に作るものなのに
それをなにに再利用するんだよw
>>129 世の中なんの外部依存関係もないピュアなアプリケーションだけじゃない
そしてすべての外部依存関係がネットワークを通じて呼び出せるエンドポイントを持っているわけじゃない
こんな基本的なことをなんで説明しなきゃわからないんだ
「よしなに」が仕様のツール誰が作るの
トラブったら
>>128 みたいなのに文句言われるんだろ
>>131 docker公式かツールベンダが作るんだよ当たり前だろ
ほらな、説明できない(笑) 言ってることが不明瞭の場合は聞き返してみるに限るね
はぁ…┐(´д`)┌ヤレヤレ
>>130 だから同じイメージに複数のパッケージを入れて環境変数やボリューム設定をするというユースケースが当たり前のように出てくる
そのためにはimageではなくパッケージって単位で再利用できねーと非効率的なんだよ
わかったかなボウヤ
>>136 主張を繰り返せって言ってるんじゃなくて
主張の理由を言えって言ってんの
ほんと会話ができんやつだなw
>>137 これがdockefile専用パッケージマネージャが必要な理由に見えないならもう話にならんわ
会話が通じないレベルの差があるってことだ
お前が言ってるのは、ユースケースと主張だけ 理由を言ってない
「同じイメージに複数のパッケージを入れて環境変数やボリューム設定をするというユースケース」 これはユースケース 「imageではなくパッケージって単位で再利用できねーと非効率的」 これは主張 「なぜなら、・・・・」 これが理由
「世の中なんの外部依存関係もないピュアなアプリケーションだけじゃない そしてすべての外部依存関係がネットワークを通じて呼び出せるエンドポイントを持っているわけじゃない」 これは事実 「こういう場合に、・・・」 これが理由
>>144 >>143 理由をさっさと書きましょう
>>145 書いてある
あとはお前が理解するだけだ
理解する気がないなら無駄な問答が続くだけだからもうレスしなくていいよ
バイバイ
お前が言った言葉の全てに対して「それは理由じゃない」と説明したんだがw
>>147 間違った説明だから意味ない
理解する気がないならレスするな
2回目だよ
俺の説明のどこが間違っているか言える?w 主張じゃなくて理由を言え
できたらコテ班付けてくれませんか 誰と誰の主張がぶつかってるのか日が変わるとわからないので
お前らはどのコンテナセキュリティスキャナ使ってるん?
>>149 いつものDocker原理主義者?
傍から見ていると、君が何故そんな下らない方向に持っていくのかスゲー疑問。
君が
>>98 に対する解決策を知っていれば教えれば良いだけ。知らなきゃ黙ってろよ。
俺はこの人がなぜ欲しががっているのか理解はできるよ。
解決策知らないから黙ってるけど。
確かにDockerのビルドはスタック上に積み上げてるから、その一部分だけ抜き取ってマージしたいとは思うわな。
何で「理由を言え、Dockerの本来の使い方はどうのこうの」の話を50レスも繰り返すの?
> 何で「理由を言え、Dockerの本来の使い方はどうのこうの」の話を50レスも繰り返すの? 理由を答えないからでは?
> 確かにDockerのビルドはスタック上に積み上げてるから、その一部分だけ抜き取ってマージしたいとは思うわな。 思わないな
同じファイルを使うとか同じポートを使うとか 事情がわかってないとイメージだけマージしてもしょうがのにな
>>153 理由を答えてるけど君が理解しないだけだよね?
>>136 はどこからどう読んでも
理由にしか見えないんだが?しかし別に理由はどうでも良いよ。
知ってるんなら答えろよ。知らないんなら黙っとけ。
スレの無駄だ。
そういう面倒なところを解決するためにスマートなDockerfile専用パッケージマネージャがあるといいなぁって話だろ
それは同一イメージ内でyumやaptを複数回使うのと何が違うの
>>156 じゃあ重要でない言葉をマスクしてみようか?
○○というユースケースが当たり前のように出てくる
そのためには○○できねーと非効率的なんだよ
見ての通り、理由が書いていない
環境変数の設定やインストールの手順がわからないことがあり、 イチイチ調べてDockerfile書かないといけないから、って話じゃなかったの?
>>158 Dockerfile専用パッケージマネージャは
理屈は不明、何をしてくれるかもわからないが
面倒なことを魔法のように解決してくれるのです
どうにかして~って叫ぶだけで
何かが解決するのです
>>159 もう良いよwお前は黙っとけ!w
「できねーと非効率的なんだよ」
何でこれが理由だと読めないんだよ!アスペ野郎w
サービス起動するときにあれこれ設定して起動するの面倒だなぁ ↓ Dockerfileの中で基本設定は全部済ませたで、必要最小限の 環境変数を渡すだけで起動可能だ、やったー ↓ Dockerfileの中で設定を済ませるの面倒だな Dockerfile専用パッケージマネージャがあれば解決するはずだ! ↓ Dockerfile専用パッケージマネージャ 「インストールだけしておいたで、設定は全部Dockerの外でやるんやで」 ↓ Docker使ってサービス起動するときにあれこれ設定して起動するの面倒だなぁ (本末転倒)
>>162 じゃあ同じように"理由"を言うね
「imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
これがお前の言う"理由"です
理由を言ったので納得しますよね?w
>>164 元の文章:
「imageではなくパッケージって単位で再利用できねーと非効率的なんだよ」
>これがお前の言う"理由"です
×「imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
○「imageではなくパッケージって単位で再利用できれば効率的なんだよ」
君はマジでここに粘着するより、病院に行ったほうが良い。
>>165 元の文章が間違ってるから
俺が正しい"理由"を言っただけですが?
俺はこれを"理由"とは認めてないが、
お前は"理由"だというのだから問題ないはずだが?
>>166 なるほど、君は
>>136 に、
「俺はそれを理由として認めない、お前はエスパーになって、
俺の納得いく理由を答えろ、それ以外は会話できると見なさない」
と、こう言いたかったのですね。
>>167 話の九割はDocker関係ないけどな!
>>168 納得がいくかどうかじゃなくて
"理由"そのものになってない。
もしその文章が本当に"理由"であれば、
頭に「なぜなら」や「その理由は」をくっつけて自然な文章になる
「なぜなら、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
「その理由は、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
自然な文章になってないので、これは理由ではない
これは単なる主張
文章が逆だったなw 「なぜなら、imageではなくパッケージって単位で再利用できれば効率的なんだよ」 「その理由は、imageではなくパッケージって単位で再利用できれば効率的なんだよ」
>>170 わかったから病院に行け。
明日の朝イチですぐに行け。
君は相当、重度の発達障害だぜ。
「なぜなら、imageではなくパッケージって単位で再利用できねーと非効率的なんだよ」
これが理由と読めない理由がさっぱりわからないw
他人が述べた理由を
「なぜなら、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
と勝手に書き換えるのもわからないww
実は君は宇宙人で、夏休みで日本に降り立ったのかいw?
日本語難しいよな!
>>172 なぜパッケージ単位で再利用できねーと非効率的なんですか?
>>173 なんで俺に理由を聞くの?
>>136 にレスしろよ。
彼が言っている事で、俺にも思い当たることはあるけど、正確に136が
どのようなケースを想定してこういったのかは知らない。エスパーじゃないからねw
俺は
>>137 の日本語の理解がおかしい、と指摘しているだけだが。
何か知らんけど、マージ機能なんか実現するわけないし話しても仕方なくね? 使いたいOSのパッケージマネージャーに入れてもらう方が現実的
>>174 おや?「パッケージ単位で再利用できねーと非効率的」では
理由になってないと認めたのですか?w
それが理由だろって言えばいいだろうw
コンテナの安全性をどう保証するのか社内で揉めてる 既存のノウハウが通じない事が多くてこんなんじゃ本番環境での採用に納得してもらえないよ
>>176 謎の技術で面倒なものをよきに計らってくれるものが
作れると思ってるやつに何言っても無駄だろうw
>>178 既存のノウハウで安全性を保証すればいいだけでは?
何が通じないのかいいましょう
>>180 新しい試みだから何が足りんかもわからん
訓えて
>>181 既存のノウハウがそのままつかえると言ってるんですが
今どうやってコンテナではないものの
安全性を保証してるんですか?
まずそれを答えてください
>実際、オープンソースセキュリティ企業のSnyk社が、自社のコンテナースキャン機能で最も広く普及している10個のDockerイメージを分析したところ、すべてのイメージに脆弱なシステムライブラリがあることが明らかになりました。
>その中でも群を抜いて最悪だったのはDocker社の公式のNode.jsイメージで、580もの脆弱なシステムライブラリが含まれていました。
ぐぐったらこんなんでてきた
公式イメージでこの体たらくじゃセキュリティガバガバすぎて使い物にならなくねえか?
>>182 君だったら既存の対策で↑の580の脆弱性にどうやって対応する?
あらら即レスくん黙っちゃった やっぱり既存の対策じゃ難しいのかね?
>>183 > 君だったら既存の対策で↑の580の脆弱性にどうやって対応する?
だからお前はどうやってそれに対応してるのかって聞いてるんだが
Node.jsに脆弱性がったら、アップデートするだけやろ
>>183 これはどうやって安全性を保障するか社内でもめている、って人へのレスなの?
自社で使う場合は「Docker社の公式のNode.jsイメージ」なんて使わないだろ。
「Docker社の公式のNode.jsイメージ」を作るためのDockerfileは 公開されてるんだから自分でビルドしなおせばいいだけの話 Dockerfileがあれば誰でもイメージを再現できるのが Dockerの特徴の1つ 「Docker社の公式のNode.jsイメージ」なんて手っ取り早く 開発するためのもので、実際にサービスとして運用するなら 自分でDockerfile作るでしょ?難しいって?そんなわけない Dockerを使わずに開発するときに、自分で動作環境作ってるじゃん
こうやって突き詰めていくとスゲーめんどくせえんだDockerってさ 普通に仮想マシン使えばいいんだよ そうすりゃ全てがうまくいく
>>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使ってるの?
>>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は不要になります
どこにもこんなこと書いてない
っていうかさ、お前が書いてある証拠を出さないといけない案件だろ
>>307 >Dockerは最初からアプリを配布する他のものだって
と、どこに書いてあるのか、
と聞いているのだが?
https://www.docker.com/why-docker Containers are a standardized unit of software that allows developers to
https://www.docker.com/resources/what-container Containers and Virtual Machines Together
Containers and VMs used together provide a great deal of flexibility in deploying and managing app
コンテナと仮想マシンを一緒に 一緒に使用されるコンテナーとVMは、アプリのデプロイと管理に大きな柔軟性を提供します
ここ荒らしてるのもアンチLinuxの解無しクンじゃないのか? 荒らすのが目的だから、食いついてくるなら何でも書き込んでくるぞ。
>>309 無能でコミュ障って本当大変だな(周りの人が)
get-started:に
"Docker is a system specialized for developers to develop and distribute applications."
と書かれている場合だけ「Dockerは最初からアプリを配布する他のもの」という理解で良いかもしれないけど
そんなことは勿論書かれておらず
柔軟性: すげー複雑なアプリもコンテナ化できるんだぜ。
軽量: コンテナってホストのカーネル借りたり共有したりするから、VMと比べてシステムリソースの使い方がすげー効率的だぜ。
可搬性: きみはローカルでビルドしてクラウドでデプロイしたり、どこでも実行できるぜ。
疎結合: コンテナって自己完結してカプセル化されてるから、君はほかのものを混在させずに1つだけリプレイスとかアップグレードとかできるぜ。
スケーラブル: 君はデータセンターまたいで自動的にコンテナのレプリカを配布出来るんだぜ。
セキュア: コンテナってユーザーの設定なしで強い制約とかプロセス分離ができてるからすげーセキュアだぜ。
なんでこの記述よんで「Dockerは最初からアプリを配布する他のもの」という理解になるのか?
>>307 Docker EEはベアメタルかVMで動くものだったね。
去年の11月に売却したけど。
これでDockerはエンタープライズ市場
(クラウドでサービス展開する商用の本番機はほぼ全てだろ)
は諦めた、という事。
Dockerの終わりの始まりと書いている記事もあるね。
>>313 なんでとか俺に聞くな
Dockerは最初からアプリを配布(デプロイ)するためのものだし
お前はそのことに対して否定することを何も言ってない
お前は、違うかもしれない。な?な?としか言ってない
>>314 > Docker EEはベアメタルかVMで動くものだったね。
ベアメタルかVMでって、それ以外なんかあるの?
Docker EEじゃなくて、普通のDockerでも同じだけど
>>314 > これでDockerはエンタープライズ市場
> は諦めた、という事。
Docker社とDockerを区別しろ
会社の方針としてエンタープライズ市場を制覇するのを辞めたってことで
相変わらずDockerはエンタープライズでも使われてる
終わりの始まりというのはDocker社の話であって
Dockerはオープンソースでこれからも幅広い分野で使われる
volumeの中のmysqlのデータをバックアップ取る方法を教えてください
dockerは終わりでしょ だってこれからはpodmanだから
>319 RedHadが代替を目指して作成したもので 成功したものなんてない RedHatとCentOSとFedoraで使われる程度
>>321 まあとにかく使ってみなよ
dockerがpodmanに勝ってる部分って全くないぞ
いいえ違います。 podmanが勝ってる部分がないと podmanへの乗り換えは起きません
>>320 ありがとうございます dockerスレでpodmanの話しされてもうざいからpodmanのスレ立てましょうか?
>>323 セキュア、デーモンレス、コンパクト、podサポートとかかな
ビルダーもDockerfileより簡単で柔軟だ
dockerはpodmanのエイリアスだからここで話してもOK
いいですね。立てました。
Docker代替のpodman専用スレ (Dockerの話題禁止)
http://2chb.net/r/linux/1599897027/ >>328 ありがとうございます。
podman使いの方はご移動をお願いいたします。
>>318 は、docker上でmysql使っててバックアップが取りたかったんだよな?
でその問題の解決方法はいつものmysqldumpだったと。
じゃあ君の問題は解決したんだからもう良いじゃん。
何でpodmanなんて君の問題に関係ないネタにスレ立てとか、おせっかいやくの?
君と関係ないじゃん。
>>330 関係ない話題に参加したらいかんのか?
お前だって関係ない話題に参加しただろ。お前のそのそのレスで
>>328 しかも322とか325はpodmanをDockerと比べて云々という話題をしているのに
立てたスレは「Dockerの話題禁止」ww
それじゃ325の続きかけねーよwww
>>331 行動が不自然だと言っている。
なんでmysqlに問題を抱えるやつが自分の問題が解決した
喜ぶべきスレ立ててまでタイミングで他人を排除とか変な
行動しなきゃならんの?
って話。
>>332 podmanを消してDockerの話題だけをすればいい
>>334 全く意味のない情報になるね。
>>1 には「情報共有しましょう」と書いてるのに。
俺はその話に興味があるんだから、お前が勝手に排除するなよ。
dockerとpodmanを比較したい?
話したいなら話せば良いじゃねーか。
比較の一方がDockerならスレチでもない。
お前が興味ないだけなんだろ?じゃあ2、3日PC閉じてろよ。
話し終わってるから。
韓国「日本が~、日本が~」 日本「韓国?興味ない」
>>336 まんまお前じゃねーかw
お前「Dockerが~、Dockerが~」
ほかの皆さん「Docker?コンテナ技術の1つですね。」
www
>>338 podmanの話をしようとした人はそうだろ。
ほかにNautilus の話しようとした人も。
>>333 すいません、理解できる日本語で書き直していただけますか
>>340 何で君は自分の問題が解決した喜ぶべきタイミングで
君の問題と全く関係ない話をしている、他の人を排除しようとするの?
別にスレチって事も無いよな?
mysqlはmysqlのスレに行けよ 関係ない話されっとマジ迷惑
じゃあpodmanは別ツールですから移動してくださいね 迷惑ですよ
>>343 dockerとpodmanの比較の話をしてたはずだが?
俺は続きに興味があるんだが?
何処に優位性があるのか、思わずggちまった。
mysqlへの興味は10年前に終わった。mysqldumpとか初心者かよw
dockerはpodmanのエイリアスだぞ dockerを語るということはpodmanを語るということだ
誰もpodmanに興味が内容であっちのスレは落ちそう
Linux使え MacもWindowsも一般ユーザー向け
会社だとMacかWindowsが支給されるがLinuxは支給されない だからMacかWindowsでやったほうがいいのかなと思って
>>351 会社支給品で開発するなら普通はMacでは?
WindowsのDockerはまだこれからと言う気がする。
とはいえMacはARMに移行するから、近い将来買い替えなければならなくなる。
ARM CPUで開発して本番機はx86(Xeon)ってのも色々リスクがあるから会社の方針を変える必要があるかもね。
(本番機もArmのlinux使う検討するとか)
最近のWindowsUpdateの更新でWSLがバグってるらしいけどDockerは普通に動くの?
WSLのバグは大きな問題じゃないから ほとんど問題なく動いてる
メモリ食いつぶしたり古いカーネルAPIの互換性でクラッシュしたりするけど仕様なんだってな バグじゃないってよ WSL2ってそういうとこだよ
メモリは上限を決めれば問題ないだろ 普通の仮想マシンと同じ扱いになる そして絶賛対応中。今のWindowsはマジで改善しまくってるから どんどん使いやすくなってる
普通の仮想マシンと同じ扱いならトラブル少ない普通の仮想マシンを使うわ 改善たってもとがアレじゃいつまでかかることやら… 最終的にMicrosoft Linuxまで改善が進んだらようやっと乗り換えを検討してもいいかなってところかな
普通の仮想マシンと同じ扱いなんて書いてないよ メモリの上限は普通の仮想マシンと同じ方法でやれる それ以外は仮想マシン使うより格段に便利なんだから 仮想マシンに比べてメリットはあれど欠点はないということになる 論理的思考をしましょうね
欠点はある WSLはデフォルト設定でメモリ食いつぶす レガシーAPIコールでクラッシュ コンフィグ用のクールなUIもない カスタマイズが前提なのにカスタマイズ方法がわかりにくいというクソ仕様 普通の仮想マシンはデフォルトでいい具合にメモリが制限されている 意味不明なクラッシュもしない コンフィグ用のUIが用意されてる
はい自滅しました(笑) 仮想マシンのメリットは それだけなんです
そう だから仮想マシンなんて使わないほうがいいんだ 最初からLinuxを使うだけ Docker on WSL2 on Windowsってどんだけ無駄なレイヤー積み重ねるつもりだよ
>>362 いくらレイヤーを重ねようが、お前が作ってるわけじゃないんだから
どうせ見てないだろw
>>362 原理的にはそうなんだろうけどね。
linuxってそもそも効率的な開発できるもんなの?
excelもwinmergeもないOSで効率的な開発できるとは到底思えん。
ファイルマネージャも使いにくいしな。
同僚でlinuxを開発機にしてる人がいるけどミスが多くて、やはり効率的に仕事しているとは思えない。
>>369 何にw?
エアプなら何にでも使えて便利だよなwww
>>370 docker-vpn-browserとかあるんですよ
無知晒しちゃったねw
>>371 その程度の用途ならそもそもdockerのホストがlinuxなのかwinなのかmacなのかなんて
どうでもいいじゃんw
>>372 >開発以外の用途にdockerなんか使うのかよ?
これの答えなんだがそれすらも理解できなかったかな?
>>373 その上がDockerはWin/MacかLinux化って話だから、
そんな用途ならホストはどうだっていいよ、って話だね。
今の本番環境といえばクラウドだが クラウドはDocker対応がかなり進んでいて Dockerイメージを前提とした本番環境を構築するサービスだってある 本番環境でDockerを使うから、開発でもDockerを使う
imageを上げるだけでサイト公開できるwebサービスありませんか?
>>365 エクセルは使いみちないかな
DiffはVSCodeで見てる
作業中にいちいち外部ツール起動するのは非効率的
>>365 Excelもwinmergeも要らない。
同僚がヘタレなだけ
差分比較ツールなんか、ほかにもある。
Meldもいいし、VSCodeのDiffもいい。
Excelなんか、こだわる必要ない。
テレワークだとエクセルが遅すぎるんだよな 画像満載のブックは特にひどい
>>377 Excelは顧客との仕様確認、テスト仕様書用やな。
最も半分以上googleスプレッドシートに移行してるからだんだん存在感なくなってきてるけど。
今時のクラウドエンジニアってマジでWeb上のサービスしか使わないのね。
winmergeはディレクトリ配下全部の比較が出来るのが良いね。
同じことができるのがMacにもLinuxにもなかなか存在しない。
win10嫌いだからあれば移行するんだけど。
>>378 まあフランス人だからな。
ヘタレなのが日本語不便だからなのか本人の性格(面倒くさいことが大嫌い)
なのかLinux使ってるからなのかわからんのが何とも言えんw
でも奴の使いっぷりはイマイチだと思ったね。
Markdown等 + テーブルエディタ これでエクセルの出番はほぼ消えるよね
data visualizationならmatplotlibとかでえんちゃう
じゃあ Markdown等 + テーブルエディタ+クラウド上にある色々 これでエクセルの出番はほぼ消えるよね って言わないと駄目だよねw
ただしExcelを神エクセルとか単なるデータファイルとして使ってる場合 って言わないと駄目だろw エクセルは表計算ソフトであって 計算するために使うものだからな
可視化はmatplotlibとか使えばいいんじゃないの 1つの道具でなにもかもやろうとすると何をやっても中途半端で重いツールになる だから特定の仕事をよりうまくできる軽いツールを組み合わせるのが正解なんだ
>>391 複数の道具を使うことは論点じゃないよ
エクセルと同じことをするならviみたいな単純な機能のものでできるっていうんじゃなくて
Markdown等 + テーブルエディタ+matplotlib+クラウド上にある色々
みたいに多数の道具を使うと言わないと駄目でしょって話
SQLもあったなw Markdown等 + テーブルエディタ+matplotlib+SQL+クラウド上にある色々
>>392 多数の道具を使うとうまく行く
1つの道具で全部やろうとすると失敗する
リモコンと箸と金づちを一体化させたようなものが使いやすいと思うか?
>>394 自動車にはエアコンやカーナビが搭載されていますが?
1つに道具に、それを補う機能を搭載させると使いやすくなりますし、
関連する機能を搭載すると、更に便利になります。
重要なのは「関連する機能」ということです。
関連しない機能を搭載しても使いやすくならないという主張は的外れです。
知り合いにLinux縛りでIDEすら使わないVimmer居るけど馬鹿なんじゃないかと思う
>>395 関連しない機能を詰め込んだから使いにくいのですね
なるほど
volumeの内容をオンラインで共有する方法教えて
>>396 そいつは仕事出来る奴なの?
俺の同僚でlinux使ってて効率的に仕事出来てる奴は知らない。
一方でグーグルは正社員にlinux配ってるらしいから(goobuntu/gLinux)
出来る奴は出来るんだろうけど、winの便利ツールに対応するものが見当たらないんだよなぁ。
>>398 volumeのフォルダをsambaか何かで共有すれば良いだけでは?
httpで見たいならdocumentrootにするとか。
>>398 NASマウント
>>396 Vimは極めるとめちゃ速くなるよ
極めるまでが大変だが
まあ凡人には解らんだろうね
おれもわからん
>>397 エクセルは関連する機能を詰め込んでるので使いやすいんですよ
嘘だと思ったら、エクセル使ってる人に
エクセルを使わないでやらせてみればいいと思います。
もちろんエクセル使ってる人の大半はプログラミングできません。
>>402 へえプログラミングできない人のためのツールをプログラマが使ってるんだ
>>403 そりゃ使うだろw
電卓だってプログラミングできない人の
ためのツールだがプログラマも使う
それと同じ
dockerでexcel.applicationうごかしたいんですが動きませんなぜですか
dockerでは、起動するたびに同じ状態になるけど docker-composeでは、起動するたびに前回の状態を復元している という認識であってますか?実装そうなってるような感じなので
>>408 ぜんぜん違う。
docker-composeは、docker起動のオプションがたくさんあって
大変だからYAMLに書いておけるようにしましたってだけ
1つのYAMLで複数のdockerを起動することもできる
コンテナのなかにデータ持たせて(DBなど)新規起動と停止してるのを起動で挙動が違うのを観測して後者をそうとらえたのかもしれんね
コンテナって儚い 変更を保持できるのはボリュームをマウントしたディレクトリだけ コンテナを削除するとボリュームに加えた変更以外は全て無かったことになる
なかったことになるから嬉しいんだよ 本当に永続化したい部分が明確になって管理しやすくなる
>>411 それがプロセスってもんだよ
nginxを起動すると、nginxがメモリに読み込まれ起動する
終了したらそこまで。メモリに読み込まれたプログラムは儚く消える
変更を保存できるのはディスクのみ
これがnginxをラップしたDockerイメージでも同じこと
>>408 そりゃコンテナをdown/upで停止起動するからだろ。
stop/startで起動すればそうはならない。
普通にVMのshutdown→起動と同じように使える。
ほかの連中は何で無かった事になるのが当たり前、的なレスしてるんだ?
stopは滅多に使わない containerを止めるのはimageを更新したときが最も多い その次がnodeが故障したとき どちらにしてもcontainer内のFSは初期化される
>>415 それは単なる君の好みだろ。
docker自身はコンテナを破棄して起動するコマンドと
単に停止起動するだけのコマンドをちゃんと分けて用意している。
単に知らなかっただけでしょ。 この点もずっと前からスレの中でDockerは起動停止で中身破棄されるのが当たり前 とか間違った主張繰り返してたし。
414に書いてるのに気付かないとか どんだけ日本語不自由なの?
>>420 いや、DockerはVMと同じようには使わないから、VMと同じように使える、と言われたって、それは実質使いどころがない、と言ってるのと大差ないんだが
>>421 外国人?日本語勉強しようね。
それ以外にも情報書いてあるでしょ。
それとも先週か先々週、週明けに病院行けとか言われた人?
行ったの?
>>420 > 414に書いてるのに気付かないとか
> どんだけ日本語不自由なの?
>>414 >
>>408 > そりゃコンテナをdown/upで停止起動するからだろ。
> stop/startで起動すればそうはならない。
> 普通にVMのshutdown→起動と同じように使える。
> ほかの連中は何で無かった事になるのが当たり前、的なレスしてるんだ?
VMのshutdown→起動にしか言及してないが、それ以外の情報はどこに書いたんだ?
ひょっとして書いたという幻覚でも見たのかな?
>>423 shutdown→起動と同じように使えるよ、と言っているんだが?
>>408 が
起動するたびに前回と同じ状態に戻ると言うから、それ以外の仕組みも
用意されている、と言う話をしている筈だが?
本題と関係ない日本語の理解をここまで説明しなければ理解できない君の脳味噌ってマジでどうなってるの?
いい加減にしろよ。
> 普通にVMのshutdown→起動と同じように使える。 サービス動かないのに?
>>425 エアプの人達に説明するのって大変だな!
掲示板なんかに粘着してないで、まあ自分でやってみろよw!
>>426 知らないのか?
stopってDockerコンテナの中にあるプロセスを全部停止してるんだぞ
そこから再開してもスタートしない
>>427 そこから再開してもスタートしないというのなら、君がそういうイメージを作ったんだろう、
としか言い様が無いな。
>>427 もう一回ENTRYPOINT等で起動されるだけ
stopで止める理由がねえんだよな コンテナを一時的に止める時は、潔く破棄して、再作成するのが基本 それで済むのにあえてstopを使わなきゃいけない理由があるとしたら コンテナがイミュータブルかつ、可変部分をボリューム化していない、ということだから、明らかに設計に欠陥がある
>>430 >コンテナを一時的に止める時は、潔く破棄して、再作成するのが基本
これは、どこにそう書いてあったの?
君は何を読んでこれが、「基本」だと理解したの?
URL(若しくは書籍名)示せよ。
書いてあるかないかは関係ないわな 権威主義は思考停止、エンジニアとしての死に等しい コンテナを止める時はどんなときか?というのを自分の頭で考えればstopなんて要らないなとわかる
個人的にはdocker runは--rm付きでしかしない 永続化したいデータはボリュームに出す 基本かどうかは知らん
>>432 >stopなんて要らないなとわかる
じゃあ、なんでstopと言うコマンドは実装されたのw?
>権威主義は思考停止、エンジニアとしての死に等しい
お前はニートのニセエンジニアだろ?
ここ迄、理解に難有りの人間に給料払い続ける雇用者はそうは居らんわ。
>>434 startの対として脳停止でstopも作っちゃったんだろうな
本来は要らなかったんだけどDocker開発側も作り始めた頃はDockerを深く理解してなかった
今から再設計するならstopは消えるだろうね
>>435 なるほど
「Dockerを実装したDocker社の正社員は間違っている、
俺の方がDockerの思想を理解している」
と、こう言いたい訳ですねw
>>437 その常識は何を根拠に形成されたのか?とさっきから聞いているのだが?
君以外の誰のエンジニアの脳内にも、そんな常識とやらは存在し無いんだが。
>>439 しつけーなー君は
そんなにstopの有用性を示したいなら、君がstopの効果的な使い方挙げてみればいいよ
それができないなら、ま、そういうことだ
便利に使うのが正解 自分にとって不便なら作法に従う必要はない それを強要する権利もない
さあ一体どんな便利なstopの使い方が出てくるのかな楽しみだ まさかここまで粘着して思いつきませんでした、なんてこたないだろうけど、まさかねぇ~
>>440 エッ!?うちのチームはほぼ、start/stopしか使わないけど?
down/up使うのはSREチームから新しいImage作ったよ、と通知が来た時位だが?
だから一連の書込みにずっと違和感があるんだが?
Docker原理主義者のお前が勘違いした思想を元に非効率的な開発を一人で進めるのは一向に
構わない、俺達に被害は無いからな。ただ仕事でやってる俺達は開発効率が第一な訳よ?
1つのIssue消化するのにテストユーザー作ったりコンテナの中身を一時的に設定変更することは良くある。
そんな時にPC立ち上げる度にdown/upされたら毎回同じ作業する羽目になるし馬鹿馬鹿しいだろ?
そんな時にstopさせるだけよ。あー今日の作業終わったdocker-compose stop、
さあ今日も仕事始めよう。docker-compose start するだけの話。
次のIssue始める時に真っ更に戻したいならdown->up、それだけの話だ。
Docker原理主義者のお前が勘違いした思想をレスの間中うざく書き込まれると、まともなこちらの情報
交換の効率が悪くなるから、黙ってろって事だ。
後、知らないのなら謙虚になれよ。
>>443 あーあ、ほら
Dockerの使い方全くわかってねえのな
起動したコンテナを後から変更するなんて完全なバッドプラクティス
イミュータブルインフラストラクチャの意味を全く理解してないじゃないか
>>443 最後の段落
すげえキレイにブーメランになってて笑う
この前入れたバグ修正がアップデートで消えちゃったんですけど、助けてください~、って泣きついてくる新人並みw
>>444 >>441 の通りだね。開発中は「便利に使うのが正解」
イミュータブルインフラストラクチャは本番機で実行される時の話。
開発中は関係ない。
・・・もうね、427以降のニートで実務わかってませんっぷりの酷さは何なのw?
何度も「何をもってその理解に到達したのか?」と聞いているのに、そこはスルー。
誰かが以前「Docker使ったからと言ってイミュータブルにできるわけじゃないよ」
と言った書き込みも理解できずに、そのまま来たんだろうね。
初心者くんに教えてやるか バグの調査などで、一時的にユーザーを作りたいならDockerfileの末尾にユーザー追加のコマンドを書く、それだけだ さあ仕事を始めよう、up --buildハイ起動おしまい 一時的な変更が確定したらDockerfileをコミット コンテナに入ってコマンドうったら、ソースに残らねえから、変更が確定したあとに自分がどんなコマンドを打ってきたか思い出して、Dockerfileに書き出さなきゃならねーだろ 書き出したDockerfileが正しいか、また動作確認作業やり直しかよ こんな非効率的なバカバカしい開発フローじゃ、いつまで立っても仕事おわんねえよ
>>448 DockerfileはSREの責務だから触れないよ。
一連のDocker原理主義者のおかしな書き込みを見直して、なんとなくわかったわ。
アプリに対するステートレスなつくり、イミュータブルインフラ、永続化する場所の選定、
ログの一元管理、それらは確かに必要だけど、それは本番機を運用するときの話だ。
本番機じゃコンテナ自体がでデプロイする度に破棄されるし、いくつのreplicaで動くかわからないからね。
それと、開発中の話がゴチャになってるから、話の展開がおかしいんだね。最初に相談する人は
立場がそれぞれなのに、自分が理解したものでしか返せないから、会話がおかしくなっている
開発中は
>>441 が正義。
開発効率が高ければ、やりたい様にやれば良いし、自分のやり方を他人に強要する権利も無い。
開発者としてアプリを作るときはStatelessに作ること自体は気にかけるけど、そこで動くDockerに気を配ることは無い。
便利で軽いVMとして使いたい?全く問題ないよ。
>>449 やりたいようにやりたいってのは逃げの議論だな
stopを使うような非効率的な開発方法も、僕がそうやりたいんだからしょうがないだろ、開発効率なんて知ったことか、とそういうことだろ
>>450 ん?話の発端は
>>408 以外にも方法はあるよ、って話をしただけだが?
君の話を俺が非効率だと感じるのはウチのチームでそうしている奴が誰も居ないからだが?
開発機のコンテナだけで10個あるのにDockerfile弄って毎回コンテナの破棄→構築なんて、やってられんわ。
まるきりDocker原理主義的だし。
stopの話自体は、「起動するたびに同じ状態」以外にあるよって例を示したに過ぎない。
多分単に君が知らなかったのであろう、stopコマンドに
>>430 とか
>>440 でやたら噛み付いてきたから、
言い方が酷くなったに過ぎない。
>>451 コンテナが何個あろうが、Dockerfileとマニフェストを書いて、適用するだけ
つーか、コンテナ数が増えたら余計に、コンテナに入ってコマンド実行なんて、やってらんねえわ
それぞれのコンテナに、どんなコマンドで、どんな変更を施してきたか、把握すんの大変だろーが
そういうのもうやめよーぜ、ってんで出てきた考え方がIaaCであって、その実装の1つがDockerなんだよ
なあんで、そこまで進歩したのに、昔の非効率的なやり方に退化してんだよ
>>452 いやだから、そういう話をしたんじゃないっていってるでしょw。
非効率で退化しているというなら、Docker社にメッセージ入れてコマンド消して貰えよw
もしくは君が入社して消してしまえよwww
俺にとっちゃどうでも良い話しだし。君以外のすべての掲示板参加者にとってもそうだろうよ。
Aだけのやり方しか知らなかった人にAとBの道がある、現場で効率が高いほうを選べば良いよって話ね。
>>453 効率の悪いstopはやめようねって話ね
>>449 > DockerfileはSREの責務だから触れないよ。
お前の会社の話なんか知らんがなw
Dockerfileだけじゃなくて色んなものに制限があって
開発効率下げてるやろ?お前の会社の問題だ。
いやーコミュ障のニートって本当、大変だよな。 14:37に俺がコマンドを提示してから、この話題(コンテナの状態、起動、停止)を発展させるような 話題はゼロwwwこの間10時間。B2Bのエンジニア価格なら、五万円いってるよ。 できるエンジニアならその時点で知ってた、知ってないに関わらず 「なるほど、そんなやり方もあるんですね、教えていただいて、ありがとうございます!」 の一言で次に行く話を、顔真っ赤にしてそれは非効率だDockerの原理主義に反する! と話題を延々と繰り返す。この間わかった事実は、どうやらDocker原理主義者は 開発環境と本番環境をゴチャにして考えているようだ、という事実のみw。 ・・・誰も雇わんわな、これじゃ・・・
なるほど(笑)そんなレスの勝利宣言(笑)もあるんですね、(笑)
>>457 うちの会社のことはどうでも良いな。
開発効率を下げている、どうしよう、って話をしているものでも無いんだが?
こういう解決策もありますよって話でね。
「ソースに残らねえから、変更が確定したあとに自分がどんなコマンドを打ってきたか思い出して・・・」
ってそういう話をしているものでもない。確定するような作業なら最初からDockerfileの修正プルリク出すし。
>>460 君(なのか君達か知らんが)、に対する俺からの率直な評価だ。
受け取ってくれ。
>>459 ブーメランwww
stopが非効率的だと教えていただきありがとうございます、で終わってた話なんだがな
>>463 君が「stopが非効率的」だと考える原因は一体どこ?
>>465 自分でブーメランとか流石やなw
「Dockerfileで確定している作業なら最初からプルリク出すでしょ」といっているのに。
Docker-Composeなどでipv6を無効にする方法ってありますか?
apacheでバーチャルホストで20サイト運用するのと docker-composeで1サイト1コンテナで20サイト起動するの どっちがCPUとメモリに優しいですか?
apacheでバーチャルホストで20サイト運用するのと docker-composeで1サイト1コンテナで20サイト起動するの どっちがCPUとメモリに優しいですか?
>>471 CPUとメモリに「優しい」ってどういう意味?
少量で済む、という意味なら常識的にバーチャルホストだろ。
バーチャルホスト:OS->Apacheプロセス
コンテナ:OS->Dockerプロセス->コンテナ(薄いとはいえOS)->Apacheプロセス(名前空間で保護されているとはいえコンテナ毎に別プロセス)
独立していて他のプロセスに影響を与えない、と言う意味ならDockerだろ。
最もDockerの親プロセスが死んだら配下のコンテナも死ぬだろうけど。
20サイトを満足に動かすhttpdワーカープロセス数を確保することを考えたらそんなに得かね コントローラプロセス数は節約できるだろうが
すでにDocker関係ないなw apacheでバーチャルホストを使うのと 複数のapacheを起動した場合の話になってる
473がおかしな方向に持っていくからだろ。 CPUとメモリの話(「優しい」が消費量の事かは知らんが)しているのにプロセスの数の確保? これはhttpd.confの設定か何かの話でもしているの?
大したサイトでも無かろう 普段ほとんどアクセスないだろうし サーバーレスに移行すれば最も費用を節約できる
Docker Desktop更新 不具合なさそう?
Windowsってコマンドラインで操作できないの?
LinuxってシェルスクリプトからGUIを操作できないの?
このスレ見てるとコンテナの扱いがわからんなる dockerhubに頼ってるようじゃまだまだってことかね
>>482 スレを見るのが言けない。
>>1 だけ読んでいればいいよ。それが正しいコンテナの理解だから
自分で全部構築するならDocker使う意味ないじゃんアゼルバイジャン
>>478 githubに動かないってissue投げられまくってるから様子見するのが良いかもしれない
>>1 は「Dockerイメージ(Dockerfile)はアプリケーション開発者が作成します」
これ書いてる時点でIT業界にいない人間な事は明白だろ。
>>484 アプリをデプロイするのが楽になるという意味がありますが?
>>486 アプリを動かすのに何が必要かってのを
アプリ開発者以外が知ってるっていうの?
そういうのをわざわざ調べたり伝えたりするのが
嫌だっていういのがDockerを使う理由のひとつなんだが
Dockerを使えば動かすのに必要なものはコード(Dockerfile)に
書いて終わりですからね
>>487 アプリの開発者がimage作ることもあるけど何でそれ「だけ」を強調するの?って話なんだが?
コード(Dockerfile)に書いてインフラに渡したのならそれがスタート地点でしょ。
そもそもLBで振り分けられられる膨大な基幹システムのサブシステムでしかない
コンテナのイメージを何でイチ開発者が作るの?って話で。
全体との調整はインフラの人しか分からない。
「コンパイル通るようにDockerfile書いときましたよ」と渡せばインフラの人がそれをk8sとかecsとか
オケに乗っかるように修正する。プルリクが来れば開発者とインフラの人がレビューする。
コードがやり取りに使えるから便利ですよ、と言うなら
まあ、合っているが、頑なに「開発者がつくってインフラが動かすだけ」と強調するのは何なの?
そんな事しないよ。
> コンテナのイメージを何でイチ開発者が作るの?って話で。 > 全体との調整はインフラの人しか分からない。 全体ってなんですか? イメージを作るのは開発者で 全体との調整=インフラはイメージを動かすんですよ イメージをbuildしないって意味じゃないです。 Dockerfileを作らないという意味です。
> 「コンパイル通るようにDockerfile書いときましたよ」と渡せばインフラの人がそれをk8sとかecsとか > オケに乗っかるように修正する。プルリクが来れば開発者とインフラの人がレビューする。 しません。イメージはどこででも動きます
>全体ってなんですか?
この業界に居ない人ならではのコメントやな。
全体ってなんですか?って何ですかw?本当に分からないの??
ロードバランサって知ってる?パスベースのルーティングとか分かるの??
>しません。イメージはどこででも動きます
いや、俺たちやってるし。
そもそも動くドメイン名すら変更されかねない全体部分をロジック作る人が見たりしないし。
そもそも
>>1 もそうなら、
>>489 ,
>>490 もそうだけど、生産性を高めるためのシステムに対して
~はAが行う、と断定口調自体が俺たちの業界とは思えない。
やった方が効率が高い方がやれば良いのであって。何の為のコード化なんだ。
誰かが「便利に使うのが正義」と言った事を幾度も書き込んでくれているのに全く伝わっている様子が無い。
> ロードバランサって知ってる?パスベースのルーティングとか分かるの?? Dockerと一切関係ないですねw インフラがやることです。
>>492 ロードバランサ―のDockerイメージは
インフラの人が作ってんるんですがw
どのリクエストをどのサブシステムに振るかなんて開発者が知る訳ないでしょ。
>>1 Dockerイメージ(Dockerfile)はアプリケーション開発者が作成します
w
> ロードバランサ―のDockerイメージは > インフラの人が作ってんるんですがw なにいってんだ? 普通ロードバランサーなんてクラウドの機能使うだろ 仮に自作するにしても、なにでロードバランサー作ってるというのか ロードバランサーを開発してるんじゃなくて、Dockerでインストールしてるだけなんだろ? 何のソフト使ってるか言ってみ そういうネットワーク性能重視のものは物理・仮想マシン上にインストールするのが普通だし インフラでもDockerfile作るんです!ロードバランサー!とか言われても え?今どき自社に設置してんの?としか思わんわw
>普通ロードバランサーなんてクラウドの機能使うだろ
>
>仮に自作するにしても、なにでロードバランサー作ってるというのか
>ロードバランサーを開発してるんじゃなくて、Dockerでインストールしてるだけなんだろ?
>何のソフト使ってるか言ってみ
>
>そういうネットワーク性能重視のものは物理・仮想マシン上にインストールするのが普通だし
>インフラでもDockerfile作るんです!ロードバランサー!とか言われても
>え?今どき自社に設置してんの?としか思わんわw
>
すべてが全く違うよ。最初の1行目だけかろうじて近いけどそれがIaCで変わってきている
よく上から目線でそこまで間違った意見を自信満々に言えるもんだね。
流石
>>1 w
そもそもこの話は1が「Dockerイメージは開発者が作成する」と間違ったことを言うから、反証を示しただけなんだがw
LBの役割自体はどうでも良い。
>何のソフト使ってるか言ってみ
教えて欲しいなら「すいませんがイメージできないので具体的に何があるのか教えてください」だろ?w
俺の気分が良ければ教えてやるよw
>>ロードバランサーを開発してるんじゃなくて、Dockerでインストールしてるだけなんだろ?
因みにこの一文は、仮にそうだったとしても
>>1 の「Dockerイメージ(Dockerfile)はアプリケーション開発者が作成します」
に対する反証となっている。実際はもっと色々やるけどね。
> 俺の気分が良ければ教えてやるよw じゃあこのままでいいよ。 俺は反論してほしくない お前は反論できない 利害が一致してるw
>>497 そこはアプリをインストールしているだけならDockerを使う必要はないということです。
物理・仮想マシンに直接インストールすればいいのです。
なるほど、じゃあDockerは単体ではシステムとして運用する事は全くできず、物理か仮想マシンが フロントに立たなければ、開発機としても本番機としても全く使用できない出来損ないのシステム、 って結論で大丈夫ですね?w
Sleepからの復帰でコンテナが死ぬんだがスリープ入るときに自動的にコンテナ終了させる方法ない?
アプリ開発者はアプリ開発するだけだよ普通 ようするにJavaやJSみたいなプログラムを書く人がアプリ開発者ね Dockerfileはインフラ担当者が作るもの インフラ知識に乏しいアプリ開発者にはDockerfileを任せられない インフラ担当者はアプリ開発者が作ったソースと依存関係等の情報からDockerfileを作成する
>>502 では、アプリを動かすのに何が必要か教えて下さい。
アプリはwordpressみたいなものです。
私が開発しました(笑)
>>506 ドキュメントに間違いがあって余計な手間がかからないように
Dockerfileという動くコードで提出しました
>>507 アプリ開発者の書くDockerfileは過不足が多いのでだめ
Dockerfileを誰が書くか何てどうでも良い話題だけど 話の展開が何故そんなに頑なんだ? 一体何時から原理主義者のおかしな話を展開してるのかPart1見たらなんと 2014年じゃねーかw こんなどうでも良い話を6年も続けてるの?w 人生の無駄遣いだと思わないの?w
>>509 一人のためにおかしなことになってるね。
nodeとかcondaで恩恵感じてたとこにdocker知った衝撃は計り知れなくて。
想像だけど、あんなふうにあるべき美しい運用方法にこだわる人は法学とか語学修めた人なんじゃないかな、と。
dockerfileはエレガントでなくても動くならそれでいいじゃん、っておれは思う。
>>508 > アプリ開発者の書くDockerfileは過不足が多いのでだめ
過不足とは? いつも具体的ではな話でごまかそうとしてんなw
アプリ屋にパフォーマンスチューニングとかできねえだろw
お前の考えが最高なんだろ? なら良かったじゃん。 でもな、お前の考えを他人に押し付けんな。分かったか?
> でもな、お前の考えを他人に押し付けんな。分かったか? 今更何言ってんだかw 自己の考えの押し付け合いはこのスレの基本だろ?2014年の時点で既に同じような押付けしてる。 何かと言うとお前はDockerを理解してないとかww 最初の頃はまともなエンジニアからのレスもあったみたいだけど、今やコミュ障の粘着スレと化してるわ。
多分、書きっぷりからして、Part1の頃からお前はDockerを理解してない! とか説教してる奴と今粘着してる奴は同一人物だろうけど、 2014年-2020年と言えば、俺の取引先会社が資本金100万円で発足して、市場価値100億円になった 期間とほぼ同一。俺がここ見たのは2019年位だと思うけど、それは会社がDockerに移行しよーぜ とか言い出したからで その間、こいつは、ずーーーーーーーーと、「お前はDockerを理解してない!」とか、間違った理解で講釈 たれてたのかと思うと、慄然としたね。ゼロから生まれた会社が100億になってDocker使うようになるまでに コイツがDockerスレで役に立ったことはゼロ! 生産性もゼロ!! でも土日も休まず粘着してます! システムを高効率で動かすためのDockerに粘着して人生を非効率にしすぎると何じゃそりゃw マジで仰天したね。。。
つかpart1って俺も居ないしwww 脳内で敵の設定を作って独りで熱くなってんのまじ笑える テロリスト学校襲撃に備えてシミュレーションしてる中学生みたい
>>519 ん?じゃあ君の事を言っるんじゃ無いんじゃないの?
きみはDocker原理主義者の自覚でもあるの?
> 2014年-2020年と言えば、俺の取引先会社が資本金100万円で発足して、市場価値100億円になった > 期間とほぼ同一。 ワロタwww へぃ、彼女~、俺の友達の友達は芸能人なんだぜ~ みたいな言い草だなwww
>>512 > 過 リソース使いすぎ
> 不足 セキュリティ対策など
アプリ開発者が、リソース使いすぎで、セキュリティ不足だったら
その開発者が作るアプリは怖くて使えないなw
それをアプリ問題である、リソース使いすぎやセキュリティ不足を
インフラの力だけで解決できるって?夢見るのも大概にしろやwww
インフラがDockerfileを使って解決できる リソース使いすぎとかセキュリティ対策って マルチステージビルド等を駆使してDockerイメージのサイズを減らしました! 使ってるライブラリのバージョンが古かったのでイメージ作り直して変更しました! ぐらいなもんやろw そんなのアプリ開発者でもできるわwww
無理無理 アプリ開発者って想像以上に低レベルだからな
匿名掲示板で役立たずと書かれて即座に自分の事だと 反応できるってもの凄いな…
>>524 インフラにとっての高レベル=
マルチステージビルド等を駆使してDockerイメージのサイズを減らしました!
使ってるライブラリのバージョンが古かったのでイメージ作り直して変更しました!
低レベルすぎw
アプリ開発者じゃサーバーのパラメータ調整とかできねーだろうなぁ 与えられたフレームワークのなかで単純作業するだけだし彼ら
> アプリ開発者じゃサーバーのパラメータ調整とかできねーだろうなぁ アプリ開発者の場合、小手先のパラメータ調整ではなくて ロジックを変更することでパフォーマンスチューニングを行う
アプリ屋はロジックの変更はできてもサーバーパラメータの調整はできない それはインフラ屋の仕事 Dockerfileはそういうことも考慮して書かなきゃならなん なのでアプリ屋の出番はない アプリ屋はパッケージだけ作ってろってこった
なんでDockerfileの話でサーバーパラメータの調整が出てくるんだかw
サーバーパラメータの調整っていうのはマシンスペックや構成によって変わるもので どこでも同じように動くものを作るDockerfileの外でやるここと 完全にDockerの意味を理解してないわw
データベースのチューニングとかしたことねんだろうなぁ アプリ屋さんはJavaとかRubyとかそのへん適当に書くだけで勤まるから楽でいいよね
データベースのチューニングでDockerfileいじると思ってるんだろうな(笑) あんなの設定ファイルを注入するだけなのに
すでにDockerイメージ作成済みなのに、どうやって設定ファイルを 注入するんだ?とか言いそうだからヒントな ボリューム
公式より
https://hub.docker.com/_/mysql Using a custom MySQL configuration file
カスタムMySQL構成ファイルの使用
$ docker run --name some-mysql -v /my/custom:/etc/mysql/conf.d -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag
>>538 ビギナー向けのサンプルコードを真に受けて本番でも使っちゃうやつwww
せっかくDocker使ってんのにインスタンス1個1個べっこに設定管理してた時代に逆行してんのマジ笑える ヒントはボリューム(笑)ファーwwww
ほらな、やっぱり理解してない Dockerのコンテナはアプリを動かす環境を一体化するものであって 設定ファイルを一体化するものじゃないんだよ。(してもいいけど) なぜ公式のDockerイメージがそうなってるのかよく考えたほうがいいよ Dockerイメージ=アプリ。 アプリの中に設定を変更することがあるファイルを内蔵するか? サーバーの構成に合わせてビルドするか?って話
>>542 わかってないのは君だな
君はDockerの流儀にまったく適応できてない
古い考え方のままDockerを使おうとしてる
正解はこれだ
・設定はイメージに埋め込む
・構成によってビルド後に可変にしたいものはコマンドライン引数、環境変数などを通じて変更できるようにエントリポイント、あるいはアプリ自体に細工する
これ、脱初心者を目指すなら必須の知識だから君も覚えておくといい
>>543 はい、そうやって作るからチューニングでDockerfileをいじることはないんです。
>>544 設定を埋め込むものエントリポイントに細工するのもDockerfileの仕事
正確にはassetを編集することが多いがそれも込でDockerfileをいじるということだ
アプリ屋「設定を注入する方法知ってるか?くくく、ヒントはボリューム」ドヤッドヤァアアアアア 上司「あー新人くん、データ保存領域以外は全てステートレスに作れってDocker入門コースで教えたよね。作り直して」 アプリ屋「あっ、ハイ…(´・ω・`)」
公式より
https://hub.docker.com/_/mysql Using a custom MySQL configuration file
カスタムMySQL構成ファイルの使用
$ docker run --name some-mysql -v /my/custom:/etc/mysql/conf.d -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag
新人「Dockerfileイジってチューニングやー」 上司「設定外出ししといたから、それいじってってな」 新人「あっ、ハイ…(´・ω・`)」
Dockerfileでデータベースのチューニング? なんだデータベースの設定変えてビルドし直すだけかよw Dockerfileイジってねーじゃんwww
もう邪魔だから隔離スレ建ててそこでやってくれない?
気が触れてるな。 こいつと同じ会社でなくて良かった。 こいつの同僚はこいつと同じなのだろうか。それとも、こいつだけ…
docker exec あとのコマンドを補完できるライブラリとかプラグインってありますか?
DockerfileのLinterはありますが docker-compose.ymlのLinterってありませんか?
docker-compose なんかローカルでのテストくらいにしか使わないのにLintもクソもないでしょ あえてやるとしたら docker-compose.yml があったらテスト用だ本番とは違うとワーニング出すくらいだろうな
k8sよりcomposeのほうが簡単でいい swarmでいいじゃん
設定ファイルが多少簡単だろうと、まともなマネージドサービスがない時点で難易度MAXなのです
fargateは? 最近docker comoose対応したよね
Fluent Bit supports Amazon S3 as a destination to route container logs Posted On: Oct 14, 2020 Customers using container services including Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Services (EKS), or self-managed Kubernetes can now send their container logs to Amazon Simple Storage Service (Amazon S3) using the Fluent Bit log router. Fluent Bit allows customers to route container logs to various AWS and partner monitoring solutions including Amazon CloudWatch, Amazon Kinesis, Datadog, Splunk, and now Amazon S3. Amazon ECS customers can use the FireLens interface in their task definition to configure Fluent Bit to send logs to Amazon S3. Once you deploy your task definition, it will automatically start routing logs. Customers using containers on Amazon EKS or self-managed Kubernetes clusters can now route container logs to Amazon S3 by installing Fluent Bit as a DaemonSet. To get started see a FireLens example to route logs to Amazon S3 here, the Fluent Bit release notes here, and the Fluent Bit documentation here.
大切なパスワードを保存したイメージを間違ってdokerhubにうpしちゃったらどうなるの
どうやったらそんなミスをするのかって悩むレベルだなw
dockerの理念的に 1アプリ1イメージ 使い終わったらコンテナ削除する ってことらしいですが 開発環境の場合、毎回コンテナ削除してたら編集データとかリセットしませんか・・? データやら設定ファイルだけはホストに保存するってことでしょうか?
>>570 dockerイメージ=プログラム(exeファイル)と考えればいいんだよ。
exeファイルの中に消えたらいけないデータを保存するかい?しないだろ?
つまり保存するデータはdockerイメージの外に保存するんだよ。
それがボリューム。ボリュームっていうのはdockerイメージを起動するときに割り当てる。
例えば任意のディレクトリをボリュームとして使うことができる。
exeファイルを実行するときにデータディレクトリを指定しているようなもんだ
こうやってdockerイメージの外のリソースを起動時に割り当てることで
dockerイメージ内部からはどこで動かしても同じように見えるようになるわけ
ちなみにデータと設定ファイル(アプリ実行中に保存しないもの)は別な。
設定ファイルはdockerイメージに埋め込んでいい(場合によっては外に出すこともある)
>>571 >dockerイメージ=プログラム(exeファイル)と
なるほどそういうことなんですね
>任意のディレクトリをボリュームとして使うことができる。
容量に余裕のあるHDDを指定して永続的に保存なんてこともできるのですね
アプリの設定を変えたあとその設定も他の環境でも共有したいとなると
イメージまるごと共有するか
クラウドに設定を保存するとか
ですかね
(chromeブラウザとかだとログインすればすぐ同期されていい感じなのですが)
ありがとうございました
そんなゴリゴリに使い倒すつもりはないからホストPCのシステムディスクって250GB(SSD)もあれば十分だよね・・?
Docker Hub Image Retention Policy Delayed, Subscription Updates
https://www.docker.com/blog/docker-hub-image-retention-policy-delayed-and-subscription-updates/ Docker Hubのイメージ削除は2021年半ばまで延期するってよ・・・
リソース消費量ベースのサブスクリプションにどう対応したら良いかとか
そもそも現在のリソース消費量は?とかよく分からないからってフィードバックが寄せられたっぽい
dockerhubの方針はよくわからないからgithubでいいや
imageを共有すること自体がないから docker-compose.ymlの共有はするけど
イメージ作成したときにダウンロードしてきたイメージはどこに保存されているの? イメージ作成前後でボリュームのサイズ調べてもサイズが増減しない・・見間違えてるだけかな
最初にイメージの格納場所のサイズを設定するだろ。 ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.rawとか。 docker system df -v で確認。
Ready for pull rate limits? Docker outlines 'next chapter' as Google tells customers how to dodge subscriptions
https://www.theregister.com/2020/10/28/docker_pull_rate_limit_1_november/ The issue is worse for users of private GKE clusters since "all image pulls will be routed via a single NAT gateway".
Winser warned that "any service that relies on container images may be affected, including Cloud Build, Cloud Run, App Engine etc."
11月からNATゲートウェイ経由かつ匿名ユーザーだと
全くpull出来なくなる感じ?
ヤバくね?
必要なイメージをプライベートレジストリに確保するだけ
https://labs.play-with-docker.com/ でボリュームのマウントがうまく行かない
$ cat test.txt
$ docker run -it -v /my/:/var/my ubuntu
コンテナの端末に入って/var/myに移動してもtest.txt無し
ローカルのPCでは成功したのになあ
補足 test.txtはmyディレクトリに作ってある
たぶん/my/のパスが間違ってるってことだよね ほんとは /なんたら/かんたら/うんたら/my ってパスなんだろうけど
改めてやってみたら /my:/var/my じゃなく /root/my: でやったらできた!
python使いたいだけなのに886MBって重くない?
alpineベースのPythonは扱いが難しい 特にCライブラリを使うパッケージが必要なプログラムの場合、ソースからビルドされて遅かったり alpineにコンパイル済みのがあってもバージョンが古かったり たまにglibcとmuslの違いから起きる互換性の問題がある alpineよりslimの方がオヌヌメ alpineよりは大きいがまだ小さめ
python:3.7-slim で-alpineとか-slimつけるだけでいけた㌧
つけるだけでいけたの前にdocker-hubくらい見ようよ
ん dockerhubみたら python:<version>-slim って書いてあったよ
Docker Hubを見るのも当然だし、大元のDovkerfileを読もうよ。
謎の現象に苦しんでいます。 CentOS 7で、yumでdockerを導入しました。 docker volume creteで、vol_etcと、vol_varを作成し、docker runのオプションで、次のようにボリュームを指定のディレクトリにマウントしました。 --mount source=vol_etc,target=/etc --mount source=vol_var,target=/var このコンテナはimageから起動しているので、オリジナルの/etcと/varとが、それぞれボリュームにコピーされるはずです。 オリジナル/etcの内容は全てボリュームにコピーされたようです。 しかし、/varの一部のディレクトリの内容が、なぜかボリュームにコピーされません。 そのため、そのディレクトリの内容のみ空っぽになってしまいます。 (具体的には、/var/spool/hylafaxというディレクトリが空になります。/var/spool/の他のサブディレクトリについては中身がコピーされています。) 念の為、ボリュームをマウントせずにコンテナを起動すると、問題のディレクトリも中身が入っていることが確認されます。 原因として何が考えられるでしょうか。お手上げ状態です。
>>594 自己レスです。
オリジナルの/var/spool/hylafax 内に、pipeファイルがあります。
prw------- 1 uucp uucp 0 Sep 19 2018 FIFO
これが原因で、ボリュームにサブディレクトリも含めてコピーがされない可能性はあるでしょうか。
pipeを削除したイメージを作ってやってみれば原因かどうかわかるんじゃないの
>>594 基本的な話として、
ホストの/etcや/varをDockerコンテナの中にマウントしてはいけません。
厳禁といってもいいレベルでダメです
/etc や /var 以下の必要なものだけをマウントする場合はギリOKです。 そのDockerイメージは何の機能をコンテナ化したものですか? その機能に必要なものだけをマウントしてください
ついでに言っておくと/etcや/varなんかをDockerコンテナに 割り当てたりなんかしたら最悪ホストシステムが破壊されます。
>>594 >― mount source=vol_etc,target=/etc --mount source=vol_var,target=/var
なんで、こうするのか、理解に苦しむわ…。
とくに、 /var をなぜVolumeにする?
意味がわからない。
Dockerを仮想マシンか何かだと思ってるんだろ /etcや/varを共有してDockerコンテナの中で作業しようとしてる
仮想マシンでvar とかetcの共有なんてしないけどね。
だから仮想マシンとしてログイン(?)して使いたいけど /etcや/varを共有したいって思ったんでしょ? アプリ専用コンテナとして考えれば 必要なものだけを共有するという発想になる そんな広い範囲のディレクトリを参照するってことは そのコンテナでいろんな作業をしたいってことだろう /etcが見れればいろんなアプリ何も設定しなくても動くと勘違いしちゃうもんねw
もうめちゃくちゃだなこいつ 質問者はホストと共有するなんて言ってねえし
>>594 Dockerのmountとかvolumeってのは、システムの可変の部分を定義することね。
/var/www/html 配下をマウントして、中身はプライベートなgithub/gitlabとかからpullするとか。
或いは/etc/nginx/conf.d配下だけをマウントして独自の定義ファイル置くとか。
例えホストと同等のゲストを作りたいと思ったとしてもホストのetcとゲスト(コンテナ)のetc全く別物w
/etc/とか/var/直下をゲストがマウントしたいとか、多分Dockerの作者も仰天の利用方法だと思うわ。
こいつvolumeとbind mountの区別ついてなさそうだな
DOCKER_CONTENT_TRUSTって設定するべきでしょうか?
DockerfileでRUNするたびにdocker imagesの一覧が増えていくんだけどなんで
Use GitHub Actions to deploy your application to IBM Cloud Kubernetes Service
ダウンロード&関連動画>> VIDEO >>611 Dockerコンテナやイメージがなんであるか理解してください。
それでも分からなければ、Docker社にお問い合わせください。
>>601 使用するアプリが、/var/spool/app以下に設定ファイルをいろいろと自動作成するんですよ。
それから/var/spoolは、postfixも作業領域を持つので、
varまるごとボリューム化しておけば便利だと思いました。
>>605 そのとおりです。
ボリュームを作成した上で、コンテナ内の/etc/と、/var/spoolを書き出して、
データ永続化しようとしているわけです。
>>596 pipeのない/var/spool/hylafax/etcにボリュームをマウントすると、
きちんとコンテナ内容物がボリュームにコピーされました。
おそらく、pipeが原因だと思います。
>>604 ぜんぜん違います。
>>605 さんの言うとおりです。
>>598 コンテナのディレクトリにマウントしているのは、
docker volumeです。
ホストの内容ではありません。
コンテナをprivilegeで動作させて、sshログインできるように設定しました。 リモートでコンテナ内に入ってから、yumで必要なパッケージを導入して、 アプリ環境を整えました。その後、commitしてイメージに固めました。 /etcや、/var/spoolは、コンテナ内での作業内容が保存されるので、 永続化のためにボリュームに切り出しておきます。 こんな使い方便利すぎて、どこが悪い?
>>622 メモリ食うから仮想マシンは無理
>>621 Dockerのボリュームとか、イメージとか、
ネットワークとか、便利なのでなあ。
LXCは古い技術でしょ。やりたいことができなかったらと思うとわざわざ使う気になれないなあ。
>>621 CentOS7イメージだとprivilegeコンテナにすれば仮想マシンぽく運用できた。
でも、CentOS6イメージだとそういうわけには行かなかった。
こういう場合には、LXCというのを使うのが良いのかなと思っています。
Dockerのマウント3種類についてわかったことをまとめる
https://qiita.com/y518gaku/items/456f34c317a65a9dae86 Volumes、bind mounts、tmpfs mounts について
ホストディレクトリをコンテナにマウントする場合も、Dockerボリュームを複数コンテナで共有する場合も、排他同時アクセス機能はないんでしょ? それができたら、ファイルサーバ機能を別コンテナに切り分けたりできるのになあ。
誰かDocker Certified Associate受けたことある人おらん? 英語あんまり自信ないんだが、問題文の英語どのくらいの難易度か教えて欲しい
>>620 便利なんだろうけどIaaCとは全然違うような?
メモリ、ストレージは節約できるだろうけどインフラの構築手順をコード化
して共有するという、コンテナ化の元の理念は死んでる気がする。
別に原理主義ではないけどな。属人化の部分が解消されない気はする。
Linuxのシェル変数$USERを Dockerfileの中でのみ使う方法を教えてください ${USER}とか$USERでは取れませんでした ARG USER=$USER とか ARG USER=${USER} もだめでした
>>629 そもそもここで使いたいと期待するUSER変数がdocker buildを実行するホスト側
のユーザーなのか、コンテナ側なのか分からないんだが・・・
そういうこと。仮想マシンがあるのに わざわざDockerでやる必要がない
DockerはDockerの目的にために利用するのがいい
>>620 あと、この使い方は最初の一発目位は良いけど、運用が進むとそのうちexportされたetcやvarに
依存するようになって、ホストAで動いていたものがホストBでpullすると動かないとか、
コンテナの最大のウリだった可搬性も消えてなくなる気がする。
・・・まあ、VMで運用してメモリ食うことが問題なら、メモリ増やすことが解決策であって
privilegeにしてシステム全体をリスクに晒してまでコンテナ化して解決しよう、というのは
ちょっと理解し難いな。
>>628 >インフラの構築手順をコード化して共有するという、コンテナ化の元の理念
コード化するということは、意図したとおりにエラーなく進行するかいわばデバッグが必要になると思う。
おっしゃるとおりそれを共有するなら一回のデバッグの努力に意義があるけど、
自分でコンテナとそのイメージを構築するだけなら、
sshログインしてコンテナ内で直接構築作業すれば楽に思う。
共有しない構築手順のコード作成は労力がめんどうくさくなる。
>>636 >運用が進むとそのうちexportされたetcやvarに依存するようになって、ホストAで動いていたものがホストBでpullすると動かない
運用が進む前から、最初から、ボリュームに逃したetcやvarに依存しているよ。
もちろん、別のホストでコンテナを動作させるには、そのコンテナのイメージと、ボリューム内容、そしてrunするためのワンライナーが必要になる。
それでも、ホストマシンに直にシステム構築するよりもはるかに可搬性が高いと思う。
万人向けに共有する場合であればおっしゃるとおり、可搬性は悪いと言えると思うけどね。
コンテナを削除しても残り続けるボリュームという概念が存在するとは、
Dockerはボリュームに逃した内容(etc,varなど)に依存するコンテナがあっても仕方ないと考えているのではないかと思う。
>>633 >>634 Dockerの原理主義ってどうして多いんだろう
仮想マシンも、LCXも、Dockerコンテナに劣るところがたくさんある。
LCXはコンテナの削除などの扱いがディスクコピーにかかる時間を要するために非常に遅いらしい。
>>636 >運用が進む
運用が進むとはいっても、最初に構築したコンテナをイメージに固めるよ。
ただ、アプリのためのコンフィグファイルはコンテナのetcやvarなどに保存されるので、
その書き換えを目的としてそれらのディレクトリはボリュームに逃がしている。
etc全体とか、var全体にするよりも、もっと局所に留めるのが良いかもしれないけどね。
以後は、そのイメージからrunするようにする。
>>628 さんのいうような構築手順はコード化していないけど、
構築されたアプリケーションはイメージという形で維持しつづけるよ。
IaC全くしてないレガシーなPHPのシステムをDocker+ECSに移行なら昔やった でも、本番でバインドマウントしてるのはアップロードされたファイルだけだな 設定は環境変数から取得するようにして アップロードされたファイルなど一部だけをバインドマウント経由でEFSに保存する 他は全てnginxやphpのイメージに予め入れておく ログは標準出力経由で全てコンテナのログへ DBは元から別サーバー ローカル開発環境ではUnisonでphpファイルを同期 開発機のphp入ってるディレクトリを丸ごとマウントでも良いか、このシステムは肥大化してて遅いのでUnisonを使用
俺は横着なのでDockerfileが構築手順書がわりになる方が便利 それがなけりゃlxc使う(かつては使ってた) docker runも--rm付けて毎回クリーンに起動するのが性に合う 無論ログやdbファイルはボリュームで外部化するけど
>>626 直接マウントするのはハードウェア1つにつきコンテナ1つだけ
マウントしてるコンテナが他のコンテナにサービスとしてファイルアクセスを提供する
排他制御とかもその1つのコンテナが全部引き受ける
>>636 dockerに限らずIasCって必ずしもコストパフォーマンスがいいとも限らんからな
自動化の制御が複雑になるなら手作業で設定してコミットしちゃったほうが簡単だって考え方は十分ありだと思うよ
IasCに疲弊してる企業が、よくよく考えたら本当に欲しかったものはサーバーの状態をexp impする機能だった
>>643 ホストディレクトリをマウントしているコンテナが、
他のコンテナにサービスとしてファイルアクセスを提供するには、
XFSとか、Sambaとか、排他制御ができるというオンラインファイル共有サービスを公開するということですか。
なるほど、じゃあ、ボリュームをマウントしたコンテナが、
それらの共有サービスを公開すれば、他のコンテナでもボリューム内容を共有できますね。
>>644 >IasCに疲弊してる企業
Docker原理主義者の言うことを鵜呑みにしたのかしら
アプリの設定ファイル作成をコード化するなんて頭おかしいとすら思えてしまった。
>>645 オンライン共有サービス? ストレージサービスとかいう名前でいいだろw
アプリ用コンテナとデータベース用コンテナは分けて
それぞれコンテナ=1サービスにしろっていうのはそういうこと
>>646 それはあなたの感想であって、意見や主張は何も含まれてないですね
最初からDocker前提で書いてればそんな難しくはない レガシーなシステムを大量に抱えてたら大変
>>647 でも、データベースの場合は、SQLコマンドのやり取りだけなので、データベースのデータファイルを直接オンラインストレージサービスで共有する必要はないよな。
排他制御を行うためにストレージサービス(XFS, samba)を使う場合は、ファイルレベルでの取り扱いが必要な場合だけだよね。
レガシーの移行はいっぺんにやろうとするな VM、LXC、systemdコンテナ、Ansible、Chefなどを使って段階的に移行すべし そもそもdockerに移行する意味があるのかはよく考えたほうがいい
>>647 でも、そもそもどうしてコンテナには1サービスしかおいたら駄目なのか?
例えば、名前解決させるのにdnsmasqデーモンが別途必要だとすると、これで複数サービスになってしまう。
アプリケーションという概念は、様々なサービスの組み合わせが本質だから、可搬性を考えても、それらをワンコンテナに組み込むのが自然だと思う。
即ち、データベースとwebサービスは同一コンテナにしてもよいでしょということになる。
>>647 ストレージサービスだと、iSCSIも含んでしまう。
排他制御ができるファイル単位サービスということで、オンライン共有サービスと言った。
>>626 ホストの同一ディレクトリを複数コンテナでマウントするだけでしょ
排他もかかるよ
>>652 その考え方で概ね正しいよ
好例としてGitlabのオフィシャルコンテナも1コンテナにすべてのサービスを詰め込んで1コンテナ:マルチサービスで動かしている
そして内部的な構成管理ツールとしてChefを使っている
これは1コンテナ:1プロセスという無意味なプラクティスには反するが現実として非常にうまくいってる
ただしこの構成だと特定のコンテキストやレイヤーを抜き出してそれだけスケールアウトするのが難しくなる
デメリットはせいぜいそれぐらいしかない
よく言われるのは1プロセスじゃなく1サービスだろ WebとDBで完結して1サービスと見なせるなら分ける必要ないよ Webを複数にして負荷分散等する予定があるとか DBをデータマート的に多目的に使う奈良分けた方が柔軟だろうが
mysqlとかphpmyadminとか既存のDockerイメージあるじゃん? なのにわざわざ苦労して手動インストールして 1つの複雑なDockerイメージにする理由がない
>>652 > 即ち、データベースとwebサービスは同一コンテナにしてもよいでしょということになる。
する理由がない
複数コンテナを結合できるのに、一体化させる理由がないんだよね
複数コンテナをつなげるのは簡単だが、一つになってるものは分離できない
・複数のコンテナをオーケストレーションしないと使えないサービス ・コンテナ1個動かせばOKなサービス どっちが楽なのかは自明だろ
更に既存資産があれば作るのも楽々だ わざわざ労力をかけてDockerfileに書き直す? ハァト…無駄な努力
>>659 docker -composeも使えない猿未満の方?
DBは本番だと別サーバーな事も多い メインのDockerイメージに含まれてても容量が大きくなって邪魔なだけ DBは自分で用意するから余計なお節介はやめろ DBだけAWS RDS使いたければ、 元から別コンテナだったら本番で構成に含めなければ済む話 なぜsupervisordとか使って複雑にする必要がある?
流行ってるからでぇ~すwww たいがいこんなもんだろ
>>661 なぜ使える使えないという個人のスキルの話に脱線するのか意味不明だよ君
dockercomposeを使わなくても簡単に動かせるならそちらのほうがいい
より簡単な方はどっちなのか?
答えは誰でもわかる、単一コンテナのほうが簡単
>>662 ケースバイケース
既存資産があるなら1つにまとめてしまったほうが楽な場合がある
Gitlabのように戦略的に単一コンテナを選ぶ場合だってある
何でもかんでも分割すりゃいいってもんじゃない
>>664 論理的じゃない
簡単に動かせるならそちらのほうがいい・・・とは限らないだろ
>>665 分割したほうが再利用しやすいという話だ
>>666 いやいや
同じ機能が手に入るなら簡単であればあるほどいい
難しい構成が許されるのはそれに見合う目的が必要
つまりデフォルトは限りなくシンプルに簡単に
細かくチューンナップしたいなら難しい構成を許可する
という順番がある
最初から難しい構成を押し付けるのはクソ製品
> 同じ機能が手に入るなら簡単であればあるほどいい 自分で答え言っちゃってるわなw 「同じ機能が手に入らない」ので 言ってることが論理的ではない
>>667 そうとも限らない
Gitlabコンテナは世界中で再利用されている
再利用するのにまったく困ることがない
もし仮にGitlabコンテナを構成するサービスが別のコンテナになっていたらオーケストレーション構成を考えるのが面倒で再利用に余計な手間がかかってしまう
× Gitlabコンテナは世界中で再利用されている ○ GitLabサービスは世界中で利用されている 一番簡単なのは GitLabサービスなのだ
そらしてないなぁ データベースが一体化していれば GitLabサービスの運営は大変だろう
Gitlabは本当によくできている デフォルトでは単一コンテナで最小のパラメーター設定だけで動かせるように作られてる その上で内部サービスをオミットして別のコンテナに分割することもできる そうする必要もないのにデフォルトの構成を複雑化させたがるバカはGitlabコンテナを見習ってほしい
>>674 そらしてる
今はGitlabコンテナの話をしてる
Gitlab.comのサービスの話はしてない
だから大抵の人にとって一番簡単なのはGitLabサービスを使うことだろ それに対してデータベースを別でバックアップしておきたいって人にとっては データベースは分離されていたほうがいいし
>>654 ボリュームを複数コンテナでマウントするだけでは排他制御されない。
ホストディレクトリをコンテナにマウントしても同様に排他制御はかからないのではないか
GitLabは全部一緒くたになってるから 間違ってコンテナを消してしまうとデータまで消えてしまう データのバックアップも大変 安心して運用なんてできないよ
>>677 またトンチンカンなことを
Gitlabサービスを使う話はしてない
コンテナの構成として1コンテナマルチサービスの是非を議論しているのにマネージドサービスと比較してどうすんだよ
本当に意味不明だよ君
今の話の大前提は「DockerでGitlabをセルフホストする」ことだ
マネージドサービスの話がしたいならスレ違いだからさっさと別のスレにいけ
>>654 排他制御の意味が違ってる。
例えばMySQLを2つ起動したとして、同じディレクトリを
参照していたらデータが壊れるだろ
ファイルは壊れなくてもデータが壊れる
github使わずにgitlab使うのは自社サーバで運用したいケースが多いんじゃね マイクロソフト資本を嫌悪したケースもあるかも知らんが あとデータベースのバックアップは基本的にコンテナやボリューム単位ではなくて データベース純正のバックアップ手段使うケースが多いと思うよ
>>681 > 今の話の大前提は「DockerでGitlabをセルフホストする」ことだ
ほらなw また条件つけた。
つまりこいつにとっての「使いやすい」の基準は
「DockerでGitlabをセルフホストする」場合の話であって
誰かのためにサービスを運営する(つまりGitLabサービス)のようなものには
当てはまらないということだ
開発者なら「誰かのためにサービスを運営する」だろ?
>>680 間違って消しちゃたら困るのは纏めてようが分けてようが同じ
バックアップはgitlabのコマンドラインツールを使う方法、ボリュームをバックアップする方法がサポートされている
いずれの場合も、対象が1つのコンテナにまとまってるから簡単にバックアップできる
もし、これが複数のコンテナに分量外していたら、それぞれのコンテナについてバックアップを考えなければならないので大変だ
> バックアップはgitlabのコマンドラインツールを使う方法、ボリュームをバックアップする方法がサポートされている はいそれなw 「一つにまとめたほうがいい」という方針の結果がそれだよw そういう方法を自分で作らなければいけなくなるということ データベースが分離されていれば、一般的なやり方がそのまま使える GitLabに依存してないからだ。しかし一つにまとめた結果そのやり方が使えなくなり そういうツールを開発しなければいけなくなった
>>684 条件を付けた?
最初からこの条件で話してたらお前がマネージドサービスとの比較などというズレまくったトピックを持ち込んできたんだろ
いい加減にしろ
>>687 お前は他人が用意したものを使うだけの話をしてるが
こちとらDockerfileを「作る側」の話をしてるんだよ
それはGitLabサービスと同じ立場だ
一つにまとめれば作るのが簡単?
GitLabのバックアップの件からも特殊なツールの開発が
必要になるってことがわかったよなw
>>686 考えが浅すぎてため息しかでない
なにが一般的な方法が使えるだよ
Gitlabの管理するデータはDBだけじゃない
リポジトリデータやその他のサービスのデータも管理してる
これらを個別に管理したら大変だよ
個別に簡単に管理できるならGitlabはわざわざバックアップコマンドを用意したりしねーよ
少しは考えろ
>>688 作る側ならより慎重に使う側の都合を考えろよ
使う側に知識と労力を期待するのは三流の開発者だ
Gitlabの開発者はdocker runさえ知ってればGitlabを動かせるように整備した
これが一流の開発者だ
ああ、使う側って自分で開発したアプリでサービスを運営するって考えがないのかw いやはや、考えが浅いなぁ
>>691 利用形態は外向けサービス運営だけじゃない
むしろサービス運営のほうが圧倒的に少数派
どんな企業でも開発用の社内システムを持ってるがサービス運営をしているとは限らない
社内システムでは導入の手軽さと運用コストがまっさきに検討される
こんなことにすら考えを巡らせられないのか?
浅い
浅すぎる
自分たちで作って自分たちだけで消費してるから不特定多数にイメージを使ってもらうという想定ができないんだろうな 閉じた世界で考えてるからとにかく浅い
GitLabの公式イメージが気に入らなければ
k8sでHelmチャート版使うか非公式の方入れたら良い
https://github.com/sameersbn/docker-gitlab 既存のPostgreSQLとかRedisを使いたい!って要望に答えられないので
こういうものが作られる当然ではある
SMTPサーバーは流石にごった煮版の方もない
こればかりは一つのコンテナ内でどうにかならないからか
別にSMTPサーバー立てたり外部サービスを利用が必要
>>632 ありがとうございます!
ちなみにもう一つ質問なんですが
シェル変数に渡せないことがあるんですが全てのシェル変数には対応できないんでしょうか?
$UIDとか
>>682 排他ロックがかかるという意味で言ってる
>>699 UIDやGIDが何ものであるか、考えてみてください。
>>701 通常ディレクトリでも、libreOfficeでファイルを開けばロックファイルが作られる。
アプリケーションレベルでのみロックが掛けられると思う。
viでも編集中のファイルは、ロックファイルが作られるよね。
Dockerボリュームとか、ファイルシステムレベルでのロックなんてそもそもなかったのではないか?
ボリュームなんてただのディレクトリでしかないのに何いってんだ カーネルを共有してるにどうやって ファイルシステムのロックを回避するっていうんだよ Dockerは仮想マシンじゃねーよアホ
>>702 > UIDやGIDが何ものであるか、考えてみてください。
ただの環境変数です。
>>654 何のアプリケーションを試してるんだから知らないが
それDockerとか関係なく複数のプロセスから同じファイルを触らせてるだけだろ?
排他制御がどうなるかは動かしてるアプリケーションの仕様による
Docker関係ない
>>704 ファイルシステムのロックってなんのこと??
>>706 ボリューム使ってコンテナ間でふを共有しても、
排他制御されないらしい
https://www.digitalocean.com/community/tutorials/how-to-share-data-between-docker-containers but there’s one critical caveat: at this time, Docker doesn’t handle file locking. If you need multiple containers writing to the volume, the applications running in those containers must be designed to write to shared data stores in order to prevent data corruption.
ファイルオープンしているときに、
別のコンテナからファイルに変更を加えられるということだよね。
コンテナは、確か、同じカーネルで動作しているけど、リソースを分けるように名前をわけているらしい。
ファイルハンドラーも分けられているに違いない。
なので、ローカルマシンで同じファイルシステムに複数プロセスがファイルにアクセスするシナリオとは異なっているのだと思う。
>>709 いや、ファイルハンドラーのくだりでおかしいこと言ってるな
勘違いしたわ。
結局、一つのカーネルがファイルシステムをとりあつかっているから、
ボリュームでコンテナ間でファイルを共有しても、
それはコンテナ使わない通常の状況において複数プロセスがファイルにアクセスできるのと同じことになるのかな。
初心者なんだけど、WindowsにDockerインストールして、DockerでCentOSのコンテナを起動、そこから、nginxとかpythonとかのコンテナを使いたいんだけど、そういう事出来るんでしょうか。 CentOSの80番に来たのをnginxのコンテナに飛ばして、更にpythonのコンテナに飛ばして処理、とか。 CentOS上にDockerをインストールして、そこからnginxのコンテナを置くとかの形になるんでしょうか。
> DockerでCentOSのコンテナを起動、そこから、nginxとかpythonとかのコンテナを使いたいんだけど、 意味不明w Dockerのコンテナ=アプリ つまり「Windowsでnginxアプリを使う」だけの話 そのnginxアプリっていうのが、内部でDockerを使ってるかもしれないし使ってないかもしれないが nginxアプリをつかつ人にとってはどうでもいいことだ
Dockerっていうのはな、アプリを作るためのものなんだよ もちろん誰かが作ったアプリを使うだけのやつも居るが 本来はアプリを開発するために使うもの 例えばお前が作ったアプリがWindows上でそのまま動くか? Linux上で動かすことを想定して作ったアプリだと動かないだろ? Dockerを使えば、そういうアプリがWindows上でも動くということ なぜならアプリを動かすのに必要なものが全てコンテナに含まれているから コンテナに含まれていないのはLinuxカーネルだけだが、そのLinuxカーネルは Docker for Windowsが提供している。(WSL2を使う場合はWindowsが提供しているLinuxカーネルを使う)
>>712 Docker in dockerかDocker outside of dockerというテクニックを使えばコンテナからコンテナを扱うことができるが
君が本当にやりたかったことはおそらくただのdocker composeだろう
いつものDockerを仮想マシンと勘違いしてるやつだろ Dockerコンテナには原則としてログインしない(デバッグのときぐらい) アプリにログインとかするか?それぐらい意味不明な行為
>>716 devcontainerを使ったことないのか
>>716 それは言い過ぎ(とうぜん、アプリにsshログインなんてしない。)
アプリを取り巻いている環境がコンテナにあるわけで、
それを調べるためにsshログインすると便利
なるほど。 つまり、全体として一つの目的を果たすアプリを構築するモノであって、細かいコンテナを結合して使うような形はあまり想定されていないと。 やる場合はdocker composeが一番イメージに近そう。 こちらの想定としては、例えばpython2の実行環境が本番で動いているとして、その周りの環境はそのままに、pythonを2から3の実行環境へと入れ替え(ここをコンテナの入れ替えをするイメージでした)して、実際に全体として動くのかと言うような形の検証が出来ればいいなと考えていました。 この場合、python3ではうまく動かないなとなれば、python2のコンテナにつなぎ直せばゴミも残らず即元通りになると思いましたので。
>>719 python2用コンテナと、
python3用コンテナを用意する。
というか、paython2も3も同一マシンに同時に導入できたんじゃ?
>>719 そういう使い方ではない
Dockerは「実際に全体として動くのか」の「全体」を作るもの
つまり「Python2を使う全体」と「Python3を使う全体」を
Dockerfileの内容を元にそれぞれ作る。
念の為。それぞれの中にはDockerは入ってないぞ。
Dockerfile(手順)を実行してDockerイメージを作るのがDockerで
さらにできたDockerイメージを動かすのがDockerだ
>>724 今やっと(多分)正確に理解出来ました。
つまり、「nginxのコンテナ」や「python2のコンテナ」の中にも、(乱暴な言い方をすれば)CentOSが入っているということですね。
>>714 を参考にすれば、kernelだけは含まれず、そこは別でDockerなりWindowsなり、ホスト側の環境に依存する形で利用される、と。
とすると、docker compose等で3306はMySQLコンテナに飛ばす、と言った話は、こちらも乱暴な言い方をすれば、WEBサーバとDBサーバが2つ立っていて、そのサーバ間で通信を行うイメージになるわけですね
>>726 試しに受けてみようかなと思ったら195ダラーに引いたw
たった55題でその値段とか冗談でしょ。
>>726 資格持ってるやつほどできなさそう
発想ゼロで創造性なさそう
外国のベンダー試験は死ぬほど実務的。 勉強して役に立たないという事は基本ない、という印象。高いけど。 ただdocker自体コンテナランタイムとしてどうよ?って気がする。 Docker swarmとか別に知りたくもないし。
前から言ってんじゃんこれからはpodmanだって dockerはレジストリとしての価値も危ぶまれてるまじオワコンよ
> これからはpodmanだって podmanになったらまた来てくれ これからはと言ってるやつの99%は外れだから
Docker は、namespace, cgroup, overlayfs を使っている。 本質は使い捨ての、immutable 仮想OS じゃないし、Docker Compose も、実システムとして使えない。 実システムは、AWS などのKubernetes
>>731 podmanになるかは知らないけどDockerが何かに置き換えられるの可能性はあるだろうね。
DockeはDockerデーモンがネットワークを奪い取っちゃうのがイマイチなところ。
run -p 80:80 と書けるのは一見便利な様でコンテナランタイムでしかない筈のDockerプロセス
が標準ポートに対する攻撃を一人で引き受けることになる。
オマケにk8sとか上位からコンテナランタイムを制御したいシステムとネットワークが干渉して
邪魔になる。
Python の環境構築なら、YouTube のキノコードの動画を参照!
【Bash】Windows Subsystem for Linux【WSL】8
http://2chb.net/r/linux/1590742701/893 play with dockerで簡易cgiローカルサーバー動かそうと思ったけど 起動はしたもののどこに接続していいのかわからない $ vim index.html $ mkdir cgi-bin $ vim cgi-bin/sample.py $ docker pull python:3.7-slim # $ docker images $ docker run -itd -v /root:/var/www/html [イメージID] bash # $ docker ps -a $ docker exec -it [コンテナID] bash コンテナ内bash $ cd var/www/html $ python -m http.server --cgi 8000 これで一応サーバーは動いたっぽいものの play-with-dockerのOPEN PORTボタンからアクセスしてもページが無かった (自分のPCからだとコンテナに割り当てられたローカルホストのアドレスからきちんとアクセスできた)
Ruby なら、コマンドプロンプト・PowerShell から、1-liner で、
Rubyで作られた遅いウェブサーバー、WEBrick が起動する
ruby -run -e httpd . -p 8080
そのフォルダに、index.html があれば、これでブラウザからアクセスできる
http://localhost:8080 ローカル回線だけでしょ。
ひょっとして、外部からアクセスさせるの?
外部なら、AWS のKubernetes, VPC のインターネット・ゲートウェイとか
compose使ってるんだけど毎回cdするの面倒くさい ymlを登録するなりしてショートカット出来ないの?
>>737 回答がお門違いやな。"play with docker"って言ってるでしょ。
でも
>>736 のやり方じゃnginx とpythonを別々に動かしてるだけだから
アクセスは出来んわな。pythonとnginxをセットにしたイメージをdockerhubから
探すしかないんじゃね?
外部に公開するのは、 BB ルーターのポートフォワーディング・ポートマッピング・静的IP マスカレードの設定とか、 ファイアウォールのufw, netsh とか でも、素人が公開すると、すぐに乗っ取られるw ssh で、リモートログインの方が安全
nginx, python の組み合わせは、珍しい。 普通は、web サーバーと、フレームワークの組み合わせ nginx, Ruby on Rails とか、 Apache, WordPress とか
>>726 ググってみたが、資格のページ無くないか?
podman 見た感じだとわるくないんだけど、Red Hat のかじ取りというかやり方が微妙であんまり流行らないだろうなとは思う
pythonでdjangoとか使いますし nginxと組み合わせるなんて珍しいとは思いませんよ
>>734 > podmanになるかは知らないけどDockerが何かに置き換えられるの可能性はあるだろうね。
当たり前だろ。「いつまでに」って期限をつけないならいつかは置き換えられる。
Linuxだって置き換わるだろ。100年後、200年後までLinuxのままだとは思えない。
>>742 https://prod.examity.com/docker にある。アカウント作ったら入れる。トラブったらチャットの人が即座に解決してくれる。
>>745 そういう非現実的な話はしてないな。
デーモンじゃマズイ、と言っているんだからその問題が無視できくなれば
置き換わるだろ、と言うか自分たちが作ってるクラスタは置き換わってるし。
(あるバージョンからコンテナランタイムのDockerが消えた)
>>744 まあそうだよね。
nginx+pythonで珍しいとか意味が解らんね。
自分が使ったことない物をめずらしいって言ってるだけだろうから無視していいよ
>>747 だから世間がいつまでに置き換わるか言ってみ
当たるか当たらなかいかじゃなくて、お前がどれだけ
自分の説に自信と信念を持ってるかを判断してるんだよ
それとDockerはrktに置き換わるんじゃなかったっけ?w
pylay with dockerでdjango+mysqlいけたけど
ロケットのおなじみの画面が表示されなくてALLOWED_HOST=['*']にすればいけた
あとchromeだと
http:// が弾かれることに気づかず(表示できたりできなかったりするので)めちゃくちゃハマった糞が
>>731 知識は役に立たないけど、経験は役に立つということなんだろうな。
Dockerコンテナ作れるから、もう安心ということにはならないな。
また、別の新しい技術が登場する。
前の知識は役に立たない。
役に立つのは、試行錯誤や理解に必要な経験だなあ。
こういうのを結晶化なんとかというのだろう。
表面的な知識は異なれども、それを成り立たせる思想には共通するものがある。
こう考えると、特定のアプリ技術に関する資格なんて無意味だな。
IPとか、低レベルの技術はなかなか変容しないから、そのあたりの資格はあっても良いと思う。
>>753 代替ツールを流行っても居ないのに、これからはこれ!とか
言ってる奴は大概、役に立たない知識で終わっちゃうよね
ツールの使い方じゃなくて、考え方を理解してる人は、
後からでもすぐに理解できるから、焦って未熟な段階で使う必要がない
ノウハウがたまってバグがあらかた解決してからでも遅くないし
Docker, Docker Compose は、本番では使えないから、 最も重要なものは、AWS, Kubernetes Linux 財団のCloud Native Computing Foundation(CNCF)の卒業プロジェクトも。 Kubernetes, Prometheus, Envoy, CoreDNS, containerd, Fluentd
dockerの入門書にk8sも記述されていることもあるけど k8s使う場合って複数サーバが必要になりますよね?
k8sって重過ぎじゃね?
特にetcdが
minikubeも色々入れたらすぐ遅くなった
k3sだと小さなサーバー1台でも使える、データベースにsqliteとか他のも使えるらしいが
デメリットある?
sqliteはHAに対応してない
dqliteはsqliteの分散版で、HAに対応してるが実験的
と言うのは知ってる
https://rancher.com/docs/k3s/latest/en/installation/ha-embedded/ >>761 そのとおり。VMインスタンスで最小スペックだとメモリ4GBほどだが
k8sはそのうち1GBほどかっさらっていく
最小スペックのマシンは実質使い物にならなくなる
k3sはdqliteじゃなくてembedded etcdになるらしい それって軽いの?
k8sもメモリ食い過ぎだが、fluentdも酷い たかがCPUとかメモリ使用率を取得するだけで数百MBもメモリを使用する Ruby製なのが原因か知らんがC言語で作っていれば10MB程度しか食わないだろう
fluentd_v1.11使っているが2週間くらいでElasticにデータ渡さなくなる症状に悩まされているよ docker-compose restartを定期期にする必要がある
k8sとかが、いったい何をしてくれるのか全然わからない。 全然わからないから、使う気にもなれない。 概要を読んでみても、まるで遠い話をしているみたいに聞こえて、必要性を感じられない。 だから、自分は素のままでDockerコンテナ使ってますよ。 何か一つこんなことができるよ的なことってないですかね。
クラスタ組まないならcomposeでおk クラスタ組む場合も自前ならswarmのほうが何かとお手軽で安定してる composeもほとんどそのまま流用できる AWSなんかはcomposeにも対応してるから今は無理してk8sを使う必要はない
k8s は、Auto Scale, Rolling Update, blue/green deployment データセンター分離・ラック分離、多数決で意思決定 可用性・スケールアウトとか、全体の安全性が高い Terraform も良い
>>770 やっぱり、遠い話、雲の上の話
ぜんぜんぴんとこない
docker環境で開発をしている人に質問なのですが 本番環境は別にdockerfile(もしくはdocker-compose.yml)を作っていますか? 本番環境ではソースコードをイメージの中に入れたいのですが 開発環境ではソースコードはホスト側に置いて、マウントしたいです (開発中に1行書き換える度にイメージ作り直す訳にいかんし) とはいえ別ファイルにすると(ソースコードをマウントしている)開発環境では動くけど、(ソースコードをイメージの中に含んでいる)本番では動かない という可能性も出てきてしまう気がして、一般的にはどうしているのかを知りたいです
動画配信サイトとか高負荷かつ安定稼働を求められるシステムなら採用する価値はあるかもね でもなんとなくK8S使ってみたかった程度の気持ちで無意味に使ってる人も多い
>>772 開発と言っても「実機と同等の構成で動かしてみる」というのも含まれるけど
一般にソースコードを修正してデバッグしてみたいな開発作業中は
Dockerを使わないよ
今はWindowsでもWSLがあるし、Dockerを使わないで開発やテストができる
いちいちDockerの中に開発ツール(ビルドツールやらlintツールやや)
入れなくていいから一番快適だしね。
その上で開発プロセスの一環として実機に近い環境で
テストしたいときはDockerを使う
>>772 テストはイメージ作ってやるから問題ないよ
K8Sは金がふんだんに有り余ってるようなところが使うようなイメージ 金を使って広大なK8S用クラスタを組んで、必要になったらコンテナ起動するけど 普段はクラスタの中に空きがあって、その部分にも金がかかってる それでもOKな所が使ってる それともK8Sを使ってコストを最小化するような話聞いたことある?
>>772 Dockerfileは同一で、開発時はソースコードをADDしてるディレクトリに、バインドマウントしてあげるだけで良いのでは。
>>777 そう簡単な話ではない。開発用イメージには、運用用イメージに加えて
開発用のツールやライブラリを含めなければいけない
どちらにしろ、開発用イメージはそのまま運用で使うことはできない これが大前提。だから別々に作らなければいけないが それするぐらいなら開発にはDockerを使わないほうがいい 使用する言語のバージョンやライブラリを統一するのは Dockerを使わずともできる
>>778 うん、そういうケースがあるのは分かるけど、ライトなWeb開発とかだとこれで必要十分なことも多いよね。
あとは商用向けはマルチステージビルドで成果物だけ持ってくるとかできるし。
開発者の裁量で好きなように開発すればいい テストさえしっかりしてれば何も問題はない しかし好きにしろとは言ってもプロジェクトとして推奨構成をas codeで提示したほうが親切だろうな ならDockerfileとdocker-compose.ymlが最も手軽だろう
>>772 >本番環境は別にdockerfile(もしくはdocker-compose.yml)を作っていますか?
別です。
開発環境のDockerは本番機よりもっと簡略化されている
サーバー証明書もオレオレ。
あくまでも、うちのケースの話ね。
>本番環境ではソースコードをイメージの中に入れたいのですが
>開発環境ではソースコードはホスト側に置いて、マウントしたいです
それで良いんじゃないの?
開発環境はdocker-compose.override.ymlで開発担当部分のみvolumesで上書きとか。
>とはいえ別ファイルにすると(ソースコードをマウントしている)開発環境では動くけど、(ソースコードをイメージの中に含んでいる)本番では動かない
という可能性も出てきてしまう気がして..
何故、開発機の次が本番機なのさw?
テスティングやステージングは?問題があるなら、そこでわかるでしょう。
k8s は、マスターは多数決で決めるから、分散数は奇数にして、3, 5, 7 個 ラックの電源断に備えて、ラックも別々。 データセンターの災害に備えて、データセンターも別々 こんな安全性を考えるのは、大企業
Ruby on Rails の場合は、Heroku, Cloud9 が最短。 git push するだけで、デプロイ完了! 他には、CircleCI, Capistrano Chef, CookPad 製のItamae Terraform
ネットワーク分断の場合に、 どれがマスターに格上げされるかを、多数決で決める 多数決には過半数が必要だから、ミニマムで、2:1。 だから分散数は、3, 5, 7 個と奇数にしておく 2個は、1:1 になるから、過半数を取れない。 4個でも、1:3 なら過半数を取れるが、2:2 になったら過半数を取れない Raft という分散合意システムで、HashiCorp のConsul でも使っている
そろそろスレチと言う気がしてきたな。 k8sの話したいのなら、航海1日目に行けよ。
Kubernetes 航海1日目
http://2chb.net/r/linux/1553389453/ 超過疎スレなので来てやってください
>>786 奇数から1台死んだら偶数になって多数決で分断が起こるのでは?
docker pull django:latestってやるとバージョンが1なんですけど 古くないですか?
>>789 多数決と言っているのはクラスタを構成するノードに対する比率を言っているのでは?
3ノード構成で2ノード生きているなら継続するよ、と。
あと分断耐性で言っているのはネットワークなので必ずしもノードが死んでいるとは限らない様な気がする。
クライアントからノード1、2には到達できるけど、3に到達する為のルーターが障害とかね。
>>792 いえ、どうして2でもなく3でもないのかな、と。
これならdockerhubからよりもベースpythonでpipしないといけないような
>>793 django2とか3とをpullすりゃ良いんじゃね?
https://hub.docker.com/_/django DEPRECATED と大書きているだろうが。
はい非推奨は知っていたのですが オフィシャルイメージかつcopy and paste to pull this imageのプリントがそのままなので 他の方法やバージョン1でも問題がないのかと思っていました
非推奨と書いてあるのが読めて最終更新日からどれだけメンテナンスされてないか確認できたら 問題ないかどうか判断できるよね
その判断の仕方だとどちらにも取れるのでは 問題かどうかは主にpythonのバージョンに依存するような・・ 要は問答無用で1は非推奨なのか、安定版なのか みたいな
「自分の環境にとって許容範囲かどうか判断できるだろ」って意味じゃないの だからどちらとも言う必要がない
それはdjangoのほぼ全部の仕様把握してないと無理
Django のバージョンが分からないのは、おかしい。 自分で使うバージョンを決めるものだから Ruby on Rails なら、6 の本が有名著者で、6冊以上出ている。 黒田努、掌田津耶乃、パーフェクト・シリーズなど それに、5・6 の違いをまとめた本も出ている。 だから、4 は相当古いと誰でも分かる
どうして急にRoRの話しだすの... こわいんだけど
RoRの事しか知らないからだろ。 わかって無いけど会話に参加したい(デキる男感をアピールしたい) 初心者心理。
Dockerを仮想マシンのよう使う人って未だに居るんだな
べつにいいでしょ ツールが使い方を決めるんじゃなくて人が使い方を決めるんやで
仮想マシンのように使うって具体的にはどういうことなんだろ
Docker, Kubernetes は、immutable。 状態を持たない すべて破棄してから、作るのが基本。 サイボウズのkintone では毎日、破棄してから作っている AWS などを知らない香具師が、コンテナ内に状態を持とうとする。 クラウド・コンテナの機能の、区別ができない香具師 Cloud Native Computing Foundation(CNCF)の卒業プロジェクト、 Kubernetes, Prometheus, Envoy, CoreDNS, containerd, Fluentd 他には、はてなのMackerel, DataDog, Elasticsearch などを、知らない香具師。 コンテナを仮想マシンのように使うなって、延々と言われているw
ググった単語を色々並べて、頑張ってるなw 散文詩みたいで意味がさっぱり通じないw 匿名掲示板でそんなに俺できるぜ感をアピールしたいの?なんで? その心理がサッパリ分からないw
>>739 すいませんポート開くの忘れてただけだった
$ docker run -itd -v /root:/var/www/html [イメージID] bash
を
$ docker run -itd -v /root:/var/www/html -p 8000:8000 [イメージID] bash
とやればできた
が、今度はcgi-bin内にアクセスしようとするとダウンロードになってしまう
・cgi-binとcgi-bin/sample.pyのパーミッションを755
・sample.pyの一行目に#!/usr/bin/env python
・改行コードはLF
とやっても
PermissionError: [Errno 13] Permission denied: '/var/www/html/cgi-bin/sample.py'
が出てしまう
自分のホストPCでローカル環境なら大丈夫だった
あとplay with dockerでnginxを介した場合は大丈夫だった
>>810 pythonのhttpdって誰の権限で動いてるんだろう?
(分からないけど)/root/cgi-bin/ (?)に対する権限を持っているのだろうか?
結局コンテナに入ってプロセスの実行者とディレクトリの権限を確認しないと分からない気がする。
>>812 /var/www/html/cgi-bin/sample.py
のvarもwwwもhtmlもcgi-binも
全部 chmod 755したら無事
ウェブからsample.py実行できた・・
権限許可はvar/www/htmlの下のcgi-bin以下だけでいいのかと思ってた
>>813 で、誰が動かしているのか理解して、0755にしたの?
Docker compose stopでコンテナ止める時って結構時間掛かるのに OSに対してシャットダウン掛けると即時停まるんだけど これは本来保存されるべきデータが消えてる可能性ってある? サービスかなんかでシャットダウン時に自動で何かデータを書き出すような処理入れるべきなのかな?
>>815 >Docker compose stopでコンテナ止める時って結構時間掛かるのに
docker stopコマンドは10秒程度で止まるように優先度を掛けてくるから。
https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/ When you issue a docker stop command Docker will first ask nicely for the process to stop
and if it doesn't comply within 10 seconds it will forcibly kill it.
docker-compose stop --time=1 とかすれば、結構即時に近い形で止まるように見える。
動いてるコンテナの重要度は自分で把握しているだろうから、永続データ無いのなら
time=1で良いんじゃね?とはいえmysql postgresとかあるなら危ないだろうけど。
VM上で動かしたとしても、そんなに早くは落ちないだろうし。
Dockerコンテナ内のcrontab -eで、デーモンのスケジュール再起動を任せたら、 oom Killerでホストが倒れてしまった。ホストにsshログインもできない状態に陥って大変あせった。データもっていかれるかと思ったが、再起動でなんとか復帰できた。 ホストは2GB程度だが、そのコンテナ内でこのデーモンは1G程度も消費する。 デーモンの再起動のタイミングで、メモリ溢れが発生したようだ。 そこで、ホストにおいて、docker restart コンテナとするようにした。 そうすると、メモリ溢れなく、安全にコンテナごとデーモンの再起動ができたので報告しておく。
>>811 香具師/野師/野士/弥四(やし)とは。
意味や解説、類語。盛り場・縁日・祭礼などに露店を出して商売したり、
見世物などの興行をしたりする人。
また、露天商の場所割りをし、世話をする人。
的屋 (てきや) 。 - goo国語辞書
そういうことじゃないから... アスペムーブやめてほしい
>>818 コンテナ内で何のプロセス動かしてんの?
>>822 iaxmodemだけなら小さい消費だが、
それらをfaxgettyさせてhylafaxに接続すると、
5倍くらいに膨れ上がった。
コンテナ内でのサービス再起動時にメモリが溢れるってのもよくわからんが、そのサービスの再起動の動作が特殊なのかね 再起動のための停止時には一時的にメモリ使うとか? コンテナごと再起動するなら内部のサービスは通常の停止(あるいは強制停止?)+起動だろうから、メモリに問題ないのはまあわかる どっちにしろdockerというよりサービス固有の事情に見える
>>824 参考になります。
iaxmodemが始動されると、プロセスが生成されます。
その後、hylafaxを始動させて、
さらに別途faxgettyによって、両者を連結させるイメージです。(3者登場します。そのうち、iaxmodemと、faxgettyはたくさん。hylafaxとは、多対1の関係になっています。)
>>823 のように、iaxmodemだけでは専有容量は僅かなんですが、
faxgettyさせると、膨れ上がります。
faxgettyは、hylafaxの関係者なので、
hylafaxがガーベージコレクトするようです。
以前テストした結果は、hylafaxの再起動時には、直ちにfaxgettyプロセスは消滅しました。
しかし、今回の環境ではそういう風にならなかったようです。
前回の環境はCentOS6でネイティブ、今回はCentOS7でコンテナです。
iaxmodemや、hylafaxのバージョンも上がっています。
いずれにしても、デーモンの再起動が特殊です。
逆に考えて、ネイティブ環境でも他の要因で同じ問題を引き起こすなら、
コンテナ環境であってよかったと思います。
docker restart faxContainerをcrontabでコンテナの外側ホストでスケジュールすれば良いのですから。
コンテナ内部でそういうデーモンの消滅のスケジュールを組むと、イメージ化されていることからタイミングの変更が困難になるので、
せっかくの利便性を損なうと思いました。
docker restart faxContainer は素晴らしいです。
俺はどちらかといえば「Dockerコンテナは仮想マシンじゃない」方の思想に近いから コンテナごと再起動するのは普通というか自然だけど荒れるかな そもそも個別ソフトの事情でメモリ食いすぎるなら、ホストでOOM起こすくらいならコンテナにリソース制限するのがいいのでは
Linux上でchrootを仮想マシンと思うやつは、どうにかしている。
>>826 荒れるっていうか・・・・
その事に対してコダワリ持ってるのって一人だよね?
殆どの参加者は、そもそもどうでもいい話題で、そいつの書き込みに
反応するのは、そいつがなぜ、VMじゃないからどうのこうのと反発する
必要があるのか分からないから。
イスラム原理主義者に向かって暴力行為やめろよ。そもそも宗教なんて
どうだって良いだろ?と言うのと変わらない。
0番の親プロセスから連鎖的に、必要な環境(ディストリ標準体系)を組みた立てていくということを、「仮想マシン」とよんでいるだけですよね。 それに対して、例えば、helloworldバイナリを実行するだけなのが、非「仮想マシン」ということですよね。 前者は、systemctlによるコントロールができて楽です。 また、アプリを構成するデーモンに依存関係がる場合はとても楽です。 しかし、後者はそういう構成を組むのに別途考慮が必要になるのでお手軽さがなくなり、せっかのコンテナがとっつきにくくなってしまいます。 こういう認識を持っているのです。
>>829 必要な環境(ディストリ標準体系)と言いましたが、最初にcentos7をdocker ハブから引っ張ってきているので、標準体系にはならないですよね。
最初に何が入っているのか知らないけど、
docker run --privileged -d --net=mynetwork --name centos7 centos:centos7 /sbin/init
のようにすれば、いわゆる「仮想マシン」風の操作性のコンテナができます。
あとは、yumなどでパッケージを導入すれば、
systemctlで制御ができます。
--net=mynetwork に指定するネットワークは、自分で作成が必要になります。
LAN に対して、ポート開放もいらなくなります。
ipfilterで制御するだけです。
--net=ネットワーク名 を指定しないと、インターネットへの穴を開けてしまって危険。
ネットワークの知識がいるので、
これが唯一難しい点ではないかと思います。
個々のコンテナの中でsystemd動かしてrsyslogdでログ出してlogroteteまてやるとか無駄の極み 動かすプロセスは複数でもいいけど必要なものだけ動かすのがdocker的な考え方だよ systemctlに頼らず起動コマンドくらい自分で調べろ そんなにsystemd入れてinitしたいならlxcを熱烈推奨
コンテナ内でsupervisordとか動かすのはアンチパターン
>>833 ごった煮版は手軽に試したい人向けだろ
まともに使いたい人はhelmチャート版か
よそのDockerイメージ使えって事だろう
>>834 つまりマルチプロセスなら手軽に使えるコンテナが作れるわけだよね
ということはコンテナ分割と利便性はトレードオフの関係なんだよ
このことを無視してごった煮はダメだアンチパターンだとわめき散らすのは典型的な解ってない人
>>835 helmチャートとかdocker-compose.ymlで配布してくれた方がカスタムしやすい。
ログやCPU使用率も各コンテナで分かれるので見やすい
よって利便性も複数コンテナの方が上
docker-composeで試せるものが docker runで試せるようになったからって そんな楽になったとは思えない むしろ不便になってる件
ほれみろ。仮想マシンのような使い方をした結果 いつものように苦しんでるではないかw
>>836 カスタムはある程度は環境変数とかでできる
高度なカスタムが必要なら勝手に非公式で頑張れ
ほとんどの人は公式ので十分だ
オーケストレーターごとにマニフェストを用意しなきゃならんのは面倒だ
オーケストレーターを選択するのも負担になる
マルチプロセスならdocker runだけでOK
これ以上にかんたんなものはない
>>837 コンポーズだとファイルが必要だし内容の理解も必要
docker runはファイル不要で面倒なことは考えなくていい
これ以上楽なことはない
ここで仮想マシンのような使い方をしようとして 簡単に解決できない質問が出てるのが苦しんでる証拠
>>840 Dockerfileでたくさん面倒なことしてるだろ
docker-composeはyamlファイルを持ってくるだけ
Dockerfileと違って中身を理解する必要がない!(笑)
では分割コンテナでいいから質問者が求める構成を提示してみて できないならそれはマルチプロセスコンテナが悪いのではなく単純に難しい構成だったというだけだな 1日待ってあげるからどうぞ
>>843 gitlabはdockerhubからpullするだけで使えるということも知らんのか
dockerfileなんか書かんよ
>>844 論点がずれてる
単一であっても分割であっても
仮想マシンのような使い方をするのが間違ってると言ってる
>>845 docker-composeもdockerhubから勝手にpullしてくれるってことも知らんのか?
誰かが作ったdocker-compose.ymlをgitとかからpullするのが増えるだけやろ
docker-composeは、docker runだとたくさん引数を指定するのが
めんどくさいってのを解決してくれるものだ
docker runするだけ(引数がたくさんで辛いよぉ)←これを見なかったことにするな
>>847 docker composeはファイルが必要
>>848 質問者が言ってるだろ
> 818 名前:login:Penguin[sage] 投稿日:2020/11/12(木) 04:08:50.18 ID:tXLSOFMO [1/7]
> Dockerコンテナ内のcrontab -eで、デーモンのスケジュール再起動を任せたら、
> oom Killerでホストが倒れてしまった。ホストにsshログインもできない状態に陥って大変あせった。データもっていかれるかと思ったが、再起動でなんとか復帰できた。
↑これが仮想マシンのような使い方
↓これが本来のDockerの使い方
> そこで、ホストにおいて、docker restart コンテナとするようにした。
> そうすると、メモリ溢れなく、安全にコンテナごとデーモンの再起動ができたので報告しておく。
>>849 ファイルをコピーするのが難しいって話をしてんの?w
docker runで引数をたくさん指定するのと、その引数がファイルに全部書かれてるから
docker-composeするだけで起動できるのと、どっちが簡単ですかって話なんだが
docker-composeも使えない男の人って…
Linuxでdocker使ってるんですけど volumeマウントするとホスト上のroot権限のディレクトリができるのですが 対策ありますか? nginxです
>>818 そのものズバリの「?oom-kill-disable」なんつーオプションがあるらしいね。
https://knowledge.sakura.ad.jp/5118/ --memory=1024mb
コンテナにこの辺掛けたらどうなるか、興味深いところ。
ホストが死ぬなんてことはなくなるのでは。
また、仮想マシン厨が出てきたw Docker, Kubernetes は、immutable だから、状態を持ってはいけない。 サイボウズのkintone なんか毎日、破棄して作ってる Heroku 相当のPaaS、AWS Elastic Beanstalk のRuby, Docker などの基本。 OOM killer も、k8s の基本 そもそも、k8sのetcd は、OS の/etc の事
>>854 oom killerせず、スワップも貧弱なら、
oom-kill-disableすれば、「盾と鉾」の話になりそうですね。
いろいろと興味深いオプションありますね。
>>855 OOM killer も、k8s の基本 って
どういうことだろう?
OOM killer を無効にしてメモリが足りなくなったら メモリが足りなくなったプロセスが落ちるだけの話 一般的には今まさに動いてるプロセスになるだろう
k8s のLimitRange で、各Pod のCPU, メモリの使用量を制限すると、 PodがOOM killed される それで、Pod数が足りなくなるから、また再作成されて、また終了させられる
だから、仮想マシン厨がやってる事は、 OS の機能を、コンテナ内でやろうとしているだけの話 Docker, Kubernetes、 Heroku 相当のPaaS、AWS Elastic Beanstalk などに書いてある
OOM killerに殺されて転生したらPodでした
全て一つのマシンに配置する事も データベースだけ別のマシンにする事も自由自在なのがコンテナの良いところ
K8S使うまでもないんやけどコンテナで運用したいんやがどこのサービスがええのん?
>>864 一台しか使わないならdocker-composeでもよくね?
それともマネージドサービスが使いたい?
ならコントローラーが無料のサービスを選ぶとよい
Amazon ECSは無料
Azure Kubernetes Serviceも無料らしい
Google Kubernetes EngineはZonal Clusterなら一つは無料らしい
dockerコンテナ一つで終わるなら、dockerをデーモンで起動すればいいし 複数のコンテナが必要なら、docker-composeだろうな
当然、Heroku 相当のPaaS、AWS Elastic Beanstalk Docker, Ruby もある
Fargateがベスト K8Sなんて大げさなものは超大規模システムでしかメリットがない アプリをお手軽にパッケージングしてお手軽にデプロイする基盤がほしい でもDockerホストは管理したくない 大半のユーザーが求めてるモノはそれだけだ
自分でオーケストレーターをインストールするのか? k3sなら単一ノード構成でも使えるしセットアップも比較的楽 より機能の少ない物ならNomad, Docker Swarm等もあるが 使いやすいかは知らん HerokuもDocker使えるから 自分でオーケストレーターの管理したくないならありかも
Herokuはvolume使えないんだろ クソじゃん
古いプログラムソースのファイルアクセスをクラウドストレージアクセスに書き換えるのがめんどくさい なんかファイルIOをフックしてクラウドに転送する魔法ないの?
>>872 クラウドストレージが何を指してるのか分からないけど
単にホストがストレージをマウントしてDockerのvolumeか
mountで逃がせば良いんじゃね?
>>873 ホストに依存したくない
コンテナの中だけで解決できないか
コンテナにrcloneでも入れればいい 個人的にはそういうものはホストに入れるけど
dockerでボリュームマウントするとroot権限でしか編集できなくなるので面倒なのですが podmanならこの問題が解決されてますか?
それはまた別な問題だろ UID、GIDをホスト側とコンテナで合わせておくか コンテナのentrypointでボリューム内のディレクトリやファイルのUID、GIDをユーザーに設定すれば良い そうすればroot要らない
>>876 podmanの実行ユーザーのuid gidになるよ
dockerはオワコン
>>880 勝手にホストのファイルのUIDが変わったらホラーだろ
ありえねー
dockerは勝手にrootで作っちゃうからやべーのなんの
名前付きボリュームはDockerfile内にVOLUMEで指定がなければrootになる
https://github.com/docker/compose/issues/3270#issuecomment-543603959 でもディレクトリがrootでもパーミッションがworld-writableなら
書き込みはできるんじゃね?
バインドマウントはホストのUID、GIDがそのまま使われる
AWS Fargate は、Elastic Beanstalk(PaaS)のAuto Scale までも、全自動にする奴。 企業向けの究極 確かに、first choice に、Fargateを勧めている。 昔は、Elastic Beanstalkだった AWSの動画を見ると、 Lambda, コンテナ、仮想OS の並び順で、 コンテナを仮想OS のように勘違いする人が多いけど、 あくまでもコンテナは、Lambda・仮想OSの中間だと言ってる Elastic Beanstalkの図を見ると、 以下のようなOSの機能は、コンテナ外にあって、Amazonが提供している ロードバランサー・Auto Scale SNS による通知、CloudWatch による監視・アラーム Aurora などのデータベース 仮想マシン厨は、これらをすべてコンテナ内に実装しようとしている
ユーザーを、docker group に入れるのだろう。 k8s には、Namespace, Role もある Docker の欠点は、IP・Port(NAT・ポートマッピング)でアクセスするので、 ポート80などが1つのサービスに対応付けられてしまう k8sでは各Pod に、IPが割り当てられるので、 NAT無しで、異なるNode(ホスト)上のPod間通信もできる
関数で実装できるならコンテナもいらねえ クラウドなら関数、でないならコンテナ、永続層はマネージドって感じか 関数とコンテナを意識せず透過的に扱えるプラットフォームが普及したら、コンテナもオワコン
>>887 ECSならELBに登録するのが一般的な設計パターン
ロードバランサーが必要になる代わりに、空きポートがランダムに割り当てされるので、衝突することが無い
awsvpcネットワークモードにすればタスク毎に独立したIPになるが、
EC2の場合は1つのタスク毎に仮想ネットワークインタフェースが必要
>>889 Fargateは
料金がEC2より少し高い
EBSボリュームは利用出来ない
特権が必要な設定は利用不可
などの制約があるので万能ではない
ロードバランサーの存在は結局意識する必要があるのも何かね
何れにせよロードバランサは使うので問題ない ECSより無駄がないし管理コストを考えたら安い 特権は別に要らんかな 永続化はマネージドに逃がすからボリュームもイラネ Fargateが最強 Fargateならcomposeも使えるのがイイね
運用まで真面目に考えるとdockerもそんなに便利なもんじゃないね アプリ開発~デプロイは楽になるんだろうけど それって全体の2割にも満たないだろう
全体の2割が解決すれば十分じゃん アホなの? なんつーか、ハンマーで木を切断できなければ 便利なもんじゃないって言ってるみたいだw
問題は2割を多少楽にするために余計な厄介事まで持ち込んでくること
全体の2割を解決するために5割の新しい問題を持ち込んでるのが実感。
厄介事じゃなくて、技術力ないやつが切り捨てられること が正解だろ?厄介事なんてないよ
クラウドリソースを使わせたいベンダの戦略にまんまと載せられてる 今更選択肢間違いでしたとも言い出せないから苦しいなと思いつつ使い続けるしかない
マジでそれ! Dockerなんかどっか行っちまえ!
くろかわこうへい、2019/7
今から追いつくDocker講座!AWS ECSとFargateで目指せコンテナマスター!〜シリーズ1回目〜
ダウンロード&関連動画>> VIDEO 彼は年明けから、会員制のAWS の初心者向け講座を始めるらしい。
彼は、Amazon の21万円のAWSの3日コースも受講したみたい
>>900 投じた21万を広告収入で回収しようと必死やなw
くろかわのAWS 新講座のモニター受講生には、千人が殺到した。 1万円もらえるらしいけど その中から5人と、スタッフ7人を選んだみたい 彼は日本の初心者に、クラウド革命を起こしそう!
とおもったら、
>>1 に宣伝もしくはそれに準ずる投稿を禁止と書かれていない…。
ただの一般人の動画に金払うくらいならネットで十分だわ
壊れたラジオくんは動画から拾ってきた単語を並べるだけのアレだったのか... サロンの食い物にされててかわいそう
FargateはDockerイメージをキャッシュ出来ないっぽい
クソでかいイメージ動かす時は起動に時間かかるかも
ホストにDockerイメージがキャッシュされないので、
NATゲートウェイ経由でイメージをダウンロードすると起動のたびにコストがかかる
設定ミスしたECSサービスを放置することによるクラウド破産に注意
一応、ECRにイメージをミラーしてVPCエンドポイント経由で使う事で
課金を回避は可能
How we lost $800/mo with Amazon ECS Fargate - DEV
https://dev.to/raphael_jambalos/secret-costs-of-ecs-fargate-4j3b ↑は500MBのプルが2、3分おきにされる状態を1ヶ月放置して16TB分の料金を課金された人のお話
アマゾンのクラウド関係はベゾスにとって打ち出の小槌やな。 そらゲイツ抜いて世界一の金持ちにもなりますわ。
Amazon は不況の株高で、1年で5割ぐらい株価が上がっているのでは? 100兆円どころではなく、日本の総時価総額と同じ、500兆円ぐらいまで上がりそう
ファイル編集した後にイメージ消してから Docker-composeでリビルドしてイメージ作ってコンテナ立ち上げても ファイルの中身が古いまんまなんだけどどういうこっちゃ……
ボリュームマウントしてるとか 消したつもりで消してないとかだろ
CIでビルドとか時間かかる CIは最終結果を作るためにやるもので 普段使いするものではない
https://www.docker.com/blog/docker-compose-for-amazon-ecs-now-available/ docker-composeでEC2もデプロイすんの?
EC2のすべての機能が使えないLeaky Abstractionの悪寒
劣化版CloudFormation (Terraform)みたいになってるのでは?
このツールで出来ないカスタマイズがしたければTerraformとか使えってこと?
Dockerはホストに依存しないからカスタマイズなんていらないんだよね 依存してるなら開発者のスキル不足
AWS CloudFormation なら、 Terraform, Packer, Ruby 製のkumogata, chef, Cookpad 製のitamae
>>916 GPU付きインスタンスの例とか書いてるじゃん
VPCとかIAMロール、ALB、セキュリティグループの設定は流石にこれでは出来まい スポットフリートも非対応っぽい 2つのツールを使い分けるぐらいなら もう全部Terraformでよくね?
リンクされているAWSのブログを見たらIAMロールは新規で作れるようだ ツールの目的は既存のdocker-composeを出来るだけ変更せずECSで動かすことらしい 既存クラスターやロールの利用も可能だがそれだと省力化の意味が薄れるな ボリュームはEFSになるようだ 対応してないファイルシステムの機能が必要なくて 速度がEBSに劣るのを許容できれば使えると思う
>>921 なんで?コンテナでデプロイするの便利じゃん
GPUで機械学習とかやりたい人居るだろ?
>>922 デプロイ先を選ぶようなコンテナはコンテナでなくていい
NVIDIA Container Toolkitを作ったNVIDIAが馬鹿だとでも?
EC2一台で動かすようなシステムなんだけど、git pullでソースコードもdockerfile docker-composeも持ってきて、ソースコードマウントして動かして大丈夫? セキュリティ的に問題あります?
問題あるかもしれないしないかもしれない パラメータとソースコードの内容次第
AWS CodePipeline(CodeCommit/CodeDeploy) EC2 に、yum install -y ruby と書いてあるから、Ruby 製 CircleCI, Terraform → ECR と同じ
>>929 そんなことしても
面倒くさいだけで節約にならなくね
ディスクは…レイヤーの掃除しなくていいかな?その程度の差だね 面倒くさくはないよ この程度ならワンライナーsshできる K8Sよりよっぽど楽だ
定期的にdocker image pruneすれば良くね? 何日以内は残すとか指定も可能
>>928 開発中はマウントして作業してるので、そのままの構造で行きたいのと、masterにpushしてpullするだけのgitコマンドで完結するので楽かなぁと...
>>934 それでいいよ
というかターゲットマシン決まってるならまじでDockerは要らない
不要な管理対象スタックが増えるだけ
どこで動かすかわからないならdockerのほうがいいけどな
>>935 確かにそうですね
一応、本番機にはdocker入れるだけでPHPやらnodeやらは直接入れなくてビルドするだけでいいのでその辺は楽かなと思ってますが
>>936 稼働中のPHPサーバーでgit pullとかcomposer installしたらエラーになりまくる
デプロイ中はサーバー停止が必要
そんなテキトーな管理でも怒られないようなサービスなら別に良いけど
それが嫌なら、ディレクトリ2つ作って入れ替えるデプロイツールとかが必要になるが
そこまでするぐらいなら、俺はマネージドのコンテナオーケストレーターとかDockerレジストリを使う
>>925 のやり方ならオーケストレーションもレジストリも要らないね
余計なものを持ち込まないことが成功の鍵
KISSの法則
YAGNIの法則
趣味ならともかくまともなサービスならデプロイの度にダウンタイムは許されない
銀行とかゲームとかしょっちゅうメンテナンスしてるだろ
固定回線や携帯電話の回線交換機やパケット交換機がメンテナンスで停止する事あるんですか? はい論破
まともなシステムから「システムメンテナンスのお知らせ」的なメールがよく来るな
>>927 に書いたように、
CodePipeline は、Ruby 製だから、EC2 に、Rubyが入る。
200MB ぐらい使うのでは?
サイズなど気にしていたら、キリがない
>>925 > EC2一台で動かすようなシステムなんだけど、git pullでソースコードもdockerfile docker-composeも持ってきて、ソースコードマウントして動かして大丈夫?
シェルスクリプトでも動かす気?
まあ
KISSの法則
YAGNIの法則
ならシェルスクリプトしかありえないけど
EC2に言語とかライブラリとか色々入れないと動かないなら
KISSの法則
YAGNIの法則
でDocker使うといいよ
Dockerだけ入れれば動くからね
毎回本番サーバーでソースコードの入ってるディレクトリをマウントしたり npmのパッケージインストールしたり ビルドしたりするなんてシンプルじゃない AWSならECSとECR使えば良くね?
git pull && make シンプルイズベスト
クライン【KLEIN】の動画を、この順番で見るとよい。
他にも、AWS の動画なら、くろかわこうへいが神!
2020/5
【AWS 入門】EC2とDockerでHello Worldしよう
ダウンロード&関連動画>> VIDEO 2020/8
【AWS 入門】ECS(Fargate)とECRで楽々コンテナからHelloWorldしよう!
ダウンロード&関連動画>> VIDEO >>956 自分がAWSを作ったら、無償で提供すんのか?
>>956 LightSailでいいんじゃね?
Lightsail コンテナ: クラウドでコンテナを実行する簡単な方法
↓規制でURL貼れないのでURLを少し変えた
https://aws. アマゾン.com/jp/blogs/news/lightsail-containers-an-easy-way-to-run-your-containers-in-the-cloud/
スポットインスタンス活用でも良いが
難易度は高い
仮想OS 1つで、1日300円。月1万円 企業向け
Dockerもそろそろオワコンかもな 猫も杓子も静的サイト、関数サービス、マネージドDB
>>960 Dockerの本来の対象である
アプリケーションサーバーはどこに行った?w
サーバー用途は諦めて、ユーザーへのアプリ配布に活路を見出そうぜ
Dockerはアプリケーションサーバー用途が一番適してるんだって アホなのかな?
一番かは別として、コンテナにしてデプロイ~はよくやる動作ではあるだろ
>>962 それだと利益が出ないんだよな
オンプレミスでもライセンス料取れるほど価値のあるサービスって難しいよ
折角今まで孤軍奮闘してきたDockerがイメージ配布で立て直そうとしたのに 横から急に出てきた巨大資本に掠め取られるんだもんな そりゃやってられんわ
Dockerはマイクロソフトあたりに買収されれば安泰じゃないか
>>965 関数ってなんだ?
関数だけでアプリケーションサーバーが作れるのか?
railsを関数とやらで動かしてみてくれよ
>>967 > Dockerがイメージ配布で立て直そうとしたのに
なんか勘違いしてそう
Dockerの言うイメージ配布というのは
自社開発アプリのデプロイという意味だぞ
なんかフリーソフト配布みたいなものと
勘違いしてる感じがするんだよなw
>>969 関数は関数だよ
ラムダとかAzureFuncとか
いわゆるFaaSってやつだな 今や世の中だいたいこれで動いてる
>>970 pullにお金を取るようにしようとしたのは有料サービスでお金稼ぐ為じゃないの?
いやだからrailsをその関数で動かしてみてくれと言ってる
>>973 6 時間あたり 100 件の pull という制限で金稼げると思うの?
6時間すぎればまた100個pullできるようになるというのに
>>974 動かす必要がない
railsみたいなフレームワークを不要にするのが関数
関数を動かすのにいちいちフレームワークを導入するか?
しないだろ
>>976 ちょっとその関数を手元で動かしてみるわ
なんか簡単なの教えて
AWS Lambda は、フロントエンドでJavaScript の香具師が、金を稼ぐためにやってる。
一方、Ruby on Rails は、バックエンド。
出自と、勉強している領域が違う
Rubyは元々、Vagrant, Chef, Cookpad 製のItamae とか、サーバー構築運用言語
ロマサガでも、Ruby風の関数型言語Elixir で、
CloudFormation で、Kumogata2 とか
Railsはテレビ東京で、Amazon Killer と言われる、Shopify を取り上げていた。
また、Railsから巨大企業が誕生する!
レールは続く】 Ruby on Rails Part21 【これからも
http://2chb.net/r/php/1545146635/119 関数はバックエンドだよ バックエンドで何か処理をしたいな~、って思ったら、まさにその処理だけを書く、ってのが関数な その処理を書くために、色々めんどくさい、他のコードや設定を、沢山かかなきゃいけないのが、ウェブフレームワーク 関数なら、railsみたいな、めんどくさいフレームワークは必要ない
僕たちはバックエンドで実行される、処理だけ、を書きたい 目的は関数なんだ railsを書きたいんじゃない railsは目的でなく、遠回りな、手段 関数サービスは目的に、最も近い、手段
Ruby on Rails は、バックエンドを勉強している香具師が、 フロントのJavaScript を勉強して構築したもの。 元々、フロント屋じゃない 一方、AWS Lambda は、バックエンド・Linux を勉強していなかった、 フロントのJavaScript の香具師が、バックエンドに攻めてきたもの GUI だけ作っていた、Linux も何も知らない香具師が、 バックエンドは金になるからと、攻めてきた!
そうじゃない railsのようなウェブフレームワークからこれって余計だよね?なくてもいいよね?って無駄を削減したら関数になったというだけのこと
関数じゃ無理があるな まともなウェブアプリは作れない 作れるとういのなら見せてほしい
>>986 使えるだけであって使うべきものではない
Webサイト構築にdocker使うとやっぱりオーバーヘッドありますか?
どんなものでも、オーバーヘッドがゼロのものなんてない オーバーヘッドをゼロにしたいならOSすら使うなってことになる 答えは「僅かなオーバーヘッドで大きなメリットがある」だ
docker-compose.ymlの入ったディレクトリに移動して端末で docker-compose upして起動したのはいいのですが それで発生した痕跡(イメージやコンテナ含む)だけ消すにはどうしたらいいですか stop → rm → rmi ってのを毎回するのでしょうか・・?
docker-composeのservices名って 別のdocker-compose.ymlでかぶらない方がいいですね?
>>990 docker-compose down --rmi all
WSL2ベースのDockerはまだβ版のような出来 PCを休止状態にすると 時計がずれてTLS通信が正常に動作しなくなる
どうしてもWindows使わなきゃならんならhyperv安定
docker-composeでbuildしたとき dockerfileのrunでpipでモジュールをインストールしたら (同じdockerfileだと)その後そのモジュールに変更があっても更新されないから イメージ消して再びdocker-composeでbuildするしかないよね もしくは、commandで毎回新しくpip installするか
>>998 !
まさにっていうオプションがあったのか やってみる㌧
pipに限らずaptやyumでも同じことだから 誰もが一度は考える
このスレッドは1000を超えました。 新しいスレッドを立ててください。 life time: 107日 18時間 26分 38秒
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
read.cgi ver 07.7.23 2024/12/25 Walang Kapalit ★ | Donguri System Team 5ちゃんねる
mmp lud20250310015226caこのスレへの固定リンク: http://5chb.net/r/linux/1597591176/ ヒント: 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「Docker Part4 YouTube動画>4本 ->画像>1枚 」 を見た人も見ています:・Door Kickers ・Docker Part7 ・Dockerに関する質問スレ ・Dockerを教えて下さい ・UnixはなんでDockerに対応できないの? ・Don't look pants backerて曲かんがえた ・docomo版 RIM BlackBerry Bold 9900 Part6 ・Don't look back in anger.という神曲 ・HackerNews Slashdot reddit 4chan 観測所 ・DOUBLE DECKER! ダグ&キリルの声優を語るスレ 5 ・【Doe-doe】Dallas Mavericks 50th【Maxi】 ・【Luka】Dallas Mavericks 46th【Doncic】 ・マサ伊藤のPRT・ROCK CITY・ROCKADOM 2019/10 ・LXD コンテナを仮想マシンとして使う (Not Docker) ・DOUBLE DECKER! ダグ&キリル バディ3人目 ・マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 112 ・マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 105 ・すまんIT弱者の俺にDockerを使うと何がいいのかざっくりでいいから教えてくれ ・「Rainmeter」「Samurize」「Mac風Dock」…デスクトップ改造は何故廃れた!? ・【速報】紅白出場者決定もメンツがショボい 髭男、優里、Ado、back number、藤井風なし★2 ・[VIP931]:【MOBILE NEWS】NTT Docomo’s mobile network tracking technology raises privacy concerns【ハヨ】 ・When I tried to go to McDonald's now, I immediately turned back because there were a lot of Yankees in the parking lot. ・Docker代替のpodman専用スレ (Dockerの話題禁止) (58) ・TH eROCKERS☆4 ・Locker KENZO 2 ・Locker KENZO 4 ・280blocker Part21 ・SHERLOCK3 #2★1 ・Locker KENZO 5 ・280blocker Part19 ・280blocker Part20 ・280blocker Part18 ・ClockLauncher part.7 ・ワイbitlocker 分からん ・Summer Pockets ★8 ©bbspink.com ・PeerBlock 16ブロック目 ・SILVER BUCK 闘狂 Part.7 ・SHERLOCK/シャーロック 第3話 ・BlackBerry Classic part7 ・BitLockerでドライブ暗号化 2台目 ・SILVER BUCK 闘狂 Part.22 ・BitLockerでドライブ暗号化 1台目 ・【bayfm】MAXIMUM POWER ROCK TODAY ・【BlackDesert】 黒い砂漠 Part242 ・Buckcherry / バックチェリー PART8 ・【BlackDesert】 黒い砂漠 Part402 ・【BlackDesert】 黒い砂漠 Part439 ・【CK2】Crusader Kings 110世【CK3】 ・【BlackDesert】黒い砂漠PC版 Part607 ・【BlackDesert】黒い砂漠PC版 Part536 ・BlackDesert】 黒い砂漠 Part474 ・teratailもりあがっいlucker? 1問目 ・【CK2・CK3】Crusader Kings 133世 ・☆☆☆TH eROCKERS~SHAKIN'☆☆☆ ・【Black Desert】黒い砂漠 PC版 Part708 ・【Black Desert】黒い砂漠 PC版 Part650 ・【Black Desert】黒い砂漠 PC版 Part692 ・【Black Desert】黒い砂漠 PC版 Part739 ・【Black Desert】黒い砂漠 PC版 Part690 ・NixOS・Nix Package Manager Part1 ・山田だが、今更blackberry使いてえ ・【全能20周年】 BALZAC【SHOCKER20周年】 ・【BlackDesert】 黒い砂漠 Part412
22:31:25 up 54 days, 23:30, 0 users, load average: 7.73, 7.72, 7.94
in 0.077486038208008 sec
@0.077486038208008@0b7 on 061111