IronFlock Appliance

IronFlock Appliance는 완전한 IronFlock 시스템이 즉시 사용 가능한 상태로 배송되는 사전 구성된 자체 완결형 박스입니다. 관리 대상 기계 옆의 현장에 설치되며, DMZ, VPC, Kubernetes 클러스터가 필요 없습니다.

박스 형태의 IronFlock이라고 생각하시면 됩니다.

대상 사용자

Appliance는 두 가지 주요 대상을 위해 설계되었습니다:

기계 제조업체 및 OEM — 자사 기계와 함께 디지털 서비스를 제공하고자 하는 제조업체입니다. 최종 고객에게 DMZ를 개방하거나 클라우드 인프라를 프로비저닝하도록 요청하는 대신, 제조업체는 자사의 디지털 서비스를 포함한 IronFlock Appliance를 기계 배송의 일부로 함께 제공합니다. 고객은 이를 로컬 네트워크에 연결하기만 하면 바로 작동합니다.
소규모 IT 팀을 보유한 작은 공장 — 전체 Kubernetes 스택을 운영하지 않고 로컬에서 동작하는 턴키 IoT 플랫폼을 원하는 곳입니다. Appliance는 사전 구성된 상태로 도착하여 몇 분 만에 설치되고 모든 데이터를 현장에 보관합니다. 인프라 운영 부담 없이도 소규모 운영 환경에서 완전한 클라우드 배포와 동일한 대시보드, 앱 관리, 디바이스 제어 기능을 제공합니다.

프라이빗 클라우드 배포와의 차이점

Appliance와 프라이빗 클라우드 배포는 모두 IronFlock을 로컬에서 실행합니다. 주요 차이점은 범위와 복잡성입니다:

프라이빗 클라우드는 완전한 IT 설치입니다. 고객의 DMZ 또는 VPC에서 실행되고 고객의 IT 팀이 관리하며, 조직 전반에 걸쳐 다수의 계정과 프로젝트를 지원할 수 있습니다.
Appliance는 소형의 턴키 박스입니다. 사전 구성된 상태로 도착하여 기계 옆 로컬 네트워크에 설치되며, 고객 측 IT 인력의 개입이 필요 없습니다. 제한된 수의 기계를 대상으로 설계되었습니다.

시작하기

자체적인 공장 로컬 IronFlock 인스턴스를 구축하는 데에는 단 몇 분이면 충분합니다. 빈 산업용 PC에서 완전히 동작하는 플랫폼까지 — 3단계, 1개의 명령어, 수동 구성 불필요.

요구 사항

설치 중 인터넷 접속이 가능한 Linux OS가 설치된 산업용 PC(또는 가상 머신).
ARM64 또는 AMD64 아키텍처.
최소 사양: CPU 2코어, 2GB RAM, 24GB 스토리지. 기계에서 수집한 분석 데이터 이력을 저장하려면 훨씬 더 큰 스토리지가 권장됩니다(예: > 500GB).

시간 동기화 (NTP)

설치하기 전에 어플라이언스 호스트가 실제로 도달할 수 있는 시간 서버를 지정하십시오. 시스템 시계는 장식이 아닙니다. TLS 인증서 검증, 주기적인 라이선스 재확인, 원격 접속 토큰, 그리고 기계가 생성하는 모든 데이터 포인트의 타임스탬프가 여기에 의존합니다. 몇 분씩 어긋난 호스트는 인증서 오류와 로그인 실패를 일으키고, 현장에서 실제로 일어난 일과 더 이상 맞지 않는 이력을 남깁니다.

기업 네트워크에서는 운영체제에 기본 설정된 공용 시간 서버에 대개 도달할 수 없습니다. UDP 123 포트의 아웃바운드 NTP가 방화벽에서 차단되기 때문입니다. 눈에 띄는 오류는 없습니다. 호스트가 그저 한 번도 동기화되지 않은 채 어긋나 갈 뿐입니다. IT 부서에 내부 시간 서버를 확인해 호스트에 설정하거나, 아웃바운드 UDP 123을 허용하도록 요청하십시오.

systemd-timesyncd 사용 시 (Debian 및 Ubuntu 기본값):


sudo mkdir -p /etc/systemd/timesyncd.conf.d
sudo tee /etc/systemd/timesyncd.conf.d/corporate.conf > /dev/null <<'EOF'
[Time]
NTP=ntp.your-company.com
EOF
sudo systemctl restart systemd-timesyncd
timedatectl status

chrony 사용 시:


echo "server ntp.your-company.com iburst" | sudo tee -a /etc/chrony/chrony.conf
sudo systemctl restart chrony
chronyc sources

설치 프로그램을 실행하기 전에 timedatectl status가 System clock synchronized: yes를 보고해야 합니다.

가상 머신은 물리 하드웨어보다 빠르게 어긋납니다. 어플라이언스를 가상 머신에서 운영한다면 하이퍼바이저의 게스트 시간 동기화도 켜고, 그래도 게스트 내부에서 NTP를 설정하십시오.

