Skip to content
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

docker-compose vs docker stack #22

Open
EasternPA opened this issue Jul 3, 2019 · 1 comment
Open

docker-compose vs docker stack #22

EasternPA opened this issue Jul 3, 2019 · 1 comment

Comments

@EasternPA
Copy link
Contributor

EasternPA commented Jul 3, 2019

Raspberry Pi 2B / 1GB RAM / 4GB disk

My FA container has been dying after several hours with an error code of 137. That's pointing to an out of memory condition. But it restarts fine when I start it by hand. So I wanted to know why the docker-compose was not restarting the image.

It seems you are using the docker stack version of restart_policy in the yml but the docker stack restart policy requires "any" not "always". So I switched always to any. Then the startup failed due to no compatible nodes found. There's an issue with Raspberry Pis reporting different platforms between armhf, armv7, arm, etc. So to get it to try to start, I now run

docker stack up -c docker-compose.yml adbs --resolve-image=never

Then I run "watch docker stack ps adsb" to keep an eye on the stack. The containers reach a "preparing" state but never reach "running". I'm trying to figure out why. (Update: they eventually started after 15-20 minutes)

Also, in your dump1090 config, you have a constraints block that limits dump1090 to only run on a host named "shed". I'm guessing you run your dump1090 literally in a shed outside and that's why you only want to run it there. That doesn't work for the rest of us! I deleted the constraint block and dump1090 is now willing to start on my Pi.

Right now, I can get dump1090, fa, and fr24 to reach a preparing state in docker stack. The images show up in "docker images ls" but nothing shows up in "docker ps -as". I'll keep working on it. For this new issue, though, the restart_policy needs to be "any" not "always" to be compatible with docker stack. "Always" is for use with docker-container but the rest of the restart_policy block is not compatible with docker-container as written. Hence my containers are dying with error 137 and not restarting.

Update: Again, they eventually started after 15-20 minutes. The dump1090 container kept restarting every 2-5 minutes, so I added a restart policy line compatible with docker-compose up and relaunched it that way. FA, FR24, and dump1090 are all running under docker-compose up but none have died yet, so I don't know if the corrected restart parameter is working.

@EasternPA
Copy link
Contributor Author

Update: I've added a line

restart: on-error

to the docker-compose.yml so that the automatic restart option is respected regardless of the launch method used -- docker-compose up or docker stack up

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant