はじめに
こんにちは、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-downloadArista アカウント登録
*アカウントがない場合は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