Docker Part3

LXCを使った軽量仮想環境。
これからの動向が気になるところ。
情報共有しましょう。

http://www.docker.io/

前スレ
Docker Part2
https://mao.5ch.net/test/read.cgi/linux/1506574845/

kubernetesだんだん分かってきたわ
面白い仕組みやね(´・ω・`)

オーバースペック気味だよな
なによりメモリ消費量が多すぎる

流行ってないけどswarm modeが結構好き

dockerを前提としたソフト開発において、差分ビルドとかデバッグはどうやって使っていけばいいの？

>>738
毎度のことながら使い方が間違っている。
Dockerは仮想マシンじゃない。

Dockerの中で差分ビルドやデバッグという
開発作業は行わない

開発が終わってテストもデバッグもすんで
それを配布するときに使うもの

>>739
ありがとう。いっていることは分かる。
質問を変えてもう聞きたいのだけど、開発環境の統一化という意味でdocker使いたいけどいい案ありますか？

そんなふわっとした聞き方するならググった方が早いんでね？

>>740
開発環境を押し付けるな。プログラマの自由にやらせろ。「統一環境」ではなく
「推奨環境」として環境づくりが面倒な人のために、例の一つとして作るだけにしろ
統一はしないという前提で「統一しなくても信頼できる」
ことを保証するためにDockerを使うんだよ

統一しないっていうことはわかりやすく言えば、開発環境は
WindowsでもLinuxでもmacOSでも使っていいということ
使うIDEやテキストエディタやブラウザなどはそれぞれ違うだろう
しかし何を使って作っても、同じように動くと保証するにはどうするか？

それが必要なのは"差分"ビルドやデバッグ環境を統一することではない。
"完成版"ビルドと完全なテスト用のDockerイメージを作成することだ。
テスト用のDockerイメージを使ってCIで実行すれば
どういう開発環境を使って開発していたとしても正しく動くことが保証される。

もちろんこのテストというのは全体のテストだ。
自分が開発した部分のテストだけをやりたいのに全体のテストをしていては時間がかかる。
こういうのは自分の開発したマシンでやることだ。つまりそれぞれ違う開発環境でやることだ。

開発には何よりスピードが重要だ。いちいちDocker（ついでにいうと仮想マシンも）を
絡ませなければ開発できないなんて愚の骨頂だ。
環境特有のバグはゼロではないから、統一した環境（つまりDocker）でテストすることは重要だが
大抵の問題は開発者が書いたコードにバグがある。特定の環境でしか発生しない問題は少ない。

どうしてもDockerや仮想マシンが必要な場合でない限り、Dockerや仮想マシンを使わない。
それが開発環境のあるべき姿だ。Dockerや仮想マシンを使わずに高速に開発テストし
場合によってはローカルでDockerを使って統一"実行"環境でテストも出来るようにする。
そして最終的には共通のCIサーバーでテストを実行する。本番用Dockerイメージを使って実行する。
これが今の理想の開発スタイルだ。
もう一度言うがDocker（や仮想マシン）で開発環境を統一するな。そういう時代は終わった。

Heroku, CircleCI などの、CI/CD パイプラインだろ

git すれば、Jenkins などのタスクランナーが走って、テスト・デプロイされる

何を持ってそんな自信満々に言えるんだろう。クッソ古いlibcとかどーすんのさ

libc5やELF移行前とかどうすんのさ！ってか。

>>744-745
なにがいいたいのかわからん。クロスコンパイルがしたいって話？
つまり開発マシンでそのまま動かすことが出来ないバイナリを動かしたいって話？

いや俺は長文は読まない主義なので、元ネタすら知らん。

おまえらの糞みたいな書き込みは3行が限界だ。
それ以上は時間の無駄。

自分で知恵遅れ宣言してて草

ガイジの日記帳だからしゃーない

>>742
へいすみません

クーベルネーテスって便利ですか？

そーでもねーです

Dockerfileに以下を書いてbuildしてもWarningになってしまいます…
Qiitaやら海外の掲示板の情報を試しても上手くいかず…
誰か同じ経験or解決したことある人いませんか？
docker介さず行えばpip install コマンドは動くのですが…
Hyper-VにCentos8入れてそこでやってます。

FROM python:3.7
RUN pip install --upgrade pip

→WARNING: Retrying (略　Failed to establish a new connection

>>754
おそらくプロキシ環境でDockerfileにプロキシ設定していないのでは

>>754
これ実行したらどうなる？

docker run -it busybox ping 8.8.8.8
docker run -it busybox wget http://google.com

>>755 ありがとう。プロシキ環境は使ってないっす。念のため調べてみます。

>>756 こんな結果になりました。下が通らないのが変なのでしょうか？
[root@localhost ~]# docker run -it busybox ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=5 ttl=49 time=29.793 ms
64 bytes from 8.8.8.8: seq=6 ttl=49 time=15.181 ms
64 bytes from 8.8.8.8: seq=7 ttl=49 time=13.270 ms
64 bytes from 8.8.8.8: seq=8 ttl=49 time=18.520 ms

[root@localhost ~]# docker run -it busybox wget http://google.com
wget: bad address 'google.com'

ネットワークはつながってるけど、DNSサーバーの問題だね。
いまから飯作るんで後でなｗｗｗ
それか他の人お願い

DNSサーバーか…ありがとう、もう少し調べてみます！

でもまあ解決策はよく知らんのよねｗ
俺は普通に使えるし。

こことか参考になるんじゃね？
https://qiita.com/frost-tb-voo/items/fcc0c0fe7561b9101bf4

あと興味があるからこの結果も見てみたいな。
普通はプライベートIPアドレスなはずだが
身元がばれるようなものが入ってないことに注意なｗ

docker run -it busybox df -h
docker run -it busybox cat /etc/resolv.conf

DNSサーバーっていうか、名前解決が出来てないってことね

test

Filesystem Size Used Available Use% Mounted on

何か書けないな？
resolv.confはプライベートIPアドレスと、あと自分でさっき追加した8.8.8.8が入ってました…

>>760
docker run -it busybox df -h
↑の結果を書こうとしたら何故かjaneがエラーになーるww

hyper-Vの設定が悪さしてる気がしてきた…

Docker Desktop for Windows を使ってるんだよね？

何か、コンテナの概念と仕組みをスッキリ、はっきり
説明してるお勧めサイトってありませんか？

遅まきながら使い始めたけど、よくわからない。
思考がどうもコンテナ≒仮想マシンってイメージに引っ張られる

とりあえずくじらが書いてある本を、ｱﾏｿﾞﾝﾎﾟﾁｰﾉからのンロッカーで受け取って
ざっと読んだが、余計に混乱しだした・・・。

すみません、コンテナはDockerの誤りです。

>>768
何のためにDockerが作られ、どんな問題を解決しているのか？を調べたほうがいいよ
何に使えるかじゃなくて、何のために使うか。
（何に使えるかだと本来の用途ではない使い方をしてる例が多い。
曰くそういう使い方も出来るからいいじゃん。らしいｗ）

まあ答えを言ってしまえば、自分でビルドしたアプリを配布するために使う。
用途が重要だから仕組みをいくら調べても間違ったイメージは訂正できない。

Dockerの本とかでも良くない例が多くて、Dockerはdockerコマンドや
kubenetes使いこなすんじゃなくて、Dockerfileを自分で書くことが重要なんだが
そのDockerfileであっても例として「既存の○○サーバーをDockerで動かしてみましょう。」
という話が始まる。本来は自分で開発したアプリのDockerfileを書くものだ。
「自分で開発したアプリ」はDockerの話からすれば本題からずれるから
既存の○○を例として使うのはわかるが、そうするとDockerの正しいイメージから遠ざかってしまう。

自分が使いたい使い方を我慢してまで
Dockerの本来の使い方を守ろうとする意味は何？

他の方法がある、とか言うんだろうが
いろんな手法を混ぜるのがめんどくさいから
多少設計思想から外れても全部Dockerでやっちゃうってのも別に自由じゃん

あ、ごめん流れ読んでなかった。
>>768の質問があっての返答なら全くごもっともだわ

>>771
> 自分が使いたい使い方を我慢してまで

自分が使いたい使い方にはそれに適したツールがあるから
より適したツールが有るのに、我慢してDockerを使わなくていい

>>771
> いろんな手法を混ぜるのがめんどくさいから

いるよね。そういう奴ｗ
より適したツールが有るのに「新しいのを覚えるのが嫌だから」
全部エクセルで頑張りましたとかｗ

頑張るところを間違っている。楽するために頑張って知恵をつけるのではなく
バカなまま無駄な努力をすることを頑張る

>>773-774
スクリプト書けば一発なのにExcelで何とかするのは純粋に時間のムダだけど、
「Dockerの本来の想定からは外れるかもしれないけどあっさり使える」用途があるなら
実際そういう使い方もできるからいいじゃんとしか言えんわな。

何のために作られたとか、
作った奴の思想はこうだから、とかクソどうでもいい。

>>775
実際は「そういう使い方出来るからいいじゃん。
それにしてもDockerって使いづらいですねｗ
こんな事したいんですが出来ないんです。」
ってなってるから言ってんだよ

>>776
そこは異論ないよ。
俺のそもそものツッコミも筋違いだったわけだし。

>>770
> Dockerはdockerコマンドや
> kubenetes使いこなすんじゃなくて、

買った本はまさにそんな感じの本だった。
このコマンドを打つと、コンテナはこういう状態になりまーす、って感じで
Dockerコマンドとは、Dockerとは何ぞや、どういう仕組みなのかって事が中心で
「どうしたら、Dockerって便利だなーってなるんだよ！！」って雰囲気の本だった

目鱗。ありがとうございます。

「前CentOSで組み立てたこのWebサービス環境だけど今度はUbuntuで動かして！」とかいう指示が来た時にdockerで作っていればもしや楽だったのでは…ってなった事はあった
そういう感じじゃないかなぁ的外れだったらごめん

インフラ専業の人が仮想化技術の1つとしてdockerを学ぼうとしているのだとしたら、
たぶんそれはあまり意味がないからやめた方がいい
dockerコンテナはアプリケーションのパッケージ化技術だ
アプリケーションにOSを丸ごとバンドルする、いわばスタティックリンクの一種にすぎない

インフラ屋だけどDocker便利。
Zabbixコンテナを複数環境にそれぞれ独立して作ってるんだけど、
VMではメモリ消費の観点で難しかった。

開発者がCPUやコンパイラの技術を知っておくべきなのと同じように
インフラ屋がDockerの内部技術を知っておくのは正しいが、
普段の仕事でそれらの技術は使わないんだよ。

知っておくとトラブル解決が素早く出来るが
インフラ屋にとってのdockerを使う普段の仕事は
作られたDockerイメージをただ起動するだけ
YAMLファイルに一行書けば終わるぐらいのもの

インフラ屋の仕事が楽になるのではなく、
インフラ屋の仕事が無くなるのがDockerの便利さなんだから

世にあるDocker本は「Docker入門」ではなく
「Dockerを実現する内部技術詳細」と言ったほうがいいぐらい
それぐらい普段の使い方と入門書の内容はずれている

いや普段の仕事で使ってるけど

用途を決めつけるんじゃなくこれなら便利だって思ったらどんどん活用すればいいんだよな
このスレ見てるとdockerは将来夢のような快適さを提供してくれる
気がする

実際には、間違った用途で使っていて、
これDockerでどうやるの？
こんな事したいんですがどうやるの？
Dockerって使いにくいね
って話になるのでうんざり。

間違った用途で使うと、Docker批判につながる
だから、用途が間違ってると、毎回言ってる。

読点とか改行の使い方がアレっぽい

>>786
そういうとこだぞ

正しいか間違ってるかってより
向いてるか向いてないかよね

インフラ屋はすぐにDockerの中でsshサーバーを動かそうと考える
Dockerはそういう為のものじゃない

なんかめんどくさい原理主義荒らしが居着いたね

wordでドキュメント書くの面倒だから、dockerでasciidocのコンパイラを作って、
イメージファイルと、バッチファイルを配布した。
なかなか便利に使ってる模様。

↑このように
本当にやりたいことは「asciidocのコンパイラ」を作りたいだけ
だけど、それを動かすのにライブラリとかが必要だから
Dockerでまとめる。という使い方をするもの

CIで使うようなビルド用/テスト用の本当に使い捨てのコンテナは十分にコンテナ仮想化の哲学と目的にマッチしてるけどな
上でも書いたがVSCodeで使えるような開発用コンテナも十分に有用

個人的には使い捨て或いは壊れたら作り直すものならアプリも環境もサービスもコンテナが良い
そういう意味では, コンテナ仮想化を選択する前に用途が決まっていないと話にならない

用途が違うこともまぁあるんだろうが, それ以上にコンテナに求めるものが曖昧なのにふわっとした目的で使おうとするからコンテナに柔軟性やら壊れた時に直すやらが必要になるのだと思う
少なくともディスポーザブルな環境としてのコンテナは普通に適応

MS-DOS時代ならOSもアプリも全部フロッピー一枚だったのにな

せやな、Aドライブに起動ディスクを入れて、
Bドライブにシステムディスクを入れるんだよね。

>>754
Dockerfileのビルド時に--network=host入れたらビルド出来たわ…

Docker哲学とかどうでもよすぎてゲロ吐きそう

哲学とかどうでもいいがいい加減ステージング用とプロダクション用でそれぞれ別のイメージ作る馬鹿は絶滅してくれないかな

>>798
そんなばかは放置すればOK
もし仕事を一緒にしているのであれば、そのバカを追放するか、その仕事を止めるか。

馬鹿でも何でもいいから、どう使ってもよい。

やっとnginx、gunicorn、flaskをdocker化できた…
ファイアウォールが原因で動かないとか…

dockerとkubernetesの環境をネットで調べながら作ってるんだけど、
下記のようなエラーが出てるんですが、解決する方法ありますか？

CentOS8
docker-ce 19.03.8
kubernetes GitVersion:"v1.18.2"

kubelet[7677]: E0519 10:42:28.107265 7677 manager.go:1086]
Failed to create existing container: /kubepods.slice/kubepods-burstable.slice/kubepods-burstable-
podaなんかID.slice/docker-なんかID.scope: failed to identify the read-write layer ID for
container "なんかID". - open /var/lib/docker/image/overlay2/layerdb/mounts/なんかID
/mount-id: no such file or directory

dockerのイメージ保存先を起動オプションで変えてあります。
ググったら無視してもいいようなことは書いてあったんですがなんか気持ち悪い･･･。


kubelet[7677]: W0519 10:24:35.435700 7677 watcher.go:87] Error while processing event
("/sys/fs/cgroup/memory/libcontainer_7748_systemd_test_default.slice": 0x40000100 == IN_CREATE|IN_ISDIR):
inotify_add_watch /sys/fs/cgroup/memory/libcontainer_7748_systemd_test_default.slice:
no such file or directory

dockerのオプションで、cgroupではなく、systemdを使用するようにしてあります。

両方ともディレクトリがないエラーですが、dockerのオプションとkubernetesの認識がずれてるように見えます。

dockerは理解するとめちゃ便利だとわかった。
ただしlinuxカーネル以外で使おうとすると地獄

ランタイムや開発キットのコンテナって、他のコンテナとはどうやって組み合わせて使うものなの？
具体的には、code-server + Swiftで使ってみたいんだけど・・・・やり方が全くわからん
https://hub.docker.com/r/codercom/code-server
https://hub.docker.com/_/swift

64bit OSでDocker使ってるんだけど
ダイジェスト指定以外で32bit用のDockerイメージを使う方法ない？

>>805
ダイジェストとは何？

ハッシュと同じ意味じゃろ

>>807
thx

ホノカチャン

>>798
環境変数サポートの追加がめんどくさい時によくやる
環境ごとに設定ファイル書いてCOPYするほうが楽だもの

--mountで存在しないボリューム名を指定して実行したらエラーになるらしいのですが
エラーにならずボリュームが作成されてしまいます。
エラーにならないのが正しい動作ですか？

docker run -dit --name test --mount type=volume,source=volume1,target=/tmp

最近触り始めたんだがなんでコレ突然RHEL8からハブられてんの？
Kubernetesからも距離置かれはじめてるみたいだし何かあったんか

podmanの件はredhatのほうが先走って自滅した感じ
運用環境はコンテナ標準を満たす限り、dockerにこだわる必要はないから、運用向けに機能を削ったり追加したりして最適化したほうがいい、これは正しい
でも、運用環境っていったら普通はk8sだから、podmanが使われる機会は滅多にない
一方で、開発環境はpodmanのエコシステムがまだまだ貧弱すぎて、dockerにはぜんぜん追いついてない
docker社もそれを理解してるから、開発環境でのエクスペリエンス向上に投資を集中し始めた
またpodmanのセールスポイントの1つであるrootlessも本家dockerはとっくに実装済
結果として誰もpodmanを使ってない（そしておそらくそのまま消え去ると俺は予想してる）という状況になってしまった
redhatにしては珍しくマヌケな戦略をとったなといった感想

へー、サンクス。posmanとかはopenshiftやるならって感じなのかね
にしても開発で使う分には裏方が何やっててもちゃんと使えさえすれば関係ないしな…

PODMANのメリットはデーモンレスってことだけ?
赤帽がなにを目指してるのか正直よくわからない
だけど赤帽のやることだから何かがあるんだろうな

dockerコマンドだけ使う分にはpodmanにエイリアス設定されてるしあんまり意識しない
問題はdocker-composeを使いたいときだなぁ(podman-composeの互換性が大変怪しい)

まぁmicrok8s使っちゃうからdocker-compose使うこと自体減ってるけど

docker-composeのメリットがさっぱりわからない
こんなのつかっても結局Dockerfile作らないといけないし意味がない

Dockerfileはアプリケーションのソース
docker composeはビルドしたアプリケーションをどうデプロイするかを定めたマニフェスト
全く役割が異なるのでどちらかがもう一方の代替になることはない

docker-composeと比べるのはDockerfileじゃなくてdockerコマンドだよ
DockerfileあったってDockerコマンドは使うだろ？

コンテナ一つだけならDockerコマンドを直接使っても苦労はないが
複数のコンテナを使う時Dockerコマンドを何度も実行して起動するのは大変
Dockerコマンドが面倒になったらdocker-composeを使うんだよ

Dockerfileを書かなくてもいいものだと思ってた
勉強になりました

書かなくてもいいけど、なにやったか忘れる。

そのまんま手順書になるのがいいとこでは

docker execは邪道なのかな

docker execはデバッグ機能

docker exec して、動かしながら、Dockerfileを書く。
最後にdocker buildして同じものが出来上がって完成。
って感じじゃない？

うちは運用ジョブをdocker execで流してます
docker execを使わない場合、運用ジョブ専用のAPIやWebAppを整備するんでしょうか?

データベースをホストにマウントするのとボリュームで管理するのはどっちがいいんでしょうか？

>>825
そんなことめったにしないなぁ。docker buildはキャッシュが効くんで
（キャッシュが効くように）Dockerfileに追記しながらDockerfileを書く
終わったらDockerfileをシンプルにしたりサイズが膨れ上がらないように調整するって感じ
docker execなんかして作業したら、その作業結果をファイルに保存するの二度手間じゃん

>>826
そういうのはdocker runやるのが普通
最初docker execなんてなかったんだよ
それなのにそういう用途にも使えたわけ

>>827
どちらもボリューム。データの保存先のパスが違うだけって知ってる？
Dockerサーバー上の特定のパスに保存するか
Dockerが用意したパスを使うかの違い

ホストマウントはホスト環境への明示的な依存なので、どうしても必要でなければ避けてvolumeを使うべき
volumeも内部的にはホスト環境に依存してるといえばそうだけど、抽象化・隠蔽されているのでホストマウントよりBETTER
実例として、Docker for Windowsでのパーミッション、リモートエンドポイントへのコマンド実行、などでvolumeを使用していれば避けられたトラブルが結構あった

つまりはいろんな種類のホスト、例えばWindowsやMacでも使いたいなら
Docker上のボリュームを使えってことだな。

Dockerイメージ自体は同じものを使える。
必要に応じてDockerのボリュームを使おうがサーバー上の
パスを使おうが自由に選択できる。

だが相対パスを使えばいいだけじゃないか？

相対パスでマウントできたっけ

相対パスを変換するだけやろ