A 04 10/27/24, 12:57

A 04
Due Oct 17 by 3pm
Points 10
Submitting a file upload
File Types zip
Attempts 1
Allowed Attempts 3
Available Oct 10 at 9:40pm - Oct 17 at 3pm
This assignment was locked Oct 17 at 3pm.

Learning Objectives
The objective of this assignment is to learn how to build custom machine images with our application
and dependencies baked in.

Packer & Custom Images - Building Custom

Application Images using Packer
For this assignment only, install MySQL/MariaDB/PostgreSQL locally in the custom image.

1. Use Ubuntu 24.04 LTS as your source image to create a custom image using Packer.
2. All custom images you build should be private. Only you can launch instances from it.
3. All custom image builds should happen in your DEV AWS account.
4. Custom image builds should be set up to run in your default VPC.
5. The custom image should include everything needed to run your application and the application
binary itself. For e.g., if you are using Tomcat to run your Java web application, your custom
image must have Java & Tomcat installed. You should also ensure the Tomcat service starts when
an instance is launched. If you are using Python, make sure you have the right version of Python
and that the libraries you need are installed in the custom image.
6. The packer template should be stored in the same repo as the web application.
7. For this assignment only, install MySQL/MariaDB/PostgreSQL locally in the custom image.

https://northeastern.instructure.com/courses/192916/assignments/2473742 Page 1 of 7
A 04 10/27/24, 12:57

Packer Continuous Integration - Add New GitHub

Actions Workflow for Status Check
When a pull request is raised, this GitHub Actions workflow should do the following:

1. Run the packer fmt command. If this command modifies the packer template, the workflow
should fail and prevent users from merging the pull request.
2. Run the packer validate command. If this command fails to validate the packer template, the
workflow should fail, and users should be prevented from merging the pull request.

Packer Continuous Integration - Add New GitHub

Actions Workflow to Build Packer custom image
!!! danger Make sure you do not trigger your workflow to build custom image when pull request is
raised. It should only build custom image when pull request is merged.

Setup

1. You will need to create a new IAM service account (manually in AWS console) in the DEV AWS
for GitHub Actions and configure the security credentials in your organization repository. Refer
to this (https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions) for
more details.
2. Grant the service account the roles needed. See documentation
(https://github.com/hashicorp/packer-plugin-googlecompute/blob/main/docs/README.md#running-
on-google-cloud) for more details.
3. Install & configure on your GitHub Actions runner with this
AWS cli (https://github.com/aws-
actions/configure-aws-credentials) marketplace action.

When a pull request is merged, this GitHub Actions workflow should be triggered to do the
following:

1. Run the integration test.

2. Build the application artifact (war, jar, zip, etc.). This artifact should be build on the GitHub actions
runner and not in the custom image i.e. do not git clone your repository in the packer template
and then build it. You will build the artifact on the runner and copy it into the custom image.
3. Build the custom image with following.

https://northeastern.instructure.com/courses/192916/assignments/2473742 Page 2 of 7
A 04 10/27/24, 12:57