단계

ironflock.com에서 계정을 생성합니다.
Instance Key 생성 — IronFlock UI에서 Profile → Instances를 열고 사용 사례에 맞는 플랜을 선택한 후 새 Instance Key를 생성합니다. 키를 복사합니다.
어플라이언스 호스트에서 설치 프로그램을 실행합니다. 산업용 PC에서 터미널을 열고 다음 명령을 실행하세요. IronFlock 소프트웨어를 다운로드 및 구성하고 스택을 시작하며, 모든 과정이 완전히 자동으로 수행됩니다:
```
# 회사 프록시 환경에 있나요? 실행하기 전에 아래 안내를 참조하십시오.
curl -fsSL https://instance-registry.ironflock.com/dl/appliance/install_ironflock.sh \
  | sudo bash -s -- <your-instance-key>
```
<your-instance-key>를 2단계에서 받은 키로 교체하십시오.

회사 프록시 환경에 있나요? 어플라이언스가 회사 HTTP 프록시를 통해서만 인터넷에 도달할 수 있다면, Docker 데몬이 이미지를 가져올 수 있도록 설치 명령에 프록시를 함께 제공해야 합니다 — 그렇지 않으면 설치가 로그인 단계에서 멈춥니다. 회사 프록시 환경 사용을 참조하십시오.

이것이 전부입니다. 설치 프로그램이 완료되면 어플라이언스는 전체 IronFlock 플랫폼을 부팅하며, 재부팅 시에도 자동으로 다시 시작됩니다.

ironflock.com에서 인스턴스 접근하기

어플라이언스는 완전한 로컬 플랫폼이지만, 이를 사용하기 위해 반드시 공장 네트워크 내에 있어야 하는 것은 아닙니다. 어플라이언스가 인터넷에 연결되어 있고 어플라이언스 계정이 ironflock.com 계정과 연결되어 있는 한(계정 연결 참조), IronFlock 클라우드 UI에서 인스턴스로 직접 전환할 수 있습니다. VPN, 포트 포워딩, 추가 도구가 필요 없습니다.

이는 다음을 의미합니다:

하나의 통합된 UI — 클라우드 프로젝트와 어플라이언스 인스턴스를 단일 브라우저 탭에서 나란히 관리할 수 있습니다.
어디서나 작업 가능 — 운영자, 개발자, 지원 인력이 인터넷을 통해 어플라이언스에 접근할 수 있으며, 모든 프로덕션 데이터와 워크로드는 어플라이언스에 로컬로 유지됩니다.
간편한 다중 사이트 관리 — 여러 공장에 걸쳐 여러 어플라이언스를 운영하는 경우 각각이 ironflock.com 계정에 표시되며 클릭 한 번으로 접근할 수 있습니다.

어플라이언스가 인터넷 연결을 잃으면 로컬에서 계속 실행되며, 공장 네트워크 내부에서는 http://<appliance-host>를 통해 여전히 접근할 수 있습니다. 연결이 복구될 때까지 원격 접근 경로만 일시 중지됩니다.

방화벽 구성

어플라이언스가 제한된 로컬 네트워크에서 실행되는 경우, 클라우드에 도달할 수 있도록 다음 IronFlock 엔드포인트에 대한 아웃바운드 접근을 허용하십시오. 모든 연결은 어플라이언스가 시작하므로, 방화벽에서 인바운드 포트를 열 필요가 없습니다.


instance-registry.ironflock.com:443   # IronFlock 소프트웨어 및 에이전트 다운로드 및 업데이트, AI 어시스턴트 및 SMS 알림
cbw.ironflock.com:443                 # 클라우드에서 어플라이언스 원격 관리
web.ironflock.com:443                 # 라이선스 활성화 및 검증
registry.ironflock.com:443            # 공개 IronFlock Store에서 동기화 시 앱 이미지 가져오기
regauth.ironflock.com:443             # 해당 공개 Store 이미지 가져오기 인증
app.ironflock.com:7000                # 클라우드에서 앱 및 디바이스 사용자 인터페이스 열기 (선택 사항, 프록시 뒤에서는 포트 443)
smtp-proxy.ironflock.com:2525         # 계정 및 알림 이메일 전송 (선택 사항)

registry.ironflock.com 및 regauth.ironflock.com 항목은 공개 IronFlock Store에서 local App Store로 앱을 동기화하는 데 필요합니다. registry.ironflock.com은 앱 이미지를 제공하고 regauth.ironflock.com은 각 가져오기를 인가하는 토큰을 발급하므로 — 둘 다 도달 가능해야 하며, 그렇지 않으면 동기화(및 원격 앱 탐색/설치)가 실패합니다. 어플라이언스가 로컬에서 빌드한 앱만 제공한다면 이 항목들은 생략해도 됩니다. Docker Hub 같은 공개 레지스트리에서 이미지를 가져오는 앱은 동기화 중에 해당 레지스트리에서 복사되므로, 어플라이언스가 그 레지스트리에도 도달할 수 있어야 합니다.

