Ansible nmcliモジュール活用術：よくあるエラーとトラブルシューティング徹底解説

nmcliモジュールの主な機能と利点

• YAMLによる宣言的な設定:

  • ネットワーク設定をYAML形式で宣言的に記述できるため、可読性が高く、バージョン管理が容易になります。

• 汎用性と冪等性:

  • nmcliモジュールは、ターゲットシステムにnmcliコマンドがインストールされていれば動作します。
  • Ansibleの他のモジュールと同様に冪等性を持っています。つまり、Playbookを複数回実行しても、システムは常に望ましい状態に収束し、不必要な変更は行われません。例えば、既に存在する接続を作成しようとしても、何も変更されません。

• デバイスの管理:

  • ネットワークインターフェースの状態（接続済み、切断済みなど）を確認できます。
  • 特定のインターフェースを有効化/無効化できます。

• 接続の管理:

  • 接続の作成: イーサネット、Wi-Fi、ブリッジ、ボンド、VLANなどの様々なネットワーク接続タイプを作成できます。IPアドレス、DNSサーバー、ゲートウェイなどの設定も細かく指定可能です。
  • 接続の変更: 既存の接続の設定を変更できます。IPアドレスの変更、DNSの追加、接続名の変更などが含まれます。
  • 接続の削除: 不要になったネットワーク接続を削除できます。
  • 接続の有効化/無効化: 特定のネットワーク接続を一時的に有効にしたり、無効にしたりできます。
  • 接続の自動起動設定: システム起動時に自動的に接続を確立するかどうかの設定が可能です。

nmcliモジュールの使用例（概念）

基本的な使用例としては、以下のようなシナリオが考えられます。

• 複数のネットワークインターフェースを束ねて、ボンド接続を設定する。
• 特定のアプリケーションのために、VLAN接続を設定する。
• 既存のサーバーのIPアドレスやDNS設定を変更する。
• 新しいサーバーにデプロイする際に、初期ネットワーク設定を行う。

なぜnmcliモジュールを使うのか？

• インフラストラクチャ・アズ・コード: ネットワーク設定をコードとして管理できるため、変更履歴の追跡やロールバックが容易になります。
• エラーの削減: 手作業による設定ミスを減らし、信頼性の高いネットワーク構成を保証します。
• 一貫性: 複数のサーバー間でネットワーク設定の一貫性を保つことができます。
• 自動化: 大規模なインフラストラクチャにおいて、手動でのネットワーク設定は時間がかかり、エラーが発生しやすいため、nmcliモジュールを使うことで、このプロセスを完全に自動化できます。

• ネットワーク設定の変更は、リモート接続に影響を与える可能性があります。特に、Ansible ControllerとManaged Host間のネットワーク接続を変更する場合は、慎重に行う必要があります。
• nmcliモジュールはNetworkManagerサービスに依存しています。ターゲットシステムでNetworkManagerが稼働していることを確認する必要があります。

---

必要なPythonライブラリが見つからないエラー (Failed to import the required Python library)

これは、nmcliモジュールを使用する際に最もよく発生するエラーの一つです。Ansibleのnmcliモジュールは、ターゲットシステム上でNetworkManagerのPythonバインディング（python-dbus、python3-dbus、python-gobject、python3-gobject、python-nmstate、python3-nmstateなど、ディストリビューションやPythonのバージョンによって異なる）に依存しています。

エラーメッセージの例

Failed to import the required Python library (NetworkManager glib API) on <hostname>'s Python /usr/bin/python. Please read module documentation and install in the appropriate location. If the required library is installed, but Ansible is using the wrong Python interpreter, please consult the documentation on ansible_python_interpreter

原因

• Ansibleが使用しようとしているPythonインタープリタに、必要なライブラリがインストールされていない。
• ターゲットシステムに必要なPythonライブラリがインストールされていない。

トラブルシューティング

• NetworkManagerのバージョンと互換性
  
  • 特定の古いNetworkManagerのバージョンでは、nmcliモジュールが正しく機能しない場合があります。
  • 可能であれば、NetworkManagerを最新の安定版にアップデートすることを検討してください。
• ansible_python_interpreter の設定
  
  • ターゲットシステムに複数のPythonバージョンが存在する場合、Ansibleが正しいPythonインタープリタを使用するように設定する必要があります。
  • インベントリファイル (hosts.ini または YAMLインベントリ) で以下のように指定します。

    [webservers]
    web1 ansible_host=192.168.1.10 ansible_python_interpreter=/usr/bin/python3
    

    または

    all:
      hosts:
        web1:
          ansible_host: 192.168.1.10
          ansible_python_interpreter: /usr/bin/python3
    

