I have used Kompose in the past. I wrote a blog post collabnix.com/translate-a-docker-c... last Nov. TBH, Kompose is an opinonated transformation. If you don't like the way it translates compose stuff into k8s (labels, annotations, ports?) you're stuck.
Compose Bridge uses Go templates for transformations, making it easy to extend or customize. You can learn more about it here: docs.docker.com/compose/bridge/cus...
In Docker Compose, you can define a service and expose its ports, but there’s no native support for things like Kubernetes Ingress (which allows external HTTP access to your service). So, if you're using Compose-bridge, you might want to add custom metadata (such as x-ingress) to your Compose file so that Compose-bridge knows to generate an Ingress resource when transforming the Compose file into Kubernetes YAML.
Here's an example of a Compose file with a service definition that includes the x-ingress custom attribute:
Now when you run Compose-bridge with this Compose file, it looks at the custom attribute x-ingress: /test and knows that you want to create a corresponding Kubernetes Ingress resource for your service. It then generates a Kubernetes YAML that includes an Ingress definition like this:
Ingress: This is a Kubernetes resource that allows external traffic to reach your service.
path: /test: This defines the URL path that external traffic will use to reach the test service.
backend: This points to the test service on port 80.
Why This is Useful:
Customization: Compose-bridge allows you to customize your Compose file with extra attributes (like x-ingress) that it uses during the transformation to Kubernetes resources.
Flexible Generation: This method enables the automatic generation of Kubernetes-specific resources (like Ingress) that aren’t directly available in Docker Compose.
In nutshell,
By adding x-ingress: /test in the Compose file, you're providing additional information that Compose-bridge uses to generate the appropriate Kubernetes Ingress resource. This is a way to bridge the gap between Docker Compose and Kubernetes, customizing the transformation for your specific needs.
Hi, I've been a professional developer and DevOps engineer for 18 years 🤓. I share original content from diverse real-world production experiences through monthly blog posts.
Thank you for your response, but it is still hard to grasp the advantages over Kompose. "don't like the way" is not precise enough to discard something that is concise and working.
A side by side comparison of files, and traction of one against the other in the community, would help me considering switching to Compose bridge.
Great question.
I have used Kompose in the past. I wrote a blog post collabnix.com/translate-a-docker-c... last Nov. TBH, Kompose is an opinonated transformation. If you don't like the way it translates compose stuff into k8s (labels, annotations, ports?) you're stuck.
Compose Bridge uses Go templates for transformations, making it easy to extend or customize. You can learn more about it here: docs.docker.com/compose/bridge/cus...
Let me answer your second question.
In Docker Compose, you can define a service and expose its ports, but there’s no native support for things like Kubernetes Ingress (which allows external HTTP access to your service). So, if you're using Compose-bridge, you might want to add custom metadata (such as x-ingress) to your Compose file so that Compose-bridge knows to generate an Ingress resource when transforming the Compose file into Kubernetes YAML.
Here's an example of a Compose file with a service definition that includes the x-ingress custom attribute:
Now when you run Compose-bridge with this Compose file, it looks at the custom attribute x-ingress: /test and knows that you want to create a corresponding Kubernetes Ingress resource for your service. It then generates a Kubernetes YAML that includes an Ingress definition like this:
What's Happening in the Kubernetes YAML?
Why This is Useful:
In nutshell,
By adding x-ingress: /test in the Compose file, you're providing additional information that Compose-bridge uses to generate the appropriate Kubernetes Ingress resource. This is a way to bridge the gap between Docker Compose and Kubernetes, customizing the transformation for your specific needs.
Thank you for your response, but it is still hard to grasp the advantages over Kompose. "don't like the way" is not precise enough to discard something that is concise and working.
A side by side comparison of files, and traction of one against the other in the community, would help me considering switching to Compose bridge.
Thanks for the feedback. Let me come up with the comparative write-up with some sample apps. Stay tuned!