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/

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

コンテナが動くマシンが決まりきってる、ってんなら仮想マシンで十分だ
EC2でもなんでもいいよ
普通にパッケージを入れて、普通にsystemdで動かしゃいい
dockerなんて余計なリソース食うだけ
仮想マシンなら、従来の管理ノウハウも役に立つ
コンテナを使うなら、クラスタが大前提

>>522
日本語を読めよ、と俺は言ってるんだが？502はそんな情報は与えてない。

>>523
だから勝手に妄想を膨らませて話を横道に持っていくなよ、と言っている。
「仮想マシン」も「EC2」も「systemd」も「従来の管理手法」も502の話には一切あがっていない。
「移行するための標準的な方法は何ですか？」って聞いてるんだから
こういう方法があるよ、と答えれば良いだけ。

>>525
標準的な方法？従来の管理手法とおなじだぞ

何か知らんけどコンテナ嫌いなら
Dockerアンチスレとか
コンテナアンチスレとかいう名前のスレ立てて引きこもれば？

リナックス板とオーディオ板はなんでか殺伐としてる

>>526
お前馬鹿なの？502を口に出して10回読んでからレスしろよ。
「
その後、新しいDockerホストで、コピー済のはずのvolumeをつかって、
コンテナを復元します。
どういう方法が標準的、推奨方法でしょうか。
あるいは以上の方法でも良いのでしょうか。
」
と書いてあるんだが？

>>529
だから従来の管理手法でいいと言ってるんだよ

>>530
「どういう方法が標準的、推奨方法でしょうか。」

この一文を30回ほど口に出して読んでね。
アスペには10回じゃ足りない。

>>531
だから従来の管理手法でいいと言ってるんだよ

もういいよ。

もういいよ。

Software Design 12月号のDocker 特集3章、Ruby on Rails プロジェクトの所で、
data volume を利用した、MySQL データのバックアップ・復元方法が書いてある

data volume を圧縮解凍する、専用のbusybox コンテナを用意して、
その起動時に、--volume-from で、MySQLコンテナを指定する

圧縮: busybox tar cvf
解凍: busybox tar xvf

>>514
その、tarコマンドでボリュームバックアップをとる方法は、
ターゲットボリュームをマウントしているコンテナでバックアップ先ディレクトリもマウントし、
tarコマンドでボリュームに保存されているファイルをバックアップ先へ横流ししているだけだと考えています。

そうだとしたら、
Docerホスト上において、/var/lib/docker/volumes/target-volume/_data をrsyncで他のホストに直移しでも良いように思うわけなのですが。

tarを使う方法ではなにか違うんでしょうか。

>>520
メンテナンスによるダウンタイムを避けるために、
別ホストへコンテナを引っ越しさせます。
ボリュームも移してあげる必要が有ります。

>>530
ボリュームを移す従来的管理方法ってあるんですか？

>>535
なるほど。
いったんtarで圧縮ファイル化するわけですね。

Dockerホスト上の、/var/lib/docker/volumes/target-voryume/_data から直移しの例があればいいんだけどなあ
rsyncなら、変更のあったファイルだけを追加的に移せるので作業時間を分散できます。

>>537
いや、530が言うには君はコンテナ使う資格無いからVM使えってさ。

>dockerなんて余計なリソース食うだけ
>仮想マシンなら、従来の管理ノウハウも役に立つ
>コンテナを使うなら、クラスタが大前提

そもそも「コンテナを使うなら、クラスタが大前提」は完全に間違い。
k8sはその通りだがDockerはターゲットが開発者だから、どちらかと言うとシングル。
おまけにコンテナ化する目的はIaCなのに、それも理解してないｗ。
さらに日本語も読めてないとかｗ

Dockerは可搬性を持たせるためのものだから
どこでも動く=k8s上でも動くってだけなんだよね

>>536
ホストマシンへの依存を減らすことが可能です

>>538
IaCはdocker専売特許ではありません

>>536
> Docerホスト上において、/var/lib/docker/volumes/target-volume/_data をrsyncで他のホストに直移しでも良いように思うわけなのですが。
そこはDocker内部のボリューム領域
どういう管理をしているかはDockerの内部の仕組み次第

フォルダをそのままボリュームとして使いたいなら
指定したフォルダをボリュームにすればいいだけの話

>>541
> IaCはdocker専売特許ではありません

質問「他に何があるんですか？」
↓
お前「○○があります」
↓
お前のマネ「IaCは○○専売特許ではありません」


↓
お前「IaCは○○専売特許なんていってねーよ！」
↓
お前のマネ「IaCはDocker専売特許なんて誰も言ってねーよｗｗｗ」

うわぁ…

言い返せなかったようだ

うわぁ…

さて、IaCはdocker専売特許とは誰が言ったのかな？

うわぁ…