Docker Part6

テンプレとかいらんやろ

Dockerイメージはnixで生成するのがさいつよだろ

Dockerfileでapt使ったりしたら
aptはロックファイルも無いから
「Dockerイメージをビルドした時点での最新版パッケージ」になってしまう
aptの部分だけ別Dockerfileにするとかは面倒くさいし

nixなら同じソースファイル使えば同じバイナリになる
既存パッケージを使うだけなら、再現性もたせるためだけに別々にビルドする必要はなくなる

再現性のあるビルド - Wikipedia
https://ja.wikipedia.org/wiki/%E5%86%8D%E7%8F%BE%E6%80%A7%E3%81%AE%E3%81%82%E3%82%8B%E3%83%93%E3%83%AB%E3%83%89

>>756
とんだにわかだ
apt も dnf もバージョンを指定してインストールできる
そしてそれが必ずしも正義ではない
互換性がある範囲で脆弱性やバグを修正した新しいバージョンを使おうする方法論もある
そもそも、基本的にはイメージを再利用し再現性を保証するのが一般的な考えでDockerfileで完全な再現性を求める運用には無理がある

なんとか頑張って「俺はお前らの知らない凄いことを知っている」
と言いたい人

>>755
アスペ？

>>759
ん？なら
「dockerfile無しでcommitで構築したimageを運用するやつはアスペ」
ということでOK？

>>723が結論だと思うが。

>>760
？俺もそう思うが

なんだこいつ…

「なにいってんだこいつ」と感じた時点でそいつは貴方に取っての変なおじさん
変なおじさんは真面目にかまうとうれション垂れ流しが加速します

>>757
大体aptが悪い

npmみたいな、package.jsonで緩いバージョン指定して
package-lock.jsonで厳密なバージョン指定、みたいな仕組みでもあれば便利なのに

現状は完全にバージョン固定、再現するには
apt-getコマンドで依存するパッケージも含めて「手動で」全部バージョン指定が必要でかなり無理がある

2022年にもなってビルドしたイメージ保存しないと完全再現できない時点で
aptは欠陥設計と思われ

まぁ、せいぜい好きに使えばいいよｗ

>>764
有意義ではないが自動化できないこともないはず
一度インストールしたあとパッケージの一覧を抽出してそれをDockerfileにインストールさせるよう書けばいい
シェルスクリプトかなにか使えば自動化できると思うよ
繰り返しだけど一般的ではないし脆弱性やバグ修正のためのアップデートに非常に脆い

すいません、超基本的な質問をさせてください。
最終的にクラウド上のDockerコンテナで動くプログラムを作りたいのですが、開発のやり方としてはローカル（自分の場合はWSL2を利用）にDocker Desktopを入れて、そこでコンテナを作成して開発することになると思います。
その場合、ソースコードの作成、編集は、VSCodeでコンテナ内のソースを編集すれば良い・・・という理解でよいでしょうか。
あるいは、コンテナなしの環境で作成したソースを、ローカルのコンテナにコピーして動作を確認し、さらに本番環境にデプロイする・・・という流れになるのでしょうか。

後者のほうが一般的
ぶっちゃけ好みの問題でしかなくて、コンテナで開発する派がよく議論に持ち出す環境統一論はほぼ詭弁だから真に受けちゃダメ
コンテナ内で開発したからといって開発に使ったのと同じコンテナで運用環境に持っていくわけではないからな

>>768
ありがとうございます！
なるほど。

このへんについて 解説本を見ても書かれていないし、検索してもなかなか見つけることができず悩んでいました。
助かりました。

コンテナ内のソースを編集したって、じゃあテストツールを動かしたり
のソースコードの静的チェックとかするのはどうするのよ？という話になる。
そうするとコンテナの中に開発ツールをバンバン入れることになる。

開発ツールをバンバン入れたコンテナを運用環境に持っていくわけない
動かすのに必要ないのに開発ツールに脆弱性とかあったらどうするんだ
運用環境用のコンテナは、プログラムが動く最低限の環境のものを作る

いずれにしろ開発環境は運用環境とは別なんだからどこで開発しようが関係ない。
コンテナの中に開発環境を作るのは面倒
開発環境ぐらい自分の好きにさせろ

開発時はボリューム(バインドマウント)使え

>>770
ありがとうございます！
参考になります。

>>771
了解です。

どっから始めればいいのか　ﾅﾝﾂｯﾃ

どっからでも始めればよいです

初心者な質問ですみません。
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上でしか動かしたことないから知らなかった。

開発環境もLinuxだと困ることないよね

Dockerってレンサバでも使えるのかな
さすがにroot権限ないと無理か？

rootなしにどうやってコンテナ環境作んねん

root権限持ってる人に、自分をdockerグループに入れといてもらう、でええんちゃう

podmanならroot権限なくても使えるんじゃね
Steam Deckで使えるらしいので

https://i.imgur.com/w3kkFJu.jpg
https://i.imgur.com/TPQO8YW.jpg
https://i.imgur.com/F2xdgpB.jpg
https://i.imgur.com/22de65R.jpg
https://i.imgur.com/8iZEnpy.jpg
https://i.imgur.com/SLWjBBW.jpg
https://i.imgur.com/uSrpbWs.jpg
https://i.imgur.com/ONeBPVl.jpg
https://i.imgur.com/tNnUXRO.jpg
https://i.imgur.com/IhjMRLP.jpg
https://i.imgur.com/oCqEbqc.jpg
https://i.imgur.com/uiDbP03.jpg

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？

githubでええやん

レジストリと連携できる脆弱性スキャンツール

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で十分な人なら課金してまで使うものではない

開発にLinux使わせてくれないと面倒なのよ

ぽ、PodmanDesktop

ドッカー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内でだけで使うなら、仮想マシンで使えばいいと言ってるのと一緒