Reference Architecture

Prodvana is designed to be flexible and handle any architecture you already have. However, if you are starting from scratch, this is the architecture we recommend.

For a more detailed tutorial including instructions for further customizations, see Managed Delivery for Basic SaaS Applications.

Directory Structure

You will be writing a number of configurations. We recommend the following directory structure:

applications/
  my-app/
    my-app.pvn.yaml
    services/
      my-backend/
        my-backend.pvn.yaml
        deployment.yaml  # Kubernetes Deployment spec
        service.yaml  # Kubernetes Service spec, if needed
      my-frontend/
        my-frontend.pvn.yaml
        deployment.yaml  # Kubernetes Deployment spec
  my-other-app/
    my-other-app.pvn.yaml
    services/
      ...

Kubernetes Runtime

Create a Kubernetes Runtime from your cloud provider of choice:

AWS: use EKS (NOTE: creating an EKS cluster can be complicated. See our guide for a quickstart if you do not already have a process in place).
GCP: use GKE
Azure: use AKS

Link your Kubernetes Runtime to Prodvana. See Configuring a Kubernetes Runtime. We recommend creating two Kubernetes Runtimes, one for staging and one for production, in two different subaccounts/projects.

Container Registry

Use the container registry supported by your cloud provider.

AWS: use ECR
GCP: use Artifact Registry
Azure: use Azure Container Registry

Add your registry to Prodvana on the integrations page (my-demo-organization.runprodvana.com/integrations).

Push images to your registry from your CI on every commit to main, after tests have passed.

Application

Start off with one Application with two Release Channels, staging and production, with a manual approval on production.

application:
  name: my-application
  releaseChannels:
  - name: staging
    runtimes:
    - runtime: kubernetes-staging
  - name: production
    runtimes:
    - runtime: kubernetes-production
    preconditions:
    - releaseChannelStable:
        releaseChannel: staging
    - manualApproval: {}

Service

Define a Prodvana Service with one parameter, the docker image.

service:
  name: my-service
  application: my-application
  kubernetes_config:
    type: KUBERNETES
    local:
      path: .

  parameters:
    - name: image
      required: true
      dockerImage:
        imageRegistryInfo:
          containerRegistry: registry-name
          imageRepository: pvn-infra/pvn/dynamic-delivery

Write your Kubernetes configuration in the same directory as the Prodvana Service config, without using a third-party templating library like Kustomize or Helm. Use the template syntax {{.Params.image}} to reference your docker image.

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

Release Channel Differences

Use parameters and constants to capture differences between Release Channels in configurations. constants can also be specified at the Release Channel layer, for global constants that should be shared across all Services in the Release Channel.

More complex differences can be captured via separate configuration files.

Secrets

Do not use Prodvana for secret storage. Instead, use your cloud provider's secret storage and reference the secret from your code.

CI Integration

Automatically start a new release after your Docker image has been created from your CI. This will automatically deploy staging and leave production waiting on an approval.