Traefik v2 to v3 migration: என்னென்ன மாற்றங்கள்?

Traefik v2 மற்றும் v3-க்கு இடையிலான மாற்றங்கள்

Traefik v2-லிருந்து v3-க்கு மாறுவது பெரும்பாலும் பெயர்களை மாற்றும் பணியாகும். இதில் முக்கியமான மாற்றம் ipWhiteList middleware, ipAllowList என மாற்றப்பட்டதுதான். இதைத் தாண்டி, v3-ல் router rule syntax மிகவும் கடுமையாக்கப்பட்டுள்ளது (PathPrefix-ல் regex வசதிகள் நீக்கப்பட்டுள்ளன, பல matchers பெயர்கள் மாற்றப்பட்டுள்ளன அல்லது நீக்கப்பட்டுள்ளன). சில providers மற்றும் options முழுமையாக நீக்கப்பட்டுள்ளன. மற்றபடி, entrypoints, ACME certificate அமைப்பு, Docker labels workflow மற்றும் உங்கள் acme.json போன்றவை அப்படியே செயல்படும். v3-ல் compatibility mode வசதி உள்ளது; இது v2 rule syntax-ஐ தொடர்ந்து இயங்க வைக்கும். எனவே, நீங்கள் binary-ஐ முதலில் upgrade செய்துவிட்டு, ஒவ்வொரு service-ஆக விதிகளை மாற்றிக்கொள்ளலாம். ஒரே இரவில் அனைத்தையும் மாற்ற வேண்டிய அவசியமில்லை.

இந்த வழிகாட்டி Traefik reverse proxy வழிகாட்டி-ல் உள்ள label-அடிப்படையிலான Docker Compose அமைப்பை அடிப்படையாகக் கொண்டது. அந்தப் பக்கம் v3-க்கு ஏற்றது; இது traefik:v2 tag-ஐ இன்னும் பயன்படுத்தும் server-களுக்கானது.

பெயர் மாற்றங்கள் மற்றும் நீக்கங்கள்

• ipWhiteList இப்போது ipAllowList என மாற்றப்பட்டுள்ளது, இது HTTP மற்றும் TCP ஆகிய இரண்டு middleware-களுக்கும் பொருந்தும். உள்ளே இருக்கும் விருப்பங்கள் மாறவில்லை, எனவே sourcerange அதன் அதே பொருளைத் தக்கவைத்துக் கொள்கிறது. தற்போதைய v3 releases, v3.5 உட்பட, பழைய பெயரை ஒரு deprecated alias-ஆக ஏற்றுக்கொண்டு பட்டியலை அமல்படுத்துகின்றன, எனவே இந்த ஒரு பெயர் மாற்றம் எதையும் செயலிழக்கச் செய்யாது. இருப்பினும், அதை மாற்றிவிடுங்கள்: அந்த alias நீக்கப்படத் திட்டமிடப்பட்டுள்ளது, மேலும் அது deprecation பட்டியலிலிருந்து எந்த அறிவிப்பும் இன்றி மறைந்துவிடும்.
• providers.docker.swarmMode=true நீக்கப்பட்டுவிட்டது. Swarm-க்கு எனத் தனி provider உள்ளது, அது providers.swarm.endpoint என configure செய்யப்படுகிறது.
• 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 ஒருங்கிணைப்புகள் உட்பட, நீக்கப்பட்டுவிட்டன; அதற்குப் பதிலாக v3 இப்போது OTLP (OpenTelemetry protocol)-ஐ ஏற்றுமதி செய்கிறது.
• headers middleware-க்குள் இருந்த deprecated ssl* விருப்பங்கள் (sslRedirect, sslHost மற்றும் பிற) நீக்கப்பட்டுவிட்டன. Entrypoint redirections மற்றும் redirectScheme middleware ஆகியவை அவற்றுக்குப் பதிலாக வந்துவிட்டன.

இந்த நீக்கங்கள் பார்ப்பதை விட முக்கியமானவை, ஏனெனில் Traefik-க்குத் தெரியாத ஒரு விருப்பம் அதன் static configuration-ல் இருந்தால், அது தொடங்க மறுத்துவிடும். எஞ்சியிருக்கும் ஒரு pilot அல்லது swarmMode வரி, boot-ன் போது அந்த எஞ்சியிருக்கும் வரியைக் குறிப்பிட்டு incompatible deprecated static option found செய்தியுடன் container-ஐ நிறுத்திவிடும்; Traefik-க்குத் தெரியாத ஒரு விருப்பம் (எழுத்துப் பிழை அல்லது tls.caOptional) இருந்தால், அது field not found செய்தியுடன் நிறுத்திவிடும். image tag-ஐ மாற்றும் முன் static configuration-ஐச் சுத்தப்படுத்துங்கள்.

