Skip to main content

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:

Example
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:

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).

Example
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:

Example
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.

Example
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:

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:

{4-6}
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:

{5-7}
spec:

  cloudInit: |

    disks:

      mounts:

        - name: test-block-part

          mountPoint: /mnt/foo

          partition: "1"

Create ephemeral storage​

Caution

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.

{1}
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:

Example
  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.

Last updated on