Run VM Build Executors in Virtual Cloud Network

A Virtual Cloud Network (VCN) is a software-defined network that you set up in the OCI data centers of a region. A subnet is a subdivision of a VCN. A VM build executor always runs in a VCN's public subnet.

You can choose to run a VM executor in the VB Studio compartment's VCN or in another compartment's VCN. Run the VM executor in the VB Studio compartment's VCN if you don't have a VCN or want to use the default option without any additional configuration. Run the VM executor in another compartment's VCN if you want the VM executor to access Oracle Cloud services running in that compartment's VCN.

Note:

You can't run VM executors in a VCN if VB Studio is connected to the built-in free account. To use another compartment's VCN, configure VB Studio to connect to an OCI account.

Use VB Studio's Default VCN

VB Studio compartment's VCN, also called the default VCN, is automatically created for you when the first VM build executor that uses it starts.

VB Studio's default VCN is called vbs-executor-vcn and resides in the VB Studio's compartment. When a VM executor that uses the default VCN starts, VB Studio checks the OCI compartment for the default VCN. If it doesn't exist, VB Studio creates a VCN called vbs-executor-vcn with CIDR block 10.0.0.0/16 and public subnets in all availability domains. If the VCN exists, VB Studio uses it to run your VM executors.

When VB Studio creates the default VCN, it also creates these components and adds them to the VCN:

An Internet Gateway
A Route Table that uses the Internet Gateway as the routing rule
Security Rule Ingress rules that allow TCP traffic on:
- Destination port 22 (SSH), 9003 (Executor agent debug), 9005 (VM agent debug), 9082 (Executor agent), and 9085 (VM agent), and 8095 (Docker Agent), and 9001-9010 from source 0.0.0.0/0 and any source port.
- Destination port 443 from sources in the 10.0.0.0/16 IP range.
A Security Rule that allows Egress to any destination from any protocol.
Three public subnets, one for each availability domain. Their CIDR is set to 10.0.0.0/24, 10.0.1.0/24, and 10.0.2.0/24.

Here's an example of the default VCN:

Description of vbs-default-vcn.bmp follows

Description of the illustration vbs-default-vcn.bmp

As soon as the default VCN is available, you have full control over it and can modify it. You can add private subnets for your private services, add more public subnets or delete the existing subnets, modify security lists, and add or remove other components.

Note:

When a VM executor runs on the default VCN, it runs on any of its available public subnets. You can't specify which subnet it should run on.
If you plan to remove some public subnets of the default VCN, make sure that at least one public subnet is available in the VCN. If there are no public subnets, VM executors in the default VCN won't run and your builds will fail.
The default VCN is created once and continues to stay until it is deleted manually.
If your organization's members configure jobs that access Oracle Cloud services in the private or public subnets of the VCN, ask them to configure their jobs to access the services using private IPs or Fully Qualified Domain Name (FQDN).

Run VM Build Executors in Another Compartment's VCN and Subnets

To allow a VM build executor access your Oracle Cloud services in a compartment's VCN, you should configure the VM executors to run in the same VCN. This allows the VM executor to access Oracle Cloud services easily without any complex networking configuration.

Before you configure the VCN, make a note of these:

A VM executor always runs in a public subnet.
In the VCN, you must create a public subnet or configure an existing public subnet to allow inbound access from and outbound access to VB Studio. See Create and Configure a Public Subnet in a VCN.
Make sure that the public subnet is regional.
Instead of modifying an existing security list's security rules, create a new security list for the public subnet.
For the public subnet, create a security list and add ingress rules from source CIDR 0.0.0.0/0 for VB Studio ports 22 (SSH), 9082 (Executor Agent), and 9085 (VM Agent). This is required to allow VB Studio access the VM executors in the VCN.
For the subnet's compartment, assign the use virtual-network-family OCI policy to the user whose OCID you specified when you set up the OCI connection in VB Studio. This is required for networking permissions and builds to run in the VCN's subnet. This statement assigns the policy to the user's group:
allow group <group-name> to use virtual-network-family in compartment <subnet-compartment-name>

Here's an example of the use virtual-network-family policy added to the policies you created in Set Up the OCI Account.

