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

On more recent Docker versions, hashes added to container names, app fails to start #1316

Closed
andileco opened this Issue Nov 28, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@andileco
Copy link

andileco commented Nov 28, 2018

This is for future development: I know that only the version of Docker that comes with Lando is supported

When using a more recent version of Docker (in my case, Version 2.0.0.0-mac77 (28700) Channel: Edge) and building a site for the first time in Lando, hashes get added to some containers, and then the app fails to start. Here's an example of the error:

Starting landoproxyhyperion5000gandalfedition_proxy_1 ... done Creating network "myapp_default" with the default driver Creating volume "myapp_data" with default driver Creating volume "myapp_appserver" with default driver Creating volume "myapp_data_database" with default driver Creating volume "myapp_data_index" with default driver Creating myapp_index_1_6a1c57b5617c ... done Creating myapp_appserver_1_ae454b8b1420 ... done error: Looks like one of your build steps failed with Error: (HTTP code 404) no such container - No such container: myapp_appserver_1 warn: This **MAY** prevent your app from working warn: Check for errors above, fix them, and try again Starting myapp_index_1_64cf297fdc63 ... done Creating myapp_cache_1_bb47a8b2ff77 ... done Starting myapp_appserver_1_23c9915bfe49 ... done Creating myapp_database_1_fbd1b8c60c23 ... done Creating myapp_nginx_1_8abd3c0d8fe6 ... done Creating myapp_edge_1_c8ef0eb4f148 ... done Creating myapp_edge_ssl_1_708a46f2df6c ... done Waiting until edge_ssl service is ready... Waiting until edge service is ready... Waiting until database service is ready... Waiting until nginx service is ready... Waiting until cache service is ready... Waiting until appserver service is ready... Waiting until index service is ready... Waiting until database service is ready... Waiting until database service is ready... ... Builds, (re)creates, starts, and attaches to containers for a service. Unless they are already running, this command also starts any linked services. The `docker-compose up` command aggregates the output of each container. When the command exits, all containers are stopped. Running `docker-compose up -d` starts the containers in the background and leaves them running. If there are existing containers for a service, and the service's configuration or image was changed after the container's creation, `docker-compose up` picks up the changes by stopping and recreating the containers (preserving mounted volumes). To prevent Compose from picking up changes, use the `--no-recreate` flag. If you want to force Compose to stop and recreate all containers, use the `--force-recreate` flag. Usage: up [options] [--scale SERVICE=NUM...] [SERVICE...] Options: -d, --detach Detached mode: Run containers in the background, print new container names. Incompatible with --abort-on-container-exit. --no-color Produce monochrome output. --quiet-pull Pull without printing progress information --no-deps Don't start linked services. --force-recreate Recreate containers even if their configuration and image haven't changed. --always-recreate-deps Recreate dependent containers. Incompatible with --no-recreate. --no-recreate If containers already exist, don't recreate them. Incompatible with --force-recreate and -V. --no-build Don't build an image, even if it's missing. --no-start Don't start the services after creating them. --build Build images before starting containers. --abort-on-container-exit Stops all containers if any container was stopped. Incompatible with -d. -t, --timeout TIMEOUT Use this timeout in seconds for container shutdown when attached or when containers are already running. (default: 10) -V, --renew-anon-volumes Recreate anonymous volumes instead of retrieving data from the previous containers. --remove-orphans Remove containers for services not defined in the Compose file. --exit-code-from SERVICE Return the exit code of the selected service container. Implies --abort-on-container-exit. --scale SERVICE=NUM Scale SERVICE to NUM instances. Overrides the `scale` setting in the Compose file if present. ... error: Failed after 5 retries with backoff 500 and error Error at module.exports.sh.Promise.try.then (/snapshot/lando/build/cli/lib/shell.js:0:0) at runCallback (timers.js:696:18) at tryOnImmediate (timers.js:667:5) at processImmediate (timers.js:649:5) From previous event: at Shell.sh (/snapshot/lando/build/cli/lib/shell.js:0:0) at dc (/snapshot/lando/build/cli/plugins/lando-engine/engine.js:0:0) at compose (/snapshot/lando/build/cli/plugins/lando-engine/engine.js:0:0) at exports.start.datum (/snapshot/lando/build/cli/plugins/lando-engine/lib/router.js:0:0) at Promise.each.Promise.retry (/snapshot/lando/build/cli/plugins/lando-engine/lib/router.js:0:0) at Promise.resolve.then.Promise.try (/snapshot/lando/build/cli/lib/promise.js:0:0) at rec (/snapshot/lando/build/cli/lib/promise.js:0:0) at Promise.resolve.then.Promise.try.fn.catch.Promise.delay.then (/snapshot/lando/build/cli/lib/promise.js:0:0) at ontimeout (timers.js:427:11) at tryOnTimeout (timers.js:289:5)

I found the following issue on ServerFault, and it seems to explain what's happening with the hashes being added:
https://serverfault.com/questions/938050/how-to-prevent-docker-compose-appending-hashes-to-created-container-names

@ccharlton

This comment has been minimized.

Copy link
Contributor

ccharlton commented Nov 28, 2018

Roll back to previous Docker version. That fixed it for many of us.

@andileco

This comment has been minimized.

Copy link
Author

andileco commented Nov 28, 2018

Thanks for posting. I mostly just wanted to put this on the team's radar for future development.

@pirog pirog added this to the RC1 milestone Nov 28, 2018

@pirog pirog self-assigned this Nov 28, 2018

@calin-marian

This comment has been minimized.

Copy link

calin-marian commented Dec 3, 2018

So, docker compose reverted the change in the latest release (https://github.com/docker/compose/releases/tag/1.23.2). From the release notes:

Reverted a 1.23.0 change that appended random strings to container names created by docker-compose up, causing addressability issues.
Note: Containers created by docker-compose run will continue to use randomly generated names to avoid collisions during parallel runs.

However, I think that at some point this change will find it's way back in, so maybe it's something to keep an eye on and handle at an apropiate time. See this comment: docker/compose#6316 (comment) , more speciffically this part:

Service discovery shouldn't be an issue as it should be handled using service names (rather than container names) and network aliases, which are static on their associated network. You may read the networking docs for more details on that specifically

I don't know the scope of changes that's need to switch lando from container names to service names and network aliases, or even if it's possible, so I am just puting this information here, and leting someone else make this decision.

@ccharlton

This comment has been minimized.

Copy link
Contributor

ccharlton commented Dec 28, 2018

I think that at some point this change will find it's way back in...

That is my feeling too.

@pirog

This comment has been minimized.

Copy link
Member

pirog commented Jan 12, 2019

Newest docker and docker-compose will ship with RC2. We've spun up an internal ticket to track the possible re-introduction of the breaking change in future docker releases

@pirog pirog closed this Jan 12, 2019

pirog added a commit that referenced this issue Jan 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment