4. Deploy the Frontend

Deploy the frontend on the account

We were told that, for a full deployment, we will need to copy the properly configured application files into the S3 bucket with the name <YourEnvironmentName>.app.

Considering the initial tests, we are still receiving a 403 error when trying to access the application. Some people believe that by making this S3 bucket public, we will solve this access issue. However, other folks say that we should use CloudFront to restrict access to the S3 origin and better secure the bucket content.

What do you think is the best option? Can you give us a justification for your decision?

Based on intel, we received some guidance on how to solve this…

[Option 1] If you HAVE NOT completed all workshop steps to fix the environment:

Well, the first step seems obvious: Go through the process of fixing the environment!

However, a developer on our team has been inspecting the code, and she thinks that there is an easier way for fix Alien Attack.

It was said that if you go to your Cloud9 environment, navigate to the ~/environment/aws-alien-attack/infrastructure/cdk on the terminal, and then run the cdk command with specific parameters, you can fix the environment.

For example, if you run the command below, CDK indicates that the missing parameter on Systems Manager/Parameter Store - /<envnameLowercase>/session - is going to be created when you use the cdk deploy command in place of the cdk diff:

cdk diff -c envname=$envname -c sessionparameter=true

Our developer also told us that she identified other parameters that can be passed to CDK via the command line:

  • kinesisintegration=true, she believes that must be used to automatically deploy the missing integration between Kinesis Data Streams and Lambda.
  • firehose=true seems to create the missing Kinesis Data Firehose resource, integrating it with the existing Kinesis Data Streams.
  • deploycdn=true seems that should be used to deploy a CloudFront distribution, and in this case it will make the content at the .app S3 bucket readable via the Cloudfront URL.

She bets that if you execute the command below in an untouched new deployment of Alien Attack, you will be able to fix everything automatically. She hasn’t tried it yet because she is waiting for the approval from the Change Management team.

cdk deploy -c envname=$envname -c sessionparameter=true -c kinesisintegration=true -c firehose=true -c deploycdn=true

Once the deployment finishes, the next step is to move the configured frontend application to the S3 .app bucket, by executing the command below from the ~/environment/aws-alien-attack/infrastructure folder:

source deploy.frontend.sh

You will be able to access the application via your CloudFront Distribution URL, noted in the Amazon CloudFront Console.

[Option 2] If you have completed all the workshop steps to fix your environment:

In such case, your enviroment is working and you can create a session and play the game from your Cloud9 enviroment, but the content of the ~/environment/aws-alien-attack/application folder is not yet deployed on your S3. However, even if you had it, you still wouldn’t be able to access the application via the static website hosting endpoint of your .app bucket because that bucket is not public.

So, after having the content on your bucket, you have 2 options: to deploy the Cloudfront distribution for your environment, or to make the bucker public readable.

Option 2a: If you decide to deploy Cloudfront…

If you decide to deploy Cloudfront, which should take around 15-20 minutes, you need to execute the command below:

cdk deploy -c envname=$envname -c deploycdn=true

You can check in on the progress of this deployment by navigating to the Amazon CloudFront Console. Once your deployment has completed, your application will be accessible from the associated CloudFront Distribution URL.

Finally, copy the applications to the S3 bucket by issuing the command below from the ~/environment/aws-alien-attack/infrastructure folder :

source deploy.frontend.sh

As result, you will get an output with your properly configured /application/resources/js/awsconfig.js file, a log of the copy of the files to S3 and, if you have deployed Cloudfront, the URL pointing to your distribution which you can use to access your deployment.

… or Option 2b: If you decide to make the objects public in your S3 bucket instead

To do this, you need to create a resource policy for your S3 bucket - maybe using the AWS Policy Generator - that grants permissions to everyone to read objects from your S3 bucket. However, we have heard that this is not best practice to make buckets world readable. What do you think about this? Does this apply to Alien Attack?

After creating and applying the policy, the next step is going to be to move all the code to S3. So, from the ~/environment/aws-alien-attack/infrastructure folder, execute the following command:

source deploy.frontend.sh

In this case, you will access the application via the S3 static website hosting endpoint. Can you find it?

That was quick! While making your S3 objects public took less time, let’s compare the two approaches. Which one was more efficient? Which one was more secure? Can you highlight the benefits? Is it worth waiting for your CloudFront distribution to deploy?

Congratulations! You’ve successfully hosted your own Alien Attack Environment.

The home page of your CloudFront Distribution URL should look something like this:

Image

This is the end of our journey together… for now. Check back later for more modules and new activities to further improve your Alien Attack Application.

Goodbye.