Manage your servers
Use the Console to manage your server instances.
Instances page
On the Instances page, you can:
- Add new server instances
- See each server’s state and status
- View and copy each server’s name, ID, and IP address
- Open a detailed view of a server
Select a server in the Instances list to open it in a detailed view.
Instance details
On the instance Details tab, you can:
- See your server’s state and status
- See updates about potential outages or errors
- Stop, start, reboot, and terminate your server
- See a summary of your server configuration, network settings, and security settings
The Console provides up-to-date status updates in case a server has system or instance-level issues. In case of an incident, you can respond directly within the Console by rebooting or terminating servers.
Attach storage
Nebula enables you to attach additional block storage to your server instances. This is useful in scenarios where you need separate, additional storage to store data away from the operating system drive of your server.
You can create additional block storage in 2 ways:
- On the Disks Console page
- Directly via the
+
button in left navigation menu of the Console
When you create block storage instances, you must define a name and a size for the storage in GiB
. You can then attach block storage to a server in 2 ways:
- On the Disk tab of a server's details page
- On the details page of a storage instance via the Disks page
Visit the Disks page to create new block storage volumes, or manage existing ones.
You can resize block storage instances, attach or detach them from servers, and delete them.
Add security groups
On the instance Security groups tab, you can attach or remove security groups from your instance.
Visit the Security groups Console page to create or edit security groups.
You can attach multiple security groups to a server instance.
Read more about the available security features here.
Server states and statuses
These are the available server states and statuses:
State | Meaning |
---|---|
No data | No information is available. This usually happens during server initialization or failure events. |
Active | The instance is running. |
Stopped | The instance has been shut down. |
Deleted | The instance is deleted. |
Status | Meaning |
---|---|
Initialized | The instance has finished initializing but is not yet functional. |
In progress | Server provisioning is in progress. |
Successful | The instance has started and is ready to be used. |
Failed | Server provisioning failed. Check out the Instance status on the server’s details page for more details. |
Cloud-init scripts
Cloud-init scripts help you speed up the initial configuration of your cloud instances. You can automate tasks such as setting hostnames, configuring networks, installing packages, or running custom scripts during a server's initialization phase.
Nebula supports cloud-init scripts on all available operating systems: Windows Server and Linux, including Ubuntu and CentOS.
Create scripts for Linux
Nebula uses the open-source cloud-init for Linux server instances, enabling you to use YAML
or shell
scripts to customize your server instance during the boot sequence. Take a look at these examples that set the hostname, install basic packages, and log the results:
#cloud-config
hostname: my-server
packages:
- vim
- curl
- git
runcmd:
- echo "Customizing server"
- touch /tmp/custom-init-script-completed
Nebula supports both user-data scripts and cloud-config data scripts.
User-data scripts
User-data scripts, such as shell
and python
scripts, can be used for custom configurations. The script is executed only once, when the instance is started for the first time: after the status of the server changes to Running, and before /etc/init
is executed.
You need to follow these constraints when configuring user-data scripts:
- The first line must start with
#!
, for example:#!/bin/bash
or#!/usr/bin/env python
- No spaces are allowed at the beginning.
- When a script is started for the first time, it will be executed at the
rc.local
-like level. This indicates a low priority in the boot sequence. - The file size of the script cannot exceed 32 KBs.
You can view the customized user data injected into a Linux instance via these steps:
Log in to the server
As
root
user, run this command to view the user-data script applied to the instance:curl http://{server_ip}/openstack/latest/user_data
Replace
{server_ip}
with the IP address of your server.
Cloud-config data scripts
Cloud-config methods pre-defined in cloud-init, such as the yum
repository and SSH key
are used to configure certain compute applications.
Cloud-config data scripts are executed with a frequency based on the applications configured on your server instance.
You need to follow these constraints when creating cloud-config data scripts:
- The first line must be
#cloud-config
. - No space is allowed at the beginning.
- The file size of the script cannot exceed 32 KBs.
Create scripts for Windows
Custom user-data scripts on Windows Server instances are based on the open-source cloudbase-init architecture. This architecture uses the compute metadata as the data source for initializing and automatically configuring servers. Take a look at these examples that write a simple message to an output file:
rem cmd
echo "Hello, BAT Test" > C:\1111.txt
Both batch scripts and PowerShell scripts are supported.
Batch scripts
You need to follow these constraints when configuring batch scripts:
- The first line must be
rem cmd
. - No space is allowed at the beginning.
- The file size of the script cannot exceed 32 KBs.
PowerShell scripts
You need to follow these constraints when configuring PowerShell scripts:
- The first line must be
#ps1
. - No space is allowed at the beginning.
- The file size of the script cannot exceed 32 KBs.
You can view the customized user data injected into a Windows instance via these steps:
Log in to the server
As
root
user, run this command to view the user-data script applied to the instance:curl http://{server_ip}/openstack/latest/user_data
Replace
{server_ip}
with the IP address of your server.
Use cloud-init scripts
You can use cloud-init scripts during the server creation flow.
To ensure that your cloud-init scripts function properly, your server needs to be configured:
- You need to set up a VPC. All VPCs have DHCP enabled by default, which is required for cloud-init scripts.
- You must define a security group that allows outbound traffic on port
80
.
Once these requirements are met, upload your cloud-init script file and launch your server. And you're done! The rest is managed automatically by Nebula.
Cloud-init script errors
Nebula does not validate, compile, or interpret the cloud-init scripts you upload in any way or form.
We recommend that you test your scripts locally before using them to configure a server.
Errors in a cloud-init script can impact your server creation and configuration process. The impact of an error can be critical or non-critical:
Critical errors
When an integral part of the server configuration fails, the instance might be unable to fully initialize or might encounter issues during the boot sequence. For example:
- The cloud-init script might be unable to set the hostname, network configuration, or SSH keys, leading to potential access issues.
- A failure in network-related configurations may result in the instance being unable to reach external repositories for package installations.
In some cases, the server instance may appear as stuck or not fully functional. Situations like these might require manual intervention to fix the issue.
Non-critical errors
If an error is non-critical, the cloud-init script will typically proceed with the rest of the initialization. The instance may continue the boot sequence, but the affected component (such as a service or configuration change) may not be properly set up. For example:
- If a package installation fails, Nebula logs the error and continues the setup process.
Cloud-init script logs
Nebula provides detailed logs to help you diagnose and troubleshoot issues. These logs can be found on every instance after boot-up. Check these logs immediately after failures to identify specific error messages and pinpoint the cause of failures.
Linux logs
In Linux environments, cloud-init logs are usually stored in these locations in all instances:
- Primary log of the cloud-init script execution:
/var/log/cloud-init.log
- The output of user-data scripts:
/var/log/cloud-init-output.log
Windows logs
In Windows instances, you can find cloud-init logs in these locations:
- Primary log of the cloud-init script execution:
C:\ProgramData\Cloudbase Solutions\Cloudbase-Init\logs\cloudbase-init.log
- The output of user-data scripts:
C:\ProgramData\Cloudbase Solutions\Cloudbase-Init\logs\cloudbase-init-output.log
Error handling in your scripts
You can add error handling directly within your own cloud-init scripts. Handle specific cases gracefully and ensure that an error doesn't prevent the entire script from executing.
Linux: Ubuntu and CentOS examples
Add set -e
in shell
scripts to halt execution on the first error, or use || true
to ignore errors for non-critical commands:
#!/bin/bash
set -e # Exit on first error
# Install a package, and continue even if it fails
yum install -y vim || true
# Some other critical task
hostnamectl set-hostname my-server
Windows examples
Use Try
and Catch
blocks to catch exceptions when an action you defined fails:
try {
# Attempt to install a feature
Install-WindowsFeature -Name Web-Server
}
catch {
Write-Host "Error: Failed to install the Web-Server feature."
exit 1 # Exit with error status
}
Need help?
If you have any technical questions or encounter any problems, get in touch with our Support team! We are here to help, and will provide support if you encounter any issues with NebCompute.