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 a dedicated server for your database and burst cloud servers for your front end.
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 not the same 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=22.214.171.124 --user=root --tags="dc-1,az US"
- Operating system: We currently only support Ubuntu 16.04 and it 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.
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 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 Maestro. Open (at least) TCP ports
22to the outside world. Maestro installs a firewall on each box which blocks port
22. All servers must be allowed to communicate inside the security group on TCP port
6783is needed to create the overlay network (Weave) for CSv1 applications.
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