背景とアプローチを見直すべき理由
Linuxサーバーの管理経験がある方なら、延々と続く長いnmcliコマンドを何十行も叩かされたり、/etc/NetworkManager/system-connections/配下のキーファイルを1つずつ手作業で書き換えたりする苦痛を一度は味わったことがあるはずです。筆者は個人ラボやKVM仮想マシンクラスタでFedora Serverを2年以上運用していますが、3〜4ノードのクラスタを再構築するたびに、物理NICの設定やBridgeの束ね作業に30分以上奪われ、IPアドレスの入力ミスも頻発していました。
こうした手動でのネットワーク設定は、命令型（Imperative）のアプローチです。これはカフェで注文するときに、店員に対して「カップを取って、練乳を30ml注ぎ、コーヒーを入れて、氷をすくい、5回シェイクしてください」と手順を一から指示するようなものです。
もし店員が1つのステップを忘れたり、途中で氷が切れたりすれば、その瞬間にプロセスは破綻します。サーバー運用でも全く同じです。デフォルトゲートウェイを1つ設定ミスしたり、ルーティングの競合を起こしたりするだけで、SSHセッションは即座に切断されます。サーバーを復旧するには、物理コンソールを直接繋ぐか、VPSプロバイダのWeb VNCコンソールを開くしかなくなります。
一方でNmstateは、宣言型（Declarative）のアプローチを採用しています。あなたが伝えるのは「甘さ控えめのミルクコーヒーを1杯ください」という最終的な期待結果（Desired State）だけです。ネットワーク基盤においては、NIC enp1s0にどのIPを割り当て、どのゲートウェイに向け、どのDNSサーバーを参照させるかをすべて1つのYAMLファイルにまとめます。Nmstateが現在の状態と宣言ファイルを自動で比較照合し、差分を計算した上で、単一のトランザクションとして新しい設定を適用します。万が一トラブルが発生しても、システムが自動的かつクリーンに元の状態へロールバックしてくれます。
Fedoraへのインストール
NmstateはFedoraの公式リポジトリで提供されています（Fedora 38から41まで完全対応）。付属のCLIツールはnmstatectlです。
パッケージのインストールはdnfで簡単に行えます：
sudo dnf install -y nmstate
正常にインストールされたかバージョンを確認します：
nmstatectl --version
# 出力例: nmstatectl 2.2.32
NmstateはNetworkManagerを置き換えるものではありません。内部的にはD-Bus APIを介してNetworkManagerデーモンと直接やり取りするため、OSの基盤となるネットワークサービスはそのまま維持されます。
実践例で学ぶ詳細な設定手順
Nmstateの大きなメリットは、YAML構文をゼロから手探りで書く必要がない点です。まずはマシンの現在の構成をエクスポートし、それをテンプレート（雛形）として活用しましょう。
1. 現在のネットワーク状態をエクスポートする
# ネットワーク構成全体をYAMLファイルに出力
nmstatectl show > network-state.yaml
# またはメインNICの情報のみを抽出
nmstatectl show enp1s0
2. YAMLファイルによる静的IPとDNSの設定
メインのNICがenp1s0であると仮定します。静的IP 192.168.1.50/24、ゲートウェイ 192.168.1.1を設定し、CloudflareとGoogleのDNSサーバーを併用したいとします。static-ip.yamlファイルを作成します：
interfaces:
- name: enp1s0
type: ethernet
state: up
ipv4:
enabled: true
address:
- ip: 192.168.1.50
prefix-length: 24
dhcp: false
ipv6:
enabled: false
routes:
config:
- destination: 0.0.0.0/0
next-hop-address: 192.168.1.1
next-hop-interface: enp1s0
dns-resolver:
config:
server:
- 1.1.1.1
- 8.8.8.8
3. ロールバック機構を活用した安全な設定適用
SSH経由のリモート作業でネットワークを変更する場合、接続切断のリスクが常に伴います。Nmstateは重要な2段階チェックによってこのリスクを防いでくれます。
ステップ1：ドライランを実行して構文エラーを検証する
nmstatectl apply static-ip.yaml --dry-run
構文が正しければ、ターミナル上に新旧設定の差分（diff）が表示されます。この時点ではNICに何ら変更は加えられません。
ステップ2：タイムアウト付きロールバックを指定して適用する
sudo nmstatectl apply static-ip.yaml --rollback-timeout 60
Enterキーを押した瞬間から、60秒のカウントダウンが始まります。別ターミナルを開いて、ゲートウェイへpingを打って疎通確認をします：ping -c 3 192.168.1.1。ネットワークが正常に通っており、SSHセッションも維持されていることが確認できたら、確定コマンドを実行します：
sudo nmstatectl commit
万が一、ゲートウェイアドレスの誤入力などでSSHセッションから締め出されてしまった場合でも、焦らず60秒待つだけで構いません。Nmstateが自動的に以前の設定へとロールバックしてくれます。データセンターの保守部隊（NOC）に連絡してレスキューを依頼する必要もありません。
4. KVM仮想マシン向けのLinux Bridgeを作成する
仮想化ラボを構築する際、仮想マシンがルーターから直接IPを取得できるようにするには、ブリッジインターフェースbr0が必須となります。setup-bridge.yamlを作成します：
interfaces:
- name: br0
type: linux-bridge
state: up
ipv4:
enabled: true
dhcp: true
bridge:
port:
- name: enp1s0
- name: enp1s0
type: ethernet
state: up
ipv4:
enabled: false
Bridge設定を適用します：
sudo nmstatectl apply setup-bridge.yaml --rollback-timeout 60
sudo nmstatectl commit
わずか15行のYAMLで、Nmstateは物理NIC enp1s0をBridge br0に収容し、スレーブ側のIPv4を無効化してBridgeインターフェース側でDHCP要求を行うという、複雑な2つの操作を安全に一括処理してくれます。
検証と実運用
commitが正常に完了したら、使い慣れたコマンド群で状態を確認します：
# 作成したBridgeの状態を確認
nmstatectl show br0
# デフォルトルーティングテーブルを確認
ip route show
# systemd-resolved経由でアクティブなDNSを確認
resolvectl status br0
ネットワーク構成をGitOpsワークフローへ統合する
これで、ネットワーク構成のすべてがわずか数キロバイトのYAMLファイル群に収まりました。これらのファイルを組織内のGitリポジトリ（GitLabやGitHub）にプッシュしてバージョン管理できます。
例えば20台のサーバーでIP帯の変更が必要になった場合でも、Pull Requestを作成してチームメンバーに差分をレビューしてもらい、Ansible等を使って一括でnmstatectl applyを実行するだけで済みます。git logを確認すれば、いつ誰がどのIPを変更したのかが正確に追跡可能です。ディスプレイの隅に貼られた付箋や、陳腐化したExcelのネットワーク台帳とは完全に決別できます。
