If P2P streaming is enabled there will be traffic to other workers.įrom the web node on port 7777 (Garden) and 7788 (BaggageClaim). It makes sense to scale them up and down with demand.Įxternal traffic to arbitrary locations as a result of periodic resource checking and running buildsĮxternal traffic to the web node's configured external URL when downloading the inputs for a fly executeĮxternal traffic to the web node's TSA port ( 2222) for registering the worker Horizontally scalable: yes workers directly correlate to your capacity required by however many pipelines, resources, and in-flight builds you want to run.
Workers on guardians of traffic drivers#
Workers are inherently singletons, as they're being used as drivers running entirely different workloads. fresh VM/container and all processes were killed), it should be brought back with an empty disk. All state on disk must not outlive the worker itself it is all ephemeral. We suggest going for a larger disk size if it's not too much trouble. Resource fetching and pushing will also use arbitrary bandwidth.ĭisk usage: arbitrary data will be written as builds run, and resource caches will be kept and garbage collected on their own life cycle.
Expect spikes from periodic checking, though the intervals should spread out over enough time. Expect usage to increase with the number of containers on the worker and spike as builds run.īandwidth usage: again, almost entirely subject to pipeline workloads. Memory usage: also subject to pipeline workloads. More resources configured will result in more checking, and in-flight builds will use as much CPU as they want. 1.2.5.4.6 Configuring Peer-to-Peer Volume StreamingĬPU usage: almost entirely subject to pipeline workloads.1.2.5.4.5.4.3 A note on allowing host access and DNS proxy.1.2.5.4.5.4.1 Pointing to external DNS servers.
0 kommentar(er)
