애플리케이션 생성, 업로드 및 배포 - AMS 고급 온보딩 가이드

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

애플리케이션 생성, 업로드 및 배포

먼저 WordPress 애플리케이션 번들을 생성한 다음 CodeDeploy CTs를 사용하여 애플리케이션을 생성하고 배포합니다.

  1. WordPress를 다운로드하고 파일을 추출한 다음 ./scripts 디렉터리를 생성합니다.

    Linux 명령:

    wget https://github.com/WordPress/WordPress/archive/master.zip

    Windows: 브라우저 창에 붙여https://github.com/WordPress/WordPress/archive/master.zip넣고 zip 파일을 다운로드합니다.

    패키지를 어셈블할 임시 디렉터리를 생성합니다.

    Linux:

    mkdir /tmp/WordPress

    Windows: "WordPress" 디렉터리를 생성합니다. 나중에 디렉터리 경로를 사용합니다.

  2. 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 scripts

    Windows: 생성한 "WordPress" 디렉터리로 이동하여 여기에 "scripts" 디렉터리를 생성합니다.

    Windows 환경에 있는 경우 스크립트 파일의 브레이크 유형을 Unix(LF)로 설정해야 합니다. 메모장 ++에서 창 오른쪽 하단에 있는 옵션입니다.

  3. 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
  4. 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
  5. 동일한 디렉터리에서 다음 콘텐츠install_dependencies.sh로를 생성합니다.

    #!/bin/bash yum install -y php yum install -y php-mysql yum install -y mysql service httpd restart
    참고

    HTTPS는 상태 확인이 처음부터 작동하도록 시작 시 사용자 데이터의 일부로 설치됩니다.

  6. 동일한 디렉터리에서 다음 콘텐츠start_server.sh로를 생성합니다.

    • Amazon Linux 인스턴스의 경우 다음을 사용합니다.

      #!/bin/bash service httpd start
    • RHEL 인스턴스의 경우 다음을 사용합니다(추가 명령은 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
  7. 동일한 디렉터리에서 다음 콘텐츠stop_server.sh로를 생성합니다.

    #!/bin/bash service httpd stop
  8. zip 번들을 생성합니다.

    Linux:

    $ cd /tmp/WordPress $ zip -r wordpress.zip .

    Windows: "WordPress" 디렉터리로 이동하여 모든 파일을 선택하고 zip 파일을 생성합니다. 이름을 wordpress.zip으로 지정해야 합니다.

  1. 애플리케이션 번들을 S3 버킷에 업로드합니다.

    스택을 계속 배포하려면 번들이 있어야 합니다.

    생성한 모든 S3 버킷 인스턴스에 자동으로 액세스할 수 있습니다. Bastion 또는 S3 콘솔을 통해 액세스하고 zip 파일을 drag-and-drop거나 탐색하여 선택하여 WordPress 번들을 업로드할 수 있습니다.

    쉘 창에서 다음 명령을 사용할 수도 있습니다. zip 파일의 경로가 올바른지 확인하세요.

    aws s3 cp wordpress.zip s3://BUCKET_NAME/
  2. WordPress 애플리케이션 번들을 배포합니다.

    시작하기 전에 다음 데이터를 수집하면 배포 속도가 빨라집니다.

    필수 데이터:

    • VPC-ID:이 값은 S3 버킷의 위치를 결정합니다. 이전에 사용한 것과 동일한 VPC ID를 사용합니다.

    • CodeDeployApplicationNameCodeDeployApplicationName: HA 2-Tier 스택 RFC에서 사용한 ApplicationName 값은 CodeDeployApplicationName 및 CodeDeployDeploymentGroupName을 설정합니다. 이 예제에서는 "WordPress"를 사용하지만 다른 값을 사용했을 수 있습니다.

    • S3Location:의 경우 이전에 생성한 BucketNameS3Bucket사용합니다. S3BundleType 및는 S3 스토어에 배치한 번들S3Key에서 가져온 것입니다.

    1. CodeDeploy 애플리케이션의 실행 파라미터 JSON 스키마를 출력하여 DeployCDAppParams.json.

      aws amscm get-change-type-version --change-type-id "ct-2edc3sd1sqmrb" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > DeployCDAppParams.json
    2. 다음과 같이 스키마를 수정하고 다른 이름으로 저장하면 콘텐츠를 삭제하고 바꿀 수 있습니다.

      { "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" } } } }
    3. CreateRfc용 JSON 템플릿을 DeployCDAppRfc.json:

      aws amscm create-rfc --generate-cli-skeleton > DeployCDAppRfc.json
    4. DeployCDAppRfc.json 파일을 수정하고 저장하면 콘텐츠를 삭제하고 바꿀 수 있습니다. 이제 RequestedStartTimeRequestedEndTime는 선택 사항입니다. 제외하면 승인되는 즉시 실행되는 ASAP RFC가 생성됩니다(일반적으로 자동으로 발생함). 예약된 RFC를 제출하려면 해당 값을 추가합니다.

      { "ChangeTypeVersion": "1.0", "ChangeTypeId": "ct-2edc3sd1sqmrb", "Title": "CD-Deploy-For-WP-RFC" }
    5. DeployCDAppRfc 파일과 DeployCDAppParams 실행 파라미터 파일을 지정하여 RFC를 생성합니다.

      aws amscm create-rfc --cli-input-json file://DeployCDAppRfc.json --execution-parameters file://DeployCDAppParams.json

      응답에서 새 RFC의 RfcId를 수신합니다. 후속 단계를 위해 ID를 저장합니다.

    6. RFC 제출:

      aws amscm submit-rfc --rfc-id RFC_ID

      RFC가 성공하면 출력이 수신되지 않습니다.

    7. RFC 상태를 확인하려면를 실행합니다.

      aws amscm get-rfc --rfc-id RFC_ID