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
ecfn-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 noAWS::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.exe
que 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: