ब्लाइंड कटओवर किए बिना Microsoft IIS से Webship में माइग्रेट करें।

ट्रैफ़िक बदलने से पहले माइग्रेशन सीमा को परिभाषित करें।

केवल वही व्यवहार Webship को स्थानांतरित और सत्यापित करके शुरू करें जिसे वह पुन: उत्पन्न कर सकता है। एप्लिकेशन प्रमाणीकरण, सेवा खोज, स्क्रिप्ट, और विशिष्ट कैश नियमों को मौजूदा मूल पर रहने दें जब तक कि उनके प्रतिस्थापन उत्पादन-जैसे परीक्षणों में पास न हो जाएँ।

सबसे छोटी उत्पादन मार्ग को पहले अनुवाद करें।

स्रोत खंड माइग्रेशन अवधारणा की पहचान करता है; Webship खंड लक्ष्य स्वरूप दिखाता है। उदाहरण डोमेन, पते, प्रमाणपत्र, सीमाएं, और स्वास्थ्य पथों को अपने पर्यावरण के लिए मान्य मानों के साथ बदलें।

<rewrite>
  <rules>
    <rule name="ReverseProxy" stopProcessing="true">
      <match url="(.*)" />
      <action type="Rewrite" url="http://127.0.0.1:8080/{R:1}" />
    </rule>
  </rules>
</rewrite>

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 कॉन्फ़िगरेशन क्षेत्र खोजने के लिए इस तालिका का उपयोग करें, फिर प्रभावी कॉन्फ़िगरेशन और रनटाइम व्यवहार को मान्य करें।

एक उलटने योग्य पाँच-चरण कटओवर का उपयोग करें।

पुराने श्रुतकर्ता को तैयार रखें जब तक कि Webship प्रतिनिधि ट्रैफिक पर सटीकता, क्षमता, सुरक्षा, अवलोकनीयता और रोलबैक गेट्स से पास न हो जाए।

1. 1

   इन्वेंटरी प्रेक्षणीय व्यवहार

   श्रोताओं, डोमेन, मार्ग, अपस्ट्रीम, प्रमाणपत्र, पुनर्लेखन, प्रमाणीकरण, कैश नियम, स्वास्थ्य परीक्षक, सीमाएँ और परिचालन एकीकरण रिकॉर्ड करें।

2. 2

   एक सीमा का अनुवाद करें

   एक होस्ट या मार्ग को सख्त TOML में स्थानांतरित करें। अलग विकल्प साबित होने तक विक्रेता-विशेष मॉड्यूल और आवेदन तर्क को Webship के पीछे बनाए रखें।

3. 3

   ऑफ़लाइन और स्थानीय रूप से सत्यापित करें

   --check-config और --print-effective-config चलाएँ, संशोधित परिणाम का निरीक्षण करें, स्थानीय रूप से स्वास्थ्य की जांच करें, और जब HTTP/3 सक्षम हो तो TCP और UDP दोनों में TLS का उपयोग करें।

4. 4

   कैनरी वास्तविक ट्रैफ़िक

   Webship को एक छोटा, देखी जा सकने वाला ट्रैफ़िक स्लाइस भेजें। स्टेटस कोड, हेडर, बॉडी, विलंब, अपस्ट्रीम स्वास्थ्य, कैश व्यवहार, लॉग और सुरक्षा निर्णयों की तुलना करें।

5. 5

   रोलबैक तैयार के साथ प्रचारित करें

   मापी गई चरणों में ट्रैफ़िक बढ़ाएँ। पिछला लक्ष्य स्वस्थ और तुरंत मार्गदर्शित रखने योग्य बनाए रखें जब तक कि सहमत प्रेक्षण खिड़की और लोड गेट पास न हो जाएँ।

पहले मान्य करें। लाइव संपादन करके नहीं, मार्गing द्वारा रोलबैक करें।

उम्मीदवार फ़ाइल को मान्य करें, संशोधित प्रभावी कॉन्फ़िगरेशन का निरीक्षण करें, और ट्रैफ़िक बदलने से पहले निजी श्रोता की जांच करें। पुरानी बाइनरी, कॉन्फ़िगरेशन, श्रोता और DNS या लोड-बैलेंसर लक्ष्यों को उस समय तक सुरक्षित रखें जब तक अवलोकन विंडो बंद न हो जाए।

/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