Admin: Add Navbox deployment template before Related (via update-page on MediaWiki MCP Server)

2026-07-06T03:59:55Z

Add Navbox deployment template before Related (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 09:29, 6 July 2026
Line 324:		Line 324:
	* '''Netlify''': Another static site hosting service that supports automatic deployments from GitHub repositories. See [<nowiki/>https://docs.netlify.com/site-deploys/deploy-previews Netlify deploy previews] for how to deploy preview builds of the frontend.		* '''Netlify''': Another static site hosting service that supports automatic deployments from GitHub repositories. See [<nowiki/>https://docs.netlify.com/site-deploys/deploy-previews Netlify deploy previews] for how to deploy preview builds of the frontend.
	* '''Vercel''': Another static site hosting service that supports automatic deployments from GitHub repositories. See [<nowiki/>https://vercel.com/docs/concepts/deployments/previews Vercel preview deployments] for how to deploy preview builds of the frontend.		* '''Vercel''': Another static site hosting service that supports automatic deployments from GitHub repositories. See [<nowiki/>https://vercel.com/docs/concepts/deployments/previews Vercel preview deployments] for how to deploy preview builds of the frontend.

			{{Navbox deployment}}

	{{Related}}		{{Related}}

Admin: OHC identity seed

2026-07-04T23:08:04Z

OHC identity seed

New page

{{Doc header
|type=guide
|domain=deployment
|title=Deploying Care on AWS ECS
|order=2
}}

This guide walks through deploying Care on AWS using '''Elastic Container Service (ECS)''' with the '''Fargate''' serverless launch type. ECS runs the backend, Celery, and Redis containers as serverless tasks, so there are no EC2 instances to provision or manage yourself.

For an overview of the AWS deployment, see the [[Index|AWS overview]].

== Infrastructure ==

Provision the supporting AWS infrastructure first, then create the ECS cluster and services that run the application containers.

=== Configuring the Virtual Private Cloud (VPC) ===

# Access the '''AWS Console''' and locate the '''VPC''' service.
# Initiate the creation of a new VPC by selecting the '''VPC and more''' option and name it <code>care-vpc</code>. This action will automatically generate a new VPC, along with associated subnets, route tables, and internet gateways.
# The default settings will be applied automatically, but you can modify these according to your specific requirements.
# Ensure that the '''Internet Gateway''' is attached to the VPC to enable external communication.

=== Configuring the Relational Database Service (RDS) ===

# From the '''AWS Console''', navigate to the '''RDS''' service.
# Create a new database instance using the <code>PostgreSQL</code> engine.
# Assign the '''DB cluster identifier''' as <code>care-db</code>.
# Set the '''Credential management''' as <code>Self managed</code> and provide the master username and password.
# Set the '''Availability Zone''' as per requirement.
# Configure the database instance size and storage capacity as needed.
# Use the same '''VPC''' and '''subnet group''' that was created earlier.
# Configure the '''security group''' to allow inbound traffic on port <code>5432</code> from all sources. ''(This can be restricted to the VPC to enhance security.)''
# Set '''Public accessibility''' to <code>No</code> to restrict access to the database from the internet.

=== Configuring the S3 Bucket ===

# Locate the '''S3''' service in the '''AWS Console'''.
# Create two new buckets named <code>facility-data</code> and <code>patient-data</code>.
# Adjust the '''permissions''' settings for each bucket:
#* Set <code>facility-data</code> to '''public'''.
#* Set <code>patient-data</code> to '''private'''.
# Configure the '''CORS policy''' for both buckets to restrict access to specific domains after deployment.

=== Setting Up IAM Roles ===

# Navigate to the '''IAM''' service in the '''AWS Console'''.
# Create a user named <code>gh-action</code>.
# Assign the necessary permissions required to run the deployment commands.
# Generate access keys and secrets for the user and store them securely.

{{Tip|1=The <code>gh-action</code> user's access key and secret are used by the GitHub Actions pipeline as the <code>AWS_ACCESS_KEY_ID</code> and <code>AWS_SECRET_ACCESS_KEY</code> secrets. Store them securely and grant only the permissions required for the deployment.}}

=== Setting Up the Load Balancer ===

# Access the '''Load Balancer''' service in the '''AWS Console'''.
# Create a new load balancer named <code>care-lb</code>.
# Configure the load balancer to use the '''VPC''' and '''subnets''' created earlier.
# Configure the '''security group''' to allow inbound traffic on the required ports.
# Set up the '''listener configuration''' to forward traffic to the '''target group'''.

=== Setting Up the ECS Cluster ===

# Access the '''ECS''' service in the '''AWS Console'''.
# Create a new cluster named <code>care-cluster</code>.
# Choose '''Fargate (Serverless)''' as the launch type.
# Create '''service and task definitions''' for the backend, Celery, and Redis Stack Server.
# Create a new '''service''' for each task definition and configure the desired number of tasks to run.
# In the '''Networking''' tab, select the '''VPC''' and '''subnets''' created earlier.
# Configure the '''security group''' to allow inbound traffic on the required ports.
# Ensure that the service is linked to the '''load balancer''' created earlier.

=== Cost Estimate Table ===

{| class="wikitable"
|-
! Resource
! Instance Type
! Region
! Monthly Cost (INR)
! Cost Estimation Methodology
|-
| ECS Cluster
| Fargate
| ap-south-1
| ~₹4000.00
| Estimated based on Fargate pricing for minimal usage
|-
| RDS Instance
| db.t2.micro
| ap-south-1
| ~₹1245.00
| Estimated for a single instance with minimal usage
|-
| S3 Bucket
| 20 GB Storage
| ap-south-1
| ~₹38.00
| Calculated for 20 GB of standard storage
|-
| Load Balancer
| ALB
| ap-south-1
| ~₹1500.00
| Estimated based on ALB pricing
|-
| Data Transfer
| 10 GB Outbound
| ap-south-1
| ~₹74.00
| Estimated for 10 GB of outbound data transfer
|-
| '''Total'''
|
|
| ~₹6857.00
|
|}

{{Note|1=The estimated cost for deploying the '''Care''' application on '''AWS''' using '''ECS''' may vary based on actual usage and traffic patterns.}}

== GitHub Actions pipeline ==

The GitHub workflow file is triggered on every manual trigger, push to the <code>develop</code> branch, or tags starting with <code>v</code>. It builds the new container image upon the trigger and updates the task definition in the ECS cluster. This ensures that the latest image is deployed to the ECS cluster.

The image is built from <code>docker/prod.Dockerfile</code> and pushed to both the GitHub Container Registry (<code>ghcr.io</code>) and Docker Hub. The deploy job then renders the task definitions at <code>./aws/backend.json</code> and <code>./aws/celery.json</code> with the new image and rolls them out to the ECS services.

<syntaxhighlight lang="yaml">name: Deploy Care

on:
workflow_dispatch:
push:
tags:
- 'v*'
branches:
- develop
paths-ignore:
- "docs/**"

concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true

env:
IMAGE_NAME: care
AWS_DEFAULT_REGION: ap-south-1
AWS_DEFAULT_OUTPUT: json
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} # AWS Access Key ID for authentication
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} # AWS Secret Access Key for authentication
ECS_SERVICE_BACKEND: "care-backend" # ECS service name for the backend
ECS_SERVICE_CELERY: "care-celery" # ECS service name for Celery
ECS_CLUSTER: "example_cluster" # Name of the ECS cluster
ECS_TASK_DEFINITION_BACKEND: "./aws/backend.json" # Path to the backend task definition
ECS_TASK_DEFINITION_CELERY: "./aws/celery.json" # Path to the Celery task definition
CONTAINER_NAME_BACKEND: "care-backend" # Container name for the backend
CONTAINER_NAME_WORKER: "care-celery-worker" # Container name for the Celery worker
CONTAINER_NAME_CRON: "care-celery-beat" # Container name for the Celery beat

jobs:
build:
name: Build & Push to container registries
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4

- name: Generate docker tags
id: meta
uses: docker/metadata-action@v5
with:
images: |
ghcr.io/${{ github.repository }}
${{ secrets.DOCKER_HUB_USERNAME }}/${{ github.event.repository.name }}
tags: |
type=raw,value=production-latest,enable=${{ startsWith(github.event.ref, 'refs/tags/v') }}
type=raw,value=production-latest-${{ github.run_number }}-{{date 'YYYYMMDD'}}-{{sha}},enable=${{ startsWith(github.event.ref, 'refs/tags/v') }}
type=raw,value=latest,enable=${{ github.ref == 'refs/heads/develop' }}
type=raw,value=latest-${{ github.run_number }},enable=${{ github.ref == 'refs/heads/develop' }}
type=semver,pattern={{version}}
flavor: latest=false

- name: Setup QEMU
uses: docker/setup-qemu-action@v3

- name: Setup Docker Buildx
uses: docker/setup-buildx-action@v3

- name: Login to DockerHub
uses: docker/login-action@v3
with:
username: ${{ secrets.DOCKER_HUB_USERNAME }} # DockerHub username
password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }} # DockerHub access token

- name: Login to GitHub Container Registry
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }} # GitHub token for authentication

