daytonaio / daytona

Infrastructure Agnosticism

Daytona is designed to operate on diverse infrastructure. This means you can run Daytona on different cloud providers (AWS, GCP, Azure), on-premise hardware, or even within a virtual machine. This flexibility is achieved through Daytona’s infrastructure agnostic design.

Here’s a breakdown of the key design principles and how they enable Daytona’s adaptability:

1. Configuration Management

Daytona leverages configuration files to manage its infrastructure dependencies. These files define parameters like:

  • Cloud provider: Specify the target cloud provider (e.g., AWS, GCP, Azure).
  • Region: Define the geographical region where resources will be deployed.
  • Network configuration: Configure network settings like subnets and security groups.
  • Storage configuration: Manage storage resources like buckets and volumes.

Example:

# example_config.yaml
          cloud_provider: aws
          region: us-east-1
          vpc_cidr: 10.0.0.0/16
          subnet_cidr: 10.0.1.0/24

Reference:

2. Provider-Specific Implementations

Daytona uses a plugin-based approach to handle provider-specific operations. Each cloud provider has a dedicated plugin that implements the necessary functions.

Example:

  • An AWS plugin might be responsible for creating AWS instances, S3 buckets, and other AWS resources.
  • A GCP plugin would handle creating GCP instances, Cloud Storage buckets, and other GCP resources.

Reference:

3. Abstraction Layer

Daytona’s core logic interacts with an abstraction layer that hides the underlying provider implementation. This allows Daytona to function independently of the specific cloud provider.

Example:

  • When Daytona needs to create a virtual machine, it communicates with the abstraction layer. The abstraction layer then delegates the request to the appropriate provider plugin based on the configuration settings.

Reference:

4. Extensibility

Daytona’s plugin system allows developers to add support for new infrastructure providers without modifying the core codebase. This ensures that Daytona remains adaptable to future technologies.

Example:

  • To support a new cloud provider, a developer would need to create a plugin that implements the necessary functions and register it with Daytona.

Reference:

5. Server Configuration

Daytona’s server configuration (pkg/apiclient/docs/ServerConfig.md) defines various settings related to the server’s operation. These settings include:

  • API port: Defines the port on which the Daytona API server listens.
  • Binaries path: Specifies the location of Daytona’s binaries.
  • Registry URL: Defines the registry server used for storing Daytona images.
  • Builder image: Specifies the container image used to build Daytona projects.

Example:

# server_config.yaml
          api_port: 8080
          binaries_path: /usr/local/bin/daytona
          registry_url: registry.example.com
          builder_image: daytonaio/builder:latest

Reference:

6. Project Configuration

Daytona projects use configuration files (pkg/apiclient/docs/ProjectConfig.md) to define project-specific settings. These settings include:

  • Repository: Defines the Git repository containing the project source code.
  • Image: Specifies the container image used for the project.
  • Default: Indicates if the project is the default project.
  • BuildConfig: Defines the build configuration for the project.

Example:

# project_config.yaml
          repository: [email protected]:daytonaio/example-project.git
          image: daytonaio/example-project:latest
          default: true
          build_config:
            devcontainer:
              image: daytonaio/devcontainer:latest

Reference:

These design principles contribute to Daytona’s ability to operate on diverse infrastructure, providing developers with greater flexibility and choice in their development environments.

Top-Level Directory Explanations

pkg/ - Go packages directory.

pkg/views/ - Subdirectory for view templates.