Webship 설치, 구성 및 자동화.

제품 개요

네트워크와 애플리케이션 사이의 한 대의 서버.

Webship는 셀프호스팅 Rust 엣지 및 정적 웹 서버입니다. 하나의 런타임이 최신 프로토콜을 종료하고, 엣지 정책을 적용하며, 파일을 제공하고, 애플리케이션 요청을 프록시합니다.

빠른 시작

릴리스 바이너리에서 정상 동작하는 리스너까지.

루프백에서 시작하고, 바인딩 전에 모든 것을 검증하며, 공용 트래픽을 추가하기 전에 내장 헬스 응답을 확인합니다.

1. 1

   파일 준비

   릴리스 바이너리, TOML 구성 파일, 정적 루트, 그리고 구성된 TLS 인증서 및 키 파일을 호스트에 배치합니다.

2. 2

   검증 및 확인

   두 구성 명령을 모두 실행합니다. 첫 번째 오류를 수정하고 시작 전에 수정된 실제 결과를 확인합니다.

3. 3

   개인적으로 시작

   선택한 TOML 파일로 Webship를 시작합니다. 사이트가 안전한 공개 트래픽 준비가 되면 완전한 인증서 쌍 또는 자동 TLS를 추가합니다.

4. 4

   런타임을 확인합니다.

   로컬에서 GET /health를 호출합니다. 그런 다음 정적 경로, TLS, 프록시 경로, 보안 규칙 및 인증된 모니터링을 테스트합니다.

listen = "127.0.0.1:4433"
workers = 4
root = "./public"

/usr/local/bin/webship --check-config --config /etc/webship/production.toml
/usr/local/bin/webship --print-effective-config --config /etc/webship/production.toml

/usr/local/bin/webship --config /etc/webship/production.toml
curl --http3-only --insecure https://127.0.0.1:4433/health

AI 에이전트를 위한 빠른 시작 가이드

AI 에이전트를 다섯 줄로 Webship에 연결합니다.

Claude Code, OpenAI, DeepSeek 또는 호환 가능한 모든 MCP 클라이언트를 개인 SSH 터널을 통해 연결하세요. 에이전트는 공개 리스너를 공유하거나 제어 자격 증명을 인터넷 트래픽에 노출하지 않고 인증된 운영 표면을 받습니다.

{
  "mcpServers": {
    "webship": { "url": "https://localhost:19443/mcp",
      "headers": { "Authorization": "Bearer <token>" } }
  } }

정적 제공

프로토콜 인식 기본값으로 디렉토리를 제공합니다.

글로벌 또는 사이트별로 루트를 설정하십시오. TLS 사이트는 기본적으로 HTTP/3만 사용하며; 일반 텍스트 사이트는 기본적으로 HTTP/1.1 및 H2C를 사용합니다. 각 사이트별로 HTTP/1.1, HTTP/2, HTTP/3를 독립적으로 재정의할 수 있습니다.

[[sites]]
domain = "app.example.com"
root = "/srv/app"
listen = "0.0.0.0:443"

[sites.protocols]
h1 = true
h2 = true
h3 = true

내장 라우터는 GET 및 HEAD, 바이트 범위, 조건부 요청, 검증기, 그리고 .br, .zst, .gz 사이드카를 지원합니다. 기본적으로 점(.) 파일 경로는 거부됩니다; .well-known은 계속 사용 가능합니다.

애플리케이션 트래픽

요청을 하나 이상의 업스트림으로 라우팅합니다.

리버스 프록시를 활성화하고, 호스트와 경로를 일치시킨 다음, 마지막 무조건 정책을 정의합니다. Webship는 제한된 풀, 헬스체크, 로드 밸런싱, 서킷 브레이커, 안전한 바디 없는 재시도, 웹소켓, 캐싱을 지원합니다.

[reverse_proxy]
enabled = true

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/api"
strip_path_prefix = true
upstreams = ["127.0.0.1:8080", "127.0.0.1:8081"]

[[reverse_proxy.policies]]
name = "default"
hosts = []
path_prefixes = ["/"]
methods = []
max_body_bytes = 1048576
total_timeout_ms = 30000

TLS 및 HTTP/3

수동 인증서를 사용하거나 Webship가 관리하도록 하십시오.

Webship는 TLS 1.3을 허용합니다. HTTP/3는 일치하는 UDP 리스너 위에서 실행됩니다; TLS 사이트도 TCP 호환성이 필요할 때는 HTTP/1.1 또는 HTTP/2을 명시적으로 활성화합니다.

listen = "0.0.0.0:443"

[automatic_tls]
enabled = true
directory_url = "https://acme-v02.api.letsencrypt.org/directory"
cache_dir = "/var/lib/webship/acme"
contacts = ["mailto:ops@example.com"]
accept_terms_of_service = true

[[sites]]
domain = "app.example.com"
root = "/srv/app"

엣지 정책

보안 기준을 그대로 유지하십시오.

Webship는 기본적으로 주요 보호 계층을 활성화합니다. 워크로드에 맞게 제한을 조정하고, 규칙 또는 헤더 정책이 변경될 때마다 검증하세요.

[ddos]
enabled = true
mode = "normal"
requests_per_minute = 600
burst = 100
block_seconds = 300

[security.response_headers]
enabled = true
nosniff = true
frame_deny = true
referrer_no_referrer = true
hsts = "max-age=31536000; includeSubDomains"
content_security_policy = "default-src 'self'; frame-ancestors 'none'"

정상 트래픽에는 일반 모드를 사용하고, 보다 엄격한 활성 공격 대응이 필요할 때는 under_attack를 사용하며, 탐침 및 명시적으로 허용된 경로만 남겨두어야 할 경우에는 lockdown을 사용하십시오.

비공개 진단

제어 플레인을 노출하지 않고 엣지를 검사하십시오.

통계 및 Prometheus 메트릭은 별도의 인증된 리스너에서 실행됩니다. 어느 한 엔드포인트가 활성화될 때마다 계측이 활성화되어야 합니다.

[observability]
instrumentation = true
stats = true
metrics = true
listen = "127.0.0.1:9090"
token = "replace-with-at-least-32-random-printable-ascii-characters"

안전한 작업

의도적으로 다시 로드하십시오. 롤백을 가까이 유지하십시오.

kill -HUP "$(pidof webship)"
/usr/local/bin/webship update --config /etc/webship/production.toml
sudo systemctl daemon-reload
sudo systemctl enable --now webship
sudo systemctl status webship

프로파일 기반 최적화

학습과 프로덕션을 혼동하지 않고 타겟 네이티브 프로파일 수집

모든 Webship 1.1 대상에는 대표적인 트래픽 아래에서 대상 고유 LLVM 프로필 데이터를 수집하기 위한 별도의 계측된 CLI가 있습니다. 정확한 버전과 대상 트리플을 사용하고, 중요한 경로와 프로토콜을 실행하며, 각 .profraw 파일을 플러시할 수 있도록 프로세스를 정상적으로 중지하세요.

1. 1

   정확한 타겟 선택

   최적화하려는 런타임과 정확히 일치하는 릴리즈 버전 및 Rust 타겟 트리플을 가진 PGO 학습 CLI를 다운로드합니다. 먼저 게시된 SHA-256을 확인합니다.

2. 2

   대표 트래픽 캡처

   LLVM_PROFILE_FILE을 쓰기 가능한 디렉토리로 설정하고, 검증된 실제 구성 복사본으로 교육용 CLI를 시작한 다음, 대표적인 직접 및 리버스 프록시 트래픽을 재생하고 Webship을 정상적으로 중지하세요.

3. 3

   원시 프로파일 병합

   릴리즈용으로 기록된 컴파일러 생성 llvm-profdata를 사용합니다. 생성된 모든 .profraw 파일을 하나의 sparse webship.profdata 파일로 병합합니다.

4. 4

   재빌드 및 게이트

   병합된 프로파일을 생성한 정확한 소스, 컴파일러, 암호 제공자, 기능 세트 및 타겟에만 적용합니다. 승격 전에 정확성과 성능 게이트를 실행합니다.

mkdir -p ./profiles
export LLVM_PROFILE_FILE="$PWD/profiles/webship-%p-%m.profraw"
./webship-pgo-training-1.1.0-<target> --config ./webship.toml

New-Item -ItemType Directory -Force ./profiles
$env:LLVM_PROFILE_FILE = "$PWD/profiles/webship-%p-%m.profraw"
.\webship-pgo-training-1.1.0-<target>.exe --config .\webship.toml

llvm-profdata merge -sparse ./profiles/*.profraw -o ./webship.profdata

명령줄 참조

작은 표면, 명시적 시작

webship [OPTIONS] | webship update [OPTIONS]

-c, --config PATH

TOML 파일을 선택하세요. 존재하지 않는 경우, Webship가 개인 로컬호스트 TLS 아이덴티티로 생성합니다.

--check-config

전체 구성을 검증하고 리스너를 시작하지 않고 종료합니다.

--print-effective-config

비밀을 제거한 병합된 유효 구성을 출력합니다.

update

서명된 커뮤니티 매니페스트를 검증하고, 이 정확한 플랫폼 타겟을 선택하며, 새 버전이 존재하면 설치합니다.

--help / --version

명령어 도움말이나 설치된 Webship 버전을 출력합니다.

일반적인 실패 모드

구성에서 시작한 후 외부로 이동합니다.

1. --check-config를 실행하고 보고된 첫 번째 오류를 수정합니다; 알 수 없는 TOML 필드는 거부됩니다.
2. 구성된 TCP 및 UDP 포트가 사용 가능하며 방화벽에서 허용되는지 확인합니다.
3. 인증서와 키가 존재하고 서비스 계정에서 읽을 수 있으며, 서로 짝이 맞는지 확인합니다.
4. 자동 TLS의 경우, 구성된 모든 도메인이 Webship 호스트로 해석되는지 확인합니다.
5. DNS 또는 외부 로드 경로를 통해 테스트하기 전에 로컬 애플리케이션 리스너에서 /health를 호출합니다.
6. 런타임 증거가 필요한 경우 일시적으로 인증된 관찰 가능성을 활성화합니다.