DEV Community: Mubarak Alhazan

How to Import Existing AWS Resources into the Serverless Framework (Using CloudFormation Import)

Mubarak Alhazan — Sun, 29 Mar 2026 14:54:07 +0000

Introduction

While working on a project to fully transition an application into Infrastructure as Code (IaC), I encountered a challenge that proved more difficult than I expected: importing existing AWS resources into the Serverless Framework.

The application already had several AWS resources created manually over time, including multiple SQS queues used by different services. Since our goal was to have all infrastructure managed through IaC, we needed those existing resources to be managed directly inside our serverless.yml.

At first thought, this seemed straightforward. However, I discovered that Serverless Framework does not provide a direct way to import existing resources into a stack.

Since Serverless deployments are built on top of AWS CloudFormation, the only reliable way to achieve this is by using CloudFormation’s resource import functionality. Even then, the process can be tricky, and if done incorrectly, it can cause stack drift or even delete existing resources.

Because I couldn't find a clear, practical guide that walks through this process from start to finish, I decided to document the approach that worked for us.

Understanding The Challenge

The Serverless Framework uses AWS CloudFormation under the hood to create and manage infrastructure. When you deploy a Serverless application, the resources defined in serverless.yml are translated into a CloudFormation template and applied to a stack.

This workflow works well when CloudFormation is responsible for creating the resources from the beginning. However, the situation becomes more complicated when the resources already exist.

In many real-world projects, infrastructure evolves. Some resources may have been created manually through the AWS console, while others may have been created by different deployment tools. As a result, these resources exist outside of the CloudFormation stack managed by Serverless.

Serverless Framework cannot manage these resources because CloudFormation isn't aware of them.

To bring these resources under IaC management, they must first be imported into the CloudFormation stack that Serverless controls.

CloudFormation does provide a resource import feature, but it has strict requirements:

The resource configuration in the template must match the existing resource
A valid resource identifier must be provided
No unrelated stack changes can occur during the import

In our case, the goal was to import several existing SQS queues into our Serverless stack so they could be fully managed through serverless.yml without recreating or disrupting the existing resources.

The Approach that Worked

After experimenting with different options, the most reliable approach we found was to use AWS CloudFormation’s Infrastructure as Code (IaC) Generator to scan existing resources and generate a template that could be safely imported into our Serverless stack.

This allowed us to import the resources without recreating them, while ensuring the generated template accurately reflected the existing configuration.

The process involved four main steps.

Existing AWS Resources
        ↓
IaC Generator Scan
        ↓
Template Generation
        ↓
CloudFormation Import
        ↓
Managed in Serverless

Step 1: Scan The Existing Resources

The first step is to scan the AWS account for the resources you want to import.

In the CloudFormation console, navigate to IaC Generator and click Scan.

You’ll be presented with two options:

Scan all resources
Scan specific resources

Since we only needed to import SQS queues, we selected Scan specific resources and chose the resource type:

AWS::SQS::Queue

CloudFormation then scans the account and identifies all SQS queues that exist in the account.

This scan allows AWS to capture the configuration of those resources so they can be represented in a CloudFormation template.

Selecting AWS::SQS::Queue when scanning resources using the CloudFormation IaC Generator.

Step 2: Generate a Template for the Existing Stack

Once the scan is completed, CloudFormation displays a success message and prompts you to create a template from the scanned resources.

Click Create Template, and you will be given two options:

Start a new template
Update a template for an existing stack

Since we wanted the resources to be managed by our existing Serverless stack, we selected:

Update a template for an existing stack

Next, you’ll be asked to choose the stack you want to update. In our case, this was the stack created by our Serverless deployment.

After selecting the stack, CloudFormation asks for a few template details:

Template Name

A name for the generated template.

Deletion Policy

Defines what happens to the resource if it is removed from the stack.

For example:

DeletionPolicy: Retain

This ensures the resource is not deleted if it is later removed from the CloudFormation stack.

Update Replace Policy

Defines what happens if CloudFormation needs to replace the resource during an update.

Using Retain here also helps prevent accidental deletion.

After providing these details, CloudFormation shows the list of resources that were discovered during the scan.

At this stage:

Resources already managed by a stack cannot be selected.
Resources not yet managed by any stack can be selected for import.

You can then choose the specific resources you want to add to the existing stack.

In the next step, CloudFormation checks if the selected resources require related resources. Some AWS services require dependent resources to be imported together, but in the case of SQS queues, there were no additional dependencies required.

Finally, you are given a chance to review the generated template before creating it.

Choosing to update the template for an existing stack.

Selecting the SQS queues to add to the existing stack.

Step 3: Import the Resources

After the template is created, CloudFormation allows you to import the resources directly into the selected stack.

Because the template was generated from the scanned resources and tied to the existing stack, the import process becomes much smoother.

There is no need to manually create a change set or define logical resource IDs. The IaC Generator already handles this as part of the template generation process.

Once the import is executed successfully, the resources appear inside the CloudFormation Resources tab for the stack.

At this point, the imported resources become fully managed by the stack, which means future deployments can safely reference them from serverless.yml.

The imported SQS queue now appears as a managed resource in the CloudFormation stack.

Step 4: Define the Resources in `serverless.yml`

Once the resources are imported successfully, the next step is to define them inside serverless.yml so that future deployments continue to manage them correctly.

For example:

resources:
  Resources:
    SQSQueueDemoimportqueue:
      Type: AWS::SQS::Queue
      Properties:
        QueueName: demo-import-queue

To keep the configuration clean and reusable across environments, we defined queue names inside the custom block:

custom:
  queue_suffix:
    dev: ""
    staging: "_staging"
    prod: "_prod"

  queues:
    email_queue:
      name: demo-queue${self:custom.queue_suffix.${sls:stage}}

This approach allows the same resource definition to work across multiple environments while keeping naming consistent.

Things to Watch Out For When Importing Resources

While the import process is fairly straightforward when using the IaC Generator, there are a few things to keep in mind.

Resources Already Managed by Another Stack

If a resource is already associated with a CloudFormation stack, it cannot be imported into another stack. During the template creation step, CloudFormation will indicate which resources are already managed and prevent them from being selected.

If you need to move a resource between stacks, ensure the original stack removes the resource safely before attempting the import.

Use a Safe Deletion Policy

When generating the template, it is recommended to set:

DeletionPolicy: Retain

This prevents the resource from being deleted if it is later removed from the stack.

For stateful resources like SQS queues, this provides an additional safety layer.

Ensure the Resource Configuration Matches

CloudFormation imports require the template configuration to match the existing resource configuration.

Using the IaC Generator helps avoid this issue since it generates the template directly from the existing resources.

Conclusion

Importing existing AWS resources into the Serverless Framework isn’t always straightforward because Serverless relies on CloudFormation to manage infrastructure. This means that existing resources must first be imported into the underlying CloudFormation stack before they can be managed through serverless.yml.

By using the IaC Generator to scan resources and generate a template for an existing stack, we were able to safely import our SQS queues without recreating them. Once imported, defining them in serverless.yml allows Serverless to manage them as part of future deployments.

Although the process requires a few careful steps, it provides a reliable way to bring existing infrastructure under Infrastructure as Code.

Webflow CMS Behind CloudFront: Serving Dynamic and Static Pages on the Same Domain

Mubarak Alhazan — Sun, 18 Jan 2026 16:12:35 +0000

Introduction

A prevalent way to deploy a frontend on AWS is to use S3, CloudFront, and Route 53. It’s simple and cost-effective. Many teams begin here and successfully run this setup for years.

It’s also very common for teams to eventually move some public-facing pages (such as the homepage or blog) to a CMS like Webflow. This shift is usually driven by practical reasons: marketers want to publish content without engineering involvement, SEO workflows become easier, and design iterations move faster.

The challenge starts when you want to do both. You might want:

company.com and /blogs to be managed in Webflow
Other pages (especially dynamic ones like /dashboard/*, to remain on S3).
Everything is to live under the same domain, without redirects or subdomains.

At this point, the problem is traffic routing. In this article, I’ll walk through how I solved this problem in a recent deployment.

The approach allows you to:

Keep CloudFront as the single entry point
Serve Webflow pages and S3-backed pages from the same apex domain
Handle Webflow domain verification without permanently routing traffic away from CloudFront

This setup works reliably in production and avoids several pitfalls that aren’t clearly documented elsewhere.

The Architecture That Works

At a high level, the solution is surprisingly simple once you adopt the right mental model.

Instead of trying to move routing logic into Webflow (which might require an enterprise plan) or introducing a new proxy layer, we keep CloudFront as the single entry point for the domain and let it do what it’s already designed to do: route requests to different origins based on path patterns. This avoids extra proxy layer infrastructure and builds directly on an architecture many teams already have in production.

The Core Idea is:

CloudFront remains the single edge
Webflow and S3 are treated as origins
Path-based behaviours decide where each request goes

Requests flow like this:

Route53 → CloudFront
        ├── /dashboard/* → S3
        └── /*             → Webflow

From the browser’s perspective, everything is still coming from company.com. There are no redirects, no subdomains, and no visible boundary between Webflow-managed pages and S3-backed pages.

Webflow as an Origin (and the Verification Gotcha)

Treating Webflow as an origin in CloudFront is straightforward from an infrastructure perspective. You create a custom origin pointing to your Webflow-hosted site, just like you would for an ALB or any external service. However, if that’s all you do, you’ll likely run into a 502 Bad Gateway error on the paths meant to route to Webflow.

This happens because Webflow requires domain ownership verification before it allows publishing.

The way Webflow handles this verification can be confusing. Before a domain can be published, Webflow asks you to add DNS records, typically:

A TXT record for ownership verification
An A record or CNAME that points traffic directly to Webflow

This works well when Webflow is intended to be the final destination for traffic. In this architecture, however, DNS must point to CloudFront, not Webflow.

This creates a fundamental mismatch:

Webflow expects DNS to point directly to them
CloudFront must stay in front to enable path-based routing

The key to resolving this is understanding that the Webflow UI is mixing two very different concerns:

Verification is a control-plane requirement: it exists to prove domain ownership and enable publishing
Traffic routing is a data-plane concern: it determines where live requests are actually served from

Webflow’s UI strongly suggests that both the TXT record and the A/CNAME record must continuously point to Webflow. In reality, only the TXT record is required for ongoing verification.

The practical workaround is:

Initially, point the TXT, A, and CNAME records to Webflow so verification can succeed
Once the domain is verified and publishing is enabled:
- Keep the TXT record in place for continuous ownership proof
- Point the A and CNAME records back to CloudFront

At that point, CloudFront can safely forward traffic to Webflow as an origin, since the domain is already verified.

In the next section, we’ll walk through how this is implemented step by step, without breaking production traffic.

Step-by-Step Implementation

1. Keep DNS Pointing to CloudFront

Ensure your apex domain (company.com) and www (if used) point to CloudFront
Do not remove or bypass CloudFront as part of the final setup

This remains true before and after verification.

2. Add Webflow as a Custom Origin in CloudFront

Create a new custom origin in your CloudFront distribution
Origin domain:
```
your-site.webflow.io
```
Protocol policy: HTTPS only
Origin headers: none required

At this point, requests routed to Webflow will still fail until verification is completed.

3. Configure Path-Based Behaviours

Default behaviour (*):
- Origin: Webflow
- Cache policy: CachingDisabled (recommended for CMS content)
- Origin request policy: AllViewer (or equivalent)
Specific behaviour (/dashboard/*):
- Origin: S3
- Cache policy: As per your existing setup

Ordering matters:

More specific paths (/dashboard/*) must appear above the default (*) behavior.

4. Temporarily Point DNS to Webflow for Verification

In Webflow:
- Add your custom domain (company.com)
In Route53:
- Add the TXT record provided by Webflow (_webflow)
- Temporarily update:
  - Apex A record → Webflow IP(s)
  - www CNAME → cdn.webflow.com
Wait for verification to complete in Webflow

This step is temporary and only required once.

5. Revert DNS to CloudFront

Restore DNS records:
- Apex A record → CloudFront
- www CNAME → CloudFront
Keep the TXT record in place

At this point:

DNS routes traffic to CloudFront
Webflow remains verified and publishable

6. Publish the Site in Webflow

Set the custom domain as the default
Publish the site
No further DNS changes are required

CloudFront now routes:

/* → Webflow
/restaurants/* → S3

All under the same domain.

Conclusion

The key insight in this setup is simple: CloudFront remains the single edge, and everything else becomes an origin behind it.

Webflow does not need to own DNS long-term to serve content. It only needs to verify the domain once. After that, CloudFront can safely sit in front, handle routing, and forward requests to Webflow exactly like it would to any other backend.

You may still see Webflow UI warnings like “update required” after DNS is reverted to CloudFront. These warnings are harmless, as long as the domain is already verified and published.

With this model, you get the flexibility of mixing static assets, dynamic frontends, and managed platforms like Webflow, while still retaining CloudFront.

That’s the architecture that actually works.

Thank you for reading

You can follow me on LinkedIn and subscribe to my YouTube Channel, where I share more valuable content. Also, let me know your thoughts in the comments section.

Cooking Without Burning: My DevOps Doings in the Past Few Years

Mubarak Alhazan — Mon, 20 Oct 2025 08:49:29 +0000

DevOps, much like cooking, is all about balance. Too little automation, and the process stays raw; too much change without control, and something catches fire. Over the past few years, I’ve spent countless hours in the kitchen, experimenting with tools, tweaking workflows, and sometimes cleaning up after the inevitable smoke. Each deployment, like a dish, taught me a lesson: precision, timing, and preparation make all the difference.

From Code to Cloud

My journey into DevOps began after attending OSCAFEST 2022, where I attended multiple sessions on DevOps and cloud-native technologies. Listening to the speakers talk about automation, scalability, and continuous delivery opened up a new world for me. I became fascinated by what happens beyond the code: how software is deployed, monitored, and kept running smoothly.

L-R: Michael Balli, Nader Dabit, Paul Ibeabuchi and I at OSCAFEST 2022

At the time, I was a frontend engineer. Inspired by what I learned at OSCAFEST, I decided to take the first step by deploying the frontend applications I built at work. That experience sparked a deeper interest in understanding the full deployment process, and soon I found myself exploring other aspects of DevOps.

Since then, I’ve worked on multiple DevOps projects that have shaped my perspective on software delivery and reliability. Each project presented unique challenges, ranging from automating complex AWS infrastructures to managing deployments on bare servers.

In this article, I’m shining the spotlight on some of the most interesting projects that tested my problem-solving skills, deepened my understanding of infrastructure, and helped me appreciate the craft of building systems that work.

Automating AWS with Terraform

At one time, our AWS infrastructure at my current company was managed entirely through the console: VPCs, EC2, load balancers, security groups, etc, were all created and updated manually. It worked, but it was messy. There were inconsistencies across environments, occasional missing configurations, and the constant risk of someone making a change in production that wasn’t mirrored elsewhere.

That pain led us to adopt Terraform for Infrastructure as Code. The first step was to replicate our existing setup so we could version and reproduce it easily. Afterwards, I began organising it into modular components such as networking, frontend and backend services, each reusable across environments.

This modular approach completely changed how we handled deployments. Instead of manually provisioning resources, we could spin up or tear down entire environments with a single command. It eliminated configuration drift and brought consistency across development, staging, and production environments.

To make testing faster and safer, I integrated LocalStack, a local AWS emulator. This allowed us to validate Terraform changes and experiment confidently before applying them to live resources.

The result was a leaner, more predictable workflow that saved time, reduced human error, and gave us consistent, reproducible environments across the board.

Deploying on Bare Server

When I joined this particular team, the company was facing a tough challenge: skyrocketing cloud costs. The dollar-to-naira exchange rate had become a major burden, and even after applying several AWS cost-optimisation strategies, we still weren’t hitting the company’s cost targets. That reality pushed us to make a bold decision to move away from AWS and deploy on a local cloud provider that billed in naira. It meant giving up the scalability and managed services AWS offered, but because our business operated in a B2B model with predictable growth, the trade-off was viable.

With only raw servers available, I had to design a production-ready deployment that was secure, automated, and maintainable. We ran two main layers: the backend and the database, each on separate servers.

For the backend layer, I containerised all services using Docker to ensure consistency and easier updates. I configured Nginx as a reverse proxy to route traffic across the microservices and set up SSL using Let’s Encrypt, which provided free certificate issuance and automatic renewal (free is important, given our cost-saving goals). You can read the detailed SSL implementation in this article.

To automate deployments, I created a GitHub Actions pipeline that built Docker images, pushed them to private Amazon ECR (which was practically free for our usage), and redeployed them on the server whenever a new release was made. I document the complete workflow in this article.

Of course, deployment alone wasn’t enough. We needed monitoring, something AWS CloudWatch had previously handled for us. This time, I manually set up Prometheus to track database performance, server metrics, and resource utilisation. The metrics were visualised in Grafana dashboards, and I configured alerts to trigger Slack and email notifications when thresholds were breached.

For database reliability, we used Acronis for daily backups. This required installing backup agents on the database server and syncing data to the Acronis dashboard.

On the security side, I implemented least-privilege principles at both the security group and server firewall levels. This ensured that access to the app and database servers was tightly controlled and auditable.

In the end, we were able to cut infrastructure costs by more than half, with the added advantage of paying locally in naira, protecting the business from foreign exchange volatility.

More importantly, the experience reminded me that no solution fits all contexts. AWS is usually my go-to platform because of its maturity and range of services, but this project forced me to look in a different direction. It was like a cook realising that not every dish needs the same spice; sometimes you need to reach for something unexpected to get the right flavour 😅. This project was my ghetto DevOps moment; it was hands-on, challenging, but full of learning.

If you’re a Nigerian business looking for a cloud provider that bills in naira, I’d genuinely recommend Nobus; their support team is excellent

Migrating Infrastructure Across AWS Accounts

While working at a consultancy firm, I was assigned to a project that required moving a client’s entire cloud deployment from our company’s AWS account to the client’s own AWS account, all with minimal downtime. The migration was part of a new contract. The main challenge was that much of the infrastructure hadn’t been fully codified with Infrastructure as Code (IaC), which meant every migration step had to be carefully planned and executed.

We began with the database layer. The client’s data was stored in DynamoDB, and we decided to use the S3 export-import method for the migration. This approach was cost-effective and efficient for the dataset size we were dealing with. To avoid disrupting the live environment, we scheduled the migration outside active business hours, and the entire process was completed smoothly.

Next was the backend layer, which ran on AWS Lambda. For this, we wrote a Python script using Boto3 to automate copying function configurations and code from the source account to the destination account.

Then came the frontend migration, which turned out to be the most challenging part of the entire process. The frontend stack combined S3 (for hosting), CloudFront (for distribution), and Route 53 (for DNS management), but I couldn’t find a clear, end-to-end guide on migrating this exact stack. So, I had to piece together best practices from multiple AWS resources, carefully sequencing the migration of S3 buckets, CloudFront distributions, and DNS records to prevent service interruption. When the migration was finally complete, I documented the entire process in an article so the next person would find it easier. You can read that detailed walkthrough here.

Documenting the DevOps Process

Across every team I’ve worked with, one thing that has remained consistent is my commitment to documentation. While many engineers see documentation as an afterthought, I’ve always treated it as a core part of engineering. It is a way to make complex systems understandable and sustainable. Over time, I’ve become known as the person who ensures things are written down, organised, and easy to follow.

My motivation has always been easy onboarding, knowledge sharing, and reducing dependency on any single engineer. I’ve seen how teams can slow down or lose context when crucial setup steps or troubleshooting processes live only in someone’s head. Good documentation turns individual know-how into collective knowledge.

My approach varies based on the type of content. For technical references that evolve frequently, such as configuration steps, I prefer GitHub README files, where updates can easily follow version control. For broader, long-form guides like deployment workflows, architecture decisions, or troubleshooting procedures, I use Confluence, which provides better structure and discoverability for team-wide access.

Documentation is something I do for myself and for others. It helps me think clearly, ensures the next person can build faster, and makes sure that when systems scale, the knowledge behind them scales too.

Reflections: Growth Beyond the Pipeline

Looking back at these projects, I see more than just deployments, configurations, or scripts; I see growth. Each challenge pushed me to think beyond technical correctness and focus on building systems that serve real business needs; solutions that are resilient, cost-conscious, and adaptable to change.

If there’s one lesson I’ve learned and want to leave you with, it’s that DevOps isn’t about fancy tools; it’s about making sure the kitchen runs smoothly even when no one’s watching the stove*.*

Thank you for Reading

You can follow me on LinkedIn and subscribe to my YouTube Channel, where I share more valuable content.

What’s a project you’re most proud of or learned the most from? I’d love to hear from you in the comments.

Building a Subtitle Service for Your App Using AWS Transcribe

Mubarak Alhazan — Mon, 02 Jun 2025 11:20:59 +0000

Introduction

Over the past two years, I've worked on three different video learning platforms. A recurring requirement across these projects has been subtitles, regardless of the target audience, tech stack, or business goal. Subtitles are essential for improving accessibility, accommodating users in sound-sensitive environments, and enhancing comprehension.

However, integrating subtitles at scale isn't as straightforward as toggling a switch. You need a system that can reliably handle transcription, process different media formats, and keep the architecture maintainable.

In this article, I’ll walk you through a reusable subtitle service architecture built using Amazon Transcribe. By the end, you’ll know how to:

Automatically transcribe video/audio content using Amazon Transcribe
Store and serve subtitle files securely from S3
Build a reusable subtitle service you can plug into any of your applications

Whether you're developing an e-learning app, a video streaming platform, or something in between, this approach will save you time and improve the user experience with minimal effort.

Understanding AWS Transcribe and the Project Goal

Amazon Transcribe is a fully managed automatic speech recognition (ASR) service that makes it easy to add real-time or batch transcription to your applications. It’s capable of converting speech from audio or video files into text, supporting a wide range of languages and input formats such as .mp3, .mp4, and more.

Transcribe outputs its results in a structured .json format, and with a little processing, you can convert this into common subtitle formats such as .vtt or .srt. This flexibility makes it a solid choice for building custom subtitle pipelines.

The goal of this article is to build a Node.js-based subtitle service that does the following:

Accepts a video or audio file URL stored in Amazon S3
Uses AWS Transcribe to generate a transcript
Converts the transcription into a .vtt subtitle file
Uploads the subtitle file back to S3 with public read access
Returns a public URL for use in video players

This modular flow ensures reusability, making it easy to integrate into any application that handles media playback

Setting Up Your AWS Environment

Before diving into code, you need to set up a few AWS resources. These are essential for securely storing your media files, triggering transcription jobs, and handling the resulting subtitle files.

S3 Bucket Setup

Create an S3 bucket where you’ll:

* Upload input media files (video/audio)

* Store output subtitle files (`.vtt` or `.srt`)

Important: The subtitle service we'll build will work even if your input media files are stored in a different bucket or even a different region. We’ll show this in a later section.

Suggested folder structure:

your-subtitle-service-bucket/
├── inputs/
│   └── my-video.mp4
└── outputs/
    └── my-video.vtt

Bucket Policy

You’ll need to attach a bucket policy to:

Allow Amazon Transcribe to write subtitle files to your bucket
Optionally allow public read access to subtitle files (or serve them via signed URLs)

Sample Bucket Policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::transcription-subtitles-files/*"
        },
        {
            "Sid": "AllowTranscribePutObject",
            "Effect": "Allow",
            "Principal": {
                "Service": "transcribe.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::transcription-subtitles-files/*"
        }
    ]
}

This policy permits Amazon Transcribe to write the output and optionally expose the files publicly (which you can adjust based on your use case).

CORS Configuration

If you plan to use the subtitle files in a frontend app (e.g., loading them into an HTML5 <video> tag), you’ll also need to enable CORS (Cross-Origin Resource Sharing) on your bucket. Without this, the browser will block requests from your frontend.

Sample CORS Configuration:

[
    {
        "AllowedHeaders": ["*"],
        "AllowedMethods": ["HEAD", "GET", "PUT", "POST", "DELETE"],
        "AllowedOrigins": ["*"],
        "ExposeHeaders": ["ETag"]
    }
]

This configuration allows your frontend (from any domain) to fetch subtitle files without CORS errors. You can adjust AllowedOrigins to restrict access to your app's domain for more control.

IAM Role

You’ll also need an IAM role or user with the right permissions to start transcription jobs and access media in S3.

Required Permissions:

* `transcribe:StartTranscriptionJob`

* `transcribe:GetTranscriptionJob`

* `s3:GetObject` – to fetch media

* `s3:PutObject` – to store subtitle files


**Minimal IAM Policy Example:**

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::your-subtitle-service-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "transcribe:StartTranscriptionJob",
        "transcribe:GetTranscriptionJob"
      ],
      "Resource": "*"
    }
  ]
}
```

Attach this to the process that triggers transcription, such as a backend service, Lambda function, or container task.

Region Considerations

Amazon Transcribe is not available in all regions. For best results:

* Choose a supported region like `us-east-1`, `us-west-2`, or `eu-west-1`

* Ensure your S3 buckets and transcription jobs are in the **same region** when possible to reduce latency and avoid cross-region errors

Writing the Transcription Service in Node.js

Let’s now build the core logic of our subtitle service using Node.js. The service will accept a media file (hosted in any S3 bucket or region), transcribe it using Amazon Transcribe, convert the result to .vtt, and upload it back to your configured bucket.

We’ll start by looking at the complete code and then explain each part step-by-step.

Full Code: `transcriptionService.mjs`

// transcriptionService.mjs

import {
  TranscribeClient,
  StartTranscriptionJobCommand,
  GetTranscriptionJobCommand,
} from "@aws-sdk/client-transcribe";
import {
  S3Client,
  PutObjectCommand,
  CopyObjectCommand,
  DeleteObjectCommand,
} from "@aws-sdk/client-s3";
import axios from "axios";
import vttConvert from "aws-transcription-to-vtt";
import { v4 as uuidv4 } from "uuid";

const REGION = "us-west-1"; // Change to your AWS Region
const S3_BUCKET = "transcription-subtitles-files"; // Bucket for storing VTT files and temporary videos
const S3_BASE_URL = `https://${S3_BUCKET}.s3.${REGION}.amazonaws.com`;

const transcribeClient = new TranscribeClient({ region: REGION });
const s3Client = new S3Client({ region: REGION });

async function transcribeAndGenerateSubtitle(videoS3Url) {
  let mediaFileUri = videoS3Url;
  let copiedKey = null;

  // Check if the video S3 URL matches our region bucket
  const { hostname, pathname } = new URL(videoS3Url);
  const bucketRegion = hostname.split(".")[2]; // extract region part like "us-east-1"

  if (bucketRegion !== REGION) {
    console.log(`[i] Video is from different region (${bucketRegion}), copying to correct region...`);

    // Copy the object into our transcription bucket under transcribed-video/
    const sourceBucket = hostname.split(".")[0]; // get bucket name
    const sourceKey = decodeURIComponent(pathname.slice(1)); // remove leading "/"

    copiedKey = `transcribed-video/${uuidv4()}-${sourceKey.split("/").pop()}`; // Create unique path

    await s3Client.send(new CopyObjectCommand({
      CopySource: `/${sourceBucket}/${sourceKey}`,
      Bucket: S3_BUCKET,
      Key: copiedKey,
    }));

    console.log(`[+] Copied video for transcription: ${copiedKey}`);
    mediaFileUri = `${S3_BASE_URL}/${copiedKey}`;
  }

  const jobId = `transcription-job-${uuidv4()}`;

  const startParams = {
    TranscriptionJobName: jobId,
    LanguageCode: "en-US",
    MediaFormat: "mp4",
    Media: {
      MediaFileUri: mediaFileUri,
    },
    OutputBucketName: S3_BUCKET,
  };

  // Start transcription job
  await transcribeClient.send(new StartTranscriptionJobCommand(startParams));
  console.log(`[+] Started transcription job: ${jobId}`);

  // Polling transcription job status
  let completed = false;
  let transcriptFileUri = '';
  while (!completed) {
    await new Promise((r) => setTimeout(r, 5000)); // wait 5 seconds
    const { TranscriptionJob } = await transcribeClient.send(
      new GetTranscriptionJobCommand({ TranscriptionJobName: jobId })
    );

    const status = TranscriptionJob.TranscriptionJobStatus;
    console.log(`[i] Job status: ${status}`);

    if (status === "COMPLETED") {
      completed = true;
      transcriptFileUri = TranscriptionJob.Transcript.TranscriptFileUri;
    } else if (status === "FAILED") {
      throw new Error(`Transcription job failed: ${TranscriptionJob.FailureReason}`);
    }
  }

  // Download transcription JSON
  const response = await axios.get(transcriptFileUri);
  const transcriptionJson = response.data;

  // Convert transcription to VTT
  const vttData = vttConvert(transcriptionJson);

  // Upload VTT file back to S3
  const vttKey = `subtitles/${jobId}.vtt`;

  await s3Client.send(new PutObjectCommand({
    Bucket: S3_BUCKET,
    Key: vttKey,
    Body: vttData,
    ContentType: "text/vtt",
  }));

  const vttUrl = `${S3_BASE_URL}/${vttKey}`;
  console.log(`[+] Subtitle uploaded: ${vttUrl}`);

  // delete the copied video if we created one
  if (copiedKey) {
    try {
      await s3Client.send(new DeleteObjectCommand({
        Bucket: S3_BUCKET,
        Key: copiedKey,
      }));
      console.log(`[i] Cleaned up temporary copied video: ${copiedKey}`);
    } catch (cleanupError) {
      console.warn(`[!] Failed to delete temporary video (safe to ignore):`, cleanupError.message);
    }
  }

  return vttUrl;
}

export { transcribeAndGenerateSubtitle };

Code Walkthrough

Setup AWS Clients

const transcribeClient = new TranscribeClient({ region: REGION });
const s3Client = new S3Client({ region: REGION });

Handle Cross-Region Video Files

If the input video is in a different region, we copy it into our main S3 bucket to avoid region mismatch errors.

const { hostname, pathname } = new URL(videoS3Url);
const bucketRegion = hostname.split(".")[2]; // extract region part like "us-east-1"

if (bucketRegion !== REGION) {
  // Copy logic here...
}

Start Transcription Job

We generate a unique job ID, configure the job with language and format, and send the request.

const jobId = `transcription-job-${uuidv4()}`;
const startParams = { ... };
await transcribeClient.send(new StartTranscriptionJobCommand(startParams));

Poll Until Completion

We periodically check the job status every 5 seconds until it completes or fails.

while (!completed) {
    await new Promise((r) => setTimeout(r, 5000)); // wait 5 seconds
    const { TranscriptionJob } = await transcribeClient.send(...);

    const status = TranscriptionJob.TranscriptionJobStatus;

    if (status === "COMPLETED") {
      completed = true;
      transcriptFileUri = TranscriptionJob.Transcript.TranscriptFileUri;
    } else if (status === "FAILED") {
      throw new Error(`Transcription job failed: ${TranscriptionJob.FailureReason}`);
    }
  }

Convert to .vtt Format

Once the transcription is ready, we fetch the JSON, convert it to VTT using the aws-transcription-to-vtt package, and upload it to S3.
```
const vttData = vttConvert(transcriptionJson);
await s3Client.send(new PutObjectCommand({ ... }));
```

Clean Up Temporary Files

If we copied the video earlier, we clean it up at the end.

if (copiedKey) {
  await s3Client.send(new DeleteObjectCommand({ ... }));
}

Design Choices That Make This Reusable

Accepts any media URI: Works across buckets and regions by copying to a known location, enabling use across teams or environments.
Job name namespacing: Each job uses a unique identifier (job-userId-timestamp) to prevent collisions, especially in high-concurrency environments.
Formats and language are parameterized: The design can easily support multilingual subtitles or alternate media types by tweaking just a few parameters.
Scoped resource access: All outputs and temporary assets are stored in a predictable subtitles/ and transcribed-video/ S3 path, making organization and lifecycle management easier.
Idempotent and modular logic: Small, composable functions enable wrapping into different execution models like Lambda functions, HTTP endpoints, or background queues.
Automatic cleanup of temporary files: Temporary copies are deleted after use to minimize cost and clutter.

Usage and Integration in Applications

Now that we have a reusable transcription service, let’s look at how to integrate it into real-world applications. This service is flexible enough to be used inside:

A backend API route (e.g., Express or Fastify)
A serverless Lambda function
A CLI tool or job processor

Sample Usage: Calling the Service

import { transcribeAndGenerateSubtitle } from "./transcriptionService.mjs";

const videoUrl = "https://some-bucket.s3.us-east-1.amazonaws.com/uploads/my-video.mp4";

transcribeAndGenerateSubtitle(videoUrl)
  .then((subtitleUrl) => {
    console.log("Subtitle available at:", subtitleUrl);
  })
  .catch((err) => {
    console.error("Failed to generate subtitles:", err.message);
  });

Once the function completes, it returns a URL pointing to the .vtt subtitle file stored in your configured S3 bucket. For example:

https://transcription-subtitles-files.s3.us-west-1.amazonaws.com/subtitles/transcription-job-2cdbfd78-a3cc-47f3-a414-dcb27ac163c9.vtt

Using the Subtitle in HTML Video

You can plug the subtitle URL directly into an HTML <video> tag using the <track> element:

<video controls crossorigin="anonymous" width="640">
  <source src="https://some-bucket.s3.amazonaws.com/uploads/my-video.mp4" type="video/mp4" />
  <track
    src="https://transcription-subtitles-files.s3.us-west-1.amazonaws.com/subtitles/transcription-job-2cdbfd78-a3cc-47f3-a414-dcb27ac163c9.vtt"
    kind="subtitles"
    srclang="en"
    label="English"
    default
  />
</video>

This will show a “CC” button that lets users toggle subtitles on/off in supported browsers, no extra libraries are required.

Gotchas & Best Practices

Before you ship this transcription service in production, here are a few key considerations and pitfalls to be aware of:

Region Mismatches

Amazon Transcribe can only access videos in S3 buckets in the same region as the transcription job. As implemented in our code, if the input video is hosted in a different region, we automatically copy it to the bucket in the target region before starting the transcription job. This ensures compatibility without requiring upstream changes to the source video hosting.

Transcribe Limitations

Amazon Transcribe has a few important limitations:

Maximum audio/video length: 4 hours
Maximum file size: 2 GB

Files exceeding these limits will cause the job to fail.

Tip: Validate media files ahead of time and reject or trim them before attempting transcription.

Conclusion

In this guide, we built a complete transcription service that:

Accepts any S3-hosted video file, even across regions.
Automatically transcribes it using Amazon Transcribe.
Converts the result into .vtt subtitle format.
Uploads the subtitle to a central S3 bucket for easy access.
Cleans up temporary files to keep things tidy.

The core function transcribeAndGenerateSubtitle(videoS3Url) handles the full lifecycle. It’s modular, serverless-friendly, and designed to plug into a web app, job queue, or CLI.

You can also extend the solution in the following directions:

Multi-language support: Pass LanguageCode dynamically to support users in multiple locales.
Real-time transcription: Consider integrating Amazon Transcribe Streaming for live captioning in calls or webinars.

You can find the complete code on GitHub: https://github.com/poly4concept/transcription-service

Thank you for reading

You can follow me on LinkedIn and subscribe to my YouTube Channel, where I share more valuable content. Also, Let me know your thoughts in the comment section

Securing Your Nginx Container with Let's Encrypt SSL Certificates

Mubarak Alhazan — Mon, 13 Jan 2025 06:00:17 +0000

Introduction

In the modern web landscape, securing web applications with SSL has become a non-negotiable best practice. Secure Sockets Layer (SSL) encryption protects sensitive user data from being intercepted, enhances trust and improves search engine rankings.

Nginx is a popular choice for serving web traffic, especially in containerized environments. Running Nginx in a container allows for lightweight, scalable, and portable deployments, making it a go-to solution for many DevOps engineers and system administrators.

Let's Encrypt is a free, and automated SSL certificate authority. With Let's Encrypt, obtaining and renewing SSL certificates is streamlined, removing the financial and operational barriers that once deterred many from implementing robust encryption.

This article will guide you through securing an Nginx server running inside a Docker container using Let's Encrypt SSL certificates. By the end, you will have a solid understanding of how to:

Configure your Nginx container for SSL.
Obtain and install Let's Encrypt certificates.
Automate certificate renewal for uninterrupted security.

Prerequisites

Before diving into securing your Nginx container with Let's Encrypt SSL certificates, ensure you meet the following prerequisites:

Familiarity with Docker and Nginx: You should have a basic understanding of Docker's containerization concepts and be comfortable working with Nginx as a web server.
A Server with a Public Domain: You'll need access to a server with a public IP address and a registered domain name. Additionally, you must have permission to modify your domain's DNS records to point it to your server.

Setting Up The Environment

The first step in securing your Nginx container with Let's Encrypt SSL certificates is to prepare your environment. This involves installing Docker, setting up Nginx in a container, and configuring a directory structure for Let's Encrypt.

Step 1: Install Docker and Set Up Nginx in a Container

Install Docker: Ensure Docker is installed on your server. If not, you can install it by following this official guide.
Pull the Nginx Docker Image: Pull the latest Nginx image from Docker Hub
```
docker pull nginx:latest
```
Run the Nginx Container: Launch an Nginx container, exposing port 80 for HTTP traffic and 443 for HTTPS traffic:
```
docker run --name nginx-container -d -p 80:80 -p 443:443 nginx
```
Confirm the container is running:
```
docker ps
```

Step 2: Create a Directory Structure for the Let's Encrypt Webroot

Let's Encrypt uses a webroot for the HTTP-01 challenge to verify domain ownership. Create a directory to act as the webroot:

sudo mkdir -p yourdirectory/certbot/webroot/.well-known/acme-challenge

This directory will hold the temporary files Let's Encrypt uses during the certificate issuance process.

Also, ensure that necessary permissions are granted to access the directory:

sudo chown -R $(whoami):$(whoami) yourdirectory/certbot/webroot  
sudo chmod -R 755 yourdirectory/certbot/webroot

Step 3: Mount the Webroot to the Nginx Container

To allow Let's Encrypt to place challenge files in your webroot, mount the directory into your Nginx container. Stop the running container, then rerun it with the volume mounted:

Stop and remove the container:

docker stop nginx-container
docker rm nginx-container

Run the container with the webroot mounted:

docker run --name nginx-container -d -p 80:80 \
-v yourdirectory/certbot/webroot:/var/www/certbot \
nginx

Test the setup by creating a test file in the webroot:
```
echo "Let's Encrypt Webroot Test" > yourdirectory/certbot/webroot/test.html
```
Access the file in your browser:
```
http://<your-domain>/test.html
```
Once you see the test file content in your browser, your environment is correctly set up for Let's Encrypt.

Configuring Nginx for SSL

Securing the Nginx server for Let's Encrypt SSL involves configuring a dedicated location block to handle ACME HTTP-01 challenges and ensuring the container reflects these changes.

Step 1: Add a Dedicated Location Block for ACME Challenges

Let's Encrypt uses the ACME HTTP-01 challenge to validate your domain ownership. For this to work, you'll need to configure a specific location block in your Nginx configuration to serve the challenges from the webroot.

 location /.well-known/acme-challenge/ {
     root /var/www/certbot;
 }

Step 2: Update the Nginx Configuration

To make the configuration process easily maintainable, you can create an nginx.conf file in your local directory. The updated configuration file should include the location block defined above.

Here’s an example of how your nginx.conf file might look:

events {}
http {
    # Include mime types
    include       mime.types;
    default_type  application/octet-stream;
    # Proxy settings
    sendfile        on;
    keepalive_timeout 65;

    #... other ngnix configuration

    # Server block for HTTPS
    server {  
        listen 443 ssl;  
        server_name yourdomain.com;  # Replace with your domain

        #... other server configuration
    }  

    # Server block for HTTP
    server {
        listen 80;
        server_name yourdomain.com www.yourdomain.com;

        location /.well-known/acme-challenge/ {
            root /var/www/certbot;
        }
    }
}

Once the file is ready, stop and remove the container:

docker stop nginx-container
docker rm nginx-container

Then rerun the container with nginx.conf file mounted to it as a volume:

docker run --name nginx-container -d \
  -p 80:80 \
  -p 443:443 \
  -v yourdirectory/nginx.conf:/etc/nginx/nginx.conf \
  -v yourdirectory/certbot/webroot:/var/www/certbot \
  nginx

Installing and Using Certbot

Certbot is a widely used client for obtaining SSL certificates from Let's Encrypt. In this section, we’ll install Certbot, generate an initial certificate, and configure Nginx to use it for secure communication.

Step 1: Install Certbot on the Host Machine

Install Certbot using your Linux distribution’s package manager.

sudo apt update
sudo apt install certbot

You can also check the Certbot official documentation and select your operating system for tailored guidance.

Step 2: Obtain the Initial SSL Certificate

Run Certbot with the webroot plugin, pointing to the directory mounted as the webroot in your Nginx container:

sudo certbot certonly --webroot -w yourdirectory/certbot/webroot -d yourdomain.com

Once successful, Certbot will generate the certificate files, typically found in etc/letsencrypt/live/yourdomain.com/.

Step 3: Update the Nginx Configuration

Once the certificate has been issued, update the nginx.conf file to use SSL. Open the nginx.conf file in your local directory and update the HTTPS server block with the following:

# Server block for HTTPS
server {  
    listen 443 ssl;  
    server_name yourdomain.com;  # Replace with your domain  

    # SSL Certificates  
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;  
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;  

    # SSL Settings  
    ssl_protocols TLSv1.2 TLSv1.3;  
    ssl_prefer_server_ciphers on;  
    ssl_ciphers HIGH:!aNULL:!MD5;  

    # Other https server configuration...  
}

To ensure all HTTP traffic is redirected to HTTPS, update the HTTP server block in the same nginx.conf file:

# Server block for HTTP
server {  
    listen 80;  
    server_name yourdomain.com;  

    location /.well-known/acme-challenge/ {
            root /var/www/certbot;
    }

    # Redirect all HTTP traffic to HTTPS  
    location / {  
        return 301 https://$host$request_uri;  
    }  
}

After updating the configuration file, stop and remove the container:

docker stop nginx-container
docker rm nginx-container

Then rerun the container with an additional volume for the SSL certificates:

docker run -d --name nginx-container \
  -p 80:80 -p 443:443 \
  -v yourdirectory/nginx.conf:/etc/nginx/nginx.conf \
  -v /etc/letsencrypt:/etc/letsencrypt:ro \
  -v yourdirectory/certbot/webroot:/var/www/certbot \
  nginx

Step 4: Verify SSL is Working

Open your domain in a browser and ensure it loads over HTTPS.
Alternatively, use curl to test the connection:
```
curl -I https://yourdomain.com
```

If everything is set up correctly, you should see a response with a status code of 200 and the protocol HTTPS.

Automating Certificate Renewal

SSL certificates issued by Let's Encrypt are valid for 90 days, so automating the renewal process ensures your web services remain secure without manual intervention. In this section, you’ll configure a cron job for certificate renewal, test it, and automate the Nginx container reload after a successful renewal.

Step 1: Set Up a Renewal Cron Job for Certbot

To ensure certificates are renewed before expiration, you can configure a cron job. Open the cron configuration for editing:

crontab -e

Add the following line to schedule a daily check for renewal:

0 0 * * * sudo certbot renew --webroot -w yourdirectory/certbot/webroot --quiet && docker exec nginx-container nginx -s reload

Here’s a breakdown of the command:

sudo certbot renew: Automatically renews certificates close to expiration.
--webroot -w yourdirectory/certbot/webroot: Specifies the webroot directory for the renewal challenge.
--quiet: Suppresses non-critical output for cleaner logs.
docker exec nginx-container-name nginx -s reload: Reload the Nginx container to apply the renewed certificate.

Step 2: Test the Cron Job Manually

Before relying on automation, test the command manually to ensure it works as expected:

sudo certbot renew --webroot -w yourdirectory/certbot/webroot --dry-run

The --dry-run flag simulates the renewal process without actually renewing the certificates. Check for a success message.

If successful, run the reload command manually to confirm Nginx applies the changes:

docker exec nginx-container nginx -s reload

If both commands are successful, you can be sure the Cron job will work effectively.

Conclusion

Securing your Nginx server with Let's Encrypt SSL certificates enhances your web services’ security and ensures compliance with modern web standards. By leveraging Docker for containerized deployment and Certbot for automated SSL certificate management, you can achieve a streamlined, scalable, and secure web environment.

The steps outlined in this guide—from setting up the environment to automating certificate renewals—are designed to simplify the process, even for those new to containerized web hosting. Implementing SSL through Let's Encrypt eliminates traditional barriers such as cost and complexity, making it accessible to developers and organizations of all sizes.

With your Nginx container now secured, you can focus on other aspects of application development and deployment, confident that your web traffic is encrypted and protected.

Thank You For Reading

You can follow me on LinkedIn and subscribe to my YouTube Channel, where I share more valuable content. Also, Let me know your thoughts in the comment section.

Happy Deploying 🚀

Automate Docker Deployments to Your Server Using GitHub Actions and Amazon ECR

Mubarak Alhazan — Sun, 20 Oct 2024 18:22:35 +0000

Introduction

In a recent project, I had to deploy a backend application on a server hosted on a local cloud platform. Cost-saving considerations drove the choice to use a local cloud, but it came with its limitations—particularly the absence of a built-in CI/CD service. I needed to implement a custom deployment process, and GitHub Actions emerged as the perfect solution to automate the workflow.

I created a deployment strategy that leverages GitHub Actions to build the application's Docker image, push it to Amazon ECR (Elastic Container Registry), and then pull the image onto the server for execution. This approach offers several advantages. By handling the image build externally on ECR, I could reduce the resource load on the server, preventing excessive disk space and memory consumption. Additionally, using ECR allowed us to manage our images more effectively, making it easier to implement rollback policies in case a deployment failed.

In this article, I'll walk you through creating a GitHub Action workflow to automate Docker deployments. I'll cover the steps to build an application image, push it to ECR, and deploy it to a server.

Prerequisites

To follow along with this guide, you'll need:

A GitHub repository where the deployment workflow will be set up, with access to add secrets for sensitive information.
An AWS account and an IAM user with permission to interact with ECR.
A server where the application will be deployed, with SSH access configured.
A basic understanding of Docker and GitHub Actions

Amazon ECR Setup

We'll use Amazon Elastic Container Registry (ECR) to store and manage Docker images for our deployment. Follow these steps to set up the ECR repository and configure access.

Create a Private Image Repository

Navigate to the Amazon ECR console. Create a new private image repository to store your Docker images. Leave the default settings, with the image tag set as mutable, which allows you to update images tagged with the same name.
Set Up a Lifecycle Policy

Over time, the ECR repository may accumulate a large number of images, which can take up storage space. To manage this, you can set up a lifecycle policy to automatically delete older or unneeded images. For example, I configured a rule to delete images older than 30 days.

Configure an IAM Role for GitHub OIDC Provider

Instead of storing long-term AWS credentials in GitHub Secrets, use GitHub’s OpenID Connect (OIDC) provider to grant access to AWS resources. Set up an IAM role that allows GitHub Actions to authenticate and perform ECR operations. You can find detailed instructions on setting up an OIDC role in this article.
Create an IAM User for AWS CLI Access on the Server

In addition to the OIDC role, you need to create an IAM user to set up the AWS CLI on the server. This user should have the least privilege necessary, with permissions restricted to the specific ECR repository being used. Here’s an example of IAM policy to grant access only to the relevant repository:
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetAuthorizationToken"
      ],
      "Resource": "arn:aws:ecr:<region>:<account-id>:repository/<repository-name>"
    }
  ]
}
```
This policy allows the user to pull images from the specified ECR repository, ensuring access is as limited as possible.

Server Configuration

For this deployment, I set up a server on a local cloud platform, but these instructions will work for any server configuration. If you are using AWS, you can follow this guide to create an EC2 instance.

Install Docker Engine

The server needs Docker installed to run the application as a container. Containerization ensures that the application runs consistently across environments. To install Docker Engine, follow this tutorial, which covers the installation process for various operating systems.
Create a Non-Root User for SSH Access

To securely manage server access from GitHub Actions, create a dedicated user account rather than using the root user. This setup limits access and follows best practices for securing server resources. If you’re logged in as the root user, you can create a new user by running the following command (assuming a Linux server):
```
sudo useradd -m deploy-user
```
You can find more information about creating user accounts in this article.

After creating the user, switch to the user’s directory:
```
sudo su - deploy-user
```
Add the User to the Docker Group

To allow the deploy-user to run Docker commands without needing sudo, add the user to the Docker group:
```
sudo usermod -aG docker deploy-user
```
This configuration lets the GitHub Actions pipeline execute Docker commands seamlessly. You can learn more about that here.
Set Up SSH Key Pair for GitHub Actions

You’ll need an SSH private key from the GitHub Actions workflow to connect to the server. You can use the existing key pair from the server's creation, or generate a new one specifically for this pipeline. This article details how to create an SSH key pair.
Configure AWS CLI on the Server

To pull images from Amazon ECR directly from the server, you need to set up the AWS CLI using the IAM user created in the ECR setup. If you haven’t already, install the AWS CLI on the server. You can follow this guide for installation instructions based on your operating system.

Run the following command to configure the AWS CLI:
```
aws configure
```
You'll be prompted to enter the IAM user's AWS Access Key ID, AWS Secret Access Key, Default region name, and Default output format. The region should match the AWS region where your ECR repository is located.

GitHub Action Workflow

The next step is setting up a GitHub Action workflow that automates the deployment process. The workflow will perform the following: checking out the code, building a Docker image, pushing it to the Amazon ECR repository, and then pulling and running the image on the server. Below is a breakdown of the script and an explanation of each step.

GitHub Action Script

Here's what the GitHub Action script looks like:

name: Deploy to staging
on:
  push:
    branches:
      - staging

env:
  AWS_REGION: aws-region           
  ECR_REGISTRY_URL: registry-url

jobs:
  deploy-api:
    name: Deploy Backend API
    runs-on: ubuntu-latest

    permissions:
      id-token: write
      contents: read

    steps:

    # Step 1: Checkout the code
    - name: Checkout the code
      uses: actions/checkout@v4

    # Step 2: Configure AWS credentials
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v4 
      with:
        role-to-assume: arn:aws:iam::123456789012:role/my-github-actions-role
        aws-region: ${{ env.AWS_REGION }}

    # Step 3: Login to Amazon ECR
    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v2  

    # Step 4: Build, Tag, and Push Docker Image to ECR
    - name: Build, tag, and push Docker image to ECR
      run: |
        TAG=$(git rev-parse --short ${{ github.sha }})
        docker build -t $ECR_REGISTRY_URL/${{ secrets.APP_NAME }}:$TAG .   
        docker tag $ECR_REGISTRY_URL/${{ secrets.APP_NAME }}:$TAG $ECR_REGISTRY_URL/${{ secrets.APP_NAME }}:latest   
        docker push $ECR_REGISTRY_URL/${{ secrets.APP_NAME }}:$TAG
        docker push $ECR_REGISTRY_URL/${{ secrets.APP_NAME }}:latest

    # Step 5: SSH into the server, pull the latest image, and restart the container
    - name: Deploy to server
      uses: appleboy/ssh-action@v1.0.3
      with:
        host: ${{ secrets.SSH_HOST }}
        username: ${{ secrets.SSH_USER }}
        key: ${{ secrets.SSH_PRIVATE_KEY }}
        script: |
          aws ecr get-login-password --region ${{ env.AWS_REGION }} | docker login --username AWS --password-stdin ${{ env.ECR_REGISTRY_URL }}
          docker pull ${{ env.ECR_REGISTRY_URL }}/${{ secrets.APP_NAME }}:latest
          docker stop ${{ secrets.APP_NAME }}
          docker system prune -f
          docker run --env-file .env --name ${{ secrets.APP_NAME }} --restart unless-stopped -d -p 80:${{ secrets.APP_PORT }}  ${{ env.ECR_REGISTRY_URL }}/${{ secrets.APP_NAME }}:latest

Explanation of Each Step

Checkout the Code: This step uses the actions/checkout action to clone the repository into the GitHub Actions runner. It ensures the latest code from the staging branch is available for building.
Configure AWS Credentials: Here, the aws-actions/configure-aws-credentials action is used to assume an IAM role in AWS that allows access to ECR. This configuration allows GitHub Actions to authenticate securely using GitHub's OIDC provider.
Login to Amazon ECR: The aws-actions/amazon-ecr-login action logs into the ECR registry, allowing Docker commands to push and pull images from the ECR repository.
Build, Tag, and Push Docker Image to ECR:

* The image is built using `docker build` and tagged with the short Git commit hash for versioning.

* The image is then tagged `latest` for easy access to the most recent build.

* Both the versioned tag and the `latest` tag are pushed to the ECR registry.

Deploy to Server:

* The `appleboy/ssh-action` action is used to SSH into the server.

* It logs in to the ECR registry, pulls the latest image, stops the running container, performs a system cleanup, and then runs the new image.

* The `--restart unless-stopped` flag ensures that the container automatically restarts if the server restarts.

GitHub Secrets

You need to configure the following secrets in your GitHub repository for this workflow to function correctly:

APP_NAME: The name of the application, used as the ECR repository name.
SSH_HOST: The IP address or domain name of the server.
SSH_USER: The username for SSH access.
SSH_PRIVATE_KEY: The private key used for SSH authentication.
APP_PORT: The port on which the application should be exposed (e.g., 80).

Once you commit to the specified branch, this workflow will be triggered automatically. It will build the Docker image, push it to ECR, and deploy it to the server. You can monitor the progress and view the workflow's execution details in the Actions tab of the repository.

Common Pitfalls and Troubleshooting

Here are some potential issues that may arise while setting up this workflow and how to troubleshoot them:

Access Denied When Pushing to ECR

If you encounter an access denied error while pushing images to ECR, confirm that the GitHub Actions workflow has the correct permissions and that the ECR repository policy is set to allow your IAM role or user. Also, verify that the workflow script correctly references the ECR repository URI.
SSH Connection Issues

If the SSH connection to the server fails, ensure that:

* The SSH private key added to the GitHub Secrets matches the public key on the server.

* The server's firewall settings allow inbound connections on the specified SSH port (usually port 22).

* The `deploy-user` has been correctly set up and has the required permissions to execute commands.

Docker Commands Failing on the Server

If Docker commands fail on the server, ensure that:

* The deploy-user is part of the Docker group to allow non-sudo Docker commands.


There are enough system resources (CPU, memory, disk space) for Docker operations, especially during the image pull or run stages.

Conclusion

Automating Docker deployments using GitHub Actions and Amazon ECR streamlines the process of building, deploying, and managing containerized applications. By leveraging this workflow, you can separate the build process from the deployment, reduce the load on your server, and maintain a clean, versioned history of your application images in ECR.

In this guide, we walked through setting up an Amazon ECR repository, configuring a server, and creating a GitHub Actions workflow that automatically builds and pushes Docker images to ECR, and then deploys them to the server.

Thank You For Reading

You can follow me on LinkedIn and subscribe to my YouTube Channel, where I share more valuable content. Also, Let me know your thoughts in the comment section.

Happy Deploying 🚀

Seamlessly Migrating Frontend Deployment Across AWS Accounts

Mubarak Alhazan — Thu, 03 Oct 2024 12:08:33 +0000

How to Move S3 Buckets, CloudFront Distributions, and Route 53 Hosted Zones

Introduction

I recently worked on a project to migrate an entire application deployment from one AWS account to another. While migrating individual resources between accounts is common, I couldn't find a clear, straightforward guide on how to move a frontend deployment. This left me piecing together different AWS resources and best practices to ensure a smooth transition.

The frontend we were working with is a React application deployed using a typical AWS architecture: an S3 bucket to host the static files, a CloudFront distribution placed in front to improve performance and security, and a Route 53 hosted zone to route traffic to the CloudFront distribution. Given how common this setup is in AWS, I wanted to share the step-by-step process of migrating this architecture across AWS accounts.

In this article, we’ll walk through how to efficiently migrate the entire Frontend architecture while ensuring minimal downtime and a smooth transition for our deployment.

Pre-Migration Checklist

Before starting the migration, it's important to identify the key AWS resources involved and ensure we have everything prepared to make the transition seamless. Here's a checklist of what we'll need to migrate:

Resources To Migrate

S3 Buckets

In our case, we have four S3 buckets, each holding the static assets for different application portals.
CloudFront Distributions

Each S3 bucket has an associated CloudFront distribution, improving performance and security. Like the S3 buckets, we will migrate four CloudFront distributions — one for each bucket.
ACM Certificate

We need an ACM certificate to enable SSL and secure our frontend applications. Since all the applications are under the same domain, we can create a single ACM certificate and use it across all CloudFront distributions. This will ensure that each application serves traffic over HTTPS.
Route 53 DNS Records

For each subdomain, there is a corresponding DNS record in Route 53 that routes traffic to the correct CloudFront distribution. Additionally, we'll need to create DNS records to validate the ACM certificate.

In this guide, we’ll walk through the process for one frontend app, but the same steps can be repeated for the remaining applications.

Access and Permissions

To migrate these resources without issues, you need access to both the source AWS account (where the resources currently reside) and the target AWS account (where the resources will be moved). Adequate permissions to create, modify, and delete the mentioned resources in both accounts will ensure a smooth migration. Here is an IAM policy for all the access required for this migration.

Migrating S3 Buckets

The first step in the migration is moving the static assets from the S3 buckets in the source AWS account to new buckets in the target AWS account. Here's how we approach this migration:

Creating a New Bucket in the Target Account

Since S3 bucket names must be globally unique, you might not be able to create a new bucket with the same name as the one in the source account.

In addition, make sure that the new bucket is configured for static website hosting, which is crucial for serving your React application. You can enable this feature via the AWS Console or the AWS CLI. You can refer to this resource to learn more about setting up an S3 bucket for static website hosting.
Copying Static Assets to the Target Bucket

Once the new bucket is created, the next step is to transfer the static assets (such as HTML, CSS, JS, and media files) from the source bucket to the target bucket. You can achieve this with the following method:

Method 1: Using AWS CLI
```
aws s3 sync s3://source-bucket-name s3://destination-bucket-name --acl bucket-owner-full-control
```
This command ensures that all files from the source bucket are copied to the target bucket, with appropriate access permissions (bucket-owner-full-control).

Method 2: Manual Download and Upload

For smaller sets of files, you can download the assets from the source bucket and upload them to the new bucket via the AWS Console. While this method is simple, it’s not ideal for large datasets or continuous deployment.

Method 3: Using a CI/CD Pipeline to Deploy to the Target Bucket

In our case, an existing CI/CD pipeline deployed our React frontend directly to the S3 bucket from GitHub. Instead of manually copying the files, we updated the pipeline to deploy to the new bucket in the target account. After switching the pipeline’s destination, we triggered a redeployment to ensure that the latest version of the application was in the new S3 bucket.

This method is preferable because having a CI/CD pipeline allows for ongoing updates to the application. You can follow this resource to learn how to create a CodePipeline that deploys a React app to an S3 bucket.

Migrating ACM Certificates

One important aspect of migrating a frontend deployment is ensuring SSL certificates are set up to secure your applications. In AWS, these certificates are managed through the AWS Certificate Manager (ACM), but it's important to note that ACM certificates cannot be transferred between AWS accounts. This means we need to create a new certificate in the target account.

To start, navigate to the Certificate Manager in the AWS Console of the target account. Select Request a certificate and choose a public certificate, as it will be used with CloudFront.

As part of the request, you need to add subdomains the certificate will secure. These subdomains represent the frontend applications, which will later be served through CloudFront distributions. Here’s a visual representation of what that looks like:

After adding the necessary subdomains, you can leave the other settings at their defaults and proceed to request the certificate.

At this point, the certificate request will be marked as "Validation in progress." Since we selected DNS validation, AWS will provide CNAME records that need to be added to the DNS configuration of your domain. This step is crucial, as it verifies ownership of the subdomains. The pending validation status will appear like this:

Next, you’ll need to add the provided DNS validation records to the hosted zone in the source account. This is required to complete the validation process. Take note that Route 53 automatically pre-fills the base domain when adding the CNAME records, so you only need to enter the part before it.

Once the DNS records are in place, ACM will automatically detect the validation, and the certificate’s status will change to Issued. With the certificate validated, you’re now ready to attach it to your CloudFront distributions in the following steps.

Migrating CloudFront Distributions

Similar to ACM certificates, CloudFront distributions cannot be directly transferred between AWS accounts. As a result, we’ll need to recreate the distribution in the target account.

To begin, navigate to the CloudFront section in the AWS Console of the target account and select Create Distribution. During the creation process, you’ll need to choose the origin domain, which in this case is the S3 bucket containing the static assets for your application. Make sure you select the correct bucket and use website endpoint.

Once the origin is set, adjust the other settings based on your specific requirements for caching, behavior, or access logging.

In the Settings section of the distribution setup, you’ll need to specify the alternate domain name (CNAME), which is the subdomain that you want to associate with the distribution (e.g. blog.poly4.dev). Additionally, you’ll need to attach the SSL certificate that was created in the previous step. This ensures that the subdomain can securely communicate with the CloudFront distribution over HTTPS. Here's an example of what it looks like:

Before finalizing the distribution creation, there’s an important step: Remove the subdomain from the existing distribution in the source account. This is because a subdomain cannot be assigned to two CloudFront distributions at the same time. You may need to wait for the changes in the source distribution to deploy.

Once you’ve created the new distribution, copy the distribution endpoint URL, which looks something like d1234abcdef.cloudfront.net.

The final step is to update the DNS records in the Route 53 hosted zone for the subdomain. Replace the old CloudFront distribution endpoint with the new one, so that traffic to the subdomain routes to the newly created CloudFront distribution.

Migrating Route 53 Hosted Zones

At this stage, resources in the target account — such as S3, CloudFront, and ACM certificates — serve traffic for the application. However, to minimize downtime, the DNS records in the source account were updated first, ensuring that the traffic routing remained uninterrupted during the transition.

The next step is to migrate the hosted zones to the target account to manage DNS records within the same account as other resources. Navigate to Route 53 in the AWS Console of the target account and select Create Hosted Zone. Use the same domain name as the one in the source account.

After creating the new hosted zone, you need to manually add all the DNS records from the source account to the new hosted zone in the target account. Each record must match exactly, including the record types (A, CNAME, TXT, etc.), values, TTLs, and other configurations. If you have a large number of DNS records, manually recreating them can be time-consuming. Here is a resource that explains how to export and import DNS records between hosted zones using the AWS CLI.

Once the records are added, compare the DNS records between the source and target accounts to ensure everything matches.

The final step is to update the name server records at your domain registrar to point to the new hosted zone in the target account. The name servers are provided by AWS when you create the hosted zone and can be found in the Hosted Zone details tab. This ensures that future traffic is routed through the new hosted zone in the target account.

Post-Migration

After successfully migrating all resources and updating DNS records, it is essential to allow time for DNS propagation. It is recommended to wait at least 48 hours to ensure traffic has fully propagated to the new resources. During this time, monitor your application to verify that everything is functioning as expected.

After confirming that the migration is complete and the new resources are handling traffic smoothly, you can optionally delete the resources in the source account. This ensures no residual costs or conflicts from the old infrastructure.

Conclusion

Migrating a front-end deployment between AWS accounts can seem complex due to the individual services involved—S3, CloudFront, ACM, and Route 53. However, by breaking down the process step-by-step, it becomes more manageable.

In this guide, we walked through the necessary stages to ensure a smooth migration, from setting up new resources in the target account to updating DNS records and minimizing downtime.

Thank you for reading

You can follow me on Linkedin and subscribe to my YouTube Channel where I also share more valuable content. Also, Let me know your thoughts in the comment section.

Efficiently Testing Asynchronous React Hooks with Vitest

Mubarak Alhazan — Wed, 10 Apr 2024 20:59:20 +0000

Introduction

While working on a fairly large frontend project, a seemingly minor change in the backend's error message structure triggered a cascade of changes across numerous files on the front end, making it a notably hard task to rectify. Determined to spare myself and my team from such headaches in the future, I created a custom useApi hook. This hook was tailored for handling API calls throughout the application, ensuring that any future changes to data structure could be managed from a single file.

Realizing the pivotal role of this hook across the codebase, the necessity of writing robust tests became apparent, In this article, we'll walk through the process of efficiently testing asynchronous React Hooks, drawing insights from my experience with this useApi hook.

Dependencies

We should have a React project set up and running. We can initialize the project with Vite using the command npm create vite@latest.

To replicate this test, we need to install the following dependencies:

Vitest: our main testing framework
JSDOM: DOM environment for running our tests
React Testing Library: provides utilities to make testing easier
MSW: library to mock API calls for the tests.

To do so, we run the following command:

npm install -D vitest jsdom @testing-library/react msw
#OR
yarn add -D vitest jsdom @testing-library/react msw

In vitest.config.js (or vite.config.js for Vite projects), we add the following test object:

export default defineConfig({
  //...
  test: {
    global: true,
    environment: 'jsdom',
  },
})

Now we can run our test with npx vitest .

The `useApi` Hook

import { useState } from "react";
import axios from "axios";

export const useApi = (url, method, body, headers) => {
  const [data, setData] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState("");

  const callApi = async () => {
    setLoading(true);
    try {
      const response = await axios({ url, method, body, headers });
      if (response.data === null || response.data === undefined) {
        setData([]);
      }
      setData(response.data);
    } catch (error) {
      setError(error.message);
    }
    setLoading(false);
  };

  return [data, loading, error, callApi];
};

The hook is designed to handle API calls within the application and offers flexibility to adapt to various API scenarios. It accepts the following parameters: url , method, body , and headers .

The hook uses axios to execute the API call to the specified URL which handles gracefully cases when certain parameters like the request body or headers are not provided.

The useApi hook returns an array containing the fetched data, a boolean flag indicating the loading state, any encountered errors, and a function callApi to initiate the API request.

A sample usage of this hook to make a POST request will look like this:

const [createResponse, creating, createError, createRecord] = useApi(
    "https://jsonplaceholder.typicode.com/posts", "POST", body
  );

In this example, createResponse holds the response data from the API call, creating indicates whether the request is currently in progress, createError captures any errors encountered during the request, and createRecord is the function to initiate the API call.

By encapsulating API logic within the reusable useApi hook, we can enhance code maintainability, improve readability, and ensure consistent handling of asynchronous operations throughout our application.

Now let's test 🪄:

Testing the Hook

We will test a scenario when the useApi makes a successful GET request.

Default Value Test

We start by testing the default return value of the useApi hook. Using renderHook from @testing-library/react. renderHook returns an object instance containing result property from which we can access the hook's return value.

import { renderHook} from "@testing-library/react";
import { useApi } from "./useApi";

describe("useApi", () => {
    test("should fetch data on callApi for GET request", async () => {
        const { result } = renderHook(() =>
          useApi("https://api.example.com/items", "GET")
        );

        expect(result.current[0]).toBe(null); // Data should be null initially
        expect(result.current[1]).toBe(false); // Loading state should be false initially
        expect(result.current[2]).toEqual(""); // Error should be an empty string initially
    });

})

Testing the`callApi` Function

Next, we test the behaviour when the callApi function is invoked. We use act to simulate the function call and waitFor to await its asynchronous result. Here's the test case:

import { act, renderHook, waitFor } from "@testing-library/react";
import { useApi } from "./useApi";

const mockData = [
  { id: 1, item: "Leanne Graham" },
  { id: 2, item: "Ervin Howell" },
];

describe("useApi", () => {
    test("should fetch data on callApi for GET request", async () => {
        const { result } = renderHook(() =>
          useApi("https://api.example.com/items", "GET")
        );

        expect(result.current[0]).toBe(null);
        expect(result.current[1]).toBe(false);
        expect(result.current[2]).toEqual("");

        act(() => {
          result.current[3]();// Invoke callApi function
        });

        expect(result.current[1]).toBe(true); // Loading state should be true during API call
        await waitFor(() => {
          // Wait for API call to complete
          expect(result.current[1]).toBe(false); // Loading state should be false after API call
          expect(result.current[0]).toEqual(mockData); // Data should match mock data
        });
    });
})

In the code above, we used waitFor to await the result of the callApi function because it is an asynchronous function. waitFor accepts a callback and returns a Promise that resolves when the callback executes successfully.

Mocking the Api Call

In the above test scenarios, we directly called the API, which is not ideal for unit tests as it can lead to dependencies on external services and unpredictable test outcomes. Instead, we should mock the API call to isolate the behaviour of the hook and ensure reliable and consistent testing.

Using MSW for API Mocking

To mock the GET request, we'll define a mock handler using MSW like this:

import { afterAll, afterEach, beforeAll /**... */ } from "vitest";
import { HttpResponse, http } from "msw";
import { setupServer } from "msw/node";

