DEV Community: itTrident Software Services

Deploy Fider as a Private App on AWS with CloudFront VPC Origin

Mohamed Wasim — Wed, 26 Mar 2025 04:49:33 +0000

When architecting solutions on AWS, minimizing the attack surface and ensuring secure deployments is essential. CloudFront VPC Origins provides a way to deliver content from private VPC subnet, reducing direct exposure to the internet. This makes it an ideal choice for those looking to host a private app while securely exposing it to the public internet, offering a more secure alternative to exposing applications from a public subnet.

In this guide, I’ll explain:

What is CloudFront VPC Origin
Why you should deploy Fider as a private application
Create an Internal Application Load Balancer
Create CloudFront VPC origin
Create a CloudFront Distribution
Create Secrets manager secret and Lambda function
Create a Custom Header rule in AWS WAF
Spin up ECS and RDS
Monitor CloudFront and WAF logs
Do You Really Need Zero Trust for Every App
Is CloudFront Truly Zero Trust Compliant
Deciding on Enterprise Grade Deployment for Fider
Caveats to consider
Final thoughts

1. What is CloudFront VPC Origin

Traditionally, when using CloudFront with an origin resource (such as an ALB or EC2 instance), the origin needs to be in a public subnet with a public IP address, implementing Access Control Lists (ACLs) and other controls to restrict access effectively. Users needed to invest ongoing effort to implement and maintain these solutions, resulting in undifferentiated heavy lifting.

However, With CloudFront VPC Origins, users can host their applications in a private VPC, without requiring any direct route to the internet and make sure CloudFront is the only entry point to their applications. When CloudFront VPC Origin is set up as an origin for the CloudFront distribution, traffic stays on the high-throughput AWS Backbone network all the way to your AWS origin, making sure of optimized performance and low latency.

This is designed to prevent end users from discovering or bypassing CloudFront to access web applications directly. By implementing network-level isolation, the origin servers remain hidden on the internet (Obfuscating AWS resources), significantly reducing the attack surface (attack surface reduction) and enhancing the overall security posture. At the same time, users continue to benefit from the CloudFront global scale and high-performance capabilities.

2. Why you should deploy Fider as a private application

Alright, here’s the deal: With this setup, even your ALB can be internal, and it'll route traffic straight to your ECS instances in those private subnets. You heard that right, no public access. This keeps your backend services completely hidden from the internet. User requests go from CloudFront to the VPC origins over a private, secure connection, providing additional security for your applications.

Now, with CloudFront VPC origin, you can stick that ALB in a private subnet where nobody can get to it directly. CloudFront is the only way in, so you can rest easy knowing the attack surface is way smaller. Plus, that ALB? The DNS name only resolves to private IPs, so no internet users can mess with it. By doing so, you significantly reduce the exposure of your internal ALB to DDoS attacks.

Even if someone were to somehow discover your ALB’s ARN (which is very unlikely), they still couldn’t send traffic to it using their own CloudFront distribution. That’s because internal ALBs are only accessible from within the same AWS account and VPC.

And if you’re really serious about security, you can slap on Origin Custom Headers to make sure only your CloudFront distribution is allowed to talk to the ALB. This header verification ensures the traffic legitimacy. But wait, it gets better, those custom headers can be dynamically rotated using AWS Secrets Manager and a Lambda function automation, keeping everything secure without manual intervention.

3. Create an Internal Application Load Balancer

Click on create load balancer, and choose Application Load Balancer

Under Basic Configuration choose Internal as scheme,

Under Network Mapping choose the VPC you created or refer this guide to create a VPC, creating a single public subnet should suffice this time (for placing NAT gateway).

Choose to launch the Application Load Balancer in at least 2 Azs, in private subnets.

Choose the Security group for your internal ALB and create an HTTPS listener,

Navigate to the VPC console and click on the Managed prefix lists, choose pl-b6a144df and map this to your ALB's inbound SG rules(HTTPS), by doing so you are only letting the CloudFront's IP ranges to communicate with your ALB. This is the recommended approach according to AWS Best Practices for DDoS Resiliency.

Under Secure listener settings choose the certificate you created from ACM, if not you can refer this guide and forward to Step 3.

Once you are done with requesting the public certificate in ACM, your certificate will appear in the drop-down select it, scroll down, and click on create load balancer.

The internal ALB is now created with the traffic originating from the CloudFront IP ranges.

4. Create CloudFront VPC origin

Now that you are done with the internal ALB creation, Navigate to the CloudFront service console and choose VPC origins from the navigation pane.

Click on VPC origins and create a VPC origin,

Provide a Name and choose internal ALB's ARN from the Origin ARN drop-down,

Choose the protocol to HTTPS only and click on create VPC origin.

The VPC origin creation is now complete.

5. Create a CloudFront Distribution

Navigate to the CloudFront service console and click on Create a CloudFront distribution,

Under the Origin section, select the VPC origin you created. Enable Origin Shield for an additional layer of caching, and don't forget to add the custom header, name it x-origin-verify.

Under Default cache behaviour choose the following settings, under Allowed HTTP methods choose the third option, if you want to know why then check out this guide for reason.

Under Cache key and origin requests choose Cache policy and origin request policy (recommended). Choose the default cache policy and origin request policy. Under Response headers policy choose CORS-with-preflight-and-SecurityHeadersPolicy, it is an AWS-managed response header policy. Use this policy to specify security-related HTTP response headers that CloudFront adds to HTTP responses that it sends to viewers.

The AWS-managed policy provides the following security headers, it ultimately narrows down to your use case, you can also create a Custom policy and attach it under Response headers policy.

Enable Web Application Firewall for your CloudFront distribution, toggle on use monitor mode you can later disable it once you get know how much of your requests are being blocked by this WAF configuration(False positives and red herrings).

Check SQL protections and Rate limiting(DDoS protection) and take a note of price estimation.

Add the CNAME through which you would like to access your application publicly and choose the custom SSL certificate for your CNAME.

Configure standard logging for your CloudFront distribution to monitor the performance and usage metrics.

The CloudFront distribution creation is now complete.

Navigate to the WAF & Shield console, click on Web ACLs and choose Global(CloudFront) in the region drop-down. Click on the Web ACL and make a note of the rules and WCUs.

6. Create Secrets manager secret and Lambda function

Choose secret type:

Navigate to the Secrets manager service console, and click on Store a new secret.

Under Secret type choose Other type of secret, and provide HEADERVALUE as a Key and paste the same header value you used in the CloudFront distribution. Click on next.

Configure secret:

Choose the secret name and click on next, take a note of Resource permissions step, we will come back to this step once we are done creating the lambda function.

Review:

Skip to the review section leaving behind the configure rotation step, as we will configure that once we create and configure the lambda function.

The secret creation is now complete.

Create a rotator lambda function:

Navigate to the lambda console and click on Create function,

Choose Author from scratch and choose Python 3.9 as runtime with architecture as x86_64. Under Execution role choose create a new role, this creates a new service role for the function.

Under Additional Configurations enable tags and VPC, i am placing lambda function inside VPC to enable VPC flow logs to monitor network traffic, which is critical for auditing and incident response. Before moving onto choosing the security group create a new one in the EC2 console and then revert back here.

Since this rotator Lambda function will be triggered by Secrets Manager, it won't be needing any inbound rules, as it's event-driven. It still needs one outbound rule, to reach out to the Secrets manager endpoint via HTTPS protocol, as the traffic (for HTTPS) will be routed through public internet via a NAT-gateway.

Now, reference the created SG under the lambda's configuration parameters drop-down and click on Create function.

The rotator-lambda function is now created.

Configuration parameters - rotator lambda function:

Use the python code https://gist.github.com/WasimTTY/ff092402d09c56f6496b359036e42aa0 from this gist to deploy the code onto the lambda function.

This code was modified to work with the CloudFront WAF configuration.

Once pasted, click on deploy to deploy the code to the lambda function. Additionally, this code does come with an external dependency, so create a lambda layer and attach it to the rotator-lambda function.

You can find the artifact in this repository: https://github.com/aws-samples/amazon-cloudfront-waf-secretsmanager/tree/master/artifacts

Now, under the Configuration tab choose the Timeout for the rotator-lambda function, i have set it to 5 mins 3 sec with the memory and the Ephemeral storage left to defaults.

Take a note of the Existing role attached to the lambda function. we will be needing it attach the policies to let the lambda function interact with the CloudFront distribution and WAF for rotating the secret-custom-header.

Navigate to the IAM console and under Roles tab search for the service role created by the rotator-lambda function.

Create an inline policy for accessing the CloudFront distribution. I’ve provided only the permissions necessary for the service to function. This policy grants the rotator Lambda function the minimal privileges required to modify the Secret-Custom-Header on the CloudFront distribution.

  {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "cloudfront:GetDistribution",
                "cloudfront:UpdateDistribution",
                "cloudfront:GetDistributionConfig"
            ],
            "Resource": "arn:aws:cloudfront::<AWS ACCOUNT ID>:distribution/E3R3ZKP77W4214",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::<AWS ACCOUNT ID>:role/service-role/header-rotate-function-role-tinh6qnu"
                }
            }
        }
    ]
}

I’ve applied the same approach for the Secrets Manager, CloudFront WAF, and Lambda VPC policies as well, granting only the minimal permissions required for each service.

  {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "secretsmanager:DescribeSecret",
                "secretsmanager:PutSecretValue",
                "secretsmanager:UpdateSecretVersionStage"
            ],
            "Resource": "arn:aws:secretsmanager:us-east-2:<AWS ACCOUNT ID>:secret:Custom-Header-lQWRrQ",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::<AWS ACCOUNT ID>:role/service-role/header-rotate-function-role-tinh6qnu"
                }
            }
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "secretsmanager:GetRandomPassword",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::<AWS ACCOUNT ID>:role/service-role/header-rotate-function-role-tinh6qnu"
                }
            }
        }
    ]
}

  {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:CreateNetworkInterface",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DeleteNetworkInterface",
                "ec2:UnassignPrivateIpAddresses",
                "ec2:DescribeSubnets",
                "ec2:AssignPrivateIpAddresses"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::<AWS ACCOUNT ID>:role/service-role/header-rotate-function-role-tinh6qnu"
                }
            }
        }
    ]
}

  {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "wafv2:UpdateWebACL",
                "wafv2:GetWebACL"
            ],
            "Resource": [
                "arn:aws:wafv2:*:<AWS ACCOUNT ID>:*/regexpatternset/*/*",
                "arn:aws:wafv2:*:<AWS ACCOUNT ID>:*/managedruleset/*/*",
                "arn:aws:wafv2:*:<AWS ACCOUNT ID>:*/rulegroup/*/*",
                "arn:aws:wafv2:us-east-1:<AWS ACCOUNT ID>:global/webacl/CreatedByCloudFront-4ffb490d-8e92-419b-a38b-017361fd80aa/a2512452-7f08-4591-bf1a-fec1923ac75a",
                "arn:aws:wafv2:*:<AWS ACCOUNT ID>:*/ipset/*/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::<AWS ACCOUNT ID>:role/service-role/header-rotate-function-role-tinh6qnu"
                }
            }
        }
    ]
}

The IAM policies crafted above are identity-based policies scoped down to a specific IAM role using a PrincipalArn condition, enforcing least privilege.

The rotator-lambda function also needs a resource-based policy in order for the Secrets manager to invoke the function. I have used AWS CLI to add this policy to the lambda function.

  aws lambda add-permission \
  --function-name secret-header-rotator-function \
  --statement-id AllowSecretsManagerInvoke \
  --action lambda:InvokeFunction \
  --principal secretsmanager.amazonaws.com \
  --source-account <AWS ACCOUNT ID> \
  --source-arn arn:aws:secretsmanager:us-east-2:<AWS ACCOUNT ID>:secret:Custom-Header-lQWRrQ

