Docker Part2©2ch.net

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

http://www.docker.io/

前スレ
Docker
http://mao.2ch.net/test/read.cgi/linux/1374861492/

もうLXCに依存してないんじゃ？

そうだね
前スレからそのまま持ってきてしまったか

>>1
乙

>>1
乙

本番系のマシンと、Docker動かしてるホストとで、カーネルのバージョンって
みなさんどこまで合わせてます?

うちはRHELで動いてる本番系と、それとコピーの総合試験環境があって、
そいつらはカーネルもパッケージもバージョン揃えてあるんだけど、
その手前の、コーディングとか単体試験とかをやるコンテナ動かすDockerのホストも
やっぱしカーネルのバージョン揃えるべき?

>>6
うちは本番系から単体試験ホストまですべてカーネル揃えることにしてるよ

Docket導入前だったけど、errataレベルの違いでI/Oスケジューラだったかの挙動が変わったことがあってね

理想はどうあれ、揃えておきなよ

本番系と、カーネルだけ揃えておけばいつでもコンテナ作れるっていうのが仮想マシンに対するDockerの大きな利点

カーネルをバージョンアップしてコンテナが壊れたんならさっさと作り直す、さっさと作り直せるように周辺の仕組みを整える、
消されて困るコンテナは作らない、他とカーネルを揃えられないコンテナも作らない、なんてことがDockerカンファレンスでも
強く言われてた

hoshu

Arukas終わったしもう遊べる場所はないのかな
GCPは制限ありそうだし

Linux板で言うことじゃないかもしれないけどWindowsでもHyper-Vで使えるようになってたんだな
Bash on UbuntuにDockerも使えてWindowsPC強制されて虐げられてもなんとかなるぜ

＞WindowsでもHyper-Vで使えるようになってた
Windows以外で使えるHyper-Vなんてあるの？

VirtualBoxが不要ってことを言いたかった

HyperV無しのWSLで動くようになる予定はあるのかな
MobyとかLinuxKitとか出てきたし

タグが<none>なイメージを削除するにはどうしたら良いですか？
普通に削除しようとすると、
Error response from daemon: conflict: unable to delete XXXXX(image ID) (cannot be forced) - image has dependent child images
※-fを付けても同じ。

docker rmi $(docker images -f dangling=true -q)だと、
"docker rmi" requires at least 1 argument(s).

そもそもdocker images -f dangling=trueは何も引っかからない。

"image name cannot be blank"
と出たこともありました。何のコマンドか失念。

このコンテナは起動もできません。
どうやったら削除できるでしょうか？

docker imagesってやったらどうでるの？

docker使うとこ増えたけど
アホって綺麗なサンプルいっぱいあるのになぜか設定ファイルグチャグチャ作るのな
結局構成管理出来ないだろ、あんなんじゃ

Dockerで設定ファイル？何の話だ？
Dockerで構成管理？何の話だ？
お前なんか勘違いしてそうだな

まあ言いたいことはわかるよ
それだって秘伝のシェルスクリプトを書き足すよりはずっといいさ

AWS Fargateってサービスがアマゾンからリリースされたらしいけど
それってなんなの？

docker系の技術は日進月歩すぎるのでredhatやcentosのような枯れたOSで使うのはきついですよね？
色々入れたり設定が必要だし。
お勧めなディストリはやはりubuntuやfedoraなどですか？

>>21
docker自体は日進月歩すぎるところがあるので、OSは枯れたモノを使うというのがベストプラクティス

fedoraでdocker運用するのって、fedoraのカーネル自体が不安定すぎて、コンテナ上げすぎると落ちたりするよ

>>21-22
枯れたOSでよく話が通じるな？
対応OS書いてあるんだから、それ使うだけじゃん

https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/
Artful 17.10 (Docker CE 17.11 Edge only)
Zesty 17.04
Xenial 16.04 (LTS)
Trusty 14.04 (LTS)

https://docs.docker.com/engine/installation/linux/docker-ce/debian/
Buster 10 (Docker CE 17.11 Edge only)
Stretch 9 (stable) / Raspbian Stretch
Jessie 8 (LTS) / Raspbian Jessie
Wheezy 7.7 (LTS)

https://docs.docker.com/engine/installation/linux/docker-ce/centos/
To install Docker CE, you need a maintained version of CentOS 7. Archived versions aren’t supported or tested.