const mockData = [
  { id: 1, item: "Leanne Graham" },
  { id: 2, item: "Ervin Howell" },
];

const handlers = [
  http.get("https://api.example.com/items", () => {
    return HttpResponse.json(mockData);
  })
];

// Set up the mock server with the defined handlers
const server = setupServer(...handlers);

describe("useApi", () => {
    // Start the mock server before running the tests
    beforeAll(() => server.listen({ onUnhandledRequest: "error" }));
    // Reset mock server handlers after each test
    afterEach(() => server.resetHandlers());
    // Close the mock server after all tests have run
    afterAll(() => server.close());

    /** Tests will go here **/
})

In the above code:

We define a mock handler using http.get() from MSW. This handler intercepts GET requests and responds with the mockData
We then set up a mock server using setupServer() from MSW and pass the defined handlers to it.
Just before running the tests, we start the mock server (server.listen()), ensuring that it intercepts requests during test execution.
After each test, we reset the mock server handlers to ensure a clean state for the next test.
Finally, after all tests have run, we close the mock server to clean up resources (server.close()).

And that's it, we can test the hook now.

Other Scenarios

Using a similar structure, we can write a test for other scenarios for the useApi hook. Let's consider a scenario where a POST request fails, such as due to authentication issues:

import { afterAll, afterEach, beforeAll, describe, expect, test } from "vitest";
import { HttpResponse, http } from "msw";
import { setupServer } from "msw/node";
import { act, renderHook, waitFor } from "@testing-library/react";
import { useApi } from "./useApi";

