Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make our playbook command compatible with boto (for AssumedRoles) #26

Merged
merged 3 commits into from
Feb 18, 2021

Conversation

vkurup
Copy link
Contributor

@vkurup vkurup commented Feb 2, 2021

This is an attempted fix for caktus/ansible-role-django-k8s#29 (comment)

I haven't yet tested this out, but wanted to see what people thought of the approach.

Update. I've now tested it out locally, and it works. If I don't have profile_name set in my tasks.py, then it fails. If I set aws.profile_name = saguaro-cluster, then it succeeds.

Copy link
Member

@copelco copelco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @vkurup! Added a few comments.

While reviewing the original ticket, I remembered this comment about sts_assume_role. I've never actually tested it. Is that the same thing as what we're doing with boto3 in Python here? Would that be any better? Not a blocker, just wondering about it.

with c.cd("deploy/"):
c.run(f"ansible-playbook {name} {extra} -{'v'*verbosity}")
c.run(f"ansible-playbook {name} {extra} -{'v'*verbosity}", env=shell_env)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neat, looks like env updates the default environment dict by default, rather than replace it. 🆒

@@ -77,6 +77,7 @@ configuration each task uses.
"app": "appname",
"aws": {
"region": "us-west-2",
"profile_name": "my-aws-profile", # a profile from .aws/credentials
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the idea that since not all tasks require this method, this would be set temporarily in your local checkout, run the tasks, and then unset it? If not, I wonder if everyone is using the same AWS_PROFILE name or not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I was going on the assumption that we standardize the AWS_PROFILE that each developer uses for the project. The docs in jade-truffle now include a section for setting up a profile named after the project, and that's what we're doing in philly-hip. But maybe I should make that more explicit in the docs or here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right, and this is just the playbook task, not deploy. I suppose if you wanted an optional profile, you could write a project-level task to just set it ad-hoc, like inv staging temp-creds playbook.

So I think making it more explicit in the docs sounds good 👍

@vkurup
Copy link
Contributor Author

vkurup commented Feb 2, 2021

Hmm, I had skipped over your sts_assume_role comment in the other issue. It does look like it does the same thing, but in a cleaner way since it's done just for the problematic task. I'll give that a shot. What do you think the value for role_session_name is supposed to be?

@copelco
Copy link
Member

copelco commented Feb 9, 2021

Good question, I'm not sure, maybe it can be made up since it's just for CloudTrail?

I also don't mean to delay merging this PR as is, since it's working as is 👍

@vkurup
Copy link
Contributor Author

vkurup commented Feb 18, 2021

@copelco thanks for the reviews! This is updated.

@vkurup vkurup merged commit 0c8c64f into master Feb 18, 2021
@vkurup vkurup deleted the boto-compatibility branch February 18, 2021 15:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants