This seems like a noobish problem, so I apologize if the answer is really obvious.
I’m trying to run an AWS CLI step in a deployment, using a Default Worker and Powershell, and in the script window I tried running ‘aws lambda…’ but got the error “ObjectNotFound: The term ‘aws’ is not recognized as the name of a cmdlet…”
So then I tried using the cmdlet Update-LMFunctionCode and got a similar error of “ObjectNotFound: The term ‘Update-LMFunctionCode’ is not recognized as the name of a cmdlet”
Can someone help me what I’m doing wrong? Thank you!
Depending on the version of Dynamic Worker the Default Worker Pool is set to use, they come with different tools: Dynamic Worker pools - Octopus Deploy
Unfortunately, no matter which one you choose, they wont have AWS CLI. However, we do have a feature to help with this, Execution containers.
When choosing which version of worker tools you want to use, there is a tradeoff.
You can choose to use the latest version (untagged), which will typically have the quickest download time to your worker because we bundle a version of the docker image close to the latest, but the downside here is that your tool versions will get updated regularly which may cause instability if you are depending on a AWS CLI cmdlet that gets deprecated, or if Amazon introduces a bug into their tool.
The alternative is to pick a version and stick with that version. The downside here is that as the worker tools that get bundled with the dynamic worker get updated over time, this will cause more drift with the static version you chose, which means the download time will increase over time and this will cause some initial delay when you are leased a new worker.
Please let me know if that helps or if you have any other questions.
Quick followup: it sounds like maybe that image is in a registry that Octopus makes available…? Or do I have to host the image in my own container repository?
If you want to make your own execution container with your own custom set of tools, you would just need to find hosting and set up a docker registry in your Octopus feeds and use that.
Thanks Jeremy! The current hurdle is “Unable to connect to docker service” regardless of which container I try to get from Docker Hub. I tested it through the external feeds and am able to search for images in the repo there, and I’m using a free login to auth against Docker. Any thoughts what I might be up against?
OMG never mind, I see what I’m doing wrong, running the job in a container instead of on the worker. sigh … wait, is that really the problem? (This is a “run an AWS CLI script” step type)
Are you using our Dynamic workers? If so, can you go to Infrastructure and check which type of workers are being used in that worker pool? Windows Server 2019 workers should have docker installed on them by default. If you have a 2019 worker, it’s possible that you got a bad worker.
If you aren’t using our Dynamic workers, can you please try remoting into those workers and running docker version on them in PowerShell? It’s best to run this logged in as the Service Account that runs the Octopus Tentacle service to make sure there’s not a PATH issue.