const handlers = [
  //other handlers...
  http.post("https://api.example.com/login", ({ request }) => {
    if (!request.headers.has("cookie")) {
      throw new HttpResponse(null, { status: 401 });
    }
  }),
];
const server = setupServer(...handlers);

describe("useApi", () => {
    beforeAll(() => server.listen({ onUnhandledRequest: "error" }));
    afterEach(() => server.resetHandlers());
    afterAll(() => server.close());

   test("post request error", async () => {
    const body = { name: "test", password: "test" };
    const { result } = renderHook(() =>
      useApi("https://api.example.com/login", "post", body)
    );

    expect(result.current[0]).toBe(null);
    expect(result.current[1]).toBe(false);
    expect(result.current[2]).toEqual("");

    act(() => {
      result.current[3]();
    });

    expect(result.current[1]).toBe(true);
    await waitFor(() => {
      expect(result.current[1]).toBe(false);
      // Expect error message
      expect(result.current[2]).toEqual("Request failed with status code 401");
      expect(result.current[0]).toEqual(null);
    });
  });
})

Conclusion

In this article, we learnt how to test asynchronous React hooks using the React Testing Library and Vitest package. We also learn how to mock requests using the MSW package.

Thank you for reading

I appreciate the time we spent together. I hope this content will be more than just text. Follow me on Linkedin and subscribe to my YouTube Channel where I plan to share more valuable content. Also, Let me know your thoughts in the comment section.

