Examples

Score examples

The following examples show how to use Score to deploy Applications and infrastructure configurations.

Each example highlights a particular use case and shows either a Score file (score.yaml), a Score extension file (humanitec.score.yaml), or both.

To use any particular example, use the humctl CLI and execute this command:

humctl score deploy \
              -f score.yaml \
              --extensions humanitec.score.yaml
              --app ${APP_ID} \
              --env ${ENV_ID} \
              --org ${HUMANITEC_ORG} \
              --token ${HUMANITEC_TOKEN} \

Usage notes:

If both files are shown, they must be used in conjunction.
If no Score file or no Score extension file is shown, no particular configuration is required through that file.
A Score extension file alone is never sufficient to perform a Workload Deployment. If no Score file is shown, you may choose one of your own, e.g. the Hello World example.
A Score file is picked up automatically if present in the same directory and named score.yaml.
A Score extension file is picked up automatically if present in the same directory and named humanitec.score.yaml.

Affinity

Define affinity rules that are added to Pods generated for the Workload.

humanitec.score.yaml (view on GitHub) :

apiVersion: humanitec.org/v1b1

spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd

Annotations

Define Annotations that are added to Pods generated for the Workload.

humanitec.score.yaml (view on GitHub) :

apiVersion: humanitec.org/v1b1

spec:
  annotations:
    annotationkey: annotationvalue
  service:
    annotations:
      serviceannotationkey: serviceannotationvalue

score.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

containers:
  demo:
    image: registry/my-image:1.0.0
service:
  ports:
    http:
      port: 80
      targetPort: 8080

Argument and command overrides

Provide overrides for container commands or arguments.

score.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

containers:
  demo:
    image: registry/my-image:1.0.0
    command: ["/bin/sh"]
    args: ["-c", "while true; do printenv && sleep 60; done"]

Cronjobs

Define schedules under which the Workload should run as a Kubernetes CronJob.

Refer to the schedules feature for configuration details.

The Score extension file specifies the humanitec/default-cronjob Workload Profile to use which supports the feature.

humanitec.score.yaml (view on GitHub) :

apiVersion: humanitec.org/v1b1
profile: humanitec/default-cronjob

spec:
  schedules:
    6-hour-run:
      containers:
        main-container:
          args:
            - "--hours"
            - "6"
      schedule: "15 1,7,13,19 * * *"

score.yaml (view on GitHub) :

apiVersion: score.dev/v1b1

metadata:
  name: my-cronjob

containers:
  main-container:
    image: registry/my-image:1.0.0

Environment variables

Define environment variables for a container. There are two ways to configure them.

Via the Score file

This definition supports placeholders. By default, variables will be visible in the Platform Orchestrator UI. Variables will be mapped into the container through a ConfigMap or Secret.
Via the Score extension file

This definition does not support placeholders. By default, variables will not be visible in the Platform Orchestrator UI. Variables will be mapped into the container as part of the container specification.

humanitec.score.yaml (view on GitHub) :

apiVersion: humanitec.org/v1b1

spec:
  containers:
    demo:
      env:
      - name: "SOME"
        value: "VARIABLE"

score.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

containers:
  demo:
    image: registry/my-image:1.0.0
    variables:
      API_KEY: "${resources.env.API_KEY}"
resources:
  env:
    # The type "environment" is available per the Score specification.
    type: environment

Files

Add files to Containers.

Refer to the files feature for configuration details.

The examples show these variations to provide file content:

score.yaml: Base approach supplying the file contents as a multiline string. This approach creates the same file content across all environments.
score-shared-values.yaml: (Recommended) Supplying the file contents via a Shared Value via the environment resource which is available as part of the Score specification. Since Shared Values may optionally be overridden on an Environment level, this approach lets you inject environment-specific configuration managed through the Platform Orchestrator.
score-local-file-source.yaml: Supplying the file contents via a file available locally which is read at Score deployment time, i.e. when executing humctl score deploy.

appsettings.json (view on GitHub) :

{
  "key1": "value1",
  "key2": "value2",
  "key3": "value3"
}

score-local-file-source.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

containers:
  demo:
    image: registry/my-image:1.0.0
    files:
      - target: /app/default.config
        mode: "0644"
        # The source references a locally available file
        # It is read by the humctl CLI when running "humctl score deploy"
        source: "./appsettings.json"

score-shared-values.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

containers:
  demo:
    image: registry/my-image:1.0.0
    files:
      - target: /app/default.config
        mode: "0644"
        # The content references the Shared Value APP_SETTINGS, available through the "env" resource declared below
        content: "${resources.env.APP_SETTINGS}"
resources:
  env:
    # The type "environment" is available per the Score specification
    type: environment

score.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

containers:
  demo:
    image: registry/my-image:1.0.0
    files:
      - target: /app/default.config
        mode: "0644"
        content: |
          [config]
          key=value

Labels

Define Labels that will be added to Pods or Services generated for the Workload.

humanitec.score.yaml (view on GitHub) :

apiVersion: humanitec.org/v1b1

spec:
  labels:
    labelkey: labelvalue
  service:
    labels:
      servicelabelkey: servicelabelvalue

