Skip to content

Quickstart 1: Basics

This quickstart will guide you along the steps required towards manually deploying a simple web application on the WoK platform.

Warning

This quickstart requires:

  • Access to the WoK platform
  • Usage of the OKD CLI

WIP: WorkInProgress

Requesting a project on the WoK platform

The Project resource is not a Kubernetes Vanilla concept (ie. you will not find them in Vanilla Kubernetes clusters) but is an Openshift/OKD construct. It mostly allows for Openshift/OKD specific mechanisms (such as WebUI displays, ownership definition, etc). Every Project is thightly coupled with a regular Kubernetes Namespace.

On the WoK platform clusters, regular users cannot create projects. In order to proceed with this quickstart guide, you must request for a project creation.

Discovering existing resources

So you've got a fresh new project on the WoK cluster. Let's see what's there.

$ oc get all
No resources found in test-mkdocs-qs1 namespace.

There is nothing to see. It makes sense, it's a new project right ?

Well... not so much. The oc get all command will only show you a specific set of resources. Those types that are flaged, upon their definition as a cluster resource, as to be shown when requesting the all flag. This is counter intuitive.

When a project is created, several resources are also created. This list varies, from one cluster to another, and may change over time. Those resources are usually difined by the cluster administrators and the reasons for their existence may vary.

For instance, in a new project you can find ServiceAccounts that are automatically created:

$ oc get sa
NAME       SECRETS   AGE
builder    1         17h
default    1         17h
deployer   1         17h

Tip

Most resources API defined "shorthands" for interacting with them more easily. Here sa was used in place of the full name serviceaccounts. This is for convenience only.

Those 3 ServiceAccounts have specific roles and are intended for project specific uses:

  • default: This is the default ServiceAccount that will be used by Pods unless stated otherwise.
  • builder: This is the default ServiceAccount for BuildConfig jobs. It has specific access to the internal cluster image registry.
  • deployer: This is the default ServiceAccount for DeployConfig jobs. It has specific access to the internal cluster image registry.

Note

The builder and deployer service accounts are very specific to Openshift/OKD native workflows, leveraging BuildConfigs and DeployConfigs. Most users will most likely never use them and they could very well be forgoten about.

You can also display RoleBindings associated to these ServiceAccounts:

$ oc get rolebindings
NAME                    ROLE                               AGE
admin                   ClusterRole/admin                  17h
system:deployers        ClusterRole/system:deployer        17h
system:image-builders   ClusterRole/system:image-builder   17h
system:image-pullers    ClusterRole/system:image-puller    17h
view                    ClusterRole/view                   17h

$ oc describe rolebinding/system:deployers
Name:         system:deployers
Labels:       <none>
Annotations:  openshift.io/description:
                Allows deploymentconfigs in this namespace to rollout pods in this namespace.  It is auto-managed by a controller; remove subjects to disa...
Role:
  Kind:  ClusterRole
  Name:  system:deployer
Subjects:
  Kind            Name      Namespace
  ----            ----      ---------
  ServiceAccount  deployer  test-mkdocs-qs1