app.ironflock.com 항목은 원격 접근 터널에 사용됩니다. 이 터널을 통해 ironflock.com에서 인스턴스로 작업하는 동안 앱과 디바이스의 사용자 인터페이스에 접근할 수 있습니다. 인터넷에 직접 연결된 어플라이언스는 포트 7000을 사용하며, 회사 프록시 뒤에서는 설치 프로그램이 이를 자동으로 포트 443으로 전환합니다. 이 항목이 차단되어도 눈에 띄는 오류는 발생하지 않습니다 — 해당 인터페이스가 클라우드에서 열리지 않을 뿐이며, 로컬 네트워크에서는 계속 동작합니다. 어플라이언스를 로컬에서만 사용한다면 이 항목은 생략해도 됩니다.

smtp-proxy.ironflock.com 항목은 내장된 IronFlock 이메일 릴레이를 사용하는 경우에만 필요합니다. 자체 SMTP 서버를 구성하면 생략할 수 있습니다.

선택적 접속 대상. AI 어시스턴트는 raw.githubusercontent.com과 cdn.jsdelivr.net에서 모델 및 위젯 메타데이터를 갱신하며, 디바이스 위치의 주소 조회에는 nominatim.openstreetmap.org를 사용합니다. 세 곳 모두 선택 사항입니다. 차단되면 어시스턴트는 내장 데이터를 대신 사용하며, 주소 조회는 사용할 수 없게 됩니다.

시간 동기화는 IronFlock으로 향하는 트래픽이 아니므로 이 목록에 없습니다. 그래도 어플라이언스에는 동작하는 시간 소스가 필요합니다. 시간 서버로 향하는 아웃바운드 **UDP 123**을 허용하거나, 호스트에 내부 시간 서버를 설정하십시오 — 시간 동기화 (NTP)를 참조하세요.

네트워크가 회사 HTTP 프록시를 통해서만 인터넷에 도달하는 경우 회사 프록시 환경 사용을 참조하십시오 — 설치 프로그램이 Docker 데몬을 자동으로 프록시로 향하게 설정할 수 있습니다.

어플라이언스에 연결하는 디바이스

엣지 디바이스는 클라우드가 아니라 어플라이언스에 연결됩니다. 디바이스가 어플라이언스와 다른 네트워크 세그먼트에 있는 경우, 디바이스 네트워크가 다음 포트에서 어플라이언스 호스트에 도달할 수 있도록 허용하십시오:


<APPLIANCE_HOST>:18080   # 디바이스 연결(WebSocket) — 필수
<APPLIANCE_HOST>:15001   # local App Store 레지스트리(앱 이미지 가져오기) — 필수
<APPLIANCE_HOST>:15002   # 레지스트리 인증(이미지 가져오기 토큰), 디바이스 에이전트 업데이트 및 디바이스 설치 프로그램 — 필수
<APPLIANCE_HOST>:7000    # 디바이스 UI 원격 접근(선택적 터널 기능)

이 연결들은 직접 연결입니다 — 회사 HTTP 프록시를 통해 라우팅되어서는 안 됩니다. 디바이스의 네트워크가 모든 트래픽을 프록시를 통해 강제로 보내는 경우, 디바이스에서 어플라이언스 호스트를 프록시 예외로 지정하거나, 어플라이언스를 회사 인증서를 사용하는 HTTPS로 전환하십시오: 이 모드에서는 모든 디바이스 트래픽 — 디바이스 연결, 이미지 가져오기, 에이전트 업데이트, 그리고 원격 접근 터널 — 이 **도메인의 단일 프록시 친화적 포트인 443**으로 이동하며, 포트별 예외 없이 회사 프록시와 엄격한 방화벽을 통과하여 작동합니다.

포트 15002는 디바이스 에이전트 업데이트와 디바이스 설치 프로그램에도 사용됩니다. 어플라이언스에 연결된 디바이스는 에이전트 업데이트를, 새 디바이스는 설치 프로그램을 인터넷이 아니라 어플라이언스 자체에서 다운로드합니다 — 도메인 모드에서는 대신 https://registry.<APPLIANCE_DOMAIN>/dl에서 포트 443을 통해 받습니다. 디바이스 에이전트 업데이트와 인터넷에 접근할 수 없는 디바이스 등록을 참조하세요.

디바이스는 일반 운영에 인터넷 접근이 필요하지 않습니다. 연결된 디바이스의 모든 트래픽 — 디바이스 링크, 앱 이미지, 에이전트 업데이트, 원격 접근 — 은 어플라이언스로 향합니다. 디바이스가 인터넷에 접근하는 경우는 다음뿐입니다: 베이스 이미지가 공개 레지스트리에 있는 Dockerfile로 앱을 빌드할 때, 공개 이미지를 사용하는 앱을 게시할 때, Docker 자체를 아직 설치해야 할 때, 그리고 FlockOS를 실행하는 디바이스가 instance-registry.ironflock.com에서 운영체제 업데이트를 확인할 때입니다. 배포하는 앱에는 별도의 네트워크 요구 사항이 있을 수 있습니다.

