Mise à jour manuelle sans douleur depuis la Chine
étapes
- créer un proxy SOCKS5 hors de Chine
- configurer et établir la connexion proxy sur le serveur CN
- créer un modèle pour faciliter l’édition
- ajouter les paramètres proxy git au modèle
- inclure le modèle dans
app.yml
- reconstruire l’application
1 - SOCKS5 distant
Pour plus de commodité (et leur tarification avantageuse), je recommande de configurer un serveur Digital Ocean, par exemple à Singapour. Utilisez simplement un serveur Ubuntu standard, effectuez toutes les configurations de sécurité de base requises (paires de clés SSH, UFW, etc.), puis installez Shadowsocks :
sur la machine distante
$ sudo apt install shadowsocks-libev
Configurez les paramètres du proxy :
$ cd /etc/shadowsocks-libev
# J'aime conserver les fichiers d'origine
$ sudo cp config.json orig.config.json
$ sudo nano config.json
Portez une attention particulière au délai d’attente (timeout) et à la méthode :
{
"server":"123.123.123.123", # IP du serveur distant
"server_port":8400, # à vous de choisir
"local_port":1080,
"password":"Swordfish",
"timeout":600, # <= essentiel !
"method":"chacha20-ietf-poly1305"
}
Assurez-vous de vérifier attentivement tous les paramètres dans la configuration systemd (/lib/systemd/system/shadowsocks-libev-local@.service). Activez le service shadowsocks-libev-local@.service, redémarrez, puis vérifiez que le service est en cours d’exécution.
2 - configurer la connexion proxy sur le serveur CN
sur la machine Discourse
$ sudo apt install shadowsocks-libev
Si vous êtes chez Aliyun, recherchez les paramètres du pare-feu dans leur console étrange et vérifiez les paramètres de port respectifs.
Vous n’avez pas besoin de vous embrouiller avec les paramètres systemd sur la machine cliente, mais gardez des fichiers de configuration séparés pour Docker et l’utilisation normale, car vous pourriez vouloir utiliser le proxy SOCKS5 en dehors du contexte de Docker. Dans ce cas, vous voudrez utiliser 127.0.0.1 plutôt que les adresses réseau accessibles par Docker.
$ cd /etc/shadowsocks-libev
$ sudo cp config.json local.json
$ sudo cp config.json docker.json
Adaptez la configuration à quelque chose de similaire à ceci :
$ sudo nano local.json
{
"server":["123.123.123.123"], # l'IP de la machine distante
"mode":"tcp_and_udp", # cette annotation diffère en raison de versions différentes de shadowsocks-libev dans ma configuration
"server_port":8400,
"local_address":"127.0.0.1",
"local_port":1080,
"password":"Swordfish",
"timeout":600, # <= assurez-vous de cela
"method":"chacha20-ietf-poly1305"
}
Pour plus de commodité, ajoutons un alias à notre .bashrc :
$ nano ~/.bashrc
# coller
alias dockershadow='ss-local -c /etc/shadowsocks-libev/local.json'
Adaptez l’autre configuration pour permettre à Docker d’utiliser le réseau de la machine hôte :
$ 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"
}
Définissez l’alias pour utiliser la configuration spécifique à Docker :
alias dockershadow='ss-local -c /etc/shadowsocks-libev/docker.json'
3 & 4 - créer un modèle pour garder votre app.yml propre
Ceci est tout à fait optionnel et dépend de vos préférences ; je préfère garder le app.yml lisible et court, et maintenir les composants ailleurs. Donnez-lui un nom selon vos goûts, j’ai choisi web.git.template.yml.
$ nano templates/web.git.template.yml
# coller :
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
# optionnel
after_code:
- exec:
cmd:
- git config --global --unset http.proxy
- git config --global --unset https.proxy
- git config --global --unset https.sslVerify
Je l’ai testé avec le hook after_web, mais cela n’a pas fonctionné.
5 - adapter le app.yml
Appelez le modèle dans votre app.yml :
$ cd /<répertoire 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"
Votre section de modèles ressemble probablement différemment, assurez-vous simplement d’inclure web.china et les modèles web.git-blabla (ou ce que vous avez nommé). Ne exposez pas 1080:1080 dans votre app.yml !
6 - reconstruction
Avant de reconstruire, vérifiez que vos paramètres proxy fonctionnent lors du clonage avec 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
Cela ajoute bien sûr les drapeaux proxy à votre .gitconfig utilisateur dans le répertoire home, alors faites attention à les supprimer après les tests. Sélectionnez un dépôt aléatoire volumineux sur Github avec une multitude de fichiers et vérifiez votre vitesse de clonage. Si votre configuration est correcte, vous devriez pouvoir cloner à environ 12-15 Mo/s, selon votre configuration Aliyun. Si votre vitesse de connexion monte lentement de 200 Ko/s à environ 10 Mo/s, alors vos efforts n’ont pas abouti.
Enfin, reconstruisez :
$ cd /<répertoire discourse>
# lancez le proxy en utilisant l'alias que nous avons défini précédemment
$ dockershadow
$ ./launcher rebuild app
Le processus de reconstruction échouera souvent, alors vous avez besoin de patience (et éventuellement de Baijiu). Plus vous avez peu de plugins définis dans votre app.yml, plus il est probable que votre reconstruction réussisse.
7 - remarques
Je considère toujours cela comme une solution de contournement, pas une procédure prête pour la production, donc peut-être que quelqu’un a une idée pour miroirer le dépôt GitHub en Chine, afin de rendre cela moins douloureux. Et comme nous le savons tous, les mécanismes opaques à l’intérieur du GFW continuent de changer.
Bien sûr, un proxy SOCKS5 n’est qu’une option parmi d’autres, mais j’aime avoir des solutions polyvalentes à portée de main.
Si quelqu’un a une idée pour rendre cette solution de contournement prête pour la production, j’apprécie vos commentaires. Discourse est un logiciel fantastique, mais je suppose que l’une des raisons pour lesquelles il n’est pas largement utilisé en Chine est la complexité des processus d’installation et de maintenance. Tenter de mettre à jour via l’interface graphique m’a donné un taux d’échec de 100 % au cours de l’année dernière, peu importe les paramètres de délai d’attente que j’avais configurés dans mon proxy inverse nGinx.
Traduction chinoise à suivre
