어플라이언스 명령

ironflock appliance 명령은 직접 운영하는 Linux 서버에 IronFlock 어플라이언스를 설치하고, 그 뒤로 어플라이언스를 관리합니다. 이 명령으로 어플라이언스를 설치하고, 설정을 변경하고, 업데이트하고, 시작, 중지, 재시작하고, 로그를 읽고, admin 비밀번호를 재설정하고, 시크릿을 백업, 복원, 교체하고, 다시 제거합니다.

어플라이언스는 현장의 머신 한 대에서 실행되는 완전한 IronFlock 시스템입니다. 어플라이언스가 무엇인지, 그 HTTPS 모드, 네트워크, 운영은 IronFlock Appliance에서 설명합니다. 머신의 요구 사항(CPU, 메모리, 스토리지, 시간 동기화)은 설치 페이지에 있습니다.

참고: 이 명령은 ironflock 릴리스 2.1.0에서 새로 추가되었습니다. 새로 설치한 Ubuntu 24.04 가상 머신(amd64)에서 appliance install부터 appliance remove --purge까지 한 차례 테스트를 통과했습니다. 실패한 업데이트와 그에 따른 이전 릴리스로의 롤백은 아직 검증되지 않았습니다.

어플라이언스

어플라이언스 명령은 Linux에서 실행됩니다. appliance install에는 systemd를 사용하는 Debian 또는 Ubuntu 기반 시스템이 필요합니다. macOS에서 이 명령은 아무것도 살펴보기 전에 종료 코드 3으로 끝납니다. 어플라이언스의 머신에서 실행하거나, Mac에서 --host로 실행하십시오.

sudo를 사용해 root로 실행하십시오. 시스템을 변경하는 명령은 root가 아니면 종료 코드 3으로 끝나며 sudo를 직접 호출하지 않습니다(root 권한).

각 명령은 전역 플래그 --yes, --json, --download-base, --host, --hosts, --parallel도 받습니다(전역 플래그). 질문에는 터미널이 필요합니다. 터미널이 없으면 --yes를 지정하십시오(질문과 확인).

ironflock status는 설치된 어플라이언스를 보여 줍니다: 버전과 채널, UI 주소, 라이선스가 있는지, 서비스, 서비스의 상태, 대기 중인 업데이트(ironflock status).

설치된 어플라이언스의 구성 요소

설치는 ironflock.service 외에 워치독과 타이머도 설정합니다. 워치독은 5분마다 라우터와 백엔드를 검사하고, 정상이 아니면 ironflock.service를 재시작합니다(5분에 최대 한 번). 타이머는 UI에서 실패한 업데이트를 매시간 다시 시도합니다.

/usr/local/bin/ironflock을 그 자리에 두십시오. 어플라이언스의 유닛이 시작할 때마다 이를 실행합니다. appliance install은 다른 위치에서 실행되면 거부하며, 그 위치에 설치하는 방법을 알려 줍니다. root로 실행한 ironflock status는 이 바이너리가 없거나, 어플라이언스를 마지막으로 설치하거나 업데이트한 바이너리보다 오래되었으면 경고합니다. sudo ironflock self-update는 이 바이너리를 최신 릴리스로 교체합니다(ironflock self-update).

어플라이언스는 호스트 자체의 디바이스 에이전트도 실행하며, --no-agent를 지정하지 않으면 appliance install이 이를 설치합니다. 이 에이전트는 agent 명령으로 관리합니다.

한 번에 하나의 변경

어플라이언스의 설치, 업데이트 또는 그 밖의 변경은 한 번에 하나만 실행됩니다. 두 번째 실행은 첫 번째 실행을 기다리며 그렇다고 알려 줍니다:

Another IronFlock install, update or other change of the appliance is running on this host (process <pid>); waiting up to <time> for it to finish

install, update, configure, rotate, revoke-direct-access, reset-admin-password, restore는 최대 한 시간 기다립니다. start, stop, restart, remove는 최대 30초 기다립니다. 그때까지 다른 실행이 계속되면 명령은 아무것도 변경하지 않고 종료 코드 3으로 끝납니다.

ironflock appliance install

IronFlock 어플라이언스를 /opt/ironflock에 설치하고 시작합니다. 모든 서비스가 정상이 되고 IronFlock 클라우드가 어플라이언스에 도달할 때까지 기다린 다음, 웹 UI의 admin 로그인 정보를 터미널에 한 번 보여 줍니다.

ironflock appliance install --license-file <file> [flags]

실행 환경: systemd를 사용하는 Debian 또는 Ubuntu 기반 Linux. root 권한: 필요.

설치는 다음을 설정합니다:

• 채널의 릴리스 또는 --version이 지정하는 릴리스. 어플라이언스 릴리스 키로 확인합니다
• 어플라이언스의 구성과 시크릿
• 호스트 자체의 디바이스 에이전트, 그리고 Docker가 없으면 Docker
• 호스트의 설정
• 라이선스 키를 사용한 레지스트리에 대한 Docker의 로그인
• 릴리스의 이미지
• ironflock.service

Docker가 없으면 설치는 get.docker.com의 Docker 설치 스크립트를 root로 실행합니다. 이 다운로드는 TLS로만 보호됩니다.

