Docker Part6
■ このスレッドは過去ログ倉庫に格納されています
コンテナ内のソースを編集したって、じゃあテストツールを動かしたり
のソースコードの静的チェックとかするのはどうするのよ?という話になる。
そうするとコンテナの中に開発ツールをバンバン入れることになる。
開発ツールをバンバン入れたコンテナを運用環境に持っていくわけない
動かすのに必要ないのに開発ツールに脆弱性とかあったらどうするんだ
運用環境用のコンテナは、プログラムが動く最低限の環境のものを作る
いずれにしろ開発環境は運用環境とは別なんだからどこで開発しようが関係ない。
コンテナの中に開発環境を作るのは面倒
開発環境ぐらい自分の好きにさせろ >>770
ありがとうございます!
参考になります。 初心者な質問ですみません。
DockerFile を使わずに、docker compose だけで python の環境を作りたいのですが、どう書けばいいでしょうか。
教えて下さい。 >>776
docker compose use python@3 でできるよ docker run で--net networknameを指定したコンテナがあります。
内部的に自動でIPv4アドレスが割当てられました。
後から、このコンテナのIPv4アドレスを変更するにはどうすればよいでしょうか。
コンテナをstopしてから、
docker network connect --ip 新IPv4アドレス networkname コンテナ名
を実行し、再びstartしたのですが、IPv4アドレスは以前のままでした。 >>778
自己解決しました。
docker network disconnectしてから
docker network connect --ip 新IPv4アドレス networkname コンテナ名
する必要が有りました。
変更できました。 docker ps -a でコンテナ一覧が見られますが、
コンテナ数が多くなるとごちゃごちゃしてきます。
関連するコンテナをフォルダみたいにまとめて表示できるといいと思うんですが、
そういう機能ってありますか。 別にいらないな。
というかその使い方あんまりだと思うけど。 いっぱい立てるならだいたいcomposeとかで見るしなぁ Dockerたまにしか使わないから詳細すぐに忘れる
その度に学習し直すから効率が悪い >>785
仕組みが変わってないのに学習とは?
一度使えるようにしたら覚えることないじゃん。 しかも問題はDockerそのものではなく785の記憶力や情報管理能力と言う Ctrl-Rによる逆逐次検索で、履歴を遡れるし、忘れてもいつでも思い出せると思うけどな 知らんけどそう言う発想すら無くて、他の人にその都度書かせたいかまってちゃんでは コマンドライン履歴なんか、一月二月もたてばなくなる。 ほらやっぱり「ポックンにいい感じの情報整理おしえてよう」ってなかまってちゃんだ
docker全然関係ないし CentOS 7のイメージから作成したコンテナなのですが、
/tmpの内容っていつ削除したらよいでしょうか。
docker stop/start containerはしますが、tmpの内容はクリアされないようです。
定期的に削除しても問題ないでしょうか。 docker kill / docker run --rmでいい
それで問題になるようならコンテナの使い方が間違っている >>794
docker stop/start containerでなくて、
その都度、コンテナを再生成せよということでしょうか。 回答としては
再起動じゃtmpに限らずクリアされない
定期的に削除しても問題ない OSを起動したのになんで起動処理が走らないの?と思っての質問だったら
起動スクリプトは実行されないから、コンテナのENTRYPOINTでやる必要があるよ、と >>796
ありがとうございました。
自分で消したいと思います。
>>797
docker run の指定で、tmpの内容を削除するようなスクリプトからスタートさせてみたいと思います。
そうすれば、docker startのタイミングでもtmpの内容をクリアできると思います。 tmpを消す運用してるとコンテナが無駄に大きくなるよ commitしなければ問題なくね
kill/runの方が運用上は圧倒的に推奨されるけど しばらく前だが、公式はホストOSはUbuntuをお薦めって記載があったけど、
今でもUbuntu推奨なのかな
その記載は無くなってるようだけど、Rocky Linuxとかは公式的には
どういう扱いなのだろ 開発環境ではVM含めホストとしてUbuntuが使われてるケースが圧倒的に多いから、開発チームによるテストもUbuntuファーストだという程度のことでしょ
実運用ではコンテナの実行にDockerエンジンを使うこと自体が絶滅危惧種なんでどうでもいい たしかに今となってはどうでもいい
だからググっても情報が出てこない
専用の軽量ホストOSとかもあった気がするが そもそも今のDockerはcontainerdの薄いラッパーに過ぎないから推奨も相性もクソもないのでは >>802
実運用だとなにが使われるのだろ
Dockerの知識が役に立たない、ということではないと思うけど、何だろ containerdだよ
k8sや、Fargateのようなマネージドコンテナサービスはコンテナの実行に関してライフサイクル管理や実行環境の整備を行う仕組みを独自に持っているため、
Dockerという不要なレイヤを通す必要がなく、直接containerdのAPIを呼んでいる Docker便利だけど新人に導入させるのが大変でなかなかペイしない気がする
もうちょっとすんなり、どんな環境でも動いてくれるようにならないもんか 簡単にしたら「オレDockerできるんだぜ」の人達が困るだろ >>807
それはなー、とりあえず、まずはVPSで用意してあげればええんやで
VPS上で、一度自分で動かせられるところから始まりやわ
Dockerコンテナがなんで動くとか、なんでできあがったとか、
もっとも簡易的なUnix系のchrootの仕組みが理解できんかぎり、
Dockerなんか、根本から理解できひんよ
chrootでやってみて、そっかプロセスがホストと分かれて見えないとこまるなーとか、
ネットワークセグメントも別々になっていてほしいなとか、
気づくから。 Linux知らないなら色々ごっちゃになって大変かもだけど知ってれば簡単じゃね? あ、俺が言ってたのはちょっと違くて単に各々のPC上で開発環境欲しいだけなんだわ
それがWindowsだとめんどくさいじゃん、WSL入れたりゴチャゴチャしてるうちにわけわからんエラー出るしぐぐっても簡単には解決しないし
動いたら便利なんだが動くようにするまでが大変なのよね >>813
それなー、Windowsだとめんどくさいから、WSLにしてもDocker Desktop for Windowsにしても、
結局Windowsはアレになっちゃうから、妥協してWindowsに合わせて動くようにするか、Windowsを窓から投げ捨てるしかないわ Dockerの仕組みを理解させたいわけじゃないんだよな、ていうか俺も大して理解してない
ただの便利なツールとして使えるようになる日が来ることを夢見てる へぇ、Windowsだと面倒くさいのか、Linux上でしか動かしたことないから知らなかった。 Dockerってレンサバでも使えるのかな
さすがにroot権限ないと無理か? root権限持ってる人に、自分をdockerグループに入れといてもらう、でええんちゃう podmanならroot権限なくても使えるんじゃね
Steam Deckで使えるらしいので composeを使わない巣のDockerでrunしたディレクトリを後から確認する事って出来ない?
docker psでコンテナを確認して設定とかを見直したいと思っても
そのコンテナを起動するのに必要なファイルがどこにあったのかを後から知りたい。
mountとかしてるならinspectでファイルのパスが見れるし、composeならlabelにパスそのものが入ってるけど
コンテナ1つで済むような小規模なイメージだとcompose使わずに直にdocker runしてるの少なくなくて。 >>823
なに言っているのかさっぱり分からんけど、
少なくとも、ホスト側のpsを普通に見たら終わりちゃうのか? >>824
ホスト側でとあるディレクトリに.envファイルを準備して以下のコマンドを実行します
docker run -itd --name hoge --env-file .env anyimage
1年後、envファイルに書いてあるはずのDBの接続先を一箇所だけ変更してコンテナ再作成したいけど
どのディレクトリで実行したか忘れてしまった。という状態です。 >>825
なるほどなー
たしかに、docker container inspectとかじゃ分からんもんな
コンテナ内(で動かしているユーザ)の環境変数を set コマンドとかで洗い出して、
該当しそうな .env を探すぐらいちゃう?
さらに、DBの接続先って分かっているんだったら、そのDBで具体的な何かで引き出せるはずやし
ちなみに、自分はそういう使い方をするときも、systemdを経由するから、路頭に迷うことがないな >>825
それだったら単純にfindコマンドで.env探して中を確認すればいいんでね?ワンライナーで実行できるっしょ。 >>825
そのdockerのプロセスのPIDを調べて
cat /proc/PID/cwd
とかすると何か出てくるのでは ホスト側にある.env無くしちゃったから、稼働中のコンテナがどんな変数を参照してるかわからないってこと?? dockerコマンド使って本番でコンテナ動かしてんのかな?(笑) 久しぶりにPodmanをインストールして3日ほど弄くり回してみたけどかなり出来が良くなったね
root権限いらないとか最高だしDockerから乗り換えてみる docker hubの公式imageがupdateされたら通知するサイトとかツールとか何使ってる?
enso docker nofity とか crazymax/diun? DockerDesktopの代替になるかも?と巷で話題の「Finch」を使ってみた - NRIネットコムBlog
https://tech.nri-net.com/entry/use_finch AWSがlima+nerdctlのジャップスタックを葬ってくれるのかと思ったらこれもlima+nerdctlベースかよ
だったら普通にdockerクライアントとlima使えばいいだけ
解散 Rancher Desktopどうです?Docker Desktop課金避けとしてはvscodeのdevcontainerも動かせて私的にはいい感じに思ってますが Docker Desktopってコンテナの状態がGUIで分かりやすく確認できる程度のものでしょ
CLIで十分な人なら課金してまで使うものではない ドッカー7つの経営方針の本読んでるけどさっぱり分からん >>839
Rancher DesktopはWindowsではWSLのラッパー、Macでは>>837のFinchと同じくlimaの簡易的なラッパーに過ぎない
どうしてもGUIがないと死ぬのでないなら直接WSLやlimaを使って非デスクトップのdocker動かした方が遥かにシンプルで分かりやすい >>840
そうなの?単にWindows版Dockerのことかと思ってた Docker Desktopは、以前は845の言うようにWindowsやMacに簡単にインストールできるDockerディストリビューションとしてそれなりに価値があった
今のDocker DesktopはWindows上ではWSL使うのがデフォになっちゃったから、WSL上のDockerコマンドのフロントエンドでしかなくて、もはやほとんど存在価値がないんだよ >>846
いや、WindowsからDockerを使うという目的があるだろ
WSLのDockerじゃ、Windowsから呼べないぞ
しかも元々のDocker Desktopだって仮想マシン上のフロントエンドでしか無く
「Windows上」からDockerが使えることが売りだったわけで
Docker Desktopの存在価値は前から変わっていない >>840
Docker DesktopはWindowsとmacOS上で
どちらもLinuxが動かない理由で仮想マシン上でLinuxを動かした上で
WindowsとmacOSからネイティブにDockerを使うためのインターフェース
ボリュームやネットワーク通信の調整を行っている。単なるGUIではない。 つーかDocker DesktopにGUIがついたいのなんて最近だし
昔からCLIで使っていただろと やっぱりそうだよね
WindowsでDocker使うにはDocker Desktopを入れるしかない wsl2内で普通にdockerデーモン動かすことを「WindowsでDocker使う」と言わないのなら確かにそうだけど実質一緒でしょ 848で言っているとおり。
その辺の調整を自分でやるのなら同じってことになるかもしれんが
結構めんどくさいと思うよ
よくわかってない人には素直にDocker Desktopの類を使っとけ、と言ったほうがいい >>851
お前WindowsでDocker使ってないだろ?
Dockerで何やってるんだ? >>853
なぜWSL内ならDocker使ってないことになるの? >>854
Docker DesktopはWindowsとmacOSで使うために作られた
WSL内でだけで使うなら、仮想マシンで使えばいいと言ってるのと一緒 >>855
?
wslから普通にWindows側にアクセスできるでしょ
仮想マシン内でDocker動かすのとは全然違う アホだろお前ら Docker Desktop は WSL上に建てられた中に Docker がインストールされて、Dockei Desktop はそのソケットを使ってる ただのguiだよ >>858
DockerはDocker社が作ったもの
GUI経由で使おうがDockerの偉業は素晴らしい >>857
誰もアクセス不可能だと言ってなくて
そのDockerをWindowsローカルで動いているかのように調整してくれてるのがDocker Desktop
だからただのGUIじゃない、と説明しているわけで
Docker Desktopをインストールしたら、なんでWindows上でdockerコマンドが使えるようになるのか、って考えたらわかるでしょ つまり、理解できない人はDocker Desktopを使っとけ、ということ 公式ドキュメントさえもまともに読めないパソコンおじさんが、Docker Desktop for Windowsを騒いでいるだけやね
まぁ、無知のまま、パソコンおじさんを突き進めばいいと思うよ
ttps://docs.docker.com/desktop/install/windows-install/ >>861
そうだね
その上で、今はWSLがネットワークの設定やホストファイルシステムのマウントをやってくれるから、もはやDocker Desktopには単なるGUI以上の価値はない。
もちろんDocker DesktopはWSLをDockerデーモンを動かすためだけに使用していて「ローカルで動いているかのように調整」するのはWSL任せではなく独自に実装しているわけだけど、
もはや機能的にはそれは無意味になっているんだよ。 要は Docker + GUI = Docker Desktop だから
Docker Desktopは単にGUIだけではないってことだろ
Docker Desktopを入れればWSL用のDockerも入る Docker Desktop - GUI = Dockerでしょと言われてるのに
Docker Desktop = Docker + GUIだから単なるDockerじゃない!と屁理屈こねてるだけだな >>867
いえ、だからDocker DesktopのGUIはすごい機能なんですって
話をしてるんです。 × もはやDocker Desktopには単なるGUI以上の価値はない。
○ Docker DesktopのGUIは単なるGUI以上の価値がある。
Docker DesktopのGUIってすごい機能ですよね?
それを認めればいいだけの話です。 ■ このスレッドは過去ログ倉庫に格納されています