Closed cjoecker closed 11 months ago
Hi, once again sorry for the late response :see_no_evil: Normally this shouldn't happen, because we don't set dynamic parts in any of the ids, but only pass through, whats given to the construct or set static ids. Is this still a problem in the current version? Can you share some more code around that call?
Thanks already!
Hi @snowiow. I asked AWS customer support and they said that the ID is regenerated on every change in the CDK. So, I think there is not much we can do. So, I will close this issue. Here what they say:
...changes to your CDK code causes the instance to be replaced, therefore the instance id changes everytime a new instance is deployed, causing the need to change same in other step which references an instance id to run ssm command.
...
...there is no way to maintain the same ec2 instance id. ec2 instance id are randomly generated and is not assignable at launch time
In case someone need it, what I do now is, I output the bastion ID like this:
new CfnOutput(scope, "Ec2BastionId", {
value: bastionInstance.instanceId ?? "",
description: "EC2 Bastion instance id",
exportName: "Ec2BastionId",
});
And then I reuse it as an env
Variable in my github action like this:
- name: 🏗️ Export Bastion ID to ENV Variable
run: echo "DB_BASTION_INSTANCE_ID=$(aws cloudformation describe-stacks --stack-name AppStack --query 'Stacks[0].Outputs[?ExportName==`Ec2BastionId`].OutputValue' --output text)" >> $GITHUB_ENV
@cjoecker @snowiow CloudFormation redeploys a resource only if it's changed. It looks like it redeploys EC2 instance each time new AMI version is released. To prevent that, you can pass cachedInContext: true
option in the AmazonLinuxImage constructor here: https://github.com/moia-oss/bastion-host-forward/blob/0cf3b76045c16faab55f6cfb9a822c03e1638e35/lib/bastion-host-forward.ts#L120
This option is intended to prevent such a recreation. Keep in mind that passing this option means that version will become old with time, so we probably need to expose this option as a parameter to the BastionHostRDSForward construct end-users.
yes, that sounds good. Getting the newer AMI is generally a thing we want, so I would keep that as the default but we can expose the attribute in case someone wants to set this differently :+1:
thanks for pointing this out @NikitaKemarskiy :pray:
It's available with v2.1.0
@snowiow Thanks for quick response!
Right now, I'm creating a bastion as follows:
In every pipeline run, I deploy the stack. The problem is, that the bastion gets recreated on every deploy. That makes it generate a new id. Ideally, the bastion doesn't gets recreated and keeps the same id if it already exists.