To get to the container config, follow these steps:
- Click the Environments tab on the navigation menu to the left.
- Select the environment the container instance you want to access is in.
- Click the Containers tab under the environment name.
- Select the container from the list.
- 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"
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.
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.
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.
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.
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.
|CYCLE_INSTANCE_ID||The ID of the instance.|
|CYCLE_SERVER_ID||The ID of the server this container is deployed to.|
|CYCLE_CONTAINER_ID||The ID of the container.|
|CYCLE_CONTAINER_IDENTIFIER||An identifier used for this container.|
|CYCLE_ENVIRONMENT_ID||The ID of the environment this container is deployed in.|
|CYCLE_LOCATION_ID||The location of the server that this container is deployed to.|
|CYCLE_PROVIDER_IDENTIFIER||An identifier that indicates the provider of the server.|
|CYCLE_PROVIDER_LOCATION||The physical location of the server displayed as an abbreviation.|
|CYCLE_COMPUTE_PROXY||The Cycle compute proxy url.|
|CYCLE_FIRST_START||If 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.
- 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.
These settings define exactly what privileges the container has on the host.
- 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
MOUNTnamespace. 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_RAWcapability, 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 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.
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.
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.
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 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.
This section refers to how your containers are deployed.
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.
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.
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!