Container Configuration

Modify how your container is deployed, run, or scaled. Cycle's commitment to simplicity does not mean sacrificing customizability. Nearly every aspect of how a container is run, from it's deployment tags to resource limits, are configurable.

Accessing Container Config

To get to the container config, follow these steps:

  1. Click the Environments tab on the navigation menu to the left.
  2. Select the environment the container instance you want to access is in.
  3. Click the Containers tab under the environment name.
  4. Select the container from the list.
  5. Click the Config tab under the container name.

Use the tabs on the left to navigate to different sections of the config. Feel free to modify multiple config settings between tabs before clicking "Save & Restart" Some sections of the config may be disabled, meaning none of the settings underneath will take effect. To enable it, make sure the toggle in the top right of the form is set to "Enabled"

Changing the configuration of a running container will cause it to restart!

Networking

Hostname

The hostname is how other containers identify this container within the network.

Updating the hostname will restart all instances of the container. Discovery will automatically be informed of the new name and will not need to be restarted.

Public Network

There are three types of network privilege a container can have:

  • Disabled - Public internet access is completely disabled for this container. It may only communicate with other containers within the same environment. This is ideal for sensitive things, such as databases.
  • Egress Only - The container may initiate connections over the internet, but all incoming connections will be blocked. This is ideal for things that require fetching data from the web, but do not need to respond to inbound requests, such as web scrapers.
  • Enabled - The container is able to both start and accept connections over the internet. This is a must for websites, APIs, and other services where clients may not be known ahead of time.

Port Mappings

Only the ports specified are exposed on the host (for that container's specific IP). The format is [container]:[host], meaning Cycle will expose route traffic to the host port to the container, and map it to the internally to the container port (the one your application will read). For example, 3000:80 will accept connections on port 80, but your application will serve over port 3000.

Name Servers

Override default name servers for your container by setting them here. All DNS lookups will go through the specified IP addresses rather than Google's (8.8.8.8).

Runtime

The runtime configuration specifies the how a container starts, information it has access to, and permissions it has on the host. It needs to be enabled for the settings underneath to have an effect.

Environment Variables

Cycle automatically populates environment variables defined on the container image, but allows you to change the values or add completely new variables. These can be accessed within the container in your code.

Some environment variables are always created, regardless of the image. Below is a full list of those values.

NameDescription
CYCLE_INSTANCE_IDThe ID of the instance.
CYCLE_SERVER_IDThe ID of the server this container is deployed to.
CYCLE_CONTAINER_IDThe ID of the container.
CYCLE_CONTAINER_IDENTIFIERAn identifier used for this container.
CYCLE_ENVIRONMENT_IDThe ID of the environment this container is deployed in.
CYCLE_LOCATION_IDThe location of the server that this container is deployed to.
CYCLE_PROVIDER_IDENTIFIERAn identifier that indicates the provider of the server.
CYCLE_PROVIDER_LOCATIONThe physical location of the server displayed as an abbreviation.
CYCLE_COMPUTE_PROXYThe Cycle compute proxy url.
CYCLE_FIRST_STARTIf this is the first time an instance starts this value will be yes, after that it will be no.

Environment variables defined on the image cannot be removed. Cycle interprets these as critical to the way your program works. However, their values can be changed, which may be useful for things such as specific development-only settings. You are free to create and remove environment variables outside of those defined on the image.

Command

  • Path - Set an override to the default command run when the container starts. May be useful if you have a custom debug command you wish to run.
  • Args - Any arguments you wish to pass into the overidden path.

Privileges

These settings define exactly what privileges the container has on the host.

Changing these settings can open you up to security vulnerabilities. Do so at your own risk.
  • Namespaces - Namespaces define what is isolated in the container, and what is used on the host. The fewer namespaces a container has, the less secure it becomes. By default, a container has all namespaces enabled. At the least, they must have the MOUNT namespace. See here for detailed descriptions of the available namespaces.
  • Privileged Capabilities - You can granularly assign specific kernel-level capabilities to a container for extra functionality. These can lead to interesting use cases, for example adding the CAP_NET_RAW capability, and building a containerized network monitoring dashboard. See here for detailed descriptions of the available kernel capabilities.
  • Run as Fully Privileged - This is by far the most dangerous option available to you. This gives the container full permissions on the host, treating it as a root process.There is almost no reason to do this, and you will most likely break something. If you feel there is a reason to do this, reach out to our support team. We'll help you find a better way.

Scaling

Feature Alert
At the moment, Cycle's scaling options are purposefully limited. We are in the process of adding more granular options.

Scaling refers to how many and where container instances are started. There are many different ways applications can be scaled, including geographic and load based scaling. Cycle's current scaling solution, while basic, is the foundation to more complex and powerful scaling we will be implementing over time.

Select the minimum and maximum number of instances, and Cycle will start that many instances, balanced across all servers matching your deployment tags.

Resources

If you're coming from the VM world, you are probably used to resource allocations, where you set aside a chunk of RAM, storage, CPU time, etc that can only be utilized by that VM. In the container world, we set limits.

By setting limits, you're able to overcommit your container resources, and as long as all containers aren't maxing out, get top performance out of them. On Cycle, you can set both the limit and a reserve (allocation), if you need to guarantee a floor of resources to be available for a critical piece of your application.

CPU

Both the limit and reserve of the CPU can be set to eithe "cores" or "seconds". Cores, as you'd expect, are the number of CPU cores a container can utilize. Seconds are a bit more complicated, but refers to how much processing time the container can take up per 1 second of CPU time. If you have a 1 core CPU, setting this value to 1 means the container can utilize 100% of the CPU. On a 4 core CPU, 100% would be 4 seconds, and so on.

Both of these values can be set to fractional numbers, i.e 0.5 cores or 0.1 seconds.

In addition to the limit and reserve, Cycle also supports CPU pinning. Setting this option will force your container to run only on the specified cores. If you want to guarantee a mission critical container can always run, pin it to CPU cores.

RAM

RAM is very straightforward - limits and reserves are set in KB, MB, GB etc. In addition, you can define the swappiness of your container's RAM usage. Swappiness defines how much (and how often) your container will copy RAM contents to swap. This parameter's default value is "60" and it can take anything from "0" to "100". The higher the value of the swappiness parameter, the more aggressively your container will swap.

Deployment

This section refers to how your containers are deployed.

Initial Instances

The initial number of instances are set on container create, and are here for reference. To adjust the current number of instances, please refer to the scaling section.

Deployment Tags

In short, deployment tags give you the power to match container instances to servers that meet the criteria.

If left blank, Cycle will deploy instances to any available servers until the 'Initial Instances' quota has been met.

Options

Cycle can be configured to auto-restart your container if it detects the process has died. You may also specify who to email on restart, and if Cycle should call out to a webhook.

The max restarts field refers to how many times Cycle will attempt to "resuscitate" your container, and the delay is how many seconds between attempts the platform will wait. By default Cycle will attempt to restart your container 15 times, after this point manual intervention is necessary.

Need Help?

If you've got questions about the platform or need some help getting started, our team is more than happy to assist. Whether you're new to containers or just new to Cycle, reach out to us via livechat by clicking the blue circle in the bottom right corner. Join our Slack channel, and get help from the dev team or other members of the community, and check out our Roadmap to see what's planned for the future!