Ansibleでクッキングジュニパーネットワーク









ある晴れた日、私はすべてのデバイスからログを収集する通常のrsyslogから別のものに切り替えることにしました。選択などはこのトピックとはほとんど関係がありません(Graylog2を選択しました)が、その結果、syslogホストの設定をすべてのジュニパーのデバイスに置き換えるタスクがありました。



原則として、100台のデバイスでハンドルを操作する(またはperlでスクリプトを投げる)ことやコマンドをクリックすることは問題ではありませんが、私の頭の中には、ネットワークデバイスと数百台のサーバーの両方の管理を自動化するためのタスクが既にたくさんあります。 私の環境でWindowsに問題がない場合(SCCMを使用)、Linux環境では、大量操作は手動操作またはbashスクリプトのいずれかに囲まれています(SCCMを管理することもできますが、このオプションはやや不便です)。



そして、私は長い間Ansibleの使用を開始したかったため、このタスクの開始として選択されました(ChefとPuppetの場合、結局、タスクはそれほど大きくなく、エントリのしきい値は既に大きくなっています)。



Ansibleをインストールする



Ansibleのインストールは簡単です。すべてがすぐに使用できるためです(このタスクでは、ubuntuサーバー04.16.03を使用しました)。



sudo apt-add-repository ppa:ansible/ansible sudo apt-get update sudo apt-get install ansible
      
      





/etc/ansible/ansible.cfgの設定を変更します
 #     roles_path = /etc/ansible/roles #  ,   ,        SSH   . host_key_checking = False # log_path = /var/log/ansible.log      ,      .
      
      







ジュニパーのモジュール



主題のジュニパーと偉大な人たちは、彼らのモジュールを開発しました。 彼に関する情報は、オフサイト: Ansible for JunOSで見つけることができます。 バージョンAnsible 2.1以降コアモジュールAnsibleにネイティブに含まれています



このモジュールをインストールし、リストで確認します。



 sudo ansible-galaxy install Juniper.junos ansible-galaxy list
      
      





また、モジュールを使用するにはnccclientが必要です



 sudo apt-get install python-pip pip install ncclient
      
      





デバイスに接続する



Ansibleはいくつかの方法でJuniperデバイスに接続できます。デフォルトのプロトコルはNetconfおよびポート830です。 telnetとシリアルコンソール接続を使用することもできますが、telnetは比較的安全ではなく、シリアルは特定のタスクには少し適していますが、接続がある場合のベアメタルの初期設定は自動化できます。



Netconfは通常の22 sshポートでも使用でき、cliをトランスポートとして使用します。



Netconfについて
Habré の古い出版物の1つで Netconfがよく開示されているもの



デバイスの認証については、すぐにキーで認証を設定したいと思います。 便宜上、 RSAキーをルートとして生成します(DSAがさらに理解されない理由)。 使いやすくするために、以前に作成した/etc/ansible/.sshにコピーした後。



 ssh-keygen -t rsa cp /root/.ssh/id_rsa.pub /etc/ansible/.ssh/ansible.pub cp /root/.ssh/id_rsa /etc/ansible/.ssh/ansible
      
      





その結果、ターゲットデバイスでは、公開キーを持つユーザーを手動で作成する必要があります。



 set system login user ansible class super-user authentication ssh-rsa "<SSH-key>"
      
      





しかし、これもさらに自動化します。



ホスト



接続する相手に、ファイル/ etc / ansible / hostsに記述します。

さまざまなジュニパーのデバイスを使用しているため、デバイスグループとその中の変数を説明できます。そのため、すぐにいくつかのグループを作成します。



/ etc / ansible /ホスト
 [junex2200] 192.168.111.101 [junex3300] 192.168.111.51 [junexcore] 192.168.111.4 [junexdc] 192.168.111.11 [alljuniper:children] junex2200 junex3300 junexcore junexdc [alljuniper:vars] ansible_jun_username=ansible ansible_jun_port=22 ansible_jun_timeout=60 ansible_ssh_private_key_file=/etc/ansible/.ssh/ansible
      
      







