- Популярные видео
- Авто
- Видео-блоги
- ДТП, аварии
- Для маленьких
- Еда, напитки
- Животные
- Закон и право
- Знаменитости
- Игры
- Искусство
- Комедии
- Красота, мода
- Кулинария, рецепты
- Люди
- Мото
- Музыка
- Мультфильмы
- Наука, технологии
- Новости
- Образование
- Политика
- Праздники
- Приколы
- Природа
- Происшествия
- Путешествия
- Развлечения
- Ржач
- Семья
- Сериалы
- Спорт
- Стиль жизни
- ТВ передачи
- Танцы
- Технологии
- Товары
- Ужасы
- Фильмы
- Шоу-бизнес
- Юмор
Run Multiple Containers with ECS Fargate Task: Ghost CMS + Webhook Receiver with ECR on AWS
In this build session, I extended the Ghost ECS Fargate deployment from the previous video by adding a second container to the same task — a FastAPI webhook receiver that listens for Ghost member events.
The idea: Ghost fires events when members sign up, posts go live, or tiers change. Without something listening, those events vanish. So we added a small receiver running alongside Ghost in the same Fargate task, communicating over localhost.
🧱 What We're Building
We extended the single-container Ghost deployment into a multi-container ECS task:
➜ Ghost runs as the primary container on port 2368
➜ A FastAPI webhook receiver runs on port 8000 in the same task
➜ Both containers share the Fargate task's network namespace
➜ Ghost sends member events to localhost:8000/webhook
➜ The webhook receiver logs everything to CloudWatch
➜ The receiver is internal only — not exposed through the ALB or the internet
🔍 What We Covered
✅ Why multi-container tasks exist and when to use them
✅ Building a FastAPI webhook receiver and testing it locally
✅ Creating an ECR repository and pushing a custom image
✅ Updating the ECS task definition to run two containers
✅ Essential vs non-essential containers and what happens when one crashes
✅ How containers in the same task communicate over localhost
✅ Security group behavior — why port 8000 stays blocked from outside
✅ Configuring Ghost webhooks to fire on member events
✅ Verifying webhook delivery in CloudWatch Logs
🧩 Where This Breaks Down
The coupling is deliberate — both containers scale, deploy, and restart together. That works for prototyping. It stops working when Ghost needs to scale on HTTP traffic and the webhook processor needs to scale on event volume. Future sessions will cover:
➜ Splitting into separate ECS services
➜ ECS Service Connect for private inter-service routing
➜ Independent autoscaling per service
Subscribe for more practical AWS build sessions.
Full Terraform code and step-by-step walkthrough on the blog: https://brainyl.cloud/ghost-ecs-fargate-multi-service-webhooks/
— Build with Brainyl
Видео Run Multiple Containers with ECS Fargate Task: Ghost CMS + Webhook Receiver with ECR on AWS канала Brainyl
The idea: Ghost fires events when members sign up, posts go live, or tiers change. Without something listening, those events vanish. So we added a small receiver running alongside Ghost in the same Fargate task, communicating over localhost.
🧱 What We're Building
We extended the single-container Ghost deployment into a multi-container ECS task:
➜ Ghost runs as the primary container on port 2368
➜ A FastAPI webhook receiver runs on port 8000 in the same task
➜ Both containers share the Fargate task's network namespace
➜ Ghost sends member events to localhost:8000/webhook
➜ The webhook receiver logs everything to CloudWatch
➜ The receiver is internal only — not exposed through the ALB or the internet
🔍 What We Covered
✅ Why multi-container tasks exist and when to use them
✅ Building a FastAPI webhook receiver and testing it locally
✅ Creating an ECR repository and pushing a custom image
✅ Updating the ECS task definition to run two containers
✅ Essential vs non-essential containers and what happens when one crashes
✅ How containers in the same task communicate over localhost
✅ Security group behavior — why port 8000 stays blocked from outside
✅ Configuring Ghost webhooks to fire on member events
✅ Verifying webhook delivery in CloudWatch Logs
🧩 Where This Breaks Down
The coupling is deliberate — both containers scale, deploy, and restart together. That works for prototyping. It stops working when Ghost needs to scale on HTTP traffic and the webhook processor needs to scale on event volume. Future sessions will cover:
➜ Splitting into separate ECS services
➜ ECS Service Connect for private inter-service routing
➜ Independent autoscaling per service
Subscribe for more practical AWS build sessions.
Full Terraform code and step-by-step walkthrough on the blog: https://brainyl.cloud/ghost-ecs-fargate-multi-service-webhooks/
— Build with Brainyl
Видео Run Multiple Containers with ECS Fargate Task: Ghost CMS + Webhook Receiver with ECR on AWS канала Brainyl
ecs fargate multi-container ecs ecs task definition aws ecs fargate tutorial run multiple containers ecs ghost cms aws webhook receiver fastapi webhook ecr push image ecs multi-container task aws fargate tutorial docker ecs ecs container communication aws cloudwatch logs ghost webhooks ecs essential container aws container service deploy containers aws ecs fargate terraform ghost cms docker multi-service ecs sidecar container ecs ecs task networking
Комментарии отсутствуют
Информация о видео
11 февраля 2026 г. 7:50:32
00:53:33
Другие видео канала




