DEV Community: Mubarak Alhazan

How to Import Existing AWS Resources into the Serverless Framework (Using CloudFormation Import)

Introduction

Understanding The Challenge

The Approach that Worked

Step 1: Scan The Existing Resources

Step 2: Generate a Template for the Existing Stack

Step 3: Import the Resources

Step 4: Define the Resources in serverless.yml

Things to Watch Out For When Importing Resources

Conclusion

Webflow CMS Behind CloudFront: Serving Dynamic and Static Pages on the Same Domain

Introduction

The Architecture That Works

Webflow as an Origin (and the Verification Gotcha)

Step-by-Step Implementation

1. Keep DNS Pointing to CloudFront

2. Add Webflow as a Custom Origin in CloudFront

3. Configure Path-Based Behaviours

4. Temporarily Point DNS to Webflow for Verification

5. Revert DNS to CloudFront

6. Publish the Site in Webflow

Conclusion

Thank you for reading

Cooking Without Burning: My DevOps Doings in the Past Few Years

From Code to Cloud

Automating AWS with Terraform

Deploying on Bare Server

Migrating Infrastructure Across AWS Accounts

Documenting the DevOps Process

Reflections: Growth Beyond the Pipeline

Thank you for Reading

Building a Subtitle Service for Your App Using AWS Transcribe

