Bootstrapping de pilhas do Windows do AWS CloudFormation - AWS CloudFormation

Bootstrapping de pilhas do Windows do AWS CloudFormation

Este tópico descreve como fazer bootstrap de uma pilha do Windows e solucionar problemas na criação da pilha. Se você for criar sua própria imagem do Windows a ser usada com o CloudFormation, consulte as informações em Configurar uma instância do Windows usando EC2ConfigService no Guia do Amazon EC2 para Microsoft Windows para obter instruções. Você deve configurar uma instância do Windows com EC2ConfigService para ele funcionar com as ferramentas de bootstrapping do AWS CloudFormation.

Exemplo de bootstrapping de uma pilha do Windows

Para fins ilustrativos, examinaremos um modelo de servidor do SharePoint de instância única do AWS CloudFormation.

O modelo pode ser visualizado, na íntegra, no seguinte URL:

Este exemplo demonstra como:

  • Criar um usuário do IAM e um grupo de segurança para ter acesso à instância

  • Configurar os arquivos de inicialização: cfn-credentials, cfn-hup.conf e cfn-auto-reloader.conf.

  • Fazer download e instalar um pacote como o SharePoint Foundation 2010 na instância de servidor.

  • Usar um WaitCondition para garantir que os recursos estejam prontos.

  • Recuperar um IP para a instância com o Amazon Elastic IP (EIP).

O script auxiliar do AWS CloudFormation cfn-init é usado para executar cada uma dessas ações com base em informações no recurso AWS::CloudFormation::Init do modelo Windows Single Server SharePoint Foundation.

A seção AWS::CloudFormation::Init é chamada de "SharePointFoundation" e começa com uma declaração padrão:

