Execute commands after wait in container

[benjamindonze]

Hello,

It would be nice to have an equivalent maven goal to the docker exec command. I would need in some case to be able to run a docker exec command previously started containers.

Or does it already exist?

[rhuss]

No, it doesn't exist yet. Do you have a use case for me where you would need this (and can't easily use docker exec itself ?)

[benjamindonze]

Well I have a docker container that I want to start at the beginnig of my integration test then run a docker exec to start some extra stuff in the docker containers then run my tests and finally stop and delete everything.

[rhuss]

I understand.

I think this will be a useful addition, though it might take a bit until its get implemented (however, we are happily integrating pull requests ;-)

[jgangemi]

in the interim, couldn't you just build the container w/ an startup script that starts the extra services?

[rhuss]

you could also use a different build configuration in a dedicated Maven profile which you use only for the integration tests.

Timing could also be an issue for when to execute the docker:exec task (would need to wait for the startup of the container, too)

[DennisDenuto]

I don't mind giving this a go. Regarding the timing, I am thinking 3 'hooks' into the maven docker lifecycle. With an option to run a command based on a time interval or log message.

<exec>
   <preWait>command goes here</preWait>
   <postWait>command goes here</postWait>
   <preStop>command goes here</preStop>
   <wait>
      <time>10 seconds</time>
      <msg>log message to match against</msg>
      <cmd>command goes here</cmd>
   </wait>
</exec> 

However I think initially I will work on just getting 'postWait' tag working. (as it seems to fit the use case above.).

What do you think?

[jgangemi]

i think it looks ok. you can probably leverage much, if not all, of the existing wait code for this.

i also advise working off the integration branch of the project instead of master.

[DennisDenuto]

cool thanks

[rhuss]

I wonder whether we shouldn't include that into the docker:start goal and the extend the wait config accordingly section.

The benefits would be:

• No additional goal (yes, that's a benefit ;-)
• No duplication in <wait> configurations. Also, the exec goal would only be callled after or before start and hence might later than necessary.

What I can think about would be somethings like extension for the wait section in <run> configuration:

<wait>
  <http>
    <url>http://localhost:${host.port}</url>
    <method>GET</method>
    <status>200..399</status>
  </http>
  <time>10000</time>
  <shutdown>500</shutdown>
  <exec>
    <postStart>/opt/init_db.sh<postStart>
    <preStop>/opt/notify_end.sh</preStop>
  </exec>
</wait>

Wouldn't this be enough for this use case ?

[benjamindonze]

Sure I think it would totally fit the use case. Not sure I can implement it myself but I'll take a look

[rhuss]

No problem, we can take care about this, too.

Shouldn't be that hard but is also not super trivial (because a new backend call to the Docker API must be introduced).

[RiccardoManzan]

This way, using one command works. What if i wanted to execute multiple commands?

<exec>
 <postStart>commandOne &amp;&amp; commandTwo</postStart>
</exec>

does not work as && and commandTwo are considered as arguments

I also tried to put multiple <postStart>, but only second one gets executed

[rhuss]

What's about putting those commands in a script and call that ?

Alternatively, I suggest to try sh -c "commandOn && commandTwo"

[bergerst]

Replying in an old thread but the suggested approach with sh -c doesn't work for something like loops.

It turns something like bash -c "while [ ! -d /app/probes/ready ]; do sleep 4s; done" into

Command: bash Args:

• -c
• "while
• [
• !
• -d
• /app/probes/ready
• ...
• done"

Which fails with an error about the second " missing. Doesn't work with single quotes, either.