Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for `extends` feature in Compose v3 / docker stack deploy #31101

Open
shin- opened this issue Feb 16, 2017 · 132 comments

Comments

@shin-
Copy link
Contributor

commented Feb 16, 2017

As can be seen in docker/compose#4315 , the extends feature that exists in docker-compose seems to be popular among users despite its flaws. However, it has so far not been added in the Engine's implementation of the Compose format. So far, we have advised users to simply flatten their Compose file structure when using v3, but is this the long-term solution we want to go with? How can we provide a clear upgrade path for users who have come to rely on this feature?

cc @dnephin @vdemeester

@shouze

This comment has been minimized.

Copy link
Contributor

commented Feb 17, 2017

I've added some notes docker/compose#4315 (comment) to me bringing back extends as it exists up to docker compose file 2.1 version is not a good idea but the main feature I miss is to be able to declare abstract services (that should never be runned but could be used to group common properties of services for convenience).

@jakajancar

This comment has been minimized.

Copy link

commented Feb 22, 2017

Agreed on comments from docker/compose#4315 that the way extends worked was a bit spartan.

I won't recommend a solution, but FWIW, to show the extent of abuse, here are the conventions that adorn the top of our compose file:

#
# Docker Compose configuration
#
# Due to lack of "expressivity" in Compose, we define our own couple of service
# "pseudo-types":
#
#   - image-only services (name: *-image)
#
#     The only goal of these is to build images. No other services build images.
#
#     These have entrypoint overridden to exit immediately.
#
#   - base services (name: *-base)
#
#     These contain common configuration and are intended to be extended.
#
#     Their command (not entrypoint, to keep the original one) is overridden to
#     exit immediately. Service must support a command to exit immediately.
#
#   - task services (name: *-task)
#
#     These are intended for running one-off commands.
#
#     Their default command is overridden to exit immediately. Service must
#     support a command to exit immediately.
#
#   - "real" services
#
#     These are actual services that stay up and running.
#
version: '2'
services:
  ...
@nicodmf

This comment has been minimized.

Copy link

commented Mar 4, 2017

I think the extends as in v2.1 is a good choice. Extends is actually simple and understandable, this is too a good pratice for each environnement to have a little and readable transformation between dev, prod and env.

Actually, i have

  • a common docker-compose file which present the base rules
  • a dev docker compose extending it and with facilities for developper
  • a staging docker compose extending common too and with facilities for this environnement
  • a production docker compose extending common too and with facilities for this environnement, specially container replication, rules about restarting, etc...

This works, and i don't understand why we should search in this ticket a complete rewrite, but more the keep of an interessing feature. Extends is a good part with special use cases that other techniques can't resolv easily. I'm happy with extends possibilities.

@sambernet

This comment has been minimized.

Copy link

commented Mar 13, 2017

Blocking us from upgrading to v3.x format as well.

We keep our docker container definitions in a folder-per-instance layout, where each folder contains a docker-compose.yml that defines the env specifics for the container instance at hand. To factor out the common stuff (DRY) we use base service definitions in a parent folder and use extend.

So when I need to manage a particular container instance, I just need to cd into the right folder and can then directly run docker-compose commands without further configuration (no -f flags required that team members need to lookup or know, just works as expected out-of-the-box).

@SC7639

This comment has been minimized.

Copy link

commented Mar 17, 2017

I'm blocked from using version 3 compose files.

I use services.yml to define the base layout of my services and then extend that with dev.services.yml for my development evironment (mostly adding volumes) but I like the (DRY) re usability of extends when it was added. It's not a deal breaker but it would keep me from moving to version 3 unless there is a must have feature.

@sambernet

This comment has been minimized.

Copy link

commented Mar 17, 2017

I'm not against improving the v2.1 'extends' solution with something more appropriate though. Something like abstract services could be both more safe to use and more powerful.

