Docker Part3

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

http://www.docker.io/

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

>>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のボリュームを使おうがサーバー上の
パスを使おうが自由に選択できる。

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

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

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

docker-composeはそれを自動でやってくれる

そもそもDockerのクライアントがどんなOSかなんて関係ない
Dockerはサーバーで動くし、DockerはLinuxでしか動かない

>>832
その相対パスが存在するか、適切なパーミッションを持っているか、といった条件はホストへの依存性となる
基本的にホストへの依存性が少ないほどトラブルは減る

>>829
docker runで全てが解決するならdocker execは存在しない
docker runはコンテナ外部で解決可能なジョブの実行に適している
docker execはコンテナ内部で行う必要があるジョブのために存在する

問題は Windows と Mac でボリュームを使うとファイルシステムの変換が起こるのでとても遅いということですね

>>838
だからdocker execは主にデバッグ用だって
通常の運用時には使わないもの

コンテナ外部で解決可能とか何のことを言ってるんだかさっぱりわからん
docker runとdocker execで実行できることは全く同じ
違いはdocker runはメインの処理を行うもので、
docker execはメインの処理を行ってる最中に乗り込んでデバッグするもの

runで常時起動してるコンテナに
例えばcronからexecでジョブ実行してもいいと思うがな

kubectl exec 経由なら、管理用のコンソールが欲しいときにわりと使ってる

>>840
全く違うよ
運用ジョブには大まかに分けてリモート実行可能なものとローカル実行のみ可能なものに分類できる

コンテナの外で解決可能なジョブはこの分類で言うとリモート実行可能なジョブに当たる
具体例はデータベースのバックアップ、バグデータの修正など
データベースコンテナとは別にジョブ専用のコンテナを同じネットワークでrunすれば良い

コンテナの外で解決できないジョブはローカル実行の可能なジョブにあたる
具体例はGitlabのバックアップ(gitlab rake)コマンドなど
ローカルで実行される前提のコマンドはdocker execで実行するしかない

Dropboxにバックアップするのが楽だからホストのボリュームがいいと思ってたけど
Dockerのなかでボリューム作ったほうがはまらないってことですね
勉強になりました

>>843
なんか使い方がおかしいな
まさかDockerコンテナの中に永続的な情報を入れてるんじゃないだろうか？
永続的な情報はボリュームに入れるんだぞ

>>843
> ローカルで実行される前提のコマンドはdocker execで実行するしかない
何度読んでも全く理解できん
なんでだよ

コンテナの外で解決できないジョブはローカル実行の可能なジョブにあたる
ローカル実行の可能なジョブはコンテナの外で解決できない
と話をループさせてるだけで全く説明してないよ

>>845
例として運用ジョブとしてポピュラーなバックアップを挙げたが、今の話題と永続化は別の問題だ

>>846
わからないなら、わかるまでよく考えるしかない、としか言えないな

では無いということで決着

イメージ開発者など実際に運用までしない人には確かに要らない機能だと思う

イメージ開発してる人は自分でイメージつくからね
今あるイメージでなんとかしなきゃで
バッドノウハウ溜め込む運用とは考え方が違う

で、工数がかさんで、メンテナンス範囲が広がる、と
既存のツールセットをうまく使う、ということもできないと後々つらくなる

execでコマンドうちゃいいだけなのに、わざわざ工数をかけてメ対象を増やして、アタックサーフェスを広げて、何がしたいのかね一体

>>853
よりシンプルになる

>>854
execのがシンプルですけど