feat: add front rendering app #8728
Conversation
|
Size Change: 0 B 🆕 Total Size: 0 B |
| new StringParameter(this, 'ec2RoleArn', { | ||
| // Annoyingly this doesn't follow the same pattern as the other SSM parameters | ||
| parameterName: `/${stack}/${stage}/${app}.loadBalancerDnsName`, | ||
| stringValue: loadBalancer.loadBalancerDnsName, | ||
| }); |
There was a problem hiding this comment.
This autogenerates the SSM parameter that we can use here.
There was a problem hiding this comment.
Looks good - this is an exciting step!
Just a warning that this "conflicts" (although not at a file level) with #8886 - one of these PRs will need to be updated to copy DotcomRendering-front-CODE.template.json, depending on which gets merged first. I'm mentioning it because I don't think it would cause a file conflict in git, but it would break the build.
| CODE: DotcomRendering-front-CODE.template.json | ||
| cloudFormationStackByTags: false | ||
| cloudFormationStackName: render-front | ||
| amiParameter: AMIRenderfront |
There was a problem hiding this comment.
how does this work?
There was a problem hiding this comment.
@JamieB-gu do you have more insight on this - I can't really see where it's used?
There was a problem hiding this comment.
When you run cdk synth (in this project make cdk-synth) you'll see it in the generated cloudformation template.
AFAIK (@jacobwinch can correct me if I've got any of this wrong) AMIgo1 can be used to define an AMI with particular features, known as a recipe, and "bake" (build) it on a regular schedule. RiffRaff uses amiTags defined in the riff-raff.yaml file to derive the latest version of an AMI that's baked to a particular AMIgo recipe, and gets an id for this image. It passes this id into cloudformation during deployment2 via a parameter, and this is the name of that parameter. Cloudformation needs to know what name to expect and what it means (image id), so this will also be defined in the cloudformation template.
In our case we generate the cloudformation template using CDK, which automatically sets the name of this parameter to "AMI" + "name of your app"3. Previously we only had one app, rendering, so this parameter was always AMIRendering. This PR creates a new app called render-front, so now there's a second version of this parameter called AMIRenderfront.
This PR sets up RiffRaff to deploy both apps together, so we have two sets of deployments defined:
- One for the rendering app, using the
DotcomRenderingcloudformation template containing theAMIRenderingparameter. - One for the render-fronts app, using the
DotcomRendering-frontcloudformation template containing theAMIRenderfrontsparameter.
AFAIK @jamesgorrie you would like this new fronts app to use the same AMIgo recipe as the existing rendering app. Therefore we're able to use a shared deployment template45 to define most of the AMI configuration (like amiTags), only diverging when we hit this amiParameter field because it's different for each app as mentioned. As we always want the same recipe, I think it's preferable to only define and update it in one place, which also makes it a bit easier to run the check-node-versions script:
dotcom-rendering/scripts/check-node-versions.mjs
Lines 37 to 38 in 3a1ef2e
Footnotes
-
https://github.com/guardian/amigo/blob/5edc0ff7daaaee94f3697c35f2729b1a12391510/docs/riffraff-integration.md ↩
-
https://github.com/guardian/cdk/blob/402a5bb57f696461cd1c4f7afc2220fc525d3700/docs/migration-guide-ec2.md?plain=1#L191 ↩
-
https://github.com/guardian/riff-raff/blob/main/riff-raff/public/docs/reference/riff-raff.yaml.md#templates ↩
-
https://github.com/guardian/riff-raff/blob/main/riff-raff/public/docs/reference/riff-raff.yaml.md#template ↩
There was a problem hiding this comment.
This all sounds correct to me @JamieB-gu!
@georgeblahblah - I'll wait for that PR to be merged as that change is more relevant to this PR than that. |
| bucketSsmKey: /account/services/dotcom-artifact.bucket | ||
| dependencies: | ||
| - frontend-static | ||
| - frontend-cfn |
There was a problem hiding this comment.
I think we want to depend on the render-front-cfn deployment here:
| - frontend-cfn | |
| - render-front-cfn |
|
The latest changes look good to me 👍 |
…ng into front-code-stack
jamesgorrie
force-pushed
the
front-code-stack
branch
from
c32b889
to
0751562
Compare
What does this change?
Adds new
front-webapp to our stack.Part of #8351
This PR also stores the ELB in a parameter that we can later read from
frontendto help mitigate any manual input of these values.Why?
When we see a degradation of 1 endpoint in DCR e.g.
/Front,/AMPInteractiveit can have a knock-on effect and degrade the performance of all the other stacks as DCR is currently the rendered as described here.Some notes on creating a stack (to be stored / scripted somewhere)
/CODE/frontend/{app}/elb.logs.bucketName/CODE/frontend/{app}/logging.stream.nameCo-authored-by: Georges Lebreton georges.lebreton@guardian.co.uk