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 para usar com o CloudFormation, consulte as informações em Usar o serviço EC2Config para realizar tarefas durante a execução da instância herdada do sistema operacional Windows do EC2 no Manual do usuário do Amazon EC2 para obter instruções. Você deve configurar uma instância do Windows com o serviço EC2Config para que ela funcione 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:
-
Crie um usuário e um grupo de segurança do IAM para acessar a instância.
-
Configurar os arquivos de inicialização:
cfn-credentials
,cfn-hup.conf
ecfn-auto-reloader.conf
. -
Fazer download e instalar um pacote como o SharePoint Foundation 2010 na instância de servidor.
-
Use uma
WaitCondition
para ter certeza de que os recursos estejam preparados. -
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
é denominada SharePointFoundation
e começa com uma declaração padrão:
"SharePointFoundation": { "Type" : "AWS::EC2::Instance", "Metadata" : { "AWS::CloudFormation::Init" : { "config" : {
Depois, 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 paracfn-hup
. -
cfn-auto-reloader.conf
, o arquivo de configuração do hook usado porcfn-hup
para iniciar uma atualização (chamandocfn-init
) quando os metadados emAWS::CloudFormation::Init
são alteados.
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 próxima seção é a seção commands
, 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, a seção Properties
:
"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.exe
que será executado por cfn-init
, entre tags <script>
. Você pode usar aqui um script do Windows Powershell em vez de colocar 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
. O WaitConditionHandle
e o WaitCondition
associado são declarados no modelo a seguir:
"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 podem demorar um pouco, mas menos de uma hora, a WaitCondition
aguarda uma hora (3.600 segundos) antes de atingir o 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 Conectar à 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 os 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: