docs(blueprint): separate apps directory

examples/blueprint/README.ko.md

@@ -36,53 +36,8 @@ terraform apply -var-file fixture.tc1.tfvars
 ### AWS 그래비톤
 [AWS 그래비톤](https://aws.amazon.com/ec2/graviton/) 프로세서는 are custom built by Amazon Web Services using 64-bit ARM Neoverse cores to deliver the best price performance for you cloud workloads running on Amazon EC2. The new general purpose (M6g), compute-optimized (C6g), and memory-optimized (R6g) instances deliver up to 40% better price/performance over comparable current generation x86-based instances for scale-out and Arm-based applications such as web servers, containerized microservices, caching fleets, and distributed data stores that are supported by the extensive Arm ecosystem. You can mix x86 and Arm based EC2 instances within a cluster, and easily evaluate Arm-based application in existing environments. Here is a useful [getting started](https://github.com/aws/aws-graviton-getting-started) guide on how to start to use AWS Graviton. This github repository would be good point where to start. You can find out more details about how to build, run and optimize your application for AWS Graviton processors.
 
-### EC2 오토스케일링 그룹 웜풀
-웜풀(Warm Pool)은 미리 초기화된 EC2 인스턴스들을 오토스케일링 그룹(Auto Sacling Group)에 함께 보관해두는 기능입니다. 여러 분의 어플리케이션이 수평 확장을 수행할 때 오토스케일링 그룹은 풀에서 인스턴스를 가져와서 사용할 수 있습니다. 웜풀은 사용자의 어플리케이션이 준비 시간이 특히 오래 걸리는 경우, 특히 인스턴스가 엄청난 양의 데이터를 디스크로부터 읽어야 하는 경우에 인스턴스가 서비스에 투입되는 시간을 줄여 줄 수 있습니다. 웜풀을 사용한다면, 빠른 대응을 위해 필요 이상으로 인스턴스를 생성해야할 필요가 없습니다. 보다 자세한 내용은 아마존 EC2 오토스케일링 사용자 안내서의, [EC2 오토스케일링 그룹 웜풀](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html)을 참조하시기 바랍니다.
-
-#### 웜풀 인스턴스 생명주기
-웜풀의 인스턴스들은 각각의 생명주기 상태변화에 맞는 행동을 정의하기 위한 독립접인 생명주기를 가집니다. 이 생명주기는 인스턴스 시작시점부터 종료까지 달라지는 상태를 거쳐갑니다. 이러한 상태변화 과정 사이에 생명주기 훅(Hook)을 만들어서 특정 순간에 해야할 작업을 지정할 수 있습니다.
-
-아래 그림은 각 상태변화를 표시한 것입니다:
-
-![aws-asg-wp-lifecycle](../../images/aws-asg-wp-lifecycle.png)
-
-#### 검증
-테라폼 명령을 수행하고 나면, 웜풀과 인스턴스를 볼 수 있습니다. 인스턴스는 user-data에 있는 스크립트를 활용하여 어플리케이션을 초기화 합니다. 이 스크립트에서는 초기화 작업이 오래 걸리는 상황을 가정한 내용이 포함되어 있습니다.
-
-![aws-asg-wp-init-instance](../../images/aws-asg-wp-init-instance.png)
-
-초기화가 완료되면 'Stopped' 상태로 전환되어 대기합니다.
-
-![aws-asg-wp-stopped](../../images/aws-asg-wp-stopped.png)
-
-웜풀 인스턴스가 초기화하는 데 걸린 시간을 확인하기 위하여, 생성된 스크립트를 실행합니다 (사전 준비사항에 언급한 도구가 반드시 있어야 합니다):
-```
-bash elapsedtime.sh
-```
-명령을 실행하면 다음과 같은 출력을 볼 수 있습니다.
-```
-Launching a new EC2 instance into warm pool: i-0180961b460339ed3 Duration: 215s
-```
-
-#### 웜풀로부터 새 인스턴스 실행
-[main.tf](https://github.com/Young-ook/terraform-aws-ssm/tree/main/examples/blueprint/main.tf) 파일을 열어서 *node_groups* 중 *warmpools*의 *desired_capacity* 값을 1로 변경합니다. 저장한 다음 다시 테라폼을 실행해서 변경 내용을 반영합니다.
-```
-terraform apply
-```
-변경할 내용이 표시됩니다. 확인하였다면, *yes* 를 입력해서 실제 적용합니다. 몇 분 후, 오토스케일링 그룹의 이력을 확인하기 위하여 다음 스크립트를 실행합니다.
-```
-bash elapsedtime.sh
-```
-출력 결과는 아래와 비슷할 것입니다. 웜풀로부터 가져와서 실행한 인스턴스는 실행시간이 단축된 것을 볼 수 있습니다.
-```
-Launching a new EC2 instance from warm pool: i-0180961b460339ed3 Duration: 19s
-Launching a new EC2 instance into warm pool: i-0180961b460339ed3 Duration: 215s
-```
-
-![aws-asg-activity-history](../../images/aws-asg-activity-history.png)
-
-#### 연결
-예제에서 사용한 EC2 인스턴스는 시스템 매니저를 사용해서 접속할 수 있습니다. AWS 관리 콘솔화면에서 EC2 서비스 페이지로 이동합니다. 인스턴스를 선택하고 '연결' 또는 'Connect' 단추를 누릅니다. 그러면, EC2를 접속할 수 있는 여러 방법이 표시되는데, 그 중 세션 매니저(Session Manager)를 선택합니다. 이 후 안내를 따라 인스턴스 내부에 접속합니다.
+## Applications
+- [웜풀](./apps/README.ko.md#EC2-오토스케일링-그룹-웜풀)
 
 ## 정리
 테라폼 실행:

examples/blueprint/README.md

@@ -36,53 +36,8 @@ terraform apply -var-file fixture.tc1.tfvars
 ### AWS Graviton
 [AWS Graviton](https://aws.amazon.com/ec2/graviton/) processors are custom built by Amazon Web Services using 64-bit ARM Neoverse cores to deliver the best price performance for you cloud workloads running on Amazon EC2. The new general purpose (M6g), compute-optimized (C6g), and memory-optimized (R6g) instances deliver up to 40% better price/performance over comparable current generation x86-based instances for scale-out and Arm-based applications such as web servers, containerized microservices, caching fleets, and distributed data stores that are supported by the extensive Arm ecosystem. You can mix x86 and Arm based EC2 instances within a cluster, and easily evaluate Arm-based application in existing environments. Here is a useful [getting started](https://github.com/aws/aws-graviton-getting-started) guide on how to start to use AWS Graviton. This github repository would be good point where to start. You can find out more details about how to build, run and optimize your application for AWS Graviton processors.
 
-### EC2 Auto Scaling Warm Pools
-A warm pool is a pool of pre-initialized EC2 instances that sits alongside the Auto Scaling group. Whenever your application needs to scale out, the Auto Scaling group can draw on the warm pool to meet its new desired capacity. A warm pool gives you the ability to decrease latency for your applications that have exceptionally long boot times, for example, because instances need to write massive amounts of data to disk. With warm pools, you no longer have to over-provision your Auto Scaling groups to manage latency in order to improve application performance. For more information and example configurations, see [Warm pools for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html) in the Amazon EC2 Auto Scaling User Guide.
-
-#### Warm pool instance lifecycle
-Instances in the warm pool maintain their own independent lifecycle to help you create the appropriate lifecycle actions for each transition. An Amazon EC2 instance transitions through different states from the moment it launches through to its termination. You can create lifecycle hooks to act on these event states, when an instance has transitioned from one state to another one.
-
-The following diagram shows the transition between each state:
-
-![aws-asg-wp-lifecycle](../../images/aws-asg-wp-lifecycle.png)
-
-#### Verify
-After terraform apply, you will see an instance in the warm pools. That instance will be launched to run the user-data script for application initialization when it is registered with the warm-pool. In this example, the user-data script waits for a while to simulate a long working time.
-
-![aws-asg-wp-init-instance](../../images/aws-asg-wp-init-instance.png)
-
-After initialization, the instance state changes to 'Stopped' for waiting.
-
-![aws-asg-wp-stopped](../../images/aws-asg-wp-stopped.png)
-
-To check the elpased time to initial configuration of the instance, run this script:
-```
-bash elapsedtime.sh
-```
-The output of this command shows the duration of the instance launch.
-```
-Launching a new EC2 instance into warm pool: i-0180961b460339ed3 Duration: 215s
-```
-
-#### Launch a new instance from warm pool
-Modify the *desired_capacity* value of *warmpools* in *node_groups* in [main.tf](https://github.com/Young-ook/terraform-aws-ssm/tree/main/examples/blueprint/main.tf) file to 1 to scale out the current autoscaling group. After terraform configuration file update, run again terraform apply.
-```
-terraform apply
-```
-The output of the change plan will be displayed. Check it, and enter *yes* to confirm. After a few minutes, run the script below to see the history of Autoscaling group activity and the elapsed time of each operation.
-```
-bash elapsedtime.sh
-```
-The output of this command shows the duration of the instance launch.
-```
-Launching a new EC2 instance from warm pool: i-0180961b460339ed3 Duration: 19s
-Launching a new EC2 instance into warm pool: i-0180961b460339ed3 Duration: 215s
-```
-
-![aws-asg-activity-history](../../images/aws-asg-activity-history.png)
-
-#### Connect
-Move to the EC2 service page on the AWS Management Conosol and select Instances button on the left side menu. Find an instance that you launched. Select the instance and click 'Connect' button on top of the window. After then you will see three tabs EC2 Instance Connect, Session Manager, SSH client. Select Session Manager tab and follow the instruction on the screen.
+## Applications
+- [Warm Pools](./apps/README.md#ec2-auto-scaling-warm-pools)
 
 ## Clean up
 To destroy all infrastrcuture, run terraform:

examples/blueprint/apps/README.ko.md

@@ -0,0 +1,50 @@
+[[English](README.md)] [[한국어](README.ko.md)]
+
+# 애플리케이션
+## EC2 오토스케일링 그룹 웜풀
+웜풀(Warm Pool)은 미리 초기화된 EC2 인스턴스들을 오토스케일링 그룹(Auto Sacling Group)에 함께 보관해두는 기능입니다. 여러 분의 어플리케이션이 수평 확장을 수행할 때 오토스케일링 그룹은 풀에서 인스턴스를 가져와서 사용할 수 있습니다. 웜풀은 사용자의 어플리케이션이 준비 시간이 특히 오래 걸리는 경우, 특히 인스턴스가 엄청난 양의 데이터를 디스크로부터 읽어야 하는 경우에 인스턴스가 서비스에 투입되는 시간을 줄여 줄 수 있습니다. 웜풀을 사용한다면, 빠른 대응을 위해 필요 이상으로 인스턴스를 생성해야할 필요가 없습니다. 보다 자세한 내용은 아마존 EC2 오토스케일링 사용자 안내서의, [EC2 오토스케일링 그룹 웜풀](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html)을 참조하시기 바랍니다.
+
+### 웜풀 인스턴스 생명주기
+웜풀의 인스턴스들은 각각의 생명주기 상태변화에 맞는 행동을 정의하기 위한 독립접인 생명주기를 가집니다. 이 생명주기는 인스턴스 시작시점부터 종료까지 달라지는 상태를 거쳐갑니다. 이러한 상태변화 과정 사이에 생명주기 훅(Hook)을 만들어서 특정 순간에 해야할 작업을 지정할 수 있습니다.
+
+아래 그림은 각 상태변화를 표시한 것입니다:
+
+![aws-asg-wp-lifecycle](../../../images/aws-asg-wp-lifecycle.png)
+
+### 검증
+테라폼 명령을 수행하고 나면, 웜풀과 인스턴스를 볼 수 있습니다. 인스턴스는 user-data에 있는 스크립트를 활용하여 어플리케이션을 초기화 합니다. 이 스크립트에서는 초기화 작업이 오래 걸리는 상황을 가정한 내용이 포함되어 있습니다.
+
+![aws-asg-wp-init-instance](../../../images/aws-asg-wp-init-instance.png)
+
+초기화가 완료되면 'Stopped' 상태로 전환되어 대기합니다.
+
+![aws-asg-wp-stopped](../../../images/aws-asg-wp-stopped.png)
+
+웜풀 인스턴스가 초기화하는 데 걸린 시간을 확인하기 위하여, 생성된 스크립트를 실행합니다 (사전 준비사항에 언급한 도구가 반드시 있어야 합니다):
+```
+bash elapsedtime.sh
+```
+명령을 실행하면 다음과 같은 출력을 볼 수 있습니다.
+```
+Launching a new EC2 instance into warm pool: i-0180961b460339ed3 Duration: 215s
+```
+
+### 웜풀로부터 새 인스턴스 실행
+[main.tf](https://github.com/Young-ook/terraform-aws-ssm/tree/main/examples/blueprint/main.tf) 파일을 열어서 *node_groups* 중 *warmpools*의 *desired_capacity* 값을 1로 변경합니다. 저장한 다음 다시 테라폼을 실행해서 변경 내용을 반영합니다.
+```
+terraform apply
+```
+변경할 내용이 표시됩니다. 확인하였다면, *yes* 를 입력해서 실제 적용합니다. 몇 분 후, 오토스케일링 그룹의 이력을 확인하기 위하여 다음 스크립트를 실행합니다.
+```
+bash elapsedtime.sh
+```
+출력 결과는 아래와 비슷할 것입니다. 웜풀로부터 가져와서 실행한 인스턴스는 실행시간이 단축된 것을 볼 수 있습니다.
+```
+Launching a new EC2 instance from warm pool: i-0180961b460339ed3 Duration: 19s
+Launching a new EC2 instance into warm pool: i-0180961b460339ed3 Duration: 215s
+```
+
+![aws-asg-activity-history](../../../images/aws-asg-activity-history.png)
+
+### 연결
+예제에서 사용한 EC2 인스턴스는 시스템 매니저를 사용해서 접속할 수 있습니다. AWS 관리 콘솔화면에서 EC2 서비스 페이지로 이동합니다. 인스턴스를 선택하고 '연결' 또는 'Connect' 단추를 누릅니다. 그러면, EC2를 접속할 수 있는 여러 방법이 표시되는데, 그 중 세션 매니저(Session Manager)를 선택합니다. 이 후 안내를 따라 인스턴스 내부에 접속합니다.

examples/blueprint/apps/README.md

@@ -0,0 +1,50 @@
+[[English](README.md)] [[한국어](README.ko.md)]
+
+# Applications
+## EC2 Auto Scaling Warm Pools
+A warm pool is a pool of pre-initialized EC2 instances that sits alongside the Auto Scaling group. Whenever your application needs to scale out, the Auto Scaling group can draw on the warm pool to meet its new desired capacity. A warm pool gives you the ability to decrease latency for your applications that have exceptionally long boot times, for example, because instances need to write massive amounts of data to disk. With warm pools, you no longer have to over-provision your Auto Scaling groups to manage latency in order to improve application performance. For more information and example configurations, see [Warm pools for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html) in the Amazon EC2 Auto Scaling User Guide.
+
+### Warm pool instance lifecycle
+Instances in the warm pool maintain their own independent lifecycle to help you create the appropriate lifecycle actions for each transition. An Amazon EC2 instance transitions through different states from the moment it launches through to its termination. You can create lifecycle hooks to act on these event states, when an instance has transitioned from one state to another one.
+
+The following diagram shows the transition between each state:
+
+![aws-asg-wp-lifecycle](../../../images/aws-asg-wp-lifecycle.png)
+
+### Verify
+After terraform apply, you will see an instance in the warm pools. That instance will be launched to run the user-data script for application initialization when it is registered with the warm-pool. In this example, the user-data script waits for a while to simulate a long working time.
+
+![aws-asg-wp-init-instance](../../../images/aws-asg-wp-init-instance.png)
+
+After initialization, the instance state changes to 'Stopped' for waiting.
+
+![aws-asg-wp-stopped](../../../images/aws-asg-wp-stopped.png)
+
+To check the elpased time to initial configuration of the instance, run this script:
+```
+bash elapsedtime.sh
+```
+The output of this command shows the duration of the instance launch.
+```
+Launching a new EC2 instance into warm pool: i-0180961b460339ed3 Duration: 215s
+```
+
+### Launch a new instance from warm pool
+Modify the *desired_capacity* value of *warmpools* in *node_groups* in [main.tf](https://github.com/Young-ook/terraform-aws-ssm/tree/main/examples/blueprint/main.tf) file to 1 to scale out the current autoscaling group. After terraform configuration file update, run again terraform apply.
+```
+terraform apply
+```
+The output of the change plan will be displayed. Check it, and enter *yes* to confirm. After a few minutes, run the script below to see the history of Autoscaling group activity and the elapsed time of each operation.
+```
+bash elapsedtime.sh
+```
+The output of this command shows the duration of the instance launch.
+```
+Launching a new EC2 instance from warm pool: i-0180961b460339ed3 Duration: 19s
+Launching a new EC2 instance into warm pool: i-0180961b460339ed3 Duration: 215s
+```
+
+![aws-asg-activity-history](../../../images/aws-asg-activity-history.png)
+
+### Connect
+Move to the EC2 service page on the AWS Management Conosol and select Instances button on the left side menu. Find an instance that you launched. Select the instance and click 'Connect' button on top of the window. After then you will see three tabs EC2 Instance Connect, Session Manager, SSH client. Select Session Manager tab and follow the instruction on the screen.

examples/blueprint/main.tf

@@ -73,7 +73,7 @@ module "ec2" {
       max_size      = 1
       instance_type = "t3.small"
       tags          = merge({ eipAllocId = aws_eip.eip.id })
-      user_data     = file("${path.module}/templates/eip.tpl")
+      user_data     = file("${path.module}/apps/eip/eip.tpl")
       policy_arns   = [aws_iam_policy.eip.arn]
     },
     {
@@ -102,7 +102,7 @@ module "ec2" {
       min_size      = 0
       max_size      = 3
       instance_type = "t3.small"
-      user_data     = templatefile("${path.module}/templates/httpd.tpl", { lc_name = "warmpools-lifecycle-hook-action" })
+      user_data     = templatefile("${path.module}/apps/warmpools/httpd.tpl", { lc_name = "warmpools-lifecycle-hook-action" })
       policy_arns   = [aws_iam_policy.lc.arn]
       warm_pool = {
         max_group_prepared_capacity = 2
@@ -140,7 +140,7 @@ resource "aws_autoscaling_lifecycle_hook" "lc" {
 }
 
 resource "local_file" "elapsedtime" {
-  content = templatefile("${path.module}/templates/elapsedtime.tpl", {
+  content = templatefile("${path.module}/apps/warmpools/elapsedtime.tpl", {
     asg_name = module.ec2.cluster.data_plane.node_groups.warmpools.name
     region   = var.aws_region
   })