Release notes 1.29 - initContainer information missing

[dennzo]

Problem description

In the version 1.29 the support for initContainers have been added through the following PR.
docker/compose#8122

But there is no reference to this feature in the release notes. Also there is no documentation provided on how to use this.
https://github.com/docker/docker.github.io/blob/master/compose/release-notes.md#1290

Problem location

I saw a problem on the following URLs:

• https://docs.docker.com/compose/release-notes/
• https://docs.docker.com/compose/compose-file/compose-file-v3/

Project version(s) affected

docker-compose - 1.29

Suggestions for a fix

Add the information to the release notes and also add some context on how to use it to the main documentation of docker-compose.

Thanks very much! :)

[carehart]

Seeking clarification on this also. The listed release notes refers to "Add a depends_on condition to wait for successful service completion". Other resources discussing the addition of init containers (like the PR and discussions for it) don't indicate that.

Is this feature enabled by the init: true (for services), indicated in the compose file doc, indicating that was added in 3.7?

To be clear, I'm not an active participant in things. I just heard the news (of init containers in Compose). Apologies if I have something crazy wrong here.

[aritas1]

depends_on has a condition key. the following values are available according to the compose tests.
service_started service_healthy service_completed_successfully

you can try this with my example.

version: '3.4'
services:
  my_init:
    image: alpine
    command: /bin/sh -c "exit 1"
  my_follower:
    depends_on:
      my_init:
        condition: service_completed_successfully
    image: alpine
    command: /bin/sh -c "echo init finished"

if the depends_on container exits none zero, you will see an error:

Creating my_init_1 ... done

ERROR: for my_follower  Container "cd06a63129c2" exited with code 1.
ERROR: Encountered errors while bringing up the project.

[carehart]

I appreciate that as a seeming clue. Still looking forward to more official confirmation/documentation (for everyone's sake, I mean). I'm on mobile as I see this so am challenged to dig around based on this info, but I wanted to reply before losing track of my notification of your reply. Perhaps someone else may have additional thoughts.

[shoce]

Is this feature enabled by the init: true (for services), indicated in the compose file doc, indicating that was added in 3.7?

No init: true is to "Run an init inside the container that forwards signals and reaps processes." according to the docs. So, absolutely different feature.

[shoce]

depends_on has a condition key. the following values are available according to the compose tests.
service_started service_healthy service_completed_successfully

Yes, i confirm that works. Below config starts testback only after testback_prepare finishes successfully.

version: '3.7'
services:
    testback_prepare:
        container_name: testback_prepare
        image: alpine
        command: /bin/sh -c 'echo come on; sleep 3'
    testback:
        container_name: testback
        image: alpine
        command: /bin/sh -c 'echo yohoho; sleep 1000'
        depends_on:
            testback_prepare:
                condition: service_completed_successfully

docker-compose --version
docker-compose version 1.29.1, build c34c88b2

[carehart]

OK, it seems to be specifically that the depends_on value of service_completed_successfully is what's new in docker-compose 1.29.0, which is what gives the equivalent of initcontainer functionality in compose: that a given container/service must not only start but complete (and complete successfully) before the dependent container/service will proceed to start.

Back to the initial discussion in this thread, it was just not as clear in the resources I or we (?) were looking at. Thanks.

[bluebrown]

@jflambert, those are also self-explanatory.

[carehart]

Sorry, but if all this was so "self-explanatory", why would we have raised the concern in the first place?

[bluebrown]

@carehart, because it's not clear that it even exists.

[carehart]

@bluebrown, wait, what? To be clear I'm with you on that. But you had just responded differently to @jflambert (whose comment from 2 hrs ago seems gone now, oddly).

To recap, it seems that jf and @dennzo (who started the issue) and I are of the opinion that more documented clarification on these things is needed. But your reply to jf (in sharing what they had) was that it "also" was "self-explanatory". Thus my last question to you. :-) Just trying to help.

[bluebrown]

@carehart I was just going off the fact that jf claimed completed_succesfully was self-explanatory. So My comment was like, if this is self-explanatory, then the other 2 states are in the same way.

In any case, I think we don't add anything productive here. At least I for my part have to admit that I was trolling a bit. My apologies.

[shantanoo-desai]

In case anyone stumbles upon this issue, I have some example repositories that can help users with init containers in compose

• Hashicorp Vault Config Init with Docker Compose Trial
• Proof of Concept of Initializing InfluxDBv2 with Docker Compose Init Containers
• Role-Based Access Control in Mosquitto MQTT with Compose Init Containers

These are by no means full-proof examples but might be helpful to someone working with them

[docker-robott]

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 14 days. This helps our maintainers focus on the active issues.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

[dennzo]

/remove-lifecycle stale
/lifecycle frozen