High Level Look - Cycle Environments
As we continue our high-level dive into different Cycle components and detailing how they work, today we’re taking a look at Environments. A core piece of how Cycle works, environments are critical to the platform as they provide discovery / load balancing services, isolation, and other valuable features to containers. These environments can span multiple servers across multiple providers, and automatically build and maintain all necessary networks.
For simple projects, generally, a user will deploy the complete application into a single environment, as shown in the illustration above. More advanced users may want to segment their products/services over multiple environments for more granular control. It’s important to note that containers in one environment have no concept or communication with containers in other environments unless an SDN (software defined network) is attached to both environments.
Let’s take a look at some more details about environments:
Referencing the illustration above again, you can see that all the containers in an environment are connected via a private network, yet the load balancer also has a connection to public traffic.
The private network is established by Cycle through the use of vxlan networks which are created across the necessary servers in your cluster. If you’re not familiar with vxlan, don’t worry - you’ll never have to configure this setting, it’s handled automatically by Cycle.
By default these networks utilize IPv6, and each container receives a /96 private network address space. Enabling legacy mode, during environment create, will also create a /16 on the 10.x IPv4 subnet.
All hostname lookups on the private network are handled by the environment discovery service.
Public network requests are all routed through the Load Balancer, which is able to handle TCP passthrough by port or HTTP routing via domain and port combinations.
Due to the nature of the environment services, you can assign host:container ports mappings such as 80:80 and 443:80 to as many containers as you’d like within the environment as each container will get its own IP on the private network giving it access to the full range of available ports per instance.
The VPN service allows users to extend the private network to their local machines or any machine capable of authentication to an OpenVPN client.
No environment would be complete without user containers. Users can add individual containers to an environment or use a stack build on create to deploy multiple containers at once, with the option to control more granular configuration settings on deploy. Containers and stacks can also be deployed to environments using the API.
User containers can be scaled, migrated, debugged, reconfigured and more easily within the portal. Each environment can adapt dynamically to changes being made to individual containers and rarely does an environment need to be restarted for a change to take place.