배포 및 업그레이드

첫 번째 로컬 설정의 경우 다음을 따르세요. 첫 번째 요청. 배포 방법을 선택하거나, 원격 인스턴스를 구성하거나, 업그레이드할 때 이 페이지를 사용하세요.

SubLane은 내장된 프런트엔드와 SQLite이 있는 하나의 프로세스로 실행됩니다. 프로덕션에는 Node.js, Redis 또는 별도의 프록시 서비스가 필요하지 않습니다. 각 데이터 디렉터리에 대해 하나의 인스턴스를 실행합니다.

게시된 Docker 이미지

태그된 릴리스 게시 ghcr.io/murongg/sublane ~을 위한 linux/amd64 그리고 linux/arm64. Docker은 호스트 아키텍처를 선택합니다. 이미지는 공개되어 있으며 GHCR에 로그인하지 않고도 가져올 수 있습니다. 배포에는 Compose와 함께 Docker이 필요합니다. 소스 체크아웃, Go, Node.js 또는 로컬 이미지 빌드가 필요하지 않습니다.

아래의 매뉴얼 Compose 예시는 게시된 내용을 고정합니다. 0.1.0-rc.1 사전 출시. 세트 SUBLANE_IMAGE 수동 배포의 경우 명시적으로: Compose 기본값은 latest, 안정적인 릴리스로만 게시됩니다.

반복 가능한 배포에는 고정 버전이나 다이제스트를 사용하세요. GHCR에 나타나는 새 이미지는 실행 중인 컨테이너를 자동으로 업데이트하지 않습니다.

스크립트 설치

터미널에서 설치 프로그램을 실행하여 Docker 또는 게시된 Linux 바이너리, 일반 인스턴스 또는 읽기 전용 데모를 선택한 다음 프록시 없음, Caddy 또는 Nginx를 선택합니다.

위/아래 또는 숫자 키를 사용하여 옵션을 강조 표시한 다음 Enter를 눌러 확인합니다. 기본적으로 첫 번째 옵션이 선택되어 있습니다. 기본 터미널은 번호가 매겨진 텍스트 프롬프트를 사용합니다. 도메인은 텍스트 입력으로 유지되며 설치 프로그램은 배포 전 확인을 위해 생성된 구성을 표시합니다. 제공된 플래그는 해당 선택을 건너뜁니다. --non-interactive 모든 프롬프트를 비활성화합니다.

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash

없이 --version, 스크립트는 GitHub의 최신 안정 릴리스를 선택합니다. 안정적인 릴리스가 없는 경우에만 초안을 제외하고 가장 최근에 게시된 시험판을 선택합니다. 선택한 구체적인 버전은 생성된 구성에 저장되므로 다시 시작해도 자동으로 버전이 변경되지 않습니다. GitHub API 오류는 채널 대체를 트리거하는 대신 설치를 중지합니다.

스크립트는 선택한 릴리스 아티팩트를 확인합니다. SHA256SUMS 새로 설치하기 전에 ./sublane 예배 규칙서. 배쉬, 컬 및 둘 중 하나 sha256sum 또는 shasum 필수입니다. 자동 버전 선택에는 추가로 jq가 필요합니다. Docker 모드에는 Docker Compose가 필요하며 컨테이너가 건강해질 때까지 기다립니다. 바이너리 모드는 Linux amd64/arm64를 지원하고 작동하는 시스템 사용자 관리자가 필요하며 사용자 서비스를 활성화하고 /readyz. Docker, Caddy 또는 Nginx를 설치하지 않으며 소스에서 빌드하지 않습니다.

메시지 없이 게시된 버전, 새 디렉터리 및 호스트 포트를 선택하려면 다음을 수행하세요.

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- \
  --version 0.1.0-rc.1 --dir ./team-gateway --port 8088 --runtime docker --proxy none --non-interactive

버전 태그에는 다음이 포함될 수 있습니다. v. 백엔드 포트는 계속 바인딩되어 있습니다. 127.0.0.1. 사용할 수 있는 터미널이 없으면 프록시 없이 Docker을 사용하는 일반 인스턴스가 기본값으로 유지됩니다. 통과하다 --runtime, --proxy, 또는 --demo 다른 모드를 선택하려면 원격 서버의 경우 초기 설정에 SSH 터널을 사용하거나 HTTPS 역방향 프록시.

