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
Copy file name to clipboardExpand all lines: docs/tasks/local-github-cache.md
+47-27Lines changed: 47 additions & 27 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,34 +2,43 @@
2
2
3
3
The cache for GitHub Actions can speed up CI/CD pipelines. Hosted runners are placed close to the cache which means the latency is very low. Self-hosted runners can also make good use of this cache. Just like caching container images on the host in [a registry mirror](/tasks/registry-mirror/), you can also get a speed boost over the hosted cache by running your own cache directly on the host.
4
4
5
-
To improve cache speeds with Actuated runners you can run a self-hosted S3 server and switch out the official [actions/cache@v3](https://github.com/actions/cache) with [tespkg/actions-cache@v1](https://github.com/tespkg/actions-cache). The tespkg/actions-cache@v1 can target S3 instead of the proprietary GitHub cache.
5
+
To improve cache speeds with Actuated runners you can run a self-hosted S3 server and switch out the official [actions/cache@v3](https://github.com/actions/cache) with [tespkg/actions-cache@v1](https://github.com/tespkg/actions-cache). The tespkg/actions-cache@v1 can target S3 instead of GitHub's proprietary, hosted cache.
6
6
7
7
You can run the cache on every actuated server for the speed of communicating over a loopback network, or you can run it on a single dedicated server that's placed in the same region as the actuated servers, which will still be very quick.
8
8
9
-
> Note that if you have multiple actuated hosts consider running a single dedicated server for the cache. Subsequent jobs can be scheduled to different hosts so there is no guarantee the cache is populated when running a cache on every actuated server.
9
+
> Note: This guide sets up an S3 cache on each actuated server, so you may still get a cache miss from time to time. If you have more than one actuated server, you may wish to deploy a VM or a dedicated host in the same private network to host the S3 cache. Reach out if you'd like any help with this.
10
10
11
-
## Set up an S3 cache
11
+
## Install an S3-compatible server
12
12
13
-
There are a couple of options to run a self-hosted S3 server, most notably [Seaweedfs](https://github.com/seaweedfs/seaweedfs) and [Minio](https://min.io/).
13
+
There are a few popular options when it comes to self-hosting S3, including [Seaweedfs](https://github.com/seaweedfs/seaweedfs)(Apache-2.0) and [Minio](https://min.io/) (AGPLv3).
14
14
15
-
This guide will cover the setup of Seaweedfs but any S3 compatible service will work in a very similar way.
15
+
This guide will cover the setup of Seaweedfs but any S3 compatible service will work in a very similar way: install the service, set its storage location, and bind it only the IP address of the actuated microVM bridge.
16
16
17
17
### Install Seaweedfs
18
18
19
19
Seaweedfs is distributed as a static Go binary, so it can be installed with [arkade](https://github.com/alexellis/arkade), or from the [GitHub releases page](https://github.com/seaweedfs/seaweedfs/releases).
20
20
21
+
Port 443 will be used to expose the S3 server's API to the actuated microVMs, and the built-in TLS certificate will be used from `/var/lib/actuated/certs/server.crt` and `/var/lib/actuated/certs/server.key` to serve traffic over TLS, to ensure encryption.
22
+
23
+
Just like cloud-based S3, an access key and secret key will be required. You can provide those or generate them using the provided `openssl` commands. These then need to be added as secrets for the workflows via the repository settings or the organisation's settings.
24
+
25
+
If you don't already have arkade, you can install it via `curl -sLS https://get.arkade.dev | sudo sh`.
26
+
27
+
Next, download the binary and move it to `/usr/local/bin`:
28
+
21
29
```sh
22
30
arkade get seaweedfs
23
31
sudo mv ~/.arkade/bin/seaweedfs /usr/local/bin
24
32
```
25
33
26
34
Define a secret key and access key to be used from the CI jobs in the `/etc/seaweedfs/s3.conf` file.
27
35
28
-
Generate a secret key: `openssl rand -hex 16 > secret_key`
29
-
30
36
```bash
31
-
export ACCESS_KEY=""# Replace with your access key
32
-
export SECRET_KEY="$(cat ~/secret_key)"
37
+
openssl rand -hex 16 >~/seaweed_access_key
38
+
openssl rand -hex 16 >~/seaweed_secret_key
39
+
40
+
export ACCESS_KEY="$(cat ~/seaweed_access_key)"
41
+
export SECRET_KEY="$(cat ~/seaweed_secret_key)"
33
42
34
43
cat >> /tmp/s3.conf <<EOF
35
44
{
@@ -54,11 +63,11 @@ cat >> /tmp/s3.conf <<EOF
54
63
}
55
64
EOF
56
65
57
-
mkdir -p /etc/seaweedfs
66
+
sudo mkdir -p /etc/seaweedfs
58
67
sudo mv /tmp/s3.conf /etc/seaweedfs/s3.conf
59
68
```
60
69
61
-
Install and start Seaweedfs with a systemd unit file:
70
+
Create a systemd unit file to start Seaweedfs:
62
71
63
72
```bash
64
73
(
@@ -69,30 +78,37 @@ After=network.target
69
78
70
79
[Service]
71
80
User=root
72
-
ExecStart=/usr/local/bin/seaweedfs server -ip=192.168.128.1 -volume.max=0 -volume.fileSizeLimitMB=2048 -dir=/home/runner-cache -s3 -s3.config=/etc/seaweedfs/s3.conf
The `/var/run/s3/cache` folder will be used for storing files created by the S3 server.
97
+
86
98
We have set `-volume.max=0 -volume.fileSizeLimitMB=2048` to minimize the amount of space used and to allow large zip files of up to 2GB, but you can change this to suit your needs. See `seaweedfs server --help` for more options.
87
99
88
-
The `ip`only needs to be set to `192.168.128.1` if you are running the cache directly on the agent host. If you set up the cache to be accessible by multiple Actuated runner hosts use the appropriate interface IP address.
100
+
The `-ip`flag binds the S3 API server to the actuated bridge IP address. This IP address is accessible to microVMs, but hidden from the Internet. As mentioned above, TLS is enabled via a certificate and key provided by actuated, then the S3 server is exposed on port 443. You can change the port if you wish.
89
101
90
-
Check the status with:
102
+
Check the status of the service with:
91
103
92
104
```bash
93
105
sudo journalctl -u seaweedfs -f
94
106
```
95
107
108
+
If you see an error such as `listen tcp 192.168.128.1: bind: cannot assign requested address`. This will disappear when actuated is started.
109
+
110
+
It may also take a couple of minutes for the service to settle and be ready to accept connections.
111
+
96
112
## Use the self-hosted cache
97
113
98
114
To start using the local cache you will need to replace `actions/cache@v3` with `tespkg/actions-cache@v1` and add `tespkg/actions-cache` specific properties in addition to the `actions/cache` properties in your cache steps.
* `use-fallback` - option means that if Seaweedfs is not installed on the host, or is inaccessible, the action will fall back to using the GitHub cache.
142
-
* `bucket` - the name of the bucket to use in Seaweedfs
157
+
* `bucket` - the name of the bucket to use in Seaweedfs, this could be the same for every job, different per repository or per workflow.
143
158
* `region` - the bucket region - use `local` when running your own S3 cache locally.
144
-
* `accessKey` and `secretKey` - the credentials to use to access the bucket - we'd recommend using an organisation-level secret for this.
145
-
* `insecure` - use http instead of https. You may want to create a self-signed certificate for the S3 service and set `insecure: false` to ensure that the connection is encrypted. If you're running builds within private repositories, tampering is unlikely.
159
+
* `accessKey` and `secretKey` - the credentials to use to access the bucket, it's easier to define these secrets at the organisation level than on each repository
146
160
147
161
Checkout the list of `actions/cache` [examples](https://github.com/actions/cache/blob/main/examples.md) to configure caching for different languages and frameworks. Remember to replace `actions/cache@v3` with `tespkg/actions-cache@v1` and add the additional properties mentioned above.
One of the most contentious issues for self-hosted GitHub Actions runners is the speed a reliability of depending on the hosted caches. This is not a problem when using hosted runners, but when running outside of Azure's backbone, the latency is often a problem.
243
+
244
+
In a short period of time, we solved any potential latency or reliability by setting up our own S3 server using fast local storage. The default cache action was swapped for one with a compatible syntax, and we were able to cache the git checkout, *node_modules*, Go cache, and other common dependencies.
245
+
246
+
If you'd like a hand with this, feel free to reach out to the team.
247
+
228
248
## Further reading
229
249
230
250
* From our blog: [Fixing the cache latency for self-hosted GitHub Actions](https://actuated.com/blog/faster-self-hosted-cache)
231
-
* A primer on using the GitHub Actions cache: [Using caching in builds](/examples/github-actions-cache/)
251
+
* A primer on using the GitHub Actions cache: [Using caching in builds](/examples/github-actions-cache/)
0 commit comments