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.
  • hard:
object Allocated resources.
    • cpu
uint Allocated CPU. To simplify CPU allocation Containerum uses only mCPU units. mCPU = 10**-3 CPU. 100
    • memory
uint Allocated RAM. To simplify RAM allocation Containerum uses only Mi units. 128
  • used:
object Actually used resources.
    • cpu
uint Used CPU value in mCPU. 50
    • memory
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.
  • name
string Container name. Should be unique within a Deployment. myContainer
  • image
string App Docker image. nginx
  • limits:
object Resources allocated for a container.
    • cpu
uint Allocated CPU. To simplify CPU allocation Containerum uses only mCPU units. mCPU = 10**-3 CPU. 100
    • memory
uint Allocated RAM. To simplify RAM allocation Containerum uses only Mi units. 128
  • env:
array objects Environments list.
    • name
string Environment name. CONTAINERUM_API
    • value
string Environment value. https://api.containerum.io
  • config_maps:
array objects Configmap list.
    • name
string Configmap name. Should be unique within a Project. myConfigmap
    • mount_path
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.
  • portname
string Port name. Should be unique within a service. myPort
  • port
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
  • target_port
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
  • protocol
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.
  • host
string Domain URL. hello.hub.containerum.io
  • tls_secret
string TLS support. If supported, secret name should be specified. tls-cert
  • path:
array objects Paths list.
    • path
string URL path. /project
    • service_name
string Target service. It is necessary to choose a target service. myService
    • service_port
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