De minha VM Ubuntu, consegui fazer ping em rubygems.org. Não sei se há uma maneira de verificar se o contêiner Docker consegue. Acredito que pinguei apenas a versão HTTP, não HTTPS, no entanto. Estou mencionando isso caso o problema esteja relacionado a isso. (Uma das páginas que vi ao pesquisar no Google sugeriu mudar de HTTPS para HTTP, mas não é como se eu pudesse fazer isso, já que o comportamento definido está em algum lugar dentro do contêiner Docker.)
1 curtida
Já tentei as opções do macOS.
Primeiro, usando a Opção 2, o Homebrew. No entanto, encontrei problemas, pois nem todas as dependências foram instaladas usando o comando deste guia. https://medium.com/@yutafujii_59175/a-complete-one-by-one-guide-to-install-docker-on-your-mac-os-using-homebrew-e818eb4cfc3 me ajudou a avançar um pouco.
Agora estou travado na Etapa 2 d/boot_dev --init:
Migrando banco de dados...
rake aborted!
PG::ConnectionBad: não foi possível conectar ao servidor: Nenhum arquivo ou diretório
O servidor está rodando localmente e aceitando
conexões no socket de domínio Unix "/var/run/postgresql/.s.PGSQL.5432"?
/src/lib/site_settings/db_provider.rb:61:in `table_exists?'
/src/lib/site_settings/db_provider.rb:16:in `all'
/src/lib/site_settings/defaults_provider.rb:29:in `db_all'
/src/lib/site_setting_extension.rb:277:in `block in refresh!'
/src/lib/site_setting_extension.rb:274:in `synchronize'
/src/lib/site_setting_extension.rb:274:in `refresh!'
/src/lib/site_setting_extension.rb:495:in `block in setup_methods'
/src/config/initializers/004-message_bus.rb:120:in `<main>'
/src/config/environment.rb:7:in `<main>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tarefas: TOP => db:migrate => db:load_config => environment
(Veja o rastreamento completo executando a tarefa com --trace)
Em seguida, baixei o arquivo .dmg, mas como sou novo no Docker, não entendo o que fazer a partir daí. Seria ótimo ter uma descrição um pouco mais detalhada da opção para macOS.
Obrigado.
1 curtida
No MacOS, após instalar o Docker a partir do arquivo .dmg, verifique apenas se ele está em execução — deve haver um ícone na barra de ferramentas do MacOS que você pode usar para conferir seu status. Em seguida, siga literalmente as instruções do primeiro post (clone, etc.). Publique aqui se encontrar algum problema ao seguir esse caminho.
Atenção: se você já instalou o Docker usando o Homebrew antes, pode ser uma boa ideia desinstalar essa versão primeiro ou, pelo menos, garantir que ela não esteja em execução. Eu nunca instalei o Docker com o Homebrew, então não posso dar orientações sobre isso.
2 curtidas
Obrigado.
Usei o ícone e abri o painel do Docker. Não encontrei nenhum contêiner em execução lá, mas na linha de comando pude ver vários contêineres rodando. Estava me perguntando se preciso fazer login para usar o painel do Docker? Ou talvez esse comportamento ocorra porque há várias versões do Docker instaladas: Homebrew e Desktop (.dmg)?
Enquanto isso, consegui configurar o Discourse no DigitalOcean, que está funcionando sem problemas e atende às minhas necessidades.
1 curtida
O DMG instala o Docker, não o Discourse. Ele não adicionará nenhum container inicialmente.
A partir daí, você pode seguir o guia do Docker.
2 curtidas
Ao executar o comando acima (em um Mac), recebo este erro:
Ocorreu um erro ao instalar o cppjieba_rb (0.3.3), e o Bundler não pode continuar.
Certifique-se de que `gem install cppjieba_rb -v '0.3.3' --source 'https://rubygems.org/'` tenha sucesso
antes de executar o bundler.
Você tem alguma sugestão? Não entendo exatamente qual é o problema. A instalação separada do gem também não funciona (mesmo com sudo).
Além disso, por que os gems precisam ser instalados quando estou executando uma imagem Docker? Isso já deveria ter sido pré-instalado completamente, certo?
ATUALIZAÇÃO: RESOLVIDO
Clonei para
~/repos/discourse, mas deveria ter sido para~/discourse. Agora funciona perfeitamente.
3 curtidas
Se você receber este erro ao executar d/unicorn:
Could not find aws-partitions-1.284.0 in any of the sources
Run `bundle install` to install missing gems.
você pode corrigi-lo executando:
docker exec -it -u discourse:discourse discourse_dev /bin/bash -c "cd /src && USER=discourse RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 LD_PRELOAD=/usr/lib/libjemalloc.so RAILS_ENV=${RAILS_ENV:=development} bundle install"
após o que d/boot_dev será executado com sucesso.
3 curtidas
Mais simples
d/boot_dev
d/bundle install
Temos helpers para todas as tarefas comuns.
5 curtidas
No OP está escrito
O fluxo de desenvolvimento do Docker suporta links simbólicos no diretório
plugins/
Para onde devemos vincular o diretório de plugins neste contexto? Obrigado!
1 curtida
cd plugins
ln -s /caminho/completo/do/seu/plugin .
ln -s ~/src/meu-otimo-plugin # por exemplo
6 curtidas
Ah, obrigado, apenas querendo criar um link simbólico para o diretório de plugins neste contexto.
1 curtida
Geralmente, você não cria um link simbólico para um diretório inteiro nesse fluxo de trabalho, pois normalmente deseja controle granular sobre quais plugins estão no escopo durante uma execução.
4 curtidas
Oi, estou usando este guia e ele funciona bem, mas minha preocupação é que sempre que executo d/boot_dev, ele começa a baixar várias coisas. Como faço para baixar apenas uma vez os arquivos necessários e mantê-los para a próxima inicialização? Meu sistema operacional é o Ubuntu 20.04.
1 curtida
Tentei instalar em um sistema Mint 20 limpo. O Docker está disponível:
terrapop@terrapop:/var$ docker version
Client: Docker Engine - Community
Version: 19.03.12
terrapop@terrapop:/var/discourse$ sudo systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset>
Active: active (running) since Mon 2020-08-24 19:03:48 CEST; 31min ago
Em seguida, clonei o Discourse:
sudo git clone GitHub - discourse/discourse_docker: A Docker image for Discourse · GitHub /var/discourse
cd /var/discourse
No entanto, ao executar d/boot_dev --init, obtive:
d/boot_dev --init
bash: d/boot_dev: Arquivo ou diretório não encontrado
Alguém?
1 curtida
Atualização: Agora adicionei nossas chaves de API do SendGrid ao app.yml e inicializei o aplicativo via ./launcher, e agora ele está rodando no localhost. Seria possível que todos aqueles comandos d/ no OP estejam desatualizados? Ainda assim, não entendo. O aplicativo agora está rodando no Docker no meu computador Ubuntu (Mint) no localhost, assim como faz no ambiente de staging na Digital Ocean. Queremos desenvolver no localhost com o aplicativo rodando via Docker e links simbólicos para plugins, mas não tenho certeza se está pronto como deveria, já que não consigo executar aqueles comandos d/ de forma alguma. Alguém poderia ajudar? Obrigado.
Atualização: Minha culpa. Peguei o link do git para produção:
git clone GitHub - discourse/discourse_docker: A Docker image for Discourse · GitHub /var/discourse
Em vez de:
git clone GitHub - discourse/discourse: A platform for community discussion. Free, open, simple. · GitHub
No entanto…
Agora estou enfrentando novos problemas. Só consigo clonar em /var como superusuário/root no Ubuntu Mint 20 (UID 0). Então, quando clono e executo d/boot_dev --init, tudo é baixado e iniciado corretamente, mas em uma etapa posterior o script lança um erro de permissão, pois espera executar algo com UID 1000, que é o primeiro usuário criado no Mint, ou seja, minha conta pessoal (terrapop), e não root. Como contornar esse problema?
Solução: Mais simples do que eu pensava. Basta criar um novo diretório www em var. Altere o proprietário (chown) e as permissões (chmod) do diretório www para o seu primeiro usuário no Mint e prossiga conforme descrito nos posts do OP. Agora funciona. Feliz.
2 curtidas
Por algum motivo, os links simbólicos para os diretórios de origem do meu plugin não estavam funcionando, e precisei mover/copiar manualmente os diretórios de origem do plugin para o diretório plugins para que eles aparecessem em /admin/plugins após reiniciar o contêiner Docker.
Talvez tenha havido uma mudança na forma como o Docker suporta links simbólicos? Estou executando o docker-ce 19.03.12 no Ubuntu.
1 curtida
Eu também experienciei isso recentemente com o Docker Desktop para Mac.
1 curtida
Fiz os mesmos passos em um droplet DO de $5. Tudo correu bem. Agora, como exponho meu site para que eu possa acessá-lo?
P.S. Funciona com ngrok. Ainda não funciona com proxy reverso nginx na porta 9292
Obrigado por isso. Você pode fazer isso no servidor e evitar configurar o proxy reverso nginx. Aproveitando a configuração d/o docker+vscode remoto 
Use d/unicorn -D para executar o unicorn como um daemon, para que o shell permaneça utilizável após iniciar o servidor.
Além disso, você precisa de pelo menos um droplet d/o de $10.
3 curtidas
Estou em um Mac com zsh (no iTerm2) e, ao tentar usar um link simbólico para o desenvolvimento de plugins, fico preso com esses erros:
readlink: opção ilegal -- f
uso: readlink [-n] [arquivo ...]
Isso ocorre porque a implementação do comando readlink no Mac é ligeiramente diferente da versão GNU.
A maneira mais fácil de resolver isso é fazendo o seguinte:
# brew install coreutils
# ln -s "$(which greadlink)" "$(dirname "$(which greadlink)")/readlink"
Isso permitirá que você use uma versão compatível do readlink.
Lembre-se de que você precisa ter o valor de dirname "$(which greadlink)" no seu PATH em uma posição anterior a /usr/bin (onde geralmente está o readlink original). No meu caso, o PATH é algo como /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:... e o link simbólico para o greadlink está em /usr/local/bin.
Referência: Fixing "readlink: illegal option -- f" error on a Mac
5 curtidas
Para executar um conjunto de testes de um único plugin, você pode fazer da seguinte maneira:
# d/rake "plugin:spec[NOME_DO_PLUGIN]"
1 curtida