중국 내에서 고통 없는 수동 업그레이드
단계
- 중국 밖에서 SOCKS5 프록시 생성
- 중국 서버에서 프록시 연결 설정 및 구성
- 편집을 더 쉽게 하기 위한 템플릿 생성
- 템플릿에 git 프록시 설정 추가
app.yml에 템플릿 포함- 앱 재빌드
1 - 원격 SOCKS5
사용 편의성(그리고 친절한 가격 정책)을 위해 싱가포르와 같은 지역에 Digital Ocean 서버를 설정하는 것을 추천합니다. 표준 Ubuntu 서버를 사용하고, 기본적인 보안 요구 사항 구성(SSH 키 페어, UFW 등)을 거친 후 Shadowsocks를 설치하세요:
원격 머신에서
$ sudo apt install shadowsocks-libev
프록시 설정을 구성하세요:
$ cd /etc/shadowsocks-libev
# 원래 파일들을 유지하는 것을 좋아합니다
$ sudo cp config.json orig.config.json
$ sudo nano config.json
timeout과 method 설정에 주의하세요:
{
"server":"123.123.123.123", # 원격 서버 IP
"server_port":8400, # 사용자가 원하는 포트
"local_port":1080,
"password":"Swordfish",
"timeout":600, # <= 필수!
"method":"chacha20-ietf-poly1305"
}
systemd 구성(/lib/systemd/system/shadowsocks-libev-local@.service)의 모든 설정을 두 번 확인하세요. shadowsocks-libev-local@.service를 활성화하고, 재부팅한 후 실행 중인 서비스를 확인하세요.
2 - 중국 서버에서 프록시 연결 설정
Discourse 머신에서
$ sudo apt install shadowsocks-libev
Aliyun을 사용 중이라면, 그들의 특이한 콘솔에서 방화벽 설정을 찾아 해당 포트 설정을 확인하세요.
클라이언트 머신에서 systemd 설정을 가지고 헤매지 않아도 되지만, Docker와 일반 사용을 위한 별도의 구성 파일을 유지하세요. Docker 컨텍스트 밖에서 SOCKS5 프록시를 사용하려는 경우 Docker에서 접근 가능한 네트워크 주소 대신 127.0.0.1을 사용하게 되므로, 이렇게 하는 것이 좋습니다.
$ cd /etc/shadowsocks-libev
$ sudo cp config.json local.json
$ sudo cp config.json docker.json
다음과 유사한 내용으로 구성을 수정하세요
$ sudo nano local.json
{
"server":["123.123.123.123"], # 원격 머신의 IP
"mode":"tcp_and_udp", # 제 설정에서 shadowsocks-libev 버전이 다르기 때문에 이 주석이 다릅니다
"server_port":8400,
"local_address":"127.0.0.1",
"local_port":1080,
"password":"Swordfish",
"timeout":600, # <= 이 설정을 꼭 확인하세요
"method":"chacha20-ietf-poly1305"
}
편의상 .bashrc에 별칭을 추가해 봅시다:
$ nano ~/.bashrc
# 붙여넣기
alias dockershadow='ss-local -c /etc/shadowsocks-libev/local.json'
Docker가 호스트 머신의 네트워크를 통해 통신하도록 다른 구성을 수정하세요
$ 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"
}
Docker 전용 구성을 사용하기 위한 별칭을 설정하세요:
alias dockershadow='ss-local -c /etc/shadowsocks-libev/docker.json'
3 & 4 - app.yml을 깔끔하게 유지하기 위한 템플릿 생성
이것은 완전히 선택 사항이며 취향에 따라 다릅니다. 저는 app.yml을 가독성 있고 짧게 유지하는 것을 선호하며, 대신 다른 곳에서 구성 요소를 관리합니다. 취향에 따라 이름을 붙이세요. 저는 web.git.template.yml을 선택했습니다.
$ nano templates/web.git.template.yml
# 붙여넣기:
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
# 선택 사항
after_code:
- exec:
cmd:
- git config --global --unset http.proxy
- git config --global --unset https.proxy
- git config --global --unset https.sslVerify
after_web 훅으로 테스트해 보았지만, 효과가 없었습니다.
5 - app.yml 수정
app.yml에서 템플릿을 호출하세요:
$ cd /<discourse dir>
$ 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"
템플릿 섹션은 아마도 다르게 보일 것입니다. web.china와 web.git-blabla(또는 당신이 지정한 이름) 템플릿을 포함하는지 확인하세요.
app.yml에서 1080:1080을 노출하지 마세요!
6 - 재빌드
재빌드하기 전에 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
물론 이것은 홈 디렉토리의 사용자 .gitconfig에 프록시 플래그를 추가하므로, 테스트 후 이를 제거하는 것에 주의하세요.
Github에서 파일이 많은 무작위 대형 저장소를 선택하여 클론 속도를 확인하세요. 구성이 올바르면 Aliyun 설정에 따라 ~12-15 mb/s 속도로 클론할 수 있어야 합니다. 연결 속도가 200 kb/s에서 약 10 mb/s로 느리게 올라간다면, 당신의 시도는 성공적이지 못한 것입니다.
마지막으로 재빌드하세요:
$ cd /<discourse directory>
# 이전에 설정한 별칭을 사용하여 프록시 실행
$ dockershadow
$ ./launcher rebuild app
재빌드 과정은 자주 실패하므로 인내심이 필요합니다(그리고 아마도 바이주). app.yml에 설정한 플러그인이 적을수록 재빌드가 성공할 가능성이 높습니다.
7 - 비고
저는 이것을 여전히 우회책으로 보고, 프로덕션 환경에 적합한 절차로 보지 않습니다. 따라서 GitHub 저장소를 중국에 미러링하여 이 과정을 덜 고통스럽게 만드는 방법에 대한 아이디어가 있는 사람이 있을까요? 그리고 우리 모두 알다시피, GFW(중국 장거리 방화벽) 내부의 불투명한 메커니즘은 계속 변하고 있습니다.
물론 SOCKS5 프록시는 많은 옵션 중 하나일 뿐이지만, 저는 다목적 솔루션을 손에 갖추어 두는 것을 좋아합니다.
누군가 이 우회책을 프로덕션 환경에 적합하게 만드는 방법에 대한 아이디어가 있다면, 여러분의 의견을 환영합니다. Discourse는 훌륭한 소프트웨어이지만, 중국에서 널리 사용되지 않는 이유 중 하나는 번거로운 설치 및 유지보수 과정이라고 생각합니다. 지난 1년 동안 GUI를 통해 업그레이드를 시도해 보았지만, nGinx 리버스 프록시에 어떤 타임아웃 설정을 적용했든 100% 실패율을 기록했습니다.
중국어 번역은 뒤따를 것입니다
