[Jenkins-infra] Request for feedback: IEP-002 - Azure Virtual Networks for Cluster Segregation
bwalding at cloudbees.com
Tue Nov 29 10:53:46 UTC 2016
On 19 November 2016 at 04:34, R. Tyler Croy <tyler at monkeypox.org> wrote:
> On Fri, 18 Nov 2016, Ben Walding wrote:
> > *Networks*
> > I would also consider separating your static infrastructure from your
> > dynamic CI infrastructure - i.e. Confluence / JIRA etc would be static
> > infrastructure, whereas the build farms would be dynamic CI
> I hadn't considered this, could you expand more on the reasoning behind
> Are there limits on public IPs or something from within VPCs that make
> this a
> prudent choice on AWS? I'm not sure what the benefit of peering two Virtual
> Networks would be between static and dynamic workloads in "Public
> To give you a sense of size, our dynamic Jenkins agents at their max
> utilization are only about 10-15 VMs.
This was of more interest if you have multiple Azure accounts - in AWS an
errant process can rapidly consume your AWS API quota - so separating into
different accounts limits that.
You probably won't have the kind of dynamic workload we have for CI - so it
wouldn't be as much of an issue.
The separation also helps when you have to give your CI infrastructure some
Azure API keys to stop/start build servers (for example).
By having separate accounts you don't have to worry about the CI infra
being able to stop/start unrelated instances.
So assuming Resource Groups give you that level of granularity, you should
be able to use the Resource Group as the boundary for permissions.
> Does this approach address your concerns about separating Virtual Networks
> into separate Accounts/Subscriptions (since we can't actually accomplish
> Yes, I think it is sufficient given your use-cases - just wanted to ensure
that someone getting into the CI farm (since that is likely the lowest
hanging fruit) doesn't give them access somewhere else.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Jenkins-infra