https://docs.docker.com/engine/installation/linux/docker-ce/fedora/
25
26

https://docs.docker.com/engine/installation/linux/docker-ee/rhel/#prerequisites
To install Docker EE, you need the 64-bit version of Red Hat Enterprise Linux 7 running on an x86 hardware platform, or s390x (IBM Z) architecture.

Dockerの古いバージョンならもう少し古いディストリでも動くかもな

俺、OpenSuseで使ってる変態。

Redhat/CentOSはカーネル古いから新しいバージョンのdocker composeが使えないよ

>>25
そんな制限あったっけ？
どこかに書いてある？

GUIいらないからホストOSも軽くて無駄がないalpineにするのが好き
ほとんど何もできないから逆に後腐れなく気軽に捨てて新しくできるし！

俺はホストにはfedora atomic使ってるぞ

なんかlinuxがいいものになったかのような錯覚をおこすわ

coreosで使ってるっていう生粋のドッカーはいないのか？

CoreOSはもうねぇだろ

coreOSってalpine以上に使いにくくて何が良いの？って感じなんだけど何か取り柄はあるのかね

RancherOSが出たときコレは来るかと思ったがそうでもなかった

雨後の筍のようにポコポコ出てくるな
はやく収斂してくれ

そいつらがいずれ、どうにもつまらない理由で内輪もめを起こしてまとまらなくなり
あの機能はそちらにしかない、その機能はあちらにしかない、なんて状況となってる間に
OracleやMSに持っていかれる、というところまでがテンプレ

誰かが早く僕の考えた最強Linuxを発表しないとな。
え、それが乱立してるって？

BargeっていうのがDockerホスト用で最軽量・高速ブートをうたってるけど
これVirtualBox専用でノートPCとかには直接インスコできないのかな？

更新頻度は高いみたいだから物理マシンでも動けば最強候補じゃないかコレ

それ完全にvagrant用では？

RaspberryPiで使えますみたいなことは書いてあるね
普通には使えないっぽいのは何か残念だな

やっぱubuntu + kubernetesがいいのかな

これからはなんでもかんでもコンテナって時代になるのですかね？
自前でリポジトリをシコシコ築いてきたディストリベンダーも
もはややる意義を失っちゃったりするんですかね？

未だにコンテナとchrootの違いが理解できない

chはchangeの頭文字から取っているから
rootの変更って意味だろう
コンテナはOS内にあるけど完全に独立しているから

例えばある家族の家の中で、
親がroot
子供がchroot
ホームスティしてきた外国人娘がコンテナだ

>>41
コンテナ使い出すと便利すぎてディストリあれこれこだわってたのが笑えてくるほどだね

そして指摘の通り、独自にバグ潰しとかやってる一番活発なリポジトリ持ってるところと
逆に古いツールを保守し続けてるところはもてはやされてるが、それ以外が意気消沈してる
二極化だな

リソースが集中するのはいいことではあると思う

パッケージ管理ツールをLSB前提でpythonやperlで書いてたところは
それが原因でコンテナイメージのサイズをある一定以下に削減できなくてイーッてなってた

かと言ってパッケージマネージャーは各ディストリのシステムに根深く食い込んでるから
切り離そうにも切り離せない・・・最近じゃsystemdの呪縛もあるだろうし

でもまさかパッケージを単品ごとにインスコする日が来るとは誰も思ってなかったんだよな結局は

コンテナってもっと早く登場しても良かった気がするんだが
技術的にはホスト型ハイパーバイザ型の仮想化よりも簡単なんじゃないの？

そりゃ日本での常識だな、
日本は金持ちだから高性能コンピューターが当たり前だけど
世界的にはようやく高性能コンピューターが普及してきた
ようやっとOS内にOSをおいても通常に使えるぐらいのPCが普及してきたんだ

それはひょっとしてギャグで言ってんのか

コンテナは昔からあっただろ
Linuxに来るのが遅かっただけで

user mode linuxはコンテナに入りますか?

コンテナ内のプロセスがしんで終了しても自動でコンテナ再起動してくれるオプションがあった
コレ使えばわざわざプロセス死活監視用ツール起動しなくて良くなるのか
ちょっとスゴ杉ない？

そんなもんsystemdに標準搭載されてる機能だろ

