We saw in a previous post that it’s important to ensure that the Selenium container is running and accepting requests before the crawler actually gets started. This is because the crawler depends on Selenium being available. We can use ECS task dependencies to assert this dependency.
Since the crawler container can only start doing it’s thing once Selenium is up and running it would make sense to create an explicit dependency between the containers. So we’ll set the ordering for the crawler container so that it depends on the Selenium container being in
- Click on Task Definitions (menu on left).
- Follow the link to the task.
- Follow the link to the most recent (there should only be one!) revision and press .
- Follow the link to the definition of the crawler container.
- Scroll down to the Startup Dependency Ordering section. Choose the Selenium container from the Container name dropdown and
STARTfrom the Condition list.
- Press the .
- Press the to create a new revision.
You can now run the task again, but using the newly created revision.
What happens? Well, somewhat anticlimactically, this doesn’t seem to really make any difference. The crawler still starts trying to connect to Selenium before it’s ready for connections. Why? Because ECS is waiting for the Selenium container to be in the
START state before kicking off the crawler. However, the
START state simply indicates that the container has been launched. It doesn’t imply anything about the running state of the container.
Let’s review the conditions available for startup dependency ordering:
HEALTHY is what we’re looking for?
In the next post we’ll look at setting up container health checks.