Containerized Deployment of Chinese Domestic Operating Systems: A Production-Grade Practice Guide
As Chinese domestic operating systems (such as Kylin Server) are increasingly adopted in critical industries, teams need practical ways to run and validate applications on these platforms. This guide explains how to deploy these OS environments in containers instead of on physical machines or VMs. It clarifies which scenarios are suitable and which are not, explains how to match container images to host CPU architectures (ARM and x86), walks through a minimal Docker deployment and verification workflow, and covers production-grade practices including Dockerfile-based image builds, the single-process principle, why systemd should stay out of containers, health checks, resource limits, restart policies, and a post-deployment go-live checklist.
Containerized Deployment of Chinese Domestic Operating Systems: A Production-Grade Practice Guide
As China’s domestically produced software and hardware ecosystem accelerates its rollout across critical industries, a growing number of teams need to run applications based on Chinese domestic operating systems in development, test, and production environments. The conventional approach relies on physical machines or virtual machines for system installation, dependency setup, and application deployment. Although intuitive, this method falls short in environment consistency, migration efficiency, and resource utilization. Carrying a domestic OS environment in a container preserves the system’s security capabilities and ecosystem compatibility while adding the benefits of standardized delivery and lightweight execution.
It is important to be clear, however, that a domestic OS container image is not a direct replacement for a virtual machine. Containers and VMs differ fundamentally in design goals, isolation level, and operational model. Treating a container like a VM—stacking an SSH service, cron jobs, system daemons, and multiple business processes into the image—degrades observability, orchestration, and fault diagnosis. This article therefore does not focus on demonstrating how to “stuff an entire OS into a container.” Instead, from a production-grade perspective, it explains how to properly deploy and validate a containerized domestic OS environment.
1. Draw the Boundaries First: When It Fits and When It Doesn’t
A containerized domestic OS environment is mainly suitable for two clearly defined scenarios.
The first is commercial software that has a hard requirement for a complete domestic OS runtime but only needs to run temporarily or for short-term validation. A container can provide a directory structure, base libraries, and security policies that closely match the target system, so you don’t have to provision a physical machine or VM just for a single validation run.
The second is compatibility and adaptation testing for domestic applications. During development and testing, teams often need to quickly spin up multiple system environments of different versions or architectures to verify application compatibility. The ability of containers to start and be destroyed within seconds significantly reduces environment preparation costs.
Conversely, the following scenarios are not recommended:
- Using the domestic OS image as a general-purpose base image for long-running business workloads
- Integrating SSH, cron jobs, multiple services, and system daemons into a single container
- Fully replacing VMs with containers for traditional system administration duties
- Running these container workloads as multi-service workloads on an orchestration platform
The core reason for these restrictions is that containers share the host kernel and do not have an independent OS kernel. The system image inside a container provides mainly a user-space runtime environment, not full operating system capabilities. Forcing a large number of background services to start inside the container leads to chaotic process management, hard-to-attribute resource contention, and exclusion from standardized health checks, rolling upgrades, and log collection.
2. Before Deployment: Confirm the Architecture and Choose the Right Image
Domestic servers typically come in several CPU architectures, most commonly ARM and x86. ARM is widely used with domestic Chinese processor platforms, while x86 is compatible with traditional server environments. The container image must match the host architecture; otherwise, startup fails immediately.
Run the following command to confirm the current server architecture:
uname -m
Common outputs include aarch64 and x86_64. In practice, select the image tag that corresponds to your architecture—do not run an ARM image on an x86 host, or vice versa.
On image versions: domestic operating systems usually offer multiple major versions and update releases. These versions differ in hardware driver support, database compatibility, and security updates. For scenarios that involve adapting domestic databases, middleware, or office software, newer versions generally offer better compatibility. In production, however, version selection should not simply chase the latest release. Base the decision on the target application’s official compatibility notes, system patch requirements, and your internal software asset inventory.
3. The Core Value of Containerized Deployment
Compared with traditional VM deployment, the containerized approach delivers value in three main ways.
Environment consistency. Domestic applications often show the classic pattern of “passes on the developer’s machine, fails in the test environment, errors in production.” The usual causes are different base system versions, missing dependency libraries, or divergent security policies. When the application and its required system environment are packaged into a single image, development, test, and production all receive the same image, which effectively reduces the uncertainty caused by environment drift.
Resource efficiency. A lightweight system image is typically only a few hundred megabytes, and startup completes within seconds. Compared with a VM, which must boot a full operating system and initialize a large number of system services, a container has a much shorter startup path and a lower memory footprint. On domestic servers with limited resources, containerized deployment increases deployment density per machine.
Version isolation. When an enterprise runs both new and legacy domestic business systems, it may need to keep several versions of the base system environment side by side. Containers natively isolate processes and filesystems, so multiple system containers of different versions can run in parallel on the same host without interfering with one another. This is far more efficient than maintaining multiple separate VM images.
4. Example Deployment Workflow
The following example shows a minimal deployment and verification workflow. It uses generic container commands and does not rely on any cloud-vendor-specific capabilities.
1. Pull the image
Select the tag that matches your host architecture:
docker pull registry.example.com/kylin-server:v10-sp3-arm64
In real usage, replace the registry address, version tag, and access credentials with the information provided by your internal image registry.
2. Run a temporary container
To verify that the image is usable, start a temporary container first:
docker run --rm -it \--name kylin-check \registry.example.com/kylin-server:v10-sp3-arm64 \/bin/bash
The --rm flag ensures the container is cleaned up automatically when it exits, avoiding leftover containers.
3. Verify system information
Inside the container, run the following commands to confirm the system version and kernel information:
cat /etc/os-releaseuname -a
Note that the distribution information shown inside the container comes from the system files baked into the image, while the kernel information comes from the host. This is one of the key differences between containers and VMs.
4. Install the target application’s dependencies
If the application requires additional dependencies, install them inside the container with the corresponding package manager. For example:
yum install -y some-package
After installation, record the dependency list so it can later be baked into an image or deployment script.
5. Persist the runtime environment
Once the dependencies are confirmed to be complete, you can commit the current container as a new image for later reuse:
docker commit kylin-check kylin-app:latest
The better practice, however, is to write a Dockerfile and produce a reproducible image through a build process, which avoids the lack of transparency that comes with manual operations.
5. Runtime Constraints and Cautions
Even when deploying a domestic OS environment with containers, the following constraints must be observed.
Single-process principle. The container’s main process should focus on the actual business workload. Do not run SSH services, cron jobs, or system logging services as persistent processes in the same container. When multiple business processes run in one container, process exit handling, resource attribution, and signal handling all become complicated, which hurts fault diagnosis and automated operations.
Do not use this OS image as a general-purpose base image. The value of a domestic OS image lies in providing a specific runtime environment, not in replacing general-purpose base images. If every business workload starts from this image, image size balloons, maintenance costs rise, and unnecessary system components creep in. General business workloads should still use lightweight base images; use the domestic OS image only when the domestic environment is explicitly required.
Do not enable systemd. Starting systemd inside a container requires special privileges and additional configuration, and it pulls in a large number of background services. This runs against the container process model and can leave the container unable to exit properly or cause health checks to fail. System-level service management should be left to the host or the orchestration platform.
Configure health checks correctly. Once the container is running, use a health check endpoint or a liveness command to determine whether the business is healthy, rather than merely checking whether the container is in the running state. This helps detect application-layer failures promptly and trigger a restart or take the instance out of rotation.
6. Production-Grade Recommendations for Images and Runtime Configuration
To meet production requirements, build a dedicated application image on top of the default base image and follow these practices.
Use a Dockerfile to declare the base image, dependency installation, and environment variables explicitly:
FROM registry.example.com/kylin-server:v10-sp3-arm64RUN yum install -y some-package && \yum clean allENV APP_ENV=productionCMD ["/app/start.sh"]
When running the container, declare resource limits and the restart policy explicitly:
docker run -d \--name kylin-app \--restart=unless-stopped \--memory=2g \--cpus=2 \--health-cmd="curl -f http://localhost:8080/health || exit 1" \--health-interval=30s \--health-timeout=5s \--health-retries=3 \kylin-app:latest
This configuration retains the integrity of the domestic OS environment while complying with the norms of running containers in production.
7. From Deployment to Validation: A Go-Live Checklist
After deployment, validate each of the following items:
- The container starts and stays in the running state
- The system version information matches expectations
- Application dependencies are complete and the service starts normally
- The health check reports healthy
- Logs are accessible via standard output or a log collection system
- The business recovers automatically after the container restarts
- Resource usage stays within the expected range
- No extraneous persistent system services are present
Only when all of these conditions are met is the workload ready for production. Containerized deployment of a domestic OS environment is, at its core, a standardized way of delivering software. Only by respecting the design boundaries of containers can you gain both the ecosystem advantages of the system and the delivery efficiency of cloud native.
