How do we create Launch configurations in cloudformation with specific name.? I looked at the docs https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-launchconfig.html, there is no property that sets the name of the launch configuration that we create in template.
Is there any way?
You should not try to name the LaunchConfiguration yourself, as cloudformation need to setup its own name to be able to update it later.
Usually, the LauchConfiguration will be named according to the stack and resource name from the template, something like: {stack-name}-{resource-name}-{AWS-generated-id}, this gived me for example: amp-g2g-preprod-api-ec2-ApiLaunchConfiguration-1PQ85HXBX7DVC.
If you need to reference anywhere else your LaunchConfiguration, use {"Ref":"..."} from within the template, or use output export/import from another template.
Related
As in the title of my post, it is possible? I don't see any options.
Also, the job details include advanced properties that include the name of my script, for example, job-name.py When the python script is renamed, will the job name also change? I'm afraid I might mess something up after the change.
Thanks in advance
From CloudFormation docs (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-glue-job.html) is stated that changing the name parameter would replace the job so I would say no.
Expanding on the answer from #zoran2709:
From CloudFormation docs (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-glue-job.html) is stated that changing the name parameter would replace the job so I would say no.
In the console, it doesn't look like you can. If you defined this job in CloudFormation, you can update the name of the job, but it will replace the resource with a new one. I would recommend setting the UpdateReplacePolicy on the resource to Retain just to be safe. Checkout the docs here:
If you update a resource property that requires that the resource be replaced, CloudFormation recreates the resource during the update. Recreating the resource generates a new physical ID. CloudFormation creates the replacement resource first, and then changes references from other dependent resources to point to the replacement resource. By default, CloudFormation then deletes the old resource. Using the UpdateReplacePolicy, you can specify that CloudFormation retain or, in some cases, create a snapshot of the old resource.
So I have a command like this that should create the instance template and give it the "cloud-platform" scope (which should give full access according to docs):
gcloud compute instance-templates create "webserver-template"\
--source-instance=webserver --source-instance-zone=us-east4-c\
--configure-disk=instantiate-from=custom-image,custom-image=projects/myproject-dev/global/images/webserver-image,device-name=webserver\
--network=vpc-dev --scopes=cloud-platform
However, GCP seems to ignore that scope and assigns the default ones instead. Am I missing something here? I did go to an instance template in the GCP UI and created a new one based on it, and specified the option to "Allow full access to all Cloud APIs". When I then use gcloud to describe that template, the scope is "cloud-platform" as it should be. I just can't figure out how to do it all in one gcloud command.
EDIT: I also tried "--scopes=https://www.googleapis.com/auth/cloud-platform"
The problem is the scopes command-line option. Change to
--scopes=https://www.googleapis.com/auth/cloud-platform
I figured out what was going on. As you can see in my original question, I'm specifying the flag "--source-instance". And according to the docs:
The name of the source instance that the instance template will be created from.
You can override machine type and labels. Values of other flags will be ignored and values from the source instance will be used instead.
So the scopes flag was rightfully being ignored, and my source instance had the more limited scopes assigned to it.
Can you rename a resource in a CloudFormation template?
Let's say I've created a stack template that creates a single lambda function.
GetTheFunnyPhraseText:
Type: AWS::Serverless::Function
Properties:
CodeUri: ../Lambda/
Handler: GetFunnyPhrase.handler
FunctionName: GetFunnyPhrase
Role: !GetAtt [ ExecuteFunctionGetFunnyPhrase, Arn ]
For whatever reason, I want to change the resource name GetTheFunnyPhraseText to GetFunnyPhrase. Is there a mechanism to change the name?
A couple things I tried...
Changing the resource name in the template. It looks like this acts like a delete on GetTheFunnyPhraseText and create of GetFunnyPhrase. Problem here is the resource creation happens before the resource deletion causing the action to fail because the Lambda function exists.
Create two drafts of the template. Draft-1: Change the function name for the existing resource(s). Draft-2: Delete the old resource (omit their definition from the template) and add the new resource. Execute the draft templates in sequence: 1st then 2nd. This works. It's just gross.
For folks that suggest not naming the function, understood; put a pin in that piece of feedback for the moment.
Now that CloudFormation import is available it's technically possible to do this, although it's tedious.
Here's what you'd need to do:
Update the definition for GetTheFunnyPhraseText to add DeletionPolicy: "Retain", upload to CloudFormation
Remove GetTheFunnyPhraseText entirely from your template. Upload to CloudFormation. This will not actually delete the underlying Lambda because of the previously added DeletionPolicy
Revert your template back to the previous state in Step #1 (add GetTheFunnyPhraseText back) and change the logical name to GetFunnyPhrase
Start the "Stack Actions" > "Import resources into stack" workflow.
Upload your reverted template (with the changed logical name, still including the DeletionPolicy)
The import process will notice the new GetFunnyPhrase logical name and ask you what actual FunctionName should be mapped to that name. Provide the existing GetFunnyPhrase Lambda name and complete the import.
Finally, you can re-upload your template and remove the DeletionPolicy
A tedious process for sure, but technically possible if you really don't want to delete the existing resource.
No! Renaming a resource's logical name is not possible in Cloud Formation.
As you tested as well, CloudFormation sees it as the removal of the old resource and creation of the new one. This is so because the logical resource IDs are bound to the physical IDs of the resources by CloudFormation after creation. But for CloudFormation template language, it only recognizes the logical ID while parsing the template so any changes to that would mean the resource associated to it is going to be changed.
In some resource types though you can set the physical IDs yourself by using certain name properties which are resource-specific, for example a resource AWS::RDS::DBInstance may have a property DBInstanceIdentifier which will be the physical name of the db instance itself.
Seems it's common practice to make use of count on a resource to conditionally create it in Terraform using a ternary statement.
I'd like to conditionally update an AWS Route 53 entry based on a push_to_prod variable. Meaning I don't want to delete the resource if I'm not pushing to production, I only want to update it, or leave the CNAME value as it is.
Has anyone done something like this before in Terraform?
Currently as it stands interpolation syntax isn't supported in lifecycle tags. You can read more here. Which will make this harder because you could use the "Prevent Destroy". However, without more specifics I am going to take my best guess on how to get your there.
I would use the allow_overwrite property on the Route53 record and set that based on your flag. That way if you are pushing to prod you can set it it false. Which should trigger creating a new one. I haven't tested that.
Also note that if you don't make any changes to the Route53 resource it should trigger any changes in Terraform to be applied. So updating any part of the record will trigger the deployment.
You may want to combine this with some lifecycle events, but I don't have enough time to dig into that specific resource and how it happens.
Two examples I can think of are:
type = "${var.push_to_prod == "true" ? "CNAME" : var.other_value}" - this will have a fixed other_value, there is no way to have terraform "ignore" the resource once it's being managed by terraform.
or
type = "${var.aws_route53_record_type}" and you can have dev.tfvars and prod.tfvars, with aws_route53_record_type defined as whatever you want for dev and CNAME for prod.
The thing is with what you're trying to do, "I only want to update it, or leave the CNAME value as it is.", that's not how terraform works. Terraform either manages the resource for you or it doesn't. If it's managing it, it'll update the resource based on the config you've defined in your .tf file. If it's not managing the resource it won't modify it. It sounds like what you're really after is the second solution where you pass in two different configs from your .tfvars file into your .tf file and based off the different configs, different resources are created. You can couple this with count to determine if a resource should be created or not.
I am running a AWS CloudFormation stack that takes in some parameters and launches EC2 instances along with other AWS resources. The parameters are fed into the user data of the EC2 instance and based on that changes are made dynamically to the web application residing on the EC2 instance.
UserData:
Fn::Base64:
Fn::Join:
- ""
-
- "#!/bin/bash \n"
- "sh website-conf/website_mysql_config.sh "
- " -c \""
-
Ref: "CompanyName"
As shown in the example above, CompanyName is one of the many parameters passed to the userdata script. The problem is, when any one or multiple of parameters are updated, CloudFormation does not detect that and instead throws this error.
So, in order to update the stack, I have to edit the stack and make changes to the ASG so that CloudFormation 'sees' the changes and executes the stack update.
Is there a way to force CFN to update the stack when the parameters are updated?
CloudFormation will not update the stack unless there is a change in properties of the resources already created in the stack.
For example:
Consider I have a simple template to create a database where I need to pass 2 parameters:
db-name
region
Assume that I am using db-name passing it as value to DBInstanceIdentifier.
Also assume that I am not using the input parameter region for any purpose in creation of resources (or its properties) of the stack in any way.It is more of a dummy parameter I keep for readability purpose.
I passed (TEST-DB1, us-east-1) as input parameters to the CloudFormation template and successfully created the resources.
Scenario-1:
Now if I update the stack(still using the existing template) and just change the input parameters to (TEST-DB2, us-east-1). ie: changing just the db-name and not the region. Then CloudFormation will detect that, this parameter update, results in change in properties of running resource(s) of the stack and will compute and display the modifications as a change set.
Scenario-2:
Suppose I make another update(still using the existing template) property and just change the input parameters to (TEST-DB1, us-east-2). ie: changing just the region and not the db-name. Then CloudFormation will detect that, this parameter update, result in NO change in properties of running resource(s) of the stack will show the Error creating change set.
Bottomline:
Your change in input parameter must result in an update/replacement of any resources(or its attributes like security-groups,port etc..) of the stack. Then AWS CloudFormation will display them as Change Sets for your review. Also, the method (update or replacement) AWS CloudFormation uses depends on which property you update for a given resource type.
Your parameter "CompanyName" is not making any changes to the running
resources of the stack. Hence it is reporting as Error creating
change set. You need to use it to create any resource/resource properties of the stack. Then CloudFormation will detect the change-sets when you modify it. The same applies for any other input-parameters which you use.
Use the AWS CLI Update-Stack command. If you use the AWS CLI you can inject parameters into your stack so any change to any of the parameters result in a new stack. I do this myself to inject the Git/version commit ID into UserData so simply committing changes to the stack's JSON/Yaml to Git will allow stack updates. Any change to the parameters file will allow stack updates, even just a comment. I reference my Git commit ID in UserData the same way you are referencing Ref:CompanyName so when I change the Git commit ID the userData section is updated on stack updates.
Update Stack Command
aws cloudformation update-stack --stack-name MyStack --template-body file:///Users/Documents/Git/project/cloudformation/stack.json --parameters file:///Users/Documents/Git/project/cloudformation/parameters/stack-parameters.dev.json --capabilities CAPABILITY_IAM
Process
With this approach you make your parameters changes to the parameters json or yaml file then check it into version control. Now if you use a build server you can update your stack by checking out master and just running that one line above. Using AWS CodeBuild makes this easy so you don't need jenkins.
The answer of your problem is already answered with this state, CloudFormation will not update the stack unless there is a change in properties of the resources already created in the stack.
And for the answer for your question, please check the explanation below.
There is a way to force Cloudformation to update the stack using the AWS::CloudFormation::Init.
By using cfn-init, each instance can update itself when it detect the change that made by AWS::CloudFormation::Init in metadata.
There is a concept that we must understand first, that is the difference between UserData and metadata, at least under the AWS::CloudFormation::Init case.
Userdata: Will be only called once when the instance is being launch for the first time (this including update that need the instance to be replaced). So, if you update the stack (not creating a new one), even if you change the parameter value, it won't change anything if you call the parameter under UserData.
Metadata: Can be updated anytime. To make it works, you have to make sure that the daemon that detect the metadata changed is running (the daemon is called the cfn-hup)
If you already use the Metadata and AWS::CloudFormation::Init, the data is not immediately being updated. As far I know, here is the condition the data to be change after change the Metadata value.
Reboot the instance
Run cfn-init command again with it's parameter
Waiting about 15 minutes, because the daemon to check the change in Metadata is checking the change once in 15 minutes.