ashupednekar / ashupednekar/compose
support for poststart Commands
- Dominant language
- Go
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
### Enhancement: Support for PostStart Commands Using Dependent Containers
#### Description
Add support for Kubernetes `postStart` lifecycle hooks in the `compose` tool by leveraging dependent containers to execute initialization tasks defined in Helm charts. This approach ensures compatibility with complex charts requiring post-startup commands or scripts, such as database migrations, configuration setups, or service warm-ups, while aligning with Docker Compose's architecture.
#### Proposed Implementation
- **Parsing**: Parse `postStart` commands from container specs in Helm-rendered Kubernetes manifests.
- **Translation**: Create dependent containers in the generated `docker-compose.yaml` to handle `postStart` tasks. These containers will:
- Use the same image as the main container or a lightweight alternative (e.g., `busybox`).
- Execute the `postStart` command/script as their entrypoint.
- Be configured with `depends_on` to ensure they run after the main container starts.
- **Execution**: Use Docker Compose's `condition: service_completed_successfully` for dependent containers to ensure `postStart` tasks complete before the main container proceeds, mimicking Kubernetes `postStart` behavior.
- **Configuration**: Add CLI flags/options to `compose` (e.g., `--enable-poststart`) to toggle or customize dependent container generation for `postStart` hooks.
#### Benefits
- Seamless integration with Docker Compose's dependency management.
- Maintains isolation of `postStart` tasks from the main container's process.
- Enhances compatibility with Helm charts using lifecycle hooks.
- Simplifies debugging and monitoring of initialization tasks.
#### Acceptance Criteria
- Successfully convert a Helm chart with `postStart` hooks to a `docker-compose.yaml` with dependent containers.
- Dependent containers execute `postStart` commands correctly after the main container starts.
- Main container waits for `postStart` tasks to complete (if required) before proceeding.
- CLI flag/option works to enable/disable `postStart` support.
- Minimal performance overhead from additional containers.
#### Example
For a Helm chart with a `postStart` command like `sh -c 'sleep 5 && /init.sh'`, generate:
```yaml
services:
main-app:
image: my-app:latest
# Other configurations
poststart-main-app:
image: busybox:latest
command: sh -c 'sleep 5 && /init.sh'
depends_on:
main-app:
condition: service_started
```
Contributor guide
No contributing guide indexed for this repository
Research direction
No files or tests are named. Start by locating the compose CLI, Helm-rendered manifest parsing, and Docker Compose generation entry points, then determine how lifecycle hooks and dependency conditions are represented. Done means the proposed flag controls conversion and an example chart produces dependent containers that execute postStart commands with the required ordering.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker-compose, go, helm, kubernetes
- Domain
- cli, devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100