The resultant policy will look like this,

  {
  "Version": "2012-10-17",
  "Id": "default",
  "Statement": [
    {
      "Sid": "AllowSecretsManagerInvoke",
      "Effect": "Allow",
      "Principal": {
        "Service": "secretsmanager.amazonaws.com"
      },
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:us-east-2:<AWS ACCOUNT ID>:function:secret-header-rotator-function",
      "Condition": {
        "StringEquals": {
          "AWS:SourceAccount": "<AWS ACCOUNT ID>"
         },
        "ArnLike": {
          "AWS:SourceArn": "arn:aws:secretsmanager:us-east-2:<AWS ACCOUNT ID>:secret:Custom-Header-lQWRrQ"
        }
      }
    }
  ]
}

The resource-based policy above follows the Zero Trust principle by minimizing trust, ensuring access is explicitly verified through conditions like Source Account and Source ARN before granting permissions.

Configure secrets manager - resource policy:

Now, navigate to the Secrets manager service console and under the Resource permissions paste the resource-based policy for invoking the rotator-lambda function.

  {
  "Version" : "2012-10-17",
  "Statement" : [ {
    "Sid" : "AllowLambdaAccess",
    "Effect" : "Allow",
    "Principal" : {
      "AWS" : "arn:aws:iam::<AWS ACCOUNT ID>:role/service-role/header-rotate-function-role-tinh6qnu"
    },
    "Action" : [ "secretsmanager:GetSecretValue", "secretsmanager:PutSecretValue", "secretsmanager:UpdateSecretVersionStage", "secretsmanager:DescribeSecret" ],
    "Resource" : "arn:aws:secretsmanager:us-east-2:<AWS ACCOUNT ID>:secret:Custom-Header-lQWRrQ",
    "Condition" : {
      "StringEquals" : {
        "aws:ResourceTag/Environment" : "production",
        "aws:SourceAccount" : "<AWS ACCOUNT ID>",
        "aws:SourceArn" : "arn:aws:lambda:us-east-2:<AWS ACCOUNT ID>:function:secret-header-rotator-function"
      }
    }
  } ]
}

This policy also aligns with the Zero Trust principle, Even though the request is coming from the rotator-lambda function (which could be considered a trusted service), the policy does not allow access by default. It enforces strict conditions including ABAC (Attribute Based Access Control) using resource tags to validate the request’s origin and ensure the caller is explicitly authorized.

Taking this approach tightens security by enforcing stringent, context-aware access controls.

7. Create a Custom Header rule in AWS WAF

Navigate to the WAF & Shield service console and look-up for Web ACLs created under the Global(CloudFront).

Create a new rule named XOriginVerify, and configure the same secret-custom-header value that was set in the CloudFront distribution and the Secrets manager.

The rotator-lambda function looks Explicitly for this rule name as it is hard-coded in the python code. You can modify it according to your use case.

Once the rotator-lambda function updates the secret-custom-header in both the CloudFront distribution and in WAF, it tests the secret by pinging your domain-name, in this case the request has to propagate through the CloudFront, and WAF will let the request through only if that header matches, it should result in 200 OK. You have to check CloudWatch logs for this.

8. Spin up ECS and RDS

You can refer to this guide for spinning up the ECS and RDS infrastructure.

9. Monitor CloudFront and WAF logs

Monitoring CloudFront and AWS WAF logs is a crucial part of incident response in any secure AWS setup, especially when you're running a public-facing app.

You need visibility into what’s happening at your edge and app layers. That’s where CloudFront and AWS WAF logs come in.

In the AWS management console under the region drop-down choose us-east-1, this is where CloudFront delivers logs to in the CloudWatch log-group.

Each log contains information such as the time the request was received, the processing time, request paths,client-IP and server responses. You can use these access logs to analyze response times and to troubleshoot issues.

When you're absolutely done observing the false positives for WAF rules, navigate to the WAF console and adjust the actions for the rules according to your use case. You can choose whether to set actions such as Allow, Block, Captcha, or Count based on your specific needs. It ultimately narrows down to your requirements and the level of protection you wish to enforce.

It’s important to note that when you set a rule group action to 'Count,' it will override any Allow, Block, or Captcha actions that were originally specified for the rules within that group. As a result, all rules in the group will only count matching requests, regardless of their original action.

By default, the action is set to 'Count' during testing and monitoring of the rule group’s behavior, which allows you to observe how the rules perform before deploying them to production.

AWS WAF now supports sending logs to CloudWatch logs, Hover over to the Logging and metrics tab and click on Enable drop-down and choose Logging destination.

Choose the CloudWatch logs log group as destination and click on save,

Logging is now enabled for AWS WAF.

Hover over to the Sampled requests tab to help you analyze how your AWS WAF rules are evaluating traffic. Each sampled request shows details like the IP address, headers, URI, country, and rule evaluation outcome. Sampled requests are free.

In addition to this, you can also use the default queries provided by WAF to query the number of requests that come from an IP address. Under the Cloudwatch logs insight tab in the WAF console.

10. Do You Really Need Zero Trust for Every App

Before slapping on Zero Trust policies like they’re the new fad, take a step back and do the threat modelling first.

That’s the only way to know whether Zero Trust is even the right fit for your app.

Threat modelling is like a security audit before you go shopping for locks and alarms. It forces you to ask:

What exactly are you protecting ?
Who would want to break in ?
How might they try to do it ?

That last part? That’s basically recon and attackers do it all the time. They scan your public IPs, poke at your APIs, look for leaky S3 buckets or overly permissive roles. So when you threat model, you're doing a defensive version of recon: identifying what an attacker might see and how they'd try to exploit it.

Threat modeling helps you spot risks like this, Once you know that, you can set up your Zero Trust stuff, like least privilege access, network segmentation, and strong authentication all tailored to the actual threats, not just random paranoia.

Even something as focused as the rotator Lambda function, which runs every 4 hours to manage the secret header, carries real risk. Its footprint may be small, but its role is critical. In cloud environments, even well-scoped serverless functions can become attack vectors if misconfigured or exposed.

This strict posture isn't just theoretical. Tools like AWSRedirector demonstrates how serverless components can be exploited in real-world attacks . That's why we lock down even the smallest moving parts.

Without threat modeling, you’d be like, ‘Oh, I’ll just block everything!’ but that’s like building a fortress with no doors. You gotta know who’s allowed in, and under what conditions. That’s how Zero Trust works it’s not about ‘trust no one’ for the sake of it, it’s about verifying every request based on real risks. You should understand the balance between security and usability.

If you’re curious about how AWS approaches Zero Trust in detail, you can check out their Zero Trust Security Model and AWS Zero Trust Architecture principles.

11. Is CloudFront Truly Zero Trust Compliant

Zero Trust architectures are identity-centric, requiring per-request authentication and authorization before traffic reaches the application. Using CloudFront means your application is publicly addressable on the internet, even if access is restricted with WAF, signed URLs, or custom headers. This introduces a public entry point, contrary to Zero Trust principles of default deny and private access.

CloudFront does not support integration with IAM Identity Center, Azure AD, Okta, or other identity providers (IdPs) to enforce access control. While it offers IP-level and path-level access logs, it lacks identity-based audit trails, making per-user auditing and continuous trust evaluation impossible. Additionally, it does not inspect or enforce device posture or context, meaning it cannot verify whether requests originate from secure, approved environments.

If you're looking to implement true Zero Trust at the edge, Cloudflare and Akamai (EAA) offer the most complete solutions today. Others like Fastly are catching up, but platforms like AWS CloudFront, Azure Front Door, and Google Cloud CDN still fall short of Zero Trust standards.

12. Deciding on Enterprise Grade Deployment for Fider

Fider is just a feedback platform, and most of what it contains are suggestions and feedback. We don’t store any sensitive Personally Identifiable Information (PII) like Social Security Numbers or financial data. Even in the event of a compromise, the risk is minimal, typically limited to names and email addresses. However, if you're using Fider internally within your organization, the risk could be higher, as internal feedback may include more sensitive or proprietary information

Given Fider’s risk profile, a Lambda-based secret header rotator backed by Secrets Manager offers a strong security baseline. This level of protection is more than sufficient if you’re using Fider to collect public feedback and suggestions without overengineering.

AWS Verified Access is indeed the right choice if you’re planning to host everything within AWS and require enterprise-level security controls. But, it’s generally overkill unless you have tighter access control policies in your enterprise setup, and costs more. You are also charged per GB for data processed by Verified Access. You can calculate the estimated cost here AWS Verified Access Pricing. It functions more as an access control solution than as traditional VPN tunnels. It only works with AWS hosted systems.

If you are curious about this setup then you can check this out https://pages.nist.gov/zero-trust-architecture/VolumeC/HowTo-E4B5.html

Cloudflare Zero Trust is the sweet spot and comes out as the better choice when considering both cost and performance. It supports edge services, DNS, and mTLS out of the box, providing enhanced security, performance, and seamless encryption with Cloudflare’s global network.You can check out its pricing here.

13. Caveats to consider

VPC Endpoints:

You can still choose to go with VPC interface endpoints (Powered by AWS PrivateLink) if you haven't integrated external OAuth providers (like Google, GitHub, etc.) because these services are not available via AWS PrivateLink.

When you configure OAuth providers with Fider, the authentication requests go to the OAuth provider's endpoints over the internet. This involves external APIs that cannot be routed through VPC Interface Endpoints directly, since these OAuth services are external to your AWS infrastructure and not hosted within your VPC or private AWS environment.

It will also cost you more than the NAT gateway, you can checkout this post from the official AWS forum for even more clarification. Only choose this method if you consider security as paramount.

⚠️ Network Isolation ≠ Identity Validation:

Using a VPC origin does make the app private, but it does not guarantee identity-based access control. CloudFront doesn't authenticate requesters the way solutions like Cloudflare Zero Trust do, leaving the application vulnerable without proper identity verification.

14. Final thoughts

Let’s be real no system is made of adamantium. Given enough time, resources, or misconfigurations, even the most locked-down architecture can be poked at. But this setup doesn’t aim for invincibility, it aims to minimize exposure, limit blast radius, and make exploitation significantly harder and riskier.

This architecture trades convenience for control, reducing your attack surface, slowing down adversaries, and giving you time and telemetry to respond.

Deploying Fider on AWS ECS: A Step-by-Step Guide to Deploy a Feedback Platform

Mohamed Wasim — Tue, 05 Nov 2024 12:12:17 +0000

This guide provides detailed instructions for deploying Fider on AWS ECS, with tasks running inside a private subnet and an internet-facing Application Load Balancer (ALB) set up as a custom origin for CloudFront(Cloudfront + WAF).

This is a detailed article, so buckle up! Since this setup closely mimics a production deployment and let’s be real, deploying Fider on AWS isn’t an easy feat, you’ll want to follow along carefully.

AWS services used

Elastic container registry(ECR)
Elastic container service(ECS Fargate launch type)
Application Load Balancer(ALB)
Relational Database Service(RDS)
Systems Manager Parameter Store
Simple Storage Service(S3)
Simple Email Service(SES)
Cloudfront(CDN)
Web Application Firewall(WAF)
Key Management Service(KMS)
Amazon Certificate Manager (ACM)

What is Fider ?
Fider's Tech Stack
Pre-flight Checks
Install AWS CLI
Push the Docker Images to ECR
Create a VPC
Create Subnet Group for RDS
Create an RDS PostgreSQL DB
Create Parameters in Systems Manager Parameter Store
Create an IAM User
Create an S3 Bucket
Create an Identity in SES
Why Use ECS Instead of EC2
Create an ECS Cluster
Create Task Definition
Create an ECS Service
Create CloudFront Distribution with WAF

What is Fider ?