Traefik-க்குத் தெரியாத ஒரு middleware பெயர் (எழுத்துப் பிழை அல்லது alias செய்யப்படாமல் நீக்கப்பட்ட பெயர்) வேறுவிதமாகச் செயல்படும்: அதைச் சுட்டிக்காட்டும் router, route-க்கு பதிலாக ஒரு பிழையுடன் load ஆகும், dashboard அதை அடையாளப்படுத்தும், மேலும் API middleware "offce@docker" does not exist எனத் தெரிவிக்கும். அந்த hostname-க்கு வரும் கோரிக்கைகள் 404 பிழையைப் பெறும், ஏனெனில் router தொடங்கப்படாது. தற்போதைய v3-ல் ipwhitelist இந்தப் பிரிவில் இல்லை என்பதைக் கவனத்தில் கொள்க: அது deprecated alias-ஆகத் தொடர்கிறது, எனவே பெயர் மாற்றப்படாத label தொடர்ந்து வேலை செய்யும்.

விதி தொடரியல் மாற்றங்கள்

விதிகள் (rules) மூலமே உண்மையான மறுஎழுத்து (rewriting) நடைபெறுகிறது. v3-ல் ஏற்பட்டுள்ள மாற்றங்கள்:

• Matcher-களுக்குள் உள்ள மதிப்புகளைச் சுற்றி backticks கட்டாயம் இருக்க வேண்டும். v2-ல் double quotes அனுமதிக்கப்பட்டது; v3-ல் அது அனுமதிக்கப்படாது. எனவே, Host("app.example.com") என்பது Host(app.example.com) என மாற வேண்டும்.
• PathPrefix இனி regular expressions அல்லது {id}-வகை placeholders-ஐப் புரிந்துகொள்ளாது. v2-ன் PathPrefix(/api/{version:v[0-9]+}) போன்ற விதியை, Go regular expression தொடரியலில் எழுதப்பட்ட PathRegexp matcher-ஆக மாற்ற வேண்டும்.
• Matcher-கள் இப்போது ஒரு மதிப்பை மட்டுமே ஏற்கும். 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-ல் அதே செயல்பாட்டைச் செய்யும்.
• இரண்டு புதிய matcher-கள் சேர்க்கப்பட்டுள்ளன: QueryRegexp, மற்றும் விதிகளுக்குள் client முகவரியைப் பொருத்துவதற்கான ClientIP.

நல்ல செய்தி என்னவென்றால்: backticks பயன்படுத்தி எழுதப்பட்ட ஒரு எளிய Host(app.example.com) விதி ஏற்கனவே v3 தொடரியலில் செல்லுபடியாகும். பெரும்பாலான சிறிய Compose அமைப்புகள் இதையே பயன்படுத்துகின்றன, எனவே பெரும்பாலான labels எந்தவித விதி மாற்றங்களும் இன்றி அப்படியே இடம்பெயரும்.

தொடங்குவதற்கு முன் உங்கள் labels-ஐ தணிக்கை செய்யவும்

ஒவ்வொரு breaking label மாற்றமும் grep மூலம் கண்டறியக்கூடிய ஒரு pattern-ஐ விட்டுச் செல்வதால், ஒரே ஒரு search மூலம் உங்கள் migration-ன் அளவை நீங்கள் கணக்கிட முடியும்:

grep -rnE 'ipwhitelist|HostHeader|Headers\(|PathPrefix\(`[^`]*\{|Host\(`[^`]*`,' docker-compose*.yml

