Cloud-init

Learn more about CloudInit for Virtual Servers.

Cloud-init can be used to configure granular aspects of Virtual Servers at the time of instance boot.

Cloud-init identifies where it is running (in this case, CoreWeave Cloud), reads any provided metadata from the Cloud environment, then initializes the system according to that metadata.

The most common use cases for cloud-init include:

  • 🔑 Automatically configuring SSH access keys

  • 🗄️ Setting up storage or network devices

  • 🧑 Configuring additional user accounts

  • 📜 Running custom scripts on system initialization

Any parameters passed to cloud-init via the implementation options below will use the standard cloud-init configurations.

Basic usage

Additional Resources

For more examples of cloud-init use cases and additional reference material, refer to the cloud-init website.

Deployment method: CoreWeave Cloud UI

Cloud-init configuration options must be configured in the YAML editor on the Virtual Servers deployment menu. All cloud-init options are configured in the cloudInit stanza:

cloudInit: |
  write_files:
  - content: |
    #!/bin/bash
    echo "Hello world!"
    path: /home/myuser/script.sh
    permissions: `0744`
    owner: myuser:myuser
    package_update: true
    packages:
      - curl
      - git
    runcmd:
      - [df, -h]
      - [git, version]
      - [curl, --version]
      - [bash, /home/myuser/script.sh]

In the example above, cloud-init is configured to create a file with a simple script that prints the string Hello world!. The file is given a permission mask of 0744, and is owned by the user named myuser.

Additionally, a package update command will be run on the machine, before the curl and git packages are installed on the machine.

Lastly, the system will run the commands given under the runcmd list:

  1. First, the amount of free disk space will be printed in human-readable format (df -h).

  2. Then, the version of git installed on the system earlier will be output (git version).

  3. Similarly, the version of curl installed on the system will be printed (curl --version).

  4. Finally, the script created at the top of the block under write_files will be passed to bash to run (bash /home/myuser/script.sh).

Mounted drive settings

Specify drive letters for block volumes

By default, letters assigned to block volumes are randomized, but cloud-init can be used to assign specific letters to mounted block volumes.

Note

A PVC must first be created before cloud-init can assign it a letter as a mounted drive. See Get Started with Storage for more information.

For example:

cloudInit: |
    mounts:
    - drive: G
      name: local-storage
    - drive: Y
      serial: banana
    - drive: E
      name: windows-smb-vol
      serial: orange
      partition: 2

Here, the desired letter is set as the value of mounts.drive. To select the drive to assign this letter, pass either its .drive.name (this must match the name of the associated PVC), and/or its serial number (.drive.serial).

cloudInit: |
    mounts:
    - drive: G
      name: local-storage

Specific partitions may be selected for letter assignments using .drive.partition. If a partition is not specified, it's assumed to be the first non-SystemReserved partition.

If a serial number (.drive.serial) is not specified to identify a drive, the desired drive is discovered using .drive.name.

Mount point data is written from cloud-init to the registry. Mount points attempt to reconcile on each boot. Should there be any mount point collisions, the colliding drive is re-assigned to the first available drive letter.

Change the disk's format

By default, any drives that are in RAW format are automatically formatted to ext4 as a full disk partition. This can be disabled by setting cloudInit.disks.autoFormatRAW to false:

spec:
  cloudInit: |
    disks:
      autoFormatRAW: false

Or, the new format may be changed to something specific, by setting the desired filesystem type as the value of cloudInit.disks.fsType.

spec:
  cloudInit: |
    disks:
      fsType: ext4

Configure custom mount points for block devices

By default, block devices are mounted automatically to a Virtual Server during creation, and are mounted to the path /mnt/$DRIVE_SERIAL. If the block device has multiple partitions, the device will be mounted to the path /mnt/$DRIVE_SERIAL/$PARTITION.

For example:

Filesystem      Size  Used Avail Use% Mounted on

/dev/vde1       9.8G   24K  9.3G   1% /mnt/B0144F2B8B06/0
/dev/vde2       9.8G   24K  9.3G   1% /mnt/B0144F2B8B06/1

Custom mount points for block devices may be configured using cloud-init, using cloudInit.disks.mounts. To specify a mount point for a specific disk, pass through the name of the disk (.mounts.name), and then specify the desired mount point (.mounts.mountPoint).

For example:

spec:
  cloudInit: |
    disks:
      mounts:
        - name: test-block-2
          mountPoint: /mnt/banana

If the block device has partitions, set the partition to target as the value of .mounts.partition.

For example:

spec:
  cloudInit: |
    disks:
      mounts:
        - name: test-block-part
          mountPoint: /mnt/foo
          partition: "1"

Create ephemeral storage

Warning

Ephemeral storage does not persist if the Virtual Server is restarted, shut down, or deleted. In these events, all ephemeral storage data will be lost.

Ephemeral storage enables high performance storage for Virtual Servers that does not persist if the Virtual Server is shut down, restarted, or deleted. Ephemeral storage is provided free of charge.

During Virtual Server creation, ephemeral storage disks may be attached to the Virtual Server toggling on the Add ephemeral storage option.

The size of the ephemeral disk may be chosen using the slider or by entering the desired size (in Gi) in the field to the right of the slider.

In the YAML manifest editor, this new ephemeral storage allocation is defined within the additionalDisks stanza.

additionalDisks:
  - name: ephemeral-disk
    spec:
      emptyDisk:
        capacity: 10Gi

Set a custom mount point for ephemeral storage

By default, ephemeral storage disks are automatically mounted to the path /var/tmp. To change this using cloud-init, set the desired path in the .cloudInit.disks.ephemeralMountPoint field:

  cloudInit: |
    disks:
      ephemeralMountPoint: /foo/bar

Note

The default path for ephemeral storage may also be set using the Virtual Servers creation screen on the Cloud UI.

PreviousNode AffinityNextAdditional Features

Last updated