HTTPS 모드와 각 모드가 암호화하는 대상은 HTTPS 및 인증서와 보안에서 설명합니다. 프록시 비밀번호는 시크릿의 규칙을 따릅니다. 비밀번호가 들어 있는 프록시 URL은 잘못된 명령줄입니다.

라이선스 키

라이선스 키는 ironflock.com의 프로필 → 인스턴스에서 생성하는 Instance Key입니다(설치). --license-file 또는 --license로 지정합니다. 이미 설치된 어플라이언스는 둘 다 없어도 자신의 키를 유지합니다. license.env에 있는 키가 유효한 라이선스 키가 아니면(라이선스 키는 UUID입니다) 어플라이언스의 모든 명령이 경고와 함께 이를 무시합니다. 이때 실행에는 키 또는 --skip-login이 필요합니다.

환경 변수

일부 플래그는 환경 변수에서 기본값을 가져옵니다:

sudo는 셸의 변수를 대부분 버립니다. sudo env NAME=value ironflock appliance install ...로 전달하십시오.

설치 선택 사항의 기록

root만 읽을 수 있는 <install-dir>/install.json에는 .env도 유닛도 보관하지 않는 선택 사항이 기록됩니다: 레지스트리와 그 사용자, 어플라이언스의 호스트(IRONFLOCK_APPLIANCE_HOST), --no-agent, --bucket-url의 다운로드 베이스, 그리고 어플라이언스를 마지막으로 설치하거나 업데이트한 ironflock의 버전. 비밀번호, 토큰, 키는 들어 있지 않습니다.

이후의 appliance install, appliance update, appliance configure는 플래그(또는 그 변수)가 달리 지정하지 않는 한 이 선택 사항을 유지합니다. 지정한 플래그가 우선하며 기록됩니다. 기본값으로 되돌리려면 --registry "", --no-agent=false 또는 빈 IRONFLOCK_APPLIANCE_HOST를 지정하십시오.

기록을 읽을 수 없거나 더 새로운 형식이면 install, update, configure는 아무것도 변경하기 전에 종료 코드 3으로 중단합니다. 메시지가 해야 할 일을 알려 줍니다: 기록을 다른 곳으로 옮기고 플래그와 함께 다시 설치하거나, 더 새로운 ironflock을 사용하십시오.

다시 실행하기

설치된 어플라이언스에서 실행하면, 명령은 어플라이언스를 지정한 릴리스와 옵션으로 맞추고 시크릿과 설정은 유지합니다. 릴리스를 의도적으로 바꿀 때 이 방법을 사용하십시오. ironflock appliance install --version <version>은 그 릴리스가 이미 실행 중이어도 다시 가져오고, 재시작하고, 검사합니다.

중단된 실행은 같은 명령을 다시 실행하면 멈춘 곳부터 이어서 진행합니다.

상태 검사를 통과하면 설치는 업데이트가 보관한 이전 릴리스의 사본(/opt/ironflock/.update-previous)을 삭제합니다. 설치한 릴리스가 실행할 릴리스이기 때문입니다.

첫 번째 변경부터는 터미널이나 SSH 세션이 끊기거나(SIGHUP), 아무도 더 이상 읽지 않는 출력(닫힌 파이프)이 있어도 설치는 멈추지 않습니다. Ctrl-C와 SIGTERM은 설치를 멈춥니다. admin 비밀번호를 잃지 않도록, 설치는 SSH 세션이 끊긴 뒤에도 터미널에 계속 씁니다. 따라서 sudo의 use_pty 설정을 사용하면, 열려 있지만 더 이상 읽히지 않는 터미널이 설치 잠금을 쥔 채 설치를 붙잡아 둘 수 있습니다.

예시

# 어플라이언스 설치. 라이선스 키는 파일에서 읽음
sudo ironflock appliance install --license-file license.txt
# 어플라이언스 자체 CA의 HTTPS로 설치. 키는 표준 입력에서 읽음
sudo ironflock appliance install --license-file - --tls < license.txt
# 프록시 뒤에서 설치. .corp.example.com 아래의 호스트는 프록시를 거치지 않음
sudo ironflock appliance install --https-proxy http://proxy.example.com:3128 --no-proxy .corp.example.com
# 어플라이언스의 주소와 도메인을 묻고 HTTPS로 설치
sudo ironflock appliance install --license-file license.txt --interactive --tls

거부와 실패

• 유닛이 그대로 지정할 수 없는 --bucket-url의 다운로드 베이스(로그인 정보, %, 공백, $, \, 따옴표, 제어 문자, UTF-8이 아닌 바이트가 들어 있는 경우)는 아무것도 쓰기 전에 종료 코드 2로 거부됩니다.
• root로 실행되지 않을 때, 설치 선택 사항의 기록을 읽을 수 없을 때, 다른 실행이 한 시간의 대기 시간을 넘어 설치 잠금을 쥐고 있을 때 명령은 종료 코드 3으로 거부합니다. 실행 중인 ironflock이 /usr/local/bin/ironflock이 아닐 때도 거부하며, 그 위치에 설치하는 방법을 알려 줍니다.
• 단계가 실패하면 명령은 종료 코드 1로 끝납니다. 같은 명령을 다시 실행하면 이어서 진행합니다.

