엣지 배포를 위한 Docker Swarm 및 Portainer Edge

인포매텍 디지털 » Recursos » 엣지 배포를 위한 Docker Swarm 및 Portainer Edge

Docker Swarm, Portainer, 그리고 엣지 배포를 처음 접할 때는 에이전트, 엣지 에이전트, 메시 라우팅, 오버레이 네트워크, 서로 다른 도시에 있는 VPS 간의 지연 시간 등 복잡한 개념에 혼란스러워지기 쉽습니다. 모두 멋진 기술처럼 들리지만, 막상 설정에 들어가면 방화벽을 과도하게 열지 않고도 명확하고 안정적이며 효율적인 구성이 필요합니다.

다음 내용에서는 이 모든 것이 어떻게 통합되는지에 대한 자세한 설명을 쉬운 스페인어로 제공합니다. Docker Swarm의 기능, 메시 라우팅 작동 방식, Portainer Agent 및 Edge Agent의 역할(표준 및 비동기 모드), 분산 환경 관리 방법(예: 뉴욕과 시애틀에 있는 VPS), 그리고 제한된 디바이스에서도 WebAssembly(Wasm)를 사용하여 엣지에서 Docker를 활용하는 방법 등을 다룹니다.

기본 개념: Docker Swarm, 엣지 컴퓨팅, Portainer

명령어를 다루기 전에, 모든 Docker Swarm 엣지 아키텍처에 공통적으로 적용되는 몇 가지 기본 개념을 이해하는 것이 중요합니다 . 바로 Swarm의 오케스트레이터 역할, 엣지 컴퓨팅의 역할, 그리고 Portainer가 왜 작업을 훨씬 수월하게 만들어주는지입니다.

Docker Swarm 은 여러 Docker Engine(예: 여러 VM 또는 VPS)을 그룹화하여 단일 가상 호스트처럼 관리할 수 있도록 하는 Docker의 기본 클러스터링 모드입니다. 실질적으로 이를 통해 복제된 서비스를 쉽게 배포하고, 노드 간 오버레이 네트워크를 사용하고, 로드 밸런싱을 수행하고, 고가용성을 활용할 수 있습니다.

반면, 엣지 컴퓨팅은 데이터가 생성되는 곳(센서, IoT 장치, 소형 공장 기계, 라우터, 게이트웨이 등)에 더 가까운 곳에서 데이터 처리를 수행하는 것을 의미합니다. 이를 통해 지연 시간을 줄이고 클라우드 대역폭을 절약하며, 연결이 제한적이거나 불안정한 환경에서도 작동할 수 있습니다. Docker는 중간 정도 성능의 장치에서는 잘 작동하지만, 하드웨어 사양이 매우 낮은 환경, 예를 들어 변경 불가능한 Linux 배포판을 사용하는 경우에는 제대로 작동하지 못합니다 .

바로 이 지점에서 Portainer가 유용하게 사용됩니다 . Portainer는 Docker, Swarm, Kubernetes 또는 ACI 환경 관리를 위한 웹 인터페이스와 API를 제공하는 경량 플랫폼입니다. Portainer를 사용하면 단일 호스트에서든 수십 개의 원격 노드에서든 컨테이너, 이미지, 네트워크, 볼륨 및 기타 리소스를 쉽게 관리할 수 있습니다.

원격 환경을 Portainer 서버에 연결하는 방법에는 여러 가지가 있습니다. 기존 Portainer 에이전트, Docker API/소켓 직접 연결, 그리고 표준 또는 비동기 모드의 Portainer Edge 에이전트가 있습니다. 올바른 옵션을 선택하는 것은 깔끔한 설정과 보안 취약점 및 개방형 포트로 가득한 설정 사이의 차이를 만듭니다.

Docker Swarm: 포트, 메시 라우팅 및 서비스 게시

Docker에서 Swarm 모드를 활성화하면 클러스터의 모든 노드가 인그레스 라우팅 메시( ingress routing mesh) 에 참여하게 됩니다 . 간단히 말해, 클러스터의 모든 노드는 해당 서비스에 대한 작업을 실행하고 있지 않더라도 서비스가 공개한 포트로 들어오는 트래픽을 수신할 수 있습니다.