dockerコンテナってホストOSのカーネル使ってるの？
どこもそう説明してるんだけど、ベースイメージにlinuxつかってその上にmysqlとか載せてイメージ化してるって認識だったんだが。

ホストのカーネルを使っているという説明で合っているよカーネルの上で動かすカーネルとかもうそれVMじゃん

>>55
ありがと。
そうなるとwindowsだとdockerインストール出来るけど、エンジンとかに工夫してあるのか

ttps://www.slideshare.net/zembutsu/docker-images-containers-and-lifecycle
ここの19ページめに、ベースイメージにイメージ層を載っけていくて記載あるけど、
これは間違ってるの？

http://www.publickey1.jp/blog/17/dockerlinuxkitlinux_subsystemdockercon_2017.html
こういうのじゃね？

>>57


https://github.com/docker-library/mysql/blob/6c414e7f38c2079c7193beae5dc7c34ee46cd6e7/8.0/Dockerfile
mysqlのdockerfileだと FROM debian:jessie ってあるけど、
これはどうなの？？
何かこんがらがってきた。
sshで入れるし、やっぱ根底はlinux立ち上がってるのか？

おい、素人同士で勝手に話をすすめるなｗ

>>55
> カーネルの上で動かすカーネルとかもうそれVMじゃん
VM=仮想マシン＝マシン（ハードウェア）を仮想化してないならVMにはならない

>>54
> dockerコンテナってホストOSのカーネル使ってるの？
そもそもホストとかゲストとかいうものがない

Linuxっていうのはカーネル（https://www.kernel.org/ で配布しているやつ）に
DebianやらUbuntuやらRedhatなんかが、いろんなアプリをセットにして配布してる

カーネルは基本的に汎用。だから同じカーネルを使っても
DebianやCentOSなんていう別のディストリが作れる

さてパソコンにDebianをインストールしたとする。そこにはカーネルといろんなアプリが有るわけだが
Dockerで作ったDockerコンテナはこのうちカーネルだけを利用する。

例えばFROM debian:jessieであれば、debian:jessieのディスクイメージを使うと考える
そのディスクイメージにはもしかしたらカーネルのバイナリも含まれてるかもしれないがそれは使わない。
パソコンにインストールしてあるカーネル + FROMの元になったディスクイメージ を使ってアプリを動かす

そんなもんだから、Debianをインストールしていたとしても、UbuntuやCentOSのディスクイメージを使うこともできる

パソコンにインストールしたカーネルを使う。
そこで疑問になるかもしれない。

幾つものDockerコンテナが同じカーネルを使っているとしたら
psコマンドでプロセス見た時、他のコンテナのプロセスまで見えてしまわないのか？と

そこで出てくるのがLinuxカーネルに搭載されたコンテナ機能
この機能によって各コンテナは別々に隔離されることになる

同じカーネルを使っているというのに、それぞれ別々の環境を持っているようにみえる
ファイルシステム空間を分離したり、プロセス空間を分離したり、
メモリ空間を分離したり、ネットワーク空間を分離したり
ありとあらゆるものを分離して独立した環境を作り出している

それが大変な作業だった

さて、ここまではパソコンにインストールされたものがLinuxの場合だけど
WindowsやMacOSはどうなっているのか？

コンテナ機能っていうのはLinuxカーネルが持っている機能だが
WindowsやMacOSはLinuxではない。
どうやってLinuxのカーネルの機能を使っているのか？

答えを言ってしまえばあたり前のことだが、WindowsやMacOSでは
裏で仮想マシンが起動していてLinuxがインストールされている

ちょっと前までの、Docker Toolboxと呼ばれていた時代はVirtualBoxを使っていた。
今のDocker for Windows および Docker for Macでは
WindowsではWindows標準のHyperVを
MacOSではMacOS標準のHypervisor Frameworkを利用したHyperKitを使っている

仮想マシンを使っていると言ってもDockerに最適化されており
Windows もしくは MacOS のCUIからdockerコマンドを動かすとちゃんと
使えるように構成されており、まるでLinuxと同じようにOSの上に直接dockerが
起動しているようにみえる。だけど実際は仮想マシン上で動いているので
Dockerの設定画面にはメモリをどれだけ仮想マシンに割り当てるかなどという設定が存在する

余談だがWindows 10ではWSLという仕組みによって
LinuxカーネルをNTカーネルでエミュレートしている