ironflock appliance configure

설치된 어플라이언스의 설정을 변경합니다: 라이선스, TLS 모드(사용자 소유의 인증서 포함), 프록시, UI의 추가 호스트 이름, 터널, 이중 인증 정책.

ironflock appliance configure [flags]

실행 환경: 어플라이언스가 설치된 Linux. root 권한: 필요.

설정은 어플라이언스의 .env와 파일에 남으므로 업데이트가 이를 유지합니다. 지정하지 않은 설정은 어플라이언스의 기존 값을 유지합니다. 무언가를 변경한 실행만 어플라이언스를 재시작하므로, 같은 명령을 두 번 실행하면 두 번째에는 아무것도 변경하지 않습니다.

• 새 라이선스(--license, --license-file, 또는 표준 입력용 --license-file -)는 기록되기 전에 레지스트리에 로그인할 수 있어야 합니다. 레지스트리 로그인은 --registry-user로 --registry에, 없으면 설치가 선택한 레지스트리와 사용자(기록)로, 그것도 없으면 어플라이언스의 미러가 동기화하는 레지스트리로 갑니다. --registry나 --registry-user로 로그인하면 업데이트를 위해 이 값이 기록에 남습니다.
• **--tls-cert와 --tls-key**는 사용자의 인증서를 설치하고 TLS를 켜며, 디바이스는 어플라이언스의 도메인으로 이동합니다.
• **--http-proxy "" 또는 --https-proxy ""**를 단독으로 지정하면 프록시를 지웁니다.
• 설치의 **--no-agent**는 그대로 유지됩니다.
• TLS에 필요한 Caddyfile은 --bucket-url에서, 없으면 설치가 릴리스를 가져온 곳에서 가져옵니다.

예시

# 파일에서 읽은 새 라이선스 키를 어플라이언스에 적용
sudo ironflock appliance configure --license-file license.txt
# 조직의 인증서로 UI 제공
sudo ironflock appliance configure --tls-cert wildcard.crt --tls-key wildcard.key
# 프록시를 설정하고 다시 지우기
sudo ironflock appliance configure --https-proxy http://proxy.example.com:3128 --no-proxy .corp.example.com
sudo ironflock appliance configure --https-proxy ""
# 모든 사용자에게 이중 인증 요구
sudo ironflock appliance configure --2fa required

--2fa required를 설정하기 전에 모든 계정에 이중 인증이 설정되어 있는지 확인하십시오. 설정하지 않은 사용자는 더 이상 로그인할 수 없습니다(계정 및 접근).

거부하는 경우

root로 실행되지 않을 때, 설치 선택 사항의 기록을 읽을 수 없을 때, 다른 실행이 한 시간의 대기 시간을 넘어 설치 잠금을 쥐고 있을 때, 그리고 업데이트가 중단된 상태일 때(업데이트가 중단된 경우) 명령은 종료 코드 3으로 거부하며 아무것도 변경하지 않습니다.

ironflock appliance update

이 머신의 어플라이언스를 채널의 최신 릴리스, 또는 --version이 지정하는 릴리스로 업데이트합니다. 릴리스를 어플라이언스 릴리스 키로 확인하고, 이미지를 가져오고, 어플라이언스를 그 릴리스로 재시작합니다. 명령은 모든 서비스가 정상이 되고 IronFlock 클라우드가 어플라이언스에 도달할 때까지 기다립니다. 어플라이언스는 시크릿과 설정을 유지합니다. 새 릴리스가 정상이 되면 이전 릴리스의 이미지는 삭제됩니다.

ironflock appliance update [flags]

실행 환경: 어플라이언스가 설치된 Linux. root 권한: 필요. 질문: --discard-previous를 제외하면 없음.

릴리스는 --bucket-url에서, 없으면 IRONFLOCK_BUCKET_URL에서, 없으면 설치가 릴리스를 가져온 곳(설치 선택 사항의 기록 /opt/ironflock/install.json 또는 유닛이 지정)에서, 그것도 없으면 IronFlock에서 가져옵니다. 레지스트리, 그 사용자, 어플라이언스의 호스트, --no-agent는 설치가 선택한 그대로 유지됩니다.

새 채널은 업데이트가 성공하면 유지되며, 롤백하면 이전 채널로 돌아갑니다. UI의 Apply update도 같은 업데이트를 실행합니다.

검사를 통과하면 설치나 업데이트는 어플라이언스 자체의 디바이스를, 이전에 모든 어플라이언스가 공유하던 시크릿에서 APPLIANCE_DEVICE_SECRET의 값으로 옮깁니다. 이때 그 에이전트는 실행이 끝나고 35초 뒤에 재시작됩니다. 옮길 수 없으면 그 이유를 알리는 경고가 나오며, 다음 설치나 업데이트가 다시 시도합니다.

이미 최신인 경우

