CI/CD によるネットワーク管理の自動化

【IIJ 2023 TECHアドベントカレンダー 12/21の記事です】

※本記事は、原文「Using CI/CD to add automation to your network」の日本語訳です

概要

ネットワークが複雑さを増すにつれて、それを維持しスケールさせることが難しくなります。ネットワークエンジニアは、効率を向上させるために自動化を取り入れています。これらの自動化ツールを統合することで、ネットワークの作業はより効率的で正確かつスケーラブルになります。

以下のセクションでは、ネットワークエンジニアリングタスクを自動化するための主要なツールやテクニックについて説明します。

ツール

自動化されたネットワーク管理への移行は、ソフトウェア開発のベストプラクティスを取り入れた強力なツール群によって大きく容易になります。これらのツールはユーザフレンドリーであり、既存のネットワークエンジニアリングのワークフローにシームレスに統合されます。

Docker

Dockerは、コンテナを使用してアプリケーションを作成、デプロイ、実行するためのプラットフォームです。コンテナを使うことで、ライブラリやその他の依存関係など、アプリケーションが必要とするすべての部品をパッケージ化し、一つのパッケージとして配布することができます。事前にパッケージ化されたソフトウェアは、一貫したアプリケーション体験を保証し、ポータビリティを高めます。コンテナは非常に軽量で、アプリケーションの実行に必要な最低限のもののみを含みます。これは、アプリケーションの実行に関係のないソフトウェアやフルオペレーティングシステムを実行する仮想マシンとは異なります。

単一のコンテナを実行するためのDockerコマンドを使用することは素晴らしいですが、スケーラビリティはすぐに問題になります。Docker Composeを使用すると、複数のコンテナを単一のサービスとして管理できます。Docker Composeは、YAMLを使用してこのプロセスを簡素化するDockerのプラグインです。これは、互いに依存する複数のネットワークサービスやアプリケーションをデプロイする際に特に役立ちます。ウェブサーバ、データベース、DNSサービスを別々のコンテナで実行しながら、スケーラブルなシステムとして連携させることができます。今では、一連のコマンドを実行する代わりに、一つのコマンドで全てのサービスを起動できます。

Ansible

Ansibleは、複雑な設定作業や繰り返し作業を簡素化するオープンソースの自動化ツールです。Ansibleが他のツールと異なる点は、そのシンプルさと使いやすさにあります。Ansibleはプレイブック（YAML形式）を使用して自動化ジョブを記述し、インベントリファイルを使用して自動化するシステムを定義します。AnsibleはSSHを介して接続し、エージェントレスであるため、さまざまな種類のマシンをサポートしています。これは、ターゲットマシンにエージェントをインストールする必要がなく、新しいターゲットマシンを簡単に追加できることを意味します。

Git

Gitの機能の中心は、変更の履歴を保持し、コラボレーションを支援することにあります。私たちは、変更の各セットをメッセージと共にコミットし、誰がいつ何を行ったかについての明確な監査の軌跡を作成することができます。ネットワークエンジニアは、ネットワークの設定、スクリプト、またはドキュメンテーションに加えられたすべての変更を追跡することができます。これにより、説明責任が確保され、早期に問題を発見しやすくなり、発見されたエラーを元に戻すことができます。

Docker ComposeとAnsibleで使用されるYAML形式のプレーンテキストの性質は、Gitで追跡するのに最適です。これにより、ネットワークの段階的な変更を簡単に追跡し、「バージョン管理」を行うことができます。Gitを使用すると、複数のエンジニアがネットワークやインフラの異なる側面や部分に取り組むことができます。その後、彼らは他のメンバーがレビューし、変更をマージするか、発生した場合には衝突を解決するための提案を行うことができます。

これらの基本ツールを手に入れた今、次に、これらを組み合わせてネットワーク自動化に利益をもたらすワークフローを作成する方法について説明します。

継続的インテグレーションと継続的デプロイメント（CI/CD）

CI/CDは、現代のソフトウェア開発において重要であり、ネットワーク自動化に大いに利益をもたらすことができます。CI/CDを使用することで、開発者やネットワークエンジニアは、より頻繁かつ確実に変更を統合できます。CI/CDは、これらの実践によって構築、テスト、デプロイメントプロセスの自動化を強化することでこれを実現します。

継続的インテグレーション（CI）

CIは、エンジニアが共有リポジトリに自分の変更を統合する実践です。提案された変更は、統合される前に一連の自動テストを通過しなければなりません。ネットワークの複雑さを考えると、すべてのテストに合格しても、変更を自動的に受け入れるのが常に良い考えとは限りません。ベストプラクティスは、変更を適用する前に他の誰かにレビューしてもらうことです。このアプローチの目標は、ネットワーク設定をデプロイする際の統合問題を避けることです。

継続的デプロイメント（CD）

CDは、ビルドとテストの段階の後、変更を本番環境に自動的にプッシュすることで、さらなる自動化を保証します。これは、行われた変更が単にテストされるだけでなく、継続的にデプロイされることを意味します。CI/CDを使用すると、インフラストラクチャの変更は最小限のダウンタイムで継続的に展開されます。

CI/CDパイプラインの作成

CI/CDパイプラインは、ビルド、テスト、デプロイの方法に関して多くの自由を提供します。詳細については、GitHubアクションを使用してGo Webアプリをビルドおよびデプロイする方法について詳しく説明しているこちらのブログをご覧ください。典型的なパイプラインの見た目を理解するために、彼らのパイプラインを上で示します。

