diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..dfe0770 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,2 @@ +# Auto detect text files and perform LF normalization +* text=auto diff --git a/README.md b/README.md index a42f263..c9f25f2 100644 --- a/README.md +++ b/README.md @@ -1,29 +1,50 @@ +> 이 문서는 https://github.com/tryolabs/aws-workshop 를 Fork하여 작성되었습니다. + # AWS Workshop -This workshop aims to introduce the reader to managing infrastructure using [Amazon Web Services](https://aws.amazon.com/) (AWS). +이 워크숍에서는 여러분에게 [Amazon Web Services](https://aws.amazon.com/) (AWS) 을 이용하여 인프라를 관리하는 방법을 소개하고자 합니다. + +우리는 실제 애플리케이션을 배포하는 방법을 배웁니다. +데모 애플리케이션으로는 Conduit라 불리는 [오픈소스 테스트 애플리케이션](https://github.com/gothinkster/realworld)을 사용합니다. +이는 같은 애플리케이션이 여러 가지 백엔드와 프런트엔드 프레임워크에 구현되어 있어, +새로운 프레임워크를 배울 때 편리하기 때문입니다. +특히, 우리는 [React](https://reactjs.org/)와 [Django](https://www.djangoproject.com/) + [Django-Rest-Framework](http://www.django-rest-framework.org/) 백엔드로 작성된 버전을 사용할 예정입니다. -We will learn to deploy real applications. As our demo app, we will use an [open source](https://github.com/gothinkster/realworld) test application called Conduit, which is handy to learn new frameworks because the same app has implementations in multiple frameworks for backend and frontend. In particular, we will use the version built with [React](https://reactjs.org/) and [Django](https://www.djangoproject.com/) + [Django-Rest-Framework](http://www.django-rest-framework.org/) backend. +이 레포지토리에서, +여러분은 앞으로 사용할 인프라에 맞게 설정이 수정된, +백엔드와 프론트엔드 컴포넌트를 찾을 수 있습니다. -In this repo, you can find the backend and frontend components, both with modified settings to fit our future infrastructure. +# 전제조건 -# Preconditions +실습을 위해서는 AWS 계정이 꼭 필요합니다. +실습 대부분이 프리 티어를 사용하겠지만, 일부 서비스에서 비용이 발생할 수 있습니다. +따라서 여러분은 이 워크숍을 끝내기 위해 몇 달러(US 5달러 미만)를 쓸 준비가 되어 있어야 합니다. +> AWS 계정을 가지고 계시지 않은 분은 우선 실습 진행자에게 문의해 주시기 바랍니다. -You must have an AWS account. Even though you mostly will be in the free tier, some services like Elastic Load Balancers, Encryption Keys, and others **will be billed**. This means that you should be ready to spend a few dollars (< 5 U$S) to complete this workshop. +원하신다면, +만일의 경우를 대비하여 +[AWS 예산을 사용한 AWS 프리 티어 사용 알림](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free-tier-alarms.html)을 이용하여 이러한 상황을 회피할 수 있습니다. -If you want to, you can [set up a billing alarm](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free-tier-alarms.html) to avoid these situations, just in case. +## AWS 관리 콘솔 언어 설정 -> **TryoTip:** if you are doing this workshop as part of Tryolabs training, feel free to ask for access to the **Tryolabs Playground AWS account**. This way, you will not have to put your own credit card. +이 워크숍에서 사용하는 **AWS 관리 콘솔** 메뉴는 영문 메뉴를 기준으로 설명되어져 있습니다. 관리 콘솔의 표시 언어는 콘솔 화면 맨아래에 있는 언어 설정 버튼을 눌러서 변경 할 수 있습니다. -# Content +# 목차 -This workshop contains the following sections: +이 워크숍의 섹션은 다음과 같습니다: -1. [Set up users](/workshop/set-up-users.md). -2. [S3, RDS and EC2](/workshop/s3-web-ec2-api-rds/introduction.md). Here, you will deploy the website on S3, the backend will store the data using RDS and the API will be deployed on EC2. -3. [Load Balancer and Auto Scaling Group](/workshop/elb-auto-scaling-group/introduction.md). -4. [VPC configuration and Bastion instance](/workshop/vpc-subnets-bastion/introduction.md). Here, you will setup your own VPC with public and private subnets, modify your Auto Scaling Group and Load Balancer to work with those and add a Bastion to access to your API instances through SSH. -5. [Beanstalk](/workshop/beanstalk/introduction.md). Here we will learn how to use Beanstalk to setup and manage our backend (EC2 + ASG + ELB) without handcrafting every detail of the setup. +1. [IAM 사용자 설정하기](/workshop/set-up-users.md). +2. [S3, RDS 그리고 EC2](/workshop/s3-web-ec2-api-rds/introduction.md). + 여기에서 여러분은 S3에 웹사이트를 배포하고, 백엔드는 RDS에 데이터를 저장하며, API는 EC2에 배포됩니다. +3. [Load Balancer와 Auto Scaling Group](/workshop/elb-auto-scaling-group/introduction.md). +4. [VPC 설정과 베스천 호스트](/workshop/vpc-subnets-bastion/introduction.md). + 여기에서 여러분은 퍼블릭 및 프라이빗 서브넷를 가진 VPC를 설정하고, 이에 맞게 Auto Scaling Group(ASG) 및 Load Balancer(ELB)를 수정하며, + SSH를 통하여 API 인스턴스에 접근하기 위한 **베스천 호스트**(Bastion Host)를 추가합니다. +5. [Beanstalk](/workshop/beanstalk/introduction.md). + 여기에서 여러분은 모든 상세한 설정을 수작업으로 작성하지 않고, 백엔드(EC2 + ASG + ELB)를 설정하고 관리하기 위한 Beanstalk 사용법을 배웁니다. --- -**Next:** assuming you already have an AWS account, you can [get started](/workshop/set-up-users.md). +**다음:** AWS 계정을 가지고 계시면, 바로 [시작합시다](/workshop/set-up-users.md). + + diff --git a/workshop/beanstalk/01-clean-up.md b/workshop/beanstalk/01-clean-up.md index 82ae0df..4def2f2 100644 --- a/workshop/beanstalk/01-clean-up.md +++ b/workshop/beanstalk/01-clean-up.md @@ -1,32 +1,29 @@ -# Clean up - -We have a pretty interesting infrastructure running now so in order to integrate Beanstalk we need to remove some services to make room. Our current setup has four major components: Elastic Load Balancer (ELB), Auto Scaling Group (ASG), Virtual Private Cloud (VPC) and Relational Database Service (RDS). As powerful as it is Beanstalk [can't setup VPCs](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/vpc.html) for you and [is not recommend](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.RDS.html) for RDS other than for testing environments so we are going to keep these two and remove the ELB and ASG. - -To remove the ELB: - -1. On your AWS Console, go to **EC2** under **Compute** -2. Click on **Load Balancers** under **LOAD BALANCING** -3. Select the load balancer we created earlier. We used the name `aws-workshop-load-balancer` -4. Click **Actions** -5. Select **Delete** -6. Click **Yes, Delete** - -Now do the same for the **Target Groups**, **Launch Configurations** and **Auto Scaling Groups**. - -Once you completely remove the ELB and ASG we need to terminate the EC2 instances we have running. - -1. Go to **EC2** under **Compute** -2. Click on **Instances** -3. Using the checkbox at the left select all the instances that aren't the Bastion (if you have it running) and the NAT instance. -4. Click **Actions** -5. Click **Instance State** -6. Click Terminate -7. Click **Yes, Terminate** - -Next we are going to setup our application with a production environment. +# 제거하기 +Beanstalk를 지금의 인프라에 연동하기 위해서, 몇가지 써비스를 없애야 합니다. 현재 셑업은 네개의 컴포넌트 Elastic Load Balancer (ELB), Auto Scaling Group (ASG), Virtual Private Cloud (VPC), 그리고 Relational Database Service (RDS) 있습니다. Beanstalk은 [VPCs](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/vpc.html) 를셑업하지 못하며, 테스팅 환경외의 RDS를 [추천하지](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.RDS.html) 않기때문에, VPC 와 RDS를 뺀 나머지 써비스 ELB and ASG를 지웁니다. + +ELB 없애기: +1. AWS 콘솔에서, **Compute** 아래 **EC2** 로 가십시오 +2. **LOAD BALANCING** 아래 **Load Balancers** 를 클릭하십시오 +3. `aws-workshop-load-balancer` 라고 명명된 로드밸런서를 선택하십시오 +4. **Actions** 클릭하십시오 +5. **Delete** 선택하십시오 +6. **Yes, Delete** 클릭하십시오 + +이제는 위와 똑같은 실행을 **Target Groups**, **Launch Configurations** 그리고 **Auto Scaling Groups** 하십시오. + +ELB와 ASG를 완전히 없앤다음, 사용하던 EC2를 터미네이트 해야합니다. +1. **Compute** => **EC2** 로 가십시오 +2. **Instances** 에 클릭하십시오 +3. 왼쪽편 첵박스에 Bastion이 아니고 NAT인스턴스인 모든 인스턴스를 선택하십시오 +4. **Actions** 클릭하십시오 +5. **Instance State** 클릭하십시오 +6. Terminate 클릭하십시오 +7. **Yes, Terminate** 클릭하십시오 + +다음은 프로덕션 환경에 애플리케이션을 셋업합니다. --- -**Extra mil:** when all the instances are terminated remove all the security groups that aren't needed anymore. Could you leave your setup broken by doing this? +**추가 작업:** 모든 인스턴스를 종료 한 다음, 필요없는 보안 그룹은 모두 없앱니다. 이렇게 고장난 셋업을 방치해도 될까요? --- -**Next:** [create a new app](/workshop/beanstalk/02-new-app-environment.md) \ No newline at end of file +**다음:** [새로운 앱 만들기](/workshop/beanstalk/02-new-app-environment.md) diff --git a/workshop/beanstalk/02-new-app-environment.md b/workshop/beanstalk/02-new-app-environment.md index 20265db..cd9e117 100644 --- a/workshop/beanstalk/02-new-app-environment.md +++ b/workshop/beanstalk/02-new-app-environment.md @@ -1,57 +1,58 @@ -# Create new app +# 새로운 앱 만들기 -> **Important:** these steps refer to the last UI available for Elastic Beanstalk. If the Elastic Beanstalk site asks you to _opt in_ to a new UI choose to use it. +> **중요한점:** 다음 스텝들은 최근 Elastic Beanstalk 사용자 인터페이스를 지칭하고 있습니다. 만약 Elastic Beanstalk 싸이트가 새로운 사용자 인터페이를 사용할것을 요청하면, 그렇게 하십시오. -Now we are going to start using Beanstalk to manage our production environment. First we need to create a new application. +이제 Beanstalk를 사용하여 운영환경을 매니징을 시작합니다. 우선 새로운 애플리케이션을 다음과 같이 만듭니다. -1. Go to **Elastic Beanstalk** under **Compute**. -2. Click **Create New Application** on the top right. -3. Set the **Application Name** to `Conduit` -4. Click **Create** +1. **Compute** 아래 **Elastic Beanstalk** 로 갑니다. +2. 오른쪽 상단 **Create New Application**에 클릭합니다. +3. **Application Name**을 `Conduit`로 합니다. +4. **Create**에 클릭합니다. -Now we have a new application without any environment so we are going to add a new one. To provision our new environment we need to give to Beanstalk a snapshot of our app in a zip file ([here](/workshop/backend/beanstalk_deploy.zip) is the one we are going to use), this is how the deploys work in Beanstalk. When we upload a new snapshot Beanstalk extract it, install all the dependencies declared in `requirements.txt` and execute the actions declared in a special folder called [.ebextensions](/workshop/backend/.ebextensions). Check the content of that folder for more details. +위에서 만든 새로운 애플리케이션에 환경을 더합니다. 새로운 환경을 규정하기위에서, Beanstalk에 새로만든 애플리케이션 스냅샵을 압축파일로 제공합니다([사용할앱 다운로드](/beanstalk_deploy.zip URL goes here)), 이렇게 Beanstalk에서 배포가 작동합니다. Beanstalk가 업로드된 새로운 애플리케이션 스냅샵을 압축파일을 풀기위해, `requirements.txt`에 있는 모든 의존파일을 설치및 [.ebextensions](/workshop/backend/.ebextensions)폴더에있는 액션들을 실행합니다. 자세한 내용은 앞서말한 폴더를 참조하십시오. -1. Click **Actions**, **Create environment** -2. Now we have to choose an _"environment tier"_, we have: [Web server environment](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts-worker.html) for web apps that handle HTTP requests and [Worker environment](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts-worker.html) for apps that handle input from an AWS serial queue, typically for long running tasks. We are going to select **Web server environment** and click **Select** -3. Change **Environment name** to `Conduit-prod` -4. In **Domain** put `conduit-prod` and click **Check availability**. -5. Click on **Choose a platform** and select **Python** under **Preconfigured** -6. Select **Upload your code** in **Application code** and click **Upload**. -7. Now you could choose a location on your local machine or a bucket on S3, we are going to use [this zip](/workshop/backend/beanstalk_deploy.zip) so download it, click on **Choose file** and select the zip. -8. On **Version label** put a mining full description like _"First version"_ -9. We could terminate the process now and we will have a working environment with an ELB and ASG properly set up. But we need to configure other details to like use our VPC and the RDS instance. So instead we are going to click **Configure more options**. -10. Choose **Custom configuration** under **Configuration presets**. Look how the options change for every preset. +1. **Actions** => **Create environment** 클릭하십시오. +2. _"environment tier"_를 선택하십시오. 긴시간 처리를 위해, HTTP요청 [웹서버 환경](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts-worker.html) 와 AWS serial queue 처리를 위해 [작업 환경](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts-worker.html)가 있습니다. +**Web server environment**를 선택한다음 **Select** 클릭하십시오. +3. **Environment name**를 `Conduit-prod`로 바꾸십시오. +4. **Domain**에 `conduit-prod` 라고 쓰고 **Check availability**에 클릭하십시오. +5. **Choose a platform**에 클릭한 다음 **Preconfigured** 아래 **Python**를 선택하십시오. +6. **Application code**에 **Upload your code**를 선택한다음 **Upload**에 클릭하십시오. +7. 여기서 로컬 또는 S3 버킷을 선택할수 있습니다. 이번 예제에서는 [예제 다운로드](/workshop/backend/beanstalk_deploy.zip)를 사용하니, **Choose file** 클릭한다음 압축파일을 선택합니다. +8. **Version label**에 _"First version"_ 같이 알아볼수있는 이름을 쓰십시오. +9. 여기서 프로세스를 터미네이트 하고 ELB and ASG 환경을 셋업할수있지만, VPC 와 RDS를 지정하기위해 **Configure more options**를 클릭합니다. +10. **Configuration presets**밑에 **Custom configuration**를 선택하십시오. 각 preset마다 어떻게 선택사항이 바뀌는지 보십시오. -This is an important step, here we can control almost all the aspects regarding how our instances are going to be provisioned and how to configure their environment and behavior (ELB and ASG). Do you remember how much details we need to take into account to setup these parameters by hand? This is one of the stronger points in using Beanstalk. +이번은 중요한 스텝입니다. 여기서 우리는 우리의 인스턴스, 환경, 그리고 ELB 와 ASG 어떻게 규정되고 구성되는걸 조정할수 있습니다. 인스턴스, 환경, 그리고 ELB 와 ASG등에 얼만큼 신경을 써야하는 기억하십니까? 이점이 바로 Beanstalk를 사용해야하는 이유입니다. -Take a moment to investigate this screen, don't make any change but look around. This dashboard is going to be available to make changes to the environment when we finish. +다음 스크린은 바꾸지말고, 보기만 하십시오. 여기 대시보드를 바꿀수있는 기회는 끝에가면 있습니다. -1. Now go to the **Security** card and click **Modify** -2. Click on **Choose a key pair** on the **Virtual machine permissions** and select the key pairs you created during the workshop. -3. Click **Save**. If you pay attention you will notice that we are leaving the **IAM instance role** in the default value instead of using the **_ApiRol_** we created before for provisioning our instances. That's because we need an extra set of permissions that Beanstalk already puts together in a default role. +1. **Security** 카드로 가서 **Modify**에 클릭하십시오. +2. **Virtual machine permissions**에 **Choose a key pair**를 클릭한다음, 이번 워크샵중에 만든 키페어를 선택하십시오. +3. **Save**를 클릭하십시오. 여기서 주의를 기울인다면, **IAM instance role**를 떠나서 인스턴스 규정할때 만든 **_ApiRol_** 를 사용한다는 것을 알것입니다. 그이유는 Beanstalk가 이미 우리에게 필요한 엑스트라롤을 설정했기 때문입니다. -Now we are going to setup our environment to use the VPC we have in place. +여기서는 VPC를 우리환경에 설정합니다. -1. Go to **Network** card and click **Modify** -2. Scroll to the top and click the dropdown next to the **VPC** field and select your VPC. -3. In the **Load balancer settings** section make sure the **Visibility** dropdown has the **Public** option selected. -4. Under **Load balancer subnets**, select the checkbox on the left for the public subnets (those are with the CIDR 10.0.1.0/24 and 10.0.3.0/24). -5. In **Instance settings** go to **Instance subnets** grid and select the privates subnets (the ones with CIDR 10.0.2.0/24 and 10.0.4.0/24). -6. In **Instance security groups** select the group with name **default**. -7. Click **Save** -8. Click **Create environment** +1. **Network** 카드로 가서 **Modify**를 클릭하십시오. +2. 화면 위쪽으로 올린다음 **VPC**옆 드랍다운에 본인의 VPC를 선택하십시오. +3. **Load balancer settings** 섹션에서 **Visibility** 드랍다운에 **Public**를 선택하십시오. +4. **Load balancer subnets** 아래에 첵박스 왼쪽편 공동 섭넷(CIDR 10.0.1.0/24 and 10.0.3.0/24)를 선택하십시오. +5. **Instance settings** => **Instance subnets**, 개인 섭넷(CIDR 10.0.2.0/24 and 10.0.4.0/24)을 선택하십시오. +6. **Instance security groups**에서 그룹 이름으로 **default**를 선택하십시오. +7. **Save** 클릭하십시오. +8. **Create environment** 클릭하십시오. -Now the setup of the environment is running. When it finishes, we are going to have a full working load balancer with an auto scaling group that starts instances in the VPC we have setup earlier. +환경설정이 끝나면, 앞서 우리가 설정한 VPC안에서 로드밸런서와 오토 스케일링이 작동할것입니다. -When the setup finishes you will land on the environment dashboard. At the top is the URL associated with the load balancer, next to the **All Applications** > **Conduit** > **Conduit-prod**. Try clicking that URL and append the `/api`. You should get an error now because we still need to push some buttons but the API is there. +설정이 끝나면, 환경 대시보드 맨 위쪽에 **All Applications** > **Conduit** > **Conduit-prod**이 로드 밸런서 URL 입니다. URL를 클릭한다음 `/api`를 주소창끝에 붙이십시오. 여기서 에러가 나는 이유는 몇개의 버튼을 API를 이용해서 배포해야합니다. -If for some reason the deploy fails take a look at [this troubleshooting](/workshop/beanstalk/troubleshooting.md). If you feel comfortable with the command line there is a CLI tool to interact with Elastic Beanstalk that is much more comfortable to use than the AWS console for maintenance tasks. Check [here](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3.html) for more. +만약에 어떠한 이유로 배포가 실패했을경우, 다음 링크를 보십시오[문제해결](/workshop/beanstalk/troubleshooting.md). CLI가 AWS console보다 익숙한 사용자를위해, Elastic Beanstalk를 상호작용할수 있는 CLI가 있습니다. 자세한 사항은 [이쪽](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3.html)을 보십시오. --- -**Extra mil:** +**도전 과제:** -- Once the setup finishes, take a look at how Beanstalk did the setup for the ELB and ASG. Is it different from the one we did? how? -- You should have your bastion instance running (if not take a look on [how to run one](/workshop/vpc-subnets-bastion/07-bastion.md)) so why not try to log to the new instance? Tip: the username for Amazon Linux is `ec2-user` +- 셋업이 끝나면, Beanstalk이 ELB 와 ASG를 셋업했는지 보십시오. 우리가 직접한것과 다릅니까? 어떻게 다릅니까? +- bastion이 런하는 인스턴스를 갖고 있을테니, 그 인스턴스에 로그인 해보십시오. 만약에 런하지 않는다면, 다음을 보십시오 [런하는 방법](/workshop/vpc-subnets-bastion/07-bastion.md)) 팁: Amazon Linux 사용자명은 `ec2-user` 입니다. --- -**Next:** [finish integration](/workshop/beanstalk/03-finish-integration.md) \ No newline at end of file +**다음:** [연동 끝맺기](/workshop/beanstalk/03-finish-integration.md) diff --git a/workshop/beanstalk/03-finish-integration.md b/workshop/beanstalk/03-finish-integration.md index d18ab9b..ed5820a 100644 --- a/workshop/beanstalk/03-finish-integration.md +++ b/workshop/beanstalk/03-finish-integration.md @@ -1,59 +1,55 @@ -# Finish integration +# 연동 끝맺기 -Now that we have our instance running we need to adjust some details to make it work with the other components of our infrastructure. Those are: our frontend in S3 and the database in RDS. Now we have to tell the frontend that the API now is reachable in another URL. +지금 우리의 인스턴스가 다른 구성원과 협업하기위해서는 세부사항을 조율해야 합니다. 그들은 S3 프론트엔드와 RDS 데이타베이스 입니다. 여기서 우리는 다른 URL에있는 API를 부를수 있다고 프론트단에 말해줘야 합니다. -First we need the new URL for the API. +우선 우리는 API를 위한 새로운 URL을 필요로 합니다. +1. **Compute** 아래 **Elastic Beanstalk** 로 가십시오. +2. **Conduit** 애플리케이션 아래 **Conduit-prod** 카드에 클릭하십시오. +3. 맨위, **All Applications** 끝쪽에 **Environment ID** 와 **URL** 가 있습니다. URL을 복사하십시오. -1. Go to **Elastic Beanstalk** under **Compute**. -2. Click the **Conduit-prod** card under the **Conduit** application. -3. At the top, in the end of **All Applications**... breadcrumb you have the **Environment ID** and **URL**. Copy that URL. +이제 우리는 API URL를 프론트단 Parameter Store에 붙이기를 합니다. +1. **Compute** 아래 **EC2**로 가십시오. +2. **SYSTEMS MANAGER SHARED RESOURCES** 아래 **Parameter Store**를 클릭하십시오. +3. **/prod/frontend/API_URL** 를 선택하십시오. +4. **Actions** => **Edit Parameter** 클릭하십시오. +5. 인풋 박스에 API URL 붙여넣기를 하십시오. URL이 `elasticbeanstalk.com`로 끝날수 있도록 `/`를 제거하십시오. `/`를 제거하지 않으면 API요청은 실패할것입니다. -Now we need to paste the API URL in the Parameter Store read for the frontend. +이번 바꿈이 효과를 발휘하기위해서는, CodeBuild를 런해야하는데, 왜냐하면 바뀐값은 [플론트단 배포](buildspec.frontend.yml)시간에 읽기 때문입니다. +1. **Developer Tools** 아래 **Code Build**로 가십시오. +2. 당신의 프로젝을 클릭하십시오. +3. **Build History** 섹션에서, 가장 최근 빌드에 첵 하십시오. +4. **Retry** 클릭하십시오. -1. Go to **EC2** under **Compute**. -2. Click on **Parameter Store** under **SYSTEMS MANAGER SHARED RESOURCES**. -3. Select the parameter **/prod/frontend/API_URL**. -4. Click **Actions**, **Edit Parameter**. -5. In the value field past the URL for the API. You may need to remove the last `/` so the URL ends in `elasticbeanstalk.com`. If you left the last path separator all the API calls will fail. +빌드이름에 클릭하면 진행과정을 볼수있습니다만, 얼마 걸리지 않을것입니다. 빌드가 완성되면, 프론트단은 새로운 프로덕션 환경을 콜하게 될것입니다. 하지만, 우리는 API를 콜할수있는 허가를 주기전까지 그 콜은 성공하지 않을것입니다. 이것은 전에 **ApiRole**에 했던것과 같습니다만, 여기서 우리는 Beanstalk이 생성한 롤을 사용하기 때문에, 읽기허가를 Parameter Store에 주어야 합니다. -For this change to take effect we need to run CodeBuild because this value is read when the [frontend is deployed](buildspec.frontend.yml). +1. **Security, Identity & Compliance** 아래 **IAM**로 가십시오. +2. 왼쪽편 **Roles** 클릭하십시오. +3. **aws-elasticbeanstalk-ec2-role** 클릭하십시오. 이 Beanstalk가 EC2 인스턴스를 사용하기위해 만든 롤입니다. +4. **Permissions** 탭에 **Attach policy** 클릭하십시오. +5. 서치바에 클릭한다음 `AmazonSSMReadOnlyAccess`를 찾아서 첵박스에 클릭하십시오. +6. **Attach policy** 클릭하십시오. -1. Go to **Code Build** under **Developer Tools**. -2. Click your project name. -3. In the **Build History** section, select the checkbox at the left for the most recent build. -4. Click **Retry**. +이제 우리 인스턴스가 Parameter Store를 접속할수있으나, 아직도 비밀번호가 걸려있는값들은 읽을수 없습니다. 해결책으로 우리 암호화 키에 **aws-elasticbeanstalk-ec2-role**롤을 주고 모두가 접속할수있도록 합니다. -You can click the build name to follow the progress, it shouldn't take too long. When the build completes, the frontend will be hitting our new production environment. However, it won't work because we still need to give permissions to access the Parameter Store to our API web instances. This is the same we did in the past with our **ApiRole**, but as we are using the role created by Beanstalk for provisioning our instances now, we need to grant read access to the Parameter Store to that role. +1. **Security, Identity & Compliance** 아래 **IAM**, **Encryption keys** 가십시오. +2. **Key Users** 섹션까지 스크롤을 내린다음 **This Account** 부섹션 아래 **Add** 클릭하십시오. +3. **aws-elasticbeanstalk-service-role** 롤을 선택하십시오 +4. **Attach** 클릭하십시오. -1. Go to **IAM** under **Security, Identity & Compliance**. -2. Click **Roles** in the left pane. -3. Click **aws-elasticbeanstalk-ec2-role**, that's the role created for Beanstalk to use in the EC2 instances. -4. Click **Attach policy** in the **Permissions** tab. -5. Click the search bar and look for `AmazonSSMReadOnlyAccess` and select the checkbox in the left. -6. Click **Attach policy**. +좋습니다. 이제 우리 인스턴스는 Parameter Store 안에 있는 모든 파라미터를 접속할수 있습니다. 여기서 Parameter Store에 값을 읽기위해 서버를 다시 시작해야합니다. -Great, now our instances can access the Parameter Store, but they still can't read the password protected values. To fix this we need to grant access to anyone with the **aws-elasticbeanstalk-ec2-role** role to our encryption keys. +1. **Compute** 아래 **Elastic Beanstalk**로 가십시오. +2. **Conduit** 애플리케이션 아래 **Conduit-prod** 카드를 클릭하십시오. +3. 오른쪽편에 **Action** 클릭하십시오 +4. **Restart App Server(s)** 클릭하십시오. -1. In **IAM** under **Security, Identity & Compliance**, go to **Encryption keys**. -2. Scroll down to **Key Users** section and click **Add** under **This Account** sub section. -3. Select the **aws-elasticbeanstalk-service-role** role. -4. Click **Attach**. - -Ok, so our instances have full access to all the parameters in the Parameter Store now. We need to restart the server in our prod environment because the values from the Parameter Store are read when the app starts. - -1. Go to **Elastic Beanstalk** under **Compute**. -2. Click the **Conduit-prod** card under the **Conduit** application. -3. Click **Action** on the right. -4. Click **Restart App Server(s)**. - -When the restart finishes the API should be working. You can navigate to the prod environment URL, append `/api` to get the default Django Rest-Framework page describing the API. Try also to navigate to the front end and inspect some of the requests to confirm that you are using the right environment. +서버가 다시시작되면, API가 작동을 할것입니다. 프로덕션 환경 URL 뒤에 `/api`를 붙이면, API 를 기술한 Django Rest-Framework 페이지를 볼수있습니다. 그리고 맞는 환경에 있는지 확인하기위해 몇몇의 프론엔드링크를 테스트 해보십시오. --- -**Extra mil:** - -- What about the RDS? Why is it working without touching anything? -- Check the **Scaling** card in the **Configuration** options for the environment. Click the gear and a **Time-based Scaling** action. Check how that change impact the configuration. -- Not sure about the database? Login to one of your instance, install `postgresql` and try it yourself. Tip: Amazon Linux use [yum](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-software.html) package manager. +**도전 과제:** +- 왜 RDS는 아무런 조치를 안했는데 작동하나요? +- 환경을 위해 **Configuration** 선택지에 **Scaling**를 보십시오. **Time-based Scaling** 액션을 클릭하십시오. 그리고 그것이 구성에 어떤변화를 주는지 보십시오. +- 데이타베이스는 확신할수 없나요? 한 인스턴스에 로그인 해서, `postgresql` 를 설치한다음 해보십시오. 팁: Amazon Linux는 [yum](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-software.html)을 사용합니다. --- -**Next:** [conclusion](/workshop/beanstalk/04-conclusion.md) \ No newline at end of file +**다음:** [결론](/workshop/beanstalk/04-conclusion.md) diff --git a/workshop/beanstalk/04-conclusion.md b/workshop/beanstalk/04-conclusion.md index a0cb9bf..8b4adbe 100644 --- a/workshop/beanstalk/04-conclusion.md +++ b/workshop/beanstalk/04-conclusion.md @@ -1,16 +1,16 @@ -# Conclusion +# 결론 -If everything went as expected you have now a running production-ready environment accessible from the same frontend as before. Take some time to explore what Beanstalk offer from the environment dashboard. There are plenty of interesting metrics and health status reports. +모든 것이 예상대로 진행 되었다면 이전과 동일한 프론트 엔드에서 실행 가능한 실제 운영 환경을 사용할 수 있습니다. Beanstalk이 환경 대시 보드에서 제공하는 것을 탐색 할 시간을 가지십시오. 흥미로운 통계 및 건강 상태 보고서가 많이 있습니다. -The more valuable feature of Beanstalk is the ability to setup and terminate environments for the same application independently. This makes a big difference when you are working on a real project where the changes have to be tested before move to production, new people come to the project and other leave, you need to demo things without the risk of some other team member break the app because it's on active development, etc. In that kind of situations is where Elastic Beanstalk shine. +Beanstalk의 더 가치있는 기능은 동일한 응용 프로그램의 환경을 독립적으로 설정하고 종료 할 수있는 기능입니다. 이것은 실제 프로젝트에서 작업 할 때 큰 변화를 일으 킵니다. 변경 사항을 프로덕션으로 이동하기 전에 테스트해야하고, 새로운 사람들이 진행중인 프로젝에 합류하거나 떠납니다. 그와중에 개발중인 애플리케이션을 팀원이 고장내지않게 하면서 데모를 해야합니다. 이런상황이 바로 Elastic Beanstalk 이 빛을 발휘하는 때입니다. --- -**Extra mil:** +**도전 과제:** -- Thinking about the later our current app architecture (frontend in S3 and API in EC2) is not the ideal combination for taking the most out of multi-environment scenarios. There are many options on how to do this and there are all good and bad depending on the case. Try to think about this and come up with your idea of how can you make the environment management more simple and implement it. +- 최신 앱 아키텍처 (S3의 프론트 엔드 및 EC2의 API)에 대해 생각해 보면 다중 환경 시나리오를 최대한 활용하는 데 이상적인 조합은 아닙니다. 이 작업을 수행하는 방법에는 여러 가지 옵션이 있으며 사례에 따라 모두 좋고 나쁨이 있습니다. 이것을 생각해보고 환경 관리를보다 단순하게 만들고 구현할 수있는 방법에 대해 생각해보십시오. -What is the big pain point? +Beanstalk 사용에 앞서 가장 큰 걸림돌은? -- We mentioned [earlier](/workshop/beanstalk/introduction.md) that letting Beanstalk manage your RDS instances is **not** recommended for production environments. This is because in order to handle your environment configuration Beanstalk needs to handle the life time of your instances like if they were stateless entities. A database is the opposite of that. +- [앞서](/workshop/beanstalk/introduction.md) 말했듯이 Beanstalk 안에 프로덕션 RDS를 관리하는것 은 추천하지 **않습니다**. 이유는 환경구성을 위해서 Beanstalk은 인스턴스를 상태 비저장으로 다뤄야만 합니다만, 데이타베이스는 그 반대입니다. -Try creating a new environment with an internal RDS called **Conduit-staging**. \ No newline at end of file +**Conduit-staging** 이라는 내부 RDS가있는 새로운 환경을 만들어보십시오. diff --git a/workshop/beanstalk/introduction.md b/workshop/beanstalk/introduction.md index 3194db1..b246a92 100644 --- a/workshop/beanstalk/introduction.md +++ b/workshop/beanstalk/introduction.md @@ -1,20 +1,21 @@ # Beanstalk -[Elastic Benstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) is an AWS service that allows us to deploy a web app without having to worry about what combination of AWS services might be needed. All we have to do is describe what we need and let Beanstalk do the rest (create security groups, setup a load balancer, etc). +[Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) 는 웹 애플리케이션 배포에 앞서 해야할 일들(보안 그룹, 로드 밸런서 등등)을 걱정할 필요없이 쉽게 배포할수 있도록 해줍니다. 그걸하기위해 우리가 해야할일은 Beanstalk가 해야할일을 지정해주고 기다리는 일뿐입니다. -Beanstalk also have some nice tools that aren't available in other AWS services that really add value other than the automatic setup, those are: +Beanstalk는 또한 다른 AWS 써비스는 제공하지 않는 몇몇의 나이스한 툴을 제공하는데요. 그들은: -- The ability to manage different environments for the same app (dev, prod, testing, etc). -- Centralized panel to handle the setup for each environment. -- Great monitoring metrics. -- Detailed health status. -- Really easy to setup new environments quickly. +- 앱 환경(개발, 운영, 테스팅 등등) 매니징. +- 각환경을 핸들할수있는 중앙 대시보드. +- 많은 감시 측정 항목. +- 자세한 현재 상황표시. +- 쉽고 빠른 환경 셋업. -At the time of writing this, Beanstalk support apps developed in Java, PHP, .NET, Node.js, Python, Ruby out of the box and you can build your custom containers for other platforms all running on Amazon Linux. +이 글을 쓰고있는 현재, Beanstalk는 Java, PHP, .NET, Node.js, Python, Ruby 로 개발된 앱을 써포트하며, 아마존 리눅스에 도는 여러분 자신들의 콘테이너도 빌드할수있습니다. -In this section we are going to use Beanstalk to setup a _production environment_ (this means with an [external RDS](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.RDS.html)) replacing our current Elastic Load Balancer (ELB) and Auto Scaling Group (ASG) setup with a Beanstalk-handled setup. -It's important to remember not to make manual changes over the components generated by Beanstalk because it could prevent the correct clean up if we decide to remove an environment in the future. So to start fresh we need to remove some things before creating our new environment. +이번 섹션에는 현 로드밸런서와 오토 스케일링을 대체할 프로덕션 환경 [외장 RDS](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.RDS.html)를 Beanstalk를 사용해서 셋업합니다. + +중요한것은 환경을 정확하게 지우기 위해서는, Beanstalk로 생성된 컴포넌트를 임의적으로 바꾸는일을 하지 않아야 합니다. 그래서 우리는 깨끗하게 시작하기 위해 몇가지를 지우고 시작해야 합니다. --- -**Next** [clean up current setup](/workshop/beanstalk/01-clean-up.md) \ No newline at end of file +**다음** [현재 셋업 제거하기](/workshop/beanstalk/01-clean-up.md) diff --git a/workshop/elb-auto-scaling-group/01-load-balancer.md b/workshop/elb-auto-scaling-group/01-load-balancer.md index 8bd1ba2..cdcf401 100644 --- a/workshop/elb-auto-scaling-group/01-load-balancer.md +++ b/workshop/elb-auto-scaling-group/01-load-balancer.md @@ -1,24 +1,27 @@ -# Create a Load Balancer +# Load Balancer 생성하기 -Elastic Load Balancing automatically distributes incoming application traffic across multiple targets, such as Amazon EC2 instances, containers, and IP addresses. When you are running applications in production, you typically will use multiple instances so if one fails, your application can still work. The Load Balancer will get the traffic, and will forward it to the instances that serve your app. You can more about this [here](https://aws.amazon.com/elasticloadbalancing/). +Elastic Load Balancing은 Amazon EC2 인스턴스 와 컨테이너, IP 주소와 같은 여러 대상을 통해 들어오는 트래픽을 자동으로 배분한다. -1. Go to **EC2** under **Compute** section. -2. On left menu select **Load Balancers** under **LOAD BALANCING**. -3. Click **Create Load Balancer**. -4. Select **Application Load Balancer**. -5. As name put: `aws-workshop-load-balancer`. -6. Select at least 2 Availability zones. -7. Click **Next: Configure Security Settings**. -8. Click **Next: Configure Security Groups**. -9. Select **Create a new security group** and as name put `load-balancer-security-group` and add a description. -10. Click **Next: Configure Routing**. -11. As name put: `aws-workshop-target-group`. -12. As Port: `9000`. -13. As path: `/api/tags`. -14. Click **Next: Register Targets**. -15. Click **Next: Review**. -16. Click **Create**. -17. Click **Close**. +production환경의 응용프로그램을 실핼할때, 우리는 하나가 실행이 불가능하여도 응용프로그램이 작동할 수 있도록 일반적으로 여러 인스턴스를 사용할 것이다. Load Balancer는 트래픽을 받아 응용프로그램의 인스턴스에 전송할 것이다. +더 자세한 사항은 [여기](https://aws.amazon.com/elasticloadbalancing/)를 참고해 주세요. + +1. **컴퓨팅** 섹션의 **EC2** 로 이동한다. +2. 왼쪽 메뉴에서 **로드 밸런싱** 섹션의 **로드밸런서** 선택한다. +3. **로드 밸런서 생성** 클릭한다. +4. **Application Load Balancer** 선택한다 +5. 이름: `aws-workshop-load-balancer` 입력한다. +6. 적어도 2개의 가용 영역 선택한다. +7. **다음: 보안 설정 구성** 클릭한다. +8. **다음: 보안 그룹 구성** 클릭한다. +9. **새 보안 그룹 생성** 선택 후 이름에 `load-balancer-security-group` 입력하고 설명 추가한다. +10. **다음:라우팅 구성** 클릭한다. +11. 이름: `aws-workshop-target-group` 입력한다. +12. 포트: `9000` 입력한다. +13. 경로: `/api/tags` 입력한다. +14. **다음: 대상 등록** 클릭한다. +15. **다음: 검토** 클릭한다. +16. **생성** 클릭한다. +17. **닫기** 클릭한다. --- -**Next:** [create an Auto Scaling Group](/workshop/elb-auto-scaling-group/02-auto-scaling-group.md). +**다음:** [Auto Scaling Group 생성하기](/workshop/elb-auto-scaling-group/02-auto-scaling-group.md). diff --git a/workshop/elb-auto-scaling-group/02-auto-scaling-group.md b/workshop/elb-auto-scaling-group/02-auto-scaling-group.md index 870ed66..8342cbd 100644 --- a/workshop/elb-auto-scaling-group/02-auto-scaling-group.md +++ b/workshop/elb-auto-scaling-group/02-auto-scaling-group.md @@ -1,20 +1,20 @@ -# Create Auto Scaling Group +# Auto Scaling Group 생성 -Production applications need to be ready to tolerate a growing number of users at the same time. For example, if you get published in a popular blog, you may receive many more users that you had expected in a short period of time, and your application may crash because it's not able to sustain all the incoming traffic. +Production 응용프로그램은 일시에 증가하는 사용자를 결딜 준비가 되어있어야 한다. 예를 들어, 인기있는 블로그가 배포하면 단시간에 예상했던 것보다 많은 사용자의 요청을 받게 될 것이다. 그러면 우리의 응용프로그램은 모든 트래픽 요청을 감당할 수 없어 중단 될 것이다. -Amazon provides [Auto Scaling Groups](https://docs.aws.amazon.com/autoscaling/latest/userguide/AutoScalingGroup.html) as way to build a more robust application which can handle increasing loads. Using these, you can setup rules (scaling policies) so more instances serving your application +Amazon은 증가하는 로드를 감당할 수 있는 더욱 강력한 응용프로그램을 만드는 방법으로 [Auto Scaling Groups](https://docs.aws.amazon.com/autoscaling/latest/userguide/AutoScalingGroup.html)를 제공한다. -To create an Auto Scaling Group, first we need to create a [Launch Configuration](http://docs.aws.amazon.com/autoscaling/latest/userguide/LaunchConfiguration.html), which is basically a template that specifies properties of the instances that will be launched. +Auto Scaling Group를 만들려면, 우선 시작될 인스턴스의 속성을 기술한 기본적인 템플릿인 [시작 구성](http://docs.aws.amazon.com/autoscaling/latest/userguide/LaunchConfiguration.html)을 만들어야 한다. -## Create Launch Configuration -1. Go to **EC2** under **Compute** section. -2. On left menu select **Launch Configuration** under **AUTO SCALING**. -3. Click **Create launch configuration**. -4. Look for Ubuntu Server (make sure it say Free tier eligible) and click Select. -5. Select `t2.micro` and then click on **Next: Configure Details**. -6. As name put: `aws-workshop-auto-scaling-group`. -7. As **IAM Role** select: `ApiRole`. -8. On **Advanced Settings**, there you have to select **As text** in **User data** and paste this bash script: +## 시작 구성 생성 +1. **컴퓨팅** 섹션의 **EC2** 로 이동한다. +2. 왼쪽 메뉴에서 **AUTO SCALING** 섹션의 **시작 구성** 선택한다. +3. **시작 구성 생성** 클릭한다. +4. Ubuntu Server (프리 티어로 사용할 수 있는지 확인하십시요) 를 찾고 선택 클릭한다. +5. `t2.micro` 를 선택하고 **다음: 세부 정보 구성** 클릭한다. +6. 이름: `aws-workshop-auto-scaling-group` 입력한다. +7. **IAM 역활** 에서 선택: `ApiRole`. +8. **고급 세부 정보** 에서, **사용자 데이터** 의 **텍스트** 선택하고 아래 스크립트를 붙여넣는다. ``` #!/bin/bash export LC_ALL=C.UTF-8 @@ -25,40 +25,38 @@ To create an Auto Scaling Group, first we need to create a [Launch Configuration chmod +x ./install ./install auto ``` - Be careful that there are NO SPACES before every line in the script. -9. Click **Next: Add Storage**. -10. Click **Next: Configure Security Group**. -11. Click **Create new security group**. -12. Security Group Name: `api-security-group`. -13. Click: **Add Rule**. -14. Type: **All TCP**. -15. Source: `load-balancer-security-group` and select the one suggested. -16. Click **Review**. -17. Click **Create launch configuration** and select the key pair to used to `ssh` into future instances. - -Now that we have our **Launch configuration** we can create our **Auto Scaling Group**. - -## Create Auto Scaling Group -1. Go to **EC2** under **Compute** section. -2. On left menu select **Auto Scaling Groups** under **AUTO SCALING**. -3. Click: **Create Auto Scaling group**. -4. Select: `aws-workshop-auto-scaling-group` and then click **Next Step**. -5. On **Group name** put the same as in Launch configuration. -6. **Group size:** 2. At least we will have some redundancy form the start! -7. On **Subnet** add all the available options. -8. On **Advanced Details** click on: **Receive traffic from one or more load balancers**. -9. On **Target Groups** click and select: `aws-workshop-target-group`. -10. Click **Next: Configure scaling policies**. -11. Select: **Use scaling policies to adjust the capacity of this group**. We will configure a toy scaling policy only for learning. In a real system, you would have to do some benchmarking and determine your application's bottlenecks to setup an optimal scaling policy. -12. Configure it to scale between 2 and 4 instances. -13. Pick `Average CPU Utilization` as metric (imagine your app was compute intensive). In Target value, set something like 80. -14. **Instances need:** 180 seconds for warm up. See more [here](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-scaling-simple-step.html#as-step-scaling-warmup). -15. Click **Next: Configure Notifications**. -16. Click **Next: Configure Tags**. -17. Click **Review**. -18. Click **Create Auto Scaling group**. -19. Click **Close**. - + 스크립트의 모들 줄 앞에 공백이 없도록 주의한다. +9. **다음: 스토리지 추가** 클릭한다. +10. **다음: 보안 그룹 구성** 클릭한다. +11. **새 보안 그룹 생성** 클릭한다. +12. 보안 그룹 이름: `api-security-group`. +13. 클릭: **규칙 추가**. +14. 유형: **All TCP**. +15. 원본: `load-balancer-security-group` 입력하거나 제한된 것을 선택한다. +16. **검토** 클릭한다. +17. **시작 구성 생성** 클릭하고 추후 인스턴스의 `ssh`에 사용할 키 쌍을 선택한다. + +지금 우리는 **시작 구성**을 구성하였고 **Auto Scaling 그룹** 을 생성할 수 있다. + +## Auto Scaling 그룹 생성하기 +1. **컴퓨팅** 섹션의 **EC2** 로 이동한다. +2. 왼쪽 메뉴에서 **AUTO SCALING** 섹션의 **Auto Scaling 그룹** 선택한다. +3. 클릭: **Auto Scaling 그룹 생성**. +4. 선택: `aws-workshop-auto-scaling-group` 하고 **다음 단계** 선택한다. +5. **그룹 이름** 에 시작 구성과 같은 이름 입력한다. +6. **그룹 크기:** 2. 우리는 어쨌든 약간의 여분을 가지고 시작할 것이다. +7. **서브넷** 에서 모든 사용 가능한 옵션 추가한다. +8. **고급 세부 정보** 에서 클릭: **하나 이상의 로드 밸런서에서 트래픽 수신**. +9. **대상 그룹** 에서 선택 및 클릭: `aws-workshop-target-group`. +10. **다음: 조정 정책 구성** 클릭한다. +11. 선택: **조정 정책을 사용하여 이 그룹의 용량 조정**. 우리는 학습을 위해 toy 조정 정책을 구성할 것입니다. 실제의 시스템에서는 최적의 조정 정책을 구성하기 위해 일부 벤치마킹을 실행하고 응용프로그램의 병목현상을 파악해야 합니다. +12. 조정 범위를 2에서 4개의 인스턴스로 설정한다. +13. 지표유형: `평균 CPU 사용률` 선택 (imagine your app was compute intensive). 대상 값은 80. +14. **인스턴스 필요 시간:** 180 초 동안 워밍업 시간(초). 더 자세한 사항은 [이곳](https://docs.aws.amazon.com/autoscaling/latest/userguide/as-scaling-simple-step.html#as-step-scaling-warmup)을 참고해 주세요. +15. **다음: 알림 구성** 클릭한다. +16. **다음: 태그 구성** 클릭한다. +17. **검토** 클릭한다. +18. **Auto Scaling 그룹 생성** 클릭한다. +19. **닫기** 클릭한다. --- -**Next:** finishing up, we need to [modify parameters and re-run CodeBuild](/workshop/elb-auto-scaling-group/03-finishing-up.md). - +**다음:** 마지막으로 이제 [파라미터를 수정하고 CodeBuild를 재실행하기](/workshop/elb-auto-scaling-group/03-finishing-up.md) 를 수행하도록 하겠습니다. diff --git a/workshop/elb-auto-scaling-group/03-finishing-up.md b/workshop/elb-auto-scaling-group/03-finishing-up.md index 7aebbf2..1decf7f 100644 --- a/workshop/elb-auto-scaling-group/03-finishing-up.md +++ b/workshop/elb-auto-scaling-group/03-finishing-up.md @@ -1,61 +1,70 @@ -# Finishing up - -Now, we have two instances on EC2, an ELB to distribute the traffic across them, and an Auto Scaling Group to have redundancy and scale in an automatic way if throughput needs to increase. - -In [the first section](/workshop/s3-web-ec2-api-rds/05-finishing-up.md), the `API_URL` parameter was set to the DNS name of our only instance. Now, we need to tell the web that the request must be done through the load balancer, so we need to modify `API_URL`. -We also need to modify the CodeDeploy project so the tool knows that now we have an Auto Scaling Group and that it needs to run the deploy each time a new instance is launched. -Finally, we need to re-run CodeBuild so the new bundle on S3 points to the DNS of the load balancer instead of the instance' DNS. - -## Modify `API_URL` -1. Go to **EC2** under **Computer** section. -2. On left menu select **Load Balancer** under **LOAD BALANCING**. -3. Copy the DNS name of your load balancer that appears under **Description**. -4. On left menu, select **Parameter Store**. -5. Click on `/prod/frontend/API_URL` and on **Actions** select **Edit Parameter**. -6. As Value put: `http://` + the DNS that you copied 3 steps ago. -7. Click **Save Parameter**. - -## Modify the CodeDeploy project -1. Go to **CodeDeploy** under **Developer Tools**. -2. Click your application's name. -3. Select your deployment group and on **Actions** select **Edit**. -4. On **Environment configuration** select your Auto Scaling Group on **Auto Scaling groups** tab. -5. Go to **Amazon EC2 instances** tab, and delete all existing Tag groups that we setup earlier. -6. Check **Enable load balancing**. -7. On **Load balancer** check **Application Load Balancer**. -8. Select your target group in the dropdown. -9. Click **Save**. -10. Select your deployment group and on **Actions** click **Deploy new version**. +# 마무리 + +지금, 우리는 2개의 EC2 인스턴스와 트래픽을 분산시키는 ELB 및 자동으로 처리량의 확장과 여분을 구성하는 Auto Scaling 그룹을 갖추었다. + +[첫 섹션](/workshop/s3-web-ec2-api-rds/05-finishing-up.md)에서, `API_URL` 파라미터에 특정 인스턴스의 DNS 이름을 설정 하였습니다. 지금, 우리는 웹에 로드 밸런서를 통해 요청이 치리되어야 하므로 `API_URL`를 수정해야만 합니다. +또한 CodeDeploy 프로젝트를 수정해야 한다. 지금 Auto Scaling 그룹 사용하고 새로운 인스턴스가 시작될때마다 배포를 실행하여야 한다고 적용해야한다. +마지막으로, CodeBuild를 S3의 새로운 배포본이 인스턴스 대신 로드 밸런서의 DNS로 처리될 수 있게 재실행해야 한다. + +## `API_URL` 수정하기 +1. **컴퓨팅** 섹션의 **EC2** 로 이동한다. +2. 왼쪽 메뉴에서 **로드 밸런싱** 섹션의 **로드밸런서** 선택한다. +3. **설명** 밑의 로드 밸런서의 DNS 이름을 복사한다. +4. 왼쪽 메뉴 중, **파라미터 스토어** 를 선택한다. +5. `/prod/frontend/API_URL` 를 클릭하고 **작업** 의 **파라미터 편집** 를 선택한다. +6. 값: `http://` + 3번에서 복사한 DNS 값을 입력한다. +7. Click **파라미터 스토어** 클릭한다. +8. **닫기** 클릭한다. + +## CodeDeploy 프로젝트 수정하기 +1. **개발자 도구** 아래의 **CodeDeploy** 로 가기. +2. 응용프로그램 이름을 클릭한다. +3. 배포 그룹을 선택 후 **작업** 에서 **수정** 을 클릭한다. +4. **환경구성** 에서 **Auto Scaling 그룹** 탭에서 생성한 Auto Scaling 그룹을 선택한다. +5. **Amazon EC2 인스턴스** 탭으로 가서 이전에 설정한 모든 태그 그룹을 삭제한다. +6. Check **로드 밸런싱 활성화** 를 클릭한다. +7. **로드 밸런서** 에서 **어플리케이션 로드 발랜서** 를 체크한다. +8. 드롭다운 리스트의 타켓 그룹을 선택한다. +9. **저장** 을 클릭한다.. +10. 배포 그룹을 선택 후 **작업** 에서 **새 개정 배포** 를 클릭한다. +**이부분이 조금 달라진 것 같습니다. 현재 GitHub 계정을 인증해야만 되게 되어있습니다.** 11. On **Repository** type select: `My application is stored in GitHub`. 12. Repository Name: `tryolabs/aws-workshop`. 13. Get the last commit id and past it in the **Commit ID** field. -14. Then click **Deploy**. -## Re-run CodeBuild -1. Go to **CodeBuild** under **Developer Tools**. -2. Click **Start build**. -3. Click **Start build**. +11. **레파지토리 유형** 유형 선택: `GitHub에 어플리케이션 저장`. +12. GitHub 계정: `본인의 GitHub계정` 입력 후 **GitHub 연결** 클릭 후 연결을 한다. +13. **레파지토리 이름** 필드에 및 **Commit ID** 필드 각각 레파지토리 이름과 마지막 commit id를 입력한다. -## Update RDS security group -To give access to the instances created by the auto scaling to the data base we need to update our Postgres instance security group. +14. **배포** 를 클릭한다. -1. Go to **RDS** under **Database** -2. Click **Instances** on the left -3. Select your instance and with the radio button on the left and click **Instance actions** and select **Modify** -4. Scroll to **Security group** under **Network & Security** section -5. Click on the security groups drop down and select `api-security-group`. This is the group we created with the Launch Configuration for our Auto Scaling Group in the [previous section](/workshop/elb-auto-scaling-group/02-auto-scaling-group.md#create-launch-configuration-group). +## CodeBuild 재실행하기 +1. **개발자 도구** 아래의 **CodeBuild** 로 가기. +2. Click **빌드 시작** 을 클릭한다. +3. Click **빌드 시작** 을 클릭한다. -Now, terminate all your running instances and wait for the Auto Scaling group to start the new ones, this might take some minutes. You can follow the current state of the ASG by going to **EC2**, **Auto Scaling Groups**, select your group and check the **Activity History** and **Instances** tabs. Once the new instances were in place and `running` you should be able to get the full site working on the URL of the load balancer. +## RDS 보안 그룹 수정하기 +Auto Scaling으로 생성된 인스턴스에게 데이터베이스 접근 권한을 부여하려면 Postgres 인스턴스의 보안 그룹을 업데이트 하여야 한다. + +1. **데이터베이스** 아래의 **RDS** 로 가기. +2. 왼쪽 **인스턴스** 를 클릭한다. +3. 인스턴스를 선택 후 **인스턴스 작업** 클릭 후 **수정** 을 선택한다. +4. **네트워크 및 보안** 섹션 아래의 **보안 그룹** 까지 스크롤한다. +5. 보안 그룹 콤보박스를 클릭하여 `api-security-group`를 선택한다. 이 그룹은 Auto Scaling 그룹을 위해 시작 구성에서 생성한 것이다. [이전 섹션](/workshop/elb-auto-scaling-group/02-auto-scaling-group.md#create-launch-configuration-group). ---- -**Extra mile:** once you have the site running: -- Can you tell which instance is getting the requests? -- Try changing the _Desired_ and _Min_ parameters of the ASG and see what happens. -- Force the launch of new instances by triggering a condition that would make the scale up policy activate (that is, without changing the _Desired_ value). - > Tip: running `yes > /dev/null &` will max out one of the CPU cores. +이제, 모든 실행중인 인스턴스를 종료하고 Auto Scaling 그룹이 새로운 인스턴스를 시작하기를 기다립니다. 이 작업은 몇 분 정도 걸릴 수 있습니다. +**EC2**, **Auto Scaling 그룹** 이동하여 그룹을 선택하고 **활동 기록** 과 **인스턴스** 탭을 확인하여 Auto Scaling 그룹의 상태를 확인 할 수 있습니다. +새로운 인스턴스가 설치되고 `running` 상태과 되면 로드 밸런서의 URL로 모든 사이트를 사용할 수 있습니다. -- Try running [ab](http://httpd.apache.org/docs/2.2/programs/ab.html) (installed by default on macOS) to stress test the API. Do you see any reaction in the AWS console? +--- +**추가 사항:** 일단 사이트를 실행하면: +- 요청받고 있는 인스턴스를 알 수 있나요? +- Auto Scaling 그룹에서 _Desired_ 와 _Min_ 파라미터를 변경하고 무슨 일이 일어나는지 확인해 보자. +- 확장 인스턴스 정책을 활성화하는 조건을 트리거하여 새 인스턴스의 시작을 강제 실행하십시오. (즉, _Desired_ 값을 변경하지 않고) + > Tip: `yes > /dev/null &` 을 실행하면 CPU코어 중 하나가 최대값이 됩니다. +- API 스트레스 테스트를 위해 [ab](http://httpd.apache.org/docs/2.2/programs/ab.html) 를 실행하십시오. (기본적으로 macOS에 설치됨) +AWS 콘솔에 반응이 있습니까? --- -**Next:** [VPC configuration and Bastion instance](/workshop/vpc-subnets-bastion/introduction.md). \ No newline at end of file +**다음:** [VPC configuration and Bastion instance](/workshop/vpc-subnets-bastion/introduction.md). diff --git a/workshop/elb-auto-scaling-group/introduction.md b/workshop/elb-auto-scaling-group/introduction.md index a5e2f2e..be08ccc 100644 --- a/workshop/elb-auto-scaling-group/introduction.md +++ b/workshop/elb-auto-scaling-group/introduction.md @@ -1,12 +1,15 @@ -# Add an extra EC2 instance with ELB and auto-scaling +# ELB 와 auto-scaling을 통한 여분의 EC2 추가 -In this section we want to add an extra EC2 instance to be able to manage a bigger amount of trafic and improve our performance. -To do that we are going to add also a [ELB](https://aws.amazon.com/elasticloadbalancing/) that is going to be the one in charge of distribute the traffic accross our instances. +이 번 장에서는 더 많은 양의 트래픽 관리가 가능하고 성능 향상을 위해 여분의 EC2 인스턴스를 추가에 대해 알아보겠다. -Also we will add an [auto-scaling group](https://aws.amazon.com/documentation/autoscaling/) with 2 availability zones. -This way we ensure that if we have 2 instances one on each availability zone, and an [Availability Zone](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones) goes down and our instance terminated, AWS will automatically start a new instance in the other availability zone so we don't decrease our performance. -Also we will create some rules to add more instances if our 2 instances are overloaded (example: using 80% of cpu for the last 5 minutes), you can add whatever rule you want. +또한 우리는 인스턴스의 성능을 넘은 트랙픽의 배분 관리를 하는 [ELB](https://aws.amazon.com/elasticloadbalancing/)도 추가할 것이다. + +또한 우리는 2개의 가용 영역(availability zone)에 [auto-scaling group](https://aws.amazon.com/documentation/autoscaling/)을 추가할 것이다. +이것은 우리가 각각의 가용 영역(availability zone)에 한 개씩 2개의 인스턴스가 있다면, 한 [가용 영역(Availability Zone)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones)이 다운되거나 인스턴스가 종료되어도, AWS는 성능이 떨어지는 것을 막기위해 자동적으로 다른 가용 영역(availability zone)의 새로운 인스턴스를 시작할 것이다. + +또한 2개의 인스턴스가 과부화되는 경우라면 더 많은 인스턴스 추가하는 규칙을 만들어야 할 것이다. (ex: 마지막 5분 동안 cpu 사용량 80%), 우리는 원하는 어떤 규칙도 추가할 수 있다. --- -**Next:** [Create a Load Balancer](/workshop/elb-auto-scaling-group/01-load-balancer.md) \ No newline at end of file + +**다음:** [Load Balancer 생성하기](/workshop/elb-auto-scaling-group/01-load-balancer.md) diff --git a/workshop/s3-web-ec2-api-rds/01-serve-website-from-s3.md b/workshop/s3-web-ec2-api-rds/01-serve-website-from-s3.md index 2284d5e..ba27cde 100644 --- a/workshop/s3-web-ec2-api-rds/01-serve-website-from-s3.md +++ b/workshop/s3-web-ec2-api-rds/01-serve-website-from-s3.md @@ -1,17 +1,21 @@ -# Serve a static website from S3 - -## Creating the bucket - -First we need to create a bucket from where we are going to serve the website. - -1. On your AWS Console, go to **S3** under **Storage section** and click on Create bucket. -2. Enter the name of the bucket. Remember, bucket names must be unique across all existing accounts and regions in AWS. You cannot rename a bucket after it is created, so chose the name wisely. Amazon suggests using DNS-compliant bucket names. You should read more about this [here](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules). -3. Pick a region for the S3 bucket. You can chose any region you like, but beware that Amazon has [different pricing](https://aws.amazon.com/s3/pricing/) for storage in different regions. In this case (though it won't matter too much) we will pick `US East (N. Virginia)`. -4. Click Create. We will configure the properties later. -5. Once created, click on the name of your bucket, go to properties, click **Static website hosting** check the option **Use this bucket to host a website** -6. As index and error document put: `index.html`. Later, we will go to the **endpoint url** specified at the top to access our website. -7. Click Save. -8. Go to **Permissions**, **Bucket Policy,** and add the following policy to make every object readable: +# S3로부터 정적 웹 사이트 제공하기 + +## 버킷 만들기 + +우선 웹사이트를 제공할 곳에서 버킷을 만들어야 한다. + +1. AWS Console에서 **Storage section** 아래의 **S3**로 이동하여 버킷 생성을 클릭하십시오. +2. 버킷의 이름을 입력하십시오. +버킷 이름은 AWS의 모든 기존 계정 및 지역에서 고유해야합니다. +버킷을 만든 후에는 버켓의 이름을 바꿀 수 없으므로 이름을 현명하게 선택하십시오. +Amazon은 DNS 호환 버킷 이름 사용을 제안합니다. [여기](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules)에서 이에 대한 추가적인 정보를 찾으실 수 있습니다. +3. S3 버킷의 리전을 선택하세요. 여러분이 원하는 어떤 리전이든 선택할 수 있습니다. 그러나 AWS는 [리전별로 가격이 다릅니다](https://aws.amazon.com/s3/pricing/). 이번 실습에서 우리는`미국 동부(버지니아 북부)`를 선택할 것입니다. +4. Create를 클릭하세요. 우리는 나중에 속성을 수정할 것입니다. +5. 일단 만들어지면, 버킷 이름을 클릭하고 속성(Properties)탭을 클릭하여 이동 한 다음 **정적 웹 사이트 호스팅(Static website hosting)을 클릭**한 후에 **이 버킷을 사용하여 웹 사이트를 호스팅(Use this bucket to host a website)** 를 선택 하십시오. +6. Index document와 Error document란 에는`index.html`을 넣습니다. 이후에 우리는 **웹 사이트**에 접속하기 위해 상단에 표시된 **Endpoint URL**를 사용할 것 입니다. 텍스트 에디터를 열어 Endpoint의 주소를 적어 놓으시기 바랍니다. +> 입력란에 index.html이 미리 표시 되어 있어 마치 사전에 입력되어 있는것처럼 보이지만 반드시 손으로 입력해 주셔야만 **Save**버튼이 활성화 됩니다. +7. Save 버튼을 클릭하세요. +8. **권한(Permissions)** 탭에서 **버킷 정책(Bucket Policy)** 버튼을 클릭하고, 모든 객체를 읽을 수있게 만들기 위해 다음 정책을 추가하십시오: ``` { "Version": "2012-10-17", @@ -21,98 +25,99 @@ First we need to create a bucket from where we are going to serve the website. "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", - "Resource": "arn:aws:s3:::/*" + "Resource": "arn:aws:s3:::<여러분의 버킷이름>/*" } ] } ``` +> 위 예제에서 여러분의 버킷 이름을 입력할때 꺽쇠<>는 필요 없습니다. -9. Click Save - - -## Add `WEBSITE_BUCKET_NAME` to the Parameters Store +9. 저장 버튼을 누르세요. +> 버킷 내용이 공개되었다는 경고메세지가 나오지만 이번 실습에서는 신경쓰지 않아도 됩니다. -Every application needs to have some configurations that inherently will vary between different deployments: whether to enable debug or not, the address of the database server, secret keys or access tokens for third party services, etc. Some of these need to be stored securely (ie. keys API tokens). Many people use [environment variables](https://en.wikipedia.org/wiki/Environment_variable) for this, but it is not secure enough. +## 매개 변수 저장소에`WEBSITE_BUCKET_NAME`을 추가하십시오. -[AWS Parameters Store](http://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) is a service designed for just this, and we will use it to store variables of our system. This will enable us to store constants and later use them during other steps of the deployment. We will start by storing the bucket name. +모든 어플리케이션에는 각각의 배포 때마다 고유한 설정이 있어야합니다: 디버그 사용할지 여부, 데이터베이스 서버의 주소, Third Party 에 대한 서비스를 사용을 위한 비밀 키 또는 액세스 토큰 등등. 이들 중 일부는 안전하게 저장해야합니다 (ex. keys API tokens). 많은 사람들이 이를 위해 [환경 변수](https://en.wikipedia.org/wiki/Environment_variable) 를 사용하지만 안전하다 라고 말할 순 없습니다. -1. Go to **S3** under **Storage** **section**. -2. See details of the bucket you just created and copy its name. -3. Go to **EC2** under **Compute section**. -4. On the left menu select **Parameter Store**. -5. Click **Create Parameter**. -6. Enter `/prod/codebuild/WEBSITE_BUCKET_NAME` as name and a meaningful description of what the parameter means (ie. "name of the website bucket"). -7. Enter `s3://` as value. -8. Click create parameter. +[AWS Parameters Store](http://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) 는 이를 위해 고안된 서비스로 우리 시스템의 변수를 저장하는 데 사용합니다. 이렇게하면 우리에게 상수를 저장하고, 나중에 다른 배포 단계동안에도 사용할 수 있습니다. 우리는 버킷 이름을 저장하여 시작합니다. -Now we can retrieve the bucket name with `aws ssm get-parameter` like we did [here](/buildspec.frontend.yml). Also, we can use [AWS SSM Agent](http://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) to manage our instances' configuration from the AWS web console. +1. **Storage** **section** 에서 **S3** 로 이동하십시오. +2. 버킷의 세부 정보를 보고 만들었던 버킷의 이름을 복사하십시오. +3. **Compute section**.에서 **EC2** 로 이동하십시오. +4. 왼쪽 탐색 메뉴 하단 에서 **Parameter Store** 를 선택하십시오. +5. **Create Parameter** 를 클릭하십시오. +6. **Name**에 `/prod/codebuild/WEBSITE_BUCKET_NAME`을 입력하고 **Description**란에는 파라미터가 의미하는 바에 대한 설명 (예. "웹사이트용 버킷 이름")을 입력하십시오. **Type**란은 **String**이 선택된 그대로 두시면 됩니다. +7. **Value**에는 `s3://`을 입력하십시오(꺽쇠<>는 입력할 필요가 없습니다). +8. Create Parameter 를 클릭하십시오. +이제 우리가 [여기에](/buildspec.frontend.yml) 셋팅 한 것처럼 'aws ssm get-parameter'로 버킷 이름을 검색 할 수 있습니다. 또한 [AWS SSM Agent](http://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html) 를 사용하여 AWS 웹 콘솔에서 인스턴스 구성을 관리 할 수 있습니다. -## Create a policy to get full access to the S3 website bucket -With [AWS Policies](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html), you can specify different permissions regarding every AWS resource you use. For example, you can create a policy for enabling full access to a specific S3 bucket, and that is what we are going to do. We will need this in the future to build the project programmatically and store it on S3. +## S3 웹 사이트 버킷에 대한 full access 권한을 얻는 정책을 만듭니다. -1. Go to **IAM** under **Security, Identity & Compliance**. -2. Click in Policies. -3. Click in Create Policy. -4. Click **Import managed policy**. -5. Search and select `AmazonS3FullAccess` (this is a premade policy, but you can also build your own). -6. Click the **JSON** tab and change the `Resource` value to `["arn:aws:s3:::", "arn:aws:s3:::/*"]` in the JSON content. -7. Click **Review policy** -8. Choose a name for the policy (eg. S3WebsiteFullAccess) and click in Create Policy. +[AWS Policies](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) 내에서, 너가 사용하는 모든 AWS 리소스에 대해 다른 권한을 지정할 수 있습니다. 예를 들어, 특정 S3 버킷에 대한 전체 액세스를 가능하게하는 정책을 만들 수 있습니다. 이것이 바로 우리가 할 일입니다. 앞으로 우리는 프로젝트를 프로그래밍적으로 빌드하고 그것을 S3에 저장해야합니다. -Now we have a policy that allows full access (list, write, update, delete, etc) to our website bucket. Let’s see how we can use it in the following section. +1. **Security, Identity & Compliance** 에서 **IAM** 으로 이동하십시오. +2. Policies 을 클릭하십시오. +3. Create Policy 를 클릭하십시오. +4. **Import managed policy** 를 클릭하십시오. +5. 'AmazonS3FullAccess'를 검색하고 선택하십시오 (사전 정책이지만 당신이 직접 build 할 수도 있습니다). +6. **JSON** 탭을 클릭하여 JSON본문에서 `Resource`의 `"*"`부분을 `["arn:aws:s3:::<여러분의 버킷이름>", "arn:aws:s3:::<여러분의 버킷이름>/*"]`으로 대체 합니다. +> 위 예제에서 여러분의 버킷 이름을 입력할때 꺽쇠<>는 필요 없습니다. +7. **Review policy** 를 클릭하십시오. +8. 정책 이름(예 : S3WebsiteFullAccess)을 선택하고 Create Policy 을 클릭하십시오. +이제 우리는 웹 사이트 버킷에 대한 전체 액세스 (목록 작성, 업데이트, 삭제 등)를 허용하는 정책을 가지고 있습니다. 다음 섹션에서 어떻게 사용할 수 있는지 보도록하겠습니다. -## Create a project in CodeBuild to build and deploy the frontend +## CodeBuild 안에서 프런트앤드에 빌드 및 배포하기 위해 프로젝트를 생성하십시오. -As we mentioned earlier, [AWS CodeBuild](https://aws.amazon.com/codebuild/) is an AWS service to build projects. In order to instruct CodeBuild on what to do, we have created the `buildspec.frontend.yml`. CodeBuild will first pull the repository, and then run the commands specified on [that file](/buildspec.frontend.yml). If you see, we have specified what is needed for a fresh install of the project, which ends up in a build using `npm build` and `aws s3 sync` for uploading the resulting files to S3. +앞서 언급했듯이 [AWS CodeBuild](https://aws.amazon.com/codebuild/)는 프로젝트를 빌드하는 AWS 서비스입니다. CodeBuild에게 무엇을 할 것인지를 지시하기 위해 우리는`buildspec.frontend.yml` 파일을 만들었습니다. CodeBuild는 먼저 repository를 pull 한 다음 [해당 파일](/buildspec.frontend.yml)에 지정된 명령을 실행합니다. 아시다시피, 우리는 프로젝트를 새로 설치하는 데 필요한 것을 지정했습니다. 생성 된 파일은 S3에 결과 파일을 업로드하기 위해 `npm build` 와 `aws s3 sync` 를 사용하여 빌드를 완료 합니다. -Follow these steps to get it ready: +준비하기 위해 다음 단계를 진행하세요: -1. Go to **CodeBuild** under the **Developer Tools** section. -2. Click on Get Started (or Create Project if you had other projects). -3. Choose a project name and write an description (optional). -4. On the Source section: - 1. Choose **Github** as the source provider. - 2. Select an option for the repository. - 3. Connect Github with AWS if neccesary. - 4. Fill the repository URL or choose one repository from your Github account. -5. On the Environment section: - 1. Choose Ubuntu as the OS and Node.js as the Runtime. - 2. Select `aws/codebuild/nodejs:7.0.0` as the Version. - 3. Change the BuildSpec name to `buildspec.frontend.yml` (our yaml file with the steps to follow). -6. In the Artifacts section select _No artifacts_. -7. In the Service Role section: - 1. Select Create a service role in your account. - 2. Choose a name for the Role and name it `codebuild-aws-workshop-service-role`. -8. Click on Continue. -9. Click on Save. +1. **Developer Tools** 섹션 아래 있는 **CodeBuild** 로 이동하십시오. +2. Get Started 를 클릭하세요 (이미 다른 프로젝트가 있다면 Create Project 를 클릭하십시오). +3. 프로젝트 이름(Project Name)에 `Hands-on-project` 입력하고 설명(Description)을 작성하십시오(선택). +4. Source 섹션에서: + 1. 소스 제공자(Source provider)로서 **Github** 를 선택하십시오. + 2. repository 옵션을 선택하십시오. + 3. 필요한 경우 AWS와 Github을 연결하십시오. + 4. repository URL을 채우거나 Github 계정에서 하나의 repository를 선택하십시오. +5. Environment 섹션에서: + 1. OS는 `Ubuntu`를 선택하고 런타임은 `Node.js`를 선택하십시오. + 2. 버전은 `aws/codebuild/nodejs:8.11.0`을 선택하십시오. + 3. BuildSpec 이름을`buildspec.frontend.yml` (따라야할 스탭을 가지고 있는 yaml 파일)로 변경하십시오. +6. 이슈 섹션에서 _No artifacts_을 선택하십시오. +7. Service Role 섹션에서: + 1. 당신의 계정에서 Create a service role 를 선택하십시오. + 2. role의 이름을 선택하고 이름을 `codebuild-aws-workshop-service-role` 로 지정하십시오. +8. Continue를 클릭하십시오. +9. Save를 클릭하십시오. -Now, we have created a CodeBuild application. We won’t be able to run it though, because we don’t have permissions to add files to our S3 bucket. That is why earlier we created the policy and also something called a "role". For everything to work, we need to attach the policy to the role. +이제 CodeBuild Application을 만들었습니다. 우리는 S3 버킷에 파일을 추가 할 수있는 권한이 없기 때문에 실행할 수 없습니다. 그래서 우리는 "role" 이라는 정책을 초기에 만들어 냈습니다. 모든 것이 제대로 작동하려면 우리는 정책을 역할에 첨부해야 합니다. -## Attach policies to the CodeBuild role +## CodeBuild role에 정책 첨부 -A [Role](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) defines permissions inside AWS. Those permissions come in the form of policies, just like in the case of your AWS user. Things like certain EC2 services (and even instances) which need to execute some actions can run attached to a certain role, and will thus get whatever permissions the role has. +[role](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) 은 AWS 내부에서 사용 권한을 정의합니다. 이러한 권한은 AWS 사용자와 마찬가지로 정책 형태로 제공됩니다. 특정 작업을 실행해야하는 특정 EC2 서비스 (심지어 인스턴스)와 같은 것들은 특정 역할에 연결되어 실행될 수 있으므로 역할에 부여 된 권한을 얻습니다. -Earlier, we created a policy to allow full access to our S3 bucket and assigned a new role to our CodeBuild application. Now we will attach the policy to the role, effectively giving CodeBuild access to our S3 bucket. Moreover, we will need to attach another policy to give it access to SSM, so that it can query the values of the variables we setup in the Parameter Store. +이전에 우리는 S3 버킷에 대한 전체 액세스를 허용하고 CodeBuild 응용 프로그램에 새로운 역할을 할당하는 정책을 만들었습니다. 이제 정책에 역할을 첨부하여 CodeBuild에 S3 버킷에 대한 액세스 권한을 부여합니다. 또한 Parameter Store 에서 설정 한 변수의 값을 쿼리 하기 위하여 SSM에 대한 액세스 권한을 부여하기 위해 다른 정책을 첨부해야합니다. **Website full access** -1. Go to IAM under Security, Identity & Compliance. -2. Click in Roles. -3. You should see the role created in the CodeBuild project creation, select it. -4. Click Attach Policy. -5. Search for the Policy for full access to the S3 website bucket, select it and then click Attach Policy. +1. Security, Identity & Compliance 아래 IAM으로 이동하십시오. +2. Roles 를 클릭하십시오. +3. CodeBuild 프로젝트 생성시 생성 된 역할을 볼 수 있어야합니다. +4. Attach Policy를 클릭하십시오. +5. S3 웹 사이트 버킷에 대한 전체 액세스 정책을 검색하여 선택하고 정책 첨부를 클릭하십시오. **SSM read access** -1. Click Attach Policy again. -2. Search for `AmazonSSMReadOnlyAccess` and click on Attach. +1. Attach Policy 를 다시 클릭하십시오. +2. `AmazonSSMReadOnlyAccess`를 검색하고 Attach를 클릭하십시오. --- -**Extra mile:** try get the value of `WEBSITE_BUCKET_NAME` from the command line. +**도전 과제:** CLI를 사용하여 `WEBSITE_BUCKET_NAME`의 값을 얻으십시오. --- -**Next:** [EC2 instances](/workshop/s3-web-ec2-api-rds/02-EC2-instances.md). \ No newline at end of file +**다음:** [EC2 인스턴스](/workshop/s3-web-ec2-api-rds/02-EC2-instances.md). diff --git a/workshop/s3-web-ec2-api-rds/02-EC2-instances.md b/workshop/s3-web-ec2-api-rds/02-EC2-instances.md index 4ee112d..2717ab1 100644 --- a/workshop/s3-web-ec2-api-rds/02-EC2-instances.md +++ b/workshop/s3-web-ec2-api-rds/02-EC2-instances.md @@ -1,38 +1,38 @@ # EC2 instances -The API of our application will run on several [AWS EC2](https://aws.amazon.com/ec2/) instances. In the sections that follow, we will create one and deploy our API there using [CodeDeploy](http://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html). +[AWS EC2](https://aws.amazon.com/ec2/) 애플리케이션의 API는 여러 곳에서 이용됩니다. 다음 섹션에서는 [CodeDeploy](http://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 를 사용하여 API를 만들고 배포할 것입니다. -First we will create a role to allow our EC2 instances access to SSM: +먼저 EC2 인스턴스가 SSM에 액세스 할 수 있도록 role을 만듭니다: -1. Go to **IAM** under **Security, Identity & Compliance**. -2. Go to Role section and click Create Role. -3. Select **AWS Service** and then **EC2**. -4. Under **Select your use case**, select the one that says _"Allows EC2 instances to call AWS services on your behalf."_ and click next. -5. Search for `AmazonSSMReadOnlyAccess`, select it and click next. -6. Lets call it `ApiRole`. Click create Role. +1. **Security, Identity & Compliance** 아래에 있는 **IAM** 으로 이동하십시오. +2. Role 섹션으로 이동하고, Create Role을 클릭하십시오. +3. **AWS Service** 선택한 후 **EC2** 를 선택하십시오. +4. **Select your use case** 에서, _"Allows EC2 instances to call AWS services on your behalf."_ 라는 메시지를 선택하고 next를 클릭하십시오. +5. `AmazonSSMReadOnlyAccess`를 검색하고 , 그것을 선택 후 next를 클릭하십시오. +6. 그것을 `ApiRole` 이라 부를 수 있습니다. create Role를 클릭하십시오. -We have already created entries in the Parameter Store. In the future we will need encrypted variables, like the password for our database. For this, will create an encryption key to encrypt and decrypt those values. That encryption key will be attached to our admin user and to the role we just created, so only services that are setup to assume the role can get access to the decrypted values. You can read more about SSM and secure data [here](https://aws.amazon.com/blogs/compute/managing-secrets-for-amazon-ecs-applications-using-parameter-store-and-iam-roles-for-tasks/). +우리는 이미 Parameter Store에 항목을 만들었습니다. 앞으로는 데이터베이스 password와 같은 암호화 된 변수가 필요할 것입니다. 이를 위해 암호화 된 키를 만들어 해당 값을 암호화하고 해독합니다.해당 암호화 키는 관리자와 방금 만든 역할에 첨부되므로 역할을 맡을 수 있도록 설정된 서비스만 암호 해독 된 값에 액세스 할 수 있습니다. SSM 및 보안 데이터에 대한 자세한 내용을 볼 수 있습니다. [here](https://aws.amazon.com/blogs/compute/managing-secrets-for-amazon-ecs-applications-using-parameter-store-and-iam-roles-for-tasks/). -1. Go to the section **Encryption keys**. -2. Select **Create key**. -3. Enter `workshopkey` as alias and a meaningful description like "this is the encryption key for the AWS workshop". -4. Click next step and then next step again. -5. Select both your AWS CLI and console users and click next. -6. Select your EC2 Role and click next. -7. Click Finish. +1. **Encryption keys** 섹션으로 이동하십시오. +2. **Create key** 를 선택하십시오. +3. `workshopkey`를 별칭으로 입력하고 "this is the encryption key for the AWS workshop"와 같은 의미있는 설명을 입력하십시오. +4. next step을 클릭하고 next step을 다시 클릭하십시오. +5. AWS CLI 및 콘솔 사용자를 모두 선택하고 next 를 클릭하십시오. +6. 너의 EC2 Role을 선택하고 and next를 클릭하십시오. +7. Finish를 클릭하십시오. -In the future, if an EC2 instance with our new role wants to access an encrypted parameter, AWS will automatically decrypt it! +앞으로는 새로운 역할을 가진 EC2 인스턴스가 암호화된 매개 변수에 액세스 하려고하면 AWS가 자동으로 암호를 해독합니다. -## Launch your first EC2 instance +## 첫 번째 EC2 인스턴스 실행 -We are ready to launch our first EC2 instance. We will create a standard EC2 instance, add a [startup script](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) (which will run automatically when the instance boots) and finally create a [security group](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) that will control the outbound and inbound in our EC2 instances. +우리는 첫 번째 EC2 인스턴스를 시작할 준비가되었습니다. 우리는 스탠다드한 EC2 인스턴스를 만들것이고, [startup script](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) (인스턴스가 부팅 될 때 자동으로 실행 되는) 를 추가해야하고, 마지막으로 EC2 인스턴스에서 아웃 바운드 및 인바운드를 제어하는[security group](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) 을 만들 것입니다. -1. Go to the **EC2** under **Compute section**, and in the top right corner, you can pick the region we are going to use. In this case, we will be using the same region that we used for the S3 bucket setup earlier, that is, `US East (N. Virginia)`. -2. Click on Launch Instance. -3. Look for Ubuntu Server (make sure it says Free tier eligible) and click Select. -4. Select `t2.micro` and then click on Next: Configure Instance Details. -5. Select our `ApiRole` on **IAM role**. -6. On Advanced Details, select "As text" in User data and then paste the following bash script: +1. **Compute section** 아래의 **EC2** 로 이동하고, 오른쪽 상단에서 우리가 사용할 region을 선택할 수 있습니다. 이 경우 이전에 S3 버킷 설정에 사용했던 것과 동일한 영역 인 `US East (N. Virginia)`를 사용하게됩니다. +2. Launch Instance를 클릭하십시오. +3. Ubuntu Server를 본다음 (free tier를 사용할 수 있는지 확인하십시오), 그것을 선택후 클릭하십시오. +4. `t2.micro`를 선택하고 Next : Configure Instance Details를 클릭하십시오. +5. **IAM role** 에서 우리의 `ApiRole` 을 선택하십시오. +6. 고급 세부 사항에서 사용자 데이터에서 "As text"를 선택하고 다음 bash 스크립트를 붙여 넣으십시오: ``` #!/bin/bash export LC_ALL=C.UTF-8 @@ -44,28 +44,28 @@ We are ready to launch our first EC2 instance. We will create a standard EC2 ins ./install auto ``` - Be careful, if you leave spaces at the beginning of the script it will not work. So NO SPACES! - If you had used another region, the bucket name in the `wget` line would be different (see [here](https://docs.aws.amazon.com/codedeploy/latest/userguide/resource-kit.html#resource-kit-bucket-names)). + 스크립트 시작 부분에 공백을 남겨두면 작동하지 않습니다. 그래서 각 행의 앞부분에는 공백을 남기지 지마십시오! + 만약 다른 region을 사용했다면 `wget` 행의 버킷 이름이 다를 수 있습니다([여기](https://docs.aws.amazon.com/codedeploy/latest/userguide/resource-kit.html#resource)를 참조해 주세요). -kit-bucket-names)) -7. Click Next: Add Storage. -8. Leave the default settings and click Next: Add Tags. -9. Click Add Tag. -10. Fill Key with `service` and in Value with `api`. -11. Add another tag with Key `environment` and Value `prod`. These keys will help us identify our EC2 instances running the API later. -12. Click on Next: Configure Security Group. -13. Make sure the _Create a new security group_ option is selected and write a descriptive name on the _Security group name:_ field. You cannot rename it later so choose the name wisely. -14. Click Add Rule. -15. In port range put `9000` and in Source `0.0.0.0/0`, and add a meaningful description. This will enable incoming traffic on port 9000 from every IP, so you can "contact" your instance from the outside. If you pay attention, by default we also get a rule allowing inbound traffic on port 22, which we will use for SSH'ing to the instance. Also by default, outbound traffic (that is, traffic originating from your instance) will be allowed to any destination and port, but you could restrict that later by editing the outbound rules for the security group. -16. Click Review and Launch. -17. Click Launch. -18. When asked to select an existing key pair, choose `create a new key pair`, give it as name `aws_workshop` and click download. Store it in a secure place (`~/.ssh` is good, but make sure you `chmod 400` the PEM file so only your user can read it), we will use it to SSH into the instances during the whole workshop. -19. Click Launch Instances. +7. 다음을 클릭하십시오: Add Storage +8. 기본 설정을 그대로두고 다음을 클릭하십시오: Add Tags +9. Add Tag를 클릭하십시오. +10. Fill 키에`service`를 넣고 Value에는`api`를 넣습니다. +11. Key `environment` 와 Value `prod` 를 가진 또 다른 태그를 추가하십시오. 이 키는 나중에 API를 실행하는 EC2 인스턴스를 식별하는 데 도움이됩니다. +12. 다음을 클릭하십시오: Configure Security Group. +13. _Create a new security group_ 옵션이 선택되었는지 확인하고, on the _Security group name:_ 필드에 설명이 포함 된 이름을 작성하십시오. 나중에 이름을 바꿀 수 없으므로 이름을 현명하게 선택하십시오. +14. Add Rule를 클릭하십시오. +15. port range 는 `9000` 을 셋팅하고, 소스에는 `0.0.0.0/0`를 셋팅하고, 의미있는 설명 추가하십시오. 이렇게하면 모든 IP의 포트 9000에서 들어오는 트래픽을 사용할 수 있으므로 외부에서 인스턴스에 "연결할"수 있습니다. 만약 너가 집중해서 본다면, 기본적으로 우리는 포트 22에서 인바운드 트래픽을 허용하는 규칙을 얻습니다. 이 규칙은 인스턴스에 대한 SSH를 사용할 수 있습니다. 또한 기본적으로 아웃 바운드 트래픽 (즉, 인스턴스에서 시작된 트래픽)은 모든 대상 및 포트에 허용되지만 나중에 보안 그룹에 대한 아웃 바운드 규칙을 편집하여 제한 할 수 있습니다. +16. Review and Launch를 클릭하십시오. +17. Launch를 클릭하십시오. +18. 기존 키 쌍을 선택하라는 메시지가 나타나면 `create a new key pair` 을 선택하고 이름을 `aws_workshop` 으로 지정하고 download를 클릭하십시오. 그것을 안전한 장소에 저장하십시오. (`~/.ssh`는 좋습니다.하지만 `chmod 400` 은 PEM 파일이므로 사용자만 읽을 수 있습니다.) 우리는 그것을 전체 워크샵 동안 SSH에 사용합니다. +19. Launch Instances를 클릭하십시오. --- **Extra mile:** -- Try `ping`ing your EC2 instance. Extra points if you get it to work! -- Connect to the new instance via SSH. The username is _ubuntu_, and try the `-i` flag to use the `.pem` file. +- EC2 인스턴스를 핑 (ping) 해보십시오. 엑스트라 포인트를 받으면 작동합니다! +- SSH를 통해 새 인스턴스에 연결하십시오. 사용자 이름은 _ubuntu_이며`.pem` 파일을 사용하기 위해`-i` 플래그를 사용하십시오. --- -**Next:** create a [PostgresSQL database on RDS](/workshop/s3-web-ec2-api-rds/03-RDS.md). +**다음:** [PostgresSQL database on RDS](/workshop/s3-web-ec2-api-rds/03-RDS.md) 만들기. diff --git a/workshop/s3-web-ec2-api-rds/03-RDS.md b/workshop/s3-web-ec2-api-rds/03-RDS.md index 7b94bf6..05c90f8 100644 --- a/workshop/s3-web-ec2-api-rds/03-RDS.md +++ b/workshop/s3-web-ec2-api-rds/03-RDS.md @@ -1,45 +1,45 @@ -# RDS - -## Create a PostgreSQL instance in RDS -1. Go to **RDS** under **Database** section. -2. Click on **Launch a DB Instance**. -3. Click on PostgreSQL logo, tick the _"Only enable options eligible for RDS Free Usage Tier"_ checkbox at the bottom and click Next. -7. Enter a name on _DB Instance identifier_ (we will need it later, so don’t forget it). -8. Enter a username and password and click Next (again, we will need these later). -9. Select No on **Publicly Accessible**. -10. Availability Zone: `us-east-1a`. -11. On **VPC security groups** choose _Select existing VPC security groups_ and select the security group you create when [launching the EC2 instance](/workshop/s3-web-ec2-api-rds/02-EC2-instances.md#launch-your-first-ec2-instance). -11. Pick a db name and click Launch Instance (again, we will need the database name later). -12. Click View Your DB Instances. - -Now our instance is created. We configure its access, allowing every instance under the security group that was created in the previous section to connect. - -## Add DB parameters on Parameters Store - -As before, we will need some variables stored in the parameter store, including the database name, username, password and endpoint. These variables are referenced in [this file](/backend/conduit/settings/ec2.py), so Django can access the database. - -1. Go to **RDS** under **Database** section. -2. Click on Instances. -3. See details of your db and copy the **Endpoint**. This will be the value for `DATABASE_HOST`. -4. Go to **EC2** under **Compute** section. -5. On the left menu select Parameter Store. -6. Click Create Parameter. -7. Enter `/prod/api/DATABASE_NAME` as the name and a meaningful description like "Name of the PostgreSQL database". -8. Enter the DB name you selected before on the value attribute. -9. Click create parameter and close. -10. Now we will need to do the same thing for the username and host - 1. For the username enter `/prod/api/DATABASE_USER` as the name and your database username and as the value - 2. For the host enter `/prod/api/DATABASE_HOST` as the name and the hostname you copied earlier as the value -11. For `/prod/api/DATABASE_PASSWORD` do the same steps but select as **Type: Secure String** and as KMS Key ID the key `workshopkey`. - -Now we have our database parameters set, and the password encrypted. Only our EC2 instances will be able to decrypt it. +# RDS + +## RDS에서 PostgreSQL 인스턴스 만들기 +1. **Database** 섹션 아래에 있는 **RDS** 로 이동하십시오. +2. **Launch a DB Instance**를 클릭하십시오. +3. PostgreSQL 로고를 클릭하십시오, _"RDS 무료 사용 등급에 해당하는 옵션 만 활성화"_ 체크 박스를 선택하고 Next을 클릭하십시오. +4. _DB Instance identifier_ 에 이름을 입력하십시오.(나중에 필요하므로 잊지 마십시오). +5. 사용자 이름과 비밀번호를 입력하고 Next를 클릭합니다 (다시 말하지만 나중에 필요합니다). +6. **Publicly Accessible** 에 대해 No 를 선택하십시오. +7. 이용가능한 Zone: `us-east-1a`. +8. **VPC security groups** 에서 _Select existing VPC security groups_ 를 선택하고, [EC2 인스턴스 시작](/workshop/s3-web-ec2-api-rds/02-EC2-instances.md#launch-your-first-ec2-instance)할 때 너가 생성한 보안 그룹을 선택하십시오. +9. DB 이름을 선택하고 인스턴스 실행을 클릭합니다 (다시 말하면 나중에 데이터베이스 이름이 필요합니다). +10. 너의 DB 인스턴스 뷰를 클릭하십시오. + +이제 우리의 인스턴스가 생성됩니다. 이전 섹션에서 작성한 보안 그룹의 모든 인스턴스를 연결할 수 있도록 액세스를 구성합니다. + +## Parameters Store 에서 DB 파라미터 추가 + +이전과 마찬가지로 데이터베이스 이름, 사용자 이름, 암호 및 끝점을 포함하여 매개 변수 저장소에 저장된 일부 변수가 필요합니다. 이 변수는 [이 파일](/backend/conduit/settings/ec2.py)에서 참조되므로 Django는 데이터베이스에 액세스 할 수 있습니다. + +1. **Database** 섹션에 있는 **RDS** 로 이동하십시오. +2. 인스턴스를 클릭하십시오. +3. 데이터베이스의 세부 정보를 확인하고 **Endpoint**를 복사하십시오. 이것은`DATABASE_HOST`의 값이 될 것입니다. +4. **Compute** 섹션 아래 있는 **EC2** 로 이동하십시오.. +5. 왼쪽메뉴에서 Parameter Store를 선택하십시오. +6. Create Parameter를 클릭하십시오. +7. `/prod/api/DATABASE_NAME` 의 이름을 입력하고, "PostgreSQL 데이터베이스의 이름"과 같은 의미있는 설명을 입력하십시오. +8. 이전에 선택한 DB 이름을 value 속성에 입력하십시오.. +9. create parameter and close를 클릭하십시오. +10. 이제 유저이름과 호스트에 대해 동일한 작업을 수행해야합니다. + 1. 유저이름으로 `/prod/api/DATABASE_USER` 를 이름과 데이터베이스 사용자 이름으로 입력하고 value로 입력하십시오. + 2. 호스트의 경우 이전에 값으로 복사 한 이름과 호스트 이름으로 `/prod/api/DATABASE_HOST` 를 입력하십시오. +11. `/prod/api/DATABASE_PASSWORD` 에 대해서도 같은 과정을 반복하되 **Type: Secure String** 로 선택하고 KMS Key ID로 키 `workshopkey` 를 선택하십시오. + +이제 데이터베이스 매개 변수를 설정하고 암호를 암호화했습니다. EC2 인스턴스만 해독 할 수 있습니다. --- -**Extra mile:** +**도전과제:** -- Can you `ping` the Postgres instance? -- Try to connect to the DB through your running EC2 instance. +- Postgres 인스턴스에 'ping'할 수 있습니까? +- 실행중인 EC2 인스턴스를 통해 DB에 연결하십시오. --- -**Next:** create a [CodeDeploy project to deploy your API](/workshop/s3-web-ec2-api-rds/04-code-deploy.md). +**다음:** [CodeDeploy project to deploy your API](/workshop/s3-web-ec2-api-rds/04-code-deploy.md) 만들기. diff --git a/workshop/s3-web-ec2-api-rds/04-code-deploy.md b/workshop/s3-web-ec2-api-rds/04-code-deploy.md index d8236cb..893ec1b 100644 --- a/workshop/s3-web-ec2-api-rds/04-code-deploy.md +++ b/workshop/s3-web-ec2-api-rds/04-code-deploy.md @@ -1,47 +1,47 @@ -# CodeDeploy +# CodeDeploy -[CodeBuild](http://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) is a service to automate the deployment of any kind of applications to EC2 instances. The configuration is really simple and easy to adapt. The deployment process is described in an `appspec.yml` file like [this one](/appspec.yml). If you want to know what happens during the deploy, you can also check the implementation of the hooks [here](/infrastructure/aws/codedeploy). +[CodeBuild](http://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 는 모든 종류의 응용 프로그램을 EC2 인스턴스에 자동으로 배포하는 서비스입니다. 이 구성은 정말 간단하고 적응하기 쉽습니다. 배포 프로세스는 [이것](/appspec.yml)과 같은 'appspec.yml` 파일에 설명되어 있습니다. 배포 중에 어떤 일이 발생하는지 알고 싶으면 hook [here](/infrastructure/aws/codedeploy) 의 구현을 확인할 수도 있습니다. -First, we need to create a default role for CodeDeploy so it can have access to other AWS services (like S3). +먼저 다른 AWS 서비스 (예 : S3)에 액세스 할 수 있도록 CodeDeploy의 기본 역할을 만들어야 합니다. -## Create CodeDeploy Role -1. Go to **IAM** under **Security, Identity & Compliance**. -2. Go to **Role** section and click **Create Role**. -3. Select **CodeDeploy** and click **Next: Permissions**. -4. Select **Next: Review**. -5. Type a name and description and click **Create Role**. +## CodeDeploy Role 만들기 +1. **Security, Identity & Compliance** 아래 **IAM** 로 이동하십시오. +2. **Role** 섹션으로 이동하고 **Create Role**를 클릭하십시오. +3. **CodeDeploy** 를 선택하고 **Next: Permissions**을 클릭하십시오. +4. **Next: Review** 를 선택하십시오. +5. 이름 및 설명을 입력하고 **Create Role**를 클릭하십시오. -Now we are ready to start using it. +이제 우리는 그것을 사용할 준비가되었습니다. -## Configure Code Deploy -1. Go to **CodeDeploy** under **Developer Tools**. -2. Click **Create application**. -3. Enter an **Application name** and **Deployment group name**. -4. Select **In-place deployment** on **Deployment Type** section. -5. Select **Amazon EC2 instances** tab on **Environment configuration**. -6. On the first tag group select `environment` as Key and as Value `prod`, on the second line select `service` as Key and as Value `api`. This means that CodeDeploy will deploy our application to all the EC2 instances with those tags. -7. On **Deployment configuration** select **OneAtATime**. -8. On **Service role** select the role created to grant CodeDeploy access to the instances. -9. Click Create application. +## Code Deploy 구성 +1. **Developer Tools** 아래에 있는 **CodeDeploy** 로 이동하십시오. +2. **Create application** 를 클릭하십시오. +3. **Application name** 과 **Deployment group name** 를 입력하십시오. +4. **Deployment Type** 섹션에서 **In-place deployment** 를 선택하십시오. +5. **Environment configuration** 탭 에서 **Amazon EC2 instances** 를 선택하십시오. +6. 첫 번째 태그 그룹에서 Key로 `environment` 를 선택하고 값 `prod` 로 두 번째 라인에서 key로`service`를, 값으로 `api` 를 선택합니다. 즉, CodeDeploy는 해당 태그가 있는 모든 EC2 인스턴스에 어플리케이션을 배포합니다. +7. **Deployment configuration** 에서 **OneAtATime** 를 선택하십시오. +8. **Service role** 에서 인스턴스에 대한 CodeDeploy 액세스 권한을 부여하기 위해 만든 역할을 선택합니다. +9. Create application 를 클릭하십시오. -Now our CodeDeploy application is ready. Let’s try our first deployment. +이제 CodeDeploy 애플리케이션이 준비되었습니다. 첫 번째 배포를 시도해 보겠습니다. -1. Under **Deployment groups** section tick your group and in **Actions** select **Deploy new revision**. -2. On **Repository type** select **"My application is stored in GitHub"**. -3. In **Connect to GitHub** section type your GitHub account and select **Connect to GitHub**. -4. Allow AWS to access your GitHub account, if needed. -5. Enter your repository name in the form _account/repository_. -6. In **Commit ID** type the commit hash that you want to deploy. -7. Select **Overwrite the content** below. -8. Click Deploy. +1. **Deployment groups** 섹션에서 너의 그룹을 선택하고 **Actions** 에서 **Deploy new revision** 를 선택하십시오. +2. **Repository type** 에서 **"My application is stored in GitHub"** 를 선택하십시오. +3. **Connect to GitHub** 섹션에서 GitHub 계정을 입력하고 **Connect to GitHub** 를 선택하십시오. +4. 필요한 경우 AWS에서 귀하의 GitHub 계정에 액세스하도록 허용하십시오. +5. _account / repository_ 형식으로 저장소 이름을 입력하십시오. +6. **Commit ID** 에 배포하려는 커밋 해시를 입력하십시오.. +7. 아래의 **Overwrite the content** 를 선택하십시오. +8. Deploy를 클릭하십시오. -During the deploy try **View instances** and then **View events** to follow the progress and see what's happening. +배포하는 동안 **View instances**를 클릭 한 다음 **View events**를 클릭하여 진행 상황을 확인하고 무슨 일이 일어나는지 확인하십시오. --- -**Extra mile:** once the deploy finished: +**Extra mile:** 배포가 완료되면: -- Try hitting the API with something like [Postman](https://www.getpostman.com/) or [httpie](https://httpie.org/). -- What effect did the deploy have? Where did all the Python code end up? Is the API connected with the RDS already? `ssh` in to get all those answers, and more. +- [Postman](https://www.getpostman.com/) 또는 [httpie](https://httpie.org/) 와 같은 방법으로 API를 실행 해보십시오. +- 배포에 어떤 영향이 있습니까? 모든 파이썬 코드는 어디에서 끝났습니까? API가 이미 RDS와 연결되어 있습니까? `ssh`에서 모든 답변을 얻으십시오. --- -**Next:** we are going to [finish our first deploy](/workshop/s3-web-ec2-api-rds/05-finishing-up.md), only some extra parameters are missing! +**다음:** 우리는 [Finish-deploy](/workshop/s3-web-ec2-api-rds/05-finishing-up.md) 할 것입니다, 일부 추가 파라미터만 누락되었습니다! diff --git a/workshop/s3-web-ec2-api-rds/05-finishing-up.md b/workshop/s3-web-ec2-api-rds/05-finishing-up.md index b0bac31..60e6bc2 100644 --- a/workshop/s3-web-ec2-api-rds/05-finishing-up.md +++ b/workshop/s3-web-ec2-api-rds/05-finishing-up.md @@ -1,27 +1,27 @@ -# Finishing up +# 마무리 -We are almost done. We have to add some more parameters and we are ready to deploy the whole project. +우리는 거의 끝났습니다. 더 많은 parameter 를 추가해야하며 전체 프로젝트를 배포 할 준비가 되었습니다. -## Create API_URL on Parameter Store -1. Go to **EC2** under **Compute** section. -2. Select your instance. -3. Copy the **Public DNS** under **Description**. -4. On the left menu select **Parameter Store**. -5. Click **Create Parameter**. -6. Enter `/prod/frontend/API_URL` as name and `http://:9000` as value. -7. Click **Create Parameter** and close. +## Parameter Store 에서 API_URL 만들기 +1. **Compute** 섹션 아래에 **EC2**로 이동하십시오. +2. 너의 인스턴스를 선택하십시오. +3. **Description** 아래에 **Public DNS** 를 복사하십시오. +4. 왼쪽메뉴에 있는 **Parameter Store** 를 선택하십시오. +5. **Create Parameter** 를 클릭하십시오. +6. `/prod/frontend/API_URL` 을 이름으로 입력하고 `http://:9000`을 입력하십시오. +7. **Create Parameter** 를 클릭하고 닫으십시오. -This will be used by CodeBuild, so the frontend knows where the API is. You can check how [here](/buildspec.frontend.yml). +이것은 CodeBuild에서 사용되므로 프론트 엔드는 API의 위치를 ​​알고 있습니다. [here] (/ buildspec.frontend.yml)에서 체크할 수 있습니다.. -## Run CodeBuild project -1. Go to **CodeBuild** under the **Developer Tools** section. -2. Select the project created before and click **Start Build**. -3. Click **Start Build**. -4. Wait. -5. Check if all the phases run successfully. -6. Done. +## CodeBuild 프로젝트 실행 +1. **Developer Tools** 섹션 아래 있는 **CodeBuild** 로 이동하십시오. +2. 이전에 생성 한 프로젝트를 선택하고 **Start Build** 를 클릭하십시오. +3. **Start Build** 를 클릭하십시오. +4. 잠시만 기다리십시오. +5. 모든 단계가 성공적으로 실행되는지 확인하십시오. +6. 끝. -Now, if you go to the public URL provided by S3 (under **S3**, your bucket, **Properties**, **Static website hosting**) you will find the endpoint. If everything went as planned, you should see the complete website. +이제 S3에서 제공하는 공개 URL (under **S3**, your bucket, **Properties**, **Static website hosting**)으로 이동하면 엔드 포인트를 찾을 수 있습니다. 모든 것이 계획대로 진행되면 전체 웹 사이트를 볼 수 있습니다. --- -**Next:** add an extra [EC2 instance with ELB and auto-scaling](/workshop/elb-auto-scaling-group/introduction.md). +**다음:** [EC2 instance with ELB and auto-scaling](/workshop/elb-auto-scaling-group/introduction.md)를 추가하십시오. diff --git a/workshop/s3-web-ec2-api-rds/introduction.md b/workshop/s3-web-ec2-api-rds/introduction.md index bf1e74d..730e67e 100644 --- a/workshop/s3-web-ec2-api-rds/introduction.md +++ b/workshop/s3-web-ec2-api-rds/introduction.md @@ -1,27 +1,27 @@ -# Introduction +# 소개 -We are ready to start the deployment of our website. +우리는 웹 사이트 배포를 시작할 것입니다. -The first step will be the frontend. Because it’s a static website, we can create an [S3 bucket](http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html), put all the code in it and serve it as a static website. Think of an S3 bucket as a folder in the cloud, which can be setup for access from the outside world via a URL (and even help a bit with your application's routes). +첫 번째 단계는 프론트 엔드가 될 것입니다. 정적 웹 사이트이기 때문에, 우리는 [S3 bucket](http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html) 을 생성 할 수 있고, 그 곳에 모든 코드를 넣을 수 있고, 정적인 웹사이트로서 제공할 수 있습니다. S3 버킷을, 외부에서 URL을 통해 액세스 할 수 있도록 설정할 수 있는(응용 프로그램의 경로를 조금이라도 도울 수 있는) 클라우드의 폴더로 생각하십시오. -To automate the build, we will use [CodeBuild](https://aws.amazon.com/codebuild/), AWS service to build projects on the go. -CodeBuild will pull our repository, build the webpage and copy the build directory to S3. The configuration is specified on `buildspec.frontend.yml` on [the root folder of our repo](/buildspec.frontend.yml). +빌드를 자동화하기 위해, 우리는 지속적으로 프로젝트를 빌드하기 위한 AWS service 인 [CodeBuild](https://aws.amazon.com/codebuild/) 를 사용할 것입니다. +CodeBuild 는 우리의 레파지토리에서 소스를 가져오고, 웹페이지에 빌드하고, S3에 빌드 디렉토리를 복사할 것입니다. 설정값은 우리의 레파지토리의 root 폴더에 있는 (/buildspec.frontend.yml) `buildspec.frontend.yml` 파일에 명시 되어 있습니다. -In order to automate the deployment of our API to the EC2 instances, we will use [CodeDeploy](http://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html). It will pull our repo to the EC2 instances and start our server (gunicorn). The full deploy process is described in the `appspec.yml` file, [here](/appspec.yml). +우리의 API를 EC2 인스턴스에 자동으로 배포하기 위해, [CodeDeploy](http://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 를 사용할 것입니다. EC2 인스턴스로 repo를 가져오고 서버를 시작합니다(gunicorn). 전체 배포 프로세스는 `appspec.yml` 파일에 설명되어 있습니다.[here](/appspec.yml) -Last but not least our database will be hosted using [AWS RDS](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html), as a PostgreSQL instance. +마지막으로 데이터베이스는 PostgreSQL 인스턴스로 [AWS RDS](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html) 를 사용하여 호스팅됩니다. -To sum up, in this section we will create: +요약하면, 이 섹션에서 우리는 아래 내용을 생성할 것입니다.: -- an S3 bucket to host our static frontend. -- a CodeBuild setup to build the frontend and copy the output to the S3 bucket. -- a CodeDeploy setup to deploy our API to the EC2 instances. -- a RDS PostgreSQL instance. +- 정적 프런트엔드를 호스팅하기 위한 s3 버킷 +- 프런트엔드를 배포하기 위한, S3 버킷에 결과물을 복사하기 위한 CodeBuild 설정 +- API를 EC2 인스턴스에 배포하기위한 CodeDeploy 설정 +- RDS PostgreSQL 인스턴스. -> **Important:** after you are done with this workshop, you will ideally clean up your account, so you are not billed anymore. This means that you need to delete everything you have created. +> **중요:** 이 워크숍을 마친 후에는 계정에 사용중인 인스턴스를 중지할 것이므로 더 이상 청구되지 않습니다. 즉, 이번에 신규로 생성한 모든 것을 삭제해야합니다. > -> Many resources in AWS [can be tagged](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/). If something can be tagged, then you should tag it with a **unique name**. Later, you can use the [Tag Editor](https://aws.amazon.com/blogs/aws/resource-groups-and-tagging/) to find your tagged resources to delete, and make sure you don't leave anything behind. +> AWS의 많은 자원은 [태그를 달 수 있습니다](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/). 만약 태그 할 수 있는 어떤 항목이 있으면, **unique name** 으로 태그를 지정해야 합니다. 나중에, 여러분들은 지울 태그된 리소스를 찾기 위해 [Tag Editor](https://aws.amazon.com/blogs/aws/resource-groups-and-tagging/) 를 사용할 수 있고, 뒤에 어떤것도 남기지 않을 것이라 확신합니다. --- -**Next:** learn how to [serve a static website from S3](/workshop/s3-web-ec2-api-rds/01-serve-website-from-s3.md). +**다음:** [S3에서 정적 웹 사이트를 제공하는 방법](/workshop/s3-web-ec2-api-rds/01-serve-website-from-s3.md)을 배우십시오. diff --git a/workshop/set-up-users.md b/workshop/set-up-users.md index efd2e58..0978a86 100644 --- a/workshop/set-up-users.md +++ b/workshop/set-up-users.md @@ -1,45 +1,63 @@ -# Set up users on AWS - -> **TryoTip:** if you are using the **Tryolabs Playground AWS account**, this section does not apply. Please, read it anyway, so you have some context on what you would do with a bare new AWS account. - -As you might already now there is a special account in AWS called _root_. This is the account used to do the initial setup for users, roles and billing information. Is recommended to create a user with administrator priviledges for the every day use and [not use the root account](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users) to login to AWS. Additionally, you should make sure you enable [Multi Factor Authentication (MFA)](http://docs.aws.amazon.com/console/iam/security-status-activate-mfa) on your root account, and use an app like [Authy](https://authy.com/) as a second factor on your phone (Android/iOS). - -Next, we are going to use our root account to setup 2 AWS users. - -One will be used to access AWS via the console (web interface, so this will be your own user). The other will be used for accessing our account *programmatically*: we will create an **access key ID** and **secret access key** for the AWS API, CLI, SDK, and other development tools. - -Every account has some associated permissions. It is a good practice to have those strictly limited to the bare minimum necessary, especially for programmatic access. Permissions are handled by attaching [policies](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) to the user accounts. There, you can customize the access levels to various AWS services. - -First we are going to create the user for the AWS console: - -1. Login to your AWS account with the root user. -2. Go to **IAM** under Security, Identity & Compliance section. -3. Click on Users. -4. Click Add user button. -5. Enter a username and check the option: **AWS Management Console access** under the **Select AWS access type** section and then click next. You should also mark the option so that the user is forced to change his password on next login (pick a secure password!). -6. Select **Attach existing policies directly**. -7. Search for: `AdministratorAccess`, check it and click next. -8. Click on Create user. Copy the url and password that appear in the Success message. - -Now, lets login with our new user: - -1. Log out from AWS and go to the link you copied earlier. -2. Enter the username and password that was auto-generated. -3. Enter your new password. - -After this, we can create the user to access AWS programmatically: - -1. Repeat steps from 2 to 4 to setup a user. -2. Enter a username and check the option **Programmatic access** under the **Select AWS access type** section. Click next. -3. Select **Attach existing policies directly**. -4. Search for: `AdministratorAccess`, check it and click next. Of course, in a real use case, you would design or use a policy with more restricted access. -5. Click on Download CSV. - -In the downloaded file, you can find the access key id and the secret access key. You’ll need them to [configure your AWS CLI](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) in your computer. If you don’t have AWS CLI installed yet, you can do it following [these steps](http://docs.aws.amazon.com/cli/latest/userguide/installing.html). +# IAM 사용자 설정하기 + +여러분도 이미 아시겠지만, AWS에는 루트(_root_)라 불리는 특별한 계정(`루트 계정`)이 있습니다. +이 계정은 사용자(users), 역할(roles) 그리고 결제 정보에 대한 초기 설정을 수행하는 데 사용됩니다. +매일 작업에 사용할 관리자 권한을 가진 사용자를 생성하고, +[루트 계정으로 AWS에 로그인하지 않기](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users)를 권장합니다. +또한 루트 계정은 [멀티 팩터 인증 (MFA)](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users)을 활성화하고, +로그인할 때 여러분의 핸드폰(Android/iOS)에 설치된 [Authy](https://authy.com/) 같은 앱을 "두 번째 요소"로 이용하시길 권장합니다. + +다음으로, 루트 계정을 이용하여 AWS 사용자 2개를 설정합니다. + +하나는 console (웹 인터페이스)을 이용하여 AWS에 접근하는 데 사용됩니다. +다른 하나는 프로그래밍 방식(programmatically)으로 접근하는 데 사용됩니다: +AWS API, CLI, SDK 그리고 다른 개발 도구들을 위한 액세스 키 ID(**access key ID**), 보안 액세스 키(**secret access key**)를 생성합니다. + +모든 계정은 몇 가지 관련 권한(Permission)을 가집니다. +해당 계정이 최소 권한을 가지도록 엄격하게 제한하는 것이 좋습니다. +특히 프로그램 방식 액세스는 더욱더 그러합니다. +권한(Permission)은 [정책(Policy)](http://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)을 사용자 계정에 부여함으로써 처리됩니다. +여기에서 여러분은 다양한 AWS 서비스에 대한 접근 수준을 정의할 수 있습니다. + +먼저, AWS console 사용자를 생성합니다: + +1. 루트 사용자ID(AWS 가입에 사용한 email)로 AWS 관리 콘솔(Management Console)에 로그인. +2. "Security, Identity & Compliance" 섹션에서 **IAM**으로 이동. +3. 메뉴 Users 클릭. +4. 버튼 "Add user" 클릭. +5. Username에 `ConsoleUser`를 입력하고, + **Select AWS access type** 섹션에 있는 **AWS Management Console access** 옵션을 선택한 후, + 버튼 "Next" 클릭. + **Require password reset** 옵션을 선택하여 다음번 로그인할 때 비밀번호를 수정하도록 합니다 (안전한 암호를 선택하십시오!). +6. **Attach existing policies directly** 선택. +7. `AdministratorAccess`를 검색하여 선택한 후, "Next" 클릭. +8. "Create user"를 클릭하여 사용자를 생성한 후, 메시지에 표시된 AWS Management Console 접근 URL 및 비밀번호를 텍스트 에디터에 복사해 둡니다. + +이제, 새로운 사용자로 로그인합니다: + +1. AWS console에서 로그아웃하고, 복사한 URL 링크를 이용하여 console에 접속합니다. +2. Username과 자동 생성된 비밀번호를 입력합니다. +3. 새로운 비밀번호를 입력합니다. + +이다음으로, 프로그래밍 방식으로 액세스할 사용자를 생성합니다: + +1. 아래 2~4번을 반복하여 사용자를 설정합니다. +2. Username에 `ProgrammaticUser`를 입력하고, **Select AWS access type** 섹션에서 **Programmatic access** 옵션을 선택. + "Next" 클릭. +3. **Attach existing policies directly** 선택. +4. `PowerUserAccess`로 검색하여 이를 선택한 후, 버튼 "Next" 클릭. + 물론 실제 상황에서는 더욱 제한적인 접근 권한을 가지는 정책(Policy)을 설계하고 이를 사용합니다. +5. "Download .csv" 클릭. + +내려받은 CSV 파일에서 액세스 키 ID, 보안 액세스 키를 확인할 수 있습니다. +이는 여러분의 컴퓨터에 설치된 [AWS CLI를 설정](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)하는 데 필요합니다. +아직 AWS CLI가 설치되어 있지 않다면, [이곳 링크](http://docs.aws.amazon.com/cli/latest/userguide/installing.html)를 따라 해 보세요. --- -**Extra mile**: set the `ViewOnlyAccess` permissions to the user with programmatic access. Double points if you do it with the CLI. +**도전 과제**: + 1. 프로그래밍 방식 액세스 사용자에 `ViewOnlyAccess` 권한을 부여해 보세요. AWS CLI 를 사용하여 할 수 있다면 더욱 좋겠죠. + 2. 콘솔 액세스 사용자에게 MFA를 적용시켜 보세요. 이를 위해서는 여러분의 스마트폰에 가상 MFA 어플리케이션을 설치하여야만 합니다. --- -**Next:** [S3, RDS and EC2](/workshop/s3-web-ec2-api-rds/introduction.md). +**다음:** [S3, RDS 그리고 EC2](/workshop/s3-web-ec2-api-rds/introduction.md). diff --git a/workshop/vpc-subnets-bastion/01-create-vpc.md b/workshop/vpc-subnets-bastion/01-create-vpc.md index ba5f6b8..a746d01 100644 --- a/workshop/vpc-subnets-bastion/01-create-vpc.md +++ b/workshop/vpc-subnets-bastion/01-create-vpc.md @@ -1,26 +1,28 @@ # VPC -We are going to create our VPC with 4 subnets (2 private and 2 public). +지금부터 새로운 VPC를 4개의 서브넷(프라이빗2개, 퍼블릭2개)과 함깨 생성하도록 하겠습니다. -## Create a VPC -1. Go to VPC under Networking & Content Delivery. -2. Go to Your VPCs on the left section. -3. Click on Create VPC. -4. As **Name** **tag** put: `awsworkshopvpc`. -5. As **IPv4 CIDR** **block** put: `10.0.0.0/16`. -6. Then click: Yes, Create. +## VPC생성 +1. AWS Management Console에 접속한 후 Region(예:Seoul) 을 Click 하세요. 이후 메뉴에서 Networking & Content Delivery 안의 VPC를 Click 하세요. +2. 왼쪽 메뉴에서 **Your VPCs** 를 Click 하세요. +3. 화면 왼쪽 위에 **Create VPC** 를 Click 하세요. +4. **Name tag** 에는 `awsworkshopvpc` 를 입력하시거나 원하시는 것을 입력하세요. +5. **IPv4 CIDR block** 에는 `10.0.0.0/16` 를 입력하시거나 원하시는 IP 대역을 입력하세요. +6. 오른쪽 아래에 **Yes, Create** 를 Click 하세요.. -## Create 4 subnets -1. Go to Subnets on the left section. -2. Click Create Subnet. -3. As **Name tag** put: `10.0.1.0-us-east-1a`. -4. **Availability Zone**: `us-east-1a`. -5. As **IPv4 CIDR** **block** put: `10.0.1.0/24`. CIDR block for any subnet will be a subset of the VPC CIDR block. -6. Then click in Yes, Create. -7. Repeat steps 2-6 using as **Name tag**: `10.0.2.0-us-east-1a`, **Availability Zone**: `us-east-1a` and **IPv4 CIDR block**: `10.0.2.0/24`. -8. Repeat steps 2-6 using as **Name tag**: `10.0.3.0-us-east-1b`, **Availability Zone**: `us-east-1b` and **IPv4 CIDR block**: `10.0.3.0/24`. -9. Repeat steps 2-6 using as **Name tag**: `10.0.4.0-us-east-1b`, **Availability Zone**: `us-east-1b` and **IPv4 CIDR block**: `10.0.4.0/24`. +## 4개의 서브넷을 생성 +1. 왼쪽 메뉴에서 **Subnets** 를 Click 하세요. +2. 화면 왼쪽 위에 **Create Subnet** 을 Click 하세요. +3. **Name tag** 에는 `10.0.1.0-ap-northeast-1a` 를 입력하시거나 원하시는 것을 입력하세요. +4. **VPC** 에는 생성한 VPC 를 Click 하세요. +5. **Availability Zone** 에는 원하시는 Availability Zone(예:ap-northeast-2a)을 Click 하세요. +6. **IPv4 CIDR block** 에는 `10.0.1.0/24` 를 입력하세요. 모든 Subnet 에 대한 CIDR 블록은 VPC CIDR 블록의 하위 집합이 됩니다. +7. **Create** 을 Click 하세요. +8. 반복, 위의 2번 - 7번을 반복하여 **Name tag**: `10.0.2.0-ap-northeast-2a`, **Availability Zone**: `ap-northeast-1a`, **IPv4 CIDR block**: `10.0.2.0/24`. +9. 반복, 위의 2번 - 7번을 반복하여 **Name tag**: `10.0.3.0-ap-northeast-2b`, **Availability Zone**: `ap-noreast-1b`, **IPv4 CIDR block**: `10.0.3.0/24`. +10. 반복, 위의 2번 - 7번을 반복하여 **Name tag**: `10.0.4.0-ap-northeast-2b`, **Availability Zone**: `ap-northeast-2b`, **IPv4 CIDR block**: `10.0.4.0/24`. --- -**Next:** [create an Internet Gateway and a public Routes table](/workshop/vpc-subnets-bastion/02-internet-gateway.md). +**다음:** [Create an Internet Gateway and a public Routes table](/workshop/vpc-subnets-bastion/02-internet-gateway.md). + diff --git a/workshop/vpc-subnets-bastion/02-internet-gateway.md b/workshop/vpc-subnets-bastion/02-internet-gateway.md index dac69dc..e5bfcf2 100644 --- a/workshop/vpc-subnets-bastion/02-internet-gateway.md +++ b/workshop/vpc-subnets-bastion/02-internet-gateway.md @@ -1,41 +1,40 @@ # Internet Gateway -We already have our VPC with 4 subnets, but none of those can access the Internet (they are effectively private). To turn 2 of them into public, we need to setup an [Internet Gateway](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html) for our VPC and create a Route Table to route all external traffic through the gateway. -Finally, we need to associate 2 of our subnets to this route table and assign them a public IP, so they turn into public subnets. +우리는 이미 VPC에 4개의 Subnet 을 함께 가지고 있지만, 그 중 아무것도 인터넷에 접속할 수 없습니다. (그것들은 Private 상태입니다). Public으로 2개를 전환하려면, 우리는 VPC용 [Internet Gateway](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html) 를 Setup하고 Gateway를 통하여 모든 외부 트래픽을 라우팅하는 Routing Table 을 create 해야 합니다. 마지막으로, 우리는 2개의 Subnet을 라우팅 테이블에 associate 하고 public IP 를 할당하면, public subnet이 됩니다. -## Create a Internet Gateway -1. Go to Internet Gateways on the left section. -2. Click Create Internet Gateway. -3. As Name tag put: `awsworkshopIGW`. -4. Click: Yes, Create. -5. Click Attach to VPC. -6. Click: Yes, Attach. +## Internet Gateway 만들기 +1. VPC Dashboard 의 왼쪽 메뉴에서 **Internet Gateways** 를 Click 하세요. +2. **Create Internet Gateway** 를 Click 하세요. +3. **Name tag** 에는 `awsworkshopIGW` 를 입력하거나 원하시는 것을 입력하세요. +4. **Create** 를 Click 하세요. +5. 메뉴 상단에 **Action** 을 Click 하고 **Attach to VPC** 를 Click 하세요. +6. **Attach** 를 생성한 VPC를 선택하여 Click 하세요. -## Create Route tables -1. Go to Route Tables on the left section. -2. Click Create Route Table. -3. As Name tag: `awsWorkshopPublicRT`. -4. Click Yes, Create. -5. On the bottom section select the Routes tab. -6. Click on Edit button. -7. Click on Add another Route. -8. As **Destination** put `0.0.0.0/0`. -9. As **Target** select your Internet Gateway. -10. Click Save. -11. Now select Subnet Associations tab. -12. Click on Edit. -13. Select `10.0.1.0-us-east-1a` and `10.0.3.0-us-east-1b`. -14. Click Save. +## Route tables 만들기 +1. VPC Dashboard 의 왼쪽 메뉴에서 **Route Tables** 을 Click 하세요. +2. **Create Route Table** 을 Click 하세요. +3. **Name tag**: `awsWorkshopPublicRT` 을 입력하거나 원하시는 것을 입력하세요. +4. **Yes, Create** 을 Click 하세요. +5. 화면 아래에 **Routes** tab 을 Click 하세요. +6. **Edit** button 을 Click 하세요. +7. 추가할 `Route` 을 입력하세요. +8. **Destination** 에서 `0.0.0.0/0` 을 입력하거나 원하시는 것을 입력하세요. +9. **Target** 에는 생성한 **Internet Gateway** 을 선택하여 Click 하세요. +10. 설정이 완료되었으면 **Save** 를 CLick 하세요. +11. **Subnet Associations** tab 에는 Subnet을 선택하세요. +12. **Edit** 를 Click 하세요. +13. `10.0.1.0-ap-northeast-1a` 와 `10.0.3.0-ap-northeast-1b` 을 선택하세요. +14. **Save** 을 Click 하세요. ## Assign public IP to our public subnet -1. Go to Subnets on the left section. -2. Select the `10.0.1.0-us-east-1a`. -3. Click on Subnet Actions. -4. Select Modify auto-assign IP settings. -5. Check: Enable auto-assign public IPv4 address. -6. Click Save. -7. Click Close. -8. Repeat steps 2-7 with `10.0.3.0-us-east-1b`. +1. 왼쪽 메뉴에서 **Subnets** 을 Click 하세요. +2. `10.0.1.0-ap-northeast-1a` 을 선택하세요. +3. **Actions** 를 Click 하세요. +4. **Modify auto-assign IP** 를 수정하여 설정하세요. +5. **Enable auto-assign public IPv4 address** 를 Click 하세요. +6. **Save** Click 하세요. +7. **Close** Click 하세요. +8. 반복, 위의 2번 - 7번을 반복하여 `10.0.3.0-ap-northeast-1b` 을 선택하세요. --- -**Next:** [create a NAT Instance](/workshop/vpc-subnets-bastion/03-nat-instance.md). +**다음:** [Create a NAT Instance](/workshop/vpc-subnets-bastion/03-nat-instance.md). diff --git a/workshop/vpc-subnets-bastion/03-nat-instance.md b/workshop/vpc-subnets-bastion/03-nat-instance.md index 6556f8a..60128b4 100644 --- a/workshop/vpc-subnets-bastion/03-nat-instance.md +++ b/workshop/vpc-subnets-bastion/03-nat-instance.md @@ -1,52 +1,51 @@ # NAT Instance -Until now we have 2 public subnets and 2 private subnets. In the private ones, we will deploy the webserver instances that will be accessible via a Load Balancer. +지금까지 2개의 Public Subnet과 2개의 Private Subnet 을 만들었습니다. Private 에서는 Load Balancer 를 통해 액세스 할 수 있는 웹 서비 인스턴스를 배포합니다. -Even if these instances don't need to be reachable from outside of the VPC, they need to have Internet access to download and update packages. For this reason, we need a NAT through which we can route all external outbound traffic. +이러한 인스턴스가 VPC 외부에서 연결할 필요가 없더라도 패키지를 다운로드하고 업데이트하려면 인터넷에 액세스 할 수 있어야합니다. 이러한 이유로 외부의 모든 아웃 바운드 트래픽을 라우팅 할 수있는 NAT가 필요합니다. -AWS offers two options for NAT: [NAT Instance](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html) and [NAT Gateway](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html). -The Gateway offering is newer and easier to setup than the NAT Instance, and also automatically scales. However, for this tutorial, will go for the NAT Instance purely because it's cheaper (we don't want to be billed too much!). +AWS 는 NAT: [NAT Instance](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html) 와 [NAT Gateway](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html) 2가지 option을 제공합니다. Gateway 오퍼링은 NAT 인스턴스보다 새롭고 설치가 쉽고 자동으로 확장됩니다. 그러나이 자습서에서는 NAT 인스턴스를 저렴하게 사용할 수 있습니다 (너무 많이 청구되기를 원하지 않습니다!). ## Create Nat Instance -1. Go to EC2 under Computer section. -2. Click on Instances on the left menu. -3. Click Launch Instance. -4. Select Community AMIs. -5. Type NAT and then hit Enter. -6. Select the first option that appears: +1. AWS Management Console 에서 Computer 의 EC2 Dashboard 로 이동하세요. +2. 왼쪽 메뉴에서 Instances 를 Click 하세요. +3. Launch Instance Click 하세요. +4. Community AMIs 를 선택하세요. +5. NAT 를 입력하고 그 다음 Enter 를 누르세요. +6. 나타나는 첫 번째 옵션을 선택하십시오: 1. Root device type: `ebs` 2. Virtualization type: `hvm` 3. ENA Enabled: `No`. -7. Select `t2.micro` and click Next: Configure Instance Details. -8. On Network, select your VPC. -9. As subnet, select `10.0.1.0-us-east-1a` -10. Click Next: Add Storage. -11. Click Next: Add Tag. -12. As Key put `Name` and as Value `MyNat`. -13. Click Next: Configure Security Group. -14. Select: Create a new security group. -15. As **Security group name** put `natsecuritygroup`. -16. Add 3 rules: SSH, HTTP, HTTPS. -17. Click: Review and Launch. -18. Click: Next. -19. Click: Launch. -20. Select your key pair and click Launch Instances. -21. Click View Instances. -22. Select your NAT instance. -23. Go to Actions - Networking and click on **Change Source/Dest. Check**. -24. Click Yes, Disable. -25. Go to Actions again - Networking and click **Change Security Groups** and add the default one for the VPC. +7. `t2.micro` 를 선택하고 Next 를 click : Configure Instance Details. +8. Network 에서, VPC를 선택하세요. +9. subnet 에서, `10.0.1.0-ap-northeast-1a` 를 선택하세요. +10. Next: Add Storage 를 Click 하세요. +11. Next: Add Tag Click 하세요. +12. Key 에서 `Name` 과 Value `MyNat` 을 입력하거나 원하시는 것을 입력하세요. +13. Next: **Configure Security Group** Click 하세요. +14. Select: 새로운 **security group** 을 만듭니다. +15. **Security group name** 을 `natsecuritygroup` 를 입력하거나 원하시는 것을 입력하세요. +16. 기본이 되는 3개의 rules: SSH, HTTP, HTTPS 을 추가하세요. +17. **Review and Launch** 를 Click 하세요. +18. Next 를 Click 하세요. +19. Launch 를 Click 하세요. +20. key pair 를 선택하고 Launch Instances 를 Click 하세요. +21. **View Instances** 를 Click 하세요. +22. NAT instance 선택하세요. +23. Actions - Networking 으로 이동하고 **Change Source/Dest. Check** 을 click 하세요. +24. Yes, **Disable** Click 하세요. +25. 다시 Actions - Networking 으로 이동하고 **Change Security Groups** 을 click 하고 VPC에 기본으로 추가하세요. ## Create a route for private subnets through the NAT instance -1. Go to VPC under Networking & Content Delivery. -2. Go to Route Tables on the left section. -3. Select the Main subnet of `awsworkshopvpc`. -4. On the bottom section go to the Routes tab. -5. Click Edit. -6. Click Add another Route. -7. As Destination put: `0.0.0.0/0`. -8. As Target select your NAT Instance. -9. Click Save. +1. AWS Management Console에서 Networking & Content Delivery 의 VPC로 이동하세요. +2. 왼쪽 메뉴에서 **Route Tables** 로 이동하세요. +3. Main subnet 인 `awsworkshopvpc` 을 선택하세요. +4. 화면 하단의 **Routes tab** 으로 이동하세요. +5. **Edit** 를 Click 하세요. +6. **another Route** 를 추가하고 Click 하세요. +7. Destination `0.0.0.0/0` 을 입력하세요. +8. NAT Instance 를 Target 으로 선택하세요. +9. **Save** 를 Click 하세요. --- -**Next:** [create new Load Balancer](/workshop/vpc-subnets-bastion/04-load-balancer.md). +**다음:** [Create new Load Balancer](/workshop/vpc-subnets-bastion/04-load-balancer.md). diff --git a/workshop/vpc-subnets-bastion/04-load-balancer.md b/workshop/vpc-subnets-bastion/04-load-balancer.md index 8e676c8..00faed3 100644 --- a/workshop/vpc-subnets-bastion/04-load-balancer.md +++ b/workshop/vpc-subnets-bastion/04-load-balancer.md @@ -1,36 +1,36 @@ # Load Balancer -At this point, we need to create a Load Balancer to be able to route request from the web to our instances. +이 시점에서 웹에서 인스턴스로 요청을 라우팅 할 수 있도록 로드밸런서를 만들도록 하겠습니다. -## Create a new Load Balancer -1. Go to EC2 under Computer section. -2. Click on Load Balancers. -3. Click Create Load Balancer. -4. Click Create on Application Load Balancer. -5. As Name put: `aws-workshop-load-balancer-vpc`. -6. On Availability Zones, on VPC select `awsworkshopvpc`. -7. Click on `us-east-1a`. -8. Click on `10.0.1.0-us-east-1a`. -9. Repeat steps 7 and 8 for `us-east-1b` and `10.0.3.0-us-east-1b`. -10. Click Next: Configure Security Settings. -11. Click Next: Configure Security Groups. -12. Select Create a **new** security group and then click Next: Configure Routing. -13. As name put: `aws-workshop-target-group-vpc`. -14. As Port: `9000`. -15. As path: `/api/tags`. -16. Click Next: Register Targets. -17. Click Next: Review. +## 새로운 로드밸런서 생성 +1. AWS Management Console 에서 Computre 의 EC2 Dashboard 로 이동하세요. +2. **Load Balancers** 를 Click 하세요. +3. Load Balancer Create 를 Click 하세요. +4. Application Load Balancer 생성을 Click 하세요. +5. Name 입력: `aws-workshop-load-balancer-vpc` 을 입력하거나 원하는 것을 입력하세요. +6. Availability Zones, VPC 를 선택하고 `awsworkshopvpc` 입력하거나 원하시는 것을 입력하세요. +7. `ap-northeast-1a` Click 하세요. +8. `10.0.1.0-ap-northeast-1a` Click 하세요. +9. 반복, 7번에서 8번까지 반복하여 `ap-northeast-1b` 와 `10.0.3.0-ap-northeast-1b` 를 입력하거나 원하시는 것을 입력하세요. +10. Next: Configure Security 를 Click 하여 Settings 하세요. +11. Next: Configure Security Groups 를 Click 하세요. +12. 생성한 **new** security group 을 선택하고 그 다음 Next: Configure Routing click 하세요. +13. name 입력: `aws-workshop-target-group-vpc` 을 입력하거나 원하시는 것을 입력하세요. +14. Port: `9000`. +15. path: `/api/tags`. +16. Next: Register Targets Click 하세요. +17. Next: Review 를 Click 하세요. 18. Click: Create. 19. Click: Close. -20. Select the new load balancer. -21. Go to Description on bottom and find Security. -22. Click Edit Security Groups. -23. Select default (so that both security groups are selected). -24. Click Save. -25. Delete old Load Balancer. +20. New load balancer 를 선택하세요. +21. 아래 Description 으로 이동하여 Security 를 찾으세요. +22. Security Groups 에서 Edit 를 Click 하세요. +23. default (so that both security groups are selected) 를 선택하세요. +24. Save 를 Click 하세요. +25. Old Load Balancer 를 삭제하세요. ## Modify API_URL -Repeat the steps outlined in [this section](/workshop/elb-auto-scaling-group/03-finishing-up.md). +반복, 이 단계를 반복하세요 [this section](/workshop/elb-auto-scaling-group/03-finishing-up.md). --- -**Next:** [move RDS into your VPC](/workshop/vpc-subnets-bastion/05-RDS.md). \ No newline at end of file +**다음:** [Move RDS into your VPC](/workshop/vpc-subnets-bastion/05-RDS.md). diff --git a/workshop/vpc-subnets-bastion/05-RDS.md b/workshop/vpc-subnets-bastion/05-RDS.md index 655f760..b6b9ad3 100644 --- a/workshop/vpc-subnets-bastion/05-RDS.md +++ b/workshop/vpc-subnets-bastion/05-RDS.md @@ -1,21 +1,21 @@ # RDS -Now, we should move our RDS to the private subnets of our VPC. This way, we ensure that RDS is only accessible from these private subnets, and never from the outside world. +이제 RDS를 VPC의 개인 서브넷으로 이동해야합니다. 이렇게하면 RDS가 외부 전용이 아닌 개인 서브넷에서만 액세스 할 수 있습니다. -## Move RDS to your VPC -1. Open the [Amazon RDS console](https://console.aws.amazon.com/rds) and choose Subnet Groups on the left navigation pane. -2. Choose **Create DB Subnet Group**. -3. Enter the subnet name: `vpcsubnetgroup`. -4. As VPC ID: your VPC. -5. Then choose Availability Zone `us-east-1a` and Subnet Id `10.0.2.0-us-east-1a` and click Add. -6. Then choose Availability Zone `us-east-1b` and Subnet Id `10.0.4.0-us-east-1a` and click Add. -7. Click **Create**. -8. Go to Instances, select your RDS instance and on Instance Actions select Modify. -9. As Subnet Group select your `vpcsubnetgroup`. +## RDS를 여러분의 VPC로 이동시키기 +1. AWS Management Console 에서 [Amazon RDS console](https://console.aws.amazon.com/rds) 을 열고 왼쪽 메뉴에서 Subnet Groups 을 선택하세요. +2. **Create DB Subnet Group** 을 선택하세요. +3. Enter the subnet name: `vpcsubnetgroup` 을 입력하거나 원하시는 것을 입력하세요. +4. VPC ID: your VPC 를 선택하세요. +5. 이후 Availability Zone `ap-northeast-1a` 와 Subnet Id `10.0.2.0-ap-northeast-1a` 을 선택하고 Click 하여 추가하세요. +6. 이후 Availability Zone `ap-northeast-1b` 와 Subnet Id `10.0.4.0-ap-northeast-1a` 를 선택하고 Click 하여 추가하세요. +7. **Create** Click 하세요. +8. 왼쪽 메뉴에서 Instances 로 이동하고, RDS instance 와 Instance Actions Modify 를 선택하세요. +9. Subnet Group 에서 `vpcsubnetgroup` 을 선택하세요. 10. Security Group: `default`. -11. Click Modify DB Instance. -12. Check Apply Immediately. -13. Click Continue. +11. Modify DB Instance 를 Click 하세요. +12. Immediately 를 확인하여 Apply 를 하세요. +13. Continue Click 하세요. --- -**Next:** [Auto Scaling Group](/workshop/vpc-subnets-bastion/06-auto-scaling-group.md). +**다음:** [Auto Scaling Group](/workshop/vpc-subnets-bastion/06-auto-scaling-group.md). diff --git a/workshop/vpc-subnets-bastion/06-auto-scaling-group.md b/workshop/vpc-subnets-bastion/06-auto-scaling-group.md index e543dd2..5780878 100644 --- a/workshop/vpc-subnets-bastion/06-auto-scaling-group.md +++ b/workshop/vpc-subnets-bastion/06-auto-scaling-group.md @@ -1,52 +1,52 @@ # Auto Scaling Group -We are going to create a new Launch Configuration and Auto Scaling Group so that all our instances start only in our private subnets. +모든 인스턴스가 Private Subnet에서만 시작되도록 새로운 Launch Configuration and Auto Scaling Group을 만들 것입니다. -## Create a new Launch Configuration -1. Go to EC2 under Compute. -2. Go to Auto Scaling Groups on the left menu. -3. Delete the existing Auto Scaling group. -4. Go to Launch Configuration on the left menu. -5. Delete existing Launch Configuration. +## 새로운 시작 구성(Launch Configuration) 생성하기 +1. AWS Management Console 에서 Compute 의 EC2 를 Click 하세요. +2. 왼쪽 메뉴 아래에 Auto Scaling Groups 를 Click 하세요. +3. 기존의 Auto Scaling group 은 삭제하세요. +4. 왼쪽 메뉴에서 Launch Configuration 을 Click 하세요. +5. 기존의 Launch Configuration 은 삭제하세요. -Now, you need to create a new Launch Configuration that is almost identical to the one that you just deleted except for one thing: instead of creating a Security Group you need to choose the default one for your VPC. +새로운 인스턴스 구성 및 자동 확장 그룹을 만들어 모든 인스턴스가 Private Subnet 에서만 시작되도록합니다. 이제 한 가지를 제외하고 방금 삭제 한 인스턴스와 거의 동일한 새 Launch Configuration 을 만들어야합니다: Security Group 을 만드는 대신 VPC에 대한 Default Security Group 을 선택해야합니다. -There is no simple way to find it because your AWS account already has a default VPC with its default security group and at this stage of the Launch Configuration wizard there is no way to distinguish between your VPC's default group and the default group for the default VPC (🤔). To find the security group: +AWS 계정에 이미 Default Security Group 이 포함 된 Default VPC가 있기 때문에이를 쉽게 찾을 수있는 방법이 없으며 Launch Configuration Wizard 의 단계에서는 VPC의 Default Group과 Default VPC의 Default Group 을 구별 할 수있는 방법이 없습니다 (🤔). Security Group 을 찾으려면 다음과 같이하십시오. -1. Go to **VPC** under **Networking & Content Delivery**. -2. Select **Security Groups** on the **Security** section on the left. -3. Search for a group with name `default` and VPC `vpc-ugly-id | awsworkshopvpc`. -4. Copy the **Group ID** value. +1. AWS Management Console 에서 **Networking & Content Delivery** 의 **VPC** 를 Click 하세요. +2. 왼쪽 메뉴에서 **Security** 에서 **Security Groups** 을 선택하세요. +3. `default` 라는 Name을 찾고 VPC `vpc-ugly-id | awsworkshopvpc` 을 선택하거나 원하시는 것을 하세요. +4. **Group ID** 값을 Copy 하세요. -Once you have this Security Group Id, start the Launch Configuration creation wizard. Once you reach the _Click Next: Configure Security Group._ step, instead of creating a new security group choose **Select an existing security group** and look for the group with name _default_ and the same Id that you have. You can check the [previous instructions](/workshop/elb-auto-scaling-group/02-auto-scaling-group.md) if you need. +Security Group Id 가 있다면, Launch Configuration creation wizard 를 시작하세요. _Click Next: Configure Security Group. _step, 새로운 security group 을 생성하는 대신 **Select an existing security group** 을 선택하고 _default_ 라는 Name 의 ID 를 찾습니다. 필요한 경우 [previous instructions](/workshop/elb-auto-scaling-group/02-auto-scaling-group.md) 확인할 수 있습니다. ## Create Auto Scaling Group -1. Go to EC2 under Compute section. -2. On left menu select Auto Scaling Groups under AUTO SCALING. +1. AWS Management Console 에서 Compute 에서 EC2 를 선택하세요. +2. 왼쪽 메뉴에서 Auto Scaling Groups 에서 AUTO SCALING 을 선택하세요. 3. Click: Create Auto Scaling group. -4. Select: `aws-workshop-auto-scaling-group` and then click Next Step. -5. On Group name put the same as in Launch configuration. +4. Select: `aws-workshop-auto-scaling-group` 이후 click Next Step. +5. Launch configuration 과 동일한 Group Name 을 입력하세요. 6. Group size: 2. -7. Network: `awsworkshopvpc`. -8. Subnet: `10.0.2.0-us-east-1a` and `10.0.4.0-us-east-1b`. -9. Advanced Details click on: Receive traffic from one or more load balancers. -10. On Target Groups double click and select: `aws-workshop-target-group-vpc`. -11. Click Next: Configure scaling policies. +7. Network: `awsworkshopvpc` 을 입력하거나 원하시는 것을 입력하세요. +8. Subnet: `10.0.2.0-ap-northeast-1a` and `10.0.4.0-ap-northeast-1b` 를 선택하세요. +9. Advanced Details 를 click 하고 : Receive traffic from one or more load balancers 를 선택하세요. +10. Target Groups 을 click 하고 select: `aws-workshop-target-group-vpc` 를 선택하거나 원하시는 것을 선택하세요. +11. Next: Configure scaling policies 를 Click 하세요. 12. Select: **Use scaling policies to adjust the capacity of this group**. 13. Between 2 and 4. 14. Target value: 80. 15. Instances need: 180. -16. Click: Next: Configure Notifications. -17. Click: Next: Configure Tags. -18. Click: Review. -19. Click: Create Auto Scaling group. -20. Click: close. +16. Next: Configure Notifications Click 하세요. +17. Next: Configure Tags Click 하세요. +18. Review 를 Click 하세요. +19. Create Auto Scaling group Click 하세요. +20. Close Click 하세요. --- -**Extra mile:** +**도전 과제:** -- Why is the ASG only available on two subnets and not all of them? -- Why do we need this configuration of subnets anyway? (2 public and 2 private). +- 왜 ASG는 두 서브넷에서만 사용할 수 있으며 모든 서브넷에서 사용할 수 있습니까? +- 어쨌든이 서브넷 구성이 필요한 이유는 무엇입니까? (Public 2 와 Private 2). --- -**Next:** [create a Bastion](/workshop/vpc-subnets-bastion/07-bastion.md) to be able to SSH into the private instances. +**다음** [create a Bastion](/workshop/vpc-subnets-bastion/07-bastion.md) Private instances 에서 SSH 로 연결할 수 있습니다. diff --git a/workshop/vpc-subnets-bastion/07-bastion.md b/workshop/vpc-subnets-bastion/07-bastion.md index 97b4054..1a1caec 100644 --- a/workshop/vpc-subnets-bastion/07-bastion.md +++ b/workshop/vpc-subnets-bastion/07-bastion.md @@ -1,48 +1,42 @@ # Bastion instance -A bastion is a regular EC2 instance located in one of the public subnets, which allows incoming traffic through SSH. Through this instance, we will be able to SSH into any instance located in the private subnet (assuming they accept incoming traffic from the bastion). - -## Create a Bastion Instance -1. Go to **EC2** under **Compute section**. -2. Click on Launch Instance. -3. Look for Ubuntu Server (make sure it says Free tier eligible) and click Select. -4. Select `t2.micro` and then click on Next: Configure Instance Details. -5. On Network, select your VPC. -6. As subnet, you can pick any of the two public ones. For example, `10.0.1.0-us-east-1a`. -8. Click Next: Add Storage. -9. Leave the default settings and click Next: Add Tags. -10. Click Add Tag. -11. Fill Key with `Name` and in Value with `bastion`. -12. Click on Next: Configure Security Group. -13. Write a meaningful name in **Security group name**. -14. Click Review and Launch. -15. Click Launch. -16. Select your key pair and click Launch Instances. -17. Select the Bastion on the instances list and on Actions/Networking select Change Security Groups. -18. Check the default security group of your VPC. Make sure that 2 security groups are checked, the default one and the one you created during the creation of the bastion. - -## Accessing private instances through the bastion - -Now you have a public instance that can be accessed via SSH, but what you want is to be able to access to your private instances. - -To access the instances, you need to SSH with the PEM (key pair) that you had generated when launching the first one. - -### Option 1: setup SSH agent forwarding -You can read a guide [here](https://developer.github.com/v3/guides/using-ssh-agent-forwarding/). Even though the examples check access to GitHub, it's analogous to accessing our private instances. - -You can setup SSH so it's easier to access protected instances going transparently through the bastion. [Here](https://www.cyberciti.biz/faq/linux-unix-ssh-proxycommand-passing-through-one-host-gateway-server/) you have a nice guide. - -### Option 2: copy the PEM file from your machine to the bastion instance -Ideally, you would be using a different PEM file for the bastion and the instances (increased security). - -1. Copy the file with `scp ~/.ssh/.pem ubuntu@:/home/ubuntu/.ssh -i ~/.ssh/.pem`. -2. SSH into the bastion. -2. Make sure the file permissions are correct: `chmod 400 `. -3. SSH into the instances (from the bastion) with `ssh -i `. +Bastion dms Public Subnet 중 하나에 있는 일반 EC2 인스턴스로, SSH를 통해 들어오는 트래픽을 허용합니다. 이 Bastion 인스턴스를 통해 Private Subnet 에 있는 모든 인스턴스로 SSH를 수행 할 수 있습니다 (Bastion 에서 들어오는 트래픽을 수락한다고 가정). + +## 베스천 호스트 생성하기 +1. AWS Management Console 에서 **Compute section** 의 **EC2** 로 이동하세요. +2. Launch Instance 를 Click 하세요. +3. Ubuntu 서버를 찾아 (무료 티어를 사용할 수 있는지 확인하세요) 선택하여 Click 하세요. +4. `t2.micro` 를 선택하고 이후 Next: Configure Instance Details 를 click 하세요. +5. Network 에서, VPC 를 선택하세요. +6. subnet 에서, 2개의 Public 중 1개를 선택하세요. 예를 들어, `10.0.1.0-ap-northeast-1a`. +8. Next: Add Storage Click 하세요. +9. 기본 Settings 을 하고 Next: Add Tags Click 하세요. +10. Add Tag 를 Click 하세요. +11. `Name` 에 Key 를 입력하고 `bastion` 을 입력하거나 원하시는 것을 입력하세요. +12. Next: Configure Security Group Click 하세요. +13. **Security group name** 에 원하시는 것을 입력하세요. +14. Review and Launch 를 Click 하세요. +15. Launch 를 Click 하세요. +16. Key pair 를 선택하고 Launch Instances 를 Click 하세요. +17. EC2 Dashboard 에서 Instances list 를 보고 Bastion 을 선택하고 Actions/Networking Change Security Groups 을 선택하세요. +18. VPC 에서 default security group 을 확인하세요. 2 개의 Security Group 이 선택되었는지 확인하세요. Default Security Group 과 1개의 Security Group 을 작성되었습니다. + +## 베스천 호스트를 통해 프라이빗 인스턴스에 접속하기 + +이제 SSH를 통해 액세스 할 수 있는 Public Instance 가 있지만 원하는 것은 Private Instance 에 액세스 할 수있는 것입니다. + +인스턴스에 액세스하려면 첫 번째 인스턴스를 시작할 때 생성 한 PEM (키 쌍)으로 SSH를 수행해야 합니다. + +### SSH agent forwarding을 설정 +[가이드](https://developer.github.com/v3/guides/using-ssh-agent-forwarding/)를 참고하세요. 예제는 GitHub에 대한 액세스를 다루고 있지만 개인 인스턴스에 액세스하는 것도 유사합니다. + +윈도우즈 사용자의 경우 [Putty에서 agent forwarding을 사용](https://www.lesstif.com/pages/viewpage.action?pageId=14090790)하실수도 있습니다. + +Bastion 을 통해 투명하게 진행되는 보호된 인스턴스에 더 쉽게 액세스 할 수 있도록 SSH를 설정할 수 있습니다. [Here](https://www.cyberciti.biz/faq/linux-unix-ssh-proxycommand-passing-through-one-host-gateway-server/) 에 좋은 가이드가 있습니다. ---- -**Extra mile:** `ssh` to one of the instances in the private subnets and `tracepath` to an external host. Do the same for a instance in the public subnets. What's the difference? --- +**도전과제:** `ssh` 는 Private Subnet 의 인스턴스 중 하나에 연결하고 `tracepath`를 외부 호스트에 전달합니다. Public Subnet 의 인스턴스에 대해서도 동일하게 수행하십시오. 차이점이 뭘까요? -**Next:** [finish the deploy](/workshop/vpc-subnets-bastion/08-finishing-up.md). \ No newline at end of file +--- +**다음:** [finish the deploy](/workshop/vpc-subnets-bastion/08-finishing-up.md). diff --git a/workshop/vpc-subnets-bastion/08-finishing-up.md b/workshop/vpc-subnets-bastion/08-finishing-up.md index 9e1bb89..32ba9e3 100644 --- a/workshop/vpc-subnets-bastion/08-finishing-up.md +++ b/workshop/vpc-subnets-bastion/08-finishing-up.md @@ -1,7 +1,12 @@ -# Finishing up +# 마무리 -As usual, the last steps are modifying our CodeDeploy project so it uses our new Auto Scaling Group, re-run the deploy and rebuild the web so it uses the new parameters. +늘 그렇듯이, 마지막 단계는 새로운 Auto Scaling Group을 사용하도록 CodeDeploy 프로젝트를 수정하고, deploy를 다시 실행하고, 새로운 매개 변수를 사용하도록 웹을 재구성하는 것입니다. -For this, you can repeat the steps outlined [here](/workshop/elb-auto-scaling-group/03-finishing-up.md#modify-the-codedeploy-project). +이후에는 이전에 수항했던 [단계](/workshop/elb-auto-scaling-group/03-finishing-up.md#modify-the-codedeploy-project)를 반복하게 됩니다. ---- \ No newline at end of file +**도전과제:** 지금까지 진행해 왔던 모든 과정들을 보다 손쉽게 해 낼 수 있는 방법이 있습니다. 바로 Elastic Beanstalk라는 툴을 이용하는 것 인데요, Beanstalk을 사용한 실습은 [이곳](/workshop/beanstalk/introduction.md)에서 해 보실 수 있습니다. + +# 이것으로 모든 실습이 완료되었습니다. 수고하셨습니다! +## 불필요한 과금을 막기위해 실습에서 생성한 자원들은 모두 삭제하여 주시기 바랍니다. + +--- diff --git a/workshop/vpc-subnets-bastion/introduction.md b/workshop/vpc-subnets-bastion/introduction.md index 6242ea3..9d116d0 100644 --- a/workshop/vpc-subnets-bastion/introduction.md +++ b/workshop/vpc-subnets-bastion/introduction.md @@ -1,21 +1,20 @@ -# VPC and *bastion* instance +# VPC 와 Bastion 인스턴스 -The aim of this section is to improve a bit our security and redundancy. For this we are going to create a [custom VPC](https://aws.amazon.com/documentation/vpc/). +이 섹션의 목적은 우리의 Security 와 Redundancy 를 개선시키는 것에 있습니다. 이를 위해 [custom VPC](https://aws.amazon.com/documentation/vpc/)를 만듭니다. -Once we have our VPC, we will create 2 private subnets (where our Auto Scaling Group will launch the web server instances) in different Availability Zones (for redundancy reasons). We will also setup 2 public subnets in the same availability zones, which are needed by the load balancer. You can read more about VPC and subnets [here](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html). +VPC가 생기면 중복성을 이유로 서로 다른 가용 영역에서 2 개의 Private Subnet (AutoScaling Group 이 웹 서버 인스턴스를 시작할 위치)을 만듭니다. Load Balacner 에 필요한 동일한 가용 영역에 2 개의 Public Subnet 을 설치합니다. VPC 와 subnets 에 대해 많은 것은 [here](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html) 읽을 수 있습니다. -For our public subnets, we will need to setup an [Internet Gateway](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html) and create a new [Route Table](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html), so any instance in the subnet can access the Internet. +Public Subnet의 경우 [Internet Gateway](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html)를 설정하고 새로운 [Route Table](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html) 을 생성, 그래서 이 Subnet 의 모든 인스턴스는 인터넷에서 액세스 할 수 있습니다. -Since our application's instances will live in the **private** subnets, we also will need a [NAT Instance](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html) that will route their Internet traffic through the public subnets. We need our instances to access the Internet so that we can download packages, update our system, etc. +애플리케이션의 인스턴스는 **Private** Subnets 에 존재하는 것이라면 Public Subnets 을 통하여 인터넷 트래픽을 라우트 할 [NAT 인스턴스](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html)가 필요할 것입니다. 패키지를 다운로드하고 시스템을 업데이트 할 수 있도록 인터넷에 액세스하려면 인스턴스가 필요합니다. -We need to create a new Launch Configuration and modify our Auto Scaling Group so from now on it deploys to our VPC in the right subnets. Also, our RDS (PostgreSQL database) needs to be moved to our VPC so our instances can reach it. +새로운 Launch Configuration을 만들고 Auto Scaling Group을 수정하여 올바른 Subnet의 VPC에 배치해야 합니다. 또한 RDS (PostgreSQL 데이터베이스)를 VPC 로 이동하여 인스턴스가 도달 할 수 있습니다. -To access our instances through SSH from the outside world, we will add a [bastion instance](https://aws.amazon.com/blogs/security/how-to-record-ssh-sessions-established-through-a-bastion-host/). Since the bastion has direct access to the instances, we can access them by accessing the bastion first. +바깥 세상에서 SSH를 통해 인스턴스에 액세스하려면 [Bastion 인스턴스](https://aws.amazon.com/blogs/security/how-to-record-ssh-sessions-established-through-a-bastion-host/)를 추가하십시오. Bastion은 인스턴스에 직접 액세스 할 수 있으므로 첫번쨰로 Bastion에 액세스하여 접속 할 수 있습니다. -Finally, some changes need to be made to our CodeDeploy project so it deploys to our VPC, as expected. +마지막으로 CodeDeploy 프로젝트에 일부 변경을 하여 VPC에 배포합니다. -So, let's get started. +그래서 이제 시작하겠습니다. --- -**Next:** [create a VPC](/workshop/vpc-subnets-bastion/01-create-vpc.md). - +**다음:** [Create a VPC](/workshop/vpc-subnets-bastion/01-create-vpc.md).