<p>One could use <a href="https://composerize.com/" rel="nofollow noreferrer">Composerize</a> to create a consistent docker-compose.yml.</p>

<p>There seems to be two options. Options one is to enter some docker run command, e.g. <code>docker run app/test_clients</code> on their website, which will return:</p>

<pre><code>version: '3.3'
services:
    test_clients:
        image: app/test_clients
</code></pre>

<p>Or use the <a href="https://github.com/magicmark/composerize#cli" rel="nofollow noreferrer">command line</a>: <code>composerize docker run app/test_clients</code>.</p>

CC BY-SA 4.0
2019-12-24T17:18:49.497Z
2019-12-24T17:18:49.497Z
030
<p>You could also introduce a YAML linter to your CI to ensure that a consistent docker-compose.yml format will be enforced, like <a href="https://www.npmjs.com/package/yaml-lint" rel="nofollow noreferrer">yaml-lint</a>. According the docs it should be possible to define a certain format. If the pipeline fails, then the developer has to apply changes in order to fix the build.</p>

CC BY-SA 4.0
2019-12-24T17:23:39.313Z
2019-12-24T17:23:39.313Z
030
<p>Is there some globally admitted coding conventions for <code>docker-compose</code> files?
Below is a sample <code>docker-compose.yml</code> from a small project we have here:</p>

<pre><code>version: 3
networks:
  net:
    driver: 'bridge'

services:
  app:
    build: .
    networks:
    - net
    ports:
    - 3000:3000
  redis:
    image: redis:alpine
    networks:
    - net
  client:
    image: "app/test_clients"
    deploy:
      replicas: '3'
</code></pre>

<p>The quoting is especially inconsistent. Sometimes quotes are used around text and numerical literals. Sometimes they aren't. Sometimes single quotes are used, sometimes double quotes are used instead. The various example in the <a href="https://docs.docker.com/compose/compose-file/" rel="nofollow noreferrer">official docker-compose documentation</a> seems relatively inconsistent in that area too.</p>

<p>This is valid YAML. And YAML is very permissive about quoting and, as far as I know, quotes could simply be omitted in most of the cases. I know this is probably a matter of internal policy but I wonder if there are some commonly accepted "best practices" in that matter.</p>

CC BY-SA 4.0
2019-02-05T22:36:48.457Z
This answer seems well considered https://stackoverflow.com/a/22235064/329496
simbo1905
CC BY-SA 4.0
2019-12-24T17:19:39.673Z
@simbo1905 Could you post an answer?
030
CC BY-SA 4.0
2019-12-24T17:29:26.993Z
According to this [Q&A](https://stackoverflow.com/a/40158753/2777965) one could also use `docker-compose config`. I tried it and it returned `ERROR: Version in "./docker-compose.yml" is invalid - it should be a string.` and `WARNING: Some services (client) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.`.
030
CC BY-SA 4.0
2024-11-23T18:58:48.000Z
Looks like we still don't have globally admitted coding conventions. So you could use one of the docker compose formatting utils for that: - [compose_format](https://github.com/funkwerk/compose_format/) - although sometimes it's not working. - [docker-compose-linter (dclint)](https://github.com/zavoloklom/docker-compose-linter) - with `--fix` option.
zavoloklom
<docker-compose><linting>
Coding conventions for docker-compose files?
Sylvain Leroux
# Coding conventions for docker-compose files?

(Asked by: username_0 on 2019-02-05)

Is there some globally admitted coding conventions for docker-compose files?
Below is a sample docker-compose.yml from a small project we have here:
version: 3
networks:
  net:
    driver: 'bridge'

services:
  app:
    build: .
    networks:
    - net
    ports:
    - 3000:3000
  redis:
    image: redis:alpine
    networks:
    - net
  client:
    image: "app/test_clients"
    deploy:
      replicas: '3'

The quoting is especially inconsistent. Sometimes quotes are used around text and numerical literals. Sometimes they aren't. Sometimes single quotes are used, sometimes double quotes are used instead. The various example in the official docker-compose documentation seems relatively inconsistent in that area too.
This is valid YAML. And YAML is very permissive about quoting and, as far as I know, quotes could simply be omitted in most of the cases. I know this is probably a matter of internal policy but I wonder if there are some commonly accepted "best practices" in that matter.

**Tags:** docker-compose, linting

> **Comments:**
> **username_1**: This answer seems well considered https://stackoverflow.com/a/22235064/329496  
> **username_2**: @username_1 Could you post an answer?  
> **username_2**: According to this [Q&A](https://stackoverflow.com/a/40158753/2777965) one could also use `docker-compose config`. I tried it and it returned `ERROR: Version in "./docker-compose.yml" is invalid - it should be a string.` and `WARNING: Some services (client) use the 'deploy' key, which will be ignored. Compose does not support 'deploy' configuration - use `docker stack deploy` to deploy to a swarm.`.  
> **username_3**: Looks like we still don't have globally admitted coding conventions. So you could use one of the docker compose formatting utils for that: - [compose_format](https://github.com/funkwerk/compose_format/) - although sometimes it's not working. - [docker-compose-linter (dclint)](https://github.com/username_3/docker-compose-linter) - with `--fix` option.  

---

## 2 answers

### Answer by username_2 on 2019-12-24. Score: 3

One could use Composerize to create a consistent docker-compose.yml.
There seems to be two options. Options one is to enter some docker run command, e.g. docker run app/test_clients on their website, which will return:
version: '3.3'
services:
    test_clients:
        image: app/test_clients

Or use the command line: composerize docker run app/test_clients.


---

### Answer by username_2 on 2019-12-24. Score: 0

You could also introduce a YAML linter to your CI to ensure that a consistent docker-compose.yml format will be enforced, like [yaml-lint](https://www.npmjs.com/package/yaml-lint). According the docs it should be possible to define a certain format. If the pipeline fails, then the developer has to apply changes in order to fix the build.


---