Description of the illustration oci_vbstudio_vcn_policy.png
Make sure that the VCN has a route table with a rule that allows Internet access.
To allow the VM executor to access the VCN's private subnet's services and resources, configure the private subnet's security rules to allow incoming traffic from the public subnet used by the VM executor.
While adding a VM executor, you can specify multiple public subnets. If VB Studio can't create the VM executor on the first specified public subnet, it tries to create it in the second subnet, and so on.
After configuring a VM executor to run in another compartment's VCN, ask your organization's members to configure their build jobs to use the private IP addresses or the Fully Qualified Domain Name (FQDN) of services that are running in the VCN.
Tell them not to use public IP addresses, because when VM executors are in the same VCN as the service, public IP addresses will route the traffic outside the VCN, causing builds to fail.

This table describes what you need to do if you have a VCN.

If ...	Then :
You have a VCN without a public subnet	Create and Configure a Public Subnet in a VCN. You'll also configure the subnet's security list to allow inbound access from and outbound access to VB Studio. To allow a VM executor access a service running in the private subnet, configure the private subnet's security list. See Allow VM Build Executors to Access a Private Subnet's Resources. Add and Manage VM Build Executors in the VCN.
You have a VCN with a public subnet	In your VCN, create a security list with ingress rules and egress rules as described in steps 6-11 in Create and Configure a Public Subnet in a VCN. Open your public subnet's details page and add the security list. See step 14 in Create and Configure a Public Subnet in a VCN. To allow a VM executor access to services running in the private subnet, configure the private subnet's security list. See Allow VM Build Executors to Access a Private Subnet's Resources. Add and Manage VM Build Executors in the VCN.
You don't have a VCN and want to create one	Use the VCN wizard to create a VCN with a public subnet and an internet gateway. See Virtual Networking Quickstart. Create and Configure a Public Subnet in a VCN. You'll also configure the subnet's security list to allow inbound access from and outbound access to VB Studio. To allow a VM executor access to services running in the private subnet, configure the private subnet's security list. See Allow VM Build Executors to Access a Private Subnet's Resources. Add and Manage VM Build Executors in the VCN.

Create and Configure a Public Subnet in a VCN

Before you can run VMs in another compartment's VCN, you must first create a public subnet in your VCN with security rules that allow inbound access from and outbound access to VB Studio.

Sign in to Oracle Cloud Console.
In the upper-left corner, click Navigation Menu .
Select Networking and select Virtual Cloud Networks.
Under List Scope, select the compartment.
From the VCNs list, click the VCN's name.
Under Resources, click Security Lists, and then click Create Security List.
In Name, enter a name for the security list.
In Create in Compartment, ensure that the correct compartment is selected.
In Allow Rules for Ingress, click + Another Ingress Rule and follow these steps:
1. In Source Type, select CIDR.
2. In Source CIDR, enter 0.0.0.0/0.
3. In Destination Port Range, enter 9082.
4. (Optional) In Description, add a description.
  Here's an example:
  
  Description of the illustration oci_ingress_rule.png
5. Click + Another Ingress Rule and repeat steps 9a through 9d to add ports 9085 and 22.
6. (Only if you are using Docker executors) Click + Another Ingress Rule and repeat steps 9a through 9d to add ports 8095 and 9001-9010 to 0.0.0.0/0 and add port 443 to your VCN CIDR (for example 10.0.0.0/16).
In Allow Rules for Egress, click + Another Egress Rule and follow these steps:
1. In Source Type, select CIDR.
2. In Source CIDR, enter 0.0.0.0/0.
3. In IP Protocol, select All Protocols.
4. (Optional) In Description, add a description.
Click Create Security List.
After creating the security list, click its name to verify the ingress and egress rules you added.
Here's an example of ingress rules:

Description of the illustration oci_ingress_rules.png

Here's an example of the egress rule:

Description of the illustration oci_egress_rules.png
Return to the VCN's details page.
Under Resources, select Subnets and follow these steps to create a public subnet:
If you want to edit an existing public subnet, jump to the next step.
1. Click Create Subnet.
2. In Name, enter the subnet's name.
3. In Create in Compartment, select the correct compartment.
4. In Subnet Type, make sure that Regional is selected.
5. In CIDR Block, enter the subnet's CIDR block.
  Don't set it to 172.17.0.0/16 as it's the default subnet allocated to Docker.
