Una dintre cele mai frustrante provocări în dezvoltarea de aplicații din zilele noastre este paritatea de mediu. În timp ce ultimii ani au arătat că instrumentele de virtualizare și containerizare, cum ar fi Vagrant și Docker (și propriul instrument State Tool de la ActiveState), pot asigura că sistemele de operare și dependențele care alimentează infrastructura unei aplicații sunt consecvente între medii, dependențele externe sunt aproape imposibil de replicat într-un mediu care nu este de producție.
Într-o lume în care dependențele de la terți au devenit ireversibil împletite cu logica de bază a afacerii din aproape fiecare proiect software, devine din ce în ce mai dificil să păstrezi mediile de dezvoltare, de staging și de producție consecvente între ele. În timp ce unele produse cu variante de autogospodărire – cum ar fi Minio pentru Amazon S3 – ușurează durerea de a gestiona mai multe implementări ale unui singur serviciu, nu face prea mult pentru a ușura provocarea gestionării configurației între medii.
Când producția, stadiul de pregătire, dezvoltarea, mașina locală a lui Bob și mediul QE necesită toate o implementare diferită a unui anumit serviciu, transmiterea fișierelor de configurare înainte și înapoi sau bazarea pe condiționalități complexe pentru a determina cu ce implementare ar trebui să vorbească un anumit mediu devine din ce în ce mai nepractică. Nevoia de flexibilitate evidențiază, de asemenea, dificultatea acestor soluții într-un mediu la scară largă. Ce se întâmplă dacă, de exemplu, Mașina locală a lui Bob trebuie să vorbească temporar cu un serviciu care este rezervat pentru mediul Staging?
Variabile de mediu în Python
Configurarea între medii este o pacoste, dar, din fericire, problemele prezentate mai sus au devenit suficient de comune în ultimii ani pentru a fi aproape rezolvate. Mulțumită sprijinului comunității open source și a evanghelizării celor mai bune practici, cum ar fi aplicația cu 12 factori, în ultimii ani a avut loc o trecere de la gestionarea configurației aplicațiilor pe bază de fișiere la gestionarea configurației pe bază de variabile de mediu.
Disponibile în toate sistemele de operare importante, variabilele de mediu sunt – așa cum le spune și numele – variabile care sunt implementate la nivelul mediului pentru a defini modul în care trebuie să se comporte aplicațiile care rulează sub acesta. În termeni mai simpli, acestea sunt variabile agnostice pentru aplicații care sunt gestionate în afara contextului unui anumit proces. Principalul avantaj al utilizării variabilelor de mediu este că acest lucru permite dezvoltatorilor să definească modul în care ar trebui să ruleze o aplicație fără a modifica o linie de cod.
De exemplu, dacă Mașina locală a lui Bob trebuie să vorbească cu serviciul CDN care este rezervat pentru mediul Staging, el poate modifica variabila de mediu CDN_URL pentru a reflecta ceea ce este definit în Staging fără a fi nevoit să atingă niciun cod gestionat. Mai important, acest lucru îi permite lui Bob să definească servicii simulate sau interne pentru a le utiliza cu testele unitare și de integrare, toate acestea fără a fi nevoit să scrie o singură linie de cod suplimentar.
Definirea variabilelor de mediu
În timp ce actul de definire a variabilelor de mediu depinde, în general, de sistemul de operare, marea majoritate a limbajelor de programare au abstractizat aceste diferențe prin utilizarea pachetelor de dezvoltare precum proiectul dotenv de la Python. De exemplu, mai degrabă decât să fie nevoie să se definească o variabilă de mediu API_USER la nivelul sistemului de operare, un fișier .env gitignored local poate menține variabilele de mediu în toate mediile de dezvoltare. Acest lucru permite dezvoltatorilor să utilizeze un fișier de configurare gestionat la nivel local pentru stabilirea variabilelor de mediu, permițând în același timp configurarea prin intermediul variabilelor de mediu „adevărate” în mediile care nu sunt de dezvoltare.
Ca exemplu, iată un fișier .env simplu pe care un dezvoltator îl poate utiliza în mediul său local:
APP_ENVIRONMENT=localAPP_NAME=localhostQUEUE_DRIVER=syncAPI_USER=bob
Pe de altă parte, mediul de producție își poate defini variabilele de mediu în cadrul unui fișier Docker, ambele fiind metode valide pentru menținerea variabilelor de mediu.
Retragerea variabilelor de mediu
Indiferent de modul în care sunt definite variabilele de mediu, acestea pot fi întotdeauna recuperate în Python folosind metoda os.getenv():
import os# Get environment variablesUSER = os.getenv('API_USER')
Rețineți că, în cazul în care variabila de mediu este nedefinită, valoarea va fi implicit None.
Începând cu Secretele
Acum, în timp ce variabilele de mediu sunt o soluție excelentă pentru gestionarea configurațiilor disparate între medii, ele nu sunt un glonț de argint. În climatul de dezvoltare de astăzi, securitatea trebuie să fie o prioritate absolută, iar datele sensibile trebuie păstrate într-un mod sigur.
Din păcate, variabilele de mediu în sine nu sunt sigure. Deși fac o treabă foarte bună în ceea ce privește stocarea datelor de configurare, modul în care definim datele mai sensibile, cum ar fi parolele, cheile API și cheile de criptare, ar trebui să necesite mai multă atenție. Aici intră în joc secretele. Criptate în repaus, secretele ar trebui să fie recuperate doar într-o singură perioadă de execuție, după cum este necesar, pentru a reduce șansele unei încălcări a datelor. În acest fel, chiar dacă furnizorul dvs. de găzduire este compromis, puteți fi siguri că secretele dvs. sensibile sunt bine închise.
Crearea & Gestionarea secretelor cu instrumentul State Tool
Deci, cum creăm și gestionăm secretele? Deși există o serie de moduri diferite de a aborda această problemă, instrumentul State Tool de la ActiveState este o soluție excelentă pentru limbajul Python. Similar cu virtualenv sau pipenv, State Tool este o interfață de gestionare a mediului virtual care va preveni contaminarea încrucișată a instalațiilor și configurațiilor Python între proiecte. Ceea ce îl diferențiază de alte instrumente de gestionare a mediului virtual este integrarea sa cu platforma ActiveState, permițând o interfață centrală pentru gestionarea configurațiilor de mediu și, da, a secretelor.
Înainte de a putea profita de capacitățile de gestionare a secretelor din State Tool, trebuie mai întâi să folosim State Tool pentru a configura un mediu virtual în directorul proiectului nostru. Pentru a face acest lucru, mai întâi identificați proiectul ActiveState cu care veți lucra (pentru acest tutorial, puteți folosi proiectul meu zachflower/envs-vs-secrets-demo atâta timp cât aveți un cont gratuit ActiveState Platform, sau vă puteți crea propriul proiect). Apoi, executați comanda state activate pentru proiectul dat:
$ 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'
După cum puteți vedea, comanda activate setează mediul virtual așa cum este definit în proiectul ActiveState. În cazul în care proiectul nu a fost încă configurat, un proiect simplu va fi însămânțat cu parametri impliciți pentru a vă oferi un exemplu despre cum ar trebui să meargă totul împreună. Această configurație este stocată într-un fișier la rădăcina directorului proiectului dvs. numit activestate.yaml.
Fisier de configurare pentru secrete & Mai mult
Fisierul activestate.yaml definește un timp de execuție de dezvoltare sub care va rula aplicația dumneavoastră. De exemplu, cel implicit definește un script simplu care utilizează un secret, precum și câțiva ascultători de evenimente care efectuează acțiuni ori de câte ori apare un eveniment definit:
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'"
În timp ce nu există nimic deosebit de revoluționar aici, puterea potențială a acestui fișier ar trebui să fie imediat evidentă. De exemplu, următorul script oferă un exemplu de bază privind modul de utilizare a secretelor din fișierul de configurare:
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}
Când comanda helloWorld este executată (dintr-o stare activată), aceasta va reda valoarea secretului user.world și, în cazul în care secretul nu este încă definit, va solicita o valoare:
$ 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": ******
Utilizarea secretelor
Deși exemplul este relativ simplist, adevărata valoare a secretelor provine din evenimentele de activare. În loc să se recupereze o valoare secretă în contextul unui script, variabilele de mediu pot fi definite folosind secretele recuperate fără a expune vreodată aceste secrete în afara acestui mediu securizat:
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}
Acum, dacă secretul user.world este definit, atunci variabila de mediu WORLD va fi definită și poate fi recuperată ca orice altă variabilă de mediu:
$ echo $WORLDworld!
Dar, dacă nu este definită, atunci utilizatorului i se va cere să o definească la activarea mediului 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": ******
Frumos, nu?
Mai departe
Gestionarea configurației în dezvoltarea aplicațiilor este, în cea mai mare parte, o problemă rezolvată, dar gestionarea secretelor încă nu este. Numărul de proiecte care au verificat date sensibile într-un depozit de control al versiunilor este uimitor și este un lucru pe care l-au făcut chiar și companii foarte respectate, dar prin utilizarea unei igiene de securitate corespunzătoare și a unor produse precum State Tool de la ActiveState, păstrarea datelor de configurare sensibile în siguranță și securitate devine mai ușoară pe zi ce trece.
- Încercați să vă convingeți singuri prin crearea unui cont gratuit ActiveState Platform și prin descărcarea State Tool pentru a simplifica gestionarea secretelor.
- De asemenea, puteți viziona seminarul nostru web despre Cum să gestionați secretele partajate utilizând State Tool
Bloguri conexe:
Secretul gestionării secretelor partajate
Dezvoltatorii pot partaja secrete rapid și ușor fără a sacrifica securitatea
.