Hi,
We have three instances of Octopus Server with the following addresses and instance names (for all intents and purposes): https://octopus1.com (Default) , https://octopus2.com (Octopus2) and https://octopus3.com (Octopus3).
NOTE: Our tentacles are all polling and are communicating with the Octopus Server on port 10943 and this issue was experienced for both Windows and Linux deployment targets.
When we create new deployment targets our VMs connect to the default instance completely fine.
However, when creating a new deployment target to report to a non-default instance (in this example Octopus3) the tentacle on the client VM successfully connects to the correct instance using an API key generated in Octopus3, although then the initial health check fails with the following error:
A request was sent to a polling endpoint, but the polling endpoint did not collect the request within the allowed time (00:02:00), so the request timed out.
Server exception:
System.TimeoutException: A request was sent to a polling endpoint, but the polling endpoint did not collect the request within the allowed time (00:02:00), so the request timed out.
Looking in the logs in the client VM we get an error saying that the client can’t connect due to the server presenting a certificate with a different thumbprint to what it was expecting. To be more precise the Octopus server is responding with the certificate of the default Octopus instance and NOT that of Octopus3.
Furthermore, when looking in the tentacle-default.config file on the client VM the thumbprint of the trusted Octopus Server matches that of the (Octopus3) instance which can be viewed at https://octopus3.com/app#/Spaces-1/infrastructure/machines/[machine-id]/settings and vice versa.
Is this behavior expected? And if so how do I go about rectifying it?
EXTRA INFO
The configuration of the Octopus tentacle is done when the VMs are created through Terraform using the Octopus Extension in Azure for Windows VMs and a cloud-init script for Ubuntu Linux VMs.
Octopus Extension Settings (Windows)
settings = <<SETTINGS
{
"OctopusServerUrl": "${var.octopus_url}",
"Environments": ["${var.environment_name}"],
"Roles": ["WS"],
"CommunicationMode": "Poll",
"Port": 10943,
"Tenants": ["${var.tenant_id}"]
}
SETTINGS
protected_settings = <<PROTECTED_SETTINGS
{
"ApiKey": "${var.OCTOPUS_API_KEY}"
}
PROTECTED_SETTINGS
Cloud-Init Commands
runcmd:
- /opt/octopus/tentacle/Tentacle create-instance --config "/etc/octopus/default/tentacle-default.config"
- /opt/octopus/tentacle/Tentacle new-certificate --if-blank
- /opt/octopus/tentacle/Tentacle configure --noListen True --reset-trust --app "/home/Octopus/Applications/"
- echo "Registering the Tentacle $HOSTNAME with server ${server_url} in environment ${environment} with role ${role}"
- /opt/octopus/tentacle/Tentacle register-with --server "${server_url}" --apiKey "${api_key}" --name "$HOSTNAME" --env "${environment}" --role "${role}" --tenant "${tenant}" --comms-style "TentacleActive" --server-comms-port 10943 --force
- /opt/octopus/tentacle/Tentacle service --install --start
- [systemctl, status, Tentacle.service]