GitHub Actionsと仲良くなったよ

パイプラインの各ステップはDockerコンテナ内で実行され、Dockerコンテナ内でホストまたはビルドすることもできます。もし興味がありましたら、Kanikoを使用する方法を説明している別のブログもあります。

GitHub Actionsでkanikoを使ってコンテナイメージをビルドする技術

前述の通り、コンテナは非常に移植性が高く、自己完結しています。これは、パイプラインで実行するジョブが20個ある場合、それらは20台の異なるマシンで実行できることを意味します。GitHubやGitLabのデフォルトのCI/CDパイプラインを使用する場合、ジョブは20個の異なるネットワークで実行できます。ほとんどのアプリケーションにとっては問題ではありませんが、パイプラインの目的はアプリケーションをテストすることではなく、アプリケーションを使用してネットワークをテストすることです。パイプラインを実行しても、テストしている同じネットワーク上になければ成功しません。

ネットワーク内でテストを行うことを確実にするために、ランナー（テストを「実行」するアプリケーション）をホストする必要があります。GitLabを使用すると、ランナー用のDockerコンテナを提供され、パイプラインの設定と実験が非常に簡単になります。複数の自己ホスト型ランナーを持つことは、負荷分散と冗長性を提供します。これにより、単一の障害点がない堅牢なCI/CDパイプラインが作成されます。

サンプルパイプライン

使用環境内で作成可能なパイプラインは無限にありますが、どのような場合でもバックアップは必要です。これらのツールがどのように連携しているかを示すために、いくつかのルータのバックアップを行う簡単なパイプラインの例を紹介します。

Inventory File:

[routers]
r01.demo.the-net.work ansible_host=r01.demo.the-net.work
r02.demo.the-net.work ansible_host=r02.demo.the-net.work
r03.demo.the-net.work ansible_host=r03.demo.the-net.work

[routers:vars]
ansible_user=cvisser
ansible_connection=ansible.netcommon.network_cli 
ansible_network_os=vyos.vyos.vyos

Ansible playbook:

--
  - hosts: routers
    gather_facts: no 

    tasks: 
      - name: Login to each router and take the backup 
        vyos.vyos.vyos_config: 
          backup: yes 
          backup_options:
              filename: "{{ inventory_hostname }}.cfg"

CI/CD pipeline:

stages:
  - Backup 

vyos_take_backup:
  image: registry.gitlab.com/vmastar/demo-router-backup/ansible:latest
  stage: Backup
  script:
    - echo "$SSH_PRIVATE_KEY" > /root/.ssh/id_rsa
    - cd /root/demo-router-backup
    - git pull
    - ansible-playbook -i inventory backup.yml
    - git add backup && git commit -m "Changes in router config" && git push
    - exit 
  only:
    - web
    - schedules

CI/CDパイプラインやAnsibleに不慣れな場合は、コードブロックを逆順に読むのが最も簡単です。CI/CDパイプラインは、他のブロックで定義したタスクを実行しています。CI/CDパイプラインの最初から始めます：

• このサンプルパイプラインには「バックアップ」という一つのステージのみがあり、過去に構築した「ansible」コンテナで実行されます。
• GitLabのアーティファクトを使用して、私たちのコンテナにネットワーク内のマシンにアクセスするために使用できるSSHキーを提供します。
• ローカルのGitリポジトリが最新であることを確認します。
• 「インベントリ」ファイルを使用してAnsibleプレイブック「backup.yml」を実行します。
  • Ansibleはルータグループ内の各ルータにログインし、現在の設定のバックアップを取ります。
• Gitにルータの変更をコミットし、変更をGitリポジトリにプッシュして終了します。
• 最後に、このジョブは、スケジュールされた場合、またはREST APIを介してこのパイプラインをトリガーした場合にのみ実行されます。

これにより、自動的にすべてのルータの定期的なバックアップを行うことができます。従来のcronジョブを配布しようとするのとは異なり、スケジュールを一度だけ書く必要があります。パイプラインのためのランナーが利用可能である限り、これらルーは定期的なバックアップを受け取ります。

最終的なワークフローは次のようになります：

 

まとめ

この記事は、今年京都で開催されたAPNIC 56でのネットワーク自動化チュートリアルの要約版です。このチュートリアルのリソースはこちらで入手でき、ラボ演習のための多くのスライドとドキュメントが含まれています。自分で行うことができる短い自己完結型のチュートリアルについては、こちらの指示に従ってください。このチュートリアルには、IIJ LabのTechTrend Talkシリーズの一環として行われたトークも付属しており、この記事で説明したワークフローを要約しています。

現代のネットワーク環境の複雑さを管理するためには、自動化を取り入れることが不可欠です。DockerやAnsibleのようなツールは、ネットワーク設定のデプロイメントと管理を効率化します。一方、CI/CDパイプラインは一貫性がありエラーのない運用を促進します。これらの実践は、ネットワークエンジニアが革新を優先し、生産性とネットワークの信頼性を向上させるのに役立ちます。

ワークフローにさらなる自動化を取り入れる方法は無数にあります。もしかしたら、今回紹介したツールの中には不慣れなものもあり、難しく感じるかもしれません。最良のアプローチは、小さく始めることです。例えば、バックアップを取り、そこからスキルを構築することです。