ஒவ்வொரு hit-ம் திருத்தப்பட வேண்டிய ஒரு வரியாகும். ipwhitelist என்பது ipallowlist ஆக மாறுகிறது. HostHeader என்பது Host ஆக மாறுகிறது. Headers என்பது Header ஆக மாறுகிறது. PathPrefix-க்குள் இருக்கும் ஒரு {...} placeholder, PathRegexp matcher-ஆக மாறுகிறது. Host()-க்குள் இருக்கும் ஒரு கமா, || மூலம் இணைக்கப்பட்ட இரண்டு Host() matcher-களாக மாறுகிறது. பூஜ்ஜிய hits என்றால் உங்கள் labels ஏற்கனவே v3 syntax-ல் செல்லுபடியாகும் நிலையில் உள்ளன என்று அர்த்தம், மேலும் migration என்பது static configuration மற்றும் image tag-ஐ மட்டும் உள்ளடக்கியதாகச் சுருங்கிவிடும். திரையில் நிறைய hits தெரிந்தால், இந்த server-க்கு இதுவே சரியான proxy தானா என்று சிந்திக்க இது ஒரு நல்ல தருணம், மேலும் Traefik, Nginx மற்றும் Caddy ஆகியவற்றுடன் எவ்வாறு ஒப்பிடப்படுகிறது என்பது, மற்ற இரண்டு proxy-களும் ஒவ்வொரு app-க்கும் கோரும் தேவைகளுடன் இந்த rewriting செலவை ஒப்பிட்டுப் பார்க்க உதவுகிறது.

மாறாமல் இருப்பவை

Entrypoints மற்றும் அவற்றின் HTTP-to-HTTPS redirect, இரண்டு challenge வகைகளையும் கொண்ட ACME resolvers, exposedByDefault, router மற்றும் service labels, loadbalancer.server.port, மற்றும் dashboard ஆகிய அனைத்தும் v2-ல் செயல்பட்டது போலவே v3-லும் செயல்படுகின்றன. v2 உருவாக்கிய acme.json கோப்பை v3 தொடர்ந்து வாசிப்பதால், உங்கள் certificates அப்படியே பயன்பாட்டில் இருக்கும். இருப்பினும், தொடங்குவதற்கு முன் கோப்பை backup எடுத்துக்கொள்ளுங்கள். ஏனெனில், தரவு இழப்புடன் கூடிய rollback, Let's Encrypt-ன் duplicate-certificate rate limit சிக்கலுக்கு வழிவகுக்கும்:

cp ./letsencrypt/acme.json ./letsencrypt/acme.json.v2-backup

இடம்பெயர்வு வழிமுறை (Migration path)

படி 1: தற்போது இயங்கும் பதிப்புகளை உறுதிப்படுத்தவும். ஏதேனும் traefik:latest அல்லது traefik:v2 குறிச்சொல்லை (tag) நீங்கள் தற்போது பயன்படுத்தும் சரியான release-க்கு மாற்றவும் (உதாரணமாக traefik:v2.11). பின், முழு compose கோப்பகத்தையும் git-ல் commit செய்யவும். இதன் மூலம், பிந்தைய ஒவ்வொரு படியையும் checkout கட்டளை மூலம் எளிதாக மாற்றியமைக்க முடியும். docker compose up -d <service> கட்டளையைப் பயன்படுத்தி ஒரு service-ஐ மீண்டும் உருவாக்குவது உங்களுக்குப் பழகவில்லை என்றால், Docker Compose அடிப்படை வழிகாட்டியை பார்க்கவும்; இந்த இடம்பெயர்வு அந்த அடிப்படை செயல்பாடுகளையே சார்ந்துள்ளது.

படி 2: static configuration-ஐ சுத்தம் செய்து compatibility mode-ஐ இயக்கவும். v3 பதிப்பில் நீக்கப்பட்ட அனைத்து விருப்பங்களையும் (pilot, swarmMode, tls.caOptional, experimental.http3) நீக்கவும். பின்னர், v3 விதிகளை இயல்பாகவே v2 syntax-ஆகக் கருதும்படி அமைக்கவும். traefik.yml கோப்பில்:

core:
  defaultRuleSyntax: v2

அல்லது compose command: பட்டியலில் ஒரு flag-ஆகச் சேர்க்கவும்: --core.defaultRuleSyntax=v2. Compatibility mode விதிகளின் syntax-ஐ மட்டுமே கையாளும். இது நீக்கப்பட்ட விருப்பங்களை மீண்டும் கொண்டு வராது, மேலும் middlewares-ன் பெயர்களை உங்களுக்காக மாற்றாது.

படி 3: middleware பெயர் மாற்றங்களுக்குத் தயாராகுங்கள். உங்கள் compose கோப்புகளில் பழைய பெயர்களைத் தேடவும்: grep -rn ipwhitelist docker-compose*.yml. ஒவ்வொரு ipwhitelist label-ஐயும் ipallowlist என மாற்றவும். ஆனால், இந்த மாற்றத்தை இப்போதே செயல்படுத்த வேண்டாம், ஏனெனில் v2-ல் புதிய பெயர் இன்னும் இல்லை. இந்த மாற்றங்கள் அடுத்த படியில் செய்யப்படும் மாற்றத்துடன் சேர்த்து செயல்படுத்தப்பட வேண்டும். (ஏதேனும் ஒன்று விடுபட்டாலும், தற்போதைய v3 பழைய பெயரை deprecated alias-ஆகக் கருதி அனுமதிக்கும்; எனவே, அவசரப்படாமல் அடுத்த கட்டத்தில் அதைச் சரிசெய்யலாம்.)

