By default, the Helion Stackato VM starts as a single-node "micro cloud" with a base set of roles already running and ready to use. This can be used as a test bed for pushing applications still in development. If your program deploys successfully to a Helion Stackato micro cloud, it will deploy to any Helion Stackato deployment of the same version. The application hosting environment is the same in all aspects except scale.
This section describes running the Helion Stackato VM as a micro cloud. To get started building a cluster, see the Cluster Setup section.
Download a Helion Stackato VM in the hypervisor format of your choice or use the latest Helion Stackato image on Amazon EC2.
Host system requirements:
The Helion Stackato VM requires at least 3GB of RAM to run (4GB recommended). Ensure that there is sufficient memory remaining on the host system to run the operating system and any other applications you require.
The steps for importing and starting the Helion Stackato VM will vary depending on which hypervisor and OS you are using. Follow the steps in the relevant guide below, then continue with Initial Configuration:
On first boot, the Helion Stackato VM generates a hostname in the form
stackato-xxxx.local which is displayed on the hypervisor console. It
receives its IP address via DHCP and broadcasts the generated hostname
on the local subnet via multicast DNS.
The default password for the
stackato system user is
stackato. This password is changed automatically when you set up
the first administrator in the Management Console.
Once you have set up the primary Helion Stackato admin account, use that
account's password when logging in at the command line.
The VMware and VirtualBox start virtual machines with NAT networking enabled by default.
If you are using VirtualBox to run the Helion Stackato VM, configuring "Bridged" networking before starting the VM is the simplest way to set it up. If you need to run in "NAT" mode, configure port forwarding as per the VirtualBox documentation.
Bridged networking exposes the VM through the hypervisor host system to your local network. This makes it easier to connect with Helion Stackato servers running on other hosts, but should only be done on trusted networks.
NAT networking exposes the VM only to the host system (unless routing through the host is configured). This is a preferable configuration if you are operating on an untrusted network.
Multiple hosts broadcasting the same name via mDNS on the same network can cause confusion and network problems. If you plan on running multiple Helion Stackato micro clouds on one network:
By default, the Helion Stackato VM broadcasts its generated hostname via
multicast DNS. This mDNS/DNS-SD broadcast address (for example,
stackato-xxxx.local) is intended for micro clouds running on a local
machine or subnet. To use the VM on a remote subnet, the server may need
one or more of the following:
See the Detailed Configuration section for instructions on setting up the Helion Stackato VM in these situations.
Windows does not properly support mDNS hostname resolution. You will
need to use the
xip.io service, update the Windows hosts file, or create a DNS record in order to target the API
endpoint, push applications, and resolve the deployed applications.
The Management Console is the web interface of Helion Stackato.
When the Helion Stackato server finishes the start-up process, the hypervisor's tty console will display the URL of the Management Console. Enter this URL into your web browser.
The SSL certificate for the Helion Stackato Management Console is self-signed. You will need to manually accept this certificate in your browser. See the HTTPS section of the Admin Guide for information on using your own certificate.
The Management Console will load, and you will be prompted to create the first administrator (and the first organization) for the system. Use these account credentials to push applications, create additional users, and configure the system.
The password you set here will become the new password for the
stackato system user for access via SSH or the hypervisor console.
Each organization has an assigned quota plan that should be changed or edited to reflect the resources available on the VM or cluster.
Before members of an organization can deploy applications, one or more spaces must be added to the organization. The Management Console will prompt for creation of the first space, and subsequent spaces can be created by clicking Add Space in the Organizations view (or the stackato create-space command).
$ stackato add-user <username> [--passwd '<password>']
In order to leave as much memory as possible available for user applications, the micro cloud starts with a number of services disabled by default:
You can enable them individually in the Management Console. Click Admin > Cluster and then click the cog icon, or use the kato role add command.
An administrator's view of the Management Console provides access to most commonly configured system settings, control over the roles that are running on the VM, and views of the system log streams and other metrics.
End users of the system without admin privileges have a more limited view, showing only information for their user or group accounts. Deploying applications and consuming system services is covered in the Helion Stackato User Guide.
The quickest way to set up wildcard DNS resolution is to use the
nip.io service. This service provides wildcard
DNS resolution for addresses with the format:
To change the hostname of the Helion Stackato VM, log in to the VM via SSH or
the hypervisor console (username: 'stackato', default password:
'stackato'), then run
kato node rename with external IP
address and the
xip.io domain appended. For example:
$ kato node rename 10.9.8.7.xip.io
This will change the system hostname and reconfigure some internal
Helion Stackato settings. The xip.io DNS servers will resolve the domain
10.9.8.7.xip.io and all sub-domains to
10.9.8.7. This works for
private subnets as well as public IP addresses.
If you are running Windows, multicast DNS discovery of a locally
running Helion Stackato micro cloud will not generally work. One solution is to
manually set the mapping for the API endpoint and for each application
in the Windows
Using xip.io for hostname resolution is the
easiest way to set up a Helion Stackato micro cloud VM if mDNS is not an
option. Try this method before modifying the
To modify the
hosts file open the
hosts file typically has some comments and one or two entries.
Add your new entries to the bottom of the file on their own lines.
You will need to add an entry for the API endpoint and for each application, along with their corresponding IP addresses. To determine the IP address of the Helion Stackato server, open the server window and enter the command:
Then, if for example the IP address of your Helion Stackato VM is
192.168.68.54, and you have an app with the URL
myapp.stackato-xxxx.local, you would enter the following lines:
192.168.68.54 api.stackato-xxxx.local 192.168.68.54 aok.stackato-xxxx.local 192.168.68.54 logs.stackato-xxxx.local 192.168.68.54 myapp.stackato-xxxx.local
Using the Helion Stackato VM makes no changes to the underlying host operating system.
If you wish to remove it, select the VM in your hypervisor and click Remove or Delete as appropriate.