Proxmox cloud init что это

In the last post I covered deploying Linux-based Proxmox instances using Terraform, leveraging Cloud-Init and cloud-config to register these instances with SaltStack.

The instances in the previous post were both Linux distributions (Debian and Fedora). This is because Cloud-Init was initially built for Linux, and then ported to other Unix-like systems (eg FreeBSD, OpenBSD and more).

Thanks to a company called Cloudbase Solutions an equivalent of Cloud-Init is also available for Windows, known as Cloudbase-Init.

Cloudbase-Init

Cloudbase-Init is written in Python, and was originally developed to allow customization of Windows images on OpenStack. However it also supports a number of different metadata services (everything from AWS and Azure to VMware).

Preparing the template machine

The first step before creating your instances is to create a template Windows image. This image can then be used as a base image for other instances (using cloning).

Cloudbase Solutions provide tools to build Windows images ready to be deployed with Cloudbase-Init installed, but they rely on Hyper-V on Windows. If you do not have access to a Windows machine to generate the images, do not have access to Hyper-V, or simply want to go through the process yourself, then you can install Cloudbase-Init in a Windows instance yourself.

Installing Windows

In this post, I am using Windows Server Core 2019 (i.e. without the Desktop Experience installed). As Proxmox uses KVM as its underlying hypervisor, you will also need to download the VirtIO-Win ISO. This contains all the necessary drivers for Windows for VirtIO-based NICs, storage and serial devices. Without this, you would need use emulated devices (i.e. emulated SATA or network devices), which are less efficient than the VirtIO equivalents.

First, download the VirtIO ISO and place it in the /var/lib/vz/templates/iso directory on your Proxmox host. This is where Proxmox expects to find all ISO images by default.

After this, place the ISO for your Windows version of choice in the same directory. If you already have the ISOs, then use something like scp or rsync to place it on the Proxmox server. Alternatively, you can dowload trial versions of Windows from the Microsoft Evaluation Center. These trial versions can be activated later with the appropriate license key and service contract with Microsoft.

Create the VM

General Options

Choose the OS

