[go: nahoru, domu]

Jump to content

Help:Unmanaged Cloud VPS instances

From Wikitech

This page contains information about unmanaged and unpuppetized cloud-vps instances. Most cloud-vps users will want to use managed instances instead.

Difference between managed and unmanaged Cloud VPS instances

Most Cloud VPS instances are automatically provisioned with WMCS-specific features and receive occasional support from WMCS admins. These features include:

  • Automatic configuration management, provided by Puppet and based on a centralized and staff-managed catalog
  • Automatic, unattended upgrades of most installed Debian packages
  • SSH key management, integrated with Horizon and Wikimedia IDM
  • Horizon management of VM access and sudo policies
  • On request, admin assistance with rescuing data and/or regaining access to a VM that has become inaccessible due to hardware or system failure or user error.

In some cases, a Cloud VPS users will want a more standard, stripped-down public cloud experience. For example, users provisioning VMs with OpenTofu or Ansible may want complete control of every step in a VM's lifecycle so they can rapidly discard and recreate VMs.

Users who need to opt out of WMCS management of their VMs can request access to an unmanaged base image. This will be a generic upstream Debian image with no Cloud VPS-specific additions. Access can then be configured via ssh key injection on startup, and additional configuration can be provided to cloud-init via user data.

Unmanaged instances are subject to certain limitations:

  • WMCS admins will be unable to easily gain access to unmanaged VMs. Once such an instance becomes unreachable or otherwise broken it will have to be discarded and replaced.
  • Because an unmanaged instance will present as a black box to WMCS admins, any suspected violation of the terms of use will be dealt with swiftly and likely without consultation with project members. An unmanaged VM may be immediately shut down or deleted if it is a source of malicious web traffic or appears to be running unapproved software.
  • Unmanaged VMs may be subject to additional brief periods of unscheduled downtime.

Enabling umanaged instances in your Cloud VPS project

If you would like to use unmanaged instances and you accept the associated risks and responsibilities, open a Cloud-VPS quota request explaining your needs and plans.

Unmanaged instances are enabled by adding an unpuppetized base image to your project. The command will be run by a WMCS admin and look something like

$ openstack image add project debian-12.0-nopuppet <projectname>

Creating unmanaged instances

Any instance based off of an unpuppetized base image will be unmanaged. If a WMCS admin has added such an instance to your project, you can create an unmanaged instance by selecting that image during VM creation. Such images will typically have 'nopuppet' or 'upstream' in their names.

A screenshot of the Horizon instance creation dialog, showing the image-selection tab. The selected image is named 'debian-12.0-nopuppet'

Don't forget to include an ssh key in the new VM, or the VM will be unreachable.

Accessing unmanaged instances

Because unmanaged instances do not have automatic ssh key integration, you need to inject one or more ssh keys on creation for access. Key injection is only available as part of instance creation, and a VM created without ssh key injection will never be reachable.

The Horizon 'create instance' dialog box, showing the 'Key Pair' tab. This tab includes buttons to create and import keypairs as well as an interface for adding or removing a given keypair to or from an instance before creation.

If using Horizon, there is a tab visible in the VM creation workflow that supports creation, importation, and injection of ssh keys into the to-be-created instance.

Ssh keys can also be injected during VM creation by OpenTofu or directly via the OpenStack commandline or Openstack Nova APIs.

Communication and support

Support and administration of the WMCS resources is provided by the Wikimedia Foundation Cloud Services team and Wikimedia movement volunteers. Please reach out with questions and join the conversation:

Discuss and receive general support
Stay aware of critical changes and plans
Track work tasks and report bugs

Use a subproject of the #Cloud-Services Phabricator project to track confirmed bug reports and feature requests about the Cloud Services infrastructure itself

Read stories and WMCS blog posts

Read the Cloud Services Blog (for the broader Wikimedia movement, see the Wikimedia Technical Blog)