diff --git a/docs/architecture_en.md b/docs/architecture_en.md index 3ce891a4ed8466f6d47a4cafb547115de774fc0b..cc35834c920374df6ef977aea7a51f18044ec5b7 100644 --- a/docs/architecture_en.md +++ b/docs/architecture_en.md @@ -4,40 +4,40 @@ ![architecture](design/arch.jpg) -iSulad is an OCI-compliant container running engine that emphasizes simplicity, robustness, and lightweight. +iSulad is an OCI-compliant container runtime engine that emphasizes simplicity, robustness, performance and lightweight. -As a daemon process, it manages the entire container life cycle of the host system, including image transmission and storage, container execution and monitoring management, container resource management, and network management. iSulad provides Docker-like CLI man-machine interfaces for external systems. +As a daemon process, it manages the entire container life cycle of the host system, including image transmission and storage, container execution and monitoring management, container resource management, and network management. iSulad provides Docker-like CLI for users. -You can use Docker-like commands to manage containers and provides gRPC APIs that comply with the CRI interface standard for Kubernetes to invoke based on the CRI interface protocol. +You can use Docker-like commands to manage container images and iSulad provides gRPC APIs which comply with the CRI standard for Kubernetes. -For easily understanding, the behavior unit of the iSulad is divided into different modules, and the modules are roughly organized into subsystems. Understanding these modules, subsystems, and their relationships is key to modifying and extending iSulad. +iSulad is divided into different modules, and the modules are organized into subsystems. Understanding these modules, subsystems, and their relationships is important to modify and extend iSulad. -This document describes only the high-level function design of each module. For more information about each module, see the relevant design documents. +This document describes the high-level system architecture design. For more information about each module, please refer to the relevant design documents. ## Subsystem -You can interact with the iSulad by calling gRPC APIs provided by the subsystem. +You can interact with the iSulad by invoking gRPC APIs exported by the subsystem. -- **image service** : Image management service, which provides image-related operations, such as image download, query, and deletion. -- **execution service**: Container life cycle management service, which provides container-related operations, such as container creation, startup, and deletion. +- **image service** : Image management service, provides image-related operations, such as image download, query, and deletion. +- **execution service**: Container life cycle management service, provides container-related operations, such as container creation, startup, and deletion. - **network**:The network subsystem is responsible for network management capabilities of the pod of the CRI. When a pod is started, the pod is added to the network plane specified in the configuration file through the CNI interface. When a pod is stopped, the CNI API is used to remove the pod from the network plane where the pod is located and clear related network resources. ## Module - **image content** : Managing Image Metadata and Container File Systems -- **resource manage**: Container resource management, for example, setting available CPU and memory resource limits +- **resource manage**: Container resource management module, for example, setting available CPU and memory resource limits -- **Executor**:Runtime for executing actual container operations. The LCR is provided as the default runtime and can be extended through the plug-in mechanism. +- **Executor**:Runtime for executing actual container operations. The LCR acts as the default runtime and can be extended through the plug-in mechanism. -- **Events**:Container event collection +- **Events**:Container event collection module -- **Plugins**:Provides the plugin mechanism to extend container functions through different plugins. +- **Plugins**:Provides the plugin mechanism to extend container capabilities through different plugins. -- **HA**:The log mechanism is provided for fault locating. The garbage collection mechanism is provided to reclaim abnormal container resources such as D and Z. +- **HA**:This module provides fault locating and garbage collection service. ### Network architecture design -The following figure shows the architecture: +The figure shows the architecture: ![CNI_architecture](./design/CNI_architecture.png) diff --git a/iSulad.spec b/iSulad.spec index d504ffe22e0d3a1549867740403f74edfedacf7d..22655b69ef2cd8f15db58c65be6122a0282411cc 100644 --- a/iSulad.spec +++ b/iSulad.spec @@ -1,5 +1,5 @@ %global _version 1.1.12 -%global _release 20200311.212052.git8d13b09e +%global _release 20200317.200806.git18c7747a %global is_systemd 1 %global debug_package %{nil} diff --git a/src/contrib/config/systemcontainer_config.json b/src/contrib/config/systemcontainer_config.json index dfef975eca69c46dba7f2705a2ee48adcd83130b..36c4fb94be1b5b8831b082e826549d4fb97fe95c 100644 --- a/src/contrib/config/systemcontainer_config.json +++ b/src/contrib/config/systemcontainer_config.json @@ -96,6 +96,18 @@ "ro" ] }, + { + "destination": "/dev/shm", + "type": "tmpfs", + "source": "shm", + "options": [ + "nosuid", + "noexec", + "nodev", + "mode=1777", + "size=65536k" + ] + }, { "destination": "/sys/fs/cgroup", "type": "cgroup", diff --git a/src/libisula.c b/src/libisula.c index 4ea923efca7d706f1bdf91572c1f1edb6bb9f511..3a6fdedb341d34b6ac328fbfe8dcf548914ca992 100644 --- a/src/libisula.c +++ b/src/libisula.c @@ -211,6 +211,13 @@ void isula_info_response_free(struct isula_info_response *response) free(response->no_proxy); response->no_proxy = NULL; + + free(response->driver_name); + response->driver_name = NULL; + + free(response->driver_status); + response->driver_status = NULL; + free(response); } diff --git a/src/services/execution/execute/execution_create.c b/src/services/execution/execute/execution_create.c index 02fb7995a1e02c54cc1b61d5879bebe406b857b7..037587559c4909bfc52bfec67744df14d10b78da 100644 --- a/src/services/execution/execute/execution_create.c +++ b/src/services/execution/execute/execution_create.c @@ -603,6 +603,10 @@ void umount_share_shm(container_t *cont) if (cont->hostconfig == NULL) { return; } + // ignore shm of system container + if (cont->hostconfig->system_container) { + return; + } if (cont->hostconfig->ipc_mode == NULL || is_shareable(cont->hostconfig->ipc_mode)) { if (cont->common_config == NULL || cont->common_config->shm_path == NULL) { return; diff --git a/src/services/execution/spec/specs_mount.c b/src/services/execution/spec/specs_mount.c index 62498cdf3bfad358b8b0bf1579f2422f98fffbe8..979be1e78137b33ded1ef328fc080bbfa9538e3b 100644 --- a/src/services/execution/spec/specs_mount.c +++ b/src/services/execution/spec/specs_mount.c @@ -2276,6 +2276,10 @@ static int setup_ipc_dirs(oci_runtime_spec *oci_spec, host_config *host_spec, char *tmp_cid = NULL; char *right_path = NULL; + // ignore shm of system container + if (host_spec->system_container) { + return 0; + } // setup shareable dirs if (host_spec->ipc_mode == NULL || is_shareable(host_spec->ipc_mode)) { return prepare_share_shm(oci_spec, host_spec, v2_spec);