I am using AWS ECS Faragate to generate and deploy docker containers into tasks.
I’m using the docker image FROM php:7.4-fpm-alpine for my app container.
I have been working on a workaround for cron type solution to the app container. This solution runs a php yii2 command and then sleeps for 1m, in a while loop.
The app container is now resulting in the following error message, which is not resulting in the task definition to persist, and to constantly restart, here is the error I am receiving from my app container:
[error] 22#22: *135 connect() failed (111: Connection refused) while connecting to upstream, client: 10.0.19.236, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "10.0.2.163"
As a result, to try and get around this error. I updated my fastcgi_pass to app:9000 but got the following error from the app container:
[emerg] 7#7: host not found in upstream "app" in /etc/nginx/conf.d/nginx.conf:35
I have attached the code changes I made during the process.
Can anyone suggest what I’m doing wrong?
I was reading that maybe I need to create the bash script on a different thread to the main one?
Thanks in advance.
Your diff also changes nginx.conf from pointing to
127.0.0.1:9000
toapp:9000
– Wondering where the short-form hostname “app” is defined. Are you usingdocker-compose
to launch the containers?@amphetamachine I thought that to be an immediate solution but I was wrong. I’ve reverted that back to use 127.0.0.1:9000. I am using docker-compose for local development yes, but for prod it’s doing a docker build.
My point is that
docker-compose
lets you give private short-form hostnames to “services” in its YAML files. It’s a shortcut for adding a bunch of--add-host "myservicehostname:127.0.0.1"
arguments when usingdocker run
. Unless you specified them in prod, the short-form address are not going to be resolvable inside your containers and you must use IP addresses.@amphetamachine yes, I agree with you there. That’s why I reverted the code to point at 127.0.0.1. Do you agree that this should then work? That fastcgi_pass should resolve? The issue here is why does the newly added “cron” mechanism code mess the fastcgi / nginx configuration/connectivity up.
So, can you reproduce this locally? How does that relate to the amazon-ecs tag then? And is the title you chose representative then? As is common, you should extract a minimal reproducible example first, even if just to include it in a question here. Please use text for that, too, so people can conveniently cut’n’paste it into a file or two to reproduce the problem.
Show 1 more comment