Configuring Services

To define a service, create a Prodvana config in a directory of your choosing, e.g. if you have an existing directory you use to store other configurations for the service, use that.

service:
  name: my-service
  application: my-application
  programs:
    # name of the program
  - name: program-name
    imageRegistryInfo:
      # name of the container registry integration (see ${org}.prodvana.io -> Integrations)
      containerRegistry: dockerhub-public
      # name of the image repository for this registry
      imageRepository: library/nginx
    imageTag: 1.22-alpine
    # (optional) command to run
    cmd:
    - nginx
    - '-g'
    - daemon off;

  # (optional) replica settings
  replicas:
    fixed: 5
  # set to NONE for now, will undo later
  parametersAutogen: NONE

Use pvnctl to apply this config file:

pvnctl configs apply path/to/my-service.pvn.yaml

Once applied, the service will be configured but not deployed. You can see it by going to my-demo-organization.prodvana.io -> Applications -> your app -> your service.

Deploying from UI

To deploy the service from the service UI, click on "deploy" and follow the on-screen instructions.

Parametrizing from UI

You can define parameters in your service config that can then be set at push time in the UI. This is useful to allow fast changes of safe fields, such as replica count or container image, without having to go through a code commit.

Additionally, Prodvana can automatically define common parameters, as controlled by autogen_parameters in your service config. Valid values are:

  • NONE - do not automatically generate any parameters.
  • IMAGE - generate a parameter per program to allow changing the images from the UI
  • IMAGE_AND_REPLICAS - IMAGE + generate a parameter to change the fixed replica count

If unset, the default behavior is IMAGE.

Below is what the deploy screen looks like with autogen_parameters set to IMAGE.

IMAGE_AND_REPLICAS

Custom Parameters

Custom parameters can be defined and then used as go templates under {{.Params.param-name}}. For example:

service:
  name: nginx
  application: my-app
  programs:
  - name: nginx
    imageRegistryInfo:
      containerRegistry: dockerhub-public
      imageRepository: library/nginx
    imageTag: 1.22-alpine
    env:
      ENVIRONMENT:
        value: "{{.Params.env}}"
  replicas:
    fixed: 5
  parametersAutogen: IMAGE_AND_REPLICAS
  parameters:
  - name: env
    description: "Environment, used for tagging"
    string:
      defaultValue: dev

Custom parameters can be used anywhere a string is used.

Common Examples

Using Kubernetes Config

It is possible to use a Kubernetes config with Prodvana, instead of using the Prodvana runtime-agnostic config above. When using Kubernetes configs, Prodvana will automatically replace the namespace with the namespace of the release channel being deployed to. Prodvana will also add additional environment variables (PVN_*) as well as any environment variables that is set in the release channel config as defaults, as long as it recognizes the Kubernetes objects (deployment, job supported today).

service:
    name: my-service
  kubernetesConfig:
    type: KUBERNETES
    local:
      path: path/to/config/relative/to/this/file  # can also be a directory, in which case all yaml files are selected

Parameters can still be used with Kubernetes configs, but they can no longer be automatically generated. Define them explicitly:

service:
    name: my-service
  kubernetesConfig:
    type: KUBERNETES
    local:
      path: path/to/config/relative/to/this/file  # can also be a directory, in which case all yaml files are selected
  parameters:
    - name: image
      dockerImage:
        defaultTag: my-tag
        imageRegistryInfo:
          containerRegistry: my-registry-name
          imageRepository: my-repository

The parameters should be used directly inside Kubernetes configurations, such as

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-deployment
  template:
    metadata:
      labels:
        app: my-deployment
    spec:
      containers:
        - name: api
          image: "{{.Params.image}}"

The order of operation is:

  1. pvnctl reads in your local config file and passes it as a string to Prodvana.
  2. Prodvana sets namespace and injects environment variables.
  3. Prodvana evaluates and applies parameters.

Different Kubernetes Config Per Release Channel

If you need to customize Kubernetes configs per release channel beyond namespaces and environment variables, you can instead pass a whole set of different configs.

service:
  name: my-service
  application: support
  perReleaseChannel:
    - releaseChannel: staging
      kubernetesConfig:
        type: KUBERNETES
        local:
          path: staging-configs/
    - releaseChannel: prod
      kubernetesConfig:
        type: KUBERNETES
        local:
          path: prod-configs/

perReleaseChannel acts as an override, so if you have all but one release channel needing a different set of configs, you can also set it as:

service:
    name: my-service
  kubernetesConfig:
    type: KUBERNETES
    local:
      path: global
  perReleaseChannel:
    - releaseChannel: staging
      kubernetesConfig:
        type: KUBERNETES
        local:
          path: staging-configs/