You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in GitHub official document, there's an approach to [inject environment variables into runners process](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-a-proxy-server-with-self-hosted-runners#using-a-env-file-to-set-the-proxy-configuration) via the `.env` file before configuring or starting the self-hosted runners. This can be achieved via the `--dotenv` option, for example:
Then the following lines will be added to `.env` file located in self-hosted runner's directory before its configuring and starting:
181
182
182
183
```plain
183
184
TZ=Asia/Shanghai
184
185
PATH=$PATH:/mybin
185
-
```
186
-
187
-
## Case Study - Deploy multi runners on single host which can not access GitHub directly
188
-
189
-
A multi-national corporation adopted GitHub as its centralized engineering efficiency platform. But in a country branch, according to some network blockade/bandwidth/QoS reasons, neither GitHub-hosted runners can access endpoints in this country stably, nor virtual machines in this country can access GitHub liberally.
190
-
191
-
In such a bad situation, we still need to setup reliable self-hosted runners in this country. What should we do? 🤣
192
-
193
-
A cost-conscious solution can be described as following architecture:
-------------------------- | ----> Other endpoints
199
-
Branch office network Remote Proxy
200
-
```
201
-
202
-
A host *VM-Runners* is required for self-hosted runners, which is placed in this country and:
203
-
204
-
- Can access endpoints of this country branch
205
-
- Can NOT access *GitHub* directly or stably
206
-
207
-
A tiny specification host *VM-Proxy* is required as ***Remote Proxy***, which is deployed in a place that:
208
-
209
-
- Can access *GitHub* directly and stably
210
-
- Can be accessed by *VM-Runners* directly and stably
211
-
212
-
Meanwhile, **outbound traffics from *VM-Runners* MUST be routed by predefined rules**:
213
-
214
-
- [Requests to *GitHub* endpoints](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#communication-requirements) and non-local endpoints should be forward to the *Remote Proxy* on *VM-Proxy*
215
-
- Requests to local endpoints should be handled directly
216
-
217
-
Let's implement this solution. 🧐
218
-
219
-
On *VM-Proxy*, we can setup a *Remote Proxy* that's not easy to be blocked by the firewall, such as [*SS*](https://github.com/shadowsocks), [*TJ*](https://github.com/trojan-gfw), [*XR*](https://github.com/XTLS), etc. These particular proxies have their own deployment and configuration methods. Please read their documents for more information. It's advised to set the outbound IP of *VM-Runners* as the only whitelist of the *Remote Proxy* port on *VM-Proxy* to avoid active detection from the firewall.
220
-
221
-
Before setup runners on *VM-Runners*, we need a [***Local Proxy***](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/using-a-proxy-server-with-self-hosted-runners) on *VM-Runners*.
222
-
223
-
Usually firstly we need to setup the client of selected *Remote Proxy* which exposes a SOCKS5 proxy on *VM-Runners* (this local SOCKS5 localhost port will unconditionally forward all traffics to *VM-Proxy*), and then setup a [*privoxy*](https://www.privoxy.org/) on top of previous local SOCKS5 for [domain based forwarding](https://www.privoxy.org/user-manual/config.html#SOCKS). These configurations are complex and prone to errors. Via [*Clash*](https://github.com/Dreamacro/clash), we can combine both client of *Remote Proxy* and domain based forwarding into only one *Local Proxy*. The example configuration file and startup script of *Clash* and given in this repo's [clash.example/](clash.example/) directory.
224
-
225
-
Assume the *Local Proxy* was launched as `socks5h://localhost:7890`, we can test it via following commands on *VM-Runners*:
226
-
227
-
```bash
228
-
# Without *Local Proxy*, it will print outbound public IP of *VM-Runners*
229
-
curl -s -4 icanhazip.com
230
-
231
-
# With *Local Proxy*, it will print outbound public IP of *VM-Proxy* !!!
As self-hosted runners' tar package downloading and registration-token fetching also requires communication with GitHub, we also configure *Local Proxy* for this application:
245
-
246
-
```bash
247
-
cat > .env <<- __
248
-
MR_GITHUB_PAT='<paste-for-GitHub-PAT-here>'
249
-
all_proxy='socks5h://localhost:7890'
250
-
__
251
-
```
252
-
253
-
To download the self-hosted runners' tar package from *GitHub*:
254
-
255
-
```bash
256
-
./mr.bash download
257
-
```
258
-
259
-
To validate your *PAT* has sufficient permissions for self-hosted runners registration on your GitHub organization `https://github.com/<ORG-NAME>`:
260
-
261
-
```bash
262
-
./mr.bash pat2token --org <ORG-NAME>
263
-
```
264
-
265
-
To setup two self-hosted runners on *VM-Runners* for your GitHub organization:
To check the *Local Proxy* works well in your runners' process, you can add a simple workflow `.github/workflows/test-local-proxy.yml` in your repository. If `icanhazip.com` was configured as a following-to-remote domain, the workflow run will print outbound public IP of *VM-Proxy*, even though this workflow actually runs on *VM-Proxy*.
279
-
280
-
```yaml
281
-
---
282
-
name: Test Local Proxy works in my self-hosted runners
0 commit comments