Inmediatamente antes de iniciar el script, el servidor le pasa algunas variables de entorno con información. Ciertas variables contienen algunos encabezados, pero, como se mencionó, no todos (no se pueden obtener todos los encabezados). Las variables de entorno en PHP se pueden utilizar como variables ordinarias. Las variables ambientales se dividen en cuatro grandes grupos:
- Variables generadas por el servidor;
- variables específicas del servidor Apache;
- Variables de campos de solicitud HTTP;
- Variables de conexión SSL (conexión segura).
Veamos los primeros tres grupos de variables de entorno:
Variables generadas por el servidor:
variable de entorno |
|
| AUTH_TYPE | Se utiliza un esquema de autenticación. Generalmente "BÁSICO" |
| CONTENIDO_LENGTH | Longitud del contenido, p. ej. texto/html |
| CONTENIDO_TIPO | Tipo de contenido MIME, por ejemplo texto/html |
| ESCAPADA_INTERFACE | Versión CGI, por ejemplo CGI/1.1 |
| RUTA_INFO | Ruta HTTP al script |
| RUTA_TRADUCCIÓN | Ruta completa al guión. |
| REMOTE_ADDR | Dirección IP del ordenador cliente solicitado |
| HOST_REMOTO | Nombre de dominio computadora solicitante (si está disponible). El nombre de dominio lo determina el servidor web mediante el servicio DNS. La directiva Apache HostNameLookups permite (o niega) la resolución de una dirección IP a un nombre de dominio. |
| PUERTO_REMOTO | Puerto asignado al navegador para recibir una respuesta del servidor |
| USUARIO_REMOTO | Nombre de usuario autenticado |
| QUERY_STRING | Cadena de parámetros pasados al servidor. |
| SERVIDOR_ADDR | Dirección IP del servidor |
| SERVIDOR_NOMBRE | Nombre de dominio del servidor. Determinado por la directiva ServerName del archivo de configuración. |
| SERVIDOR_PORT | Puerto TCP del servidor web. Generalmente 80 |
| PROTOCOLO_SERVIDOR | Versión del protocolo HTTP. Por ejemplo, HTTP/1.1 |
| SERVIDOR_SOFTWARE | software de servidor |
| SCRIPT_NOMBRE | Ruta HTTP al script |
| SCRIPT_FILENAME | Nombre del archivo de script en sistema de archivos servidor (ruta física). Por ejemplo, /var/www/cgi-bin/script.cgi |
Variables especiales del servidor Apache:
Variables del campo de solicitud HTTP:
variable de entorno |
Descripción de la variable de entorno. |
| HTTP_HOST | Nombre del host virtual al que se dirige la solicitud |
| HTTP_USER_AGENT | Software usuario remoto. Normalmente, esta variable de entorno contiene el nombre y la versión del navegador. |
| HTTP_ACEPTAR | Lista de clientes de tipos de contenido admitidos. Recientemente, en lugar de una lista, los navegadores devuelven *.*, que significa "todos los tipos" |
| HTTP_ACCEPT_LANGUAGE | Lista de idiomas admitidos en orden de preferencia, por ejemplo, ru, en |
| HTTP_ACCEPT_ENCODING | Lista de métodos de compresión admitidos |
| HTTP_ACCEPT_CHARSET | Lista de codificaciones admitidas |
| CONEXIÓN_HTTP | Tipo de conexión. Hay dos opciones:
|
| HTTP_REFERER | Valor del campo REFERENTE. En este campo, el navegador pasa la URL del recurso que enlaza con nuestro servidor. Por ejemplo, si el usuario llegó al sitio desde la página http://www.somehost.com/page.php, entonces el valor del campo REFERER sería http://www.somehost.com/page.php. |
| HTTP_X_FORWARDED_FOR | Si el usuario trabaja a través de un servidor proxy, este campo contendrá la dirección IP de la computadora que accedió al servidor proxy. Si este campo ya contiene un valor, entonces el nuevo valor se agregará separado por comas. |
Este es un breve procedimiento para implementar la configuración de un servicio PHP, según el entorno en el que se ejecuta. Me alegraré si alguien sugiere una solución más elegante o corrige en pequeñas cosas.
Idea principal
Ejecute el servicio, los microservicios y las aplicaciones dependientes dentro del mismo ecosistema, configurado mediante variables de entorno.Problema
Este artículo repite "variables ambientales" demasiadas veces.De fábrica, php-fpm ignora las variables de entorno globales (función getenv), mientras que php cli puede recibirlas.
Fondo
Puedes saltarte esta sección si ya has trabajado con .env
EN en este momento Estoy trabajando en un proyecto escrito en ZF2. Para configurar el proyecto se utilizaron archivos de configuración para diferentes entornos. Esto genera gran número configuraciones duplicadas en el repositorio del proyecto algo como esto:
- sesión.global.php
- sesión.local.php.dist
- sesión.unittest.php.dist
- db.global.php
- db.local.php.dist
- db.unittest.php.dist
Entonces el proyecto ahora tiene en cuenta el medio ambiente, pero...
Mientras el desarrollo se llevaba a cabo en máquinas en funcionamiento, el proyecto leyó el archivo .env y todo funcionó. Pero cuando implementé un entorno de prueba, resultó que si configuro variables de entorno reales del sistema, php-fpm las ignora. Varias recetas de Google y StackOverflow se redujeron a una u otra automatización del uso de dos métodos conocidos:1. Pasar variables a través de nginx usando la prueba SOMEENV del parámetro fastcgi_param;
2. Establecer variables en formato env en la configuración del grupo de procesos de trabajo php-fpm.
Tanto la primera como la segunda opción son convenientes para algunas situaciones especiales. Pero si piensa en el paradigma de "configurar el entorno, no la aplicación", entonces estos métodos resultan mucho más difíciles que, por ejemplo, simplemente colocar un archivo .env en la carpeta del proyecto. Pero un orquestador, un sistema de CI o simplemente administrador del sistema No se deben conocer los detalles de la implementación del proyecto, no es elegante.
Solución sugerida
Habiendo combinado varias recetas de Internet, encontré la siguiente solución funcional.Probado bajo Centos 7, PHP 5.6.14.
1. Abra /etc/php.ini - Reemplace variables_order = "GPCS" con variables_order = "EGPCS" # Después de esto, PHP agregará variables de entorno al espacio global # http://php.net/manual/ru/ini. core.php #ini.variables-order 2. Abra /etc/php-fpm.d/www.conf, que no debe confundirse con /etc/php-fpm.conf (en diferentes sistemas tal vez en diferentes lugares, esta es la configuración del grupo de procesos www para php-fpm. - Agregar (o reemplazar, si corresponde): clear_env = no # deshabilitar la eliminación de variables globales para los trabajadores iniciados 3. Establecer las variables de entorno necesarias en /etc/environment (sintaxis estándar A=B) 4. ln -fs /etc/environment / etc/sysconfig/php-fpm # ahora la configuración de la variable de entorno del servicio php-fpm será simplemente un enlace a la configuración global 5. systemctl daemon-reload && service php-fpm restart
El mismo enfoque con un enlace simbólico, en teoría, es aplicable a otros servicios.
Ventajas de la solución propuesta:
- Las variables almacenadas en /etc/environment son accesibles para diferentes aplicaciones. Puedes llamar a echo $MYSQL_HOST en shell o getenv("MYSQL_HOST") en php.
- Las variables de entorno que no estén configuradas explícitamente en /etc/environment no terminarán en php-fpm. Esto permite al orquestador controlar el entorno desde fuera del sistema aislado en el que se ejecuta el servicio.
Contras:
- Desafortunadamente, no encontré un comando que funcione para recargar en php-fpm, similar a nginx, por lo que si cambia /etc/environment, debe hacerlo systemctl daemon-reload && servicio php-fpm reiniciar.
Importante: Si su aplicación no se ejecuta en un entorno aislado (servidor, máquina virtual, contenedor), la definición de variables de entorno puede afectar de manera impredecible los servicios vecinos en el sistema debido a coincidencias de nombres en el espacio global.
variables
En PHP, las variables comienzan con un signo de dólar ( $ ). Este carácter puede ir seguido de cualquier número de caracteres alfanuméricos y de subrayado, pero el primer carácter no puede ser un dígito ni un guión bajo. También debes recordar que los nombres de las variables en PHP distinguen entre mayúsculas y minúsculas, a diferencia de las palabras clave.
Al declarar variables en PHP, no es necesario indicar explícitamente el tipo de variable, sin embargo, una misma variable puede tener diferentes tipos a lo largo del programa;
Una variable se inicializa cuando se le asigna un valor y existe mientras se ejecuta el programa. Es decir, en el caso de una página web, esto significa que hasta que se complete la solicitud.
Variables externas
Después de que el servidor web analiza la solicitud de un cliente y la pasa a la máquina PHP, esta última establece una serie de variables que contienen datos relacionados con la solicitud y están disponibles durante su ejecución. Primero toma PHP variables de entorno su sistema y crea variables con los mismos nombres y valores en el entorno de script PHP para que los scripts ubicados en el servidor puedan acceder a las funciones del sistema del cliente. Estas variables se colocan en matriz asociativa $HTTP_ENV_VARS(Puede obtener más información sobre las matrices en el Capítulo 4).
Naturalmente, las variables de matriz $HTTP_ENV_VARS dependen del sistema (ya que en realidad es variables de entorno). Puede ver los valores de las variables de entorno de su máquina utilizando el comando env (Unix) o set (Windows).
Luego, PHP crea un grupo de variables GET que se crean cuando se analiza la cadena de consulta. La cadena de consulta se almacena en una variable. $QUERY_STRING y representa la información que sigue al símbolo " ? " en la URL solicitada. PHP rompe la cadena de consulta carácter por carácter & en elementos individuales y luego busca el signo "=" en cada uno de esos elementos. Si se encuentra el signo "=", se crea una variable con un nombre de los caracteres a la izquierda del signo igual. Considere la siguiente forma:
Si en este formulario escribe, por ejemplo, "Maxtor" en la línea HDD y "Nec" en la línea CDROM, se generará el siguiente formulario de solicitud:
http://localhost/PHP/test.php?HDD=Maxtor&CDROM=NecEn nuestro caso, PHP creará las siguientes variables: $disco duro= "Maxtor" y $CD-ROM= "Nec".
Puede trabajar con estas variables desde su script (usamos test.php) como con variables normales. En nuestro caso, simplemente se muestran en pantalla:
eco("El disco duro es $HDD
"); eco("CDROM es $CDROM
"); ?>
Si se realiza una solicitud de página utilizando el método POST, aparece un grupo de variables POST, que también se interpretan y se colocan en una matriz. $HTTP_POST_VARS.
Las variables de entorno utilizadas en la configuración son hoy el método principal para establecer configuraciones en una aplicación, como credenciales de base de datos, claves API, claves secretas y todo lo demás. Es diferente dependiendo de dónde se implemente la aplicación.. Ahora, dichas configuraciones ingresan al código a través del entorno, en lugar de escribirse directamente en archivos de configuración o, peor aún, codificarse directamente en el código.
Echemos un vistazo más de cerca:
- ¿Cómo funciona esto?
- ¿Es realmente una buena idea?
- ¿Cómo trabajar con ellos en PHP?
- y finalmente, algunas recomendaciones y errores comunes que se deben evitar: ¡los errores con los que nos topamos en el mundo real!
No cubriremos cómo configurar variables de entorno en su servidor web/Docker/crontabs... porque depende del sistema, software, y queremos centrarnos en las variables de entorno mismas.
Si su alojamiento utiliza Docker Swarm o AWS, las cosas serán un poco diferentes, por ejemplo, ya que han elegido insertar archivos en el sistema de archivos de su contenedor para inyectar sus claves privadas en lugar de utilizar variables de entorno. Esto es muy específico de estas plataformas y no es una opción común para todos.
Variaciones ambientales 101
Cuando se ejecuta un programa, hereda todas las variables de entorno de sus padres. Entonces, si configura la variable YOLO en covfefe en bash y luego ejecuta el comando, podrá leer YOLO en cualquier proceso hijo.
$ YOLO=covfefe php -r "echo getenv("YOLO");" covfefe
Dado que esta variable solo se define localmente, no podemos leerla desde otro terminal (otro padre). La idea es asegurarse de que su aplicación siempre herede las variables correctas.
Puede ver todas las variables de entorno en línea de comando ejecutando el siguiente comando, pero no verá la variable YOLO porque solo se pasó al comando php sobre la marcha y no se configuró en el proceso actual:
Puede configurar la variable de entorno usando exportar<имя>=<значение> :
$ exportar YOLO=covfefe
Los nombres de las variables distinguen entre mayúsculas y minúsculas y la convención es utilizar nombres en inglés únicamente, en mayúsculas, con _ como separador (el llamado estilo "serpiente" en mayúsculas). Probablemente ya conozca algunas variables, como PATH, DISPLAY, HTTP_PROXY...
Mejores prácticas hoy
josegonzalez/dotenv, orientado a la seguridad:
Esta biblioteca no completará superglobales de forma predeterminada:
$Loader = new josegonzalez\Dotenv\Loader("ruta/a/.env"); // Analiza el archivo.env: $Loader->parse(); // Envía el resultado del análisis.env a la variable $_ENV: $Loader->toEnv();
Admite variables requeridas, filtrado y puede generar excepciones cuando se sobrescribe una variable.
Symfony/dotenv, un chico nuevo en la cuadra:
Disponible desde Symfony 3.3. Este componente se encarga del archivo .env como los demás y también llena matrices superglobales:
$dotenv = nuevo Symfony\Component\Dotenv\Dotenv(); $dotenv->load(__DIR__."/.env"); $dbUser = getenv("DB_USER"); $dbUser = $_ENV["DB_USER"]; $dbUser = $_SERVER["DB_USER"];
No deberías usarlo para obtener tus valores, por lo que te sugiero que llames a $_SERVER en su lugar; además, existe una ligera diferencia de rendimiento entre llamar a una matriz y llamar a una función a favor de las matrices.
Las variables de entorno son siempre cadenas.
Uno de los principales problemas es que actualmente PHP tiene tipos y nuestra configuración no siempre se escribe correctamente.
Class Db ( public function connect(string hostname, int port) ( ) ) // Esto no funcionará: $db->connect($_SERVER["DATABASE_HOSTNAME"], $_SERVER["DATABASE_PORT"]);
En Symfony ahora puedes convertir variables y aún más: leer un archivo, decodificar json...
Variables de entorno en todas partes o no
Actualmente existe mucho debate entre el uso de variables de entorno, archivos o una combinación de ambos: una variable de entorno hace referencia a un archivo de configuración. La cuestión es que, aunque se considera una mejor práctica, las variables de entorno no ofrecen muchos beneficios...
Pero si se usan correctamente, en una aplicación Symfony, por ejemplo, las variables de entorno se pueden cambiar sobre la marcha, sin borrar ningún caché, sin acceder al sistema de archivos, sin implementar código: simplemente reiniciando el proceso, por ejemplo.
La tendencia de tener solo una variable como APP_CONFIG_PATH y leerla a través de "%env(json:file:APP_CONFIG_PATH)%" me parece como reinventar los viejos parámetros.yml a menos que el archivo sea administrado automáticamente por una herramienta confiable (como AWS Secret Store). ). Y también está envkey.com, que le permite administrar sus variables de entorno en un solo lugar sin tener que manipular los archivos usted mismo. ¡Me gusta este enfoque porque es mucho más fácil!
Instrucciones
