Provide support for Job containers

[tomkerkhove]

Would be great if we could use "job" containers with Docker Compose before other services start.

These are containers that have the sole role of starting up, do some work and die. An example of them are containers to prepare the database (which is run in another container) and stop.

Here is an example of how Kong uses them.

The issue is that Docker Compose depends_on does not wait for the dependant container to start until the depending container has finished.

The recommendation is to use the following approach:

docker-compose build
echo "Running tests inside docker container"
docker-compose up -d pubsub
docker-compose up -d mongo
docker-compose up -d botms
docker-compose up -d events
docker-compose up -d identity
docker-compose up -d importer
docker-compose run status
docker-compose run testing

example

However, we do not control this with the Docker tools for Visual Studio and would be great to have that support or documentation how to work around it.

Some alternatives also package an external tool to containers to wait but this should not be required given that changes the docker image that is being shipped

[bwateratmsft]

Hey @tomkerkhove,

It's possible we can solve your problem with MSBuild targets in the dcproj. Can you share the run command you need to have happen before launch, redacting as needed?

[tomkerkhove]

Hi Brandon,

I think the above is a good example, would that work for you?

[bwateratmsft]

@tomkerkhove I was able to make it run a custom command with this target in the .dcproj:

<Target Name="RunDockerPreLaunchCommand" BeforeTargets="DockerPrepareForLaunch">
    <Exec ConsoleToMsBuild="true" IgnoreExitCode="false"
          Command="docker run -e &quot;MyVariable=MyValue&quot; hello-world" />
</Target>

If your needed image name / service name to run is fixed, it's quite easy to add here, otherwise it may need some more refined MSBuild properties in the command. In the above example, ConsoleToMsBuild pipes the standard error/standard output to the Build Output window, and IgnoreExitCode=false makes the build fail if the command fails (which is the default behavior but I wanted to be explicit about it).

For reference, here's what my .dcproj looks like:

[bwateratmsft]

One additional thought I had. Depending on your implementation, our container warmup may produce a non-usable container, because warmup would not execute this MSBuild target. If needed, you can disable this container warmup with the following option:

[tomkerkhove]

Thanks, I'll give it a go soon!