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.
Field | Type | Create | Update | Default | Notes |
---|---|---|---|---|---|
description | string | Optional | Yes | - | |
members | array[projectMember] | Optional | - | - | |
name | string | Optional | Yes | - | |
projectTemplateId | projectTemplate | Optional | - | - | |
servicesPortRange | servicesPortRange | Optional | Yes | - | |
virtualMachine | boolean | Optional | Yes | - |
Field | Type | Notes |
---|---|---|
defaultNetworkId | network | |
healthState | string | |
id | int | The unique identifier for the project |
orchestration | string | |
version | string |
Please read more about the common resource fields. These fields are read only and applicable to almost every resource. We have segregated them from the list above.
/v2-beta/projects/${PROJECT_ID}/projects/${ID}?action=activate
/v2-beta/projects/${PROJECT_ID}/projects/${ID}?action=deactivate
/v2-beta/projects/${PROJECT_ID}/projects/${ID}?action=defaultNetworkId
/v2-beta/projects/${PROJECT_ID}/projects/${ID}?action=setmembers
/v2-beta/projects/${PROJECT_ID}/projects/${ID}?action=upgrade