I’m having some issues getting my Octopus Server to use the Powershell Az module instead of the baked in AzureRM module.
I have set the step to use Azure tools pre-installed on the worker enabled, I have installed the Az module on my deployment worker and have checked the service account running the tentacle can use the module in the OS, however, my deployments keep falling over with:
ObjectNotFound: The term ‘az’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Am I missing something I should be doing server config wise to allow Octopus to use the Az module?
In most cases, a service restart of the Octopus Server service (and for anyone else reading this, it applies to the Tentacle service as well, if you encounter this on a worker/Tentacle). If you installed az after the service was started, it won’t know about the updated PATH environment variable with az's executable location, restarting the service will allow it to initialise with the new PATH and be able to call it directly.
Thanks for that, I thought that was the case as well, so I tried both restarting the tentacle and restarting the server the tentacle is on, no joy unfortunately.
I haven’t tried a restart of the Octopus server as I didn’t think it would be needed, the jobs are run on the worker not the server, would you still recommend a restart of the server in this case?
On a worker, a Tentacle service restart should be all that you need to get the PATH variable updated, the Octopus server service would only be needed if you were using the built-in worker on the Octopus server itself.
You have done most of the common steps that I’d typically suggest, like checking the user running the tentacle service can access the executable outside of Octopus etc.
One thing to verify, and I do apologize in advance for how “simple” this one is, is the execution location of the step in your deployment process. If it’s configured for the built-in worker on the Octopus server, a different worker pool, or even a different worker in the pool that’s not configured yet, we could see this behavior.
If none of this is the case, if you could email us through a copy of your raw task log for the deployment to support@octopus.com, we can take a look to see if there’s anything out of place
No worries with the question, we only have 2 workers, one for prod one for non prod, and I installed the Az module on the non-prod one, and can see in the deployment logs that the right worker is being used to try and run the script.
I’ll give the box a reboot tonight to make absolutely sure and see if it fixes the issue, will get back to you.
No joy I’m afraid, I’m even getting the same error when just try and run a normal PowerShell script, not the Azure Script, even dumbed it down to just trying to get the job to print out the az --version information.
Will shoot over the raw task log today. Thanks for you suggestions in any case.
Thanks for that, that makes sense for my dumbed down script where I’m just doing az –version, but on my more complex one, the one I sent you the raw log from, I’m using the proper module commandlets.
I have emailed the script to so you can see what I’m doing.
Unless I’m interoperating the logs wrong, its almost like Octopus is trying to use the Azure CLI to authenticate but cant find the tool installed, as this only started happening when I tell Octopus to use the Azure Tools pre-installed on the worker, should I be telling it to use the bundled ones instead? Or do I need to install the Azure CLI as well in order to use the pre-installed on the worker setting?