- Notifications
You must be signed in to change notification settings - Fork 185
Add (optional) --profile options for run command#379
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
Uh oh!
There was an error while loading. Please reload this page.
Changes from all commits
59de786e410b9ddd1b00a97767b1File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -64,6 +64,8 @@ class Lambda { | ||
| this._setRunTimeEnvironmentVars(program) | ||
| } | ||
| this._loadAWSCredentials(program) | ||
| const handler = require(path.join(process.cwd(), filename))[handlername] | ||
| const event = require(path.join(process.cwd(), program.eventFile)) | ||
| const context = require(path.join(process.cwd(), program.contextFile)) | ||
| @@ -754,21 +756,6 @@ so you can easily test run multiple events. | ||
| console.log('=> Uploading zip file to AWS Lambda ' + region + ' with parameters:') | ||
| console.log(params) | ||
| const awsSecurity = { region: region } | ||
| if (program.profile) { | ||
| aws.config.credentials = new aws.SharedIniFileCredentials({ | ||
| profile: program.profile | ||
| }) | ||
| } else { | ||
| awsSecurity.accessKeyId = program.accessKey | ||
| awsSecurity.secretAccessKey = program.secretKey | ||
| } | ||
| if (program.sessionToken) { | ||
| awsSecurity.sessionToken = program.sessionToken | ||
| } | ||
| if (program.deployTimeout) { | ||
| aws.config.httpOptions.timeout = parseInt(program.deployTimeout) | ||
| } | ||
| @@ -777,7 +764,7 @@ so you can easily test run multiple events. | ||
| aws.config.httpOptions.agent = proxy(program.proxy) | ||
| } | ||
| aws.config.update(awsSecurity) | ||
| aws.config.update(this._loadAWSCredentials(program, {region: region})) | ||
| const lambda = new aws.Lambda({ apiVersion: '2015-03-31' }) | ||
| const scheduleEvents = new ScheduleEvents(aws) | ||
| @@ -875,6 +862,29 @@ so you can easily test run multiple events. | ||
| console.log(err) | ||
| }) | ||
| } | ||
| _loadAWSCredentials (program, options) { | ||
| if (typeof options !== 'object' || !options.region) { | ||
| options = {region: null} | ||
| } | ||
| const awsSecurity = { region: options.region } | ||
| if (program.profile) { | ||
| aws.config.credentials = new aws.SharedIniFileCredentials({ | ||
Contributor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems that there is a sense of unity if you make it to | ||
| profile: program.profile | ||
| }) | ||
| } else { | ||
| awsSecurity.accessKeyId = program.accessKey | ||
| awsSecurity.secretAccessKey = program.secretKey | ||
| } | ||
| if (program.sessionToken) { | ||
| awsSecurity.sessionToken = program.sessionToken | ||
| } | ||
| return awsSecurity | ||
| } | ||
| } | ||
| module.exports = new Lambda() | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes no sense here,
runis local only... perhaps you can explain the usecase a bit better?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @DeviaVir...good question...for sure the event.js is run against the handler locally.
But what happens inside the handler often interacts with AWS services (it may publish to kinesis or upload to S3, etc)- and being able to pass credentials and profile in a familiar way (e.g.
--profile) sounds like the right the thing to do.That's a pretty common use for the lambdas we're deploying.
Let me know if that answers your question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What stops you from using
environment variables?
The part I'm unsure about here, is that for a handler, you'd just expect it to be agnostic to what it runs. If we start passing these vars, the handler is not agnostic anymore.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @DeviaVir - good question, sorry for the late reply.
Agnosticism of handlers
Hmmmm - like I said in my prior comment - our handlers are rarely an island unto themselves.
They mostly do something aws-y as a result...like publishing to kinesis or uploading to S3.
Using AWS_PROFILE, AWS_ACCESS_KEY_ID, and AWS_SECRET_ACCESS_KEY
When you talk about adding those three env vars - you're talking about adding them to
.envright?node-lambdafavors having one AWS account across deployments. There's a lot of parallel flexibility betweendeployandrunnow (e.g:--runtime,--timeout,--configFile) and I feel that adding--profileadds to that flexibility.Without the
--profileflag/param, developers have to juggle the.envfiles depending on which account's services they want the handler to interact with. At least in our team, that juggling has been too easy to mess up. Being able to control it with--profilewould be more wieldy than juggling.envs.