설치 프로그램이 사용하는 ss (iproute2에서) 또는 lsof 다운로드하기 전과 배포를 생성하기 전에 다시 선택한 백엔드 포트를 확인합니다. 루프백 또는 와일드카드 리스너가 이미 해당 포트를 사용하는 경우 중지되고 사용되지 않는 포트를 선택하라는 메시지가 표시됩니다. --port, 예를 들어 --port 8088. 둘 다 사용할 수 없는 경우 두 유틸리티 중 하나를 설치하십시오. 포트 80 또는 443의 기존 프록시는 백엔드 포트 8080을 사용한 설치를 차단하지 않습니다. 검사에서는 포트를 예약할 수 없습니다. 시작 상태 확인은 이후에 나타나는 충돌을 여전히 포착합니다.

예를 들어 게시된 바이너리를 선택하고 공개 도메인에 대한 Caddyfile을 생성합니다.

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- \
  --runtime binary --proxy caddy --domain sublane.example.com

--domain Caddy 또는 Nginx에서는 선택 사항입니다. 이것이 없으면 생성된 프록시는 다음을 수신합니다. 127.0.0.1:80 HTTP 이상 및 SUBLANE_PUBLIC_URL 설정되지 않은 상태로 유지됩니다. 도메인을 사용하면 설치 프로그램이 설정합니다. SUBLANE_PUBLIC_URL=https://<domain> HTTPS 프록시 구성을 생성합니다. 설치하기 전의 구성을 보여주지만 프록시 서비스에 복사하거나 다시 로드하지 않습니다.. 생성된 내용을 검토하세요. Caddyfile 또는 nginx.conf 직접 적용해 보세요. Nginx 템플릿은 다음의 인증서 파일을 가정합니다. /etc/letsencrypt/live/<domain>/.

Docker의 경우 설치 프로그램은 선택한 이미지, 포트 및 고유한 Compose 프로젝트 이름을 .env. 함께 보관하세요 docker.compose.yaml; 배포의 데이터 볼륨을 식별합니다. 바이너리 모드의 경우 다음을 생성합니다. sublane.env, start.sh 및 링크된 시스템 사용자 유닛; 데이터는 비공개로 유지됩니다. data/ 예배 규칙서. 유지 기능이 활성화되지 않은 경우 사용자가 로그아웃하면 시스템 사용자 서비스가 중지될 수 있습니다. 확인하다 loginctl show-user "$USER" -p Linger 무인 작업이 필요한 경우 지연을 준비하십시오. 새로 설치하면 기존 디렉토리와 심볼릭 링크가 거부됩니다. 아래 설명된 대로 기존 스크립트 관리 설치를 동일한 스크립트로 업데이트할 수 있습니다. 시작에 실패하면 구성 및 생성된 모든 데이터가 검사를 위해 유지됩니다.

스크립트 관리 설치 업데이트

첫 번째 데이터베이스 백업 내보내기 및 확인, 타겟 릴리스 노트를 읽어보세요. 설치 디렉터리의 상위에서 스크립트를 실행합니다. 터미널에서 기존 대상이 제공하는 기존 인스턴스 업데이트 배포하기 전에 확인을 요청합니다. 명시적으로 업데이트를 선택하려면:

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- \
  --update --dir ./sublane

없이 --version, 업데이트는 설치와 동일한 안정/시험판 선택을 사용합니다. 추가하다 --version <published-version> 릴리스를 고정하려면 --wait-timeout 120 준비 상태를 변경하려면 기다리거나 --non-interactive 확인을 건너뛰려면 스크립트는 기존 런타임을 감지합니다. 다음과 같은 설치 전용 플래그 --runtime, --port, --proxy 그리고 --demo 업데이트 중에 거부됩니다.

