Blog Engineering How to deploy a React application to Amazon S3 using GitLab CI/CD
Published on: March 1, 2023
12 min read

How to deploy a React application to Amazon S3 using GitLab CI/CD

Follow this guide to use OpenID Connect to connect to AWS and deploy a React application to Amazon S3.

cover1.jpg

Amazon S3 has a Static Website Hosting feature which allows you to host a static website directly from an S3 bucket. When you host your website on S3, your website content is stored in the S3 bucket and served directly to your users, without the need for additional resources. Combine this with Amazon CloudFront and you will have a cost-effective and scalable solution for hosting static websites – making it a popular choice for single-page applications.

In this post, I will walk you through setting up your Amazon S3 bucket, setting up OpenID Connect (OIDC) in AWS, and deploying your application to your Amazon S3 bucket using a GitLab CI/CD pipeline.

By the end of this post, you will have a CI/CD pipeline built in GitLab that automatically deploys to your Amazon S3 bucket. Let's dive in.

Prerequisites

For this guide you will need the following:

  • Node.js >= 14.0.0 and npm >= 5.6 installed on your system
  • Git installed on your system
  • A GitLab account
  • An AWS account

A previous tutorial demonstrated how to create a new React application, run unit tests as part of the CI process in GitLab, and output the test results and code coverage into the pipeline. This post continues where that project left off, so to follow along you can fork this project or complete the guide in the linked post.

Configure your Amazon S3 bucket

You'll need to configure your Amazon S3 bucket so let's do that first.

Create your bucket

After you log in to your AWS account, search for S3 using the search bar and select the S3 service. This will open the S3 service home page.

Right away, you should see the option to create a bucket. The bucket is where you are going to store your built React application. Click the Create bucket button to continue.

Create S3 bucket

Give your bucket a name, select your region, leave the rest of the settings as default (we’ll come back to these later), and continue by clicking the Create bucket button. When naming your bucket, it’s important to remember that your bucket name must be unique and follow the bucket naming rules. I named mine jw-gl-react.

After creating your bucket, you should be taken to a list of your buckets as shown below.

S3 bucket list

Configure static website hosting

The next step is to configure static website hosting. Open your S3 bucket by clicking into the bucket name. Select the Properties tab and scroll to the bottom to find the static website hosting option.

static hosting button

Click Edit and then enable static website hosting. For the Index and Error document, enter index.html and then click Save changes.

edit static hosting

Set up permissions

Now that you have enabled static website hosting, you need to update your permissions so the public can visit your website. Return to your bucket and select the Permissions tab.

Under Block public access (bucket settings), click Edit and uncheck Block all public access and continue to Save changes.

block public access

Your page should now look this this:

saved blocked public access

