Docker Part5

DockerはLinuxが持つコンテナ技術を使ったアプリケーション仮想化技術です。
アプリケーションを動かすために必要な各種ライブラリ等を一つのDockerイメージに
まとめることで、さまざまな環境へのデプロイが容易になります。
例えばWindowsやmacOSを使って開発・テストしたDockerイメージを
そのままクラウド上のLinuxの本番環境で使うことができます。

クラウド上の環境が仮想マシンであるため、Dockerは仮想マシンと併用して使うことが多いですが
仮想マシン技術とは無関係の技術です。実際Linux環境において仮想マシンは必須ではありません。
WindowsとmacOSでは仮想マシンを使いますが、これはOSがLinuxではないからです。

Dockerは主にアプリケーションを動かすために設計されているのでデータを保存するのには適していません。
データはDockerイメージの外部、ボリュームを使ってホスト環境に保存するかネットワーク通信で外部サーバーに保存します。
またDockerコンテナは一つのサービスを実行し、複数のサービスが必要な場合はdocker-composeやk8sなどを使って連携させます。
Dockerを仮想マシンの代替として、コンテナ内で複数のサービスを起動しようとすると困難が待ち受けています。
それはDockerの設計方針とあっていないからです。

Dockerイメージ（Dockerfile）はアプリケーション開発者が作成します
動かすのに必要なもの全てがDockerイメージに含まれるので
インフラ担当者はそれを動かすだけ、本来のインフラの作業に集中できるようになります

Dockerは主にウェブ業界でサービスのデプロイの必須技術になりました
情報共有しましょう

http://www.docker.io/

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

注意　Dockerを仮想マシンの代替として使いたいと考えてる人は、DockerではなくLXCを使いましょう
LXC(Linux Containers)
https://mao.5ch.net/test/read.cgi/linux/1330826939/

>>422
Amazonはgoのbuildしててアホってこと？
おまえAmazonより賢いの？

dockerには様々な使い方ができてそれが便利なんだが
どうも「僕の考えた正しい使い方」以外に強烈な拒否反応を示す輩がここに住み着いてるみたいだね
こいつのせいでいつも荒れる

>>423
アホなのか？ビルドしても問題ない場合の話なんか誰もしてねーよ
ちゃんと読んでみろ、1000回のビルドに困ってるやつが
「ビルドしててアホ、俺はDinDを使ってる」って言ってんだろ

そして、1000回のビルドの組合せ爆発を行わせないために
ファイルを入れ替えて、1000回のテストをやるって
言ってるんだぜ？どっちみち組合せ爆発してるじゃねーかｗｗｗ

組合わせビルドだと1000の追加容量
全部のせだと30の追加容量

DinDなら追加容量ほぼなし最適化もテストも各種イメージ提供元がやってくれてる

ほらな？馬鹿だったやろ？
レイヤーを共通で使うってわかってないんだよ

>>427
組み合わせだからレイヤー使っても減らんぞ？

どんなに組み合わせがあろうと、OSのレイヤーは
全部共通だってまだ気づいてないのかな？ｗ

スベってるよきみ

DockerコンテナじゃなくてMacに直接ツールをインスコしたいんだが
バージョン含めて統一は難しいな

asdfは一見バージョン切り替えに便利そうに見えるが、
とうも一部プラグインのインスコは自動ではないようだ
brew使ってインストールとか手動でさせたらむずいし、バージョンの組み合わせによっては失敗するかも

nixはインストール自動化は出来るが
関数型言語で書く必要があるのが何だかなあ

Mac上で直接やるの諦めて
開発用のパッケージが入ったDockerイメージを配った方が良いかも
IDEとの連携はVSCodeのRemote Container拡張機能とかでする感じで・・・この拡張機能まだプレビューだけと

>>431
無断転載禁止

プログラマの雑談部屋 ★128
https://medaka.5ch.net/test/read.cgi/prog/1610960220/655

>>431
これは本当に必要か？手段が目的化していないか？
と自分に問うクセを付けたほうがいいよ

asdf とか、日本人が作った、バージョンマネージャーのanyenv は、
主に、Ruby, Node.js などの言語のバージョンを指定するだけ

アプリ・フレームワーク内での、依存モジュールを指定するには、
RubyのBundler, Node.jsのnpm/yarn などを使う

例えば、Ruby on Rails なら、まず、Ruby 2.6 で、Rails 6 などを先に決めてから、
それに合った依存モジュールとして、
サーバー側はRubyのBundler, GUI側はJavaScriptのYarnで決めていく

