-
Notifications
You must be signed in to change notification settings - Fork 0
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
fix(postgres-manager): failing unit test from cdk-nag
#128
Conversation
vpc: ec2.IVpc; | ||
lambdaSecurityGroup: ec2.ISecurityGroup; | ||
}; | ||
|
||
export class PostgresManager extends Construct { | ||
constructor(scope: Construct, id: string, props: PostgresManagerStackProps) { | ||
export class PostgresManagerStack extends Stack { |
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.
@mmalenic am thinking of making microservice to stack instead of construct. One of the thought is that we could have the control for each microservice stack (e.g. we could deploy yarn cdk-stateless-pipeline deploy ${stateless-microservice-stack}
instead of the whole stateless stack). Do you have any thoughts or perhaps objection on this?
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.
No objections, I think that's a good idea. What would be the process of deploying individual microservice stacks? Would there be a individual_stacks.ts
file in bin
that lists all the microservices, or is there a way deploy stacks that are nested within other stacks?
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.
Hmmm, perhaps adding in the stack construct at the bin/orcabus.ts
could be it and yarn cdk-orcabus ls
could list all the stacks? I temporary deploy from yarn cdk-stateless-pipeline deploy ${stateless-microservice-stack}
but maybe I should try defining at bin/orcabus.ts
(thou might be some namespace clashes). Not sure what is the best pattern/approach yet.
{ | ||
"name": "lambda-with-rds", | ||
"name": "postgres-manager", | ||
"packageManager": "[email protected]", | ||
"dependencies": { | ||
"@aws-sdk/client-secrets-manager": "^3.515.0", |
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.
Should this be in the top-level package.json
?
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.
As part of the postgres-manager lambda, it will require the secret manager sdk part of the lambda asset to retrieve the master credentials and generating the random password. So I think putting at the inner package.json
should be relevant?
tsc
check on microservicecdk.construct
tocdk.stack