From a761b4a09615ebf8c8e01721ff7ba24ec85402d0 Mon Sep 17 00:00:00 2001 From: Piotr Hajdas Date: Sun, 27 Apr 2025 13:58:24 +0200 Subject: [PATCH 1/2] feat: help kubernetes --- .../docker-compose-requirements.md | 12 + docs/deploystack/one-click-deploy.md | 2 + docs/docker-to-iac/api.md | 295 ++++++++++++++++-- .../docker-to-iac/multi-file-configuration.md | 191 ++++++++++++ docs/docker-to-iac/parser/helm.md | 216 +++++++++++++ docs/docker-to-iac/parser/index.md | 1 + docs/docker-to-iac/publishing-to-npm.md | 2 +- docs/docker-to-iac/supported-registries.md | 2 + docs/index.md | 5 +- 9 files changed, 702 insertions(+), 24 deletions(-) create mode 100644 docs/docker-to-iac/multi-file-configuration.md create mode 100644 docs/docker-to-iac/parser/helm.md diff --git a/docs/deploystack/docker-compose-requirements.md b/docs/deploystack/docker-compose-requirements.md index 6202909..9f1748f 100644 --- a/docs/deploystack/docker-compose-requirements.md +++ b/docs/deploystack/docker-compose-requirements.md @@ -54,12 +54,24 @@ The infrastructure templates we generate require specific, immutable container i We currently support these Docker Compose properties -> please check [Supported Docker Compose Variables](/docs/docker-to-iac/supported-docker-compose-variables.md). +### Kubernetes/Helm + +When generating Helm charts for Kubernetes: + +- Database services (MySQL, PostgreSQL, Redis, etc.) are converted to Bitnami Helm chart dependencies +- Environment variables are split between ConfigMaps (regular variables) and Secrets (sensitive data) +- Each service in your Docker Compose becomes a separate Deployment and Service +- Volume mounts are supported and configured as needed + +This allows for better security practices and easier management of your application on Kubernetes. + ## Multiple Services Support DeployStack can handle Docker Compose files with multiple services, but support varies by cloud provider: - Some providers support deploying all services at once - Others will only deploy the first service in your compose file +- Kubernetes (Helm) supports multi-service deployments with each service becoming a separate Deployment Check the specific [Multi Services Support](/docs/docker-to-iac/multi-services-support.md) for details about multi-service support. diff --git a/docs/deploystack/one-click-deploy.md b/docs/deploystack/one-click-deploy.md index 1a56bc6..ec5056b 100644 --- a/docs/deploystack/one-click-deploy.md +++ b/docs/deploystack/one-click-deploy.md @@ -39,6 +39,7 @@ We create a dedicated branch for each project to support one-click deployment fu We integrate with cloud providers' native deployment systems. For example: - **DigitalOcean**: Uses the "Deploy to DigitalOcean" functionality as documented in their [official guide](https://docs.digitalocean.com/products/app-platform/how-to/add-deploy-do-button/) +- **Kubernetes**: Generates Helm charts that can be deployed to any Kubernetes cluster - Check [supported cloud providers](/docs/docker-to-iac/index.md) for full list ### Provider-Specific Templates @@ -49,6 +50,7 @@ Each cloud provider may require specific template formats: - DigitalOcean App Spec - Render Blueprints - And more based on provider requirements +- Kubernetes Helm charts with all necessary templates ## Using Deploy Buttons diff --git a/docs/docker-to-iac/api.md b/docs/docker-to-iac/api.md index 80c7a7b..1ad3ccc 100644 --- a/docs/docker-to-iac/api.md +++ b/docs/docker-to-iac/api.md @@ -1,5 +1,6 @@ --- description: Here's everything you need to know about our docker-to-iac module - from listing available cloud providers to converting your Docker setup into deployable code. +menuTitle: API --- # docker-to-iac module API list @@ -28,29 +29,53 @@ console.log(parsers); { providerWebsite: 'https://aws.amazon.com/cloudformation/', providerName: 'Amazon Web Services', - provieerNameAbbreviation: 'AWS', + providerNameAbbreviation: 'AWS', languageOfficialDocs: 'https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html', languageAbbreviation: 'CFN', languageName: 'AWS CloudFormation', - defaultParserConfig: { fileName: 'aws-cloudformation.yaml', cpu: 512, memory: '1GB', templateFormat: 'yaml' } + defaultParserConfig: { files: [Array], cpu: 512, memory: '1GB' } }, { providerWebsite: 'https://render.com/docs', providerName: 'Render', - provieerNameAbbreviation: 'RND', + providerNameAbbreviation: 'RND', languageOfficialDocs: 'https://docs.render.com/infrastructure-as-code', languageAbbreviation: 'RND', languageName: 'Render Blue Print', defaultParserConfig: { - subscriptionName: 'free', + files: [Array], + subscriptionName: 'starter', region: 'oregon', - fileName: 'render.yaml', - templateFormat: 'yaml' + diskSizeGB: 10 + } + }, + { + providerWebsite: 'https://www.digitalocean.com/', + providerName: 'DigitalOcean', + providerNameAbbreviation: 'DO', + languageOfficialDocs: 'https://docs.digitalocean.com/products/app-platform/', + languageAbbreviation: 'DOP', + languageName: 'DigitalOcean App Spec', + defaultParserConfig: { files: [Array], region: 'nyc', subscriptionName: 'basic-xxs' } + }, + { + providerWebsite: 'https://helm.sh/', + providerName: 'Kubernetes', + providerNameAbbreviation: 'K8S', + languageOfficialDocs: 'https://helm.sh/docs/', + languageAbbreviation: 'HELM', + languageName: 'Helm Chart', + defaultParserConfig: { + files: [Array], + cpu: '100m', + memory: '128Mi' } } ] ``` +**Note the files array**: that's because we have a [multi file strategy](/docs/docker-to-iac/multi-file-configuration.md). + ### Type ```typescript @@ -76,13 +101,24 @@ console.log(awsInfo); ```json { - providerWebsite: 'https://aws.amazon.com/cloudformation/', - providerName: 'Amazon Web Services', - provieerNameAbbreviation: 'AWS', - languageOfficialDocs: 'https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html', - languageAbbreviation: 'CFN', - languageName: 'AWS CloudFormation', - defaultParserConfig: { fileName: 'aws-cloudformation.yaml', cpu: 512, memory: '1GB', templateFormat: 'yaml' } + providerWebsite: 'https://aws.amazon.com/cloudformation/', + providerName: 'Amazon Web Services', + providerNameAbbreviation: 'AWS', + languageOfficialDocs: 'https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html', + languageAbbreviation: 'CFN', + languageName: 'AWS CloudFormation', + defaultParserConfig: { + files: [ + { + path: 'aws-cloudformation.cf.yml', + templateFormat: 'yaml', + isMain: true, + description: 'AWS CloudFormation template' + } + ], + cpu: 512, + memory: '1GB' + } } ``` @@ -106,7 +142,25 @@ translate(input: string, options: { environmentVariableGeneration?: EnvironmentVariableGenerationConfig; environmentVariables?: Record; persistenceKey?: string; -}): any + serviceConnections?: ServiceConnectionsConfig; +}): TranslationResult +``` + +Where `TranslationResult` has the structure: + +```typescript +interface TranslationResult { + files: { + [path: string]: FileOutput + }; + serviceConnections?: ResolvedServiceConnection[]; +} + +interface FileOutput { + content: string; + format: TemplateFormat; + isMain?: boolean; +} ``` ### Examples @@ -114,32 +168,166 @@ translate(input: string, options: { #### Translating Docker Compose ```javascript -import { readFileSync, writeFileSync } from 'fs'; +import { readFileSync, writeFileSync, mkdirSync, existsSync } from 'fs'; +import { join, dirname } from 'path'; import { translate } from '@deploystack/docker-to-iac'; const dockerComposeContent = readFileSync('path/to/docker-compose.yml', 'utf8'); -const translatedConfig = translate(dockerComposeContent, { +const result = translate(dockerComposeContent, { source: 'compose', target: 'CFN', templateFormat: 'yaml' }); -console.log(translatedConfig); + +// Access individual file contents +console.log(`Generated ${Object.keys(result.files).length} files:`); +Object.keys(result.files).forEach(path => { + console.log(`- ${path}`); +}); + +// Write files to disk preserving directory structure +Object.entries(result.files).forEach(([path, fileData]) => { + const fullPath = join('output', path); + const dir = dirname(fullPath); + + if (!existsSync(dir)) { + mkdirSync(dir, { recursive: true }); + } + + writeFileSync(fullPath, fileData.content); +}); ``` #### Translating Docker Run Command ```javascript import { translate } from '@deploystack/docker-to-iac'; +import { writeFileSync, mkdirSync, existsSync } from 'fs'; +import { join, dirname } from 'path'; const dockerRunCommand = 'docker run -d -p 8080:80 nginx:latest'; -const translatedConfig = translate(dockerRunCommand, { +const result = translate(dockerRunCommand, { source: 'run', - target: 'CFN', + target: 'RND', templateFormat: 'yaml' }); -console.log(translatedConfig); + +console.log(result) + +// Access and save all generated files +Object.entries(result.files).forEach(([path, fileData]) => { + const fullPath = join('output', path); + const dir = dirname(fullPath); + + if (!existsSync(dir)) { + mkdirSync(dir, { recursive: true }); + } + + writeFileSync(fullPath, fileData.content); + console.log(`Created: ${path}`); +}); +``` + +#### Translating Docker Compose to Helm Chart + +```javascript +import { translate } from '@deploystack/docker-to-iac'; +import { writeFileSync, mkdirSync, existsSync } from 'fs'; +import { join, dirname } from 'path'; + +const dockerComposeContent = ` +version: '3' +services: + web: + image: nginx:latest + ports: + - "80:80" + db: + image: postgres:13 + environment: + POSTGRES_USER: myuser + POSTGRES_PASSWORD: mypassword + POSTGRES_DB: myapp +`; + +const result = translate(dockerComposeContent, { + source: 'compose', + target: 'HELM', + templateFormat: 'yaml' +}); + +// Access and save all generated files to create a complete Helm Chart +Object.entries(result.files).forEach(([path, fileData]) => { + const fullPath = join('helm-chart', path); + const dir = dirname(fullPath); + + if (!existsSync(dir)) { + mkdirSync(dir, { recursive: true }); + } + + writeFileSync(fullPath, fileData.content); + console.log(`Created: ${path}`); +}); +``` + +#### Example Output (Partial - Chart.yaml) + +```yaml +apiVersion: v2 +name: deploystack-app +description: A Helm chart for DeployStack application generated from Docker configuration +type: application +version: 0.1.0 +appVersion: 1.0.0 +maintainers: + - name: DeployStack + email: hello@deploystack.io +dependencies: + - name: db + repository: https://charts.bitnami.com/bitnami + version: ^12.0.0 + condition: dependencies.db.enabled +``` + +#### Configuring Service Connections + +```javascript +import { translate } from '@deploystack/docker-to-iac'; + +const dockerComposeContent = ` +version: "3" +services: + db: + image: mariadb:latest + environment: + - MYSQL_ROOT_PASSWORD=rootpass + app: + image: node:alpine + environment: + - DATABASE_HOST=db # This will be transformed +`; + +const result = translate(dockerComposeContent, { + source: 'compose', + target: 'DOP', // DigitalOcean App Platform + templateFormat: 'yaml', + serviceConnections: { + mappings: [ + { + fromService: 'app', // Service that needs to connect + toService: 'db', // Service to connect to + environmentVariables: [ // Env vars that reference the service + 'DATABASE_HOST' + ] + } + ] + } +}); + +// The result will include transformed service references: +console.log(result.serviceConnections); ``` ### Example Output (AWS CloudFormation) @@ -310,11 +498,74 @@ const result = translate(dockerConfig, { #### `options.persistenceKey?: string` -Optional. The `persistenceKey` parameter allows you to maintain consistent variable values across multiple template generations +Optional. The `persistenceKey` parameter allows you to maintain consistent variable values across multiple template generations. + +#### `options.serviceConnections?: ServiceConnectionsConfig` + +Optional. Configure service-to-service communications by defining which environment variables reference other services. + +```typescript +type ServiceConnectionsConfig = { + mappings: Array<{ + fromService: string; // Service that needs to connect + toService: string; // Service to connect to + environmentVariables: string[]; // Environment variables that reference the service + property?: string; // Connection property type (connectionString, hostport, etc.) + }> +}; +``` + +This option is currently supported by: + +- Render.com (RND): Uses Blueprint's `fromService` syntax +- DigitalOcean App Platform (DOP): Uses direct service names +- Kubernetes Helm Charts (HELM): Uses Kubernetes DNS service discovery + +Example: + +```javascript +serviceConnections: { + mappings: [ + { + fromService: 'frontend', + toService: 'api', + environmentVariables: ['API_URL'], + property: 'hostport' + }, + { + fromService: 'app', + toService: 'db', + environmentVariables: ['DATABASE_URL'], + property: 'connectionString' + } + ] +} +``` ### Return Value -Returns the translated Infrastructure as Code template in the specified format. The structure and content will vary based on the target IaC language and template format chosen. +Returns the translated Infrastructure as Code template and any resolved service connections: + +```typescript +{ + files: { + // Generated IaC template files with paths as keys + 'render.yaml': { content: '...', format: 'yaml', isMain: true } + }, + serviceConnections: [ + { + fromService: 'app', + toService: 'db', + variables: { + 'DATABASE_HOST': { + originalValue: 'db', + transformedValue: 'db' // Transformed as appropriate for the provider + } + } + } + ] +} +``` ## List Services API diff --git a/docs/docker-to-iac/multi-file-configuration.md b/docs/docker-to-iac/multi-file-configuration.md new file mode 100644 index 0000000..52e0eb3 --- /dev/null +++ b/docs/docker-to-iac/multi-file-configuration.md @@ -0,0 +1,191 @@ +--- +description: Learn how docker-to-iac supports complex Infrastructure as Code templates with multiple interconnected files, including Helm Charts and other multi-file IaC formats. +menuTitle: Multi-File Configuration +--- + +# Multi-File Configuration in docker-to-iac + +## Introduction to Multi-File Support + +Starting with version 1.20.0, [docker-to-iac](https://github.com/deploystackio/docker-to-iac) supports generating multiple interconnected files for more complex Infrastructure as Code (IaC) templates. This feature was introduced primarily to support Helm Charts and other sophisticated IaC formats that require multiple files with specific directory structures. + +## Why Multi-File Templates? + +Modern IaC solutions often require multiple files that work together: + +- **Helm Charts** need Chart.yaml, values.yaml, and template files +- **Terraform modules** use main.tf, variables.tf, outputs.tf, and more +- **Kubernetes manifests** are typically split into multiple YAML files +- **Multi-tier applications** may need separate configurations for each tier + +These complex deployments would be difficult or impossible to represent in a single file, which led to the introduction of multi-file support. + +## The Main File Concept + +Each parser must designate one file as the "main" file using the `isMain: true` property. This maintains backward compatibility with existing code and provides a clear entry point for deployment tools. + +```typescript +parseFiles(config: ApplicationConfig): { [path: string]: FileOutput } { + return { + 'Chart.yaml': { + content: this.formatFileContent(chartConfig, TemplateFormat.yaml), + format: TemplateFormat.yaml, + isMain: true // This is the main file + }, + 'values.yaml': { + content: this.formatFileContent(valuesConfig, TemplateFormat.yaml), + format: TemplateFormat.yaml + } + }; +} +``` + +When a parser is invoked through the legacy `parse()` method, only the content of the main file is returned. However, when using the `parseFiles()` method, all files are included in the response. + +## Example: Helm Chart Structure + +Helm Charts are a perfect example of why multi-file support is needed. A basic Helm Chart requires at least the following files: + +```bash +mychart/ +├── Chart.yaml # Chart metadata +├── values.yaml # Default configuration values +└── templates/ + ├── deployment.yaml # Kubernetes Deployment + ├── service.yaml # Kubernetes Service + └── _helpers.tpl # Template helpers +``` + +The docker-to-iac module now includes a Helm parser that generates this exact structure when translating Docker configurations to Helm Charts: + +```javascript +const result = translate(dockerComposeContent, { + source: 'compose', + target: 'HELM', + templateFormat: 'yaml' +}); + +// Result contains all files needed for a complete Helm Chart +console.log(Object.keys(result.files)); +// [ +// 'Chart.yaml', +// 'values.yaml', +// 'templates/deployment.yaml', +// 'templates/service.yaml', +// 'templates/configmap.yaml', +// 'templates/secret.yaml', +// 'templates/NOTES.txt', +// 'templates/_helpers.tpl' +// ] +``` + +With the multi-file support, a Helm Chart parser configuration might look like: + +```typescript +const defaultParserConfig: ParserConfig = { + files: [ + { + path: 'Chart.yaml', + templateFormat: TemplateFormat.yaml, + isMain: true, + description: 'Chart metadata file' + }, + { + path: 'values.yaml', + templateFormat: TemplateFormat.yaml, + description: 'Default configuration values' + }, + { + path: 'templates/deployment.yaml', + templateFormat: TemplateFormat.yaml, + description: 'Kubernetes Deployment template' + }, + { + path: 'templates/service.yaml', + templateFormat: TemplateFormat.yaml, + description: 'Kubernetes Service template' + }, + { + path: 'templates/_helpers.tpl', + templateFormat: TemplateFormat.text, + description: 'Template helper functions' + } + ] +}; +``` + +## Implementation Details + +### File Structure + +Each parser must implement the `parseFiles` method, which returns an object mapping file paths to their content: + +```typescript +interface FileOutput { + content: string; // File content as a string + format: TemplateFormat; // Format (yaml, json, text) + isMain?: boolean; // Whether this is the main file +} + +parseFiles(config: ApplicationConfig): { [path: string]: FileOutput }; +``` + +### Directory Support + +The file paths can include directories, which will be created automatically when the templates are saved: + +```typescript +return { + 'templates/deployment.yaml': { + content: deploymentContent, + format: TemplateFormat.yaml + }, + 'templates/ingress.yaml': { + content: ingressContent, + format: TemplateFormat.yaml + } +}; +``` + +### Content Formatting + +The `formatFileContent` helper method ensures that content is properly formatted according to the specified template format. + +## Backward Compatibility + +To maintain backward compatibility, the `BaseParser` class implements a default `parse` method that: + +1. Calls the new `parseFiles` method +2. Finds the file marked with `isMain: true` +3. Returns only that file's content + +```typescript +parse(config: ApplicationConfig, templateFormat?: TemplateFormat): any { + const files = this.parseFiles(config); + const mainFile = Object.values(files).find(file => file.isMain); + + if (!mainFile) { + throw new Error('No main file defined in parser output'); + } + + return typeof mainFile.content === 'string' + ? mainFile.content + : formatResponse(JSON.stringify(mainFile.content, null, 2), templateFormat || mainFile.format); +} +``` + +This ensures that existing code that calls `parse()` will continue to work as expected. + +## Best Practices + +When implementing multi-file parsers: + +1. **Always mark one file as main**: Designate exactly one file as `isMain: true` to maintain backward compatibility. + +2. **Use consistent directory structure**: Follow the conventions of your target IaC format (e.g., Helm Chart layout). + +3. **Use appropriate formats**: Choose the right format for each file (YAML for Kubernetes manifests, text for template helpers, etc.). + +4. **Include descriptive comments**: Add descriptions to help users understand the purpose of each file. + +5. **Handle file dependencies**: Ensure that files reference each other correctly using relative paths. diff --git a/docs/docker-to-iac/parser/helm.md b/docs/docker-to-iac/parser/helm.md new file mode 100644 index 0000000..a01b0e4 --- /dev/null +++ b/docs/docker-to-iac/parser/helm.md @@ -0,0 +1,216 @@ +--- +description: Translate Docker Compose files into Kubernetes Helm Charts with DeployStack docker-to-iac module +menuTitle: Helm +--- + +# Helm - Parser Full Documentation + +The parser for Helm translates Docker configurations into Kubernetes Helm Charts. The parser logic can be found in GitHub inside the [docker-to-iac repo](https://github.com/deploystackio/docker-to-iac/blob/main/src/parsers/helm.ts). + +## Parser language abbreviation for API + +- `languageAbbreviation`: `HELM`. + +## Prerequisite to deploy Helm Charts + +To deploy the generated Helm Charts, you need: + +- A Kubernetes cluster (local or cloud-based) +- Helm CLI installed (version 3.x recommended) +- Appropriate RBAC permissions to deploy resources in your target namespace + +## Architecture + +The Helm parser generates a complete Helm Chart structure that follows Kubernetes and Helm best practices: + +![Kubernetes Helm Architecture](/docs/assets/images/docker-to-iac/helm-kubernetes-architecture.png) + +### Kubernetes Resources + +The generated Helm Chart creates the following Kubernetes resources for each service in your Docker configuration: + +- **Deployments**: Container specifications, replica count, resource limits +- **Services**: Network access to your pods with appropriate ports +- **ConfigMaps**: Non-sensitive environment variables +- **Secrets**: Sensitive environment variables (passwords, tokens, etc.) + +### Database Support + +For database services, the parser leverages Helm's dependency management to incorporate official Bitnami charts: + +- **MySQL/MariaDB**: Uses Bitnami's MySQL/MariaDB chart +- **PostgreSQL**: Uses Bitnami's PostgreSQL chart +- **Redis**: Uses Bitnami's Redis chart +- **MongoDB**: Uses Bitnami's MongoDB chart + +Each database dependency is configured with appropriate defaults and includes persistent storage for data. + +## Default output format + +- The default output format for this parser: `YAML`. + +## File Configuration + +The Helm parser generates a complete Helm Chart directory structure: + +- `Chart.yaml` - The main chart definition with metadata and dependencies +- `values.yaml` - Configuration values that can be customized at deployment time +- `templates/` - Directory containing Kubernetes YAML templates: + - `deployment.yaml` - Deployment specifications for each service + - `service.yaml` - Service definitions for network access + - `configmap.yaml` - ConfigMap for non-sensitive environment variables + - `secret.yaml` - Secret for sensitive environment variables + - `_helpers.tpl` - Helper functions for template generation + - `NOTES.txt` - Usage instructions displayed after installation + +This multi-file approach follows the standard Helm Chart structure and allows for maximum flexibility when deploying to Kubernetes. + +## Supported Docker Compose Variables + +This parser supports the following Docker Compose variables: + +- `image` +- `environment` +- `ports` +- `command` +- `volumes` + +::content-alert{type="note"} +The parser automatically detects sensitive environment variables (containing keywords like "password", "secret", "key", "token", or "auth") and places them in Kubernetes Secrets instead of ConfigMaps. +:: + +## Volume Support + +The parser supports Docker volume mappings by converting them to Kubernetes volume mounts: + +- Each volume is converted to a hostPath volume by default +- Volume names are sanitized to conform to Kubernetes naming conventions +- For production use, you should modify the generated templates to use more appropriate volume types (PersistentVolumeClaims, etc.) + +## Database Integration + +When a database service is detected (MySQL, PostgreSQL, Redis, MongoDB), the parser: + +1. Adds the corresponding Bitnami Helm chart as a dependency in `Chart.yaml` +2. Configures database settings in `values.yaml` +3. Maps environment variables to the expected format for the database chart +4. Sets up appropriate persistence configurations + +### Example Database Configuration + +For a PostgreSQL database in your Docker Compose file: + +```yaml +services: + db: + image: postgres:13 + environment: + POSTGRES_USER: myuser + POSTGRES_PASSWORD: mypassword + POSTGRES_DB: myapp +``` + +The parser will create: + +```yaml +# In Chart.yaml +dependencies: + - name: db + repository: https://charts.bitnami.com/bitnami + version: ^12.0.0 + condition: dependencies.db.enabled + +# In values.yaml +dependencies: + db: + enabled: true + auth: + postgres: + password: mypassword + database: myapp + username: myuser + password: mypassword + primary: + service: + ports: + postgresql: 5432 + persistence: + enabled: true + size: 8Gi +``` + +## Service Connections + +The parser supports service-to-service connections by leveraging Kubernetes DNS for service discovery. When a service refers to another service in an environment variable, the parser automatically configures the appropriate DNS references. + +For example, if your `app` service connects to a `db` service: + +```yaml +# Docker Compose +services: + app: + image: myapp + environment: + DATABASE_URL: postgresql://postgres:password@db:5432/mydb + + db: + image: postgres + environment: + POSTGRES_PASSWORD: password + POSTGRES_DB: mydb +``` + +The parser will create: + +```yaml +# In ConfigMap template +data: + DATABASE_URL: {{ include "deploystack.serviceReference" (dict "service" (index $.Values.services "db") "serviceKey" "db") }} +``` + +Which resolves to the Kubernetes DNS name: `db.{{ .Release.Namespace }}.svc.cluster.local:5432` + +## Multi Services Support + +Multi `services` support for Helm: **yes** + +Helm Charts are designed to handle multiple services and dependencies in a single deployment, making them ideal for complex applications. The parser transforms all services from your Docker Compose file into corresponding Kubernetes resources. + +Please read more about [multi service support here](/docs/docker-to-iac/multi-services-support.md). + +## Deployment Instructions + +To deploy the generated Helm Chart: + +1. Navigate to the directory containing the generated chart +2. Install dependencies: + + ```bash + helm dependency update + ``` + +3. Install the chart: + + ```bash + helm install my-release . + ``` + +4. For custom configurations: + + ```bash + helm install my-release . --set services.app.replicaCount=2 + ``` + +## Production Considerations + +For production deployments, consider the following modifications to the generated chart: + +1. Replace hostPath volumes with appropriate persistent volume claims +2. Adjust resource limits in `values.yaml` +3. Configure proper ingress settings for external access +4. Enable and configure horizontal pod autoscaling +5. Set up proper liveness and readiness probes + +::content-alert{type="important"} +The generated Helm Chart is a starting point that you should review and customize to match your production requirements and security best practices. +:: diff --git a/docs/docker-to-iac/parser/index.md b/docs/docker-to-iac/parser/index.md index e2753c7..67b1f04 100644 --- a/docs/docker-to-iac/parser/index.md +++ b/docs/docker-to-iac/parser/index.md @@ -9,3 +9,4 @@ Here you can find the list of available [parsers](/docs/docker-to-iac/parser-exp - [AWS CloudFormation](/docs/docker-to-iac/parser/aws-cloudformation.md) - [Render.com](/docs/docker-to-iac/parser/render.com.md) - [DigitalOcean](/docs/docker-to-iac/parser/digitalocean.md) +- [Helm (Kubernetes)](/docs/docker-to-iac/parser/helm.md) diff --git a/docs/docker-to-iac/publishing-to-npm.md b/docs/docker-to-iac/publishing-to-npm.md index fcb60e7..a4a0693 100644 --- a/docs/docker-to-iac/publishing-to-npm.md +++ b/docs/docker-to-iac/publishing-to-npm.md @@ -4,7 +4,7 @@ description: Explore our automated NPM publishing workflow for docker-to-iac. Fr # Publishing docker-to-iac module to NPM -We have created an organization @deploystack for NPM. Publishing in NPM happens automatically through `semantic-release`. Config: [https://github.com/deploystackio/docker-to-iac/blob/main/.github/workflows/release.yml](https://github.com/deploystackio/docker-to-iac/blob/main/.github/workflows/release.yml) +We have created an organization @deploystack for NPM. Publishing in NPM happens automatically through `semantic-release`. Config: [https://github.com/deploystackio/docker-to-iac/blob/main/.github/workflows/release-pr.yml](https://github.com/deploystackio/docker-to-iac/blob/main/.github/workflows/release-pr.yml) The prerequisite for a release is a successful pull request to the default branch `main`. This means that all tests must first be successfully completed. `semantic-release` creates a new version and automatically publishes the node package to: [https://www.npmjs.com/package/@deploystack/docker-to-iac](https://www.npmjs.com/package/@deploystack/docker-to-iac) diff --git a/docs/docker-to-iac/supported-registries.md b/docs/docker-to-iac/supported-registries.md index 8391aa4..34f039b 100644 --- a/docs/docker-to-iac/supported-registries.md +++ b/docs/docker-to-iac/supported-registries.md @@ -1,5 +1,6 @@ --- description: Complete guide to Docker registries in docker-to-iac - From official Docker Hub images to GHCR, learn supported formats with practical examples. +menuTitle: Supported Registries --- # Supported Registries for docker-to-iac module @@ -79,3 +80,4 @@ Here's how different registry types are handled: - If no tag is specified, `latest` is used as the default tag - The module preserves the original registry URL format for custom registries - SHA256 digests are supported for all registry types +- All supported registries work with all parsers, including AWS CloudFormation, Render.com, DigitalOcean App Platform, and Kubernetes Helm Charts diff --git a/docs/index.md b/docs/index.md index af62bd3..f37e8f6 100644 --- a/docs/index.md +++ b/docs/index.md @@ -4,7 +4,7 @@ description: Welcome to DeployStack documentation. Learn how to automate Docker # DeployStack Documentation -DeployStack converts your **Docker configurations** into **Infrastructure as Code** (IaC) templates for multiple cloud providers. Whether you have a docker-compose.yml file or docker run commands, it generates the necessary AWS CloudFormation, Render.com Blueprint, or DigitalOcean specifications for example. This lets you and your users deploy the same application consistently across different cloud platforms using their native deployment mechanisms, **without needing to manually create** each provider's infrastructure. +DeployStack converts your **Docker configurations** into **Infrastructure as Code** (IaC) templates for multiple cloud providers. Whether you have a docker-compose.yml file or docker run commands, it generates the necessary AWS CloudFormation, Render.com Blueprint, DigitalOcean specifications, or Kubernetes Helm charts for example. This lets you and your users deploy the same application consistently across different cloud platforms using their native deployment mechanisms, **without needing to manually create** each provider's infrastructure. ## Get Started @@ -43,6 +43,9 @@ DeployStack generates infrastructure templates for major cloud providers, each o :::card-item-image{title="Render.com" link="/docs/docker-to-iac/parser/render.com" imageWidth=130 imageHeight=28 src="/img/deploy/render.svg"} ::: +:::card-item-image{title="Helm" link="/docs/docker-to-iac/parser/helm" imageWidth=47 imageHeight=47 src="/img/deploy/helm.svg"} +::: + :: ### DeployStack Ecosystem From a3c9fecf66ff74fb4e9962a3b4f9fba482e6db69 Mon Sep 17 00:00:00 2001 From: Piotr Hajdas Date: Sun, 27 Apr 2025 14:10:07 +0200 Subject: [PATCH 2/2] fix: missing architecture image. --- docs/docker-to-iac/parser/helm.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/docs/docker-to-iac/parser/helm.md b/docs/docker-to-iac/parser/helm.md index a01b0e4..2b13ff5 100644 --- a/docs/docker-to-iac/parser/helm.md +++ b/docs/docker-to-iac/parser/helm.md @@ -19,12 +19,6 @@ To deploy the generated Helm Charts, you need: - Helm CLI installed (version 3.x recommended) - Appropriate RBAC permissions to deploy resources in your target namespace -## Architecture - -The Helm parser generates a complete Helm Chart structure that follows Kubernetes and Helm best practices: - -![Kubernetes Helm Architecture](/docs/assets/images/docker-to-iac/helm-kubernetes-architecture.png) - ### Kubernetes Resources The generated Helm Chart creates the following Kubernetes resources for each service in your Docker configuration: