Docker Part6
■ このスレッドは過去ログ倉庫に格納されています
>>480 GitHub ActionsやCircleCIみたいなCIツールから金取るのが狙いでしょ 実際パートナーシップ契約結んでレート制限解除の代わりに金貰ってるみたいだしな ミラーされたら単純に売上は減る >>483 だからDocker社の通信量やインフラ代をへらすことが目的だから Docker社の思惑通りじゃん もともと売上はなかったって知ってる? インフラのコストが高くなってきたから 金払うか、ダウンロード量を減らすかのどちらかを選びなさいって言って その思惑通りダウンロード量をへらすことになった IP制限のかかったレポジトリにあるソースコードをEC2のdockerで実行する時、どの様な手順がありますでしょうか? 用意できる環境は、実行環境のaws EC2のlinuxインスタンス、開発用のwindowsマシン、ソースコードのgitレポジトリ(windowsからは接続出来るがEC2から接続出来ない) のみで Private Docker Registry とかは使えない状態です。 単純に考えると、windowsにあるソースコードをscpなりでEC2に転送し、EC2にssh接続してdocker-compose up -d --build ですが、 プログラムに更新があった時、毎回ソースコードをscpで転送して、EC2上で再ビルドをするのは手順が多く避けたいです。 windows上のdockerでimageをsaveして、aws EC2上のlinuxのdockerでloadすれば、scpで転送するファイルは1つだし EC2上で再ビルドをする事も無いと思ったのですが、 windowsで作成したdocker imageをlinuxで使う事に不安を感じます。 windowsのdockerもlinuxコンテナなので理屈から言えば問題ないかなと思ってしまうのですが、どのような問題点がありますでしょうか? >>485 普通は本番用のDockerイメージをCIでビルドして ECRに入れるだろ AWSで使えるCIならCodeBuildがある ECRもCodeBuildも使えない変なルールの職場はやめて転職しろ >>485 そんな腐りきった職場でdockerとか意味がわからない そういうところに新しいツールを持ち込んでも無用な混乱と手間をもたらした結果破綻するだけだ もしお前が犯人なら、今すぐ関係者に土下座してdocker使うのやめたほうがいい >>488 マヂに 腐った水に何溶かしても幸せになれんよ 逃げろ 俺は分からんw だからこのスレのレベル見せてちょw >>490 本人がイメージそのまま送ってロードって言う dockerの旨味全否定してるからな 何が問題かといえば、他人から見たら全くもって意味不明な>>485 にしか分からない極めて珍奇なデプロイ手順になってしまうことが問題だろうな 自分が辞めたあと後任者がそれ見てどう思うか、一度変な拘りを捨てて客観的なフラットな頭で考えてみ windowsで作成したdocker imageをlinuxで使う事に、どのような問題点がありますでしょうか? >>497 ・Windows上のDocker環境で作成したDocker image ・Linuxで上のDocker環境で作成したDocker image ・macOSで上のDocker環境で作成したDocker image に何か差がありますか? Docker環境は一体どうやって動いていますか? これらを自分で説明できると、自ずと自分で答えられるはずです。 https://docs.docker.com/security/ > Docker Desktop version 4.3.0 and 4.3.1 has a bug that may log sensitive information (access token or password) on the user's machine during login. > Additionally, these logs may be included when users upload diagnostics, meaning access tokens and passwords might have been shared with Docker. もうボロボロだな そもそもDockerだけを普通に入れたら良いのに、Docker Desktopなんか上っ面の皮を使うもんじゃないよな >>498 言いたい事はわかるんだけど「考えさせる」は 今時ただの老害扱いされるよ。 TLDR要は全部同じ。 何でビルドしてどのプラットフォームに送っても問題無い >>504 いいたことはわかるんだけど、答えだけ教えてもだめだよ > ・Windows上のDocker環境で作成したDocker image > ・Linuxで上のDocker環境で作成したDocker image > ・macOSで上のDocker環境で作成したDocker image DockerはLinuxカーネルの機能を使って(仮想マシンを使わずに) アプリケーション仮想化を行うものだから Windows上でもmacOS上でも動かない Windows上やmacOS上で動いているように見えるが 内部的にはLinuxがインストールされた仮想マシンが使われてる Dockerはクライアントサーバー方式で Windows・macOSから実行したdockerコマンドは 仮想マシンで動いているLinux上のDockerサーバーと通信している 結局の所Linuxで作成してるのと同じことになる >>504 いや、だったら、公式ドキュメントを全部嫁、以上で終わるやん。 初心者ですみませんがコンテナのuidとgidを確認する方法はありませんか? 環境 docker desktop wls AWSでコンテナを動かしたいのですが EC2にDockerEngineをインストールするのではなく、ECSというのを使うのが正しいのでしょうか? >>511 基本的な疑問が解けました。 ありがとございました。 >>510 使う起動タイプはEC2ではなくFargateだぞ 同じECSでもゴミと神の2種類があるから注意 間違って送信してしまいました。 別料金がかかるかもしれないので、ちょっと調べてみます。 料金を気にし過ぎな人がAWSなんか使えるはずもない >>510 どう使うの? 自動ロードバランサーとか備えたelastic beanstalkとかもあるよ docker-composeで、一日一回動かしてるスクリプトがあるのだけど、 これをawsで一日一回動かしたいとしたら、 何のサービス使うのが良いですか? cronみたいに毎朝8時、とかのスケジューラーも有るのが希望です AWSスレの話題になっちゃうと思うが、 少なくともLambdaじゃ短時間実行のスクリプトしか動かせないからな ECSちゃうん https://docs.aws. あまぞん.com/ja_jp/AmazonECS/latest/developerguide/scheduling_tasks.html 知らんけど AWS Batch でいいやん 調べれば普通に出てくんのに Lambdaは短時間といっても最大15分までいけるから余程のデカブツでない限りは無問題だろう 今はDockerイメージも使えるし How Docker Made Me More Capable and the Host Less Secure https://www.cyberark.com/resources/threat-research-blog/how-docker-made-me-more-capable-and-the-host-less-secure ホストのrootではない一般ユーザーが/var/lib/dockerのデータを読み書き出来る脆弱性を修正しようとして ホストの一般ユーザーが特権昇格できる別な脆弱性を生んだ模様 旧バージョンのmssqlには何故かgdbが入ってたので 他ユーザーのプロセスを勝手にkillできてりする dockerコンテナのログファイルは dockerホストの/var/lib/docker/containers/コンテナID/コンテナID-json.logにあるということですが windowsのdocker desktop上でこのdockerホストのディレクトリにアクセスするにはどうすればいいのでしょうか? >>527 docker logsもしらない男の人って・・・ そもそもホストにアクセスする必要なくね? logs — Docker-docs-ja 19.03 ドキュメント http://docs.docker.jp/v19.03/engine/reference/commandline/logs.html 個人サイトだとdockerってオーバースペックなのかな ちょっとしたツールをポコポコ作っていると、以前作ったツールを更新する時再起動していいやつだっけ?とか、ソースを最新化する時は再ビルド必要なんだっけ?とか 毎回調べ直すところから始まるからしんどい。 手元でちょこっと動かす時に、これはdockerを使わず直に動かしても問題ないやつだったっけ?一見動くように見えるけど特定の部分だけ動いてないとかなかったっけ?とか気になってしまう ググると「開発環境は全部wslのdockerに閉じ込めました」みたいなdockerファーストの人居るけど、そういう人はどうしてるのか知りたい。 共通手順を厳守するとか、プロジェクトごとにしっかりドキュメント化しているのか 何も考えず再起動やビルドしても問題ないように作るのがコンテナアプリ dockerでonlyoffice+letsencryptで建てようとしてるんだけど、うまくいかんで頭沸いてきた 何も考えずにDockerを使っている連中ばっかりなんやなw >>531 AWSサービスのSSLターミネーションに頼るのが楽だが Traefik使えばそーいうの無しでもそんな苦労せずLet's encryptでHTTPSに出来た 似たようなので確かCaddyってのもあったはずだが どう違うのかしらん 仕事でDocker触る人2割 フリーランスを夢見てる駆け出しエンジニア(笑)8割でこのスレは成り立ってる アホみたいなレスがあるのはしょうがない >>533 情報助かる。nginxのssl設定がうまくできてなかったから、traefikでリバプロにする方が簡単そうね。 普段はルータの方が触る機会多いから、ソフトウエアルータの方がわかりやすそうだわ。 Kubernetesベースだから素のDockerは触ってないかな Dockerfileに以下の記載をして USER node:node WORKDIR /workspace/app ローカルのwindowsのwsl2のdockerで実行すると/workspace/app の所有者はnodeになるが ec2のdocker側で実行すると/workspace/appの所有者がrootのままなんだけど これはどっちが正しくて、なぜこんな違いが生じているのでしょうか。 解決策としては事前にrootの状態でmkdirしてchown nodeすればいいのだろうけど なんでこんな差異が出ているのかの原因が知りたい。 添付画像の左側がec2のdockerで、/workspace/appの所有者はrootになっている(左の赤枠) 右側がローカルのwindowsで、所有者はnodeになっている(右の赤枠) https://i.imgur.com/J2wHj7x.png win側でビルドしてるときBuildKit使ってる? >>536 こういうなんちゃってSEがいるからこの業界はおかしくなってきたんだろうな SDやGMかもしれないがw コピペで組み合わせて貼り付けて動けばええんやでw っていう輩ばっかりだから、どないしようもない 納品するときに動いてれば十分なんだから深い理解()なんて要らんしなぁw そんなことしてる暇あるならコミュニケーションしようよw >>528 ありがとうございます たしかにログファイルを取得するという目的はdocker logsで達せられますが、 windows上でdockerホストはそもそもどういうものとして動いているのだろう・・? という疑問がありました 調べたところ、 dockerホストはWSL上でdocker-desktop-data、docker-desktopという二つのVMとして動作していて、 エクスプローラからWSL上のVMへは \\wsl$VM名 でアクセスでき、dockerホストに格納されたログファイルは \\wsl$\docker-desktop-data\version-pack-data\community\docker\containers\コンテナID\コンテナID-json.log でアクセスできると分かりました コミュニケーションしとるで それバグってんだろ、コピペばかりしてるから そんなことになるんやで はぁ?コードの意味がわからんからバグの修正ができない? この無能が! >>544 ああ、絶対やっちゃダメな方法を見つけたんだね(苦笑) なんでドキュメント読まないで 自分で探そうとするの? 正しい答えを探せない無能なのを自覚してないの? ↑の546,547は一体何を言ってるんだ? 544は自分でちゃんと自分で正しい答えを見つけてるだろ。 「ログが読みたい」と言っているのでは無く、Windows環境でlinuxの時の様に「ログを吐き出す場所を知りたい」 と言っているのに頓珍漢な回答した上にdisらなきゃ気がすまないって、こいつはどんだけ無能なの? 544はえらい丁寧に返してるように見える。まあ、平日の真昼間に連投できるやつって時点でお察しだけどw フリーのDocker Desktop for Windowsの代替品がデタらしい Stevedore: free and open-source Docker Desktop alternative for Windows https://www.reddit.com/r/docker/comments/t9c5q7/stevedore_free_and_opensource_docker_desktop/ というか、Windows kernelをLinux kernelに置き換えたらええんよ いまのWindows NT kernelを、Linux subsystem for Windows にしたらええねん そうするだけで、すべてが解決する そうする理由があるならそうしてるでしょ そうしないのはそうしないだけの理由があるから 統一教ほど危ない思想はないよ? >>550 LinuxカーネルにWindows APIを実行する能力がないんだよ ソースコードが公開されてるから、何かあったらコードを修正すればいいでしょという 考えになってて、拡張性が乏しく融通がきかない。 Linuxだとサードパーティのクローズドのドライバの互換性を保つことすら出来ない ドライバはカーネル毎にコンパイルすことが前提になってる 考え方が違うとはいえ、Linuxはカーネルとドライバの互換性の点では劣ってるのさ LinuxカーネルよりもWindowsカーネルの方が優れてるんだよ Docker社、ロシアとベラルーシからDockerのサブスクリプションを購入できなくしてしまうwwwwwww Docker's Response to the Invasion of Ukraine - Docker Blog https://www.docker.com/blog/dockers-response-to-the-invasion-of-ukraine/ vimの設定ファイルに文字コード指定しても文字化けしてしまいます… どうしたらよいでしょう? .vimrcに下記設定を保存していますが、ダメなようです。 set encoding=utf-8 set fileencodings=utf-8 set fileformats=unix,dos,mac >>568 失礼しました。 DockerのContainer内でvimを使っていましたので、つい… >>569 ありがとうございます。 移動します。 Dockerコンテナ内でvimを使う意味がわからない (好きなようにつかえばええけど、)そもそものDockerの使い方として、まずアリエナイ だからそんなDockerの使い方をする時点で、向いていない やるなら、host側のvimからover sshでコンテナ内のファイルを触るでしょ それも辺やろ、普通bindするやろ 再起動したら変更消えるやんけ 昔はdockerの事がよくわからなくてコンテナの中に入って色々弄ってたことあったから使い慣れたエディタが欲しくてvimをインストールしてた事もあったな・・・ 開発の初期フェーズでは、Dockerfileいじっては作り直す、をやるよりも vimを使って設定ファイルを編集し、それをDockerfileにフィードバックする、と した方が早いからそうしてもよい、ということのようだ 今すぐ不足ライブラリをpipで入れたいってときはdocker execで入れちゃうな。ただし、Dockerfileをその直後に変更しておくのとセットかな。ビルドまで本当はしなくちゃいけないんだろうけどサボってる。 >>577 vimを使う時点で遅いだろ… だれがあんな低機能テキストエディタなんか 使うんだよw おれはコンテナ内のファイルをエディタで直接いじらないけど、 まぁ、コンテナの差分を取れば、コンテナ内で編集した設定ファイルのdiffをすぐに吐けるし、その差分から元のDockerfileに反映させればエエか ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる