블라인드 컷오버 없이 Traefik에서 Webship로 마이그레이션

트래픽을 변경하기 전에 마이그레이션 경계를 정의하십시오.

Webship가 재현하고 검증할 수 있는 동작만 먼저 이동하여 시작하세요. 애플리케이션 인증, 서비스 검색, 스크립트 및 특수 캐시 규칙은 대체품이 프로덕션과 유사한 테스트를 통과할 때까지 기존 오리진에 남겨둡니다.

가장 작은 프로덕션 경로를 먼저 마이그레이션하십시오.

소스 프래그먼트는 마이그레이션 개념을 식별합니다; Webship 프래그먼트는 대상 형태를 보여줍니다. 예제 도메인, 주소, 인증서, 한도 및 헬스 경로를 환경에 맞게 검증된 값으로 교체하십시오.

http:
  routers:
    app:
      rule: Host(`app.example.com`)
      service: app
  services:
    app:
      loadBalancer:
        servers:
          - url: http://127.0.0.1:8080

listen = "0.0.0.0:443"
workers = 4

[reverse_proxy]
enabled = true
connect_timeout_ms = 2000
max_retries = 0

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

[reverse_proxy.tls]
cert = "/etc/letsencrypt/live/app.example.com/fullchain.pem"
key = "/etc/letsencrypt/live/app.example.com/privkey.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["127.0.0.1:8080", "127.0.0.1:8081"]
load_balancing = "weighted-peak-ewma"

[[reverse_proxy.upstreams]]
address = "127.0.0.1:8080"
protocol = "http1"
health_check_path = "/health"
health_check_interval_ms = 5000
health_check_timeout_ms = 1000

[[reverse_proxy.upstreams]]
address = "127.0.0.1:8081"
protocol = "http1"
health_check_path = "/health"
health_check_interval_ms = 5000
health_check_timeout_ms = 1000

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

구문이 아닌 개념을 매핑하십시오.

기술 지침은 항상 일대일로 일치하지 않습니다. 이 표를 사용하여 해당하는 Webship 구성 영역을 찾은 다음, 유효한 구성과 런타임 동작을 검증하십시오.

되돌릴 수 있는 5단계 전환을 사용하십시오.

대표 트래픽에서 Webship가 정확성, 용량, 보안성, 관찰 가능성 및 롤백 검증을 통과할 때까지 이전 리스너를 준비 상태로 유지하십시오.

1. 1

   재고 관찰 가능한 동작

   리스너, 도메인, 라우트, 상류, 인증서, 리라이트, 인증, 캐시 규칙, 상태 점검, 제한 및 운영 통합을 기록하십시오.

2. 2

   하나의 경계를 변환

   하나의 호스트 또는 경로를 엄격한 TOML로 이동합니다. 별도의 대체품이 입증될 때까지 Webship 뒤에 공급업체별 모듈과 애플리케이션 로직을 유지합니다.

3. 3

   오프라인 및 로컬에서 검증

   --check-config 및 --print-effective-config를 실행하고, 편집된 결과를 검사하며, 로컬에서 상태를 확인하고, HTTP/3이 활성화된 경우 TCP와 UDP에서 TLS를 활용합니다.

4. 4

   카나리아 실제 트래픽

   작고 관찰 가능한 트래픽 조각을 Webship에 전송하십시오. 상태 코드, 헤더, 본문, 지연 시간, 상류 상태, 캐시 동작, 로그 및 보안 결정을 비교하십시오.

5. 5

   롤백 준비 상태로 홍보

   측정된 단계에서 트래픽을 증가시킵니다. 이전 목표를 건강하게 유지하고 합의된 관찰 창과 부하 게이트가 통과될 때까지 즉시 라우팅 가능하게 합니다.

먼저 검증하십시오. 라이브 편집으로 롤백하지 말고 라우팅으로 롤백하십시오.

후보 파일을 검증하고, 편집된 유효 구성(configuration)을 검사하며, 트래픽을 변경하기 전에 프라이빗 리스너를 시험해 보십시오. 관찰 창(observation window)이 종료될 때까지 이전 바이너리, 구성, 리스너, DNS 또는 로드 밸런서 대상(target)을 보존하십시오.

/usr/local/bin/webship --check-config --config /etc/webship/production.toml
/usr/local/bin/webship --print-effective-config --config /etc/webship/production.toml
curl --http3-only --insecure https://127.0.0.1:443/health