• 必要なライブラリのインストール
  
  • RedHat系 (CentOS, RHEL, Fedora)
    
    • sudo yum install NetworkManager NetworkManager-libnm python3-gobject (RHEL/CentOS 8以降)
    • sudo yum install NetworkManager NetworkManager-glib python-gobject (RHEL/CentOS 7以前、Python 2.x の場合)
  • Debian系 (Ubuntu, Debian)
    
    • sudo apt install network-manager python3-dbus python3-gi gir1.2-networkmanager-1.0 (Python 3.x の場合)
    • sudo apt install network-manager python-dbus python-gi gir1.2-networkmanager-1.0 (Python 2.x の場合)
  • openSUSE
    
    • sudo zypper install NetworkManager python3-dbus-python typelib-1_0-NMClient-1_0 typelib-1_0-NetworkManager-1_0

NetworkManagerサービスが実行されていない

nmcliモジュールはNetworkManagerサービスと通信するため、ターゲットシステムでNetworkManagerが実行されていない場合、エラーが発生します。

エラーメッセージの例
特に明確なエラーメッセージが出ないこともありますが、タスクがハングしたり、関連するエラー（例: DBus error）が発生することがあります。

原因

• NetworkManagerがインストールされていない。
• NetworkManagerサービスが停止している。

トラブルシューティング

• NetworkManagerのインストール
  
  • インストールされていない場合は、適切なパッケージマネージャでインストールします（上記1.の「必要なライブラリのインストール」を参照）。
• NetworkManagerの起動と有効化
  
  • ターゲットシステムでsystemctl status NetworkManagerを実行し、状態を確認します。
  • 停止している場合は、systemctl start NetworkManagerで起動し、systemctl enable NetworkManagerで自動起動を有効にします。

権限の問題 (Permission Denied, sudo/become関連)

ネットワーク設定の変更は通常、root権限を必要とします。Ansibleが適切な権限で操作できていない場合、エラーが発生します。

エラーメッセージの例

• Error: Failed to modify connection 'eth0': not authorized to perform operation
• Failed to modify connection: insufficient privileges
• Permission denied

原因

• sudoersファイルに適切な設定がない。
• ansible_become_user や ansible_become_pass の設定が誤っている。
• become: yes が設定されていない、または正しく機能していない。

トラブルシューティング

• SSHキー認証の確認
  
  • パスワード認証ではなく、SSHキー認証を使用していることを確認します。パスワード認証は自動化には向きません。
• sudoersの設定確認
  
  • ターゲットシステム上で、Ansibleが接続するユーザーがsudo権限を持っているか確認します。必要に応じてsudo visudoで設定を調整します。パスワードなしでsudoを実行できるようにすることが一般的です。
• become: yes の設定
  
  • nmcliモジュールを使用するタスク、またはPlaybook全体にbecome: yesを設定します。

  - name: Configure static IP
    community.general.nmcli:
      conn_name: eth0
      ifname: eth0
      type: ethernet
      ip4: 192.168.1.100/24
      gw4: 192.168.1.1
      dns4: 8.8.8.8
      state: present
    become: yes # ここで昇格
  

ネットワーク接続が切断される問題 (セルフロックアウト)

ネットワーク設定を変更する際、特にAnsible ControllerとManaged Host間のネットワーク接続を変更すると、接続が切断され、Playbookが途中で停止する可能性があります。

原因

• IPアドレスの変更、ネットワークインターフェースの再起動、ブリッジの作成などで、既存のSSH接続が中断される。

トラブルシューティング

• ネットワーク設定を慎重に行う
  
  • 変更の影響を理解し、特に重要なシステムでは、テスト環境で十分に検証してから本番に適用します。
• NetworkManagerの自動再接続機能に頼る
  
  • nmcliモジュールは通常、変更後にNetworkManagerに再接続を指示します。ただし、これが原因で接続が不安定になる場合もあります。