今ではLinuxカーネルを使っていないのにUbuntuが
Windows上で動作するようになっている。

もしこのWSLがコンテナ機能までエミュレートする完璧なものになったら
その時はWindowsでHyperVを使わずにDockerが動くようになるだろう

>>62
親切すぎて草
下手な記事よりわかりやすい

＞もしこのWSLがコンテナ機能までエミュレートする完璧なものになったら

なるのかね？
最近MSがLinuxに擦り寄ってて気持ち悪い

>>62
帰ってきたらすごい丁寧なレス来てたっ
ありがとうございます

> 例えばFROM debian:jessieであれば、debian:jessieのディスクイメージを使うと考える
> そのディスクイメージにはもしかしたらカーネルのバイナリも含まれてるかもしれないがそれは使わない。

ttps://github.com/aws/amazon-linux-docker-images/blob/10641478ad16c6f44b691dc41acfc221c7a7594f/Dockerfile
たしかにamazon linuxの中見ると、コマンドとかは設置してるけど/boot のカーネルとかは置いてなかったわ

windows, macも結局裏では仮想化されてたのね
色々わからなかった所が一遍にわかったわ！

>>59-62
これは永久保存レベル

Github上のissueでもWSLだけでLinuxコンテナ動かしたいって要望はかなり挙げられてて
MSスタッフからみんなの期待は認識してますってレスも付いてた
もしホントに実現したら世界が変わる！みたいな投稿もあって大げさだけどちょっと同意しちゃう

>>59-62を書いた本人だけど、なんでこんなに喜ばれてるんだろう？ｗ
WindowsやMacOSでDocker使ってる人にとっては常識だと思ったんだけどね

最近MacOSでDocker使ってる人なのかな？
昔はVirtualBoxのインストールが必要だし
今もWindowsならHyperVの有効化が必要
仮想マシンが使われてるのはすぐにわかると思ったんだけど

あと仮想化という言い方は良くない
色んな意味の仮想化があるから

WindowsやMacOSで使った時のDockerのボリュームって謎だよね

例えばWindowsでdockerコマンド使った時、Windowsのディレクトリを
ボリュームとして指定すれば、dockerコンテナの中から見える

Linuxでは当たり前の動作だけど、WindowsやMacOSでは仮想マシンで
dockerが動いてるのだから、単純に考えれば仮想マシンの中にボリュームができるはず

まあホストOSのディレクトリを仮想マシンのディレクトリにマッピングしてるんだろうけど
Docker for WindowsやDocker for Macではそういうことを感じさせない作りになってる

vagrant入れて色々弄ってた後にdockerやったから全然気付かなかった
職場macで家はwindowsで、両方vagrant入れてたしね

ネットで調べても、その手の情報全然見なかったよ
本読んで勉強しろって話なのかな？

>>67
自分は初心者なのでナイスな解説に出会えてラッキーでした
ありがとう

俺も最近、Docker for Windows入れてみてたばかりなんで、HyperVが必要な理由とかが分かって参考になった

> ネットで調べても、その手の情報全然見なかったよ
> 本読んで勉強しろって話なのかな？
そうなんか？ じゃあなんで俺知ってるんだろう？ｗ
もう3年ぐらい前から触ってるからなぁ。当時はWindows使っていたし（今はMacOS）

まあ普通DockerってLinuxで使うもんな。Dockerの解説といったら普通Linux上の話だし
WindowsやMacOSでどうやって使えるようにしているのかまでは関係ないか

じゃあおまけでもう少し仕組みの話を。

Dockerっていうのはクライアント・サーバー型の設計になってる
つまり通常端末から実行しているdockerコマンドとサービスとして実行する
dockerサーバーが存在する(紛らわしいことにどちらもdockerコマンド)

サーバーの方のdockerは説明したとおりWindowsやMacOSでは仮想マシンなしには動かない
だけどクライアントはWindowsやMacOSでも動く
(dockerはgoで作られておりマルチプラットフォームになってる)

クライアントーサーバー型ということは、ようするにdockerサーバーを
リモートのLinuxで動かしていて、手元のWindowsでdockerコマンドを叩いて
接続するということができる。ちなみにdocker buildを実行すると手元のDockerfileやDockerfileと
同じディレクトリにあるファイルを全てリモートに送信してDockerイメージをビルドしている
(なので手元にごみファイルがあると遅くなるよ = dockerignoreの話につながるが省略)

