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
Copy file name to clipboardExpand all lines: README.md
+74-60Lines changed: 74 additions & 60 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,11 +64,9 @@ 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.
58
-
59
70
### Step 2: Deploy the Application 🚢
60
71
61
72
Deploy your application locally using the following command:
@@ -71,12 +82,14 @@ This command will deploy your application to the LocalStack. Ensure that there a
71
82
Run the application test cases using the following command:
72
83
73
84
```bash
74
-
make test
85
+
make test-local
75
86
```
76
87
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.
88
+
Ensure that all test cases pass and pay attention to any output that is displayed. This step should validate that the
89
+
application is functioning as expected.
78
90
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:
91
+
Alternatively, you can also check the application by curling the ALB endpoint. You can find the ALB endpoint in the
92
+
LocalStack console or by running the following command:
This command will deploy your application to AWS. Ensure that there are no errors.
116
129
117
-
### Step 2: Run Test Cases 🧪
130
+
### Step 2: Run Test Cases Against AWS🧪
118
131
119
132
Run the application test cases using the following command:
120
133
121
134
```bash
122
135
make test
123
136
```
124
137
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:
138
+
Alternatively, you can also check the application by curling the ALB endpoint. You can find the ALB endpoint in the AWS
139
+
console or by running the following command:
126
140
127
141
```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:
132
-
133
-
```bash
134
-
curl <ALB_ENDPOINT-FROM_ABOVE_COMMAND>
142
+
make curl-aws
135
143
```
136
144
137
145
The output should be similar to the following:
@@ -150,58 +158,64 @@ make destroy
150
158
151
159
## 🚀 Configuring Visual Studio Code for Efficient Remote Node.js Debugging
152
160
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. 🛠️🔍
161
+
Setting up Visual Studio Code for remote Node.js debugging enables smoother and more intuitive development workflows.
162
+
This guide will walk you through the essential steps to configure your VSCode efficiently for remote debugging of your
163
+
Node.js applications. 🛠️🔍
154
164
155
165
1️⃣ **Configure LocalStack for remote Node.js debugging** 🛠️
156
166
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
-
167
+
First, we need to configure LocalStack to enable remote debugging of Node.js applications. To do so, we need to set
168
+
the `ECS_DOCKER_FLAGS` to enable the debugger using `NODE_OPTIONS`:
2️⃣ **Adding a Task to Wait for Remote Debugger Server** 🕰️
164
175
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.
176
+
First, let's ensure that VSCode waits for the remote debugger server to be available. Add a new task by creating or
177
+
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.
194
+
Next, define how VSCode should connect to the remote Node.js application. Create a new `launch.json` file or modify an
195
+
existing one from the *Run and Debug* tab, then add the following configuration.
183
196
184
197
```json
185
198
{
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
-
}
199
+
"version": "0.2.0",
200
+
"configurations": [
201
+
{
202
+
"address": "127.0.0.1",
203
+
"localRoot": "${workspaceFolder}",
204
+
"name": "Attach to Remote Node.js",
205
+
"port": 9229,
206
+
"remoteRoot": "/var/task/",
207
+
"request": "attach",
208
+
"type": "node",
209
+
"preLaunchTask": "Wait Remote Debugger Server"
210
+
}
211
+
]
212
+
}
200
213
```
201
214
202
215
4️⃣ **Running the Debugger** 🏃
203
216
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. 🐳
217
+
Finally, run the debugger by selecting the *Attach to Remote Node.js* configuration from the *Run and Debug* tab. You
218
+
can now set breakpoints and debug your Node.js application running in a Docker container. 🐳
0 commit comments