For example (since it's abstract) I could imagine supporting abstract volumes/mountpoints/networks, where the abstract base service defines a local mount point or a required network for a service, without defining the host part - meaning a deriving service could then define/map the host part of the mounts/volumes and networks to whats appropriate in his host/stage environment.

That's an example of something we can't do now with 'extends' as far as I know, and would open some interesting possibilities.

@alwaysastudent

This comment has been minimized.

Copy link

commented Mar 21, 2017

Taking away extends feature was not helpful at all. We have a lot of web services started with the same volumes mapped, environment variables and labels set. They also have same healthcheck policies. And Not to mention ports. Combining compose files using multiple -f option is tedious and error prone if you are dealing with multiple projects in the same host.

@alwaysastudent

This comment has been minimized.

Copy link

commented Mar 21, 2017

@shin- will this be brought back on 3.2 schema ?

@efrecon

This comment has been minimized.

Copy link

commented Mar 29, 2017

I really, really would love to get extends back into the file format. I have been using it to further refine abstract services for a number of projects. I understand that multiple -f options fits almost the bill, but it doesn't always work. For example, I rather often change the name of the abstract service into something that is more meaningful in the context of the project at hand. This is something that the overriding that occurs with multiple -f options does not support.

I would not mind loosing the exact extends though, as long as their is some other way to "instantiate" an abstract service in a file.

@jazzfog

This comment has been minimized.

Copy link

commented Apr 15, 2017

I have a setup with a common service file and bunch of services extending it, changing mostly volumes, so I would say I rely on extends feature and do not see other good way to describe my setup.

--frustrated

@rationull

This comment has been minimized.

Copy link

commented Apr 19, 2017

+1
I can see the logic behind the recommendation to flatten docker-compose files but I don't like the idea of duplicating the code that defines our development service topology across multiple projects. We'll use the -f workaround for now, with shell scripts so that developers don't have to remember which services to include in which cases.

I'm hoping a satisfactory solution can be found here to enable better factoring of compose structures!

@MadBomber

This comment has been minimized.

Copy link

commented Apr 21, 2017

At the top of my use case list is to DRYup my configuration managed hoard of services. I thought I'd be able to take advantage of 'extends' if v3. I don't want to go back to v2... and I don't want to have special cases where I must use the -f process work-around.

@cirocosta

This comment has been minimized.

Copy link
Contributor

commented Apr 28, 2017

Hey, did anyone start working on this? I can't find a PR to keep track. It'd simplify a lot some things for us here as well (use-case very similar to some described above).

@JanNash

This comment has been minimized.

Copy link

commented May 13, 2017

Since version 3 is frozen and I needed a way to share common configuration, I hacked a small workaround, which I think I could share here (I'm not sure if this is the right place but feel free to tell me where else I can share this info :))

I'm not going to elaborate on it here, since there's a readme in the repo.
Have a nice one, everyone ☮️

Edit:

Sorry, here's the link :D

@gustavosbarreto

This comment has been minimized.

Copy link

commented May 23, 2017

+1

2 similar comments
@fabiohbarbosa

This comment has been minimized.

Copy link

commented May 23, 2017

+1

@ccamp46

This comment has been minimized.

Copy link

commented Jun 15, 2017

+1

@JanNash

This comment has been minimized.

Copy link

commented Jun 15, 2017

Thanks for the +1s 💃
In the meantime, I've found another docker noop image, which smaller by a factor of 10^3 (due to the actual noop being written in assembly).

Unfortunately, there's no License in that repo. I already wrote a message to the owner on facebk but he didn't answer yet. Maybe he'll add a license if more people query him about it :)

@grayside

This comment has been minimized.

Copy link

commented Jun 16, 2017

Something that might help some of the extends use cases (those within a single file) would be support for YAML anchors: https://learnxinyminutes.com/docs/yaml/

It appears that the JSON Schema may be failing validation on them service must be a mapping, not a NoneType..

@JanNash

This comment has been minimized.

Copy link

commented Jun 16, 2017

Hey, @grayside, yaml anchors do work, at least for me. See my comment above for how I use them.

@shouze

This comment has been minimized.

Copy link
Contributor

commented Jun 16, 2017

Ok but it's too sad to use some noop service no?

Especially for env vars, what kind of values those env vars handle? If it's about secrets, use swarm secrets feature (or any other secrets solution). If it's about settings, we're ok that most of the time settings are app/service specific, not intended to be shared between services.

If you need to share settings between services, most of the time it's when you launch the same container image but for different runtime purposes/tasks (consumer, producer, http worker, ...).

@JanNash

This comment has been minimized.

Copy link

commented Jun 16, 2017

If it's about settings, we're ok that most of the time settings are app/service specific, not intended to be shared between services.

I tend to disagree. In the project I'm currently working on, I use it for example for volumes:

# Volume paths
environment:
  - &volume_a        volume-a:/usr/share/my_project/volumes/volume-a
  - &volume_b        volume-b:/usr/share/my_project/volumes/volume-b
  - &volume_c        volume-c:/usr/share/my_project/volumes/volume-c
  - &volume_d        volume-d:/usr/share/my_project/volumes/volume-d

Now I can specify these volumes like that:

volumes:
  - volume-a:
  - volume-b:
  - volume-c:
  - volume-d:

services:
  some-service:
    image: some-image
    volumes:
      - *volume_a
      - *volume_b
  
  some-other-service:
    image: some-other-image
    volumes:
      - *volume_b
      - *volume_c

  some-third-service:
    image: yet-another-image
    volumes:
      - *volume_a
      - *volume_b
      - *volume_c
      - *volume_d

This makes it way easier to navigate different volumes without having to think about which container you're in. Imho, this is one way to make your docker-compose setup more consistent and easier to use and maintain.

@shouze

This comment has been minimized.

Copy link
Contributor

commented Jun 16, 2017

Ok yes I understand @JanNash but in your example below you don't have any noop service right?

@Yajo

This comment has been minimized.

Copy link

commented Jun 16, 2017

But anchors are not enough for many cases.

My case involves supporting several environments for the same project. You can see a scaffolding for our projects here.

When you develop, you use devel.yaml, but in production you use prod.yaml. There's also test.yaml. All of them inherit from common.yaml and get some common variables from an .env file.

Each one has its own peculiarities:

  • devel environment aims for development speed, so it uses build args that produce faster builds, mounts volumes with the app code from the developer computer, and adds some dummy services that isolate the app from the outside world.
  • prod aims for stability instead, so it downloads and compiles all code, and bundles it in the image itself instead of using volumes. Builds are slower, but more secure.
  • test aims to be exactly like prod, but with isolation from external services, to avoid polluting the external world.

This simple separation allows to have a very agile and flexible DevOps pipeline, where everybody uses the same code among different stages, with just little tweaks depending on the environment in use.

I tried to move to compose file format v3, but not only extends is unsupported, but also .env, so right now it would be a maintenance nightmare (more because of the lack of .env, to be honest). When deciding between Swarm and DRY, we chose DRY for now, but some day we'll need Swarm and I hope that day both features are supported again... ☺️

... or at least we have a way to generate a valid DRY-less format from a DRY-ful solution. I thought docker-compose bundle was for that, but seems to be doomed to deprecation right now...

... or we have a different tool that makes everything (I'm keeping an eye on ansible-container too). But surely this is not "the fix".

@grayside

This comment has been minimized.

Copy link

commented Jun 16, 2017

The link in #31101 (comment) includes a README with the working example of YAML anchors. Looking it over and trying it again today, it works fine. Not sure what I'm doing differently.

@JanNash 👍

@JanNash

This comment has been minimized.

Copy link

commented Jun 16, 2017

@Yajo I hear you and as said, it's a workaround and it would be better by an order of magnitude if there was a good, built-in, DRY solution supplied by docker/moby/docker-compose (whatever is the correct reference). Let's all hope that will come soon because apart from that, I'm pretty happy with docker compose 👍

For the sake of missing .env support, I also hacked a workaround (my project's not in production yet, so my talk is a bit cheap, I know :)). To support different sets of env vars (dependency and image versions/tags, for example) in different environments (for me right now, that is local-development and a small dev-server), I use two files, local.env and development.env and instead of running my commands by just docker-compose <command>, I either source the respective .env file into my shell before, or I run it like this: (. local.env && docker-compose <command>). Still a hack, but for now, I'm quite happy with this.

Have a nice one, y'all 🚶

@dedalozzo

This comment has been minimized.

Copy link

commented Jul 30, 2018

@teodorescuserban

This comment has been minimized.

Copy link

commented Jul 30, 2018

@dedalozzo, "in the thread" == ?

@dedalozzo

This comment has been minimized.

Copy link

commented Jul 30, 2018

@luckydonald

This comment has been minimized.

Copy link

commented Aug 15, 2018

Wouldn't we be able to get the same extendability back if we combine
yaml extension fields (compose 2.1+/3.4+)
with allowing those x- fields to reference other files?

So we could allow a root include listing to specify files to load.
they would be put in an x-include and be instantly usable via standard YAML anchors & merging.


Current compose v2.1+
# /docker-compose.yml
version: '2.1'

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    extends:
      file: reverse_proxy/docker-compose.yml
      service: proxy
    restart: 'always'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    extends:
      file: webservice/docker-compose.yml
      service: app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx
# /proxy/docker-compose.yml
version: '2.1'
services:
  proxy:
    build: ./
    volumes:
      - /certs:/certs:ro
# /webservice/docker-compose.yml
version: '2.1'
services:
  app:
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

Idea of compose v3.X
# /proxy/docker-compose.yml
version: '3.9'
services:
  proxy:
    &proxy
    build: ./
    volumes:
      - /certs:/certs:ro
# /webservice/docker-compose.yml
version: '3.9'
services:
  app:
    &app
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1
# /docker-compose.yml
version: '3.9'
include:
  - /proxy/docker-compose.yml
  - /webservice/docker-compose.yml

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    restart: 'always'
    << : *proxy
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    restart: 'no'
    extends:
      file: web1/docker-compose.yml
      service: app
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

Diff
@@ /proxy/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
 services:
   proxy:
+    &proxy
     build: ./
     volumes:
       - /certs:/certs:ro
@@ /webservice/docker-compose.yml @@
-version: '2.1'
+version: '3.9'
services:
  app:
+    &app
    build:
      context: ./folder
      args:
        LINUX_VERSION: 20.s
        LINUX_FLAVOR: dash
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1
@@ /docker-compose.yml @@
-version: '2.1'
+version: '3.9'
+include:
+  - /proxy/docker-compose.yml
+  - /webservice/docker-compose.yml

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
-    extends:
-      file: reverse_proxy/docker-compose.yml
-      service: proxy
+    << : *proxy
    restart: 'no'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
-    extends:
-      file: webservice/docker-compose.yml
-      service: app
+    << : *app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

Resulting in the final version, which should be already yaml parsable:
# /docker-compose.yml
version: '3.9'
#include:
#  - /proxy/docker-compose.yml
#  - /webservice/docker-compose.yml
x-include:
  /proxy/docker-compose.yml:
    version: '3.9'
    services:
      proxy:
        &proxy
        build: ./
        volumes:
          - /certs:/certs:ro
  /webservice/docker-compose.yml:
    version: '3.9'
    services:
      app:
        &app
        build:
          context: ./folder
          args:
            LINUX_VERSION: 20.s
            LINUX_FLAVOR: dash
        environment:
          - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
          - bootstrap.memory_lock=true
        ulimits:
          memlock:
            soft: -1
            hard: -1

volumes:
  nginx_file_sockets:
    external: false
    driver: local

services:
  reverse_proxy:
    << : *proxy
    restart: 'always'
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  reverse_proxy_test:
    << : *proxy
    restart: 'no'
    ports:
      - "8080:80"
      - "8443:443"
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web:
    << : *app
    restart: 'always'
    environment:
      ENVIRONMENT: 'production'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx

  web_staging:
    << : *app
    restart: 'no'
    environment:
      ENVIRONMENT: 'staging'
      DB_USER: ${WEB1_DB_USER}
      DB_PASSWORD: ${WEB1_DB_PASS}
    volumes:
      - nginx_file_sockets:/sockets/nginx
@Yajo

This comment has been minimized.

Copy link

commented Aug 16, 2018

AFAIK that's a YAML feature, built into the laguage spec itself, to avoid repeating parts in the same file. When using different files, that's basically impossible.

You should propose that feature to the YAML spec itself.

@blaggacao

This comment has been minimized.

Copy link

commented Aug 19, 2018

This discussion burns down to:

  • How docker-compose -f file.yml is so much better than docker-compose -f file.yml -f file_extension.yml ?
  • Or: wiring at the command level vs wiring at the file level.

Only when working on the command line, the inconvenience becomes notable. We have to acknowledge that for a second. Everything else is scriptable, anyway.

If that's the real argument, then docker-compose up service has better semantics than docker-compose -f service.yml up: define everything needed for local development (aka on the command line) in docker-compose.override.yml.

Given semantics are very clean and well thought through. Adopting service.yml for the command line use probably means lowering UX. There is another argument to it: while it is clear at first sight, what a docker-compose.yml is, a service.yml can be anything, really anything.

Disclaimer: A provocative opinion. 😉 I didn't take into account every possible use case...

@soubhik-c

This comment has been minimized.

Copy link

commented Oct 10, 2018

After this prolonged discussion not sure whether it will ever make it. IMHO, extends was cool and must have been atleast carefully deprecated and then discussed instead of simply dropping it away.

@BretFisher

This comment has been minimized.

Copy link

commented Oct 10, 2018

I think one thing we could do is improve the documentation story about v2 vs. v3. Many assume that v3 replaced v2, but that's not entirely true. Both receive new features that focus on their use cases. This GH issue was started so we could have the discussion about what future features needed to make their way from docker-compose into Swarm, and how to improve docs for using docker-compose, the compose file format, and Swarm stacks together. Extends still works great in the up-to-date v2.4. Hopefully, I can help offer information on what solutions we have today:

v2: For docker-compose cli only. Development workflow focused on a single machine and engine. Also good for CI build/test workflows. This version branch received new features as recent as December 2017 in v17.12

v3: Ideal for Swarm/Kube stacks, with multi-node concepts and maintains support for most docker-compose cli features.

If you're not using Swarm or Docker Enterprise Kubernetes stacks, there is no reason to use v3. Stick with v2.4, and you get all the docker-compose cli features including extends, depends_on, extension fields, and even depends_on with healthchecks (to avoid wait-for-it scripts).

v3 was created to try and merge the features of a single engine docker-compose cli world with a multi-node cluster world. Not all v2 features (like depends_on) make sense in a cluster. Other features (like extend) just haven't made it into v3, likely because before v3 existed, all the code was in docker-compose Python, and for v3.0 to support Swarm, they had to rewrite that in docker cli Go, and now they are writing it again in the engine daemon to eventually make a Swarm stacks API, which doesn't yet exist.

For those new to this issue, also note much of the work that's gone on to solve various configuration, templating, and team workflow concerns since 3.0 release:

@krisrp

This comment has been minimized.

Copy link

commented Oct 16, 2018

The docs at https://docs.docker.com/compose/extends/#extending-services should emphasize in red the fact that the extends keyword is removed in v3, as it's more important than just a note.
I migrated and skimmed the docs for why it was no longer working, then followed several closed issues before ending up here, then went back to the original docs and noticed the wording.

The extends keyword is supported in earlier Compose file formats up to Compose file version 2.1 (see extends in v1 and extends in v2), but is not supported in Compose version 3.x.

Could be rephrased as:

The extends keyword has been removed in Compose version 3.x, but is still supported in earlier Compose file formats up to Compose file version 2.1 (see extends in v1 and extends in v2).

It's a small difference, but one that's easy to overlook when skimming docs.

BretFisher added a commit to BretFisher/docker.github.io that referenced this issue Oct 16, 2018

clear up confusion between compose file versions
Really this type of info could be placed elsewhere and referenced in this note, so maybe suggest where it would live better. See comments moby/moby#31101 (comment) and others for how we could better communicate the "best fit" file versions depending on someones use case. This is a top 3 issue of anyone I meet trying to use compose files with or without swarm. They are all confused thinking 2.x branch is not supported or maintained now that 3.x exists.
@BretFisher

This comment has been minimized.

Copy link

commented Oct 16, 2018

@krisrp PR started ^^^

@krisrp

This comment has been minimized.

Copy link

commented Oct 17, 2018

Thanks @BretFisher

Are there any plans to perhaps rename v2 to "version: docker-cli" and v3 to "version: swarm/kube"?
It'd make more sense to differentiate them like this, considering how v3 supersedes v2 in most other versioning schemes. At present both are maintained and diverging, so unless I'm mistaken it seems like they'll both be around for a while.

@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Oct 17, 2018

@krisrp On the contrary, the reason for incrementing a major version number is to signal the divergence in compatibility.

@krisrp

This comment has been minimized.

Copy link

commented Oct 17, 2018

@cpuguy83 I wasn't implying otherwise. Apologies for not being more clear or explicit.
IIRC Gnome 2 & 3 also had this confusion years ago when independent forks of each were maintained.

I don't want to derail this thread to discuss the semantics of versioning (bad pun), so I'll leave it at that. @BretFisher 's post last week about improving documentation on v2 vs v3 would have helped myself and probably others.

@luckydonald

This comment has been minimized.

Copy link

commented Oct 18, 2018

@shin- @cpuguy83 Looking at this issue over a year later, what is the reasoning for not adding it back in version 3?

I couldn't find much about it, other than "we could do it differently" (but no actual better solution offered)
Is there a technical limitation? Or just a lack of pull request?

After all, my compose 2.1 files are still running fine.

@skorokithakis

This comment has been minimized.

Copy link

commented Jan 22, 2019

Not only this, but the changelog says "this has been removed, see 'how to upgrade' for details". I look at "how to upgrade" for, you know, details on how to upgrade, and what that says is "see 'extending services' for details". I go to "extending services" figuring I'll finally see a way to extend my files, only to see "this has been removed, see the changelog for details".

At this point, this seems like a cruel joke the documentation writer is playing.

@cpuguy83

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2019

Ultimately, the "stack" format is not controlled here and is part of the Docker CLI.

I personally don't know the reason it was excluded from v3... I also don't think I've seen anyone actually try to add it in.
It might be best to bring this up in docker/cli... maybe even just a PR with a high level doc change that acts as if the feature is there so it can be discussed and the implementation can be added once the design is approved.

Basically, if someone wants it, make a PR. I suggest the doc change just to make sure you don't waste a ton of time in case it is rejected... since again I am not sure why it was omitted from v3.

@andrewjaanuu

This comment has been minimized.

Copy link

commented Apr 5, 2019

Same as above. Waiting for this to be solved before using docker-compose again.

@aminancelot

This comment has been minimized.

Copy link

commented Apr 25, 2019

+1 please get this fixed, we have extend based compose files and can't use compose for swarm because of it.

@M0NsTeRRR

This comment has been minimized.

Copy link

commented May 31, 2019

+1 for extends feature

@tabulon

This comment has been minimized.

Copy link

commented Jun 8, 2019

Any news on this?

@daniele-orlando

This comment has been minimized.

Copy link

commented Jun 25, 2019

Still waiting for it

@thomasrutkowski

This comment has been minimized.

Copy link

commented Jul 5, 2019

Same here. Still waiting.

@jaykishan007

This comment has been minimized.

Copy link

commented Aug 5, 2019

Any update?

@SC7639

This comment has been minimized.

Copy link

commented Aug 5, 2019

lieut-data added a commit to cpanato/mattermost-server that referenced this issue Aug 6, 2019

leverage docker-compose extends
This moves the developer `docker-compose.yml` to the root, extending the `build/docker-compose.yml` and overriding the `container_name` to preserve compatibility with the older, non-docker-compose setup.

Note that this required downgrading to docker-compose 2.4's file format (still supported by the newer tooling) due to the long and frustrating converstaion at moby/moby#31101.

cpanato added a commit to mattermost/mattermost-server that referenced this issue Aug 6, 2019

add docker-compose for ci (#11795)
* add docker-compose for ci

* docker-compose logs does not have the option to set the dc file

* leverage docker-compose extends

This moves the developer `docker-compose.yml` to the root, extending the `build/docker-compose.yml` and overriding the `container_name` to preserve compatibility with the older, non-docker-compose setup.

Note that this required downgrading to docker-compose 2.4's file format (still supported by the newer tooling) due to the long and frustrating converstaion at moby/moby#31101.

* remove -f docker-compose-ci.yml references
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.