systemd-nspawnに関するn314のブックマーク (3)
-
ずいぶん前の記事だが これ dockerやめてどうしたか？ とか これ Docker ではないコンテナ systemd-nspawn を使ってみた / マスタカの ChangeLog メモ を最近読んで僕も知識不足で自分にイラッときたのでちょっと考えてみた。 なお仕事でコンテナを使った経験はない。 あとsystemd-nspawnとかLXDは適宜各﹁システムコンテナ技術﹂に置き換えても同じ。 TL;DR 自分は以下で判断することにした。 1. とりあえずDockerイメージがないか探して自分が起こそうとしている環境が簡単に実装できるか見極める 2. オーケストレーションする以上に手を加える必要があるならsystemd-nspawnやLXDなどを使う Dockerfileをいじって思ったのは、 DockerHubなんかにあるDockerfileから実行プロセスを追加・変更するべきではないとい
-
2017/02/18 /var/lib/machinesの所在についてを追記 systemd-nspawnが何かはsystemd-nspawn – ArchWikiを見ていただくとして。 systemd-nspawnはネットワークに関して何も指定せず起動すると、ホストと共通のネットワークになる。同じIPアドレスを持つ、みたいな感じ。特に何も考えなくて済むので楽と言えば楽だけど、コンテナを仮想マシンみたいな感覚で触ろうと思うと、なかなかキツい。sshのポート変えれば区別出来るけど、みたいな状況になってしまう。 -n︵–network-veth︶オプションをつけると、ホスト・コンテナ双方に仮想イーサネットインターフェイスを作成して、これを接続する。ホストの下に新たにネットワークを作るようなものなので、お隣のパソコンからコンテナにアクセスしようとすると、きちんとルーティングしたりIPマスカレード
-
前回、 自作FRPライブラリTimeEngineをブラッシュアップして http://timeengine.github.io/ を公開しました。 次回は、その日本語訳、 Reactの応用技術、あるいはReact再入門についての記事をUPしますのでお楽しみに！ と書いていたのですが、Dockerじゃないsystemd-nspawn＋machinectlが非常に良い、ので予定を変更して、こちらを先にエントリします。いろいろ印象を忘れないうちに。TimeEngineに関してはとりあえず自分がすでに英文で書いたものを和訳してどこかにUPしておいたほうが、何か別展開や国内のためになるかな程度のことなのでお急ぎの方は上記リンクから英文読んでください。そちらも全部仕上がっているとは言えないですし、行き届いていないところをセルフチェックするために和訳もしておこうという感じです。 実用的で枯れた技術﹁コン
-
1
"dockerやめてどうしたか？"を読んで - Qiita
systemd-nspawnでコンテナをブリッジ接続する | お茶漬けぶろぐ
Dockerじゃないsystemd-nspawn＋machinectlが非常に良い