• async と poll の使用
  
  • ネットワーク設定の変更が完了するまでAnsibleが待機しないように、asyncとpollを使用します。これにより、タスクはバックグラウンドで実行され、Ansibleは接続が切断されても処理を継続できます。その後、wait_forモジュールなどで新しい接続が確立されるのを待ちます。

  - name: Change IP address and restart network
    community.general.nmcli:
      conn_name: eth0
      ip4: 192.168.1.200/24
      state: present
    async: 60 # 60秒まで待機
    poll: 0   # バックグラウンドで実行し、すぐに次のタスクへ
    become: yes
  
  - name: Wait for SSH to be available on new IP
    wait_for:
      host: 192.168.1.200 # 新しいIPアドレス
      port: 22
      timeout: 300
      state: started
  

nmcliコマンドのバージョンとパラメータの互換性

nmcliコマンド自体はバージョンによって利用可能なパラメータやオプションが異なる場合があります。Ansibleのnmcliモジュールは、 underlying のnmcliコマンドに依存しているため、ターゲットシステムのnmcliのバージョンが古い場合、新しいパラメータがサポートされていないことがあります。

エラーメッセージの例

• Error: Failed to modify connection 'conn_name': property 'abc' is not allowed for 'type=ethernet'
• Error: unknown option --xyz

原因

• Playbookで指定したパラメータが、ターゲットシステムのnmcliのバージョンでサポートされていない。

トラブルシューティング

• ignore_unsupported_suboptions: yes の使用 (一部のモジュールで利用可能)
  
  • community.general.nmcliモジュールには、サポートされていないサブオプションを無視するignore_unsupported_suboptions: yesパラメータがあります。これにより、特定の環境でエラーを回避できる場合がありますが、意図した設定が適用されない可能性もありますので注意が必要です。
• より汎用的なオプションを使用する
  
  • 最新の機能が不要であれば、古いバージョンのnmcliでも動作する汎用的なオプションを使用します。
• Ansible nmcliモジュールのドキュメントを確認
  
  • Ansibleの公式ドキュメントで、使用しているnmcliモジュールのバージョンと対応するnmcliコマンドのバージョンを確認します。
  • 記載されているオプションが、ターゲットのnmcliでサポートされているか確認します。
• nmcli --version の確認
  
  • ターゲットシステムでnmcli --versionを実行し、バージョンを確認します。

Ansible PlaybookにおけるYAMLのインデントや構文のミスは、一般的なエラーの原因です。

エラーメッセージの例

• expected a key=value or a simple string
• ERROR! 'key' is not a valid attribute for a Play

原因

• 引用符の不足
• 誤ったキー名や値の指定
• インデントの不一致 (スペースとタブの混在など)

• Ansibleの実行オプション
  
  • ansible-playbook --syntax-check your_playbook.ymlで構文エラーがないか事前に確認できます。
  • ansible-playbook -vvv your_playbook.yml で詳細なデバッグ出力を確認し、エラーの原因を探します。
• YAMLバリデーターの使用
  
  • YAMLファイルをLinterやバリデーター（例: VS CodeのYAML拡張機能、オンラインのYAMLバリデーター）でチェックします。

---

nmcliモジュールの基本的な使い方

nmcliモジュールは、community.generalコレクションの一部です。Ansible 2.9以前ではデフォルトで利用できましたが、Ansible 2.10以降ではcommunity.generalコレクションをインストールする必要があります。

コレクションのインストール

ansible-galaxy collection install community.general

静的IPアドレスを持つ新しいイーサネット接続の作成

最も一般的なユースケースの一つです。state: presentは、その接続が存在しない場合は作成し、既に存在する場合は指定された設定に更新します。

---
- name: Configure a static IP address for eth0
  hosts: your_target_server
  become: yes # ネットワーク設定の変更にはroot権限が必要です

  tasks:
    - name: Create or modify an Ethernet connection with a static IP
      community.general.nmcli:
        conn_name: "Static_Eth0" # 接続の名前 (任意の分かりやすい名前)
        ifname: "eth0"         # ネットワークインターフェース名
        type: "ethernet"       # 接続タイプ
        ip4: "192.168.1.100/24" # IPv4アドレスとサブネットマスク (CIDR形式)
        gw4: "192.168.1.1"      # IPv4デフォルトゲートウェイ
        dns4:                  # IPv4 DNSサーバー (複数指定可能)
          - "8.8.8.8"
          - "8.8.4.4"
        state: "present"       # 接続が存在することを確認（なければ作成、あれば更新）
        autoconnect: "yes"     # システム起動時に自動接続するかどうか

解説