score.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

service:
  ports:
    http:
      port: 80
      targetPort: 8080

containers:
  demo:
    image: registry/my-image:1.0.0

Overrides

Provide overrides for container commands or arguments.

score.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

containers:
  demo:
    image: registry/my-image:1.0.0
    command: ["/bin/sh"]
    args: ["-c", "while true; do printenv && sleep 60; done"]

Probes

Define liveness and readiness probes for your Workload.

Refer to the probe feature for configuration details.

humanitec.score.command.yaml (view on GitHub) :

apiVersion: humanitec.org/v1b1

spec:
  containers: 
    demo:
      liveness_probe:
        type: command
        command:
          - "bash"
          - "-c"
          - "/app/is_alive.sh"

humanitec.score.grpc.yaml (view on GitHub) :

apiVersion: humanitec.org/v1b1

spec:
  containers: 
    demo:
      liveness_probe:
        type: grpc
        port: 7001

humanitec.score.tcp.yaml (view on GitHub) :

apiVersion: humanitec.org/v1b1

spec:
  containers: 
    demo:
      liveness_probe:
        type: tcp
        port: 7001

score.http.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

containers:
  demo:
    image: registry/my-image:1.0.0
    livenessProbe:
      httpGet:
        path: "/alive"
        port: 8080
    readinessProbe:
      httpGet:
        path: "/ready"
        port: 8080

Resources

Specify the resources required for a container.

score.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

containers:
  demo:
    image: registry/my-image:1.0.0
    resources:
      limits:
        cpu: "0.250"
        memory: "256Mi"
      requests:
        cpu: "0.025"
        memory: "64Mi"

Route

A route resource defines how to route traffic to the Workload. See Routes and Ingress for details.

score.yaml (view on GitHub) :

# Example Score file for a Workload that has three routes from one DNS name
apiVersion: score.dev/v1b1
metadata:
  name: routes-example
service:
  ports:
    www:
      port: 80
      targetPort: 8080
containers:
  webserver:
    image: my-webservice:latest
resources:
  api-dns:
    type: dns
  users-route:
    type: route
    params:
      host: ${resources.api-dns.host}
      path: /users
      port: 80
  products-route:
    type: route
    params:
      host: ${resources.api-dns.host}
      path: /products
      port: 80
  checkout-route:
    type: route
    params:
      host: ${resources.api-dns.host}
      path: /checkout
      port: 80

Service

Define how a service for the Workload is configured.

Refer to the service feature for configuration details.

score.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

containers:
  demo:
    image: registry/my-image:1.0.0
service:
  ports:
    www:
      port: 8080
      targetPort: 3001
    stream:
      port: 19245
      targetPort: 19245
      protocol: UDP

Serviceaccount

Define the Kubernetes Service Account that Pods in the Workload should run as. It does not manage the creation of that Service Account.

Refer to the service-account feature for configuration details.

humanitec.score.yaml (view on GitHub) :

apiVersion: humanitec.org/v1b1

spec:
  serviceAccountName: data-access-service-account

Tolerations

Define tolerations rules that are added to Pods generated for the Workload.

humanitec.score.yaml (view on GitHub) :

apiVersion: humanitec.org/v1b1

spec:
  tolerations:
  - key: "my-example-key"
    operator: "Exists"
    effect: "NoSchedule"

Volumes

Define volumes and volume mounts for a Workload.

Volume mounts are declared in the volumes section of the Score file.

Volumes that are not provisioned through the Humanitec Resources System, e.g. emptyDir, are declared in the volumes section of the Score extension file. For mounting them, specify volumes.<name>, as the source in the volume mount in the Score file.

Volumes that are provisioned through the Resources system are not declared in the Score or Score extension file. For mounting them, specify their Resource ID, e.g. shared.nfs-share, as the source in the volume mount in the Score file.

Refer to the volumes and volume-mounts features for configuration details.

humanitec.score.yaml (view on GitHub) :

apiVersion: humanitec.org/v1b1

spec:
  # Volume declaration. Not required if the volume mount
  # references an externally declared volume,
  # i.e. one provisioned via the Platform Orchestrator
  # Resources system.
  volumes:
    tmp-pod:
      type: emptyDir
      source:
        sizeLimit: "1024Mi"

score.yaml (view on GitHub) :

apiVersion: score.dev/v1b1
metadata:
  name: my-workload

containers:
  demo:
    image: registry/my-image:1.0.0
    # Volume mount declaration referencing the volume from the Score extension.
    volumes:
      - source: "volumes.tmp-pod"
        target: /mnt/data
        path: "" # Shown for illustration purposes. Must be a relative path.
        readOnly: true

Examples

Score examples #

Affinity #

Annotations #

Argument and command overrides #

Cronjobs #

Environment variables #

Files #

Labels #

Overrides #

Probes #

Resources #

Route #

Service #

Serviceaccount #

Tolerations #

Volumes #

Score examples

Affinity

Annotations

Argument and command overrides

Cronjobs

Environment variables

Files

Labels

Overrides

Probes

Resources

Route

Service

Serviceaccount

Tolerations

Volumes