DEV Community: Charbel El Kahwaji

Deployment Automation Of A Static Website ⚙️

Charbel El Kahwaji — Wed, 24 Jan 2024 00:09:35 +0000

Static websites used to be very disregarded (and still are) especially when WEB2 took its place in the tech world. When we talk about static websites, we usually mean HTML, CSS, and JS at the core.
Fortunately for static website users, with the rise of serverless concepts, your static websites are more than enough to run a business securely and efficiently. Read more about it on my other blog.

In fact, in this blog, I will be talking about how to automate the deployment of such websites and what AWS services helped me achieve this.

To elevate the development productivity and keep the architecture simple, we developed our website at Zero&One with a library that compiles chunks of code to basic HTML, CSS, and JS. Sergey is a cool static website generator that helped me refactor redundant code chunks into a file and include this specific file in other files.

So why didn't we use React.js or Next.js? As I said, I want to keep the architecture very simple and don't want to include any additional functionality for a static website. So this eliminates Next.js. React is directly out because I want SEO optimization for this project.

In this image, I have an _imports folder where I write my components
and then call them anywhere with the <sergey-import /> tag like so.

I then proceed to run a build command that will build my files in a public folder where the imports will be the actual HTML compiled. You can start a server to preview your changes with the start command. So this public folder is where everything on my website will be, images, scripts, CSS, etc... I can take this folder and manually deploy it to a static web hosting S3 each time I make a change... OR, we can automate this entire procedure!

In your AWS console, go to code pipeline and create a new pipeline.

Name your pipeline, choose a role if you already have one for it, or just let aws code pipeline create one for you. Then choose where you want the artifact to be stored.

Click next and choose your source stage. This means what is the event source that will trigger this pipeline. In my case, I used GitHub and its webhooks. Connect GitHub and then your repos and branches will show. Pick the repo and branch where you would like to create a push event. Now each time you commit and push to this branch in this repository, this pipeline will execute automatically.

Click next. Now comes the fun part, stick with me. In this Build stage, we are going to compile Sergey so it spits out the public folder. Note that the node modules and the public folder generated in your project should be added to .gitignore.

Our build provider is gonna be code build. Choose the region that suits you, then click on create project. A new window will open in CodeBuild. Name and describe your project.
Choose Managed Image and pick Amazon Linux 2.

Pick whatever suits you as options. You can explore additional configurations for your container.

In the Buildspec section choose insert build commands and paste the following code. (You can always go by the buildspec file option if you like)

version: 0.2

phases:
  build:
    commands:
       - npm install&&npm run build
artifacts:
  files:
    - 'public/**/*'

What will happen is that the package.json in your project will run and install Sergey, then execute the build command generating the public folder. Once generated, it will create an artifact by traversing recursively everything inside of the public folder. Remember that our node modules and public folder are not in our repo. Only our none compiled HTML files and package.json

Deploy your project. Choose S3 as your Deploy provider and select your region. Pick the bucket that is configured to host a static website. By reaching this stage the pipeline would have transferred the previously generated artifact to be deployed.

Make sure to click extract file before deploying so we can unzip our artifact, otherwise your files will not be visible to the S3.

Review your changes and create your pipeline.

If you're here now, this is the architecture that you should have built if you followed the steps correctly.

You can configure CloudFront and Route 53 if you want to add more action to your project. And that's it! Congratulations on automating the deployment of your static website! :)

Serverless Technology: Static to Dynamic

Charbel El Kahwaji — Wed, 24 Jan 2024 00:01:09 +0000

In today's fast-paced digital era, companies require websites that have not only an attractive UI but also functionality and dynamism. A static website could be decent at first, but it may become restrictive in no time. This is where serverless technology comes into power.

So what is Serverless? Simply, it's a computing model that operates on the cloud. At its core, servers are operating obviously, but it's called "Serverless" because you do not have to worry about provisioning, maintaining, or giving whatever attention that's required to get a server up and running.

In other terms, you can develop and execute apps without having to arrange or supervise servers. Smooth scaling of the infrastructure is to be expected as this approach will handle big loads of traffic effortlessly.

The AWS architecture illustrated in the image above shows an example of serverless technology that I applied to turn a static website into a dynamic one. It involves integrating Amazon CloudFront, AWS Lambda, and Amazon API Gateway to back up the hosting features on Amazon S3.

Why was this solution required? The website was purely static, and as mentioned previously, it can become extremely limiting. We needed to create a careers page where anonymous users/visitors could apply for jobs. Note that we did not have a Sign-Up/Sign-In feature as it was not a requirement for a commercial static website.

