puma dev
v0.18.3
Puma-Dev est le successeur émotionnel de Pow. Il offre un moyen rapide et facile de gérer les applications en développement sur macOS et Linux.
.test (configurable).test , .puma .pow n'est plus maintenu Tout d'abord, assurez-vous que la gemme puma est installée. Il appartient probablement au gemfile de la ou des applications que vous essayez de servir via PUMA-DEV.
# Gemfile
gem 'puma' brew install puma/puma/puma-dev
Vous pouvez télécharger des binaires pour macOS et Linux sur 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 vous souhaitez que puma-dev utilise un port autre que 80, passez-le via le -install-port , par exemple pour utiliser le port 81: puma-dev -install -install-port 81 .
Remarque: Si vous avez installé PUMA-DEV V0.2, veuillez exécuter sudo puma-dev -cleanup pour supprimer les règles de pare-feu que PUMA-DEV n'utilise plus (et sera en conflit avec PUMA-DEV fonctionnant).
Remarque: Si vous aviez déjà installé Pow dans le système, assurez-vous d'exécuter le script de désinstallation de POW. Lisez plus de détails dans le manuel POW.
Run: puma-dev -uninstall
Remarque: Si vous avez passé des options personnalisées (par exemple -d test:localhost ) à -setup , assurez-vous de les transmettre à -uninstall également. Sinon /etc/resolver/* peut contenir des entrées orphelines.
Lorsque PUMA-DEV est installé en tant qu'agent utilisateur (le mode par défaut), il enregistrera la sortie de lui-même et des applications vers ~/Library/Logs/puma-dev.log . Vous pouvez vous référer à là-bas pour savoir si les applications ont commencé et rechercher des erreurs.
À l'avenir, PUMA-DEV fournira une console intégrée pour cette sortie de journal.
PUMA-DEV prend en charge Linux mais nécessite les étapes d'installation supplémentaires suivantes pour que toutes les fonctionnalités fonctionnent ( -install et -setup les drapeaux pour Linux ne sont pas fournis):
Le PUMA-DEV Root CA est généré (dans ~/.puma-dev-ssl/ ), mais vous devrez l'installer et faire confiance en tant qu'autorité de certificat en l'ajoutant au magasin de confiance de certificat de votre système d'exploitation, ou en lui faisant confiance directement dans votre navigateur préféré (car certains navigateurs ne partageront pas le magasin de confiance du système d'exploitation).
Tout d'abord, démarrez PUMA-DEV pour générer un certificat CA en ~/.puma-dev-ssl/cert.pem .
Pour Arch Linux, Fedora et d'autres distributions à l'aide de p11-kit, essayez ceci:
# 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-devPour Debian, Ubuntu, etc., essayez ceci:
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 Sur les systèmes avec systemd-resolved l'extension .localhost sera disponible par défaut. Essayez ping some-domain.localhost pour voir si cela fonctionne.
Pour que les demandes du domaine .test (ou tout autre personnalité) à résoudre, installez le Dev-Tld-Resolver, en vous assurant d'utiliser test (ou le TLD personnalisé que vous souhaitez utiliser) lors de la configuration des TLD.
Linux empêche les applications de se lier aux ports plus bas que 1024 par défaut. Vous n'avez pas besoin de vous lier au port 80/443 pour utiliser PUMA-DEV, mais cela rend l'utilisation du domaine .test )
Il y a 2 options pour permettre à Puma-Dev d'écouter sur les ports 80 et 443:
sudo setcap CAP _ NET _ BIND _ SERVICE=+eip /path/to/puma-dev ou 2. Installez authbind . et invoquez Puma-Dev avec lui lorsque vous souhaitez l'utiliser, par exemple
authbind puma-dev -http-port 80 -https-port 443 Il y a un raccourci pour la liaison à 80/443 en passant -sysbind à Puma-Dev lors du démarrage, qui remplace -http-port et -https-port .
Sur Linux, PUMA-DEV ne s'exécutera pas automatiquement en arrière-plan (selon le script macOS -install ); Vous devrez l'exécuter au premier plan. Vous pouvez configurer un démon système pour démarrer PUMA-DEV en arrière-plan vous-même.
/lib/systemd/system/puma-dev.service et mettre ce qui suit: [Unit]
After=network.target
[Service]
User=$USER
ExecStart=/path/to/puma-dev -sysbind
Restart=on-failure
[Install]
WantedBy=multi-user.target
Remplacez path/to/puma-dev par un chemin absolu pour PUMA-DEV remplacer la variable $USER par le nom de l'utilisateur dans lequel vous souhaitez exécuter.
sudo systemctl daemon-reload
sudo systemctl enable puma-dev
sudo systemctl start puma-dev Sur les systèmes avec SELINUX, vous devrez peut-être exécuter restorecon /path/to/puma-dev afin de l'exécuter.
Symagez simplement le répertoire de votre application dans ~/.puma-dev ! C'est ça!
Vous pouvez utiliser la sous-commande d'assistance intégrée: puma-dev link [-n name] [dir] pour lier les répertoires d'applications dans votre répertoire PUMA-DEV ( ~/.puma-dev par défaut).
Run: puma-dev -h
Vous avez la possibilité de configurer la plupart des valeurs que vous utiliserez au jour le jour.
PUMA-DEV prend en charge les variables d'environnement de chargement avant le début de PUMA. Il vérifie les fichiers suivants dans cet ordre:
~/.powconfig.env.powrc.powenv.pumaenvVous pouvez empêcher PUMA-DEV de charger l'un de ces fichiers environnementaux en définissant une variable d'environnement correspondante à «0»:
PUMADEV_SOURCE_POWCONFIG=0PUMADEV_SOURCE_ENV=0PUMADEV_SOURCE_POWRC=0PUMADEV_SOURCE_POWENV=0PUMADEV_SOURCE_PUMAENV=0De plus, PUMA-DEV utilise quelques autres variables d'environnement pour contrôler comment PUMA est démarré que vous pouvez écraser dans votre configuration de shell chargé.
CONFIG : un fichier de configuration PUMA à charger, généralement quelque chose comme config/puma-dev.rb . Par défaut, aucune configuration.THREADS : Combien de threads PUMA doit utiliser simultanément. Par défaut à 5.WORKERS : Combien de processus de travailleurs commencent. Par défaut est 0, ce qui signifie que vous utilisez uniquement des threads..test ..dev , mais il appartient à Google et depuis décembre 2017 HSTS uniquement avec de vrais sites Web hébergés..dev et .foo , car ce sont de vrais TLD. Si vous souhaitez que PUMA-DEV redémarre une application spécifique , vous pouvez exécuter touch tmp/restart.txt dans le répertoire de cette application.
Si vous souhaitez que PUMA-DEV arrête toutes les applications (pour les problèmes de ressources ou parce qu'une application ne redémarre pas correctement), vous pouvez envoyer puma-dev le signal USR1 . La façon la plus simple de le faire est:
puma-dev -stop
Run: puma-dev
PUMA-DEV sera démarré par défaut à l'aide du répertoire ~/.puma-dev , à la recherche de symbals symboliques sur les applications comme POW. Déposez un lien symbolique à votre application comme: cd ~/.puma-dev; ln -s /path/to/my/app test . Vous pouvez désormais accéder à votre application en tant que test.test .
L'exécution de puma-dev de cette manière vous obligera à utiliser le port HTTP répertorié, qui est 9280 par défaut.
PUMA-DEV V0.3 et utilisez plus tard Launchd pour accéder aux ports privilégiés, donc si vous avez installé V0.2, vous devrez supprimer les règles de pare-feu.
Courir: sudo puma-dev -cleanup
Par défaut, PUMA-DEV utilise le domaine .test pour gérer vos applications. Si vous voulez que Puma-DEV recherche des applications dans ~/.pow , exécutez simplement puma-dev -pow .
Si vous avez un ensemble d'applications plus complexes que vous souhaitez gérer PUMA-DEV, vous pouvez également utiliser des sous-répertoires sous ~/.puma-dev . Cela fonctionne en nommant l'application avec un trait d'union ( - ) où vous auriez une barre oblique ( / ) dans le nom d'hôte. Ainsi, par exemple, si vous accédez cool-frontend.test , Puma-Dev recherchera ~/.puma-dev/cool-frontend et s'il ne trouve rien, essayez ~/.puma-dev/cool/frontend .
PUMA-DEV peut également proxy les demandes d'un joli domaine de développement vers une autre application. Pour ce faire, écrivez simplement un fichier (plutôt qu'un répertoire systémique) dans ~/.puma-dev avec les informations de connexion.
Par exemple, pour que le port 9292 apparaisse comme awesome.test : echo 9292 > ~/.puma-dev/awesome .
Ou pour procurer à un autre hôte: echo 10.3.1.2:9292 > ~/.puma-dev/awesome-elsewhere .
PUMA-DEV rend également les applications disponibles via SSL. Lorsque vous exécutez PUMA-DEV pour la première fois, cela aura probablement provoqué un dialogue à mettre dans votre mot de passe. Ce qui s'est passé, PUMA-DEV génère sa propre certification CA qui est stockée dans ~/Library/Application Support/io.puma.dev/cert.pem .
Ce certificat CA est utilisé pour créer dynamiquement des certificats pour vos applications lorsque l'accès à eux est demandé. Cela se produit automatiquement, aucune configuration nécessaire. Les certificats sont entièrement stockés en mémoire, donc les redémarrages futurs de PUMA-DEV en génèrent simplement de nouveaux.
Lorsque -install est utilisé (et soyons honnêtes, c'est ainsi que vous souhaitez utiliser PUMA-DEV), puis il écoute le port 443 par défaut (configurable avec -install-https-port ) afin que vous puissiez simplement faire https://blah.test pour accéder à votre application via HTTPS.
Si votre application utilise HTTPS, le serveur de développement WebPack (WDS) doit également être exécuté via SSL pour éviter les erreurs de "contenu mixte" du navigateur. Bien que le WDS puisse générer ses propres certificats, ceux-ci expirent régulièrement et ont souvent besoin de reproduire dans un nouvel onglet pour éviter de répéter les erreurs de console sur /sockjs-node/info?t=123 qui rompent le relaxage automatique des actifs via WDS.
Pour corriger ce WDS, Laissez les WDS en mode HTTP ordinaire et combinez les fonctionnalités de proxy et de HTTPS de Puma-DEV.
Voici comment configurer les rails et le webpacker Gem, pour un exemple d'application qui s'exécute déjà sur https://blah.test :
echo 3035 > ~/.puma-dev/webpack.blah pour configurer le proxy au WDSconfig/environments/development.rb pour inclure l'une des opérations suivantes: # 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 pour correspondre: dev_server:
https: false
host: localhost
port: 3035
public: webpack.blah.test
Vous pouvez maintenant redémarrer l'application avec puma-dev -stop et démarrer WDS avec bin/webpack-dev-server .
PUMA-DEV prend en charge les WebSockets nativement, mais vous devrez peut-être informer votre framework Web pour permettre les connexions.
Dans le cas des rails, vous devez configurer des rails pour permettre à tous les listes Web ou aux demandes WebSocket de certains domaines. Le moyen le plus rapide consiste à ajouter config.action_cable.disable_request_forgery_protection = true à config/environments/development.rb . Cela permettra toutes les connexions WebSocket pendant le développement.
N'utilisez pas Disable_Request_Forgery_Protection en production!
Ou vous pouvez ajouter quelque chose comme config.action_cable.allowed_request_origins = /(.test$)|^localhost$/ pour autoriser quoi que ce soit sous .test ainsi que localhost .
PUMA-DEV prend en charge les domaines xip.io et nip.io Il les détectera et les déploiera, afin que votre application test soit accessible en tant que test.ABCDxip.io .
PUMA-DEV vous permet d'exécuter plusieurs domaines locaux. À portée de main si vous travaillez avec plus d'un client. Configurez simplement PUMA-DEV comme SO: puma-dev -install -d first-domain:second-domain .
PUMA-DEV prend en charge les domaines, pas seulement les TLD. puma-dev -install -d test:puma.dev permettra à myapp.test et myapp.puma.dev de résoudre correctement. Mais, bien sûr, cela rendrait la page Web du projet à https://puma.dev inaccessible.
Comme POW, PUMA-DEV Prise en charge desservant des fichiers statiques. Si une application a un répertoire public , les URL qui correspondent aux fichiers dans ce répertoire sont servies. Les fichiers statiques ont la priorité sur l'application.
Une fois qu'un hôte virtuel est installé, il est également automatiquement accessible à partir de tous les sous-domaines de l'hôte nommé. Par exemple, un hôte virtuel myapp était également accessible à http://www.myapp.test/ et http://assets.www.myapp.test/ . Vous pouvez remplacer ce comportement pour, par exemple, point www.myapp.test à une application différente: créez simplement un autre lien d'hôte virtuel nommé www.myapp pour l'application que vous souhaitez.
PUMA-DEV commence à faire évoluer une API de statut qui peut être utilisée pour l'introspecter et les applications. Pour y accéder, envoyez une demande avec l' Host: puma-dev et le chemin /status , par exemple: curl -H "Host: puma-dev" localhost/status .
Le statut comprend:
PUMA-DEV émet un certain nombre d'événements internes et les expose via une API d'événements. Ces événements peuvent être utiles lors du dépannage des erreurs de configuration. Pour y accéder, envoyez une demande avec l' Host: puma-dev et le chemin /events , par exemple: curl -H "Host: puma-dev" localhost/events .
Pour construire PUMA-DEV, suivez ces étapes:
go mod downloadmake build./puma-dev -V pour utiliser votre nouveau binaire Tagged builds (par exemple v0.18.0 ) créera automatiquement la pré-libération avec des artefacts à utiliser dans la formule Homebrew.
Toutes les constructions avec des tests de passage publieront des binaires qui sont sauvés pendant 90 jours.
