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á. # Apps **Importante** O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support). Um *aplicativo OpsWorks * Stacks representa o código que você deseja executar em um servidor de aplicativos. O próprio código reside em um repositório, como um arquivo morto do Amazon S3; o aplicativo contém as informações necessárias para implantar o código nas instâncias apropriadas do servidor de aplicativos. Quando você implanta um aplicativo, o OpsWorks Stacks aciona um evento Deploy, que executa as receitas Deploy de cada camada. OpsWorks O Stacks também instala a [configuração da pilha e os atributos de implantação](workingcookbook-json.md) que contêm todas as informações necessárias para implantar o aplicativo, como o repositório do aplicativo e os dados de conexão do banco de dados. Você deve implementar as receitas personalizadas que recuperam os dados de implantação do aplicativo dos atributos de configuração e implantação da pilha e lidam com as tarefas de implantação. **Topics** + [Adição de aplicativos](workingapps-creating.md) + [Implementação de aplicativos](workingapps-deploying.md) + [Editar aplicativos](workingapps-editing.md) + [Conectando-se a um aplicativo para um servidor de banco de dados](workingapps-connectdb.md) + [Usar variáveis de ambiente do](apps-environment-vars.md) + [Transmissão de dados para aplicativos](apps-data.md) + [Utilização de chaves SSH de repositório Git](workingapps-deploykeys.md) + [Usando domínios predefinidos](workingapps-domains.md) + [Uso de SSL](workingsecurity-ssl.md) # Adição de aplicativos **Importante** O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support). A primeira etapa na implantação de um aplicativo nos seus servidores de aplicativos é a adição do aplicativo na pilha. O aplicativo representa o programa e contém uma variedade de metadados, como o nome e o tipo do aplicativo e as informações necessárias para implantar o aplicativo nas instâncias do servidor, como o URL do repositório. Você precisa ter a permissão Manage para adicionar um aplicativo a uma pilha. Para obter mais informações, consulte [Gerenciamento de permissões de usuário](opsworks-security-users.md). **nota** O procedimento descrito nesta seção se aplica a pilhas do Chef 12 e mais recentes. Para obter mais informações sobre como adicionar aplicativos a camadas nas pilhas do Chef 11, consulte [Etapa 2.4: Criar e implantar um aplicativo - Chef 11](gettingstarted-simple-app.md). **Para adicionar um aplicativo a uma pilha** 1. Coloque o código no repositório de sua preferência: um arquivo compactado do Amazon S3, um repositório Git, um repositório Subversion ou um arquivo compactado HTTP. Para obter mais informações, consulte [Origem do aplicativo](#workingapps-creating-source). 1. No painel de navegação, clique em **Apps**. Na página **Apps**, clique em **Add an app** no seu primeiro aplicativo. Para os aplicativos subsequentes, clique em **\$1App**. 1. Use a página **App New **para configurar o aplicativo, como descreve a seção a seguir. ## Configuração do aplicativo A página **Add App** consiste nas seguintes seções: **Settings**, **Application source**, **Data Sources**, **Environment Variables**, **Add Domains** e **SSL Settings**. **Topics** + [Configurações](#workingapps-creating-settings) + [Origem do aplicativo](#workingapps-creating-source) + [Fontes de dados](#workingapps-creating-data) + [Variáveis de ambiente](#workingapps-creating-environment) + [Configurações de Domínio e SSL](#workingapps-creating-domain-ssl) ### Configurações **Nome** O nome do aplicativo, que é usado para representar o aplicativo na interface do usuário. OpsWorks O Stacks também usa esse nome para gerar um nome curto para o aplicativo usado internamente e para identificar o aplicativo nos atributos de [configuração e implantação da pilha](workingcookbook-json.md). Depois de adicionar o aplicativo à pilha, você pode ver o nome abreviado clicando em **Apps** no painel de navegação e, em seguida, clicando no nome do aplicativo para abrir a página de detalhes. ****Document root**** OpsWorks Stacks atribui a configuração **raiz do documento** ao [`[:document_root]`](attributes-json-deploy.md#attributes-json-deploy-app-root)atributo nos atributos do `deploy` aplicativo. O valor padrão é `null`. Suas receitas de implantação podem obter esse valor dos atributos `deploy` usando a sintaxe do nó padrão do Chef e implantar o código especificado no local apropriado do servidor. Para obter mais informações sobre como implantar aplicativos, consulte [Receitas de implantação](create-custom-deploy.md). ### Origem do aplicativo Você pode implantar aplicativos dos seguintes tipos de repositório: Git, pacote do Amazon S3, pacote de HTTP e outros. Todos os tipos de repositórios exigem que você especifique o tipo e o URL do repositório. Tipos de repositórios individuais têm seus próprios requisitos, como explicamos a seguir. **nota** OpsWorks O Stacks implanta automaticamente aplicativos dos repositórios padrão nas camadas integradas do servidor. Se você usa o tipo Outro repositório, que é a única opção para pilhas do Windows, o OpsWorks Stacks coloca as informações do repositório nos [`deploy`atributos](workingcookbook-json.md#workingcookbook-json-deploy) do aplicativo, mas você deve implementar receitas personalizadas para lidar com as tarefas de implantação. **Topics** + [Arquivo HTTP](#w2ab1c14c57c13c11b8b8) + [Arquivo do Amazon S3](#w2ab1c14c57c13c11b8c10) + [Repositório Git](#w2ab1c14c57c13c11b8c12) + [Outros repositórios](#w2ab1c14c57c13c11b8c14) #### Arquivo HTTP Para usar um servidor HTTP de acesso público como um repositório: 1. Crie um arquivo compactado do tipo zip, gzip, bzip2, Java WAR ou tarball com o conteúdo da pasta que contém o código do aplicativo e quaisquer arquivos associados. **nota** OpsWorks O Stacks não suporta arquivos tar não compactados. 1. Carregue o arquivo compactado no servidor. 1. Para especificar o repositório no console, selecione HTTP Archive como tipo do repositório e insira o URL. Se o arquivo compactado é protegido por senha, especifique as credenciais de entrada em **Fonte do aplicativo**. #### Arquivo do Amazon S3 Crie um bucket do Amazon Simple Storage Service como um repositório: 1. Crie um bucket público ou privado no Amazon S3. Para mais informações, consulte a [documentação do Amazon S3](https://aws.amazon.com/documentation/s3/). 1. Para que o OpsWorks Stacks acesse buckets privados, você deve ser um usuário com pelo menos direitos de somente leitura no bucket do Amazon S3 e precisará do ID da chave de acesso e da chave de acesso secreta. Para obter mais informações, consulte a [Documentação do AWS Identity and Access Management](https://docs.aws.amazon.com/iam/). 1. Coloque o código e quaisquer arquivos associados em uma pasta e armazene a pasta em um arquivo compactado – zip, gzip, bzip2, Java WAR ou tarball. **nota** OpsWorks O Stacks não suporta arquivos tar não compactados. 1. Carregue o arquivo compactado no bucket do Amazon S3 e anote o URL. 1. Para especificar o repositório no console OpsWorks Stacks, defina o **tipo de repositório** como **S3 Archive** e insira a URL do arquivo. Para arquivos compactados privados, você também deve fornecer um access key ID e a chave de acesso secreta da AWS cuja política concede as permissões para acessar o bucket. Deixe essas configurações em branco para arquivos compactados públicos. #### Repositório Git Um repositório [Git](http://git-scm.com/) fornece controle de origem e controle de versão. OpsWorks O Stacks oferece suporte a sites de repositórios hospedados publicamente, como [GitHub](https://github.com/)o [Bitbucket](https://bitbucket.org), bem como a servidores Git hospedados de forma privada. Para ambos os aplicativos e os submódulos do Git, o formato que você usa para especificar o URL do repositório em **Application Source** depende se o repositório é público ou privado: **Repositório público**: use os protocolos HTTPS ou Git somente de leitura. Por exemplo, [Conceitos básicos das pilhas Linux do Chef 11](gettingstarted.md) usa um GitHub repositório público que pode ser acessado por qualquer um dos seguintes formatos de URL: + Somente leitura do Git: **git://github.com/amazonwebservices/opsworks-demo-php-simple-app.git** + HTTPS: **https://github.com/amazonwebservices/opsworks-demo-php-simple-app.git** **Repositório privado** — Use o read/write formato SSH mostrado nestes exemplos: + Repositórios Github: **git@github.com:*project*/*repository***. + Repositórios em um servidor Git: ***user*@*server*:*project*/*repository*** Ao selecionar **Git** em **Source Control**, duas configurações opcionais adicionais são exibidas: **Chave SSH de repositório** Você deve especificar uma chave SSH de implantação para acessar os repositórios Git privados. Esse campo requer a chave privada; a chave pública é atribuída ao seu repositório Git. Para submódulos do Git, a chave especificada deve ter acesso a esses submódulos. Para obter mais informações, consulte [Utilização de chaves SSH de repositório Git](workingapps-deploykeys.md). A chave SSH de implantação não pode exigir uma senha; o OpsWorks Stacks não tem como passá-la. **Ramificação/Revisão** Se o repositório tiver várias ramificações, o OpsWorks Stacks baixa a ramificação master por padrão. Para especificar uma ramificação específica, insira o nome da ramificação, o SHA1 hash ou o nome da tag. Para especificar uma determinada confirmação, insira o identificador completo de confirmação de 40 dígitos hexadecimais. #### Outros repositórios Se os repositórios padrão não atendem aos seus requisitos, você pode usar outros repositórios, como o [Bazaar](http://bazaar.canonical.com/en/). No entanto, o OpsWorks Stacks não implanta automaticamente aplicativos desses repositórios. Você deve implementar receitas personalizadas para lidar com o processo de implantação e atribuí-las aos eventos de implantação das camadas apropriadas. Para ver um exemplo de como implementar o Implantar receitas, consulte [Receitas de implantação](create-custom-deploy.md). ### Fontes de dados Esta seção mostra como anexar um banco de dados no aplicativo. Você tem as seguintes opções: + **RDS**: anexe uma das camadas de serviço do [Amazon RDS da pilha](workinglayers-db-rds.md). + **Nenhum**: não anexe um servidor de banco de dados. Se você selecionar **RDS**, precisará especificar o seguinte. **Instância do banco de dados** A lista inclui todas as camadas de serviço do Amazon RDS. Você também pode selecionar um dos seguintes: (Obrigatório) especifique o servidor de banco de dados a ser anexado ao aplicativo. O conteúdo da lista depende da fonte de dados. + **RDS**: uma lista das camadas de serviço do Amazon RDS da pilha. **Nome do banco de dados** (Opcional) especifique um nome de banco de dados. + Camada do Amazon RDS: insira o nome do banco de dados que você especificou para a instância do Amazon RDS. Você pode obter o nome do banco de dados do [console do Amazon RDS](https://console.aws.amazon.com/rds/). Quando você implanta um aplicativo com um banco de dados anexado, o OpsWorks Stacks adiciona a conexão da instância do banco de dados aos [`deploy`atributos](workingcookbook-json.md#workingcookbook-json-deploy) do aplicativo. Você pode criar uma receita personalizada para recuperar as informações dos atributos `deploy` e colocá-la no arquivo que pode ser acessado pelo aplicativo. Esta é a única opção para fornecer informações de conexão de banco de dados ao tipo de aplicativo Outros. Para obter mais informações sobre como lidar com conexões de banco de dados, consulte [Conectar-se a um banco de dados](workingapps-connectdb.md). Para desanexar um servidor de banco de dados de um aplicativo, [edite a configuração do aplicativo](workingapps-editing.md) para especificar um servidor de banco de dados diferente ou nenhum servidor. ### Variáveis de ambiente Você pode especificar um conjunto de variáveis de ambiente para cada aplicativo, que são específicas para o aplicativo. Por exemplo, se você tiver dois aplicativos, as variáveis de ambiente que você define para o primeiro aplicativo não são disponibilizadas para o segundo aplicativo e vice-versa. Você também pode definir a mesma variável de ambiente para vários aplicativos e atribuir a ela um valor diferente para cada aplicativo. **nota** Não há um limite específico para o número de variáveis de ambiente. No entanto, o tamanho da estrutura de dados associada, que inclui os nomes e valores das variáveis e os valores de sinalização protegidos, não pode ultrapassar 20 KB. Esse limite deve acomodar a maioria dos casos de uso. Se o limite for ultrapassado, isso causará um erro de serviço (console) ou exceção (API) com a mensagem, "Ambiente: é muito grande (o tamanho máximo é 20 KB)." OpsWorks O Stacks armazena as variáveis como atributos nos [`deploy`atributos](workingcookbook-json.md#workingcookbook-json-deploy) do aplicativo. Você pode fazer com que suas receitas personalizadas recuperem esses valores usando a sintaxe padrão do nó do Chef. Para obter exemplos de como acessar as variáveis de ambiente de um aplicativo, consulte [Usar variáveis de ambiente do](apps-environment-vars.md). **Chave** O nome da variável. Ele pode conter até 64 letras maiúsculas e minúsculas, números e caracteres sublinhados (\$1), mas deve começar com uma letra ou sublinhado. **Valor** O valor da variável. Ele pode conter até 256 caracteres, que devem ser todos imprimíveis. **Valor protegido** Determina se o valor é protegido. Essa configuração permite que você oculte informações confidenciais, como senhas. Se você definir uma variável como **Protected value** depois de criar o aplicativo: + A página de detalhes do aplicativo exibirá somente o nome da variável, e não o valor. + Se você tiver permissão para editar o aplicativo, pode clicar em **Update value** para especificar um novo valor, mas não poderá ver ou editar o valor antigo. **nota** Às vezes, os logs de implantação do Chef podem incluir variáveis de ambiente. Isso significa que as variáveis protegidas podem ser exibidas no console. Para evitar que isso ocorra, recomendamos que você use buckets do Amazon S3 como armazenamento para variáveis protegidas que você não deseja que sejam exibidas no console. Um exemplo de como usar um bucket do S3 para essa finalidade está disponível em [Usar um bucket do Amazon S3](gettingstarted.walkthrough.photoapp.md) neste guia. ### Configurações de Domínio e SSL Para o tipo de aplicativo Outro, o OpsWorks Stacks adiciona as configurações aos `deploy` atributos do aplicativo. Suas receitas podem recuperar os dados a partir desses atributos e configurar o servidor, conforme necessário. **Configurações de domínio** Esta seção tem um campo opcional **Add Domains** para especificar domínios. Para obter mais informações, consulte [Usando domínios predefinidos](workingapps-domains.md). **Configurações de SSL** Esta seção tem uma opção de alternância de **SSL Support** que você pode usar para habilitar ou desabilitar o SSL. Se você clicar em **Yes**, precisará fornecer as informações do certificado SSL. Para obter mais informações, consulte [Uso de SSL](workingsecurity-ssl.md). # Implementação de aplicativos **Importante** O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support). O objetivo principal da implementação é implementar código de aplicativo e arquivos relacionados em instâncias do servidor de aplicativos. A operação de implementação é processada pelas receitas de Implementação de cada Instância, determinadas pela camada da instância. Quando você inicia uma instância, após a conclusão das receitas de configuração, o OpsWorks Stacks executa automaticamente as receitas de implantação da instância. No entanto, ao adicionar ou modificar um aplicativo, você deve implementá-lo manualmente em quaisquer instâncias online. Você deve ter as permissões Gerenciar ou Implementar para implementar um aplicativo. Para obter mais informações, consulte [Gerenciamento de permissões de usuário](opsworks-security-users.md). **Para implementar um aplicativo** 1. Na página **Apps**, clique na ação **deploy** do aplicativo. ![\[Apps page showing SimplePHP app with deploy, edit, and delete action options.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/apps_with_content.png) **nota** Você também pode implementar um aplicativo clicando em **Deployments **no painel de navegação. Na página **Deployments & Commands**, clique em **Deploy an app**. Ao fazer isso, você também pode escolher qual aplicativo implementar. 1. Especifique o seguinte: + (Obrigatório) Defina **Command:** como **deploy**, se ainda não estiver selecionado. + (Opcional) Inclua um comentário. 1. Clique em **Avançado >>** para especificar o JSON personalizado. OpsWorks O Stacks adiciona um conjunto de [atributos de configuração e implantação da pilha ao objeto](workingcookbook-json.md) do nó. Os atributos `deploy` contêm os detalhes de implementação e podem ser usados pelas receitas de Implementação para cuidar da instalação e configuração. Nas pilhas do Linux, você pode usar o campo JSON personalizado para [substituir as configurações padrão das OpsWorks pilhas ou passar as configurações](workingcookbook-json-override.md) personalizadas para suas receitas personalizadas. Para obter mais informações sobre como usar JSON personalizado, consulte [Usar JSON personalizado](workingstacks-json.md). **nota** Se você especificar JSON personalizado aqui, ele é adicionado aos atributos de implementação e configuração da pilha apenas para essa implementação. Se você deseja adicionar JSON personalizado permanentemente, você deve [adicioná-lo à pilha](workingstacks-json.md). JSON personalizado é limitado a 120 KB. Caso precise de mais capacidade, recomendamos armazenar alguns dados no Amazon S3. Suas receitas personalizadas podem então usar a CLI da AWS ou o [AWS SDK para Ruby](https://aws.amazon.com/documentation/sdk-for-ruby/) para fazer download dos dados do bucket para sua instância. Para ver um exemplo, consulte [Usar o SDK for Ruby](cookbooks-101-opsworks-s3.md). 1. Em **Instances**, clique em **Advanced >>** e especifique em quais instâncias executar o comando de implementação. O comando de implementação aciona um evento Implementar, que executa as receitas de implementação nas instâncias selecionadas. As receitas de implementação do servidor de aplicativo associado baixa o código e os arquivos relacionados do repositório e os instala na instância, portanto você normalmente seleciona todas as instâncias do servidor de aplicativo associado. No entanto, outros tipos de instâncias podem exigir algumas alterações na configuração para acomodar o novo aplicativo, portanto geralmente é útil executar as receitas de implementação nessas instâncias também. Essas receitas atualizam a configuração conforme necessário, mas não instalam os arquivos do aplicativo. Para obter mais informações sobre receitas, consulte [Livros de receitas e receitas](workingcookbook.md). 1. Clique em **Deploy** para executar as receitas de implementação nas instâncias especificadas, o que irá exibir a página Implementação. Quando o processo estiver concluído, o OpsWorks Stacks marca o aplicativo com uma marca verde para indicar a implantação bem-sucedida. Se a implantação falhar, o OpsWorks Stacks marca o aplicativo com um X vermelho. Nesse caso, você pode acessar a página **Implantações** e examinar o registro de implantação para obter mais informações. ![\[Deployment status page showing successful deployment of PHPTestApp with details.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/deployed_app.png) **nota** Quando você implanta uma atualização em um aplicativo JSP, o Tomcat pode não reconhecer a atualização e, em vez disso, continuar a executar a versão do aplicativo existente. Isso pode acontecer, por exemplo, se você implantar seu aplicativo como um arquivo.zip que contém apenas uma página JSP. Para garantir que o Tomcat execute a última versão implementada, o diretório raiz do projeto deve incluir um diretório WEB-INF que contenha um arquivo `web.xml`. Um arquivo `web.xml` pode conter uma variedade de conteúdos, mas o conteúdo a seguir é suficiente para garantir que o Tomcat reconheça as atualizações e execute a última versão implementada do aplicativo. Você não precisa alterar a versão para cada atualização. O Tomcat reconhecerá a atualização mesmo se a versão não tiver sido alterada. ``` appVersion 0.1 ``` ## Outros comandos de implementação A página **Deploy app** inclui vários outros comandos para gerenciar seus aplicativos e os servidores associados. Dos comandos a seguir, somente **Undeploy** está disponível para aplicativos nas pilhas do Chef 12. **Desfazer a Implementação** Aciona um [evento do ciclo de vida](workingcookbook-events.md) para Desfazer a Implementação, que executa as receitas apropriadas para remover todas as versões do aplicativo das instâncias especificadas. **Reversão** Restaura a versão do aplicativo implantada anteriormente. Por exemplo, se você implementou o aplicativo três vezes e, em seguida, executou **Rollback**, o servidor irá servir o aplicativo da segunda implementação. Se você executar **Rollback** novamente, o servidor irá servir o aplicativo na primeira implantação. Por padrão, o OpsWorks Stacks armazena as cinco implantações mais recentes, o que permite reverter até quatro versões. Caso exceda o número de versões armazenadas, o comando falha e deixa a versão mais antiga em vigor. Este comando não está disponível nas pilhas do Chef 12. **Iniciar o Servidor Web** Executa as receitas que iniciam o servidor do aplicativo nas instâncias especificadas. Este comando não está disponível nas pilhas do Chef 12. **Parar o Servidor Web** Executa as receitas que param o servidor do aplicativo nas instâncias especificadas. Este comando não está disponível nas pilhas do Chef 12. **Reiniciar o Servidor Web** Executa as receitas que reiniciam o servidor do aplicativo nas instâncias especificadas. Este comando não está disponível nas pilhas do Chef 12. **Importante** **Start Web Server**, **Stop Web Server**, **Restart Web Server** e **Rollback** são versões personalizadas do [comando de pilha Executar receitas](workingstacks-commands.md). Eles executam um conjunto de receitas que realizam a tarefa nas instâncias especificadas. Esses comandos não acionam um evento de ciclo de vida, portanto você não pode conectá-los para executar o código personalizado. Esses comandos funcionam apenas para as [camadas do servidor de aplicativo](workinglayers-servers.md) integradas. Especificamente, esses comandos não afetam as camadas personalizadas, mesmo que elas ofereçam suporte ao servidor de aplicativo. Para iniciar, parar ou reiniciar servidores em uma camada personalizada, você deve implementar receitas personalizadas para realizar essas tarefas e usar o [comando de pilha para Executar Receitas](workingstacks-commands.md) para executá-las. Para obter mais informações sobre como implementar e instalar receitas personalizadas, consulte [Livros de receitas e receitas](workingcookbook.md). # Editar aplicativos **Importante** O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support). Você pode modificar a configuração de um aplicativo editando-o. Por exemplo, se você estiver pronto para implantar uma nova versão, poderá editar as configurações de OpsWorks pilhas do aplicativo para usar a nova ramificação do repositório. É necessário ter as permissões Gerenciar ou Implementar para editar a configuração de um aplicativo. Para obter mais informações, consulte [Gerenciamento de permissões de usuário](opsworks-security-users.md). **Para editar um aplicativo** 1. Na página **Apps**, clique no nome do aplicativo para abrir sua página de detalhes. 1. Clique em **Edit** para alterar a configuração do aplicativo. + Se você modificar o nome do aplicativo, o OpsWorks Stacks usará o novo nome para identificar o aplicativo no console. Alterar o nome não altera o nome curto associado. O nome curto é definido ao adicionar o aplicativo na pilha e não pode ser modificado posteriormente. + Se você especificou uma variável de ambiente protegida, não é possível visualizar ou editar o valor. No entanto, você pode especificar um novo valor clicando em **Update value**. 1. Clique em **Save** para salvar a nova configuração e, em seguida, **Deploy App** para implementar o aplicativo. A edição de um aplicativo altera as configurações com as OpsWorks pilhas, mas não afeta as instâncias da pilha. Na primeira vez que [um aplicativo é implementado](workingapps-deploying.md), as receitas de Implementação baixam o código e os arquivos relacionados para as instâncias de servidor do aplicativo, que então executam a cópia local. Se você modificar o aplicativo no repositório ou alterar qualquer outra configuração, deverá implantar o aplicativo para instalar as atualizações nas instâncias do seu servidor de aplicativos, da seguinte maneira. OpsWorks O Stacks implanta automaticamente a versão atual do aplicativo em novas instâncias quando elas são iniciadas. Entretanto, para as instâncias atuais a situação é diferente: + OpsWorks O Stacks implanta automaticamente a versão atual do aplicativo em novas instâncias quando elas são iniciadas. + OpsWorks O Stacks implanta automaticamente a versão mais recente do aplicativo em instâncias off-line, incluindo instâncias [baseadas em carga e em tempo, quando elas são reiniciadas](workinginstances-autoscaling.md). + Você deve implementar manualmente o aplicativo atualizado em instâncias online. Para obter mais informações sobre como implementar aplicativos, consulte [Implementação de aplicativos](workingapps-deploying.md) # Conectando-se a um aplicativo para um servidor de banco de dados **Importante** O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support). Você pode associar um servidor de banco de dados do Amazon RDS; a um aplicativo ao [criar o aplicativo](workingapps-creating.md), ou, posteriormente, [editando a configuração do aplicativo](workingapps-editing.md). O aplicativo pode então usar as informações de conexão de banco de dados, como nome de usuário, senha etc., para se conectar ao servidor de banco de dados. Quando você [implanta um aplicativo](workingapps-deploying.md), o OpsWorks Stacks fornece essas informações aos aplicativos de duas maneiras: + Para pilhas do Linux, o OpsWorks Stacks cria um arquivo em cada uma das instâncias do servidor de aplicativos integrados que contêm os dados de conexão que o aplicativo pode usar para se conectar ao servidor do banco de dados. + OpsWorks As pilhas incluem as informações de conexão na [configuração da pilha e nos atributos de implantação](workingcookbook-json.md) que são instalados em cada instância. Você pode implantar uma receita personalizada para extrair as informações de conexão desses atributos e colocá-la em um arquivo no formato de sua preferência. Para obter mais informações, consulte [Transmissão de dados para aplicativos](apps-data.md). **Importante** Para pilhas do Linux, se você desejar associar uma camada de serviço Amazon RDS com seu aplicativo, você deve adicionar o driver adequado para o pacote camada de servidor do aplicativo associado, da seguinte forma: Clique em **Layers** no painel de navegação e abra a guia **Recipes** do servidor do aplicativo. Clique em **Edit** e adicione o driver adequado a **OS Packages**. Por exemplo, você deve especificar `mysql` se a camada contém as instâncias do Amazon Linux e `mysql-client` se a camada contém as instâncias Ubuntu. Salve as alterações e reimplante o aplicativo. ## Usando uma receita predefinida Pode ser implementada uma receita predefinida que extrai os dados de conexão dos [`deploy` atributos do aplicativo](workingcookbook-json.md#workingcookbook-json-deploy) e os salva em um formato que o aplicativo pode ler, como um arquivo YAML. Um servidor poderá ser anexado ao banco de dados de um aplicativo quando [o aplicativo for criado](workingapps-creating.md) ou posteriormente, [editando o aplicativo](workingapps-editing.md). Quando você implanta o aplicativo, o OpsWorks Stacks instala uma [configuração de pilha e atributos de implantação](workingcookbook-json.md) em cada instância que incluem as informações de conexão do banco de dados. Dessa forma, seu aplicativo pode recuperar os atributos apropriados. Os detalhes dependem se você estiver usando uma pilha do Linux ou Windows. ### Conectando-se a um servidor de banco de dados para uma pilha do Linux Para pilhas do Linux, o namespace de [atributos de implantação e configuração de pilha](workingcookbook-json.md) `deploy` incluem um atributo para cada aplicativo implantado, identificado pelo nome abreviado do aplicativo. Quando você anexa um servidor de banco de dados a um aplicativo, o OpsWorks Stacks preenche o `[:database]` atributo do aplicativo com as informações de conexão e o instala nas instâncias da pilha para cada implantação subsequente. Os valores de atributo são fornecidos pelo usuário ou gerados pelo OpsWorks Stacks. **nota** OpsWorks O Stacks permite que você conecte um servidor de banco de dados a vários aplicativos, mas cada aplicativo pode ter somente um servidor de banco de dados conectado. Se desejar conectar um aplicativo para mais de um servidor de banco de dados, anexe um dos servidores ao aplicativo, e use as informações de atributos `deploy` do aplicativo para se conectar a esse servidor. Use o JSON predefinido para passar as informações de conexão aos outros servidores de banco de dados para o aplicativo. Para obter mais informações, consulte [Transmissão de dados para aplicativos](apps-data.md). Um aplicativo pode usar as informações de conexão dos `deploy` atributos da instância para se conectar a um banco de dados. No entanto, os aplicativos não podem acessar diretamente essas informações, somente receitas podem acessar os atributos `deploy`. Você pode resolver esse problema, implementando uma receita predefinida que extrai as informações de conexão dos `deploy` atributos e os coloca em um arquivo que pode ser lido pelo aplicativo. # Usar variáveis de ambiente do **Importante** O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support). **nota** As recomendações neste tópico se aplicam ao Chef 11.10 e a versões anteriores do Chef. Para obter as variáveis de ambiente no Chef 12 ou em versões mais recentes, você deverá usar a Data bag do aplicativo. Para obter mais informações, consulte [AWS OpsWorks Data Bag Reference e App Data Bag](https://docs.aws.amazon.com/opsworks/latest/userguide/data-bags.html) [(aws\$1opsworks\$1app](https://docs.aws.amazon.com/opsworks/latest/userguide/data-bag-json-app.html)). Quando você [especifica variáveis de ambiente para um aplicativo](workingapps-creating.md#workingapps-creating-environment), o OpsWorks Stacks adiciona as definições das variáveis aos [`deploy`atributos](workingcookbook-json.md#workingcookbook-json-deploy) do aplicativo. Camadas personalizadas podem usar uma receita para recuperar o valor de uma variável, usando a sintaxe de nó padrão, e armazená-lo em um formato que possa ser acessado pelos aplicativos da camada. Você deve implementar uma receita personalizada que obtém os valores das variáveis de ambiente dos atributos `deploy` da instância. A receita poderá então armazenar os dados na instância em um formato que possa ser acessado pelo aplicativo, como um arquivo YAML. As definições das variáveis de ambiente de um aplicativo são armazenadas nos atributos `deploy`, nas `environment_variables` do aplicativo. O exemplo a seguir mostra a localização desses atributos para um aplicativo chamado `simplephpapp`, usando JSON para representar a estrutura do atributo. ``` { ... "ssh_users": { }, "deploy": { "simplephpapp": { "application": "simplephpapp", "application_type": "php", "environment_variables": { "USER_ID": "168424", "USER_KEY": "somepassword" }, ... } } ``` Uma receita pode obter os valores das variáveis, usando a sintaxe de nó padrão. O exemplo a seguir mostra como obter o valor `USER_ID` do JSON anterior e colocá-lo no log do Chef. ``` Chef::Log.info("USER_ID: #{node[:deploy]['simplephpapp'][:environment_variables][:USER_ID]}") ``` Para obter uma descrição mais detalhada de como recuperar informações do JSON de configuração e implantação da pilha e armazená-las na instância, consulte [Transmissão de dados para aplicativos](apps-data.md). # Transmissão de dados para aplicativos **Importante** O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support). Muitas vezes, é útil transmitir dados como pares de chave-valor a um aplicativo no servidor. Para fazer isso, use um [JSON personalizado](workingstacks-json.md) para adicionar os dados à pilha. OpsWorks O Stacks adiciona os dados ao objeto de nó de cada instância para cada evento do ciclo de vida. Observe, no entanto, que embora as receitas personalizadas possam obter os dados do JSON personalizado no objeto de nó usando atributos do Chef, os aplicativos não conseguem fazer o mesmo. Uma abordagem para a obtenção de dados do JSON personalizado para um ou mais aplicativos é implementar uma receita personalizada que extraia os dados do objeto `node` e grave-os em um arquivo que o aplicativo possa ler. O exemplo neste tópico mostra como gravar os dados em um arquivo YAML, mas você pode usar a mesma abordagem básica para outros formatos, como JSON ou XML. Para transmitir dados de chave-valor para instâncias da pilha, adicione um JSON personalizado, como o mostrado a seguir, à pilha. Para obter mais informações sobre como adicionar um JSON personalizado a uma pilha, consulte [Usar JSON personalizado](workingstacks-json.md). ``` { "my_app_data": { "app1": { "key1": "value1", "key2": "value2", "key3": "value3" }, "app2": { "key1": "value1", "key2": "value2", "key3": "value3" } } } ``` O exemplo pressupõe que você tenha dois aplicativos cujos nomes curtos são `app1` e `app2`, sendo que cada um deles tem três valores de dados. A receita associada pressupõe que você use os nomes curtos dos aplicativos para identificar os dados associados; outros nomes são arbitrários. Para obter mais informações sobre os nomes abreviados de aplicativos, consulte [Configurações](workingapps-creating.md#workingapps-creating-settings). A receita no exemplo a seguir mostra como extrair os dados para cada aplicativo dos atributos `deploy` e inseri-los em um arquivo `.yml`. A receita pressupõe que seu JSON personalizado contenha dados para cada aplicativo. ``` node[:deploy].each do |app, deploy| file File.join(deploy[:deploy_to], 'shared', 'config', 'app_data.yml') do content YAML.dump(node[:my_app_data][app].to_hash) end end ``` Os atributos `deploy` contêm um atributo para cada aplicativo, chamado pelo nome abreviado do aplicativo. Cada atributo do aplicativo contém um conjunto de atributos que representam várias informações sobre o aplicativo. Este exemplo usa o diretório de implementação do aplicativo, que é representado pelo atributo `[:deploy][:app_short_name][:deploy_to]`. Para obter mais informações sobre `[:deploy]`, consulte [Atributos deploy](attributes-json-deploy.md). Para cada aplicativo em `deploy`, a receita faz o seguinte: 1. Cria um arquivo chamado `app_data.yml` no subdiretório `shared/config` do diretório `[:deploy_to]` do aplicativo. Para obter mais informações sobre como o OpsWorks Stacks instala aplicativos, consulte. [Receitas de implantação](create-custom-deploy.md) 1. Converte os valores do JSON personalizado para YAML e grava os dados formatados em `app_data.yml`. **Para transmitir dados para um aplicativo** 1. Adicione um aplicativo à pilha e anote o nome abreviado dele. Para obter mais informações, consulte [Adição de aplicativos](workingapps-creating.md). 1. Adicione um JSON personalizado com os dados do aplicativo aos atributos `deploy`, conforme descrito anteriormente. Para obter mais informações sobre como adicionar um JSON personalizado a uma pilha, consulte [Usar JSON personalizado](workingstacks-json.md). 1. Crie um livro de receitas e adicione uma receita a ele com código baseado no exemplo anterior, modificado conforme necessário em relação aos nomes dos atributos que você usou no JSON personalizado. Para obter mais informações sobre como criar livros de receitas e receitas, consulte [Livros de receitas e receitas](workingcookbook.md). Se você já tem receitas personalizadas para esta pilha, também pode adicionar a receita a um livro de receitas, ou até mesmo adicionar o código a uma receita Implantar existente. 1. Instale o livro de receitas em sua pilha. Para obter mais informações, consulte [Instalação de livros de receitas personalizados](workingcookbook-installingcustom-enable.md). 1. Atribua a receita ao evento Deploy lifecycle da camada do servidor de aplicativos. OpsWorks As pilhas então executarão a receita em cada nova instância, após a inicialização. Para obter mais informações, consulte [Execução de receitas](workingcookbook-executing.md). 1. Implante o aplicativo, o que também instala os atributos de configuração e implantação da pilha, que agora contém seus dados. **nota** Se for necessário implantar os arquivos de dados antes da implantação do aplicativo, também é possível associar a receita ao evento de ciclo de vida Configuração da camada, o que ocorre uma vez, logo após a conclusão da inicialização da instância. No entanto, o OpsWorks Stacks ainda não criou os diretórios de implantação, portanto, sua receita deve criar os diretórios necessários explicitamente antes de criar o arquivo de dados. O exemplo a seguir cria explicitamente o diretório `/shared/config` do aplicativo e, em seguida, cria um arquivo de dados nesse diretório. ``` node[:deploy].each do |app, deploy| directory "#{deploy[:deploy_to]}/shared/config" do owner "deploy" group "www-data" mode 0774 recursive true action :create end file File.join(deploy[:deploy_to], 'shared', 'config', 'app_data.yml') do content YAML.dump(node[:my_app_data][app].to_hash) end end ``` Para carregar os dados, você pode usar algo como o seguinte código do [Sinatra](http://www.sinatrarb.com/): ``` #!/usr/bin/env ruby # encoding: UTF-8 require 'sinatra' require 'yaml' get '/' do YAML.load(File.read(File.join('..', '..', 'shared', 'config', 'app_data.yml'))) End ``` Você pode atualizar os valores dos dados do aplicativo a qualquer momento atualizando o JSON personalizado, como mostrado a seguir. **Para atualizar os dados do aplicativo** 1. Edite o JSON personalizado para atualizar os valores de dados. 1. Implante o aplicativo novamente, o que faz com que as OpsWorks pilhas executem as receitas de implantação nas instâncias da pilha. As receitas usarão os atributos atualizados de configuração e implantação da pilha, portanto, sua receita atualizará os arquivos de dados com os valores atuais. # Utilização de chaves SSH de repositório Git **Importante** O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support). Uma chave SSH de repositório Git, às vezes chamada de chave SSH de implantação, é uma chave SSH sem senha que fornece acesso a um repositório privado do Git. O ideal é que ela não pertença a um desenvolvedor específico. Seu objetivo é permitir que o OpsWorks Stacks implante aplicativos ou livros de receitas de forma assíncrona de um repositório Git sem precisar de mais informações de você. A tabela a seguir descreve o procedimento básico para a criação de uma chave SSH de repositório. Para obter detalhes, consulte a documentação do seu repositório. Por exemplo, [Gerenciar chaves de implantação](https://help.github.com/articles/managing-deploy-keys) descreve como criar uma chave SSH de repositório para um GitHub repositório, e [Chaves de implantação no Bitbucket](http://blog.bitbucket.org/2012/06/20/deployment-keys/) descreve como criar uma chave SSH de repositório para um repositório Bitbucket. Observe que alguns documentos descrevem a criação de uma chave em um servidor. Para OpsWorks Stacks, basta substituir “servidor” por “estação de trabalho” nas instruções. **Para criar uma chave SSH de repositório** 1. Crie um par de chaves SSH de implantação para o repositório Git da sua estação de trabalho usando um programa como o `ssh-keygen`. **Importante** OpsWorks O Stacks não oferece suporte a frases secretas de chave SSH. 1. Atribua a chave pública ao repositório e armazene a chave privada em sua estação de trabalho. 1. Insira a chave privada na caixa **Repository SSH Key** quando adicionar um aplicativo ou especificar um repositório de livros de receitas. Para obter mais informações, consulte [Adição de aplicativos](workingapps-creating.md). OpsWorks O Stacks passa a chave SSH do repositório para cada instância, e as receitas integradas usam a chave para se conectar ao repositório e baixar o código. A chave é armazenadas nos atributos de [`deploy`](workingcookbook-json.md) como [`node[:deploy]['appshortname'][:scm][:ssh_key]`](attributes-json-deploy.md#attributes-json-deploy-app-scm-key), e pode ser acessada apenas pelo usuário raiz. # Usando domínios predefinidos **Importante** O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support). Se você hospedar um nome de domínio com terceiros, você pode mapear esse nome de domínio para um aplicativo. O procedimento básico é como se segue: 1. Crie um subdomínio com o registrador do DNS e mapeie-o para o seu endereço IP elástico de load balancer ou para o seu endereço IP público do servidor de aplicativos. 1. Atualize a configuração do aplicativo para indicar o subdomínio e reimplantar o aplicativo. **nota** Certifique-se de encaminhar o seu nome de domínio não qualificado (como myapp1.example.com) para o seu nome de domínio completo (como www.myapp1.example.com) para que ambos sejam mapeados para seu aplicativo. Quando você configurar um domínio para um aplicativo, ele é listado como um apelido do servidor no arquivo de configuração do servidor. Se estiver usando um load balancer, o load balancer verifica o nome de domínio na URL, à medida que as solicitações chegam e redirecionam o tráfego com base no domínio. **Para mapear um subdomínio para um endereço IP** 1. Se estiver usando um load balancer, na página **Instances**, clique no load balancer da instância para abrir sua página de detalhes e obter o endereço **Elastic IP** da instância. Caso contrário, obtenha o endereço IP público a partir da página de detalhes da instância do servidor de aplicativos. 1. Siga as instruções fornecidas pelo seu registrador DNS para criar e mapear seu subdomínio para o endereço IP a partir da Etapa 1. **nota** Se o load balancer da instância for encerrada em algum momento, você será atribuído a um novo endereço IP elástico. Você precisa atualizar o registrador DNS para mapear configurações para o novo endereço IP elástico. OpsWorks O Stacks simplesmente adiciona as configurações do domínio aos [`deploy`atributos](workingcookbook-json.md#workingcookbook-json-deploy) do aplicativo. Implemente uma receita personalizada para recuperar as informações do objeto do nó e configurar o servidor adequadamente. Para obter mais informações, consulte [Livros de receitas e receitas](workingcookbook.md). # Executando vários aplicativos no mesmo servidor de aplicações **Importante** O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support). **nota** As informações neste tópico não se aplicam aos aplicativos do Node.js. Se tiver vários aplicativos do mesmo tipo, às vezes é mais econômico executá-los no mesmo servidor do aplicativo de instâncias. **Para executar vários aplicativos no mesmo servidor** 1. Adicione um aplicativo à pilha para cada aplicativo. 1. Obtenha um subdomínio separado para cada aplicativo e mapeie os subdomínios para o servidor de aplicativo ou o endereço IP do load balancer. 1. Edite cada configuração do aplicativo para especificar o subdomínio apropriado. Para obter mais informações sobre como executar essas tarefas, consulte [Usando domínios predefinidos](workingapps-domains.md). **nota** Caso seu aplicativo esteja executando vários aplicativos HTTP, o Elastic Load Balancing poderá ser usado para balanceamento de carga. Para vários aplicativos HTTPS, você deve encerrar a conexão SSL no load balancer ou criar uma pilha separada para cada aplicativo. As solicitações de HTTPS são criptografadas, o que significa que, se você encerrar a conexão SSL em servidores, o load balancer não poderá verificar o nome de domínio para determinar qual aplicativo deverá lidar com a solicitação. # Uso de SSL **Importante** O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support). Para usar o SSL com seu aplicativo, consiga um certificado digital de servidor de uma autoridade de certificação. Para simplificar, essa demonstração cria um certificado e, em seguida, autoassina ele. Os certificados autoassinados são úteis para fins de aprendizagem e teste, mas sempre use um certificado assinado por uma autoridade de certificação para pilhas de produção. Nessa demonstração, siga as seguintes instruções: 1. Instale e configure o OpenSSL. 1. Crie uma chave privada. 1. Crie uma solicitação de assinatura do certificado. 1. Gere um certificado autoassinado. 1. Edite o aplicativo com as informações do certificado. **Importante** [Se seu aplicativo usa SSL, recomendamos que você desative, se possível SSLv3, nas camadas do servidor de aplicativos para resolver as vulnerabilidades descritas em CVE-2014-3566.](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2014-3566) Caso sua pilha inclua uma camada Ganglia, desative o SSL v3 para essa camada também. Os detalhes dependem da camada em questão. Para obter mais informações, consulte o seguinte. [Camada de OpsWorks pilhas do servidor de aplicativos Java](layers-java.md) [Camada de OpsWorks pilhas do servidor de aplicativos Node.js](workinglayers-node.md) [Camada de OpsWorks pilhas do servidor de aplicativos PHP](workinglayers-php.md) [Camada de pilhas do servidor de aplicativos OpsWorks Rails](workinglayers-rails.md) [Camada estática de OpsWorks pilhas de servidores Web](workinglayers-static.md) [Camada Ganglia](workinglayers-ganglia.md) **Topics** + [Etapa 1: instalar e configurar o OpenSSL.](#w2ab1c14c57c29c15) + [Etapa 2: criar uma chave privada](#w2ab1c14c57c29c17) + [Etapa 3: criar uma solicitação de assinatura do certificado](#w2ab1c14c57c29c19) + [Etapa 4: Enviar a CSR para a autoridade de certificação](#w2ab1c14c57c29c21) + [Etapa 5: editar o aplicativo](#w2ab1c14c57c29c23) ## Etapa 1: instalar e configurar o OpenSSL. A criação e a atualização de certificados de servidores exigem uma ferramenta compatível com os protocolos SSL e TLS. OpenSSL é uma ferramenta de código aberto que fornece as funções básicas de criptografia necessárias para criar um token RSA e assinar com sua chave privada. O procedimento a seguir supõe que seu computados ainda não tem o OpenSSL instalado. **Para instalar o OpenSSL no Linux e Unix** 1. Acesse [OpenSSL: Source, Tarballs](https://www.openssl.org/source/). 1. Faça o download da fonte mais recente. 1. Construa o pacote. **Para instalar o OpenSSL no Windows** 1. Se o Pacote redistribuível do Microsoft Visual C\$1\$1 2008 não estiver instalado no seu sistema, faça o download do [pacote](https://www.microsoft.com/en-us/download/details.aspx?id=11895). 1. Execute o instalador e siga as instruções fornecidas pelo assistente de configuração do Microsoft Visual C\$1\$1 2008 Redistributable para instalar o redistributable. 1. Acesse [OpenSSL: distribuições binárias](https://www.openssl.org/community/binaries.html), clique na versão adequada dos binários do OpenSSL para o seu ambiente e salve o instalador localmente. 1. Execute o instalador e siga as instruções no **OpenSSL Setup Wizard** para instalar os binários. Crie uma variável de ambiente que aponta para o ponto de instalação do OpenSSL abrindo o terminal ou a janela de comando e usando as seguintes linhas de comando. + No Linux e Unix ``` export OpenSSL_HOME=path_to_your_OpenSSL_installation ``` + No Windows ``` set OpenSSL_HOME=path_to_your_OpenSSL_installation ``` Adicione o caminho dos binários do OpenSSL na variável de caminho do seu computador abrindo o terminal ou a janela de comando e usando as seguintes linhas de comando. + No Linux e Unix ``` export PATH=$PATH:$OpenSSL_HOME/bin ``` + No Windows ``` set Path=OpenSSL_HOME\bin;%Path% ``` **nota** Qualquer alteração feira nas variáveis do ambiente usando essas linhas de comando são válidas apenas para a seção atual de linha de comando. ## Etapa 2: criar uma chave privada Será necessário uma chave privada exclusiva para criar sua solicitação de assinatura de certificado (CSR). Crie a chave usando a seguinte linha de comando: ``` openssl genrsa 2048 > privatekey.pem ``` ## Etapa 3: criar uma solicitação de assinatura do certificado Uma solicitação de assinatura do certificado (CSR) é um arquivo enviado para uma autoridade de certificação (CA) para solicitar um certificado digital de servidor. Crie a CSR usando a seguinte linha de comando. ``` openssl req -new -key privatekey.pem -out csr.pem ``` A saída do comando será semelhante à seguinte: ``` You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ``` A tabela a seguir pode ajudar você a criar sua solicitação de certificado. **Dados da solicitação de certificado** | Name (Nome) | Descrição | Exemplo | | --- | --- | --- | | Nome do país | A abreviação ISO de duas letras para seu país. | US = Estados Unidos | | Estado | O nome do estado ou província onde sua organização está localizada. Este nome não pode ser abreviado. | Washington | | Nome da localidade | O nome da cidade onde sua organização está localizada. | Seattle | | Nome da organização | A razão social completa da sua organização. Não abrevie o nome de sua organização. | CorporationX | | Unidade organizacional | (Opcional) Para informações adicionais da sua organização. | Marketing | | Nome comum | O nome do domínio completamente qualificado para seu CNAME. Você receberá um aviso de verificação do nome do certificado se não houver correspondência. | www.exemplo.com | | Endereço de e-mail | O endereço de e-mail do administrador do servidor | someone@example.com | **nota** O campo do nome comum geralmente é mal-interpretado e completado incorretamente. O nome comum geralmente é o seu servidor mais o nome do domínio. Será semelhante a "www.example.com" ou "example.com". Será necessário criar uma CSR usando o nome comum correto. ## Etapa 4: Enviar a CSR para a autoridade de certificação Para uso na produção, é preciso obter um certificado de servidor enviando sua CSR para uma autoridade de certificação (CA), que pode exigir outras credenciais ou comprovantes de identidade. Se sua solicitação for bem-sucedida, a CA envia de volta um certificado de identidade assinado digitalmente e, possivelmente, um arquivo de cadeia do certificado. AWS não recomenda um CA específica. Para obter uma lista parcial dos disponíveis CAs, consulte [Autoridade Certificadora - Provedores](https://en.wikipedia.org/wiki/Certificate_authority#Providers) na Wikipedia. Além disso, é possível gerar um certificado autoassinado, que pode ser usado apenas para fins de teste. Para esse exemplo, use a seguinte linha de comando para gerar um certificado autoassinado. ``` openssl x509 -req -days 365 -in csr.pem -signkey privatekey.pem -out server.crt ``` A saída será semelhante à seguinte: ``` Loading 'screen' into random state - done Signature ok subject=/C=us/ST=washington/L=seattle/O=corporationx/OU=marketing/CN=example.com/emailAddress=someone@example.com Getting Private key ``` ## Etapa 5: editar o aplicativo Após gerar o seu certificado e assiná-lo, atualize seu aplicativo para ativar o SSL e forneça as informações do seu certificado. Na página **Apps (Aplicativos)**, escolha um aplicativo para abrir a página de detalhes e clique em **Edit App (Editar aplicativo)**. Para ativar o suporte ao SSL, defina **Enable SSL (Habilitar SSL)** como **Yes (Sim)**, que exibe as seguintes opções de configuração. **SSL Certificate (Certificado SSL)** Cole o conteúdo do arquivo do certificado da chave pública (.crt) na caixa. O certificado deve ser semelhante ao seguinte: ``` -----BEGIN CERTIFICATE----- MIICuTCCAiICCQCtqFKItVQJpzANBgkqhkiG9w0BAQUFADCBoDELMAkGA1UEBhMC dXMxEzARBgNVBAgMCndhc2hpbmd0b24xEDAOBgNVBAcMB3NlYXR0bGUxDzANBgNV BAoMBmFtYXpvbjEWMBQGA1UECwwNRGV2IGFuZCBUb29sczEdMBsGA1UEAwwUc3Rl cGhhbmllYXBpZXJjZS5jb20xIjAgBgkqhkiG9w0BCQEWE3NhcGllcmNlQGFtYXpv ... -----END CERTIFICATE----- ``` Caso esteja usando o Nginx e tenha um arquivo de cadeia do certificado, acrescente o conteúdo no arquivo do certificado da chave pública. Se estiver atualizando um certificado existente, siga as seguintes instruções: + Escolha **Update SSL certificate (Atualizar certificado SSL)** para atualizar o certificado. + Caso o novo certificado não corresponda à chave privada existente, escolha **Update SSL certificate key (Atualizar chave de certificado SSL)**. + Caso o novo certificado não corresponda à cadeia de certificado existente, escolha **Update SSL certificates (Atualizar certificados SSL)**. **SSL Certificate Key (Chave de certificado SSL)** Cole o conteúdo do arquivo do certificado da chave privada (.pem) na caixa. Ela deve ser parecida com a seguinte: ``` ----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQC0CYklJY5r4vV2NHQYEpwtsLuMMBhylMrgBShKq+HHVLYQQCL6 +wGIiRq5qXqZlRXje3GM5Jvcm6q0R71MfRIl1FuzKyqDtneZaAIEYniZibHiUnmO /UNqpFDosw/6hY3ONk0fSBlU4ivD0Gjpf6J80jL3DJ4R23Ed0sdL4pRT3QIDAQAB AoGBAKmMfWrNRqYVtGKgnWB6Tji9QrKQLMXjmHeGg95mppdJELiXHhpMvrHtpIyK ... -----END RSA PRIVATE KEY----- ``` **SSL certificates of Certification Authorities** Se tiver um arquivo de cadeia do certificado, cole o conteúdo na caixa. Se estiver usando Nginx, deixe a caixa em branco. Se tiver um arquivo de cadeia do certificado, acrescente-o no arquivo do certificado da chave pública em **SSL Certificate Key (Chave de certificado SSL)**. ![\[SSL Settings interface with options for SSL Suporte, Certificate, Key, and Certification Authorities.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/app_ssl_settings.png) Depois de clicar em **Save**, [refaça a implantação do aplicativo](workingapps-deploying.md) para atualizar suas instâncias online. Para as [camadas integradas do servidor de aplicativos](workingcookbook-json.md#workingcookbook-json-deploy), o OpsWorks Stacks atualiza automaticamente a configuração do servidor. Após o término da implantação, verifique se a instalação do OpenSSL funcionou da seguinte maneira. **Para verificar a instalação de um OpenSSL** 1. Acesse a página **Instances**. 1. Execute o aplicativo clicando no endereço de IP da instância do servidor do aplicativo ou, se estiver usando um load balancer, o endereço de IP do load balancer. 1. Altere o prefixo do endereço de IP de **http://** para **https://** e atualize o navegador para verificar se a página carrega corretamente com o SSL. Os usuários que têm aplicativos configurados para serem executados no Mozilla Firefox às vezes recebem o seguinte erro no certificado: `SEC_ERROR_UNKNOWN_ISSUER`. Esse erro pode ser causado pela funcionalidade de substituição do certificado nos programas antivírus e antimalware de sua organização, por alguns tipos de monitoramento de tráfego de rede e software de filtragem ou por malware. Para obter mais informações sobre como solucionar esse erro, consulte [Como solucionar problemas de códigos de erro de segurança em sites seguros](https://support.mozilla.org/en-US/kb/error-codes-secure-websites?redirectlocale=en-US&redirectslug=troubleshoot-SEC_ERROR_UNKNOWN_ISSUER#w_monitoringfiltering-in-corporate-networks) no site de suporte do Mozilla Firefox. Para todas as outras camadas, incluindo as personalizadas, o OpsWorks Stacks simplesmente adiciona as configurações do SSL aos atributos [`deploy`](workingcookbook-json.md#workingcookbook-json-deploy) do aplicativo. Implemente uma receita personalizada para recuperar as informações do objeto do nó e configurar o servidor adequadamente.