Docker 업데이트는 Compose 파일과 프로젝트 이름을 유지하고 변경만 합니다. SUBLANE_IMAGE ~에 .env, 선택한 이미지를 가져오고 상태 대기를 사용하여 서비스를 다시 만듭니다. 바이너리 업데이트는 아카이브를 확인하고, 실행 파일과 패키지된 문서/라이선스 파일을 교체하고, 기존 시스템 사용자 유닛을 다시 시작하고, /readyz. 환경 파일, 실행 프로그램, 사용자 장치, 프록시 구성 및 데이터 경로가 보존됩니다. 서비스의 기존 포트가 사용될 것으로 예상되므로 업데이트에서는 새 설치 포트 확인을 실행하지 않습니다.

다운로드, 체크섬, 구성 및 이미지 가져오기 실패로 인해 배포된 파일은 변경되지 않습니다. 교체하기 전에 스크립트는 이전 프로그램/구성 파일을 개인 폴더에 저장합니다. .update-backup.* 설치 내의 디렉터리를 검색하고 해당 경로를 인쇄합니다. 이러한 파일은 데이터베이스 백업이 아닙니다. 실패한 시작은 검사를 위해 해당 데이터와 현재 배포 데이터를 유지하고 실패를 보고하며 잠재적으로 마이그레이션된 데이터베이스에 대해 이전 버전을 자동으로 실행하지 않습니다. 따르다 복구 및 롤백 데이터 복원이 필요할 때. 동시 업데이트가 거부됩니다. 프로세스가 강제로 종료된 경우 제거 .update-lock 업데이트가 활성 상태로 유지되지 않음을 확인한 후에만 가능합니다.

이 업데이트 경로는 스크립트로 생성된 설치를 지원합니다. 수동 배포 및 추가 Compose 재정의 파일이 필요한 배포에서는 수동 업그레이드 절차, 후속 시작 시 모든 재정의를 포함합니다.

스크립트를 실행하기 전에 검토하려면 다음을 사용하여 다운로드하세요. curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh -o install.sh, 그런 다음 실행 bash install.sh --help 또는 bash install.sh 검토한 후.

수동 Compose 배포

배포 디렉터리 생성 및 다운로드 docker.compose.yaml 선택한 것 중에서 GitHub 출시:

mkdir sublane && cd sublane
curl -fsSL https://github.com/murongg/SubLane/releases/download/v0.1.0-rc.1/docker.compose.yaml -o docker.compose.yaml

해당 디렉터리에 Compose을 만듭니다. .env 다시 시작하고 업그레이드해도 선택한 이미지 버전을 유지하려면 다음 파일을 사용하세요.

SUBLANE_IMAGE=ghcr.io/murongg/sublane:0.1.0-rc.1
SUBLANE_BIND_ADDRESS=127.0.0.1
SUBLANE_PORT=8080
SUBLANE_LOG_LEVEL=info
# Add this when using an HTTPS reverse proxy:
# SUBLANE_PUBLIC_URL=https://sublane.example.com
# In Docker, first identify the proxy source IP as seen inside the container:
# SUBLANE_TRUSTED_PROXIES=<proxy-source-ip>/32

Compose 읽기 .env 보간을 위해; 독립 실행형 Go 애플리케이션이 로드되지 않습니다. .env 그 자체. 불변 다이제스트를 전체로 사용할 수 있습니다. SUBLANE_IMAGE 태그 대신 값을 사용하세요.

docker compose -f docker.compose.yaml pull
docker compose -f docker.compose.yaml up -d
docker compose -f docker.compose.yaml ps
docker compose -f docker.compose.yaml logs --tail=100 sublane

열려 있는 http://127.0.0.1:8080 회원 액세스를 허용하기 전에 관리자 설정을 완료하세요. 원격 호스트의 경우 초기 설정에 SSH 터널을 사용합니다. 기본 Compose 매핑은 루프백 상태로 유지됩니다. 출판 0.0.0.0 명시적인 연산자 선택입니다.

이미지는 기존 알파인처럼 실행됩니다. sublane 서비스 계정에는 CA 인증서, 라이선스 공지, 확인 사항이 포함됩니다. /readyz. Compose은 쓰기 가능한 64MiB의 읽기 전용 루트 파일 시스템을 사용합니다. /tmp SDK 스크래치 파일용 tmpfs, Linux 기능 삭제, 제한된 컨테이너 로그 및 30초 중지 유예 기간. 컨테이너는 포트 8080에서 수신 대기합니다. 다음을 통해 호스트 포트를 사용자 정의하세요. SUBLANE_PORT. 내부 수신 포트를 직접 재정의하는 경우 상태 확인 및 포트 매핑도 변경하세요.