같은 채널과 다운로드 베이스에서 이미 채널의 최신 릴리스(또는 --version이 지정하는 릴리스)를 실행하는 어플라이언스는 그대로 둡니다. 명령은 그렇다고 알리고 종료 코드 0으로 끝납니다. --json을 사용하면 result는 nothing-to-do입니다. 그 릴리스를 의도적으로 다시 가져오고, 재시작하고, 검사하려면 ironflock appliance install --version <version>을 실행하십시오.

이는 마지막 업데이트가 깨끗한 상태로 남긴 어플라이언스에만 해당합니다. 이전 릴리스의 보관된 사본이 있거나(중단된 업데이트), 상태 파일이 failed 또는 running이면 업데이트는 모든 것을 다시 실행합니다.

롤백

업데이트는 무언가를 변경하기 전에, 실행 중인 릴리스의 파일을 /opt/ironflock/.update-previous에 보관합니다. 어플라이언스를 변경한 뒤에 업데이트가 실패하면, 그 파일을 되돌리고 이전 릴리스를 다시 시작합니다. 이전 릴리스의 이미지는 머신에 있으므로 네트워크가 필요하지 않습니다. 최대 세 번 시도합니다. 그래도 안 되면 명령은 포기하고, 어플라이언스의 다음 시작이 이전 릴리스가 되도록 이전 릴리스의 파일을 그 자리에 둡니다.

아무것도 변경하기 전에 실패한 업데이트는 더 이상 아무것도 변경하지 않으며 그렇다고 알려 줍니다. 예를 들어 릴리스가 없거나 서명되지 않은 경우, 또는 다운로드 베이스가 응답하지 않는 경우입니다.

릴리스에 실행 중인 것보다 더 새로운 ironflock이 필요할 수 있습니다. 이때는 아무것도 변경하지 않으며, 명령이 먼저 설치할 ironflock을 알려 줍니다. appliance update는 ironflock을 스스로 업데이트하지 않습니다. ironflock self-update가 최신 릴리스를 설치합니다.

상태 파일과 재시도

업데이트는 UI의 업데이트와 마찬가지로 진행 상황을 triggers/apply-update.status에 쓰므로 UI가 이를 보여 줍니다. 출력도 triggers/apply-update.log에 기록됩니다. UI에서 실패한 업데이트를 다시 시도하는 타이머는, 이 명령으로 실행했다가 실패했거나 무언가를 변경하기 전에 중지된 업데이트는 다시 시도하지 않습니다.

인터럽트

• Ctrl-C 또는 SIGTERM은 업데이트가 무언가를 변경하기 전이면 업데이트를 멈춥니다. 그 이후에는 첫 번째 신호가 이전 릴리스를 되돌리고(종료 코드 130), 두 번째 신호는 즉시 멈춥니다.
• 터미널이나 SSH 세션이 끊기거나(SIGHUP) 아무도 더 이상 출력을 읽지 않아도 업데이트는 멈추지 않습니다. 업데이트와 롤백은 끝까지 실행됩니다. 어떻게 끝났는지는 상태 파일과 ironflock status가 알려 줍니다.
• 터미널 없이 --host를 사용하면 처음 두 번의 Ctrl-C가 머신에 전달됩니다. 첫 번째 뒤에는 명령이 그곳의 업데이트가 끝나기를 최대 30분 기다리고, 두 번째 뒤에는 15초 기다리며, 세 번째는 이쪽에서 즉시 명령을 끝냅니다. 이쪽의 세션이 끊기거나 SIGTERM을 받으면 Ctrl-C가 아니므로 명령은 이쪽에서 즉시 끝납니다. 이쪽에서 먼저 끝나면 머신에서는 업데이트가 계속되며, 어떻게 끝났는지는 ironflock --host <machine> status가 보여 줍니다.

업데이트가 중단된 경우

업데이트가 어플라이언스를 변경하기 시작한 뒤 끝나지 않으면 업데이트가 중단된 것입니다. 업데이트가 중지되었거나, 머신이 꺼졌거나, 롤백이 이전 릴리스를 다시 실행하지 못한 경우입니다. 이때 설치 디렉터리에는 두 릴리스의 파일이 섞여 있을 수 있습니다. 보관된 사본은 실행되는 것으로 알려진 릴리스를 나타내며, ironflock status도 그 릴리스를 보여 줍니다.

• 다음 업데이트는 먼저 그 사본을 되돌린 다음 업데이트합니다. 사본을 읽거나 되돌릴 수 없으면 업데이트는 종료 코드 3으로 멈추며, 오류가 ironflock appliance install --version <version>을 알려 줍니다.
• 매시간 실행되는 재시도 타이머는 더 새로운 릴리스가 없어도 스스로 사본을 되돌리고, 그 릴리스를 재시작하고 검사합니다.
• **configure, rotate, revoke-direct-access, restore, reset-admin-password**는 아무것도 변경하기 전에 종료 코드 3으로 거부합니다. 이 명령들은 세 가지 해결 방법을 알려 줍니다: ironflock appliance update, ironflock appliance install --version <version>, 그리고 네트워크 없이 ironflock appliance update --discard-previous.
• **backup**은 읽기만 하며 경고합니다. **start, stop, restart**는 사본을 건드리지 않습니다. **remove**는 어플라이언스의 나머지 파일과 함께 사본도 삭제합니다.
• **appliance install**은 평소대로 실행되며, 상태 검사를 통과하면 사본을 삭제합니다.