படி 4: image tag-ஐ மாற்றவும். Traefik image-ஐ தற்போதைய v3 release-க்கு மாற்றவும் (இந்தக் கட்டுரையை எழுதும் போது traefik:v3.5). பின்னர்:

docker compose up -d
docker compose logs -f traefik

Compatibility mode இயக்கத்தில் இருப்பதால், உங்கள் v2 விதிகள் தொடர்ந்து செயல்படும். மேலும், நீங்கள் middleware label-களை மாற்றியமைத்த services-ஐ up -d மூலம் மீண்டும் உருவாக்கியுள்ளதால், அந்த routers சரியாகச் செயல்படும். ஆரோக்கியமான log-ல் field not found வரியோ அல்லது does not exist வரியோ இருக்காது.

இந்த மாற்றத்தின் போது ஏற்படும் கால இடைவெளியைப் பற்றி கவனமாக இருக்கவும். v3-க்குத் தெரியாத ஒரு middleware பெயரை (தட்டச்சுப் பிழை அல்லது நீக்கப்பட்ட விருப்பம்) ஒரு router குறித்தால், புதிய Traefik தொடங்கும் தருணத்திலிருந்து அந்த app container மீண்டும் உருவாக்கப்படும் வரை அந்த router இயங்காது. ஒரு server-ல் இது docker compose up -d பட்டியலைச் செயல்படுத்த எடுக்கும் சில நொடிகள் மட்டுமே. ஒரு route-ன் செயல்பாடு தடைபடக்கூடாது என்றால், மாற்றத்திற்கு முன்பே அந்த router-ன் middlewares label-லிருந்து பெயர் மாற்றப்பட்ட middleware-ஐ நீக்கிவிட்டு, மாற்றத்திற்குப் பிறகு மீண்டும் சேர்க்கவும். அந்த இடைப்பட்ட நிமிடத்தில் IP allow list இல்லாமல் அந்த route இயங்குமா என்பதை முன்கூட்டியே முடிவு செய்யவும்.

படி 5: ஒவ்வொரு service-ஆக விதிகளை இடம்பெயர்க்கவும். ஒரு நேரத்தில் ஒரு application-ஐ மட்டும் கையாளவும்: அதன் விதியை v3 syntax-க்கு மாற்றவும், docker compose up -d app மூலம் அந்த service-ஐ மட்டும் மீண்டும் உருவாக்கவும், பின்னர் அடுத்ததற்குச் செல்லும் முன் அதைச் சோதிக்கவும். ஏதேனும் ஒரு service-ன் விதியை உங்களால் இப்போதே மாற்ற முடியவில்லை என்றால், அந்த குறிப்பிட்ட router-க்கு traefik.http.routers.app.ruleSyntax=v2 label-ஐ வழங்கிவிட்டுத் தொடரவும்.

படி 6: compatibility mode-ஐ அணைக்கவும். அனைத்து விதிகளும் v3 syntax-க்கு மாறிய பிறகு, defaultRuleSyntax மற்றும் ஏதேனும் ruleSyntax label-களை நீக்கவும். Traefik-ஐ restart செய்து, dashboard-ல் அனைத்து routers-ம் பச்சை நிறத்தில் (green) உள்ளதா என்பதை உறுதிப்படுத்தவும். Compatibility mode-ஐ நிரந்தரமாகப் பயன்படுத்த வேண்டாம்: Traefik v3.4-ல் இந்த இரண்டு விருப்பங்களையும் deprecated என அறிவித்துள்ளது, அடுத்த பெரிய பதிப்பில் இவை நீக்கப்படும். எனவே, இது ஒரு தற்காலிகப் பாலம் மட்டுமே, இறுதி இலக்கல்ல.

மாற்றத்திற்கு முன்னும் பின்னும்: ஒரு service-ன் labels

ஒரே நேரத்தில் அனைத்து முக்கிய மாற்றங்களையும் கொண்ட ஒரு application இதோ: பல மதிப்புகளைக் கொண்ட Host, ஒரு PathPrefix placeholder, மற்றும் ஒரு ipWhiteList middleware. 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