Dockerで複数のイメージを作っても
同じ内容は共通化されるんですよ
だからファイルサイズは増えません

バイナリを入れ替えるとかいう変なやり方と
使用する容量はほぼ変わりません

内容が同じなら共通化されるわけじゃない
Dockerfileのコマンドが同一かどうかだろ

パッケージをA,Bの順で入れるのとB,Aの順で入れるのでは結果イメージが同一でも別物

マルチステージの動作確認ってどうしてるの？

>>437
それ結局1000容量必要じゃんｗ

>>439
使うたびに消すのだからいらない

それ言ったら、DinDだって1000容量必要なわけで
イメージ毎にファイル差し替え＝コピーしてるでしょｗ

>>438
他のやり方と何が違うと思ってんの？

nodeをdocker runして複数のバージョンのnodeで自作ライブラリをテストするとする

ソースコードのディレクトリをボリュームマウントして
npm ciでライブラリをインスコして
npm run test
これの繰り返しで良くね？

CIが普通にLinux仮想マシン使えるやつならDinDにはならん

Docker内でしかコマンド実行できないCIだとして
そのCIに複数のイメージで同じコマンドを実行する機能とか無いか？

>>441
必要なディレクトリが分からないケースがあるので困ってる。後はパスをどうやって通すのか。

本とかあれば教えて

>>443
そんな内容で他人に通じるとでも思ってんの？

↑単にnodenv,pyenv,rbenv入れて切り替えれば良いだけじゃね？
マスターは全部（３０全部のせ）インストールして。
jdkだけ無いから、dockerfile内でJDK_HOME変数いじる。

なんかしらんがどうしてもDinD使いたいんだろうさｗ

>>440
実行するたびにビルドすんの？もうめちゃくちゃだな
DinDなら30の容量で済むのに組み合わせの事前ビルドだと1000必要
DinDだと実行するまで容量を食わない

>>445
依存パッケージのバージョン競合が不安になるな

>>448
依存パッケージは各々の環境配下に入るんだから別に関係ない。

>>447
各言語、お前がいう30の容量だけ事前ビルドして、
残りは実行時にビルドするんだよ
ビルドって言ってもファイルコピーと変わらない
お前の言う「差し替え」＝実行時ビルド

>>450
実行時にビルドとかｗ
もうめちゃくちゃ

マルチステージだから容量食わないけど、毎回ビルドと言ってるキチガイは何なの。

毎回ビルドする位なら、オンプレに入れて各言語の仮想環境使った方が遥かに効率的でマシ。何分まつのやら

結局のところDinDが一番スマートじゃん

別に此処で聞くような事では無いって気がするね。
要するに、どうしてもDinDが使いたいって話だろ。
他の解決策はあると思うし、DinDの設計意図はそういう事（組合わせ）では無いと思うけど
DinD使ってドヤ顔したい奴はそれ自体が目的だしね。

>>451 >>452
実行時ビルドにちゃんと理由言って反論しなよｗ
俺は認めたくないって言ってるだけじゃんかｗｗｗ

起動に5分かかるようなシステムはイラネ

毎回ビルドはしない。
頻繁に変わるソースコードなどは、bind mount・共有フォルダ、
DB のデータなどは、Docker 管理のdata volume

複数言語のバージョンマネージャーのanyenv なら、

which ruby
~/.anyenv/envs/rbenv/shims/ruby

which node
~/.anyenv/envs/nodenv/shims/node

実行時ビルドとかゴミすぎて笑うわ

なんか、実行時ビルドが数分かかるとか勘違いしてるっぽいなｗ
ファイルコピーしかしないのに、どこに時間がかかると思ってるんだろう

うだうだ言ってねえでソース晒せよ

CIでビルドすることなんて当たり前ですし

［速報］GitHub Actions発表、Dockerコンテナの連係によるワークフローを自由に定義可能。GitHub Universe 2018
https://www.publickey1.jp/blog/18/github_actionsdockergithub_universe_2018.html

https://cloud.google.com/cloud-build/docs/automating-builds/run-builds-on-github?hl=ja

GitHub でのビルドの実行
Cloud Build では、Cloud Build GitHub アプリが利用できます。このアプリでは、
新しい commit を GitHub に push するごとにコードを自動的にビルドできます。

このチュートリアルでは、アプリのインストールと構成方法、GitHub でビルドを自動でトリガーする方法について説明します。

>>462
そのリンクはビルド→デプロイの自動化、デプロイ→テストの自動化であって
「プログラムの実行前のビルド」ではないけどね。
てかごく一般常識的に、実行前にビルドなんてしない。
pull→ビルドすら長ったらしいので何とか短縮する方法考える位だし。

