Actualización manual sin dolor desde China
pasos
- crear un proxy SOCKS5 fuera de China
- configurar y establecer la conexión del proxy en el servidor de CN
- crear una plantilla para facilitar la edición
- agregar la configuración del proxy de git a la plantilla
- incluir la plantilla en
app.yml
- reconstruir la aplicación
1 - SOCKS5 remoto
Para facilitar su uso (y por sus precios amigables), recomiendo configurar un servidor de Digital Ocean, por ejemplo, en Singapur. Simplemente utilice un servidor Ubuntu estándar, complete todas las configuraciones básicas de seguridad (pares de claves SSH, UFW, etc.) y luego instale Shadowsocks:
en la máquina remota
$ sudo apt install shadowsocks-libev
Configure los ajustes del proxy:
$ cd /etc/shadowsocks-libev
# Me gusta mantener los archivos originales
$ sudo cp config.json orig.config.json
$ sudo nano config.json
Preste mucha atención al tiempo de espera (timeout) y al método:
{
"server":"123.123.123.123", # IP del servidor remoto
"server_port":8400, # a su elección
"local_port":1080,
"password":"Swordfish",
"timeout":600, # <= ¡esencial!
"method":"chacha20-ietf-poly1305"
}
Asegúrese de verificar dos veces toda la configuración en la configuración de systemd (/lib/systemd/system/shadowsocks-libev-local@.service). Habilite el servicio shadowsocks-libev-local@.service, reinicie y verifique que el servicio se esté ejecutando.
2 - configurar la conexión del proxy en el servidor de CN
en la máquina de Discourse
$ sudo apt install shadowsocks-libev
Si está en Aliyun, busque la configuración del firewall en su extraña consola y verifique la configuración del puerto correspondiente.
No necesita perder el tiempo con la configuración de systemd en la máquina cliente, pero mantenga archivos de configuración separados para Docker y uso regular, ya que es posible que desee usar el proxy SOCKS5 fuera del contexto de Docker; en ese caso, querrá usar 127.0.0.1 en lugar de las direcciones de red accesibles por Docker.
$ cd /etc/shadowsocks-libev
$ sudo cp config.json local.json
$ sudo cp config.json docker.json
Adapte la configuración a algo similar a esto:
$ sudo nano local.json
{
"server":["123.123.123.123"], # la IP de la máquina remota
"mode":"tcp_and_udp", # esta anotación es diferente debido a las diferentes versiones de shadowsocks-libev en mi configuración
"server_port":8400,
"local_address":"127.0.0.1",
"local_port":1080,
"password":"Swordfish",
"timeout":600, # <= asegúrese de esto
"method":"chacha20-ietf-poly1305"
}
Por comodidad, agreguemos un alias a nuestro .bashrc:
$ nano ~/.bashrc
# pegar
alias dockershadow='ss-local -c /etc/shadowsocks-libev/local.json'
Adapte la otra configuración para permitir que Docker pase por la red de la máquina anfitriona:
$ 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"
}
Establezca el alias para usar la configuración específica de Docker:
alias dockershadow='ss-local -c /etc/shadowsocks-libev/docker.json'
3 y 4 - crear una plantilla para mantener su app.yml ordenado
Esto es absolutamente opcional y depende de sus preferencias; yo prefiero mantener app.yml legible y breve, y en su lugar mantener los componentes en otro lugar. Déle cualquier nombre según su gusto; yo elegí web.git.template.yml.
$ nano templates/web.git.template.yml
# pegar:
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
# opcional
after_code:
- exec:
cmd:
- git config --global --unset http.proxy
- git config --global --unset https.proxy
- git config --global --unset https.sslVerify
Lo he probado con el hook after_web, pero no funcionó.
5 - adaptar el app.yml
Llame a la plantilla en su app.yml:
$ cd /<directorio de 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"
Su sección de plantillas probablemente se ve diferente, solo asegúrese de incluir web.china y las plantillas web.git-blabla (o como las haya nombrado). No exponga 1080:1080 en su app.yml!
6 - reconstrucción
Antes de reconstruir, verifique que su configuración de proxy funcione al clonar 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
Esto, por supuesto, agrega las banderas de proxy al archivo .gitconfig del usuario en el directorio home, así que tenga cuidado de eliminar esto después de las pruebas. Seleccione un repositorio grande y aleatorio en GitHub con muchos archivos y verifique su velocidad de clonación. Si su configuración es correcta, debería poder clonar a ~12-15 MB/s, dependiendo de su configuración de Aliyun. Si su velocidad de conexión sube lentamente desde 200 KB/s hasta aproximadamente 10 MB/s, entonces sus esfuerzos no fueron exitosos.
Finalmente, reconstruya:
$ cd /<directorio de discourse>
# ejecute el proxy usando el alias que hemos configurado antes
$ dockershadow
$ ./launcher rebuild app
El proceso de reconstrucción fallará a menudo, por lo que necesita paciencia (y posiblemente Baijiu). Cuantos menos plugins tenga configurados en su app.yml, más probable es que su reconstrucción tenga éxito.
7 - observaciones
Aún considero esto como una solución temporal, no un procedimiento listo para producción, así que quizás alguien tenga una idea sobre cómo reflejar el repositorio de GitHub en China para hacer esto menos doloroso. Y como todos sabemos, los mecanismos opacos dentro del GFW siguen cambiando.
Por supuesto, un proxy SOCKS5 es solo una de muchas opciones, pero me gusta tener soluciones de uso múltiple a mano.
Si alguien tiene una idea sobre cómo hacer que esta solución temporal esté lista para producción, aprecio sus comentarios. Discourse es un software fantástico, pero asumo que una de las razones por las que no se usa ampliamente en China son los engorrosos procesos de instalación y mantenimiento. Intentar actualizar mediante GUI me dio una tasa de falla del 100% durante el último año, sin importar qué configuración de tiempo de espera hubiera configurado en mi proxy inverso de Nginx.
La traducción al chino seguirá pronto
