📚 Automation Examples

📋 Table of Contents

Overview
RabbitMQ Automation
Kafka/Strimzi Automation
FastAPI Automation
k6 Load Testing Automation
External Source Code Automation
Image Base Automation
Best Practices
Additional Resources

Overview

This chapter provides real-world examples of service automation and relationships generated by Stacktic. These examples demonstrate how Stacktic automates configurations based on best-practice patterns, creating the necessary resources, documentation, and relationships to support full-stack demands.

Important Notes

⚠️ Scope Notice: These are examples only, not complete automation implementations.
The full automation is generated into your target repository's documentation with all configurations, secrets, and operational procedures.

What Gets Automated

Service	Automated Components	Key Features
RabbitMQ	Exchanges, queues, bindings, users	Message flow configuration
Kafka	Topics, bridges, connectors, sinks	Event streaming setup
FastAPI	Routes, endpoints, documentation	API gateway integration
k6	Test scripts, CRDs, plugins	Performance testing
External Source	Git integration, CI/CD, deployments	Automated builds from source
Image Base	Pre-built deployments, init containers	Direct image deployment

🐇 RabbitMQ Automation

Component Architecture

RabbitMQ automation demonstrates how Stacktic handles message queue patterns with sub-components and relationships.

Sub-Component Creation

You can create sub-components such as:

Exchanges - Message routing logic
Queues - Message storage
Bindings - Flow definitions between exchanges and queues

Relationship Configuration

The link between an exchange and a queue represents the binding configuration:

Generated Configuration

Secret Configuration Example

The automation generates a complete RabbitMQ configuration stored as a Kubernetes secret:

