Wait for multiple services about wait-for-it HOT 13 CLOSED

Yeah, I did that but that approach is potentially misleading.

For example:

./wait-for-it.sh service-a:1234 -- ./wait-for-it.sh service-b:1234 -- docker-entrypoint.sh

Logically, is service-b dependent on service-a? In my case it isn't (so they shouldn't be chained). In my view, it would be clearer to have:

./wait-for-it.sh service-a:1234 service-b:1234 -- docker-entrypoint.sh

Structurally, there should be two options:

container -> {service-a, service-b} // set denotes mutually-exclusive dependencies

container -> [service-a, service-b] // list denotes dependency order

A chain provides a list mechanism and multiple host:port arguments provides a set mechanism.

from wait-for-it.

@andrewshawcare FWIW I implemented this on https://github.com/jlordiales/wait-for-it/blob/master/wait-for-it.sh (for my use case at least). You can specify multiple host:port pairs and the whole thing will fail as soon as the first host times out

from wait-for-it.

I feel like this is better solved by either a top level script that orchestrates the logic of such a situation or chaining multiple wait-for-it commands together.

from wait-for-it.

Didn't see this issue, also implemented this: Forever-Young@f9aa0c1

from wait-for-it.

There is a python version of wait-for-it that supports waiting for multiple services. It is blocking and will wait for the services to be available in sequential order.

e.g.

Assuming both python3 and wait-for-it are installed.

$ wait-for-it \
--service www.google.com:80 \
--service www.bing.com:80 \
--service www.duckduckgo.com:80 \
-- echo "google, bing, and duckduckgo are up (in that order)"

Here are the docs!

from wait-for-it.

There is also a shell script called docker-compose-wait which allows this required behaviour:

version: "3"

services:
  mongo:
    image: mongo:3.4
    hostname: mongo
    ports:
      - "27017:27017"

  postgres:
    image: "postgres:9.4"
    hostname: postgres
    ports:
      - "5432:5432"

  mysql:
    image: "mysql:5.7"
    hostname: mysql
    ports:
      - "3306:3306"

  mySuperApp:
    image: "mySuperApp:latest"
    hostname: mySuperApp
    environment:
      WAIT_HOSTS: postgres:5432, mysql:3306, mongo:27017

from wait-for-it.

A high-level script is your best option to solving this particular use case, as it allows you the flexibility you need in testing and interpreting the various states that arise in your specific scenario. wait-for-it is intentionally designed to keep-it-simple, leaving the use-case you describe as an exercise for the reader. Feel free to fork and tailor to your needs.

from wait-for-it.

@vishnubob did you get to implement your use case? I was looking to do exactly the same

from wait-for-it.

@jlordiales: i think you meant to ask @andrewshawcare, since he originally posted the issue.

from wait-for-it.

Yes @vishnubob, sorry it was late :)

from wait-for-it.

Could this issue be closed as "won't fix" so it is clear that this high-level functionality shouldn't be integrated in this project?
As vishnubob already mentioned it makes totally sense to keep this script as simple as possible and to not patch this script for this reason.

from wait-for-it.

I guess it's enough to have some receipts just in the issue comments.

from wait-for-it.

There is also a shell script called docker-compose-wait which allows this required behaviour:

version: "3"

services:
  mongo:
    image: mongo:3.4
    hostname: mongo
    ports:
      - "27017:27017"

  postgres:
    image: "postgres:9.4"
    hostname: postgres
    ports:
      - "5432:5432"

  mysql:
    image: "mysql:5.7"
    hostname: mysql
    ports:
      - "3306:3306"

  mySuperApp:
    image: "mySuperApp:latest"
    hostname: mySuperApp
    environment:
      WAIT_HOSTS: postgres:5432, mysql:3306, mongo:27017

Thanks for this tip, much better imo and not dependant on bash present in the image

from wait-for-it.