- name: Cache Docker layers
uses: actions/cache@v4
with:
path: /tmp/.buildx-cache
key: ${{ runner.os }}-buildx-build-${{ hashFiles('Pipfile.lock', 'docker/prod.Dockerfile') }}
restore-keys: |
${{ runner.os }}-buildx-build-

- name: Build and push image
uses: docker/build-push-action@v6
with:
context: .
file: docker/prod.Dockerfile
push: true
provenance: false
platforms: linux/amd64,linux/arm64
tags: ${{ steps.meta.outputs.tags }}
build-args: |
APP_VERSION=${{ github.sha }}
ADDITIONAL_PLUGS=${{ secrets.ADDITIONAL_PLUGS }} # Additional plugins
cache-from: type=local,src=/tmp/.buildx-cache
cache-to: type=local,dest=/tmp/.buildx-cache-new,mode=max

- name: Move cache
run: |
rm -rf /tmp/.buildx-cache
mv /tmp/.buildx-cache-new /tmp/.buildx-cache

deploy:
name: Deploy to ECS
runs-on: ubuntu-latest
environment:
name: Deployment-ecs
url: https://careapi.example.com
steps:
- name: Checkout repository
uses: actions/checkout@v4

- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} # AWS Access Key ID for authentication
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} # AWS Secret Access Key for authentication
aws-region: ${{ env.AWS_DEFAULT_REGION }}

- name: IMAGE Tagging
env:
ECR_REGISTRY: ghcr.io/${{ github.repository }}
IMAGE_TAG: latest-${{ github.run_number }}
run: echo "IMAGE_VALUE=`echo ghcr.io/${{ github.repository }}:$IMAGE_TAG`" >> $GITHUB_ENV

- name: Fill Celery Cron definition
id: task-def-celery-cron
uses: aws-actions/amazon-ecs-render-task-definition@v1
with:
task-definition: ${{ env.ECS_TASK_DEFINITION_CELERY }}
container-name: ${{ env.CONTAINER_NAME_CRON }}
image: ${{ env.IMAGE_VALUE }}

- name: Fill Celery Worker definition
id: task-def-celery-worker
uses: aws-actions/amazon-ecs-render-task-definition@v1
with:
task-definition: ${{ steps.task-def-celery-cron.outputs.task-definition }}
container-name: ${{ env.CONTAINER_NAME_WORKER }}
image: ${{ env.IMAGE_VALUE }}

- name: Deploy Backend Celery
uses: aws-actions/amazon-ecs-deploy-task-definition@v2
with:
task-definition: ${{ steps.task-def-celery-worker.outputs.task-definition }}
service: ${{ env.ECS_SERVICE_CELERY }}
cluster: ${{ env.ECS_CLUSTER }}
wait-for-service-stability: true