Okay, okay, so, listen up! Fider is like this thing where people can go and, like, share their opinions on stuff, right? Imagine you’ve got a big ol' bag of potato chips don’t ask me why I’m talking about chips, it just seems right and you wanna know what everyone thinks about the flavor. Fider’s the place where people can give feedback on stuff like that, but, you know, for real stuff like websites and apps.

So, you go there, type up your thoughts, and boom other people can vote on whether they agree or disagree, like they're choosing between watching Family Guy or some other dumb show. But here’s the kicker, Fider lets people actually vote and prioritize the feedback they care about!

So, yeah, that’s Fider. Kinda like a big opinion poll but with a lot more techy stuff behind it. And you can totally use it for, you know, not chips...

You can checkout the Fider's official page for more details: https://fider.io/

This guide focuses on deploying Fider on AWS, but you can also self-host it on other platforms like Heroku, Azure, or your own servers. For more details, check out the official Fider self-hosting documentation.

Fider's Tech Stack

Backend: Go (Golang), with custom HTTP handling.
Frontend: React, using SCSS(Sassy CSS) for styling.
Database: PostgreSQL.
Authentication: OAuth 2.0.
Background Jobs: Go routines.
Cloud Storage and Email Integration: S3 for blob storage and SES for email notifications.

Pre-flight checks

Before starting, ensure that you have an AWS account with access to the free tier or a valid payment method on file.

Install AWS CLI

Step 1:

You need the awscli package installed for pushing the images built locally to Elastic Container Registry(ECR).

Step 2:

If you use ubuntu distro, Check the snap version by using the following command.

  snap version

Run the following snap install command for the AWS CLI.

  sudo snap install aws-cli --classic

After the installation is complete, verify the installation by using the command,

  aws --version

With Snap package you always get the latest version of AWS CLI as snap packages automatically refresh.

For command line installer check out the documentation: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

Step 4: Configure AWS CLI

Use this command to configure the AWS CLI.

  aws configure

Once configured, verify your AWS CLI credentials using the following command.

  aws configure list

Step 5: Pull official docker images from DockerHub

Pull the official docker image for Fider from the DockerHub registry at: https://hub.docker.com/r/getfider/fider/tags

Use the docker pull command to pull the image from the DockerHub.

  docker pull getfider/fider:main

Check if the docker image is available in your instance.

  docker images

Push the Docker images to ECR

Step 1: Visit the ECR console

Create a public or private repository based on your use case by clicking on the create repository prompt in the top right corner.

Name the repo getfider/fider

Check if the repository is created.

Step 2: View the push commands

View the push commands by clicking on the respective repository.

Use the AWS CLI to retrieve an authentication token and authenticate your Docker client to your registry.

tag your pulled image so you can push the image to this repository.

Run the following command to push this image to your newly created AWS repository.

The docker images should now be available in the repository you created.

Create a VPC

Step 1: Create a standalone VPC for deploying Fider application

Create VPC only for now, you can create public and private subnets manually and can attach these subnets to particular route tables.

A route table will also get created with route to local traffic.

Step 2: Create an Internet gateway

Create an IGW and attach it to the VPC you created.

The IGW is now attached to the VPC.

Associate the IGW with the route table by clicking on edit routes.

By clicking on Add route attach the the IGW to the route table.

The route table now has a route to the IGW, which means the subnets associated with this route table can have Internet access.

Step 3: Create Public Subnets

Create at least two public subnets, so that the Application Load Balancer can reside in it.

Navigate to the VPC Console, under the subnets section create two public subnets.

Decide the subnet CIDR range and provision it accordingly.

Associate the public subnets to the public route table where the IGW is also attached.

Step 4: Create Private Subnets

Create at least two private subnets, so that your ECS tasks and RDS can reside in it.

Navigate to the VPC Console, under the subnets section create at least two private subnets.

Under the actions dropdown choose Edit subnet settings and uncheck the Enable auto-assign public IPv4 address.

Step 5: Create a Private route table

Create a private route table in the VPC console under the route tables section to route traffic locally.

Associate the private subnets to the private route table, like how you did with the public route table, and follow the same steps.

Step 6: Create an Elastic-ip

Allocate an elastic-ip address and attach it with the NAT gateway.

Click on Allocate Elastic IP address

From public ipv4 address pool, choose Amazon's pool of ipv4 address and click Allocate

You should now be able to check the static Elastic IP allocated to you. It can now be attached to the NAT gateway.

Step 7: Create NAT gateway

Create a NAT gateway to allow tasks in the private subnet to connect to the internet.

Navigate to NAT gateway section under the VPC console and create a NAT gateway.

Associate it with a public subnet and also associate an Elastic IP address to it.

Set the connectivity type to public.

Attach the NAT gateway to the private route table that has three private subnets associated with it.

The private route table now has a route to the NAT gateway.

Your VPC lineage should now look like this.

Create Subnet group for RDS

Navigate to the RDS sevice console and click on subnet groups,

Click on create DB subnet group

Fill out the subnet group details and add subnets and choose the availability zones(azs) accordingly(private subnets).

If you choose to launch multi-AZ DB clusters, you must select 3 subnets in three different availability zones.

Click on create,your subnet group will now be available in the subnet groups dashboard.

Create an RDS PostreSQL DB

Navigate to the RDS service console from the management console and click on DB instance, to create an RDS DB instance.

Click on create database

Choose standard create and choose PostgreSQL as engine type.

Choose the latest PostgreSQL engine version and for this guide i choose to go with single DB instance under the availability and durability section.

Under credential settings provide postgres as master user name and choose self managed to use your custom password for authenticating with RDS.

For this guide, I chose to go with Burstable classes, depending on your use case you can fine tune the DB instance class. Storage will be left as default, unless you choose to customise it.

Under connectivity section, choose the VPC that you created(fider-vpc) and the subnet group you created previously would appear under the DB subnet group section.

Choose NO under public access section.

Now, before proceeding to VPC security group section, navigate to VPC console and create a security group for both RDS and ECS.

The above sg rules are for ECS service.

The above sg rule is for RDS and it has no outbound rules set.

Now back to the RDS console where we left,

Choose the security group you created and choose the availability zone where you would want to host the DB instance.

Set database authentication as password based, I have disabled monitoring you can enable it if you want.

Create the initial database as fider in the DB instance.

I chose to go with the above settings, you can enable it if you want.

Click on create database to provision an RDS PostgrSQL DB.

The RDS PostgreSQL DB is now available!

Create Parameters in Systems manager Parameter Store

Since Fider currently does not appear to have built-in logic specifically to fetch credentials or secrets from AWS Secrets Manager, I have used parameter store to store Fider's environment variables so the tasks in ECS can fetch these credentials when they are being fired up.

Fider supports the above environment variables. I have used the standard tier and secureString type to encrypt sensitive data using KMS keys.

Create an IAM user

Fider supports the use of Amazon S3 for blob storage and Amazon SES for sending emails. However, simply passing the access keys through environment variables will not automatically make the images appear in the S3 bucket, nor will it enable SES for email sending.

The application will assume the role assigned to the user, which will then allow it to perform actions on the user's behalf.

Navigate to the IAM console and create a user and assign the roles necessary for accessing the S3 bucket and SES service,

I've granted full access to S3 and SES for this guide, but this isn't the recommended approach. Instead, you should create fine-grained access policies and assign them to the role.

Create an S3 bucket

Navigate to the S3 bucket console and create a general purpose S3 bucket for blob storage.

Once you've created the bucket, navigate to the Permissions tab and check the Bucket Policy section. It’s likely empty, right? Well, it shouldn’t be, if left empty the S3 bucket will remain empty forever.

  {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<ACCOUNT_ID>:user/<USER_NAME>"
            },
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::<BUCKET_NAME>"
        }
    ]
}

This policy is too permissive; you can create more fine-grained policies to restrict access.

Create an identity in SES

The application requires email verification as part of the signup process to prevent spam and ensure only valid users access the platform. I chose the SES API route instead of SMTP.

Navigate to the SES service console and start creating an identity.

I chose to go with domain verification. Once you've created the identity via the domain, make sure to validate the records with your DNS provider.

You can send a test mail from the verified identities to the check the workflow.

If you plan to run this setup in production, you can request production access from Amazon support. Otherwise, you can remain in the sandbox environment.

Why use ECS instead of EC2

There is one major reason to use ECS instead of EC2,

1. Reduced Operational Overhead:

EC2 is cheaper on paper, but that requires careful capacity management and container resource planning plus reserved instance commitments or spot fleet configurations. In the end it feels like 99% of the time, the admin overhead doesn't outweigh the savings.

Depends on how much control you want. If you want less control, go with Fargate. And yes, if you go with standard ECS, the EC2 instances are run and managed by you.

Create an ECS cluster

Step 1:

Navigate to the ECS console and create an ECS cluster with Fargate launch type.

Click on Create cluster.

I have turned on container insights for this guide, to see aggregated metrics at cluster and service level. In this way you can run the deep dive analysis.

This will create an ECS cluster via Cloudformation in the backend.

Create Task Definition

Step 1:

Navigate to the task definition section under the ECS console and create a task definition named fider-app-task-definition.

The task definition can be created via both the console and JSON.

Refer to the following JSON task definition for creating the task definition via JSON.

  {
    "taskDefinitionArn": "arn:aws:ecs:us-east-2:624184658995:task-definition/fider-app-task-definition:7",
    "containerDefinitions": [
        {
            "name": "fider-app",
            "image": "624184658995.dkr.ecr.us-east-2.amazonaws.com/getfider/fider:main",
            "cpu": 2048,
            "memory": 8192,
            "memoryReservation": 4096,
            "portMappings": [
                {
                    "name": "fider-app-3000-tcp",
                    "containerPort": 3000,
                    "hostPort": 3000,
                    "protocol": "tcp",
                    "appProtocol": "http"
                }
            ],
            "essential": true,
            "environment": [],
            "mountPoints": [],
            "volumesFrom": [],
            "secrets": [
                {
                    "name": "BASE_URL",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/BASE_URL"
                },
                {
                    "name": "DATABASE_URL",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/DATABASE_URL"
                },
                {
                    "name": "JWT_SECRET",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/JWT_SECRET"
                },
                {
                    "name": "GO_ENV",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/GO_ENV"
                },
                {
                    "name": "EMAIL_NOREPLY",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/EMAIL_NOREPLY"
                },
                {
                    "name": "EMAIL_AWSSES_ACCESS_KEY_ID",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/EMAIL_AWSSES_ACCESS_KEY_ID"
                },
                {
                    "name": "EMAIL_AWSSES_SECRET_ACCESS_KEY",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/EMAIL_AWSSES_SECRET_ACCESS_KEY"
                },
                {
                    "name": "EMAIL_AWSSES_REGION",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/EMAIL_AWSSES_REGION"
                },
                {
                    "name": "BLOB_STORAGE",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/BLOB_STORAGE"
                },
                {
                    "name": "BLOB_STORAGE_S3_ACCESS_KEY_ID",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/BLOB_STORAGE_S3_ACCESS_KEY_ID"
                },
                {
                    "name": "BLOB_STORAGE_S3_BUCKET",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/BLOB_STORAGE_S3_BUCKET"
                },
                {
                    "name": "BLOB_STORAGE_S3_ENDPOINT_URL",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/BLOB_STORAGE_S3_ENDPOINT_URL"
                },
                {
                    "name": "BLOB_STORAGE_S3_REGION",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/BLOB_STORAGE_S3_REGION"
                },
                {
                    "name": "BLOB_STORAGE_S3_SECRET_ACCESS_KEY",
                    "valueFrom": "arn:aws:ssm:us-east-2:624184658995:parameter/BLOB_STORAGE_S3_SECRET_ACCESS_KEY"
                }
            ],
            "logConfiguration": {
                "logDriver": "awslogs",
                "options": {
                    "awslogs-group": "/ecs/fider-app-task",
                    "mode": "non-blocking",
                    "awslogs-create-group": "true",
                    "max-buffer-size": "25m",
                    "awslogs-region": "us-east-2",
                    "awslogs-stream-prefix": "ecs"
                },
                "secretOptions": []
            },
            "systemControls": []
        }
    ],
    "family": "fider-app-task-definition",
    "taskRoleArn": "arn:aws:iam::624184658995:role/ecsTaskExecutionRole",
    "executionRoleArn": "arn:aws:iam::624184658995:role/ecsTaskExecutionRole",
    "networkMode": "awsvpc",
    "revision": 7,
    "volumes": [],
    "status": "ACTIVE",
    "requiresAttributes": [
        {
            "name": "ecs.capability.execution-role-awslogs"
        },
        {
            "name": "com.amazonaws.ecs.capability.ecr-auth"
        },
        {
            "name": "com.amazonaws.ecs.capability.docker-remote-api.1.28"
        },
        {
            "name": "com.amazonaws.ecs.capability.docker-remote-api.1.21"
        },
        {
            "name": "com.amazonaws.ecs.capability.task-iam-role"
        },
        {
            "name": "ecs.capability.execution-role-ecr-pull"
        },
        {
            "name": "ecs.capability.secrets.ssm.environment-variables"
        },
        {
            "name": "com.amazonaws.ecs.capability.docker-remote-api.1.18"
        },
        {
            "name": "ecs.capability.task-eni"
        },
        {
            "name": "com.amazonaws.ecs.capability.docker-remote-api.1.29"
        },
        {
            "name": "com.amazonaws.ecs.capability.logging-driver.awslogs"
        },
        {
            "name": "com.amazonaws.ecs.capability.docker-remote-api.1.19"
        }
    ],
    "placementConstraints": [],
    "compatibilities": [
        "EC2",
        "FARGATE"
    ],
    "requiresCompatibilities": [
        "FARGATE"
    ],
    "cpu": "2048",
    "memory": "8192",
    "runtimePlatform": {
        "cpuArchitecture": "X86_64",
        "operatingSystemFamily": "LINUX"
    },
    "registeredAt": "2025-02-18T06:06:55.123Z",
    "registeredBy": "arn:aws:sts::624184658995:assumed-role/AWSReservedSSO_AdministratorAccess_263ab8d7ae88c1c4/wasim",
    "tags": []
}

I have referenced the environment variables created in systems manager parameter store by their resource arn.

You also need the following policies to be attached to ecsTaskExecutionRole along with AmazonECSTaskExecutionRolePolicy,

AmazonSSMFullAccess
ROSAKMSProviderPolicy

The policies attached provides the ECS agent the required permissions to fetch the KMS encrypted environment variables from the systems manager parameter store, decrypt it and provide it to the application hosted inside the ECS tasks.

I have provided full access permission policies, but it's usually not the right way to do it. You can craft the fine grained access policies and attach the same to the ecsTaskExecutionRole.

Create an ECS service

Step 1:

Navigate to the ECS cluster you created and click on it, once inside the cluster click on service.

Step 2: Configuration parameters

In the compute configuration choose the capacity provider strategy and choose FARGATE as capacity provider with base 1 and weight as 100

Choose service as the application type in the deployment configuration and Replica as the service type with Desired tasks set to 1. You can also set it 2, I have used one for this guide.

In the networking configuration choose the VPC you created.

Turn off the public IP address as the tasks will use NAT gateway.

Configure the Application load balancer and place it inside the public subnet as front-facing for your application.

Create a target group on the fly in the ECS console itself and set up an HTTPS listener for your ALB. For this deployment, I’ve chosen to handle the HTTP to HTTPS redirect at the CDN level, so you don’t need an HTTP listener for your ALB, as redirects won’t happen at that level.

For the SSL certificate to appear in the dropdown, skip to step 3 from here and request a public certificate from the ACM console.

The health check path for Fider is _/health

I have not enabled service auto scaling for this guide, you can enable it if you want.

Click on create in the end and navigate to Cloudformation to view the status.

The password authentication with RDS PostgreSQL is successful and the records got migrated!

Since we have also enabled container insights, we can check the performance metrics of clusters, services and tasks.

Note: If you are not able to run the tasks or if you ran into errors like this,

It's because you placed the task in the public subnet with no public IP assigned to it, when you created the application load balancer in the ECS service console itself. Even i ran into this issue and then i had to troubleshoot the failed tasks.

I used the Systems Manager's AWSSupport-TroubleshootECSTaskFailedToStart automation document. It diagnosed the issue for me.

Note: Create the application load balancer and target group separately, note the availability zones(AZs) you assinged for ALB, and when you spin up the ECS tasks via service make sure you provide the private subnets from the same availability zones(AZs).

Feel free to check this documentation when you run into issues!

Step 3: Use ACM for SSL certificates

The service is up and running now.

Navigate to the ACM console and click on request a certificate.

Request a public certificate and click on Next.

Provide your domain name and choose the DNS validation method.

Click on request and ACM provides you with the DNS records, verify the records by mapping them to your DNS registrar settings.

Your SSL certificate is now ready to be used with the Application Load Balancer. You can map it under the Listener configuration for the ALB in the certificate section of the ECS service console.

Since I’m setting up CloudFront, I’ve also chosen to enable WAF at the CDN level for this deployment, as CloudFront acts as the first point of contact and can filter traffic before it reaches the ALB.

Since WAF is enabled at the CloudFront level and all traffic originates from there, you don’t need to enable WAF at the ALB level. Instead, I’ve added an X-Custom-Header to restrict access to the Application Load Balancer (ALB), ensuring that only requests from CloudFront are allowed.

Create Cloudfront distribution with WAF

Navigate to the integrations tab under the application load balancer

Click on manage cloudfront + WAF integration.

click on the check box to enable the cloudfront IPs as inbound to your application load balancer.

create an SSL/TLS certificate for your domain, from which you would like to host Fider on. Cloudfront only accepts SSL/TLS certificates from us-east-1(N.virginia) region.

Once you click create, WAF rules and Cloudfront distribution will get enabled for your ALB.

Now,navigate to the Cloudfront distribution and click on the behaviours tab to edit the settings of default cache behaviour,

I chose to handle the HTTP to HTTPS redirect at this level.

Since Fider is a dynamic application, Features like submitting feedback, voting, and commenting are processed in real-time, and the application relies on a database to store and manage user data dynamically. So set the Allowed HTTP methods to GET,HEAD,OPTIONS,PUT,POST,PATCH,DELETE . If not you won't be able to perform PUT operation if you choose from first two.

Save it and now hover over to the origins tab and choose to edit the ALB origin settings.

Set the protocol to HTTPS only, I choose to let Cloudfront talk to my ALB over HTTPS and scroll further down,

Add the Custom header which you added in the previous step with ALB, Cloudfront passes this header in every request it makes to the ALB. Hitting the ALB DNS without this header would result in 403 forbidden error.

This is how your ALB resource map should look. It will only forward traffic to the target group if the string you configured in CloudFront is present in the request header.

Next, map the distribution domain to the domain where you want to host Fider in your DNS records(CNAME record). Don't hit the distribution domain name it will only result in 502 error.

Hit the domain name you configured in the DNS entry, You should be able to see the landing page.

The images you upload to the webiste will get stored as an object in the S3 bucket, and when you access it from the browser via UI. you should be able to see this in the network tab under response headers (X-cache: Hit from Cloudfront)

You can navigate to the AWS WAF in the console and look for the request metrics.

You can also configure the managed rules in the WAF console under the Rules tab.

Viola! There you have it. Fider's up and running with the tasks securely inside their own private subnet, and the ALB routing requests to them. Additionally, with CloudFront and AWS WAF configured, traffic is efficiently delivered via the CDN while being protected at the edge, ensuring secure and optimized access.

Deploying Node-Red on Azure Container Instance

Manjula Rajamani — Thu, 05 Sep 2024 12:30:38 +0000

This guide provides instructions for deploying the Node-Red application on the Azure platform, utilizing Azure Container Instances, Azure Container Registry, and Azure Storage Account.

What is Azure Container Instance?
Azure Container Instances (ACI) is a managed service that allows you to run containers directly on the Microsoft Azure public cloud, without requiring the use of virtual machines (VMs)

For more information about Azure Container Instances, check out the official documentation at this link: Azure Container Instances Documentation.

What is Azure Container Registry?
Azure Container Registry is a private registry service for building, storing, and managing container images and related artifacts

For more information about Azure Container Registry, check out the official documentation at this link: Azure Container Registry Documentation.

What is an Azure Storage account?
The Azure Storage platform is Microsoft's cloud storage solution for modern data storage scenarios. Azure Storage offers highly available, massively scalable, durable, and secure storage for a variety of data objects in the cloud. Azure Storage data objects are accessible from anywhere in the world over HTTP or HTTPS via a REST API.

For more information about the Azure Storage account, check out the official documentation at this link: Azure Storage account Documentation.

Startup:
Before starting, ensure that you have an Azure account with an active subscription

Step 1:
Login into your Azure account



az login

Step 2:

Create a container registry and store the Node-RED image in the container registry
As of Node-RED 1.0, the repository on Docker Hub was renamed to nodered/node-red.
Log in to a registry using Azure CLI



az acr login --name myregistry
docker login myregistry.azurecr.io

If you are unfamiliar with creating an Azure Container Registry (ACR), you can refer to the following link for step-by-step instructions using the Azure portal: Get Started with Azure Container Registry

Step 3:

Create an Azure file share:
Run the following script to create a storage account to host the file share, and the share itself. The storage account name must be globally unique, so the script adds a random value to the base string.



# Change these parameters as needed
RESOURCE_GROUP=myResourceGroup
STORAGE_ACCOUNT_NAME=storageaccount$RANDOM
LOCATION=eastus
FILE_SHARE_NAME=node-red-share
IMAGE=testingregistrydevops.azurecr.io/node-red:latest
ACI_NAME=node-red

# Create the storage account with the parameters
az storage account create \
    --resource-group $RESOURCE_GROUP \
    --name $STORAGE_ACCOUNT_NAME \
    --location $LOCATION \
    --sku Standard_LRS

# Create the file share
az storage share-rm create \
    --resource-group $RESOURCE_GROUP \
    --storage-account $STORAGE_ACCOUNT_NAME \
    --name $FILE_SHARE_NAME \
    --quota 1024 \
    --enabled-protocols SMB \
    --output table

Step 4:

Get storage credentials:
To mount an Azure file share as a volume in Azure Container Instances, you need three values: the storage account name, the share name, and the storage access key.

Storage account name - If you used the preceding script, the storage account name was stored in the $STORAGE_ACCOUNT_NAME variable. To see the account name, type:



echo $STORAGE_ACCOUNT_NAME

Share name- This value is already known (defined as node-red-share in the preceding script). To see the file share name



echo $FILE_SHARE_NAME

Storage account key - This value can be found using the following command:



STORAGE_KEY=$(az storage account keys list --resource-group $RESOURCE_GROUP --account-name $STORAGE_ACCOUNT_NAME --query "[0].value" --output tsv)
echo $STORAGE_KEY

Step 5:

Deploy container and mount volume - CLI:
To mount an Azure file share as a volume in a container by using the Azure CLI, specify the share and volume mount point when you create the container with az container create. If you followed the previous steps, you can mount the share you created earlier by using the following command to create a container:



az container create \
        --resource-group $RESOURCE_GROUP \
        --name $ACI_NAME \
        --image $IMAGE \
        --dns-name-label unique-acidemo-label \
        --ports 1880 \
        --azure-file-volume-account-name $STORAGE_ACCOUNT_NAME \
        --azure-file-volume-account-key $STORAGE_ACCOUNT_KEY \
        --azure-file-volume-share-name $FILE_SHARE_NAME \
        --azure-file-volume-mount-path /aci/logs/

