Connakers SRE | DevOps | Cloud Journey

Deploy IaC in AWS using CI/CD pipeline

Michael Connaker — Mon, 04 Jul 2022 15:08:29 GMT

Hello and Welcome!

In this article, we will go over how to use CI/CD pipeline to deploy infrastructure into AWS utilizing an IaC.

Overview

As DevOps and SRE engineers, we ideally want to automate the deployment of infrastructure, applications and code. For an SRE Engineer, that is our mantra - automate everything.

This is where Infrastructure as Code comes in. Infrastructure as Code, or IaC, is the process of managing and provisioning data-centers or Cloud infrastructures through machine-readable definition files. Generally, IaC can be used as a source of truth and version controlling.

When it comes to deployment, you have Configuration Management and Orchestration. Configuration Management tools are primarily used to deploy and manage software, but can also be used to deploy infrastructure. Some examples include Ansible, Puppet and Chef.

Orchestration tools are used primarily to provision infrastructure. For orchestration tools, there are native tools for cloud services, such as AWS Cloudformation, Azure Resource Manager, Google Cloud Deployment Manager and open source tools like Terraform or Pulumi.

In this article, we will use A popular IaC open source orchestration tool called Terraform that will be used to generate the infrastructure and implemented directly through a CI/CD. Terraform is a great tool that is used for creating, changing, and versioning infrastructure safely and efficiently.

Terraform uses State Files, which keeps track of resources created by configuration and maps them to real-world resources.

State files must be preserved for later reference, modification, or destruction by subsequent deployments to a durable backend. Backends can be local or remote in something like s3. When working with multiple engineers, it is often a good practice to store it remotely.

Now, as said before as an SRE we want to automate everything. So how do we automate Terraform?

There are several solutions. There are open source tools like Atlantis, but the most efficient way would be through a CI/CD platform.

For this solution, we will use two AWS services to form the foundation of the CI/CD pipeline. For Continuous Delivery, we will use AWS CodePipeline. For Continuous Integration (CI), We will use AWS CodeBuild.

CodePipeline will help us automate our release pipeline through build test and deployment. CodeBuild compiles source code, runs tests, and produces software packages that are ready to deploy.

Architecture

Naturally, when it comes to creating this, there will be several AWS services that we will need to use.

These include:

IAM Roles and Policies
AWS CodePipeline
AWS CodeBuild
S3
DynamoDB Table
Container Registry

Outside of AWS, we will be using Terraform and GitHub.

When we are finished, this is what our infrastructure will look like:

Requirements

Naturally, there are some requirements in order to get started. We will not go over how to do these requirements, but I will list them below.

First, you'll need an AWS account and have your aws config and credentials configured on your local machine.

Second, you will need a Github account.

Third, you will need terraform on your local machine.

Alright, lets get started.

Build out

Our first stop will be in Github. We'll want to create a repository that will store our terraform IaC that will be used to deploy infrastructure to AWS from the Pipeline.

To save some time, here is a Example repository.

let's take a look at the repository. Reviewing main.tf, we see that we'll be deploying vpc's into AWS. Reviewing variables, you will see the CIDR and vpc names.

There are two other significant files - terraform_plan.yml and terraform_apply.yml. These are the buildspec's that will be used to plan and apply infrastructure to AWS using AWS Codebuild. They are required to be in the root directory; however, you can specify a separate subdirectory by using subdirectory/yml file. Without these files, AWS Codebuild will fail.

lastly, let's take a look at our provider.tf. Note that we do not have a backend. This will need to be created.

Let's go ahead and do that now.

Creating Terraform Backend in s3

Like everything else, we want to automate deployment. For this, we will use terraform.

On your local machine, create a main.tf file. In here, we will create a s3 bucket and DynamoDB Table that will be used to store our state file and locks. In aws_s3_bucket resource, replace terraform_state_bucket_name with a name for your bucket. In aws_dynamodb_table resource, replace app-state with an easily identifiable name.

provider "aws" {
    region = "us-east-1"
}