• autoconnect: yes: システム起動時にこの接続を自動的に有効にするよう設定します。
• state: present: この設定は冪等性を提供します。もしStatic_Eth0という接続がeth0に設定されていなければ作成し、既に存在してもIPアドレスなどが異なれば更新します。
• ip4, gw4, dns4: それぞれIPv4アドレス、ゲートウェイ、DNSサーバーを指定します。ip6, gw6, dns6でIPv6の設定も可能です。
• type: 接続のタイプです（ethernet, wifi, bridge, bond, vlan など）。
• ifname: 物理的なネットワークインターフェース名です（例: eth0, enp0s3, ens192）。
• conn_name: NetworkManagerが管理する接続の名前です。後でこの名前で接続を識別します。

DHCP接続の作成

DHCPを使用する場合も同様に設定できます。IPアドレスなどの情報はDHCPサーバーから自動的に取得されます。

---
- name: Configure DHCP for eth0
  hosts: your_target_server
  become: yes

  tasks:
    - name: Create or modify an Ethernet connection with DHCP
      community.general.nmcli:
        conn_name: "DHCP_Eth0"
        ifname: "eth0"
        type: "ethernet"
        ip4: "dhcp"           # DHCPを使用する場合
        state: "present"
        autoconnect: "yes"

既存の接続の変更（DNSサーバーの追加）

既存の接続名を指定して、その設定の一部を変更することもできます。

---
- name: Add a secondary DNS server to an existing connection
  hosts: your_target_server
  become: yes

  tasks:
    - name: Modify DNS settings for an existing connection
      community.general.nmcli:
        conn_name: "Static_Eth0" # 変更したい既存の接続名
        dns4:                  # DNSサーバーを更新（既存のDNSに加えて新しいものを追加）
          - "8.8.8.8"
          - "1.1.1.1"          # 新しく追加するDNSサーバー
        state: "present"       # 既存の接続が存在することを確認し、更新

ネットワーク接続の有効化/無効化

state パラメータを up または down に設定することで、接続を有効または無効にできます。

---
- name: Control network connection state
  hosts: your_target_server
  become: yes

  tasks:
    - name: Bring the 'Static_Eth0' connection up (activate)
      community.general.nmcli:
        conn_name: "Static_Eth0"
        state: "up"

    - name: Bring the 'Static_Eth0' connection down (deactivate)
      # wait_for などを挟んでネットワーク接続断の影響を考慮
      community.general.nmcli:
        conn_name: "Static_Eth0"
        state: "down"

ネットワーク接続の削除

不要になった接続を削除します。

---
- name: Delete a network connection
  hosts: your_target_server
  become: yes

  tasks:
    - name: Remove the 'Static_Eth0' connection
      community.general.nmcli:
        conn_name: "Static_Eth0"
        state: "absent" # 接続が存在しないことを確認（あれば削除）

ボンディングインターフェースの作成

複数の物理インターフェースを論理的に束ねて冗長性や帯域幅を確保するボンディング接続を作成する例です。

---
- name: Create a bond interface (active-backup mode)
  hosts: your_target_server
  become: yes

  tasks:
    - name: Create the bond master connection
      community.general.nmcli:
        conn_name: "mybond0"
        type: "bond"
        ifname: "bond0"
        ip4: "192.168.2.10/24"
        gw4: "192.168.2.1"
        dns4: ["8.8.8.8"]
        bond_options: "mode=active-backup,miimon=100" # ボンディングオプション
        state: "present"
        autoconnect: "yes"

    - name: Add eth1 as a slave to mybond0
      community.general.nmcli:
        conn_name: "mybond0-slave1"
        ifname: "eth1"
        type: "ethernet"
        master: "mybond0" # マスター接続名を指定
        state: "present"
        autoconnect: "yes"

    - name: Add eth2 as a slave to mybond0
      community.general.nmcli:
        conn_name: "mybond0-slave2"
        ifname: "eth2"
        type: "ethernet"
        master: "mybond0"
        state: "present"
        autoconnect: "yes"

解説

• master: スレーブとなる接続が属するマスター接続の名前を指定します。
• bond_options: ボンディングモード（例: mode=active-backup）、ヘルスチェック間隔（miimon=100）などを指定します。
• ボンディングインターフェースは、まずマスターとなる接続を作成し、その後に物理インターフェースをスレーブとして追加する手順になります。

ブリッジインターフェースの作成

仮想マシンやコンテナが物理ネットワークに接続するために使用されるブリッジインターフェースを作成する例です。