1. Create a local user csye6225 with the primary group csye6225 . This user should not have a
login shell, i.e. login shell should be /usr/sbin/nologin .
See https://www.baeldung.com/linux/create-non-login-user
(https://www.baeldung.com/linux/create-non-login-user) for details.
2. Install application dependencies and set up the application by copying the application artifacts
and the configuration files.
3. The application artifacts, configuration, etc., must be owned by the user csye6225 and
group csye6225 .
4. Add your systemd service file to /etc/systemd/system and configure it to start your service
when the instance is launched.
1. Run systemctl daemon-reload with sudo
2. Run systemtl enable <service_name> with sudo
4. No custom image should be built if any of the jobs or steps in the workflow fail.

Infrastructure as Code w/Terraform

In this assignment, you will update the Terraform template to add the following resources.

Application Security Group

1. Create an EC2 security group for your EC2 instances hosting web applications.
2. Add ingress rule to allow TCP traffic on ports 22 , 80 , 443 , and port on which your application
runs from anywhere in the world.
3. This security group will be referred to as the application security group .

EC2 Instance
Create an EC2 instance with the following specifications. You may go with default values for any
parameter not provided in the table below. The EC2 instance must be launched in the VPC created
by Terraform. You cannot launch the EC2 instance in the default VPC.

Application security group should be attached to this EC2 instance.

Make sure the EBS volumes are terminated when EC2 instances are terminated.
Parameter Value
Amazon Machine Image (AMI) Your custom AMI

https://northeastern.instructure.com/courses/192916/assignments/2473742 Page 3 of 7
A 04 10/27/24, 12:57

Protect against accidental termination No

Root Volume Size 25
Root Volume Type General Purpose SSD (GP2)

Submission
1. Create a folder with the naming convention firstname_lastname_neuid_## where ## is the
assignment number.
2. Clone each (all) repository you have created for the course using git clone command into this
directory. It is important that you clone your Organization repository and not your fork.
3. Create a zip of the firstname_lastname_neuid_## directory. The zip file should
be firstname_lastname_neuid_##.zip .
4. Now unzip the zip file in some other directory and confirm the content of the zip files.
5. Upload the Zip to the correct assignment in Canvas.
6. You are allowed to resubmit. If you think the ZIP file may have an issue, please submit it again.
Only the latest submission will be graded.

Grading Guidelines
Warning: The following guidelines are for information only and are subject to change at the discretion
of the instructor and TA.

Common Grading Rubrics

Git
1. All commits to GitHub repositories must be made via pull request. No changes can be made by
pushing commits directly to the main branch. The exception to this is the first commit made to the
repository to initialize it, which can be done directly from the UI.
2. All pull requests must have status checks and be enforced. Merging pull requests that did not
pass status checks may result in penalties.

Security
1. Committing any kind of credentials to the code or uploading them as part of your Canvas

https://northeastern.instructure.com/courses/192916/assignments/2473742 Page 4 of 7
A 04 10/27/24, 12:57

submission may result in a penalty.

2. Service providers may automatically disable your keys or suspend your account if they detect
keys being committed in your GitHub repositories, even if they are private. This can severely
affect your assignment grade and your ability to work on assignments in the course. This is not
grounds for assignment extensions; late penalties will apply as documented in the syllabus.

Software Engineering Best Practices

1. Values for variables should not be hardcoded in the code. It’s OK to set default values for
variables, but if the value cannot be modified during the demo or when the TA or instructor asks,
you may be penalized.
2. Follow industry standards and use a style guide for your code. You can find them with simple web
searches.

Code Stability, Error Handling, & Edge Cases

1. The application should not crash between various API calls.
2. The application, VM, or other resources should not require a restart during the demo unless the
grading guidelines require it to demonstrate a specific feature/functionality.
3. The server cannot respond with a 500 Internal Server Error. This usually highlights areas of code
that do not have proper error handling.

Previous Assignment Objectives

TAs must verify that students have resolved all open issues from the previous assignment(s).

Git & GitHub Repository (2%)

Git Repository Content Check
1. Check the repository for any IDE-specific files. IDE configuration files must not be in the
repository.
2. Verify their .gitignore configuration.
3. Check the repository for build artifacts such as .class , .jar , .war files
and build , node_modules , venv directory. None of these should be checked into the repository.
4. Check for dependencies. Dependencies from the Maven repository, npm, or Python should not be
committed to the git repository.

Git Forking Workflow

https://northeastern.instructure.com/courses/192916/assignments/2473742 Page 5 of 7
A 04 10/27/24, 12:57

1. No direct commits are made to the organization repository. Verify that the student works from a
forked repository and uses the feature branch. There should be no direct commits to the main
branch in their forked repository.

IAM (8%)
1. The student has created a separate IAM user for GitHub Actions in their DEV account.
2. This user has a custom IAM policy
(https://developer.hashicorp.com/packer/integrations/hashicorp/amazon#iam-task-or-instance-role)
attached to them.
3. This IAM user does not have admin access to the AWS account.
4. This IAM user does not have console access.
5. This IAM user only has programmatic access to the account.

GitHub Action Workflow - Packer Status Check (20%)

1. The workflow runs a check to make sure the packer template is formatted correctly. Test this by
raising PR in which the template is not properly formatted.
2. The workflow validates the packer template. Test this by removing some closing brackets.
3. Students cannot merge the PR when any of the above checks fail.
4. This workflow does not build the AMI.
5. The workflow runs on the organization repository and not in the forked repository.

GitHub Action Workflow - Packer AMI Build (20%)

1. This workflow runs only after the pull request is merged. It should not run when a pull request is
raised.
2. This workflow builds AMI in the DEV account and shares it with DEMO the account.
3. The AMI is private.
4. The AMI uses Ubuntu 24.04 LTS for the source image.
5. The Packer template does not contain any hard-coded values, so it's okay to set default values for
variables.
6. The Packer template does not contain any AWS credentials.

https://northeastern.instructure.com/courses/192916/assignments/2473742 Page 6 of 7
A 04 10/27/24, 12:57

Infrastructure as Code w/Terraform (50%)

1. terraform apply should create the networking, security group, and EC2 instance with the AMI
built during the demo.
2. terraform destroy should delete all resources created in the above step.
3. Student cannot ssh to the instance to start their application. Test all APIs implemented in
previous assignments, including the health check endpoint.
1. Students cannot run npm install or pip install or any other commands to install
dependencies, as they should have been installed and set up when AMI was built.
4. For this assignment only, students will have database running locally in the EC2 instance.
5. The database port, 3306 for MySQL & MariaDB and 5432 for PostgreSQL should not be included in
the security group. No one can connect to the database from outside the virtual machine.
6. git should not be installed in the AMI. Check for it using the which git command.

https://northeastern.instructure.com/courses/192916/assignments/2473742 Page 7 of 7