はじめに

こんにちは、iTOC事業部MBS部の北村です。
皆様、仮想的な検証環境を作ろうとする際に、どのような基盤を利用するか悩まれることはないですか？
または、少し試してみたいことがあるけど、一から検証環境を作るのを面倒に感じたりすることはないですか？いくつかに例に挙げると、virtualbox、ESXi、GNS3等がありますが、構築するのに手間がかかったり、動作環境に高いスペックが求められたり、環境ができても動作が重いこともあると思います。
この記事では、containerlabを使ったArista検証機の立ち上げから、Ansibleでの設定変更を試してみたので紹介したいと思います。

containerlabとは

containerlabはネットワーク製品に特化した検証環境をコンテナで実現するツールです。
あらかじめDockerをインストールしたLinux環境さえあれば、コンテナベースの検証環境を用意することができます。
またOSSのため誰でも利用可能です。

containerlabには以下の特徴があります。

VMと比べると消費リソースが少ない
環境をyml形式で定義するので簡単で流用もしやすい
パケットキャプチャやトポロジー図作成もできる
マルチベンダーに対応できる
環境の構築、削除が1コマンドで実行できる

事前準備

Ansibleが実行できる環境の用意
containerlabを実行するための環境準備
(1VMにつき1つ以上のvCPUが必要)
Dockerインストール
以下のURLからeosのイメージをダウンロード(アカウント登録必要)
https://www.arista.com/en/support/software-download
Arista アカウント登録
*アカウントがない場合はneed a user accountより作成します
ログイン後にsoftware downloadからイメージをダウンロード

想定構成

containerlabインストール

それでは、さっそく以下のコマンドでcontainerlabをインストールします。

sudo bash -c "$(curl -sL https://get.containerlab.dev/)"

無事インストールできました。

・イメージのimport

適当なディレクトリを以下のコマンド作成、移動して先ほどダウンロードした、eosのイメージファイルを格納しておきます。

mkdir container_lab
cd container_lab

その後下記のコマンドで、imageをインポートします。

sudo docker import cEOS-lab-4.28.8.1M.tar ceos:4.28.8.1M

・containerlabで実行したい環境をymlファイルで記述します

今回は2台の機器を接続状態で立ち上げて、外部からsshで入れるようにポートフォワーディングしています。

---
name: ceos_test

topology:
  nodes:
    ceos1:
      kind: ceos
      image: ceos:4.28.8.1M
      ports:
        - 2222:22
    ceos2:
        kind: ceos
        image: ceos:4.28.8.1M
      ports:
        - 2223:22

  links:
    - endpoints: ["ceos1:eth1", "ceos2:eth2"]

containerlab 起動

・起動

以下のコマンドでデプロイしてみます。

sudo containerlab deploy -t ファイル名.yml

statusがrunningになっており、起動していることが確認できました。

・トポロジー図確認

続いてのでトポロジー図を確認してみます。

sudo containerlab graph -t (containerlab起動ymlファイル)

表示されたURLをクリックします

無事表示されました！

・疎通確認

実際にsshでログインして疎通確認をしてみましょう

 ssh admin@clab-ceos_test-ceos1

Arista初期password: admin
enable password: なし

ceos1からceos2のmanegement interfaceにpingが当たっていることが確認できます。

Ansible実行環境からcontanerlabにssh

「EC2→セキュリティ→セキュリティグループ→インバウンドルールの編集」で、インバウンドルールに以下の設定をします。

項目	値
タイプ	カスタムTCP
ポート範囲	2222-2223
ソース	ansible実行環境のIP

それでは、Ansible実行環境からcontainerlabで立ち上げた機器のshow routeを見るための簡単なplaybookを動かしてみます。

---
- hosts: eos
  gather_facts: false

  tasks:
    - name: show version
      arista.eos.eos_command:
        commands: 
          - command: show version
      register: result

    - name: Debug show
      ansible.builtin.debug:
        msg: "{{ result.stdout_lines[0] }}"

無事Ansibleの実行環境からcontainerlabで立ち上げた環境のshow versionを見ることができました！

PLAY [eos] ******************************************************************************************************************************************

TASK [show version] *********************************************************************************************************************************
ok: [ceos02]
ok: [ceos01]

TASK [Debug show] ***********************************************************************************************************************************
ok: [ceos01] => {
    "msg": [
        "Arista cEOSLab",
        "Hardware version: ",
        "Serial number: C176FE288E152E5E5664D77832C446BE",
        "Hardware MAC address: 001c.73ee.f229",
        "System MAC address: 001c.73ee.f229",
        "",
        "Software image version: 4.28.8.1M-32996684.42881M (engineering build)",
        "Architecture: i686",
        "Internal build version: 4.28.8.1M-32996684.42881M",
        "Internal build ID: 747d90a4-e0fb-465d-ba68-4a63d8baf0be",
        "Image format version: 1.0",
        "Image optimization: None",
        "",
        "cEOS tools version: 1.1",
        "Kernel version: 6.1.49-70.116.amzn2023.x86_64",
        "",
        "Uptime: 4 minutes",
        "Total memory: 16365748 kB",
        "Free memory: 13624384 kB"
    ]
}
ok: [ceos02] => {
    "msg": [
        "Arista cEOSLab",
        "Hardware version: ",
        "Serial number: 0C4001D8BA125051E6FADB3C4B4F5430",
        "Hardware MAC address: 001c.7311.48ba",
        "System MAC address: 001c.7311.48ba",
        "",
        "Software image version: 4.28.8.1M-32996684.42881M (engineering build)",
        "Architecture: i686",
        "Internal build version: 4.28.8.1M-32996684.42881M",
        "Internal build ID: 747d90a4-e0fb-465d-ba68-4a63d8baf0be",
        "Image format version: 1.0",
        "Image optimization: None",
        "",
        "cEOS tools version: 1.1",
        "Kernel version: 6.1.49-70.116.amzn2023.x86_64",
        "",
        "Uptime: 4 minutes",
        "Total memory: 16365748 kB",
        "Free memory: 13624384 kB"
    ]
}

PLAY RECAP ******************************************************************************************************************************************
ceos01                     : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
ceos02                     : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

終わりに

実際にcontainerlabに触れてみて、以下のことを感じました。

containerlabで検証環境を立ち上げるまでのプロセスが簡単
一度定義ファイルを作成してしまえば、検証環境を消したり、作り直すことが簡単
作業者間で定義ファイルを共有して、それぞれの環境で同一の検証環境を簡単に作成できる
1コマンドでトポロジー図まで表示できるのが便利
少ないリソースで動かせる
マルチベンダーに対応しているが、ベンダーによってはイメージを手に入れるのが難しい場合もある

今後、仮想検証環境を作成する際の選択肢の一つにしていただけると幸いです。

参考リンク

https://containerlab.dev/ https://enog.jp/wordpress/wp-content/uploads/2022/11/ENOG76_containerlab_%E4%BA%8B%E5%BE%8C%E8%B3%87%E6%96%99.pdf https://www.janog.gr.jp/meeting/janog51/wp-content/uploads/2022/12/janog51-lab-nakagawa-shima.pdf

APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

【Blog Week】containerlabを使ってみた