영구 데이터

명명된 sublane-data 볼륨 보유 /data/sublane.db, 해당 WAL 파일 및 /data/credentials.key. 데이터베이스와 함께 암호화 키를 보관하세요. 기존 Compose 서비스/볼륨 키는 유지되므로 이전 소스 빌드의 업그레이드는 동일한 Compose 프로젝트에서 실행될 때 동일한 볼륨을 계속 사용합니다.

Compose 프로젝트 이름/디렉토리를 일관되게 유지하십시오. 이를 변경하면 다른 이름의 볼륨이 생성되고 기존 인스턴스가 초기화되지 않은 것처럼 보일 수 있습니다. 달리지 마세요 docker compose -f docker.compose.yaml down -v 업그레이드 또는 복구 시: 데이터 볼륨이 제거됩니다. 바인드 마운트가 지원되지만 해당 호스트 권한을 통해 이미지의 루트가 아닌 계정이 마운트된 디렉터리에 쓸 수 있도록 해야 합니다. 호스트 경로 소유권이 의도적이지 않은 한 기본 명명된 볼륨을 선호합니다.

소스에서 빌드

대신 로컬로 빌드하려면 저장소를 복제하고 소스 빌드 재정의를 사용하세요.

git clone https://github.com/murongg/SubLane.git
cd SubLane
docker compose -f docker.compose.yaml -f docker.compose.build.yaml up --build -d

해당 배포에 대한 후속 명령에 두 파일을 모두 사용합니다. 빌드 메타데이터를 설정하려면 다음 안내를 따르세요.

VERSION=0.1.0-dev REVISION=$(git rev-parse HEAD) \
  docker compose -f docker.compose.yaml -f docker.compose.build.yaml build

Dockerfile은 Go를 컴파일합니다. TARGETOS/TARGETARCH 기본 빌드 단계에서 생성되므로 x86-64에서 ARM64를 빌드해도 컴파일러 또는 프런트엔드 빌드를 에뮬레이트하지 않습니다. 구성된 Buildx 빌더를 사용하여 다중 플랫폼 이미지를 빌드할 수 있습니다.

docker buildx build --platform linux/amd64,linux/arm64 \
  --build-arg VERSION=0.1.0-dev --output type=oci,dest=dist/sublane.oci.tar .

만들다 dist 첫 번째. 일반 로컬 빌드/로드는 일반적으로 하나의 플랫폼을 대상으로 합니다. Docker을 참조하세요 크로스 컴파일 지침.

독립형 Linux 바이너리

귀하의 머신과 일치하는 아카이브를 다운로드하고 SHA256SUMS 동일한 릴리스에서:

• sublane_VERSION_linux_amd64.tar.gz: x86-64.
• sublane_VERSION_linux_arm64.tar.gz: AArch64.

Linux에서는 다운로드한 파일을 확인하고 새 버전의 디렉터리에 아카이브를 추출한 후 다음을 실행합니다.

sha256sum --check --ignore-missing SHA256SUMS
./sublane --version
SUBLANE_ADDR=127.0.0.1:8080 SUBLANE_DATA_DIR=/srv/sublane/data ./sublane

아카이브에는 실행 파일, AGPL 및 타사 라이센스 텍스트, Compose 파일, 환경 예제 및 배포/백업 문서가 포함되어 있습니다. 버전이 지정된 실행 가능 디렉터리 외부에 데이터 디렉터리를 유지하고 서비스 사용자가 쓸 수 있도록 비공개로 만들고 지속적인 작업을 위해 프로세스 감독자를 사용합니다. 안내 설치 프로그램은 시스템 사용자 서비스를 사용하여 이 설정을 수행할 수 있습니다. 게이트웨이를 루트로 실행하지 마십시오.

데모 모드

설치 프로그램이 제공하는 일반 인스턴스 또는 읽기 전용 데모 런타임 선택 후. 일반 모드는 기본값으로 유지됩니다. 데모 모드를 직접 선택하려면:

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- --demo