cat k8s/deploy/base/rabbitmq/secret/definitions.json
{
  "vhosts": [
    { "name": "/" }
  ],
  "users": [
    {
      "name": "user",
      "password_hash": "EJBKv6SgKs6UFaLurzia3tPUIxQ/d4NIfwXG0OUWD2ayoCRd",
      "tags": "management"
    },
    {
      "name": "admin",
      "password_hash": "C5pNaWoy+Fb7WeHsIgtP/6DvaimpRJkdo4BQQYlO+yluv0b/",
      "tags": "administrator"
    }
  ],
  "permissions": [
    { "user": "user", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*" },
    { "user": "admin", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*" }
  ],
  "parameters": [],
  "global_parameters": [
    { "name": "cluster_name", "value": "rabbit@my-rabbit" }
  ],
  "policies": [],
  "bindings": [{
    "source": "api-system",
    "destination": "systems",
    "destination_type": "queue",
    "vhost": "/",
    "routing_key": "#"
  }],
  "queues": [{
    "name": "systems",
    "vhost": "/",
    "durable": true,
    "auto_delete": false,
    "arguments": {}
  }],
  "exchanges": [{
    "name": "api-system",
    "type": "topic",
    "vhost": "/",
    "durable": true,
    "auto_delete": false,
    "internal": false,
    "arguments": {}
  }]
}

Additional Configurations

Configuration Type	Location	Purpose
Versioning	Component level	RabbitMQ version management
Resources	Component attributes	CPU/Memory allocation
Security	Component & links	Authentication, TLS, network policies
Monitoring	Auto-generated	Prometheus metrics, Grafana dashboards

📝 Note: Additional configuration related to versioning, resources, and security exists within the RabbitMQ component itself.

🦄 Kafka Automation

Advanced Event Streaming

Kafka Strimzi is a more complex component but follows similar automation principles.

Sub-Component Types

Sub-Component	Purpose	Automation Features
Topics	Event streams	Partitions, replication, retention
Bridges	HTTP integration	REST API exposure
Connectors	External systems	Database sinks, source connectors
Users	Access control	ACLs, authentication

Integration Capabilities

API Gateway Integration

Bridge connects to API gateway
Integrates with OIDC via Keycloak
Automatic authentication setup

Database Integration

Topic sub-components connect to databases for sink operations
Automated Kafka Connect configuration
End-to-end setup including connectors and secrets

Example Resources

Demo Repository

Explore a sample implementation (not full automation):
🔗 Basic Strimzi Setup

Connectors Example

Review automated connector configurations:
🔗 Kafka Connectors

Automated Components

Component	Generated Assets
Kafka Cluster	StatefulSets, services, config
Kafka Connect	Deployment, connector definitions
Schema Registry	Deployment, schemas
Monitoring	JMX exporters, dashboards

⚡ FastAPI Automation

API Development Acceleration

FastAPI automation streamlines API configuration and documentation through intelligent relationship management.

Automatic Configuration

When you connect FastAPI to a queue or database, Stacktic automatically:

Action	Generated Assets
Adds dependencies	Python packages, requirements.txt
Configures routes	API endpoints, middleware
Creates services	Business logic templates
Generates endpoints	GET, POST, DELETE, PUT methods
Documents APIs	OpenAPI/Swagger specs

API Gateway Integration

Connect FastAPI to APISIX API Gateway for production-ready deployment:

Automatic route registration
Load balancing configuration
Health check setup
Rate limiting rules

Validation & Testing

Validate the configuration by testing the FastAPI endpoints and viewing generated documentation:

sub_component for custom API

Stacktic acts as version control for your stack.
You can:

Create your own API on the existing FastAPI service in the main branch.
Modify an existing API.
Or use sub-components to define APIs.

When you add a sub-component, Stacktic automatically generates the API code inside the existing structure.
You don't need to manually touch main—just add the route and basic service definition.

✅ Advantages of Using Sub-Component APIs

Saved as part of Stacktic's version control, making it easy to track changes.
Minimizes direct code editing—no need to manage dependencies or modify main; simply provide the API definition.
Gives Stacktic additional metadata about your logic, enabling smarter automation and insights.

Security Best Practices

🔒 Security Recommendation:
We recommend external authentication instead of relying solely on FastAPI's built-in API key system.

OIDC Integration with APISIX & Keycloak

Use APISIX and Keycloak for enterprise-grade authentication:

Benefits:

✅ Centralized authentication
✅ OIDC/OAuth2 support
✅ Single Sign-On (SSO)
✅ Token-based security
✅ Role-based access control

Configuration Details

Configuration	Level	Description
Versioning	Component	Python version, FastAPI version
Admin Credentials	Component	Initial admin setup
Resources	Component	CPU/Memory limits
Build Image	Link	Required when linking APIs

💡 Build Note: Build image is required when linking APIs to ensure dependency compatibility.

📈 k6 Load Testing Automation

Performance Testing Framework

To quickly assess your stack's performance and scaling configuration, link k6 to any service component.

Automated Test Generation

When k6 is linked to services, Stacktic automatically:

Action	Generated Output
Creates test files	k6 JavaScript test scripts
Builds CRDs	Kubernetes custom resources
Configures plugins	Database, queue, API plugins
Sets up reporting	Metrics collection, dashboards

Example k6 Structure

tree k8s/deploy/base/k6
k8s/deploy/base/k6
├── k6.yaml                    # k6 operator configuration
├── kustomization.yaml         # Kustomize manifest
├── mongodb_collector.yaml     # MongoDB metrics collector
├── namespace.yaml            # k6 namespace
├── secret
│   ├── cloud.env            # Cloud configuration
│   └── registry.json        # Registry credentials
├── test-run.yaml            # Test execution definitions
└── tests
    ├── cnpg.js              # PostgreSQL tests
    ├── kafka.js             # Kafka tests
    ├── mongo.js             # MongoDB tests
    ├── psql.js              # PostgreSQL tests
    └── rabbitmq.js          # RabbitMQ tests

Test Execution Configuration

Sample test-run.yaml

apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: mongo-test
  namespace: k6-operator-system
spec:
  parallelism: 1
  paused: "false"
  quiet: "false"
  script:
    configMap:
      name: k6-test-scripts
      file: mongo.js
  runner:
    image: index.docker.io/asauer/k6:0.0.1-SNAPSHOT
    imagePullSecrets:
    - name: registry-credential
    envFrom:
    - secretRef:
        name: k6-cm
    resources:
      limits:
        cpu: 1000m
        memory: 1Gi
      requests:
        cpu: 250m
        memory: 256Mi
---
apiVersion: k6.io/v1alpha1
kind: TestRun
metadata:
  name: rabbitmq-test
  namespace: k6-operator-system
spec:
  parallelism: 1
  paused: "false"
  quiet: "false"
  script:
    configMap:
      name: k6-test-scripts
      file: rabbitmq.js
  runner:
    image: index.docker.io/asauer/k6:0.0.1-SNAPSHOT
    imagePullSecrets:
    - name: registry-credential
    envFrom:
    - secretRef:
        name: k6-cm
    resources:
      limits:
        cpu: 1000m
        memory: 1Gi
      requests:
        cpu: 250m
        memory: 256Mi

Loading your full stack with single JSON

Add Sub_componenets Endpoints

enter your json URL to the "Load Test Json" attribute. for example:

[
  {
    "url": "https://prod.stack.source-lab.io/",
    "insecure": true
  },
  {
    "url": "https://dev.stack.source-lab.io/",
    "insecure": true,
    "method": "POST",
    "payload": {"key": "value"}
  },
  {
    "url": "https://secure-endpoint.com",
    "insecure": false
  }
]

Execute the tests (k8s/deploy/base/k6/test-run.yaml)

kubectl logs endpoints-test-1-4p7ff  -n k6-operator-system

         /\      Grafana   /‾‾/  
    /\  /  \     |\  __   /  /   
   /  \/    \    | |/ /  /   ‾‾\ 
  /          \   |   (  |  (‾)  |
 / __________ \  |_|\_\  \_____/ 

     execution: local
        script: /test/generic-test.js
        output: -

     scenarios: (100.00%) 1 scenario, 1 max VUs, 10m30s max duration (incl. graceful stop):
              * default: 1 iterations for each of 1 VUs (maxDuration: 10m0s, gracefulStop: 30s)



  █ TOTAL RESULTS 

    checks_total.......: 1       6.352779/s
    checks_succeeded...: 100.00% 1 out of 1
    checks_failed......: 0.00%   0 out of 1

    ✓ status OK

    HTTP
    http_req_duration..............: avg=26.3ms   min=26.3ms   med=26.3ms   max=26.3ms   p(90)=26.3ms   p(95)=26.3ms  
      { expected_response:true }...: avg=26.3ms   min=26.3ms   med=26.3ms   max=26.3ms   p(90)=26.3ms   p(95)=26.3ms  
    http_req_failed................: 0.00%  0 out of 1
    http_reqs......................: 1      6.352779/s

    EXECUTION
    iteration_duration.............: avg=157.29ms min=157.29ms med=157.29ms max=157.29ms p(90)=157.29ms p(95)=157.29ms
    iterations.....................: 1      6.352779/s

    NETWORK
    data_received..................: 3.7 kB 24 kB/s
    data_sent......................: 1.7 kB 11 kB/s

Performance Testing Benefits

Feature	Benefit
Automated test creation	Tests generated from topology
One-time image build	Reusable across all tests
Integrated reporting	Results in Grafana dashboards
Scaling validation	Verify autoscaling configurations

📊 Pro Tip: You only need to build the k6 image once—test definitions are referenced directly in the deployment through ConfigMaps.

🔧 External Source Code Automation

Export Code to automate CI & CD

External Source Code automation enables ** integration of existing codebases** with automated build and deployment pipelines.

Component Configuration

When creating an External Source Code component, Stacktic automatically:

Action	Generated Assets
Configures Git integration	Git credentials, branch management
Sets up build pipeline	Kaniko jobs, Dockerfile processing
Creates deployments	Kubernetes manifests, services
Manages secrets	Registry credentials, environment variables
Implements security	RBAC, service accounts, security contexts

Quick setup

Configuration Tips: Define your Git Repository

Configmap: make sure to add ENV needed for the container code to come up

Docker_file_path: default is "/". if you move Dockerfiel , please update the path

Git_folder: same as above. build expect root sturcture where Dockerfile is in the root , src folder,etc...

UID/GID: make sure the UID/GID match the Dockerfile

Deployment Tips

Rarget port: should be identical to the Dockerfile port

Pvc mount path: if PVC enabled make sure it fit your code path

mount file folder: if you want to add from deployment level files to the container and mount it to PVC

configMapGenerator:
  - name: staging-static-files
    namespace: staging
    files:
      - files/test_file.text  
    options:
      disableNameSuffixHash: true      

  - name: staging-startup
    namespace: staging
    files:
      - files/startup.sh
    options:
      disableNameSuffixHash: true

Kaniko Build Process

The automation generates a complete CI using Kaniko or buildkit for containerless builds:

k8s/build/base/stage/buildkit.yaml
or 
k8s/build/base/stage/kaniko.yaml

Configuration Options

Configuration	Purpose	Automation Impact
Git Owner	Repository owner	Determines Git URL construction
Project	Repository name	Sets build context
Branch	Target branch	Controls source version
Git Folder	Subdirectory path	Sets context sub-path
Dockerfile	Custom Dockerfile path	Optional build customization
Version	Image tag	Deployment version control
Registry	Container registry	Build destination
Namespace	Kubernetes namespace	Deployment location

Security Features

Pod Security Standards

When security context is enabled, the deployment automatically implements:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000  # Configurable user ID
    runAsGroup: 1000  # Configurable group ID
    seccompProfile:
      type: RuntimeDefault
  hostNetwork: false
  hostPID: false
  hostIPC: false
  containers:
    - securityContext:
        allowPrivilegeEscalation: false
        privileged: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: [ALL]

Supply Chain Security

When signature validation (sig) is enabled:

Cosign integration for image signing
Signature verification jobs
RBAC policies for validation
Key management through Kubernetes secrets
Automated validation on deployment

Advanced Features

Feature	Configuration	Generated Components
Auto-scaling	`hpa: true`	HorizontalPodAutoscaler resources
Persistent storage	`pvc: true`	PersistentVolumeClaim manifests
Monitoring	Prometheus integration	ServiceMonitor resources
Image updates	`imageupdater_update_enable: true`	Automatic version tracking
Static files	`files_mount_path`	ConfigMap with mounted files
Health checks	`probes: true`	Liveness/Readiness probe patches
Ingress	Kong integration	Ingress rules and routes

Resource Management

Flexible resource configuration with defaults:

resources:
  requests:
    cpu: "1000m"
    memory: "512Mi"
  limits:
    cpu: "2000m"
    memory: "1024Mi"

Volume Management

Volume Type	Use Case	Configuration
PVC	Persistent data	`pvc_name`, `mount_path`
EmptyDir	Temporary storage	`/tmp`, writable directories
ConfigMap	Static files	Read-only file mounts
Secrets	Sensitive data	Environment variables

Build Process Options

Build Feature	Description	Configuration
SonarQube	Code quality analysis	Automated scanning
Multi-stage builds	Optimized images	Dockerfile support
Build caching	Faster builds	Layer caching
Custom base images	Corporate standards	Registry configuration

🐳 Image Base Automation

Pre-Built Image Deployment

Image Base automation provides streamlined deployment of existing container images without requiring source code access.

Component Architecture

Image Base components support deployment of any containerized application with automated configuration:

Component	Automated Features
Init Containers	Startup scripts, initialization logic
Main Container	Application deployment
Startup Scripts	Custom initialization via ConfigMap
Security Policies	Pod and container security contexts
Service Accounts	RBAC and permissions

Startup Automation

Init Container Configuration

The automation includes sophisticated initialization capabilities:

initContainers:
  - name: startup
    image: application-image:version
    command: ["/bin/sh", "-c"]
    args: ["/startup/startup.sh"]
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 200m
        memory: 256Mi
    envFrom:
      - secretRef:
          name: component-external-source-secrets
    volumeMounts:
      - mountPath: /startup
        name: startup-scripts
        readOnly: true
      - mountPath: /tmp
        name: tmp-volume

Configuration Management

Startup Script Integration

Automatically mounts custom startup scripts via ConfigMap:

configMapGenerator:
  - name: component-startup
    namespace: namespace
    files:
      - files/startup.sh
    options:
      disableNameSuffixHash: true

Image Management Features

Feature	Configuration	Benefit
Direct image deployment	Image URL/tag	No build required
Version control	`version` attribute	Consistent deployments
Registry authentication	Pull secrets	Private registry support
Update automation	`imageupdater_update_enable`	Automatic version updates
Multi-registry support	Registry configuration	Flexibility in image sources

Resource Allocation

Flexible resource configuration with separate init container limits:

# Init Container Resources
initContainers:
  - resources:
      requests: {cpu: 100m, memory: 128Mi}
      limits: {cpu: 200m, memory: 256Mi}

# Main Container Resources  
containers:
  - resources:
      requests: 
        cpu: "{{ cpu_request }}"
        memory: "{{ mem_request }}"
      limits:
        cpu: "{{ cpu_limit }}"
        memory: "{{ mem_limit }}"

Security Implementation

Multi-Level Security

Both pod-level and container-level security contexts:

# Pod Level Security (when pod_level_security: true)
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000  # Configurable
    runAsGroup: 1000  # Configurable
    seccompProfile:
      type: RuntimeDefault
  hostNetwork: false
  hostPID: false
  hostIPC: false

# Container Level Security (when securityContext: true)
containers:
  - securityContext:
      allowPrivilegeEscalation: false
      privileged: false
      readOnlyRootFilesystem: true
      runAsNonRoot: true
      capabilities:
        drop: [ALL]

Deployment Patterns

Pattern	Implementation	Use Case
Init + Main	Startup container + app	Database migrations, config setup
Sidecar Ready	Multiple container support	Logging, monitoring agents
StatefulSet Compatible	PVC integration	Databases, stateful services
Job Pattern	One-time execution	Batch processing, migrations
DaemonSet Ready	Node-level deployments	System agents, monitoring

Monitoring & Observability

When Prometheus is configured:

Automatic ServiceMonitor creation
Metrics endpoint configuration
Namespace-aware monitoring
Standard Kubernetes labels
Custom metrics path support

Advanced Configurations

Configuration	Purpose	Generated Resources
Affinity Rules	Pod distribution	Anti-affinity policies
Service Types	Network exposure	ClusterIP, NodePort, LoadBalancer
Ingress Integration	External access	Kong ingress rules
Cosign Validation	Image verification	Signature check jobs
Image Pull Secrets	Private registries	Docker config secrets
Service Account	RBAC permissions	Roles and bindings

Comparison: External Source vs Image Base

Aspect	External Source Code	Image Base
Build Process	Kaniko from source	Pre-built images
Startup Logic	In Dockerfile	Init containers
Flexibility	Full source control	Image-level control
Speed	Build + deploy	Deploy only
Use Case	Custom applications	Third-party/pre-built apps
Git Integration	Required	Not needed
CI/CD Pipeline	Full automation	Deployment only
Resource Usage	Build resources needed	Deployment resources only

Secret Management

Both automation types handle secrets securely:

secretGenerator:
  - name: registry-credential
    namespace: namespace
    files:
      - .dockerconfigjson=secret/registry.json
    type: kubernetes.io/dockerconfigjson
    
  - name: component-external-source-secrets
    namespace: namespace
    envs:
      - secret/cloud.env
      
  - name: component-cosign-key-secret
    namespace: namespace
    files:
      - secret/cosign/cosign.key
      - secret/cosign/cosign.pub
      - secret/cosign/password

📚 Best Practices

General Automation Guidelines

Practice	Description	Benefit
Start Simple	Begin with basic components	Easier troubleshooting
Use Sub-Components	Leverage hierarchical structure	Better organization
Define Relationships	Connect components properly	Automatic configuration
Test in Stages	Dev → Staging → Production	Risk mitigation
Review Generated Docs	Check automation outputs	Understanding & validation
Version Everything	Tag images and code	Rollback capability
Use Security Contexts	Enable pod/container security	Defense in depth

Security Recommendations

External Authentication - Use OIDC providers over built-in auth
Secret Management - Let Stacktic handle secret generation
Network Policies - Enable auto-generated policies
TLS Everywhere - Use encrypted connections
Regular Updates - Keep component versions current
Image Signing - Enable Cosign for supply chain security
RBAC - Use service accounts with minimal permissions

Performance Optimization

✅ Use k6 for baseline performance testing
✅ Configure resource limits appropriately
✅ Enable horizontal pod autoscaling
✅ Implement caching strategies
✅ Monitor with Prometheus/Grafana
✅ Use init containers for one-time setup
✅ Optimize image sizes

🎯 Summary

Key Takeaways

✅ Pattern-Based Automation - Best practices built into every component
✅ Relationship Intelligence - Connections drive configuration
✅ Complete Stack Coverage - From messaging to testing
✅ Security by Default - Authentication, encryption, policies
✅ Production Ready - Generated configurations are deployment-ready
✅ Flexible Deployment - Support for both source code and pre-built images
✅ GitOps Native - All configurations in Git-friendly formats

What's Automated vs. What You Control

Stacktic Automates	You Control
Infrastructure configuration	Business logic
Service connections	Application code
Security policies	Data schemas
Monitoring setup	Business rules
Testing frameworks	Custom algorithms
Build pipelines	Source code
Deployment manifests	Configuration values

These examples demonstrate the power of Stacktic's automation. The full automation in your repository will include complete configurations, documentation, and operational procedures tailored to your specific stack.

📚 Automation Examples

📋 Table of Contents​

Overview​

Important Notes​

What Gets Automated​

🐇 RabbitMQ Automation​

Component Architecture​

Sub-Component Creation​

Relationship Configuration​

Generated Configuration​

Secret Configuration Example​

Additional Configurations​

🦄 Kafka Automation​

Advanced Event Streaming​

Sub-Component Types​

Integration Capabilities​

API Gateway Integration​

Database Integration​

Example Resources​

Demo Repository​

Connectors Example​

Automated Components​

⚡ FastAPI Automation​

API Development Acceleration​

Automatic Configuration​

API Gateway Integration​

Validation & Testing​

sub_component for custom API​

✅ Advantages of Using Sub-Component APIs​

Security Best Practices​

OIDC Integration with APISIX & Keycloak​

Configuration Details​

📈 k6 Load Testing Automation​

Performance Testing Framework​

Automated Test Generation​

Example k6 Structure​

Test Execution Configuration​

Sample test-run.yaml​

Loading your full stack with single JSON​

Performance Testing Benefits​

🔧 External Source Code Automation​

Export Code to automate CI & CD​

Component Configuration​

Quick setup​

Kaniko Build Process​

Configuration Options​

Security Features​

Pod Security Standards​

Supply Chain Security​

Advanced Features​

Resource Management​

Volume Management​

Build Process Options​

🐳 Image Base Automation​

Pre-Built Image Deployment​

Component Architecture​

Startup Automation​

Init Container Configuration​

Configuration Management​

Startup Script Integration​

Image Management Features​

Resource Allocation​

Security Implementation​

Multi-Level Security​

Deployment Patterns​

Monitoring & Observability​

Advanced Configurations​

Comparison: External Source vs Image Base​

Secret Management​

📚 Best Practices​

General Automation Guidelines​

Security Recommendations​

Performance Optimization​

🎯 Summary​

Key Takeaways​

What's Automated vs. What You Control​

📋 Table of Contents

Overview

Important Notes

What Gets Automated

🐇 RabbitMQ Automation

Component Architecture

Sub-Component Creation

Relationship Configuration

Generated Configuration

Secret Configuration Example

Additional Configurations

🦄 Kafka Automation

Advanced Event Streaming

Sub-Component Types

Integration Capabilities

API Gateway Integration

Database Integration

Example Resources

Demo Repository

Connectors Example

Automated Components

⚡ FastAPI Automation

API Development Acceleration

Automatic Configuration

API Gateway Integration

Validation & Testing

sub_component for custom API

✅ Advantages of Using Sub-Component APIs

Security Best Practices

OIDC Integration with APISIX & Keycloak

Configuration Details

📈 k6 Load Testing Automation

Performance Testing Framework

Automated Test Generation

Example k6 Structure

Test Execution Configuration

Sample test-run.yaml

Loading your full stack with single JSON

Performance Testing Benefits

🔧 External Source Code Automation

Export Code to automate CI & CD

Component Configuration

Quick setup

Kaniko Build Process

Configuration Options

Security Features

Pod Security Standards

Supply Chain Security

Advanced Features

Resource Management

Volume Management

Build Process Options

🐳 Image Base Automation

Pre-Built Image Deployment

Component Architecture

Startup Automation

Init Container Configuration

Configuration Management

Startup Script Integration

Image Management Features

Resource Allocation

Security Implementation

Multi-Level Security

Deployment Patterns

Monitoring & Observability

Advanced Configurations

Comparison: External Source vs Image Base

Secret Management

📚 Best Practices

General Automation Guidelines

Security Recommendations

Performance Optimization

🎯 Summary

Key Takeaways

What's Automated vs. What You Control