Using your own servers with Cloud 66
About registered servers
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.
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 on any stack!
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.
Cloud 66 Toolbelt
You can run the command below to register your servers using the 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=188.8.131.52 --user=root --tags="dc-1,az US"
- OS: We currentlu 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 currently only support deploying to 64bit CPU architectures.
- Once a server is registered and used, it cannot be reused until a fresh copy of Ubuntu is installed again - this is to prevent possible conflicts with old files. When a 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 Cloud 66. Open at least TCP port 80, 443 and 22 to the outside world. Cloud 66 install a firewall on each box that is blocking port 22. All servers must be allowed to communicate inside the security group on TCP port 6783. Port 6783 is needed to create the overlay network (Weave) for Docker applications.
- If your servers in a 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.
- Detecting server’s private IPs are very difficult as there might be more than one, so we cannot decide which one should be used -hence all the connections are going to be via Public IPs