[EPIC] CDK

[AshCorr]

Tasks

Preview Give feedback

1. CDK: VPC Migration #7624
   CDK ⚙️ +1
   
2. CDK: InternalLoadBalancerSecurityGroup Migration #7625
   CDK ⚙️ +1
   
3. CDK: InstanceSecurityGroup Migration #7626
   CDK ⚙️ +1
   

   
4. CDK: InstanceRole Migration #7629
   CDK ⚙️ +1
   
5. CDK: InstanceProfile Migration #7630
   CDK ⚙️ +1
   
6. CDK: InternalLoadBalancer Migration #7631
   CDK ⚙️ +1
   
7. CDK: LaunchConfig Migration #7632
   CDK ⚙️ +1
8. CDK: AutoscalingGroup Migration #7633
   CDK ⚙️ +1
   
9. CDK: ScaleDownPolicy Migration #7634
   CDK ⚙️ +1
   
10. CDK: ScaleUpPolicy Migration #7635
    CDK ⚙️ +1
    
11. CDK: LatencyScalingAlarm Migration #7636
    CDK ⚙️ +1
    
12. CDK: Backend5xxAlarm Migration #7637
    CDK ⚙️ +1
    

Ideally we should be using one of the pre-defined patterns such as GuEc2App that @guardian/cdk provides, however for now I believe we should use our own structs atleast whilst we migrate to CDK.

• This allows us to migrate one thing at a time to CDK, we can delete the resource definition from YML and add a CDK definition, whilst if we used a pattern I believe we'd have to migrate multiple things over at once.
• I'm not entirely sure how well a pattern will work with the traffic swimlane concept we have for seperating AR traffic from Web traffic.

Migration Guide

1. Pick a resource to migrate over
2. Find the appropriate GuCDK construct to represent that resource https://github.com/guardian/cdk/tree/main/src/constructs (hopefully there should be one!)
3. Create an instance of that construct in the constructor of https://github.com/guardian/dotcom-rendering/blob/main/dotcom-rendering/cdk/lib/dotcom-rendering.ts

export class DotcomRendering extends GuStack {
	constructor(scope: App, id: string, props: GuStackProps) {
		super(scope, id, props);

                const vpc = new GuVpc(this, "vpc")

                // New construct goes here!

		const yamlTemplateFilePath = join(
			__dirname,
			'../..',
			'cloudformation.yml',
		);
		new CfnInclude(this, 'YamlTemplate', {
			templateFile: yamlTemplateFilePath,
		});
	}
}

Constructs that depend on other constructs (like LoadBalancers that depend on SecurityGroups) should go last, whilst constructs that don't need other constructs such as VPCs should go first, other than that order is not very important. CfnInclude should always be last.

4. Delete the old resource from the cloudformation file.
5. Delete https://github.com/guardian/dotcom-rendering/blob/main/dotcom-rendering/cdk/lib/__snapshots__/dotcom-rendering.test.ts.snap#L495-L549 and run yarn cdk:synth, this should cause the file to be regenerated with your changes.
6. Compare the new dotcom-rendering.test.ts.snap file with the old one and verify that it has not changed. Some changes are expected, the ID of a resources will likely change, and some extra properties that previously didn't exist might have been explicitly set to their default values, but otherwise the resource should look mostly the same.

Different properties based on stage

We previously used mappings to have different properties depending on Stage. We don't need to do this anymore with CDK.

If you need to have different properties for each stage add them as props to the DotcomRendering class (you might need to extend the GuStackProps type then specify them in https://github.com/guardian/dotcom-rendering/blob/main/dotcom-rendering/cdk/bin/cdk.ts

[VDuczekW]

Do reach out to DevX ops teams when needed

[VDuczekW]

it will be done one by one

[VDuczekW]

group to have a mob re how to move forward re load balancer - like for like or optimise

[VDuczekW]

good progress and work continuing as main priority this week

[VDuczekW]

check in with DevX to understand how and when we are ready to go in to prod - due to testing taking a lot of time