puma dev
v0.18.3
Puma-Dev es el sucesor emocional de POW. Proporciona una manera rápida y fácil de administrar aplicaciones en desarrollo en MacOS y Linux.
.test (configurable).test .puma .pow ya no se mantiene Primero, asegúrese de que se instale la gema puma . Probablemente pertenece a Gemfile de la (s) aplicación (s) que está tratando de servir a través de PUMA-DEV.
# Gemfile
gem 'puma' brew install puma/puma/puma-dev
Puede descargar binarios para macOS y Linux en https://github.com/puma/puma-dev/releases
#! /usr/bin/env bash
go version
go get github.com/puma/puma-dev/...
cd $GOPATH /src/github.com/puma/puma-dev/
make && make install
$GOBIN /puma-dev -V # Configure some DNS settings that have to be done as root
sudo puma-dev -setup
# Configure puma-dev to run in the background on ports 80 and 443 with the domain `.test`.
puma-dev -install Si desea que puma-dev use un puerto que no sea 80, pase a través del -install-port , por ejemplo, para usar el puerto 81: puma-dev -install -install-port 81 .
Nota: Si instaló PUMA-DEV V0.2, ejecute sudo puma-dev -cleanup para eliminar las reglas de firewall que Puma-Dev ya no usa (y entrará en conflicto con el funcionamiento de PUMA-DEV).
Nota: Si tenía POW instalado antes en el sistema, asegúrese de ejecutar el script de desinstalación de POW. Lea más detalles en el manual de POW.
Run: puma-dev -uninstall
Nota: Si aprobó opciones personalizadas (por ejemplo -d test:localhost ) para -setup , asegúrese de pasarlas a -uninstall también. De lo contrario /etc/resolver/* podría contener entradas huérfanas.
Cuando PUMA-DEV se instala como agente de usuario (el modo predeterminado), registrará la salida de sí mismo y las aplicaciones a ~/Library/Logs/puma-dev.log . Puede consultar allí para averiguar si las aplicaciones han comenzado y buscan errores.
En el futuro, PUMA-DEV proporcionará una consola integrada para esta salida de registro.
PUMA -DEV admite Linux pero requiere que se sigan los siguientes pasos de instalación adicionales para que todas las características funcionen (no se proporcionan banderas -install y -setup para Linux)::
Se genera el PUMA-Dev Root CA (en ~/.puma-dev-ssl/ ), pero deberá instalar y confiar en esto como una autoridad de certificado agregándola a la tienda de confianza de certificados de su sistema operativo, o confiarlo directamente En su navegador favorito (como algunos navegadores no compartirán la tienda de confianza del sistema operativo).
Primero, comience a PUMA-DEV para generar un certificado CA en ~/.puma-dev-ssl/cert.pem .
Para Arch Linux, Fedora y otras distribuciones con P11-Kit, intente esto:
# convert from PEM to DER
openssl x509 -in ~ /.puma-dev-ssl/cert.pem -outform der -out ~ /.puma-dev-ssl/cert.crt
# store certificate as an anchor in the trust policy store
sudo trust anchor --store ~ /.puma-dev-ssl/cert.crt
# verify
trust list --filter=ca-anchors | grep -i -C2 Puma-devPara Debian, Ubuntu, etc., prueba esto:
sudo mkdir -p /usr/local/share/ca-certificates
sudo cp ~ /.puma-dev-ssl/cert.pem /usr/local/share/ca-certificates/puma-dev-pem.crt
sudo update-ca-certificates En los sistemas con systemd-resolved la extensión .localhost estará disponible de forma predeterminada. Intente ping some-domain.localhost para ver si funciona.
Para que las solicitudes del dominio .test (o cualquier otro personalizado) se resuelvan, instale el resolver dev-tld, asegurándose de usar test (o el TLD personalizado que desea usar) al configurar TLDS.
Linux evita que las aplicaciones se vinculen a los puertos más bajos que 1024 de forma predeterminada. No necesita vincularse al puerto 80/443 para usar PUMA-DEV, pero hace que el uso del dominio .test sea mucho más agradable (por ejemplo, podrá usar el dominio como está en su navegador en lugar de proporcionar un número de puerto )
Hay 2 opciones para permitir que Puma-Dev escuche en el puerto 80 y 443:
sudo setcap CAP _ NET _ BIND _ SERVICE=+eip /path/to/puma-dev o 2. Instale authbind . e invoca Puma-Dev con él cuando quieras usarlo, por ejemplo,
authbind puma-dev -http-port 80 -https-port 443 Hay un atajo para la unión a 80/443 pasando -sysbind a PUMA -Dev al comenzar, lo que anula -http-port y -https-port .
En Linux, PUMA -DEV no se ejecutará automáticamente en segundo plano (según el script MACOS -install ); Tendrás que ejecutarlo en primer plano. Puede configurar un demonio del sistema para iniciar Puma-Dev en el fondo usted mismo.
/lib/systemd/system/puma-dev.service y ponga lo siguiente: [Unit]
After=network.target
[Service]
User=$USER
ExecStart=/path/to/puma-dev -sysbind
Restart=on-failure
[Install]
WantedBy=multi-user.target
Reemplace path/to/puma-dev con una ruta absoluta a PUMA-Dev Reemplace la variable $USER con el nombre del usuario en el que desea ejecutar.
sudo systemctl daemon-reload
sudo systemctl enable puma-dev
sudo systemctl start puma-dev En sistemas con Selinux, es posible que deba ejecutar restorecon /path/to/puma-dev para ejecutarlo.
¡Simplemente contenga el directorio de su aplicación en ~/.puma-dev ! ¡Eso es todo!
Puede usar el subcomando Helper incorporado: puma-dev link [-n name] [dir] para vincular los directorios de aplicaciones en su directorio PUMA-DEV ( ~/.puma-dev de forma predeterminada).
Run: puma-dev -h
Tiene la capacidad de configurar la mayoría de los valores que usará día a día.
PUMA-DEV admite variables de entorno de carga antes de que comience PUMA. Verifica los siguientes archivos en este orden:
~/.powconfig.env.powrc.powenv.pumaenvPuede evitar que PUMA-DEV cargue cualquiera de estos archivos de entorno estableciendo una variable de entorno correspondiente en '0':
PUMADEV_SOURCE_POWCONFIG=0PUMADEV_SOURCE_ENV=0PUMADEV_SOURCE_POWRC=0PUMADEV_SOURCE_POWENV=0PUMADEV_SOURCE_PUMAENV=0Además, PUMA-DEV utiliza algunas otras variables de entorno para controlar cómo se inicia PUMA que puede sobrescribir en su configuración de shell cargada.
CONFIG : un archivo de configuración PUMA para cargar, generalmente algo como config/puma-dev.rb . El valor predeterminado no config.THREADS : cuántos hilos debe usar PUMA simultáneamente. El valor predeterminado a 5.WORKERS : cuántos procesos de trabajadores comenzar. El valor predeterminado es 0, lo que significa que solo usa subprocesos..test ..dev , pero es propiedad de Google y desde diciembre de 2017 HSTS solo con sitios web reales alojados allí..dev y .foo , ya que son TLDS reales. Si desea que PUMA-Dev reinicie una aplicación específica , puede ejecutar touch tmp/restart.txt en el directorio de esa aplicación.
Si desea que PUMA-Dev detenga todas las aplicaciones (para problemas de recursos o porque una aplicación no se reinicie correctamente), puede enviar puma-dev la señal USR1 . La forma más fácil de hacerlo es:
puma-dev -stop
Run: puma-dev
Puma-Dev se iniciará de forma predeterminada utilizando el directorio ~/.puma-dev , buscando enlaces simbólicos a aplicaciones al igual que POW. Deje caer un enlace simbólico a su aplicación allí como: cd ~/.puma-dev; ln -s /path/to/my/app test . Ahora puede acceder a su aplicación como test.test .
Ejecutar puma-dev de esta manera requerirá que use el puerto HTTP listado, que es 9280 de forma predeterminada.
PUMA-DEV V0.3 y luego use la lista de lanzamiento para acceder a puertos privilegiados, por lo que si instaló V0.2, deberá eliminar las reglas del firewall.
Run: sudo puma-dev -cleanup
Por defecto, PUMA-DEV usa la .test de dominio para administrar sus aplicaciones. Si desea que Puma-Dev busque aplicaciones en ~/.pow , simplemente ejecute puma-dev -pow .
Si tiene un conjunto más complejo de aplicaciones que desea que PUMA-DEV administre, también puede usar subdirectorios en ~/.puma-dev . Esto funciona nombrando la aplicación con un guión ( - ) donde tendría una barra ( / ) en el nombre de host. Entonces, por ejemplo, si accede a cool-frontend.test , Puma-Dev buscará ~/.puma-dev/cool-frontend y si no encuentra nada, intente ~/.puma-dev/cool/frontend .
Puma-Dev también puede proxy de solicitudes de un buen dominio de desarrollo a otra aplicación. Para hacerlo, simplemente escriba un archivo (en lugar de un directorio de enlaces simbólicos) en ~/.puma-dev con la información de conexión.
Por ejemplo, para que el puerto 9292 aparezca como awesome.test echo 9292 > ~/.puma-dev/awesome
O para proxy a otro anfitrión: echo 10.3.1.2:9292 > ~/.puma-dev/awesome-elsewhere .
Puma-Dev automáticamente hace que las aplicaciones también a través de SSL también. Cuando ejecute PUMA-DEV por primera vez, probablemente habrá causado que un diálogo parezca su contraseña. Lo que sucedió allí fue PUMA-Dev genera su propia certificación CA que se almacena en ~/Library/Application Support/io.puma.dev/cert.pem .
Ese CA Cert se utiliza para crear dinámicamente certificados para sus aplicaciones cuando se solicita el acceso a ellas. Ocurre automáticamente, no es necesaria la configuración. Los certificados se almacenan completamente en la memoria, por lo que los reinicios futuros de PUMA-DEV simplemente generan nuevos.
Cuando se usa -install (y seamos honestos, así es como desea usar Puma-Dev), luego escucha en el puerto 443 de forma predeterminada (configurable con -install-https-port ) para que pueda hacer https://blah.test para acceder a su aplicación a través de HTTPS.
Si su aplicación usa HTTPS, el servidor de desarrollo de Webpack (WDS) también debe ejecutarse a través de SSL para evitar errores de "contenido mixto" del navegador. Si bien el WDS puede generar sus propios certificados, estos caducan regularmente y, a menudo, necesitan volver a absorber en una nueva pestaña para evitar repetir errores de la consola sobre /sockjs-node/info?t=123 que rompen la reducción automática de activos a través de WDS.
Para arreglar esto, deje WDS en modo HTTP liso y combine las características proxy y HTTPS de PUMA-DEV.
Aquí le mostramos cómo configurar rieles y la gema webpacker, para una aplicación de ejemplo que ya se ejecuta en https://blah.test :
echo 3035 > ~/.puma-dev/webpack.blah para configurar el proxy en el WDSconfig/environments/development.rb para incluir uno de los siguientes: # for webpacker-only projects
config.action_controller.asset_host = '//webpack.blah.test'
# for hybrid webpacker/sprockets projects
config.action_controller.asset_host = proc { |source| '//webpack.blah.test' if source.starts_with?('/packs') }
config/webpacker.yml para que coincida: dev_server:
https: false
host: localhost
port: 3035
public: webpack.blah.test
Ahora puede reiniciar la aplicación con puma-dev -stop e iniciar WDS con bin/webpack-dev-server .
Puma-Dev admite WebSockets de forma nativa, pero es posible que deba decirle a su marco web que permita las conexiones.
En el caso de Rails, debe configurar Rails para permitir todas las solicitudes de WebSockets o WebSocket de ciertos dominios. La forma más rápida es agregar config.action_cable.disable_request_forgery_protection = true a config/environments/development.rb . Esto permitirá todas las conexiones WebSocket mientras están en desarrollo.
¡No use Disable_request_forgery_Protection en producción!
O puede agregar algo como config.action_cable.allowed_request_origins = /(.test$)|^localhost$/ para permitir cualquier cosa bajo .test y localhost .
Puma-Dev admite los dominios xip.io y nip.io Los detectará y los eliminará para que se pueda acceder a su aplicación test como test.ABCDxip.io .
Puma-Dev le permite ejecutar múltiples dominios locales. Handy si estás trabajando con más de un cliente. Simplemente configure Puma-Dev como: puma-dev -install -d first-domain:second-domain .
Puma-Dev admite dominios, no solo TLD. puma-dev -install -d test:puma.dev permitirá que myapp.test y myapp.puma.dev se resuelvan correctamente. Pero, por supuesto, esto haría que la página web del proyecto en https://puma.dev sea inaccesible.
Al igual que POW, PUMA-Dev admite servir archivos estáticos. Si una aplicación tiene un directorio public , entonces se sirve cualquier URL que coincida con archivos dentro de ese directorio. Los archivos estáticos tienen prioridad sobre la aplicación.
Una vez que se instala un host virtual, también se puede acceder automáticamente desde todos los subdominios del host nombrado. Por ejemplo, también se puede acceder a un host virtual myapp en http://www.myapp.test/ y http://assets.www.myapp.test/ . Puede anular este comportamiento para, por ejemplo, señalar www.myapp.test a una aplicación diferente: simplemente cree otro enlace simbólico virtual de host llamado www.myapp para la aplicación que desea.
Puma-Dev está comenzando a desarrollar una API de estado que se puede usar para introspectarlo y las aplicaciones. Para acceder a él, envíe una solicitud con el Host: puma-dev y la ruta /status , por ejemplo: curl -H "Host: puma-dev" localhost/status .
El estado incluye:
Puma-Dev emite una serie de eventos internos y los expone a través de una API de eventos. Estos eventos pueden ser útiles al solucionar problemas de errores de configuración. Para acceder a él, envíe una solicitud con el Host: puma-dev y la ruta /events , por ejemplo: curl -H "Host: puma-dev" localhost/events .
Para construir Puma-Dev, siga estos pasos:
go mod downloadmake build./puma-dev -V para usar su nuevo binario Las construcciones etiquetadas (por ejemplo, v0.18.0 ) crearán automáticamente el liberación previa con artefactos para su uso en la fórmula casera.
Todas las compilaciones con pruebas de aprobación publicarán binarios que se guardan durante 90 días.
