Что, если я скажу вам, что все, что вам нужно, это просто файл YAML с кучей строк для создания сетевой лаборатории, которую можно легко запустить на вашем ноутбуке? Вы бы назвали меня сумасшедшим, верно?
Если вы новичок в Containerlab или хотите быстро научиться, подписывайтесь на меня https://dzen.ru/kalyuzhnyy.ru Чтобы поддержать меня.
Что ж, в этой статье блога я расскажу вам, что такое Containerlab и как он может упростить создание и управление вашими лабораториями. Давайте погрузимся.
О чем мы расскажем?
- Что такое containerlab?
- Сравнение EVE-NG/GNS3 с Containerlab
- Установка и первичная настройка
- Лабораторные снимки (Arista cEOS)
- Терминология Containerlab
- Пример лабораторной работы
- Уборка
- Заключение
Что такое Containerlab?
Официальное определение звучит так: «Containerlab предоставляет интерфейс командной строки для оркестрации и управления сетевыми лабораториями на основе контейнеров. Он запускает контейнеры, прокладывает между ними виртуальную проводку для создания лабораторных топологий по выбору пользователей и управляет жизненным циклом лаборатории».
Проще говоря, containerlab — это инструмент «лаборатория как код», который помогает легко настраивать сетевые лаборатории и управлять ими. Вместо того, чтобы иметь дело со сложными настройками и конфигурациями, containerlab упрощает все за вас. Containerlab предоставляет интерфейс командной строки (CLI), который позволяет легко запускать контейнеры, соединять их виртуально и создавать сетевую топологию, которую вы хотите использовать в своей лаборатории.
Сравнение EVE-NG/GNS3 с Containerlab
Важно отметить, что сравнение EVE-NG или GNS3 с containerlab — это не совсем одно и то же самое. В то время как containerlab преуспевает в эффективном управлении сетевыми лабораториями на основе контейнеров, EVE-NG и GNS3 имеют свои сильные стороны в работе с устройствами на основе виртуальных машин, такими как Palo Alto VM, vMX или vSRX, с полной функциональностью (хотя containerlab также поддерживает запуск некоторых виртуальных машин)
Таким образом, вместо того, чтобы рассматривать их как конкурентов, правильнее рассматривать эти инструменты как дополняющие друг друга. containerlab упрощает настройку и управление лабораториями на основе контейнеров, в то время как EVE-NG и GNS3 обеспечивают универсальность в работе с устройствами на основе виртуальных машин. Вместе они представляют собой комплексный набор инструментов для сетевых инженеров для экспериментов и тестирования различных сетевых настроек.
Установка и первичная настройка
В этом примере я использую виртуальную машину Ubuntu, работающую на VMware Workstation в своей лаборатории. Поскольку containerlab использует Docker, убедитесь, что у вас установлен Docker.
С учетом этого предварительного условия установка containerlab так же проста, как выполнение одной команды.
bash -c "$(curl -sL https://get.containerlab.dev)"
Лабораторные изображения
Подобно EVE-NG или GNS3, containerlab не поставляется в комплекте с какими-либо изображениями из-за лицензионных ограничений. Тем не менее, получить необходимые изображения относительно просто. Если у вас есть учетные записи у соответствующих поставщиков, вы должны иметь возможность загружать нужные вам изображения.
💡
Я бы рекомендовал использовать версии EOS-4.28.0F или выше, чтобы избежать некоторых потенциальных проблем (подробнее об этом позже)
Для этого примера я скачал изображения Arista cEOS, создав бесплатную учетную запись в Arista. После загрузки следующим шагом будет импорт изображений в docker.
#downloaded file name - 'cEOS-lab-4.27.12M.tar'
docker import cEOS-lab-4.27.12M.tar ceos:4.27.12M
Терминология Containerlab
Прежде чем начать использовать containerlab, есть два основных термина, с которыми вы должны быть знакомы: определение топологии и виды.
Containerlab создает лаборатории на основе информации о топологии, которую передают ему пользователи. Эта информация о топологии выражается в виде кода, содержащегося в файле определения топологии.
Containerlab поддерживает широкий спектр поставщиков сетевых устройств. Однако процесс запуска и настройки этих устройств варьируется в зависимости от вендора. Чтобы упростить и абстрагировать этот процесс, containerlab вводит понятие «виды». Каждый поставщик или тип устройства связан с определенным типом, что позволяет containerlab различать их. Например, с помощью предопределенных типов, таких как eos или vr-vmx ContainerLab может определить тип развертываемого узла и настроить его соответствующим образом в процессе создания лаборатории.
Давайте создадим лабораторию
Хватит теории, давайте перейдем к примеру, чтобы продемонстрировать, насколько просто развернуть несколько узлов с помощью containerlab. В этом примере мы запустим шесть узлов Arista, создадим связи между ними и настроим OSPF только на двух из них, чтобы показать вам, что он действительно работает 😀
Определение топологии
Чтобы начать, вам понадобится.
- Изображение ноды Arista cEOS импортировано в Docker (что мы уже завершили).
- Файл топологии, указывающий желаемую настройку сети.
- И, наконец, всего одна команда для запуска узлов.
Я создал пустой каталог и YAML-файл для определения топологии. В arista.clab.yml , мы определяем структуру нашей лабораторной среды с помощью синтаксиса YAML.
#arista.clab.yml --- name: arista-labs
mgmt: network: mgmt
ipv4-subnet: 192.168.100.0/24
topology: kinds: ceos: image: ceos:4.27.12M
nodes: eos-01: kind: ceos
mgmt-ipv4: 192.168.100.11
eos-02: kind: ceos
mgmt-ipv4: 192.168.100.12
eos-03: kind: ceos
mgmt-ipv4: 192.168.100.13
eos-04: kind: ceos
mgmt-ipv4: 192.168.100.14
eos-05: kind: ceos
mgmt-ipv4: 192.168.100.15
eos-06: kind: ceos
mgmt-ipv4: 192.168.100.16
links: - endpoints: ["eos-01:eth1", "eos-02:eth1"] - endpoints: ["eos-01:eth2", "eos-04:eth2"] - endpoints: ["eos-01:eth3", "eos-03:eth3"] - endpoints: ["eos-01:eth4", "eos-05:eth4"] - endpoints: ["eos-02:eth2", "eos-03:eth2"] - endpoints: ["eos-02:eth3", "eos-04:eth3"] - endpoints: ["eos-02:eth4", "eos-06:eth4"] - endpoints: ["eos-03:eth1", "eos-04:eth1"] - endpoints: ["eos-03:eth5", "eos-05:eth5"] - endpoints: ["eos-04:eth5", "eos-06:eth5"]
- name- Указывает название нашей лаборатории, в данном случае arista-labs.
- mgmt - Определяет сеть управления для нашей лаборатории. Мы присвоили ему сетевое имя "mgmt" с подсетью IPv4 192.168.100.0/24.
- топология: описывает топологию нашей сетевой лаборатории.Виды- Указывает тип узла, который мы будем использовать, в данном случае, ceos
Узлы- Список отдельных узлов, которые мы хотим развернуть, каждый из которых имеет уникальный идентификатор («eos-01» — «eos-06») и IPv4-адрес управления.
endpoints- Устанавливает связность между узлами путем определения связей между их интерфейсами. Каждая запись в разделе "links" представляет собой соединение/кабель между двумя конечными точками, идентифицируемыми по имени узла и имени интерфейса (например, "eos-01:eth1").
После того, как мы создали этот YAML-файл, все, что осталось сделать, это выполнить одну команду для развертывания узлов и оживления лабораторной среды.
sudo containerlab deploy --topo arista.clab.yml
+---+-------------------------+--------------+---------------+------+---------+-------------------+--------------+
| # | Name | Container ID | Image | Kind | State | IPv4 Address | IPv6 Address |
+---+-------------------------+--------------+---------------+------+---------+-------------------+--------------+
| 1 | clab-arista-labs-eos-01 | d17114cddea0 | ceos:4.27.12M | ceos | running | 192.168.100.11/24 | N/A |
| 2 | clab-arista-labs-eos-02 | be0d17cffb3f | ceos:4.27.12M | ceos | running | 192.168.100.12/24 | N/A |
| 3 | clab-arista-labs-eos-03 | e1d833ab3bb2 | ceos:4.27.12M | ceos | running | 192.168.100.13/24 | N/A |
| 4 | clab-arista-labs-eos-04 | 209e18831ac0 | ceos:4.27.12M | ceos | running | 192.168.100.14/24 | N/A |
| 5 | clab-arista-labs-eos-05 | 247d1b12a980 | ceos:4.27.12M | ceos | running | 192.168.100.15/24 | N/A |
| 6 | clab-arista-labs-eos-06 | 873f89cfe2d2 | ceos:4.27.12M | ceos | running | 192.168.100.16/24 | N/A |
+---+-------------------------+--------------+---------------+------+---------+-------------------+--------------+
Хорошо, я столкнулся с проблемой
Кажется, что всякий раз, когда я пытаюсь запустить что-то в Linux, всегда возникает проблема 🥲. Поэтому, когда я выполнил команду для развертывания лабораторий, я застрял с этой ошибкой. Погуглив и немного почитав этот блог, я нашел обходной путь. Внес необходимые изменения, повторил попытку развертывания, и вуаля! Все заработало без сбоев. Вот где развертывание застряло.
INFO[0000] Creating container: eos-01
INFO[0003] Creating virtual wire: eos-01:eth1 <--> eos-02:eth1
INFO[0003] Running postdeploy actions for Arista cEOS 'eos-02' node
INFO[0003] Running postdeploy actions for Arista cEOS 'eos-01' node
nkalyuzhnyy@ubuntu-desktop:~$ docker logs clab-arista-labs-eos-01
Waiting for all 1 interfaces to be connected
Sleeping 0 seconds before boot
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization docker.
Detected architecture x86-64.
Я добавил эту строку в этот файл /etc/default/grub как описано здесь (пожалуйста, используйте его с осторожностью и убедитесь, что это не влияет на существующие ресурсы на компьютере с Linux)
GRUB_CMDLINE_LINUX_DEFAULT="quiet systemd.unified_cgroup_hierarchy=0"
Обновление - Согласно странице containerlab, начиная с EOS-4.28.0F, ceos-lab автоматически определит, использует ли хост контейнера cgroups v1 или cgroups v2, и будет действовать соответствующим образом. Дополнительная настройка не требуется. Я успешно протестировал это с версией ceos:4.28.10.1M и не столкнулся с какими-либо проблемами.
Продолжайте двигать
Как я уже упоминал ранее, после внесения необходимых изменений я успешно развернул все узлы. После развертывания доступ к ним так же прост, как SSH-подключение к каждому узлу с IP-адресом, именем пользователя и паролем, установленными в значение admin. После этого можно работать как обычно: настройте их так же, как если бы они были физическими устройствами или доступ к ним осуществлялся через EVE-NG.
nkalyuzhnyy@ubuntu-desktop:~/Documents/container_labs$ ssh admin@192.168.100.11
(admin@192.168.100.11) Password:
eos-01>en
eos-01#show run | sec ospf
router ospf 1
network 10.10.100.0/24 area 0.0.0.0
max-lsa 12000
eos-01#show ip ospf neighbor
Neighbor ID Instance VRF Pri State Dead Time Address Interface
192.168.100.12 1 default 1 FULL/DR 00:00:34 10.10.100.12 Ethernet1
eos-01#show ip interface brief
Address
Interface IP Address Status Protocol MTU Owner
----------------- ----------------------- ------------ -------------- ---------- -------
Ethernet1 10.10.100.11/24 up up 1500
Management0 192.168.100.11/24 up up 1500
nkalyuzhnyy@ubuntu-desktop:~/Documents/container_labs$ ssh admin@192.168.100.12
(admin@192.168.100.12) Password:
eos-02>en
eos-02#show ip ospf neighbor
Neighbor ID Instance VRF Pri State Dead Time Address Interface
192.168.100.11 1 default 1 FULL/BDR 00:00:29 10.10.100.11 Ethernet1
eos-02#show ip interface brief
Address
Interface IP Address Status Protocol MTU Owner
----------------- ----------------------- ------------ -------------- ---------- -------
Ethernet1 10.10.100.12/24 up up 1500
Management0 192.168.100.12/24 up up 1500
Уборка
Когда вы закончите работу с лабораторией и захотите ее закрыть, просто запустите containerlab destroy --topo arista.clab.yml. Хотя термин «уничтожение» может показаться радикальным, эта команда просто отключает экземпляры. Вы всегда можете вернуть их обратно без потери своих конфигураций.
Однако, если вы хотите полностью удалить конфигурации, вы можете добавить параметр --cleanup флагом к команде.
Так как же это работает?
За кулисами вот что происходит.
Развертывание узлов
Containerlab получает файл определения топологии, в котором вы указали шесть узлов cEOS и их конфигурации. Затем он запускает шесть контейнеров Docker из образа, который мы импортировали ранее. Если вы запустите docker ps Во время работы лаборатории вы увидите эти контейнеры активными и работающими.
nkalyuzhnyy@ubuntu-desktop:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0966d03d9990 ceos:4.27.12M "bash -c '/mnt/flash…" 9 seconds ago Up 7 seconds clab-arista-labs-eos-06
92e01de6eb7f ceos:4.27.12M "bash -c '/mnt/flash…" 9 seconds ago Up 7 seconds clab-arista-labs-eos-03
216b6741df53 ceos:4.27.12M "bash -c '/mnt/flash…" 9 seconds ago Up 8 seconds clab-arista-labs-eos-01
99dad7af050e ceos:4.27.12M "bash -c '/mnt/flash…" 9 seconds ago Up 8 seconds clab-arista-labs-eos-04
eaa62290fc11 ceos:4.27.12M "bash -c '/mnt/flash…" 9 seconds ago Up 6 seconds clab-arista-labs-eos-02
48594b2e7d2d ceos:4.27.12M "bash -c '/mnt/flash…" 9 seconds ago Up 7 seconds clab-arista-labs-eos-05
Сеть управления
Сеть управления, которую мы определили в файле YAML, облегчается драйвером сети моста Docker. Когда лаборатория создана, Containerlab автоматически создает эту сеть для нас. Вы можете убедиться в этом, выполнив docker network ls, в котором отобразятся все доступные сетевые драйверы. Среди них вы найдете тот, который был создан для нас в Containerlab, под названием 'mgmt', с типом, установленным как 'bridge'.
nkalyuzhnyy@ubuntu-desktop:~$ docker network ls
NETWORK ID NAME DRIVER SCOPE
9aa9e0dc779a bridge bridge local
2e1bfbeb9511 host host local
1adbf4b4c9da mgmt bridge local <<< here
ca338427b662 none null local
451502b7e790 pihole_default bridge local
Проверка моста управления
Если вас интересуют детали этого моста управления, вы можете использовать docker inspect mgmt команда. Эта команда предоставит вам обширную информацию о сети мостов, а также даст представление о ее конфигурации и свойствах. Здесь вы можете увидеть все 6 узлов и их IP-адреса.
[ { "Name": "mgmt", "Id": "1adbf4b4c9da982587ab7c0d956b9a8fa1c1ac57acd5fc617650256727e6fd53", "Created": "2024-03-15T18:31:27.704019477Z", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "192.168.100.0/24" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "0966d03d99902e75ee333e7d28fd238033f02693e1599119c8e89f98aa6ee120": { "Name": "clab-arista-labs-eos-06", "EndpointID": "52c73249e233f396f614af87990536fc13526c6210719c7e3b63709c7d464e7a", "MacAddress": "00:1c:73:0d:d7:66", "IPv4Address": "192.168.100.16/24", "IPv6Address": "" }, "216b6741df534886acfc481d5a3ddb446f0d1c3496c20b43dcfc6adae70e7471": { "Name": "clab-arista-labs-eos-01", "EndpointID": "29578949d0b57a369bc69c273eb0520d2d32c11c6880c1dc09bbae4cabf9aa87", "MacAddress": "00:1c:73:81:4b:52", "IPv4Address": "192.168.100.11/24", "IPv6Address": "" }, "48594b2e7d2dd0cb579e1c48b55850c2bd9fd4cf1086641337c16b1c3b6ff871": { "Name": "clab-arista-labs-eos-05", "EndpointID": "8ed07001f86291be0743cd6b0ca18309d59cfd3f3b88cf0599377f25de5834f0", "MacAddress": "00:1c:73:75:ce:b5", "IPv4Address": "192.168.100.15/24", "IPv6Address": "" }, "92e01de6eb7f89bf8c0ea2cc46ff6327738d9a717359cfaf9d76410c035dad91": { "Name": "clab-arista-labs-eos-03", "EndpointID": "bc76eb211ea028d93959794aff4612d8b3a7ed73484630e5627b7a9633074f5f", "MacAddress": "00:1c:73:2a:f0:1a", "IPv4Address": "192.168.100.13/24", "IPv6Address": "" }, "99dad7af050e69f78d1b3db9eb9ddc945bd0eaf5ef24fc96f54fe860e5247d3c": { "Name": "clab-arista-labs-eos-04", "EndpointID": "5ae7fd3a23c6339c3f86761930f23c9efe5e6b9af408ad2fd900dc47347e7120", "MacAddress": "00:1c:73:ca:3f:d4", "IPv4Address": "192.168.100.14/24", "IPv6Address": "" }, "eaa62290fc1109ff5852c9cee60c5b22c45e8374fb6fecc78c54cc137f18133a": { "Name": "clab-arista-labs-eos-02", "EndpointID": "721ee0dc608c2942c571d5125321022e42afe3bd26402a476753ea32c319f5f8", "MacAddress": "00:1c:73:71:05:89", "IPv4Address": "192.168.100.12/24", "IPv6Address": "" } }, "Options": { "com.docker.network.driver.mtu": "1500" }, "Labels": { "containerlab": "" } } ]
Как видно на схеме ниже, сеть управления (mgmt) доступна только с хост-машины. Это означает, что внешние системы, такие как NMS или серверы системных журналов в вашей сети, не смогут получить доступ к контейнерам, размещенным на хост-машине. Тем не менее, существуют альтернативные сетевые драйверы Docker, которые позволяют интегрировать контейнеры непосредственно с физической сетевой инфраструктурой.
Использование другого сетевого драйвера — это то, что я хотел бы подробнее изучить в своих следующих статьях в блоге. Чтобы быть в курсе событий и узнавать больше о containerlabs, обязательно подпишитесь ниже и следите за моим следующим постом в блоге.
Добавление узлов на основе виртуальных машин
Containerlab также поддерживает добавление узлов на основе виртуальных машин, таких как Palo Alto Firewall, Cisco FTDv, Juniper vMX и т. д. Для этого примера я собираюсь использовать межсетевой экран Palo Alto и коммутатор Junos L2.
Процесс добавления узлов виртуальной машины выполняется vrnetlab, которая упаковывает обычную виртуальную машину в контейнер и делает ее пригодной для запуска, как если бы она была образом контейнера. Вот пример того, как добавить Palo Alto и Junos vSwitch.
Запуск Palo Alto Firewall в ContainerlabВсем привет, в этом коротком сообщении в блоге давайте рассмотрим, как запустить брандмауэры Palo Alto в Containerlab. Если вы давно следите за мной, то наверняка знаете, что я стал чаще использовать Containerlab в своих проектах.
Чтобы начать работу, убедитесь, что вы загрузили соответствующие образы от поставщиков в формате KVM или qcow. После загрузки клонируйте репозиторий vrnetlab отсюда, перейдите в соответствующий каталог поставщика и скопируйте туда загруженное изображение. Например, для Пало-Альто перейдите в каталог Пало-Альто, скопируйте загруженное изображение и запустите make (убедитесь, что у вас установлен make ). Этот процесс может занять некоторое время. Как только это будет сделано, просто создайте файл топологии, и все готово.
nkalyuzhnyy@ubuntu-desktop:~/Documents$ git clone https://github.com/hellt/vrnetlab.git
nkalyuzhnyy@ubuntu-desktop:~/Documents$ cd vrnetlab/pan/
nkalyuzhnyy@ubuntu-desktop:~/Documents/vrnetlab/pan$ ls
docker Makefile PA-VM-KVM-10.1.3.qcow2 README.md
nkalyuzhnyy@ubuntu-desktop:~/Documents/vrnetlab/pan$ make
for IMAGE in PA-VM-KVM-10.1.3.qcow2; do \
echo "Making $IMAGE"; \
make IMAGE=$IMAGE docker-build; \
done
Making PA-VM-KVM-10.1.3.qcow2
make[1]: Entering directory '/home/suresh/Documents/vrnetlab/pan'
rm -f docker/*.qcow2* docker/*.tgz* docker/*.vmdk* docker/*.iso
Building docker image using PA-VM-KVM-10.1.3.qcow2 as vrnetlab/vr-pan:10.1.3
cp ../common/* docker/
make IMAGE=$IMAGE docker-build-image-copy
make[2]: Entering directory '/home/suresh/Documents/vrnetlab/pan'
cp PA-VM-KVM-10.1.3.qcow2* docker/
make[2]: Leaving directory '/home/suresh/Documents/vrnetlab/pan'
(cd docker; docker build --build-arg http_proxy= --build-arg https_proxy= --build-arg IMAGE=PA-VM-KVM-10.1.3.qcow2 -t vrnetlab/vr-pan:10.1.3 .)
[+] Building 352.8s (9/9) FINISHED docker:default
=> [internal] load build definition from Dockerfile sha256:17d0386c2fff30a5b92652bbef2b84639dba9b9f17bdbb819c8d10badd827fdb 27.51MB / 27.51MB
=> => writing image sha256:c5dc6108ea8f787c5a51f6fa8b3cd9d76b5581489aaf9ba171d83c4a46130250 0.0s
=> => naming to docker.io/vrnetlab/vr-pan:10.1.3 0.0s
make[1]: Leaving directory '/home/suresh/Documents/vrnetlab/pan'
nkalyuzhnyy@ubuntu-desktop:~/Documents/vrnetlab/pan$
nkalyuzhnyy@ubuntu-desktop:~/Documents/vrnetlab/pan$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
vrnetlab/vr-pan 10.1.3 c5dc6108ea8f About a minute ago 8.57GB
Ниже приведен пример файла топологии, который создает межсетевой экран palo alto, коммутатор vJunos L2 и узел Alpine.
name: main-labs
mgmt: network: mgmt
ipv4-subnet: 192.168.100.0/24
topology: kinds: paloalto_panos: image: vrnetlab/vr-pan:10.1.3
juniper_vjunosswitch: image: vrnetlab/vr-vjunosswitch:23.2R1.14
linux: image: alpine:latest
nodes: palo-01: kind: paloalto_panos
mgmt-ipv4: 192.168.100.30
j-switch-01: kind: juniper_vjunosswitch
mgmt-ipv4: 192.168.100.31
alpine-01: kind: linux
mgmt-ipv4: 192.168.100.32
links: - endpoints: ["palo-01:eth1", "j-switch-01:eth1"] - endpoints: ["alpine-01:eth1", "j-switch-01:eth2"]
Просмотр топологии
Вот крутая вещь в этом - вы можете легко просмотреть диаграмму/топологию, выполнив одну команду. Вот пример одной из моих лабораторий, в которой есть Juniper Switch и два альпийских узла.
nkalyuzhnyy@ubuntu-desktop:~/Documents/container_labs/common-lab$ sudo containerlab graph -t my-lab.yml
INFO[0000] Parsing & checking topology file: my-lab.yml
INFO[0000] Serving static files from directory: /etc/containerlab/templates/graph/nextui/static
INFO[0000] Serving topology graph on http://0.0.0.0:50080
Заключение
На этом мы заканчиваем вступление. Я хочу глубже погрузиться в использование большего количества лабораторий и поделиться своим опытом здесь, в блоге. Как я уже упоминал ранее, хотя я продолжу полагаться на EVE-NG для более сложных задач, таких как запуск Active Directory, Cisco ISE или нескольких виртуальных машин Palo Alto, containerlab оказывается невероятно полезным для быстрого развертывания лабораторий для тестирования различных протоколов, таких как OSPF или BGP.