API Resources

All resources in Rancher are owned or created by an account.

An API Key provides access to the Rancher API if access control has been turned on. The access key and secret key pair are created per environment and can be used to directly call the API or used with rancher-compose.

The audit log provides a list of API requests. It logs the environment as well as the API call. After access control is enabled, it also logs the user.

A certificate is used to add in SSL termination to load balancers.

A container is a representation of a Docker container on a host.

A “dnsService” in the API is referred to as a Service Alias in the UI and the Rancher documentation. In the API documentation, we’ll use the UI terminology. A service alias allows the ability to add a DNS record for your services to be discovered.

An external service allows the ability to add any IP or hostname as a service to be discovered as a service.

Hosts are the most basic unit of resource within Rancher and is represented as any Linux server, virtual or physical, with the following minimum requirements.

* Any modern Linux distribution with a supported version of Docker.
* Must be able to communicate with the Rancher server via http or https through the pre-configured port (Default is 8080).
* Must be routable to any other hosts belonging to the same environment to leverage Rancher’s cross-host networking for Docker containers.

Rancher also supports Docker Machine and allows you to add your host via any of its supported drivers.

An identity is Rancher’s representation of an object(i.e. ldap_group, github_user) when Rancher has turned on access control. The externalId in an identity is the unique identifier in the authentication system that represents the object. The role of an identity is always null unless it is being returned as the identity of a projectMember.

Rancher implements a managed load balancer using HAProxy that can be manually scaled to multiple hosts. A load balancer can be used to distribute network and application traffic to individual containers by directly adding them or “linked” to a basic service. A basic service that is “linked” will have all its underlying containers automatically registered as load balancer targets by Rancher.

Machines are created whenever Rancher uses docker-machine to create hosts in Rancher. Adding any type of host through the UI that is not the custom command option is calling docker-machine and a machine entry will be created as well as a host.


The networks available within Rancher that containers could be launched on.

A network driver is the


A “project” in the API is referred to as an environment in the UI and Rancher documentation. In the API documentation, we’ll use the UI terminology. All hosts and any Rancher resources (i.e. containers, load balancers, etc.) are created and belong to an environment. Access control to who can view and manage these resources are then defined by the owner of the environment. Rancher currently supports the capability for each user to manage and invite other users to their environment and allows for the ability to create multiple environments for different workloads. For example, you may want to create a “dev” environment and a separate “production” environment with its own set of resources and limited user access for your application deployment.

A “project member” in the API is referred to as an environment members in the UI and Rancher documentation. An environment member is a list of all of the members of the environment. An environment member is an identity.




A registry is where image repositories are hosted. The repository can be either from DockerHub, Quay.io, or a custom private registry.

A registry credential is used to authenticate against a registry.

Rancher adopts the standard Docker Compose terminology for services and defines a basic service as one or more containers created from the same Docker image. Once a service (consumer) is linked to another service (producer) within the same stack, a DNS record mapped to each container instance is automatically created and discoverable by containers from the “consuming” service. Other benefits of creating a service under Rancher include”








A volume can be associated to containers or storage pools.

* A container can have many volumes and containers are mapped to volumes the mount link on a container.
* A storage pool owns many volumes. The volume is only available to containers deployed on hosts that are part of the storage pool. When a volume is being created, you do not directly associate it to a storage pool. You will only need to specify a driver and during allocation, Rancher will resolve it to a storage pool.

Edit this page