이 모든 것이 제대로 작동하려면 스웜 노드 간에 특정 포트가 열려 있어야 합니다 . 구체적으로 스웜 네트워크 평면은 다음 포트를 사용합니다.

• 포트 7946 TCP/UDP 컨테이너 네트워크 검색을 위해.
• UDP 포트 4789 (구성 가능) VXLAN 기반 수신 네트워크 트래픽용.

또한, 서비스에 공개하는 포트는 해당 서비스를 사용할 외부 리소스( 외부 로드 밸런서, 다른 시스템, 최종 사용자 등)에서 접근 가능해야 합니다. 이러한 트래픽은 모든 노드를 통해 유입되며, 메시 라우팅은 이를 활성 서비스 컨테이너로 리디렉션하는 역할을 담당합니다.

Swarm에서 포트를 게시하려면 해당 옵션을 사용합니다. –게시 서비스를 생성하거나 업데이트할 때 사용하는 매개변수입니다. target 컨테이너의 내부 포트를 나타냅니다. published 라우팅 메시에 노출될 포트를 정의하세요. 공개 포트를 지정하지 않으면 Docker가 각 작업에 임의의 높은 포트를 할당하므로, 어떤 포트가 사용되었는지 확인하려면 작업을 일일이 검사해야 합니다.

