Позвольте мне начать с того, что я обычно запускаю Containerlab на выделенной виртуальной машине Ubuntu 24.04, которая работает поверх Proxmox. Все мои лаборатории работают на этой конфигурации. Тем не менее, недавно я хотел попробовать запустить Containerlab прямо на моем MacBook (M3 Pro с 18 ГБ оперативной памяти) по нескольким причинам. Например, мне может потребоваться запустить лабораторные работы, когда я отсутствую, работать в автономном режиме или использовать MacBook на работе, где нет доступа к домашней сети. Итак, я решил проверить, смогу ли я запустить Cisco IOL и Arista EOS на macOS. Ответ — да, и вот как вы можете это сделать.
Если вы новичок в Containerlab и пытаетесь понять, что это такое, я настоятельно рекомендую ознакомиться с моим вступительным постом, ссылка на который приведена ниже. Он охватывает основы и поможет вам начать работу.
Необходимые условия
В этой записи блога предполагается, что вы немного знакомы с Docker, VSCode и запуском контейнеров в macOS. Для этого вам потребуется установить Docker Desktop и VSCode. Если вы знаете, как работают DevContainers, это плюс, но мы рассмотрим основы по мере продвижения.
У Containerlab есть отличная документация по его запуску на macOS, включая все технические подробности. Роман также создал отличное видео, объясняющее, как это работает и как его настроить. Обе ссылки приведены ниже для справки.
- Containerlab doc - https://containerlab.dev/macos/
Стоит отметить, что существует несколько способов запустить Containerlab на macOS. Например, вы можете создать виртуальную машину Linux на macOS и запустить там Containerlab, но для этого потребуется управление виртуальной машиной. Если вы предпочитаете не использовать виртуальную машину, есть два варианта использования контейнеров разработки. Docker-in-docker и docker-outside-docker. Этот пост посвящен Docker-outside-Docker
- Докер-в-Докере - Внутри контейнера запущен собственный демон Docker.
- Docker-outside-Docker - Контейнер использует демон Docker из хост-системы (вашего Mac).
💡
Обратите внимание, что образы Cisco IOL созданы для архитектуры x86, а не для ARM (которая используется в чипах Mac M-серии). Для запуска этих образов Mac M-серии использует уровень совместимости Rosetta, который позволяет приложениям на базе x86 работать на архитектуре ARM. Однако cEOS от Arista предоставляет нативную версию ARM по состоянию на 28 января 2025 года.
Что такое DevContainers?
Контейнеры разработки, или контейнеры разработки, — это способ создания согласованной и изолированной среды разработки с помощью контейнеров Docker. Они позволяют упаковать все инструменты, зависимости и конфигурации, необходимые для проекта, в контейнер, который можно легко использовать и запускать в любой системе. С помощью расширения DevContainers от VSCode вы можете легко работать внутри этих контейнеров, что упрощает поддержание чистой и переносимой конфигурации. Этот подход особенно полезен для предотвращения конфликтов между различными проектами или средами.
Как Containerlab работает на DevContainer?
При использовании DevContainer Containerlab работает внутри контейнерной среды, используя демон Docker на хост-системе (Docker-outside-Docker). Это означает, что контейнер выполняет работу с сетью и настройку лаборатории, а фактические контейнеры для сетевых устройств (например, Cisco IOL или Arista EOS) управляются Docker на компьютере Mac.
В этой конфигурации в DevContainer установлен Containerlab, но вашему Mac он не нужен. Образы сетевых устройств (например, Cisco IOL или Arista EOS) выполняются в управляющей программе Docker хост-системы, в то время как DevContainer может просматривать их и управлять ими.
Импорт изображений
В этом примере я использую Arista cEOS и Cisco IOL. Вам нужно будет получить эти образы самостоятельно. Образ Arista можно скачать прямо с их сайта, и я подробно объяснил этот процесс в своем вступительном посте, поэтому предполагаю, что они у вас уже есть. В любом случае, вот краткое резюме.
Для Arista убедитесь, что вы скачали версию образа ARM, а затем импортировали ее как образ Docker.
docker import cEOSarm-lab-4.33.1-EFT3.tar.tar ceos:4.33.1
docker inspect c4d1b7398564 | grep Archi
"Architecture": "arm64",
Для Cisco IOL я обычно использую vrnetlab на своем сервере Linux для создания образов Docker из .bin Файлы. Однако этот процесс может не работать непосредственно в macOS. Поскольку у меня уже были образы Docker на моей виртуальной машине Ubuntu Linux, я экспортировал их оттуда и импортировал на свой Mac. Ниже приведен краткий обзор этих шагов.
- Экспортируйте образ Docker с виртуальной машины Linux с помощью docker save
- Перенесите файл изображения на Mac с помощью scp
- Импортируйте изображение в Docker на Mac с помощью docker load
Ниже приведен пример импорта образов Cisco IOL. Процесс точно такой же для других изображений, таких как Arista cEOS или любых других образов сетевых устройств, которые вы можете использовать.
#on linux vm docker save -o cisco_iol.tar vrnetlab/cisco_iol
#on mac scp suresh@10.10.10.41:/home/suresh/cisco_iol.tar . docker load -i cisco_iol.tar
После завершения процесса импорта вы можете убедиться, что изображения доступны, выполнив команду docker images. Эта команда выведет список всех образов Docker в вашей системе, включая те, которые вы только что импортировали.
docker images | grep -E 'iol|eos'
ceos 4.33.1 c4d1b7398564 2 hours ago 2.76GB
vrnetlab/cisco_iol l2-17.12.01 6b711e2baee6 5 weeks ago 607MB
vrnetlab/cisco_iol 17.12.01 f51066aaf4da 5 weeks ago 704MB
Настройка DevContainer
Давайте начнем с создания каталога на вашем Mac, в котором мы будем хранить файл топологии Containerlab. Откройте этот пустой каталог в VSCode. В VSCode установите расширение Dev Containers, если вы еще этого не сделали. (Это всего лишь разовая задача)
Далее, в корне созданного вами каталога (я назвал свой clabv1), создаем новую директорию с именем .devcontainer. Внутри этого каталога создайте файл с именем devcontainer.json и добавьте следующее содержимое.
Я использовал конфигурацию из этого репозитория. Вот что devcontainer.json Файл должен выглядеть так.
{ "image": "ghcr.io/srl-labs/containerlab/devcontainer-dood-slim", "runArgs": [ "--network=host", "--pid=host", "--privileged" ], "mounts": [ "type=bind,src=/var/lib/docker,dst=/var/lib/docker", "type=bind,src=/lib/modules,dst=/lib/modules" ], "workspaceFolder": "${localWorkspaceFolder}", "workspaceMount": "source=${localWorkspaceFolder},target=${localWorkspaceFolder},type=bind,consistency=cached" }
Этот devcontainer.json устанавливает DevContainer с помощью метода ghcr.io/srl-labs/containerlab/devcontainer-dood-slim , который предварительно настроен для Containerlab. Он работает с сетью хоста, пространством имен хост-процессов и привилегированным режимом, что дает ему необходимые разрешения для взаимодействия с хост-системой.
Обратите внимание, что если вы посмотрите видео на YouTube по ссылке, то devcontainer.json файл в папке mounts Раздел содержит три записи. Однако теперь в репозитории есть только две записи. Если вы используете две записи с версией образа Docker 0.60.1, DevContainer не запустится с сообщением об ошибке.
docker: Error response from daemon:
invalid mount config for type "bind":
bind source path does not exist: /run/docker/netns.
Чтобы избежать этой проблемы, я решил использовать последнюю версию образа Docker, и проблема была решена.
Затем создайте файл топологии так же, как вы обычно это делаете. Для этой настройки нет необходимости указывать что-то другое, файл должен выглядеть как любой другой файл топологии Containerlab. Я назвал свой topology.yml.
--- name: clab_mac
mgmt: network: mgmt
ipv4-subnet: 192.168.100.0/24
topology: nodes: iol-1: kind: cisco_iol
image: vrnetlab/cisco_iol:17.12.01
mgmt-ipv4: 192.168.100.61
iol-2: kind: cisco_iol
image: vrnetlab/cisco_iol:17.12.01
mgmt-ipv4: 192.168.100.62
ceos-01: kind: ceos
image: ceos:4.33.1
mgmt-ipv4: 192.168.100.63
iol-l2: kind: cisco_iol
image: vrnetlab/cisco_iol:l2-17.12.01
type: l2
mgmt-ipv4: 192.168.100.70
links: - endpoints: ["iol-1:Ethernet0/1","iol-l2:Ethernet0/1"] - endpoints: ["iol-2:Ethernet0/1","iol-l2:Ethernet0/2"] - endpoints: ["ceos-01:eth1","iol-l2:Ethernet0/3"]
Наконец, пришло время запустить DevContainer. В левом нижнем углу VSCode нажмите на значок (см. скриншот) и выберите «Повторно открыть в контейнере». Как только вы это сделаете, VSCode перестроит и снова откроет ваше рабочее пространство в DevContainer.
Теперь вы будете помещены внутрь оболочки контейнера, это не оболочка вашего Mac. На данном этапе ваша лаборатория еще не развернута. Если вы откроете Docker Desktop, вы увидите, что этот контейнер работает и работает. Чтобы убедиться, что все работает, можно запустить containerlab version , чтобы проверить установку.
Обратите внимание, что если вы повторно откроете этот каталог в VSCode, например, после перезагрузки ноутбука, вы автоматически получите запрос на его открытие в DevContainer. Если вы пропустите всплывающее окно, вы всегда можете следовать предыдущему методу, чтобы снова открыть его вручную.
Запуск лабораторной работы
Теперь вы готовы начать свою лабораторию. Просто запустите команду containerlab deploy как показано ниже.
На этом этапе начнется работа лаборатории, и узлы Cisco и Arista включатся. Вы можете проверить состояние лаборатории, проверив Docker Desktop, чтобы увидеть, какие контейнеры работают. Как только лаборатория будет готова, вы можете подключиться к своим устройствам и начать тестирование или настройку по мере необходимости.
Тестирование и верификация
Чтобы протестировать настройку, я подключил SSH (из терминала Dev Container) к одному устройству Arista и одному устройству Cisco, настроил IP-адреса на их интерфейсах и попытался выполнить пинг между ними. Как и ожидалось, пинг прошел успешно, подтвердив, что лаборатория функционирует правильно.
ceos-01#conf ter
ceos-01(config)#interface eth1
ceos-01(config-if-Et1)#no shut
ceos-01(config-if-Et1)#ip address 10.15.10.5/24
! IP configuration will be ignored while interface Ethernet1 is not a routed port.
ceos-01(config-if-Et1)#no switchport
ceos-01(config-if-Et1)#end
ceos-01#show ip interface brief
Address
Interface IP Address Status Protocol MTU Owner
----------------- ----------------------- ------------ -------------- ---------- -------
Ethernet1 10.15.10.5/24 up up 1500
Management0 192.168.100.63/24 up up 1500
ceos-01#
ceos-01#
iol-1#conf ter
Enter configuration commands, one per line. End with CNTL/Z.
iol-1(config)#interface ethernet0/1
iol-1(config-if)#ip address 10.15.10.6 255.255.255.0
iol-1(config-if)#no shut
iol-1(config-if)#end
iol-1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 192.168.100.61 YES TFTP up up
Ethernet0/1 10.15.10.6 YES manual up up
Ethernet0/2 unassigned YES unset administratively down down
Ethernet0/3 unassigned YES unset administratively down down
iol-1#ping 10.15.10.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.15.10.5, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
Как только вы закончите работу со своей лабораторией, как всегда, вы можете уничтожить их одной командой.
Доступ к узлу непосредственно с Mac
Поначалу я не мог понять, как получить доступ к узлам непосредственно со своего Mac, и мне пришлось использовать DevContainer для запуска сеансов SSH. Изучая я узнал, что предоставление портов в файле топологии решает эту проблему. Добавив параметр ports , как показано ниже, вы можете сопоставить SSH-порт контейнера с портом на вашем Mac, обеспечивая прямой доступ.
ceos-01: kind: ceos
image: ceos:4.33.1
mgmt-ipv4: 192.168.100.63
ports: - 2122:22
Этот порт карт 22 (SSH) внутри контейнера в порт 2122 на компьютере Mac. Теперь вы можете использовать SSH прямо со своего Mac с помощью ssh -p 2122 user@192.168.100.63. Я внес это изменение только для изображения Arista, но тот же подход работает и для других устройств.
#192.168.0.26 is my Mac's IP
ssh -p 2122 admin@192.168.0.26
(admin@192.168.0.26) Password:
Last login: Tue Jan 28 21:40:06 2025 from 192.168.100.1
ceos-01>en
ceos-01# ceos-01#exit Connection to 192.168.0.26 closed.