Using your own servers with Maestro
Registered servers are a great way for operations teams to manage and allocate physical server resources for consumption by dev teams. Registered servers are essentially a pool of your own servers on a private or public cloud that can be used on any application and configuration.
Applications can be deployed across a hybrid of cloud and registered servers. In this way you could have, for example, a dedicated server for your database and use burst cloud servers for your front end.
Check your firewalls
Any firewalls or security systems that protect to your servers will need to be configured to work with Cloud 66's specifications (see below).
Register a server
You can add any physical server as a registered server using the website, or the Cloud 66 toolbelt as long as it meets certain criteria.
Via the Dashboard
Visit the Registered Servers page on Cloud 66, which will provide with you a shell script to run on your server - you can download it to inspect it first.
Once the shell script has successfully completed, the server will now show up in the New Servers list for you to approve. Once it is approved, it will be available for you to use with any application!
The script generated by the URL is dynamic and is time sensitive, so you can't save the script itself on your server.
Using Cloud 66 Toolbelt
You can run the command below to register your servers using Toolbelt:
$ cx register-server --org="My Team" --file=servers_file --user=root
To register a single server, use the
server flag with the IP address, and to bulk register, provide a text file with the
file flag with one IP address per line.
To add tags to the registered servers, use the
$ cx register-server --org="My Team" --server=184.108.40.206 --user=root --tags="dc-1,az US"
- For Kubernetes (Maestro) clusters, we strongly recommend that your servers meet these mininum specs to be able to handle the additional load required by the platform.
- Operating system: We currently support Ubuntu 18.04 and Ubuntu 20.04. The OS needs to be freshly installed on your server.
- Connection: For security reasons, Cloud 66 only connects to your server using your secure keys on port 22.
- Sudo: As Cloud 66 connects to your server and provisions applications from scratch, administrator permissions are sometimes necessary. Therefore our script creates a new user to use for deployment that is a member of the sudoers group and that does not require a password to invoke sudo.
- Bash: We currently only support Bourne-again shell (Bash). The error
sh: n: source: not foundduring deployment may arise if you are not using the Bash shell.
- CPU Architecture: We only support deploying to 64-bit machines.
- Firewalls & security: Cloud 66 needs the following (TCP) ports open to allow us to deploy and manage your application:
3022set to allow access from
220.127.116.11(this IP is static)
For more detail please read our guide to Using Cloud 66 through firewalls.
If your application needs to accept connections from the public web you will also need to open ports
443 but we do not require that these be open in order for us to manage a server.
If your server is in a cloud with native security groups (such as AWS Security Groups) then you must manually configure them such that your registered servers are able to talk to each other and Cloud 66 via the ports listed above.
All servers must be allowed to communicate inside the security group on TCP port
6783, which is needed to create the overlay network (Weave) for CSv1 applications.
Do not configure servers manually
Cloud 66 has a number of features that systematize and automate server configuration. Manual changes to configuration files and settings on servers and components are very likely to be either overwritten or cause conflicts.
Once a server is registered and used, it cannot be reused until a fresh copy of Ubuntu is installed. This is to prevent possible conflicts with old files.
When an application with Registered Servers is deleted, the Registered Servers will appear in the Orphaned Servers list on your Registered Servers page. This list is here to allow operators to see which servers need to be destroyed/reset. Once a server is destroyed/reset it can be manually removed from the Orphaned Servers list.
If the servers running an application are in different regions, then they will not be able to use their internal IPs to communicate with each other, so you will have to change your app to use the external IP environment variables. Keep in mind that this may incur additional traffic costs.
Existing BYOS users will now be able to scale up and add a load balancer via registered servers.
Cross-cloud applications are now possible, but not recommended due to substantial latency and other potential issues.
Accurately detecting a server’s private IP is very difficult as there is often more than one - hence all the connections are via public IPs