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/

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専売特許とは誰が言ったのかな？

うわぁ…

コンテナとクラスタは、全く異なる

Docker は本番では使わない。あくまで開発者が使うもの。
本番では、Kubernetes を使う

Dockerはポートフォワーディングだから、
スケールすると、同じポート番号を使えないから困る

だから、AWSとかシステム構築運用を知らない香具師が、
Dockerを仮想マシンのように使おうとするw

だから漏れは必ず素人に、Docker・Kubernetesの相違点を聞く

> 本番では、Kubernetes を使う
1台なのにKubernetes使う理由は？

> Dockerはポートフォワーディングだから、
> スケールすると、同じポート番号を使えないから困る

Kubernetesでも同じポート番号は使えません

>>549
オンプレでテキトーに運用したいならswarmもアリ

bind mount は、プロジェクトのソースコードみたいに、
開発時に頻繁に修正するものに使う

一方、data volume は、主にDB のデータに使う。
これは、Docker が管理していて、複数コンテナで共有できて、バックアップ・移行しやすい

だから、
>>535
みたいに、バックアップ・復元用のコンテナを通して扱う

だから、Dockerの管理領域を、rsync で直接操作するのは、筋が悪い。
Docker CLI/API を通していないから

環境に依存していると、Dockerの可搬性がなくなる

bind mount は、ホストマシン OS のディレクトリ構造に依存しますが、
data volume は完全に、Docker によって管理されます。

data volume は、バックアップや移行が容易です。
Docker CLI コマンドや、Docker API を利用して管理できます。
Linux と Windows 上のコンテナーにおいて動作します。
複数コンテナー間にて、安全に共有できます

>>554
> bind mount は、ホストマシン OS のディレクトリ構造に依存しますが、
> data volume は完全に、Docker によって管理されます。

はい、それはつまりDockerに管理されてるので
ホストマシンOSのDockerのディレクトリ構造を参照してはいけないということです。

>>553
なるほど。
/var/lib/docker/volumes/target-volume/_data を直接いじるのは止めときます。
Dockerコンテナ上での操作にとどめるようにしてボリューム内容の移行作業を何かしらの方法で行いたいと思います。
rsyncを使うにしても、コンテナの上から発信したいと思います。

>>538
530の言う従来的方法って、仮想マシンのこと？

仮想マシンの方が、リソース喰いますよね
それに、仮想マシンであるVPSでは、仮想マシンは動かせない。
費用も高くつきます。

>>542
確かに、勝手な想像で事を行わないほうが安全ですよね

>>554
＞Docker CLI コマンドや、Docker API を利用して管理できます。
Linux と Windows 上のコンテナーにおいて動作します。
複数コンテナー間にて、安全に共有できます

dockerコマンドで、ボリュームをバックアップするようなこと便利な命令はないですよね

複数コンテナで同じボリュームを共有できると言っても、アプリケーションレベルで共有時におけるファイルの安全な扱いが保証されてないとだめですよね。

>>549
k8sもDocker使ってるが（笑）☺

>>556

> それに、仮想マシンであるVPSでは、仮想マシンは動かせない。

嘘は良くないなあ☺
Nested KVM があるよ☺

仮想マシンで仮想マシンを動かすときの問題点は
仮想マシンを更新するのが面倒であるということ

仮想マシンのイメージを更新したとして
それをどうやってクラスタ上に配布するのか？

前スレの567だが

＞567login:Penguinsage2020/10/16(金) 00:41:44.42
＞大切なパスワードを保存したイメージを間違ってdokerhubにうｐしちゃったらどうなるの
＞
＞568login:Penguinsage2020/10/16(金) 01:24:07.31ID:EJhQrEIg(1/1)
＞どうやったらそんなミスをするのかって悩むレベルだなｗ

自分でもまぁそんなことはないだろうけどってつもりでふとレスしたんだが
例のS◯BCのやつでワラタ
まぁ非公開のをforkってことだが

↑金融機関がクラウドサービス使うとかアホの極みだな。
プログラムを共有したいならgithub相当物をオンプレで運用しろよｗ

>>563
そのためのGitHub Enterprise
https://www.hitachi-solutions.co.jp/github/
GitHub Enterpriseは、全世界で使用されているGitに対応したバージョン管理システムである
GitHub.comと同等の機能をオンプレミスやプライベートクラウドで利用できます。

まあ知らなかったんだろうがな（苦笑）

>>564
いやいや、うちの会社Enterprise使ってるし。
github.comドメイン使うと権限間違って誰でも見れるような所に
置いたり事故が発生するから、使うなよって話してるんだが？
まあ、ニートじゃ雰囲気わからないだろうが。（苦笑）

>>562
本人が書き込んでたのか！w

>>565
早起きですね、ニートさん（笑）

>>561
最初の仮想マシンと同じ方法で更新すればいいじゃない？☺
OpenStack とかご存知でない？☺

>>565
Enterprise と、github.com の連携で internal リポジトリが作れるよ☺ 賢くなったね☺

>>568
手段が目的化してるな

>>569
ん？じゃあそれが「github相当物をオンプレで運用しろよ」じゃね？
君、話が読めてるのｗ？

>>571
ごめんよ…君の勝ちだ☺

>>572
まあ、いいよ。
ココは日本語理解できない奴ばっかりだし。
君もその一人ってことだよ。

>>573
お互い様に…ね☺

>>574
イヤイヤ、君だけだよｗ一緒にするなｗ

>>575
🙏🙏🙏

アホらし

このスレ勉強になる
皆さんありがとう

どういたしまして

>>568
> 最初の仮想マシンと同じ方法で更新すればいいじゃない？☺

「最初の仮想マシンと同じ方法」はとても大変な方法なんです。
OSの起動だけでも分単位の時間がかかる上に
イメージはでかく、それを配布する手段も確立されていません

個人的なWebサイトをDocker上に建ててローカルで見れるようにしてたんですが
今度引っ越すことになって外部からアクセスしなければならなくなりました

Linuxホスト上にVPNサーバ建ててVPN経由でアクセスするのと
Webサイトに無料DDNS追加して外部に公開するの
どっちがセキュリティや利便性的によろしいんですかね？

>>581
セキュリティや利便性の前に要件が違うだろ
まずどっちかに固めろ

自分の所（例えば自宅）からだけ見ればいいのか
それ以外の場所からも見えるようにしたいのか
それを決めるのが先だろ

↑それ以外の所からアクセスしたいからVPN鯖立てるんだろ。

>>582
自宅(サーバから見て外部ネットワーク)から見たいです
見るのは自分だけです

VPNならローカルで接続してるのと変わらない

>>583
VPNは自分しか見れないなら「自分の所」扱いです

>>581
あー、いいかい
それ、ドッカーンは1�_も関係ないよね？
スレチなんだわ

ドッカーってホストOSに影響なしで実行できるというけど
ドッカーでsshdのイメージ作れば影響なさすぎて
どこにもアクセスできないじゃん