அதே service v3-க்கு மாற்றப்பட்ட பிறகு:

  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

இரண்டு labels மாற்றப்பட்டுள்ளன. இந்த விதி, அதன் பல மதிப்புகளைக் கொண்ட Host-ஐ || மூலம் இணைக்கப்பட்ட இரண்டு matchers-ஆகப் பிரித்தது. மேலும், placeholder-ஐ PathRegexp-ஆக மாற்றியது, மற்றும் middleware label-ல் ipwhitelist-க்கு பதிலாக ipallowlist பயன்படுத்தப்பட்டது. entrypoint, certificate resolver, router-to-middleware இணைப்பு, மற்றும் service port ஆகியவற்றில் எந்த மாற்றமும் இல்லை.

ஒவ்வொரு service-ஐயும் dashboard மூலம் சோதித்தல்

ஒவ்வொரு மாற்றத்திற்குப் பிறகும், dashboard-ன் HTTP routers பக்கத்தைத் திறக்கவும். அனைத்து router-களும் பச்சை நிறத்தில் இருக்க வேண்டும். பிழை குறியீடு (error badge) கொண்ட router, அதன் துல்லியமான சிக்கலைக் குறிப்பிடும். பொதுவாக, புதிய பெயரில் இல்லாத middleware அல்லது v3 பதிப்பால் பகுப்பாய்வு செய்ய முடியாத rule காரணமாக இது நிகழும். அதன் பிறகு, ஒவ்வொரு hostname-ஆக வெளிப்புறத்திலிருந்து உறுதிப்படுத்தவும்:

curl -sI https://app.example.com/api/v1/status

ஒரு 200 அல்லது உங்கள் app-ன் வழக்கமான redirect, routing மற்றும் TLS ஆகிய இரண்டும் சரியாகச் செயல்படுவதைக் குறிக்கிறது. Traefik-லிருந்து வரும் ஒரு 404, router தொடங்கவில்லை என்பதைக் குறிக்கிறது; dashboard-க்குச் சென்று அதன் பிழைச் செய்தியைப் படிக்கவும். நீங்கள் பணிபுரியும் போது docker compose logs -f traefik-ஐ மற்றொரு terminal-ல் திறந்து வைத்திருக்கவும், ஏனெனில் container restart ஆகும் ஒவ்வொரு முறையும் பகுப்பாய்வு தோல்விகள் (parsing failure) அங்கு பதிவாகும்.

Rollback நேர்மை

v2 compose கோப்பு, அதன் static configuration மற்றும் acme.json backup ஆகியவற்றை, அனைத்து service-களும் v3-ல் இயங்கி, முழுமையாகச் சோதிக்கப்படும் வரை வைத்திருக்கவும். Rollback செய்வது என்பது migration-க்கு முந்தைய commit-க்கு மாறி, docker compose up -d-ஐ இயக்குவதாகும். இது image tag-ஐ மட்டும் மாற்றாமல், முழு கோப்பையும் மாற்ற வேண்டும். ஏனெனில், v3-க்குரிய labels v2-ல் தவறாகச் செயல்படும்; v2-ல் இருந்த labels v3-ல் தவறாகச் செயல்பட்டது போலவே இதுவும் அமையும். ipallowlist என்பது v2-ல் கிடையாது, மேலும் PathRegexp matcher-ஐயும் அங்கு parse செய்ய முடியாது. இடையில் acme.json தொலைந்துவிட்டாலோ அல்லது சேதமடைந்தாலோ, v2-ஐத் தொடங்குவதற்கு முன் backup நகலை restore செய்யவும். அப்போதுதான், rollback செய்யும்போது Let's Encrypt rate limit-ஐப் பயன்படுத்தி ஒரே நேரத்தில் ஐந்து certificates-ஐ மீண்டும் பெற வேண்டிய அவசியம் இருக்காது.

FAQ

Traefik v3-க்காக ஒவ்வொரு router விதியையும் நான் மீண்டும் எழுத வேண்டுமா?

