Funcionalidad del sistema operativo en App de Azure Service
En este artículo se describe la funcionalidad del sistema operativo de línea base que está disponible para todas las aplicaciones de Windows que se ejecutan en App de Azure Service. Esta funcionalidad incluye acceso a archivos, redes y registros, junto con registros y eventos de diagnóstico.
Nota:
Las aplicaciones Linux en App Service se ejecutan en sus propios contenedores. Tiene acceso raíz al contenedor, pero no tiene acceso al sistema operativo host. Del mismo modo, para las aplicaciones que se ejecutan en contenedores de Windows, tiene acceso administrativo al contenedor, pero no al sistema operativo host.
Niveles de plan de App Service
App Service ejecuta aplicaciones de cliente en un entorno de hospedaje multiinquilino. Las aplicaciones implementadas en los niveles Gratis y Compartido se ejecutan en procesos de trabajo en máquinas virtuales (VM) compartidas. Las aplicaciones implementadas en los niveles Estándar y Premium se ejecutan en máquinas virtuales dedicadas específicamente a las aplicaciones asociadas a un solo cliente.
Nota:
Los planes de servicio Gratis y Compartido de App Service (versión preliminar) corresponden a niveles básicos que se ejecutan en las mismas máquinas virtuales de Azure que otras aplicaciones de App Service. Es posible que algunas aplicaciones pertenezcan a otros clientes. Estos niveles solo están pensados para fines de desarrollo y pruebas.
Dado que App Service admite una experiencia de escalado sin problemas entre niveles, la configuración de seguridad aplicada para las aplicaciones de App Service sigue siendo la misma. Esta configuración garantiza que las aplicaciones no se comporten repentinamente de forma diferente y produzcan errores de maneras inesperadas cuando un plan de App Service cambie de un nivel a otro.
Marcos de desarrollo
Los planes de tarifa de App Service controlan la cantidad de recursos de proceso (CPU, almacenamiento en disco, memoria y entrada de red) disponibles para aplicaciones. Sin embargo, la amplitud de la funcionalidad del marco disponible para las aplicaciones sigue siendo la misma independientemente de los planes de escalado.
App Service admite varios marcos de desarrollo, como ASP.NET, ASP clásico, Node.js, PHP y Python. Para simplificar y normalizar la configuración de seguridad, las aplicaciones de App Service normalmente ejecutan los marcos de desarrollo con su configuración predeterminada. Los marcos y los componentes en tiempo de ejecución que proporciona la plataforma se actualizan periódicamente para satisfacer los requisitos de seguridad y cumplimiento. Por este motivo, no garantizamos versiones secundarias o de revisión específicas. Se recomienda que los clientes se dirijan a las versiones principales según sea necesario.
Las siguientes secciones resumen los tipos generales de funcionalidad del sistema operativo disponibles para aplicaciones de App Service.
Acceso a archivos
Existen varias unidades en App Service, incluidas las unidades locales y las unidades de red.
Unidades locales
En su núcleo, App Service es un servicio que se ejecuta sobre la infraestructura de plataforma como servicio (PaaS) de Azure. Como resultado, las unidades locales asociadas a una máquina virtual son los mismos tipos de unidad disponibles para cualquier rol de trabajo que se ejecute en Azure. Entre ellas, las siguientes:
- Una unidad de sistema operativo (
%SystemDrive%) cuyo tamaño depende del tamaño de la máquina virtual. - Unidad de recurso (
%ResourceDrive%) que App Service usa internamente.
Un procedimiento recomendado es usar siempre las variables de entorno %SystemDrive% y %ResourceDrive% en lugar de las rutas de acceso de archivo codificadas de forma rígida. La ruta de acceso raíz devuelta de estas dos variables de entorno ha cambiado con el tiempo de d:\ a c:\. Sin embargo, las aplicaciones anteriores codificadas de forma rígida con referencias d:\ de ruta de acceso de archivo para d:\ seguir funcionando porque App Service se vuelve a asignar automáticamente para que apunte a c:\. Como se indicó anteriormente, se recomienda encarecidamente usar siempre las variables de entorno al compilar rutas de acceso de archivo y evitar confusiones sobre los cambios de la plataforma en la ruta de acceso del archivo raíz predeterminada.
Es importante supervisar el uso del disco a medida que la aplicación crece. Alcanzar la cuota de disco puede tener efectos adversos en la aplicación. Por ejemplo:
- La aplicación podría producir un error que indica que no hay suficiente espacio en el disco.
- Es posible que vea errores de disco al navegar a la consola de Kudu.
- Es posible que se produzca un error en la implementación desde Azure DevOps o Visual Studio con
ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk). - Es posible que la aplicación tenga un rendimiento lento.
Unidades de red (recursos compartidos UNC)
Uno de los aspectos únicos de App Service que facilitan la implementación y el mantenimiento de aplicaciones es que todos los recursos compartidos de contenido se almacenan en un conjunto de recursos compartidos UNC. Este modelo se asigna perfectamente al patrón común de almacenamiento de contenido usado en entornos locales de hospedaje web que disponen de varios servidores con equilibrio de carga.
Dentro de App Service, los recursos compartidos UNC se crean en cada centro de datos. Un porcentaje del contenido del usuario para todos los clientes de cada centro de datos se asigna a cada recurso compartido UNC. La suscripción de cada cliente tiene una estructura de directorios reservada en un recurso compartido UNC específico en un centro de datos. Un cliente puede tener varias aplicaciones creadas en un centro de datos específico, por lo que todos los directorios que pertenecen a una sola suscripción de cliente se crean en el mismo recurso compartido UNC.
Debido a la forma en que funcionan los servicios de Azure, la máquina virtual específica responsable de hospedar un recurso compartido UNC cambia con el tiempo. Los recursos compartidos UNC se montan en diferentes máquinas virtuales a medida que se levantan y reducen durante el curso normal de las operaciones de Azure. Por este motivo, las aplicaciones nunca realizan suposiciones de forma rígida sobre que la información de la máquina en una ruta de acceso del UNC permanezca estable con el tiempo. En su lugar, deben usar la ruta de acceso absoluta faux adecuada %HOME%\site que proporciona App Service.
La ruta de acceso absoluta faux es un método portátil para hacer referencia a su propia aplicación. No es específico de ninguna aplicación o usuario. %HOME%\siteMediante , puede transferir archivos compartidos de la aplicación a la aplicación sin tener que configurar una nueva ruta de acceso absoluta para cada transferencia.
Tipos de acceso a archivo concedidos a una aplicación
El %HOME% directorio de una aplicación se asigna a un recurso compartido de contenido en Azure Storage dedicado para esa aplicación. El plan de tarifa define su tamaño. Puede incluir directorios como los de contenido, registros de error y diagnóstico, y versiones anteriores de la aplicación que creó el control de código fuente. Estos directorios están disponibles para el código de aplicación de la aplicación en tiempo de ejecución para el acceso de lectura y escritura. Dado que los archivos no se almacenan localmente, se mantienen al reiniciar la aplicación.
En la unidad del sistema, App Service reserva %SystemDrive%\local para el almacenamiento local temporal específico de la aplicación. Los cambios en los archivos de este directorio no se mantienen al reiniciar la aplicación. Aunque una aplicación tiene acceso de lectura y escritura completo a su propio almacenamiento local temporal, ese almacenamiento no está pensado para su uso directo por parte del código de la aplicación. El objetivo real es proporcionar un almacenamiento temporal de archivos para marcos de aplicaciones web e IIS.
App Service limita la cantidad de almacenamiento de %SystemDrive%\local cada aplicación para evitar que las aplicaciones individuales consuman cantidades excesivas de almacenamiento de archivos local. Para los niveles Gratis, Compartido y Consumo (Azure Functions), el límite es de 500 MB. En la tabla siguiente se enumeran otros niveles:
| Nivel | Almacenamiento de archivos local |
|---|---|
| B1/S1/P1 | 11 GB |
| B2/S2/P2 | 15 GB |
| B3/S3/P3 | 58 GB |
| P0v3 | 11 GB |
| P1v2/P1v3/P1mv3/Isolated1/Isolated1v2 | 21 GB |
| P2v2/P2v3/P2mv3/Isolated2/Isolated2v2 | 61 GB |
| P3v2/P3v3/P3mv3/Isolated3/Isolated3v2 | 140 GB |
| Isolated4v2 | 276 GB |
| P4mv3 | 280 GB |
| Isolated5v2 | 552 GB |
| P5mv3 | 560 GB |
| Isolated6v2 | 1 104 GB |
Los dos ejemplos de cómo usa App Service el almacenamiento local temporal son el directorio para archivos temporales ASP.NET y el directorio para archivos comprimidos IIS. El sistema de compilación ASP.NET usa el directorio %SystemDrive%\local\Temporary ASP.NET Files como ubicación temporal de la memoria caché de compilación. IIS usa el directorio %SystemDrive%\local\IIS Temporary Compressed Files para almacenar los resultados comprimidos de la respuesta. Ambos tipos de uso de archivos (junto con otros) se reasignan en App Service al almacenamiento local temporal por aplicación. Esta reasignación ayuda a garantizar que la funcionalidad continúe según lo previsto.
Cada aplicación de App Service se ejecuta como una identidad de proceso de trabajo aleatoria, única y con pocos privilegios denominada identidad del grupo de aplicaciones. El código de la aplicación usa esta identidad para el acceso básico de solo lectura para la unidad del sistema operativo. Este acceso significa que el código de aplicación puede enumerar estructuras de directorio comunes y leer archivos comunes en la unidad del sistema operativo. Aunque este nivel de acceso puede parecer amplio, se puede acceder a los mismos directorios y archivos al aprovisionar un rol de trabajo en un servicio hospedado en Azure y leer el contenido de la unidad.
Acceso al archivo en varias instancias
El directorio del recurso compartido de contenido (%HOME%) incluye el contenido de una aplicación y el código de una aplicación puede escribir en él. Si una aplicación se ejecuta en varias instancias, el directorio %HOME% se comparte entre todas las instancias de modo que todas ellas ven el mismo directorio. Por ejemplo, si una aplicación guarda los archivos cargados en el %HOME% directorio, esos archivos están disponibles inmediatamente para todas las instancias.
El directorio de almacenamiento local temporal (%SystemDrive%\local) no se comparte entre instancias. Tampoco se comparte entre la aplicación y su aplicación Kudu.
Acceso de red
El código de aplicación puede usar protocolos basados en TCP/IP y UDP para establecer conexiones de red salientes a puntos de conexión accesibles a Internet que exponen servicios externos. Las aplicaciones pueden usar estos mismos protocolos para conectarse a servicios dentro de Azure, por ejemplo, estableciendo conexiones HTTPS a Azure SQL Database.
También hay una funcionalidad limitada para que las aplicaciones establezcan una conexión de bucle invertido local y tengan una escucha de aplicación en ese socket de bucle invertido local. Esta característica permite que las aplicaciones que escuchen en sockets de bucle invertido local como parte de su funcionalidad. Cada aplicación tiene una conexión de bucle invertido privado. Una aplicación no puede escuchar un socket de bucle invertido local que se estableció otra aplicación.
Las canalizaciones con nombre también se admiten como un mecanismo para la comunicación entre procesos que ejecutan colectivamente una aplicación. Por ejemplo, el módulo FastCGI de IIS se basa en conductos con nombre para coordinar los procesos individuales que ejecutan páginas PHP.
Memoria, procesos y ejecución de código
Como se indicó anteriormente, las aplicaciones se ejecutan dentro de procesos de trabajo con pocos privilegios mediante una identidad aleatoria del grupo de aplicaciones. El código de aplicación tiene acceso al espacio de memoria asociado al proceso de trabajo, junto con los procesos secundarios que pueden generar CGI u otras aplicaciones. Sin embargo, una aplicación no puede acceder a la memoria ni a los datos de otra aplicación, aunque esté en la misma máquina virtual.
Las aplicaciones pueden ejecutar scripts o páginas escritas con marcos de desarrollo web compatibles. App Service no configura los ajustes del marco web en modos más restringidos. Por ejemplo, ASP.NET aplicaciones que se ejecutan en App Service se ejecutan en plena confianza, en lugar de un modo de confianza más restringido. Los marcos web, incluidos ASP clásico y ASP.NET, pueden llamar a componentes COM en proceso (como Objetos de datos ActiveX) registrados de forma predeterminada en el sistema operativo Windows. Los marcos web no pueden llamar a componentes COM fuera de proceso.
Una aplicación puede generar y ejecutar código arbitrario, abrir un shell de comandos o ejecutar un script de PowerShell. Sin embargo, los programas ejecutables y los scripts todavía están restringidos a los privilegios concedidos al grupo de aplicaciones primario. Por ejemplo, una aplicación puede generar un programa ejecutable que realiza una llamada HTTP saliente, pero ese programa ejecutable no puede intentar desenlagar la dirección IP de una máquina virtual desde su adaptador de red. Se permite realizar una llamada de red saliente para código con pocos privilegios, pero al intentar volver a configurar la configuración de red en una máquina virtual se requieren privilegios administrativos.
Eventos y registros de diagnóstico
La información de registro es otro conjunto de datos al que algunas aplicaciones intentan acceder. Los tipos de información de registro disponibles para el código que se ejecuta en App Service incluyen información de diagnóstico y registro que genera una aplicación y puede acceder fácilmente.
Por ejemplo, los registros HTTP de W3C generados por la aplicación están disponibles:
- En un directorio de registro de la ubicación del recurso compartido de red que creó para la aplicación
- En Blob Storage si configura el registro de W3C en el almacenamiento
Esta última opción permite a las aplicaciones recopilar grandes cantidades de registros sin superar los límites de almacenamiento de archivos asociados a un recurso compartido de red.
De forma similar, la información de diagnóstico en tiempo real de las aplicaciones .NET se puede registrar a través de la infraestructura de seguimiento y diagnóstico de .NET. Después, puede escribir la información de seguimiento en el recurso compartido de red de la aplicación o en una ubicación de almacenamiento de blobs.
Las áreas de registro y seguimiento de diagnósticos que no están disponibles para las aplicaciones son eventos de Seguimiento de eventos de Windows (ETW) y registros comunes de eventos de Windows (por ejemplo, sistema, aplicación y registros de eventos de seguridad). Dado que la información de seguimiento de ETW puede ser visible en una máquina (con las listas de control de acceso adecuadas), el acceso de lectura y el acceso de escritura a eventos ETW están bloqueados. Las llamadas API para leer y escribir eventos ETW y registros de eventos comunes de Windows pueden parecer funcionar, pero en realidad el código de la aplicación no tiene acceso a estos datos de eventos.
Acceso al registro
Las aplicaciones tienen acceso de solo lectura a gran parte (aunque no todos) del registro de la máquina virtual en la que se ejecutan. Este acceso significa que las aplicaciones pueden acceder a las claves del Registro que permiten el acceso de solo lectura al grupo Usuarios locales. Un área del registro que actualmente no se admite para el acceso de lectura o escritura es el HKEY\_CURRENT\_USER subárbol.
El acceso de escritura al registro está bloqueado, incluido el acceso a las claves del Registro por usuario. Desde la perspectiva de la aplicación, no se puede confiar en el acceso de escritura al registro en el entorno de Azure porque las aplicaciones se pueden migrar entre máquinas virtuales. El único almacenamiento que se puede escribir persistente en el que una aplicación puede depender es la estructura de directorios de contenido por aplicación almacenada en los recursos compartidos UNC de App Service.
Acceso de Escritorio remoto
App Service no proporciona acceso mediante Escritorio remoto a las instancias de la máquina virtual.
Más información
Para obtener la información más actualizada sobre el entorno de ejecución de App Service, consulte el espacio aislado de App de Azure Service. El equipo de desarrollo de App Service mantiene esta página.