기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 튜토리얼: Amazon EC2 인스턴스(Amazon Linux 또는 Red Hat Enterprise Linux 및 Linux, macOS 또는 Unix)에 WordPress 배포 이 튜토리얼에서는 PHP와 MySQL을 기반으로 하는 오픈 소스 블로그 도구 및 콘텐츠 관리 시스템인 WordPress를 Amazon Linux 또는 Red Hat Enterprise Linux(RHEL)를 실행하는 단일 Amazon EC2 인스턴스에 배포합니다. 찾는 항목이 보이지 않습니까? + 대신 Windows Server를 실행하는 Amazon EC2 인스턴스에 배포하는 방법을 연습하려면 [튜토리얼: CodeDeploy를 사용하여 "hello, world\$1" 애플리케이션 배포(Windows Server)](tutorials-windows.md) 단원을 참조하세요. + Amazon EC2 인스턴스 대신 온프레미스 인스턴스에 배포하는 방법을 연습하려면 [튜토리얼: CodeDeploy를 사용하여 온프레미스 인스턴스에 애플리케이션 배포(Windows Server, Ubuntu Server 또는 Red Hat Enterprise Linux)](tutorials-on-premises-instance.md) 단원을 참조하세요. 이 튜토리얼의 단계는 Linux, macOS, 또는 Unix를 실행하는 로컬 개발 시스템의 관점에서 제시됩니다. Windows를 실행하는 로컬 컴퓨터에서 이러한 단계를 대부분 완료할 수 있지만 명령(예: **chmod**, **wget**), 애플리케이션(예: sed), 디렉터리 경로(예: `/tmp`)를 다루는 단계를 적용해야 합니다. 이 자습서를 시작하기 전에 [CodeDeploy 시작하기](getting-started-codedeploy.md)의 사전 조건을 완료해야 합니다. 여기에는 사용자 구성, 설치 또는 업그레이드 AWS CLI, IAM 인스턴스 프로파일 및 서비스 역할 생성이 포함됩니다. **Topics** + [1단계: Amazon Linux 또는 Red Hat Enterprise Linux Amazon EC2 인스턴스 시작 및 구성](tutorials-wordpress-launch-instance.md) + [2단계: Amazon Linux 또는 Red Hat Enterprise Linux Amazon EC2 인스턴스에 배포할 원본 콘텐츠 구성](tutorials-wordpress-configure-content.md) + [3단계: WordPress 애플리케이션을 Amazon S3에 업로드](tutorials-wordpress-upload-application.md) + [4단계: WordPress 애플리케이션 배포](tutorials-wordpress-deploy-application.md) + [5단계: WordPress 애플리케이션 업데이트 및 재배포](tutorials-wordpress-update-and-redeploy-application.md) + [6단계: WordPress 애플리케이션 및 관련 리소스 정리](tutorials-wordpress-clean-up.md) # 1단계: Amazon Linux 또는 Red Hat Enterprise Linux Amazon EC2 인스턴스 시작 및 구성 CodeDeploy를 사용하여 WordPress 애플리케이션을 배포하려면 Amazon Linux 또는 Red Hat Enterprise Linux(RHEL)를 실행하는 Amazon EC2 인스턴스가 필요합니다. Amazon EC2 인스턴스에는 HTTP 연결을 허용하는 새로운 인바운드 보안 규칙이 필요합니다. 이 규칙은 애플리케이션이 성공적으로 배포된 후 브라우저에서 WordPress 페이지를 보기 위해 필요합니다. [CodeDeploy를 위한 Amazon EC2 인스턴스 생성](instances-ec2-create.md)의 지침을 따르세요. 인스턴스에 Amazon EC2 인스턴스 태그 할당 지침을 수행한 경우 태그 키로 **Name**, 태그 값으로 **CodeDeployDemo**가 지정되어 있어야 합니다. 태그 키 또는 태그 값을 다르게 지정한 경우 [4단계: WordPress 애플리케이션 배포](tutorials-wordpress-deploy-application.md)의 지침을 따르면 예기치 않은 결과가 발생할 수 있습니다. 지침에 따라 Amazon EC2 인스턴스를 시작한 후에는 이 페이지로 돌아와 계속해서 다음 단원으로 진행합니다. 다음 단계로 [CodeDeploy를 사용하여 애플리케이션 생성](applications-create.md) 단원을 진행하지 마세요. ## Amazon Linux 또는 RHEL Amazon EC2 인스턴스에 연결 새 Amazon EC2 인스턴스 시작 후 다음 지침에 따라 해당 인스턴스에 연결하는 연습을 합니다. 1. **ssh** 명령(또는 [PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html)와 같이 SSH를 지원하는 터미널 에뮬레이터)을 사용하여 Amazon Linux 또는 RHEL Amazon EC2 인스턴스에 연결하세요. Amazon EC2 인스턴스를 시작할 때 사용한 키 페어의 프라이빗 키와 인스턴스의 퍼블릭 DNS 주소가 필요합니다. 자세한 내용은 [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html)을 참조하세요. 예를 들어 퍼블릭 DNS 주소가 **ec2-01-234-567-890.compute-1.amazonaws.com**이고, SSH 액세스를 위한 Amazon EC2 인스턴스 키 페어 이름이 **codedeploydemo.pem**인 경우, 다음을 입력하세요. ``` ssh -i /path/to/codedeploydemo.pem ec2-user@ec2-01-234-567-890.compute-1.amazonaws.com ``` `/path/to/codedeploydemo.pem`을(를) `.pem` 파일의 경로로 바꾸고, 예제 DNS 주소를 Amazon Linux 또는 RHEL Amazon EC2 인스턴스에 대한 주소로 바꾸세요. **참고** 키 파일의 권한이 너무 개방되었다는 오류가 표시되면, 현재 사용자에게만 액세스를 부여하도록 권한을 제한해야 합니다. 예를 들어, Linux, macOS 또는 Unix에서 **chmod** 명령을 사용하는 경우 다음을 입력합니다. ``` chmod 400 /path/to/codedeploydemo.pem ``` 1. 로그인하면 Amazon EC2 인스턴스에 대한 AMI 배너가 표시됩니다. Amazon Linux의 경우 다음과 같아야 합니다. ``` __| __|_ ) _| ( / Amazon Linux AMI ___|\___|___| ``` 1. 이제 실행 중인 Amazon EC2 인스턴스에서 로그아웃할 수 있습니다. **주의** Amazon EC2 인스턴스를 중지하거나 종료하지 마세요. 인스턴스를 중지하거나 종료할 경우 CodeDeploy가 인스턴스에 배포할 수 없습니다. ## Amazon Linux 또는 RHEL Amazon EC2 인스턴스에 HTTP 트래픽을 허용하는 인바운드 규칙 추가 다음 단계에서는 배포된 WordPress 애플리케이션의 홈 페이지를 브라우저에서 볼 수 있도록 Amazon EC2 인스턴스에 열린 HTTP 포트가 있는지 확인합니다. 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) Amazon EC2 콘솔을 엽니다. 1. **인스턴스**를 선택한 후 인스턴스를 선택합니다. 1. **설명** 탭의 **보안 그룹**에서 **인바운드 규칙 보기**를 선택합니다. 보안 그룹에 다음과 같은 규칙 목록이 있어야 합니다. ``` Security Groups associated with i-1234567890abcdef0 Ports Protocol Source launch-wizard-N 22 tcp 0.0.0.0/0 ✔ ``` 1. **보안 그룹**에서 Amazon EC2 인스턴스를 위한 보안 그룹을 선택합니다. 이름은 **launch-wizard-*N***이 될 수 있습니다. 이름의 ***N***은 인스턴스가 생성될 때 보안 그룹에 할당된 번호입니다. **인바운드** 탭을 선택합니다. 인스턴스의 보안 그룹이 올바르게 구성되어 있으면 다음 값이 있는 규칙이 표시되어야 합니다. + **유형**: HTTP + **프로토콜**: TCP + **포트 범위**: 80 + **소스**: 0.0.0.0/0 1. 이러한 값이 있는 규칙이 없는 경우 [보안 그룹에 규칙 추가](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule)의 절차를 사용하여 해당 값을 새 보안 규칙에 추가하세요. # 2단계: Amazon Linux 또는 Red Hat Enterprise Linux Amazon EC2 인스턴스에 배포할 원본 콘텐츠 구성 이제 인스턴스에 배포할 항목이 있도록 애플리케이션의 원본 콘텐츠를 구성해야 합니다. **Topics** + [소스 코드 가져오기](#tutorials-wordpress-configure-content-download-code) + [애플리케이션을 실행하기 위한 스크립트 만들기](#tutorials-wordpress-configure-content-create-scripts) + [애플리케이션 사양 파일 추가](#tutorials-wordpress-configure-content-add-appspec-file) ## 소스 코드 가져오기 이 튜토리얼에서는 개발 시스템에서 대상 Amazon EC2 인스턴스로 WordPress 콘텐츠 게시 플랫폼을 배포합니다. WordPress 소스 코드를 얻으려면 기본 제공 명령줄 호출을 사용할 수 있습니다. 또는 Git이 개발 컴퓨터에 설치되어있는 경우 대신 사용할 수 있습니다. 이 단계를 위해, WordPress 소스 코드의 복사본을 개발 머신의 `/tmp` 디렉터리로 다운로드할 수 있다고 가정합니다. (원하는 디렉터리를 선택할 수 있지만 이 단계에서 지정되는 모든 곳에서 위치를 `/tmp`로 바꿔야 합니다.) WordPress 소스 파일을 개발 컴퓨터에 복사하려면 다음 두 가지 옵션 중 하나를 선택합니다. 첫 번째 옵션은 기본 제공 명령줄 호출을 사용합니다. 두 번째 옵션은 Git를 사용합니다. **Topics** + [WordPress 소스 코드의 복사본을 얻으려면(기본 제공 명령줄 호출)](#tutorials-wordpress-configure-content-download-code-command-line) + [WordPress 소스 코드의 복사본을 얻으려면(Git)](#tutorials-wordpress-configure-content-download-code-git) ### WordPress 소스 코드의 복사본을 얻으려면(기본 제공 명령줄 호출) 1. **wget** 명령을 호출하여 WordPress 소스 코드의 복사본을.zip 파일로 현재 디렉터리에 다운로드합니다. ``` wget https://github.com/WordPress/WordPress/archive/master.zip ``` 1. **unzip**, **mkdir**, **cp**, 및 **rm** 명령으르 호출하여 다음을 수행합니다. + `master` .zip 파일을 `/tmp/WordPress_Temp` 디렉터리(폴더)에서 압축을 풉니다. + 압축이 풀린 내용을 `/tmp/WordPress` 대상 폴더에 복사합니다. + 임시 `/tmp/WordPress_Temp` 폴더 및 `master` 파일을 삭제합니다. 명령을 한 번에 하나씩 실행합니다. ``` unzip master -d /tmp/WordPress_Temp ``` ``` mkdir -p /tmp/WordPress ``` ``` cp -paf /tmp/WordPress_Temp/WordPress-master/* /tmp/WordPress ``` ``` rm -rf /tmp/WordPress_Temp ``` ``` rm -f master ``` 이렇게 하면 `/tmp/WordPress` 폴더에 깨끗한 WordPress 소스 코드 파일 세트가 남게 됩니다. ### WordPress 소스 코드의 복사본을 얻으려면(Git) 1. 개발 머신에 [Git](http://git-scm.com)를 다운로드하고 설치합니다. 1. `/tmp/WordPress` 폴더에서 **git init** 명령을 호출합니다. 1. **git clone** 명령을 호출하여 공용 WordPress 리포지토리를 복제하고 `/tmp/WordPress` 대상 폴더에 자신만의 복사본을 만듭니다. ``` git clone https://github.com/WordPress/WordPress.git /tmp/WordPress ``` 이렇게 하면 `/tmp/WordPress` 폴더에 깨끗한 WordPress 소스 코드 파일 세트가 남게 됩니다. ## 애플리케이션을 실행하기 위한 스크립트 만들기 그런 다음 디렉터리에 폴더와 스크립트를 만듭니다. CodeDeploy는 이러한 스크립트를 사용하여 대상 Amazon EC2 인스턴스에 애플리케이션 수정 버전을 설정하고 배포합니다. 어떤 텍스트 편집기든 사용하여 스크립트를 생성할 수 있습니다. 1. WordPress 소스 코드의 복사본에 스크립트 디렉터리를 만듭니다. ``` mkdir -p /tmp/WordPress/scripts ``` 1. `/tmp/WordPress/scripts`에 `install_dependencies.sh` 파일을 생성합니다. 파일에 다음 줄을 추가합니다. 이 `install_dependencies.sh` 스크립트는 Apache, MySQL, PHP를 설치합니다. 또한 PHP에 MySQL 지원을 추가합니다. ``` #!/bin/bash sudo amazon-linux-extras install php7.4 sudo yum install -y httpd mariadb-server php ``` 1. `/tmp/WordPress/scripts`에 `start_server.sh` 파일을 생성합니다. 파일에 다음 줄을 추가합니다. 이 `start_server.sh` 스크립트는 Apache와 MySQL을 시작합니다. ``` #!/bin/bash systemctl start mariadb.service systemctl start httpd.service systemctl start php-fpm.service ``` 1. `/tmp/WordPress/scripts`에 `stop_server.sh` 파일을 생성합니다. 파일에 다음 줄을 추가합니다. 이 `stop_server.sh` 스크립트는 Apache와 MySQL을 중지합니다. ``` #!/bin/bash isExistApp="pgrep httpd" if [[ -n $isExistApp ]]; then systemctl stop httpd.service fi isExistApp=pgrep mysqld if [[ -n $isExistApp ]]; then systemctl stop mariadb.service fi isExistApp=pgrep php-fpm if [[ -n $isExistApp ]]; then systemctl stop php-fpm.service fi ``` 1. `/tmp/WordPress/scripts`에 `create_test_db.sh` 파일을 생성합니다. 파일에 다음 줄을 추가합니다. 이 `create_test_db.sh`스크립트는 MySQL을 사용하여 WordPress가 사용할 **test** 데이터베이스를 만듭니다. ``` #!/bin/bash mysql -uroot < 다음으로, CodeDeploy 에서 사용하는 [YAML](http://www.yaml.org) 형식 파일인 애플리케이션 사양 파일(AppSpec 파일)을 추가하여 다음을 수행합니다. + 애플리케이션 수정 버전의 소스 파일을 Amazon EC2 인스턴스의 대상으로 매핑합니다. + 배포된 파일에 대한 사용자 정의 권한을 지정합니다. + 배포 중에 대상 Amazon EC2 인스턴스에서 실행할 스크립트를 지정합니다. AppSpec 파일의 이름은 `appspec.yml`이어야 합니다. 애플리케이션 소스 코드의 루트 폴더에 있어야 합니다. 이 튜토리얼에서 루트 디렉토리는 `/tmp/WordPress`입니다. 텍스트 편집기에서 `appspec.yml`(이)라는 파일을 만듭니다. 파일에 다음 줄을 추가합니다. ``` version: 0.0 os: linux files: - source: / destination: /var/www/html/WordPress hooks: BeforeInstall: - location: scripts/install_dependencies.sh timeout: 300 runas: root AfterInstall: - location: scripts/change_permissions.sh timeout: 300 runas: root ApplicationStart: - location: scripts/start_server.sh - location: scripts/create_test_db.sh timeout: 300 runas: root ApplicationStop: - location: scripts/stop_server.sh timeout: 300 runas: root ``` CodeDeploy는 이 AppSpec 파일을 사용하여 개발 시스템에 있는 `/tmp/WordPress` 폴더의 모든 파일을 대상 Amazon EC2 인스턴스의 `/var/www/html/WordPress` 폴더 복사합니다. 배포하는 동안 CodeDeploy는 지정된 스크립트를 배포 수명 주기 동안 지정된 이벤트(예:**BeforeInstall** 및 **AfterInstall**)에서 대상 Amazon EC2 인스턴스에 있는 `/var/www/html/WordPress/scripts` 폴더에서 `root`(으)로 실행합니다. 스크립트를 실행하는 데 300초(5분) 이상 걸리면 CodeDeploy는 배포를 중지하고 배포를 실패로 표시합니다. 이러한 설정에 대한 자세한 정보는 [CodeDeploy AppSpec 파일 참조](reference-appspec-file.md) 단원을 참조하세요. **중요** 이 파일에 있는 각 항목 사이의 공백 위치와 개수는 중요합니다. 공백이 올바르지 않으면 CodeDeploy는 디버깅하기 어려운 오류를 발생시킵니다. 자세한 내용은 [AppSpec 파일 간격](reference-appspec-file.md#reference-appspec-file-spacing) 단원을 참조하십시오. # 3단계: WordPress 애플리케이션을 Amazon S3에 업로드 이제 CodeDeploy가 배포할 수 있는 위치에 소스 콘텐츠를 준비하고 업로드합니다. 다음 지침은 Amazon S3 버킷을 프로비저닝하고, 버킷에 대한 애플리케이션 수정 버전 파일을 준비하고, 수정 버전의 파일을 번들로 묶은 다음, 버전을 버킷에 푸시하는 방법을 보여 줍니다. **참고** 이 튜토리얼에서 다루지 않지만 CodeDeploy를 사용하여 애플리케이션을 GitHub 리포지토리에서 인스턴스로 배포할 수 있습니다. 자세한 내용은 [GitHub와 CodeDeploy 통합](integrations-partners-github.md) 단원을 참조하세요. **Topics** + [Amazon S3 버킷 프로비저닝](#tutorials-wordpress-upload-application-create-s3-bucket) + [버킷에 대한 애플리케이션 파일 준비](#tutorials-wordpress-upload-application-prepare-application-files) + [애플리케이션의 파일을 단일 아카이브 파일로 묶고 아카이브 파일을 푸시합니다.](#tutorials-wordpress-upload-application-bundle-and-push-archive) ## Amazon S3 버킷 프로비저닝 스토리지 컨테이너 또는 Amazon S3의 *버킷*을 만듭니다(또는 기존 버킷 사용). 버킷에 수정 버전을 업로드할 수 있는지, 배포에 사용된 Amazon EC2 인스턴스가 버킷에서 수정 버전을 다운로드할 수 있는지 확인합니다. AWS CLI, Amazon S3 콘솔 또는 Amazon S3 APIs를 사용하여 Amazon S3 버킷을 생성할 수 있습니다. 버킷을 생성한 후에는 버킷과 AWS 계정에 액세스 권한을 부여해야 합니다. **참고** 버킷 이름은 모든 AWS 계정의 Amazon S3에서 고유해야 합니다. **amzn-s3-demo-bucket**을(를) 사용할 수 없는 경우, 다른 버킷 이름(예: **amzn-s3-demo-bucket** 뒤에 대시와 이니셜 또는 다른 고유 식별자가 옴)을 사용하세요. 그런 다음 이 자습서 전체에서 버킷 이름을 **amzn-s3-demo-bucket**(으)로 대체해야 합니다. 대상 Amazon EC2 인스턴스가 시작되는 리전과 동일한 리전에서 Amazon S3 버킷을 생성해야 합니다. AWS Amazon EC2 예를 들어 버킷을 미국 동부(버지니아) 리전에 생성한 경우 대상 Amazon EC2 인스턴스를 미국 동부(버지니아 북부) 리전에서 시작해야 합니다. **Topics** + [Amazon S3 버킷을 생성하려면(CLI)](#tutorials-wordpress-upload-application-create-s3-bucket-cli) + [Amazon S3 버킷을 생성하려면(콘솔)](#tutorials-wordpress-upload-application-create-s3-bucket-console) + [Amazon S3 버킷 및 AWS 계정에 권한 부여](#tutorials-wordpress-upload-application-create-s3-bucket-grant-permissions) ### Amazon S3 버킷을 생성하려면(CLI) **mb** 명령을 호출하여 이름이 **amzn-s3-demo-bucket**인 Amazon S3 버킷을 생성합니다. ``` aws s3 mb s3://amzn-s3-demo-bucket --region region ``` ### Amazon S3 버킷을 생성하려면(콘솔) 1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다. 1. Amazon S3; 콘솔에서 **버킷 생성**을 선택합니다. 1. **버킷 이름** 상자에서 버킷의 이름을 입력합니다. 1. **리전** 목록에서 대상 리전을 선택한 후 **생성**을 선택합니다. ### Amazon S3 버킷 및 AWS 계정에 권한 부여 또한 Amazon S3 버킷으로 업로드할 수 있는 권한이 있어야 합니다. Amazon S3 버킷 정책을 통해 이러한 권한을 지정할 수 있습니다. 예를 들어 다음 Amazon S3 버킷 정책에서 와일드카드 문자(\$1)를 사용하면 AWS 계정이 라는 Amazon S3 버킷의 모든 디렉터리에 파일을 `111122223333` 업로드할 수 있습니다`amzn-s3-demo-bucket`. ``` { "Statement": [ { "Action": [ "s3:PutObject" ], "Effect": "Allow", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Principal": { "AWS": [ "111122223333" ] } } ] } ``` AWS 계정 ID를 보려면 [AWS 계정 ID 찾기를 참조하세요](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html#FindingYourAWSId). 이제 Amazon S3 버킷이 참여하는 각 Amazon EC2 인스턴스에서 다운로드 요청을 허용하는지 확인하는 것이 좋습니다. Amazon S3 버킷 정책을 통해 이를 지정할 수 있습니다. 예를 들어, 다음 Amazon S3 버킷 정책에서 와일드카드 문자(\$1)를 사용하면 `arn:aws:iam::444455556666:role/CodeDeployDemo` ARN이 포함된 IAM 인스턴스 프로파일이 연결된 Amazon EC2 인스턴스가 이름이 `amzn-s3-demo-bucket`인 Amazon S3 버킷의 디렉터리에서 파일을 다운로드할 수 있습니다. ``` { "Statement": [ { "Action": [ "s3:Get*", "s3:List*" ], "Effect": "Allow", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Principal": { "AWS": [ "arn:aws:iam::444455556666:role/CodeDeployDemo" ] } } ] } ``` Amazon S3 버킷 정책 생성 및 연결에 대한 자세한 내용은 [버킷 정책 예제](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html)를 참조하세요. IAM 정책을 만들고 연결하는 방법은 [정책 작업](https://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingPolicies.html#AddingPermissions_Console)을 참조하세요. ## 버킷에 대한 애플리케이션 파일 준비 WordPress 애플리케이션 파일, AppSpec 파일 및 스크립트가 개발 컴퓨터에서 다음과 같이 구성되어 있는지 확인하세요. ``` /tmp/ |--WordPress/ |-- appspec.yml |-- scripts/ | |-- change_permissions.sh | |-- create_test_db.sh | |-- install_dependencies.sh | |-- start_server.sh | |-- stop_server.sh |-- wp-admin/ | |-- (various files...) |-- wp-content/ | |-- (various files...) |-- wp-includes/ | |-- (various files...) |-- index.php |-- license.txt |-- readme.html |-- (various files ending with .php...) ``` ## 애플리케이션의 파일을 단일 아카이브 파일로 묶고 아카이브 파일을 푸시합니다. WordPress 애플리케이션 파일과 AppSpec 파일을 아카이브 파일(애플리케이션 *수정 버전*이라고도 함)로 번들링합니다. **참고** 객체를 버킷에 저장하거나 애플리케이션 수정 버전을 버킷으로 전송한 경우 요금이 부과될 수 있습니다. 자세한 내용은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요. 1. 개발 컴퓨터에서 파일이 저장된 폴더로 전환하세요. ``` cd /tmp/WordPress ``` **참고** 이 폴더로 전환하지 않으면 현재 폴더에서 파일 번들링이 시작됩니다. 예를 들어 현재 폴더가 `/tmp/WordPress` 대신 `/tmp`이면 `tmp` 폴더의 파일 및 하위 폴더로 번들링이 시작되어 `WordPress` 하위 폴더보다 더 많은 폴더를 포함할 수 있습니다. 1. **create-application** 명령을 호출하여 이름이 **WordPress\$1App**인 새 애플리케이션을 등록합니다. ``` aws deploy create-application --application-name WordPress_App ``` 1. CodeDeploy [push](https://docs.aws.amazon.com/cli/latest/reference/deploy/push.html) 명령을 호출하여 파일을 묶고, 수정 버전을 Amazon S3로 업로드하고, 업로드된 수정 버전에 대한 정보를 CodeDeploy에 등록할 수 있습니다. 이 모든 작업을 한 번에 수행할 수 있습니다. ``` aws deploy push \ --application-name WordPress_App \ --s3-location s3://amzn-s3-demo-bucket/WordPressApp.zip \ --ignore-hidden-files ``` 이 명령은 현재 디렉터리의 파일(숨겨진 파일 제외)을 단일 아카이브 파일(이름: **WordPressApp.zip**)로 번들링하고 수정 버전을 **amzn-s3-demo-bucket** 버킷에 업로드하고 업로드된 수정 버전에 대한 정보를 CodeDeploy에 등록합니다. # 4단계: WordPress 애플리케이션 배포 이제 Amazon S3에 업로드한 샘플 WordPress 애플리케이션 수정 버전을 배포합니다. AWS CLI 또는 CodeDeploy 콘솔을 사용하여 개정을 배포하고 배포 진행 상황을 모니터링할 수 있습니다. 애플리케이션 수정 배포에 성공한 후에는 결과를 확인합니다. **Topics** + [CodeDeploy로 애플리케이션 수정 버전 배포](#tutorials-wordpress-deploy-application-create-deployment) + [배포 모니터링 및 문제 해결](#tutorials-wordpress-deploy-application-monitor) + [배포 확인](#tutorials-wordpress-deploy-application-verify-deployment) ## CodeDeploy로 애플리케이션 수정 버전 배포 AWS CLI 또는 콘솔을 사용하여 애플리케이션 개정을 배포합니다. **Topics** + [애플리케이션 수정을 배포하려면(CLI)](#tutorials-wordpress-deploy-application-create-deployment-cli) + [애플리케이션 수정을 배포하려면(콘솔)](#tutorials-wordpress-deploy-application-create-deployment-console) ### 애플리케이션 수정을 배포하려면(CLI) 1. 배포에는 배포 그룹이 필요합니다. 그러나 배포 그룹을 만들기 전에 서비스 역할 ARN이 필요합니다. 서비스 역할은 서비스에 사용자를 대신할 수 있는 권한을 부여하는 IAM 역할입니다. 이 경우에 서비스 역할은 CodeDeploy에 Amazon EC2 인스턴스에 액세스하여 Amazon EC2 인스턴스 태그를 확장할(읽을) 수 있는 권한을 부여합니다. [서비스 역할 생성(CLI)](getting-started-create-service-role.md#getting-started-create-service-role-cli)의 지침에 따라 앞에서 서비스 역할을 생성했습니다. 서비스 역할의 ARN을 확인하려면 [서비스 역할 ARN 확인(CLI)](getting-started-create-service-role.md#getting-started-get-service-role-cli) 단원을 참조하세요. 1. 이제 ARN이 있으므로 **create-deployment-group** 명령을 호출하고, **CodeDeployDemo**(이)라는 Amazon EC2 인스턴스와 **CodeDeployDefault.OneAtATime**(이)라는 배포 구성을 사용하여 **WordPress\$1App**(이)라는 애플리케이션과 연결된 **WordPress\$1DepGroup**(이)라는 배포 그룹을 만듭니다. ``` aws deploy create-deployment-group \ --application-name WordPress_App \ --deployment-group-name WordPress_DepGroup \ --deployment-config-name CodeDeployDefault.OneAtATime \ --ec2-tag-filters Key=Name,Value=CodeDeployDemo,Type=KEY_AND_VALUE \ --service-role-arn serviceRoleARN ``` **참고** [create-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment-group.html) 명령은 배포 및 인스턴스의 지정된 이벤트에 대해 주제의 구독자에게 Amazon SNS 알림을 전송하게 하는 트리거를 생성합니다. 또한 해당 명령은 Amazon CloudWatch 경보 모니터링 임계값에 도달한 경우 자동으로 배포를 롤백하고 배포를 중지하도록 경보를 설정하는 옵션을 지원합니다. 이 작업에 대한 명령은 이 자습서에 포함되지 않습니다. 1. 배포를 만들기 전에 배포 그룹의 인스턴스에 CodeDeploy 에이전트가 설치되어 있어야 합니다. AWS Systems Manager 를 사용하여 명령줄에서 다음 명령으로 에이전트를 설치할 수 있습니다. ``` aws ssm create-association \ --name AWS-ConfigureAWSPackage \ --targets Key=tag:Name,Values=CodeDeployDemo \ --parameters action=Install,name=AWSCodeDeployAgent \ --schedule-expression "cron(0 2 ? * SUN *)" ``` 이 명령은 Systems Manager 상태 관리자에 연결을 생성하여 CodeDeploy 에이전트를 설치하고 매주 일요일 오전 2시에 업데이트를 시도합니다. CodeDeploy 에이전트에 대한 자세한 내용은 [CodeDeploy 에이전트 작업](https://docs.aws.amazon.com/codedeploy/latest/userguide/codedeploy-agent.html)을 참조하세요. Systems Manager에 대한 자세한 내용은 [AWS Systems Manager란 무엇입니까](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)를 참조하세요. 1. 이제 **create-deployment** 명령을 호출하고 **WordPress\$1App**이라는 버킷에 있는 **CodeDeployDefault.OneAtATime**이라는 애플리케이션 수정을 사용하여 **WordPress\$1DepGroup**이라는 애플리케이션, **WordPressApp.zip**이라는 배포 구성 및 **amzn-s3-demo-bucket**이라는 배포 그룹과 연결된 배포를 만듭니다. ``` aws deploy create-deployment \ --application-name WordPress_App \ --deployment-config-name CodeDeployDefault.OneAtATime \ --deployment-group-name WordPress_DepGroup \ --s3-location bucket=amzn-s3-demo-bucket,bundleType=zip,key=WordPressApp.zip ``` ### 애플리케이션 수정을 배포하려면(콘솔) 1. CodeDeploy 콘솔을 사용하여 애플리케이션 수정을 배포하기 전에 서비스 역할 ARN이 필요합니다. 서비스 역할은 서비스에 사용자를 대신할 수 있는 권한을 부여하는 IAM 역할입니다. 이 경우에 서비스 역할은 CodeDeploy에 Amazon EC2 인스턴스에 액세스하여 Amazon EC2 인스턴스 태그를 확장할(읽을) 수 있는 권한을 부여합니다. [서비스 역할 생성(콘솔)](getting-started-create-service-role.md#getting-started-create-service-role-console)의 지침에 따라 앞에서 서비스 역할을 생성했습니다. 서비스 역할의 ARN을 확인하려면 [서비스 역할 ARN 확인(콘솔)](getting-started-create-service-role.md#getting-started-get-service-role-console) 단원을 참조하세요. 1. 이제 ARN이 있으므로 CodeDeploy 콘솔을 사용하여 애플리케이션 수정 버전을 배포할 수 있습니다. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/codedeploy](https://console.aws.amazon.com/codedeploy) CodeDeploy 콘솔을 엽니다. **참고** [CodeDeploy 시작하기](getting-started-codedeploy.md)에서 설정한 사용자와 동일한 사용자로 로그인합니다. 1. 탐색 창에서 **배포**를 확장하고 **애플리케이션**을 선택합니다. 1. 애플리케이션 목록에서 **WordPress\$1App**을 선택합니다. 1. **배포 그룹** 탭에서 **Create deployment group(배포 그룹 생성)**을 선택합니다. 1. **Deployment group name(배포 그룹 이름)**에 **WordPress\$1DepGroup**을 입력합니다. 1. **배포 유형** 아래에서 **인 플레이스(In-place) 배포**를 선택합니다. 1. **환경 구성**에서 **Amazon EC2 인스턴스**를 선택합니다. 1. 를 **사용한 에이전트 구성 AWS Systems Manager**에서 기본값을 유지합니다. 1. **키**에 **Name**을(를) 입력합니다. 1. **값**에 **CodeDeployDemo**을(를) 입력합니다. **참고** **CodeDeployDemo**을(를) 입력한 후 CodeDeploy가 일치하는 Amazon EC2 인스턴스를 하나 찾았는지 확인할 수 있도록 **1**이 **일치하는 인스턴스** 아래에 표시되어야 합니다. 1. **배포 구성**에서 **CodeDeployDefault.OneAtATime**을 선택합니다. 1. **서비스 역할 ARN**에서 서비스 역할 ARN을 선택한 후**배포 그룹 생성**을 선택합니다. 1. **배포 만들기**를 선택합니다. 1. **배포 그룹**에서 **WordPress\$1DepGroup**을(를) 선택합니다. 1. **리포지토리 유형** 옆의 **내 애플리케이션이 Amazon S3에 저장되어 있음**을 선택합니다. **수정 버전 위치**에 이전에 Amazon S3에 업로드한 샘플 WordPress 애플리케이션 수정 버전의 위치를 입력합니다. 위치를 가져오려면: 1. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다. 1. 버킷 목록에서 **amzn-s3-demo-bucket**(또는 애플리케이션 수정 버전을 업로드한 버킷 이름)을 선택합니다. 1. 객체 목록에서 **WordPressApp.zip**을 선택합니다. 1. **개요** 탭에서 **링크** 필드의 값을 클립보드에 복사합니다. 값이 다음과 같을 것입니다. **https://s3.amazonaws.com/amzn-s3-demo-bucket/WordPressApp.zip** 1. CodeDeploy 콘솔로 돌아가서 **수정 버전 위치**에 **링크** 필드 값을 붙여 넣습니다. 1. **파일 형식**에서 파일 형식을 찾을 수 없다는 메시지가 표시되는 경우, **.Zip**을 선택합니다. 1. (선택 사항) **배포 설명** 상자에 설명을 입력합니다. 1. **배포 그룹 재정의**를 확장하고 **배포 구성**에서 **CodeDeployDefault.OneAtATime**을 선택합니다. 1. **Start deployment(배포 시작)**를 선택합니다. 새로 만든 배포에 대한 정보가 [**Deployments**] 페이지에 표시됩니다. ## 배포 모니터링 및 문제 해결 AWS CLI 또는 콘솔을 사용하여 배포를 모니터링하고 문제를 해결합니다. **Topics** + [배포를 모니터링하고 문제를 해결하려면(CLI)](#tutorials-wordpress-deploy-application-monitor-cli) + [배포를 모니터링하고 문제를 해결하려면(콘솔)](#tutorials-wordpress-deploy-application-monitor-console) ### 배포를 모니터링하고 문제를 해결하려면(CLI) 1. **WordPress\$1App**이라는 애플리케이션 및 **WordPress\$1DepGroup**이라는 배포 그룹에 대해 **list-deployments** 명령을 호출하여 배포 ID를 가져옵니다. ``` aws deploy list-deployments --application-name WordPress_App --deployment-group-name WordPress_DepGroup --query 'deployments' --output text ``` 1. 배포 ID로 **get-deployment** 명령을 호출합니다. ``` aws deploy get-deployment --deployment-id deploymentID --query 'deploymentInfo.status' --output text ``` 1. 이 명령으로 배포의 전체 상태가 반환됩니다. 성공하면 `Succeeded` 값이 반환됩니다. 전체 상태가 `Failed`이면 [list-deployment-instances](https://docs.aws.amazon.com/cli/latest/reference/deploy/list-deployment-instances.html) 및 [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html)와 같은 명령을 호출하여 문제를 해결할 수 있습니다. 문제 해결 옵션을 더 보려면 [인스턴스에 대한 배포 실패를 조사하기 위해 로그 파일 분석](troubleshooting-ec2-instances.md#troubleshooting-deploy-failures)을 참조하세요. ### 배포를 모니터링하고 문제를 해결하려면(콘솔) CodeDeploy 콘솔의 **배포 ** 페이지에 있는 **상태** 열에서 배포 상태를 모니터링할 수 있습니다. 배포에 대한 자세한 정보를 확인하려면(특히, [**Status**] 열 값이 [**Succeeded**]가 아닌 경우): 1. **배포** 테이블에서 배포 이름을 선택합니다. 배포에 실패하면 실패 원인을 설명하는 메시지가 표시됩니다. 1. **인스턴스 활동**에서 배포에 대한 자세한 정보가 표시됩니다. 배포에 실패한 후 배포에 실패한 Amazon EC2 인스턴스와 해당 단계를 확인할 수 있습니다. 1. 문제 해결을 더 수행해야 할 경우 [CodeDeploy에서 인스턴스 정보 보기](instances-view-details.md)에 설명된 것과 같은 기능을 사용할 수 있습니다. 또한 Amazon EC2 인스턴스의 배포 로그 파일을 분석할 수도 있습니다. 자세한 내용은 [인스턴스에 대한 배포 실패를 조사하기 위해 로그 파일 분석](troubleshooting-ec2-instances.md#troubleshooting-deploy-failures) 단원을 참조하세요. ## 배포 확인 배포에 성공한 후 WordPress 설치가 작동 중인지 확인합니다. Amazon EC2 인스턴스의 퍼블릭 DNS 주소(뒤에 `/WordPress`이 옴)를 사용해 웹 브라우저에서 사이트를 확인합니다. (퍼블릭 DNS 값을 확인하려면 Amazon EC2 콘솔에서 Amazon EC2 인스턴스를 선택하고 **설명** 탭에서 **퍼블릭 DNS**의 값을 찾습니다.) 예를 들어, Amazon EC2 인스턴스의 퍼블릭 DNS 주소가 **ec2-01-234-567-890.compute-1.amazonaws.com**이면 다음 URL을 사용합니다. ``` http://ec2-01-234-567-890.compute-1.amazonaws.com/WordPress ``` 브라우저에서 사이트를 볼 때 다음과 유사한 WordPress 시작 페이지가 표시됩니다. ![\[WordPress 시작 페이지\]](http://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/WordPress-Welcome-Page-013118.png) Amazon EC2 인스턴스에 HTTP 인바운드 규칙이 보안 그룹에 추가되지 않은 경우 WordPress 시작 페이지가 나타나지 않습니다. 원격 서버가 응답하지 않는다는 메시지가 표시되면 Amazon EC2 인스턴스의 보안 그룹에 인바운드 규칙이 있는지 확인합니다. 자세한 내용은 [Amazon Linux 또는 RHEL Amazon EC2 인스턴스에 HTTP 트래픽을 허용하는 인바운드 규칙 추가Windows Server Amazon EC2 인스턴스에 HTTP 트래픽을 허용하는 인바운드 규칙 추가](tutorials-wordpress-launch-instance.md#tutorials-wordpress-launch-instance-add-inbound-rule) 단원을 참조하십시오. # 5단계: WordPress 애플리케이션 업데이트 및 재배포 이제 애플리케이션 수정 버전을 배포했으므로 개발 컴퓨터에서 WordPress의 코드를 업데이트한 다음 CodeDeploy를 사용하여 사이트를 다시 배포합니다. 그런 다음 Amazon EC2 인스턴스에서 코드 변경 사항을 확인해야 합니다. **Topics** + [WordPress 사이트 설정](#tutorials-wordpress-update-and-redeploy-application-configure-and-install) + [사이트 수정](#tutorials-wordpress-update-and-redeploy-application-modify-code) + [사이트 재배포](#tutorials-wordpress-update-and-redeploy-application-deploy-updates) ## WordPress 사이트 설정 코드 변경의 효과를 보려면 완전한 기능을 설치할 수 있도록 WordPress 사이트 설정을 완료하세요. 1. 웹 브라우저에 사이트 URL을 입력합니다. URL은 Amazon EC2 인스턴스의 퍼블릭 DNS 주소에 `/WordPress` 확장자를 더한 것입니다. 이 예제 WordPress 사이트(예: Amazon EC2 인스턴스 퍼블릭 DNS 주소)의 경우 URL은 **http://ec2-01-234-567-890.compute-1.amazonaws.com/WordPress**입니다. 1. 사이트를 아직 설정하지 않은 경우 WordPress 기본 시작 페이지가 나타납니다. **Let's go\$1**를 선택합니다. 1. 기본 MySQL 데이터베이스를 사용하려면 데이터베이스 구성 페이지에서 다음 값을 입력합니다. + **데이터베이스 이름**: **test** + **사용자 이름**: **root** + **암호**: 비워 둠 + **데이터베이스 호스트**: **localhost** + **테이블 접두사**: **wp\$1** **제출**을 선택하여 데이터베이스를 설정합니다. 1. 사이트 설정을 계속합니다. **시작** 페이지에서 원하는 값을 입력하고 **WordPress 설치**를 선택합니다. 설치가 완료되면 대시보드에 로그인할 수 있습니다. **중요** WordPress 애플리케이션을 배포하는 동안 **change\$1permissions.sh** 스크립트가 `/tmp/WordPress` 폴더의 사용 권한을 업데이트하여 누구나 쓸 수 있습니다. 이제 소유자만 쓸 수 있도록 다음 명령을 실행하여 사용 권한을 제한하는 것이 좋습니다. ``` chmod -R 755 /var/www/html/WordPress ``` ## 사이트 수정 WordPress 사이트를 수정하려면 개발 컴퓨터의 애플리케이션 폴더로 이동하세요. ``` cd /tmp/WordPress ``` 사이트의 색상 중 일부를 수정하려면 `wp-content/themes/twentyfifteen/style.css` 파일에서 텍스트 편집기 또는 **sed**를 사용하여 `#fff`을(를) `#768331`(으)로 변경합니다. Linux 또는 GNU가 **sed**인 다른 시스템에서에서는 다음을 사용합니다. ``` sed -i 's/#fff/#768331/g' wp-content/themes/twentyfifteen/style.css ``` MacOS, Unix 또는 BSD가 **sed**인 다른 시스템에서에서는 다음을 사용합니다. ``` sed -i '' 's/#fff/#768331/g' wp-content/themes/twentyfifteen/style.css ``` ## 사이트 재배포 사이트의 코드를 수정했으므로 Amazon S3 및 CodeDeploy를 사용하여 사이트를 다시 배포합니다. [애플리케이션의 파일을 단일 아카이브 파일로 묶고 아카이브 파일을 푸시합니다.](tutorials-wordpress-upload-application.md#tutorials-wordpress-upload-application-bundle-and-push-archive)에 설명된 대로 Amazon S3 변경 사항을 번들로 묶어 업로드합니다. (이러한 지침을 따를 때 애플리케이션을 만들 필요가 없다는 것을 기억하세요.) 수정 버전에 이전과 동일한 키(**WordPressApp.zip**)를 지정하세요. 이전에 생성한 것과 동일한 Amazon S3 버킷(예:**amzn-s3-demo-bucket**)에 업로드합니다. AWS CLI, CodeDeploy 콘솔 또는 CodeDeploy APIs를 사용하여 사이트를 재배포합니다. **Topics** + [사이트를 재배포하려면(CLI)](#tutorials-wordpress-update-and-redeploy-application-deploy-updates-cli) + [사이트를 재배포하려면(콘솔)](#tutorials-wordpress-update-and-redeploy-application-deploy-updates-console) ### 사이트를 재배포하려면(CLI) **create-deployment** 명령을 호출하여 새로 업로드한 수정 버전을 기반으로 배포를 만듭니다. **WordPress\$1App**(이)라는 애플리케이션, **CodeDeployDefault.OneAtATime**(이)라는 배포 구성, **WordPress\$1DepGroup**(이)라는 배포 그룹, **amzn-s3-demo-bucket**(이)라는 버킷의 **WordPressApp.zip**(이)라는 수정 버전을 사용합니다. ``` aws deploy create-deployment \ --application-name WordPress_App \ --deployment-config-name CodeDeployDefault.OneAtATime \ --deployment-group-name WordPress_DepGroup \ --s3-location bucket=amzn-s3-demo-bucket,bundleType=zip,key=WordPressApp.zip ``` [배포 모니터링 및 문제 해결](tutorials-wordpress-deploy-application.md#tutorials-wordpress-deploy-application-monitor)에 설명된 대로 배포의 상태를 확인할 수 있습니다. CodeDeploy가 사이트를 재배포한 경우 웹 브라우저에서 사이트를 다시 방문하여 색상이 변경되었는지 확인합니다. (브라우저를 새로 고쳐야 할 수 있습니다.) 색상이 변경되었으면 제대로 수행된 것입니다. 사이트를 성공적으로 수정하고 재배포했습니다\$1 ### 사이트를 재배포하려면(콘솔) 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/codedeploy](https://console.aws.amazon.com/codedeploy) CodeDeploy 콘솔을 엽니다. **참고** [CodeDeploy 시작하기](getting-started-codedeploy.md)에서 설정한 사용자와 동일한 사용자로 로그인합니다. 1. 탐색 창에서 **배포**를 확장하고 **애플리케이션**을 선택합니다. 1. 애플리케이션 목록에서 **WordPress\$1App**을 선택합니다. 1. **배포 그룹** 탭에서 **WordPress\$1DepGroup**을(를) 선택합니다. 1. **배포 만들기**를 선택합니다. 1. **배포 만들기** 페이지에서, 1. **배포 그룹**에서 **WordPress\$1DepGroup**을(를) 선택합니다. 1. **리포지토리 유형** 영역에서 **내 애플리케이션이 Amazon S3에 저장됨**을 선택한 다음 수정 버전의 Amazon S3 링크를 **수정 버전 위치** 상자에 복사합니다. 링크 값을 찾으려면: 1. 별도의 브라우저 탭에서: 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) Amazon S3 콘솔을 엽니다. **amzn-s3-demo-bucket**을 찾아서 열고 수정 버전 **WordPressApp.zip**을 선택합니다. 1. Amazon S3 콘솔에서 **속성** 창이 보이지 않으면, **속성** 버튼을 선택합니다. 1. **속성** 패널에서 **링크** 필드의 값을 CodeDeploy 콘솔의 **수정 버전 위치** 상자로 복사합니다. 1. 파일 형식을 찾을 수 없다는 메시지가 표시되는 경우, **.zip**을 선택합니다. 1. **배포 설명** 상자는 비워 둡니다. 1. **배포 그룹 재정의**를 확장하고 **배포 구성**에서 **CodeDeployDefault.OneAtATime**을 선택합니다. 1. **Start deployment(배포 시작)**를 선택합니다. 새로 만든 배포에 대한 정보가 [**Deployments**] 페이지에 표시됩니다. 1. [배포 모니터링 및 문제 해결](tutorials-wordpress-deploy-application.md#tutorials-wordpress-deploy-application-monitor)에 설명된 대로 배포의 상태를 확인할 수 있습니다. CodeDeploy가 사이트를 재배포한 경우 웹 브라우저에서 사이트를 다시 방문하여 색상이 변경되었는지 확인합니다. (브라우저를 새로 고쳐야 할 수 있습니다.) 색상이 변경되었으면 제대로 수행된 것입니다. 사이트를 성공적으로 수정하고 재배포했습니다\$1 # 6단계: WordPress 애플리케이션 및 관련 리소스 정리 이제 WordPress 코드를 성공적으로 업데이트하고 사이트를 다시 배포했습니다. 이 튜토리얼에서 만든 리소스에 계속해서 비용이 부과되지 않도록 하려면 다음 항목을 삭제해야 합니다. + 모든 CloudFormation 스택(또는 외부에서 생성한 경우 Amazon EC2 인스턴스 종료 CloudFormation). + 모든 Amazon S3 버킷. + CodeDeploy의 `WordPress_App` 애플리케이션. + CodeDeploy 에이전트에 대한 AWS Systems Manager 상태 관리자 연결입니다. AWS CLI, CloudFormation, Amazon S3, Amazon EC2 및 CodeDeploy 콘솔 또는 AWS APIs를 수행할 수 있습니다. **Topics** + [리소스를 정리하려면(CLI)](#tutorials-wordpress-clean-up-cli) + [리소스를 정리하려면(콘솔)](#tutorials-wordpress-clean-up-console) + [다음 단계](#tutorials-wordpress-clean-up-whats-next) ## 리소스를 정리하려면(CLI) 1. 이 자습서에서 CloudFormation 템플릿을 사용한 경우 라는 스택에 대해 **delete-stack** 명령을 호출합니다**CodeDeployDemoStack**. 그러면 함께 제공되는 모든 Amazon EC2 인스턴스가 종료되고 스택에서 생성한 모든 동반 IAM 역할이 삭제됩니다. ``` aws cloudformation delete-stack --stack-name CodeDeployDemoStack ``` 1. Amazon S3 버킷을 삭제하려면 **amzn-s3-demo-bucket**(이)라는 버킷에 대해 **--recursive** 스위치를 사용하여 **rm** 명령을 호출합니다. 버킷을 비롯해 버킷에 있는 모든 객체가 삭제됩니다. ``` aws s3 rm s3://amzn-s3-demo-bucket --recursive --region region ``` 1. `WordPress_App` 애플리케이션을 삭제하려면 **delete-application** 명령을 호출합니다. 이렇게 하면 애플리케이션에 대해 연결된 배포 그룹 레코드와 배포 레코드가 모두 삭제됩니다. ``` aws deploy delete-application --application-name WordPress_App ``` 1. Systems Manager 상태 관리자 연결을 삭제하려면 **delete-association** 명령을 호출합니다. ``` aws ssm delete-association --assocation-id association-id ``` **describe-association** 명령을 호출하여 *association-id*를 얻을 수 있습니다. ``` aws ssm describe-association --name AWS-ConfigureAWSPackage --targets Key=tag:Name,Values=CodeDeployDemo ``` 이 자습서에서 CloudFormation 스택을 사용하지 않은 경우 **terminate-instances** 명령을 호출하여 수동으로 생성한 Amazon EC2 인스턴스를 종료합니다. 종료할 Amazon EC2 인스턴스의 ID를 입력합니다. ``` aws ec2 terminate-instances --instance-ids instanceId ``` ## 리소스를 정리하려면(콘솔) 이 자습서에서 CloudFormation 템플릿을 사용한 경우 연결된 CloudFormation 스택을 삭제합니다. 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) CloudFormation 콘솔을 엽니다. 1. **필터** 상자에 이전에 생성한 CloudFormation 스택 이름(예: )을 입력합니다**CodeDeployDemoStack**. 1. 스택 이름 옆의 상자를 선택합니다. **작업** 메뉴에서 **스택 삭제**를 선택합니다. CloudFormation 는 스택을 삭제하고, 함께 제공되는 모든 Amazon EC2 인스턴스를 종료하고, 함께 제공되는 모든 IAM 역할을 삭제합니다. CloudFormation 스택 외부에서 생성한 Amazon EC2 인스턴스를 종료하려면: 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) Amazon EC2 콘솔을 엽니다. 1. **인스턴스** 목록에서 **인스턴스**를 선택합니다. 1. 검색 상자에 종료할 Amazon EC2 인스턴스의 이름(예: **CodeDeployDemo**)을 입력한 후 Enter를 누릅니다. 1. Amazon EC2 인스턴스의 이름을 선택합니다. 1. [**Actions**] 메뉴에서 [**Instance State**]를 가리킨 다음 [**Terminate**]를 선택합니다. 메시지가 나타나면 [**Yes, Terminate**]를 선택합니다. 인스턴스마다 이들 단계를 반복합니다. Amazon S3 버킷을 삭제하려면 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) Amazon S3 콘솔을 엽니다. 1. 버킷 목록에서 이전에 생성한 Amazon S3 버킷의 이름(예: **amzn-s3-demo-bucket**)을 찾아서 선택합니다. 1. 버킷을 삭제하려면 먼저 버킷의 콘텐츠를 삭제해야 합니다. 버킷에 있는 모든 파일(예: **WordPressApp.zip**)을 선택합니다. **작업** 메뉴에서 **삭제**를 선택합니다. 삭제 확인 메시지가 표시되면 **확인**을 선택합니다. 1. 버킷을 비운 후 버킷을 삭제할 수 있습니다. 버킷 목록에서 버킷 행을 선택합니다(버킷 이름은 아님). **버킷 삭제**를 선택하고 확인하라는 메시지가 나타나면**확인**을 선택합니다. CodeDeploy에서 `WordPress_App` 애플리케이션을 삭제하려면 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/codedeploy](https://console.aws.amazon.com/codedeploy) CodeDeploy 콘솔을 엽니다. **참고** [CodeDeploy 시작하기](getting-started-codedeploy.md)에서 설정한 사용자와 동일한 사용자로 로그인합니다. 1. 탐색 창에서 **배포**를 확장하고 **애플리케이션**을 선택합니다. 1. 애플리케이션 목록에서 **WordPress\$1App**을 선택합니다. 1. **애플리케이션 세부 정보** 페이지에서 **애플리케이션 삭제**를 선택합니다. 1. 메시지가 표시되면 삭제를 확인할 애플리케이션의 이름을 입력한 후 **삭제**를 선택합니다. Systems Manager 상태 관리자 연결을 삭제하려면 1. https://console.aws.amazon.com/systems-manager AWS Systems Manager 콘솔을 엽니다. 1. 탐색 창에서 **상태 관리자**를 선택합니다. 1. 생성한 연결을 선택하고 **삭제**를 선택합니다. ## 다음 단계 축하합니다\$1 CodeDeploy 배포를 성공적으로 완료했고 사이트의 코드를 업데이트하고 다시 배포했습니다.