I have a Tentacle that is running in Docker. I run it with the following command:
docker run -d --restart always --env Space=“My Target Space” --env ServerPort=“10943” --env TargetWorkerPool=“My Target Worker Pool” --env ACCEPT_EULA=“Y” --env ServerUrl=“http://my-octopus-server.mydomain.net/” --env ServerApiKey=“API-ABCD1234_My_API_Key_Here” my-container-repository.mydomain.net/tooling/library/octo.octopus-tentacle
When I run this, it works perfectly. The Worker starts up and is seen in Octopus Deploy. I can upgrade Calamari, and run runbooks on it.
If you look, you will note that the command included
--restart always. This causes the container to restart on a reboot.
And when I restart the Linux Server that this is running on, the container does indeed attempt to restart. But it goes into a crash loop of staring up, and then crashing and trying again.
Each time, it only logs the following:
Octopus Tentacle is already configured.
I am guessing that when it re-starts it tries to create the tentacle in Octopus and, failing that, it just exits.
Is there something I can do to get it to just reconnect to the existing tentacle (instead of trying to make a new one when the container restarts).
Here is my guess of what is happening. When you start up the container it runs:
CMD /scripts/configure-tentacle.sh && /scripts/run-tentacle.sh
This is from line 54 of the Dockerfile.
The first script there (
configure-tentacle.sh) checks if an install is needed. Since there is not anything then it just outputs that the tentacle is already installed and calls
My best guess is that this return call is somehow returning false. (I am not sure how.)
I come to this conclusion because
run-tentacle.sh is not called. (It has echo statements that don’t happen.) The two scripts are joined by an
&& rather than a
&& means that the second one will not run unless the previous one is successful.
Now, assuming that the return statement is valid in this scenario (which I cannot figure how it is, since it is not in a function or called “sourced”), then it should return true (to my understanding), since the previous command was an
But the evidence is quite strong that the second script is not called. (Because the container just exits, it does not have any errors that I can see.)
I would like to suggest that this is a bug.