The --dns-name-label value must be unique within the Azure region where you create the container instance

Using Bash
You can combine the above commands and execute the bash script to create an Azure Container Instance for Node-RED.
Here is the bash script for Node-RED



#!/usr/bin/env bash

RESOURCE_GROUP=MyResourceGroup
STORAGE_ACCOUNT_NAME=storageaccount$RANDOM
LOCATION=eastus
FILE_SHARE_NAME=node-red-share
IMAGE=testingregistrydevops.azurecr.io/node-red:latest
ACI_NAME=node-red

# Function to handle errors
handle_error() {
    echo "Error: $1" >&2
    exit 1
}

# Azure Login
az login || handle_error "Failed to login to Azure"

# ACR Login
az acr login --name testingregistrydevops.azurecr.io || handle_error "Failed to login to ACR"

# Check if Resource Group exists
if az group show --name $RESOURCE_GROUP &>/dev/null; then
    echo "Resource group '$RESOURCE_GROUP' already exists."
else
    # Creating Resource Group
    az group create --name $RESOURCE_GROUP --location $LOCATION || handle_error "Failed to create resource group"
    echo "Resource group '$RESOURCE_GROUP' created."
fi

# Check if the Storage Account exists
if az storage account show --name $STORAGE_ACCOUNT_NAME --resource-group $RESOURCE_GROUP &>/dev/null; then
    echo "Storage account '$STORAGE_ACCOUNT_NAME' already exists."
else
    # Creating Storage Account
    az storage account create \
        --resource-group $RESOURCE_GROUP \
        --name $STORAGE_ACCOUNT_NAME \
        --location $LOCATION \
        --sku Standard_LRS || handle_error "Failed to create storage account"
    echo "Storage account '$STORAGE_ACCOUNT_NAME' created."
fi

# Creating File Share
echo "Creating file share '$FILE_SHARE_NAME'..."
if az storage share-rm create \
    --resource-group $RESOURCE_GROUP \
    --storage-account $STORAGE_ACCOUNT_NAME \
    --name $FILE_SHARE_NAME \
    --quota 1024 \
    --enabled-protocols SMB \
    --output table &>/dev/null; then
    echo "File share '$FILE_SHARE_NAME' created successfully."
else
    handle_error "Failed to create file share '$FILE_SHARE_NAME'"
fi

# Fetch Storage Account Key
STORAGE_ACCOUNT_KEY=$(az storage account keys list --resource-group $RESOURCE_GROUP --account-name $STORAGE_ACCOUNT_NAME --query "[0].value" --output tsv)
echo $STORAGE_ACCOUNT_KEY

# Creating Azure Container Instance for Node-Red
if az container show --resource-group $RESOURCE_GROUP --name $ACI_NAME &>/dev/null; then
    echo "Azure Container Instance '$ACI_NAME' already exists."
else
    # Creating Azure Container Instance for Node-Red
    az container create \
        --resource-group $RESOURCE_GROUP \
        --name $ACI_NAME \
        --image $IMAGE \
        --dns-name-label unique-acidemo-label \
        --ports 1880 \
        --azure-file-volume-account-name $STORAGE_ACCOUNT_NAME \
        --azure-file-volume-account-key $STORAGE_ACCOUNT_KEY \
        --azure-file-volume-share-name $FILE_SHARE_NAME \
        --azure-file-volume-mount-path /aci/logs/ || handle_error "Failed to create container instance"

    echo "Azure Container Instance '$ACI_NAME' created."
fi

After executing the file, you can make the application accessible using the public IP or Fully Qualified Domain Name (FQDN) of the Azure Container Instance.

Additionally, you can verify whether the file share is properly mounted using Azure Container Instances (ACI)

Comprehensive Guide to Integrating SonarCloud with GitHub Projects

Niresh Prabu A — Tue, 13 Aug 2024 12:31:02 +0000

This blog post exemplifies how to integrate SonarCloud with GitHub to enhance code quality and security in your projects.

Sonarcloud

SonarCloud is a Software-as-a-Service (SaaS) code analysis tool designed to detect coding issues in 30+ languages, frameworks, and IaC platforms. By integrating directly with your CI pipeline or one of the supported DevOps platforms, your code is checked against an extensive set of rules that cover many attributes of code, such as maintainability, reliability, and security issues, on each merge/pull request.

Why SonarCloud Integration with GitHub is Essential for Your Projects

Integrating SonarCloud with GitHub is essential for maintaining high code quality and security in your projects. By automatically analyzing your code with every commit, SonarCloud identifies issues like bugs, code smells, and vulnerabilities early in the development process. This integration helps ensure that only clean, reliable code gets merged, reducing technical debt and preventing potential security risks. Ultimately, it fosters a culture of continuous improvement and accountability, leading to more robust and maintainable software

Prerequisites

Before integrating SonarCloud with your GitHub projects, there are a couple of prerequisites to ensure a smooth setup process:

Admin Access to the GitHub Repository:
- You must have administrative access to the GitHub repository you wish to integrate with SonarCloud. This access is necessary to configure repository settings, add secrets, and link the repository with SonarCloud.
SonarCloud Account Setup:
- You need to have a SonarCloud account to proceed. If you don't have one, you can easily set it up by signing in with your GitHub account. This method simplifies the process by directly linking your GitHub repositories to SonarCloud, making it easier to manage projects and streamline the integration process. Visit SonarCloud and choose the "Sign in with GitHub" option to create your account and get started.

Step-by-Step Guide: GitHub Integration with SonarCloud
a. Linking SonarCloud with GitHub

Sign in to SonarCloud: Go to SonarCloud and sign in using your GitHub account.
Create a new organization: Navigate to the "My Organizations" tab and create a new organization linked to your GitHub account.

Import your GitHub repository: After creating the organization, select "Analyze new project" and choose the GitHub repository you want to integrate with SonarCloud.

b. Generating and Adding Sonar Token in GitHub Secrets

Generate a Sonar Token:
- In SonarCloud, go to your account settings and generate a new token under "Security".
- Copy the token to a secure location.

Add Sonar Token to GitHub Secrets:
- In your GitHub repository, navigate to Settings > Secrets and variables > Actions.
- Click on New repository secret and name it SONAR_TOKEN.
- Paste the Sonar token generated earlier into the value field and save it.

4. CI/CD Pipeline Integration
a. Setting Up the CI/CD Pipeline:

Modify Your YAML File: In your repository, create or modify the .github/workflows/deployment.yml file to include SonarCloud analysis steps. Include this sonarcloud code scan step in the deployment yaml file.

Example configuration:

  SonarCloudSCan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
            fetch-depth: 0
      - name: SonarCloud Scan
        uses: sonarsource/sonarcloud-github-action@master
        env:
            GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
            SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        with:
          args: >
              -Dsonar.organization=<your-organization-name>
              -Dsonar.projectKey=<your-project-key>
              -Dsonar.qualitygate.wait=true
              -X

5. Ensuring Code Quality Before Deployment

To ensure that your deployment only occurs when your code passes all quality checks, it's essential to add dependencies to your deployment step. This will prevent deployment if the code check fails, thereby maintaining the integrity and security of your application.

In your CI/CD pipeline configuration (.yml file), include the following step to make sure the deployment only happens after the SonarCloud scan are successful:

Deploy:
  needs: 
    - SonarCloudScan

jobs:
  SonarCloudSCan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
            fetch-depth: 0
      - name: SonarCloud Scan
        uses: sonarsource/sonarcloud-github-action@master
        env:
            GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
            SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        with:
          args: >
              -Dsonar.organization=tridentsqa
              -Dsonar.projectKey=TridentSQA_pmo-api
              -Dsonar.qualitygate.wait=true
              -X

   Deploy:
    needs: 
      - SonarCloudSCan
    name: deploy the new image in ECS
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: configure aws credentials
        uses: aws-actions/configure-aws-credentials@v1

 # Remaining deployment steps...........
....................................

6. Project Code Scan and Issue Resolution

After successfully integrating SonarCloud with your GitHub repository and setting up the CI/CD pipeline, your project's code will be automatically scanned by SonarCloud with every commit or pull request.

a. Viewing the Scan Results:

Access the SonarCloud Dashboard: From your dashboard, select the project that has been integrated with GitHub.
Review the Analysis Overview: The dashboard provides an overview of the code quality, including metrics like code coverage, bugs, vulnerabilities, and code smells.

Examine Detailed Reports: Click on specific issues to view detailed descriptions, including the lines of code affected and suggestions for fixing them.

b. Resolving Issues:

Prioritize Critical Issues: Start by addressing bugs and security vulnerabilities, as these can impact the stability and security of your application.
Follow SonarCloud's Recommendations: Each issue identified by SonarCloud comes with a recommended solution. Implement these fixes in your codebase.
Re-run the Analysis: After resolving issues, push your changes to GitHub. The CI/CD pipeline will trigger a new SonarCloud scan, and the updated results will be reflected in the dashboard.
Ensure Quality Gates are Passed: Quality gates are thresholds set in SonarCloud to enforce code quality standards. Make sure your project passes these gates before considering the work complete.

Adding support for stateful applications deployed on GCP Cloud Run via Filestore

Selvakumar — Wed, 04 Oct 2023 09:53:40 +0000

Introduction:

While Cloud Run offers the undeniable advantages of a serverless and stateless environment, it's important to recognize that it primarily caters to stateless applications. However, there may be instances where the need arises to deploy a stateful application which mandates a storage medium (logs, media assets, and such) within the Cloud Run environment. If you find yourself facing this very scenario, fear not, for this blog post will serve as your comprehensive guide, walking you through the process step by step.

How exactly are we going to do this, you ask? By leveraging a tf module I authored, of course!

A lil' pretext as to why I even came about with the idea to write this was when the only other way I saw around making stateful applications seamlessly work with Cloud Run was to make direct changes (google libs, sdk, etc.) to the codebase in effect, which would unequivocally alter the very substance of the application to render it working ONLY and EXCLUSIVELY on Google Cloud.

No more meddling around with the code, all thanks to this module, all of the apps volume needs are taken care of within the confinement of the Cloud Run service itself!

Prerequisite:

An account with Google Cloud with administrative access or permissions for the essential components constituting the following services - Cloud Run, VPC, API services, Filestore, and Artifact Hub.

Getting Started:

Step 1: Enable APIs

Initially, you must activate the necessary APIs:
- Cloud Filestore API
- Cloud Run API
- Serverless VPC Access API
Navigate to the "APIs & Services" section, proceed to the "Library" section, and search for the specified APIs mentioned above. Afterward, enable them as needed.

Step 2: Create Serverless VPC connector

To connect to your Filestore instance, your Cloud Run service needs access to the Filestore instance's authorized VPC network.
Every VPC connector requires its own /28 subnet to place connector instances in. Do note that this IP range must not overlap with any existing IP address reservations in your VPC network
Goto to Serverless VPC access, afterware, click CREATE CONNECTOR, fill the required field

Step 3: Filestore

Navigate to the "Filestore" section.
Click CREATE INSTANCE to create the new filestore.
Fill the required field and click Create.
Upon it being created, you'll have the "NFS mount point" displayed

Step 4: Build Docker Image

Once you've completed the preceding configuration steps, the next task involves adding the following line to your Dockerfile's ENTRYPOINT or CMD:

mount -o nolock FILESTORE_IP_ADDRESS:/FILE_SHARE_NAME MNT_DIR

Here's what each argument of this command denotes:

FILESTORE_IP_ADDRESS:/FILE_SHARE_NAME: You should obtain this value from step #3 labeled "NFS mount point"

