Tutorial

RouterOS Containers: MikroTikでDocker

MikroTik RouterOS v7でDocker形式のコンテナを実行: コンテナモードの有効化、vethネットワークとストレージの設定、大規模な展開と管理まで解説します。

MKController2026年6月23日2 min read

概要 MikroTik RouterOS v7 は Docker 互換のコンテナをルーター上で直接実行できるため、DNS フィルタリング、監視エージェント、小規模なネットワークサービスを別の機器ではなくルーティングプレーンの隣に配置できます。本ガイドでは、ハードウェアとアーキテクチャの要件、コンテナ device-mode の安全な有効化、NAT を伴う veth とブリッジネットワークの構築、最初のコンテナの展開、そして全台にわたるコンテナの管理を解説します。RouterOS 7.23（2026年5月）はすぐに使えるコンテナアプリのカタログを拡充し、ISP にもラボ構築者にも実用的な選択肢にしました。

積み重なった Docker 形式のサービスコンテナをホストするルーターを示す MikroTik RouterOS コンテナアーキテクチャ図

MikroTik RouterOS のコンテナとは？

MikroTik RouterOS のコンテナは、RouterOS v7 デバイスが分離された Docker 互換のアプリケーションイメージをルーター上で直接実行できるようにする、MikroTik による Linux コンテナの実装です。Docker Hub、GCR、Quay などのレジストリのイメージで動作し、RouterOS は docker コマンドの代わりに独自の CLI 構文を使いますが、基本的な動作は同じです — イメージをプルし、ネットワークを与え、ストレージをマウントして実行します。(MikroTik ドキュメント)

ISP やラボにとってこれは、ネットワーク近接の小規模サービスをルーティングプレーンと同居させられることを意味します。Pi-hole や AdGuard の DNS フィルタ、監視エージェント、リバースプロキシ、IoT ブリッジなどです。2026年5月25日の安定版 RouterOS 7.23 は、すぐに使えるアプリの長いリストを追加しました — paperless-ngx、nextcloud、lorawan-stack、birdnet-go、そして portainer や dockge のような Docker 管理フロントエンドなどです — あわせて、コンテナが送信トラフィックを開始するのをブロックする新しい network-outgoing-access スイッチも追加されました。(RouterOS 7.23 changelog)

要件とハードウェア

container パッケージは arm、arm64、x86 のアーキテクチャに対応しており、何よりも先にインストールする必要があります。リモートイメージのプルには多くの空き容量が必要なため、MikroTik はデバイス内部のフラッシュではなく外付けストレージを推奨しています。(MikroTik ドキュメント)

RouterOS が対応するファイルシステムでフォーマットした、USB、SATA、または NVMe の外付けメディアを計画してください。MikroTik は少なくとも 100 MB/s のシーケンシャルスループットと 10K のランダム IOPS を扱えるディスクを推奨しています — 遅いディスクではイメージの展開が苦痛なほど長くなります。コンテナのボリュームを内蔵ストレージに置くのは避けてください。容量が小さく、コンテナの書き込みパターンで摩耗します。フラッシュが非常に限られたデバイスは、リモートからプルする代わりに、接続したディスク上の事前ビルド済みイメージを使うべきです。

コンテナ Device-Mode を安全に有効化

コンテナはデフォルトで無効になっており、もっともな理由から、有効化には物理アクセスが必要です。次のコマンドで機能を有効にします。

/system/device-mode/update container=yes

すると RouterOS は、リセットボタンの押下またはコールドリブートによる確認を待ちます。この物理確認のゲートは意図的なセキュリティ制御です。いったんコンテナモードが有効になると、コンテナはリモートで追加、起動、削除でき、悪意あるイメージはルーター上の足がかりになり得ます。MikroTik はこの点を率直に述べています — RouterOS デバイスが侵害された場合、コンテナによって悪意あるソフトウェアのインストールは容易になり、サードパーティ製イメージにはセキュリティ保証がありません。

コンテナをホストするルーターは、その上で実行する最も信頼できないイメージとちょうど同じだけ安全だと考えてください。信頼できるイメージのみを展開し、デバイスをファイアウォールで保護し、本番環境で有効にする前に当社の device-mode セキュリティ運用ガイドをお読みください。