இல்லை. Backticks பயன்படுத்தப்பட்ட எளிய Host(app.example.com) விதி இரண்டு பதிப்புகளிலும் செல்லுபடியாகும், இது பெரும்பாலான Compose அமைப்புகளுக்குப் போதுமானது. v2-ல் மட்டுமே இருந்த அம்சங்களைப் பயன்படுத்திய விதிகளுக்கு மட்டுமே மாற்றம் தேவை: Path மற்றும் PathPrefix-க்குள் regex அல்லது placeholders, ஒரே Host()-க்குள் பல hostnames, backticks-க்கு பதிலாக quotes, அல்லது நீக்கப்பட்ட Headers, HeadersRegexp, மற்றும் HostHeader matchers ஆகியவற்றைப் பயன்படுத்தியிருந்தால் மட்டுமே மாற்ற வேண்டும்.

Traefik v3-ல் ipWhiteList-க்கு என்ன ஆனது?

அது ipAllowList எனப் பெயர் மாற்றப்பட்டது, அதன் உள்ளமைவு மாறவில்லை. எனவே, traefik.http.middlewares.office.ipwhitelist.sourcerange=10.0.0.0/24 போன்ற v2 label, ipallowlist கொண்ட அதே வரியாக மாறும். v3.5 உள்ளிட்ட தற்போதைய v3 பதிப்புகள், பழைய பெயரை deprecated alias-ஆக இன்னும் ஏற்றுக்கொள்கின்றன. எனவே, பெயர் மாற்றப்படாத label-ம் allowlist-ஐத் தொடர்ந்து செயல்படுத்தும். இதை நிரந்தரமானதாகக் கருதாமல், பெயர் மாற்றத்தை உடனே செய்ய வேண்டும்: இந்த alias எதிர்காலத்தில் நீக்கப்படும். Traefik-க்குத் தெரியாத ஒரு middleware பெயரைப் பயன்படுத்தினால், அது router error-ஐ உருவாக்கி 404 பிழையைக் காட்டும். Dashboard-ல் பிழை தெரியும், அந்த hostname-க்கு வரும் கோரிக்கைகள் 404-ஐத் தரும்.

Traefik v3-ல் இன்னும் v2 விதி அமைப்பைப் படிக்க முடியுமா?

ஆம். நீங்கள் இடம்பெயரும்போது v2 அமைப்பை default-ஆக வைத்திருக்க static configuration-ல் core.defaultRuleSyntax: v2-ஐ அமைக்கவும். நீங்கள் default-ஐ மாற்றிய பிறகு, எஞ்சியிருக்கும் router-களுக்கு ruleSyntax=v2 label-ஐப் பயன்படுத்தவும். இவை இரண்டையும் தற்காலிகமாக மட்டுமே பயன்படுத்தவும்: Traefik v3.4-ல் இவற்றை deprecated என்று அறிவித்தது, அடுத்த பெரிய பதிப்பில் இவை நீக்கப்படும்.

மேம்படுத்தலுக்குப் பிறகு எனது Let's Encrypt certificates அப்படியே இருக்குமா?

ஆம். Traefik v3, v2 உருவாக்கிய acme.json கோப்பைத் தொடர்ந்து படிக்கும். எனவே, binary மாறியதால் மட்டும் certificates மீண்டும் உருவாக்கப்படாது. தொடங்குவதற்கு முன் அந்த கோப்பை பாதுகாப்பான இடத்தில் நகலெடுக்கவும். ஏனெனில், rollback செய்தாலோ அல்லது acme.json உள்ள volume நீக்கப்பட்டாலோ, அனைத்து certificates-ம் ஒரே நேரத்தில் மீண்டும் உருவாக்கப்படும். ஒரே hostname தொகுப்பிற்கு வாரத்திற்கு ஐந்து duplicate certificates மட்டுமே Let's Encrypt அனுமதிக்கிறது.

மேம்படுத்தலுக்குப் பிறகு Traefik v3 ஏன் தொடங்கவில்லை?

பெரும்பாலும், static configuration-ல் v3-ல் நீக்கப்பட்ட ஒரு விருப்பம் இருப்பதால், Traefik அதை அடையாளம் காண முடியாமல் தொடங்க மறுக்கிறது. நன்கு அறியப்பட்ட எஞ்சியிருக்கும் விருப்பங்களுக்கு (pilot, providers.docker.swarmMode, experimental.http3) log கோப்பு incompatible deprecated static option found என்று கூறி அந்தப் பிழையைக் காட்டும். tls.caOptional போன்ற Traefik-க்குத் தெரியாத எதற்கும், அது node-உடன் field not found என்று காட்டும். ஒவ்வொன்றையும் நீக்கிவிட்டு அல்லது மாற்றியமைத்துவிட்டு, container-ஐ மீண்டும் தொடங்கவும்.