중단된 업데이트의 파일을 직접 다루려면 먼저 .env에 IRONFLOCK_UPDATE_RETRY=off를 설정하십시오. 그렇지 않으면 재시도 타이머가 약 한 시간 안에 이전 릴리스를 되돌립니다. 이 설정은 롤백을 포함해 재시도 타이머 전체를 끕니다.

--discard-previous

ironflock appliance update --discard-previous [--yes]

아무것도 업데이트하지 않습니다. 업데이트가 보관한 이전 릴리스의 사본(/opt/ironflock/.update-previous)을 어떤 상태이든, 읽을 수 없더라도 삭제하며, 그 밖에는 아무것도 변경하지 않습니다. 네트워크가 필요하지 않습니다.

업데이트가 중단되었고 이전 릴리스가 다시 시작되지 않을 때, 네트워크 없이 빠져나오는 방법입니다. 설치 디렉터리의 파일은 지금 상태 그대로 남고, 그 릴리스는 더 이상 되돌릴 수 없으며, 거부하던 명령이 다시 실행됩니다.

삭제할 내용을 알리고 먼저 묻습니다. “No”가 미리 선택되어 있으며, --yes는 예로 답합니다. 터미널이 없거나 --json을 사용하면 --yes가 필요하며, 없으면 종료 코드 4로 끝납니다. 사본이 없으면 그렇다고 알리고 종료 코드 0으로 끝납니다. --version, --channel, --bucket-url과 함께 쓸 수 없습니다(종료 코드 2). --json을 사용하면 결과에 action(discarded, cleaned 또는 none), path, version, state, removed가 있습니다.

예시

# 채널의 최신 릴리스로 업데이트
sudo ironflock appliance update
# 릴리스 1.6.41 설치. 되돌아갈 때도 사용
sudo ironflock appliance update --version 1.6.41
# test 채널로 전환하고 결과를 JSON으로 읽기
sudo ironflock appliance update --channel test --json
# 네트워크 없이 이전 릴리스의 사본 삭제
sudo ironflock appliance update --discard-previous

결과

{"from":"1.6.40","target":"1.6.41","version":"1.6.41","result":"updated"}

실패한 업데이트는 어플라이언스가 이전 릴리스로 돌아갔는지를 알려 주는 오류입니다. --json을 사용하면 그 kind는 중단된 경우를 포함해 다음 중 하나입니다:

ironflock appliance start

실행 중이 아닌 어플라이언스를 시작합니다: ironflock.service가 컨테이너를 시작하고(docker compose up), 워치독과 그 밖의 경로 유닛과 타이머가 다시 시작됩니다. 서비스가 올라오는 데 1~2분이 걸립니다. 서비스의 상태는 ironflock status가 보여 줍니다.

ironflock appliance start [flags]

실행 환경: 어플라이언스가 설치된 Linux. root 권한: 필요. 질문: 없음. 이 명령에는 자체 플래그가 없습니다.

어플라이언스가 실행 중이 아니어서 복원이 데이터베이스 역할을 이전 비밀번호로 남겨 두었다면, 데이터베이스가 실행되면(최대 1분) 그 역할이 복원된 .env의 비밀번호를 받습니다. 응답하지 않는 역할은 경고와 함께 다음 시작으로 넘어가며, 시작은 계속됩니다.

sudo ironflock appliance start
sudo ironflock appliance start --json

다른 실행이 어플라이언스를 변경하는 동안에는 명령이 최대 30초 기다리며 그렇다고 알려 줍니다. 그 실행이 계속되면 아무것도 변경하지 않고 종료 코드 3으로 끝납니다.

ironflock appliance stop

어플라이언스를 중지합니다: 워치독과 그 밖의 경로 유닛과 타이머, 그리고 그것들이 시작한 것을 중지한 다음, ironflock.service를 중지합니다. ironflock.service는 컨테이너를 중지하고 삭제합니다(docker compose down). 데이터는 그대로 남습니다.

ironflock appliance stop [flags]

실행 환경: 어플라이언스가 설치된 Linux. root 권한: 필요. 질문: 예. 중지하면 무엇이 끝나는지 알린 뒤 묻습니다. --yes로 답합니다.

UI가 오프라인이 되며, 이 머신의 에이전트를 포함해 어플라이언스에 연결하는 모든 디바이스도 오프라인이 됩니다. ironflock appliance start나 다음 부팅이 어플라이언스를 다시 시작합니다. 이 명령에는 자체 플래그가 없습니다.

# 어플라이언스 중지. 명령이 무엇이 끝나는지 알리고 질문함
sudo ironflock appliance stop
# 질문 없이 중지
sudo ironflock appliance stop --yes

아니요로 답하거나, 터미널도 --yes도 없이 질문하게 되면 명령은 종료 코드 4로 끝납니다. 다른 실행이 어플라이언스를 변경하는 동안에는 start와 마찬가지로 기다립니다.

ironflock appliance restart