このファイルでは、4つのグループを定義し、各グループに1つのデバイスを追加しました。 次に、彼は一般的なグループを作成し、承認用の変数を追加しました。これは、プレイブックで使用されます。 ユーザーは"ansible"になります。830はデフォルトでは有効になっていないため、ポート22を使用します。また、コミットでは標準の10秒よりも簡単に時間がかかるため、タイムアウトを60に増やします。



netconfをジュニパーで有効にする場合
システムサービスを設定するnetconf ssh



プレイブックの初期設定



別のプレイブックで初期設定を行いました。 すべてのデバイスに接続するためのユーザーがいるので、プレイブックのログイン/パスワードを使用して、キーを使用してユーザーを「可能」にします。 また、必要に応じて、ポート830でNetconfを有効にできますが、違いに気付かなかったため、これは不要であると考えています。



ディレクトリ/ etc / ansible / playbooks / juniperを作成し、その中に最初のPlaybook init.ymlを作成します



コンテンツを分析しましょう:



 --- - name: juniper initialization playbook # PB hosts: alljuniper #  hosts    #  juniper roles: - Juniper.junos connection: local gather_facts: no #   /  ,   vars_prompt: - name: "DEVICE_USERNAME" promt: "Device username" private: no - name: "DEVICE_PASSWORD" promt: "Device password" private: yes #      vars: provider_info: host: "{{ inventory_hostname }}" username: "{{ DEVICE_USERNAME }}" password: "{{ DEVICE_PASSWORD }}" port: "{{ ansible_jun_port }}" timeout: "{{ ansible_jun_timeout }}" #    tasks: #    - name: junos check connection wait_for: host: "{{ inventory_hostname }}" port: "{{ ansible_jun_port }}" timeout: 10 #  - name: junos create ansible user with key-auth junos_user: provider: "{{ provider_info }}" name: "{{ ansible_jun_username }}" role: super-user sshkey: "{{lookup('file', '/etc/ansible/.ssh/ansible.pub') }}" state: present
      
      





ユーザーを作成するには、 junos_userモジュールを使用します。 モジュールはrsaキーを持つユーザーのみを作成できるため、生成しました。 原則として、 junos_configを使用して、dsaキーで直接行を記述できます。



 set system login user ansible class super-user authentication ssh-dsa "<SSH-key>"
      
      





プレイブックを起動する



作成したプレイブックinit.ymlを実行します。



 sudo ansible-playbook init.yml
      
      





実行結果
 DEVICE_USERNAME: megaswitchuser DEVICE_PASSWORD: PLAY [juniper initialization playbook] ******************************************************************************** TASK [junos check connection] ******************************************************************************** ok: [192.168.111.101] ok: [192.168.111.51] ok: [192.168.111.4] ok: [192.168.111.11] TASK [junos create ansible user with key-auth] ******************************************************************************** changed: [192.168.111.101] changed: [192.168.111.51] changed: [192.168.111.4] changed: [192.168.111.11] PLAY RECAP ******************************************************************************** 192.168.111.101 : ok=2 changed=1 unreachable=0 failed=0 192.168.111.51 : ok=2 changed=1 unreachable=0 failed=0 192.168.111.4 : ok=2 changed=1 unreachable=0 failed=0 192.168.111.11 : ok=2 changed=1 unreachable=0 failed=0
      
      







変更= 1

変更が成功したことを意味します。任意のデバイスに移動できます。はい、ユーザーは既にそこに作成されます。



あなたがプレイブックを再起動すると、変更は再び行われず、彼は書きます

変更= 0



syslogのセットアップ



