- Docker Swarm предлага вградено клъстериране, мрежово маршрутизиране и наслагване на мрежи за публикуване на услуги и свързване на контейнери между множество възли.
- Portainer Edge Agent (стандартен или асинхронен) ви позволява да управлявате отдалечени Swarm среди, без да излагате Docker API или да отваряте ненужни портове.
- Edge computing се възползва от Docker и WebAssembly, за да изпълнява леки, сигурни и преносими задачи на ограничен хардуер.
- Чрез комбиниране на Swarm, Portainer и Wasm можете да създавате разпределени, отказоустойчиви и лесни за управление периферни архитектури.
Когато започнете да експериментирате с Docker Swarm, Portainer и edge внедрявания, е лесно да се объркате: агенти, Edge агенти, mesh маршрутизация, наслагващи се мрежи, латентност между VPS в различни градове... всичко звучи страхотно, но когато става въпрос за настройката, искате нещо ясно, стабилно и което не ви принуждава да отваряте половината си защитна стена.
В следващите редове ще намерите подробно обяснение на разбираем испански език за това как всичко това се вписва заедно: какво предлага Docker Swarm, как работи mesh маршрутизацията, каква роля играят Portainer Agent и Edge Agent (в стандартен и асинхронен режим), как да управлявате разпределени среди (например VPS в Ню Йорк и друг в Сиатъл) и как да използвате Docker на периферията, дори с WebAssembly (Wasm) за по-ограничени устройства.
Основни понятия: Docker Swarm, периферни изчисления и Portainer
Преди да започнем да се занимаваме с команди, е важно да разберем някои основни концепции, които са общи за всяка Docker Swarm edge архитектура : Swarm като оркестратор, ролята на edge изчисленията и защо Portainer прави живота толкова по-лесен.
Docker Swarm е вграденият режим на клъстеризация на Docker, който ви позволява да групирате множество Docker Engine-и (например множество виртуални машини или VPS-и) и да ги управлявате така, сякаш са един виртуален хост. На практика това означава, че можете лесно да разгръщате репликирани услуги, да използвате наслагващи се мрежи между възлите, да балансирате натоварването и да се възползвате от високата достъпност.
От друга страна, периферните изчисления включват приближаване на обработката на данни до мястото, където се генерират (сензори, IoT устройства, малки фабрични машини, рутери, шлюзове и др.). Това намалява латентността, спестява трафик към облака и позволява работа дори с ограничена или прекъсваща свързаност. Docker се представя добре на умерено мощни устройства, но се затруднява с много ограничен хардуер - например, когато се използва непроменима Linux дистрибуция .
Тук се намесва Portainer , лека платформа, която предлага уеб интерфейс и API за управление на Docker, Swarm, Kubernetes или ACI среди. Portainer ви позволява лесно да управлявате контейнери, изображения, мрежи, томове и други ресурси, независимо дали на един хост или на десетки отдалечени възли.
За да свържете тези отдалечени среди към вашия Portainer сървър, имате няколко опции: класически Portainer Agent, директна връзка към Docker API/сокет и Portainer Edge Agent в стандартен или асинхронен режим. Изборът на правилната опция е от решаващо значение за чистата конфигурация и такава, пълна с уязвимости в сигурността и отворени портове.
Docker Swarm: портове, мрежово маршрутизиране и публикуване на услуги
Когато активирате режима Swarm в Docker , всички възли в клъстера участват в така наречената ingress routing mesh . По-просто казано, всеки възел в клъстера може да получава трафик на публикуваните портове на услугата, дори ако този конкретен възел не изпълнява никакви задачи за тази услуга.
За да работи всичко това, определени портове трябва да бъдат отворени между възлите на Swarm . По-конкретно, мрежовата равнина на Swarm използва:
- Порт 7946 TCP/UDP за откриване на контейнерна мрежа.
- Порт 4789 UDP (конфигурируем) за входящ мрежов трафик, базиран на VXLAN.
Освен това, портовете, които публикувате за вашите услуги, трябва да са достъпни от външни ресурси, които ще ги консумират : външни балансьори на натоварването, други системи, крайни потребители и др. Този трафик ще влиза през всеки възел и мрежовата маршрутизация ще бъде отговорна за пренасочването му към активен контейнер за услуги.
За публикуване на портове в Swarm се използва опцията. –публикувам При създаване или актуализиране на услуга. Параметърът target показва вътрешния порт на контейнера, докато published Дефинирайте порта, изложен в мрежата за маршрутизация. Ако пропуснете публикувания порт, Docker присвоява произволен висок порт на всяка задача и след това трябва да проверите задачите, за да разберете кой от тях е бил използван.
Публикуваният порт (<PUBLISHED-PORT>) е мястото, където Swarm излага услугата на външния свят, докато контейнерното пристанище (<CONTAINER-PORT>Това е мястото, където процесът слуша в контейнера. Ако например рекламирате външен порт 8080, сочещ към вътрешния порт 80 на Nginx сървър, заявката към произволен възел на порт 8080 ще накара Swarm да насочи заявката към един от активните контейнери, без да се налага да се притеснявате къде всъщност се изпълнява.
Мрежовата маршрутизация слуша IP адреса и рекламирания порт на възела. Ако IP адресът е външно маршрутизируем, услугата ще бъде достъпна отвън на хоста; ако е само вътрешен IP адрес, достъпът ще бъде ограничен до самия хост или неговата частна мрежа. Можете да използвате проверка на услугата на Docker да видите по всяко време връзката между целевите портове (TargetPort) и публикуваните (PublishedPort).
Публикуване на TCP и/или UDP портове и използване на хост режим
По подразбиране, когато публикувате порт в Swarm, се приема, че TCP протоколАко искате да публикувате UDP портове или да комбинирате TCP и UDP, трябва да използвате дългия синтаксис на --publish и регулирайте ключа protocol a tcp o udpАко публикувате и двете и пропуснете протокола, той ще бъде публикуван като TCP.
Можете също така пропускане на мрежовото маршрутизиране за конкретна услуга, използваща т.нар. режим на хостВ този режим, когато осъществявате достъп до порт на възел, достигате само към екземпляра на услугата, работещ на този възел, ако има такъв. За да постигнете това, използвате дългия синтаксис на --publish и вие установявате mode=hostАко не посочите нищо или оставите mode=ingressЩе се използва мрежата.
При хост режим има няколко неща, които трябва да имате предвид, за да избегнете изненади: ако достъпвате възел, където няма сервизни задачи, този порт може да е свободен или зает от друго приложение ; и ако очаквате да изпълнявате множество реплики на възел, няма да можете да използвате статичен порт без конфликти, освен ако не позволите на Docker да присвоява произволни портове или да го ограничите до една реплика на възел, използвайки глобални услуги или ограничения.
В по-големи архитектури е обичайно Swarm да се комбинира с външен балансьор на натоварването като HAProxy или подобен. Можете да направите това, като използвате mesh маршрутизация или DNSRR (без VIP) и балансирате директно към IP адресите на задачите, в зависимост от това кое най-добре отговаря на вашите нужди от трафик и наблюдаемост.
Дистанционно управление с Portainer: Агент срещу Edge Агент
Portainer предлага няколко начина за свързване на отдалечени Docker или Swarm среди към вашия Portainer сървър и тук много хора се объркват. Трите основни опции са: използване на Portainer Agent, директно свързване към Docker API/сокета или внедряване на Portainer Edge Agent (стандартен или асинхронен режим).
Класическият Portainer Agent е предназначен за среди, където Portainer Server и управляваните хостове са в една и съща мрежа или поне могат да комуникират директно. В този сценарий сървърът се свързва с агента, така че трябва да отворите портове от сървъра към възлите, на които работи агентът, което не винаги е желателно, когато се работи с VPS, разпределени в множество центрове за данни или домашни мрежи зад NAT.
Най-сигурната и гъвкава алтернатива в разпределени среди е Portainer Edge Agent . Тук потокът е обратен: Edge Agent на отдалечения хост установява връзката със Portainer Server. Вместо да поддържа отворена входяща връзка, Edge Agent периодично проверява сървъра за чакащи задачи и действа съответно.
За да функционира Edge Agent, Portainer Server трябва да разкрие поне порта на уеб интерфейса (UI) , обикновено 9443 или NodePort, като например 30779 в Kubernetes. Освен това, в стандартен режим, ви е необходим и тунелният порт (8000 или 30776 в Kubernetes с NodePort). Този тунел създава защитена TLS връзка между Edge Agent и сървъра, позволявайки взаимодействие в реално време с отдалечената среда.
Официалните ръководства за инсталиране на Portainer вече конфигурират сървъра да слуша и на двата порта, но ще трябва да се уверите, че защитната стена на вашата среда разкрива тези портове. Portainer също така приема, че отговаряте на определени минимални системни изисквания; ако се отклоните значително от тях, може да се нуждаете от допълнителни корекции или някои функции може да бъдат ограничени.
Edge Agent в стандартен режим на Docker Swarm клъстер
Ако искате да управлявате отдалечена Docker Swarm среда със стандартен Edge Agent , работният процес в Portainer обикновено е подобен на следния: от менюто на Portainer отворете секцията Среди (Свързани със средата → Среди) и кликнете върху „Добавяне на среда“. Там избирате „Docker Swarm“ и стартирате помощника (Стартиране на помощника).
В съветника изберете опцията Edge Agent Standard и попълнете подробностите за средата: описателно име, URL адрес, към който агентът ще се свърже, опции за групиране или етикети и др. В секцията „Още настройки“ можете да регулирате честотата на запитванията , която определя колко често Edge Agent проверява за нови задачи или промени. По подразбиране обикновено е на всеки 5 секунди, но можете да я промените, ако искате да намалите трафика или да подобрите скоростта на реакция.
След като попълните основните полета, щракнете върху „Създаване“. Ако предварително етикетирате среди или подготвяте скриптове за автоматизация, можете да получите токена за присъединяване на този етап, за да го използвате повторно в своите внедрявания. След това Portainer ще покаже допълнителните полета, необходими за генериране на командата за инсталиране.
Следващата стъпка е да изберете платформата за отдалечен хост (Linux или Windows), да копирате командата, генерирана от Portainer, и да я изпълните в Edge средата. Тази команда изтегля образа на Edge Agent и го конфигурира с правилния токен и URL адрес. След като стартира, новата среда се появява на главния екран на Portainer като друг възел.
Ако е необходимо да внедрите друга подобна стандартна Edge среда, можете да използвате „Добавяне на друга среда“ и да повторите процеса. Когато сте готови с всички Edge среди, просто щракнете върху „Продължи“, за да продължите с конфигурирането на други среди, или върху „Затвори“, за да се върнете към главния списък.
Edge Agent в асинхронен режим и с нискокачествени връзки
Асинхронният режим на Portainer Edge Agent е предназначен за сценарии, при които свързаността е ограничена, скъпа или силно нестабилна (мобилни връзки ( 5G M2M свързаност ), селски връзки, устройства, които се свързват само периодично и др.). В този режим не се установява интерактивен тунел в реално време; вместо това, Edge Agent изпраща моментни снимки на състоянието към Portainer сървъра през конфигурируеми интервали.
С async не можете да отваряте интерактивни сесии с отдалечената среда, но можете да видите последното състояние на клъстера и да стартирате действия въз основа на тази снимка. Консумацията на данни е много по-ниска, което го прави идеален за периферни внедрявания, където всеки мегабайт е от значение.
В асинхронен режим, Edge Agent се нуждае само от сървъра да има отворен UI порт (9443 или еквивалентен NodePort). Тунелен порт 8000 вече не е необходим, което допълнително опростява показването на публични портове. Настройката на средата в Portainer е много подобна на стандартния режим; просто избирате „Edge Agent Async“ в съветника за среда на Docker Swarm.
За да добавите Edge Async, отидете на Environments → Add environment (Средини → Добавяне на среда), изберете „Docker Swarm“, стартирайте съветника, изберете „Edge Agent Async“ и попълнете основната информация. В „More settings“ (Още настройки) имате три важни интервала: Ping (Пинг), Snapshot (Моментна снимка) и Command (Команда) , които контролират съответно честотата на пулса, актуализирането на моментната снимка на средата и проверката за нови команди. По подразбиране всичко е настроено на една минута, но можете да го коригирате, ако е необходимо.
Точно както в стандартния режим, можете да използвате групи и етикети, за да категоризирате Edge среди, да създадете средата, да получите токена за присъединяване и, след като командата за вашата платформа (Linux или Windows) бъде генерирана, да я изпълните на отдалечения хост. Всеки асинхронен агент ще се регистрира и Portainer ще може да ви покаже състоянието му въз основа на последната получена снимка.
Типичен сценарий: два VPS-а в различни региони и използване на Portainer
Доста често срещан случай е този на някой, който има два VPS-а на различни места (например един в Ню Йорк и един в Сиатъл) и иска да ги управлява с Portainer, използвайки Docker Swarm или не, и настройвайки неща като Prometheus, cAdvisor и Node Exporter с частен вътрешен трафик между възлите.
В такъв сценарий се чудите дали използването само на Swarm е достатъчно или ви е необходим и Portainer Agent или Edge Agent на всеки VPS. Docker Swarm сам по себе си осигурява оркестрация и наслагване на мрежа между възлите, позволявайки например на Prometheus екземпляр на VPS в Ню Йорк да събира показатели от контейнери в Сиатъл чрез криптирана наслагваща се мрежа.
В този контекст Portainer не е задължителен, но е силно препоръчителен за централизиране на управлението на услуги, стекове, томове и мрежи . Ако настроите Portainer сървър на един от VPS-ите (например в Ню Йорк), можете да свържете VPS-а в Сиатъл с Edge Agent. По този начин не е необходимо да отваряте Docker API или да поддържате външно достъпни портове за класически агенти.
Що се отнася до латентността между възлите на Swarm в различни градове, тя обикновено е в рамките на десетки милисекунди, което в повечето случаи не е сериозен проблем за услуги като Prometheus, Node Exporter или cAdvisor, които извършват редовно извличане на данни. Това обаче трябва да се вземе предвид, ако ще стартирате услуги, които са изключително чувствителни към латентност или съгласуваност между възлите.
В обобщение, най-често срещаната и практична настройка за този тип конфигурация е да се използва Docker Swarm за клъстера и наслагващите се мрежи между VPS-ите, както и да се използва Portainer Edge Agent (по-добър от стандартния Agent) за сигурно управление на отдалечените VPS-и без отваряне на ненужни портове. Класическият Agent има смисъл, когато всичко е в една и съща мрежа или има много директна свързаност; в географски разпределени сценарии Edge Agent е логичният избор.
Edge Jobs в Portainer на Docker Swarm
Друга мощна функция при работа със среди на Portainer и Swarm са Edge Jobs . Тези задачи ви позволяват да дефинирате задачи, които ще се изпълняват във вашите управлявани от Portainer Edge среди, което е много полезно за поддръжка, преконфигуриране или периодични внедрявания.
Повтарящ се въпрос е дали е възможно да се принуди Edge Job да се изпълнява на конкретен възел в клъстера Swarm. В много случаи задачата винаги изглежда се изпълнява на един от възлите и нямате ясен контрол върху това на кой от тях се изпълнява, което може да е объркващо, ако очаквате балансирано поведение или искате да се насочите към конкретен възел.
Ключът към контролирането на това се крие в разбирането как Portainer разпределя задачите и как Swarm управлява разпределението на задачите . В зависимост от това дали задачата се стартира като самостоятелен контейнер на възел, управляван от Edge Agent, или като услуга в клъстера Swarm, ще имате повече или по-малко контрол чрез ограничения или конфигурация на Edge Job.
Въпреки че при предварително настроените настройки може да изглежда, че възелът е избран произволно, можете да експериментирате с етикети на възли, групи и правила за присвояване, за да определите по-добре къде се изпълнява всяка задача. Тук си струва внимателно да прегледате документацията на Portainer и да проведете контролирани тестове, докато не получите ясна представа за модела на планиране.
Портайнър у дома: Edge Agent за управление на устройства като Raspberry Pi
Когато говорим за използване на Portainer за управление на домашни устройства или малки хостове като Raspberry Pi , подходът се променя леко. Тук Docker хостовете много често са зад NAT, в домашни мрежи и без директен публичен IP адрес, което прави неудобно и рисковано да се излага Docker API или класическият Agent на интернет.
В този контекст много потребители избират Portainer Edge Agent в стандартен режим , за да управляват своя Raspberry Pi или други устройства. По този начин не е необходимо да се променя конфигурацията на Docker, за да се активира TCP API или да се отварят открити сокети. Edge Agent, като напомняне, отваря връзката към сървъра, преминавайки през NAT, без да се налага да се занимавате с пренасочване на портове. Освен това, тези устройства често се използват за проекти за вградено зрение с OpenMV и други edge приложения.
Класическият Portainer Agent изисква Portainer Server да може да се свързва директно с агентите , нещо, което не винаги е възможно в домашна мрежа с CG-NAT или рутери, предоставени от интернет доставчик. Освен това, това включва отваряне на портове извън домашната ви мрежа, което обикновено не е най-препоръчителният подход от гледна точка на сигурността, ако нямате надеждна стратегия за защита.
С Edge Agent, от друга страна, е необходимо само сървърът да има достъп до потребителския интерфейс (и в стандартен режим до тунелния порт) от интернет или мрежата, където се намират вашите устройства. След като Edge Agents са свързани, в основния изглед на Portainer („Начало“) виждате всяко устройство като независима среда и можете да използвате групи и етикети, за да организирате десетки Raspberry Pi или edge устройства, без да се налага да се пренастройвате.
Асинхронен режим спрямо стандартен режим в периферни среди
Важно решение при избора на Portainer Edge Agent е дали да работите в стандартен или асинхронен режим . Стандартният режим предлага изживяване, много подобно на това да имате хост „почти локален“: можете да отворите конзолна сесия в контейнери, да преглеждате лог файлове на живо, да разгръщате стекове интерактивно и т.н.
Асинхронният режим, от друга страна, жертва интерактивността, за да минимизира потреблението на честотна лента и да толерира по-добре непостоянните връзки . В среди, където искате само от време на време да проверявате състоянието, да стартирате конкретни задачи и да запазвате данни, асинхронният режим е интелигентният избор. И в двата случая Portainer все още ви позволява да категоризирате и управлявате вашите среди по групи и етикети.
По отношение на отворените портове, стандартният режим изисква както потребителския интерфейс (UI), така и тунелния порт , докато асинхронният режим изисква само потребителския интерфейс. Ако сте на път с висока степен на сигурност или искате да минимизирате откритата повърхност, асинхронният режим значително опростява настройката, но с цената на загуба на интерактивния TLS тунел.
Docker и WebAssembly (Wasm) за периферни натоварвания
Когато преминем към сферата на периферните изчисления на много ограничени устройства (малки ARM процесори, шлюзове с малко RAM и др.), дори традиционните контейнери могат да станат донякъде тромави. Тук се намесва WebAssembly (Wasm), който вече се интегрира нативно с Docker чрез среди за изпълнение като WasmEdge или Wasmtime.
Предимствата на Wasm за периферни изчисления са ясни: много малки двоични файлове, почти мигновено стартиране и силна изолация, базирана на възможности. Освен това, преносимостта между архитектури (x86, ARM, RISC-V и др.) е много висока, защото двоичният файл на Wasm работи в средата за изпълнение, а не директно в операционната система.
За да използвате Wasm с Docker на периферията, ви е необходима версия на Docker, която Поддръжка по време на изпълнение на WasmDocker Desktop версия 4.15 или по-нова, или Docker Engine с container 1.7 или по-нова версия, обикновено работят. Активирането на това в daemon.json хранилището за изображения containerrd и декларирайте съответните Wasm runtime-и (например, io.containerd.wasmedge.v1 o io.containerd.wasmtime.v1) и след това рестартирайте демона на Docker.
Типичен пример е малка услуга от обработка на данни от сензори Написано на Rust и компилирано в Wasm (целеви формат). wasm32-wasiТази програма може да чете JSON данни ред по ред, да филтрира показания, които надвишават определени прагове на температура или влажност, и да издава предупреждения също в JSON, всичко това с нелепо ниска консумация на ресурси.
След като бъде компилиран в WebAssembly, можете да използвате Минималистичен, базиран на scratch Dockerfileкопиране само на двоичния файл .wasm и декларирането му като ВХОДНА ТОЧКА. При създаването на изображението с docker buildx за платформа wasi/wasm И когато го заредите локално, ще видите как полученият размер е само няколко мегабайта в сравнение с изображенията на Python или Node, които лесно достигат гигабайт.
Разгръщане на Wasm на периферията с Docker и Compose
В реалните периферни архитектури обикновено има няколко услуги на устройство: сензорни процесори в WASM, MQTT брокери за комуникация, бази данни с времеви серии, леки обратни прокси сървъри и др. Docker Compose е идеалното решение за обединяване на всичко това в един файл.
Пример за граничен възел може да има Wasm услуга за обработка на показания (използвайки съответната Wasm среда за изпълнение), Eclipse Mosquitto брокер за получаване на данни от сензори, база данни TimescaleDB/PostgreSQL за съхраняване на времеви серии и Caddy като обратен прокси за показване на API или табла за управление. Всяка услуга би имала свои собствени портове, томове и политики за рестартиране „always-on“.
За да се улесни разпространението, е обичайно да се създаде локална регистрация на Docker на самия Edge Gateway, обикновено в порт 5000. Пакетирате вашето Wasm изображение, етикетите към localhost:5000/... и го изпращате към системния регистър. От други близки крайни възли можете да изтегляте от този локален регистър, намалявайки латентността и потреблението на ресурси към отдалечени регистри.
При много ограничени системи е препоръчително да се зададат строги ограничения за ресурсите : максимална памет (например 32 MB) и ограничения за процесора (0.5 ядра и т.н.), дори знаейки, че самият Wasm консумира малко ресурси. Това предотвратява замръзване на устройството поради грешка или пик на натоварване и принуждаване на ръчно рестартиране.
Мрежи, рояк и толерантност към прекъсване на връзката на ръба
В периферията мрежите обикновено са по-малко надеждни, отколкото в център за данни : чести прекъсвания, промени в IP адресите, мобилни връзки и др. Поради тази причина е обичайно да се създават специални мостови мрежи на всеки възел с персонализирани подмрежи или дори да се изграждат множество мрежи, свързани чрез VPN или защитени тунели.
С Docker можете да създавате изолирани мостови мрежи със собствено име на моста на хоста (например, edge-br0) и след това свържете услугите си с тази мрежа, за да постигнете по-голямо отделяне от останалия трафик. Ако направите още една крачка напред и настроите Docker Swarm на edge gateway, можете да използвате наслагващи се мрежи, за да свързване на контейнери между множество възли използвайки механизма за съхранение на клъстери и реклама на клъстери (обикновено на Consul или друг бекенд).
За сценарии с множество хостове със Swarm, Docker Machine остава полезен инструмент, както е демонстрирано от някои внедрявания с OpenNebula . В този случай можете да използвате docker-machine с драйвер на OpenNebula, за да стартирате виртуални машини с boot2docker, да настроите Consul за откриване, да създадете главния сървър и възлите на Swarm и накрая да свържете всичко с наслагващи се мрежи.
Идеята е проста: първо създавате виртуална машина за Consul, стартирате я със съответния контейнер на порт 8500, получавате нейния IP адрес и след това използвате този IP адрес в командите `docker-machine create` с опциите `--swarm` и `--swarm-discovery` . С конфигурирани `cluster-store` и `cluster-advertise` можете да създадете мрежа с наслагване и да стартирате услуги (например Nginx на един възел и BusyBox на друг), които могат да комуникират помежду си, използвайки имена на услуги.
В периферни среди, където често се случват прекъсвания на връзката, е препоръчително да се активира локално запазване, използвайки томове или монтирания, за да се съхраняват данни на диск, когато връзката се загуби ( устойчивост на данни в киберпространството ). Това позволява на вашите контейнери да натрупват данни (например показания на сензори) и да ги изпращат групово, когато връзката се възстанови, следвайки модел „съхранение и препращане“.
На ниво мониторинг, Docker предлага проста команда като docker stats за получаване на основни показатели за процесора, паметта и мрежовия трафик. За по-сериозни внедрявания е обичайно да се използват леки агенти, като например Износител на възел заедно с Prometheus, дори дефинирани в отделен docker-compose за „мониторинг“, които предоставят показателите на хоста на централната екосистема за наблюдение.
Актуализирането на тези edge внедрявания също е по-лесно с Docker: изтегляте новото изображение, спирате стария контейнер, изтривате го и рестартирате услугата с новата версия. И тъй като Wasm контейнерите стартират за милисекунди, времето на престой е минимално, което е безценно, когато edge събира данни в реално време.
С този преглед става по-ясно как частите се съчетават: Docker Swarm осигурява оркестрация и наслагване на мрежи, Portainer Edge Agent опростява дистанционното управление без отваряне на рискови портове, а Wasm намалява разходите за изпълнение на приложения на по-лек хардуер . С правилно планиране на портове, мрежи и режими на агенти (стандартни или асинхронни), можете да изградите стабилни, разпределени edge архитектури на множество места, готови за мащабиране без ежедневните административни главоболия.
