Aggiornamento manuale senza dolore dall’interno della Cina
passaggi
- crea un proxy SOCKS5 al di fuori della Cina
- configura e imposta la connessione proxy sul server CN
- crea un modello per una modifica più semplice
- aggiungi le impostazioni proxy git al modello
- includi il modello in
app.yml
- ricostruisci l’app
1 - SOCKS5 remoto
Per facilità d’uso (e per i loro prezzi convenienti) consiglio di impostare un server Digital Ocean, ad esempio a Singapore. Usa semplicemente un server Ubuntu standard, segui tutte le configurazioni di sicurezza di base (coppie di chiavi SSH, UFW, ecc.), quindi installa Shadowsocks:
sulla macchina remota
$ sudo apt install shadowsocks-libev
Configura le impostazioni del proxy:
$ cd /etc/shadowsocks-libev
# Mi piace mantenere i file originali
$ sudo cp config.json orig.config.json
$ sudo nano config.json
Presta molta attenzione a timeout e metodo:
{
"server":"123.123.123.123", # IP del server remoto
"server_port":8400, # a tua scelta
"local_port":1080,
"password":"Swordfish",
"timeout":600, # <= essenziale!
"method":"chacha20-ietf-poly1305"
}
Assicurati di controllare attentamente tutte le impostazioni nella configurazione systemd (/lib/systemd/system/shadowsocks-libev-local@.service). Abilita il servizio shadowsocks-libev-local@.service, riavvia e verifica che il servizio sia in esecuzione.
2 - imposta la connessione proxy sul server CN
sulla macchina Discourse
$ sudo apt install shadowsocks-libev
Se sei su Aliyun, cerca le impostazioni del firewall nella loro console particolare e controlla le impostazioni della porta corrispondente.
Non devi smanettare con le impostazioni systemd sulla macchina client, ma mantieni file di configurazione separati per Docker e per l’uso regolare, poiché potresti voler utilizzare il proxy SOCKS5 al di fuori del contesto di Docker; in tal caso, vorresti usare 127.0.0.1 invece degli indirizzi di rete accessibili da Docker.
$ cd /etc/shadowsocks-libev
$ sudo cp config.json local.json
$ sudo cp config.json docker.json
adatta la configurazione a qualcosa di simile a questo
$ sudo nano local.json
{
"server":["123.123.123.123"], # IP della macchina remota
"mode":"tcp_and_udp", # questa annotazione è diversa a causa delle diverse versioni di shadowsocks-libev nella mia configurazione
"server_port":8400,
"local_address":"127.0.0.1",
"local_port":1080,
"password":"Swordfish",
"timeout":600, # <= assicurati di questo
"method":"chacha20-ietf-poly1305"
}
Per comodità, aggiungiamo un alias al nostro .bashrc:
$ nano ~/.bashrc
# incolla
alias dockershadow='ss-local -c /etc/shadowsocks-libev/local.json'
adatta l’altra configurazione per far passare Docker attraverso la rete della macchina host
$ sudo nano docker.json
{
"server":["123.123.123.123"],
"mode":"tcp_and_udp",
"server_port":8400,
"local_address":"172.17.0.1",
"local_port":1080,
"password":"Swordfish",
"timeout":600,
"method":"chacha20-ietf-poly1305"
}
imposta l’alias per utilizzare la configurazione specifica di Docker:
alias dockershadow='ss-local -c /etc/shadowsocks-libev/docker.json'
3 & 4 - crea un modello per mantenere il tuo app.yml ordinato
Questo è assolutamente opzionale e dipende dai tuoi gusti; preferisco mantenere app.yml leggibile e breve, mantenendo invece i componenti altrove. Dai un nome a tuo piacimento, ho scelto web.git.template.yml.
$ nano templates/web.git.template.yml
# incolla:
hooks:
before_code:
- exec:
cmd:
- git config --global http.proxy socks5://172.17.0.1:1080
- git config --global https.proxy socks5://172.17.0.1:1080
- git config --global https.sslVerify = false
# opzionale
after_code:
- exec:
cmd:
- git config --global --unset http.proxy
- git config --global --unset https.proxy
- git config --global --unset https.sslVerify
L’ho testato con l’hook after_web, ma non ha funzionato.
5 - adatta app.yml
Chiama il modello nel tuo app.yml:
$ cd /<directory di discourse>
$ sudo nano containers/app.yml
templates:
- "templates/web.template.yml"
- "templates/web.china.template.yml"
- "templates/web.ratelimited.template.yml"
- "templates/web.socketed.template.yml"
- "templates/web.git.template.yml"
La tua sezione template probabilmente è diversa, assicurati solo di includere web.china e i template web.git-blabla (o come li hai chiamati).
Non esporre 1080:1080 nel tuo app.yml!
6 - ricostruzione
Prima di ricostruire, verifica che le impostazioni del proxy funzionino quando cloni con git.
$ git config --global http.proxy socks5://172.17.0.1:1080
$ git config --global https.proxy socks5://172.17.0.1:1080
$ git config --global https.sslVerify = false
Questo aggiunge ovviamente i flag proxy al file .gitconfig dell’utente nella directory home, quindi fai attenzione a rimuoverli dopo i test.
Seleziona un repository casuale grande su Github con un sacco di file e controlla la velocità di clonazione. Se la tua configurazione è corretta, dovresti essere in grado di clonare a circa 12-15 MB/s, a seconda della tua configurazione Aliyun. Se la velocità della connessione sale lentamente da 200 KB/s a circa 10 MB/s, allora i tuoi sforzi non sono stati coronati da successo.
infine ricostruisci:
$ cd /<directory di discourse>
# esegui il proxy usando l'alias che abbiamo impostato prima
$ dockershadow
$ ./launcher rebuild app
Il processo di ricostruzione fallirà spesso, quindi hai bisogno di pazienza (e possibilmente Baijiu). Più pochi plugin hai impostato nel tuo app.yml, più è probabile che la ricostruzione abbia successo.
7 - osservazioni
Considero ancora questo come un workaround, non una procedura pronta per la produzione, quindi forse qualcuno ha un’idea su come specchiare il repository GitHub in Cina, per rendere tutto questo meno doloroso. E come sappiamo tutti, i meccanismi opachi all’interno del GFW continuano a cambiare.
Ovviamente un proxy SOCKS5 è solo una delle molte opzioni, ma mi piace avere soluzioni multiuso a portata di mano.
Se qualcuno ha un’idea su come rendere questo workaround pronto per la produzione, apprezzo il tuo contributo. Discourse è un software fantastico, ma suppongo che una delle ragioni per cui non è ampiamente utilizzato in Cina siano i processi di installazione e manutenzione complicati. Tentare di aggiornare tramite GUI mi ha dato un tasso di fallimento del 100% nell’ultimo anno, indipendentemente dalle impostazioni di timeout configurate nel mio reverse proxy nGinx.
La traduzione in cinese seguirà