真っ当なビルドと偏執狂のビルド
区別がつかない人は怖い

結局DinDが一番スマートだったわけだ

そのスマート（笑）なDinDのやり方ってやつを
ここで言ってみなさいよ。何も言ってない。DinDといいたいだけ

>>466
コンテナ内でdockerソケットにアクセスするだけだ
余計なビルド不要、imageベンダによる最適化、テスト済、容量も最小限で済む

>>467
え？Dockerコンテナ同士が違っていたら
アクセスできないじゃんｗ

実行環境の制限がないならDINDせず
ホストOSでやれば良くね？
何やろうとしてんのか知らんけど

>>468
ぷっ

>>467
DooDな

なんでわざわざDockerの中でテストしようとしてるんだろう？
普通にホスト上でdocker-composeとか使ってテストすりゃいいんじゃん
DinDなんかいらね

>>469
見てなかったｗ　同じこと言ってたｗ

>>472
俺も思った。
最初>>437のような問題を抱えて、それが何故DinDだかDooDだかで解決するんだろうかと思ってたら、
異なるバージョン間の問題は別コンテナっぽいよな。普通にやってりゃ良いじゃんとしか思わないｗ

普通にやったら非効率なのでDinDが要るんだよ

>>475
君、そもそも会話する気ある？そんな説明じゃ分からん

ブーメラン

そろそろ　ID:6ru/T4M8　は無視で良くね？

逃

docker in dockerは使いみちあるとしても
頭悪いやつがvirtuabox in virtuaboxのように
ぐだぐだにされたら迷惑だろ

しばらく放置してたらpodmanいいかんじになってた
docker-composeもほとんどそのまま動く

次スレはコンテナでまとめたほうがいいと思う
k8sも合流させたほうがもりもりする気

>>482
同意

ここ埋めてからにしろよ

Docker代替のpodman専用スレ （Dockerの話題禁止）
https://mao.5ch.net/test/read.cgi/linux/1599897027/

>>484
Dockerの話禁止とか了見の狭い掲示板を誰が使うんだ？
自分で埋めれば？

最近まじでdockerの影が薄くなってきたな
docker composeが動きだしたから、お手軽開発環境としても存在価値が薄れてきてる
dockerの利点はせいぜいbuildkitとwindows、macで動くことぐらいか

訂正
podmanでdocker composeが〜

>>486
Windowsで簡単に使えることはメチャメチャ利点だけどな！

docker composeはdockerに依存してるんだがｗ

OCI対応してればどのコンテナランタイムでも動くんだろ？
好きなの使えよ

>>488
事務職ならあるかもだけど開発者なのにWindows縛りってのも考えにくい

>>489
docker composeはdocker apiに依存してる
そしてその代替としてpodman apiというのがある

何か知らんけどdockerのコマンドと互換性ないの？
podmanって

いつも思うけどなんでそんなに代用品を使わせようとするのか理解できないんだよなぁ
赤帽とか普通なら信用できんだろ

まあ、Flashの例もあるからね。
別に悪いわけではないし、標準に近い機能であっても業界から嫌われる技術ってのはあるんでしょ。
大体その本尊が他社の要望に答えないって事なんだろうけど。

podmanのほうがコミュニティが活発でリリース頻度が高い

どんなプロダクトでも黎明期を超えて落ち着いてきたらセキュリティ、軽量さのために余計なもん削ぎ落とした物に取って代わるもんだよ

何時になるのかはわからんけど本格的に使ってみてもいいかなって思うのはver3.1からだろ
黎明期は仕様変更多すぎて手を出したくない

docker swarm使いやすくてオヌヌメです

今だったらk0sのほうがいいんじゃないの

いらんわ。

Docker ボリュームを全て、別のホストマシンに移したいと思っていますが、
ボリュームのデータの移し方について質問があります。

いま考えているのは方法は次の通りです。

１、新しいDockerホストにおいて、旧ホストと同じになるようにdocker create volumeコマンドでボリュームを作成します。
２、新旧のDockerホストで、Dockerサービスを停止
３、対象ボリュームについて/var/lib/docker/volumes/volume-test/_data/ のように指定してrsyncで新しいDockerホストにコピーします。

rsync -avz /var/lib/docker/volumes/volume-test/_data root@newdockerhostname:/var/lib/docker/volumes/volume-test/

その後、新しいDockerホストで、コピー済のはずのvolumeをつかって、
コンテナを復元します。

