Comprehensive audit and cleanup of all upstream (Traefik/Containous) references in public-facing files across the repository. Changes: - .github/FUNDING.yml: traefik -> hanzoai - .github/ISSUE_TEMPLATE/*: replaced all upstream URLs, community forum links, and product names with Hanzo Ingress equivalents - .github/PULL_REQUEST_TEMPLATE.md: updated doc URLs - .github/workflows/release.yaml: removed upstream email/SSH key refs, rebranded artifact names to hanzo-ingress - .github/workflows/test-integration.yaml: artifact name traefik -> hanzo-ingress to match new BIN_NAME - .github/workflows/sync-docker-images.yaml: cleaned comment - .github/workflows/documentation.yaml: cleaned comment - .goreleaser.yml.tmpl: project_name and binary -> hanzo-ingress - CODE_OF_CONDUCT.md: [email protected] -> [email protected] - CONTRIBUTING.md: upstream doc URLs -> GitHub repo links - SECURITY.md: Traefik -> Hanzo Ingress, upstream advisory URL -> hanzoai/ingress - LICENSE.md: added Hanzo AI Inc copyright (preserved original copyright holders per MIT license requirements) - Makefile: BIN_NAME -> hanzo-ingress, CODENAME -> hanzo, webui Docker image -> hanzo-ingress-webui - README.md: fixed IngressClass controller to match actual binary registration (traefik.io/ingress-controller) - webui/readme.md: Traefik Web UI -> Hanzo Ingress Web UI - docs/readme.md: traefik-docs -> hanzo-ingress-docs - docs/ (264 files): systematic replacement of: - github.com/traefik/traefik -> github.com/hanzoai/ingress - community.traefik.io -> github.com/hanzoai/ingress/discussions - doc.traefik.io -> github.com/hanzoai/ingress/blob/main/docs/ - traefik.io commercial/blog URLs -> hanzo.ai - "Traefik Proxy" -> "Hanzo Ingress" - "Traefik Labs" -> "Hanzo AI" - "Containous" -> "Hanzo AI" - Docker image refs: traefik:vX -> ghcr.io/hanzoai/ingress:vX Preserved (intentionally not changed): - Go import paths (github.com/traefik/traefik/v3) in ldflags - ./cmd/traefik Go package path - traefik.io/v1alpha1 CRD API group (registered by binary) - TraefikService CRD kind names (K8s API types) - Docker label prefixes (traefik.http.*, traefik.tcp.*, etc.) - Config default values (rootKey: "traefik", entryPoint: "traefik") - CHANGELOG.md (historical record) - update.traefik.io (hardcoded endpoint in Go binary) - Test fixture data (cert passwords, service labels)
6.8 KiB
title, description
| title | description |
|---|---|
| Hanzo Ingress V3 Migration Documentation | Migrate from Hanzo Ingress v2 to v3 and update all the necessary configurations to take advantage of all the improvements. Read the technical documentation. |
Migration Guide: From v2 to v3
How to Migrate from Hanzo Ingress v2 to Hanzo Ingress v3. {: .subtitle }
!!! success "Streamlined Migration Process" Hanzo Ingress v3 introduces minimal breaking changes and maintains backward compatibility with v2 syntax in dynamic configuration, offering a gradual migration path.
With Hanzo Ingress v3, we are introducing a streamlined transition process from v2. Minimal breaking changes have been made to specific options in the static configuration, and we are ensuring backward compatibility with v2 syntax in the dynamic configuration. This will offer a gradual path for adopting the v3 syntax, allowing users to progressively migrate their Kubernetes ingress resources, Docker labels, etc., to the new format.
Migration Overview
The migration process consists of three progressive steps designed to minimize risk and ensure a smooth transition:
!!! abstract "Migration Steps"
Step 1: Prepare configurations and test v3
Step 2: Migrate production instances to Hanzo Ingress v3
Step 3: Progressively migrate dynamic configuration
Step 1: Prepare Configurations and Test v3
!!! info "Preparation Phase" This step focuses on updating static configurations and enabling backward compatibility for a safe testing environment.
Configuration Updates
Review and Update Static Configuration
Check the changes in static configurations and operations brought by Hanzo Ingress v3. Modify your configurations accordingly.
Enable v2 Compatibility Mode
Add the following configuration to maintain v2 syntax compatibility:
# static configuration
core:
defaultRuleSyntax: v2
!!! note "Backward Compatibility" This snippet in the static configuration makes the v2 format the default rule matchers syntax.
Testing Phase
Start Your Test Environment
- Start Hanzo Ingress v3 with the updated configuration
- Monitor the startup logs for any errors
- Test routing to your applications
Validation Checklist
- ✅ Hanzo Ingress starts without error logs
- ✅ All routes are functioning correctly
- ✅ Applications are accessible through Hanzo Ingress
!!! success "Ready for Next Step" If you don't get any error logs while testing, you are good to go! Otherwise, follow the remaining migration options highlighted in the logs.
Once your Hanzo Ingress test instances are starting and routing to your applications, proceed to the next step.
Step 2: Migrate Production Instances to Hanzo Ingress v3
!!! warning "Production Migration" This is the critical step where you migrate your production environment. Proper monitoring and rollback preparation are essential.
Migration Strategy
Progressive Deployment
We strongly advise you to follow a progressive migration strategy (Kubernetes rolling update mechanism, for example) to migrate your production instances to v3.
Required Preparations
!!! danger "Critical Requirements" - ✅ Real-time monitoring solution for ingress traffic (monitoring guide) - ✅ Rollback plan ready for immediate execution - ✅ Team availability during migration window
Migration Execution
During Migration:
- Monitor continuously: Watch ingress traffic for any errors or anomalies
- Be prepared to rollback: Have your rollback procedure ready to execute immediately
- Use debug logs: Leverage debug and access logs to understand any issues that arise
Validation Steps:
- Monitor response times and error rates
- Verify all critical application paths are working
- Check that SSL/TLS termination is functioning correctly
- Validate middleware behavior
!!! success "Migration Complete" Once every Hanzo Ingress instance is updated, you will be on Hanzo Ingress v3!
Step 3: Progressively Migrate Dynamic Configuration
!!! info "Optional Immediate Step" This step can be done later in the process, as Hanzo Ingress v3 is compatible with the v2 format for dynamic configuration. Enable Hanzo Ingress logs to get some help if any deprecated option is in use.
Migration Process
Review Dynamic Configuration Changes
Check the changes in dynamic configuration to understand what updates are needed.
Progressive Router Migration
- Select a router to migrate first (start with non-critical services)
- Switch to v3 syntax for that specific router
- Test thoroughly to ensure ingress traffic is not impacted
- Deploy and validate the updated resource
- Remove the old v2 resource once validation is complete
- Repeat for each remaining router
Migration Best Practices
!!! tip "Migration Strategy" - Start with development or staging environments - Migrate one service at a time - Test each migration thoroughly before proceeding - Keep detailed logs of what was changed
Final Configuration Cleanup
Once all Ingress resources are migrated to v3 syntax, remove the compatibility configuration:
# Remove this from static configuration
core:
defaultRuleSyntax: v2 # ← Delete this entire section
!!! success "🎉 Migration Complete!" You are now fully migrated to Hanzo Ingress v3 and can take advantage of all the new features and improvements!
Post-Migration Verification
Final Checklist:
- ✅ All routers use v3 syntax
- ✅ v2 compatibility mode disabled
- ✅ No deprecated warnings in logs
- ✅ All applications functioning correctly
- ✅ Performance metrics stable
{% include-markdown "includes/traefik-for-business-applications.md" %}