IronFlock 호스트의 네트워크 ID

어플라이언스와 모든 엣지 디바이스는 IronFlock을 무인 시스템 서비스로 실행합니다. 부팅 시 시작되어 누가 로그인해 있든 없든 항상 연결을 유지합니다. 따라서 이러한 호스트에 대한 방화벽 및 프록시 규칙은 머신을 기준으로 설정해야 하며, 그 머신에 마침 로그인해 있는 사람을 기준으로 해서는 절대 안 됩니다. 엣지 디바이스의 경우 어떤 플랫폼에 연결하든 마찬가지이며, 디바이스 가이드의 ID 인식 방화벽 및 프록시에서 자세히 다룹니다.

이는 주소 대신 디렉터리 ID를 기준으로 접근을 허용하는 ID 인식 방화벽 또는 프록시가 있는 네트워크에서 특히 중요합니다. IronFlock 호스트를 허용하는 규칙이 사용자에 연결되어 있으면, 해당 사용자의 세션이 만료될 때마다 호스트가 접근 권한을 잃습니다. 이미 열린 연결은 계속 동작하지만 새 연결은 모두 조용히 폐기되므로, 호스트는 다음에 연결해야 할 때까지 정상으로 보입니다. 그때 앱 설치, 에이전트 업데이트 또는 재연결이 실패하고, 다음 재시작 이후에는 디바이스가 오프라인 상태로 남습니다.

ID 기반 적용에서 예외를 둘 필요는 없습니다. 네트워크 팀에 각 호스트를 실제로 가진 ID로 식별하도록 요청하십시오:

호스트	규칙에 사용할 ID
도메인에 가입된 Windows 엣지 디바이스	해당 디바이스의 컴퓨터 계정 — 컴퓨터 개체 또는 IronFlock Edge Devices 같은 그룹
그 밖의 모든 엣지 디바이스(Linux, FlockOS, 도메인에 가입되지 않은 Windows)와 어플라이언스	예약된 IP 주소를 가진 이름이 지정된 호스트 객체, 또는 네트워크 접근 제어(802.1X 또는 MAC 인증)가 할당하는 ID
인증 프록시를 통한 어플라이언스의 인터넷 접근	어플라이언스 전용 서비스 계정 — 프록시 인증 참조

주요 제품별 적용 방법:

Check Point Identity Awareness: Access Role에서 사용자 대신 머신(컴퓨터 개체 또는 그룹)을 선택하십시오. 머신 ID는 컴퓨터 자체의 도메인 활동으로 갱신됩니다. 게이트웨이에서 머신 ID가 만료될 수 있다면 대신 네트워크 객체를 사용하십시오.
Palo Alto Networks User-ID: 컴퓨터 계정은 IP-사용자 매핑을 생성하지 않으므로, 주소 객체, 태그 또는 Device-ID를 사용하십시오.
Fortinet FSSO 및 유사한 디렉터리 기반 방화벽: 호스트에 대한 주소 객체, 또는 네트워크 접근 제어가 할당하는 동적 주소를 사용하십시오.
Zscaler, Prisma Access 및 기타 클라우드 보안 게이트웨이: 어플라이언스의 주소를 서버 또는 IoT 위치(신뢰할 수 있는 소스)로 등록하여, 트래픽이 사용자가 아닌 위치로 식별되도록 하십시오.

장애 식별하기. 디바이스가 온라인 상태를 유지하고 ping과 기존 세션은 계속 동작하는데 새 연결 — 이미지 가져오기, 레지스트리 로그인, 재연결 — 이 모두 실패한다면, 원인은 디바이스가 아니라 만료된 ID 규칙에 있습니다. 디바이스에서 새 연결이 다시 성공할 때까지 에이전트를 재시작하지 마십시오. 아직 열려 있는 세션이 유일하게 동작하는 연결입니다.

라이선스 라이프사이클

라이선스는 하나의 물리적 어플라이언스에 종속됩니다. 동일한 라이선스로 서로 다른 하드웨어에서 두 번째 IronFlock 인스턴스를 동시에 실행할 수 없습니다. 일상적인 운영에서 어플라이언스는 오프라인으로 동작합니다 — 프로덕션 데이터, 대시보드, 앱 관리, 엣지 디바이스 제어가 모두 박스 내부에 로컬로 유지됩니다.

어플라이언스가 인터넷을 필요로 하는 시점

인터넷 연결은 다음과 같은 경우에만 필요합니다:

최초 설치 및 어플라이언스 업데이트 — 어차피 IronFlock 배포 서버에서 소프트웨어를 가져와야 하므로 필요하며, 같은 단계에서 라이선스가 활성화됩니다.
주기적 라이선스 재확인 — 플랜에 따라 다릅니다:
- 월간 라이선스: 30일마다 한 번.
- 연간 라이선스: 365일마다 한 번.
- 영구 라이선스: 주기적 재확인 없음 — 설치 및 업데이트 시에만 인터넷이 필요합니다.
새 하드웨어로의 라이선스 이전 (아래 참조).
AI Multi Agent 서비스 — 실제로 사용 중인 동안에만 필요합니다.

