Docker Part6

テンプレとかいらんやろ

色々調べて、
Dockerのコマンドは、裏でDocker Engine APIを叩いているということが分かりました
Docker Engine APIを考えずにDockerコマンドについてあれこれ考えても、
隔靴掻痒というか、無理がありますよね
ただDocker Engine APIについて詳しく書いている日本語の資料が、ネットで探してもなかなか見つかりません
Docker Engine APIの層について詳しく書いてる本とかサイトはないでしょうか？

>>696
https://docs.docker.com/engine/api/v1.41/
これが全て
しかし、今のDocker Engineは単なるAPIサーバーでありcontainerdに処理を投げてるだけだから、
containerdや更にその下のruncの方を学ばないと中身は何もわからない
最近は運用環境ではDocker Engineはほとんど使われなくなりつつあり、完全に終わった技術

Docker使うようになってから開発がつらくなった
とにかく意味不明のエラーが多すぎる、流行ってる割に完成度低いなコレ

完成度の高い仮想開発環境てあるのかね？

>>697
次は何が始まったんよ

>>700
実行環境においては、今はDockerEngineという無駄なレイヤを省いてcontainerdを直接使うのが主流

ググればわかる質問し続けるだけのスレ

Dockerが嫌な人は、一生chrootでも使っとけ！

>>698
エラーが多すぎるのに使ってるとか意味不明。

エラーさえ出なければこんな便利なもんはないんだけどな

意味不明のエラーというのが「(自分にとって)意味不明なエラー」なのか「(全人類にとって)意味不明なエラー」なのか分からないので何とも言えない

こないだ出たエラーの場合はぐぐるとStackOverflow(英語版)その他でも質問されてて未解決だったので俺以外にとっても謎ではあったんだろうと思う

簡単なことをもっと簡単にするために複雑なレイヤー挟んでそのレイヤーのせいで余計にトラブるってのは往々にしてよくあるわな

エラーとかほざいている人は、chrootでも使っとけって！
それさえも分からなければ、qemuとかVMwareとかにしとけって！
わざわざ難しいの使わんでかまへん。

なんだかんだで動いてる時は便利で使い慣れてきたから、できればDockerを使いたい
また別のもの覚えるの面倒くさい

Win10のWSL2環境だけど今までPowerShellからdocker-compose upできてたのに急に Are you trying to mount a directory onto a file (or vice-versa)? とか出てできなくなった
Ubuntuからならできたけど何故何もしてないのに壊れたのか
ぐぐったらStackOverflowとかに似た問題があったが俺のは解決しなかった

何もしてないのに壊れた

LinuxでDocker使ってるけど問題起きたことないな
みんなLinuxで使おう

少なくともWindowsなんか使うのをやめろ、まずはそこからだ

それはあるかも
キータあたりでぞろぞろ出てくる導入記事もマックが多かったような

macでいいならwsl2でもいい
linuxかそれ以外か

でもWindowsでWSL2で問題出まくるから、多分Windowsが一番悪い

>>717
それあなたの感想ですよね

docker commitで作成したイメージを元にして、コンテナを作成して、変更を加えた後に、さらにコミットして、
そこから別のコンテナを作って…みたいに繰り返したら、イメージサイズが大きくなりすぎます。
この最終産物のイメージを短縮化することはできるのでしょうか。

>>719
使い方が間違っています。
docker commitでイメージを作ってはいけません

>>718
事実を述べたら感想とな

>>720
どういうこと？？

docker commitはデバッグ用であり
通常は使いません

>>719
そのイメージがどうやってできているか分かったら、
自ずと答えがわかるとおもうけどね
tarballでもraw imageでも好きにすりゃいい

>>723
でもイメージ化しないと不便でしょう

不便も何も、そもそも再現性のないイメージに価値などない

正解

>>726
イメージでなければ再現するのに時間がかかるし、
再現する方法をメモしておけば良い

そのメモをDockerfileに書けば良い

怠けるな。手順書に従った作業しろ

基本的に、Dockerfileを保持する方向でいいと思うけど、
Dockerfileの書いた内容が恒久的に使えなくなる可能性がありえるので、
少なくとも自分のレジストリを用意して、イメージのバージョンを保持するとか、
tarballなりraw imageなりに吐き出しておくといいと思うけどね

