はじめに
Containerlab を使った検証環境構築はかなり便利ですが、実際に触ってみると「便利さ」と同時に「入口の高さ」も感じました。
特に感じたのは、以下のような点です。
-
lab.clab.ymlを直接編集する前提になりやすい - デプロイや停止、状態確認が CLI 前提になりやすい
- NetDevOps に慣れていないメンバーには学習コストが高い
- ネットワークエンジニア視点では、最初の一歩が少し重い
そこで今、Containerlab 向けの WebUI プロジェクトとして Containerlab Web Studio を開発しています。
この記事では、
- どんな UI を目指しているのか
- なぜ作ろうと思ったのか
- どこまで育てたいのか
を、開発記録としてまとめます。
GitHubにてコードを公開しています。※現在は開発中のため、デプロイ手順等の整備はまだです。
- GitHub: Containerlab Web Studio
操作 UI イメージ
今回の記事で一番伝えたいのはここです。
単に「Containerlab の YAML をブラウザで編集する」だけではなく、Containerlab の主要操作を UI に載せることを意識しています。
Lab一覧
ContainerlabではYAMLファイルで管理されるLabを、Lab一覧として視覚的に管理します。
ここでは、
- 作成済みラボの一覧表示
- ラボの状態表示
- ラボの作成
- ラボの削除
を扱います。
CLI を知らなくても、まず「どのラボがあるのか」「今どういう状態か」が見えることを重視しています。
Topology Editor
中心となるのはトポロジ編集画面です。
現在は以下のような操作ができます。
- Router / Client ノードをドラッグ&ドロップで配置
- ノード間リンクの作成
- ノード設定の編集
- YAML Preview の確認
- Lab の Save / Deploy / Stop
- ノード terminal の起動
特に重要なのは、キャンバス上の操作がそのまま Containerlab YAML に反映されることです。
YAML を書ける人にとっても便利ですし、YAML をまだ書き慣れていない人にも入口になります。
Config Management
コンフィグ管理も UI に統合しています。
ここでは、
- config ファイルの新規作成
- 編集
- 削除
- ノードへの bind を前提にした管理
を行えます。
Containerlab では最終的にファイル bind が重要になるので、単なるテキストメモではなく、ラボ配下の config 資産として扱う方向で設計しています。
Lab Status
デプロイした後の状態確認もブラウザ上で見られるようにしています。
バックエンド側では containerlab inspect --details --name <lab-name> --format json を呼び出し、ノードの running 状態や管理 IP を UI に表示しています。
Browser Terminal
ノード terminal もブラウザから開けるようにしています。
操作感はできるだけ普通の terminal に寄せたかったので、WebSocket + xterm.js ベースで実装しています。
ノードメニューから terminal を開いて、そのままコンテナ内に入って確認できる流れです。
backエンド側ではCLI操作と同様docker container execによるコンテナ接続を行っているため、CLI側操作との差分や処理差分等はありません。
作成背景
この WebUI を作ろうと思った背景はかなりシンプルです。
Containerlab は強い。けれど、現場での入口はまだ CLI と YAML に寄りすぎている。
もちろん、Containerlab には公式の VS Code Extension があります。
これはとても良い仕組みだと思っていますし、VS Code を前提にできる環境では強力です。
ただ、自分が意識しているのは、「VS Code が必須」という制約を受けたくない環境です。
例えば、
- 作業端末を固定できない
- リモートの jump host や共有環境から使いたい
- ブラウザさえあれば触れる形にしたい
- IDE の導入や拡張機能の利用が難しい
- ネットワーク担当者全員に VS Code 前提を求めたくない
といったケースです。
このような環境では、
- Containerlab ホスト上で WebUI サービスを起動
- 利用者はブラウザでアクセス
- トポロジ作成、デプロイ、terminal 操作まで一通り実施
という形の方が導入しやすいと考えています。
つまりこのプロジェクトは、VS Code Extension の代替を否定したいわけではなく、
「VS Code 前提にしたくない現場向けの選択肢を作りたい」
というのが狙いです。
なぜ WebUI にするのか
ネットワークエンジニアの実務を考えると、最初から全員が CI/CD や GitOps 的なフローに馴染めるわけではありません。
一方で、だからといって YAML や自動化そのものを諦めるのも違います。
その中間にあるものとして、
- UI で触れる
- でも内部では YAML を生成する
- さらに deploy / status / config / terminal まで一つの導線で扱える
という形が、実運用への橋渡しになると思っています。
WebUI にしているのは、単に見た目のためではなく、NetDevOps の入口を広げるためです。
現在の構成
現状の構成は以下です。
- frontend: Vue + Vite
- backend: Go
- terminal: WebSocket +
xterm.js - deploy / stop / inspect: backend から
containerlabを実行 - config management: ラボ配下に保存して bind
このあたりも、単なる画面アプリではなく「ラボ資産を持つツール」として設計しています。
最終ゴール
最終ゴールは、単なる WebUI での編集ツールではありません。
自分が目指しているのは、
Containerlab を起点にした NetDevOps プラットフォーム
です。
具体的には、今後以下のような方向へ広げていきたいと考えています。
- トポロジ作成
- コンフィグ管理
- ラボの deploy / stop / status
- terminal 操作
- ノード設定変更
- イメージ管理
- ラボ資産の再利用
- 将来的な CI/CD や Git ベース連携
つまり、
- YAML を生成するだけのツール
- terminal を開くだけのツール
- ラボ一覧を表示するだけのツール
ではなく、Containerlab を使った検証・構築・運用を一つの流れとして扱える基盤にしていきたいです。
NetDevOps の世界では最終的に自動化や IaC に寄っていくとしても、最初の入口がブラウザベースで分かりやすいことには大きな意味があると思っています。
おわりに
Containerlab は本当に便利ですが、使い始めるまでのハードルが少しだけ高いと感じる場面があります。
そのギャップを埋めるために、今 Containerlab Web Studio を開発しています。
改めて、このプロジェクトで大事にしたいのは次の3点です。
- 操作 UI イメージを明確にすること
- VS Code 必須にしたくない環境向けの選択肢を作ること
- 最終的には NetDevOps のプラットフォームに育てること
まだ開発途中ですが、かなり便利なものになる手応えがあります。
今後も機能追加や改善を進めていく予定なので、また進捗を記事にしたいと思います。