LogoLogo
  • Welcome to Release
  • Getting started
    • Quickstart
    • Create an account
    • Prepare to use Release
    • Create an application
      • Create custom application
      • Create from template
      • Servers vs runnables
    • Create an environment
  • Guides and examples
    • Domains and DNS
      • Manage domains
      • DNS and nameservers
        • Configure GoDaddy
        • Configure Cloudflare
        • Configure Namecheap
        • Other DNS hosts
      • Routing traffic
    • Example applications
      • Full stack voting app
      • Flask and RDS counter app
      • Static site with Gatsby
      • Golang with Postgres and Nginx
      • WordPress with MySQL
      • Spring and PostgreSQL
      • Terraform and Flask
      • OpenTelemetry demo
      • Load balancer with hostname
      • Static JavaScript service
      • SSH bastion access to services
      • ngrok and OAuth for private tunnels
      • Using OAuth Proxy
      • Hybrid Docker and static site
      • App Imports: Connecting two applications
      • Example library
    • Running instances
      • Cron jobs
      • Jobs
      • Using Helm charts
      • Using terminal
      • Viewing logs
      • Troubleshooting
        • ImagePullBackoff error
        • CrashLoopBackoff error
        • Exit codes
        • OOM: out of memory
    • Advanced guides
      • Containers guide
      • Application guide
      • Kubernetes guide
      • Create a cluster
      • Upgrade a cluster
      • Managing node groups
      • Patch node groups
      • Hostnames and rules
      • Serve traffic on multiple ports
      • Configure access to your K8s cluster
      • Designing for multiple environments
      • Microservices architecture
      • Monitoring your clusters
      • Performance tuning
      • Visibility and monitoring
      • Working with data
        • Container-based data
        • Seeding and migration
        • Cloud-provided data
        • Golden images
        • Third party
      • Pausing Instant Datasets
        • Application pausing schedules
        • Pause/resume environments
      • Infrastructure as code
        • Terraform
  • Reference documentation
    • Account settings
      • Account info
      • Managing users
      • Build settings
        • Build arguments
        • Build SSH keys
      • Add integrations
      • View clusters and cloud integrations
      • Add datasets
      • Environment handles
    • Workflows in Release
      • Stages of workflows
      • Serial deployments
      • Parallel deployments
      • Rolling deployments
      • Rainbow deployments
    • Networking
      • Network architecture (AWS)
      • Network architecture (GCP)
      • Ingresses
      • IP addresses
      • Cloud-provided services
      • Third-party services
    • Release environment versioning
    • Application settings
      • Application Template
        • Schema definition
      • Default environment variables
      • GitHub
      • Pull requests
      • GitOps
      • Just-in-time file mounts
      • Primary App Link
      • Create application FAQ
      • App-level build arguments
      • Parameters
      • Workspaces
    • End-to-end testing
    • Environment settings
      • Environment configuration
      • Environment variables
        • Environment variable mappings
        • Secrets vaults
        • Using Secrets with GitOps
        • Kubernetes Secrets as environment variables
        • Managing legacy Release Secrets
    • Environment expiration
    • Environment presets
    • Instant datasets on AWS
    • Instant datasets on GCP
    • Instant dataset tasks
      • Tonic Cloud
      • Tonic On-Premise
    • Cloud resources
    • Static service deployment
    • Helm
      • Getting started
      • Version-controlled Helm charts
      • Open-source charts
      • Building Docker images
      • Ingress and networking
      • Configuration
    • GitOps
    • The .release.yaml file
    • Docker Compose conversion support
    • Reference examples
      • Adding and removing services
      • Managing service resources
      • Adding database containers to the Application Template
      • Stock Off-The-Shelf Examples
    • Release API
      • Account Authentication
      • Environments API
        • Create
        • Get
        • Setup
        • Patch
      • User Authentication
      • Environment Presets API
        • Get Environment Preset List
        • Get Environment Preset
        • Put Environment Preset
  • Background concepts
    • How Release works
  • Frequently asked questions
    • Release FAQ
    • AWS FAQ
    • Docker FAQ
    • JavaScript FAQ
  • Integrations
    • Integrations overview
      • Artifactory integration
      • Cloud integrations (AWS)
        • AWS guides
        • Grant access to AWS resources
        • AWS how to increase EIP quota
        • Control your EKS fleet with systems manager
        • Managing STS access
        • AWS Permissions Boundaries
        • Private ECR Repositories
        • Using an Existing AWS VPC
        • Using an Existing EKS Cluster
      • Docker Hub integration
      • LaunchDarkly integration
      • Private registries
      • Slack integration
      • Cloud integrations (GCP)
        • GCP Permissions Boundary
      • Datadog Agent
      • Doppler Secrets Manager
      • AWS Secrets Management
    • Source control integrations
      • GitHub
        • Pull request comments
        • Pull request labels
        • GitHub deployments
        • GitHub statuses
        • Remove GitHub integration
      • Bitbucket
      • GitLab
    • Monitoring and logging add-ons
      • Datadog
      • New Relic
      • ELK (Elasticsearch, Logstash, and Kibana)
  • Release Delivery
    • Create new customer integration
    • Delivery guide
    • Release to customer account access controls
    • Delivery FAQs
  • Release Instant Datasets
    • Introduction
    • Quickstart
    • Security
      • AWS Instant Dataset security
    • FAQ
    • API
  • CLI
    • Getting started
    • Installation
    • Configuration
    • CLI usage example
    • Remote development environments
    • Command reference
      • release accounts
        • release accounts list
        • release accounts select
      • release ai
        • release ai chat
        • release ai config-delete
        • release ai config-init
        • release ai config-select
        • release ai config-upsert
      • release apps
        • release apps list
        • release apps select
      • release auth
        • release auth login
        • release auth logout
      • release builds
        • release builds create
      • release clusters
        • release clusters exec
        • release clusters kubeconfig
        • release clusters shell
      • release datasets
        • release datasets list
        • release datasets refresh
      • release deploys
        • release deploys create
        • release deploys list
      • release development
        • release development logs
        • release development start
      • release environments
        • release environments config-get
        • release environments config-set
        • release environments create
        • release environments delete
        • release environments get
        • release environments list
        • release environments vars-get
      • release gitops
        • release gitops init
        • release gitops validate
      • release instances
        • release instances exec
        • release instances logs
        • release instances terminal
  • Release.ai
    • Release.ai Introduction
    • Getting Started
    • Release.ai Templates
    • Template Configuration Basics
    • Using GPU Resources
    • Custom Workflows
    • Fine Tuning LlamaX
    • Serving Inference