어플라이언스를 재시작합니다: 워치독과 마찬가지로 ironflock.service가 컨테이너를 중지하고 다시 시작합니다(docker compose down, 그다음 up). appliance stop이 중지한 경로 유닛과 타이머도 다시 시작됩니다.

ironflock appliance restart [flags]

실행 환경: 어플라이언스가 설치된 Linux. root 권한: 필요. 질문: 없음. 이 명령에는 자체 플래그가 없습니다.

UI와 어플라이언스에 연결하는 디바이스는 1~2분 동안 오프라인이 되며, 데이터는 그대로 남습니다. 서비스가 올라오면 ironflock status가 그 상태를 보여 줍니다. 복원이 이전 비밀번호로 남겨 둔 데이터베이스 역할은 start와 마찬가지로 .env의 비밀번호를 받습니다.

sudo ironflock appliance restart
sudo ironflock appliance restart --json

다른 실행이 어플라이언스를 변경하는 동안에는 start와 마찬가지로 기다립니다.

ironflock appliance logs

docker compose logs처럼 어플라이언스 서비스가 쓴 내용을 보여 줍니다. 기본적으로 각 서비스의 마지막 100줄입니다. 아무것도 변경하지 않습니다.

ironflock appliance logs [<service>...] [flags]

실행 환경: 어플라이언스가 설치된 Linux. root 권한: 필요. 질문: 없음.

router, backend, kratos, caddy처럼 서비스 이름을 지정하면 그 서비스의 로그만 봅니다.

--json을 사용하면 각 줄이 그 줄을 메시지로 담은 JSON 객체입니다.

# 각 서비스의 마지막 100줄
sudo ironflock appliance logs
# 백엔드가 지난 한 시간 동안 쓴 모든 내용
sudo ironflock appliance logs backend --since 1h
# 라우터와 Kratos의 마지막 20줄, 그다음 Ctrl-C까지 새 줄 모두
sudo ironflock appliance logs router kratos --follow --lines 20

ironflock appliance reset-admin-password

비밀번호를 잃어버린 운영자를 위해 UI 사용자 admin에게 새 비밀번호를 부여합니다. 비밀번호는 먼저 데이터베이스에 설정되며 이때 admin의 모든 활성 세션이 종료되고, 그다음 .env에 APPLIANCE_ADMIN_PASSWORD로 설정됩니다. 어플라이언스가 실행 중이어야 합니다.

ironflock appliance reset-admin-password [flags]

실행 환경: 어플라이언스가 실행 중인 Linux. root 권한: 필요.

새 비밀번호는 한 번만, 그리고 터미널에만 표시됩니다. 터미널이 없거나 --json을 사용하면 명령은 대신 비밀번호가 저장된 위치를 알려 줍니다. 업데이트가 중단된 상태에서는 종료 코드 3으로 거부합니다(업데이트가 중단된 경우).

sudo ironflock appliance reset-admin-password

ironflock appliance backup

어플라이언스에서 다시 만들 수 없는 모든 것을 tar.gz 아카이브에 씁니다: 모든 시크릿이 들어 있는 .env, license.env, TLS 인증서의 로컬 CA, 레지스트리의 토큰 키 쌍, 시크릿 목록, rotation.log.

ironflock appliance backup [-o <file>] [flags]

실행 환경: Linux. root 권한: 필요.

-o가 없으면 아카이브는 표준 출력으로 나가며, 표준 출력은 터미널이 아니어야 합니다. 리디렉션한 파일은 소유자만 읽을 수 있게 됩니다.

경고: 아카이브에는 어플라이언스의 모든 시크릿이 들어 있습니다. 분실한 FLEETDB_SECRET_KEYS나 FILE_CRED_KEY는 다른 방법으로 복구할 수 없습니다. 아카이브를 암호화하여 볼륨 백업과 함께 보관하십시오.

아카이브에 들어가지 않는 것: TLS 인증서와 그 키(생성된 인증서는 CA로 다시 서명됩니다), Kratos 구성, 릴리스의 파일, Docker 볼륨. certs/ca와 registry-token-certs에서는 설치가 그곳에 만드는 파일(rootCA.crt, rootCA.key, rootCA.srl, token_private.key, token_public.crt, token_public.der, 그리고 .prev나 .new가 붙은 파일)만 가져옵니다. restore가 다른 파일은 받지 않으므로, 그 밖의 파일은 그 이름을 알리는 경고와 함께 제외됩니다.

# 아카이브를 root만 읽을 수 있는 파일에 쓰기
sudo ironflock appliance backup -o /root/appliance-secrets.tar.gz
# 표준 출력으로 내보내 파일에 쓰기
sudo ironflock appliance backup > appliance-secrets.tar.gz

ironflock appliance restore

appliance backup이 쓴 백업을 설치 디렉터리에 되돌립니다.

ironflock appliance restore <file> [flags]

실행 환경: Linux. root 권한: 필요.

명령은 백업에 들어 있는 파일만 가져오며, 각 파일에 설치가 부여하는 소유자와 모드를 적용합니다. certs/ca와 registry-token-certs에서는 설치가 그곳에 만드는 파일만 가져옵니다. 그 밖의 것이 들어 있는 아카이브는 아무것도 변경하기 전에 거부되며, 오류가 그 내용을 알려 줍니다.