ここらへんのイメージのバックアップは、VMwareとかKVMとかでも結局同じだけどな

>>731
たしかに、dockerfileだと、レポジトリの廃止や、そのディストリビューションのサポート切れで、
インストール手順が無効になる場合もあるよな

Dockerfileでビルドしたイメージをデプロイする際にはまずECR等のレジストリにプッシュし、
デプロイ先のホストがそれをプルするのが一般的なプラクティスであり、イメージのバックアップとして機能する
つべこべ言わずにDockerfileを書け

サポート切れても無理矢理使えるようにするためにイメージのバックアップ取るなんてセキュリティ的にあり得ない
その時点でサポートされているものに対応し続けるしかない

>>733
それは結局のところ、置き場所はともかくイメージは使うということですよね
Dockerfileとイメージの役割は別。
Dockerfileの役割はコンテナのメンテナンスのためにある。
イメージはソースがネットから取れなくなるなど、Dockerfileの改良ではどうにもならない場合にへの対処方法だと思う。
commitはそれをローカルに置いておくために使う。

Dockerfileだったらbuildするだけでローカルにイメージはできるだろ？
commitなんか必要ない

dockerでシステム壊れちゃったから諦めた

>>734
なぜありえないのか？
顧客がつねにお金を出してくれるのか？
顧客がお金を出さない場合は、古いイメージのまま、使い続けることになる

古いイメージ＝脆弱性があるシステム
システムを更新しないで放置してはいけない

顧客が金出さないから云々って状況がよく分からん
システム構築とかの仕事を請け負ってその後の無償対応期間ぐらいの期間であれば、作業時に使ったイメージがサポート切れになるほどの時間は経っていないだろうし
それ以降は顧客が金出さない以上何言ってきても無視するだけの話ダロウェイ

末尾変になったけど無視して

>>740
ユニケージっていうのは現場の人間が内製するためのシステムなんだよ
例えば東急ハンズのような所にプログラミングの専門家はいない
システムなんてせいぜいCGIで作った買い物カートで十分
そういった所にシステム開発費とかないから一度作ったら何年も放置するのはざら
データベースとか難しい技術はしらないし、OSのアップデートとかシステムが動かなくなったら困る

シェルスクリプトでシステムを作っていればコピーするだけでOSのアップデートは完了
OSの基本的なコマンドしか使わないから、OSをアップデートしてもそのまま動く
パイプの匠が考えた開発手法は大規模システムにも対応している
人の入れ替わりの激しい業界で、現場のやすい人材だけで内製するにはこの方法しかない

客が金出さずサポート切れの古いイメージ使い続けて脆弱性突かれて情報流出しようがこっちには関係ないんだからどうでもいいでしょ

>>735
考え方が硬すぎる
そうなりゃ別の方法、別のイメージでイメージ作ればいいやん

commit（笑）

>>744
別のディストリを使うとなると、構築のために試す必要がでてくる。
時間かかる。
逆になぜそこまでイメージを嫌うのか。

いつまでも塩漬けにすることの問題は別にして、最低限、運用中のものについてイメージを残しておくのは必須だろう
スケールアウトや再デプロイの度にいちいちビルドしてたらクソ遅いし、パッケージの更新等でビルドが失敗するようになったときに修正までの時間を稼ぐ必要がある
そのこととcommitの是非は全くの別問題だ

バックアップなら、commitよりも、exportのがええんちゃう？

イメージが大事だとして、
どうしてcommitでイメージを生成させたら駄目だと思うのか？

自動化できねーからだろ
アホ化ｗ

まずdockerの各コマンドが何をやっているのか正確に理解することからだ

>>750
自動化ってなにを？

>>746
そうやって技術的負債が増えてくんだよ^^

デプロイのためのイメージとベースイメージごっちゃになってね？

docker commit の話がなんでimageの話に化けているんだよ。
image使うにしても、まずdockerfileにまとめろよ。dockerfile無しでimageだけとか、Dockerの利点捨てているだろ。

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でなくて、
その都度、コンテナを再生成せよということでしょうか。