Bootstrap / ricostruire senza clonare tutto da capo?

Supporto
1

L’istanza di Discourse si trova dietro il GFW, quindi utilizziamo un proxy SOCKS5 per Git. Abbiamo installato alcuni plugin, quindi la ricompilazione o l’avvio dell’app clona ripetutamente tutti questi repository. Sfortunatamente, la clonazione va regolarmente in timeout, quindi l’intero processo ricomincia da capo, anche se la base di codice più recente è già stata clonata. Ho fatto più di 40 tentativi e ho perso circa cinque ore. L’ultima barriera è un sottoprocesso yarn all’interno del container, che di solito va in timeout, con conseguente fallimento dell’aggiornamento.

C’è un modo per strutturare app.yml in modo da non invocare almeno l’intero processo di clonazione dei plugin? La clonazione nel codice docker-manager e nella base di codice di Discourse ha una probabilità del 50% di successo, con la clonazione successiva a circa 1/3 di successo. Non so cosa causi il fallimento del sottoprocesso yarn, ma al momento sembra non essere possibile riportare in vita Discourse con i metodi dati.

Naturalmente sono stato abbastanza stupido da invocare launcher destroy app poiché volevo avviarlo manualmente, quindi non posso nemmeno eseguire launcher enter app per provare a eseguire manualmente il comando yarn. Qualcuno ha qualche idea? Grazie per il vostro contributo.

2

Non sono un esperto in queste materie, ma penso che la soluzione sia un proxy di caching per le cose che stai scaricando.

C’è un web.china.template.yml, lo stai usando?

3

Certo. Uso la sorgente Ruby cinese in tutte le applicazioni Rails, sono contento di averlo almeno. Quello che mi lascia perplesso: tutte le repository (incluse quelle dei plugin) sono già clonate, solo questo sottoprocesso yarn invoca il seguente:

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

Per qualche motivo il GFW non gradisce troppi processi git clone uno dopo l’altro e a un certo punto interrompe la connessione. Se solo potessi eseguire il launcher con un flag che dica qualcosa come “OK amico, il codice è qui, non c’è bisogno di clonare… solo bootstrap per ora”, :grinning:

Modifica: È incredibile. Proprio mentre scrivo, il mio 78° tentativo è finalmente andato a buon fine dopo 11 ore. Ho ripiegato su sshuttle, che ha richiesto anche circa 12 tentativi ma per qualche motivo il GFW ha avuto pietà della mia povera anima.

4

È quello che farebbe il tuo proxy di caching (o almeno così penserei). Dai un’occhiata a squid. Quindi vedresti che il launcher viene scaricato dal tuo mirror anziché dalla sorgente effettiva.

launcher non ha il codice perché lo sta clonando in un nuovo contenitore senza alcun codice, ecco perché scarica tutto il codice. Ogni. Singola. Volta.

5

Sì, abbiamo una certa esperienza con Squid fino a un certo punto. In ogni caso, questa è una soluzione generale, dato che non posso passare ore con un aggiornamento manuale di Discourse ogni volta. Per qualche mese l’uso di un normale proxy socks5 aveva funzionato, eppure è un gioco continuo di “acchiappa la talpa” con il GFW e l’accesso a GitHub è diventato un peso fin dall’inizio di ottobre. Non c’è da stupirsi che ci siano tonnellate di cloni su questo sito gitee.com.

Grazie per la spiegazione sul launcher, sono piuttosto stupido quando si tratta di Docker e avevo ipotizzato che clonasse le repository git localmente, per poi sovrascriverle in qualche container.

Sicuramente esaminerò le opzioni di Squid, poiché questo potrebbe aiutare anche con la mia seconda fonte di dolore: fonts.googleapis.com.

1 Mi Piace
6

Non dovrebbero essere git clone ma installazioni dal registro dei pacchetti NPM. Di sicuro ci può essere un equivalente di bundle config mirror.https://rubygems.org https://gems.ruby-china.com/ per NPM/Yarn.

1 Mi Piace
7

Oh, subito dopo è seguito un sottoprocesso che ha clonato qualcosa ed è fallito. Purtroppo non riesco a riprodurre ora il log dell’errore. Aveva sicuramente scaricato qualcosa da GitHub, dato che il messaggio di errore era lo stesso errore di handshake TLS / timeout. Comunque ora non è importante. Di solito npm, per qualche motivo, non ha mai timeout qui. Il GFW è lungo e pieno di misteri!

2 Mi Piace
8

Forse è stato

1 Mi Piace
9

Sei un grande! Esattamente questo ha bloccato il mio aggiornamento.

2 Mi Piace
10

È piuttosto stabile, c’è possibilità di inviarlo al registro NPM ora @pmusaraj?

3 Mi Piace
11

Oh sì, assolutamente, facciamolo.

2 Mi Piace
12

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