운영

업그레이드

컨트롤 플레인을 먼저 업그레이드한 다음 노드를 한 번에 하나씩 업그레이드합니다.

sudo apt install runlot-cp=<new-version>
sudo /opt/runlot/bin/runlot-admin upgrade --nodes node-1,node-2 --version <new-version>

runlot-admin upgrade는 SSH로 각 노드에 설치하고, 해당 노드 자체의 준비 상태 확인을 기다리며, 처음 실패한 지점에서 멈추고 완료된 노드와 남은 노드를 알려 줍니다. --dry-run은 실행 계획을 출력합니다.

안전을 보장하는 것은 순서가 아니라, 노드가 프로토콜 허용 범위를 벗어나면 시작을 거부한다는 점입니다. 노드는 시작할 때 자신의 프로토콜 버전을 컨트롤 플레인의 버전과 비교하고, 컨트롤 플레인보다 한 버전 넘게 뒤처지거나 앞서 있으면 두 버전을 함께 알리며 종료합니다. 컨트롤 플레인보다 먼저 노드를 설치하면 그 노드는 중단된 상태로 남고 그 이유를 알려 줍니다.

버전 문자열은 파일 이름이 아닙니다. rpm은 버전에 -를 허용하지 않으므로 프리릴리스 구분자가 ~로 바뀝니다.

apt-cache policy runlot-node는 패키지 관리자가 받아들이는 문자열을 출력합니다.

다운그레이드해도 스키마는 되돌아가지 않습니다. 마이그레이션은 추가만 하므로 이전 릴리스의 코드가 새 스키마에서도 안전하게 동작하지만, 스키마가 변경된 후에 이전 패키지를 설치하는 것은 지원하지 않습니다. 한 릴리스보다 더 이전으로 돌아가야 한다면 먼저 문의해 주세요.

GitOps: 파일로 프로젝트 관리

프로젝트용 Kubernetes 커스텀 리소스는 없으며 앞으로도 만들지 않습니다. 그렇게 하면 메타데이터 데이터베이스가 이미 보관하고 있는 내용을 클러스터가 두 번째로 기록하게 되기 때문입니다. 대신 파이프라인에서 명령 하나를 호출합니다.

apiVersion: runlot/v1
kind: ProjectSet
org: acme
projects:
  - name: billing-api
    secrets:
      DATABASE_URL: ${BILLING_DATABASE_URL}     # read from the pipeline's environment
    hostnames:
      - billing.acme.example
    access:
      policy: org                               # public | org | password
  - name: inventory

runlot apply -f projects.yaml --dry-run
runlot apply -f projects.yaml

이 명령은 멱등합니다. 이미 있는 프로젝트는 그대로 두고, 선언한 secret은 매번 기록하며, 없는 호스트네임은 추가하고, 접근 정책은 달라진 경우에만 설정합니다. 규칙은 네 가지입니다.

• 시크릿 값은 예시와 같은 변수 참조를 통해서만 들어올 수 있으며, 설정되지 않은 변수가 있으면 실행이 중단됩니다. 파일은 Git에 있으므로 값을 파일에 넣으면 안 됩니다.
• 일반 텍스트가 분명하지 않은 값은 따옴표로 감싸세요. YAML은 0100을 100으로 읽습니다.
• --prune 없이는 아무것도 삭제되지 않으며, --prune을 쓰려면 org slug를 --confirm acme처럼 다시 입력해야 합니다. 삭제하면 프로젝트의 데이터베이스와 모든 백업이 함께 삭제됩니다.
• --json을 지정하면 파이프라인 로그에 남길 수 있도록 출력이 하나의 객체로 만들어집니다.

라이선스

컨트롤 플레인은 라이선스 파일을 1분마다 다시 읽으므로, 갱신은 파일을 교체하는 것으로 끝납니다.

sudo cp license /etc/runlot/license/license

GET /v1/license와 대시보드 푸터에 상태, 티어, 노드 상한, 만료일이 표시됩니다. 각 상태와 상태별 변경 사항은 개요에 있습니다.

