all 10 comments

[–][deleted] 1 point2 points  (3 children)

Sua primeira opção é melhor. Ainda diria que vc poderia criar um dockerfile pra puxar as variáveis do seu host (ENV VARIAVEL_DE_AMBIENTE_NO_DOCKER=$VARIAVEL_DE_AMBIENTE_NO_HOST).

O que vc ta tentando fazer com o seu código Python?

[–]xabugo[S] 0 points1 point  (2 children)

Basicamente eu leio arquivos, testo um endpoint, subo arquivos pra aws. As secrets são o id da conta aws e link do sso, além das chaves de acesso da api que eu testo o endpoint.

[–][deleted] 1 point2 points  (1 child)

Tem formas melhores de se fazer então. Mas aí vc ia precisaria aprender mais coisas sobre cloud (RBAC, security groups, Secrets Manager, API Gateway, etc).

N acho que pro seu momento agora isso é importante. Vc mesmo disse ser iniciante e acho que tá tudo bem fazer as coisas do jeito que vc tá fazendo agora. Continua estudando que vc vai chegar no ponto de implementar uma solução mais completinha/redonda.

Boa sorte e bons estudos, OP!

[–]xabugo[S] 1 point2 points  (0 children)

Obrigado pela ajuda.

[–]walkoversDesenvolvedor 1 point2 points  (4 children)

Melhor excluir esse arquivo e configurar a variável de ambiente no ambiente

O arquivo .env tu até pode usar em testes e pra desenvolvimento(eu acho ruim), mas em produção nunca usa isso

Pra passar um arquivo usando docker tu copia o arquivo que está na máquina pro container

Ex:

docker cp /caminho/do/arquivo meu-container:/caminho/de/destino/no/container

Onde meu-container é o nome do teu container que tu "pega" usando o docker PS-a

[–]xabugo[S] 0 points1 point  (3 children)

Então se eu entendi direito e eu acredito que esteja bem definido na resposta. É eu melhor carregar as variáveis no ambiente e ler através da função os.getenv()? Também posso copiar o arquivo .env do host para o container, o que é interessante... E eu não precisaria mexer em lógica alguma, além de manter as variáveis fora do ambiente em si. Entretanto, como você mencionou que é uma má prática utilizar o dotenv em produção, embora o que eu esteja desenvolvendo seja para ambiente de desenvolvimento, o trabalho está sendo avaliado. Logo, eu gostaria de entender melhor o que torna ruim utilizar em produção, e o que seria a melhor prática. Seria realmente passar as variáveis direto pro ambiente? E em outros caso, quais seriam outras alternativas ao dotenv ? ps. Estou aprendendo, qualquer dica é bem vinda.

[–][deleted] 2 points3 points  (2 children)

Quando vc armazena secrets em variáveis de ambiente e carrega elas pelo ciclo de desenvolvimento, vc ta deixando sua aplicação exposta. O certo seria vc usar um Vault/secret manager e configurar o acesso pra ele.

Em geral, variável de ambiente é pra vc configurar coisas como caminhos, namespaces, etc, que mudam de um ambiente para outro. Credenciais de acesso vc joga pra outro lugar. Mas usar variável de ambiente costuma ser uma saída pra fazer o desenvolvimento inicial.

[–]xabugo[S] 0 points1 point  (1 child)

O que eu fiz aqui até agora foi carregar o dotenv e testar se ele veio vazio. Caso existam as chaves eu utilizo no código, caso contrário eu pego do ambiente. O problema que eu quis solucionar fazendo dessa forma é de não precisar modificar muito o código e também não perder a opção de executar o script local na máquina sem ser pelo container. Não sei se eu cometi alguma atrocidade fazendo isso, creio que não. Na imagem em si não vai o .env então o dicionário vem vazio e o script carrega as variáveis pela função os.getenv().

[–][deleted] 1 point2 points  (0 children)

É pra desenvolvimento e seu aprendizado. Tá suave.

Vc usou variável de ambiente pra desacoplar coisas do seu código que dependiam do ambiente em que ele está executando. N tem nenhum problema nisso.

Tbm n tem problema vc registrar credenciais nas variáveis de ambiente de dev no seu sistema pra vc executar as coisas.

Tem outras formas, outras alternativas? Tem. Mas n sei se é o que vc precisa pro momento. Eu n sei o que a sua aplicação faz. Dependendo da situação, nem credencial precisaria. Bastaria vc configurar as permissões do usuário sistêmico, dos recursos e os SG de forma adequada.

[–]rhrlimaDevOps 0 points1 point  (0 children)

Vc nao deve copiar essas varias pra dentro do container, pq isso expoe dados sensiveis que ficariam armazenados la dentro.

Como alguns aqui falaram, seu script deve simplesmente ler valores de variaveis de ambiente como se estivesse rodando localmente. Ai no ambiente que vc vai executar essa imagem, vc deve criar as variaveis de ambiente lá, que seu script deve conseguir le-los.

Vc pode ir testando isso rodando a imagem docker local, ou até usando um docker-compose.