As we continue expanding the functionality and convenience of our new public RESTful API, Hivelocity is pleased to announce our bare metal dedicated servers now offer instant configuration with cloud-init support. As the industry-standard for customizing cloud instances, cloud-init means our customers can now configure their dedicated servers with the same single-click provisioning offered through our portal and API. At Hivelocity, we’re merging the convenience and scalability of the cloud with the security and reliability of a bare metal solution.
But what does our new cloud-init integration mean for you? Read on to learn about all the important features this tool has to offer.
What is Cloud-init?
If you have experience working with any of the major cloud providers, chances are you’re already familiar with cloud-init, even if you might not realize it.
Developed under the GPLv3 open source license and designed specifically for the Ubuntu operating system (OS), cloud-init has grown into the industry-standard for the configuration of new servers. By reading and executing scripts entered as User Data on a server’s initial boot, cloud-init allows users to specify the intended purpose of a machine as part of its deployment. For users working at scale, this ability to replicate and auto-initialize applications on new machines instantly is indispensable. Now compatible with most Linux instances and freely available to the public (its source code can be downloaded through GitHub), cloud-init has become an integral component of virtually every major cloud solution.
Why is Cloud-init Essential for Cloud Solutions?
When you deploy a machine through a cloud service provider, the instance that gets created is a clone of every other default instance. Using a template, the system quickly partitions and replicates necessary resources, making your new server’s basic functionality identical to all the rest.
In the end, what actually makes one machine different from another comes down to its user data. These are the instructions that help set your instance apart. Whether in the form of scripts specified by you the user, or as metadata provided by the cloud vendor, these instructions tell your machine what it’s intended to be.
For example, is this machine going to host your website? Then you might want it running WordPress or Postgresql straight out of the box. Are you dedicating this server to a single, specific process? Cloud-init let’s you make sure it has all the applications it needs on first-boot. Maybe you’re planning to split your machine into multiple VMs or containers? Install Docker, Proxmox, and more, all with a single, reusable script.
User data can be written using virtually any interpreter, however, in order for your new machine to execute these pre-packaged instructions it must already have the corresponding language installed. So, while you’re free to run your cloud-init scripts using Python, you’re going to need a script that installs Python on your server first.
For this reason, the two most commonly used languages for cloud-init are Bash (since it comes default on everything), and cloud-init’s own native cloud-config language.
Based on Yaml syntax, cloud-config provides users with a human-readable alternative to Bash. To script in cloud-config, just begin your syntax with #cloud-config and follow the Yaml guidelines for formatting. For more information on the specifics of cloud-init user data scripts, see the official cloud-init documentation. For an example of what a cloud-config script or a Bash post-install script looks like, check out these sample scripts listed in our public API documentation.
While cloud-init is available for use with all major Linux variations, including Ubuntu, FreeBSD, CentOS, Red Hat, Fedora, and more, if you’re a Windows user hoping to pre-configure your servers, you’re going to need a different tool for the job. Thankfully, such a tool already exists.
Known as CloudBase-init, this tool operates in a similar manner to cloud-init and offers cloud-configuration functions for machines running Windows OS. To learn more about CloudBase-init, check out the information available on its official website.
For our Hivelocity customers running Windows-based machines through our platform, you also have the option to provide a powershell script to bootstrap your applications automatically. For more information, check out our API documentation or start a chat now.
What Can Cloud-init Do?
So now that we’ve discussed why cloud-init is so prolific, it’s time to look at some examples of what cloud-init can be used to accomplish.
One of the biggest advantages of cloud-init is the ability to generate and set your server’s hostname and SSH keys on initial boot. Rather than manually entering and verifying this information by hand, cloud-init allows users to automatically handle this process through code which can be replicated and reused as needed. This improves the overall security of your system, minimizing the window of vulnerability between your server’s deployment and the initialization of its encryption key, as well as ensuring greater ease with future deployments too.
Additionally, other first-step processes such as selecting and installing your desired OS, establishing databases and YUM repositories, creating partitions, and setting default information like server location can all be accomplished instantly through simple syntax.
Most powerfully, cloud-init also allows users to bootstrap their machine’s applications. Pull a GitHub repo using the application source, automatically install its requirements, and activate the application, all on your machine’s first-boot. This process can then be maintained as easily as checking your cloud-init config file into the repo itself.
In the end, cloud-init functionality is really only limited by the user’s needs.
Cloud-init and IaC
One of the greatest advantages of cloud-init is the way it integrates with external IaC tools to allow users greater control over the deployment of their virtual and physical machines. Short for Infrastructure as Code, IaC tools are specialized software that facilitate and orchestrate the automatic deployment of infrastructure. Especially useful for hybrid or multi-cloud environments, IaC tools, including Terraform, Ansible, Puppet, and more, allow users to codify their infrastructure, yielding both greater control and convenience.
Additionally, since these tools all run on code input by the user, the ability to replicate processes is as easy as copying your script over to all applicable instances. This improves the scalability and stability of your system, ensuring uniformity, minimizing chances for human error, and maximizing the ease with which new instances can be created and destroyed.
But beyond the initial deployment of your infrastructure, when else might a tool like this be beneficial?
Let’s say your system runs a process one day a month that places a heavy drain on your resources. Maybe it’s a large-scale backup or some kind of system-wide check. The cycle this process occurs on is predictable and the tools needed to accomplish it are available to you, but the resource drain it causes places a strain on your entire network.
What can you do?
You could always buy a separate server, configure it for this specific process, and leave it sitting on a rack somewhere until it’s needed. This solution might cover your immediate needs, but on the whole, it’s rather inefficient. After all, if your process only runs for one day a month, that server spends the other 30 or so days just taking up space.
Wouldn’t it be better if you could deploy a new machine, place it on a specific schedule, outfit it automatically with the proper tools, and then destroy it once its task has been completed?
With IaC tools like Terraform and the instant deployment VMs offered through most major cloud platforms, the system described above is actually very achievable. However, public cloud solutions, while convenient, aren’t the right fit for every company. Whether it’s strict external regulations or simply the litany of hidden fees, the cloud can’t offer a one-size-fits-all solution for every user.
Now though, thanks to Hivelocity’s new bare metal cloud, the same functionality and convenience promised by the cloud is available in the form of a dedicated server solution.
By integrating IaC tools with our public API and cloud-init, you can now combine cloud-like flexibility with bare metal’s high-caliber performance. Simply write out your syntax, set the schedule your events will trigger on, and let your infrastructure scale and descale as needed. With cloud-init, you can ensure your newly-spun instances start off with everything they need, allowing tasks to be accomplished quickly and effectively. Once an instance has outlived its usefulness, automation included in your code can tear it down and reset the cycle for next time.
In this way, cloud-init and IaC combine to offer users an easy-to-use solution to complex infrastructure issues. Whether you’re working with virtual or physical machines, cloud-init functionality added to IaC-provided control means your system can grow and change alongside your organization’s needs. Utilize resources more efficiently, react and grow more dynamically, and trim unnecessary financial waste.
Cloud-init, Dedicated Servers, and the Hivelocity API
With Hivelocity’s new public API, hourly billing options, and cloud-init functionality, you can now construct the same auto-scaling infrastructure available from the major cloud platforms all while utilizing the superior performance and reliability of a dedicated server solution. Deploy servers instantly through API calls, initialize them to your needs automatically with cloud-init, and deploy and destroy instances as needed alongside our new on-demand pricing. For more information on cloud-init and the Hivelocity API, check out our public API documentation.
Curious what bare metal could do for your business?
The cloud may be here to stay, but at Hivelocity, we know the future is still bare metal.