DEV Community

Discussion on: Taking Docker Compose to Production with One Tool

Collapse
 
ajeetraina profile image
Ajeet Singh Raina • Edited

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...

Collapse
 
ajeetraina profile image
Ajeet Singh Raina

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:

services:
  test:
    ports:
      - target: 80
        x-ingress: /test
Enter fullscreen mode Exit fullscreen mode

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:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  rules:
  - http:
      paths:
      - path: /test
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80
Enter fullscreen mode Exit fullscreen mode

What's Happening in the Kubernetes YAML?

  • 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.

Thread Thread
 
bcouetil profile image
Benoit COUETIL 💫

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.

Thread Thread
 
ajeetraina profile image
Ajeet Singh Raina

Thanks for the feedback. Let me come up with the comparative write-up with some sample apps. Stay tuned!