Upon visiting the careers page on our website, Amazon CloudFront receives a request from an unauthenticated user. It will then proceed to serve the HTML, CSS, and JavaScript files from S3 to our user, but this time granting him extra abilities, as we have assigned him a temporary role, allowing him to put objects inside an S3 bucket and execute an API call by invocation. All this via the Amazon Cognito for unauthenticated identities. We need these permissions for steps 2 and 3.

This is how we're now tracking our anonymous users.

The form on our careers page requires the applicant to fill in text inputs for information like name, phone number, email, and a file input to upload their resume. The second the user clicks on submit, step 2 will be initiated, which is to upload the file to a secure and private s3 dedicated to all the resumes, and then retrieve the key of this file on upload success. The anonymous user has been granted the ability to put Objects in the s3 thanks to the role we assigned to him the moment he landed on the page.

After we retrieve the key, we assemble our data in a JSON object and proceed to step 3 where we invoke our lambda expecting this object, through the API gateway, protected by AWS WAF rate-based rule.
The lambda then proceeds to dispatch an email message to the recruitment team via SES, the email contains info about the user, what job he applied to, and the link to his resume.
The link to the resume is through the S3 bucket of the resumes, frontend by another Cloudfront and another Route 53.

Here's a resume: By leveraging this serverless approach, the fully static website became dynamic - and that's just one of many potential applications. The possibilities are unlimited.

here are several advantages that come with utilizing serverless approaches:

Cost reduction through pay-as-you-go
Increased scalability that adjusts automatically to meet demand.
Deployed globally for improved performance with low latency.

So in general, Serverless technology did help transform static sites into dynamic ones all while enhancing their functionality, and performance and remaining cost-effective.

If you're interested in knowing how you can automate the deployment of a static website, you can read more about it here.

Domain Redirection In A Snap 🔃

Charbel El Kahwaji — Tue, 25 Oct 2022 10:08:29 +0000

At our company, we have two domain names, exampleCorp.ae and exampleCorp.me. I was given a task to redirect users based on where they are geographically located when they visit our website.
Both of these domains lead to the same S3 bucket hosting our website which happens to be fronted by CloudFront.
If the users are from the UAE, they must be redirected to exampleCorp.ae. Everyone else around the globe must be redirected to exampleCorp.me.

I found several ways to achieve this. The first thing that might come to mind is Route 53 geolocation which is a very good solution. But what if you don't have Route 53 implemented and just had Cloudfront?

CloudFront Functions And Lambda@Edge:

According to the aws docs: Our CDNs can now perform direct computing! Take a look at Image 1. It's going to be the foundation of all the upcoming logic. This means that our requests can be manipulated on the spot without any middleware or any actual server... Another success story for the serverless concepts 🏆.

Image 1:

Cool, but what do we want to compute or manipulate? What are the inputs we want to give? And what is the difference between these two computing services?

Let's start with the differences:

Image 2:

Lambda@Edge is extremely powerful, but if we can do it with less cost, then why not use Cloudfront functions? At the end of the day, we have a computing system that is going to process our algorithm.

I want to know what the user asked to visit in the request, is it exampleCorp.me or exampleCorp.ae?
I also want to know from which country the request originated.

Amazing so now I have 2 variables, each having 2 relevant options.

Host:

exampleCorp.me
exampleCorp.ae

Country:

UAE
everything else but UAE

Seems like our algorithm is starting to take shape. But how will I pick up these variables?

Go To: Cloudfront > Distributions and select the distribution where your S3 will be the origin.

Click on create behavior.

Set your path pattern. When matched the cache behavior will apply. e.g: /* or /index.html
Select your correct origin.
Scroll down to this section:

Keep the Cache policy as is and in the Origin request policy click on Create policy, do as this image:

Now every time our path pattern is matched, a new header is appended to our request having the country where the request actually originated as value.

All we have to do is intercept the request and write our algorithm!

Go Back to the cache behavior you just created and scroll down to the last section. You should see something like this.

Image 3:

Here we are going to add our function that will redirect the users based on the variables that we now supposedly receive in the request. The function we'll write is going to be triggered by 1 of the 4 CloudFront events. I'll go with Viewer Request.

Duplicate the tab you are in and go to CloudFront functions.

Create a new one, name it, describe it (optional), and click on create. You cannot rename it afterward so watch out.
Now paste this code

function handler(event) {
  console.log("Inside our cloudfront function !!");
  var request = event.request;
  var requestURI = request.uri;
  var referer = request.headers.host.value;
  // this is added thanks to the cache behavior we created
  var country = request.headers["cloudfront-viewer-country"].value;

  if (country === "AE" && !referer.includes("exampleCorp.ae")) {
    /*this condition means that if the country of origin is UAE but the users are trying to access something other than "exampleCorp.ae" */
    console.log("inside 1st condition");
    var redirectResponse = {
      statusCode: 302,
      statusDescription: "Found",
      headers: {
        location: { value: `https://exampleCorp.ae${requestURI}` },
      },
    };
    return redirectResponse;
  } else if (country !== "AE" && referer.includes("exampleCorp.ae")) {
    /*this condition means that if the country of origin is not UAE but the users are trying to access "exampleCorp.ae" */
    console.log("inside 2nd condition");
    var redirectResponse = {
      statusCode: 302,
      statusDescription: "Found",
      headers: {
        location: { value: `https://exampleCorp.me${requestURI}` },
      },
    };
    return redirectResponse;
  } else {
    /*this means that the user has actually the correct request and nothing needs to be modified so we return the initial request */
    return request;
  }
}

