Deploying A Static Website? Choose GitLab For A Better Experience.

--

For flexibility in your content, static websites are preferred. But, when it’s about a static website on a platform like AWS, GitLab is one very helpful tool. This automates the process of deployment. To understand further let’s first know why we need a static website instead of a dynamic website.

Why Do We Need a Static Website?

Companies are using static websites for various reasons.

  1. Static websites are best for their fewer maintenance fees. Users who don’t want to change their pages often can rely on static websites. They are great for web hosting and CMS. Also, you don’t have to hire any developer to develop your site as it can be done quickly with the help of tools like Jekyll and Hugo.
  2. Server-side rendering (SSR) is an application that converts HTML files into fully rendered HTML pages on the server. Static websites use this to update the static content after you have built your site. The formatting guidelines that are applied when constructing your document are specified in the structured application.
  3. Static websites are more efficient than other dynamic websites as they work out everything beforehand due to their content delivery network, optimized design, and caching.
  4. Static websites interplay greatly with CMS to give flexible, scalable, and secure solutions for both the users and the developers.

Benefits of GitLab CI

CI (Continuous Integration) system tools provide developers and DevOps with the necessary capabilities like source control, artifacts structuring, and deployment.

GitLab brings quite a lot of advantages for CI. It helps in stressless installation to advanced automation processes. This tool is a web-based application that promotes ethical coding practices inside the team and secure production deployment.

Smooth Configuration

Installing GitLab CI tools in your container or on any reminders will help you to arrange the process in Kubernetes. This will reduce the amount as you will try to install the tools on cloud platforms and it will be easy to configure the server.

Source code security

The GitLab platform has a fully distributed version control system platform; after all, many CI platforms already have source control built in. GitLab also gives users complete control over access restrictions and code storage location.

Pipeline automation

The Auto DevOps feature in GitLab enables apps to be automatically found, developed, tested, deployed, and monitored using a CI/CD pipeline. Everything that developers are thinking about or are doing with automation is included in the feature.

Steps to deploy a Static website to AWS with GitLab CI

1.Set up S3 Bucket

1.1. Set up S3

1.2. Go to the S3 management console

1.3. Type any name, eg, yourdomainname.com, and the region. Leave the settings page.

1.4. Allow the settings from private viewers into public.

1.5. Move to the properties tab.

1.6. Choose a static website hosting card.

1.7. ✓ the box use this bucket to host a website.

1.8. In the index document field type your root page path+ and add the necessary info in the Error document field.

1.9. Last, permit the S3 bucket for visibility of the website and accessibility to users.

1.10. Go to the permission tab and click the policy of budget.

1.11. Put the following code snippet in the editor.

