Best Practices
Here you can find best practices for configuring and using CodeCanvas.
tip
TLDR: Always use warm-up snapshots to reduce costs and improve startup time.
You can significantly reduce the time it takes to start a dev environment by removing the IDE warm-up phase: a period of time when the IDE builds indexes, resolves project dependencies, and so on. To do this, you can use the CodeCanvas warm-up feature. During the warm-up, CodeCanvas creates a dev environment where it runs the IDE and performs all the necessary background activities (e.g., builds the project). The result of the warm-up is a snapshot of the dev environment that includes all the indexes and other data. The snapshot itself is stored in a cheap storage, like Amazon S3.
Warm-up snapshots are an ultimate way to optimize resource usage, as they remove the computational overhead of the warm-up phase from multiple user dev environments. E.g., you can configure creating a warm-up snapshot every day at 3 AM to ensure that the users who start their dev environments at 9 AM receive a pre-warmed environment with the indexes that include all the changes made during the last day.
tip
TLDR: If you use the standby pool, keep the number of dev environments in it to a minimum and consider using the auto-stop feature.
The standby pool is a set of already started dev environments. As all preparations are done, the dev environments in the standby pool are ready for immediate use. When a user requests a dev environment, CodeCanvas assigns them a free dev environment from the standby pool. After the environment is assigned, the pool creates a new dev environment to keep the number of available dev environments at the desired level.
Of course, the standby pool consumes resources, so you should carefully configure it to match your needs. Here are some tips:
Minimize the number of dev environments in the standby pool to save resources: Run the pool only during the peak hours, e.g., when most of the users start their workday. People don't start their workday at the same time, so, typically, it is enough to have a few dev environments in the standby pool. For example, if you're a medium-sized team that starts working at 9 AM, you can have 2–3 dev environments in the pool that runs from 8:45 AM to 10 AM.
Use the auto-stop feature: You can configure the standby pool, so that the dev environments in it are stopped right after all startup activities are done. This way, you save resources by not keeping the dev environments running when they aren't used, but still provide a decent startup time.
tip
TLDR: Use cleanup policies to prevent the accumulation of unused resources and reduce costs.
Delete unused dev environments
Once a dev environment is stopped, CodeCanvas deletes it and frees all the resources except for the dev environment volume. As the volume is stored in a block storage, this entails additional costs. To avoid these costs, you can configure the maximum period of inactivity after which the dev environments are considered unused and can be deleted, i.e., their volumes can be deleted.
Convert dev environment volumes to snapshots
Instead of deleting the dev environment volumes, you can convert them to snapshots. Snapshots are stored in a cheap storage, like Amazon S3, and don't consume resources. You can configure the maximum period of inactivity after which the volumes are considered unused and can be converted to snapshots.
Delete unused warm-up snapshots
Warm-up snapshots are stored in a cheap storage, like Amazon S3. However, they still consume resources. To prevent the accumulation of unused snapshots, you can configure the maximum period of inactivity after which the snapshots are considered unused and can be deleted.
tip
TLDR:
Use the dev container image to install tools.
Use the warm-up script for tasks that require the IDE or project sources, e.g., building the project or downloading dependencies.
Use the On activation script for tasks that require user context, e.g., logging into a Docker registry.
Use the On initialization script to customize the IDE.
When configuring a dev environment template, it is important to understand where to place specific preparation steps: in the dev container image, the warm-up, or the lifecycle scripts. For example, your project requires an SDK. To get the SDK, you run curl - o sdk.zip $SDK_URL && unzip sdk.zip. Where do you put this command: to the Dockerfile, the warm-up script, or one of the lifecycle scripts?
Our recommendations:
The key idea is to run the preparation tasks as rarely as possible. For example, dev container image build is a one-time operation, unlike warm-up, which runs on a schedule. Warm-up, in turn, runs less often than dev environment activations. Below are the limitations and suggestions for each phase.
Dev container image
Install all necessary tools during the build phase of the image – Everything that doesn't depend on the IDE or the project sources (as they aren't available at this stage). This reduces warm-up time, infrastructure costs, and web traffic usage. So, the answer to the question above is: put the
curl - o sdk.zip $SDK_URL && unzip sdk.zipcommand to theDockerfile.Warm-up script
CodeCanvas runs the warm-up script when creating a warm-up snapshot for a specific dev environment template (typically, on a schedule). All dev environments created from the snapshot use the same script results, which saves setup time. The warm-up script runs inside a dev environment container: It has all the tools from the dev container image, the IDE, and the project sources.
Use the warm-up script for tasks that require the IDE and project sources, such as building the project, downloading dependencies, performing code generation, or indexing the source code. Note that the warm-up script doesn't have access to the user context.
Lifecycle scripts
On activation – Use it for tasks you want to run every time a dev environment is activated, like logging into a Docker registry or tracking work time. Keeping this script lightweight and fast is best to avoid delaying the user's connection to the IDE. Since this script runs in the specific user's context, it can access and use personal parameters.
On initialization – Use it to customize IDE settings, such as installing plugins from custom sources or modifying JetBrains IDE XML configuration files at the application or project level. This script runs once, either during the warm-up or the dev environment creation (if the warm-up wasn't used).
tip
TLDR: Start with the initial resource estimation, perform an initial warm-up, and apply an iterative approach. Allocate more RAM than the estimated consumption to prevent OOM errors.
Start with the initial resource estimation:
Start with your best estimates for memory and disk space requirements. Consider peak usage during IDE indexing and project builds. Learn how to define instance types.
Use a custom Docker image tailored to your project to optimize resource usage and memory footprint. Learn more.
Perform an initial warm-up to build indexes and compile the project. This helps simulate potential resource usage. Learn more.
Apply an iterative approach: Monitor resource usage and adjust the instance types accordingly. Dev environments log a notification when memory usage exceeds 80%.
tip
No swap: We don't recommend enabling swap space in Kubernetes clusters due to complex configuration, potential performance impacts, and other issues. Instead, allocate more RAM than the estimated consumption to prevent OOM errors.
Thanks for your feedback!