설치된 어플라이언스의 시크릿은 --force가 있을 때만 교체되며, 그 .env는 .env.prev로 보관됩니다. --force가 없으면 설치된 어플라이언스 위로의 복원은 아무것도 변경하기 전에 종료 코드 3으로 거부되며, 메시지가 --force를 사용한 복원과 그다음 appliance restart를 알려 줍니다.

백업에 들어 있는 라이선스 키가 유효한 라이선스 키가 아니면 경고와 함께 그대로 복원됩니다. 어플라이언스의 모든 명령은 이 키를 무시합니다.

데이터베이스 비밀번호

• 어플라이언스의 데이터베이스가 실행 중이면 그 역할이 복원된 비밀번호를 즉시 받습니다. 이때 모든 서비스가 복원된 파일을 읽도록 어플라이언스를 재시작하십시오(appliance restart).
• 어플라이언스가 실행 중이 아니면 데이터베이스 역할은 이전 비밀번호를 유지합니다. 복원은 이를 표시해 둡니다(<install-dir>/.db-roles-pending, --json에서는 roles_pending). 다음 시작이 역할을 복원된 .env의 비밀번호로 설정합니다: appliance start 또는 restart, 부팅 시 시작, 설치, 업데이트.

# 설치된 어플라이언스에 복원한 뒤 재시작
sudo ironflock appliance restore appliance-secrets.tar.gz --force
sudo ironflock appliance restart

업데이트가 중단된 상태에서는 종료 코드 3으로 거부합니다(업데이트가 중단된 경우).

ironflock appliance rotate

어플라이언스의 시크릿 하나에 새 값을 부여합니다. 새 값은 이전 값이 있던 곳(데이터베이스 역할, 에이전트의 디바이스 파일, 레지스트리의 토큰 키 쌍)과 .env에 들어갑니다. 그다음 그 시크릿을 읽는 서비스만 다시 생성되며, 명령은 그 서비스가 정상인지 확인합니다.

ironflock appliance rotate <name> [flags]

실행 환경: 어플라이언스가 실행 중인 Linux. root 권한: 필요. 질문: 다른 곳에도 보관된 시크릿에 대해. --yes로 답합니다.

변경 전의 .env는 root만 읽을 수 있는 .env.prev로 남습니다. rotation.log에는 각 교체가 기록되지만 값은 기록되지 않습니다.

• 다른 곳(데이터, 디바이스, 토큰)에도 보관된 시크릿은 교체하기 전에 묻습니다. --yes로 답합니다.
• **FILE_CRED_KEY**에는 고객의 직접 접근 키에 대한 선택이 필요합니다. --keep-direct-access: 키가 계속 작동하므로 정기 교체에 적합합니다. 나중에 revoke-direct-access로 마무리하십시오. --revoke-direct-access: 키가 작동을 멈추고 제거되므로 유출이 의심될 때 사용합니다.
• **APPLIANCE_ADMIN_PASSWORD**는 reset-admin-password와 같습니다.

교체할 수 있는 시크릿:

POSTGRES_PASSWORD, PGPASSWORD_KRATOS, PGPASSWORD_ACCT_MANAGER,
PGPASSWORD_ACCT_PUSHER, PGPASSWORD_EXT_ACCT_USER, PGPASSWORD_AUDIT_SANDBOX,
DATASERVICE_PASSWORD, WAMP_SYSTEM_SECRET, WAMP_SECRET_SVC_VDM,
WAMP_SECRET_SVC_IDE, WAMP_SECRET_SVC_IDE_PROXY, WAMP_SECRET_SVC_GIT,
WAMP_SECRET_SVC_REGISTRY, WAMP_SECRET_SVC_REGISTRY_PROXY,
WAMP_SECRET_SVC_ACCT, WAMP_SECRET_SVC_ACCT_PUSH, WAMP_SECRET_SVC_PAYMENT,
WAMP_SECRET_SVC_FLEETDB, WAMP_SECRET_SVC_FLEETFILES, WAMP_SECRET_SVC_AI,
WAMP_SECRET_SVC_TUNNEL, WAMP_SECRET_SVC_RENDERER, WAMP_SECRET_SVC_WEBSERVER,
WAMP_SECRET_SVC_REAPI, WAMP_SECRET_SVC_AUTH, RENDER_TICKET_KEY,
FILES_FORWARD_SECRET, KRATOS_WEBHOOK_SECRET, KRATOS_SECRETS_PAGINATION,
REGISTRY_HTTP_SECRET, TUNNEL_DASHBOARD_PASSWORD, EDGE_SESSION_SECRET,
OBJECTSTORE_ADMIN_ACCESS_KEY, OBJECTSTORE_ADMIN_SECRET_KEY, FILE_CRED_KEY,
FLEETDB_SECRET_KEYS, KRATOS_SECRETS_COOKIE, KRATOS_SECRETS_CIPHER,
APPLIANCE_DEVICE_SECRET, APPLIANCE_ADMIN_PASSWORD, REGISTRY_TOKEN_KEY

