[過去ﾛｸﾞ] Docker Part5 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
497: 2021/02/06(土)13:51 ID:/etxQc2p(2/2) AAS
どんなプロダクトでも黎明期を超えて落ち着いてきたらセキュリティ、軽量さのために余計なもん削ぎ落とした物に取って代わるもんだよ
498: 2021/02/06(土)15:28 ID:M2uozTfZ(1) AAS
何時になるのかはわからんけど本格的に使ってみてもいいかなって思うのはver3.1からだろ
黎明期は仕様変更多すぎて手を出したくない
499: 2021/02/06(土)19:49 ID:MHK1//hz(2/2) AAS
docker swarm使いやすくてオヌヌメです
500: 2021/02/06(土)20:07 ID:yp1IqyME(1) AAS
今だったらk0sのほうがいいんじゃないの
501: 2021/02/06(土)20:10 ID:/TPKq5C8(3/3) AAS
いらんわ。
502(1): 2021/02/07(日)07:17 ID:271PT8oq(1/3) AAS
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をつかって、
コンテナを復元します。
省3
503: 2021/02/07(日)09:02 ID:Klq9yVmM(1) AAS
>>502
コンテナ管理するのにオーケストレーション使うからそんなこと考えたことないけどそれで動くならシンプルでいいんちゃうか？
504(1): 2021/02/07(日)09:33 ID:5dw25W1G(1) AAS
ボリュームの移動とか考えてる時点でバッドプラクティスにハマってる気がする
ほんとに永続化したいボリュームにはネットワーク越しのストレージを使うんだよ
そうすりゃコンテナが別のマシンで稼働してもいちいちボリュームを移動させる必要はないだろう？
コンテナは同じマシンで動き続けることを前提にしちゃだめ
505: 2021/02/07(日)09:37 ID:lg7zbpCt(1/10) AAS
GitHub ActionsはDockerHubの制限免除だって
506: 2021/02/07(日)09:39 ID:lg7zbpCt(2/10) AAS
外部ﾘﾝｸ:github.com
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と連携して、新しいレート制限の影響を受けないようにしています。
プライベートコンテナが必要な場合でも、パブリックリポジトリのフォークに関するその問題の解決策はありません。
507(1): 2021/02/07(日)10:06 ID:O8a0UlPi(1) AAS
>>504
ただの老朽更新とかの移行だろ
そんなもんに共有ストレージとかバカじゃねーの
508: 2021/02/07(日)10:25 ID:vLjACvPj(1/3) AAS
AWSならEBSボリュームのスナップショットで十分
ASG内のインスタンスが起動する時に
EBSボリュームをマウントして
ECSタスクではそのボリューム内のディレクトリをマウントする
EFSみたいなマネージドNFSは速度や互換性に問題無ければ使っても良いんじゃね
俺は使わないけど
509: 2021/02/07(日)10:37 ID:+SWvD/Px(1/5) AAS
>>507
バカだな
ストレージを外部化しておけば結合が疎になりストレージのメンテナンスもしやすくなるだろ
510: 2021/02/07(日)10:40 ID:+SWvD/Px(2/5) AAS
だいたいコンテナなんてのはどのマシンで動くかわからねえんだ
ローカルボリュームに依存しちゃだめだ
511: 2021/02/07(日)10:45 ID:+SWvD/Px(3/5) AAS
コンテナはどのマシンで動くかわからねえってのは重要なことだ
固定的なマシンで動かす前提ならコンテナを仮想マシンの延長上的な使い方しかできてないってことだ
固定的なマシンならコンテナじゃなくていい
普通にパッケージ入れて普通にsystemdで動かせばいい
どのマシンで動くかわかってるんだから事前に必要なものを準備するだけ
dockerという余計なレイヤーが消えるのでそのほうが管理が容易い
コンテナを使うなら次の瞬間にコンテナが別のマシンに移動しても動くように作れ
512: 2021/02/07(日)10:52 ID:Scp8nGyH(1) AAS
あ、キ○ガイだった
513: 2021/02/07(日)10:53 ID:+SWvD/Px(4/5) AAS
理解できない雑魚は仮想マシンでも使ってろってこった
514(1): 2021/02/07(日)11:24 ID:+SWvD/Px(5/5) AAS
俺のアドバイスを無視して、どうしても、ローカルボリュームに執着し、コピーしたいなら
docker公式文書にtarコマンドによるボリュームバックアップの方法論が書いてある、ので探せ
あとは応用だ。パイプラインと-Hフラグが便利だぞ
515: 2021/02/07(日)11:34 ID:GfGDiZUb(1) AAS
ネットワークが落ちたらどうすんの？
516: 2021/02/07(日)11:51 ID:vLjACvPj(2/3) AAS
データベースだったらデータベースのレプリケーション機能で耐障害性の高い構成にするのがベストプラクティス
ボリューム自体はローカルにする
これが最も高い速度とHA（高可用性）を両立できる構成
ただ、自前でHAをセットアップして運用するのは大変な事も多い
マネージドサービスつかうか
k8sならオペレーター使うとかした方が良い
のっぴきならない事情でアプリをHA対応に出来ない場合は
NFS使って速度は諦めるか
HAの方を諦める
アマゾンのマネージドNFSは一貫性のために性能を犠牲にしてる
省1
上下前次1-新書関写板覧索設栞歴
あと 486 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.021s