コンテナネットワークを構築

コンテナがインターネットに到達するには、仮想インターフェース、ブリッジ、NAT が必要です。以下のパターンは Docker の「ブリッジ」ネットワークを反映しています。まず、ゲートウェイアドレスを共有する veth インターフェースとブリッジを作成します。

/interface/veth/add name=veth1 address=172.17.0.2/24 gateway=172.17.0.1
/interface/bridge/add name=containers
/ip/address/add address=172.17.0.1/24 interface=containers
/interface/bridge/port add bridge=containers interface=veth1

1 つの veth は多数のコンテナを処理でき、追加の veth/ブリッジのペアを作成すれば、コンテナのグループを互いに分離できます。RouterOS のブリッジングに不慣れな場合は、当社のブリッジ設定チュートリアルが基礎となるモデルを説明します。次に、送信コンテナトラフィックが変換されるよう masquerade ルールを追加します — 全体像については NAT 設定ガイドを参照してください。

/ip/firewall/nat/add chain=srcnat action=masquerade src-address=172.17.0.0/24

最初のコンテナを展開

レジストリと一時展開ディレクトリを外部ディスクに向けてから、イメージを追加します。以下の Pi-hole の例は MikroTik ドキュメントの定番のものです。

/container/config/set registry-url=https://registry-1.docker.io tmpdir=disk1/tmp
/container/add remote-image=pihole/pihole interface=veth1 root-dir=disk1/images/pihole name=pihole logging=yes

コンテナの追加はダウンロードと展開を開始しますが、実行はしません。/container/print で進捗を確認し、status=stopped になるまで待ってから起動します。

/container/start pihole

最後に、ルーターから veth アドレスへポートを転送して、サービスを公開します。

/ip firewall nat add action=dst-nat chain=dstnat dst-address=192.168.88.1 dst-port=80 protocol=tcp to-addresses=172.17.0.2 to-ports=80

これで Pi-hole はルーターの LAN IP で応答します。この方法で DNS フィルタリングを実行するのは、RouterOS のネイティブブロックリストの代替手段です — コンテナを使わない経路を好む場合は、当社の RouterOS adlist チュートリアルを参照してください。

全台にわたるコンテナの管理

1 台のルーター上の単一コンテナは簡単です。ISP にとって本当の運用上の課題は一貫性です。すべてのデバイスで同じイメージ、同じ veth と NAT のスキーム、同じストレージレイアウト、同じ start-on-boot とメモリ上限を保つことです。RouterOS はそのためのプリミティブを提供します — start-on-boot=yes は再起動後も維持され、memory-high または memory-max はコンテナごとに RAM を制限するため、暴走したサービスがルーティングプレーンを枯渇させることはありません。

/container/config/set memory-high=200M
/container/set pihole start-on-boot=yes

難しいのは、これを数十台、数百台のリモートルーターで同一に行い、さらに各台が再起動後に実際に復帰したことを証明することです — とりわけデバイスが CGNAT の背後にあり、そのパブリック IP に単純には到達できない場合です。

ヒント

すべてのコンテナボリュームを外部ディスク上に保ち、内部 NAND には決して置かないでください。
信頼できないコンテナを信頼できるものから分離するため、別の veth/ブリッジのペアを使用してください。
ルーターの応答性を保つため、完全には信頼できないものすべてに memory-max を設定してください。
本番環境に手を付ける前のクリーンなテスト環境として、物理ルーターに展開する前に、仮想化された CHR インスタンス上で同じイメージを実行してください。

次のステップへ

コンテナは MikroTik ルーターを小さなアプリケーションホストに変えますが、そうしたホストの群れにはオーケストレーションが必要です。MKController は RouterOS 構成を一元的にテンプレート化し、インベントリ内のすべてのデバイスに適用し、ドリフトを追跡するため、どのルーターが逸脱したかを確認できます — そして NATCloud を通じて CGNAT の背後にあるデバイスにも到達し、メンテナンス後にコンテナが再起動したことを確認します。これにより、1 つのコンテナを手作業で構成することと、ISP ネットワーク全体でそれらを確実に運用することのギャップが埋まります。

MKController の無料トライアルを始める