--demo 둘 다와 함께 작동 --runtime docker 그리고 --runtime binary. 추가하다 --non-interactive 나머지 선택 항목에는 기본값을 사용합니다. 설치 프로그램이 작성합니다. SUBLANE_DEMO=true 에게 .env Compose의 경우 또는 sublane.env 바이너리 서비스의 경우 설치 후 공개 데모 로그인을 표시합니다. 상속받은 SUBLANE_DEMO 설치 프로그램이 선택한 모드를 재정의하지 않습니다.

선택한 릴리스의 검증된 구성에 데모 지원이 있어야 합니다. 설치 프로그램은 컨테이너를 가져오거나 시작하거나 서비스를 활성화하기 전에 이전 릴리스를 거부합니다. 사용 --version 데모 지원이 포함된 릴리스를 선택합니다. 일반 인스턴스로 돌아가지 않습니다.

데모 지원이 포함된 빌드에서 다음을 사용하여 읽기 전용 데모를 시작하세요.

SUBLANE_DEMO=true ./sublane

일반 서버 주소를 열고 선택하십시오. 데모 살펴보기또는 사용자 이름으로 로그인 demo 그리고 비밀번호 sublane-demo. 애플리케이션에는 명확하게 레이블이 지정된 샘플 구독 계정, 풀, 멤버, API 주요 메타데이터, 요청 기록 및 30일 사용량이 표시됩니다. 탐색, 필터, 언어 및 테마 기본 설정은 정상적으로 작동합니다. 양식을 검사할 수 있지만 쓰기, 자격 증명 공개, OAuth, 백업 및 모든 게이트웨이 호출(WebSocket 포함)이 차단됩니다. 로그인과 로그아웃은 계속 가능합니다.

시작할 때마다 새로운 개인 임시 데이터베이스와 암호화 키가 생성됩니다. 데모 모드가 열리지 않습니다 SUBLANE_DATA_DIR, 가격 캐시 또는 실제 자격 증명을 수집하며 공급자나 릴리스/가격 서비스에 연락하지 않습니다. 정상 종료는 임시 파일을 제거합니다. 갑작스러운 살인은 sublane-demo-* 운영 체제의 임시 디렉터리에 있는 디렉터리입니다. 다시 시작하면 최근 날짜로 예제가 다시 생성됩니다. 데모를 중지하고 설정을 해제하세요. SUBLANE_DEMO 일반 설치를 재개하려면

개발을 위해 다음을 사용하십시오. SUBLANE_DEMO=true make dev. 이 버전의 Compose 파일을 사용하여 SUBLANE_DEMO=true ~에 .env 컨테이너를 다시 만듭니다. 데모 지원이 없는 기존 게시 버전을 먼저 업그레이드하거나 다시 빌드해야 합니다. 일반 수신 주소, 외부 원본 및 신뢰할 수 있는 프록시 설정은 계속 적용됩니다.

런타임 구성

독립형 서비스는 이러한 프로세스 환경 변수를 읽습니다. .env.example 예시를 나열합니다. 로드되지 않습니다. .env 자동으로 파일. Compose 읽기 .env 자체 보간을 위해 구성된 환경을 컨테이너에 전달합니다.

Docker 이미지는 수신 주소를 무시합니다. 0.0.0.0:8080 및 데이터 디렉토리 /data. SUBLANE_IMAGE, SUBLANE_BIND_ADDRESS 그리고 SUBLANE_PORT Compose만 구성하십시오. SQLite은 새로운 데이터베이스에서 통합 스키마를 초기화하고 단일 데이터베이스 연결을 사용합니다.

시작 시 새 데이터베이스를 초기화하고 지원되는 기존 데이터베이스에는 누락된 마이그레이션을 순서대로 적용합니다. 001_settings.sql을 포함한 초기 비호환 구조는 거부되므로 기존 디렉터리를 보존하고 새 디렉터리를 사용하세요. 업그레이드 전에 백업을 내보내 검증하세요. 이미지만 바꿔서는 마이그레이션된 데이터를 되돌릴 수 없습니다.

