handle subdomain

[StErMi]

Hi,

I look up at the source code and it seems that this construct does not support custom subdomain.
In this use-case I would like to deploy a website that will be available under ..com and it should create/use the same resources but add a CNAME with the CloudFront Distribution ID to the hosted zone.

Let me know if maybe I just missed some steps.

Best regards,

Emanuele.

[nideveloper]

Let me just make sure I fully understand the ask. So you already have a site deployed to say "cdk.com" but you want to add a new site on "subdomain.cdk.com" which should just add a CNAME record to Route53?

This construct has been evolving to meet people's needs rather than starting complete so happy to see how much effort this is

[StErMi]

Exactly. Now, I've just started learning CDK so I just assumed that the construct was not doing this looking at the source code. The "cdk.com" has been added manually from the AWS Console but I don't think that this will be a problem.

Usually, when at the moment we want to add a subdomain website we do these:

• Create an S3 bucket
• Create a CF distribution with the correct config (s3 + amazon certificate of the root domain + subdomain alias)
• Add the CName record to Route53 zone with the CF Distribution ID just created

After that, for each build we

• Delete the S3 content, replace it
• Trigger the CF invalidation

I've another question (that might be better if I ask it in a different issue). I don't know if it's just my lack of knowledge but how can I specify the S3 bucket region? CF and Route53 are global but I would like to specify where my S3 bucket should be created.

[nideveloper]

You're 100% correct in that you are the first person to ask for sub domains so it isn't built into the construct yet. I'll take a look into it over the next couple of days

[StErMi]

@nideveloper I just saw that there's already an example (not complete like yours) directly from @aws-samples for static site deployment.

I don't get why they don't allow you to specify to which AWS region they allow you to deploy your site / CF stack. Am I missing something?

[nideveloper]

You can define region at the stack level e.g. https://github.com/cdk-patterns/serverless/blob/f183222d260cb7e64d37f462acee69ea529351c6/the-rds-proxy/typescript/bin/the-rds-proxy.ts#L8

[SnapPetal]

I am confused since it takes an array of an alias. Would that not work?

new SPADeploy(this, 'valor-privacy').createSiteWithCloudfront({ indexDoc: 'index.html', websiteFolder: '../privacy', certificateARN: 'arn:aws:acm:us-east-1:664759038511:certificate/be6ac207-1fc3-4642-9729-7ca0eff2b5bc', cfAliases: ['privacy.valorskateandserve.org'], });

[StErMi]

As I said I'm still new to CDK, I mostly come from serverless-framework but I will give a try today to understand the implication.