MNT_DIR: You must specify the target directory where you intend to mount the Filestore.

 FROM ubuntu:latest
 WORKDIR /data
 # If you use entrypoint
 ENTRYPOINT ["mount -o nolock FILESTORE_IP_ADDRESS:/FILE_SHARE_NAME /data", "&&", "npm" , "start"]
 # If you use CMD
 CMD mount -o nolock FILESTORE_IP_ADDRESS:/FILE_SHARE_NAME /data && npm start

Subsequently, proceed to build your Docker image and push it to the Artifact Hub.

Step 4: Deploy that Image to Cloud Run

Navigate to "Cloud Run"
Click on the "Create Service" button.
Service Configuration:
- Select the container image you pushed earlier.
- GGive the service a name of your choosing and fill the rest of the information.
Container Configuration:
- Give the container a port number to start serving on
- Execution environment : Choose " Second generation"
- Fill the other things.
Network Configuration:
- Select " Connect to a VPC for outbound traffic"
- Choose "Use Serverless VPC Access connectors" from the list, next, choose the serverless VPC connector that you have created in Step #2.
Finally, Click "CREATE".

A no-brainer way to smoke test if the filestore crate is actually mounted, do the following:

Launch a VM (GCE) in the same network as Filestore and SSH into it
Install the nfs utility (I'm demo'ing this on Debian: sudo apt install nfs-common)
Create an example directory, i.e; nfs? filestore?
Mount the example directory as a volume in the filesystem.

mount -o nolock FILESTORE_IP_ADDRESS:/FILE_SHARE_NAME <example-directory>
df -h to check if the share is mounted, cd into the <example-dir>, mv files you'd want accessed by the container; later, and as soon as your app begins writing data, you'll naturally find it inside the <example-dir> along with the rest.

A Step-by-Step Guide to Deploying an Application on AWS App Runner with GitHub Action workflow

Rajeshwar R — Wed, 31 May 2023 17:11:07 +0000

Privacy-Protect

Share passwords and sensitive files over email or store them in insecure locations like cloud drives using nothing more than desktop or mobile web browsers like chrome and safari.

No special software. No need to create an account. It's free, open-source, keeps your private data a secret, and leave you alone.

App Runner

AWS App Runner is a fully managed container application service that lets you build, deploy, and run containerized web application and API services without prior infrastructure or container experience.

Cons of App Runner

Lack of EFS Mount Support:

The absence of support for mounting the Elastic File System (EFS). Instead, AWS offers an alternative solution with DynamoDB for handling data storage. The lack of EFS mount support might be a challenge for certain use cases:Limited File Storage Flexibility, Potential Performance Impact, Additional Configuration Complexity. However, by leveraging AWS's alternative storage solution, DynamoDB, developers can work around this limitation and continue to build scalable applications.

Go through this Architecture diagram.

᛫ Create a IAM role

This role is used by AWS App runner to access AWS ECR docker images.

The following are the step-by-step instructions to create a service role and associating AWSAppRunnerServicePolicyForECRAccess policy.

step 1
Create a role named with app-runner-service-role



