Docker-Compose Application deployment on D-Swarm & K8s

Docker Engine Compose
1

I have a multi-container application having 3-4 component (i.e. 3-4 containers), application has multiple deployment scenarios like

1. Deployment Hosted by us –
o As Microservices deployment using K8S orchestration tool

2. On-premise delivery – hosted by customers (not using any Orchestration Tool)
o Small customers – not ready to manage complex multi-node cluster using any orchestration tool
o They just want as multi-container application deployment - Micro-service characteristic not required

3. On-premise delivery – hosted by customers (using orchestration Tool)
o Big On-prem customers
o Customer well create and manage multi-node clusters for deployment

I am thinking to develop & package application as a docker-compose application using docker compose file (3+) (linking via networks, port mapping etc.)

My assumption is – same compose file & application can be used in all deployment scenarios. Due to following understanding for various scenarios:

 As Compose file is compatible with Kubernetes and D-Swarm hence we can deploy same application & compose file on K8s or D-Swarm based clusters.
o Is my understanding is correct for production level deployment ?

 For small customers, who don’t have advance Microservices features requirement like Auto-scaling etc., they will deploy composed application using docker stack on single host machine
o Can be same docker-compose file having network linking & config will work in D-Swarm, K8s and Docker Engine (not in Swarm mode)?

Can someone please put some thoughts on this.

2

My impression is that Kubernetes has gotten so mainstream that, for your case (3), it’s likely that a “big” customer will already have a local k8s cluster, or will know how to set one up, or will be able to use something like Amazon EKS or Google GKE to get one.

If your application “fits” on a single host, Docker Compose describes it reasonably, and tools like Kompose translate it correctly, then using Docker Compose as the primary driver is probably fine. I feel like using Helm as a templating engine over native Kubernetes YAML files is the “more normal” way to use Kubernetes…but it requires having Kubernetes, and I don’t know the best way to deliver that to on-prem customers who can’t dedicate hardware to it.