terraform {
    required_providers {
      aws = {
        source   = "hashicorp/aws"
        version  = "~> 3.0"
      }
    }
}

resource "aws_s3_bucket" "terraform_state"{
    bucket      = "terraform_state_bucket_name"

    lifecycle {
      prevent_destroy = true
    }
}

resource "aws_s3_bucket_versioning" "terraform_state" {
    bucket = aws_s3_bucket.terraform_state.id

    versioning_configuration {
      status = "Enabled"
    }
}

resource "aws_dynamodb_table" "terraform_state_lock" {
  name           = "app-state"
  read_capacity  = 1
  write_capacity = 1
  hash_key       = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

now run terraform init, terraform apply. Congrats, you now have a backend s3 for your state file and DynamoDB table for your lock files.

Let's add this to your repository. Go ahead and fork the example repository to your own repository, then clone it to your local machine.

Now, in the provider.tf file, let's update this with our backend information.

terraform {
  backend "s3"{
    bucket          = "terraform_state_bucket_name"
    key             = "terraform.tfstate"
    region          = "us-east-1"
    dynamodb_table  = "app-state"
  }
}

Note our key. A key is a path to the state file inside the S3 Bucket. Here, we call it terraform.tfstate. This does not exist yet, so terraform will create it later on.

Creating our CI/CD Pipeline

Alright. now that we have our backend created, we are ready to move forward with building our pipeline. This can be done two ways - manually through AWS console or through IaC. Naturally as a SRE we want to automate everything.

Once again, we will spec it out using terraform. Again, to save time we do have a repository with the files. Feel free to fork and clone this to your local machine.

Like a good engineer, let's go over what we are exactly building.

Main tf file

A review of main.tf will show that it is pretty busy. Lots of resources and information to digest. Let's dissect this a little to understand better what we're attempting to accomplish.

IAM Roles and Policy

We require an IAM Role for AWS CodePipeline and CodeBuild to use to assume to deploy infrastructure. Secondly, we need a policy that will grant this role some list, Get and Put access to our s3 buckets. Finally, we are giving the Role Power User Access to deploy the infrastructure.

Naturally, you may want to restrict this access further. For example, we could create IAM policies for multiple pipelines designed and restrict those policies to only implement ec2, eks or ecs deployments, or only deploy network infrastructure or to deploy IAM. However, for this project we are using one pipeline and as such, we will use Power User Access.

s3 buckets

Here, we are creating two buckets - one for the Pipeline to store artifacts and one for CodeBuild to store cache files. We are creating a private ACL and enabling versioning.

resource "aws_s3_bucket" "bucket" {
  bucket = "tf-pipeline"
}

resource "aws_s3_bucket_acl" "acl" {
  bucket = aws_s3_bucket.bucket.id
  acl    = "private"
}

resource "aws_s3_bucket_versioning" "versioning" {
  bucket = aws_s3_bucket.bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket" "cb_bucket" {
  bucket = "tf-pipeline-cb"
}

resource "aws_s3_bucket_acl" "cb_acl" {
  bucket = aws_s3_bucket.cb_bucket.id
  acl    = "private"
}

resource "aws_s3_bucket_versioning" "cb_versioning" {
  bucket = aws_s3_bucket.cb_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

CodePipeline

lets break down the CodePipeline and review what it is doing.

First, we need to assign the above IAM role to our CodePipeline. This is done using role_arn = aws_iam_role.role.arn. This will allow CodePipeline to read and write to the s3 buckets.

resource "aws_codepipeline" "codepipeline"{
  name = "terraform-pipeline"
  role_arn = aws_iam_role.role.arn

Next, we need to identify where we are storing our Artifacts. CodePipeline integrates with development tools to check for code changes and then build and deploy through all of the stages of the continuous delivery process. Stages use input and output artifacts that are stored in the Amazon S3 artifact bucket. For the CodePipeline, we will store them in the tf-pipeline bucket. Note further in we use the same input artifact as the output artifact from the source stage.

resource "aws_codepipeline" "codepipeline"{
  name = "terraform-pipeline"
  role_arn = aws_iam_role.role.arn

  artifact_store {
    location = aws_s3_bucket.bucket.bucket
    type     = "S3"
  }

Alright, on to stages. We will be using three stages for the CodePipeline.

Our first stage is our source. Source is where CodePipeline will see changes and implement them. For this, we will use GitHub version 2. To implement version 2, we use aws codestarconnections. We also have a variable for the repository name. This can be updated in the variables.tf.

Note further down that we have a resource that defines the codestarconnection as Github. When this terraform is deployed, you will need to set up the connection manually. We'll go over how to do that later.

  stage {
      name = "Source"

      action {
        name             = "Source"
        category         = "Source"
        owner            = "AWS"
        provider         = "CodeStarSourceConnection"
        version          = "1"
        output_artifacts = ["source_output"]

        configuration = {
          ConnectionArn    = aws_codestarconnections_connection.tf-pipeline.arn
          FullRepositoryId = var.repositoryid
          BranchName       = "main"
        }
      }
    }

The second stage is AWS CodeBuild. In this stage, we have two actions. Our first action will be to use CodeBuild to read the artifact and run the codebuild project that will run Terraform Plan. The second happens after Terraform Plan is ran. Here, we are seeking approval, which is done manually. This action must be approved before the next stage runs.

  stage {

    action {
      name             = "Terraform_Plan"
      category         = "Build"
      owner            = "AWS"
      provider         = "CodeBuild"
      input_artifacts  = ["source_output"]
      output_artifacts = ["tfplan_output"]
      version          = "1"

      configuration    = {
        ProjectName    = aws_codebuild_project.terraform_plan.name
      }
    }

    name = "Terraform_Plan"
    action {
      name             = "Terraform_Plan_Manual_Approval"
      category         = "Approval"
      owner            = "AWS"
      provider         = "Manual"
      version          = "1"
    }

  }

The third stage is also AWS CodeBuild. In this stage, we use CodeBuild to read the artifact and run the codebuild project that will run Terraform Apply.

  stage {
    name = "Terraform_Apply"
    action {
      name             = "Terraform_Apply"
      category         = "Build"
      owner            = "AWS"
      provider         = "CodeBuild"
      input_artifacts  = ["source_output"]
      version          = "1"

      configuration    = {
        ProjectName    = aws_codebuild_project.terraform_apply.name
      }
    }
  }

Finally, we have the CodeBuild projects. There are two of them - one for Terraform Plan and one for Terraform Apply. Both projects are essentially the same, with some minor changes.

Both use the same service role as CodePipeline and both store the cache in the s3 bucket tf-pipeline-cb. Both implement a general1 small container registry that pulls in a yaml file. Both use an environment variable. The key differences here is that one runs a Plan while the other runs Apply.

resource "aws_codebuild_project" "terraform_plan" {
  name         = "Terraform-Plan"
  service_role = aws_iam_role.role.arn

  artifacts {
    type = "CODEPIPELINE"
  }

  environment {
    compute_type    = "BUILD_GENERAL1_SMALL"
    image           = "aws/codebuild/standard:3.0"
    type            = "LINUX_CONTAINER"
    privileged_mode = true
    environment_variable {
      name  = "TF_COMMAND_P"
      value = "plan"
    }
  }
  cache {
    type     = "S3"
    location = "${aws_s3_bucket.cb_bucket.bucket}/terraform_plan/cache"
  }
  source {
    type      = "CODEPIPELINE"
    buildspec = "terraform_plan.yml"
  }
}

resource "aws_codebuild_project" "terraform_apply" {
  name         = "Terraform-Apply"
  service_role = aws_iam_role.role.arn

  artifacts {
    type = "CODEPIPELINE"
  }

  environment {
    compute_type    = "BUILD_GENERAL1_SMALL"
    image           = "aws/codebuild/standard:3.0"
    type            = "LINUX_CONTAINER"
    privileged_mode = true
    environment_variable {
      name  = "TF_COMMAND_A"
      value = "apply"
    }
  }
  cache {
    type     = "S3"
    location = "${aws_s3_bucket.cb_bucket.bucket}/terraform_apply/cache"
  }
  source {
    type      = "CODEPIPELINE"
    buildspec = "terraform_apply.yml"
  }
}

Alright, that was a lot to process. Before we deploy this, we need to make some updates to our pipeline repo.

provider.tf

Before we run Terraform, we will need to update our backend. let's update this with our backend information.

terraform {
  backend "s3"{
    bucket          = "terraform_state_bucket_name"
    key             = "terraform-pipeline.tfstate"
    region          = "us-east-1"
    dynamodb_table  = "app-state"
  }
}

Notice that our key has changed. For the pipeline deployment, we will use a different tf state file over the one used for our example repo. This will keep any changes we make between the two separated and maintainable. If we use the same key, we will cause drift and taint as the example repo and pipeline repo are not together.

Deployment

Alright, we are ready to run Terraform. With the changes made, lets run Terraform. Once deploy, go to AWS console and you should see something like this:

Now, we will need to set up that connection. In AWS, click on Edit. One Source Stage, click edit stage.

Click on connect to GitHub. Give the connection a name and click on Connect to Github. Follow the directions to authorize access and select the Example Repository with the VPC's that we want to deploy.

And that is it. The Pipeline should begin a release and run through the process. Remember that you'll need to manually approve before running the Apply. If it does not automatically run the release, click on Release Change.

Once this has finished running, jump over to the VPC section of your aws console and you should see two new VPC's

Recap

In this article, we deployed a s3 backend and our CI/CD pipeline using Terraform. We connected our Source Stage to GitHub and ran the pipeline to successfully deploy two new VPC's.

Thank you for reviewing my article. Let me know if you have any questions and until next time!

A Cloud Guru Challenge - Improve Application Performance using ElastiCache Redis

Michael Connaker — Sat, 12 Jun 2021 22:29:57 GMT

Hey Guys!

Welcome to my next blog where we are covering another challenge presented by A Cloud Guru. For this challenge, we'll be improving application performance using ElastiCache Redis. The challenge can be found here.

For this challenge, A Cloud Guru has listed out steps that are required to complete the challenge.

They are:

Deploy RDS PostgresSQL database instance
Deploy ec2 instance to run the app. Include python3 and its modules psycopg2, flask, configparser, redis. Add the python application to the server from GitHub.
Deploy ElastiCache Redis
Convert application to use Redis

Github Application: https://github.com/ACloudGuru/elastic-cache-challenge

My GitHub Submission: https://github.com/mconnaker/acg-app-performance-challenge

The Goal: The application itself has been artificially slowed to represent an under-provisioned database server. The goal of this challenge is to add a cache in front of the database, not to optimize the stored procedure.

Alright, let's go ahead and break this down. First, we'll need to deploy the resources in AWS. There are two ways we can do this - manually through the AWS Management Console or through IaC. Next, we'll need to make a few manual changes on the ec2, which include creating a proxy on the server and a folder where the application will reside in. Lastly, after doing initial testing, we'll modify the application to use Redis.

Deployment using Infrastructure as Code

In a nutshell, IaC is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. Using IaC allows your code to be the single source of truth, have version control, traceability/accountability and decreases mistakes made through manual processes. IaC also allows testing, monitoring and reviewing errors that happen when attempting to deploy the code.

For the Big 3 in Cloud Computing (AWS, GCP and Azure), each has its own version of IaC. AWS CloudFormation, Azure ARM Templates and GCP Cloud Deployment Manager. There are also open source deployment tools, such as Terraform, Ansible, Chef and Puppet.

For this challenge I will deploy my infrastructure using IaC utilizing Terraform. For version control, I will use Github. With Terraform, you can use modules or write it from scratch. Modules is a packaged Terraform configuration that makes it easy to deploy.

My personal experience is with Cloud Formation. For the challenge, I decided to write my Terraform code from scratch to better understand how the deployment process works.

The Terraform code I wrote deploys ec2, RDS, ElasticCache Redis, Keypair, VPC, subnet, nacl, route table, Security Groups and key pair. I also deployed .sh install configuration setup for the ec2, which can be done using terraform. The configuration file deploys Python3, the modules, postgresql, nginx, gcc, development tools and git. The file can also be used to clone the github file where the python application resides.

Post Deployment

After deploying the infrastructure using Terraform, a few changes on the ec2 must be done. These are more minor configurations, such as grabbing the repository for the application from GitHub, creating a folder in the home directory and configuring proxy in Nginx.

Pre-Caching

Once the app is running, the elapsed time is always above 5 seconds. This is again due to the fact that the application itself has been artificially slowed to represent an under-provisioned database server

Now that we've done the initial testing, we can add Redis cache to the application.

Caching with ElastiCache Redis

Now that we know the application is working and the slowness is showing, we'll implement ElastiCache Redis to boost the performance. We'll do a cache-aside strategy, where we'll query the cache first to see if the data is there.

In Cache-aside strategy, the application looks to the cache (Redis) first, if no data is found it will query the database and populate the cache with the result.

We'll take a step further and add in an invalidation period using Time to Live (TTL). Invalidation is used when the relevant records are modified in the database, allowing the cache to stay fresh.

To this end, we'll make 3 simple modifications to the application.

First, we'll add in import json, import redis and create a variable called rcache that will have the information to access the ElastiCache Redis.

Second, we'll modify our code existing code. Our first step is to modify a slice of the code. We'll rename def fetch(sql) to def dbfetch(sql).

Finally, we'll add in Redis. the SQL statement is used as a key in Redis, and the cache is examined to see if a value is present. If a value is not present, the SQL statement is used to query the database. The result of the database query is stored in Redis. Finally, we'll use TTL to set how long the key will be stored until it expires. Once it hits the TTL, Redis will evict the key to free the associated memory.

example:

In order to get the SQL statement, we'll need to call on the function, def dbfetch(sql). We'll also use to json serialize and deserialize the results.

Once the app is modified and ran again, we'll see that the time elapse drops from 5 seconds to milliseconds.

And thats it.

Final Thoughts

This challenge was very fun to work with. Coding in general is something I lack experience in, so I am glad I got to learn a few new things with python.

Having built the environment and reviewing it, I find that there are some improvements that could be had for this challenge / project. First is deploying into ECS and taking advantage of Docker containerization. With Docker, we could add Nginx and the application as two separate containers. Second would be using aws Code Pipeline, Deploy or Jenkins and pipeline for CI/CD into the ECS.

Many thanks to A Cloud Guru for presenting this challenge.

AWS Cloud Resume Challenge

Michael Connaker — Sat, 15 May 2021 18:56:06 GMT

AWS Cloud Resume Challenge

website: https://cloudresumechallenge.dev/instructions/

So, I am a little late to the party on the Cloud Resume Challenge. The Cloud Resume Challenge started on April 23, 2020 and had certain requirements and conditions that had to be met.

Those conditions were:

HTML/CSS based website
Hosted in S3 (Static Website)
HTTPS
DNS
JavaScript
Database
API
Python
Infrastructure as Code
Source Control
CI/CD (Frontend / backend)

Why take the challenge

For me, the challenge meant learning more about the components of AWS. While I have worked in AWS fluidly, My core work is in ec2, RDS, iaaC, VPCs, CloudWatch, CloudTrail, Security Groups, and IAM. This meant there were still services that either I do not know or have a bit of working knowledge in, but never done fron scratch - coding in JavaScript and Python, configuring API Gateways, configuring CloudFront, Amazon Certificate Manager, and Lambda Functions.

Completing the Challenge

I completed the challenge by breaking down what was needed. I also skipped over using IaaC in this challenge only because I wanted to learn and understand the services I would be using in the Management Console. I will most likely go back over this and build a proper IaaC and redeploy the API in the static website to point to it later on.

Breaking this down, I needed:

PageCount Counter:

DynamoDB
Lambda Function
API Gateway
Scripts

Website:

HTML/CSS
s3
CloudFront
Amazon Certificate Manager
Domain
DNS

PageCount Counter

DynamoDB

The DynamoDB was a excellent choice for this challenge. It is a key-value and document database, severless and does not require a lot of deep knowledge of querying and database. it is simple in design and easy to create. With DynamoDB, I added two items; the Primary Key with a string value that is looked for in the python script and a second one that is used to update the count.

Scripts

I am not a coder by any stretch of the word, so I'd like to thank Don Cameron who also did this challenge and added his script in his documentation. This helped me tremendously.

Lambda Function

For the Lambda Function, I created one from scratch using Python 3.7. I then applied Don's code to the Lambda Function.

API Gateway

I created a API REST Gateway that was connected to the Lambda Function. The API Gateway was configured with a GET Method and configured with CORS.

Website

HTML / CSS

For this challenge, I used a template CSS with slight modifications to the css code. I additionally, with A slight modification to Don's code, I was able to add the API gateway URL to the script code he had.

s3

I created two s3 buckets - connaker.org and www.connaker.org. I configured the s3 bucket for connaker.org as a static website. www.connaker.org was then configured as a redirect to connaker.org under the static website. connaker.org was updated to be public with a s3 policy to allow public access. Using GitHub Actions, I deployed the website through Github to connaker.org

Domain, Certificate Manager and CloudFront

I own the domain connaker.org. I created a Certificate in Amazon Certificate Manager and added this as a CNAME to the Google Domain's DNS records. After validation, I configured Cloudfront with alternate domain names (CNAMES) *.connaker.org and used the custom SSL Certificate I created in ACM. I added the Origin as the S3 buck's website path (NOT the s3 bucket name) and configured the Behaviors for HTTP and HTTPS. I will update the Behaviors for Redirecting HTTP to HTTPS.

Finally, I added the CNAME record for awsrc.connaker.org to point to the CloudFront Domain Name.

GitHub and GitHub Actions

I deployed a public repo (https://github.com/mconnaker/awsrc) where I configured GitHubActions with a Access Keys and Secret Access Keys of IAM user profile. Any changes made for the frontend (website) on my local machines that are pushed to GitHub are automatically pushed to the s3 bucket.

What was the Hardest Part

The hardest part for me was setting up CloudFront, ACM to work with Google Domains. Turns out, I had most of CloudFront and ACM right, just understanding how to add the CNAME correctly into Google Domains DNS records was confusing.

Which Part did I enjoy?

I enjoyed everything about this. It was fun diving and working on these particular services from scratch.

My Submission

website: https://awsrc.connaker.org
github: https://github.com/mconnaker/awsrc
diagram:

A Cloud Guru - Azure Cloud Resume Challenge!

Michael Connaker — Sat, 15 May 2021 14:35:01 GMT

Hey Guys!

Today's blog is covering a challenge. Yep, presented by A Cloud Guru! In this challenge, you are to build a resume.

Seems simple enough, right? If only...

Lets get started:

A Cloud Guru Presents: "Azure Cloud Resume Challenge of 2021"

The challenge was dropped by none other than Gwyneth Pena-Siguenza over at A Cloud Guru. The challenge required you to create a hundred percent Azure-hosted version of your resume. Part of the requirements is to build it in HTML or CSS, create a JavaScript code with a API that interacts with a database. The website must be hosted in Azure Blob Storage, must have enabled HTTPS and custom domain support and finally, must have Github Actions running.

website: https://acloudguru.com/blog/engineering/cloudguruchallenge-your-resume-in-azure?utm_source=discord&utm_medium=social&utm_campaign=cloudguruchallenge

Why take the challenge

Currently, work in AWS as a consultant and manager service provider at the company I work for. I have little experience with Azure Cloud and felt that this challenge was a great way to build my skills in Azure. I'm also someone that is continuing to learn upon DevOps and scripting skills, so I felt this was a great opportunity to build on those skillsets as well.

Completing the Challenge

Having never worked in Azure, I completed this challenge by first understanding the Azure Environment. I took the AZ-900 Azure Fundementals course in A Cloud Guru and found similiarities between Azure and AWS. I also went ahead and took the certification exam and passed it.

After doing this, I had a basic understanding of the components within Azure.

I started off first by creating myself a Resource Group where all of my services would reside in. Next, I broke down the services I would need to complete the challenge. I broke this down between the backend counter and frontend website.

Backend - Visitcount Counter:

CosmosDB (Serverless, NOSQL database)
Azure Functions (Node.js, LTS 12)
API Gateway
Script (node.js)

Frontend - Website

HTML/CSS
Blob Storage
CDN
Domain
DNS

Backend - Visitcount Counter

CosmosDB

For this challenge, I chose to use CosmosDB. Cosmos DB is a serverless, NOSQL database that is simple to use and easy to configure. The challenge did not require anything overly complex, such as MongoDB, postgresql or MySQL.

CosmosDB does require some understanding on how to be deployed. First, I need to create the CosmosDB Account. This will identify what type of API (Core (SQL), Azure COsmosDB for MOngoDB APi, Cassandra, Azure Table, Gremlin) you will be using, Capacity mode (Provisioned throughput, serverless) and other options.

For API, I used Core SQL and for Capacity mode, I chose Serverless.

After creating the account, you'll needed to create the database. To do this, you'll need to create a Container. At the time of creating the container, you will need to give a name for the database id, container id and partition key.

After creating the container and database, you will need to create a Item within the database.

New Item:

{
    id:"id name",
    count: 0
}

And that is it

Azure Functions

For Azure Functions, I decided to create a very basic script using node.js, LTS 12. Creating a Function is not straight forward and does require some research.

I created the Function within Portal over using Visual Studio Code or CLI. I found working with VSC and CLI was difficult and for this challenge, the visualization with Integration and manual adding/adjusting the Code in Code+Test was easier.

When creating the function, you can give identify the runtime stack and verison. In this case, I used node.js and 12 LTS. This will create the basic function account where your function will live. I used HTTP Trigger and for authorization level, used anonymous.

After creating the function, Inputs and outputs had to be added. To this, I went through the Integration section of my script. I created a Input and output to CosmosDB databse I created earlier.

Scripts

For the script, I used a basic js script to count.

Code Deployed:

module.exports = async function (context, req, data) {
    context.log('JavaScript HTTP Trigger function processed a request.');

    context.bindings.outputDocument = data[0];
    context.bindings.outputDocument.count += 1;

    context.res = {
        body: data[0].count
        };
}

API Gateway

With Azure Functions, there isn't a need to create a API Gateway. In the Code + Test, there is a Get Function URL button. With this URL, we can add it to a main.js script for the frontend to call on the API.

FrontEnd - Website

HTML/CSS

For this challenge, I used a template CSS with slight modifications to the css code

Blob Storage

CDN

Your CDN Endpoints will live in a CDN profile. You will create a new CDN Profile, giving it a name and selecting the pricing tier. During profile creation, you can also create the CDN endpoint with its origin and origin hostname.

After this is created, then it is setting up a custom domain.

Domain, DNS and SSL Certificate

I own the domain connaker.org. With Azure, there isn't a need to do any certificate management as this will be handled by the CDN. Your first step will be to add the endpoint hostname as a CNAME record to the subdomain you wish to use (such as acgarc). Once this is created, you can go to the CDN you created earlier, click on it and add a custom domain. my custom domain is acgarc.connaker.org. Azure DNS should recongize this from the CNAME. After that, you can set it up to allow HTTPS on custom domains, create a CDN managed Certificate using TLS 1.2. Azure CDN will the create a certificate for you.

What was the Hardest Part

The hardest part for this challenge was configuring the Azure Functions. It was difficult as I have no practical experience or knoweldge in creating custom scripts. I also tried to complete the challenge using Visual Studio Code and had a lot of issues. I originally tried using Gwyn's C# code and found it difficult to modify and update to my needs.

Settling on a simple node.js script file was the easier solution. Secondly was using Portal to create the integrations and adding the Code block.

Which Part did I enjoy?

I enjoyed everything about this. It was fun diving and working on these particular services from scratch.

My Submission

website: https://acgarc.connaker.org
github: https://github.com/mconnaker/Azurechallenge
diagram: