Servers
A server represents a deployed node at an infrastructure provider managed by Cycle.
Servers on Cycle run CycleOS, and have compute software fully managed by the platform.
Server Basics
Servers are deployed to clusters, and run containerized workloads. Servers must be deployed via Cycle - servers deployed manually via a provider (such as EC2) cannot be connected back to Cycle.
Cycle automatically builds and manages the network interfaces between servers within a cluster. No manual networking should be necessary to have containers communicate between servers, datacenters, or cloud providers.
Server Hostname
The server hostname is a publicly resolvable hostname created and used by the platform.
Server Storage
Base Volumes
A server's base volume is where downloaded container images are stored.
A server's base volume size can be increased after the server is deployed, but can never be decreased. The default size for base volumes is 30GB.
Shared Mounts
Shared mounts can be configured to mount a remote file system to the host, such as an NFS Mount .
One such use-case would be mounting an NFS mount through EFS on AWS.
Shared Directories
Shared directories allow the sharing of a host directory between multiple container instances running on the server simultaneously.
Shared directories consist of an identifier that can then be referenced in the container integration settings to mount the directory into a container. Files written to a shared directory will be visible to all container instances on that host with the directory mounted.
Enable SFTP Access
Container volumes on Cycle support remote access. However, for remote access to be explicitly opted into for each server, due to the increased security risk of exposing the port required for SFTP.
Learn more about setting up remote access for container volumes through the portal.
Overcommitting
Cycle sets the value of a CPU share to be 10 shares per core., and the platform considers a server to be 'out of resources' once the total number of shares is exceeded, preventing new instances from being deployed to that server.
This can be artificially restrictive, especially when the workload of the container instances is well-known, or the instance won't be utilizing 100% CPU at all times. To make this system more flexible, Cycle allows for setting a server's overcommit ratio. The ratio is a multiplier for the number of cores available on the server. For example, a server with 4 cores and an overcommit of 2x will look like an 8 core server, thus effectively doubling the number of shares available on the server.
Server Tags
Server tags are a way to fine-tune container instance deployments. In conjunction with a deployment strategy, server tags can be used to, for example, only deploy to servers with an attached GPU, or to ensure instances only go to servers in a particular region.
When a server is created, Cycle will generate some tags for it automatically. Usually, these will include tags about the provider, location, and architecture. Unlimited additional tags can be created for each server as well.
When deploying a container, instances can be restricted to servers that have at least one or all of the specified tags, for highly customizable deployment strategies.
Allow Pool
To allow instances without any server tags specified, the allow pool option must be set to true for that server to be a valid target.
Allow Services
Servers can opt in or out of being a deploy target for environment services.
Server Console
To view server level output from CycleOS, the server console is made available in the Portal and API. It stores 128KB of logs that persists between restarts.
The server console is exposed via websocket. When accessing manually via API, credentials must first be generated to successfully connect.
Server Restarts
A server can be told to restart manually from Cycle. When a restart is issued, all container instances running on that server will be offline for the duration of the restart.
Forced Restarts
Cycle will never force restart a server, even when a critical OS update is released. To get the latest OS updates, a manual restart must be done by a member of the hub.
To manage server and compute software restarts, see one of the guides below:
Evacuate Server
The evacuate server functionality is meant to be used when migrating services from one server node to another. The platform will not make checks for space, tag matches, or other safety type checks when migrating these instances. Container instances migrated will automatically stop, migrate, and start (or go back to their desired state) after migration.
Like with any container migration, stateful instances are marked with a purge timer after migrating. To force delete the server which has been migrated from, use the force delete functionality.
Load Balancers
Because evacuate can happen between providers, if a load balancer that the user would like to replace exists on the server, that load balancers will need to be manually deleted and recreated. This is because the public IP cannot necessarily be migrated.
Deleting Servers
Servers on Cycle cannot be deleted unless all instances running on that server have been deleted or moved. This can be overridden by forcing a delete. When this option is selected, all instances on the server will be deleted, and then the server will be as well.
Caution
A server must never be deleted directly from a provider (AWS, GCP, etc). Doing so may get the server into an unrecoverable state on Cycle and cause issues within the hub.
Deploy Containers on Cycle
Follow one of our interface-specific guides to deploy servers on Cycle: