◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ: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を教えてあげて、それを納得したはずなのに何も理解していない。
> すっげー前にDeployerを教えてあげて、それを納得したはずなのに何も理解していない。
buildkitっていうのがあるんだってな
>>5 設計や動作が大きく変わってるから
長い検証期間を設けてるだけ
そのうちデフォルトになるだろうがすぐは無理
俺が知っている事例で言えばマルチステージビルドで
必要ない場合にビルドされなくなることがある
通常は問題がないだろうがビルドされているという
前提があったりすると問題が発生するだろう
buildpacksって
運用者なんていない。あるのはシステムだけだ。
いや、Dockerfileを書かなくていいのが最大のbuildpacksの長所か
> アプリケーションコードを含んでないイメージで
自分で開発してないイメージはDocker pullして使うものだ
>>10 PHPでの開発の時
ローカル開発の時はphpのコードはボリュームマウントして入れるが
本番環境で使う時は予めphpのコードが入ったイメージをCIで作っておいて
それをプルしてきて動かす
>>10 アマチュアっぽい
開発中も無駄にdocker buildしてそう
またキチくん暴れてるのか
同じベースイメージでローカルqgp環境の開発を行い
ローカルのphp開発環境だった
>>13 なぜ開発環境と本番環境を基本的に同一にしない？
Dockerなら、developmentもproductionも同じにできる。
同じにするということはイメージにソースコードを含めるということだな
>>15 開発中はDockerを使わない
テストで使えば良いのだ
新人「せんぱぁ～い。バグ報告書どおりにやったのに違うエラーがでるっス！助けてくださいよ～(´；ω；｀)」
>>23 そういうことを防ぐために例えばRubyでは
Gemfileという仕組みがある
Dockerを使った所でバージョンの固定なんかできんよ
ディストロに入っているライブラリだけを使って開発するんじゃないんだから
むしろディストロに入ってないライブラリを使うことが多い
Dockerの中でGemfileを使ってバージョンを指定しているのであれば、
同じようにDockerを使わない場合もGemfile使ってバージョン指定をするだけの話
Rubyのバージョンも.ruby-versionでしていする
もちろん他の言語でも同様の仕組みがある
> ベテラン「そもそも開発環境作るの手間だろ。なんで手間かけてトラブルの可能性を増やしてんだお前。マゾか？」
開発環境を作るためのものでもあるし他のためのものでもある
環境を作るとかいって仮想マシンの代わりだと思ってるやつの発言はこんなに間抜け
コンテナ型仮想化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にコード置いたディレクトリマウントして使って、内結以降はイメージビルドして商用相当の開発環境にデプロイしてテスト、そのイメージをリポジトリにあげといて商用からはそれpullするだけって使い方が普通じゃないの？
> 実装～単体まではローカル端末上のDockerにコード置いたディレクトリマウントして使って、
できるだけ寄せていくだけだ
開発環境を汚したくないんですよ
>>35 開発はディストリ依存にするべきじゃないよ
変更しづらくなる
>>36 > 開発環境を汚したくないんですよ
汚す必要ないのでは？
> dockerの特性上、1つのプロジェクトで
Dockerの性質のものは一つもないね
> 開発マシンにこれらを直接インストールして管理するのは大変だ
全然大変じゃないよ。
そのためにrbenvなどの仕組みが普及してる
アプリを動かす環境は特定のディレクトリ以下にすべて入る
もう随分と前から一つのマシン上に
>>37 クロスプラットフォームで動かす予定のないものをクロスプラットフォームで開発する予算は君が出すのかね？
>>38 rbenvのようなちゃちな仕組みではいずれ限界が来る
君のところは構成がシンプルなのでなんとかなっているのだろうね
>>40 クロスプラットフォーム？何を言ってるの？
どちらも同じLinuxなんだが
> rbenvのようなちゃちな仕組みではいずれ限界が来る
>>42 Linuxにも様々なディストリがあることを知らないと晒してしまったね
>>43 しょぼい構成の案件に従事してる人は気楽そうでいいね
Vagrantで十分って老害かと思ったら
QA環境作らないの？
1つイメージを利用して、名前の違う２つの内容同じコンテナを実行したら
>>53 それは同じプロセスを2つ起動したらメモリは
2倍消費されますか？と言ってるのと同じ
Dockerの話とは関係ない
>>53 2倍になるよ
ただLinuxにはKSMという仕組みがある
それで消費を削減できる
そうなんですね
apacheってオワコンじゃないの？
メモリーの少ないサーバーで動かしたいのなら
nginxをフロントに置いてPHPはapacheで動かすのがいいらしいっすよ
うちは本番環境がAWS ECSだから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アドレスをもとに制限されるとのこと。
そんなケチるほど金ないのか
pullしようとしたけどすでに最新だった場合ってどうなるんだろうか？
>>69 というか、自前でレジストリ作れってことだよ。
Circle CIとかGitHub ActionsとかのSaaSは
>>70 レジストリをメンテするぐらいなら金払うよ
たった月5ドルだろ？
>>71 別のユーザーによるpullでCIがこける可能性があるんだよな
でもそれはCIサービス側が対応する問題になるだろう
その対応の内容には安定したpullがしたければ
金払えっていうのも含まれるけどｗ
ちなみにオープンソースでツール公開してるんだけど、この間から
おそらく誰かが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がエンプラで黒字なんて無理だろ。
何を言ってんだ
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じゃなくても同じだねｗ。
最初からそう言ってる
いやもう日本語通じない通じないｗ
このトピずーとそうだけどｗ
>>77 ホスト管理がいやだからクラウドのコンテナサービを使う
>>78 インスタンス管理が大変
>>84 クラウドだからホストは管理不要ｗ←Now!
>>83 お前がホストって言葉を知らんだけじゃね？ｗ
わかりやすくパソコンにしようか？ｗ
息子がやってくれるからパソコンの管理はしなくていい
パソコンの管理をしなくていいが、パソコンという単語はでてくる。
例えば「パソコンを使う」「パソコンの電源を入れる」とかね
「（ホストの）管理しない」という話と「（ホストという）単語が出てこない」には
まったく繋がりがない
ホストの管理をしなくても、ホストという単語は出てくる
>>83 > 何でDockerだとホストの管理をする必要が無いと思うの？
Kubernetesだからホストの管理をする必要がないって話だろ
話をすり替えんなって
Kubernetesはノードを意識した細かい制御ができすぎてな
>>88 そんなレベルの話をするなよ初心者くんｗ
君の言う「パソコン」＝物理サーバは
完全に抽象化されててこのスレ内では全くでないだろｗ
Dockerの中で「ホスト」と言っているのはDockerが動く基盤であってそれが物理サーバであるかVMであるかは問わない。
非常に多くの場合はVMであり、それは「インスタンス」と言う名前で出ている。
つまりこの文脈ではホスト＝インスタンスって事
で何でk8sだからホスト管理しなくて良いの？
https://knowledge.sakura.ad.jp/3681/ 例えば、上記の構成で本番機を作ったとして、192.168.0.50が死んだらどうするの？
「ホスト管理しなくていい」と言っているのは生存管理すら必要ないと言っているんだよね？
>>92 > 例えば、上記の構成で本番機を作ったとして、192.168.0.50が死んだらどうするの？
ああ、おまえ、GKEとかEKSというサービスを知らんのかｗ
上記の構成を作って"管理"するのはクラウドサービス側なんで
”お前がやらなければいけないと思ってること”を全部クラウドサービス側がやってくれるんだよ
>>93 いやマジ君の言っている（言わんとする事）の意味がつかめないんだがｗ
君の説明はどうでも良いよ。君の行動を話してくれ。
192.168.0.50が死んだとしよう、君はどうする？
お前らよくこんなニッチなものでいつまでも言い争いできるな
>>94 サーバーの管理って何のことかわかってる？
サーバーが死んだら新しいインスタンス起動して自動的に再起動やろ
やらなくていいのはサーバーの管理だってわかってる？
FargateってEBSはマウント出来ないよな
イメージのマージ機能はいつになったらサポートされんだ
インストール方法？
そりゃチームの人が作ったら他人だろうけどそういう話じゃないだろｗ
いやいやそうじゃなくてオープンソースのツールとかあるだろ
>>102 オープンソースのものを自分でDockerfile作る意味は？
殆どのものは公式が用意してるでしょ
>>104 公式サポートない物もいくらでもある
それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
なんでこんな基本的なこと説明してやらんといかんのだ？
いや、自分で「マージしたDockerfile」作れよ
go製ツールならバイナリ落としてくればすぐ動くが
OSに最初から入ってるツールの扱いはどうするのか？とか考えたら
結局のところ必要だったのはdockerじゃなくてより賢いパッケージマネージャだったんだよな
>>105 > それに組み合わせて使えないからマージしたいときは自分で作らなきゃならん
docker-compose使えよ
１つのコンテナに複数のサービスを入れ込もうとしているからそうなるんやで？
ベストプラクティス通り1コンテナ1サービスにすれば
既存のものをそのままつかえるのに
ベストプラクティスから外れることを自分でしておいて
自分が苦労してるのって間抜けじゃねーか？ｗ
>>110 Dockerはパッケージマネージャーが対応してないような
自分（自社）で開発したアプリケーションを使って
自分でサービスを運営するためのパッケージマネージャーです
開発者向けのツールです。
snapはアプリ開発者がエンドユーザーにアプリケーションを
提供するためのもの。用途が全く違います。
apacheのバーチャルホストで20個のサイトを運営するのと
メモリとCPU使用率が重要なら、
1コンテナ1サイトって発想が出るのもやっぱりいつもの
1サイトをバックエンドとフロントエンドとDBに分けても良いよ？
>>112 アホか
何でもかんでもサービスにしたら効率が悪いこともある
メインの言語でwebアプリを作って内部で別言語製のCLIツールを呼び出すようなシステム
>>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だけで云々言っている人は、
COPY --from=some/image /source/path /dest/path
マージ君は自動でやってほしいんだからそんなもんお呼びでないだろう
>>125 マージには役に立たんわ
そもそも必要なファイルがどこにあるか探すのめんどくせぇーだろ
欲しいのはレイヤーをコピペする機能だよ
それかdocker最適化されたパッケージマネージャでもいいかな
俺たちが本当に欲しかったのってこれな
>>128 Dockerは○○専用に作るものなのに
それをなにに再利用するんだよｗ
>>129 世の中なんの外部依存関係もないピュアなアプリケーションだけじゃない
そしてすべての外部依存関係がネットワークを通じて呼び出せるエンドポイントを持っているわけじゃない
こんな基本的なことをなんで説明しなきゃわからないんだ
「よしなに」が仕様のツール誰が作るの
トラブったら
>>128 みたいなのに文句言われるんだろ
>>131 docker公式かツールベンダが作るんだよ当たり前だろ
ほらな、説明できない（笑）
はぁ…┐(´д｀)┌ﾔﾚﾔﾚ
>>130 だから同じイメージに複数のパッケージを入れて環境変数やボリューム設定をするというユースケースが当たり前のように出てくる
そのためにはimageではなくパッケージって単位で再利用できねーと非効率的なんだよ
わかったかなボウヤ
>>136 主張を繰り返せって言ってるんじゃなくて
主張の理由を言えって言ってんの
ほんと会話ができんやつだなｗ
>>137 これがdockefile専用パッケージマネージャが必要な理由に見えないならもう話にならんわ
会話が通じないレベルの差があるってことだ
お前が言ってるのは、ユースケースと主張だけ
「同じイメージに複数のパッケージを入れて環境変数やボリューム設定をするというユースケース」
「世の中なんの外部依存関係もないピュアなアプリケーションだけじゃない
>>144 >>143 理由をさっさと書きましょう
>>145 書いてある
あとはお前が理解するだけだ
理解する気がないなら無駄な問答が続くだけだからもうレスしなくていいよ
バイバイ
お前が言った言葉の全てに対して「それは理由じゃない」と説明したんだがｗ
>>147 間違った説明だから意味ない
理解する気がないならレスするな
2回目だよ
俺の説明のどこが間違っているか言える？ｗ
できたらコテ班付けてくれませんか
お前らはどのコンテナセキュリティスキャナ使ってるん？
>>149 いつものDocker原理主義者？
傍から見ていると、君が何故そんな下らない方向に持っていくのかスゲー疑問。
君が
>>98 に対する解決策を知っていれば教えれば良いだけ。知らなきゃ黙ってろよ。
俺はこの人がなぜ欲しががっているのか理解はできるよ。
解決策知らないから黙ってるけど。
確かにDockerのビルドはスタック上に積み上げてるから、その一部分だけ抜き取ってマージしたいとは思うわな。
何で「理由を言え、Dockerの本来の使い方はどうのこうの」の話を50レスも繰り返すの？
> 何で「理由を言え、Dockerの本来の使い方はどうのこうの」の話を50レスも繰り返すの？
> 確かにDockerのビルドはスタック上に積み上げてるから、その一部分だけ抜き取ってマージしたいとは思うわな。
同じファイルを使うとか同じポートを使うとか
>>153 理由を答えてるけど君が理解しないだけだよね？
>>136 はどこからどう読んでも
理由にしか見えないんだが？しかし別に理由はどうでも良いよ。
知ってるんなら答えろよ。知らないんなら黙っとけ。
スレの無駄だ。
そういう面倒なところを解決するためにスマートなDockerfile専用パッケージマネージャがあるといいなぁって話だろ
それは同一イメージ内でyumやaptを複数回使うのと何が違うの
>>156 じゃあ重要でない言葉をマスクしてみようか？
○○というユースケースが当たり前のように出てくる
そのためには○○できねーと非効率的なんだよ
見ての通り、理由が書いていない
環境変数の設定やインストールの手順がわからないことがあり、
>>158 Dockerfile専用パッケージマネージャは
理屈は不明、何をしてくれるかもわからないが
面倒なことを魔法のように解決してくれるのです
どうにかして～って叫ぶだけで
何かが解決するのです
>>159 もう良いよｗお前は黙っとけ！ｗ
「できねーと非効率的なんだよ」
何でこれが理由だと読めないんだよ！アスペ野郎ｗ
サービス起動するときにあれこれ設定して起動するの面倒だなぁ
>>162 じゃあ同じように"理由"を言うね
「imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
これがお前の言う"理由"です
理由を言ったので納得しますよね？ｗ
>>164 元の文章：
「imageではなくパッケージって単位で再利用できねーと非効率的なんだよ」
>これがお前の言う"理由"です
×「imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
○「imageではなくパッケージって単位で再利用できれば効率的なんだよ」
君はマジでここに粘着するより、病院に行ったほうが良い。
>>165 元の文章が間違ってるから
俺が正しい"理由"を言っただけですが？
俺はこれを"理由"とは認めてないが、
お前は"理由"だというのだから問題ないはずだが？
>>166 なるほど、君は
>>136 に、
「俺はそれを理由として認めない、お前はエスパーになって、
俺の納得いく理由を答えろ、それ以外は会話できると見なさない」
と、こう言いたかったのですね。
>>167 話の九割はDocker関係ないけどな！
>>168 納得がいくかどうかじゃなくて
"理由"そのものになってない。
もしその文章が本当に"理由"であれば、
頭に「なぜなら」や「その理由は」をくっつけて自然な文章になる
「なぜなら、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
「その理由は、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
自然な文章になってないので、これは理由ではない
これは単なる主張
文章が逆だったなｗ
>>170 わかったから病院に行け。
明日の朝イチですぐに行け。
君は相当、重度の発達障害だぜ。
「なぜなら、imageではなくパッケージって単位で再利用できねーと非効率的なんだよ」
これが理由と読めない理由がさっぱりわからないｗ
他人が述べた理由を
「なぜなら、imageではなくパッケージって単位で再利用できねーからこそ効率的なんだよ」
と勝手に書き換えるのもわからないｗｗ
実は君は宇宙人で、夏休みで日本に降り立ったのかいｗ？
日本語難しいよな！
>>172 なぜパッケージ単位で再利用できねーと非効率的なんですか？
>>173 なんで俺に理由を聞くの？
>>136 にレスしろよ。
彼が言っている事で、俺にも思い当たることはあるけど、正確に136が
どのようなケースを想定してこういったのかは知らない。エスパーじゃないからねｗ
俺は
>>137 の日本語の理解がおかしい、と指摘しているだけだが。
何か知らんけど、マージ機能なんか実現するわけないし話しても仕方なくね？
>>174 おや？「パッケージ単位で再利用できねーと非効率的」では
理由になってないと認めたのですか？ｗ
それが理由だろって言えばいいだろうｗ
コンテナの安全性をどう保証するのか社内で揉めてる
>>176 謎の技術で面倒なものをよきに計らってくれるものが
作れると思ってるやつに何言っても無駄だろうｗ
>>178 既存のノウハウで安全性を保証すればいいだけでは？
何が通じないのかいいましょう
>>180 新しい試みだから何が足りんかもわからん
訓えて
>>181 既存のノウハウがそのままつかえると言ってるんですが
今どうやってコンテナではないものの
安全性を保証してるんですか？
まずそれを答えてください
>実際、オープンソースセキュリティ企業のSnyk社が、自社のコンテナースキャン機能で最も広く普及している10個のDockerイメージを分析したところ、すべてのイメージに脆弱なシステムライブラリがあることが明らかになりました。
>その中でも群を抜いて最悪だったのはDocker社の公式のNode.jsイメージで、580もの脆弱なシステムライブラリが含まれていました。
ぐぐったらこんなんでてきた
公式イメージでこの体たらくじゃセキュリティガバガバすぎて使い物にならなくねえか？
>>182 君だったら既存の対策で↑の580の脆弱性にどうやって対応する？
あらら即レスくん黙っちゃった
>>183 > 君だったら既存の対策で↑の580の脆弱性にどうやって対応する？
だからお前はどうやってそれに対応してるのかって聞いてるんだが
Node.jsに脆弱性がったら、アップデートするだけやろ
>>183 これはどうやって安全性を保障するか社内でもめている、って人へのレスなの？
自社で使う場合は「Docker社の公式のNode.jsイメージ」なんて使わないだろ。
「Docker社の公式のNode.jsイメージ」を作るためのDockerfileは
こうやって突き詰めていくとスゲーめんどくせえんだDockerってさ
>>189 だから言ってるだろ
1. Dockerを仮想マシンの代わりとして使おうとする
2. Dockerは仮想マシンの代わりとして使うのは面倒くさいじゃないか！
3. Dockerは仮想マシンの変わりにはならない！
4. つまりDockerはクソ
って言ってるのがお前だろ？
俺は最初から言ってるよな？
Dockerは仮想マシンじゃない。
（必須ではないが）仮想マシンと組み合わせて使うもの。だと
ぶっちゃけ最初からアプリがポーダブルになってればDockerなんて要らんのだよね
依存関係もまとめて全部塊でわたせるって
>>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 簡単にできるというのなら、それを使えば解決するのでは？ｗ
「それ」が何のことか言えないから、お前はそうして
アプリ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でいいですよね（にっこり
結局アプリケーションの実行環境を仮想化するなら
>>207 やれやれだ
Dockerも名前空間を利用してるがその使い方が下手くそだ
よりスマートに使うにはパッケージマネージャ方式が正解
>>209 お前、名前空間の意味わかってないだろｗ
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のマッピングをすると？
パッケージマネージャー上でアプリでも動かすんか？
ファイルを配置するだけのパッケージマネージャーでは無理だよなぁｗ
なんかパッケージマネージャーとかいってるけど
>>212 ぷっ
名前空間がUIDGIDだけだと思ってんのかこいつｗｗｗ
>>213 snapd
パッケージマネージャがデーモンとして動いてるなんてのはもうすでにあんだよ
お前さん取り残されてるぞ
>>214 ユーザー名前空間と言った後
しれっと「ユーザー」を消すとか
卑怯ですねぇ（笑）
>>215 あれあれ？じゃあお前のいうパッケージマネージャーって
Dockerみたいなものだってことですかねぇ
snap？登録に数時間かかるようなものがつかえるわけ無いだろ
だから言ってるDockerは開発者のためのもので
お前のような一般ユーザーはお呼びじゃない
コンテナ配布で同じ環境を猿でも容易に作れたり、スケーリングや冗長化や障害発生時の自動回復で
前々から言ってるように
じゃあDockerHubに上がっているdocker-composeの公式イメージはどういう扱いになるんだろう
【悲報】 DockerHubのイメージが6か月しか持たなくなった……
dockerは存続できるのか?
インスコが面倒くさい人のためにDockerイメージが提供されてることはある
php向けの静的解析ツールのphpstanはDockerでも動く
シェルのエイリアス使えば普通にインストールしたのと同じ感覚で利用できる
https://phpstan.org/user-guide/docker >>221 6ヶ月pullしてないイメージが消えるだけやろ？ｗ
使ってないイメージが消えてなにか問題があるんか？
作り直せばいいだけだし、それができるのがDockerfile
>>221 dockerhubは着実にsourceforge化が進んでるな。
そのうち何か月かpullされない物はイメージ内に勝手に広告入れてくるぞｗ
>>226 そうだな。広告が入ったらお前が正しい。入らなかったお前は間違い。
今はまだ入ってないから、お前の予想は現在進行系で間違い続けてるってことだ。
これからずっと何年間もお前は間違い続けるだろうｗ
コミュ障は冗談が通じなくて大変だなｗ
冗談で言ってるといいながらそれが本音だったりするからな
そりゃ本音だろ。
「冗談じゃねーか」
Dockerが消えてもPodmanがあるから安心
>>215 dockerやってはsnap使ってるって事はmicrok8s使ってるの？
>>240 Dockerhub終了のお知らせって事で良い？
こりゃいよいよDockerhubは広告が入りそうだなｗ
>>240 > Docker as the second most popular ecosystem in Packages
Dockerってすごいな。パッケージシステムとしての
デファクトの１つを確立してるじゃん
snapとか言うのオワコン？
>>242 >>192 は単に「俺はDockerよりもsnapの考え方の方が気に入っている」
と言っているだけであって、別にシェアのことを言っている訳じゃないね。
話をちゃんと聞き取ろうね。
yumとかaptとかnpmとかが無料ユーザーは
>>243 「Dockerの役割を知らないから、snapが代わりになると思っている」
じゃねーの？ｗ
Dockerは開発者のものという意味がわからんのだろうね
自分が開発者じゃないから
>>244 Dockerも利用回数制限するとは言ってないですね
なにがいいたんでしょーか？
>>245 この勘違いくんいつまでこの勘違い続けるんだ？
クライアントはDocker使わないとでも思ってんのかね
>>247 クライアントだけに限定するなや
お前が言ってるのは、ハズレを除けば
全部アタリって言ってるだけだ
Docker Hubのプル回数制限の件は
プル回数制限ってログインしてないユーザーで6時間で100回だろ？
>>250 やべーのはCIだろうな
毎回クリーンな環境作って複数のimageをpullするから100回なんてあっという間だ
>>251 なぜ今、6時間で100回のpull制限はキツイかどうかって話をしてるかわかる？
開発者はCIを使ったテストで多数のイメージをpullする必要があるからだよ
これがDockerの主なユースケースの１つ
開発者なら容易に思いつくんだが
snapが代わりとなると思ってるような奴には理解できない
そういうやつがsnapの方が考え方が気に入ってると言ったところで
お前はDockerの使い方を知らんのだとしか言いようがないだろ
>>252 クラウドのCIを使ってるならクリーンな環境を作るときにIPアドレスが変わるはずだよ
IPアドレス固定は有料だから、固定にする必要がないものまで固定にしたりしないだろう
自社でCIサーバー立ててるようなところは苦労するかもしれんがｗ
>>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と同じ料金体系が適用される予定です。
まじかよpull回数制限ってもう始まってるのかよ
>>271 crontabかなんかで、月1回だけ、認証アカウントからpullすればいいんとちゃうの？
>>272 だからpullするのは俺じゃないんだってｗ
前から思ってたけど、イメージ名が卑怯だよな
例えば debian というイメージはDocker Hubからダウンロードと決め打ち
Googleのを使うとイメージ名が変わってしまう
わざとそういう設計にしてるんだろうけど
対策って、「空いてそうな時間にpullしてね」って言う以外にどんなのがあるかな
ネタというか暇つぶしにおちょくってるとき以外はずっと過疎ってるねここ
Macで動かすと遅いって記事をqiitaでみたけどまじなの？
ファイルシステムのせいだろ。NFSにしたら直るとか。
まじだよ。osxfsが遅い。
母艦はなんでもよかねえか
>>283 gRPC FUSEにしたら、改善はするけどな。
safariがWindowsでもLinuxでも動かせればいいんだけどね
>>286 Apple「Mac買ってください。お願いします。どうかお願いします。助けると思って」
>>285 Docker for MacのEdgeリリースには入ってるんだっけ？試してみるかぁ
DockerはもともとLinuxのLXCを使って実現したわけだけど、それ以外の環境だと
>>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 machineという名のVMの上で動いていただけです。
> （諦めました、CoreOSは離れていきました）
CoreOSはDockerと全く関係ない。
むしろ競合技術。CoreOSのrktはまさにDockerの代替
CoreOSが消え去ったのはDockerの勝利
Docker vs. CoreOS コンテナ戦争とは何だったのか？
https://gihyo.jp/news/report/2016/11/2201 > 駆逐されるはずだったVMの会社
>>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 会話についてこれてなくて大爆笑ｗ
> その公式の情報とやらは何処に…？
>>305 いいからURL示せよ。
多分にお前のファンタジー解釈が入ってるだろうからｗ
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
isolate their app from its environment, solving the “it works on my machine” headache.
Googleまるなげ
コンテナーは、開発者がアプリを環境から分離して、「自分のマシンで機能する」という
頭痛を解決できるようにするソフトウェアの標準化されたユニットです。
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は終わりでしょ
>319
>>321 まあとにかく使ってみなよ
dockerが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の話題禁止」ｗｗ
それじゃ325の続きかけねーよｗｗｗ
>>331 行動が不自然だと言っている。
なんでmysqlに問題を抱えるやつが自分の問題が解決した
喜ぶべきスレ立ててまでタイミングで他人を排除とか変な
行動しなきゃならんの？
って話。
>>332 podmanを消してDockerの話題だけをすればいい
>>334 全く意味のない情報になるね。
>>1 には「情報共有しましょう」と書いてるのに。
俺はその話に興味があるんだから、お前が勝手に排除するなよ。
dockerとpodmanを比較したい？
話したいなら話せば良いじゃねーか。
比較の一方がDockerならスレチでもない。
お前が興味ないだけなんだろ？じゃあ２、３日PC閉じてろよ。
話し終わってるから。
韓国「日本が～、日本が～」
>>336 まんまお前じゃねーかｗ
お前「Dockerが～、Dockerが～」
ほかの皆さん「Docker？コンテナ技術の１つですね。」
ｗｗｗ
>>338 podmanの話をしようとした人はそうだろ。
ほかにNautilus の話しようとした人も。
>>333 すいません、理解できる日本語で書き直していただけますか
>>340 何で君は自分の問題が解決した喜ぶべきタイミングで
君の問題と全く関係ない話をしている、他の人を排除しようとするの？
別にスレチって事も無いよな？
mysqlはmysqlのスレに行けよ
じゃあpodmanは別ツールですから移動してくださいね
>>343 dockerとpodmanの比較の話をしてたはずだが？
俺は続きに興味があるんだが？
何処に優位性があるのか、思わずggちまった。
mysqlへの興味は10年前に終わった。mysqldumpとか初心者かよｗ
dockerはpodmanのエイリアスだぞ
誰もpodmanに興味が内容であっちのスレは落ちそう
Linux使え
会社だとMacかWindowsが支給されるがLinuxは支給されない
>>351 会社支給品で開発するなら普通はMacでは？
WindowsのDockerはまだこれからと言う気がする。
とはいえMacはARMに移行するから、近い将来買い替えなければならなくなる。
ARM CPUで開発して本番機はx86(Xeon)ってのも色々リスクがあるから会社の方針を変える必要があるかもね。
（本番機もArmのlinux使う検討するとか）
最近のWindowsUpdateの更新でWSLがバグってるらしいけどDockerは普通に動くの？
WSLのバグは大きな問題じゃないから
メモリ食いつぶしたり古いカーネルAPIの互換性でクラッシュしたりするけど仕様なんだってな
メモリは上限を決めれば問題ないだろ
普通の仮想マシンと同じ扱いならトラブル少ない普通の仮想マシンを使うわ
普通の仮想マシンと同じ扱いなんて書いてないよ
欠点はある
はい自滅しました（笑）
そう
>>362 いくらレイヤーを重ねようが、お前が作ってるわけじゃないんだから
どうせ見てないだろｗ
>>362 原理的にはそうなんだろうけどね。
linuxってそもそも効率的な開発できるもんなの？
excelもwinmergeもないOSで効率的な開発できるとは到底思えん。
ファイルマネージャも使いにくいしな。
同僚でlinuxを開発機にしてる人がいるけどミスが多くて、やはり効率的に仕事しているとは思えない。
>>369 何にｗ？
エアプなら何にでも使えて便利だよなｗｗｗ
>>370 docker-vpn-browserとかあるんですよ
無知晒しちゃったねw
>>371 その程度の用途ならそもそもdockerのホストがlinuxなのかwinなのかmacなのかなんて
どうでもいいじゃんｗ
>>372 >開発以外の用途にdockerなんか使うのかよ？
これの答えなんだがそれすらも理解できなかったかな?
>>373 その上がDockerはWin/MacかLinux化って話だから、
そんな用途ならホストはどうだっていいよ、って話だね。
今の本番環境といえばクラウドだが
imageを上げるだけでサイト公開できるwebサービスありませんか？
>>365 エクセルは使いみちないかな
DiffはVSCodeで見てる
作業中にいちいち外部ツール起動するのは非効率的
>>365 Excelもwinmergeも要らない。
同僚がヘタレなだけ
差分比較ツールなんか、ほかにもある。
Meldもいいし、VSCodeのDiffもいい。
Excelなんか、こだわる必要ない。
テレワークだとエクセルが遅すぎるんだよな
>>377 Excelは顧客との仕様確認、テスト仕様書用やな。
最も半分以上googleスプレッドシートに移行してるからだんだん存在感なくなってきてるけど。
今時のクラウドエンジニアってマジでWeb上のサービスしか使わないのね。
winmergeはディレクトリ配下全部の比較が出来るのが良いね。
同じことができるのがMacにもLinuxにもなかなか存在しない。
win10嫌いだからあれば移行するんだけど。
>>378 まあフランス人だからな。
ヘタレなのが日本語不便だからなのか本人の性格（面倒くさいことが大嫌い）
なのかLinux使ってるからなのかわからんのが何とも言えんｗ
でも奴の使いっぷりはイマイチだと思ったね。
Markdown等 + テーブルエディタ
data visualizationならmatplotlibとかでえんちゃう
じゃあ
ただしExcelを神エクセルとか単なるデータファイルとして使ってる場合
可視化はmatplotlibとか使えばいいんじゃないの
>>391 複数の道具を使うことは論点じゃないよ
エクセルと同じことをするならviみたいな単純な機能のものでできるっていうんじゃなくて
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 そりゃ使うだろｗ
電卓だってプログラミングできない人の
ためのツールだがプログラマも使う
それと同じ
dockerでexcel.applicationうごかしたいんですが動きませんなぜですか
dockerでは、起動するたびに同じ状態になるけど
>>408 ぜんぜん違う。
docker-composeは、docker起動のオプションがたくさんあって
大変だからYAMLに書いておけるようにしましたってだけ
１つのYAMLで複数のdockerを起動することもできる
コンテナのなかにデータ持たせて(DBなど)新規起動と停止してるのを起動で挙動が違うのを観測して後者をそうとらえたのかもしれんね
コンテナって儚い
なかったことになるから嬉しいんだよ
>>411 それがプロセスってもんだよ
nginxを起動すると、nginxがメモリに読み込まれ起動する
終了したらそこまで。メモリに読み込まれたプログラムは儚く消える
変更を保存できるのはディスクのみ
これがnginxをラップしたDockerイメージでも同じこと
>>408 そりゃコンテナをdown/upで停止起動するからだろ。
stop/startで起動すればそうはならない。
普通にVMのshutdown→起動と同じように使える。
ほかの連中は何で無かった事になるのが当たり前、的なレスしてるんだ？
stopは滅多に使わない
>>415 それは単なる君の好みだろ。
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 エアプの人達に説明するのって大変だな！
掲示板なんかに粘着してないで、まあ自分でやってみろよｗ！
>>426 知らないのか？
stopってDockerコンテナの中にあるプロセスを全部停止してるんだぞ
そこから再開してもスタートしない
>>427 そこから再開してもスタートしないというのなら、君がそういうイメージを作ったんだろう、
としか言い様が無いな。
>>427 もう一回ENTRYPOINT等で起動されるだけ
stopで止める理由がねえんだよな
>>430 >コンテナを一時的に止める時は、潔く破棄して、再作成するのが基本
これは、どこにそう書いてあったの？
君は何を読んでこれが、「基本」だと理解したの？
URL（若しくは書籍名）示せよ。
書いてあるかないかは関係ないわな
個人的にはdocker runは--rm付きでしかしない
>>432 >stopなんて要らないなとわかる
じゃあ、なんでstopと言うコマンドは実装されたのw？
>権威主義は思考停止、エンジニアとしての死に等しい
お前はニートのニセエンジニアだろ？
ここ迄、理解に難有りの人間に給料払い続ける雇用者はそうは居らんわ。
>>434 startの対として脳停止でstopも作っちゃったんだろうな
本来は要らなかったんだけどDocker開発側も作り始めた頃はDockerを深く理解してなかった
今から再設計するならstopは消えるだろうね
>>435 なるほど
「Dockerを実装したDocker社の正社員は間違っている、
俺の方がDockerの思想を理解している」
と、こう言いたい訳ですねｗ
>>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 最後の段落
すげえキレイにブーメランになってて笑う
この前入れたバグ修正がアップデートで消えちゃったんですけど、助けてください～、って泣きついてくる新人並みｗ
>>444 >>441 の通りだね。開発中は「便利に使うのが正解」
イミュータブルインフラストラクチャは本番機で実行される時の話。
開発中は関係ない。
・・・もうね、427以降のニートで実務わかってませんっぷりの酷さは何なのｗ？
何度も「何をもってその理解に到達したのか？」と聞いているのに、そこはスルー。
誰かが以前「Docker使ったからと言ってイミュータブルにできるわけじゃないよ」
と言った書き込みも理解できずに、そのまま来たんだろうね。
初心者くんに教えてやるか
>>448 DockerfileはSREの責務だから触れないよ。
一連のDocker原理主義者のおかしな書き込みを見直して、なんとなくわかったわ。
アプリに対するステートレスなつくり、イミュータブルインフラ、永続化する場所の選定、
ログの一元管理、それらは確かに必要だけど、それは本番機を運用するときの話だ。
本番機じゃコンテナ自体がでデプロイする度に破棄されるし、いくつのreplicaで動くかわからないからね。
それと、開発中の話がゴチャになってるから、話の展開がおかしいんだね。最初に相談する人は
立場がそれぞれなのに、自分が理解したものでしか返せないから、会話がおかしくなっている
開発中は
>>441 が正義。
開発効率が高ければ、やりたい様にやれば良いし、自分のやり方を他人に強要する権利も無い。
開発者としてアプリを作るときはStatelessに作ること自体は気にかけるけど、そこで動くDockerに気を配ることは無い。
便利で軽いVMとして使いたい？全く問題ないよ。
>>449 やりたいようにやりたいってのは逃げの議論だな
stopを使うような非効率的な開発方法も、僕がそうやりたいんだからしょうがないだろ、開発効率なんて知ったことか、とそういうことだろ
>>450 ん？話の発端は
>>408 以外にも方法はあるよ、って話をしただけだが？
君の話を俺が非効率だと感じるのはウチのチームでそうしている奴が誰も居ないからだが？
開発機のコンテナだけで10個あるのにDockerfile弄って毎回コンテナの破棄→構築なんて、やってられんわ。
まるきりDocker原理主義的だし。
stopの話自体は、「起動するたびに同じ状態」以外にあるよって例を示したに過ぎない。
多分単に君が知らなかったのであろう、stopコマンドに
>>430 とか
>>440 でやたら噛み付いてきたから、
言い方が酷くなったに過ぎない。
>>451 コンテナが何個あろうが、Dockerfileとマニフェストを書いて、適用するだけ
つーか、コンテナ数が増えたら余計に、コンテナに入ってコマンド実行なんて、やってらんねえわ
それぞれのコンテナに、どんなコマンドで、どんな変更を施してきたか、把握すんの大変だろーが
そういうのもうやめよーぜ、ってんで出てきた考え方がIaaCであって、その実装の１つがDockerなんだよ
なあんで、そこまで進歩したのに、昔の非効率的なやり方に退化してんだよ
>>452 いやだから、そういう話をしたんじゃないっていってるでしょｗ。
非効率で退化しているというなら、Docker社にメッセージ入れてコマンド消して貰えよｗ
もしくは君が入社して消してしまえよｗｗｗ
俺にとっちゃどうでも良い話しだし。君以外のすべての掲示板参加者にとってもそうだろうよ。
Aだけのやり方しか知らなかった人にAとBの道がある、現場で効率が高いほうを選べば良いよって話ね。
>>453 効率の悪いstopはやめようねって話ね
>>449 > DockerfileはSREの責務だから触れないよ。
お前の会社の話なんか知らんがなｗ
Dockerfileだけじゃなくて色んなものに制限があって
開発効率下げてるやろ？お前の会社の問題だ。
いやーコミュ障のニートって本当、大変だよな。
なるほど（笑）そんなレスの勝利宣言（笑）もあるんですね、（笑）
>>457 うちの会社のことはどうでも良いな。
開発効率を下げている、どうしよう、って話をしているものでも無いんだが？
こういう解決策もありますよって話でね。
「ソースに残らねえから、変更が確定したあとに自分がどんなコマンドを打ってきたか思い出して・・・」
ってそういう話をしているものでもない。確定するような作業なら最初からDockerfileの修正プルリク出すし。
>>460 君（なのか君達か知らんが）、に対する俺からの率直な評価だ。
受け取ってくれ。
>>459 ブーメランｗｗｗ
stopが非効率的だと教えていただきありがとうございます、で終わってた話なんだがな
>>463 君が「stopが非効率的」だと考える原因は一体どこ？
>>465 自分でブーメランとか流石やなｗ
「Dockerfileで確定している作業なら最初からプルリク出すでしょ」といっているのに。
Docker-Composeなどでipv6を無効にする方法ってありますか？
apacheでバーチャルホストで２０サイト運用するのと
apacheでバーチャルホストで２０サイト運用するのと
>>471 CPUとメモリに「優しい」ってどういう意味？
少量で済む、という意味なら常識的にバーチャルホストだろ。
バーチャルホスト：OS->Apacheプロセス
コンテナ：OS->Dockerプロセス->コンテナ(薄いとはいえOS)->Apacheプロセス（名前空間で保護されているとはいえコンテナ毎に別プロセス）
独立していて他のプロセスに影響を与えない、と言う意味ならDockerだろ。
最もDockerの親プロセスが死んだら配下のコンテナも死ぬだろうけど。
20サイトを満足に動かすhttpdワーカープロセス数を確保することを考えたらそんなに得かね
すでにDocker関係ないなｗ
473がおかしな方向に持っていくからだろ。
大したサイトでも無かろう
Docker Desktop更新
Windowsってコマンドラインで操作できないの？
LinuxってシェルスクリプトからGUIを操作できないの？
このスレ見てるとコンテナの扱いがわからんなる
>>482 スレを見るのが言けない。
>>1 だけ読んでいればいいよ。それが正しいコンテナの理解だから
自分で全部構築するならDocker使う意味ないじゃんアゼルバイジャン
>>478 githubに動かないってissue投げられまくってるから様子見するのが良いかもしれない
>>1 は「Dockerイメージ（Dockerfile）はアプリケーション開発者が作成します」
これ書いてる時点でIT業界にいない人間な事は明白だろ。
>>484 アプリをデプロイするのが楽になるという意味がありますが？
>>486 アプリを動かすのに何が必要かってのを
アプリ開発者以外が知ってるっていうの？
そういうのをわざわざ調べたり伝えたりするのが
嫌だっていういのがDockerを使う理由のひとつなんだが
Dockerを使えば動かすのに必要なものはコード（Dockerfile）に
書いて終わりですからね
>>487 アプリの開発者がimage作ることもあるけど何でそれ「だけ」を強調するの？って話なんだが？
コード(Dockerfile)に書いてインフラに渡したのならそれがスタート地点でしょ。
そもそもLBで振り分けられられる膨大な基幹システムのサブシステムでしかない
コンテナのイメージを何でイチ開発者が作るの？って話で。
全体との調整はインフラの人しか分からない。
「コンパイル通るようにDockerfile書いときましたよ」と渡せばインフラの人がそれをk8sとかecsとか
オケに乗っかるように修正する。プルリクが来れば開発者とインフラの人がレビューする。
コードがやり取りに使えるから便利ですよ、と言うなら
まあ、合っているが、頑なに「開発者がつくってインフラが動かすだけ」と強調するのは何なの？
そんな事しないよ。
> コンテナのイメージを何でイチ開発者が作るの？って話で。
> 「コンパイル通るようにDockerfile書いときましたよ」と渡せばインフラの人がそれをk8sとかecsとか
>全体ってなんですか？
この業界に居ない人ならではのコメントやな。
全体ってなんですか？って何ですかｗ？本当に分からないの？？
ロードバランサって知ってる？パスベースのルーティングとか分かるの？？
>しません。イメージはどこででも動きます
いや、俺たちやってるし。
そもそも動くドメイン名すら変更されかねない全体部分をロジック作る人が見たりしないし。
そもそも
>>1 もそうなら、
>>489 ,
>>490 もそうだけど、生産性を高めるためのシステムに対して
～はAが行う、と断定口調自体が俺たちの業界とは思えない。
やった方が効率が高い方がやれば良いのであって。何の為のコード化なんだ。
誰かが「便利に使うのが正義」と言った事を幾度も書き込んでくれているのに全く伝わっている様子が無い。
> ロードバランサって知ってる？パスベースのルーティングとか分かるの？？
>>492 ロードバランサ―のDockerイメージは
インフラの人が作ってんるんですがｗ
どのリクエストをどのサブシステムに振るかなんて開発者が知る訳ないでしょ。
>>1 Dockerイメージ（Dockerfile）はアプリケーション開発者が作成します
w
> ロードバランサ―のDockerイメージは
>普通ロードバランサーなんてクラウドの機能使うだろ
>
>仮に自作するにしても、なにでロードバランサー作ってるというのか
>ロードバランサーを開発してるんじゃなくて、Dockerでインストールしてるだけなんだろ？
>何のソフト使ってるか言ってみ
>
>そういうネットワーク性能重視のものは物理・仮想マシン上にインストールするのが普通だし
>インフラでもDockerfile作るんです！ロードバランサー！とか言われても
>え？今どき自社に設置してんの？としか思わんわｗ
>
すべてが全く違うよ。最初の1行目だけかろうじて近いけどそれがIaCで変わってきている
よく上から目線でそこまで間違った意見を自信満々に言えるもんだね。
流石
>>1 ｗ
そもそもこの話は1が「Dockerイメージは開発者が作成する」と間違ったことを言うから、反証を示しただけなんだがｗ
LBの役割自体はどうでも良い。
>何のソフト使ってるか言ってみ
教えて欲しいなら「すいませんがイメージできないので具体的に何があるのか教えてください」だろ？ｗ
俺の気分が良ければ教えてやるよｗ
>>ロードバランサーを開発してるんじゃなくて、Dockerでインストールしてるだけなんだろ？
因みにこの一文は、仮にそうだったとしても
>>1 の「Dockerイメージ（Dockerfile）はアプリケーション開発者が作成します」
に対する反証となっている。実際はもっと色々やるけどね。
> 俺の気分が良ければ教えてやるよｗ
>>497 そこはアプリをインストールしているだけならDockerを使う必要はないということです。
物理・仮想マシンに直接インストールすればいいのです。
なるほど、じゃあDockerは単体ではシステムとして運用する事は全くできず、物理か仮想マシンが
Sleepからの復帰でコンテナが死ぬんだがスリープ入るときに自動的にコンテナ終了させる方法ない？
アプリ開発者はアプリ開発するだけだよ普通
>>502 では、アプリを動かすのに何が必要か教えて下さい。
アプリはwordpressみたいなものです。
私が開発しました（笑）
>>506 ドキュメントに間違いがあって余計な手間がかからないように
Dockerfileという動くコードで提出しました
>>507 アプリ開発者の書くDockerfileは過不足が多いのでだめ
Dockerfileを誰が書くか何てどうでも良い話題だけど
>>509 一人のためにおかしなことになってるね。
nodeとかcondaで恩恵感じてたとこにdocker知った衝撃は計り知れなくて。
想像だけど、あんなふうにあるべき美しい運用方法にこだわる人は法学とか語学修めた人なんじゃないかな、と。
dockerfileはエレガントでなくても動くならそれでいいじゃん、っておれは思う。
>>508 > アプリ開発者の書くDockerfileは過不足が多いのでだめ
過不足とは？ いつも具体的ではな話でごまかそうとしてんなｗ
アプリ屋にパフォーマンスチューニングとかできねえだろｗ
お前の考えが最高なんだろ？ なら良かったじゃん。
> でもな、お前の考えを他人に押し付けんな。分かったか？
多分、書きっぷりからして、Part1の頃からお前はDockerを理解してない！
つかpart1って俺も居ないしｗｗｗ
>>519 ん？じゃあ君の事を言っるんじゃ無いんじゃないの？
きみはDocker原理主義者の自覚でもあるの？
> 2014年-2020年と言えば、俺の取引先会社が資本金100万円で発足して、市場価値100億円になった
>>512 > 過 リソース使いすぎ
> 不足 セキュリティ対策など
アプリ開発者が、リソース使いすぎで、セキュリティ不足だったら
その開発者が作るアプリは怖くて使えないなｗ
それをアプリ問題である、リソース使いすぎやセキュリティ不足を
インフラの力だけで解決できるって？夢見るのも大概にしろやｗｗｗ
インフラがDockerfileを使って解決できる
無理無理
匿名掲示板で役立たずと書かれて即座に自分の事だと
>>524 インフラにとっての高レベル＝
マルチステージビルド等を駆使してDockerイメージのサイズを減らしました！
使ってるライブラリのバージョンが古かったのでイメージ作り直して変更しました！
低レベルすぎｗ
アプリ開発者じゃサーバーのパラメータ調整とかできねーだろうなぁ
> アプリ開発者じゃサーバーのパラメータ調整とかできねーだろうなぁ
アプリ屋はロジックの変更はできてもサーバーパラメータの調整はできない
なんでDockerfileの話でサーバーパラメータの調整が出てくるんだかｗ
サーバーパラメータの調整っていうのはマシンスペックや構成によって変わるもので
データベースのチューニングとかしたことねんだろうなぁ
データベースのチューニングでDockerfileいじると思ってるんだろうな（笑）
すでにDockerイメージ作成済みなのに、どうやって設定ファイルを
公式より
https://hub.docker.com/_/mysql Using a custom MySQL configuration file
カスタムMySQL構成ファイルの使用
$ ｄｏｃｋｅｒ ｒｕｎ －－ｎａｍｅ ｓｏｍｅ－ｍｙｓｑｌ －ｖ ／ｍｙ／ｃｕｓｔｏｍ：／ｅｔｃ／ｍｙｓｑｌ／ｃｏｎｆ．ｄ －ｅ ＭＹＳＱＬ＿ＲＯＯＴ＿ＰＡＳＳＷＯＲＤ＝ｍｙ－ｓｅｃｒｅｔ－ｐｗ －ｄ ｍｙｓｑｌ：ｔａｇ
>>538 ビギナー向けのサンプルコードを真に受けて本番でも使っちゃうやつｗｗｗ
せっかくDocker使ってんのにインスタンス1個1個べっこに設定管理してた時代に逆行してんのマジ笑える
ほらな、やっぱり理解してない
>>542 わかってないのは君だな
君はDockerの流儀にまったく適応できてない
古い考え方のままDockerを使おうとしてる
正解はこれだ
・設定はイメージに埋め込む
・構成によってビルド後に可変にしたいものはコマンドライン引数、環境変数などを通じて変更できるようにエントリポイント、あるいはアプリ自体に細工する
これ、脱初心者を目指すなら必須の知識だから君も覚えておくといい
>>543 はい、そうやって作るからチューニングでDockerfileをいじることはないんです。
>>544 設定を埋め込むものエントリポイントに細工するのもDockerfileの仕事
正確にはassetを編集することが多いがそれも込でDockerfileをいじるということだ
アプリ屋「設定を注入する方法知ってるか？くくく、ヒントはボリューム」ドヤッドヤァアアアアア
公式より
https://hub.docker.com/_/mysql Using a custom MySQL configuration file
カスタムMySQL構成ファイルの使用
$ ｄｏｃｋｅｒ ｒｕｎ －－ｎａｍｅ ｓｏｍｅ－ｍｙｓｑｌ －ｖ ／ｍｙ／ｃｕｓｔｏｍ：／ｅｔｃ／ｍｙｓｑｌ／ｃｏｎｆ．ｄ －ｅ ＭＹＳＱＬ＿ＲＯＯＴ＿ＰＡＳＳＷＯＲＤ＝ｍｙ－ｓｅｃｒｅｔ－ｐｗ －ｄ ｍｙｓｑｌ：ｔａｇ
新人「Dockerfileイジってチューニングやー」
Dockerfileでデータベースのチューニング？
もう邪魔だから隔離スレ建ててそこでやってくれない？
気が触れてるな。
docker exec あとのコマンドを補完できるライブラリとかプラグインってありますか？
DockerfileのLinterはありますが
docker-compose なんかローカルでのテストくらいにしか使わないのにLintもクソもないでしょ
k8sよりcomposeのほうが簡単でいい
設定ファイルが多少簡単だろうと、まともなマネージドサービスがない時点で難易度MAXなのです
fargateは?
Fluent Bit supports Amazon S3 as a destination to route container logs
大切なパスワードを保存したイメージを間違ってdokerhubにうｐしちゃったらどうなるの
どうやったらそんなミスをするのかって悩むレベルだなｗ
dockerの理念的に
>>570 dockerイメージ＝プログラム（exeファイル）と考えればいいんだよ。
exeファイルの中に消えたらいけないデータを保存するかい？しないだろ？
つまり保存するデータはdockerイメージの外に保存するんだよ。
それがボリューム。ボリュームっていうのはdockerイメージを起動するときに割り当てる。
例えば任意のディレクトリをボリュームとして使うことができる。
exeファイルを実行するときにデータディレクトリを指定しているようなもんだ
こうやってdockerイメージの外のリソースを起動時に割り当てることで
dockerイメージ内部からはどこで動かしても同じように見えるようになるわけ
ちなみにデータと設定ファイル（アプリ実行中に保存しないもの）は別な。
設定ファイルはdockerイメージに埋め込んでいい（場合によっては外に出すこともある）
>>571 >dockerイメージ＝プログラム（exeファイル）と
なるほどそういうことなんですね
＞任意のディレクトリをボリュームとして使うことができる。
容量に余裕のあるHDDを指定して永続的に保存なんてこともできるのですね
アプリの設定を変えたあとその設定も他の環境でも共有したいとなると
イメージまるごと共有するか
クラウドに設定を保存するとか
ですかね
（chromeブラウザとかだとログインすればすぐ同期されていい感じなのですが）
ありがとうございました
そんなゴリゴリに使い倒すつもりはないからホストPCのシステムディスクって２５０GB（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を共有すること自体がないから
イメージ作成したときにダウンロードしてきたイメージはどこに保存されているの？
最初にイメージの格納場所のサイズを設定するだろ。
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では成功したのになあ
補足
たぶん/my/のパスが間違ってるってことだよね
改めてやってみたら
python使いたいだけなのに８８６MBって重くない？
alpineベースのPythonは扱いが難しい
python:3.7-slim
つけるだけでいけたの前にdocker-hubくらい見ようよ
ん dockerhubみたら
Docker Hubを見るのも当然だし、大元のDovkerfileを読もうよ。
謎の現象に苦しんでいます。
>>594 自己レスです。
オリジナルの/var/spool/hylafax 内に、pipeファイルがあります。
prw------- 1 uucp uucp 0 Sep 19 2018 FIFO
これが原因で、ボリュームにサブディレクトリも含めてコピーがされない可能性はあるでしょうか。
pipeを削除したイメージを作ってやってみれば原因かどうかわかるんじゃないの
>>594 基本的な話として、
ホストの/etcや/varをDockerコンテナの中にマウントしてはいけません。
厳禁といってもいいレベルでダメです
/etc や /var 以下の必要なものだけをマウントする場合はギリOKです。
ついでに言っておくと/etcや/varなんかをDockerコンテナに
>>594 >― mount source=vol_etc,target=/etc --mount source=vol_var,target=/var
なんで、こうするのか、理解に苦しむわ…。
とくに、 /var をなぜVolumeにする？
意味がわからない。
Dockerを仮想マシンか何かだと思ってるんだろ
仮想マシンでvar とかetcの共有なんてしないけどね。
だから仮想マシンとしてログイン（？）して使いたいけど
もうめちゃくちゃだなこいつ
>>594 Dockerのmountとかvolumeってのは、システムの可変の部分を定義することね。
/var/www/html 配下をマウントして、中身はプライベートなgithub/gitlabとかからpullするとか。
或いは/etc/nginx/conf.d配下だけをマウントして独自の定義ファイル置くとか。
例えホストと同等のゲストを作りたいと思ったとしてもホストのetcとゲスト（コンテナ）のetc全く別物ｗ
/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ログインできるように設定しました。
>>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を
>>629 そもそもここで使いたいと期待するUSER変数がdocker buildを実行するホスト側
のユーザーなのか、コンテナ側なのか分からないんだが・・・
そういうこと。仮想マシンがあるのに
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に移行なら昔やった
俺は横着なのでDockerfileが構築手順書がわりになる方が便利
>>626 直接マウントするのはハードウェア1つにつきコンテナ1つだけ
マウントしてるコンテナが他のコンテナにサービスとしてファイルアクセスを提供する
排他制御とかもその1つのコンテナが全部引き受ける
>>636 dockerに限らずIasCって必ずしもコストパフォーマンスがいいとも限らんからな
自動化の制御が複雑になるなら手作業で設定してコミットしちゃったほうが簡単だって考え方は十分ありだと思うよ
IasCに疲弊してる企業が、よくよく考えたら本当に欲しかったものはサーバーの状態をexp impする機能だった
>>643 ホストディレクトリをマウントしているコンテナが、
他のコンテナにサービスとしてファイルアクセスを提供するには、
XFSとか、Sambaとか、排他制御ができるというオンラインファイル共有サービスを公開するということですか。
なるほど、じゃあ、ボリュームをマウントしたコンテナが、
それらの共有サービスを公開すれば、他のコンテナでもボリューム内容を共有できますね。
>>644 >IasCに疲弊してる企業
Docker原理主義者の言うことを鵜呑みにしたのかしら
アプリの設定ファイル作成をコード化するなんて頭おかしいとすら思えてしまった。
>>645 オンライン共有サービス？ ストレージサービスとかいう名前でいいだろｗ
アプリ用コンテナとデータベース用コンテナは分けて
それぞれコンテナ＝1サービスにしろっていうのはそういうこと
>>646 それはあなたの感想であって、意見や主張は何も含まれてないですね
最初からDocker前提で書いてればそんな難しくはない
>>647 でも、データベースの場合は、SQLコマンドのやり取りだけなので、データベースのデータファイルを直接オンラインストレージサービスで共有する必要はないよな。
排他制御を行うためにストレージサービス（XFS, samba）を使う場合は、ファイルレベルでの取り扱いが必要な場合だけだよね。
レガシーの移行はいっぺんにやろうとするな
>>647 でも、そもそもどうしてコンテナには1サービスしかおいたら駄目なのか？
例えば、名前解決させるのにdnsmasqデーモンが別途必要だとすると、これで複数サービスになってしまう。
アプリケーションという概念は、様々なサービスの組み合わせが本質だから、可搬性を考えても、それらをワンコンテナに組み込むのが自然だと思う。
即ち、データベースとwebサービスは同一コンテナにしてもよいでしょということになる。
>>647 ストレージサービスだと、iSCSIも含んでしまう。
排他制御ができるファイル単位サービスということで、オンライン共有サービスと言った。
>>626 ホストの同一ディレクトリを複数コンテナでマウントするだけでしょ
排他もかかるよ
>>652 その考え方で概ね正しいよ
好例としてGitlabのオフィシャルコンテナも1コンテナにすべてのサービスを詰め込んで1コンテナ：マルチサービスで動かしている
そして内部的な構成管理ツールとしてChefを使っている
これは1コンテナ：1プロセスという無意味なプラクティスには反するが現実として非常にうまくいってる
ただしこの構成だと特定のコンテキストやレイヤーを抜き出してそれだけスケールアウトするのが難しくなる
デメリットはせいぜいそれぐらいしかない
よく言われるのは1プロセスじゃなく1サービスだろ
mysqlとかphpmyadminとか既存のDockerイメージあるじゃん？
>>652 > 即ち、データベースとwebサービスは同一コンテナにしてもよいでしょということになる。
する理由がない
複数コンテナを結合できるのに、一体化させる理由がないんだよね
複数コンテナをつなげるのは簡単だが、一つになってるものは分離できない
・複数のコンテナをオーケストレーションしないと使えないサービス
更に既存資産があれば作るのも楽々だ
>>659 docker -composeも使えない猿未満の方？
DBは本番だと別サーバーな事も多い
流行ってるからでぇ～すｗｗｗ
>>661 なぜ使える使えないという個人のスキルの話に脱線するのか意味不明だよ君
dockercomposeを使わなくても簡単に動かせるならそちらのほうがいい
より簡単な方はどっちなのか？
答えは誰でもわかる、単一コンテナのほうが簡単
>>662 ケースバイケース
既存資産があるなら1つにまとめてしまったほうが楽な場合がある
Gitlabのように戦略的に単一コンテナを選ぶ場合だってある
何でもかんでも分割すりゃいいってもんじゃない
>>664 論理的じゃない
簡単に動かせるならそちらのほうがいい・・・とは限らないだろ
>>665 分割したほうが再利用しやすいという話だ
>>666 いやいや
同じ機能が手に入るなら簡単であればあるほどいい
難しい構成が許されるのはそれに見合う目的が必要
つまりデフォルトは限りなくシンプルに簡単に
細かくチューンナップしたいなら難しい構成を許可する
という順番がある
最初から難しい構成を押し付けるのはクソ製品
> 同じ機能が手に入るなら簡単であればあるほどいい
>>667 そうとも限らない
Gitlabコンテナは世界中で再利用されている
再利用するのにまったく困ることがない
もし仮にGitlabコンテナを構成するサービスが別のコンテナになっていたらオーケストレーション構成を考えるのが面倒で再利用に余計な手間がかかってしまう
× Gitlabコンテナは世界中で再利用されている
そらしてないなぁ
Gitlabは本当によくできている
>>674 そらしてる
今はGitlabコンテナの話をしてる
Gitlab.comのサービスの話はしてない
だから大抵の人にとって一番簡単なのはGitLabサービスを使うことだろ
>>654 ボリュームを複数コンテナでマウントするだけでは排他制御されない。
ホストディレクトリをコンテナにマウントしても同様に排他制御はかからないのではないか
GitLabは全部一緒くたになってるから
>>677 またトンチンカンなことを
Gitlabサービスを使う話はしてない
コンテナの構成として1コンテナマルチサービスの是非を議論しているのにマネージドサービスと比較してどうすんだよ
本当に意味不明だよ君
今の話の大前提は「DockerでGitlabをセルフホストする」ことだ
マネージドサービスの話がしたいならスレ違いだからさっさと別のスレにいけ
>>654 排他制御の意味が違ってる。
例えばMySQLを2つ起動したとして、同じディレクトリを
参照していたらデータが壊れるだろ
ファイルは壊れなくてもデータが壊れる
github使わずにgitlab使うのは自社サーバで運用したいケースが多いんじゃね
>>681 > 今の話の大前提は「DockerでGitlabをセルフホストする」ことだ
ほらなｗ また条件つけた。
つまりこいつにとっての「使いやすい」の基準は
「DockerでGitlabをセルフホストする」場合の話であって
誰かのためにサービスを運営する（つまりGitLabサービス）のようなものには
当てはまらないということだ
開発者なら「誰かのためにサービスを運営する」だろ？
>>680 間違って消しちゃたら困るのは纏めてようが分けてようが同じ
バックアップはgitlabのコマンドラインツールを使う方法、ボリュームをバックアップする方法がサポートされている
いずれの場合も、対象が1つのコンテナにまとまってるから簡単にバックアップできる
もし、これが複数のコンテナに分量外していたら、それぞれのコンテナについてバックアップを考えなければならないので大変だ
> バックアップはgitlabのコマンドラインツールを使う方法、ボリュームをバックアップする方法がサポートされている
>>684 条件を付けた？
最初からこの条件で話してたらお前がマネージドサービスとの比較などというズレまくったトピックを持ち込んできたんだろ
いい加減にしろ
>>687 お前は他人が用意したものを使うだけの話をしてるが
こちとらDockerfileを「作る側」の話をしてるんだよ
それはGitLabサービスと同じ立場だ
一つにまとめれば作るのが簡単？
GitLabのバックアップの件からも特殊なツールの開発が
必要になるってことがわかったよなｗ
>>686 考えが浅すぎてため息しかでない
なにが一般的な方法が使えるだよ
Gitlabの管理するデータはDBだけじゃない
リポジトリデータやその他のサービスのデータも管理してる
これらを個別に管理したら大変だよ
個別に簡単に管理できるならGitlabはわざわざバックアップコマンドを用意したりしねーよ
少しは考えろ
>>688 作る側ならより慎重に使う側の都合を考えろよ
使う側に知識と労力を期待するのは三流の開発者だ
Gitlabの開発者はdocker runさえ知ってればGitlabを動かせるように整備した
これが一流の開発者だ
ああ、使う側って自分で開発したアプリでサービスを運営するって考えがないのかｗ
>>691 利用形態は外向けサービス運営だけじゃない
むしろサービス運営のほうが圧倒的に少数派
どんな企業でも開発用の社内システムを持ってるがサービス運営をしているとは限らない
社内システムでは導入の手軽さと運用コストがまっさきに検討される
こんなことにすら考えを巡らせられないのか？
浅い
浅すぎる
自分たちで作って自分たちだけで消費してるから不特定多数にイメージを使ってもらうという想定ができないんだろうな
GitLabの公式イメージが気に入らなければ
k8sでHelmチャート版使うか非公式の方入れたら良い
https://github.com/sameersbn/docker-gitlab 既存のPostgreSQLとかRedisを使いたい！って要望に答えられないので
こういうものが作られる当然ではある
SMTPサーバーは流石にごった煮版の方もない
こればかりは一つのコンテナ内でどうにかならないからか
別にSMTPサーバー立てたり外部サービスを利用が必要
>>632 ありがとうございます！
ちなみにもう一つ質問なんですが
シェル変数に渡せないことがあるんですが全てのシェル変数には対応できないんでしょうか？
$UIDとか
>>682 排他ロックがかかるという意味で言ってる
>>699 UIDやGIDが何ものであるか、考えてみてください。
>>701 通常ディレクトリでも、libreOfficeでファイルを開けばロックファイルが作られる。
アプリケーションレベルでのみロックが掛けられると思う。
viでも編集中のファイルは、ロックファイルが作られるよね。
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とかのコンテナを使いたいんだけど、そういう事出来るんでしょうか。
> DockerでCentOSのコンテナを起動、そこから、nginxとかpythonとかのコンテナを使いたいんだけど、
Dockerっていうのはな、アプリを作るためのものなんだよ
>>712 Docker in dockerかDocker outside of dockerというテクニックを使えばコンテナからコンテナを扱うことができるが
君が本当にやりたかったことはおそらくただのdocker composeだろう
いつものDockerを仮想マシンと勘違いしてるやつだろ
>>716 devcontainerを使ったことないのか
>>716 それは言い過ぎ（とうぜん、アプリにsshログインなんてしない。）
アプリを取り巻いている環境がコンテナにあるわけで、
それを調べるためにsshログインすると便利
なるほど。
>>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ダラーに引いたｗ
たった55題でその値段とか冗談でしょ。
>>726 資格持ってるやつほどできなさそう
発想ゼロで創造性なさそう
外国のベンダー試験は死ぬほど実務的。
前から言ってんじゃんこれからはpodmanだって
> これからはpodmanだって
Docker は、namespace, cgroup, overlayfs を使っている。
>>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ローカルサーバー動かそうと思ったけど
Ruby なら、コマンドプロンプト・PowerShell から、1-liner で、
Rubyで作られた遅いウェブサーバー、WEBrick が起動する
ruby -run -e httpd . -p 8080
そのフォルダに、index.html があれば、これでブラウザからアクセスできる
http://localhost:8080 ローカル回線だけでしょ。
ひょっとして、外部からアクセスさせるの？
外部なら、AWS のKubernetes, VPC のインターネット・ゲートウェイとか
compose使ってるんだけど毎回cdするの面倒くさい
>>737 回答がお門違いやな。"play with docker"って言ってるでしょ。
でも
>>736 のやり方じゃnginx とpythonを別々に動かしてるだけだから
アクセスは出来んわな。pythonとnginxをセットにしたイメージをdockerhubから
探すしかないんじゃね？
外部に公開するのは、
nginx, python の組み合わせは、珍しい。
>>726 ググってみたが、資格のページ無くないか？
podman 見た感じだとわるくないんだけど、Red Hat のかじ取りというかやり方が微妙であんまり流行らないだろうなとは思う
pythonでdjangoとか使いますし
>>734 > podmanになるかは知らないけどDockerが何かに置き換えられるの可能性はあるだろうね。
当たり前だろ。「いつまでに」って期限をつけないならいつかは置き換えられる。
Linuxだって置き換わるだろ。100年後、200年後までLinuxのままだとは思えない。
>>742 https://prod.examity.com/docker にある。アカウント作ったら入れる。トラブったらチャットの人が即座に解決してくれる。
>>745 そういう非現実的な話はしてないな。
デーモンじゃマズイ、と言っているんだからその問題が無視できくなれば
置き換わるだろ、と言うか自分たちが作ってるクラスタは置き換わってるし。
（あるバージョンからコンテナランタイムのDockerが消えた）
>>744 まあそうだよね。
nginx+pythonで珍しいとか意味が解らんね。
自分が使ったことない物をめずらしいって言ってるだけだろうから無視していいよ
>>747 だから世間がいつまでに置き換わるか言ってみ
当たるか当たらなかいかじゃなくて、お前がどれだけ
自分の説に自信と信念を持ってるかを判断してるんだよ
それとDockerはrktに置き換わるんじゃなかったっけ？ｗ
pylay with dockerでdjango+mysqlいけたけど
ロケットのおなじみの画面が表示されなくてALLOWED_HOST=['*']にすればいけた
あとchromeだと
http:// が弾かれることに気づかず（表示できたりできなかったりするので）めちゃくちゃハマった糞が
>>731 知識は役に立たないけど、経験は役に立つということなんだろうな。
Dockerコンテナ作れるから、もう安心ということにはならないな。
また、別の新しい技術が登場する。
前の知識は役に立たない。
役に立つのは、試行錯誤や理解に必要な経験だなあ。
こういうのを結晶化なんとかというのだろう。
表面的な知識は異なれども、それを成り立たせる思想には共通するものがある。
こう考えると、特定のアプリ技術に関する資格なんて無意味だな。
IPとか、低レベルの技術はなかなか変容しないから、そのあたりの資格はあっても良いと思う。
>>753 代替ツールを流行っても居ないのに、これからはこれ！とか
言ってる奴は大概、役に立たない知識で終わっちゃうよね
ツールの使い方じゃなくて、考え方を理解してる人は、
後からでもすぐに理解できるから、焦って未熟な段階で使う必要がない
ノウハウがたまってバグがあらかた解決してからでも遅くないし
Docker, Docker Compose は、本番では使えないから、
dockerの入門書に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も酷い
fluentd_v1.11使っているが2週間くらいでElasticにデータ渡さなくなる症状に悩まされているよ
k8sとかが、いったい何をしてくれるのか全然わからない。
クラスタ組まないならcomposeでおｋ
k8s は、Auto Scale, Rolling Update, blue/green deployment
>>770 やっぱり、遠い話、雲の上の話
ぜんぜんぴんとこない
docker環境で開発をしている人に質問なのですが
動画配信サイトとか高負荷かつ安定稼働を求められるシステムなら採用する価値はあるかもね
>>772 開発と言っても「実機と同等の構成で動かしてみる」というのも含まれるけど
一般にソースコードを修正してデバッグしてみたいな開発作業中は
Dockerを使わないよ
今はWindowsでもWSLがあるし、Dockerを使わないで開発やテストができる
いちいちDockerの中に開発ツール（ビルドツールやらlintツールやや）
入れなくていいから一番快適だしね。
その上で開発プロセスの一環として実機に近い環境で
テストしたいときはDockerを使う
>>772 テストはイメージ作ってやるから問題ないよ
K8Sは金がふんだんに有り余ってるようなところが使うようなイメージ
>>772 Dockerfileは同一で、開発時はソースコードをADDしてるディレクトリに、バインドマウントしてあげるだけで良いのでは。
>>777 そう簡単な話ではない。開発用イメージには、運用用イメージに加えて
開発用のツールやライブラリを含めなければいけない
どちらにしろ、開発用イメージはそのまま運用で使うことはできない
>>778 うん、そういうケースがあるのは分かるけど、ライトなWeb開発とかだとこれで必要十分なことも多いよね。
あとは商用向けはマルチステージビルドで成果物だけ持ってくるとかできるし。
開発者の裁量で好きなように開発すればいい
>>772 >本番環境は別にdockerfile(もしくはdocker-compose.yml)を作っていますか？
別です。
開発環境のDockerは本番機よりもっと簡略化されている
サーバー証明書もオレオレ。
あくまでも、うちのケースの話ね。
>本番環境ではソースコードをイメージの中に入れたいのですが
>開発環境ではソースコードはホスト側に置いて、マウントしたいです
それで良いんじゃないの？
開発環境はdocker-compose.override.ymlで開発担当部分のみvolumesで上書きとか。
>とはいえ別ファイルにすると(ソースコードをマウントしている)開発環境では動くけど、(ソースコードをイメージの中に含んでいる)本番では動かない
という可能性も出てきてしまう気がして..
何故、開発機の次が本番機なのさｗ？
テスティングやステージングは？問題があるなら、そこでわかるでしょう。
k8s は、マスターは多数決で決めるから、分散数は奇数にして、3, 5, 7 個
Ruby on Rails の場合は、Heroku, Cloud9 が最短。
ネットワーク分断の場合に、
そろそろスレチと言う気がしてきたな。
Kubernetes 航海1日目
http://2chb.net/r/linux/1553389453/ 超過疎スレなので来てやってください
>>786 奇数から1台死んだら偶数になって多数決で分断が起こるのでは？
docker pull django:latestってやるとバージョンが1なんですけど
>>789 多数決と言っているのはクラスタを構成するノードに対する比率を言っているのでは？
３ノード構成で２ノード生きているなら継続するよ、と。
あと分断耐性で言っているのはネットワークなので必ずしもノードが死んでいるとは限らない様な気がする。
クライアントからノード１、２には到達できるけど、３に到達する為のルーターが障害とかね。
>>792 いえ、どうして２でもなく３でもないのかな、と。
これならdockerhubからよりもベースpythonでpipしないといけないような
>>793 django2とか３とをpullすりゃ良いんじゃね？
https://hub.docker.com/_/django DEPRECATED と大書きているだろうが。
はい非推奨は知っていたのですが
非推奨と書いてあるのが読めて最終更新日からどれだけメンテナンスされてないか確認できたら
その判断の仕方だとどちらにも取れるのでは
「自分の環境にとって許容範囲かどうか判断できるだろ」って意味じゃないの
それはdjangoのほぼ全部の仕様把握してないと無理
Django のバージョンが分からないのは、おかしい。
どうして急にRoRの話しだすの... こわいんだけど
RoRの事しか知らないからだろ。
Dockerを仮想マシンのよう使う人って未だに居るんだな
べつにいいでしょ
仮想マシンのように使うって具体的にはどういうことなんだろ
Docker, Kubernetes は、immutable。
ググった単語を色々並べて、頑張ってるなｗ
>>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でコンテナ止める時って結構時間掛かるのに
>>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で、デーモンのスケジュール再起動を任せたら、
>>811 香具師／野師／野士／弥四（やし）とは。
意味や解説、類語。盛り場・縁日・祭礼などに露店を出して商売したり、
見世物などの興行をしたりする人。
また、露天商の場所割りをし、世話をする人。
的屋 (てきや) 。 - goo国語辞書
そういうことじゃないから...
>>818 コンテナ内で何のプロセス動かしてんの？
>>822 iaxmodemだけなら小さい消費だが、
それらをfaxgettyさせてhylafaxに接続すると、
5倍くらいに膨れ上がった。
コンテナ内でのサービス再起動時にメモリが溢れるってのもよくわからんが、そのサービスの再起動の動作が特殊なのかね
>>824 参考になります。
iaxmodemが始動されると、プロセスが生成されます。
その後、hylafaxを始動させて、
さらに別途faxgettyによって、両者を連結させるイメージです。（3者登場します。そのうち、iaxmodemと、faxgettyはたくさん。hylafaxとは、多対１の関係になっています。）
>>823 のように、iaxmodemだけでは専有容量は僅かなんですが、
faxgettyさせると、膨れ上がります。
faxgettyは、hylafaxの関係者なので、
hylafaxがガーベージコレクトするようです。
以前テストした結果は、hylafaxの再起動時には、直ちにfaxgettyプロセスは消滅しました。
しかし、今回の環境ではそういう風にならなかったようです。
前回の環境はCentOS6でネイティブ、今回はCentOS7でコンテナです。
iaxmodemや、hylafaxのバージョンも上がっています。
いずれにしても、デーモンの再起動が特殊です。
逆に考えて、ネイティブ環境でも他の要因で同じ問題を引き起こすなら、
コンテナ環境であってよかったと思います。
docker restart faxContainerをcrontabでコンテナの外側ホストでスケジュールすれば良いのですから。
コンテナ内部でそういうデーモンの消滅のスケジュールを組むと、イメージ化されていることからタイミングの変更が困難になるので、
せっかくの利便性を損なうと思いました。
docker restart faxContainer は素晴らしいです。
俺はどちらかといえば「Dockerコンテナは仮想マシンじゃない」方の思想に近いから
Linux上でchrootを仮想マシンと思うやつは、どうにかしている。
>>826 荒れるっていうか・・・・
その事に対してコダワリ持ってるのって一人だよね？
殆どの参加者は、そもそもどうでもいい話題で、そいつの書き込みに
反応するのは、そいつがなぜ、VMじゃないからどうのこうのと反発する
必要があるのか分からないから。
イスラム原理主義者に向かって暴力行為やめろよ。そもそも宗教なんて
どうだって良いだろ？と言うのと変わらない。
0番の親プロセスから連鎖的に、必要な環境（ディストリ標準体系）を組みた立てていくということを、「仮想マシン」とよんでいるだけですよね。
>>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まてやるとか無駄の極み
コンテナ内でsupervisordとか動かすのはアンチパターン
>>833 ごった煮版は手軽に試したい人向けだろ
まともに使いたい人はhelmチャート版か
よそのDockerイメージ使えって事だろう
>>834 つまりマルチプロセスなら手軽に使えるコンテナが作れるわけだよね
ということはコンテナ分割と利便性はトレードオフの関係なんだよ
このことを無視してごった煮はダメだアンチパターンだとわめき散らすのは典型的な解ってない人
>>835 helmチャートとかdocker-compose.ymlで配布してくれた方がカスタムしやすい。
ログやCPU使用率も各コンテナで分かれるので見やすい
よって利便性も複数コンテナの方が上
docker-composeで試せるものが
ほれみろ。仮想マシンのような使い方をした結果
>>836 カスタムはある程度は環境変数とかでできる
高度なカスタムが必要なら勝手に非公式で頑張れ
ほとんどの人は公式ので十分だ
オーケストレーターごとにマニフェストを用意しなきゃならんのは面倒だ
オーケストレーターを選択するのも負担になる
マルチプロセスならdocker runだけでOK
これ以上にかんたんなものはない
>>837 コンポーズだとファイルが必要だし内容の理解も必要
docker runはファイル不要で面倒なことは考えなくていい
これ以上楽なことはない
ここで仮想マシンのような使い方をしようとして
>>840 Dockerfileでたくさん面倒なことしてるだろ
docker-composeはyamlファイルを持ってくるだけ
Dockerfileと違って中身を理解する必要がない！（笑）
では分割コンテナでいいから質問者が求める構成を提示してみて
>>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 ファイルをコピーするのが難しいって話をしてんの？ｗ
docker runで引数をたくさん指定するのと、その引数がファイルに全部書かれてるから
docker-composeするだけで起動できるのと、どっちが簡単ですかって話なんだが
docker-composeも使えない男の人って…
Linuxでdocker使ってるんですけど
>>818 そのものズバリの「?oom-kill-disable」なんつーオプションがあるらしいね。
https://knowledge.sakura.ad.jp/5118/ --memory=1024mb
コンテナにこの辺掛けたらどうなるか、興味深いところ。
ホストが死ぬなんてことはなくなるのでは。
また、仮想マシン厨が出てきたw
>>854 oom killerせず、スワップも貧弱なら、
oom-kill-disableすれば、「盾と鉾」の話になりそうですね。
いろいろと興味深いオプションありますね。
>>855 OOM killer も、k8s の基本 って
どういうことだろう？
OOM killer を無効にしてメモリが足りなくなったら
k8s のLimitRange で、各Pod のCPU, メモリの使用量を制限すると、
だから、仮想マシン厨がやってる事は、
OOM killerに殺されて転生したらPodでした
全て一つのマシンに配置する事も
K8S使うまでもないんやけどコンテナで運用したいんやがどこのサービスがええのん？
>>864 一台しか使わないならdocker-composeでもよくね？
それともマネージドサービスが使いたい？
ならコントローラーが無料のサービスを選ぶとよい
Amazon ECSは無料
Azure Kubernetes Serviceも無料らしい
Google Kubernetes EngineはZonal Clusterなら一つは無料らしい
dockerコンテナ一つで終わるなら、dockerをデーモンで起動すればいいし
当然、Heroku 相当のPaaS、AWS Elastic Beanstalk
Fargateがベスト
自分でオーケストレーターをインストールするのか？
Herokuはvolume使えないんだろ
古いプログラムソースのファイルアクセスをクラウドストレージアクセスに書き換えるのがめんどくさい
>>872 クラウドストレージが何を指してるのか分からないけど
単にホストがストレージをマウントしてDockerのvolumeか
mountで逃がせば良いんじゃね？
>>873 ホストに依存したくない
コンテナの中だけで解決できないか
コンテナにrcloneでも入れればいい
dockerでボリュームマウントすると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 までも、全自動にする奴。
ユーザーを、docker group に入れるのだろう。
関数で実装できるならコンテナもいらねえ
>>887 ECSならELBに登録するのが一般的な設計パターン
ロードバランサーが必要になる代わりに、空きポートがランダムに割り当てされるので、衝突することが無い
awsvpcネットワークモードにすればタスク毎に独立したIPになるが、
EC2の場合は1つのタスク毎に仮想ネットワークインタフェースが必要
>>889 Fargateは
料金がEC2より少し高い
EBSボリュームは利用出来ない
特権が必要な設定は利用不可
などの制約があるので万能ではない
ロードバランサーの存在は結局意識する必要があるのも何かね
何れにせよロードバランサは使うので問題ない
運用まで真面目に考えるとdockerもそんなに便利なもんじゃないね
全体の2割が解決すれば十分じゃん
問題は2割を多少楽にするために余計な厄介事まで持ち込んでくること
全体の2割を解決するために5割の新しい問題を持ち込んでるのが実感。
厄介事じゃなくて、技術力ないやつが切り捨てられること
クラウドリソースを使わせたいベンダの戦略にまんまと載せられてる
マジでそれ！
くろかわこうへい、2019/7
今から追いつくDocker講座！AWS ECSとFargateで目指せコンテナマスター！〜シリーズ1回目〜
ダウンロード＆関連動画＞＞ VIDEO 彼は年明けから、会員制のAWS の初心者向け講座を始めるらしい。
彼は、Amazon の21万円のAWSの3日コースも受講したみたい
>>900 投じた21万を広告収入で回収しようと必死やなｗ
くろかわのAWS 新講座のモニター受講生には、千人が殺到した。
とおもったら、
>>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割ぐらい株価が上がっているのでは？
ファイル編集した後にイメージ消してから
ボリュームマウントしてるとか
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 なら、
>>916 GPU付きインスタンスの例とか書いてるじゃん
VPCとかIAMロール、ALB、セキュリティグループの設定は流石にこれでは出来まい
リンクされているAWSのブログを見たらIAMロールは新規で作れるようだ
>>921 なんで？コンテナでデプロイするの便利じゃん
GPUで機械学習とかやりたい人居るだろ？
>>922 デプロイ先を選ぶようなコンテナはコンテナでなくていい
NVIDIA Container Toolkitを作ったNVIDIAが馬鹿だとでも？
EC2一台で動かすようなシステムなんだけど、git pullでソースコードもdockerfile docker-composeも持ってきて、ソースコードマウントして動かして大丈夫？
問題あるかもしれないしないかもしれない
AWS CodePipeline(CodeCommit/CodeDeploy)
>>929 そんなことしても
面倒くさいだけで節約にならなくね
ディスクは…レイヤーの掃除しなくていいかな？その程度の差だね
定期的に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だけ入れれば動くからね
毎回本番サーバーでソースコードの入ってるディレクトリをマウントしたり
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もそろそろオワコンかもな
>>960 Dockerの本来の対象である
アプリケーションサーバーはどこに行った？ｗ
サーバー用途は諦めて、ユーザーへのアプリ配布に活路を見出そうぜ
Dockerはアプリケーションサーバー用途が一番適してるんだって
一番かは別として、コンテナにしてデプロイ～はよくやる動作ではあるだろ
>>962 それだと利益が出ないんだよな
オンプレミスでもライセンス料取れるほど価値のあるサービスって難しいよ
折角今まで孤軍奮闘してきたDockerがイメージ配布で立て直そうとしたのに
Dockerはマイクロソフトあたりに買収されれば安泰じゃないか
>>965 関数ってなんだ？
関数だけでアプリケーションサーバーが作れるのか？
railsを関数とやらで動かしてみてくれよ
>>967 > Dockerがイメージ配布で立て直そうとしたのに
なんか勘違いしてそう
Dockerの言うイメージ配布というのは
自社開発アプリのデプロイという意味だぞ
なんかフリーソフト配布みたいなものと
勘違いしてる感じがするんだよなｗ
>>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 関数はバックエンドだよ
僕たちはバックエンドで実行される、処理だけ、を書きたい
Ruby on Rails は、バックエンドを勉強している香具師が、
そうじゃない
関数じゃ無理があるな
>>986 使えるだけであって使うべきものではない
Webサイト構築にdocker使うとやっぱりオーバーヘッドありますか？
どんなものでも、オーバーヘッドがゼロのものなんてない
docker-compose.ymlの入ったディレクトリに移動して端末で
docker-composeのservices名って
>>990 docker-compose down --rmi all
WSL2ベースのDockerはまだβ版のような出来
どうしてもWindows使わなきゃならんならhyperv安定
docker-composeでbuildしたとき
>>998 ！
まさにっていうオプションがあったのか やってみる㌧
pipに限らずaptやyumでも同じことだから
このスレッドは１０００を超えました。
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
このスレへの固定リンク： 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枚 」 を見た人も見ています：・Docker Part5 Docker Part6 Dockerを教えて下さい Dockerに関する質問スレ docomo版 RIM BlackBerry Bold 9900 Part6 【Luka】Dallas Mavericks 46th【Doncic】 【Doe-doe】Dallas Mavericks 50th【Maxi】 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 136 HackerNews Slashdot reddit 4chan 観測所 PRT・ROCK CITY・ROCKADOMスレ Part 123 【IT】「OpenStack」と「Docker」、2017年は普及元年に マサ伊藤のPRT・ROCK CITY・ROCKADOM 2019/7 仮想環境コンテナ総合スレ Docker、Vagrant等 DOUBLE DECKER！ ダグ&キリル バディ3人目 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 144 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 126 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 141 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 116 Don't look back in anger.という神曲 【IT/セキュリティ】Docker関連の脆弱性、仮想通貨「Monero」の採掘に悪用か マサ伊藤のPRT・ROCK CITY・ROCKADOM 2019/10 マサ伊藤のPRT・ROCK CITY・ROCKADOM 2019/08 【 MACKEREL HAS BEEN DOWN 】リブート部隊連絡所 -- Count 02 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 82 【MACKEREL HAS BEEN DOWN】サーバダウン情報 04 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 73 LXD コンテナを仮想マシンとして使う (Not Docker) 【IT】国内でDockerコンテナを本番利用しているのは9.2％ DOUBLE DECKER！ ダグ&キリル バディ4人目 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 99 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 103 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 100 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 145 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 92 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 115 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 117 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 140 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 110 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 116 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 102 マサ伊藤のPRT・ROCK CITY・ROCKADOMスレ Part 119 プログラミング言語「ruby」の人気が復活、dockerなど併用で欠点はほぼ解決したためか 「Rainmeter」「Samurize」「Mac風Dock」…デスクトップ改造は何故廃れた！？ 【 MACKEREL HAS BEEN DOWN 】リブート部隊連絡所 -- Count 02 【芸能】リアム・ギャラガー、ノエルに続いて“Don’t Look Back In Anger”の収益を寄付 WACK総合スレッド Part808【BiSH/GANG PARADE/EMPiRE/BiS/WAgg/PEDRO/CARRY LOOSE/MONSTER IDOL】 Docker Docker代替のpodman専用スレ （Dockerの話題禁止） (58) WindowsワームConfickerは今でも世界中で広がってる NixOS・Nix Package Manager Part1 IDOLMASTER 黒犬獣を語るスレッド その47 BLACK DOG 【淫乱屋敷】DICK/DOGG【ハッテン】5 【淫乱屋敷】DICK/DOGG【ハッテン】6 TOKYO LOCKDOWN 【dog】ＧＱ男が時計を語るスレ43【kick！】 【dog】ＧＱ男が時計を語るスレ27【kick！】 【悲報】NewsPicksさん、KADOKAWAから抗議を受けてさらなる特集を組んでしまう 【dog】ＧＱ男が時計を語るスレ38【kick！】 ダウンジャケット 2023AW 【down jacket】 【淫乱屋敷】DICK/DOGG【ハッテン】 ダウンジャケット 2019AW 【down jacket】 3着目 【WACK】ANTi STYLE IDOLS【ASP】Part4 【JYP】Stray Kids part7【Back Door】
16:25:02 up 69 days, 17:23, 0 users, load average: 12.66, 12.05, 12.56
in 0.056589841842651 sec
@0.056589841842651@0b7 on 062605
ブックマークへ