Overview of the compute service

The evroc compute service provides Virtual Machines (VMs) as one of two methods for delivering on-demand compute resources, the other being serverless containers.

Understanding the Object Model

The evroc cloud decomposes the elements needed to run VMs into modular resources, each of which can be created, updated and deleted independently.

This offers the advantage of allowing you to, for example, retain the same public IP while replacing the VM associated with it with a different one. Understanding these resources and their interdependencies is crucial for using evroc's cloud.

The diagram below illustrates the relationship between the core resources used to run VMs in evroc's cloud. The resources in green are created by default in each resource group, whereas the resources in blue are created, updated, and deleted by users.

Object Flow

The main resource is a VirtualMachine.

As per the API, the VirtualMachine resource contains important references to other resource types:

  • VMs MUST reference a Disk to boot from.

  • VMs MAY reference up to nine further Disks.

  • VMs MAY reference a Public IP:

    • In future, you may want to delete a VM while keeping the static public IP, allowing you to re-attach the same public IP to a different VM.
    • To create a public IP, you must first have created an external gateway and must reference the default Virtual Private Cloud (VPC), that will have automatically been created for you.

  • VMs MAY reference zero or more security groups:

    • If no security groups are referenced on the VM, the VM will be placed into the default security group. This allows all inbound and outbound connections within the VPC, and outbound connections to the internet.
    • If the VM explicitly references one or more security groups, it only has the networking capabilities specified in those security groups (losing the capabilities of the default security group).
    • VMs can reference multiple security groups, and multiple VMs can reference the same security group.

    Warning: There is a significant difference in behavior between a VM without any security groups referenced and a VM that references one or more security groups.

  • VMs MAY reference a placement group:

    • If a placement group is referenced, the VM is scheduled according to the placement strategy specified on the placement group.

  • Additionally, a VM MUST provide the name of a VMVirtualResources object, which defines the hardware resources available to it.

You will notice that VMs do not explicitly reference a subnet. Because each resource group is automatically configured with a default subnet, currently VMs are deployed within this subnet, creating an implicit reference to the subnet.

Understanding the Networking Model

  • Each resource group corresponds to a VPC with a default subnet using the CIDR range 10.0.0.0/24.
  • By default, two VMs in the same resource group will belong to the same subnet with no restrictions on how they communicate with each other.
  • By default, VMs can connect outbound to the internet, but a public IP needs to be created and then referenced by the VM in order to enable inbound connectivity.
    • A security group allowing inbound connectivity will also need to be configured on the VM, though note that this will override the default security group rules - so if outbound connectivity is also required, this will need to be configured on the security group (or on a second security group the VM is a part of).
  • Defining additional VPCs, subnets or more than one external gateway is not currently supported.
  • Attaching a VM to multiple subnets is not currently supported.
  • Outbound internet access from a VM is already present given the default networking stack. Traffic from the VM is routed to the external gateway, which forwards it onto the internet.

N.B. If you do not assign a public IP to your VM, then the public IP for outbound traffic will be shared by other users of the evroc cloud.

Enabling inbound internet access to VMs

In order to enable inbound internet access to a VM, you will then need to create a public IP resource, and assign it to a VM. See the API and CLI docs for more information on how to create the public IP.

If you need inbound SSH access, you will also need to configure SSH public keys on your VM when the VM is created.

If you assign a public IP to a VM, its outbound internet traffic will use this public IP exclusively.

In addition, you will need to ensure that the inbound traffic is not disallowed by any of the VM's security groups.