Codespace does start with docker-compose & extra container

Forked from the previous thread at the request of @cmbrose

I’ve narrowed it down to Docker at the moment, if I add any other container it fails to resume.

It all works locally, and if I stick it on Kubernetes. My first assumption is I’m doing something wrong, but my files are based on the example ones available. I’m going to go back through the documentation and re-read everything to see if I’ve configured it incorrectly.

Can provide my devcontainer.json & dockerfile if necessary.

Will email the docker-compose.yml and .devcontainer files as requested.

1 Like

@cmbrose Files sent via email, let me know if you don’t get them!

Thanks @ITHedgeHog - I got it and repro’ed first try. I’ll do some digging into what the issue is, this is really helpful :slight_smile:

1 Like

@ITHedgeHog thanks again for sending over the devcontainer and helping narrow down to that on your own! With that repro we found that there is a bug in our resume workflow where we are don’t properly handle docker-compose scenarios (which is different from the create workflow where we do handle it).

Instead of going through docker-compose on resumes we just start the containers individually and end up starting our codespaces container before the mongodb container. Since the mongodb container is a dependency of the codespaces container (from the docker-compose.yml), that causes the codespaces container to die and the codespace never comes online.

I tested that you can remove the network_mode setting in your docker-compose.yml and that will at least allow resumes to succeed again. Hopefully that doesn’t completely break your usage scenario, but we understand that it may. I’m going to file a bug to have proper docker-compose support for resumes right now.

Thank you for the update @cmbrose I’ll test it without the network mode, however, that is there as the documentation says it’s required for port forwarding to work - so I’m unsure how well it will work.

@ITHedgeHog, can you try setting the network mode to “host” for all containers as a workaround?

I’ve created a new codespace with that set on all of the containers.

That appears to work as intended, thanks! I’ll do some proper testing tonight but I can connect to SQL Server running in Codespaces from my own PC.

1 Like

Glad to hear the host networking is working so far! We’ll be working on getting proper support for the more complex network topologies with container-specific networks, which enough enable your original configuration to work well in Codespaces.

We’ve rolled out a fix for docker compose scenarios that no longer forces host networking mode for the main container for new Codespaces.

We’re still working on the fix for resuming Codespaces that use custom networks to ensure the containers are restarted in the correct order, so if you depend on custom networking across the containers, keeping host networking mode enabled enabled for the containers is a good workaround until that fix is ready.

1 Like

Thanks very much for the update, your work is very much appreciated! :heart: :smile:

@ITHedgeHog did you see a similar behaviour like mine and did you come up with a solution?

1 Like

Hi @jaulz the change to the networking worked for me, I was planning to revisit this in the next few months to see if any updates have changed the networking.