SUBLANE_MAX_REQUEST_BODY_MB 게이트웨이 HTTP 요청, WebSocket 메시지 및 재구성된 대화 컨텍스트에 적용됩니다. Responses 및 스트림 이벤트는 별도의 8MiB 제한을 유지합니다. 요청 제한을 변경한 후 독립 실행형 서비스를 다시 시작하거나 컨테이너를 다시 만들고 역방향 프록시 본문 제한을 새 값에 맞춥니다.

재정의하는 경우 SUBLANE_PRICING_URL, 또한 설정됨 SUBLANE_PRICING_HASH_URL 일치하는 SHA-256 파일에 추가하여 문서 무결성 검사를 활성화합니다. 해시 URL이 없는 맞춤 가격 URL은 가져와서 구문 분석하지만 해시 확인은 되지 않습니다.

게이트웨이 런타임을 변경하려면 다시 시작하거나 컨테이너를 다시 만들어야 합니다. 현재 Compose 파일은 이러한 변수를 통과합니다. 스크립트 관리 업데이트는 기존 Compose 파일을 보존합니다. 의존하기 전에 이전에 저장된 Compose 파일에 새 환경 항목을 추가하십시오. .env 재정의. 계정/멤버 동시성 설정은 별도로 유지됩니다.

HTTPS 역방향 프록시

세트 SUBLANE_PUBLIC_URL 정확한 외부 원점(예: https://sublane.example.com, 환경 변경 사항이 적용되도록 서비스를 다시 만듭니다. 폴백은 요청의 Host 헤더에서 원본을 파생하므로 이는 역방향 프록시 뒤에 필요합니다. 구성된 원본은 브라우저 요청 확인 및 보안 세션 쿠키에 사용됩니다. 원본 호스트 헤더를 전달하고 스트리밍 및 WebSocket 업그레이드를 유지합니다.

세트 SUBLANE_TRUSTED_PROXIES 자신의 프록시 홉의 CIDR 주소로. IPv4 루프백을 통해 도달한 독립형 SubLane 바이너리의 경우 다음을 사용합니다. 127.0.0.1/32 (추가하다 ::1/128 IPv6 루프백의 경우). Docker 컨테이너는 호스트 프록시를 루프백이 아닌 브리지 주소로 볼 수 있습니다. 통과하지 않는 한 설치 프로그램은 Docker 모드에서 이 값을 비워 둡니다. --trusted-proxies 실제로는 주소 SubLane이 표시됩니다. 프록시 컨테이너의 경우 고정 주소 또는 범위가 엄격하게 제한된 전용 프라이빗 서브넷을 사용합니다. SubLane 무시 X-Forwarded-For 직접 피어가 이 목록과 일치하지 않는 한 로그인 제한을 위해 체인에서 가장 오른쪽에 있는 신뢰할 수 없는 IP를 사용합니다. 이것이 구성되면 프록시로 제한된 SubLane에 대한 직접 액세스를 유지합니다. 이것이 없으면 하나의 프록시 뒤에 있는 모든 사용자가 프록시의 로그인 제한을 공유합니다.

동일한 호스트에서 실행되는 Caddy 프록시의 경우:

sublane.example.com {
    reverse_proxy 127.0.0.1:8080
}

캐디는 TLS 및 WebSocket 업그레이드를 처리하고 SSE 응답을 자동으로 플러시합니다. 클라이언트 연결 끊김으로 인해 업스트림 작업이 취소될 수 있도록 기본 플러시 동작을 유지합니다. 부정적인 flush_interval 취소 동작을 변경합니다. 참조 캐디 역방향 프록시 참조. 프록시가 다른 컨테이너인 경우 Compose 서비스 이름을 사용합니다. sublane:8080 공유 네트워크에서; 127.0.0.1 프록시 컨테이너 내부는 해당 컨테이너 자체를 나타냅니다.

기존 Nginx 설치의 경우 지도를 http 컨텍스트를 파악하고 HTTPS 서버 블록 내에서 다음 위치를 사용하세요.

map $http_upgrade $sublane_connection {
    default upgrade;
    ''      close;
}

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $sublane_connection;
    proxy_buffering off;
    proxy_read_timeout 650s;
    proxy_send_timeout 650s;
    client_max_body_size 128m;
}