유예 기간 및 잠금

주기적 재확인이 클라우드에 도달하지 못하는 경우(네트워크 장애, 일시적인 클라우드 오류), 어플라이언스는 7일의 유예 기간에 진입합니다. 유예 기간 동안 어플라이언스는 정상적으로 계속 실행되며 자동으로 재시도합니다.

7일이 모두 지나도 재확인이 성공하지 못하면, 어플라이언스는 스스로 잠깁니다: 대부분의 작업이 거부되고 UI에 라이선스가 유효하지 않은 것으로 표시됩니다. 복구하려면 어플라이언스의 인터넷 연결을 복원한 다음, 어플라이언스 UI(로컬 http://<appliance-host> 화면 또는 ironflock.com을 통해 접근하는 인스턴스)의 프로필 내 라이선스 패널에서 지금 재검증을 클릭하십시오.

새 하드웨어로 라이선스 이전 (핸드오버)

라이선스는 하나의 머신 하드웨어 지문에 바인딩됩니다. 다른 머신으로 옮기려면 IronFlock 클라우드 프로필에서 핸드오버를 시작합니다:

ironflock.com에서 Profile → Instances를 엽니다.
이전하려는 인스턴스에서 하드웨어 지문 재설정을 클릭합니다.

핸드오버를 위해서는 현재 바인딩된 어플라이언스가 온라인 상태여야 합니다. 클라우드가 해당 어플라이언스로 다시 연결하여 로컬 측에서 스스로 폐기하도록 요청한 후에야 클라우드 측 지문을 해제합니다. 이 핸드셰이크는 새 어플라이언스가 바인딩되는 동안 기존 어플라이언스가 계속 실행될 수 없도록 보장하여 동일 라이선스의 우발적 이중 사용을 방지합니다.

해제가 성공하면:

동일한 인스턴스 키를 사용하여 시작하기 단계에 따라 새 하드웨어를 설정합니다.
새 어플라이언스가 검증되어 자체 지문을 바인딩하고 활성 디바이스가 됩니다.

기존 하드웨어가 고장났거나 접근할 수 없는 경우

이전에 바인딩된 어플라이언스가 죽었거나 그 외의 이유로 도달할 수 없는 경우 핸드셰이크가 타임아웃되며 클라우드 UI에 appliance_unreachable_contact_support가 표시됩니다. 이 경우 IronFlock 팀에 문의하십시오 — 소유권을 확인한 후 바인딩을 수동으로 해제해 드릴 수 있습니다.

팁: 기존 하드웨어가 아직 온라인 상태일 때, 즉 폐기하기 전에 핸드오버를 트리거하십시오. 기존 어플라이언스에 여전히 접근할 수 있을 때 프로세스가 훨씬 빠르며 — 사용자와 저희 지원팀 모두에게 그렇습니다.

로컬 운영

어플라이언스를 온라인 상태로 유지하지 않으려는 경우에도, 동일 로컬 네트워크상의 브라우저에서 어플라이언스의 IP 주소 또는 호스트네임으로 언제든지 접근할 수 있습니다:


http://<appliance-host>

기본 자격 증명으로 로그인하십시오:

사용자 이름: admin
비밀번호: ironflock

첫 로그인 시 admin 자격 증명을 변경하는 것을 잊지 마십시오.

앱 웹 UI

연결된 디바이스의 앱이 웹 인터페이스를 노출하면, 어플라이언스는 내장 터널을 통해 이를 접근 가능하게 만듭니다. 기본 상태에서는 회사 IT에서 필요한 것이 아무것도 없습니다 — 각 앱 UI는 어플라이언스 주소의 자동으로 할당된 포트에서 일반 HTTP로 게시되며(http://<appliance-host>:<port>), IronFlock UI에 해당 링크가 표시됩니다. 접근은 여전히 어플라이언스 로그인으로 보호됩니다.

공유 회사 네트워크에서 신뢰할 수 있는 https:// URL이 필요한 경우 — 회사 CA의 와일드카드 인증서 또는 TLS를 종단하는 리버스 프록시 사용 — 앱 UI 및 HTTPS를 참조하십시오.

계정 연결

어플라이언스의 프로젝트 설정에서 팀원을 이메일로 초대하여 로컬 사용자 계정을 생성합니다. 초대 이메일에는 초대받은 사람에게 필요한 모든 것이 포함되어 있습니다:

개인 연결 링크 — ironflock.com에서 이 링크를 열면 초대받은 사람의 ironflock.com 계정이 어플라이언스에 연결됩니다. 아직 ironflock.com 계정이 없다면 먼저 초대받은 이메일 주소를 사용하여 계정을 생성합니다(두 이메일 주소가 일치하는 경우에만 연결이 허용됩니다). 연결이 완료되면 어플라이언스가 해당 사용자의 ironflock.com 프로젝트 선택기에 표시되며 즉시 원격으로 작업할 수 있습니다 — 수동 키 입력도, 로컬 가입도 필요 없습니다.
로컬 가입 링크 — 선택 사항: 로컬 가입을 완료하면 추가로 어플라이언스 UI(http://<appliance-host>)에 직접 로그인할 수 있습니다.

알아두면 좋은 사항:

기존 로컬 사용자는 프로젝트 소유자의 새 초대가 필요 없습니다. 어플라이언스 UI에서 자신의 프로필을 열고 ironflock.com에 연결 섹션에서 연결 링크를 이메일로 보내기를 클릭하면 됩니다.
재발송: 동일한 이메일 주소를 다시 초대하면(또는 프로필의 버튼을 다시 클릭하면) 새 연결 링크가 발급됩니다. 가장 최근 이메일에 포함된 링크만 유효합니다.
어플라이언스가 이메일을 보낼 수 없는 경우 — 예를 들어 메일 릴레이를 차단하는 제한된 회사 네트워크의 경우 — 연결 링크가 대신 UI에 직접 표시됩니다. 초대한 사람이 링크를 복사하여 원하는 채널로 전달하면 됩니다. 링크는 인터넷에 접속 가능한 브라우저에서 열어야 합니다.
연결 해제: 사용자는 ironflock.com의 Profile → Instances → 연결된 인스턴스에서 언제든지 연결을 제거할 수 있습니다. 가장 최근의 연결 링크를 다시 열면 연결이 복원됩니다.

인스턴스 소유자 — ironflock.com에서 Instance Key를 생성한 사용자 — 는 인스턴스의 로컬 admin 계정에 자동으로 연결되므로, 소유자에게는 초대가 필요하지 않습니다.

엣지 디바이스 추가

추가 엣지 디바이스(즉, 산업용 PC)를 사용하면 더 많은 기계에 IronFlock 앱을 배포하고 어플라이언스의 앱 운영 부하를 분산시킬 수 있습니다. 어플라이언스 자체도 이미 엣지 디바이스로 동작하지만, IronFlock 클라우드에서 엣지 디바이스를 배포하는 것과 동일한 방식으로 더 많은 엣지 디바이스를 연결할 수 있습니다. Project Settings -> Devices -> New Device로 이동하여 안내를 따르십시오.

유지 관리

어플라이언스의 IronFlock 시스템을 업데이트하려면, 새 버전이 제공될 때마다 admin이 자신의 프로필 라이선스 섹션에 있는 업데이트 버튼을 사용할 수 있습니다. 업데이트를 다운로드하려면 어플라이언스에 인터넷 연결이 필요합니다. 업데이트가 완료되면 IronFlock이 자동으로 재시작됩니다.

Linux OS 업데이트의 유지 관리는 사용자의 책임입니다.

디바이스 에이전트 업데이트

어플라이언스에 연결된 엣지 디바이스는 IronFlock 디바이스 에이전트의 업데이트를 어플라이언스 자체에서 받습니다. 디바이스는 instance-registry.ironflock.com에 접속하지 않으며, 업데이트를 위해 인터넷 접근이 필요하지 않습니다:

단순 모드(IP): http://<appliance-host>:15002/dl — 디바이스가 레지스트리 토큰에 이미 사용하는 것과 같은 포트입니다.
도메인/TLS 모드: https://registry.<appliance-domain>/dl(포트 443).

어플라이언스는 에이전트 바이너리의 로컬 미러를 유지하며, 이를 https://instance-registry.ironflock.com(이미 방화벽 허용 목록에 포함됨)에서 6시간마다 갱신합니다. 설정 → 라이선스/어플라이언스 → 디바이스 에이전트 업데이트 → 지금 동기화에서 수동으로 갱신할 수도 있습니다. 어플라이언스의 미러는 IronFlock 클라우드에서도 갱신할 수 있습니다. 인스턴스를 열 필요도, 어플라이언스 자체에 로그인할 필요도 없습니다. 클라우드 Studio에서 Profile → Instances로 이동하면 소유한 모든 어플라이언스에 디바이스 에이전트 업데이트 열이 있어, 해당 미러가 현재 디바이스에 제공하는 에이전트 버전(그 아래에 디바이스 설치 프로그램 버전)이 표시되며 같은 칸에서 지금 동기화를 실행할 수 있습니다. 미러는 클라우드의 릴리스 매니페스트를 따릅니다. 클라우드 매니페스트가 현재 참조하는 모든 에이전트 버전이 모든 Linux 대상과 Windows에 대해 보관되며, 각 버전은 어플라이언스에 완전히 갖춰진 뒤에야 디바이스에 제공됩니다. 클라우드가 게시한 버전이 어플라이언스에 아직 완전히 갖춰지지 않았다면 디바이스에는 계속 이전 버전이 보입니다.

디바이스는 업데이트 위치를 .flock 파일(update_url)에서 얻으며, 에이전트 버전 0.21.2부터는 매 하트비트마다 어플라이언스로부터도 받습니다. 따라서 어플라이언스 IP가 바뀌거나 도메인 모드로 전환하면 디바이스에 자동으로 전파됩니다.

이 기능 이전에 프로비저닝된 디바이스가 아직 이전 버전의 에이전트를 실행 중이라면 .flock 파일을 한 번 다시 다운로드해야 합니다. Windows의 경우: reagent 서비스를 중지하고, %ProgramData%\IronFlock\Reagent\device.flock을 새 파일(BOM 없이 저장)로 교체한 다음 서비스를 다시 시작하세요.

인터넷에 접근할 수 없는 디바이스 등록

어플라이언스는 디바이스 설치 프로그램(ironflock-init)과 그 설치 스크립트도 미러링하므로, 어플라이언스에만 접근할 수 있는 새 엣지 디바이스도 등록할 수 있습니다. 프로젝트 설정 → 디바이스 → 새 디바이스에 표시되는 명령은 이미 어플라이언스를 가리킵니다 — 단순 모드(IP)에서는 http://<appliance-host>:15002/dl/..., 도메인 모드에서는 https://registry.<appliance-domain>/dl/...입니다.

Linux: 한 줄 명령은 curl -sSL <base>/reswarmify/install.sh | IRONFLOCK_DL_BASE=<base> bash 형태입니다. 그런 다음 디바이스의 .flock 파일을 복사하고 sudo ./ironflock-init -c <file>.flock을 실행합니다. ironflock-init은 다운로드 기준 주소를 .flock 파일에서 가져오며, --download-base로 재정의할 수 있습니다.
Windows: <base>/re-agent/windows/amd64/latest/reagent.exe에서 reagent.exe를 다운로드하고 디바이스 연결에 설명된 대로 서비스를 설치합니다.

인터넷에 접근할 수 없는 디바이스의 전제 조건: Docker(Engine + Compose 플러그인)와 기본 패키지가 이미 설치되어 있어야 합니다. 어플라이언스는 IronFlock 자체 바이너리만 미러링하며 배포판 패키지는 미러링하지 않습니다 — ironflock-init은 Docker가 없을 때만 get.docker.com에 접근을 시도합니다.

설치 프로그램 저장소는 에이전트 미러와 함께 갱신됩니다 — 같은 6시간 주기이며, 같은 지금 동기화 버튼을 사용합니다.

사용자 지정 이메일 발신자 (SMTP)

기본적으로 계정 확인, 비밀번호 복구, 초대, 알람 알림을 포함한 모든 플랫폼 이메일은 IronFlock 클라우드 SMTP 프록시를 통해 전달되며 no-reply@ironflock.com으로 표시됩니다. 이메일이 회사에서 보낸 것처럼 표시되도록 하려면 어플라이언스를 자체 SMTP 서버로 연결할 수 있습니다.

어플라이언스 호스트에서 설치 프로그램이 생성한 환경 파일 /opt/ironflock/.env를 편집하고 다음 변수를 설정합니다:


SMTP_CONNECTION_URI=smtps://USERNAME:PASSWORD@smtp.your-company.com:465/
SMTP_FROM_ADDRESS=no-reply@your-company.com
SMTP_FROM_NAME=Your Company

암묵적 TLS의 경우 smtps://(일반적으로 포트 465)를, STARTTLS의 경우 smtp://(포트 587)를 사용하십시오.
사용자 이름 또는 비밀번호의 특수 문자는 URL 인코딩해야 합니다 (예: @ → %40).
SMTP_FROM_ADDRESS와 SMTP_FROM_NAME은 수신자가 각 플랫폼 이메일의 보낸 사람 헤더에서 보게 되는 값입니다.

스택을 재시작하여 변경 사항을 적용합니다:


sudo systemctl restart ironflock.service

재시작 후 모든 인증 이메일, 플랫폼 알림 및 알람 이메일은 회사의 발신자 주소와 표시 이름을 사용하여 자체 SMTP 서버를 통해 전송됩니다.

SMTP_CONNECTION_URI가 설정되지 않은 경우, 어플라이언스는 라이선스 키로 인증된 IronFlock 클라우드 SMTP 프록시를 통해 계속 이메일을 라우팅합니다 — 추가 설정은 필요 없지만, 이메일에는 IronFlock 브랜딩이 표시됩니다.

박스에 포함된 것

Appliance는 모든 IronFlock 서비스가 사전 설치 및 사전 구성된 상태로 배송됩니다:

로컬 네트워크에서 접근 가능한 IronFlock UI
오프라인 앱 배포를 위한 local App Store
Board Studio, Alarms, Data Store
AI Multi Agent 시스템(인터넷에 연결된 경우에만 작동)

엣지 디바이스와 서버의 통합

Appliance는 단순히 IronFlock 플랫폼을 실행하는 것에 그치지 않고, IronFlock 컨텍스트 내에서 엣지 디바이스로도 동시에 동작할 수 있습니다. 즉, 다른 관리 대상 디바이스와 마찬가지로 컨테이너화된 앱을 실행하면서, 동시에 같은 네트워크상의 다른 디바이스를 위한 중앙 관리 노드 역할도 수행합니다. 이로써 단일 박스 안에 플랫폼 서버와 엣지 컴퓨팅이 함께 담긴 소형의 완전한 솔루션이 됩니다.

Appliance는 다른 모든 관리 대상 엣지 디바이스와 동일한 IronFlock 디바이스 에이전트를 실행하므로, 에이전트의 연결성 및 복원력 보호 기능 또한 함께 누릴 수 있습니다 — 무기한 자동 네트워크 재연결, 디스크가 가득 찰 때 박스를 도달 가능 상태로 유지하고 자동으로 복구하는 저장 공간 비상 상태, 메모리 부족 보호, 그리고 자가 재시작 에이전트가 그것입니다. 이는 Appliance — 그리고 그에 대한 사용자의 원격 접근 — 가 로컬 네트워크, 디스크, 메모리 문제를 겪는 와중에도 온라인 상태를 유지하는 핵심적인 이유입니다.

아키텍처

하드웨어

Appliance 하드웨어는 협의 가능하며, 일반적으로 OEM 또는 기계 제조업체가 제공합니다. IronFlock은 소프트웨어 스택을 제공하고 배송 전에 선택된 하드웨어에 시스템을 사전 구성합니다. 일반적으로 중간 규모의 산업용 엣지 PC(4코어, 8GB RAM)면 전체 스택과 추가 애플리케이션을 실행하기에 충분합니다. 사용 사례에 맞는 하드웨어 요구 사항을 논의하려면 IronFlock 팀에 문의하십시오.

온라인 스토어에서 앱 동기화

Appliance에는 로컬 네트워크상의 디바이스에 앱을 제공하는 프라이빗 앱 카탈로그 및 컨테이너 레지스트리인 local App Store가 포함되어 있습니다. 동기화 시점에 Appliance가 인터넷에 연결되어 있다면 공개 온라인 IronFlock Store에서 앱을 동기화하여 이 로컬 스토어를 채울 수 있습니다. 영구적인 인터넷 연결은 필요하지 않으며, 필요한 앱을 가져오기 위한 일시적인 연결만으로도 충분합니다.

사전 요건

공개 ironflock.com 플랫폼의 계정.
어플라이언스 계정이 ironflock.com 계정과 연결되어 있어야 합니다(계정 연결 참조). 인스턴스 소유자의 admin 계정은 자동으로 연결됩니다.

앱 동기화 작동 방식


┌────────────────────┐                       ┌────────────────────┐
│  Online IronFlock  │  ◄──── account ─────► │  Appliance         │
│  Store (cloud)     │      connection       │  local Store       │
└────────────────────┘                       └────────────────────┘
         │                                            │
   apps available to                          sync button shown
   the connected account                      instead of install

local App Store 열기 — Appliance에 활성 인터넷 연결이 있는 경우, App Store에는 연결된 ironflock.com 계정이 온라인 플랫폼에서 사용할 수 있는 모든 앱이 표시됩니다.
필요한 앱 동기화 — 각 앱에는 Install 버튼 대신 Sync 버튼이 표시됩니다. 이를 클릭하면 컨테이너 이미지와 메타데이터를 포함한 앱이 온라인 스토어에서 로컬 스토어로 다운로드됩니다.
디바이스 추가 — 동기화가 완료되면 앱은 로컬 스토어에서 완전히 사용 가능해지며, 인터넷 연결 없이도 평소처럼 디바이스를 추가할 수 있습니다.

업데이트 워크플로

동기화된 앱의 새 버전이 온라인 스토어에 게시되면 해당 앱에 다시 Sync 버튼이 나타납니다. Appliance를 잠시 인터넷에 연결하여 업데이트된 릴리스를 동기화한 다음, 표준 앱 업그레이드 플로우를 통해 디바이스에 롤아웃하십시오.

이러한 설계는 네트워크에 들어오는 항목에 대한 완전한 제어권을 제공합니다. 자동으로 다운로드되는 것은 없으며, 인터넷 연결은 동기화 단계에서만 필요합니다.

제한 사항

AppStudio용 단일 마스터 계정 — Appliance는 하나의 마스터 계정에 대해서만 AppStudio 환경을 호스팅할 수 있습니다. 앱 개발은 단일 조직 범위로 제한됩니다.
확장성 제한 — Appliance는 한 위치에 있는 한정된 수의 기계에 맞게 크기가 설계되어 있습니다. 여러 사이트에 걸쳐 있거나 수만 대의 디바이스로 구성된 플릿은 클라우드 또는 프라이빗 클라우드 배포가 더 적합합니다.
AI 서비스는 아웃바운드 LLM 접근 필요 — Appliance가 전혀 인터넷에 접근할 수 없는 경우의 옵션은 프라이빗 클라우드를 참조하십시오.

문의하기

Appliance 배포는 IronFlock 팀과의 파트너십을 통해 구성됩니다. 하드웨어, 기계 수량, 브랜딩 요구 사항을 논의하려면 문의해 주십시오.