どういう方法が標準的、推奨方法でしょうか。
あるいは以上の方法でも良いのでしょうか。
よろしくお願いします。

>>502
コンテナ管理するのにオーケストレーション使うからそんなこと考えたことないけどそれで動くならシンプルでいいんちゃうか？

ボリュームの移動とか考えてる時点でバッドプラクティスにハマってる気がする
ほんとに永続化したいボリュームにはネットワーク越しのストレージを使うんだよ
そうすりゃコンテナが別のマシンで稼働してもいちいちボリュームを移動させる必要はないだろう？
コンテナは同じマシンで動き続けることを前提にしちゃだめ

GitHub ActionsはDockerHubの制限免除だって

https://github.com/actions/virtual-environments/issues/1445#issuecomment-713861495

For publicly accessible containers we are working with docker hub to make sure you will not be impacted by
the new rate limits. If you need private containers we still do not have a solution for that problem for forks of public repos.

公的にアクセス可能なコンテナについては、Docker Hubと連携して、新しいレート制限の影響を受けないようにしています。
プライベートコンテナが必要な場合でも、パブリックリポジトリのフォークに関するその問題の解決策はありません。

>>504
ただの老朽更新とかの移行だろ
そんなもんに共有ストレージとかバカじゃねーの

AWSならEBSボリュームのスナップショットで十分

ASG内のインスタンスが起動する時に
EBSボリュームをマウントして
ECSタスクではそのボリューム内のディレクトリをマウントする

EFSみたいなマネージドNFSは速度や互換性に問題無ければ使っても良いんじゃね
俺は使わないけど

>>507
バカだな
ストレージを外部化しておけば結合が疎になりストレージのメンテナンスもしやすくなるだろ

だいたいコンテナなんてのはどのマシンで動くかわからねえんだ
ローカルボリュームに依存しちゃだめだ

コンテナはどのマシンで動くかわからねえってのは重要なことだ
固定的なマシンで動かす前提ならコンテナを仮想マシンの延長上的な使い方しかできてないってことだ
固定的なマシンならコンテナじゃなくていい
普通にパッケージ入れて普通にsystemdで動かせばいい
どのマシンで動くかわかってるんだから事前に必要なものを準備するだけ
dockerという余計なレイヤーが消えるのでそのほうが管理が容易い
コンテナを使うなら次の瞬間にコンテナが別のマシンに移動しても動くように作れ

あ、キ○ガイだった

理解できない雑魚は仮想マシンでも使ってろってこった

俺のアドバイスを無視して、どうしても、ローカルボリュームに執着し、コピーしたいなら
docker公式文書にtarコマンドによるボリュームバックアップの方法論が書いてある、ので探せ
あとは応用だ。パイプラインと-Hフラグが便利だぞ

ネットワークが落ちたらどうすんの？

データベースだったらデータベースのレプリケーション機能で耐障害性の高い構成にするのがベストプラクティス
ボリューム自体はローカルにする
これが最も高い速度とHA（高可用性）を両立できる構成

ただ、自前でHAをセットアップして運用するのは大変な事も多い
マネージドサービスつかうか
k8sならオペレーター使うとかした方が良い

のっぴきならない事情でアプリをHA対応に出来ない場合は
NFS使って速度は諦めるか
HAの方を諦める

アマゾンのマネージドNFSは一貫性のために性能を犠牲にしてる
一貫性を犠牲にしたらもっと速くなるだろうが、同期されるまで各サーバーのデータが古いままって状況が起きうる

glusterfs簡単でいいよ

OSSアップリは遺憾なことにFSを使用する不届き者がまだまだ多くて困る

必死にpodman流行らせたいやついるな

相も変わらずココはコミュ障だらけだなｗ
ID:+SWvD/Px とか相手の要件も聞かずに己の持論を熱く語って何を解決したいんだｗ？
「コンテナなんてどのマシンで動くか分からない」って 502はそんな情報は何も与えて無いじゃんｗ
単に一台で動いていたDockerホストをスケールアップした別ホストに移行したいってだけかも知れんのに。
で妄想膨らませて、まーた「仮想マシンでも使ってろ」とか関係ない方向に話持って行こうとするし

たまに止まってても許されるような
そんな大事なシステムじゃなかったらローカルボリュームでも良いんじゃね？
知らんけど

>>520
その要件なら、従来のインフラ管理手法でスケールアップさせりゃいい
だから、仮想マシンと変わらんと言ってる
コンテナを使うなら、どのマシンで動くかはわからないのが、当たり前