게시된 포트(<PUBLISHED-PORT>)는 ~이 있는 곳입니다 Swarm은 서비스를 외부 세계에 노출합니다.컨테이너 포트(<CONTAINER-PORT>컨테이너 내부에서 프로세스가 수신 대기하는 위치입니다. 예를 들어, 외부 포트 8080이 Nginx 서버의 내부 포트 80을 가리키도록 설정하면, 포트 8080으로 노드에 요청을 보내더라도 Swarm은 해당 요청을 활성화된 컨테이너 중 하나로 라우팅하므로 실제 실행 중인 위치에 대해서는 신경 쓸 필요가 없습니다.

메시 라우팅은 노드의 IP 주소와 광고된 포트를 수신합니다. IP 주소가 외부에서 라우팅 가능한 경우 호스트 외부에서 서비스에 접근할 수 있으며, 내부 전용 IP 주소인 경우 호스트 자체 또는 사설 네트워크로 접근이 제한됩니다. 도커 서비스 검사 대상 포트 간의 관계를 언제든지 확인하려면 (TargetPort) 및 출판된 것들(PublishedPort).

TCP 및/또는 UDP 포트를 공개하고 호스트 모드를 사용하십시오.

기본적으로 Swarm에서 포트를 게시하면 다음과 같이 가정됩니다. TCP 프로토콜UDP 포트를 공개하거나 TCP와 UDP를 결합하려면 다음과 같은 긴 구문을 사용해야 합니다. --publish 그리고 키를 조정하세요 protocol a tcp o udp프로토콜을 생략하고 두 가지 모두 게시하면 TCP로 게시됩니다.

당신은 또한 수 스킵 메시 라우팅 소위 말하는 특정 서비스를 사용하기 위해 호스트 모드이 모드에서는 노드의 포트에 접속할 때 다음과 같은 결과를 얻습니다. 만 해당 노드에서 실행 중인 서비스 인스턴스가 있는 경우, 해당 인스턴스로 전달합니다. 이를 위해 다음과 같은 긴 구문을 사용합니다. --publish 그리고 당신은 확립합니다 mode=host아무것도 지정하지 않거나 남겨두시면 mode=ingress메쉬가 사용될 것입니다.

호스트 모드를 사용할 때 예상치 못한 상황을 방지하기 위해 몇 가지 사항을 염두에 두어야 합니다. 서비스 작업이 없는 노드에 액세스하는 경우 해당 포트가 유휴 상태이거나 다른 애플리케이션에서 사용 중일 수 있습니다 . 또한 노드당 여러 복제본을 실행하려는 경우 Docker가 임의의 포트를 할당하도록 하거나 전역 서비스 또는 제약 조건을 사용하여 노드당 단일 복제본으로 제한하지 않는 한 충돌 없이 고정 포트를 사용할 수 없습니다.

규모가 큰 아키텍처에서는 Swarm을 HAProxy 또는 유사한 외부 로드 밸런서 와 결합하는 것이 일반적입니다 . 트래픽 및 관찰 요구 사항에 따라 메시 라우팅을 활용하거나 DNSRR(VIP 없이)을 사용하여 태스크의 IP로 직접 로드 밸런싱할 수 있습니다.

Portainer를 이용한 원격 관리: 에이전트 vs. 엣지 에이전트

Portainer는 원격 Docker 또는 Swarm 환경을 Portainer 서버에 연결하는 여러 가지 방법을 제공하는데 , 이 부분에서 많은 사용자가 혼란스러워합니다. 주요 옵션은 Portainer 에이전트를 사용하는 방법, Docker API/소켓에 직접 연결하는 방법, 또는 Portainer Edge 에이전트(표준 또는 비동기 모드)를 배포하는 방법의 세 가지입니다.

기존 Portainer 에이전트는 Portainer 서버와 관리 대상 호스트가 동일 네트워크에 있거나 최소한 직접 통신할 수 있는 환경을 위해 설계되었습니다. 이 시나리오에서는 서버가 에이전트에 연결되므로 서버에서 에이전트가 실행되는 노드로 포트를 열어야 합니다. 하지만 여러 데이터 센터에 분산된 VPS나 NAT 뒤에 있는 홈 네트워크를 사용하는 경우에는 이러한 포트 개방이 항상 바람직한 것은 아닙니다.

분산 환경에서 가장 안전하고 유연한 대안은 Portainer Edge Agent 입니다 . 이 방식에서는 연결 흐름이 반대로 진행됩니다. 원격 호스트의 Edge Agent가 Portainer 서버에 연결을 설정합니다. Edge Agent는 수신 연결을 항상 열어두는 대신, 주기적으로 서버를 폴링하여 대기 중인 작업을 확인하고 그에 따라 조치를 취합니다.

엣지 에이전트가 제대로 작동하려면 Portainer 서버는 최소한 웹 인터페이스(UI) 포트 (일반적으로 9443 또는 Kubernetes의 경우 30779와 같은 NodePort)를 노출해야 합니다. 또한 표준 모드에서는 터널 포트 (Kubernetes에서 NodePort를 사용하는 경우 8000 또는 30776) 도 필요합니다 . 이 터널은 엣지 에이전트와 서버 간에 안전한 TLS 연결을 생성하여 원격 환경과의 실시간 상호 작용을 가능하게 합니다.

Portainer 공식 설치 가이드에서는 서버가 두 포트 모두에서 수신 대기하도록 이미 구성되어 있지만, 사용자의 환경 방화벽에서 해당 포트가 노출되도록 설정해야 합니다. 또한 Portainer는 특정 최소 시스템 요구 사항을 충족한다고 가정합니다. 이러한 요구 사항에서 크게 벗어나는 경우 추가 조정이 필요하거나 일부 기능이 제한될 수 있습니다.

Docker Swarm 클러스터에서 표준 모드로 실행되는 엣지 에이전트

표준 엣지 에이전트를 사용하여 원격 Docker Swarm 환경을 관리하려면 Portainer에서 다음과 같은 워크플로를 따르는 것이 일반적입니다. Portainer 메뉴에서 환경 섹션(환경 관련 → 환경)을 열고 "환경 추가"를 클릭합니다. 거기에서 "Docker Swarm"을 선택하고 마법사를 시작합니다(마법사 시작).

마법사에서 ' 엣지 에이전트 표준' 옵션을 선택 하고 환경 세부 정보(설명 이름, 에이전트가 연결할 URL, 그룹 옵션 또는 태그 등)를 입력합니다. '추가 설정' 섹션에서는 엣지 에이전트가 새 작업이나 변경 사항을 확인하는 빈도를 조정할 수 있습니다. 기본값은 일반적으로 5초마다이지만, 트래픽을 줄이거나 응답 성을 향상시키려면 수정할 수 있습니다.

기본 필드를 모두 입력했으면 "생성"을 클릭하세요. 환경에 사전 레이블을 지정하거나 자동화 스크립트를 준비하는 경우, 이 단계에서 참여 토큰을 얻어 배포 시 재사용할 수 있습니다. 그러면 Portainer에서 설치 명령을 생성하는 데 필요한 추가 필드를 표시합니다.

다음 단계는 원격 호스트 플랫폼 (Linux 또는 Windows)을 선택하고 , Portainer에서 생성된 명령어를 복사하여 Edge 환경에서 실행하는 것입니다. 이 명령어는 Edge Agent 이미지를 다운로드하고 올바른 토큰과 URL로 구성합니다. 시작되면 새 환경이 Portainer 메인 화면에 새로운 노드로 나타납니다.

유사한 표준 엣지 환경을 추가로 배포해야 하는 경우 "다른 환경 추가"를 사용하여 위의 과정을 반복할 수 있습니다. 모든 엣지 환경 설정을 완료했으면 "계속"을 클릭하여 다른 환경 설정을 진행하거나 "닫기"를 클릭하여 기본 목록으로 돌아갈 수 있습니다.

연결 품질이 낮은 상태에서 비동기 모드로 작동하는 엣지 에이전트

Portainer Edge Agent의 비동기 모드 는 연결이 제한적이거나 비용이 많이 들거나 매우 불안정한 시나리오(모바일 링크( 5G M2M 연결 ), 농촌 지역 연결, 간헐적으로만 연결되는 장치 등)를 위해 설계되었습니다. 이 모드에서는 실시간 대화형 터널이 설정되지 않고, Edge Agent가 구성 가능한 간격으로 Portainer 서버로 상태 스냅샷을 전송합니다.

비동기 방식을 사용하면 원격 환경과 대화형 세션을 열 수는 없지만, 최근 클러스터 상태를 확인 하고 해당 스냅샷을 기반으로 작업을 실행할 수 있습니다. 데이터 사용량이 훨씬 적기 때문에 모든 메가바이트가 중요한 엣지 배포에 이상적입니다.

비동기 모드에서는 엣지 에이전트가 서버에서 UI 포트 (9443 또는 해당 노드 포트)만 열려 있으면 됩니다. 터널 포트 8000은 더 이상 필요하지 않으므로 공용 포트 노출이 더욱 간소화됩니다. Portainer에서 환경을 설정하는 방법은 표준 모드와 매우 유사하며, Docker Swarm 환경 마법사에서 "엣지 에이전트 비동기"를 선택하기만 하면 됩니다.

Edge Async를 추가하려면 환경 → 환경 추가로 이동하여 "Docker Swarm"을 선택하고 마법사를 실행한 다음 "Edge Agent Async"를 선택하고 기본 정보를 입력합니다. "추가 설정"에서 하트비트 빈도 , 환경 스냅샷 업데이트 및 새 명령 확인 간격을 각각 제어하는 ​​Ping, 스냅샷 및 명령 의 세 가지 중요한 간격을 설정할 수 있습니다. 기본적으로 모든 설정은 1분으로 되어 있지만 필요에 따라 조정할 수 있습니다.

표준 모드와 마찬가지로 그룹과 태그를 사용하여 엣지 환경을 분류하고, 환경을 생성하고, 참여 토큰을 획득한 다음, 플랫폼(Linux 또는 Windows)에 맞는 명령어가 생성되면 원격 호스트에서 실행할 수 있습니다. 각 비동기 에이전트는 등록되고, Portainer는 수신된 최신 스냅샷을 기반으로 에이전트의 상태를 표시합니다.

일반적인 시나리오: 서로 다른 지역에 있는 두 개의 VPS와 Portainer 사용

흔히 볼 수 있는 사례는 서로 다른 위치 (예: 하나는 뉴욕, 하나는 시애틀)에 두 개의 VPS를 보유하고 있으며, Docker Swarm 사용 여부와 관계없이 Portainer를 사용하여 이를 관리하고, Prometheus, cAdvisor, Node Exporter와 같은 도구를 설정하여 노드 간에 비공개 내부 트래픽을 사용하려는 경우입니다.

이러한 시나리오에서는 Swarm만으로 충분한지, 아니면 각 VPS에 Portainer Agent나 Edge Agent도 필요한지 궁금할 수 있습니다. Docker Swarm 자체는 노드 간 오케스트레이션 및 오버레이 네트워킹을 제공하므로, 예를 들어 뉴욕 VPS의 Prometheus 인스턴스가 암호화된 오버레이 네트워크를 통해 시애틀의 컨테이너에서 메트릭을 수집할 수 있습니다.

이 맥락에서 Portainer는 필수 사항은 아니지만 서비스, 스택, 볼륨 및 네트워크 관리를 중앙 집중화하는 데 적극 권장됩니다 . 예를 들어 뉴욕의 VPS에 Portainer 서버를 설치하면 시애틀 VPS를 엣지 에이전트로 연결할 수 있습니다. 이렇게 하면 Docker API를 열거나 기존 에이전트처럼 외부에서 접근 가능한 포트를 관리할 필요가 없습니다.

서로 다른 도시에 위치한 Swarm 노드 간의 지연 시간은 일반적 으로 수십 밀리초 수준이며, Prometheus, Node Exporter, cAdvisor와 같이 정기적인 웹 스크래핑을 수행하는 서비스에는 대부분 심각한 문제가 되지 않습니다. 하지만 지연 시간이나 노드 간 일관성에 매우 민감한 서비스를 운영할 경우에는 이 점을 고려해야 합니다.

요약하자면, 이러한 유형의 구성에 가장 일반적이고 실용적인 설정은 Docker Swarm을 클러스터로 사용하고 VPS 간에 오버레이 네트워크를 구축하는 것이며, Portainer Edge Agent (표준 Agent보다 우수함)를 사용하여 불필요한 포트를 열지 않고 원격 VPS를 안전하게 관리하는 것입니다. 모든 장치가 동일 네트워크에 있거나 직접 연결되어 있는 경우에는 기존 Agent가 적합하지만, 지리적으로 분산된 시나리오에서는 Edge Agent가 논리적인 선택입니다.

Docker Swarm의 Portainer에서 엣지 작업 실행

Portainer와 Swarm 환경을 함께 사용할 때 활용할 수 있는 또 다른 강력한 기능은 엣지 작업(Edge Jobs) 입니다 . 이 작업을 통해 Portainer로 관리되는 엣지 환경에서 실행될 작업을 정의할 수 있으며, 이는 유지 관리, 재구성 또는 주기적인 배포에 매우 유용합니다.

자주 제기되는 질문 중 하나는 Swarm 클러스터에서 특정 노드에서 Edge Job을 실행하도록 강제 할 수 있는지 여부입니다 . 대부분의 경우, 작업은 항상 특정 노드에서 실행되는 것처럼 보이며, 어떤 노드에서 실행될지 명확하게 제어할 수 없어 균형 잡힌 동작을 기대하거나 특정 노드를 대상으로 하려는 경우 혼란스러울 수 있습니다.

이를 제어하는 ​​핵심은 Portainer가 작업을 배포하는 방식과 Swarm이 작업 배치를 관리하는 방식을 이해하는 데 있습니다 . 작업이 Edge Agent가 관리하는 노드에서 독립 실행형 컨테이너로 실행되는지, 아니면 Swarm 클러스터 내의 서비스로 실행되는지에 따라 제약 조건이나 Edge Job 구성을 통해 제어할 수 있는 범위가 달라집니다.

기본 설정 상태에서는 노드가 무작위로 선택되는 것처럼 보일 수 있지만, 노드 레이블, 그룹 및 할당 규칙을 조정하여 각 작업이 실행되는 위치를 더 정확하게 결정할 수 있습니다. 이를 위해서는 Portainer 문서를 꼼꼼히 검토하고 스케줄링 패턴을 명확히 이해할 때까지 통제된 테스트를 수행하는 것이 좋습니다.

Portainer at home: Raspberry Pi와 같은 장치를 제어하는 ​​엣지 에이전트

Portainer를 사용하여 가정용 기기나 Raspberry Pi와 같은 소형 호스트를 관리하는 경우 접근 방식이 약간 달라집니다. 이러한 경우 Docker 호스트는 대부분 NAT 뒤에 있는 홈 네트워크에 있으며, 공용 IP 주소가 직접 할당되지 않아 Docker API나 기존 에이전트를 인터넷에 노출하는 것이 불편하고 위험할 수 있습니다.

이러한 맥락에서 많은 사용자는 라즈베리 파이 또는 기타 장치를 제어하기 위해 Portainer Edge Agent를 표준 모드로 선택합니다 . 이렇게 하면 TCP API를 활성화하거나 외부 소켓을 열기 위해 Docker 구성을 수정할 필요가 없습니다. Edge Agent는 포트 포워딩 설정 없이도 NAT를 통과하여 서버에 연결을 설정합니다. 또한 이러한 장치는 OpenMV 및 기타 엣지 애플리케이션을 사용하는 임베디드 비전 프로젝트 에 널리 사용됩니다.

기존 Portainer 에이전트는 Portainer 서버가 에이전트에 직접 연결할 수 있어야 하는데 , CG-NAT가 적용되었거나 ISP에서 제공하는 라우터를 사용하는 가정 네트워크 환경에서는 이것이 항상 가능한 것은 아닙니다. 게다가, 이 방식은 가정 네트워크 외부에서 포트를 열어야 하는데, 강력한 보안 전략이 마련되어 있지 않다면 일반적으로 권장되는 보안 방식이 아닙니다.

반면, Edge Agent를 사용하면 서버의 UI 포트(표준 모드에서는 터널 포트)만 인터넷이나 장치가 위치한 네트워크에서 접근 가능하면 됩니다. Edge Agent가 연결되면 Portainer의 메인 화면("홈")에서 각 장치를 독립적인 환경으로 볼 수 있으며, 그룹과 태그를 사용하여 수십 개의 Raspberry Pi 또는 엣지 장치를 복잡하지 않게 관리할 수 있습니다.

엣지 환경에서 비동기 모드와 표준 모드 비교

Portainer Edge Agent를 선택할 때 중요한 결정 사항 중 하나는 표준 모드와 비동기 모드 중 어떤 모드를 사용할지입니다 . 표준 모드는 호스트가 "거의 로컬"인 것과 매우 유사한 환경을 제공합니다. 컨테이너에서 콘솔 세션을 열고, 실시간 로그를 확인하고, 스택을 대화형으로 배포하는 등의 작업을 수행할 수 있습니다.

반면 비동기 모드는 대역폭 소비를 최소화하고 불안정한 연결 상태를 더 잘 견디는 대신 상호 작용성을 희생합니다 . 상태를 간헐적으로 확인하고 특정 작업을 실행하며 데이터를 절약하려는 환경에서는 비동기 모드가 현명한 선택입니다. 두 경우 모두 Portainer는 그룹 및 태그를 사용하여 환경을 분류하고 관리할 수 있도록 지원합니다.

개방 포트 측면에서 보면, 표준 모드는 UI 포트와 터널 포트 모두 필요 하지만, 비동기 모드는 UI 포트만 필요합니다. 보안이 매우 엄격하거나 노출되는 부분을 최소화하려는 경우, 비동기 모드는 대화형 TLS 터널을 사용할 수 없다는 단점이 있지만 설정이 훨씬 간편해집니다.

엣지 워크로드를 위한 Docker 및 WebAssembly(Wasm)

매우 제한된 장치(소형 ARM, RAM이 부족한 게이트웨이 등)에서 작동하는 엣지 컴퓨팅 영역으로 넘어가면 기존 컨테이너조차 다소 번거로워질 수 있습니다. 바로 이 지점에서 WebAssembly(Wasm)가 등장하는데, WasmEdge나 Wasmtime과 같은 런타임을 통해 Docker와 기본적으로 통합되어 있습니다.

Wasm은 엣지 컴퓨팅에 있어 매우 작은 바이너리 크기, 거의 즉각적인 시작 속도, 그리고 강력한 기능 기반 격리 라는 명확한 장점을 제공합니다 . 또한, Wasm 바이너리가 운영 체제에서 직접 실행되는 것이 아니라 런타임에서 실행되기 때문에 다양한 아키텍처(x86, ARM, RISC-V 등)와의 이식성이 매우 뛰어납니다.

엣지 환경에서 Docker와 함께 Wasm을 사용하려면 다음 버전의 Docker가 필요합니다. Wasm 런타임 지원Docker Desktop 버전 4.15 이상 또는 containerd 1.7 이상이 포함된 Docker Engine에서는 일반적으로 작동합니다. 이 기능을 활성화하려면 다음 단계를 따르세요. daemon.json containerd 이미지 저장소를 지정하고 해당 Wasm 런타임을 선언합니다(예: io.containerd.wasmedge.v1 o io.containerd.wasmtime.v1) 그런 다음 Docker 데몬을 다시 시작하십시오.

대표적인 예로는 소규모 서비스가 있습니다. 센서 데이터 처리 Rust로 작성되었으며 Wasm(타겟)으로 컴파일되었습니다. wasm32-wasi이 프로그램은 JSON 데이터를 한 줄씩 읽고, 특정 온도 또는 습도 임계값을 초과하는 측정값을 필터링하고, JSON 형식으로 알림을 발행할 수 있으며, 이 모든 작업을 매우 낮은 리소스 사용량으로 수행합니다.

WebAssembly로 컴파일되면 사용할 수 있습니다. 최소한의 요소만 담은, 처음부터 작성한 Dockerfile바이너리 파일만 복사 .wasm 그리고 이를 진입점(ENTRYPOINT)으로 선언합니다. 이미지를 생성할 때 docker buildx 플랫폼 wasi/wasm 로컬에서 로드해 보면 결과 크기가 파이썬이나 노드 이미지가 쉽게 1기가바이트에 달하는 것과 달리 불과 몇 메가바이트에 불과하다는 것을 알 수 있습니다.

Docker와 Compose를 사용하여 엣지 환경에 Wasm 배포하기

실제 엣지 아키텍처에서는 일반적으로 디바이스당 여러 서비스가 존재합니다. WASM 기반 센서 프로세서 , 통신을 위한 MQTT 브로커, 시계열 데이터베이스, 경량 리버스 프록시 등이 그 예입니다. Docker Compose는 이러한 모든 서비스를 단일 파일로 묶는 데 매우 적합합니다.

엣지 노드의 예로는 측정값을 처리하는 Wasm 서비스(해당 Wasm 런타임 사용), 센서 데이터를 수신하는 Eclipse Mosquitto 브로커 , 시계열 데이터를 저장하는 TimescaleDB/PostgreSQL 데이터베이스, 그리고 API 또는 대시보드를 노출하는 리버스 프록시 역할을 하는 Caddy를 들 수 있습니다. 각 서비스는 자체 포트, 볼륨 및 상시 재시작 정책을 갖습니다.

유통을 용이하게 하기 위해 일반적으로 다음과 같은 방법을 사용합니다. 엣지 게이트웨이 자체에 로컬 Docker 등록일반적으로 5000번 포트에서 실행됩니다. Wasm 이미지를 패키징할 때 레이블을 해당 방향으로 지정합니다. localhost:5000/... 그런 다음 레지스트리에 푸시합니다. 인근의 다른 에지 노드에서 해당 로컬 레지스트리에서 데이터를 가져올 수 있으므로 원격 레지스트리에 대한 지연 시간과 리소스 소비를 줄일 수 있습니다.

시스템 자원이 매우 제한적인 경우에는 Wasm 자체가 리소스를 거의 소모하지 않더라도 최대 메모리(예: 32MB) 및 CPU 코어 제한(0.5코어 등)을 엄격하게 설정하는 것이 좋습니다 . 이렇게 하면 버그나 부하 급증으로 인해 장치가 멈추고 수동으로 재시작해야 하는 상황을 방지할 수 있습니다.

엣지에서의 네트워크, 스웜 및 연결 끊김 허용 오차

엣지 네트워크는 일반적으로 데이터 센터보다 신뢰성이 떨어 집니다 . 잦은 장애, IP 주소 변경, 모바일 연결 문제 등이 발생하기 때문입니다. 이러한 이유로 각 노드에 사용자 지정 서브넷을 사용하는 전용 브리지 네트워크를 구축하거나, VPN 또는 보안 터널을 통해 연결된 멀티 사이트 스웜을 구축하는 것이 일반적입니다.

Docker를 사용하면 호스트에 고유한 브리지 이름을 가진 격리된 브리지 네트워크를 생성할 수 있습니다(예: edge-br0) 그런 다음 해당 네트워크에 서비스를 연결하여 나머지 트래픽과의 분리를 더욱 강화할 수 있습니다. 한 단계 더 나아가 엣지 게이트웨이에 Docker Swarm을 설정하면 오버레이 네트워크를 사용하여 다음과 같은 작업을 수행할 수 있습니다. 여러 노드 간에 컨테이너를 연결합니다. 클러스터 스토어 및 클러스터 광고 메커니즘(일반적으로 Consul 또는 다른 백엔드에서 사용)을 사용합니다.

Swarm을 사용한 멀티 호스트 시나리오에서 Docker Machine은 OpenNebula를 사용한 몇 가지 배포 사례에서 볼 수 있듯이 여전히 유용한 도구입니다 . 이 경우 Docker Machine과 OpenNebula 드라이버를 사용하여 boot2docker로 VM을 실행하고, 검색을 위한 Consul을 설정하고, Swarm 마스터와 노드를 생성한 다음 오버레이 네트워크를 통해 모든 것을 연결할 수 있습니다.

아이디어는 간단합니다. 먼저 Consul용 VM을 생성하고, 해당 컨테이너를 8500번 포트에서 실행하여 VM을 시작한 다음, VM의 IP 주소를 얻습니다. 그리고 이 IP 주소를 `docker-machine create` 명령에 `--swarm` 및 `--swarm-discovery` 옵션과 함께 사용합니다 . `cluster-store` 및 `cluster-advertise`를 구성하면 오버레이 네트워크를 생성하고 서비스 이름을 사용하여 서로 통신할 수 있는 서비스(예: 한 노드에는 Nginx, 다른 노드에는 BusyBox)를 실행할 수 있습니다.

연결이 자주 끊기는 엣지 환경에서는 연결이 끊어졌을 때 디스크에 데이터를 저장하기 위해 볼륨이나 바인드 마운트를 사용하여 로컬 영구 저장 기능을 활성화하는 것이 좋습니다 ( 데이터 사이버 복원력 ). 이를 통해 컨테이너는 데이터(예: 센서 판독값)를 축적하고 연결이 복구되면 "저장 후 전달" 패턴에 따라 일괄적으로 전송할 수 있습니다.

모니터링 수준에서 Docker는 다음과 같은 간단한 명령어를 제공합니다. docker stats 기본적인 CPU, 메모리 및 네트워크 트래픽 지표를 얻기 위해서입니다. 보다 본격적인 배포 환경에서는 일반적으로 경량 에이전트를 사용합니다. 노드 내보내기 프로메테우스와 함께, "모니터링"을 위한 별도의 docker-compose 파일에 정의되어 호스트 메트릭을 중앙 관찰 가능 생태계에 노출합니다.

Docker를 사용하면 이러한 엣지 배포를 업데이트하는 것도 훨씬 쉬워집니다. 새 이미지를 다운로드하고, 기존 컨테이너를 중지하고, 삭제한 다음, 새 버전으로 서비스를 다시 시작하면 됩니다. 또한 Wasm 컨테이너는 밀리초 단위로 시작되므로 다운타임이 최소화됩니다. 이는 엣지에서 실시간 데이터를 수집할 때 매우 중요한 장점입니다.

이 개요를 통해 각 구성 요소가 어떻게 연결되는지 더욱 명확해집니다. Docker Swarm은 오케스트레이션 및 오버레이 네트워킹을 제공하고, Portainer Edge Agent는 위험한 포트를 열지 않고도 원격 관리를 간소화하며, Wasm은 저사양 하드웨어에서 애플리케이션 실행 비용을 절감합니다 . 포트, 네트워크 및 에이전트 모드(표준 또는 비동기)를 적절히 계획하면 여러 위치에 걸쳐 확장 가능한 견고한 분산형 엣지 아키텍처를 구축하고, 일상적인 관리 부담 없이 확장성을 확보할 수 있습니다.