{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "build.apprunner.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

step 2

Attach the AWSAppRunnerServicePolicyForECRAccess existing policy to the role app-runner-service-role.

Here the steps to deploy Privacy-Protect application in App Runner using GitHub Action

᛫ Create a AWS ECR private repostiory

᛫ Clone the repository



git clone https://github.com/r4jeshwar/privacy-protect.git
cd privacy-protect

᛫ Migrate from Server deployment(Vercel-@sveltejs/adapter-vercel) to static site generator(@sveltejs/adapter-static)

First, Install npm i -D @sveltejs/adapter-static

Go to the svelte.config.js file delete the existing content and paste the below content in svelte.config.js file.



import adapter from "@sveltejs/adapter-static";
import { vitePreprocess } from "@sveltejs/kit/vite";
import { mdsvex } from "mdsvex";
import { resolve } from "path";

/** @type {import('@sveltejs/kit').Config} */
export default {
  extensions: [".md", ".svelte"],
  kit: {
    adapter: adapter({
       pages: 'build',
       assets: 'build',
      fallback: null,
      precompress: false,
      strict: true
    }),
    alias: {
      $components: resolve("src/components"),
      $icons: resolve("src/assets/icons"),
    },
    csp: {
      directives: {
        "base-uri": ["none"],
        "default-src": ["self"],
        "frame-ancestors": ["none"],
        "img-src": ["self", "data:"],
        "object-src": ["none"],
        // See https://github.com/sveltejs/svelte/issues/6662
        "style-src": ["self", "unsafe-inline"],
        "upgrade-insecure-requests": true,
        "worker-src": ["none"],
      },
      mode: "auto",
    },
  },
  preprocess: [
    mdsvex({
      extensions: [".md"],
      layout: {
        blog: "src/routes/blog/post.svelte",
      },
    }),
    vitePreprocess(),
  ],
};

Note: This changes is to deploy in various infrastructure and to dockerize in small size. If you need to deploy in vercel ignore this.

Why we need to switch out the adapter from vercel to static ?

Adapter-Static allows deploying Vite.js application to various static hosting providers.It also simplifies the deployment process by eliminating the need for serverless infrastructure and configuration specific to Vercel.

Overall, migrating from Adapter-Vercel to Adapter-Static empowers you with greater flexibility, simplicity.

᛫ Dockerfile for privacy-protect to deploy in App Runner



FROM node:18-alpine as build

WORKDIR /app

COPY . .

RUN npm i
RUN npm run build


FROM nginx:stable-alpine

COPY --from=build /app/build/ /usr/share/nginx/html

Push the changes to your repository to be picked up by the GH workflow we'll be setting up next

᛫ Configure the GitHub Action secrets

Go to your project repository, Go to settings in the security section click the Secrets and variables drop down and click Actions. Configure the variables.

AWS_ACCESS_KEY_ID is your AWS user access key.
AWS_SECRET_ACCESS_KEY is your AWS user secret key.
AWS_REGION is the region of AWS services where you creating.
ROLE_ARN is your IAM role ARN which you have created before which you named app-runner-service-role

᛫ Configure the new workflow in GitHub Action

Click set up a workflow by yourself

Next, on the file editor(main.yml), populate the below YAML file



name: Deploy to App Runner - Image based # Name of the workflow

on:

  push:

    branches: [ main ] # Trigger workflow on git push to main branch

  workflow_dispatch: # Allow manual invocation of the workflow

jobs:


  deploy:

    runs-on: ubuntu-latest

steps:      
  - name: Checkout
    uses: actions/checkout@v2
    with:
      persist-credentials: false

  - name: Configure AWS credentials
    id: aws-credentials
    uses: aws-actions/configure-aws-credentials@v1
    with:
      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      aws-region: ${{ secrets.AWS_REGION }}

  - name: Login to Amazon ECR
    id: login-ecr
    uses: aws-actions/amazon-ecr-login@v1        

  - name: Build, tag, and push image to Amazon ECR
    id: build-image
    env:
      ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
      ECR_REPOSITORY: privacy-protect
      IMAGE_TAG: ${{ github.sha }}
    run: |
      docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
      docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
      echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"  

  - name: Deploy to App Runner
    id: deploy-apprunner
    uses: awslabs/amazon-app-runner-deploy@main        
    with:
      service: privacy-protect-app-runner
      image: ${{ steps.build-image.outputs.image }}          
      access-role-arn: ${{ secrets.ROLE_ARN }}       
      region: ${{ secrets.AWS_REGION }}
      cpu : 1
      memory : 2
      port: 80
      wait-for-service-stability: true

  - name: App Runner ID
    run: echo "App runner ID ${{ steps.deploy-apprunner.outputs.service-id }}"

᛫ GitHub Action runs successfully after a few minutes

You can see the AWS App Runner dashboard your application is up and running successfully.

How to Deploy a TimeVault Application on Cloud Run with Cloud Build on GCP

Rajeshwar R — Tue, 23 May 2023 07:00:32 +0000

Timevault

A deadman's switch to encrypt your vulnerability reports or other compromising data to be decryptable at a set time in the future. Uses tlock-js and is powered by drand. Messages encrypted with timevault are also compatible with the go tlock library.

Cloudrun
Cloud Run is a managed compute platform that lets you run containers directly on top of Google's scalable infrastructure. You can deploy code written in any programming language on Cloud Run if you can build a container image from it. In fact, building container images is optional.

Structure of Timevault

Step 1:

Create a repository as in GCP Cloud Source Repositories name timevault-cloudrun. And clone the repository to your local.

Step 2:
Clone the timevault repository

 git clone https://github.com/r4jeshwar/timevault.git
 cd  timevault

Step 3:

Mirror the Github (timevault) repository to GCP cloud source repository

Go the GCP cloud source repository service and click Add repository and click connect external repository next click continue

Select your project ID and Select Github in Git provider, next choose your needed repository and click connect selected repository

Finally, Your Github repository will connect to your GCP cloud source repository

Step 4:
Using this Multi-stage Dockerfile we can able to deploy it on Cloudrun

FROM node:18-alpine AS build

WORKDIR /app

COPY package*.json ./
COPY ./src ./src

RUN npm i
RUN npm run build

FROM nginx:stable-alpine

COPY --from=build /app/dist/ /usr/share/nginx/html/

Step 5:
Write the cloudbuild.yaml to deploy it on Cloudrun. Here the cloudbuild.yaml file

 steps:
 # Build the container image
 - name: 'gcr.io/cloud-builders/docker'
   args: ['build', '-t', 'gcr.io/$_PROJECT_ID/$_IMAGE_NAME:$COMMIT_SHA', '.']
 # Push the container image to Container Registry
 - name: 'gcr.io/cloud-builders/docker'
   args: ['push', 'gcr.io/$_PROJECT_ID/$_IMAGE_NAME:$COMMIT_SHA']
 # Deploy container image to Cloud Run
 - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
   entrypoint: gcloud
   args:
   - 'run'
   - 'deploy'
   - '$_IMAGE_NAME'
   - '--platform=managed'
   - '--image'
   - 'gcr.io/$_PROJECT_ID/$_IMAGE_NAME:$COMMIT_SHA'
   - '--region'
   - '$_REGION'
   - '--allow-unauthenticated'
   - '--port'
   - '80'  
 images:
 - 'gcr.io/$_PROJECT_ID/$_IMAGE_NAME:$COMMIT_SHA'

 substitutions:
   _IMAGE_NAME: timevault
   _REGION: <YOUR_REGION>
   _PROJECT_ID: <YOUR_PROJECT_ID>

YOUR_REGION is the region of the Cloud Run service you are deploying.
YOUR_PROJECT_ID is your Google Cloud project ID where your image is stored.

Step 6:

Go to Cloud Build and create a trigger.

Step 7:

Trigger the Cloud Build. By below steps:
Cloud Build --> Triggers --> click RUN --> click RUN TRIGGER

Deployed on Cloud Run. Copy the Cloud Run URL and expose it on web browser

Adding custom domain in Cloud run

When you deploy a service to Cloud run, you are provided with a default domain to access the service. However, you can use your own domain or subdomain instead of default one.

Step 1:
Go to Cloud run service, Click MANAGE CUSTOM DOMAINS

Step 2:

Go to the domain mapping, Click ADD MAPPING

Step 3:

In the add mapping form, select the service which you map to and select the verify the new domain, next enter your domain. As shown in the below. Click the CONTINUE

It will take some time to verify your domain, Click REFRESH to check verification is done.

After the verification is done, enter the subdomain to map to the service you have selected, then click CONTINUE

You will get the DNS record for your custom domain that maps to your Cloud run service. You need to add this DNS record to your domain provider

Finally, when you add the DNS record successfully, you can use your custom domain to access your deployed Cloud run service.

MicroBin on Fly.io

Manjula Rajamani — Wed, 17 May 2023 15:00:03 +0000

MicroBin is a tiny, feature rich, configurable, self-contained, and self-hosted paste bin web application. It is elementary to set up and use, and will only require a few megabytes of memory and disk storage.

Fly.io
Fly.io is a platform for running full-stack applications and databases close to the users without any DevOps. You can deploy your apps to Fly.io (it's about the simplest place to deploy a Docker Image) and use our CLI to launch instances in regions that are most important for their application.

Structure of MicroBin

Step 1:
Clone your repository

git clone https://github.com/manjularajamani/microbin.git
cd microbin/

Step 2:
Using Dockerfile(or pre-built Docker images)we can able to deploy the application on the fly.io app server

FROM rust:latest as build

WORKDIR /app

COPY . .

RUN \
  DEBIAN_FRONTEND=noninteractive \
  apt-get update &&\
  apt-get -y install ca-certificates tzdata &&\
  CARGO_NET_GIT_FETCH_WITH_CLI=true \
  cargo build --release

# https://hub.docker.com/r/bitnami/minideb
FROM bitnami/minideb:latest

# microbin will be in /app
WORKDIR /app

# copy time zone info
COPY --from=build \
  /usr/share/zoneinfo \
  /usr/share/zoneinfo

COPY --from=build \
  /etc/ssl/certs/ca-certificates.crt \
  /etc/ssl/certs/ca-certificates.crt

# copy built executable
COPY --from=build \
  /app/target/release/microbin \
  /usr/bin/microbin

# Expose webport used for the webserver to the docker runtime
EXPOSE 8080

ENTRYPOINT ["microbin"]

Or fetch Docker image from DockerHub: danielszabo99/microbin:latest

Step 3:

Install flyctl:
flyctl is a command line interface to the Fly.io platform.It allows users to manage authentication, application launch, deployment, network configuration, logging and more with just the one command.Install Flyctl CLI

Sign In:
If you already have a Fly.io account, all you need to do is sign in with flyctl

fly auth login

Your browser will open up with the Fly.io sign-in screen, enter your user name and password to sign in.

Step 4:
To deploy app into fly.io we need a fly.toml file

app = "microbin"
primary_region = "ams"
kill_signal = "SIGINT"
kill_timeout = "5s"

[experimental]
  entrypoint = ["microbin", "--highlightsyntax", "--private", "--qr", "--editable", "--enable-burn-after"]

[build]
  image = "danielszabo99/microbin:latest"

[[mounts]]
  source = "microbin_data"
  destination = "/app/pasta_data"

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true

I've added only a few things that are enough for micro microbin

kill_signal:
The kill_signal option allows you to change what signal is sent so that you can trigger a softer, less disruptive shutdown.
kill_timeout:
When shutting down a Fly app instance, by default, after sending a signal, Fly gives an app instance five seconds to close down before being killed.
experimental:
This section is for flags and feature settings which have yet to be promoted into the main configuration.
build:
The image builder is used when you want to immediately deploy an existing public image
mounts:
This section supports the Volumes feature for persistent storage
auto_stop_machines:
Whether to automatically stop an application's machines when there's excess capacity, per region.
auto_start_machines:
Whether to automatically start an application's machines when a new request is made to the application and there's no excess capacity, per region.

Step 5:

Launch an App on Fly:
Fly.io enables you to deploy almost any kind of app using a Docker image.

flyctl launch 
      (or)
flyctl launch --image danielszabo99/microbin:latest

If you need to edit fly.toml and redeploy use the below command

flyctl deploy

Check Your App's Status:
The application has been deployed with a DNS hostname of microbin.fly.dev. Your deployment's name will, of course, be different. fly status give us basic details

flyctl status

Step 6:
The DESTROY command will remove an application from the Fly platform.

flyctl destroy <APPNAME>

Adding Custom Domains
Fly offers a simple command-line process for the manual configuration of custom domains and for people integrating Fly custom domains into their automated workflows.

Step 1:
Run flyctl ips list to see your app's addresses

flyctl ips list

Create an A record pointing to your v4 address, and an AAAA record pointing to your v6 address on your respective DNS.

Step 2:
You can add the custom domain to the application's certificates.

flyctl certs create <domain.name>

Step 3:
You can check on the progress by running the below command

flyctl certs show <domain.name>

Once the certificate is issued you can access your application to your Domain

Step 4:
To remove the hostname from the application, drop the certificates in the process.

flyctl certs delete <domain.name>

How to Setup AWS ECS Cluster as Build Slave for Jenkins

Selvakumar — Wed, 12 Apr 2023 12:30:46 +0000

This is a blog walk through how to set up the AWS ECS Fargate as a build slave for Jenkins.

Step#1: (ECS cluster setup)

Login to the AWS
Goto ECS and click the "Create cluster"

Choose the "Networking only" and then click "Next step"

Fill the cluster name and if you want to create the new VPC just click the "Create VPC" tick box or just leave it. Finally click the "create" button.

Step#2: (Setup ECS task execution IAM role)

Goto IAM, select the "Roles". Then click the "create role" button.

Choose "AWS service" on the trusted entry, then select "Elastic Container Service" on the drop down of use cases for other AWS services, then select the "Elastic Container Service Task". And click next.

On the Add permissions section select 'AmazonECSTaskExecutionRolePolicy", then click next.

Give the name of the role, then click "create role".

Step#3: (Create the security Group to ECS Slave)

Create the security group with JNLP port "50000".

Step#4: (Install the Jenkins)

Install the Jenkins on the EC2 if you not have it.Installation link
Note: Open the JNLP port "50000" on the Jenkins machine security group

Step#5: (AWS credential config at Jenkins)

Configure the AWS programmatic access keys and secret key on Jenkins credential. This will help to run the agent on ECS.

Step#6: (Setup JNLP port on Jenkins settings)

Goto "Manage Jenkins" on the dashboard.
Click the "Security" under the security section.
On the "Agents" setting, Choose the "Fixed" and put the port "50000".
Then "save" it.

Step#7: (Install ECS plugin on Jenkins)

Goto "Manage Jenkins", then click the "Plugins".
Install the "Amazon Elastic Container Service(ECS)/Fargate".

Step#8:(Setup the slave configuration on the Jenkins)

Goto "Manage Jenkins", then choose the "Nodes and Clouds".
Click "Clouds" on the left side top.
Choose "Amazon EC2 Container Service Cloud" on the add a new cloud drop down.

Name -> Give name to you cloud config. Then click "Show More".
Amazon ECS Credentials -> Select an AWS credential which we were configured before on step-5.
Amazon ECS Region Name -> choose the region where your cluster is running(we were created the on step 1)
ECS Cluster -> Select the cluster which we were created the on step 1
Click "Add" under the ECS agent templates.

Label -> Give the label name ( this name will use us to configure the agent with job)
Template Name -> Give name to template
Type -> Choose "Fargate"
Operating System Family -> Choose "linux"
Network mode - > Select "awsvpc"
Soft Memory Reservation and CPU units give base on the doc. For "i.e. Memory is 2048 means, CPU should be 1024"
Subnets -> Given the subnets to run agent on vpc network("," is a delimiter). i.e subnet-1,subnet-2
Security Groups -> Give the security group ID which we were created on step 3.
Assign Public Ip -> Tick the check box.
Then click "Advanced".

Task Execution Role ARN -> Give the role ARN name wich we were created on step 2.
ContainerUser -> Given container user is "root".

_Note: the following log configuration step are "not required", but If you want to see agent logs then config these.

Logging Driver -> Give "awslogs"
Logging Configuration:

note: you must create the log group (/ecs/jenkins-slave) on cloud watch before you give here.
- Key: awslogs-group Value: /ecs/jenkins-slave
- Key: awslogs-region Value: us-east-1
- Key:awslogs-stream-prefix Value:ecs

Finally, Save the configuration.

Step#8:(Create the test job)

On the "Dashboard", add new item.
Select "Freestyle project".
Give the label name which we configured on step 7
On the build step just put some shell command. Then save and run the job

The slave container is PROVISIONING
Console output

Note: The Jenkins and the ecs salve should be on same network.

EC2 instance as self-hosted GItHub runners

Arunodhayam — Tue, 11 Oct 2022 05:56:39 +0000

By default, GitHub offers hosted runners to run our workloads inside. For their Linux runners, GitHub offers runners with specs: 2-core CPU, 7 GB of RAM, 14 GB of SSD disk space.

Some of your CI/CD workloads may require more powerful hardware than GitHub-hosted runners could provide. In such case, you can configure an EC2 instance to act as your GitHub runner instead.

For example, you may run a c5.4xlarge instance type for some of your workloads, or even a r5.xlarge for workloads that process large data sets in-memory.

Let us begin:

#1. Create a GitHub personal access token

Go to your GitHub Settings
Click the Developer settings

Click Personal access token to create one

Create a new GitHub personal access token with the repo scope in the name of GH_PERSONAL_ACCESS_TOKEN. The action will use the token for self-hosted runners management in the GitHub account on the repository level.

#2. Create an AMI image

Create a new EC2 instance based on a Linux distribution of your choice
Connect to the instance ```sh

ssh -i user_name@IP_ADDRESS

- Install packages and configure the instance according to your workflow requirements
- After that, land on the EC2 console, select your instance, right-click on it to find `Image and templates` , hover to see `Create image`, click it

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/buiy3gqonksd0yabhsxg.png)
- Enter the `Image name`, `Image description`, and check `No reboot`, and at last , hit `Create`
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k00gnvipndhmh2avxaor.png)
-  The AMI should show up in the AMI console 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/83mf1vod1nav7k5h2rhv.png)
- You can safely terminate the instance as it's of no use any more, of course, you could just keep it running if you plan on making any changes to it, however

## #3. Create VPC with subnet and security group
- Create a new [VPC and Subnet](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html) or use an existing
- Create a new [Security group](https://docs.aws.amazon.com/cli/latest/userguide/cli-services-ec2-sg.html) for the runners in the VPC and only allow outbound traffic to port 443, for pulling jobs from GitHub. No port opening for inbound traffic is necessay.

## #4. Configure the environment secrets
- The following environment variables must be set for this action 

| Secrets | Description |
| ------- | ----------- |
| `GH_PERSONAL_ACCESS_TOKEN` | Add the GitHub pat token in secret |
| `AWS_REGION` | Add the region in secret |
| `AWS_ACCESS_KEY_ID` | Add the access key in secret |
| `AWS_SECRET_ACCESS_KEY` | Add the secret key in secret |
| `AMI` | Add the EC2 AMI ID in secret |
| `INSTANCE_TYPE` | Provide the instance type like t2.medium, t2.micro |
| `SUBNET` | Add the subnet ID in secret |
| `SECURITY_GROUP` | Add the security group ID in secret |

- Go to your project `repo settings` to add the above Secrets

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bpbvapzu5qh3qckwpfqr.png)

- Expand the `Secrets` drop-down and click `Actions`

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y8041s4x1caywdahqwvo.png)

- In the _Actions secrets_ tab click `New repository secret` 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5fmybdpgemqq2vv6s1ci.png)

- Name your secrets and add their values to be consumed by the action

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3kx83orynk8n3mz16vwr.png)

- A complete listing of the required secrets should look something like

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gjd7ez1jzkxgwqrwmkul.png)


## #5. Configure the GitHub workflow

- Create a new GitHub Action with the below example workflow
- Please don't forget to set up a job for removing the EC2 instance at the end of the workflow execution.
   Otherwise, the EC2 instance won't be removed and continue to run even after the workflow execution is finished.

Now you're ready to go!

### Inputs

| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Required                                   | Description                                                                                                                                                                                                                                                                                                                           |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `mode`                                                                                                                                                                       | Always required.                           | Specify here which mode you want to use: <br> - `start` - to start a new runner; <br> - `stop` - to stop the previously created runner.                                                                                                                                                                                               |
| `GitHub-token`                                                                                                                                                               | Always required.                           | GitHub Personal Access Token with the `repo` scope assigned.                                                                                                                                                                                                                                                                          |
| `ec2-image-id`                                                                                                                                                               | Required if you use the `start` mode.      | EC2 Image Id (AMI). <br><br> The new runner will be launched from this image. <br><br> The action is compatible with Amazon Linux 2 images.                                                                                                                                                                                           |
| `ec2-instance-type`                                                                                                                                                          | Required if you use the `start` mode.      | EC2 Instance Type.                                                                                                                                                                                                                                                                                                                    |
| `subnet-id`                                                                                                                                                                  | Required if you use the `start` mode.      | VPC Subnet Id. <br><br> The subnet should belong to the same VPC as the specified security group.                                                                                                                                                                                                                                     |
| `security-group-id`                                                                                                                                                          | Required if you use the `start` mode.      | EC2 Security Group Id. <br><br> The security group should belong to the same VPC as the specified subnet. <br><br> Only the outbound traffic for port 443 should be allowed. No inbound traffic is required.                                                                                                                          |
| `label`                                                                                                                                                                      | Required if you use the `stop` mode.       | Name of the unique label assigned to the runner. <br><br> The label is provided by the output of the action in the `start` mode. <br><br> The label is used to remove the runner from GitHub when the runner is not needed anymore.                                                                                                   |
| `ec2-instance-id`                                                                                                                                                            | Required if you use the `stop` mode.       | EC2 Instance Id of the created runner. <br><br> The id is provided by the output of the action in the `start` mode. <br><br> The id is used to terminate the EC2 instance when the runner is not needed anymore.                                                                                                                      |
| `iam-role-name`                                                                                                                                                              | Optional. Used only with the `start` mode. | IAM role name to attach to the created EC2 runner. <br><br> This allows the runner to have permission to run additional actions within the AWS account, without having to manage additional GitHub secrets and AWS users. <br><br> Setting this requires additional AWS permissions for the role launching the instance (see above). |
| `aws-resource-tags`                                                                                                                                                          | Optional. Used only with the `start` mode. | Specifies tags to add to the EC2 instance and any attached storage. <br><br> This field is a stringified JSON array of tag objects, each containing a `Key` and `Value` field (see example below). <br><br> Setting this requires additional AWS permissions for the role launching the instance (see above).                         |
| `runner-home-dir`                                                                                                                                                              | Optional. Used only with the `start` mode. | Specifies a directory where pre-installed actions-runner software and scripts are located.<br><br> |

### Outputs

| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Description                                                                                                                                                                                                                               |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `label`                                                                                                                                                                      | Name of the unique label assigned to the runner. <br><br> The label is used in two cases: <br> - to use as the input of `runs-on` property for the following jobs; <br> - to remove the runner from GitHub when it is not needed anymore. |
| `ec2-instance-id`                                                                                                                                                            | EC2 Instance Id of the created runner. <br><br> The id is used to terminate the EC2 instance when the runner is not needed anymore.                                                                                                       |

### Example workflow

`ci.yml`

```yml


name: ci
on: pull_request
jobs:
  start-runner:
    name: Start self-hosted EC2 runner
    runs-on: ubuntu-latest
    outputs:
      label: ${{ steps.start-ec2-runner.outputs.label }}
      ec2-instance-id: ${{ steps.start-ec2-runner.outputs.ec2-instance-id }}
    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}
      - name: Start EC2 runner
        id: start-ec2-runner
        uses: machulav/ec2-github-runner@v2
        with:
          mode: start
          github-token: ${{ secrets.GH_PERSONAL_ACCESS_TOKEN }}
          ec2-image-id: ${{ secrets.AMI }}
          ec2-instance-type: ${{ secrets.INSTANCE_TYPE }}
          subnet-id: ${{ secrets.SUBNET }}
          security-group-id: ${{ secrets.SECURITY_GROUP }}
          iam-role-name: my-role-name # optional, requires additional permissions
          aws-resource-tags: > # optional, requires additional permissions
            [
              {"Key": "Name", "Value": "ec2-github-runner"},
              {"Key": "GitHubRepository", "Value": "${{ github.repository }}"}
            ]
  do-the-job:
    name: Do the job on the runner
    needs: start-runner # required to start the main job when the runner is ready
    runs-on: ${{ needs.start-runner.outputs.label }} # run the job on the newly created runner
    steps:
      - name: Hello World
        run: echo 'Hello World!'
  stop-runner:
    name: Stop self-hosted EC2 runner
    needs:
      - start-runner # required to get output from the start-runner job
      - do-the-job # required to wait until the main job is done
    runs-on: ubuntu-latest
    if: ${{ always() }} # required to stop the runner even if the error happened in the previous jobs
    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}
      - name: Stop EC2 runner
        uses: machulav/ec2-github-runner@v2
        with:
          mode: stop
          github-token: ${{ secrets.GH_PERSONAL_ACCESS_TOKEN }}
          label: ${{ needs.start-runner.outputs.label }}
          ec2-instance-id: ${{ needs.start-runner.outputs.ec2-instance-id }}

