As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Crie, carregue e implante o aplicativo
Primeiro, crie um pacote de WordPress aplicativos e, em seguida, use o CodeDeploy CTs para criar e implantar o aplicativo.
Baixe WordPress, extraia os arquivos e crie um. diretório /scripts.
Comando Linux:
wget https://github.com/WordPress/WordPress/archive/master.zipWindows: cole
https://github.com/WordPress/WordPress/archive/master.zipem uma janela do navegador e baixe o arquivo zip.Crie um diretório temporário no qual montar o pacote.
Linux
mkdir /tmp/WordPressWindows: Crie um diretório WordPress "", você usará o caminho do diretório posteriormente.
Extraia a WordPress fonte para o diretório WordPress "" e crie um. diretório /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: vá para o diretório WordPress "" que você criou e crie um diretório de “scripts” lá.
Se você estiver em um ambiente Windows, certifique-se de definir o tipo de interrupção dos arquivos de script como Unix (LF). No Notepad ++, essa é uma opção na parte inferior direita da janela.
Crie o arquivo CodeDeploy appspec.yml, no WordPress diretório (se estiver copiando o exemplo, verifique o recuo, cada espaço conta). IMPORTANTE: Certifique-se de que o caminho de “origem” esteja correto para copiar os WordPress arquivos (nesse caso, em seu WordPress diretório) para o destino esperado (/var/www/html/WordPress). No exemplo, o arquivo appspec.yml está no diretório com os WordPress arquivos, portanto, somente “/” é necessário. Além disso, mesmo que você tenha usado uma AMI RHEL para seu grupo de Auto Scaling, deixe a linha “os: linux” como está. Exemplo de arquivo 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-
Crie scripts de arquivo bash no WordPress . diretório /scripts.
Primeiro, crie
config_wordpress.shcom o conteúdo a seguir (se preferir, você pode editar o arquivo wp-config.php diretamente).nota
DBNameSubstitua pelo valor fornecido no HA Stack RFC (por exemplo,wordpress).DB_MasterUsernameSubstitua peloMasterUsernamevalor fornecido no HA Stack RFC (por exemplo,admin).DB_MasterUserPasswordSubstitua peloMasterUserPasswordvalor fornecido no HA Stack RFC (por exemplo,p4ssw0rd).DB_ENDPOINTSubstitua pelo nome DNS do endpoint nas saídas de execução do HA Stack RFC (por exemplo,).srt1cz23n45sfg---clgvd67uvydk---us-east-1---rds.amazonaws.com.rproxy.govskope.caVocê pode encontrar isso na GetRfcoperação (CLI: get-rfc --rfc-id RFC_ID) ou na página de detalhes do RFC do console AMS para o HA Stack RFC que você enviou anteriormente.#!/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 No mesmo diretório, crie
install_dependencies.shcom o seguinte conteúdo:#!/bin/bash yum install -y php yum install -y php-mysql yum install -y mysql service httpd restartnota
O HTTPS é instalado como parte dos dados do usuário no lançamento para permitir que as verificações de saúde funcionem desde o início.
No mesmo diretório, crie
start_server.shcom o seguinte conteúdo:Para instâncias do Amazon Linux, use isso:
#!/bin/bash service httpd startPara instâncias do RHEL, use isso (os comandos extras são políticas que permitem que o SELINUX aceite): 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
No mesmo diretório, crie
stop_server.shcom o seguinte conteúdo:#!/bin/bash service httpd stopCrie o pacote zip.
Linux
$ cd /tmp/WordPress $ zip -r wordpress.zip .Windows: Vá para o diretório WordPress "", selecione todos os arquivos e crie um arquivo zip, não se esqueça de chamá-lo de wordpress.zip.
Faça o upload do pacote de aplicativos no bucket do S3.
O pacote precisa estar pronto para continuar implantando a pilha.
Você tem acesso automático a qualquer instância de bucket do S3 que você criar. Você pode acessá-lo por meio de seus bastiões ou do console S3 e fazer o upload do WordPress pacote drag-and-drop ou navegar até o arquivo zip e selecioná-lo.
Você também pode usar o seguinte comando em uma janela de shell; verifique se você tem o caminho correto para o arquivo zip:
aws s3 cp wordpress.zip s3://BUCKET_NAME/Implante o pacote de WordPress aplicativos.
Coletar os dados a seguir antes de começar fará com que a implantação seja mais rápida.
DADOS NECESSÁRIOS:
VPC-ID: esse valor determina onde seu S3 Bucket estará. Use a mesma VPC ID que você usou anteriormente.CodeDeployApplicationNameeCodeDeployApplicationName: OApplicationNamevalor que você usou no HA 2-Tier Stack RFC definiu o CodeDeployApplicationName e o. CodeDeployDeploymentGroupName O exemplo usa "WordPress", mas você pode ter usado um valor diferente.S3Location: ParaS3Bucket, use oBucketNameque você criou anteriormente. OsS3BundleTypeeS3Keysão do pacote que você colocou na sua loja S3.
Exiba os parâmetros de execução do esquema JSON para o CodeDeploy aplicativo deploy CT em um arquivo JSON chamado Deploy Params.json. CDApp
aws amscm get-change-type-version --change-type-id "ct-2edc3sd1sqmrb" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > DeployCDAppParams.jsonModifique o esquema da seguinte forma e salve-o como, você pode excluir e substituir o conteúdo.
{ "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" } } } }Envie o modelo JSON CreateRfc para um arquivo, na sua pasta atual, chamado Deploy CDApp RFC.json:
aws amscm create-rfc --generate-cli-skeleton > DeployCDAppRfc.jsonModifique e salve o arquivo Deploy CDApp RFC.json, você pode excluir e substituir o conteúdo. Observe que
RequestedStartTimeagoraRequestedEndTimesão opcionais; excluí-los cria um ASAP RFC que é executado assim que aprovado (o que geralmente acontece automaticamente). Para enviar um RFC agendado, adicione esses valores.{ "ChangeTypeVersion": "1.0", "ChangeTypeId": "ct-2edc3sd1sqmrb", "Title": "CD-Deploy-For-WP-RFC" }Crie o RFC, especificando o arquivo Deploy CDApp Rfc e o arquivo de parâmetros de execução do Deploy CDApp Params:
aws amscm create-rfc --cli-input-json file://DeployCDAppRfc.json --execution-parameters file://DeployCDAppParams.jsonVocê recebe o RfcId do novo RFC na resposta. Salve o ID para as etapas subsequentes.
Envie o RFC:
aws amscm submit-rfc --rfc-idRFC_IDSe o RFC for bem-sucedido, você não receberá nenhuma saída.
Para verificar o status do RFC, execute
aws amscm get-rfc --rfc-idRFC_ID