Traefik v2 ते v3 स्थलांतर: काय बदलले आणि काय तुटते?
Traefik v3 मध्ये swarmMode किंवा pilot वापरल्यास सर्व्हर सुरू होत नाही. incompatible deprecated static option एरर सोडवण्यासाठी आणि नियमांचे स्थलांतर करण्यासाठी ही मार्गदर्शिका वाचा.
Traefik v2 आणि v3 मधील बदल
Traefik v2 वरून v3 वर स्थलांतर करणे म्हणजे प्रामुख्याने नावांमध्ये बदल करणे आहे. यात सर्वात महत्त्वाचा बदल म्हणजे ipWhiteList या middleware चे नाव बदलून ipAllowList असे करण्यात आले आहे. याव्यतिरिक्त, v3 मध्ये router rule syntax अधिक कडक करण्यात आली आहे (PathPrefix मधून regex वैशिष्ट्ये काढून टाकली आहेत, तसेच अनेक matchers ची नावे बदलली किंवा काढून टाकली आहेत). काही providers आणि पर्याय पूर्णपणे बंद करण्यात आले आहेत, परंतु इतर सर्व गोष्टी जसे की entrypoints, ACME certificate सेटअप, Docker labels वर्कफ्लो आणि तुमचे acme.json पूर्वीप्रमाणेच काम करतात. v3 मध्ये एक compatibility mode देखील उपलब्ध आहे, जो v2 ची rule syntax चालू ठेवतो. त्यामुळे तुम्ही आधी binary अपग्रेड करू शकता आणि सर्व नियम एकाच वेळी बदलण्याऐवजी, प्रत्येक सर्व्हिसचे नियम टप्प्याटप्प्याने बदलू शकता.
हे मार्गदर्शक Traefik reverse proxy मार्गदर्शकातील label-आधारित Docker Compose सेटअपवर आधारित आहे. ते पान v3 साठी तयार केलेले आहे; हे मार्गदर्शक अशा सर्व्हरसाठी आहे जे अजूनही traefik:v2 टॅग वापरत आहेत.
पुनर्नामांकन आणि काढलेले घटक
ipWhiteListआताipAllowListझाले आहे, हे HTTP आणि TCP दोन्ही middleware साठी लागू आहे. त्यातील पर्याय बदललेले नाहीत, त्यामुळेsourcerangeचा अर्थ पूर्वीप्रमाणेच राहतो. सध्याच्या v3 releases मध्ये, v3.5 सह, जुने नाव deprecated alias म्हणून स्वीकारले जाते आणि यादीची अंमलबजावणी सुरूच राहते, त्यामुळे या एका पुनर्नामांकनामुळे कोणतीही सेवा बंद पडत नाही. तरीही ते बदलून घ्या: हा alias भविष्यात काढून टाकला जाणार आहे आणि तो deprecation यादीतून कोणतीही सूचना न देता काढून टाकला जाईल.providers.docker.swarmMode=trueआता काढून टाकले आहे. Swarm साठी स्वतंत्र provider आहे, जोproviders.swarm.endpointम्हणून कॉन्फिगर केला जातो.pilotविभाग पूर्णपणे काढून टाकला आहे.experimental.http3काढून टाकले आहे. HTTP/3 आता थेट entrypoint वर सक्षम केले जाते.tls.caOptionalहे providers आणि forwardAuth middleware मधून काढून टाकले आहे. जर ते middleware एका self-hosted Authentik SSO च्या समोर असेल, तरcaOptionalओळ काढून टाकणे हीच त्यासाठीची संपूर्ण migration प्रक्रिया आहे, कारण forwardAuth पत्ता, trusted headers आणि त्यामागील outpost हे सर्व v3 वर पूर्वीप्रमाणेच काम करतात.- InfluxDB v1 metrics provider, Rancher provider आणि Marathon provider काढून टाकले आहेत.
- Tracing आता OpenTelemetry वर हलवले आहे. समर्पित tracing backends, ज्यामध्ये Jaeger आणि Zipkin integrations चा समावेश होता, ते काढून टाकले आहेत आणि त्याऐवजी v3 आता OTLP (OpenTelemetry protocol) वापरते.
- headers middleware मधील deprecated
ssl*पर्याय (sslRedirect,sslHostआणि इतर) काढून टाकले आहेत. त्याऐवजी Entrypoint redirections आणि redirectScheme middleware वापरले जातात.
हे बदल दिसतात त्यापेक्षा अधिक महत्त्वाचे आहेत, कारण static configuration मध्ये Traefik ला माहित नसलेला पर्याय असल्यास तो सुरू होत नाही. एखादी शिल्लक राहिलेली pilot किंवा swarmMode ओळ कंटेनरला बूट होताना थांबवते आणि incompatible deprecated static option found संदेश दाखवते, ज्यामध्ये त्या शिल्लक राहिलेल्या पर्यायाचे नाव असते; जर Traefik ला तो पर्याय अजिबात माहित नसेल (उदा. टायपो किंवा tls.caOptional), तर तो field not found संदेशासह थांबतो. image tag बदलण्यापूर्वी static configuration स्वच्छ करा.
Traefik ला माहित नसलेले middleware नाव (टायपो किंवा काढून टाकलेले नाव) वेगळ्या प्रकारे अपयशी ठरते: जो router त्याचा संदर्भ देतो, तो route ऐवजी त्रुटीसह लोड होतो, dashboard वर तो चिन्हांकित केला जातो आणि API middleware "offce@docker" does not exist रिपोर्ट करते. त्या hostname वर येणाऱ्या विनंत्यांना 404 त्रुटी मिळते कारण router कधीच सुरू झालेला नसतो. लक्षात घ्या की ipwhitelist सध्याच्या v3 मध्ये या श्रेणीत येत नाही: तो deprecated alias म्हणून टिकून आहे, त्यामुळे पुनर्नामांकन न केलेले label देखील शांतपणे काम करत राहते.
नियम सिंटॅक्समधील बदल
नियम (rules) हे असे ठिकाण आहे जिथे प्रत्यक्ष रीरायटिंग होऊ शकते. v3 मधील बदल खालीलप्रमाणे आहेत:
- मॅचर्समधील व्हॅल्यूजसाठी बॅकटिक्स (backticks) वापरणे अनिवार्य आहे. v2 मध्ये डबल कोट्स चालत होते; v3 मध्ये ते चालत नाहीत, त्यामुळे Host("app.example.com") चे रूपांतर Host(
app.example.com) मध्ये करणे आवश्यक आहे. PathPrefixआता रेग्युलर एक्स्प्रेशन्स किंवा{id}-शैलीतील प्लेसहोल्डर्स समजत नाही. v2 मधील PathPrefix(/api/{version:v[0-9]+}) सारख्या नियमाचे रूपांतर आता Go रेग्युलर एक्स्प्रेशन सिंटॅक्स वापरून लिहिलेल्याPathRegexpमॅचरमध्ये करावे लागेल.- मॅचर्स आता फक्त एकच व्हॅल्यू स्वीकारतात. v2 मध्ये Host(
app.example.com,www.example.com) चालत असे; v3 मध्ये Host(app.example.com) || Host(www.example.com) असे लिहावे लागते. फक्तHeader,HeaderRegexp,QueryआणिQueryRegexpहे अपवाद आहेत, जे अजूनही नाव आणि व्हॅल्यू दोन्ही स्वीकारतात. HeadersआणिHeadersRegexpयांची नावे बदलून आताHeaderआणिHeaderRegexpअशी करण्यात आली आहेत.HostHeaderकाढून टाकण्यात आले आहे. त्याऐवजीHostवापरा, जे v3 मध्ये त्याच गोष्टीशी मॅच होते.- दोन नवीन मॅचर्स जोडले आहेत:
QueryRegexpआणि नियमाच्या आत क्लायंटचा पत्ता मॅच करण्यासाठीClientIP.
चांगली बातमी अशी की: बॅकटिक्स वापरून लिहिलेला साधा Host(app.example.com) नियम v3 मध्ये आधीच वैध आहे. बहुतेक लहान Compose सेटअप्समध्ये याचाच वापर होतो, याचा अर्थ असा की बहुतेक लेबल्स कोणत्याही बदलाशिवाय स्थलांतरित (migrate) करता येतात.
सुरू करण्यापूर्वी तुमच्या लेबल्सचे ऑडिट करा
तुम्ही एका सर्चद्वारे तुमच्या मायग्रेशनचा आवाका मोजू शकता, कारण प्रत्येक ब्रेकिंग लेबल बदलामुळे एक पॅटर्न तयार होतो जो grep द्वारे शोधता येतो:
grep -rnE 'ipwhitelist|HostHeader|Headers\(|PathPrefix\(`[^`]*\{|Host\(`[^`]*`,' docker-compose*.ymlप्रत्येक हिट म्हणजे संपादित करायची एक ओळ आहे. ipwhitelist चे रूपांतर ipallowlist मध्ये होते. HostHeader चे रूपांतर Host मध्ये होते. Headers चे रूपांतर Header मध्ये होते. PathPrefix मधील {...} प्लेसहोल्डरचे रूपांतर PathRegexp मॅचरमध्ये होते. Host() मधील स्वल्पविरामाचे रूपांतर || द्वारे जोडलेल्या दोन Host() मॅचर्समध्ये होते. शून्य हिट्सचा अर्थ असा की तुमची लेबल्स आधीच वैध v3 सिंटॅक्समध्ये आहेत आणि मायग्रेशन फक्त स्टॅटिक कॉन्फिगरेशन आणि इमेज टॅगपुरते मर्यादित राहते. जर स्क्रीनवर अनेक हिट्स दिसत असतील, तर हा सर्व्हरसाठी हाच योग्य प्रॉक्सी आहे का, याचा विचार करण्याची ही योग्य वेळ आहे आणि Traefik ची Nginx आणि Caddy सोबत तुलना हे लेख इतर दोन प्रॉक्सी प्रति ॲप किती मेहनत घेतात, याच्या तुलनेत हे पुनर्लेखन किती खर्चिक आहे हे स्पष्ट करतात.
काय बदलत नाही
Entrypoints आणि त्यांचे HTTP-to-HTTPS redirect, दोन्ही challenge प्रकारांसह ACME resolvers, exposedByDefault, router आणि service labels, loadbalancer.server.port, आणि dashboard हे सर्व v3 मध्ये v2 प्रमाणेच काम करतात. तुमची प्रमाणपत्रे देखील जशीच्या तशी राहतात, कारण v3 हे v2 ने लिहिलेले acme.json वाचणे सुरू ठेवते. तरीही सुरुवात करण्यापूर्वी फाईलचा बॅकअप घ्या, कारण जर रोलबॅक करताना ती फाईल गमावली, तर तुम्ही थेट Let's Encrypt च्या duplicate-certificate rate limit मध्ये अडकाल:
cp ./letsencrypt/acme.json ./letsencrypt/acme.json.v2-backupस्थलांतराचा मार्ग (Migration path)
पायरी 1: सध्या चालवत असलेल्या आवृत्त्या निश्चित करा. कोणताही traefik:latest किंवा traefik:v2 टॅग तुम्ही सध्या वापरत असलेल्या अचूक release वर सेट करा, उदाहरणार्थ traefik:v2.11, आणि संपूर्ण compose डिरेक्टरी git मध्ये commit करा. त्यानंतरची प्रत्येक पायरी checkout वापरून पूर्ववत करता येते. जर docker compose up -d <service> वापरून एखादी सेवा पुन्हा तयार करणे अजून सवयीचे नसेल, तर Docker Compose मूलभूत मार्गदर्शक या स्थलांतरासाठी आवश्यक असलेल्या सर्व क्रिया स्पष्ट करते.
पायरी 2: स्टॅटिक कॉन्फिगरेशन स्वच्छ करा आणि compatibility mode सुरू करा. v3 मध्ये काढून टाकलेले सर्व पर्याय (pilot, swarmMode, tls.caOptional, experimental.http3) काढून टाका, त्यानंतर v3 ला नियम डीफॉल्टनुसार v2 सिंटॅक्सप्रमाणे हाताळण्यास सांगा. traefik.yml मध्ये:
core:
defaultRuleSyntax: v2किंवा compose command: यादीमध्ये फ्लॅग म्हणून: --core.defaultRuleSyntax=v2. Compatibility mode फक्त नियमांच्या सिंटॅक्सला लागू होतो. हे काढून टाकलेले पर्याय पुन्हा जिवंत करत नाही आणि तुमच्यासाठी middleware ची नावे बदलत नाही.
पायरी 3: middleware च्या नामबदलाची तयारी करा. तुमच्या compose फाईल्समध्ये जुन्या नावांचा शोध घ्या: grep -rn ipwhitelist docker-compose*.yml. प्रत्येक ipwhitelist लेबल बदलून ipallowlist करा, परंतु हा बदल लगेच लागू करू नका, कारण नवीन नाव v2 मध्ये अस्तित्वात नाही. हे बदल पुढच्या पायरीत एकाच वेळी लागू होतील. (जर एखादे नाव राहून गेले, तर सध्याचे v3 जुन्या नावाला deprecated alias म्हणून स्वीकारते, त्यामुळे नियम लागू राहतात; ते पुढच्या वेळी दुरुस्त करा.)
पायरी 4: इमेज टॅग बदला. Traefik इमेज सध्याच्या v3 release वर सेट करा, जे लिहिताना traefik:v3.5 आहे, त्यानंतर:
docker compose up -d
docker compose logs -f traefikCompatibility mode सुरू असल्यामुळे, तुमचे v2 नियम जुळत राहतील आणि up -d ने ज्या सेवांचे middleware लेबल्स तुम्ही बदलले होते त्या पुन्हा तयार केल्यामुळे, ते routers व्यवस्थित सुरू होतील. निरोगी log मध्ये कोणतीही field not found ओळ किंवा does not exist ओळ नसते.
या पायरीमुळे निर्माण होणाऱ्या वेळेच्या खिडकीबद्दल (window) प्रामाणिक राहा. ज्या router मध्ये अशा middleware चे नाव आहे जे v3 ला माहित नाही (उदा. टायपिंगची चूक किंवा काढून टाकलेला पर्याय), तो नवीन Traefik सुरू झाल्यापासून ते app कंटेनर पुन्हा तयार होईपर्यंत बंद राहील. एका सर्व्हरवर याला काही सेकंद लागतात, जे docker compose up -d यादी पूर्ण करण्यासाठी घेते. जर एखादा मार्ग (route) अजिबात बंद होऊ शकत नसेल, तर बदललेले middleware त्या router च्या middlewares लेबलमधून काढून टाका आणि नंतर पुन्हा जोडा. त्या दरम्यानच्या मिनिटासाठी तो मार्ग IP allow list शिवाय चालू शकेल का, याचा आधीच निर्णय घ्या.
पायरी 5: एकामागून एक सेवांचे नियम स्थलांतरित करा. एका वेळी एका app वर काम करा: त्याचा नियम v3 सिंटॅक्समध्ये पुन्हा लिहा, docker compose up -d app वापरून फक्त ती सेवा पुन्हा तयार करा आणि पुढे जाण्यापूर्वी तिची चाचणी करा. जर एखाद्या सेवेचा नियम तुम्ही अजून लिहू शकत नसाल, तर त्या विशिष्ट router ला traefik.http.routers.app.ruleSyntax=v2 हे लेबल द्या आणि पुढे चालू ठेवा.
पायरी 6: compatibility mode बंद करा. जेव्हा सर्व नियम v3 सिंटॅक्समध्ये असतील, तेव्हा defaultRuleSyntax आणि कोणतेही ruleSyntax लेबल्स काढून टाका, Traefik रीस्टार्ट करा आणि डॅशबोर्डवर प्रत्येक router हिरवा (green) दिसत असल्याची खात्री करा. Compatibility mode सुरू ठेवून स्थिरावू नका: Traefik ने v3.4 मध्ये हे दोन्ही पर्याय deprecated केले आहेत आणि पुढच्या प्रमुख आवृत्तीत ते काढून टाकले जातील, त्यामुळे हा फक्त एक तात्पुरता पूल आहे, अंतिम मुक्काम नाही.
बदलण्यापूर्वी आणि नंतर: एका सर्व्हिसचे लेबल्स
येथे एक ॲप आहे ज्यामध्ये एकाच वेळी सर्व महत्त्वाचे बदल केले आहेत: एक मल्टि-व्हॅल्यू Host, एक PathPrefix प्लेसहोल्डर आणि एक ipWhiteList मिडलवेअर. v2 ब्लॉक:
app:
image: app:1.4
restart: unless-stopped
networks:
- proxy
labels:
- traefik.enable=true
- traefik.http.routers.app.rule=Host(`app.example.com`,`www.example.com`) && PathPrefix(`/api/{version:v[0-9]+}`)
- traefik.http.routers.app.entrypoints=websecure
- traefik.http.routers.app.tls.certresolver=le
- traefik.http.routers.app.middlewares=office
- traefik.http.middlewares.office.ipwhitelist.sourcerange=10.0.0.0/24
- traefik.http.services.app.loadbalancer.server.port=8080आणि तीच सर्व्हिस v3 मध्ये स्थलांतरित (migrated) केली असता:
app:
image: app:1.4
restart: unless-stopped
networks:
- proxy
labels:
- traefik.enable=true
- traefik.http.routers.app.rule=(Host(`app.example.com`) || Host(`www.example.com`)) && PathRegexp(`^/api/v[0-9]+`)
- traefik.http.routers.app.entrypoints=websecure
- traefik.http.routers.app.tls.certresolver=le
- traefik.http.routers.app.middlewares=office
- traefik.http.middlewares.office.ipallowlist.sourcerange=10.0.0.0/24
- traefik.http.services.app.loadbalancer.server.port=8080दोन लेबल्स बदलली आहेत. नियमाने त्याचे मल्टि-व्हॅल्यू Host दोन मॅचर्समध्ये विभागले आहेत जे || ने जोडले आहेत आणि प्लेसहोल्डरला PathRegexp ने बदलले आहे, तसेच मिडलवेअर लेबलमध्ये ipwhitelist च्या जागी ipallowlist वापरले आहे. एंट्रीपॉइंट, सर्टिफिकेट रिझॉल्व्हर, राउटर-टू-मिडलवेअर वायरिंग आणि सर्व्हिस पोर्टमध्ये कोणताही बदल झालेला नाही.
डॅशबोर्ड वापरून प्रत्येक सेवेची चाचणी करा
प्रत्येक बदलांनंतर, डॅशबोर्डचे HTTP routers पेज उघडा. प्रत्येक राउटर हिरव्या रंगात दिसला पाहिजे. एरर बॅज असलेला राउटर त्याची नेमकी समस्या दर्शवतो; सहसा हे अशा मिडलवेअरमुळे घडते जे नवीन नावाने अस्तित्वात नाही किंवा असा नियम जो v3 द्वारे पार्स (parse) करता येत नाही. त्यानंतर, बाहेरून एका वेळी एक होस्टनेम तपासा:
curl -sI https://app.example.com/api/v1/status200 किंवा तुमच्या ॲपचे सामान्य रीडायरेक्ट म्हणजे राउटिंग आणि TLS दोन्ही यशस्वीरित्या कार्यरत आहेत. Traefik कडून येणारा 404 म्हणजे राउटर सुरू झालेला नाही; डॅशबोर्डवर परत जा आणि त्याची एरर वाचा. काम करताना दुसऱ्या टर्मिनलमध्ये docker compose logs -f traefik उघडे ठेवा, कारण कंटेनर रीस्टार्ट होताच प्रत्येक पार्सिंग अयशस्वी झाल्याची नोंद तिथे लगेच दिसते.
रोलबॅकची विश्वासार्हता
v2 compose फाईल, तिचे स्टॅटिक कॉन्फिगरेशन आणि acme.json बॅकअप तोपर्यंत जपून ठेवा जोपर्यंत सर्व सेवा v3 वर राउट होत नाहीत आणि प्रत्यक्ष वापरातून त्यांची खात्री पटत नाही. रोलबॅक करणे म्हणजे प्री-मायग्रेशन कमिट चेकआउट करून docker compose up -d चालवणे होय. हे संपूर्ण फाईलसाठी असणे आवश्यक आहे, केवळ इमेज टॅगसाठी नाही, कारण v3-ओन्ली लेबल्स v2 मध्ये चुकीची ठरतात, जशी v2 लेबल्स v3 मध्ये चुकीची ठरत होती: ipallowlist हे v2 मध्ये अस्तित्वात नाही आणि PathRegexp मॅचर तिथे पार्स होणार नाही. जर प्रक्रियेदरम्यान acme.json गहाळ झाले किंवा खराब झाले, तर v2 सुरू करण्यापूर्वी बॅकअप प्रत रिस्टोअर करा, जेणेकरून रोलबॅक करताना एकाच वेळी पाच प्रमाणपत्रे पुन्हा जारी करून तुमचा Let's Encrypt रेट लिमिट संपणार नाही.
FAQ
मला Traefik v3 साठी प्रत्येक राउटर नियम पुन्हा लिहावा लागेल का?
नाही. बॅकटिक्स (backticks) वापरून लिहिलेला साधा Host(app.example.com) नियम दोन्ही आवृत्त्यांमध्ये वैध आहे आणि बहुतेक Compose सेटअपसाठी तो पुरेसा आहे. केवळ अशा ठिकाणी नियम पुन्हा लिहिण्याची गरज आहे जिथे v2-विशिष्ट वैशिष्ट्ये वापरली आहेत: जसे की Path आणि PathPrefix मधील regex किंवा प्लेसहोल्डर्स, एकाच Host() मध्ये अनेक होस्टनेम्स, बॅकटिक्सऐवजी कोट्सचा वापर, किंवा काढून टाकलेले Headers, HeadersRegexp आणि HostHeader मॅचर्स.
Traefik v3 मध्ये ipWhiteList चे काय झाले?
त्याचे नाव बदलून ipAllowList करण्यात आले आहे, परंतु त्यातील कॉन्फिगरेशन बदललेले नाही. त्यामुळे traefik.http.middlewares.office.ipwhitelist.sourcerange=10.0.0.0/24 सारखी v2 लेबल आता ipallowlist वापरून त्याच ओळीत लिहिता येतात. v3.5 सह सध्याच्या v3 रिलीजमध्ये जुने नाव अजूनही deprecated alias म्हणून स्वीकारले जाते, त्यामुळे नाव न बदललेले लेबलही allowlist लागू करत राहते. याकडे कायमस्वरूपी उपाय म्हणून न पाहता तात्पुरती सोय म्हणून पहा: हे alias भविष्यात काढून टाकले जाणार आहे. जर Traefik ला मिडलवेअरचे नाव ओळखता आले नाही, तर राउटर एरर येते आणि 404 एरर मिळतो. डॅशबोर्डवर ही त्रुटी दिसते आणि त्या होस्टनेमवर येणाऱ्या विनंत्यांना 404 प्रतिसाद मिळतो.
Traefik v3 अजूनही v2 नियमांचे सिंटॅक्स वाचू शकते का?
हो. स्थलांतर (migration) करत असताना v2 सिंटॅक्स डीफॉल्ट म्हणून ठेवण्यासाठी स्टॅटिक कॉन्फिगरेशनमध्ये core.defaultRuleSyntax: v2 सेट करा. डीफॉल्ट सेटिंग बदलल्यानंतर उरलेल्या वैयक्तिक राउटरसाठी ruleSyntax=v2 लेबल वापरा. या दोन्ही गोष्टी तात्पुरत्या समजा: Traefik ने v3.4 मध्ये त्यांना deprecated केले आहे आणि पुढील प्रमुख आवृत्तीमध्ये ते काढून टाकले जाईल.
अपग्रेड केल्यानंतर माझी Let's Encrypt प्रमाणपत्रे सुरक्षित राहतील का?
हो. Traefik v3 v2 ने लिहिलेली acme.json फाईल वाचत राहते, त्यामुळे केवळ बायनरी बदलल्यामुळे प्रमाणपत्रे पुन्हा जारी (re-issue) केली जात नाहीत. तरीही, सुरुवात करण्यापूर्वी फाईलची सुरक्षित ठिकाणी प्रत ठेवा. कारण रोलबॅक किंवा acme.json गमावल्यास सर्व प्रमाणपत्रे एकाच वेळी पुन्हा जारी करावी लागतील आणि Let's Encrypt एकाच होस्टनेम संचासाठी आठवड्याला फक्त पाच डुप्लिकेट प्रमाणपत्रांची परवानगी देते.
अपग्रेड केल्यानंतर Traefik v3 सुरू का होत नाही?
बहुतेकदा याचे कारण असे असते की स्टॅटिक कॉन्फिगरेशनमध्ये v3 ने काढून टाकलेला एखादा पर्याय अजूनही असतो आणि Traefik अनोळखी पर्यायांसह सुरू होण्यास नकार देते. ज्ञात अवशेषांसाठी (pilot, providers.docker.swarmMode, experimental.http3) लॉगमध्ये incompatible deprecated static option found असा संदेश येतो आणि संबंधित पर्यायाचे नाव दिले जाते. v3 ला माहिती नसलेल्या कोणत्याही गोष्टीसाठी, जसे की tls.caOptional, लॉगमध्ये field not found असा संदेश येतो. प्रत्येक चुकीचा पर्याय काढून टाका किंवा बदला आणि त्यानंतर कंटेनर पुन्हा सुरू करा.