I’ve tried reading up on how this is meant to work but the docs aren’t in sync with what I am seeing.
I have some Powershell code that runs a couple of AWS CLI commands (around elbv2 and target groups)
I have created a Step Template based on the AWS CLI Script step to run a command.
It feels like the right thing to do as we don’t need to be on a specific target at this point. Just run these commands in our AWS account.
I want to use as vanilla a solution as possible, so am trying to use the built in AWS CLI environment in the default Windows worker.
First issue is the step errors with:
System.Exception: AWS-LOGIN-ERROR-0003: Failed to access the role information under http://169.254.169.254/latest/meta-data/iam/security-credentials/, or failed to parse the response. This may be because the instance does not have a role assigned to it
Obv I’ve clicked the link but that doesn’t really help.
I have tried running the step using a role, but then running it using an AWS Account variable.
Unfortunately here the UI is different from the docs and doesn’t show the account drop down. It just lets me add a variable in as a string.
I’ve also done this (as there should be a variable called #{AWSAccount} available to it in the deploy) but this still errors with the same error above.
Why is the worker instance trying to call for the role metadata? Surely it shouldn’t need to if I have given it the correct AWS Account credentials?
Why would this even work like this anyway? I want to run on a worker so getting the metadata wouldn’t make sense would it?
Like I say I thought I understood this but this doesn’t seem right at all so I have probably missed something fundamental.
My requirements seem pretty simple and well-suited to this worker but I just don’t know how to get it working.
A little progress.
Seems I can get the step to pick up the account if I use just the name of the variable
So in the field AWS Account I just add AWSAccount. Don’t try and use the variable sytax i.e. #{AWSAccount}. That’s not terribly clear.
The docs seem to use the UI I was expecting with a dropdown of the accounts. But in this case that wouldn’t work as the account is indeed in a variable and would change per deployment. So it comes down to that doc in https://octopus.com/blog/run-aws-cli-in-octopus-deploy and why that uses the UI. I ended up just confused
I’m wondering if there is a better way of setting this up but I guess not.
Our advice team took a look and they think you’re doing this in the best way possible. Would you be able to send us a screenshot of your account section of the step? You can direct message for privacy reasons if you’d like.
Did you click the binding button on the right to input the variable?
Hello again @jeremy.miller
Thanks so much for jumping on.
I realise my original request(s) ended up a little muddled as I was still in the middle of sorting out the step and understanding how it was meant to work.
I don’t think there’s any massive privacy concerns if I just post the screencap of those inputs here (I expect a lot of users have a variable called AWSAccount!)
As you can see we only have the “Insert a Variable” button and no “Bind” button. The bind buttons are present for the two boolean values though but that doesn’t really help.
We’re on v2020.5.0 (Cloud)
I don’t think that a bind button here would work because the step settings are outside any context of an AWS account or tenant. I think my original confusion was simply around how to add the variable name, as I instinctively went to add #{AWSAccount}. It’s just not really clear and the error that comes back when it runs doesn’t help because if it can’t use the account it just runs the instance metadata detection which doesn’t make any sense on the default instance Windows worker if I understand it correctly.
As it stands I think I am going to have to drop the whole idea of an AWS CLI Worker step because I need to run an ELB target group register on a specific instance as it is being deployed, which means I have to be in the context of a deployment target and an EC2 instance. The worker doesn’t have the context there to run the command I need.
I’m therefore planning to use IAM Roles (hopefully by assuming the role) in order to get the target’s instance ID. Requires a little more setup on the target itself (a worker would have been nice) but I think it makes more sense.
Sorry, that was a mistake on my part for not going and testing it within a step template. I went and looked now and see that it can only be a variable since drop downs can’t be used within Step Templates. I think that part is by design. However, the #{} syntax not working seems off. I can speak with the engineers and see if that’s intentional or not, and if it is, we should probably put in a tooltip to not use it and just type only the variable string.
I spoke with advice regarding your last paragraph, and they agree you are probably headed in the right direction, unless you store the instance name as a target name or in a variable.
I will update you when I hear back from the engineers, and please let me know if you’d like to discuss your process with us more.
Perfect thanks Jeremy.
We’ll watch the issue but as I said for now it’s not really slowed us down.
It’s just appreciated that you and the team are so quick and helpful to respond.