# Web backup uploads/downloads can be larger and last up to 15 minutes.
location /api/settings/backup/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_request_buffering off;
    proxy_buffering off;
    proxy_read_timeout 950s;
    proxy_send_timeout 950s;
    client_max_body_size 256m;
}

상위 Nginx 서버에서 HTTPS 인증서를 구성합니다. 그만큼 Nginx WebSocket 가이드 명시적인 업그레이드 헤더에 대해 설명합니다. 한도는 다른 프록시 계층에서도 요청/백업 크기를 허용해야 합니다. 게이트웨이의 자체 인증 및 본문 제한은 그대로 유지됩니다.

치받이

1. 릴리스 노트를 검토하고 현재 이미지 버전/다이제스트를 기록합니다.

2. 일관된 백업을 내보내고 데이터 볼륨에서 복사합니다.

   docker compose -f docker.compose.yaml exec sublane sh -c 'mkdir -p /data/backups'
   docker compose -f docker.compose.yaml exec sublane sublane backup --output /data/backups/pre-upgrade.sublane-backup.tar.gz
   docker compose -f docker.compose.yaml exec sublane sublane backup verify --input /data/backups/pre-upgrade.sublane-backup.tar.gz
   docker compose -f docker.compose.yaml cp sublane:/data/backups/pre-upgrade.sublane-backup.tar.gz ./pre-upgrade.sublane-backup.tar.gz
   chmod 600 ./pre-upgrade.sublane-backup.tar.gz

   각 업그레이드마다 새 파일 이름을 사용하십시오. 기존 백업은 덮어쓰지 않습니다. 아카이브에는 암호화 키가 포함되어 있으며 개인 저장소에 속합니다.

3. 변화 SUBLANE_IMAGE ~에 .env 선택한 버전으로 이동한 다음 가져와서 다시 만듭니다.

   docker compose -f docker.compose.yaml pull
   docker compose -f docker.compose.yaml up -d
   docker compose -f docker.compose.yaml ps
   docker compose -f docker.compose.yaml logs --tail=100 sublane

4. 상태, 로그인, 예상 계정/풀/키 및 명시적으로 승인된 클라이언트 호출을 확인하세요. 새로운 데이터베이스는 시작 시 통합 SQLite 스키마를 받습니다. 이미지 상태는 실제 공급자 인증이 아닌 프로세스/데이터베이스 준비 상태를 확인합니다.

복구 및 롤백

이미지 태그를 변경하는 것만으로는 데이터베이스 롤백이 아닙니다. 릴리스에서 스키마를 마이그레이션한 경우 업그레이드 전 아카이브를 의도한 이전 바이너리/이미지가 있는 새 디렉터리로 복원한 다음 현재 서비스를 중지하고 복원된 디렉터리로 전환하세요. 확인이 완료될 때까지 원래 볼륨을 보관합니다. 두 프로세스가 동일한 SQLite 디렉터리를 공유하지 않도록 하세요.

그만큼 백업 가이드 CLI 및 웹 복원 준비와 Compose 재정의를 다룹니다. /data/restore-ready. 해당 디렉터리가 활성 상태인 동안 나중에 시작할 때 복원 재정의를 계속 사용하세요. 최신 스키마의 백업은 이를 인식하지 못하는 이전 릴리스에서 열 수 없습니다.

컨테이너 검증

Docker 엔진이 실행 중인 경우:

docker compose -f docker.compose.yaml config --quiet
docker compose -f docker.compose.yaml -f docker.compose.build.yaml config --quiet
docker buildx build --load --build-arg VERSION=0.0.0-test -t sublane:smoke .
bash scripts/container-smoke.sh sublane:smoke 0.0.0-test

연기 스크립트는 네트워킹이 비활성화된 상태에서 일회용으로 명명된 볼륨과 컨테이너를 생성합니다. 상태, 버전, 루트가 아닌 실행, 읽기 전용 런타임 경로, 합성 자격 증명을 사용한 최초 실행 설정, 키 권한, 백업/확인/복원 및 다시 시작한 후 지속성을 확인합니다. 해당 임시 리소스만 제거합니다. 업스트림 공급자에게 연락하거나 기존 인스턴스 데이터를 사용하지 않습니다. CI는 기본 amd64 및 arm64 실행기에서 동일한 검사를 실행합니다.