---
- name: Create a bridge interface
  hosts: your_target_server
  become: yes

  tasks:
    - name: Create the bridge master connection
      community.general.nmcli:
        conn_name: "mybridge0"
        type: "bridge"
        ifname: "br0"
        ip4: "192.168.3.1/24"
        state: "present"
        autoconnect: "yes"

    - name: Add eth0 as a port to mybridge0
      community.general.nmcli:
        conn_name: "mybridge0-port-eth0"
        ifname: "eth0"
        type: "ethernet"
        master: "mybridge0" # マスターブリッジ接続名を指定
        state: "present"
        autoconnect: "yes"

• ブリッジもボンディングと同様に、まずマスターとなるブリッジ接続を作成し、その後、物理インターフェースをポート（スレーブ）として追加します。

• Pythonライブラリ: ターゲットサーバーに必要なPythonライブラリ（python3-gobjectなど）がインストールされていることを確認してください。
• NetworkManagerのサービス: ターゲットサーバーでNetworkManagerサービスが稼働していることを確認してください。
• ネットワーク切断: IPアドレスの変更やインターフェースの再起動など、ネットワーク設定の変更は、Ansible Controllerとターゲットサーバー間のSSH接続を一時的に切断する可能性があります。これに対処するために、asyncとpoll、そしてwait_forモジュールを組み合わせて使用することを検討してください（上記の「一般的なエラーとトラブルシューティング」で説明したセルフロックアウトの項目を参照）。
• 冪等性: state: presentを使用することで、Playbookを複数回実行してもシステムの状態は期待通りに保たれます。すでに設定が存在すれば更新され、なければ作成されます。
• become: yes: ネットワーク設定の変更は通常、root権限を必要とします。PlaybookのタスクまたはPlay全体にbecome: yesを必ず設定してください。

---

network モジュール (ansible.builtin.network または ansible.netcommon.network)

これはAnsibleの組み込みモジュールで、一般的なネットワーク設定（インターフェースの有効/無効化、IPアドレス設定など）を抽象化して扱います。ディストリビューションごとのNetworkManager、netplan、ifupdownなどの違いを吸収しようとしますが、その分、きめ細やかな設定が難しい場合があります。

特徴

• 制限
  nmcliが提供するような詳細なNetworkManagerのプロファイル管理（例: ボンドオプションの細かな設定、接続プロファイルの削除）には不向き。
• シンプル
  基本的な設定には十分。
• 抽象化
  多くのLinuxディストリビューションとネットワーク設定ツールに対応しようとする。

使用例

- name: Configure static IP using network module
  ansible.builtin.network:
    interfaces:
      - name: eth0
        ipv4:
          - address: 192.168.1.100
            prefix: 24
        gateway4: 192.168.1.1
        dns:
          - 8.8.8.8
          - 8.8.4.4
        state: up

nmcliモジュールとの比較
networkモジュールは「インターフェースをこの状態にする」という粒度で操作するのに対し、nmcliモジュールは「NetworkManagerの接続プロファイルをこうする」という粒度で操作します。そのため、NetworkManagerの機能に深く依存した複雑な設定にはnmcliの方が適しています。

ini_file/lineinfile/template モジュールによる設定ファイルの直接編集

これは、NetworkManagerの設定ファイル（/etc/NetworkManager/system-connections/以下など）や、従来のifcfgファイル（Red Hat系）や/etc/network/interfaces（Debian系）を直接編集する方法です。

特徴

• 再起動の必要性
  設定変更後にネットワークサービスやインターフェースの再起動が必要になることが多い。
• エラーハンドリング
  手動でファイルを編集するのと同じリスクがあり、構文エラーなどが起きやすい。
• 冪等性の管理
  ファイルの直接編集では、自分で冪等性を確保するロジック（例: ファイルが存在するかどうか、内容が正しいかどうか）を組む必要がある。
• ディストリビューション依存
  ディストリビューションやNetworkManagerのバージョンによってファイルの形式や場所が異なるため、Playbookが複雑になりがち。
• 柔軟性
  どんな設定でも可能。

使用例 (RHEL系 ifcfg の場合)

- name: Configure static IP using template module (RHEL/CentOS)
  ansible.builtin.template:
    src: templates/ifcfg-eth0.j2
    dest: /etc/sysconfig/network-scripts/ifcfg-eth0
    owner: root
    group: root
    mode: '0644'
  notify: restart network

- name: restart network # ハンドラ
  ansible.builtin.systemd:
    name: network
    state: restarted
    enabled: yes