check the cloudfront-viewer-country values here

Save the changes made to your function and Publish it. If you don't you won't be able to link it to CloudFront.

Go back to the previous tab and associate the function you just published to the CloudFront event Viewer Request:

Save your changes and you are done! Congratulations!!
You can see your logs in the CloudWatch following these steps.

Feel free to use both for whatever suits your scenario. Just keep in mind that Cloudfront Functions will be triggered on Viewer Request or Viewer Response as for the lambda@edge it supports any of the 4 triggers (look at Image 2).

AWS GuardDuty In A Nutshell 🌰

Charbel El Kahwaji — Tue, 04 Oct 2022 13:56:26 +0000

Introduction:

In this blog, I will be talking briefly about GuardDuty and its importance. This quick overview will help you understand the overall functionality of GuardDuty and will help you answer questions in the AWS Security Specialty Exam.

GuardDuty is an intelligent threat detection service that continuously monitors your AWS accounts, Amazon Elastic Compute Cloud (EC2) instances, Amazon Elastic Kubernetes Service (EKS) clusters, and data stored in Amazon Simple Storage Service (S3) for malicious activity without the use of security software or agents. If potential malicious activity, such as anomalous behavior, credential exfiltration, or command and control infrastructure (C2) communication is detected, GuardDuty generates detailed security findings that can be used for security visibility and assisting in remediation. Additionally, using the Amazon GuardDuty Malware Protection feature helps to detect malicious files on Amazon Elastic Block Store (EBS) volumes attached to an EC2 instance and container workloads.
I took this paragraph straight from the Amazon GuardDuty FAQs which I highly recommend reading as it answers a lot of questions about this service.
As a matter of fact, all of what is stated in this blog are from AWS references that I went through to make it easier to understand and shorten your reading time

How it works:

As mentioned, GuardDuty generates security findings. But how? By using the power of ML and analyzing events such as Amazon CloudTrail event logs, Amazon VPC Flow Logs, and DNS logs based on a threat list.

A threat list (not to be confused with a trust list) is a list of IP addresses that GuardDuty will consider as harmful and generate its findings based on it. Adding IP addresses to a trust list tells GuardDuty not to investigate events generated from this IP and therefore not raise findings from this trusted IP.

GuardDuty Integrates directly with Cloudwatch Events which is extremely helpful when you want to respond to a threat detection rapidly.

The first step to using GuardDuty is to enable it in your account. Once enabled, GuardDuty will
immediately begin to monitor for security threats in the current region.

You can manage GuardDuty findings for other accounts within your organization as a GuardDuty
administrator, you must add member accounts and enable GuardDuty for them as well:

You can invite other AWS accounts to enable GuardDuty and become associated with your account.
Once accepted, the inviting account becomes the master account, and the accounts that accepted the invitation become the member accounts.
One AWS account cannot be both a Master and member account at the same time. One membership invitation can be accepted by One AWS account.
A master account can have up to 1000 members/region

Comparison between users in Master account and users in Member accounts.

Going to the specialty exam you have to know the different actions users in the Master account can do either in their actual account or in the associated members' account. The same goes for users in the member account. Obviously, they can't do anything in the master account

In this Image, I simplified the actions that can be done respectively. Click here if you want to read more about the relationship between the GuardDuty administrator and member account.

Note:
Lists uploaded by the Master account will be imposed on GD functionality in all member accounts. Therefore, findings will be generated based on the threat list of the master account. (I believe the 4th row in the table now makes sense doesn't it ?)

The exam might test you on these actions and is expecting you to know the difference! Good Luck!