Introduction

Understanding AWS Transcribe and the Project Goal

Setting Up Your AWS Environment

Writing the Transcription Service in Node.js

Full Code: transcriptionService.mjs

Code Walkthrough

Design Choices That Make This Reusable

Usage and Integration in Applications

Gotchas & Best Practices

Conclusion

Thank you for reading

Securing Your Nginx Container with Let's Encrypt SSL Certificates

Introduction

Prerequisites

Setting Up The Environment

Step 1: Install Docker and Set Up Nginx in a Container

Step 2: Create a Directory Structure for the Let's Encrypt Webroot

Step 3: Mount the Webroot to the Nginx Container

Configuring Nginx for SSL

Step 1: Add a Dedicated Location Block for ACME Challenges

Step 2: Update the Nginx Configuration

Installing and Using Certbot

Step 1: Install Certbot on the Host Machine

Step 2: Obtain the Initial SSL Certificate

Step 3: Update the Nginx Configuration

Step 4: Verify SSL is Working

Automating Certificate Renewal

Step 1: Set Up a Renewal Cron Job for Certbot

Step 2: Test the Cron Job Manually

Conclusion

Thank You For Reading

Automate Docker Deployments to Your Server Using GitHub Actions and Amazon ECR

Introduction

Prerequisites

Amazon ECR Setup

Server Configuration

GitHub Action Workflow

Explanation of Each Step

Common Pitfalls and Troubleshooting

Conclusion

Thank You For Reading

Seamlessly Migrating Frontend Deployment Across AWS Accounts

How to Move S3 Buckets, CloudFront Distributions, and Route 53 Hosted Zones

Introduction

Pre-Migration Checklist

Resources To Migrate

Access and Permissions

Step 4: Define the Resources in `serverless.yml`

Full Code: `transcriptionService.mjs`

The `useApi` Hook

Testing the`callApi` Function