templates/ifcfg-eth0.j2 の内容例:

TYPE="Ethernet"
BOOTPROTO="none"
NAME="eth0"
DEVICE="eth0"
ONBOOT="yes"
IPADDR="{{ static_ip }}"
PREFIX="{{ static_prefix }}"
GATEWAY="{{ default_gateway }}"
DNS1="{{ primary_dns }}"
DNS2="{{ secondary_dns }}"

nmcliモジュールとの比較
nmcliモジュールはNetworkManagerのAPIを通じて安全かつ冪等に設定を変更するのに対し、この方法は生の設定ファイルを操作するため、より低レベルで、エラーのリスクが高く、ディストリビューション間のポータビリティが低いのが欠点です。しかし、NetworkManagerが導入されていない、または特定の設定ファイル形式に厳密に準拠する必要がある場合には有効です。

shell / command モジュールによる直接のnmcliコマンド実行

Ansibleのshellモジュールやcommandモジュールを使って、ターゲットシステム上で直接nmcliコマンドを実行することもできます。

特徴

• 可読性
  Playbookの可読性が下がる可能性がある。
• 冪等性の管理
  自分で冪等性を考慮したコマンドを作成する必要がある。例えば、接続が存在するかどうかをnmcli con showで確認し、存在しなければnmcli con add、存在すればnmcli con modを実行するロジックをPlaybook内で組む必要がある。
• 学習コスト
  nmcliコマンドのオプションや構文を熟知している必要がある。
• 完全な制御
  nmcliコマンドの全ての機能を利用できる。

使用例

- name: Configure static IP using nmcli command directly
  hosts: your_target_server
  become: yes

  tasks:
    - name: Check if connection exists
      ansible.builtin.command: "nmcli -t -f UUID,NAME con show {{ conn_name | default('Static_Eth0') }}"
      register: nmcli_con_check
      changed_when: false # このコマンド自体は変更を引き起こさないので常にfalse

    - name: Add or modify connection based on existence
      ansible.builtin.shell: |
        if [ -z "{{ nmcli_con_check.stdout }}" ]; then
          nmcli connection add type ethernet con-name Static_Eth0 ifname eth0 ip4 192.168.1.100/24 gw4 192.168.1.1 dns "8.8.8.8 8.8.4.4" autoconnect yes
        else
          nmcli connection modify Static_Eth0 ip4 192.168.1.100/24 gw4 192.168.1.1 dns "8.8.8.8 8.8.4.4" autoconnect yes
        fi
      args:
        creates: /etc/NetworkManager/system-connections/Static_Eth0.nmconnection # 冪等性のヒント
      when: nmcli_con_check.rc == 0 # nmcli con show がエラーを返さなければ実行

nmcliモジュールとの比較
nmcliモジュールは、上記のshellモジュールでの複雑なif文やchanged_whenの管理を内部で自動的に行い、より宣言的かつ安全にnmcliの機能を利用できるようにカプセル化したものです。特別な理由がない限り、専用のnmcliモジュールを使用することが強く推奨されます。

一部のディストリビューションや特定のネットワーク管理ツールには、それらに特化したAnsibleモジュールが存在する場合があります（例: UbuntuのNetplan、SuSEのwickedなど）。

特徴

• ディストリビューション依存
  汎用性は低い。
• 専門性
  特定の環境に最適化されている。

例

• interfaces_file モジュール (Debian系)
  /etc/network/interfacesファイルを操作します。
• netplan モジュール (Ubuntu)
  Ubuntu Server 18.04 LTS以降で推奨されるNetplan設定ファイルを操作します。

nmcliモジュールとの比較
これらのモジュールは、対象の環境でNetworkManagerが主要なネットワーク管理ツールではない場合、またはNetplanのように他の設定レイヤーが採用されている場合に選択されます。

特別な理由がない限り、AnsibleでNetworkManagerを介したネットワーク設定を自動化する際には、community.general.nmcliモジュールを使用することが最も推奨される方法です。

その理由は以下の通りです。

• ディストリビューション間の互換性
  NetworkManagerが稼働していれば、多くのLinuxディストリビューションで同じPlaybookを使用できます。
• 可読性
  YAML形式で設定を記述するため、Playbookが読みやすく、管理しやすいです。
• 安全性
  NetworkManagerのAPIを通じて操作するため、設定ファイルの破損などのリスクが低減されます。
• 冪等性
  宣言的な方法で自動的に冪等性を確保します。