Ubuntu18(17)からネットワーク設定にはNetplanが推奨されるようになった。Netplanに関しては、まだ日本語での公式リファレンスも少なく、使い勝手もわからない人も多いと思う。公式ページのリファレンス(https://netplan.io)に従って、Netplanの説明と使い方を日本語に翻訳した。
本記事は、https://netplan.io/designを日本語訳した記事である。
目次
- 概要
- 鍵となるゴール (原文: Key Goals)
- 要求事項
- デザインの概要
- 設定ファイルフォーマット
- *.yamlの一般構成
- デバイス制御ID(原文: Device Configuration IDs)
- コマンド
- ユースケース
概要
/etc/netplan/*.yaml
の中には、Snappy、クライアント、MAAS、cloud-initのための中央集権的なネットワーク設定ファイルが存在する。全てのインストーラはこのファイルのみを生成し、従来Ubuntuで用いられていた、/etc/network/interfaces
は、今後用いない。また、様々な操作をするため、Netplanのコマンドラインツールも用意されている。
システムは初期ブートの段階で、ネットワークレンダラーを用いて設定を行う。ネットワークレンダラーは/etc/netplan/*.yaml
を読みにいき、デバイスの制御を特定のネットワークデーモンにハンドオフするために/run
以下に設定を書き出す。
- WiFiとWWANに関しては、NetworkManagerが制御する
- その他の制御デバイスに関しては、特定のデバイスを指定しない限り、デフォルトでnetworkdが制御する
- この設定ファイルによってによってカバーされないデバイスに関しては、システム内でNetplanで制御しない
鍵となるゴール (原文: Key Goals)
- initframfsで使用可能
- 設定は元となるYAMLファイルのみで制御され、永続的な設定は存在しない
- 設定ファイルがなければ、デフォルトのポリシが適用される
- パーサはアプリケーション(libvirt、lxd)に対して特定のネットワーク設定(virbr0、lxdbr0)をパッケージ化できるようにするため、またあらゆることのためにNetworkManagerを使ってグローバルデフォルトポリシを変更することをできるようにするため、複数の設定ファイルをサポートする
- 生成された設定は一時的なので、後からバックエンド/ポリシを後で変更するた柔軟性を維持し、また"apt purge network-manager"にも対応する
要求事項
- オラクルからのホスト上でのネットワークの初期設定(MAAS、Cloud、Installer(Subiquity/Ubiquity)、WebDM)
- 機械翻訳可能、また人間による設定の可読性がある: YAML
- リンクとIP設定(リンクプロパティ、IPネットワーク設定オプション)、bond-、bridge-、ipv6-*などの上でフルコントロールの許可
- MTU、wake-on-lan、ethtoolの設定
- ルールベースの設定適用
- スマートな初期設定に関連している。例: Ubuntu Coreでは、どんなボードであるかによらず、オンボードインタフェースの上ではDHCPが常に実行したいかもしれない
- 予測されるフォールバック設定を備えたスマートな初期設定
- クラウドのVMをサポート(EC2、Azureなど)
- LXDのコンテナをサポート
- ベアメタル(ISO)上でのサーバ起動をサポート
- MAASを通じたサーバ起動のサポート
- 設定ファイルなしの適切なバックエンドの自動選択。一方で、あらゆる目的でNMを使うために、デスクトップ使用を考慮した着脱可能なポリシであること
- 既存の70-percent-net.rulesを持つものや、"net.ifnames=0"などで起動する古いイメージとの互換性
デザインの概要
設定ファイルフォーマット
Netplanの設定ファイルはすべてYAMLの形式で書かれ、いわゆるバージョン2の形式である。ちなみにバージョン1に関しては、現在のMAASやcurtinで用いられている。
*.yamlの一般構成
トップレベルノードには、network
を記述する。次のレベルには、version: 2
と、イーサネットや、WiFi、ブリッジのようなデバイス定義グループを記述する。その下には、それぞれのデバイスに関する設定を記述していく。これらは、レンダラが理解でき、バックエンドによってサポートされるタイプである。
また、おのおののタイプブロックはデバイス定義を含み、そのデバイスはconfigurations IDsと呼ばれるキーにマッピングされる。
デバイス制御ID(原文: Device Configuration IDs)
デバイスごとの定義マップ(ethernet:
など)の下のキー名はIDと呼ばれる。それらは設定ファイルセットの中でユニークでなければいけない。それらの主目的は、複合デバイスに対してアンカー名として働くことである。例えば、既に定義されているブリッジのメンバを列挙するために使われる。
IDには物理的・構造的に異なる2つのデバイス定義クラスがあり、IDフィールドはそれぞれ異なる解釈がなされる。2つのデバイスクラスは、物理(Physical)、仮想(Virtual)である。
物理デバイス: Physical Devices
例: イーサネット、WiFi
これらのデバイスは、リブート中から起動中まで、動的に抜き差し/着脱することができる。一般的なケースでは、このデバイス群は設定したい項目に対して、デバイス名や、MACアドレス、ドライバやデバイスパスなどのプロパティからmatch
ルールに適合したものが選択され、反映することができる。また、これらの条件は普通、不特定多数のデバイスとマッチしてしまう可能性がある。なので、ハードウェアについての記述がない場合は、これらのデバイス群は常にグループとして扱われる。
また、特定の知識がある場合、もしくはパスやMACなどのユニークなプロパティを用いた場合、マッチルールはマッチする単一のデバイスに対して書くことができる。その場合、set-name:
プロパティを用いることで、デフォルトのデバイスのインタフェース名とは異なる、任意の名前をデバイスにつけることが可能になる。set-name:
を用いたときに、その他のデバイスがルールにマッチしてしまった場合、そのデバイスは名前の変更に失敗し、オリジナルのカーネル名を継続して用い、dmesgでerrorを出力する。
全くマッチルールが指定されない場合でも、問題はない。そのような場合、IDフィールドはインタフェース名でマッチされる。簡単に使いたい場合や、ネットワークデバイスの設定に時間をかけたくないときは、、この手法が最も役に立つ。
もしマッチルールがあった場合、IDフィールドは、設定ファイル内の複合デバイスの定義からの参照のためのみに使われる、純粋な不透明な名前(原文: a purely opaque name)である。
仮想デバイス: Virtual Devices
例: veth、bridge、bond
これらのデバイスは、完全に設定ファイル内とネットワークスタックの制御下に置かれる。つまり、これらのデバイスは、マッチされる代わりに生成されている。したがって、match:
やset-name:
はこれら仮想デバイスには適用することができず、またIDフィールドは作成された仮想デバイスの名前となる。
複雑なYAMLの例
Ubuntu16.10の初期実装のために計画されていた、最も利用されるであろう機能を示す。
network: version: 2 # if specidied globally, can ony realistically have that value, as # networkd cannot render wifi/3G. This would be shipped as a separate # config.d/ by desktop images # it can also be specified by-type or by-device renderer: network-manager ethernets: # opaque ID for physical interface with match rules # only reffered to by other stanzas id0: match: macaddress: 00:11:22:33:44:55 wakeonlan: true dhcp4: true addresses: - 192.168.14.2/24 - 2001:1::1/64 lom: # example for explicitly setting a backend (default would be networkd) match: driver: ixgbe # you are responsible for setting tight enough match rules # that only match one device if you use set-name set-name: lom1 dhcp6: true switchports: # all cards on second PCI bus # unconfigured by themselves will be added to br0 below match: name: enp2* mtu: 1280 wifis: all-wlans: # useful on a system where you know there is # only ever going to be one device match: {} access-points: "Joe's home": # mode defauls to "managed" (client), key type to wpa-psk password: "s3kr1t" # this creats an AP on wlp1s0 using hostapd # no match rules, thus ID is the interface name wlp1s0: access-point: "guest": mode: ap channel: 11 # no WPA config implies default of open bridges: # the key name is the name for virtual (created) interfaces; # no 'match' or 'set-name' attributes are allowed. br0: # IDs of the components # switchports expands into multiple interfaces interfaces: [wlp1s0, swtichports] dhcp4: true routes: - to: 0.0.0.0/0 via: 11.0.0.1 metric: 3 nameservers: search: [foo.local, bar.local] address: [8.8.8.8]
コマンド
- Generate 初期ブート中に実行され、設定ファイルを読みに行き、設定をファイルに書き出す
- Apply ネットワークの設定を実現するために、様々なバックエンドへ設定を伝え、適用
- List
- Update
- Config Set:インタフェースの現在の設定をYAMLにキャプチャする Show: システム内の現在の利用可能なすべての設定をマージして出力する
ユースケース
Netplanを使ういくつかの方法を示す。
Discovery (Subiquity)
CathyはUSBキーを用いて、Intel NUC上で、最新のUbuntuサーバイメージを起動する。NUCは有線イーサネットポートと、無線のNICが内蔵されており、また現在は接続されていないが、USB-NICも接続されていた。インストール中、インストーラはCathyに3つのインタフェースを示す。Cathyは有線のイーサネットデバイスを選択する。このデバイスは、DHCPによってIPを制御する唯一のデバイスであった。インストール完了後、CathyはNUCをリブートし、次に示す/etc/netplan/01-install.yaml
を見つける。
network: version: 2 ethernets: # configured by subiquiry eno1: dhcp4: true
インストーラは明示的に選ばれ、制御された有線デバイスの要素を含んだ、YAML形式の設定ファイルを書き出した。他のNICに関しては、インストーラがその後の使用法や設定を知ることができないため、設定されなかった。
Data oracle (cloud-init、MAAS、gadget snap)
あるユーザはcloud-initユーザデータファイルを2つのネットワークカードが取り付けられるクラウドインスタンスのために作る。そのcloud-initファイルはこれら2つのネットワークカードからbondを作成する設定をするためのネットワーク定義を含む。
ルータのためのgadget snapは、2番目のPCIバス上の全てのイーサネットインタフェースがビルトインスイッチに属し、またそれらのインタフェースのためのブリッジを構成することを指定する。他のイーサネットインタフェースは、そのインタフェースを指定しやすく、使いやすい名前を提供するため、"eth-uplink"という名前に変更した。
一般的に、(インストーラを通じて)ユーザや、ハードウェアベンダ、クラウド管理ソフトウェアは性質や、数値、ネットワークインタフェースの目的に関して仮定を作成できる多くの状況がある。これらは、指定したインタフェース名とベンダのためにベンダ提供の設定に関して表現可能でなければならない。
デバイスの追加
AliceはUbnutuサーバのインストール後に、Intel NUCにUSB-NICを挿入した。サーバのデフォルトポリシはnetworkdを用い、/etc/netplan
の中にはそのデバイスに関するネットワーク設定の記述は存在しない。
以前設定したデバイスの利用
Sallyは以前設定したUSB-NICを挿入し、依然と異なるポートに接続されているにもかかわらず、同じ設定が保持されていることを期待した。
デバイスを取り外すとき、設定ファイルの変更はなかった。サーバをリブートしたら、e/n/cの処理が行われるときに、.LINKに名前を保持するためのマッチルールを含む設定と、.NETWORKに対しての同様のマッチルールを含む設定を、/run/network
に再度書き出すであろう。
注意: この挙動は既にNW/networkd/ifupdownなどの振舞い方である。このユースケースは、ただの完全な挙動の記述のためである)
パッケージインストール時のネットワーク設定のアップデート
lxd、libvirtなどは、/{etc, lib}/netplan/*.yaml
にスニペットを設置することでネットワーク設定を含むことがある。
デバイス設定の削除
Aliceは付け加えたusb0デバイスを使い終わり、システムから設定を削除したい。
現在の設定ファイルの表示
設定は全ての/etc/netpla/*.yaml
をマージしたものである。netplan config show
というコマンドは現在のディスク上の設定を読み込み/etc/netplan/*.yaml
のをマージし、標準出力にYAMLフォーマットを生成する。
次回はユースケースをサンプルコードとともに記事にしたいです。。