Merging Swarm and Compose Files

[KBaur]

Hello Bret,
I have a query pertaining to the merging of Docker Compose and Swarm files into a single unified file.

Since the release of version 3.1, the incorporation of Swarm features, including secrets, into Docker Compose has become feasible. However, I have observed that when utilizing a merged file, certain features specific to Compose are disregarded during a stack deployment. This discrepancy in behavior during execution (docker stack deploy/docker compose up) raises a consideration about whether it is pragmatic to use a combined Swarm/Compose file for both development and production environments, as opposed to maintaining separate files, as was the conventional practice. The aim is to avoid potential inconsistencies arising from the differing treatment of features based on the deployment method.

Here is an example:

version: '3'
services:
  test-service:
    image: test/test-service:dev
    build: 
    	context: ./test-service
    	tags:
        - "test-service:dev"
    env_file: ./test-service/service.env
    depends_on:
      other-service:
        condition: "service_healthy"
    ports:
      - "12345:54321"
    volumes:
      - service-volume:/data
    networks:
      - test-network
    secrets:
      - service-secret
    deploy:
      resources:
        limits:
          memory: 512M
        reservations:
          memory: 64M
     update_config:
        parallelism: 1
        delay: 5s
        order: start-first
        failure_action: rollback
     rollback_config:
        order: start-first
      restart_policy:
          condition: on-failure
          delay: 40s
          max_attempts: 2
          window: 60s
          
networks:
  test-network:
    external: true

secrets:
  service-secret:
    external: true

volumes:
  service-volume:

I would greatly appreciate your insights on whether adopting a unified file for both development and production purposes is a sound approach in light of these considerations.

Thank you for your time!
BR, Kevin

[KBaur]

In this specific case, we are using compose for development and swarm for the production environment

[BretFisher]

I don't think you need to force yourself into a single file. The vary nature of their being a Build section that Swarm will ignore, and a Deploy section that Compose ignores, means the two environments won't be identical.
I do see people starting with a single file, but in many cases, they evolve into separate files for various reasons. I don't think there's a one-design-fits-all approach.

I personally don't use the same yaml file for Compose + Swarm anymore because Swarm is stuck on version 3.9 and Compose now uses "Compose Spec" for a versionless file... Giving Compose a lot more features than Swarm now for local development in that YAML file.

I wrote about some 2023 compose.yaml features here: https://www.bretfisher.com/cloud-native-devops-27/