puma dev
v0.18.3
Puma-dev é o sucessor emocional de Pow. Ele fornece uma maneira rápida e fácil de gerenciar aplicativos em desenvolvimento no MacOS e Linux.
.test (configurável).test , .puma .pow não é mais mantido Primeiro, verifique se a gema puma está instalada. Provavelmente pertence ao Gemfile dos aplicativos que você está tentando servir via Puma-Dev.
# Gemfile
gem 'puma' brew install puma/puma/puma-dev
Você pode baixar binários para macOS e Linux em 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 Se você deseja que puma-dev use uma porta diferente de 80, passe-o por meio da -install-port , por exemplo, para usar a porta 81: puma-dev -install -install-port 81 .
NOTA: Se você instalou o PUMA-DEV v0.2, execute sudo puma-dev -cleanup para remover as regras do firewall que o Puma-dev não usa mais (e entrará em conflito com o trabalho do Puma-dev).
NOTA: Se você tinha o PoW instalado antes no sistema, certifique -se de executar o script de desinstalação do POW. Leia mais detalhes no manual do PoW.
Run: puma-dev -uninstall
Nota: Se você passou as opções personalizadas (por exemplo -d test:localhost ) para -setup , não se esqueça de passar para -uninstall também. Caso contrário /etc/resolver/* pode conter entradas órfãs.
Quando o PUMA-DEV é instalado como um agente do usuário (o modo padrão), ele registrará a saída de si mesma e dos aplicativos para ~/Library/Logs/puma-dev.log . Você pode consultar lá para descobrir se os aplicativos foram iniciados e procurar erros.
No futuro, o Puma-Dev fornecerá um console integrado para esta saída de log.
O PUMA -DEV suporta o Linux, mas requer as seguintes etapas de instalação adicionais a serem seguidas para fazer com que todos os recursos funcionem ( -install e -setup sinalizadores para Linux não são fornecidos):
A raiz puma-dev CA é gerada (em ~/.puma-dev-ssl/ ), mas você precisará instalar e confiar isso como uma autoridade de certificado adicionando-a ao armazenamento de confiança de certificação do seu sistema operacional ou confiando diretamente nele diretamente no seu navegador preferido (pois alguns navegadores não compartilham o armazenamento de confiança do sistema operacional).
Primeiro, comece a Puma-dev para gerar um certificado de CA em ~/.puma-dev-ssl/cert.pem .
Para Arch Linux, Fedora e outras distribuições usando o p11-kit, tente o seguinte:
# 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, tente o seguinte:
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 Em sistemas com systemd-resolved a extensão .localhost estará disponível por padrão. Experimente ping some-domain.localhost para ver se funciona.
Para solicitações para o domínio .test (ou qualquer outro personalizado) para resolver, instale o dev-resolver, certificando-se de usar test (ou o TLD personalizado que você deseja usar) ao configurar o TLDS.
O Linux impede que as aplicações de ligação para as portas diminuam a 1024 por padrão. Você não precisa se ligar à porta 80/443 para usar o Puma-dev, mas isso torna o uso do domínio .test muito melhor (por exemplo, você poderá usar o domínio como está no seu navegador, em vez de fornecer um número de porta )
Existem 2 opções para permitir que o Puma-dev ouça na porta 80 e 443:
sudo setcap CAP _ NET _ BIND _ SERVICE=+eip /path/to/puma-dev ou 2. Instale authbind . e invocar Puma-dev com ele quando você quiser usá-lo, por exemplo,
authbind puma-dev -http-port 80 -https-port 443 Há um atalho para se ligar para 80/443 passando -sysbind para puma -dev ao iniciar, que substitui -http-port e -https-port .
No Linux, o puma -dev não será executado automaticamente em segundo plano (conforme o script -install do macOS); Você precisará executá -lo em primeiro plano. Você pode configurar um daemon do sistema para iniciar o Puma-dev em segundo plano.
/lib/systemd/system/puma-dev.service e coloque o seguinte: [Unit]
After=network.target
[Service]
User=$USER
ExecStart=/path/to/puma-dev -sysbind
Restart=on-failure
[Install]
WantedBy=multi-user.target
Substitua path/to/puma-dev por um caminho absoluto para o puma-dev substituir a variável de $USER pelo nome do usuário em que você deseja executar.
sudo systemctl daemon-reload
sudo systemctl enable puma-dev
sudo systemctl start puma-dev Em sistemas com Selinux, você pode ter que executar restorecon /path/to/puma-dev para executá-lo.
Simplesmente simplifique o diretório do seu aplicativo para ~/.puma-dev ! É isso!
Você pode usar o subcomando auxiliar embutido: puma-dev link [-n name] [dir] para vincular diretórios de aplicativos ao seu diretório puma-dev ( ~/.puma-dev por padrão).
Run: puma-dev -h
Você tem a capacidade de configurar a maioria dos valores que usará no dia-a-dia.
O PUMA-DEV suporta variáveis de ambiente de carregamento antes do início do Puma. Ele verifica os seguintes arquivos neste pedido:
~/.powconfig.env.powrc.powenv.pumaenvVocê pode impedir que o Puma-dev carregue qualquer um desses arquivos de ambiente definindo uma variável de ambiente correspondente como '0':
PUMADEV_SOURCE_POWCONFIG=0PUMADEV_SOURCE_ENV=0PUMADEV_SOURCE_POWRC=0PUMADEV_SOURCE_POWENV=0PUMADEV_SOURCE_PUMAENV=0Além disso, o Puma-Dev usa algumas outras variáveis de ambiente para controlar como é iniciado o Puma que você pode substituir na sua configuração de shell carregada.
CONFIG : um arquivo de configuração do Puma para carregar, geralmente algo como config/puma-dev.rb . Padrões para nenhuma configuração.THREADS : quantos threads o puma deve usar simultaneamente. Padrões para 5.WORKERS : Quantos processos de trabalhadores começam. Padrões para 0, o que significa apenas usar threads..test ..dev , mas é de propriedade do Google e desde dezembro de 2017 HSTs apenas com sites reais hospedados lá..dev e .foo , pois são TLDs reais. Se você deseja reiniciar o Puma-dev um aplicativo específico , pode executar touch tmp/restart.txt no diretório desse aplicativo.
Se você deseja que o PUMA-DEV pare todos os aplicativos (para problemas de recursos ou porque um aplicativo não está reiniciando corretamente), você pode enviar puma-dev o sinal USR1 . A maneira mais fácil de fazer isso é:
puma-dev -stop
Run: puma-dev
O PUMA-DEV inicializará por padrão usando o diretório ~/.puma-dev , procurando symblinks para aplicativos como o Pow. Solte um link simulado no seu aplicativo como: cd ~/.puma-dev; ln -s /path/to/my/app test . Agora você pode acessar seu aplicativo como test.test .
A execução puma-dev dessa maneira exigirá que você use a porta HTTP listada, que é 9280 por padrão.
Puma-dev v0.3 e use posteriormente o Launchd para acessar portas privilegiadas; portanto, se você instalou v0.2, precisará remover as regras do firewall.
Execução: sudo puma-dev -cleanup
Por padrão, o Puma-Dev usa o domínio .test para gerenciar seus aplicativos. Se você quiser fazer com que o Puma-dev procure aplicativos em ~/.pow , basta executar puma-dev -pow .
Se você possui um conjunto mais complexo de aplicativos que deseja que o Puma-dev gerencie, também poderá usar subdiretos em ~/.puma-dev . Isso funciona nomeando o aplicativo com um hífen ( - ) onde você teria uma barra ( / ) no nome do host. Por exemplo, se você acessar cool-frontend.test , o Puma-dev procurará ~/.puma-dev/cool-frontend e, se não encontrar nada, tente ~/.puma-dev/cool/frontend .
O PUMA-DEV também pode solicitar solicitações de proxy de um bom domínio dev para outro aplicativo. Para isso, basta escrever um arquivo (em vez de um diretório simplink) em ~/.puma-dev com as informações de conexão.
Por exemplo, para que a porta 9292 apareça como awesome.test : echo 9292 > ~/.puma-dev/awesome .
Ou proxy para outro host: echo 10.3.1.2:9292 > ~/.puma-dev/awesome-elsewhere .
O Puma-Dev disponibiliza automaticamente os aplicativos via SSL. Quando você executa pela primeira vez o PUMA-DEV, ele provavelmente fez com que uma caixa de diálogo pareça colocar sua senha. O que aconteceu foi que o Puma-Dev gera sua própria certificação CA, armazenada em ~/Library/Application Support/io.puma.dev/cert.pem .
Esse cert de CA é usado para criar certificados dinamicamente para seus aplicativos quando o acesso a eles é solicitado. Acontece automaticamente, não é necessária uma configuração. Os certificados são armazenados inteiramente na memória; portanto, os reinicializadores futuros do Puma-Dev simplesmente geram novos.
Quando -install é usado (e sejamos honestos, é assim que você deseja usar o puma-dev), então ele ouve na porta 443 por padrão (configurável com -install-https-port ) para que você possa fazer apenas https://blah.test para acessar seu aplicativo via https.
Se o seu aplicativo usar o HTTPS, o WebPack Dev Server (WDS) deve ser executado via SSL também para evitar erros de "conteúdo misto" do navegador. Embora o WDS possa gerar seus próprios certificados, eles expiraram regularmente e geralmente precisam ser re-atendidos em uma nova guia para evitar repetir erros de console sobre /sockjs-node/info?t=123 que quebram a recuperação automática de ativos via WDS.
Para corrigir isso, deixa o WDS em execução no modo HTTP simples e combine os recursos de proxy e https da Puma-Dev.
Veja como configurar o Rails e o Webpacker Gem, para um exemplo de aplicativo que já está sendo executado em https://blah.test :
echo 3035 > ~/.puma-dev/webpack.blah para configurar o proxy para o WDSconfig/environments/development.rb para incluir um dos seguintes: # 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 corresponder: dev_server:
https: false
host: localhost
port: 3035
public: webpack.blah.test
Agora você pode reiniciar o aplicativo com puma-dev -stop e iniciar WDS com bin/webpack-dev-server .
O Puma-Dev suporta WebSockets nativamente, mas pode ser necessário informar à sua estrutura da web para permitir as conexões.
No caso dos Rails, você precisa configurar Rails para permitir que todos os WebSockets ou solicitações da WebSocket de determinados domínios. A maneira mais rápida é adicionar config.action_cable.disable_request_forgery_protection = true para config/environments/development.rb . Isso permitirá todas as conexões do WebSocket enquanto estiver em desenvolvimento.
Não use Disable_Request_Forgery_protection na produção!
Ou você pode adicionar algo como config.action_cable.allowed_request_origins = /(.test$)|^localhost$/ para permitir qualquer coisa sob .test e localhost .
O Puma-dev suporta domínios xip.io e nip.io Ele os detectará e retirará -os, para que seu aplicativo test possa ser acessado como test.ABCDxip.io .
O PUMA-DEV permite executar vários domínios locais. Handy se você estiver trabalhando com mais de um cliente. Basta configurar o puma-dev como assim: puma-dev -install -d first-domain:second-domain .
O PUMA-DEV suporta domínios, não apenas TLDs. puma-dev -install -d test:puma.dev permitirá que myapp.test e myapp.puma.dev resolvam corretamente. Mas, é claro, isso tornaria a página do projeto em https://puma.dev inacessível.
Como Pow, Puma-Dev Suporte que serve arquivos estáticos. Se um aplicativo tiver um diretório public , todos os URLs que correspondem a arquivos nesse diretório serão servidos. Os arquivos estáticos têm prioridade sobre o aplicativo.
Depois que um host virtual é instalado, ele também é acessível automaticamente a partir de todos os subdomínios do host nomeado. Por exemplo, um host virtual myapp também pode ser acessado em http://www.myapp.test/ e http://assets.www.myapp.test/ . Você pode substituir esse comportamento a, digamos, apontar www.myapp.test para um aplicativo diferente: basta criar outro host virtual symlink chamado www.myapp para o aplicativo desejado.
O PUMA-DEV está começando a evoluir uma API de status que pode ser usada para introduzi-la e os aplicativos. Para acessá-lo, envie uma solicitação com o Host: puma-dev e o caminho /status , por exemplo: curl -H "Host: puma-dev" localhost/status .
O status inclui:
O Puma-dev emite vários eventos internos e os expõe através de uma API de eventos. Esses eventos podem ser úteis ao solucionar erros de configuração. Para acessá-lo, envie uma solicitação com o Host: puma-dev e o caminho /events , por exemplo: curl -H "Host: puma-dev" localhost/events .
Para construir o Puma-dev, siga estas etapas:
go mod downloadmake build./puma-dev -V para usar seu novo binário As compilações marcadas (por exemplo, v0.18.0 ) criarão automaticamente o pré-lançamento com artefatos para uso na fórmula homebrew.
Todas as compilações com testes passantes publicarão binários salvos por 90 dias.