6. In Route Table, select the VCN's route table.
7. In Subnet Access, make sure that Public Subnet is selected.
8. In DHCP Options, select the VCN's DHCP options.
9. In Security List, select the security list you created in step 6.
10. Fill in the other fields as required.
  
  Here's an example:
  
  Description of the illustration oci_subnet.png
11. Click Create Subnet.
If you want to edit an existing subnet, follow these steps:
1. Under Resources, select Subnets and click the public subnet's name.
2. Click Add Security List.
3. In the Add Security List dialog box, in Security List, select the security list you created in step 6.
4. Click Add Security List.

That's it. After creating or editing the public subnet, your VM executors can now run in the VCN.

Allow VM Build Executors to Access a Private Subnet's Resources

After adding a public subnet in a VCN, to allow VM build executors access the resources and services (such as Java Cloud Service or a VM-based Database) running in the VCN's private subnet, configure the private subnet's security rules to allow incoming traffic from the public subnet used by VM executors.

For example, to allow VM executors access Java Cloud Service running in a private subnet, configure the subnet's security list to add the VM executors CIDR ranges to the Ingress rule associated with the JCS Admin port.

Sign in to Oracle Cloud Console.
In the upper-left corner, click Navigation Menu .
Select Networking and select Virtual Cloud Networks.
On the Virtual Cloud Networks page, click the VCN.
Under Resources, click Security Lists, and then click the private subnet's security list.
Click Add Ingress Rules.
If you want to modify an existing rule, click the Actions icon (three dots), and then select Edit.
In Source Type, select CIDR.
In Source CIDR, enter the VM executor's public subnet's CIDR range.
In Destination Port Range, enter the service's port number.
(Optional) In Description, add a description.
Here's an example of Java Cloud Service port 7002 with a source CIDR of 10.0.4.0/24:

Description of the illustration oci_ingress_rule_jcs.png
Click Add Ingress Rules.
If required, repeat steps 6-11 for each service's port.

VB Studio Public IP Addresses in OCI Data Centers

If you're running VM executors in another compartment's subnet and don't want to use the CIDR 0.0.0.0/0 range in your ingress and egress rules, specify VB Studio's public IP address in the subnet's ingress and egress rules.

For a list of public IP addresses, see VB Studio Gen 2 Public IP Addresses.

You can also use the following list of IP addresses to restrict outbound access from your build VM executors:

Server type	IP address
Storage	129.150.1.1/32 129.150.1.2/32 134.70.80.3/32 134.70.84.3/32 130.162.1.2/32 130.162.1.1/32
Public yum	23.212.73.81/32
Shared services yum	130.35.147.212/32
Yum regional mirrors	192.29.194.161/32 129.149.81.204/32 129.149.51.216/32 192.29.166.112/32 155.248.131.128/32 129.149.16.241/32 129.148.209.47/32 138.1.66.178/32 192.29.138.86/32 129.148.132.80/32 147.154.1.235/32 192.29.25.15/32 192.29.113.113/32 129.149.65.253/32 192.29.242.73/32 138.1.16.168/32 129.149.114.199/32 192.29.222.78/32 129.149.98.107/32 129.149.122.166/32 192.29.38.186/32 147.154.123.93/32 129.149.39.7/32 129.148.179.162/32 129.148.160.57/32 192.29.153.28/32 129.149.3.154/32 129.148.144.226/32 192.29.82.26/32 192.29.69.154/32 192.29.181.241/32
NPM (registry.npmjs.org)	104.16.16.35/32 104.16.17.35/32 104.16.18.35/32 104.16.19.35/32 104.16.20.35/32 104.16.21.35/32 104.16.22.35/32 104.16.23.35/32 104.16.24.35/32 104.16.25.35/32 104.16.26.35/32 104.16.27.35/32
Node.js (nodejs.org)	104.20.22.46/32 104.20.23.46/32
Docker - OL8 only (download.docker.com)	108.156.91.110/32 108.156.91.29/32 108.156.91.41/32 108.156.91.7/32