junos_loggingモジュールがあります。 原則として、ほとんどの場合、それを使用できますが、ホストの高度なパラメーターを入力する必要があり、このモジュールではサポートされていません。 したがって、ユニバーサルツール、 junos_configモジュールを使用して新しいホストを追加し、junos_loggingモジュールを使用して古いホストを削除します。



プレイブックsyslog.ymlを作成します。その中で、ユーザーansibleに対して既にキー認証を使用します。



 --- - name: juniper set syslog to graylog2 # PB hosts: alljuniper #  hosts    #  juniper roles: - Juniper.junos connection: local gather_facts: no #     ,       hosts, keyfile     vars: provider_info: host: "{{ inventory_hostname }}" username: "{{ ansible_jun_username }}" port: "{{ ansible_jun_port }}" timeout: "{{ ansible_jun_timeout }}" #    tasks: #    - name: junos check connection wait_for: host: "{{ inventory_hostname }}" port: "{{ ansible_jun_port }}" timeout: "{{ ansible_jun_timeout }}" #  - name: set juniper syslog host junos_config: provider: "{{ provider_info }}" #     lines: - set system syslog host 192.168.111.210 any any - set system syslog host 192.168.111.210 port 2514 - set system syslog host 192.168.111.210 structured-data brief #    comment: update config add syslog graylog2 #      junos_logging - name: delete old syslog host junos_logging: provider: "{{ provider_info }}" dest: host name: 192.168.111.208 facility: any level: any state: absent
      
      





以下を開始します。



 sudo ansible-playbook syslog.yml
      
      





実行結果
 PLAY [juniper set syslog to graylog2] ******************************************************************************** TASK [junos check connection] ******************************************************************************** ok: [192.168.111.101] ok: [192.168.111.51] ok: [192.168.111.4] ok: [192.168.111.11] TASK [set juniper syslog host] ******************************************************************************** changed: [192.168.111.101] changed: [192.168.111.51] changed: [192.168.111.4] changed: [192.168.111.11] TASK [delete old syslog host] ******************************************************************************** changed: [192.168.111.101] changed: [192.168.111.51] changed: [192.168.111.4] changed: [192.168.111.11] PLAY RECAP ******************************************************************************** 192.168.111.4 : ok=3 changed=1 unreachable=0 failed=0 192.168.111.11 : ok=3 changed=1 unreachable=0 failed=0 192.168.111.51 : ok=3 changed=1 unreachable=0 failed=0 192.168.111.101 : ok=3 changed=1 unreachable=0 failed=0
      
      









ジュニパーのいずれかを訪問すると、新しいsyslogサーバーが設定に登録され、古いサーバーが削除されたことは明らかです。



必要に応じて、プレイブックのコメント付きでコミット履歴を確認できます。



 show system commit
      
      





 0 2018-03-07 15:12:49 KRAT by ansible via netconf update config add syslog graylog2
      
      





プレイブックを呼び出しても構成は変更されませんが、すべてが正常であり、変更がないことが通知されます。



まとめ



ネットワークの設定を自動化する環境を設定しました。ネットワークを簡単に管理できるようになりました。 Ansibleのジュニパーモジュールを使用して解決できるタスクは、構成の変更だけでなく、ソフトウェアバージョンの更新、デバイスの再起動、バックアップ構成の作成なども可能です。



計画



近い将来、Ansibleでこのトピックについて私が特定した以下の計画。





このツールは非常に優れており、以前に使用を開始しなかったことだけを後悔しています。 1台のLinuxマシンでも100種類のスイッチでも、アクションの自動化を開始するのに遅すぎたり早すぎたりすることはありません。



試験済み機器リスト



ジュニパー:EX3300、EX2200、EX4550

JunOS:12.2R6.4、12.3R3.4、12.3R4.6、12.3R6.6、12.3R6.6、12.2R9.4、12.2R12.4



PS:すでに記事を書いている最中に、Habréの同じトピックに関する記事に出くわしたので、そのトピックをより完全に開示しようとしました。



All Articles