A sinopse do Amazon Elastic Beanstalk diz:
O Elastic Beanstalk permite "abrir o capô" e manter o controle total ... até mesmo passar variáveis ​​de ambiente através do console do Elastic Beanstalk.
Como passar outras variáveis ​​de ambiente além daquela na configuração do Elastic Beanstalk?
amazon-web-services app-config amazon-elastic-beanstalk
convém alterar a resposta aceita sobre isso #
Como aviso para quem usa o .ebextensions/*.configcaminho: hoje em dia você pode adicionar, editar e remover variáveis ​​de ambiente na interface da web do Elastic Beanstalk.
As variáveis ​​estão em Configuração → Configuração do software:
Criar os vars .ebextensionscomo na resposta do Onema ainda funciona.
Pode até ser preferível, por exemplo, se você implantar em outro ambiente mais tarde e tiver medo de esquecer de defini-los manualmente ou se concordar em confirmar os valores no controle de origem. Eu uso uma mistura de ambos.
Como alternativa, você também pode salvar a configuração e iniciar o novo ambiente usando a configuração.
— 22713 Michael Gallego
Sim, eu diria que é a melhor opção. Eu apenas continuo esquecendo e lancei novos ambientes, quer queira quer não. :)
@dingdong: sim, e em particular você pode acessá-los em seu aplicativo. Por exemplo, no Rails ENV["CUSTOM_ENV"]retornaria "something-something".
Se eu adicionar novas propriedades ou alterar um valor da propriedade, elas estarão imediatamente disponíveis, elas exigem que algo seja reiniciado etc.? Recentemente, alterei o tamanho de um grupo de dimensionamento automático e a AWS encerrou quase todas as 40 instâncias e criou 45 novas. Não quero que isso aconteça se adicionar uma nova propriedade a um ambiente existente. Alguma ideia?
— Engineer81
Cuidado com as mudanças recentes. De acordo com esta resposta , eles não são passados ​​como variáveis ​​de ambiente. Eles só são passados como propriedades do sistema
Apenas 5 valores são limitantes ou você pode querer ter um nome de variável de ambiente customizado. Você pode fazer isso usando os arquivos de configuração. Crie um diretório na raiz do seu projeto chamado
Em seguida, crie um arquivo chamado environment.config (esse arquivo pode ser chamado de qualquer coisa, mas deve ter a extensão .config) e adicione os seguintes valores
Depois de implantar seu aplicativo, você verá esse novo valor em Detalhes do ambiente -> Editar configuração -> Contêiner
para obter mais informações, consulte a documentação aqui: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html#customize-containers-format-options
Para evitar comprometer os valores do seu repositório, como chaves de API, segredos e assim por diante, você pode colocar um valor de espaço reservado.
Posteriormente, você pode acessar o painel de administração da AWS (Detalhes do ambiente -> Editar configuração -> Contêiner) e atualizar os valores lá. Na minha experiência, esses valores não mudam após implantações subsequentes.
Atualização 2 Como @Benjamin afirmou em seu comentário, desde que a nova aparência foi lançada em 18 de julho de 2013, é possível definir qualquer número de variáveis ​​de ambiente diretamente do console:
@Onema - Como você lida com a adição de novas chaves ao arquivo de configuração? O envio do arquivo atualizado atualizará todas as chaves definidas anteriormente com valores de espaço reservado?
@Tabrez, todas as chaves definidas anteriormente manterão seus valores.
Desculpe @Tabrez, eu não tive a chance de analisar isso antes. Para adicionar à resposta da Anarchtica, executei um teste e descobri que se você usa um espaço reservado e atualiza os valores no Console da AWS usando chaves reais e atualiza os valores do espaço reservado no arquivo de configuração e pressiona, as chaves não serão substituído pelo novo espaço reservado. Acho isso um pouco estranho, mas acho que é um comportamento bem-vindo, pois você terá força para gerenciar todos os valores env no console.
@ Anarchtica, perguntei sobre esse comportamento ao suporte da AWS. Eles disseram que depois que você atualizar os valores no console, eles terão precedência e você não poderá modificá-los usando os arquivos de configuração. Se você nunca alterar os valores no console, quaisquer alterações feitas no arquivo de configuração serão atualizadas.
Alguém sabe como usar as variáveis ​​de ambiente dentro do seu arquivo de configuração para container_commands? Eu tenteicommand: "nrsysmond-config --set license_key={$NR_INSTALL_KEY}"
Na AMI do Java8 Tomcat8 de 2016, o ElasticBeanstalk falha ao definir variáveis ​​de ambiente a partir da configuração da web. Eles estão realmente configurando as propriedades jvm -D.
- "As seguintes propriedades são passadas para o aplicativo como variáveis ​​de ambiente. Saiba mais."
Esta declaração está incorreta para o Java Tomcat ami. A Amazon não as define como variáveis ​​de ambiente. Eles são definidos como propriedades do sistema transmitidas na linha de comandos para o Tomcat como uma propriedade -D para jvm. O método em Java para obter variáveis ​​de ambiente não é o mesmo para obter uma propriedade. System.getenv vs System.getProperty
Entrei na caixa e verifiquei que a variável de ambiente nunca foi definida. No entanto, nos logs do tomcat, posso ver que a propriedade -D está configurada.
Alterei meu código para verificar os dois locais agora como uma solução alternativa.
— Ed J
E para .Net, eles são inseridos no seu arquivo web.config em vez de colocados em vários ambientes, conforme stackoverflow.com/a/33465765/1991614 . Além disso confundir a questão é que eles não são inseridos se essa chave já existe no web.confg :(
— bitcoder
Você é meu herói! Obrigado por perceber o mapeamento da propriedade -D no Tomcat 8.
Para pessoas como eu que realmente precisam definir variáveis ​​de ambiente do sistema, é possível recuperar essas propriedades do ambiente usando um script de beanstalk interno. Veja esta resposta para obter mais informações: serverfault.com/a/770736/292741
— BoomShadow 8/17
Amazon Linux 2017.03 v2.5.4 with Java8também não define env.
— Sanoob 22/09
Você não pode fazer o SSH na caixa e ver as variáveis. Eles são definidos apenas no shell que executou seu aplicativo. docs.aws.amazon.com/elasticbeanstalk/latest/dg/… In general, however, environment properties are passed only to the application and can't be viewed by connecting an instance in your environment and running env. Suas variáveis ​​não estão definidas em um script de login como .bashrc. No entanto, você está correto. As variáveis ​​do Tomcat são passadas como propriedades. (Veja o topo da página vinculada.)
A AWS interpretará as seqüências de modelos do CloudFormation em suas variáveis ​​de ambiente. Você pode usar isso para acessar informações sobre o seu ambiente EB dentro do seu aplicativo:
Na interface da web da AWS, o seguinte será avaliado como o nome do seu ambiente (observe as marcas anteriores):
Ou, você pode usar .ebextensions/*.confige envolver o modelo CloudFormation em back ticks (`):
— George Brassey
Obscuro, mas exatamente o que eu estava procurando.
Existe documentação para isso? Eu não consigo encontrá-lo.
@yangmillstheory docs.aws.amazon.com/elasticbeanstalk/latest/dg/…
— mike mckechnie
Como alternativa, você pode usar a CLI do Elastic Beanstalk para definir variáveis ​​de ambiente.
Para definir uma variável de ambiente: eb setenv FOO=bar
Para visualizar as variáveis ​​de ambiente: eb printenv
Detalhes do ambiente -> Editar configuração -> Contêiner
Esta parece ser a única maneira de definir ENVs com valores dinâmicos no pé de feijão. Eu vim com uma solução alternativa que funciona para minha configuração de várias janelas de encaixe:
1) Adicione isso ao seu Dockerfile antes de criar + fazer upload no seu repositório ECS:
2) No seu arquivo Dockerrun.aws.json, crie um volume:
3) Monte o volume no seu contêiner
4) No seu arquivo .ebextensions / options.config, adicione um bloco container_commands da seguinte maneira:
5) eb deploy e seu ENVS deve estar disponível no contêiner do docker
Você pode adicionar mais ENVs adicionando mais comandos container_ como:
— Dsorensen
Lifesaver. Se você tiver variáveis ​​de ambiente dinâmicas, por exemplo, o valor X: '{"Ref": "MyCache"} 'não será analisado (o valor é apenas ' {"Ref": "MyCache"}') por padrão quando o contêiner tentar acessá-lo. Com isso, você pode ter variáveis ​​dinâmicas como essa.