GuidesAPI Reference
Log In

Configuring Protections

To define a protection, create a Prodvana config file.

protection:
  name: is-not-weekend
  taskConfig:
    program:
      cmd:
      - deployment-schedule-validator.py
      imageTag: 3.10.3-slim
      imageRegistryInfo:
        containerRegistry: dockerhub-public
        imageRepository: python

Apply the config file using pvnctl.

pvnctl configs apply path/to/is-not-weekend.pvn.yaml

It is also possible to define a protection using Kubernetes configs, such as a Kubernetes job.

protection:
  name: is-not-weekend
  kubernetesConfig:
    type: KUBERNETES  # KUSTOMIZE also supported
    local:
      path: .  # change this accordingly

Parametrizing Protections

Defining parameters for protections allow you to define a protection once but instantiate it multiple times with slightly different inputs. Once defined, parameters value are available as {{.Params.myParamName}} anywhere in the config, including Kubernetes configs.

protection:
  name: is-not-weekend
  taskConfig:
    program:
      cmd:
      - deployment-schedule-validator.py
      - --schedule={{.Params.schedule}}
      imageTag: 3.10.3-slim
      imageRegistryInfo:
        containerRegistry: dockerhub-public
        imageRepository: python
  parameters:
  - name: schedule
    string:
      defaultValue: five-days-work-week

Using a Protection

Using a Protection on a Release Channel

To attach a protection to a release channel, add the following to the application configuration.

application:
  name: my-application
  releaseChannels:
    - name: my-release-channel
      ...
      protections:
        - ref:
            name: my-protection
            parameters:
            - name: my-param
              value: my-param-value

Run pvnctl configs apply on the application config and the protection will now show up in the release channel page, under my-demo-organization.prodvana.io -> Applications -> your application -> your release channel.

As defined above, the protection is purely informative. To have use protections as part of deployment, add a lifecycle config to the release channel's application config.

application:
  name: my-application
  releaseChannels:
    - name: my-release-channel
      ...
      protections:
        - ref:
            name: my-protection
          lifecycle:
            - preApproval: {}
            - postApproval: {}
            - postDeployment:
            	  checkDuration: 120s

The config above tells Prodvana to check the result of the protection before and after approvals are submitted and for 120 seconds after the deployment has completed.

Using a Protection on a Service Instance

Attaching a protection to a service instance (that is, a service in a release channel) can be done via the service config file or the application config file (at which point all service instances in that release channel gets the protection).

To add a protection to a specific service instance:

service:
  name: my-service
  application: my-application
  perReleaseChannel:
  - releaseChannel: my-release-channel
    protections:
    - ref:
        name: my-protection
      # optional, if specified, the protection will be used to gate convergence lifecycles
      # of the service (e.g. prevent a service from being deployed if protection is failing)
      lifecycle:
        - preApproval: {}
        - postApproval: {}
        - postDeployment:
            checkDuration: 120s

Run pvnctl configs apply on the config file then go and deploy the service to activate the protections.

To add a protection to all service instances in a release channel, update the application config:

application:
  name: my-application
  releaseChannels:
    - name: my-release-channel
      ...
      serviceInstanceProtections:
        - ref:
            name: my-protection
            parameters:
            - name: my-param
              value: my-param-value
          lifecycle:
            - preApproval: {}
            - postApproval: {}
            - postDeployment:
            		checkDuration: 120s

Run pvnctl configs apply on the config file, and all services will automatically pick up the new protection on their next deployments.

Valid Lifecycles

LifecycleDescriptionRequired Arguments
preApprovalCheck the status of a protection before approvals are submitted.

If there are no approvals, then once all protections and release channel preconditions are satisfied, the lifecycle advances to postApproval.

Protection failures will pause convergence until the failures are gone.
postApprovalCheck the status of a protection after approvals are submitted.

If there are no approvals, these checks are validated after all preApproval checks are satisfied.

Protection failures will pause convergence until the failures are gone.
deploymentCheck the status of a protection during the deployment itself. For example, for Kubernetes, this is from kubectl apply to Kubernetes calling the object healthy.

Protection failures will fail convergence and trigger any automated rollbacks configured.
postDeploymentCheck the status of a protection after the deployment is complete, for up to checkDuration.

Protection failures will fail convergence and trigger any automated rollbacks configured.
checkDuration - How long to check for

Injected Environment Variables

Once protections are attached to an object, the relevant environment variables identifying the object is injected into programs in the protection, both for protections defined using taskConfig and kubernetesConfig.

ObjectVariables Injected
Release ChannelPVN_APPLICATION=app-name
PVN_RELEASE_CHANNEL=release-channel-name
Service InstancePVN_APPLICATION=app-name
PVN_RELEASE_CHANNEL=release-channel-name
PVN_SERVICE=service-name