DEV Community: Selvakumar

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.

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.

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"