Um dos desafios mais frustrantes no desenvolvimento de aplicações hoje em dia é a paridade de ambiente. Enquanto os últimos anos têm mostrado que ferramentas de virtualização e contentorização como Vagrant e Docker (e a própria Ferramenta de Estado do ActiveState) podem garantir que os sistemas operacionais e dependências que alimentam a infra-estrutura de um aplicativo sejam consistentes entre ambientes, as dependências externas são todas – mas impossíveis de replicar em um ambiente sem produção.
Em um mundo onde as dependências de terceiros se tornaram irreversivelmente interligadas com a lógica central do negócio de quase todos os projetos de software, está se tornando cada vez mais difícil manter os ambientes de desenvolvimento, encenação e produção consistentes uns com os outros. Enquanto alguns produtos com lookalikes auto-hospedados – como o Minio para o Amazon S3 – aliviam a dor do gerenciamento de múltiplas implantações de um único serviço, pouco faz para amenizar o desafio do gerenciamento de configurações entre ambientes.
Quando a Produção, a Preparação, o Desenvolvimento, a Máquina Local do Bob e o Ambiente QE requerem uma implantação diferente de um determinado serviço, a passagem de arquivos de configuração para frente e para trás, ou confiar em condicionantes complexos para determinar com qual implantação um determinado ambiente deve falar, torna-se cada vez mais impraticável. A necessidade de flexibilidade também destaca a dificuldade dessas soluções em um ambiente de larga escala. E se, por exemplo, a Máquina Local do Bob precisar falar temporariamente com um serviço que esteja reservado para o ambiente Staging?
Ambiente Variáveis em Python
Configuração de ambiente cruzado é uma dor, mas felizmente os problemas descritos acima se tornaram comuns o suficiente nos últimos anos para que todos eles sejam resolvidos. Graças ao suporte da comunidade de código aberto, e ao evangelismo de melhores práticas como a aplicação de 12 fatores, tem havido uma mudança nos últimos anos do gerenciamento de configuração de aplicações baseadas em arquivos para o gerenciamento de configuração baseado em variáveis de ambiente.
Disponível em todos os sistemas operacionais principais, variáveis de ambiente são – como seu nome implica – variáveis que são implementadas no nível do ambiente para definir a forma como as aplicações rodando abaixo dele devem se comportar. Em termos mais simples, elas são variáveis agnósticas de aplicação que são gerenciadas fora do contexto de um determinado processo. A principal vantagem de usar variáveis de ambiente é que isto permite aos desenvolvedores definir como uma aplicação deve rodar sem alterar uma linha de código.
Por exemplo, se a Máquina Local do Bob precisa falar com o serviço CDN que é reservado para o ambiente Staging, ele pode alterar a variável de ambiente CDN_URL para refletir o que é definido em Staging sem ter que tocar em nenhum código gerenciado. Mais importante, isto permite ao Bob definir mock ou serviços internos para uso com testes de unidade e integração, tudo sem ter que escrever uma única linha de código extra.
Definindo Variáveis de Ambiente
Embora o ato de definir variáveis de ambiente seja geralmente dependente do SO, a grande maioria das linguagens de programação tem abstraído essas diferenças através do uso de pacotes de desenvolvimento como o projeto dotenv do Python. Por exemplo, ao invés de ter que definir uma variável de ambiente API_USER ao nível do SO, um arquivo .env localmente gitignado pode manter variáveis de ambiente através de ambientes de desenvolvimento. Isto permite aos programadores utilizar um ficheiro de configuração gerido localmente para definir variáveis de ambiente, ao mesmo tempo que permite a configuração via variáveis de ambiente “verdadeiras” em ambientes não-desenvolvidos.
Como exemplo, aqui está um simples ficheiro .env que um programador pode utilizar no seu ambiente local:
APP_ENVIRONMENT=localAPP_NAME=localhostQUEUE_DRIVER=syncAPI_USER=bob
No lado oposto, o ambiente de Produção pode definir as suas variáveis de ambiente dentro de um Dockerfile, ambos os quais são métodos válidos para manter variáveis de ambiente.
Retrieving Environment Variables
Independentemente de como as variáveis de ambiente são definidas, elas podem sempre ser recuperadas em Python usando o método os.getenv():
import os# Get environment variablesUSER = os.getenv('API_USER')
Notem que, caso a variável de ambiente não esteja definida, o valor será o padrão para None.
Começar com Segredos
Agora, enquanto variáveis de ambiente são uma excelente solução para gerenciar configurações díspares entre ambientes, elas não são uma bala de prata. No clima de desenvolvimento atual, a segurança deve ser uma prioridade máxima, e os dados sensíveis devem ser mantidos de forma segura.
Felizmente, as variáveis de ambiente por si só não são seguras. Enquanto eles fazem um ótimo trabalho de armazenamento de dados de configuração, a forma como definimos dados mais sensíveis como senhas, chaves API e chaves de criptografia deve exigir mais cuidado. É aqui que os segredos entram em jogo. Criptografados em repouso, os segredos só devem ser recuperados em um único tempo de execução, conforme necessário, a fim de reduzir as chances de uma violação de dados. Desta forma, mesmo que o seu provedor de hospedagem fique comprometido, você pode ter certeza de que seus segredos confidenciais estão bem guardados.
Criar &Gerenciar segredos com a Ferramenta de Estado
Então, como nós criamos e gerenciamos segredos? Embora existam várias formas diferentes de resolver este problema, a Ferramenta de Estado do ActiveState é uma excelente solução para a linguagem Python. Similar a virtualenv ou pipenv, a State Tool é uma interface de gerenciamento de ambiente virtual que irá evitar a contaminação cruzada de instalações e configurações Python entre projetos. O que a diferencia de outras ferramentas de gerenciamento de ambiente virtual é sua integração com a plataforma ActiveState, permitindo uma interface central para gerenciar configurações de ambiente e, sim, segredos.
Antes de podermos aproveitar as capacidades de gerenciamento de segredos da Ferramenta de Estado, precisamos primeiro usar a Ferramenta de Estado para configurar um ambiente virtual dentro do nosso diretório de projetos. Para fazer isso, primeiro identifique o projeto ActiveState com o qual você estará trabalhando (para este tutorial, você pode usar meu projeto zachflower/envs-vs-secrets-demo desde que você tenha uma conta ActiveState Platform gratuita, ou você pode criar a sua própria). Depois, execute o comando state activate para o seu projecto:
$ state activate zachflower/envs-vs-secrets-demo Where would you like to checkout zachflower/envs-vs-secrets-demo? /home/zach/Projects/miscellaneous/activestate-variables/zachflower/envs-vs-secrets-demoActivating state: zachflower/envs-vs-secrets-demoThe State Tool is currently in beta, we are actively changing and adding features based on developer feedback.Downloading required artifactsDownloading 1 / 1 Installing 0 / 1 0 %You are now in an 'activated state', this will give you a virtual environment to work in that doesn't affect the rest of your system.Your 'activated state' allows you to define scripts, events and constants via the activestate.yaml file at the root of your project directory.To expand your language and/or package selection, or to define client-side encrypted secrets, please visit https://platform.activestate.com/zachflower/envs-vs-secrets-demo.To try out scripts with client-side encrypted secrets we've created a simple script for you in your activestate.yaml, try it out by running 'helloWorld'
Como pode ver, o comando activate configura o ambiente virtual tal como definido no seu projecto ActiveState. Caso o projeto ainda não tenha sido configurado, um simples projeto será semeado com parâmetros padrão para fornecer-lhe um exemplo de como tudo deve ir junto. Esta configuração é armazenada em um arquivo na raiz do diretório do seu projeto chamado activestate.yaml.
Arquivo de Configuração para Segredos & Mais
O arquivo activestate.yaml define um tempo de execução de desenvolvimento sob o qual sua aplicação será executada. Por exemplo, o padrão define um script simples que utiliza um segredo, assim como alguns poucos ouvintes de eventos que executam ações sempre que um evento definido ocorre:
project: https://platform.activestate.com/zachflower/envs-vs-secrets-demoscripts:# This script uses a secret. Note that you can define your own secrets at# https://platform.activestate.com/zachflower/envs-vs-secrets-demo/scripts - name: helloWorld value: echo ${secrets.user.world}events: # This is the ACTIVATE event, it will run whenever a new virtual environment is created (eg. by running `state activate`) # On Linux and macOS this will be ran as part of your shell's rc file, so you can use it to set up aliases, functions, environment variables, etc. - name: ACTIVATE constraints: os: macos,linux value: | echo "You are now in an 'activated state', this will give you a virtual environment to work in that doesn't affect the rest of your system." echo "" echo "Your 'activated state' allows you to define scripts, events and constants via the activestate.yaml file at the root of your project directory." echo "" echo "To expand your language and/or package selection, or to define client-side encrypted secrets, please visit https://platform.activestate.com/zachflower/envs-vs-secrets-demo." echo "" echo "To try out scripts with client-side encrypted secrets we've created a simple script for you in your activestate.yaml, try it out by running 'helloWorld'"
Embora não haja nada particularmente inovador aqui, o poder potencial deste arquivo deve ser imediatamente óbvio. Por exemplo, o seguinte script fornece um exemplo básico de como utilizar segredos no ficheiro de configuração:
scripts:# This script uses a secret. Note that you can define your own secrets at# https://platform.activestate.com/zachflower/envs-vs-secrets-demo/scripts - name: helloWorld value: echo ${secrets.user.world}
Quando o comando helloWorld é executado (a partir de um estado activado), irá ecoar o valor do user.world secreto e, no caso do segredo ainda não estar definido, irá pedir um valor:
$ helloWorldThe action you are taking uses a secret that has not been given a value yet.Name: worldDescription: - (This secret has no description, you can set one via the web dashboard)Scope: user (Only you can access the value) Please enter a value for secret "world": ******
Using Secrets
Embora o exemplo seja relativamente simplista, o verdadeiro valor dos segredos vem dos eventos de ativação. Ao invés de recuperar um valor secreto dentro do contexto de um script, variáveis de ambiente podem ser definidas usando segredos recuperados sem nunca expor esses segredos fora desse ambiente seguro:
project: https://platform.activestate.com/zachflower/envs-vs-secrets-demo?commitID=5fd1c161-c5a4-480c-8aba-29d8ab361b42events: - name: ACTIVATE constraints: os: macos,linux value: | export WORLD=${secrets.user.world}
Agora, se o segredo user.world estiver definido, então a variável de ambiente WORLD será definida e poderá ser recuperada como qualquer outra variável de ambiente:
$ echo $WORLDworld!
No entanto, se não estiver definida, então o usuário será solicitado a defini-la na ativação do ambiente virtual ActiveState:
The action you are taking uses a secret that has not been given a value yet.Name: helloDescription: - (This secret has no description, you can set one via the web dashboard)Scope: user (Only you can access the value) Please enter a value for secret "world": ******
Pretty cool, certo?
>
Precisando mais
A gestão da configuração no desenvolvimento de aplicações é, na sua maioria, um problema resolvido, mas a gestão de segredos ainda não está resolvida. O número de projectos que verificaram dados sensíveis num repositório de controlo de versões é espantoso, e é algo que até empresas altamente respeitadas têm feito, mas através do uso de produtos e higiene de segurança adequados, como a Ferramenta de Estado do ActiveState, manter os dados de configuração sensíveis seguros e protegidos está a tornar-se mais fácil a cada dia.
- Tente você mesmo criando uma conta ActiveState Platform grátis e baixando a State Tool para simplificar o gerenciamento de segredos.
- Você também pode assistir nosso webinar sobre como gerenciar segredos compartilhados usando a State Tool
>
Blogs relacionados:
O segredo para gerenciar segredos compartilhados
Desenvolvedores podem compartilhar segredos rápida e facilmente sem sacrificar a segurança