Powered by GitBook
On this page
  • How to use rainbow deployments
  • Configuring rainbow deployments
  • State and state changes for rainbow deployments
  • Namespace details
  • What lives inside rainbow environments?
  • Choosing colors

Was this helpful?

  1. Reference documentation
  2. Workflows in Release

Rainbow deployments

PreviousRolling deploymentsNextNetworking

Last updated 1 year ago

Was this helpful?

This is an opt-in Enterprise feature. Please contact us at if you want to enable rainbow deployments on your account.

Rainbow deployments are an extension of the popular blue-green deployment pattern.

  • With blue-green deployments, you have two copies of your production environment, "blue" and "green". Either the blue or green environment is the active production environment at any given time. When you deploy changes, you deploy them to the environment that is not currently active and then switch the recently changed environment to active. This means that your development and production environments remain closely mirrored by default.

  • With Release, you have easy access to unlimited environments, so you can extend the blue-green pattern to infinite colors of the rainbow. Each deployment happens in a namespace, which is a copy of your production environment. Each namespace gets a color, and you can have as many colors as you need.

You can think of these deployments as lanes on a highway: Two lanes are better than one, but infinite lanes are better than two. Let's say you are currently running version 1 of your software in the "blue" environment and you deploy version 2 to the "green" environment. You switch "blue" over to your main environment and direct user traffic there, while keeping "green" running to complete a few asynchronous jobs that still need to complete. Now you discover a problem with version 2 and deploy a hotfix. If you're stuck with only two environments, blue and green, you have to choose between killing the jobs running on green or pushing new code directly to your live environment. If you have infinite colors available, you can keep both the previous environments running while starting a new environment, "yellow", for example.

We use rainbow deployments internally at Release, so we'll be happy to help you decide if they are a good fit for you and advise you on using them effectively in your specific case.

How to use rainbow deployments

After the rainbow deployment feature has been activated in your account, you will be able to configure rainbow deployments through your Application Template file. Note that it only works for permanent environments, not ephemeral ones. You'll specify a timeout period and how many active environments you want, as described in the next section.

If you activate rainbow deployments in an environment, you'll see a rainbow icon to indicate that it is active for that environment, as shown below.

This will also activate the Namespaces tab, where you can see a number of subenvironments, each with its own color, as shown below.

A new production deployment will automatically go to a new namespace, get a new color, and immediately become the active namespace in that environment. The previous namespace will stay alive for a configured timeout period.

This timeout period is useful in case you have long-running jobs or other tasks that need to complete before the environment disappears.

  • After the timeout, the old namespace will be removed.

  • If you redeploy exactly the same build, it will still create a new namespace and expire the previous one, but the color won't change.

Configuring rainbow deployments

To turn rainbow deployments on in a specific environment, add the following block to your Application Template YAML file:

rainbow_deployment_configuration:
    type: infinite
    termination_threshold: 180.minutes
  • The type value defines the kind of rainbow deployment. Currently, we only support infinite for this value, which means that there is no limit to how many namespaces can be created in an environment.

  • The termination_threshold value specifies the timeout for environments to stay alive after a new environment is deployed. You can set this in seconds, minutes, or hours, and you should choose a value greater than the longest-running job or process in that namespace to avoid losing any in-progress work.

Note that the termination_threshold is applied when the namespace is created, so if you update it and redeploy your build, then your existing namespace will still terminate after the previously defined value has elapsed.

State and state changes for rainbow deployments

A namespace can take on one of several states. These are:

  • Active: The currently active environment, also indicated by an arrow in the list of namespaces.

  • Pending: The namespace is initializing with your configuration. This state should only last a few seconds before moving into Activating.

  • Activating: The namespace that will be active next. As soon as it is ready, it will become active and the previously active namespace will become Inactive.

  • Inactive: Any previously active namespace that has not yet been destroyed. You'll see a countdown timer next to inactive namespaces indicating when they are due for termination.

  • Destroyed: Any previously active namespace that has passed its termination_threshold. You can still see information such as the build number, configuration version, and creation time for these environments.

There are two icons with arrows to the left of the namespaces that show the currently active environment and (if applicable) the next environment that will activate. You can see these in the image below.

Inactive environments show a timer indicating when they will be destroyed. You can see this below.

Namespace details

By clicking on the color for any namespace, you'll see a Namespace Details page that shows the same information (name, time until removal, deployment ID, and version) as you can see on the overview page, as well as a list of instances running in that namespace.

What lives inside rainbow environments?

In an ideal world, rainbow deployments mean creating infinite copies of all resources that make up a given environment. In reality, it is not practical to have infinite copies of resources such as your production database or Apache Kafka instances. Therefore, resources like this often live "outside" of this setup.

You'll have to structure your systems carefully so that you don't, for example, have conflicts when several expired but not destroyed environments are competing for the same external resource.

Choosing colors

In case you wonder how the colors for environments are chosen, we use the short Git hash (conveniently, a six-character hex number) and translate it directly to a hex color code.

support@release.com
Rainbow environments
rainbow icon
Namespaces tab
statuses
expiring
namespace details