CDK as far as I can see is missing a lot of documentation that explain to newcomers what is doing (at least that's my impression) and that's something not cool when you could harm your production env :D

[Tannheuser]

I am confused since it takes an array of an alias. Would that not work?

new SPADeploy(this, 'valor-privacy').createSiteWithCloudfront({ indexDoc: 'index.html', websiteFolder: '../privacy', certificateARN: 'arn:aws:acm:us-east-1:664759038511:certificate/be6ac207-1fc3-4642-9729-7ca0eff2b5bc', cfAliases: ['privacy.valorskateandserve.org'], });

This just populates CNAMEs property in CF distribution configuration, but does not add a new record to Route53 hosted zone.

[FavorWedge]

@Tannheuser This is what we use to set the Route 53 record. Not sure if it helps

const deployment = new SPADeploy(this, this.stackName, {
encryptBucket: true,
}).createSiteWithCloudfront({
indexDoc: 'index.html',
websiteFolder: '../admin/build',
certificateARN: props.certArn,
cfAliases: [props.siteName],
});

new r53.ARecord(this, 'cdn-a-record', {
zone: props.hostedZone,
recordName: props.siteName,
target: r53.RecordTarget.fromAlias(new CloudFrontTarget(deployment.distribution)),
});

[Tannheuser]

@Tannheuser This is what we use to set the Route 53 record. Not sure if it helps

const deployment = new SPADeploy(this, this.stackName, {
encryptBucket: true,
}).createSiteWithCloudfront({
indexDoc: 'index.html',
websiteFolder: '../admin/build',
certificateARN: props.certArn,
cfAliases: [props.siteName],
});

new r53.ARecord(this, 'cdn-a-record', {
zone: props.hostedZone,
recordName: props.siteName,
target: r53.RecordTarget.fromAlias(new CloudFrontTarget(deployment.distribution)),
});

Yes, it's helpful. We have the same approach by using SPADeploy output to create a new R53 record.

[StErMi]

I'm going to release my SPA version today or at max tomorrow. Something that I would like to do before that is to find a good way to handle different env with different configs.

For example, I will have a staging and production config, and based on that I would like to be able to specify a different region and a different domain.

[Tannheuser]

I'm going to release my SPA version today or at max tomorrow. Something that I would like to do before that is to find a good way to handle different env with different configs.

For example, I will have a staging and production config, and based on that I would like to be able to specify a different region and a different domain.

@StErMi This is how do we handle this in our project: we use yaml files with configurations for each environment.
Also you could use default environment variables like CDK_DEFAULT_ACCOUNT and CDK_DEFAULT_REGION.

import { App, StackProps } from '@aws-cdk/core';
import * as fs from 'fs';
import * as yaml from 'js-yaml';

import { CdkStack } from './cdk-stack';
import { EnvironmentProps, HostedZoneProps, SecurityProps } from './models';

const fileContents = fs.readFileSync('./config/variables.yml', 'utf8');
const yamlConfig: EnvironmentProps & HostedZoneProps & SecurityProps = yaml.safeLoad(fileContents);
const { account, region, stage, ...config } = yamlConfig;

const app = new App();
const stackProps: StackProps & HostedZoneProps & SecurityProps = {
  env: {
    account: account || process.env.CDK_DEFAULT_ACCOUNT,
    region: region || process.env.CDK_DEFAULT_REGION
  },
  ...config
};

new CdkStack(app, `my-stack-name-${stage}`, stackProps);

and variables.yml content

stage: dev
region: eu-central-1
zoneName: mywebsite.com
subdomain: subsite
certificateARN: arn:aws:acm:...........

[FavorWedge]

In most cases using the default account is not sustainable this is a good blog post about that topic.

https://taimos.de/blog/create-a-cicd-pipeline-for-your-cdk-app

[StErMi]

I'm going to release my SPA version today or at max tomorrow. Something that I would like to do before that is to find a good way to handle different env with different configs.
For example, I will have a staging and production config, and based on that I would like to be able to specify a different region and a different domain.

@StErMi This is how do we handle this in our project: we use yaml files with configurations for each environment.
Also you could use default environment variables like CDK_DEFAULT_ACCOUNT and CDK_DEFAULT_REGION.

import { App, StackProps } from '@aws-cdk/core';
import * as fs from 'fs';
import * as yaml from 'js-yaml';

import { CdkStack } from './cdk-stack';
import { EnvironmentProps, HostedZoneProps, SecurityProps } from './models';

const fileContents = fs.readFileSync('./config/variables.yml', 'utf8');
const yamlConfig: EnvironmentProps & HostedZoneProps & SecurityProps = yaml.safeLoad(fileContents);
const { account, region, stage, ...config } = yamlConfig;

const app = new App();
const stackProps: StackProps & HostedZoneProps & SecurityProps = {
  env: {
    account: account || process.env.CDK_DEFAULT_ACCOUNT,
    region: region || process.env.CDK_DEFAULT_REGION
  },
  ...config
};

new CdkStack(app, `my-stack-name-${stage}`, stackProps);

and variables.yml content

stage: dev
region: eu-central-1
zoneName: mywebsite.com
subdomain: subsite
certificateARN: arn:aws:acm:...........

How do you specify which file should be loaded when you deploy it?

[StErMi]

In most cases using the default account is not sustainable this is a good blog post about that topic.

https://taimos.de/blog/create-a-cicd-pipeline-for-your-cdk-app

Is it ok to always deploy everything even if I'm making changes at my infrastructure in the staging branch? What I would like to do is to be able to deploy to staging envs only when I deploy on the staging branch and on production envs only when I deploy on the master branch.