교체가 각 종류의 시크릿에 어떤 영향을 주는지, 그리고 어떤 시크릿을 IronFlock 팀과 함께만 교체해야 하는지는 내부 시크릿 교체에서 설명합니다.

# 서비스 하나의 시크릿 교체
sudo ironflock appliance rotate WAMP_SECRET_SVC_AI
# 파일 키를 정기적으로 교체. 직접 접근 키는 계속 작동
sudo ironflock appliance rotate FILE_CRED_KEY --keep-direct-access --yes

업데이트가 중단된 상태에서는 종료 코드 3으로 거부합니다(업데이트가 중단된 경우).

ironflock appliance revoke-direct-access

--keep-direct-access로 실행한 FILE_CRED_KEY 교체를 마무리합니다. 현재 FILE_CRED_KEY로 만들지 않은 고객의 직접 접근 키는 모두 작동을 멈추고 제거되며, 키 자체는 그대로 남습니다. fleetfiles 서비스가 다시 생성되며, 제거한 내용을 보고합니다.

ironflock appliance revoke-direct-access [flags]

실행 환경: 어플라이언스가 설치된 Linux. root 권한: 필요. 질문: 예. 그 키의 소유자가 새 키를 만들어야 하기 때문입니다. --yes로 답합니다.

sudo ironflock appliance revoke-direct-access

업데이트가 중단된 상태에서는 종료 코드 3으로 거부합니다(업데이트가 중단된 경우).

ironflock appliance remove

이 머신에서 IronFlock 어플라이언스를 제거하고, 설치가 호스트에 기록한 변경 사항을 되돌립니다. --purge를 지정하지 않으면 데이터는 남습니다.

ironflock appliance remove [flags]

실행 환경: Linux. root 권한: 필요. 질문: 예. 제거되는 것과 남는 것을 나열한 뒤 묻습니다. 질문에는 “No”가 미리 선택되어 있어 Enter만 누르면 아무것도 제거하지 않습니다.

제거하는 것:

• 어플라이언스의 systemd 유닛, 컨테이너, Docker 네트워크
• IronFlock 레지스트리에 대한 Docker의 로그인
• 설치가 호스트에 기록한 모든 변경 사항(/etc/ironflock/appliance.json): 설치가 쓴 프록시 설정, Docker daemon.json의 설정, 저널 설정, 마스킹한 절전 타깃
• 업데이트가 롤백을 위해 보관한 이전 릴리스의 사본(설치 디렉터리의 .update-previous)

어플라이언스 컨테이너의 익명 볼륨도 --purge 여부와 관계없이 제거됩니다. 이름이 있는 볼륨과 아직 컨테이너가 사용하는 볼륨은 제거하지 않습니다.

남는 것

--purge가 없으면 나중의 설치가 이어받을 수 있도록 어플라이언스의 데이터가 남습니다:

• 설치 디렉터리(/opt/ironflock): 시크릿이 들어 있는 .env, license.env, 설치 선택 사항의 기록(install.json), 복원이 설정하지 못한 데이터베이스 비밀번호의 표시(.db-roles-pending)
• Docker의 볼륨

--purge는 이것들과 이미지까지 제거합니다. 어플라이언스가 보관하던 것은 완전히 사라집니다.

--purge를 사용해도 다음은 남습니다:

• Docker 자체와 호스트의 디바이스 에이전트. 에이전트는 ironflock agent remove가 제거합니다.
• 어플라이언스가 쓴 뒤 변경된 파일. 예를 들어 ironflock agent configure가 설정한 프록시 설정과 그것을 지정하는 드롭인이 남아, 에이전트가 프록시를 유지합니다.
• 에이전트의 기록(/opt/ironflock/device-init/installed.json)이 에이전트의 것으로 지정하는 것, 그리고 에이전트가 마스킹한 절전 타깃. 이것들은 ironflock agent remove가 제거합니다.

호출이 실패하는 경우

되돌리기의 호출이 계속 실패하면(예: 직접 제거한 Docker의 재시작) 기록이 남습니다. 명령은 어떤 호출이 실패했는지 알리고 오류로 끝납니다. 그 호출이 작동하게 되면 다시 실행하거나, --force로 실행하십시오. --force는 그래도 기록을 버리며, 비활성화할 수 없는 유닛이나 응답하지 않는 Docker를 건너뛰고 계속합니다.

설치, 업데이트 또는 어플라이언스의 다른 변경이 실행되는 동안에는 명령이 최대 30초 기다리며 그렇다고 알려 줍니다. 그 실행이 계속되면 아무것도 변경하지 않고 종료 코드 3으로 끝납니다.

예시

# 데이터는 남기고 어플라이언스 제거. 명령이 제거할 내용을 나열하고 질문함
sudo ironflock appliance remove
# 모든 데이터와 함께 질문 없이 어플라이언스 제거
sudo ironflock appliance remove --purge --yes

아니요로 답하거나, 터미널도 --yes도 없이 질문하게 되면 명령은 종료 코드 4로 끝납니다.

어플라이언스를 영구히 제거하기 전에, 아직 온라인 상태일 때 라이선스를 이전하거나 해제하십시오(폐기).