We have been using Bamboo and now we are trying to integrate Octopus with Bamboo.
So this is the process which I followed.
- Installed the Octopus server and created package and pushed it. Followed this link .
- Created an environment in Octopus like Development,QA etc.
- Installed the Octopus tentacle in one of the Azure Virtual Machines. Followed this link.
- Added Azure VM Extension following this link. In this link , it is mentioned that as soon as we add extension in Azure portal, after few minutes, it will be visible Octopus Deploy server.
“After a few minutes, the machine should appear in the environments tab of your Octopus Deploy Server”.
And as mentioned, it is visible in environments tab, but it is saying unavailable like shown in the image.
I have also attached the logs which was generated while attempting a connection with Azure VM, if it helps.
log.txt (6.0 KB)
So can anyone help me in solving this problem.
Your quick response is highly appreciated.
Thanks.
Hi crazycoder,
Thanks for getting in touch. Sorry to hear you’re having trouble with the connectivity. Could I just check where the Octopus server itself is running? I.e. is it hosted on a VM in Azure also or is it an OnPremise instance?
Given the error says the connection request is timing out, it could be something like some network infrastructure causing an issue with the Octopus server’s outbound connection attempt to the tentacle. This often happens if there’s a proxy server in the middle challenging for credentials, for example. It’s possible that something like a firewall is blocking the request too, but I’d usually expect that to be a fairly quick and explicit failure, rather than a timeout.
From what you’ve outlined the installation of the Tentacle was able to locate the Octopus server and make an inbound request during the setup, given that the tentacle appears in the environment page.
Regards
Shannon
It is a common server for the entire company. So it might be a Windows server and not Azure VM.
Just to double check something, that log is from the tentacle VM, yeah? So the error is the Tentacle trying to connect to your Octopus server, if that’s the case. In which case, the Octopus server has a public IP and DNS listing?
The extension was originally made to go with the Octopus Deploy server template in Azure, which will create you a trial server instance. The 2 have access to each other, so you don’t usually run into trouble.
If you used the default setup for the Tentacle, based on the doc link you sent earlier, did you set it up as a Polling Tentacle? For a typical server OnPrem scenario you’d probably want it setup as a Listening Tentacle, then the Octopus server can reach out to it rather than a Polling Tentacle having to come in to your network.
No, the log which I sent is from Octopus web portal. So I’m assumung it is of Octopus server and not of tentacle. It means server is trying to connect to tentacle and not able to connect?
Also, I have set up a Licensing Tentacle.
Ok, thanks for the additional information. So the scenario does sound like what I had originally assumed, but good to be sure.
So we back to the most likely thing blocking the connection is network infrastructure between Octopus and the Tentacle VM. When the Tentacle installs in the VM it would have configured the inbound rule in the firewall to allow it’s port through. It’s not explicitly listed in the documentation, but if you have a listening tentacle it is also assumed that the same port (10933) has been opened in the Azure network setup for the VM, would you be able to confirm whether the Azure configuration has an inbound rule to allow that port?
Regards
Shannon
Yes, I have logged into the Azure portal, selected the VM-> Networking -> Added a Inblound Port Rule as well. Please refer to the screenshot.
I also have another doubt. The Internal and Public IP address of the VM where the tentacle is installed is completely different from the IP address which the VM extension has picked up for deployment target.
What I meant is , suppose the IP address of azure VM is : 10.9.8.7 (IP only for example purpose and not real). We use this IP to log into the VM or use it anywhere else.
But when I added Octopus deploy tentacle extension , automatically a deployment target is added right? In this deployment target, the Tentacle URL is completely different something like 52.6.102.45 , which is no where related the actual IP address.
Actual Tentacle URL : https://52.6.102.45:10933/
Expected URL : https://10.9.8.7:10933/ (my expectation)
Do you think , this could be the problem , or is this behavior normal?
And also, when it got automatically added, that means, server and tentacle are connected somehow. Then why is it still saying Unavailable?
These may be very basic questions for you, but I need to know answers for these to understand what is going on.
Awaiting your response.
Thanks,
I went through and did a test setup of this again yesterday from scratch. One thing I noticed was during the install the port number defaults to 10943, which is the default for Polling Tentacles. It doesn’t change to 10933 automatically when you switch to select that you want a Listening Tentacle. Could you just confirm what the value says in the target in Octopus? It would have passed the actual value you used in the setup through to Octopus.
Depending on how the networking is configured, this could be normal. The tentacle could quite possible have it’s own IP locally but a separate public IP that you would use to access the machine from the internet. There’s an option during the install of the Tentacle that defaults to PublicIP for which value to pass to Octopus, do you remember if you changed that from the default?
To further explain what happens during the setup, the extension installs the Tentacle in the VM. It then makes an API call to Octopus, which would be via the public name/IP and port that you specified in the extension options. That API call contains the information about the Tentacle, include port number and the public IP address that was returned from a call to https://api.ipify.org.
For a listening Tentacle, during a health check the Octopus server will connect to the Tentacle using the address and port number provided in the original API call. This is how the target appears in Octopus but is showing as Unavailable in your scenario, the Octopus server can’t reach out to it successfully.
When I was testing yesterday, I got the exact error you are seeing until I opened the port in the Inbound Port Rules for the VM in Azure networking. Your screenshot shows the same config I used and as soon as I did that the server could connect and the health check worked. So to me the issue is still pointing to something on the network blocking the Tentacle’s IP and/or port.
I was using a test instance in AWS for my Octopus server, so there was nothing else in the way. Is it possible there’s a firewall or something else at your network perimeter that could be blocking that port?
Hi,
One thing I noticed was during the install the port number defaults to 10943, which is the default for Polling Tentacles. It doesn’t change to 10933 automatically when you switch to select that you want a Listening Tentacle. Could you just confirm what the value says in the target in Octopus? — I have changed the port manually to 10933 after selecting Listening Tentacle.
There’s an option during the install of the Tentacle that defaults to PublicIP for which value to pass to Octopus, do you remember if you changed that from the default? ------ I have not changed the default value. It is PublicIP itself.
I got the exact error you are seeing until I opened the port in the Inbound Port Rules for the VM in Azure networking ---- I also think that it might be a firewall issue. Can you tell me how did you open the port. Did you open it from Azure portal? If yes, can you send me the steps please.
Thanks
In the Azure portal, under VM-> Networking -> Added a Inblound Port Rule. Exactly as you’d done and illustrated in the screenshot from earlier.
If you have an OnPrem Octopus server, I suspect there’s another device (e.g. firewall) on your network perimeter that is blocking the connection.
Do you have anything else running on that Tentacle? I’m just thinking that you should be able to configure the listening Tentacle on port 443 if nothing else is using that. Any firewalls in between would likely not block that.
I have configured the Tentacle on port 10933 and not 443? Do you want me to change that?
It is probably worth trying, if that port isn’t being used it is less likely to be blocked by other devices on the network. If changing it to that works, it will prove that there is another device somewhere on your network that is causing port 10933 to be blocked.
Hi, I have opened both the ports , but still it saying “Unavailable”. Can this be a problem of routing of VNET in azure. Let me know your thoughts.
Thanks
It’s possible, without seeing the exact VNET setup it’s hard to say. Is it a publicly accessible network setup or do you have a VPN for it onto your internal network, for example?