에어갭

버전마다 번들 하나를 보내 드립니다.

runlot-<version>-deb.tar.gz
  packages/runlot-cp_<v>_amd64.deb
  packages/runlot-node_<v>_amd64.deb
  packages/runlot-eval_<v>_amd64.deb
  SHA256SUMS
  SHA256SUMS.sig
  license/

sha256sum --check SHA256SUMS
runlot-license bundle-verify --dir .

서명은 바이너리에 컴파일되어 있는 키로 검증하므로 네트워크도 키링도 필요하지 않습니다. SHA256SUMS는 빌드의 출력을 바이트 단위로 그대로 담고 있으므로, 서명은 빌드가 만든 결과물 전체를 보증합니다. Helm 번들도 구성은 같으며, 패키지 대신 차트와 docker save 출력이 들어 있습니다.

메타데이터 데이터베이스를 복원한 경우

control plane은 PostgreSQL의 신원을 감시합니다. 클러스터 id, 타임라인, 쓰기 위치가 그 대상입니다. 백업에서 복원하거나 뒤처진 레플리카로 페일오버하면 데이터베이스가 과거 상태로 돌아오는데, 이런 경우 control plane은 노드에 lease 발급을 중단합니다. 앱은 계속 서비스되지만, 운영자가 새 상태를 확인할 때까지 배포, 복원, 파킹된 프로젝트의 wake는 모두 진행되지 않습니다.

curl -sS -H "Authorization: Bearer $RUNLOT_OPERATOR_TOKEN" http://$RUNLOT_CP_PRIVATE_ADDR:8081/v1/era

reason과 drainDeadline이 포함된 mode: lease_quarantine입니다. 기한이 지나면 다음과 같이 합니다.

curl -sS -X POST -H "Authorization: Bearer $RUNLOT_OPERATOR_TOKEN" http://$RUNLOT_CP_PRIVATE_ADDR:8081/v1/era/activate
sudo systemctl restart node-agent          # on every node

활성화하면 데이터베이스를 현재 상태 그대로 받아들이고, 노드가 확인하는 era 번호를 올립니다. 계획된 복원도 같은 방식으로 진행해야 합니다. 복원하는 동안 control plane을 중지하고, 의도적으로 이 상태에서 시작하도록 표식 파일을 작성합니다. 전체 절차는 지원 계약과 함께 제공됩니다.

apt upgrade처럼 PostgreSQL을 단순히 재시작하는 경우에는 이 상태가 발동하지 않습니다. 되감김을 감지하는 세 가지 증거는 재시작 후에 모두 정상으로 읽히며, 단순 재시작은 기록된 뒤 그대로 받아들여집니다.

접근 권한 없는 지원

저희는 고객의 설치 환경에 접근할 수 없으며 텔레메트리도 없습니다. 대신 다음을 요청드립니다.

sudo runlot-admin support-bundle --out bundle.tar.gz

내용은 코드에 정의된 목록을 직렬화한 것으로, 버전과 패키지 다이제스트, 라이선스 상태(라이선스 자체는 제외), 노드 및 배치 테이블, 최근 1시간의 control plane 로그, 설치 전 점검 출력, 마이그레이션 원장이 들어 있습니다. 마스터 키, 시크릿, 고객의 코드, 데이터베이스 내용, 운영자 목록 외의 사용자 이메일은 절대 포함되지 않습니다.

sudo runlot-admin preflight cp        # or `node`

설치 전 점검은 모든 번들의 첫 페이지이자 설치가 가장 먼저 실행하는 단계입니다. 꺼져 있는 통합 기능을 나열하므로, "켜져 있다고 생각했다"는 상황에서도 확인할 수 있는 줄이 남습니다.

메트릭은 RUNLOT_METRICS_TOKEN 뒤에 있는 Prometheus 엔드포인트이며, 차트는 ServiceMonitor를 제공합니다. 로그는 수집기용으로 journald 또는 stdout에 JSON으로 출력됩니다. 어디로든 데이터를 보내는 에이전트는 제공하지 않습니다.