After a successful first workflow execution, you should see this

Restore SSH connectivity to EC2 instance if SSH key pair is lost

Selvakumar — Thu, 06 Oct 2022 13:42:07 +0000

Some time back, unfortunately, we had lost an SSH key pair belonging to an important EC2 instance. At that point in time, we had just taken a snapshot of the instance and moved on to create a new one with a new key pair. In this blog post, we shall see how to restore SSH connectivity.

Step #1:

Create a new EC2 instance. If performing on an existing instance, make sure you hold that machine's SSH private key

Step #2:

Stop the instance you lost the SSH key pair to and detach its volume right after (Make absolutely sure that before you go about detaching the volume, it is the correct one)

 Goto --> AWS --> EC2 --> Volumes(EBS)

Step #3:

Post volume detachment, attach the volume to the EC2 machine of choice from #1, which is either a new or an existing

Goto --> AWS --> EC2 --> Volumes(EBS)

Select that detached volume and click action choose Attach volume, and select the EC2 instance that wants the volume attached to

Verify that you have attached the volume to the right instance. Go to the EC2 console, select the instance, and select storage, and you should see two volumes: one is the root and the other is our attached

Note
Before moving on to Step #4, you have to create an SSH key pair
ssh-keygen -t rsa -b 4096

Step #4:

$ ssh -i path/to/private.key username@ip-addr
$ lsblk
$ mkdir ~/data
$ sudo mount /dev/xvdf1 /data

Step #5:

Once mounted, navigate to the mounted directory cd ~/data/home/ubuntu/.ssh

Edit the authorized_keys file, delete the existing public key and paste the new public key generated in #4
Once, that is done, unmount the volume

sudo umount ~/data

Finish it by detaching the volume from the instance, and reattaching the volume back to its former owner i.e; stopped instance.

 1. Goto --> AWS --> EC2 --> Volumes (EBS)
 2. Select the correct volume, then "action --> force detach/detach volume"

 3. Select the volume again, "action --> attach volume"

Note "Device name" should be "/dev/sda1"
Because this is the device naming supported by the root volume

Step #6:

Here on forth, you can SSH back into the machine you lost your SSH keys to, using the new private key which was created in #3

Migrate RDS Cross-Account

Selvakumar — Thu, 06 Oct 2022 13:17:31 +0000

This post gives a walkthrough on how to migrate an RDS DB across two AWS accounts.

#1 Take Snapshot

Take a snapshot of the target DB

Go to AWS --> RDS --> Snapshots --> Take snapshot

#2 Create a KMS key

Create a fresh KMS key and share it with the target account

AWS --> KMS --> Customer-managed keys --> create key

Before you go on creating the new key, don't skip the above step. Now proceed to enter the target account ID in the below field

Create a snapshot (a second) of the snapshot created in #1. The reasoning for this is that the KMS key created in #2 which was shared with the target account, was done to allow the creation of the DB on the target account

select the snapshot --> action --> copy snapshot

While the steps to copying are underway, select the freshly created KMS key (I named it "test") from the drop-down

#3 Share the Snapshot

Share the copied snapshot with the target account and enter the target account ID, once more

Select the snapshot --> Action --> share snapshot

NOTE: The below-proceeding steps should be executed on the target account

#4 Create a New DB.

The shared DB snapshot will show up in your target account

Go to AWS --> RDS --> Snapshot --> Shared with me

In the target account, create a new DB instance by restoring the DB snapshot

RDS --> Snapshot --> Shared with me --> select snapshot --> action -->  restore snapshot.

NOTE: When creating a DB from the snapshot, DO NOT FORGET to swap the "test" KMS key with the "default" on the target account key. Select "(default) aws/rds"

DEV Community: itTrident Software Services

Deploy Fider as a Private App on AWS with CloudFront VPC Origin

1. What is CloudFront VPC Origin

2. Why you should deploy Fider as a private application

3. Create an Internal Application Load Balancer

4. Create CloudFront VPC origin

5. Create a CloudFront Distribution

6. Create Secrets manager secret and Lambda function

7. Create a Custom Header rule in AWS WAF

8. Spin up ECS and RDS

9. Monitor CloudFront and WAF logs

10. Do You Really Need Zero Trust for Every App

11. Is CloudFront Truly Zero Trust Compliant

12. Deciding on Enterprise Grade Deployment for Fider

13. Caveats to consider

14. Final thoughts

Deploying Fider on AWS ECS: A Step-by-Step Guide to Deploy a Feedback Platform

AWS services used

Table of Contents

What is Fider ?

Fider's Tech Stack

Pre-flight checks

Install AWS CLI

Step 1:

Step 2:

Step 4: Configure AWS CLI

Step 5: Pull official docker images from DockerHub

Push the Docker images to ECR

Step 1: Visit the ECR console

Step 2: View the push commands

Create a VPC

Step 1: Create a standalone VPC for deploying Fider application

Step 2: Create an Internet gateway

Step 3: Create Public Subnets

Step 4: Create Private Subnets

Step 5: Create a Private route table

Step 6: Create an Elastic-ip

Step 7: Create NAT gateway

Create Subnet group for RDS

Create an RDS PostreSQL DB

Create Parameters in Systems manager Parameter Store

Create an IAM user

Create an S3 bucket

Create an identity in SES

Why use ECS instead of EC2

1. Reduced Operational Overhead:

Create an ECS cluster

Step 1:

Create Task Definition

Step 1:

Create an ECS service

Step 1:

Step 2: Configuration parameters

Step 3: Use ACM for SSL certificates

Create Cloudfront distribution with WAF

Deploying Node-Red on Azure Container Instance

Comprehensive Guide to Integrating SonarCloud with GitHub Projects

Prerequisites

Adding support for stateful applications deployed on GCP Cloud Run via Filestore

Introduction:

Prerequisite:

Getting Started:

A Step-by-Step Guide to Deploying an Application on AWS App Runner with GitHub Action workflow

Privacy-Protect

App Runner

Cons of App Runner

᛫ Create a IAM role

᛫ Create a AWS ECR private repostiory

᛫ Clone the repository

᛫ Migrate from Server deployment(Vercel-@sveltejs/adapter-vercel) to static site generator(@sveltejs/adapter-static)

᛫ Dockerfile for privacy-protect to deploy in App Runner

᛫ Configure the GitHub Action secrets

᛫ Configure the new workflow in GitHub Action

᛫ GitHub Action runs successfully after a few minutes

How to Deploy a TimeVault Application on Cloud Run with Cloud Build on GCP

MicroBin on Fly.io

How to Setup AWS ECS Cluster as Build Slave for Jenkins

Step#1: (ECS cluster setup)

Step#2: (Setup ECS task execution IAM role)

Step#3: (Create the security Group to ECS Slave)