|
| 1 | +--- |
| 2 | +title: Changes to Repository Sync |
| 3 | +layout: post |
| 4 | +--- |
| 5 | + |
| 6 | +Void is a complex system, and over time we make changes to reduce this |
| 7 | +complexity, or shift it to easier to manage components. Recently |
| 8 | +through the fantastic work of one of our maintainers `classabbyamp` |
| 9 | +our repository sync system has been dramatically improved. |
| 10 | + |
| 11 | +Previously our system was based on a series of host managed rsyncs |
| 12 | +running on either snooze or cron based timers. These syncs would push |
| 13 | +files to a central location to be signed and then distributed. This |
| 14 | +central location is sometimes referred to as the "shadow repo" since |
| 15 | +its not directly available to end users to synchronize from, and we |
| 16 | +don't usually allow anyone outside Void to have access to it. |
| 17 | + |
| 18 | +As you might have noticed from the [Fastly |
| 19 | +Overview](/news/2023/02/1-new-repo-fastly.html) the packages take a |
| 20 | +long path from builders to repos. What is not obvious from the graph |
| 21 | +shown is that the shadow repo previously lived on the musl builder, |
| 22 | +meaning that packages would get built there, copied to the glibc |
| 23 | +builder, then copied back to the musl builder and finally copied to a |
| 24 | +mirror. So many copies! To streamline this process, the shadow |
| 25 | +mirror is now just the glibc server, since that's where the packages |
| 26 | +have to wind up for architectural reasons anyway. This means we were |
| 27 | +able to cut out 2 rsyncs and reclaim a large amount of space on the |
| 28 | +musl builder, making the entire process less fragile and more |
| 29 | +streamlined. |
| 30 | + |
| 31 | +But just removing rsyncs isn't all that was done. To improve the time |
| 32 | +it takes for packages to make it to users, we've also switched the |
| 33 | +builders from using a time based sync to using lsyncd to take more |
| 34 | +active management of the synchronization process. In addition to |
| 35 | +moving to a more sustainable sync process, the entire process was |
| 36 | +moved up into our Nomad managed environment. Nomad allows us to more |
| 37 | +easily update services, monitor them for long term trends, and to make |
| 38 | +it clearer where services are deployed. |
| 39 | + |
| 40 | +In addition to fork-lifting the sync processes, we also forklifted |
| 41 | +void-updates, xlocate, xq-api (package search), and the generation of |
| 42 | +the docs-site into Nomad. These changes represent some of the very |
| 43 | +last services that were not part of our modernized container |
| 44 | +orchestrated infrastructure. |
| 45 | + |
| 46 | +Visually, this is what the difference looks like. Here's before: |
| 47 | + |
| 48 | + |
| 49 | + |
| 50 | +And here's what the sync looks like now, note that there aren't any |
| 51 | +cycles for syncs now: |
| 52 | + |
| 53 | + |
| 54 | + |
| 55 | +*If you run a downstream mirror we need your help!* If your mirror |
| 56 | +has existed for long enough, its possible that you were still |
| 57 | +synchronizing from alpha.de.repo.voidlinux.org, which has been a dead |
| 58 | +servername for several years now. Since moving around sync traffic is |
| 59 | +key to our ability to keep the lights on, we've provisioned a new |
| 60 | +dedicated DNS record for mirrors to talk to. The new |
| 61 | +`repo-sync.voidlinux.org` is the preferred origin point for all sync |
| 62 | +traffic and using it means that we can transparently move the sync |
| 63 | +origin during maintenance rather than causing an rsync hang on your |
| 64 | +sync job. Please check where you're mirroring from and update |
| 65 | +accordingly. |
0 commit comments