{

“Version”: “2012–10–17”,

“Statement”: [

{

“Sid”: “PublicReadForGetBucketObjects”,

“Effect”: “Allow”,

“Principal”: “*”,

“Action”: “s3:GetObject”,

“Resource”: “arn:aws:s3:::yourdomainname.com/*”

}

]

}

2. Establishing an IAM User To Upload Files To The S3 Bucket

2.1. Create an IAM user (for accessing and uploading data to the bucket).

2.2. Move to the IAM management console.

2.3. Click the ‘Add user’ to build a new policy with the picked name.

2.4. Next, add the code given below.

2.5. Replace the Resource field with your chosen name (this will let users get the data from your bucket).

{

“Version”: “2012–10–17”,

“Statement”: [

{

“Sid”: “VisualEditor0”,

“Effect”: “Allow”,

“Action”: [

“s3:GetObject”,

“s3:PutObject”,

“s3:DeleteObject”

],

“Resource”: “arn:aws:s3:::yourdomainname.com/*”

},

{

“Sid”: “VisualEditor1”,

“Effect”: “Allow”,

“Action”: “s3:ListBucket”,

“Resource”: “*”

}

]

}

2.6. Create a new user.

2.7. ✓ the programmatic access in the section of access type.

2.8. Allocate newly built policies.

2.9. Last, press Create user.

2.10. Find two important values of variables there, ‘AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

For convenience, you should remember the key or download the .csv file.

3. GitLab CI configuration

Establishing the project’s deployment procedure to the S3 bucket is the next step in Amazon web hosting. This step assumes that GitLab CI is appropriately configured.

3.1. Login into your GitLab account

3.2. Move to the project

3.3. Click on settings and go to CI /CD section.

3.4. Click the button of variables in the drop-down menu.

3.5 Enter the following variables

AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY

AWS_REGION

S3_BUCKET_NAME

CDN_DISTRIBUTION_ID (if not, can get it after the creation of CloudFront distribution)

Use GitLab Runner to tell your GitLab how it should deploy to AWS S3 ( by adding .gitlab-ci. yml to the app’s root directory).

3.6. The steps contain first the use of the image of the latest version for the proper execution of all work as they are read-only templates. The contents include instructions for preparing a docker container

image: docker:latest

services:

– docker:dind

3.7. The next step is to follow the below-mentioned codes to pass the CI/CD process with the given variables.

stages: build, deploy

variables:

# Common

AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID

AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY

AWS_REGION: $AWS_REGION

S3_BUCKET_NAME: $S3_BUCKET_NAME

CDN_DISTRIBUTION_ID: $CDN_DISTRIBUTION_ID

3.8. Then /node_modules content is cached for later use.

cache:

key: $CI_COMMIT_REF_SLUG

paths:

– node_modules/

3.9. The received result data is stored in the folder and kept in the directory for a day.

Build:

stage: build

image: node:11

script:

– yarn install

– yarn build

– yarn export

artifacts:

paths:

– build/

expire_in: 1 day

3.10. For installation of necessary dependencies for the process of deployment use

before_script

Deploy:

stage: deploy

when: manual

before_script:

– apk add –no-cache curl jq python py-pip

– pip install awscli

– eval $(aws ecr get-login –no-include-

3.11. The script parameter helps in changing your S3 bucket and updating CloudFront distribution.

script:

– aws s3 cp build/ s3://$S3_BUCKET_NAME/ –recursive –include “*”

– aws cloudfront create-invalidation –distribution-id $

4. CloudFront Origination

The final goal is important as you distribute your website pages through CloudFront. It helps as the static website shares the cached copy of applications stored in different data centers all over the world. The process includes:

4.1. Navigate to the dashboard of CloudFront.

4.2. Press Create Distribution.

4.3. Type the S3 bucket endpoint in the ‘Origin Domain Name’ field (it must be yours).

With auto-completion, your origin ID will be produced automatically.

4.4. Next, go to the next section and ✓ ‘Redirect HTTP to HTTPS’ option (under the viewer protocol policy section. Thus, you serve websites over SSL.

4.5. Next, type your original Domain Name like www.yourdomainname.com. as you will be having an SSL CloudFront certificate, this your domain name will have .cloudfront.netpapart.

4.6. Outplace your region and then go to Amazon Certification Manager to add the wanted domain name.

4.7. You need to confirm your ownership with the domain name for that go to the setting for DNS and specify your CNAME. When your SSL certificate is produced select “Custom SSL Certificate” in the Distribution Setting option.

In this manner, a fresh CloudFront origin is produced, which is then quickly added to all AWS edge networks. The State field, which shows two states: pending or enabled, can be viewed by going to the dashboard page.

Reach out to our experts and get a consultation regarding GitLab. Visit https://metapercept.com, for more details.

TAGS: #AUTOMATION, #AWS, #CI, #CLOUDPLATFORM, #CMS, #CONFIGURATION, #DYNAMICWEBSITE, #GITLAB, #HTML, #SECURITY, #SERVER, #SOFTWAREDEVELOPMENT, #SSR, #STATICWEBSITE, #USEREXPERIENCE, #WEBSITE, #WEBSITEDEVELOPMENT #TEMPLATEDESIGN #CSS #WORDPRESS #CUSTOMSOFTWAREDEVELOPMENT #SOFTWAREDEVELOPMENTSERVICES #ECOMMERCE #DIGITALPRESENCE #WEBDEVELOPER #WEBSITEBUILDER, CI/CD

--

--

Advanced Technical Writing Group
Advanced Technical Writing Group

Written by Advanced Technical Writing Group

Technical writer sharing skills in the field of API Documentation, Information Architecture, DITA-XML, DocBook, and Open Source based technical publishing.

No responses yet