使い方の一つとしてあちこちのLinuxサーバーでDockerサービスが動いていて
手元から接続先を切り替えて操作するというものがある
この時に使うのがdocker-machineで環境変数DOCKER_HOSTなどを管理する機能がある

Linuxでローカルのdockerサーバーに接続するときはsocket経由で接続するんだが
Docker Toolboxの時代ではTCPで接続するためにWindowsやMacOSXではdocker-machineが必要だった

でも最新のDocker for WindowsやDocker for Macではdocker-machineが必要なくなっている
どういう仕組みになってるんだろうね？ｗ
少し前の手順を見るとdocker-machineがでてくると思うがローカルのDockerに接続するだけなら忘れていい

今はWindowsでもMacOSでも、ローカルのDockerに接続するときはTCP通信を使っていない(はず)だけど
WSL(Linux用Dockerサーバーは動かない)環境から、dockerクライアントのLinux用バイナリを使って
HyperV上で動いているDockerサーバーに接続するときは、TCPでつなぐ必要がある。その時に必要になるのが
「Expose daemon on tcp://localhost:2375 without TLS」というやつ。詳しくはぐぐってくれ

もう一つ思い出したが、Docker for WindowsはHyperVで動いているのでVirtualbBoxとは同居できない
vagrantを使うのならVagrant+VirtualBoxではなくVagrant+HyperVで使う必要がある

>>73
勉強になります

最近はOS、仮想化、dockerと色々と入り乱れて全体像を理解するのに苦労するなぁ
ま、所詮パンピーですから

dockerとkubernetes使いこなせないと時代遅れになるぞって言われたけど
一般の開発者がkubernetesを必要とするシーンってどのくらいあるのかな
dockerは問答無用で便利だけど

dockerとkubernetesの間にクラウド（aws、gcp等）があるね
クラウドを使わなければkubernetesはでてこないだろう
ローカルでのサービス開発用途であればdocker-composeで十分だし

kubernetesはなんかクラウドの上でクラウドを作ってる感じで、
将来的には、いろんなクラウド会社の共通インターフェースに
なるんじゃないかって思ってるけど、今は各社のクラウドのサービスに
kubernetesが対応しきれない感じ。だって自社のGCPすら完璧にコントロールできないもの

例えばオートスケールしたいならkubernetesを使わないで直接クラウドの
機能のオートスケールとかした方がいいんじゃないかな

なぜならkubernetesの場合コンテナのオートスケールになるわけだけど
起動しているVMの中でコンテナをオートスケールするだけなので
VMの数もオートスケールしないとコストは下げられないから

kubernetesを使っても頑張ればコストを下げられるオートスケールは
実現できるんだろうけど、コンテナとVMの二重のオートスケールが実行されて
少数のコンテナだと多分不安定になりそう。何十台レベルで常時コンテナが
起動してる状態じゃないと安定させられないんじゃないかな？

それが将来はコンテナのオートスケール = VMのオートスケールになるんじゃないかって思ってる
で最終的にはVMを使う＝裏で勝手にkubernetesが動いてる時代になるんじゃないかな
そうなってくるとkubernetesは確かに必須。だけど意識しない状態になってると思う

でも個人的にはkubernetesの方向じゃなくて、クラウド自体がコンテナに
直接対応してくれる方を望んでるけどｗ（例えばGCEは起動するコンテナをデプロイできるようになった）

kubernetesはバージョンが勝手にアップグレードする（GCPの場合）ことを考慮しないといけないのと
kubernetesを動かすだけで各VMで1.5GB以上のメモリを使用するのが気に入らない

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

PTHNS6LLYQ

kubernetesはほぼ全部の業界大手が参画してるけど
そんでもコケるってことあるんかな
いやまぁ莫大な金が動くインフラ業界だからねぇ

Docker swarmが本命じゃないの？

>>79
もうフェードアウトフェーズだよｗ

DockerもついにKubernetesをネイティブでサポート、Swarmの併用も可能
http://jp.techcrunch.com/2017/10/19/20171017docker-gives-into-invevitable-and-offers-native-kubernetes-support/

しばらくはswarmでもできる！とかやるだろうけど
次第にフェードアウト

小規模ではdocker-compose一択って事でおk？

小規模っていうか、1台のマシンの場合って考えてるよ
開発用メインでdocker runのオプションを指定するのが
面倒になった時ｗ