Now, you need to edit the Bucket Policy. Click the Edit button in the Bucket Policy section. Paste the following code into your new policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::jw-gl-react/*"
        }
    ]
}

Replace jw-gl-react on the resource property with the name of your bucket and Save changes.

Your bucket should now look like this:

publicly accessible bucket

Manually upload your React application

Now, let’s build your React application and manually publish it to your S3 bucket.

To build the application, make sure your project is cloned to your local machine and run the following command in your terminal inside of your repository directory:

npm run build

This will create a build folder inside of your repository directory.

Inside of your bucket, click the Upload button.

manual bucket upload

Drag the contents of your newly created build folder (not the folder itself) into the upload area. This will upload the contents of your application into your S3 bucket. Make sure to click Upload at the bottom of the page to start the upload.

Now return to your bucket Properties tab and scroll to the bottom to find the URL of your static website.

static website url

Click the link and you should see your built React application open in your browser.

deployed app

Set up OpenID Connect in AWS

To deploy to your S3 Bucket from GitLab, we’re going to use a GitLab CI/CD job to receive temporary credentials from AWS without needing to store secrets. To do this, we’re going to configure OIDC for ID federation between GitLab and AWS. We’ll be following the related GitLab documentation.

Add the identity provider

The first step is going to be adding GitLab as an identity and access management (IAM) OIDC provider in AWS. AWS has instructions located here, but I will walk through it step by step.

Open the IAM console inside of AWS.

iam search

On the left navigation pane, under Access management choose Identity providers and then choose Add provider. For provider type, select OpenID Connect.

For Provider URL, enter the address of your GitLab instance, such as https://gitlab.com or https://gitlab.example.com.

For Audience, enter something that is generic and specific to your application. In my case, I'm going to enter react_s3_gl. To prevent confused deputy attacks, it's best to make this something that is not easy to guess. Take a note of this value, you will use it to set the ID_TOKEN in your .gitlab-ci.yml file.

After entering the Provider URL, click Get thumbprint to verify the server certificate of your IdP. After this, go ahead and choose Add provider to finish up.

Create the permissions policy

After you create the identity provider, you need to create a permissions policy.

From the IAM dashboard, under Access management select Policies and then Create policy. Select the JSON tab and paste the following policy replacing jw-gl-react on the resource line with your bucket name.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::jw-gl-react"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": ["arn:aws:s3:::jw-gl-react/*"]
    }
  ]
}

Select the Next: Tags button, add any tags you want, and then select the Next: Review button. Enter a name for your policy and finish up by creating the policy.

Configure the role

Now it’s time to add the role. From the IAM dashboard, under Access management select Roles and then select Create role. Select Web identity.

In the Web identity section, select the identity provider you created earlier. For the Audience, select the audience you created earlier. Select the Next button to continue.

If you wanted to limit authorization to a specific group, project, branch, or tag, you could create a Custom trust policy instead of a Web identity. Since I will be deleting these resources after the tutorial, I'm going to keep it simple. For a full list of supported filterting types, see the GitLab documentation.

web identity

During the Add permissions step, select the policy you created and select Next to continue. Give your role a name and click Create role.

Open the Role you just created. In the summary section, find the Amazon Resource Name (ARN) and save it somewhere secure. You will use this in your pipeline.

role

Deploy to your Amazon S3 bucket using a GitLab CI/CD pipeline

Inside of your project, create two CI/CD variables. The first variable should be named ROLE_ARN. For the value, paste the ARN of the role you just created. The second variable should be named S3_BUCKET. For the value, paste the name of the S3 bucket you created earlier in this post.

I have chosen to mask my variables for an extra layer of security.

Retrieve your temporary credentials

Inside of your .gitlab-ci.yml file, paste the following code:

.assume_role: &assume_role
    - >
      STS=($(aws sts assume-role-with-web-identity
      --role-arn ${ROLE_ARN}
      --role-session-name "GitLabRunner-${CI_PROJECT_ID}-${CI_PIPELINE_ID}"
      --web-identity-token $ID_TOKEN
      --duration-seconds 3600
      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'
      --output text))
    - export AWS_ACCESS_KEY_ID="${STS[0]}"
    - export AWS_SECRET_ACCESS_KEY="${STS[1]}"
    - export AWS_SESSION_TOKEN="${STS[2]}"

This is going to use the the AWS Security Token Service to generate temporary (3,600 seconds) credentials utilizing the OIDC role you created earlier.

Create the deploy job

Now, let's add a build and deploy job to build your application and deploy it to your S3 bucket.

First, update the stages in your .gitlab-ci.yml file to include a build and deploy stage as shown below:

stages:
  - build
  - test
  - deploy

Next, let's add a job to build your application. Paste the following code in your .gitlab-ci.yml file:

build artifact:
  stage: build
  image: node:latest
  before_script:
    - npm install
  script:
    - npm run build
  artifacts:
    paths:
      - build/
    when: always
  rules:
    - if: '$CI_COMMIT_REF_NAME == "main"'
      when: always

This is going to run npm run build if the change occurs on the main branch and upload the build directory as an artifact to be used during the next step.

Next, let's add a job to actually deploy to your S3 bucket. Paste the following code in your .gitlab-ci.yml file:

deploy s3:
  stage: deploy
  image:
    name: amazon/aws-cli:latest
    entrypoint: 
      - '/usr/bin/env'
  id_tokens:
      ID_TOKEN:
        aud: react_s3_gl
  script:
    - *assume_role
    - aws s3 sync build/ s3://$S3_BUCKET
  rules:
    - if: '$CI_COMMIT_REF_NAME == "main"'
      when: always

This uses YAML anchors to run the assume_role script, and then uses the aws cli to upload your build artifact to the bucket you defined as a variable. This job also only runs if the change occurs on the main branch.

Make sure the aud value matches the value you entered for your audience when you setup the identity provider. In my case, I entered react-s3_gl.

Your complete .gitlab-ci.yml file should look like this:

stages:
  - build
  - test
  - deploy

.assume_role: &assume_role
    - >
      STS=($(aws sts assume-role-with-web-identity
      --role-arn ${ROLE_ARN}
      --role-session-name "GitLabRunner-${CI_PROJECT_ID}-${CI_PIPELINE_ID}"
      --web-identity-token $ID_TOKEN
      --duration-seconds 3600
      --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]'
      --output text))
    - export AWS_ACCESS_KEY_ID="${STS[0]}"
    - export AWS_SECRET_ACCESS_KEY="${STS[1]}"
    - export AWS_SESSION_TOKEN="${STS[2]}"
  
unit test:
  image: node:latest
  stage: test
  before_script:
    - npm install
  script:
    - npm run test:ci
  coverage: /All files[^|]*\|[^|]*\s+([\d\.]+)/
  artifacts:
    paths:
      - coverage/
    when: always
    reports:
      junit:
        - junit.xml

build artifact:
  stage: build
  image: node:latest
  before_script:
    - npm install
  script:
    - npm run build
  artifacts:
    paths:
      - build/
    when: always
  rules:
    - if: '$CI_COMMIT_REF_NAME == "main"'
      when: always


deploy s3:
  stage: deploy
  image:
    name: amazon/aws-cli:latest
    entrypoint: 
      - '/usr/bin/env'
  id_tokens:
      ID_TOKEN:
        aud: react_s3_gl
  script:
    - *assume_role
    - aws s3 sync build/ s3://$S3_BUCKET
  rules:
    - if: '$CI_COMMIT_REF_NAME == "main"'
      when: always

Make a change and test your pipeline

To test your pipeline, inside of App.js, change this line Edit <code>src/App.js</code> and save to reload. to This was deployed from GitLab! and commit your changes to the main branch. The pipeline should kick off and when it finishes successfully you should see your updated application at the URL of your static website.

updated app

You now have a CI/CD pipeline built in GitLab that receives temporary credentials from AWS using OIDC and automatically deploys to your Amazon S3 bucket. To take it a step further, you can secure your application with GitLab's built-in security tools.

All code for this project can be found here.

Cover image by Lucas van Oor on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

Find out which plan works best for your team

Learn about pricing

Learn about what GitLab can do for your team

Talk to an expert