Object types
In Containerum a user can generally operate the following objects:
Project
Project is the main object of Containerum system. To create a project a user needs to allocate RAM and CPU resources to the project. All other system objects (deployments, services, etc.) exist only within a Project. As part of teamwork, project owners can share their projects with other users and set access levels to create new software together.
Project consists of the following fields:
Field | Type | Description | Example |
---|---|---|---|
id | uui4 | Object identifier, which is the real project name in Containerum system. Should be unique for every project. | 8d616b02-1ea7-4842-b8ec-c6e8226fda5b |
label | string | Object name, set by a user. It doesn't have to be unique, as Containerum API uses the id field for routing. | myNamespace |
owner | uui4 | Identifier of the project owner, which is a user identifier inside Containerum system. There can only be one project owner. | 20b616d8-1ea7-4842-b8ec-c6e8226fda5b |
access | string | User access level in the project. Available values: owner, write, read. | owner |
resources: | object | Resources allocated to the project. | |
|
object | Allocated resources. | |
|
uint | Allocated CPU. To simplify CPU allocation Containerum uses only mCPU units. mCPU = 10**-3 CPU. | 100 |
|
uint | Allocated RAM. To simplify RAM allocation Containerum uses only Mi units. | 128 |
|
object | Actually used resources. | |
|
uint | Used CPU value in mCPU. | 50 |
|
uint | Used RAM value in Mi. | 100 |
Deployment
Deployment is an object that contains the configuration of running applications. It has a large number of parameters, that can be set during deployment creation. One of the main parameters is a container. Containers describe images, resources, environment variables, etc. that are necessary for user applications to run properly. One or more applications can run in one deployment. Users can describe apps in separate deployments and connect them using internal services or describe apps as different containers belonging to the same deployment. In this case, applications are accessible to each other by the container name and port. A user can bind configmaps to deployments to use configuration files, certificates, etc. Containerum deployments support revision control. When a user updates a deployment image, the new revision will be saved in Containerum. User can get a revision list, rename a revision, rollback to any selected version, etc. Containerum uses semantic versioning for deployments.
Deployment consists of the following fields:
Field | Type | Description | Example |
---|---|---|---|
name | string | Object name. Should be unique within a Project. | myDeployment |
replicas | uint | Number of application replicas. Available values: 0..15. If a user sets replicas to 0, every pod for the chosen deployment will be terminated. | 1 |
containers: | array | Container list. | |
|
string | Container name. Should be unique within a Deployment. | myContainer |
|
string | App Docker image. | nginx |
|
object | Resources allocated for a container. | |
|
uint | Allocated CPU. To simplify CPU allocation Containerum uses only mCPU units. mCPU = 10**-3 CPU. | 100 |
|
uint | Allocated RAM. To simplify RAM allocation Containerum uses only Mi units. | 128 |
|
array objects | Environments list. | |
|
string | Environment name. | CONTAINERUM_API |
|
string | Environment value. | https://api.containerum.io |
|
array objects | Configmap list. | |
|
string | Configmap name. Should be unique within a Project. | myConfigmap |
|
string | Path for a configmap to mount to. It is a path inside the container file system. | /home/user |
Pod
Pod is an object that constitutes one running deployment replica. Although a deployment contains configuration data, pod is actually a running application. A pod cannot exist without a deployment, while a deployment can have no pods. When a user creates a deployment with 4 replicas, 4 pods will be created. In this case, each of them utilizes the amount of resources utilized by all containers in the parent deployment. When a user deletes a pod, a new one with the same configuration will be created. Containerum allows viewing logs for pods.
Service
Service is an object, used by applications for communication with each other within Containerum ecosystem or with external applications. A service can be internal or external. An internal service connects deployments by the internal network of Kubernetes. External services allow users to access the deployment from the Internet. Each service can have several ports using TCP or UDP protocol.
Service consists of the following fields:
Field | Type | Description | Example |
---|---|---|---|
name | string | Object name. Should be unique within a Project. | myService |
deploy | string | Target deployment. It is necessary to choose the target application. | myDeployment |
ports: | array objects | Ports list. | |
|
string | Port name. Should be unique within a service. | myPort |
|
uint(11000-65535) | External port. For an external service it is a port, that allows users to access the deployment from the Internet. For an internal service it is a port, that allows a chosen deployment to communicate with another deployment within the cluster. | 8080 |
|
uint(1-65535) | Internal port. The port of deployment, where a running app is launched. In Dockerfile this is a port from EXPOSE instruction. | 80 |
|
string | Port protocol. TCP or UDP are supported. | TCP |
Domain (Ingress)
Domain (Ingress) is an object that controls access to services through DNS which is available at the Domains tab in Containerum Platform. Domains (Ingresses) can work through http or secure https protocols and support TLS-protocol. Users can use standard Let’s Encrypt certs or their own certificates. Domains (Ingresses) can contain rules for routing across several domains and different paths. For example, a Domain hello.hub.containerum.io/ leads to the service svc0 of the main application, while hello.hub.containerum.io/blog is connected to the service svc1 of the blog application.
Ingress consists of the following fields:
Field | Type | Description | Example |
---|---|---|---|
name | string | Object name. Should be unique within a Project. | myIngress |
rules: | array objects | Routing rules list. | |
|
string | Domain URL. | hello.hub.containerum.io |
|
string | TLS support. If supported, secret name should be specified. | tls-cert |
|
array objects | Paths list. | |
|
string | URL path. | /project |
|
string | Target service. It is necessary to choose a target service. | myService |
|
uint(11000-65535) | Target port of the selected service. | 8080 |
Configmap
Configmap is an object that is basically a key-value storage. It can contain any text data, for example, configuration artifacts, certificates, keys or environment variables. Configmap data is stored without any encryption, so you should only add the data that does not have additional security requirements.
Configmap consists of the following fields:
Field | Type | Description | Example |
---|---|---|---|
name | string | Object name. Should be unique within a Project. | myConfigmap |
data | object | Data that contains information in the key-value format, like key0:value0, key1:value1. In general, the key is the name of the downloaded file, and the value is the file data. | 1.txt:Hello World |