Docker toolboxの最新版（18.01.0-ce）を入れたら何故かdockerのデーモンに接続できなくなったけど
VirtualBoxのGUIから仮想マシンを止めたら直った

docker-machine restartは効果がなかった

なんでvirtualbox？

Docker toolboxってwin/mac上にlinux走らせてその上で更にdockerしてるからね

いつの話？

誰もがWindows Proを使えるわけじゃないからなぁ
VirtualboxベースのDocker toolboxはまだ必要意義は大きい

Hyper-VはProfessional以上必須なのか。
リモートデスクトップサーバ使いたいから、"わざわざ"Professionalのライセンス
にしてるけど、Docker for Windows (Hyper-V)を使うために必要ってのは微妙。

Docker使ってるとKubernetesしたくなってきてKubernetes on Atomic Host on Hyper-Vとか組みたくなるしへーきへーき

>>88
そういう人のためにDocker Toolboxというのがある

coreOSがRedHatに買収された

CoreOSはDocker利用を想定してたけどコレジャナイ残念OSだったので次はRancherOSあたりに期待してる

>>91
ヤフーの記事が、港のコンテナヤードの画像使ってて混乱したわw

クジラの方のコンテナって言えば通じる

コンテナをビルドするとき Dockerfile 内で

RUN yum list

した結果を、ホスト側に残したいんだけど、なんか良い方法ないかな？

>>95
Debian 使いだから勘違いしてる可能性が高いけどこういう感じで tee とかリダイレクトじゃダメなの？

$ cat Dockerfile
FROM centos

RUN yum list installed | tee yum.list
$ docker build -t yumlist .
~~snip~~
$ docker run --rm yumlist head -n5 /yum.list
Loaded plugins: fastestmirror, ovl
Installed Packages
acl.x86_64 2.2.51-12.el7 @CentOS
audit-libs.x86_64 2.7.6-3.el7 @CentOS
basesystem.noarch 10.0-7.el7.centos @CentOS

>>96
便利なやり方が無いかなーと思って。
一度起動してその出力を回収する方法しかないね。

/var/lib/docker/tmp
/var/lib/docker/containers
→単純にtmpfsにできる

/var/lib/docker/overlay2
→ここをtmpfsにすると再起動で空になったとき整合性エラーでコンテナが起動できなくなる
→かと言ってtmpfsをupperとしてoverlayfs化しても別エラーが出る（恐らくlower側のハードリンクが作れなくなるため）

/var/lib/docker全体をtmpfsにすれば整合性もハードリンク問題も解決するけど
消費メモリが増えるのとanything-sync-daemonとかでバックアップの手間も増える
システム再起動後にコンテナ自動起動しないならsync不要だけどイメージダウンロードからやり直しになって鬱陶しかった

☆ 現在、衆議員と参議院の両院で、改憲議員が３分の２を超えて
おります。総務省の、『憲法改正国民投票法』、でググってみてください。
国会の発議はすでに可能です。日本の、改憲を行いましょう。
平和は勝ち取るものです。お願い致します。☆☆

>>98
その問題は /var/lib/docker 以下が ext4 なら、fstab でマウントオプションに commit=300 とか付けると結構な対策になる

短命コンテナをバンバン使い捨てるケースで .../docker/overlay2 にゴチャゴチャ置かれても
sync 前にすぐ消えたファイルやディレクトリは単に無視されてディスクには書き戻されなくなって安心
デフォの 5 秒だとちょっと早すぎるんだよな
欠点はもちろん不意の電源ダウンで指定秒数ぶんだけデータロストする可能性があることだけど
ノートだったり UPS あったり、吹っ飛んでもいいや的な状況なら sync-daemon 系も不要だから楽

俺は USB メモリだけで運用してると 1 年ちょっとで寿命が来て色々と試行錯誤の後
Arch のフォーラムかどっかに書いてあったこのシンプルな方法に落ち着いた

dockerfile使わずにAnsibleでコンテナ構築してる人居ます？
物理で構築してたPlaybookのTarget SectionにDocker使うよって一行追加すれば使えるし(厳密には使えるようにするまでに色々設定は必要だけど)、
仮にコンテナのデファクトみたいなものがDockerじゃなくなっても最悪SSHで接続さえ出来れば流用できるからこのやり方良いなと思ってるんどけど。