- name: Fill Backend API definition
id: task-def-api
uses: aws-actions/amazon-ecs-render-task-definition@v1
with:
task-definition: ${{ env.ECS_TASK_DEFINITION_BACKEND }}
container-name: ${{ env.CONTAINER_NAME_BACKEND }}
image: ${{ env.IMAGE_VALUE }}

- name: Deploy Backend API
uses: aws-actions/amazon-ecs-deploy-task-definition@v2
with:
task-definition: ${{ steps.task-def-api.outputs.task-definition }}
service: ${{ env.ECS_SERVICE_BACKEND }}
cluster: ${{ env.ECS_CLUSTER }}
wait-for-service-stability: true</syntaxhighlight>
=== Secrets and Variables Used ===

==== Secrets ====

* <code>AWS_ACCESS_KEY_ID</code>: AWS Access Key ID for authentication
* <code>AWS_SECRET_ACCESS_KEY</code>: AWS Secret Access Key for authentication
* <code>DOCKER_HUB_USERNAME</code>: DockerHub username
* <code>DOCKER_HUB_ACCESS_TOKEN</code>: DockerHub access token
* <code>GITHUB_TOKEN</code>: GitHub token for authentication
* <code>ADDITIONAL_PLUGS</code>: Additional plugins specified in JSON format to include in the build

==== Variables ====

* <code>IMAGE_NAME</code>: Name of the image to be built
* <code>AWS_DEFAULT_REGION</code>: AWS region
* <code>AWS_DEFAULT_OUTPUT</code>: AWS output format
* <code>ECS_SERVICE_BACKEND</code>: ECS service name for the backend (<code>care-backend</code>)
* <code>ECS_SERVICE_CELERY</code>: ECS service name for the Celery service (<code>care-celery</code>)
* <code>ECS_CLUSTER</code>: ECS cluster name (<code>care-cluster</code>)
* <code>ECS_TASK_DEFINITION_BACKEND</code>: Path to the backend task definition (<code>./aws/backend.json</code>)
* <code>ECS_TASK_DEFINITION_CELERY</code>: Path to the Celery task definition (<code>./aws/celery.json</code>)
* <code>CONTAINER_NAME_BACKEND</code>: Container name for the backend (<code>care-backend</code>)
* <code>CONTAINER_NAME_WORKER</code>: Container name for the Celery worker (<code>care-worker</code>)
* <code>CONTAINER_NAME_CRON</code>: Container name for the Celery cron (<code>care-cron</code>)
* <code>IMAGE_TAG</code>: Tag for the built image
* <code>IMAGE_VALUE</code>: Value of the built image

== Frontend ==

The development deployment for Care relies on ECS for its backend deployment. The API provided by the backend can be used by all development frontends, including localhost and [<nowiki/>https://github.com/ohcnetwork/care_fe Care_FE] deploy previews.

You can use any of the following methods to deploy the frontend for both production and deployment previews:

* '''Cloudflare Pages''': A static site hosting service that supports automatic deployments from GitHub repositories. See [<nowiki/>https://developers.cloudflare.com/pages/configuration/preview-deployments Cloudflare Pages preview deployments] for how to deploy preview builds of the frontend.
* '''Netlify''': Another static site hosting service that supports automatic deployments from GitHub repositories. See [<nowiki/>https://docs.netlify.com/site-deploys/deploy-previews Netlify deploy previews] for how to deploy preview builds of the frontend.
* '''Vercel''': Another static site hosting service that supports automatic deployments from GitHub repositories. See [<nowiki/>https://vercel.com/docs/concepts/deployments/previews Vercel preview deployments] for how to deploy preview builds of the frontend.

{{Related}}

Deployment/Providers/Aws/Deploying Care on AWS ECS - Revision history

Admin: Add Navbox deployment template before Related (via update-page on MediaWiki MCP Server)

Admin: OHC identity seed