Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
Copia y creación de repositorios de paquetes de Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Español) |
1. Repositorios de paquetes de Image Packaging System
2. Copia de repositorios de paquetes de IPS
3. Cómo proporcionar acceso al repositorio
4. Mantenimiento del repositorio de paquetes de IPS local
Actualización del repositorio local
Comprobación y definición de las propiedades del repositorio
Personalización del repositorio local
Cómo servir varios repositorios con instancias de servidor de varios depósitos
Configuración Apache para el servidor de depósitos
Configuración del almacenamiento en caché para el servidor de depósitos
Consideraciones de caché para el archivo de atributos del catálogo
Consideraciones de caché para la búsqueda
Ejecución del servidor de depósitos detrás de un proxy web
Valores de configuración Apache genéricos recomendados
Ejemplos de configuración Apache
Configuración de proxy con prefijo simple
Varios repositorios en un mismo dominio
En esta sección se explica la ejecución del servidor de depósitos detrás de una instancia del servidor web Apache, que ofrece las siguientes ventajas:
Mejora el rendimiento mediante el almacenamiento en caché del contenido y el equilibrio de la carga.
Permite alojar varios repositorios con un mismo nombre de dominio.
Se requiere una mínima configuración para configurar el servidor de depósitos detrás de un proxy de almacenamiento en caché. Con la excepción del archivo de los atributos del catálogo y los resultados de búsqueda del repositorio, que se analizan más adelante, todos los archivos servidos son únicos, por lo que es seguro almacenarlos en caché por tiempo indefinido en caso de necesidad. Asimismo, todas las respuestas contienen los encabezados HTTP adecuados para garantizar que los archivos de la memoria caché no caduquen por error.
Consulte Caching Guide (Guía de almacenamiento en caché) de Apache para obtener más información sobre la configuración Apache como proxy de almacenamiento en caché.
Utilice la directiva CacheRoot para especificar el directorio que va a contener los archivos almacenados en caché. Asegúrese de que el directorio especificado se pueda escribir en el proceso de Apache. No se muestra ningún mensaje de error explícito si Apache no puede escribir en este directorio.
CacheRoot /tank/proxycache
Apache permite activar el almacenamiento en caché para directorios específicos. Quizá desee que su servidor de repositorios almacene en caché todo el contenido del servidor, como se muestra en la siguiente directiva.
CacheEnable disk /
Utilice la directiva CacheMaxFileSize para establecer el tamaño máximo de los archivos que se van a almacenar en caché. Puede que el valor predeterminado de 1 MB de Apache sea demasiado pequeño para la mayoría de los repositorios. La siguiente directiva establece 1 GB como tamaño máximo para el archivo almacenado en caché.
CacheMaxFileSize 1000000000
Ajustar la estructura del directorio de la memoria caché en disco para obtener el mejor rendimiento con el sistema de archivos subyacente. En un conjunto de datos ZFS, el rendimiento se ve más afectado si hay varios niveles de directorios que si hay un gran número de archivos en un mismo directorio. Por lo tanto, configure un solo nivel de directorio con un gran número de archivos en cada directorio. Utilice las directivas CacheDirLevels y CacheDirLength para controlar la estructura de directorios. Establezca CacheDirLevels en 1. Establezca CacheDirLength en un valor que proporcione un buen equilibrio entre el número de directorios y el número de archivos por directorio. El valor de 2 establecido a continuación genera 4096 directorios. Consulte la documentación Disk-based Caching (Almacenamiento en caché basado en disco) para obtener más información.
CacheDirLevels 1 CacheDirLength 2
En el archivo de atributos del catálogo del repositorio (catalog.attrs) contiene el estado actual del catálogo del repositorio. Puede que el tamaño de este archivo justifique el almacenamiento en caché. Sin embargo, este archivo caduca si el catálogo del repositorio en segundo plano ha cambiado. Puede utilizar uno de los dos métodos siguientes para solucionar este problema.
No almacene este archivo en caché. Esta solución también funciona mejor si el servidor de repositorios se ejecuta en un entorno de alto ancho de banda en el que el tráfico adicional no es una consideración importante. El siguiente archivo httpd.conf parcial muestra cómo especificar que no se almacene en caché el archivo catalog.attrs:
<LocationMatch ".*/catalog.attrs"> Header set Cache-Control no-cache </LocationMatch>
Quite este archivo de la memoria caché cuando se actualiza el catálogo del repositorio en segundo plano.
La búsqueda de un repositorio de paquetes genera respuestas personalizadas que se basan en la solicitud. Por lo tanto, los resultados de la búsqueda no son apropiados para almacenarlos en caché. El servidor de repositorios establece los encabezados HTTP apropiados a fin de asegurar que los resultados de búsqueda no caduquen en una memoria caché. Sin embargo, el ahorro de ancho de banda derivado del uso del almacenamiento en caché es reducido. El siguiente archivo httpd.conf parcial muestra cómo especificar que no se almacenen en caché los resultados de búsqueda.
<LocationMatch ".*/search/\d/.*"> Header set Cache-Control no-cache </LocationMatch>
El servidor de depósitos pkg(5) permite proporcionar acceso a un repositorio en la red local o en Internet con facilidad. Sin embargo, el servidor de depósitos no admite que se sirvan varios repositorios en un solo nombre de dominio o prefijos sofisticados. Para alojar varios repositorios en un solo nombre de dominio, ejecute el servidor de depósitos detrás de un proxy web. La ejecución del servidor de depósitos detrás de un proxy web también puede mejorar el rendimiento del servidor mediante la activación del equilibrio de la carga en varios depósitos y del almacenamiento del contenido.
Los ejemplos de esta sección utilizan el servidor web Apache como software de proxy. El sistema operativo Oracle Solaris 11.1 incluye el servidor web Apache en el paquete web/server/apache-22 y un archivo httpd.conf básico en /etc/apache2/2.2. El servidor web Apache se activa al activar el servicio svc:/network/http:apache22. Consulte la Documentación del servidor HTTP Apache versión 2.2 para obtener información adicional.
Debe poder aplicar los principios que se muestran en estos ejemplos para cualquier software de servidor proxy.
Los siguientes valores afectan el rendimiento y la seguridad.
Los clientes HTTP pueden indicar al servidor que aceptan datos comprimidos en una solicitud HTTP. La activación del filtro DEFLATE de Apache puede reducir drásticamente el tamaño en línea de los metadatos, como catálogos y manifiestos. Los metadatos como catálogos y manifiestos suelen comprimirse un 90%.
AddOutputFilterByType DEFLATE text/html application/javascript text/css text/plain
Los paquetes pueden contener barras diagonales codificadas para URL. Para asegurarse de que estas barras diagonales no se interpreten como delimitadores de directorio, establezca que Apache no los decodifique.
AllowEncodedSlashes NoDecode
Nota - Si se omite esta configuración, la funcionalidad de búsqueda se verá considerablemente afectada.
Aumente el valor MaxKeepAliveRequests para permitir que los clientes extraigan un mayor número de solicitudes canalizadas sin cerrar la conexión. El valor predeterminado de Apache de 100 es demasiado bajo.
MaxKeepAliveRequests 10000
El tiempo de espera del proxy determina cuánto tiempo Apache espera la respuesta del depósito en segundo plano. Para la mayoría de las operaciones, 30 segundos es suficiente. Las búsquedas que arrojan una gran cantidad de resultados pueden llevar bastante más tiempo. Quizá desee asignar un valor de tiempo de espera mayor para dichas búsquedas.
ProxyTimeout 30
Asegúrese de que el proxy de reenvío esté desactivado.
ProxyRequests Off
En esta sección, se ilustran configuraciones con y sin equilibrio de carga de varios repositorios.
En este ejemplo, se muestra la configuración básica para un servidor de depósitos sin equilibro de carga. En este ejemplo, se conecta http://pkg.example.com/myrepo con internal.example.com:10000.
Consulte Cómo servir varios repositorios con instancias de servidor de varios depósitos para obtener instrucciones sobre la definición de otras propiedades que necesita y que no están descritas en este ejemplo.
Debe configurar el servidor de depósitos con una configuración pkg/proxy_base que mencione la URL en la que se puede acceder al servidor de depósitos. Utilice los comandos siguientes para establecer la configuración pkg/proxy_base:
$ svccfg -s pkg/server add repo $ svccfg -s pkg/server:repo "setprop pkg/proxy_base = astring: http://pkg.example.com/myrepo" $ svcadm refresh pkg/server:repo $ svcadm enable pkg/server:repo
El cliente pkg(5) abre 20 conexiones paralelas al servidor de depósitos cuando realiza operaciones de red. Asegúrese de que el número de subprocesos de depósitos coincida con las conexiones esperadas para el servidor en cualquier momento. Utilice los siguientes comandos para definir el número de subprocesos por depósito:
$ svccfg -s pkg/server:repo "setprop pkg/threads = 200" $ svcadm refresh pkg/server:repo $ svcadm restart pkg/server:repo
Utilice nocanon para suprimir la canonización de direcciones URL. Este valor es importante para que la búsqueda funcione correctamente. Además, limite el número de conexiones en segundo plano al número de subprocesos que el servidor de depósitos proporciona. El siguiente archivo httpd.conf parcial muestra cómo aplicar un proxy en un servidor de depósitos:
Redirect /myrepo http://pkg.example.com/myrepo/ ProxyPass /myrepo/ http://internal.example.com:10000/ nocanon max=200
La principal razón para ejecutar el servidor de depósitos detrás de un proxy es que permite ejecutar varios repositorios en un mismo nombre de dominio con diferentes prefijos. El ejemplo de Configuración de proxy con prefijo simple puede ampliarse fácilmente para admitir varios repositorios.
En este ejemplo, tres prefijos diferentes de un nombre de dominio están conectados con tres repositorios de paquetes diferentes:
http://pkg.example.com/repo_one está conectado con internal.example.com:10000
http://pkg.example.com/repo_two está conectado con internal.example.com:20000
http://pkg.example.com/xyz/repo_three está conectado con internal.example.com:30000
El servidor de depósitos pkg(5) es un servicio que se gestiona mediante SMF. Por lo tanto, para ejecutar varios servidores de depósitos en el mismo host, simplemente cree una nueva instancia de servicio:
$ svccfg -s pkg/server add repo1 $ svccfg -s pkg/server:repo1 setprop pkg/property=value $ ...
Como en el ejemplo anterior, cada servidor de depósitos se ejecuta con 200 subprocesos.
Redirect /repo_one http://pkg.example.com/repo_one/ ProxyPass /repo_one/ http://internal.example.com:10000/ nocanon max=200 Redirect /repo_two http://pkg.example.com/repo_two/ ProxyPass /repo_two/ http://internal.example.com:20000/ nocanon max=200 Redirect /xyz/repo_three http://pkg.example.com/xyz/repo_three/ ProxyPass /xyz/repo_three/ http://internal.example.com:30000/ nocanon max=200
Quizá desee ejecutar servidores de depósitos detrás de un equilibrador de carga de Apache. En este ejemplo, se conecta http://pkg.example.com/myrepo con internal1.example.com:10000 y internal2.example.com:10000.
Configure el servidor de depósitos con una configuración de proxy_base adecuada, como se muestra en Configuración de proxy con prefijo simple.
Limite el número de conexiones en segundo plano al número de subprocesos que cada depósito esté ejecutando dividido por el número de depósitos de la configuración del equilibrador de carga. De lo contrario, Apache abre más conexiones con un depósito que las que están disponibles, y las conexiones se detienen, lo cual puede reducir el rendimiento. Especifique el número máximo de conexiones paralelas a cada depósito con el parámetro max=. El siguiente ejemplo muestra dos depósitos que ejecutan 200 subprocesos cada uno. Consulte Configuración de proxy con prefijo simple para ver un ejemplo de cómo definir el número de subprocesos de los depósitos.
<Proxy balancer://pkg-example-com-myrepo> # depot on internal1 BalancerMember http://internal1.example.com:10000 retry=5 max=100 # depot on internal2 BalancerMember http://internal2.example.com:10000 retry=5 max=100 </Proxy> Redirect /myrepo http://pkg.example.com/myrepo/ ProxyPass /myrepo/ balancer://pkg-example-com-myrepo/ nocanon
En el siguiente ejemplo, se incluyen todas las directivas que debe agregar al archivo httpd.conf para un servidor de repositorio que aloja una configuración de servidor de depósito con carga equilibrada y con carga no equilibrada.
En este ejemplo, dos prefijos diferentes de un mismo nombre de dominio están conectados a tres repositorios de paquetes diferentes:
http://pkg.example.com/repo_one está conectado con internal1.example.com:10000 y internal2.example.com:10000
http://pkg.example.com/repo_two está conectado con internal1.example.com:20000
AddOutputFilterByType DEFLATE text/html application/javascript text/css text/plain AllowEncodedSlashes NoDecode MaxKeepAliveRequests 10000 ProxyTimeout 30 ProxyRequests Off <Proxy balancer://pkg-example-com-repo_one> # depot on internal1 BalancerMember http://internal1.example.com:10000 retry=5 max=100 # depot on internal2 BalancerMember http://internal2.example.com:10000 retry=5 max=100 </Proxy> Redirect /repo_one http://pkg.example.com/repo_one/ ProxyPass /repo_one/ balancer://pkg-example-com-repo_one/ nocanon Redirect /repo_two http://pkg.example.com/repo_two/ ProxyPass /repo_two/ http://internal.example.com:20000/ nocanon max=200