System hardware (Disk controller and graphics

Create the disk

Choose the CPU and core count

Choose the amount of memory

Choose the network

Loading files

Booting

Choose your language and timezone

Click Install Now

Choose which version (Desktop Experience = GUI)

Choose Custom installation (because there is no existing installation to upgrade)

You can choose to install the drivers later, using either the GUI if you chose the desktop experience, or using pnputil if using Server Core.

Unlock the instance (using Ctrl, Alt and Delete

Proxmox Ctrl, Alt and Delete in NoVNC

Confirm changing of the password

Change the password

Logged in as the Administrator

At this point, we are now ready to customize the image.

Customization

The reason for disabling the firewall is that in the environments I work in, host-based firewalls are not used. Instead, they are managed either via network firewalls or via security groups (if used within a cloud provider). If you require the firewall to be enabled, then you will need to customize the firewall rules to match your environment.

Installing OpenSSH Server

Install Salt

To install the Salt Minion, again you can follow the steps in this post. However, do not follow the steps for updating the minion configuration post-install. The minion configuration will be customized by Cloudbase-Init based upon the provided User Data.

Disable the firewall and enable RDP

While most tasks can be completed using Powershell in Windows Core, there is no inbuilt text editor. You can either install something like ViM or you can use RDP so that notepad.exe is available for file editing.

We also disable the firewall at this point, as otherwise we will need to add an RDP-specific rule to the firewall to allow us to access the machine.

Installing Cloudbase-Init

To install Cloudbase-Init, go to the Cloudbase-Init product page, scroll down to Downloads, and choose the version appropriate for your environment. I am running Windows 2019 on a 64-bit x86 processor, so I chose the Stable Cloudbase-init x64 version.

You can install Cloudbase-Init interactively and follow the on-screen instructions to customize the configuration. However we will need to change some options within the Cloudbase-Init configuration anyway, so there is little to benefit in using the GUI installer to configure the Cloudbase-Init service.

Configuring Cloudbase-Init

The default configuration files for Cloudbase-Init enable a number of different metadata services, most of which are not applicable to Proxmox.

C:\Program Files\Cloudbase Solutions\cloudbase-init\conf\cloudbase-init.conf

C:\Program Files\Cloudbase Solutions\cloudbase-init\conf\cloudbase-init-unattend.conf

We also set all Cloudbase-Init logs to be exposed on the Serial port, allowing us to see the changes being made by Cloudbase-Init (as well as any errors/warnings) separately from the boot and login process itself on screen/VNC.

This will prepare the instance and tell the system to run cloudbase-init.exe on boot.

Creating a template

We can now use this template when defining an instance within Terraform

Terraform

Create the Cloud-Init template

The first step to building an instance using Terraform is to prepare the Cloud-Init template.

In regards to the latter, there is an issue with how Proxmox provides the DNS Nameservers. Proxmox provides dns_nameservers as the option, whereas Cloudbase-Init expects dns-nameservers (associated Github Issue). This issue, combined with Cloudbase-Init not supporting cloud-config network module (to customize our network configuration) means that we must rely on DHCP.

We use a feature called multi-part content to leverage both cloud-config and Powershell to configure the instance. You could extend this to use more complex Powershell scripts, setting the timezone, creating users and more. In our file, we update the Salt Minion configuration (using the write_files module in cloud-config ), and then restart the salt-minion service (using Powershell).

Define the instance

One notable difference is that we set the ipconfig0 = «ip=dhcp» option. Without this, the Terraform provider will crash. We should be able to provide a static IP here, but as noted previously, the format Cloudbase-Init provides DNS nameservers in is not compatible with Cloudbase-Init, meaning that we would not be able to access any hostname-based service (eg our Salt server, or downloading dependencies).

Other than this, we should now be able to build a Windows instance.

Build the instance

Alternatively, if you do not install the Qemu Guest Agent, then the Terraform provider will complete without issues. It is worthwile running the Guest Agent (safer shutdowns, exposes information to the hypervisor regarding the instance), but it is not necessary to the day to day running of the machine.

As per the previous post, we also run a highstate (i.e. all applicable Salt states) when the Minion is accepted by the Salt server.

Accept the key

Verify the highstate

Looks like they are working! It is worth nothing that we do not set a hostname in cloud-config for our machine, so it uses a randomly generated hostname instead.

Everything looks good!

Prometheus

As noted in the previous post, we are using the same Prometheus setup as we do here.

Grafana

Summary

Using Cloudbase-Init, it is possible to customize a Windows image when it starts for the first time, allowing you to bootstrap a machine ready to be used in your environment. This takes away the work of installing machines manually, while also being able to manage Windows in a similar way to Linux and Unix variants (eg FreeBSD, OpenBSD) that support Cloud-Init.

As we have also seen, it is not without caveats currently. Some of this is down to Proxmox in how it presents Cloud-Init data, some of it is down to the Cloudbase-Init utility that is expecting configuration in a certain format but could potentially be in multiple formats (i.e. both dns-nameservers and dns_nameservers are possible within Cloud-Init, but Cloudbase-Init currently understands the former), and some are down to the Terraform provider that does not seem to understand some of values presented by the Proxmox API (specifically the IPv6 addressing).

Over time these will improve, as issues have been raised for all of these cases. This should not discourage you from using any of these tools, as all of them together bring Windows deployment on Proxmox on par with Linux (in terms of bootstrapping and Terraform usage).

Cloudbase-Init was initially created for use with OpenStack, and the fact it works with other providers and infrastructure is a nice bonus.

Источник

Proxmox cloud init что это

Proxmox has support for Cloud-Init, which allows changing settings in the guest when deploying. This is important because you’ll want to make sure the settings in your VM do not match the base image or you’ll have IP conflicts, duplicate SSH host keys, SSH keys in authorized_keys files that you probably don’t want in there and so forth.

Cloud-Init has many ways to get the configuration information to the guest, and two of them are supported by Proxmox: NoCloud (v1), and ConfigDrive (v2). According to the documentation, NoCloud is used for Linux and ConfigDrive is used for Windows. However in the FAQ, it mentions that ConfigDrive is not officially supported for Windows.

It’s also important that your base image has support for Cloud-Init as well, and be configured to use with either NoCloud or ConfigDrive. Proxmox has documentation in the FAQ about creating a custom cloud image which should suffice.

It’s important to note that you must not reboot the base image after installing and setting up the Cloud-Init. The first boot will trigger a bunch of «first boot» configuration actions to take place. One of the standard ones is regenerating SSH host keys. This means if you install the package with a preseed file, and then run a provisioner, you’ll have triggered these steps, which means they will not be triggered after the VM is cloned.

After the base image is set up, the deployment process goes like this:

When using the Terraform provider for Proxmox, you do not need to create a configuration file. All you need to do is specify the settings that you want to pass into the guest. The most common one will be ipconfig0 to configure the first network interface, but there are more listed in the Proxmox docs.

Now, there is one other way to get the configuration data into the guest without using this magical CloudInit CD-ROM and that’s by using cicustom. This allows you to create a NoCloud (v1) or ConfigDrive (v2) configuration file instead of using the one that will be automatically generated for you. The example below shows how to use this. For help writing the config file, see the NoCloud or ConfigDrive docs.

Источник

Cloud-init: автоматическая установка hostname для виртуальной машины

Внутри каждого шаблона для виртуальной машины в Облаке КРОК установлен cloud-init. Это великолепный инструмент для автоматизации рутинных операций в процессе начального запуска вашей виртуальной машины. В этой статье я расскажу, как автоматизировать установку имени сервера (hostname).

Как работает cloud-init

В каждом публичном Облаке (AWS, GCP, Azure) или частном Облаке (OpenStack или CloudStack) есть так называемый сервис метаданных. Задача этого сервиса предоставлять виртуальной машине информацию об окружении, в котором она запущена. Эта информация обычно как минимум содержит в себе:

Например, ваша виртуальная машина может самостоятельно узнать собственный hostname следующим образом:

Cloud-init в свою очередь представляет собой набор скриптов, поддерживаемых сообществом в актуальном состоянии, который настраивает вашу виртуальную машину на основании информации из сервиса метаданных.

У сервиса метаданных есть одно интересное поле, которое может быть изменено в любой момент жизненного цикла виртуальной машины — «пользовательские данные» (user-data), доступное внутри виртуальной машины по адресу:

Пользовательские данные сервиса метаданных используются для всевозможной автоматизации ваших шаблонов, например, автоматическая установка в процессе запуска необходимого ПО, задания имени сервера, установка и запуск ПО управления изменениями в конфигурации, т.к. Chef, Puppet или Ansible и т.д.

Сloud-init работает следующим образом: он читает данные настроек «Пользовательских данных» и, если они заданы в формате, который понимает cloud-init, то он может выполнять действия описанные в пользовательских данных, игнорируя настройки сервиса метаданных.

Задание имени хоста при загрузке виртуальной машины

Простейший пример «Пользовательских данных» — это задание имени хоста при загрузке виртуальной машины. Для этого в процессе создания виртуальной машины задайте «Пользовательские данные» следующим образом:

Источник

Администрирование и не только

Не вполне стандартные задачи, с которыми мне приходится сталкиваться по работе и способы их решения.

Страницы

среда, 24 марта 2021 г.

Руководство администратора Proxmox VE R 6.0 Глава 10.8

Виртуальные машины Qemu/KVM

Поддержка Cloud-Init

Многие дистрибутивы Linux предоставляют готовые к использованию образы Cloud-Init, в основном предназначенные для OpenStack. Эти образы также будут работать с Proxmox VE. Несмотря на то, что получение таких готовых образов может показаться удобным, мы как правило рекомендуем подготавливать образы самостоятельно. Преимущество в том, что вы будете точно знать, что вы установили, и это поможет вам позже легко настроить образ в соответствии с вашими требованиями.

После создания такого образа Cloud-Init мы рекомендуем преобразовать его в шаблон виртуальной машины. С шаблоном ВМ, вы можете быстро создавать связанные клоны, так что это быстрый метод развертывания новых экземпляров виртуальных машин. Вам только необходимо настроить сеть (и, возможно, ключи ssh) перед запуском новой виртуальной машины.

Мы рекомендуем использовать аутентификацию на основе ключей SSH для входа на виртуальные машины, предоставленные Cloud-Init. Также возможно установить пароль, но это не так безопасно, как использование аутентификации на основе ключа SSH, потому что Proxmox VE приходится хранить зашифрованную версию этого пароля в данных Cloud-Init.

Proxmox VE создает образ ISO для передачи данных Cloud-Init в ВМ. Для этого всем Cloud-Init ВМ должен быть назначен привод CDROM. Также многие образы Cloud-Init предполагают наличие последовательной консоли, поэтому рекомендуется добавить последовательную консоль и использовать ее в качестве дисплея для этих виртуальных машин.

Источник

Cloud-Init Support

Cloud-Init is the de facto multi-distribution package that handles early initialization of a virtual machine instance. Using Cloud-Init, configuration of network devices and ssh keys on the hypervisor side is possible. When the VM starts for the first time, the Cloud-Init software inside the VM will apply those settings.

Many Linux distributions provide ready-to-use Cloud-Init images, mostly designed for OpenStack. These images will also work with Proxmox VE. While it may seem convenient to get such ready-to-use images, we usually recommended to prepare the images by yourself. The advantage is that you will know exactly what you have installed, and this helps you later to easily customize the image for your needs.

Once you have created such a Cloud-Init image we recommend to convert it into a VM template. From a VM template you can quickly create linked clones, so this is a fast method to roll out new VM instances. You just need to configure the network (and maybe the ssh keys) before you start the new VM.

We recommend using SSH key-based authentication to login to the VMs provisioned by Cloud-Init. It is also possible to set a password, but this is not as safe as using SSH key-based authentication because Proxmox VE needs to store an encrypted version of that password inside the Cloud-Init data.

Proxmox VE generates an ISO image to pass the Cloud-Init data to the VM. For that purpose, all Cloud-Init VMs need to have an assigned CD-ROM drive. Also many Cloud-Init images assume to have a serial console, so it is recommended to add a serial console and use it as display for those VMs.

Preparing Cloud-Init Templates

The first step is to prepare your VM. Basically you can use any VM. Simply install the Cloud-Init packages inside the VM that you want to prepare. On Debian/Ubuntu based systems this is as simple as:

Already many distributions provide ready-to-use Cloud-Init images (provided as .qcow2 files), so alternatively you can simply download and import such images. For the following example, we will use the cloud image provided by Ubuntu at https://cloud-images.ubuntu.com.

Add Cloud-Init CD-ROM drive

The next step is to configure a CD-ROM drive, which will be used to pass the Cloud-Init data to the VM.

Also configure a serial console and use it as a display. Many Cloud-Init images rely on this, as it is an requirement for OpenStack images.

In a last step, it is helpful to convert the VM into a template. From this template you can then quickly create linked clones. The deployment from VM templates is much faster than creating a full clone (copy).

Deploying Cloud-Init Templates

You can easily deploy such a template by cloning:

Then configure the SSH public key used for authentication, and configure the IP setup:

You can also configure all the Cloud-Init options using a single command only. We have simply split the above example to separate the commands for reducing the line length. Also make sure to adopt the IP setup for your specific environment.

Custom Cloud-Init Configuration

The Cloud-Init integration also allows custom config files to be used instead of the automatically generated configs. This is done via the cicustom option on the command line:

The custom config files have to be on a storage that supports snippets and have to be available on all nodes the VM is going to be migrated to. Otherwise the VM won’t be able to start. For example:

There are three kinds of configs for Cloud-Init. The first one is the user config as seen in the example above. The second is the network config and the third the meta config. They can all be specified together or mixed and matched however needed. The automatically generated config will be used for any that don’t have a custom config file specified.

The generated config can be dumped to serve as a base for custom configs:

Cloud-Init specific Options

Specify custom files to replace the automatically generated ones at start.

Specify a custom file containing all network data passed to the VM via cloud-init.

Specify a custom file containing all user data passed to the VM via cloud-init.

Specify a custom file containing all vendor data passed to the VM via cloud-init.

Password to assign the user. Using this is generally not recommended. Use ssh keys instead. Also note that older cloud-init versions do not support hashed passwords.

User name to change ssh keys and password for instead of the image’s configured default user.

Specify IP addresses and gateways for the corresponding interface.

IP addresses use CIDR notation, gateways are optional but need an IP of the same type specified.

The special string dhcp can be used for IP addresses to use DHCP, in which case no explicit gateway should be provided. For IPv6 the special string auto can be used to use stateless autoconfiguration. This requires cloud-init 19.4 or newer.

If cloud-init is enabled and neither an IPv4 nor an IPv6 address is specified, it defaults to using dhcp on IPv4.

Default gateway for IPv4 traffic.

Default gateway for IPv6 traffic.

IPv4 address in CIDR format.

IPv6 address in CIDR format.

Setup public SSH keys (one key per line, OpenSSH format).

Источник