Getting Started Overview¶
Welcome to Kraken Applications! This guide will help you understand the fundamentals of deploying applications using Kraken's infrastructure automation platform.
What You'll Learn¶
In this getting started section, you'll discover:
- How Kraken Applications work
- The anatomy of a Kraken manifest
- How to deploy your first application
- Common patterns and best practices
- Troubleshooting tips
Prerequisites¶
Before you begin, ensure you have:
- Access to a Scale Computing HyperCore environment
- Basic understanding of YAML syntax
- Familiarity with virtualization concepts
- (Optional) Experience with cloud-init for advanced configurations
Core Concepts¶
Kraken Manifests¶
Kraken manifests are YAML files that declaratively define your infrastructure. They specify:
- Virtual machines and their configurations
- Assets like disk images and ISOs
- Network and storage configurations
- Initialization scripts and cloud-init data
Deployment Workflow¶
sequenceDiagram
participant User
participant FleetManager as Fleet Manager UI
participant PubSub as Google Pub/Sub
participant KrakenAPI as Kraken Core API
participant Pulumi as Pulumi Engine
participant HyperCore as HyperCore Cluster
User->>FleetManager: Submit Manifest
FleetManager->>PubSub: Publish Event
PubSub->>KrakenAPI: Process Event
KrakenAPI->>KrakenAPI: Validate Manifest
KrakenAPI->>Pulumi: Execute Deployment
Pulumi->>HyperCore: Provision Resources
HyperCore->>Pulumi: Confirm Creation
Pulumi->>KrakenAPI: Report Status
KrakenAPI->>FleetManager: Update Status
FleetManager->>User: Show Results
Key Components¶
1. Metadata¶
Every manifest includes metadata that describes your application:
2. Assets¶
Assets define external resources like disk images:
assets:
- name: "ubuntu-image"
type: "virtual_disk"
format: "raw"
url: "https://example.com/ubuntu.img"
3. Resources¶
Resources define the actual infrastructure components:
resources:
- type: "virdomain"
name: "web-server"
spec:
cpu: 2
memory: "4294967296"
state: "running"
Manifest Structure¶
Every Kraken manifest follows this structure:
type: Application # Always "Application"
version: "1.0.0" # Schema version
metadata: # Application metadata
name: "app-name"
labels: []
spec: # Main specification
assets: [] # External resources
resources: [] # Infrastructure components
Development Environment¶
For the best development experience, we recommend:
- YAML Editor: Use an editor with YAML syntax highlighting
- Validation: Set up schema validation for immediate feedback via command line or IDE
- Version Control: Track your manifests in Git
- Documentation: Keep README files with your manifests
Common Patterns¶
Template Variables¶
Use template variables for dynamic values:
Resource Tagging¶
Tag resources for organization:
State Management¶
Control VM lifecycle with state:
Next Steps¶
Now that you understand the basics, you can:
- Try the Quick Start - Deploy your first application
- Explore Examples - See real-world use cases
- Read the Specification - Deep dive into the API
- Learn Best Practices - Optimize your deployments
Getting Help¶
If you need assistance:
- Browse Examples for similar use cases
- Review the Specification for technical details
- Open an issue on GitHub
Ready to dive in? Let's start with the Quick Start Guide!