"SharePointFoundation": { "Type" : "AWS::EC2::Instance", "Metadata" : { "AWS::CloudFormation::Init" : { "config" : {

Depois disso, a seção files de AWS::CloudFormation::Init é declarada:

"files" : { "c:\\cfn\\cfn-hup.conf" : { "content" : { "Fn::Join" : ["", [ "[main]\n", "stack=", { "Ref" : "AWS::StackName" }, "\n", "region=", { "Ref" : "AWS::Region" }, "\n" ]]} }, "c:\\cfn\\hooks.d\\cfn-auto-reloader.conf" : { "content": { "Fn::Join" : ["", [ "[cfn-auto-reloader-hook]\n", "triggers=post.update\n", "path=Resources.SharePointFoundation.Metadata.AWS::CloudFormation::Init\n", "action=cfn-init.exe -v -s ", { "Ref" : "AWS::StackName" }, " -r SharePointFoundation", " --region ", { "Ref" : "AWS::Region" }, "\n" ]]} }, "C:\\SharePoint\\SharePointFoundation2010.exe" : { "source" : "http://d3adzpja92utk0.cloudfront.net/SharePointFoundation.exe" } },

Três arquivos são criados aqui e colocados no diretório C:\cfn da instância do servidor. Esses arquivos são:

  • cfn-hup.conf, o arquivo de configuração de cfn-hup.

  • cfn-auto-reloader.conf, o arquivo de configuração do hook usado por cfn-hup para iniciar uma atualização (chamada de cfn-init) quando os metadados no AWS::CloudFormation::Init mudam.

Há também um arquivo baixado no servidor: SharePointFoundation.exe. Esse arquivo é usado para instalar o SharePoint na instância de servidor.

Importante

Como caminhos no Windows usam uma barra invertida ('\'), você deve sempre se lembrar de escapar corretamente todas as barras invertidas, acrescentando outra barra invertida sempre que consultar um caminho do Windows no modelo do AWS CloudFormation.

A seguir, vem a seção comandos, que são os comandos cmd.exe.

"commands" : { "1-extract" : { "command" : "C:\\SharePoint\\SharePointFoundation2010.exe /extract:C:\\SharePoint\\SPF2010 /quiet /log:C:\\SharePoint\\SharePointFoundation2010-extract.log" }, "2-prereq" : { "command" : "C:\\SharePoint\\SPF2010\\PrerequisiteInstaller.exe /unattended" }, "3-install" : { "command" : "C:\\SharePoint\\SPF2010\\setup.exe /config C:\\SharePoint\\SPF2010\\Files\\SetupSilent\\config.xml" }

Como comandos na instância são processados em ordem alfabética por nome, todo comando recebe um número indicando a ordem de execução desejada. Assim, podemos ter a certeza de que o pacote de instalação seja extraído inicialmente, todos os pré-requisitos acabam sendo instalados e, por fim, a instalação do SharePoint é iniciada.

A seguir, vem a seção Propriedades:

"Properties": { "InstanceType" : { "Ref" : "InstanceType" }, "ImageId" : { "Fn::FindInMap" : [ "AWSRegionArch2AMI", { "Ref" : "AWS::Region" }, { "Fn::FindInMap" : [ "AWSInstanceType2Arch", { "Ref" : "InstanceType" }, "Arch" ] } ] }, "SecurityGroups" : [ {"Ref" : "SharePointFoundationSecurityGroup"} ], "KeyName" : { "Ref" : "KeyPairName" }, "UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [ "<script>\n", "cfn-init.exe -v -s ", { "Ref" : "AWS::StackName" }, " -r SharePointFoundation", " --region ", { "Ref" : "AWS::Region" }, "\n", "cfn-signal.exe -e %ERRORLEVEL% ", { "Fn::Base64" : { "Ref" : "SharePointFoundationWaitHandle" }}, "\n", "</script>" ]]}} }

Nesta seção, a propriedade UserData contém um script cmd.exeque será executado por cfn-init, entre tags <script>. Você pode usar um script do Windows Powershell aqui, em vez de deixar o script entre tags <powershell>. Para pilhas do Windows, você deve codificar o URL de processamento da condição de espera em base64 novamente.

SharePointFoundationWaitHandle é referenciado aqui e executado com cfn-signal. WaitConditionHandle e seu associado WaitCondition são declarados a seguir no modelo:

"SharePointFoundationWaitHandle" : { "Type" : "AWS::CloudFormation::WaitConditionHandle" }, "SharePointFoundationWaitCondition" : { "Type" : "AWS::CloudFormation::WaitCondition", "DependsOn" : "SharePointFoundation", "Properties" : { "Handle" : {"Ref" : "SharePointFoundationWaitHandle"}, "Timeout" : "3600" } }

Como a execução de todas as etapas e a instalação do SharePoint pode demorar um pouco, mas não uma hora, WaitCondition aguarda uma hora (3600 segundos) antes do tempo limite.

Caso tudo dê certo, usa-se um IP elástico para fornecer acesso à instância do SharePoint:

"Outputs" : { "SharePointFoundationURL" : { "Value" : { "Fn::Join" : ["", ["http://", { "Ref" : "SharePointFoundationEIP" } ]] }, "Description" : "SharePoint Team Site URL. Please retrieve Administrator password of the instance and use it to access the URL" }

Depois que a criação da pilha for concluída, o endereço IP fornecido pelo EIP será exibido na guia Outputs (Saídas) do console do AWS CloudFormation. No entanto, para poder acessar a instância, você precisará recuperar a senha do administrador temporária gerada para a instância. Para obter mais informações, consulte Conexão com a instância do Windows usando um cliente RDP no Guia do usuário do Amazon EC2.

Como gerenciar os serviços do Windows

Você gerencia os serviços do Windows da mesma maneira que os serviços do Linux, exceto por usar uma chave windows em vez de sysvinit. O exemplo a seguir iniciará o serviço cfn-hup, definirá o serviço como automático e o reiniciará se cfn-init modificar os arquivos de configuração c:\cfn\cfn-hup.conf ou c:\cfn\hooks.d\cfn-auto-reloader.conf.

"services" : { "windows" : { "cfn-hup" : { "enabled" : "true", "ensureRunning" : "true", "files" : ["c:\\cfn\\cfn-hup.conf", "c:\\cfn\\hooks.d\\cfn-auto-reloader.conf"] } } }

Você pode gerenciar outros serviços do Windows da mesma maneira usando o nome, e não o nome de exibição, para referenciar o serviço.

Como solucionar problemas de criação da pilha

Em caso de falha na pilha durante a criação, o comportamento padrão é de reversão em caso de falha. Embora normalmente seja um bom padrão, pois evita cobranças desnecessários, isso dificulta a depuração por causa da falha na criação da pilha.

Para desativar esse comportamento, escolha Show Advanced Options (Mostrar opções avançadas) ao criar sua pilha com o console do AWS CloudFormation e, em seguida, clique no seletor No (Não) ao lado de Rollback on failure (Reverter se houver falha). Isso permitirá que você faça login na instância e visualize os arquivos de log para identificar problemas encontrados na execução dos scripts de startup.

Os logs importantes a serem observados são:

  • O log de configuração do EC2 em C:\Program Files\Amazon\Ec2ConfigService\Logs\Ec2ConfigLog.txt

  • O log cfn-init em C:\cfn\log\cfn-init.log

Consulte esses guias do EC2 para obter mais logs: