Executive Summary
In zCX environments, container startup is currently non-deterministic when external network dependencies (such as NFS over AT-TLS) are required. The platform lacks native mechanisms for dependency management, startup ordering, and retry logic for failed mounts. This forces customers to implement custom orchestration within containers, increasing complexity and operational risk. Introducing platform-level support for pre-start dependency management would significantly improve reliability, simplify architectures, and align zCX with modern container platform expectations.
Summary
In IBM zCX environments, there is currently no native mechanism to guarantee the availability of external network dependencies (such as NFS accessed via AT-TLS) before Docker containers are started. This limitation introduces startup instability and forces customers to implement custom orchestration logic within containers.
We propose introducing a platform-level capability to manage pre-start network dependencies, ensuring that required services are available before container initialization.
Background and Context
In our current architecture:
- Application containers depend on NFS volumes hosted on z/OS
- NFS access must be secured via AT-TLS
- Due to AT-TLS constraints, an intermediary proxy layer (e.g., HAProxy) is required
- This proxy must be available before any container attempts to mount NFS volumes
However:
- zCX starts all containers in parallel at system startup
- Docker does not retry failed NFS mounts
- There is no native dependency management or startup ordering mechanism
As a result, if the proxy layer is not fully available at the time of container startup, NFS mounts fail and application containers remain down.
Current Workaround
To mitigate this, we implemented a custom “watchdog” container that:
- Starts independently (no NFS dependencies)
- Waits for NFS service availability
- Dynamically starts application containers using docker-compose
- Continuously monitors and restarts services if needed
While effective, this approach:
- Introduces additional architectural complexity
- Requires Docker socket access inside a container
- Blurs the separation between infrastructure and application layers
- Adds operational overhead for maintenance and updates
Problem Statement
The lack of a platform-level mechanism for:
- Startup ordering
- Dependency management
- Retry logic for external resources (e.g., NFS mounts)
forces customers to implement custom orchestration patterns that would typically be handled by the container platform itself.
This is particularly impactful in scenarios involving:
- Secure network configurations (e.g., AT-TLS)
- Externalized configuration via network file systems
- Multi-container applications with shared dependencies
Proposed Enhancement
We suggest introducing one or more of the following capabilities within zCX:
Option A — Pre-Startup Dependency Checks
A mechanism to define network dependencies (e.g., host:port availability) that must be satisfied before container startup.
Option B — Startup Ordering / Dependencies
Support for defining dependencies between containers, ensuring correct startup sequencing.
Option C — Retry Logic for Volume Mounts
Automatic retry of failed volume mounts (especially NFS) during container startup.
Option D — Platform-Managed Network Proxy (Optional)
Provide a built-in, supported network proxy capability as part of the zCX runtime (bundled with the base environment), to enable secure access to external services (e.g., NFS over AT-TLS) without requiring customer-managed proxy containers.
This capability could be implemented using a standard proxy technology (e.g., HAProxy or equivalent), but the key requirement is that it is platform-managed, available at startup, and independent from application container lifecycle.
Business Impact
Without this capability:
- Application startup is non-deterministic after zCX restarts
- Manual intervention or custom automation is required
- Increased operational complexity and support effort
- Higher risk of service downtime
With this enhancement:
- Improved reliability and determinism of container startup
- Reduced need for custom orchestration logic
- Cleaner architectural separation
- Better alignment with modern container platform expectations
Additional Notes
This request is not tied to a specific implementation (e.g., HAProxy), but rather to the broader need for managing infrastructure-level dependencies in a consistent and supported way within zCX.
Conclusion
Introducing native support for pre-start dependency management would significantly improve robustness, usability, and architectural clarity for zCX-based solutions, especially in enterprise environments leveraging secure z/OS networking features.
We believe this enhancement would benefit multiple customers facing similar integration patterns.
