기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
애플리케이션 생성, 업로드 및 배포
먼저 WordPress 애플리케이션 번들을 생성한 다음 CodeDeploy CTs를 사용하여 애플리케이션을 생성하고 배포합니다.
WordPress를 다운로드하고 파일을 추출한 다음 ./scripts 디렉터리를 생성합니다.
Linux 명령:
wget https://github.com/WordPress/WordPress/archive/master.zipWindows: 브라우저 창에 붙여
https://github.com/WordPress/WordPress/archive/master.zip넣고 zip 파일을 다운로드합니다.패키지를 어셈블할 임시 디렉터리를 생성합니다.
Linux:
mkdir /tmp/WordPressWindows: "WordPress" 디렉터리를 생성합니다. 나중에 디렉터리 경로를 사용합니다.
WordPress 소스를 "WordPress" 디렉터리로 추출하고 ./scripts 디렉터리를 생성합니다.
Linux:
unzip master.zip -d /tmp/WordPress_Temp cp -paf /tmp/WordPress_Temp/WordPress-master/* /tmp/WordPress rm -rf /tmp/WordPress_Temp rm -f master cd /tmp/WordPress mkdir scriptsWindows: 생성한 "WordPress" 디렉터리로 이동하여 여기에 "scripts" 디렉터리를 생성합니다.
Windows 환경에 있는 경우 스크립트 파일의 브레이크 유형을 Unix(LF)로 설정해야 합니다. 메모장 ++에서 창 오른쪽 하단에 있는 옵션입니다.
WordPress 디렉터리에서 CodeDeploy appspec.yml 파일을 생성합니다(예제를 복사하는 경우 들여쓰기를 확인하고 각 공간을 계산합니다). 중요: WordPress 파일(이 경우 WordPress 디렉터리)을 예상 대상(/var/www/html/WordPress)으로 복사하기 위해 "소WordPress" 경로가 올바른지 확인합니다. 예제에서 appspec.yml 파일은 WordPress 파일이 있는 디렉터리에 있으므로 "/"만 있으면 됩니다. 또한 Auto Scaling 그룹에 RHEL AMI를 사용했더라도 "os: linux" 줄을 그대로 둡니다. 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/config_wordpress.sh timeout: 300 runas: root ApplicationStart: - location: scripts/start_server.sh timeout: 300 runas: root ApplicationStop: - location: scripts/stop_server.sh timeout: 300 runas: root-
WordPress ./scripts 디렉터리에서 bash 파일 스크립트를 생성합니다.
먼저 다음 콘텐츠
config_wordpress.sh로를 생성합니다(원하는 경우 wp-config.php 파일을 직접 편집할 수 있음).참고
DBName을 HA 스택 RFC에 지정된 값으로 바꿉니다(예:wordpress).DB_MasterUsername을 HA 스택 RFC에 지정된MasterUsername값으로 바꿉니다(예:admin).DB_MasterUserPassword를 HA 스택 RFC에 지정된MasterUserPassword값으로 바꿉니다(예:p4ssw0rd).DB_ENDPOINT를 HA 스택 RFC의 실행 출력에서 엔드포인트 DNS 이름으로 바꿉니다(예:srt1cz23n45sfg.clgvd67uvydk.us-east-1.rds.amazonaws.com). GetRfc 작업(CLI: get-rfc --rfc-id RFC_ID) 또는 이전에 제출한 HA 스택 RFC의 AMS 콘솔 RFC 세부 정보 페이지에서 이를 찾을 수 있습니다.#!/bin/bash chmod -R 755 /var/www/html/WordPress cp /var/www/html/WordPress/wp-config-sample.php /var/www/html/WordPress/wp-config.php cd /var/www/html/WordPress sed -i "s/database_name_here/DBName/g" wp-config.php sed -i "s/username_here/DB_MasterUsername/g" wp-config.php sed -i "s/password_here/DB_MasterUserPassword/g" wp-config.php sed -i "s/localhost/DB_ENDPOINT/g" wp-config.php 동일한 디렉터리에서 다음 콘텐츠
install_dependencies.sh로를 생성합니다.#!/bin/bash yum install -y php yum install -y php-mysql yum install -y mysql service httpd restart참고
HTTPS는 상태 확인이 처음부터 작동하도록 시작 시 사용자 데이터의 일부로 설치됩니다.
동일한 디렉터리에서 다음 콘텐츠
start_server.sh로를 생성합니다.Amazon Linux 인스턴스의 경우 다음을 사용합니다.
#!/bin/bash service httpd startRHEL 인스턴스의 경우 다음을 사용합니다(추가 명령은 SELINUX가 WordPress를 수락하도록 허용하는 정책임).
#!/bin/bash setsebool -P httpd_can_network_connect_db 1 setsebool -P httpd_can_network_connect 1 chcon -t httpd_sys_rw_content_t /var/www/html/WordPress/wp-content -R restorecon -Rv /var/www/html service httpd start
동일한 디렉터리에서 다음 콘텐츠
stop_server.sh로를 생성합니다.#!/bin/bash service httpd stopzip 번들을 생성합니다.
Linux:
$ cd /tmp/WordPress $ zip -r wordpress.zip .Windows: "WordPress" 디렉터리로 이동하여 모든 파일을 선택하고 zip 파일을 생성합니다. 이름을 wordpress.zip으로 지정해야 합니다.
애플리케이션 번들을 S3 버킷에 업로드합니다.
스택을 계속 배포하려면 번들이 있어야 합니다.
생성한 모든 S3 버킷 인스턴스에 자동으로 액세스할 수 있습니다. Bastion 또는 S3 콘솔을 통해 액세스하고 zip 파일을 drag-and-drop거나 탐색하여 선택하여 WordPress 번들을 업로드할 수 있습니다.
쉘 창에서 다음 명령을 사용할 수도 있습니다. zip 파일의 경로가 올바른지 확인하세요.
aws s3 cp wordpress.zip s3://BUCKET_NAME/WordPress 애플리케이션 번들을 배포합니다.
시작하기 전에 다음 데이터를 수집하면 배포 속도가 빨라집니다.
필수 데이터:
VPC-ID:이 값은 S3 버킷의 위치를 결정합니다. 이전에 사용한 것과 동일한 VPC ID를 사용합니다.CodeDeployApplicationName및CodeDeployApplicationName: HA 2-Tier 스택 RFC에서 사용한ApplicationName값은 CodeDeployApplicationName 및 CodeDeployDeploymentGroupName을 설정합니다. 이 예제에서는 "WordPress"를 사용하지만 다른 값을 사용했을 수 있습니다.S3Location:의 경우 이전에 생성한BucketName를S3Bucket사용합니다.S3BundleType및는 S3 스토어에 배치한 번들S3Key에서 가져온 것입니다.
CodeDeploy 애플리케이션의 실행 파라미터 JSON 스키마를 출력하여 DeployCDAppParams.json.
aws amscm get-change-type-version --change-type-id "ct-2edc3sd1sqmrb" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > DeployCDAppParams.json다음과 같이 스키마를 수정하고 다른 이름으로 저장하면 콘텐츠를 삭제하고 바꿀 수 있습니다.
{ "Description": "DeployWPCDApp", "VpcId": "VPC_ID", "Name": "WordPressCDAppDeploy", "TimeoutInMinutes": 60, "Parameters": { "CodeDeployApplicationName": "WordPress", "CodeDeployDeploymentGroupName": "WordPress", "CodeDeployIgnoreApplicationStopFailures": false, "CodeDeployRevision": { "RevisionType": "S3", "S3Location": { "S3Bucket": "BUCKET_NAME", "S3BundleType": "zip", "S3Key": "wordpress.zip" } } } }CreateRfc용 JSON 템플릿을 DeployCDAppRfc.json:
aws amscm create-rfc --generate-cli-skeleton > DeployCDAppRfc.jsonDeployCDAppRfc.json 파일을 수정하고 저장하면 콘텐츠를 삭제하고 바꿀 수 있습니다. 이제
RequestedStartTime및RequestedEndTime는 선택 사항입니다. 제외하면 승인되는 즉시 실행되는 ASAP RFC가 생성됩니다(일반적으로 자동으로 발생함). 예약된 RFC를 제출하려면 해당 값을 추가합니다.{ "ChangeTypeVersion": "1.0", "ChangeTypeId": "ct-2edc3sd1sqmrb", "Title": "CD-Deploy-For-WP-RFC" }DeployCDAppRfc 파일과 DeployCDAppParams 실행 파라미터 파일을 지정하여 RFC를 생성합니다.
aws amscm create-rfc --cli-input-json file://DeployCDAppRfc.json --execution-parameters file://DeployCDAppParams.json응답에서 새 RFC의 RfcId를 수신합니다. 후속 단계를 위해 ID를 저장합니다.
RFC 제출:
aws amscm submit-rfc --rfc-idRFC_IDRFC가 성공하면 출력이 수신되지 않습니다.
RFC 상태를 확인하려면를 실행합니다.
aws amscm get-rfc --rfc-idRFC_ID