You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Updated to use aws-ecs-patterns. Fixed test. Added more make targets. Added jq to parse json in makefile. Not tracking output file. Changed to typescript. Added docker-compose to start LocalStack
Copy file name to clipboardExpand all lines: README.md
+77-59Lines changed: 77 additions & 59 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,30 +1,43 @@
1
1
### 🌐 Overview
2
2
3
-
The sample application, utilizing the AWS Cloud Development Kit (AWS CDK) 🛠️, orchestrates the deployment of a containerized application 📦 on AWS Fargate within an Amazon ECS (Elastic Container Service) cluster. The CDK infrastructure-as-code model allows developers to define cloud resources using familiar programming languages 🖥️.
3
+
The sample application, utilizing the AWS Cloud Development Kit (AWS CDK) 🛠️, orchestrates the deployment of a
4
+
containerized application 📦 on AWS Fargate within an Amazon ECS (Elastic Container Service) cluster. The CDK
5
+
infrastructure-as-code model allows developers to define cloud resources using familiar programming languages 🖥️.
4
6
5
7
### 🔑 Key Components
6
8
7
-
-**🌍 VPC and Cluster:**
8
-
The script initiates a new Virtual Private Cloud (VPC) and an ECS Cluster, ensuring a secure 🔐 and isolated network environment and a logical grouping of ECS tasks and services, respectively.
9
+
-**🌍 VPC and Cluster:**
10
+
The script initiates a new Virtual Private Cloud (VPC) and an ECS Cluster, ensuring a secure 🔐 and isolated network
11
+
environment and a logical grouping of ECS tasks and services, respectively.
9
12
10
-
-**🐳 Docker Image Asset:**
11
-
The `DockerImageAsset` class is used to build a Docker image from a local directory (specified path) and push it to Amazon Elastic Container Registry (ECR). The built image is then used in the ECS task definition.
13
+
-**🐳 Docker Image Asset:**
14
+
The `DockerImageAsset` class is used to build a Docker image from a local directory (specified path) and push it to
15
+
Amazon Elastic Container Registry (ECR). The built image is then used in the ECS task definition.
12
16
13
-
-**🚀 Task Definition and Container Definition:**
14
-
An ECS task definition is created, specifying the Docker image to use, CPU 🖥️, and memory requirements, network mode, and logging configuration. A container within this task is defined, specifying port mappings and essential status.
17
+
-**🚀 Task Definition and Container Definition:**
18
+
An ECS task definition is created, specifying the Docker image to use, CPU 🖥️, and memory requirements, network mode,
19
+
and logging configuration. A container within this task is defined, specifying port mappings and essential status.
15
20
16
-
-**🛳️ ECS Fargate Service:**
17
-
The ECS service is configured to run on Fargate, which allows running containers without managing the underlying instances. The service is configured with the above task definition, desired count of tasks, and a circuit breaker for handling failures.
21
+
-**🛳️ ECS Fargate Service:**
22
+
The ECS service is configured to run on Fargate, which allows running containers without managing the underlying
23
+
instances. The service is configured with the above task definition, desired count of tasks, and a circuit breaker for
24
+
handling failures.
18
25
19
-
-**⚖️ Application Load Balancer (ALB):**
20
-
An ALB is provisioned to distribute incoming HTTP/S traffic across multiple targets, such as ECS tasks, in multiple Availability Zones. A listener is added to the load balancer to check for connection requests from clients, using the HTTP protocol and listening on port 80.
26
+
-**⚖️ Application Load Balancer (ALB):**
27
+
An ALB is provisioned to distribute incoming HTTP/S traffic across multiple targets, such as ECS tasks, in multiple
28
+
Availability Zones. A listener is added to the load balancer to check for connection requests from clients, using the
29
+
HTTP protocol and listening on port 80.
21
30
22
-
-**🎯 Target Group and Health Checks:**
23
-
Targets (in this case, the ECS service) are registered with a target group, which the ALB uses to route traffic to. Health check settings ensure that traffic is routed only to healthy targets.
31
+
-**🎯 Target Group and Health Checks:**
32
+
Targets (in this case, the ECS service) are registered with a target group, which the ALB uses to route traffic to.
33
+
Health check settings ensure that traffic is routed only to healthy targets.
24
34
25
35
## Getting Started 🏁
26
36
27
-
This guide assumes that you have cloned the repository and are in the project root directory. The following steps will guide you through the process of building, deploying, and running the sample application both locally and on AWS. We have a [sample application](https://github.com/localstack-samples/sample-cdk-ecs-elb/tree/main/src) that listens on port `3000` and returns a JSON response.
37
+
This guide assumes that you have cloned the repository and are in the project root directory. The following steps will
38
+
guide you through the process of building, deploying, and running the sample application both locally and on AWS. We
39
+
have a [sample application](https://github.com/localstack-samples/sample-cdk-ecs-elb/tree/main/src) that listens on
40
+
port `3000` and returns a JSON response.
28
41
29
42
### Prerequisites 🧰
30
43
@@ -33,7 +46,7 @@ This guide assumes that you have cloned the repository and are in the project ro
@@ -51,10 +64,12 @@ Start the LocalStack server using the following command:
51
64
52
65
```bash
53
66
export LOCALSTACK_API_KEY=<YOUR_API_KEY>
54
-
DEBUG=1 localstack start
67
+
make start-localstack
55
68
```
56
69
57
-
We specified `DEBUG=1` to get the printed LocalStack logs directly in the terminal to help us visualize the background tasks in action. If you prefer running LocalStack in detached mode, you can add the `-d` flag to the `localstack start` command, and use Docker Desktop to view the logs.
70
+
We specified `DEBUG=1` to get the printed LocalStack logs directly in the terminal to help us visualize the background
71
+
tasks in action. If you prefer running LocalStack in detached mode, you can add the `-d` flag to the `localstack start`
72
+
command, and use Docker Desktop to view the logs.
58
73
59
74
### Step 2: Deploy the Application 🚢
60
75
@@ -71,12 +86,14 @@ This command will deploy your application to the LocalStack. Ensure that there a
71
86
Run the application test cases using the following command:
72
87
73
88
```bash
74
-
make test
89
+
make test-local
75
90
```
76
91
77
-
Ensure that all test cases pass and pay attention to any output that is displayed. This step should validate that the application is functioning as expected.
92
+
Ensure that all test cases pass and pay attention to any output that is displayed. This step should validate that the
93
+
application is functioning as expected.
78
94
79
-
Alternatively, you can also check the application by curling the ALB endpoint. You can find the ALB endpoint in the LocalStack console or by running the following command:
95
+
Alternatively, you can also check the application by curling the ALB endpoint. You can find the ALB endpoint in the
96
+
LocalStack console or by running the following command:
This command will deploy your application to AWS. Ensure that there are no errors.
116
133
117
-
### Step 2: Run Test Cases 🧪
134
+
### Step 2: Run Test Cases Against AWS🧪
118
135
119
136
Run the application test cases using the following command:
120
137
121
138
```bash
122
139
make test
123
140
```
124
141
125
-
Alternatively, you can also check the application by curling the ALB endpoint. You can find the ALB endpoint in the AWS console or by running the following command:
126
-
127
-
```bash
128
-
aws elbv2 describe-load-balancers --names serviceslb --query 'LoadBalancers[0].DNSName' --output text
129
-
```
130
-
131
-
Now you can curl the endpoint using the following command:
142
+
Alternatively, you can also check the application by curling the ALB endpoint. You can find the ALB endpoint in the AWS
143
+
console or by running the following command:
132
144
133
145
```bash
134
-
curl <ALB_ENDPOINT-FROM_ABOVE_COMMAND>
146
+
make curl-aws
135
147
```
136
148
137
149
The output should be similar to the following:
@@ -150,58 +162,64 @@ make destroy
150
162
151
163
## 🚀 Configuring Visual Studio Code for Efficient Remote Node.js Debugging
152
164
153
-
Setting up Visual Studio Code for remote Node.js debugging enables smoother and more intuitive development workflows. This guide will walk you through the essential steps to configure your VSCode efficiently for remote debugging of your Node.js applications. 🛠️🔍
165
+
Setting up Visual Studio Code for remote Node.js debugging enables smoother and more intuitive development workflows.
166
+
This guide will walk you through the essential steps to configure your VSCode efficiently for remote debugging of your
167
+
Node.js applications. 🛠️🔍
154
168
155
169
1️⃣ **Configure LocalStack for remote Node.js debugging** 🛠️
156
170
157
-
First, we need to configure LocalStack to enable remote debugging of Node.js applications. To do so, we need to set the `ECS_DOCKER_FLAGS` to enable the debugger using `NODE_OPTIONS`:
158
-
171
+
First, we need to configure LocalStack to enable remote debugging of Node.js applications. To do so, we need to set
172
+
the `ECS_DOCKER_FLAGS` to enable the debugger using `NODE_OPTIONS`:
2️⃣ **Adding a Task to Wait for Remote Debugger Server** 🕰️
164
179
165
-
First, let's ensure that VSCode waits for the remote debugger server to be available. Add a new task by creating or modifying the `.vscode/tasks.json` file in your project directory.
180
+
First, let's ensure that VSCode waits for the remote debugger server to be available. Add a new task by creating or
181
+
modifying the `.vscode/tasks.json` file in your project directory.
Next, define how VSCode should connect to the remote Node.js application. Create a new `launch.json` file or modify an existing one from the *Run and Debug* tab, then add the following configuration.
198
+
Next, define how VSCode should connect to the remote Node.js application. Create a new `launch.json` file or modify an
199
+
existing one from the *Run and Debug* tab, then add the following configuration.
183
200
184
201
```json
185
202
{
186
-
"version": "0.2.0",
187
-
"configurations": [
188
-
{
189
-
"address": "127.0.0.1",
190
-
"localRoot": "${workspaceFolder}",
191
-
"name": "Attach to Remote Node.js",
192
-
"port": 9229,
193
-
"remoteRoot": "/var/task/",
194
-
"request": "attach",
195
-
"type": "node",
196
-
"preLaunchTask": "Wait Remote Debugger Server"
197
-
},
198
-
]
199
-
}
203
+
"version": "0.2.0",
204
+
"configurations": [
205
+
{
206
+
"address": "127.0.0.1",
207
+
"localRoot": "${workspaceFolder}",
208
+
"name": "Attach to Remote Node.js",
209
+
"port": 9229,
210
+
"remoteRoot": "/var/task/",
211
+
"request": "attach",
212
+
"type": "node",
213
+
"preLaunchTask": "Wait Remote Debugger Server"
214
+
}
215
+
]
216
+
}
200
217
```
201
218
202
219
4️⃣ **Running the Debugger** 🏃
203
220
204
-
Finally, run the debugger by selecting the *Attach to Remote Node.js* configuration from the *Run and Debug* tab. You can now set breakpoints and debug your Node.js application running in a Docker container. 🐳
221
+
Finally, run the debugger by selecting the *Attach to Remote Node.js* configuration from the *Run and Debug* tab. You
222
+
can now set breakpoints and debug your Node.js application running in a Docker container. 🐳
0 commit comments