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 UIIMAGE_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:
pvnctl
reads in your local config file and passes it as a string to Prodvana.- Prodvana sets namespace and injects environment variables.
- 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/
Updated 4 days ago