I'm trying to set up my docker project name, and according to documentation there should be the docker compose file top-level property 'name' to do so, but I can't figure out how to use it.
I found references at the end of The Compose application model section and in the specific Name top-level element section, but none of the two have an example and I still get an error when trying to run docker-compose up -d
docker-compose.yml file
version: "3.3"
name: "project-name"
services:
# ...
The error
ERROR: The Compose file './docker-compose.yml' is invalid because:
Invalid top-level property "name". Valid top-level sections for this Compose file are: version, services, networks, volumes, secrets, configs, and extensions starting with "x-".
You might be seeing this error because you're using the wrong Compose file version. Either specify a supported version (e.g "2.2" or "3.3") and place your service definitions under the `services` key, or omit the `version` key and place your service definitions at the root of the file to use version 1.
For more on the Compose file format versions, see https://docs.docker.com/compose/compose-file/
To use the compose-spec, you need a tool that parses that spec (like docker compose with a space) and you shouldn't be specifying a version. If you are parsing the file with an older version of docker-compose or a tool that doesn't use the spec, these newer fields won't work and you'll likely see it fall back to version 1 without a version field.
With version: "3.3", that expects the format defined in the version 3 documentation.
Related
I need to create a few images for my application functionality (a few web applications in azure that work together) and I also want to mark the images with several tags like latest, minor, major, and full versions. I have read about extensions here
https://stackoverflow.com/a/59911532/4511281 and https://www.back2code.me/2020/01/multiple-image-tags-with-docker-compose/.
But it's not so clear for me, is that will rebuild the same image 4 times or it will build only once and then tag them 4 times? Or should I just build images with the "latest" tag and then use some other commands to tag the images and push them to container storage?
There are actually a few ways to build images and add multiple tags.
slow version with docker-compose
rebuild images several times with different tags passed as environment variables. This version will use cashed images for the next build, but anyway it will take time to rebuild the image.
using docker-compose extensions
based on information on the website it is possible to define several tags with the same yaml file. Of course, they can be passed as environment variables. I am not sure if this method doesn't rebuild the images again, haven't tested it. https://www.back2code.me/2020/01/multiple-image-tags-with-docker-compose/#use-yaml-extension-to-define-multiple-tags
using docker buildx bake
I like this version more. It also uses extensions, but it allows you to define tags much easy. https://docs.docker.com/engine/reference/commandline/buildx_bake/#examples
Hope this review can help someone else.
Since Compose 2.6.0 you can define a list of tags in the build section:
services:
foo:
image: foo:latest # If omitted will default to 'project-service:latest'.
build:
context: .
tags:
- foo:1.2
- foo:1.2.3
That is not yet supported by docker buildx bake, in this case you have to put tags inside x-bake:
services:
foo:
image: foo:latest # Will be ignored if you use tags below.
build:
context: .
x-bake:
output: type=image
tags:
- foo:latest
- foo:1.2
- foo:1.2.3
Then, want you to make several services, tagged with several names? Maybe you should create a docker-compose.yaml file to define all of those images tag. Every Service has his own directory, in which there is the Dockerfile runned when by docker-compose.yaml when you launch
docker-compose run
Have a look at this project, I think that you want something like that: https://github.com/Aragorn1992gb/multi-docker4/blob/master/docker-compose.yml
Using this approach, you will have n different images as n services you built. Docker compose will link all of those services to work all together. In the example you can see that there are'postgres' and 'redis' service that load a pre-built image from docker-hub. Then there are also 'nginx', 'api', 'client' and 'worker' services, that follow the Dockerfile.dev inside their folders.
To be more clear, a service tag can be different from the folder name of the service. Have a look to 'api' service:
it depends on postgres (this is the relationship)
his image is built by Dockerfile.dev file (you use .dev only in development environment). It is stored on "server" folder, then copied inside the container at app folder (./server:app)
it has some volumes in some directories (that means when you change something in those folders, the application will takes the updates without re-generate the image)
environment specify some env variables
Hoping that this can help you
UPDATES: reading better your question, the approach is similar and the images are, of course, different.
Error: You might be seeing this error because you're using the wrong Compose file version. Either specify a supported version (e.g
"2.2" or "3.3") and place your service definitions under the
services key, or omit the version key and place your service
definitions at the root of the file to use version 1. For more on the
Compose file format versions, see
https://docs.docker.com/compose/compose-file/
Yaml:
You have a typo in the first line. Probably it should start with version: 3.3 link.
Yml depends on formatting for nested structures, and for inaccurate filled files it is very hard to find out all format errors that violate original meaning. Is there any alternative to yml format for docker-compose configuration file?
TLDR; No.
From Documentation
The Compose file is a YAML file defining services, networks and volumes. The default path for a Compose file is ./docker-compose.yml
Now to answer on your arguments regarding the format and the difficulty to find errors violating original meaning:
yamllint is a first tool that can help your validate your overall yaml syntax (whatever the target expected format).
docker-compose config will read your docker-compose.yml file in and report errors if it does not comply with the expected compose file format.
When using the integrated docker-compose structure in Visual Studio 2017, the system provides visibility to a two-tiered docker-compose structure.
docker-compose.yml and docker-compose.override.yml
Settings in the override take precedent over those in the former file. When the file is actually executed, it includes a third, auto-generated Docker compose file ...
docker-compose.vs.*configuration*.g.yml
This latter file contains mostly values related to debugging interactions and mapping volumes in for code you want. Generally, you wouldn't want to change any of these.
One thing that it does by default is to set the entrypoint which ends up becoming the command for the container. As this file is applied last (after the compose file and the override, it is holding precedence over the other two resulting in not being able to override that entrypoint.
Is there a way around this?
I have a lot of services, which use the same basic configuration in docker-compose. Actually most of the configuration is the same, with some minor tweaks.
I have seen that it is somehow possible to inherit values in YAML. Can I use this in docker-compose to define a "default-service" and use this all over in the other services for e.g. docker-compose run? How would I do this?
No, you cannot do that using YAML. The only inheritance like feature in YAML is the Merge Key Language Independent Type and that only works withing one YAML document, not between multiple documents in the same YAML file (separated by ---) and certainly not between different YAML files.
However docker-compose reads docker-compose.yml and if available docker-compose.override.yml, where the values in the second file (if available) override the ones in the first. Combined with the -f option to specify an input YAML file for docker-compose you can use a shared base file with different overrides.
This is a feature of docker-compose and is done on the data loaded from the YAML files, not by combining the YAML files and then loading them.