Bootstrapping de pilhas do Windows do AWS CloudFormation - AWS CloudFormation
Exemplo de bootstrapping de uma pilha do WindowsComo gerenciar os serviços do WindowsComo solucionar problemas de criação da pilha

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 e cfn-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 para cfn-hup.

  • cfn-auto-reloader.conf, o arquivo de configuração do hook usado por cfn-hup para iniciar uma atualização (chamando cfn-init) quando os metadados em AWS::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: