python pip openstack

instalando paquetes de python sin internet y usando código fuente como.tar.gz y.whl



pip openstack (4)

Así es como manejo este caso:

En la máquina donde tengo acceso a Internet:

mkdir keystone-deps pip download python-keystoneclient -d "/home/aviuser/keystone-deps" tar cvfz keystone-deps.tgz keystone-deps

Luego mueva el archivo tar a la máquina de destino que no tiene acceso a Internet y realice lo siguiente:

tar xvfz keystone-deps.tgz cd keystone-deps pip install python_keystoneclient-2.3.1-py2.py3-none-any.whl -f ./ --no-index

Estamos intentando instalar un par de paquetes de Python sin internet.

For ex : python-keystoneclient

Para eso tenemos los paquetes descargados de https://pypi.python.org/pypi/python-keystoneclient/1.7.1 y los guardamos en el servidor.

Sin embargo, al instalar los paquetes tar.gz y .whl, la instalación busca que primero se instalen paquetes dependientes. Como no hay conexión a Internet en el servidor, se está produciendo un error.

Por ejemplo: para python-keystoneclient tenemos los siguientes paquetes dependientes

stevedore (>=1.5.0) six (>=1.9.0) requests (>=2.5.2) PrettyTable (<0.8,>=0.7) oslo.utils (>=2.0.0) oslo.serialization (>=1.4.0) oslo.i18n (>=1.5.0) oslo.config (>=2.3.0) netaddr (!=0.7.16,>=0.7.12) debtcollector (>=0.3.0) iso8601 (>=0.1.9) Babel (>=1.3) argparse pbr (<2.0,>=1.6)

Cuando trato de instalar paquetes uno por uno de la lista anterior, una vez más busca dependencia anidada.

¿Hay alguna manera de que podamos enumerar TODOS los paquetes dependientes para instalar un módulo de Python como python-keystoneclient?

Si desea instalar un grupo de dependencias, por ejemplo, a require.txt, haría:

mkdir dependencies pip download -r requirements.txt -d "./dependencies" tar cvfz dependencies.tar.gz dependencies

Y, una vez que transfiere dependencies.tar.gz a la máquina que no tiene internet, haría:

tar zxvf dependencies.tar.gz cd dependencies pip install * -f ./ --no-index

Tenemos una situación similar en el trabajo, donde las máquinas de producción no tienen acceso a Internet; por lo tanto, todo tiene que ser administrado fuera de línea y fuera del host.

Esto es lo que probé con variadas cantidades de éxito:

  1. basket que es una pequeña utilidad que ejecuta en su host conectado a Internet. En lugar de intentar instalar un paquete, en su lugar lo descargará y todo lo demás que necesita para instalarse en un directorio. Luego mueve este directorio a su máquina de destino. Pros: muy fácil y simple de usar, sin dolores de cabeza en el servidor; No hay puertos para configurar. Contras: no hay ningún showtoppers real, pero el más importante es que no respeta ninguna versión de fijación que pueda tener; siempre descargará la última versión de un paquete.

  2. Ejecute un servidor pypi local. Utiliza pypiserver y devpi . pypiserver es súper simple de instalar y configurar; devpi toma un poco más de tiempo. Ambos hacen lo mismo: actúan como proxy / caché para el pypi real y como servidor pypi local para cualquier paquete de cosecha propia. localshop es uno nuevo que no existía cuando estaba buscando, también tiene la misma idea. Entonces, cómo funciona es que su máquina con acceso restringido a Internet se conectará a estos servidores, luego se conectarán a Internet para que puedan almacenar en caché y proxy el repositorio real.

El problema con el segundo enfoque es que, aunque obtiene la máxima compatibilidad y acceso a todo el repositorio de paquetes de Python, aún debe asegurarse de que todas las dependencias estén instaladas en sus máquinas de destino (por ejemplo, cualquier encabezado para los controladores de la base de datos y un Cadena de herramientas de construcción). Además, estas soluciones no se adaptan a repositorios que no sean pypi (por ejemplo, paquetes alojados en github).

Sin embargo, llegamos muy lejos con la segunda opción, por lo que definitivamente la recomendaría.

Eventualmente, cansados ​​de tener que lidiar con problemas de compatibilidad y bibliotecas, migramos todo el circo de servidores a contenedores docker con soporte comercial.

Esto significa que enviamos todo preconfigurado, en realidad no es necesario instalar nada en las máquinas de producción y ha sido la solución más sencilla para nosotros.

Reemplazamos los repositorios de pypi con un servidor local de imágenes docker.