pipenv: flujo de trabajo de despliegue

Estoy pensando en cambiar de pip y virtualenv a pipenv

Pero después de estudiar la documentación, todavía no sé cómo los creadores de pipenv estructuraron el flujo de trabajo de implementación.

ejemplo:

En desarrollo tengo un “Pipfile” y un “Pipfile.lock” que definen el entorno.

Utilizando un script de despliegue que quiero desplegar

1) “git pull” a través de Github al servidor de producción

2) “pipenv install” crea / actualiza el entorno en el directorio de inicio del usuario de la implementación

Pero necesito un venv en una directriz específica que ya esté configurada en systemd o supervisor

p.ej:

command=/home/ubuntu/production/application_xy/env/bin/gunicorn module:app 

pipenv crea el env en alguna ubicación como: /home/ultimo/.local/share/virtualenvs/application_xy-jvrv1OSi

¿Cuál es el flujo de trabajo previsto para implementar una aplicación con pipenv?

Tienes pocas opciones allí.

  1. Puedes correr tu gunicorn a través de pipenv run :

    pipenv run gunicorn module:app

Esto crea una ligera sobrecarga, pero tiene la ventaja de que también carga el entorno desde $PROJECT_DIR/.env (u otro $PIPENV_DOTENV_LOCATION ).

  1. Puede establecer la variable de entorno PIPENV_VENV_IN_PROJECT . Esto mantendrá el virtualenv de pipenv en $PROJECT_DIR/.venv lugar de la ubicación global.

  2. Puedes usar un virtualenv existente y ejecutar pipenv desde él. Pipenv no intentará crear su propio virtualenv si se ejecuta desde uno.

  3. Puedes usar la ruta virtualenv creada por pipenv.

Acabo de cambiar a pipenv para la implementación y mi flujo de trabajo es aproximadamente el siguiente (administrado con ansible ). Para un proyecto imaginario llamado “proyecto”, asumiendo que un Pipfile.lock en funcionamiento está registrado en el control de fuente:

  1. Clona el repository git:

    git clone https://github.com/namespace/project.git /opt/project

  2. Cambiar en ese directorio

    cd /opt/project

  3. Echa un vistazo a la referencia de destino (twig, etiqueta, …):

    git checkout $git_ref

  4. Cree un virtualenv en algún lugar, con la versión de Python de destino (3.6, 2.7, etc.):

    virtualenv -p"python$pyver" /usr/local/project/$git_ref

  5. Llame a pipenv en el contexto de ese virtualenv, para que no instale su propio:

    VIRTUAL_ENV="/usr/local/project/$git_ref" pipenv --python="/usr/local/project/$git_ref/bin/python" install --deploy

    El --deploy lanzará un error, cuando el Pipfile.lock no coincide con el Pipfile.

  6. Instale el proyecto utilizando el pip de virtualenv (solo necesario si aún no está en el Pipfile):

    /usr/local/project/$git_ref/bin/pip install /opt/project

  7. Establecer un enlace simbólico al nuevo directorio de instalación:

    ln -s /usr/local/project/$git_ref /usr/local/project/current

Entonces, mi aplicación puede cerrarse, por ejemplo, con /usr/local/project/current/bin/project_exec --foo --bar , que es lo que está configurado en supervisor , por ejemplo.

Todo esto se activa cuando se empuja una etiqueta al control remoto.

Como los controles virtuales de las versiones anteriores permanecen intactos, la reversión se realiza simplemente configurando el enlace simbólico current- nuevo a una versión anterior. Es decir, si la etiqueta 1.5 está rota y quiero volver a 1.4, todo lo que tengo que hacer es ln -s /usr/local/project/1.4 /usr/local/project/current y reiniciar la aplicación con supervisorctl .

Creo que pipenv es muy bueno para administrar dependencias, pero es demasiado lento, engorroso y aún un poco inestable para usarlo en implementaciones automáticas.

En su lugar, uso virtualenv (o virtualenvwrapper) y pip en la máquina de destino.

  • En mi máquina de desarrollo, creo un archivo de texto compatible con pipenv lock -r usando pipenv lock -r :

     $ pipenv lock -r > deploy-requirements.txt 
  • Durante el despliegue, dentro de un virtualenv ejecuto:

     $ pip install -r deploy-requirements.txt 

Para crear un entorno virtual en el mismo directorio que el proyecto, establezca la siguiente variable de entorno doc

 PIPENV_VENV_IN_PROJECT=true 

Esto instala las dependencias al directorio .venv dentro del proyecto. Disponible desde PipEnv v2.8.7