Bootstrap / reconstruir sem clonar tudo novamente?

A instância do Discourse está localizada atrás do GFW, portanto, usamos um proxy SOCKS5 para Git. Temos alguns plugins instalados, então reconstruir ou inicializar o aplicativo clona todos esses repositórios repetidamente. Infelizmente, a clonagem resulta em tempo limite regularmente, então todo o processo começa do zero, mesmo que a base de código mais recente já esteja clonada. Gastei mais de 40 tentativas e desperdicei cerca de cinco horas. A última barreira é um sub-processo yarn dentro do contêiner, que geralmente atinge o tempo limite, resultando em uma atualização falha.

Existe alguma maneira de estruturar o app.yml, para que pelo menos eu não invoque todo o processo de clonagem de plugins? Clonar no código do docker-manager e na base de código do discourse tem uma chance de 50/50, com a clonagem subsequente em cerca de 1/3 de taxa de sucesso. Não sei o que causa a falha do sub-processo yarn, mas no momento parece não ser possível trazer o Discourse de volta à vida com os métodos fornecidos.

Claro, fui estúpido o suficiente para invocar launcher destroy app pois queria inicializá-lo manualmente, então nem consigo fazer um launcher enter app para tentar executar o comando yarn manualmente. Alguém tem alguma ideia? Obrigado pela sua contribuição.

Não sou especialista nesses assuntos, mas acho que a solução é um proxy de cache para as coisas que você está baixando.

Existe um web.china.template.yml, você está usando ele?

Claro. Eu uso a fonte Ruby chinesa em todos os aplicativos Rails, fico feliz em ter isso pelo menos. O que me intriga: todos os repositórios (incluindo os dos plugins) já estão clonados, apenas este subprocesso do yarn invoca o seguinte:

INFO -- : > cd /var/www/discourse && [ ! -d 'node_modules' ] || su discourse -c 'yarn install --production && yarn cache clean'

Por alguma razão, o GFW (Great Firewall) não gosta de muitos processos de git clone um após o outro e, em algum momento, encerra a conexão. Se eu pudesse apenas executar o launcher com uma flag que dissesse algo como “Ok cara, o código está aqui, não precisa clonar… apenas inicialize por enquanto”:grinning:

Edição: É inacreditável. Assim que digitamos, minha 78ª tentativa finalmente funcionou após 11 horas. Recorri ao sshuttle, que também levou ~12 tentativas, mas por alguma razão o GFW teve piedade da minha pobre alma.

É isso que seu próprio proxy de cache faria (ou assim eu pensaria). Eu daria uma olhada no squid. Então você veria que o launcher seria puxado do seu espelho em vez da fonte real.

O launcher não tem o código porque ele o está clonando em um novo contêiner sem nenhum código, é por isso que ele está baixando todo o código. Todas. As. Vezes.

Sim, temos alguma experiência com o Squid até certo ponto. Isso precisa de uma solução geral de qualquer maneira, pois não posso passar horas com uma atualização manual do Discourse toda vez. Por alguns meses, usar um proxy socks5 regular funcionou, mas é um jogo constante de “bate-a-toupeira” com o GFW e o acesso ao GitHub se tornou um incômodo desde o início de outubro. Não é de admirar que existam toneladas de clones neste site gitee.com.

Obrigado pela explicação sobre o launcher, sou bastante estúpido quando se trata de Docker e assumi que ele clona os repositórios git localmente e, em seguida, os grava em algum contêiner.

Definitivamente, examinarei as opções do Squid, pois isso também pode ajudar com minha segunda fonte de dor: fonts.googleapis.com

1 curtida

Isso não deveria ser git clones, mas sim instalação do registro de pacotes NPM. Com certeza pode haver um equivalente de bundle config mirror.https://rubygems.org https://gems.ruby-china.com/ para NPM/Yarn.

1 curtida

Ah, logo depois disso seguiu um subprocesso que clonou algo e falhou. Infelizmente, não consigo reproduzir o log de erro agora. Definitivamente, ele puxou algo do GitHub, pois a mensagem de erro era o mesmo erro de handshake TLS / timeout. Mas não é importante agora. Geralmente, o npm, por algum motivo, nunca tem timeouts aqui. A GFW é longa e cheia de mistérios!

2 curtidas

Talvez tenha sido

1 curtida

Você é o cara! Exatamente isso quebrou meu upgrade.

2 curtidas

Isso é bem estável, alguma chance de podermos enviá-lo para o registro NPM agora @pmusaraj?

3 curtidas

Ah sim, com certeza, vamos fazer isso.

2 curtidas

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.