terraform-provider-qovery

What's Changed

• fix: set min values according to Qovery standards https://github.com/Qovery/terraform-provider-qovery/pull/217

What's Changed

• fix: Add cluster eks ec2 imds advanced setting https://github.com/Qovery/terraform-provider-qovery/pull/198

What's Changed

• feat: Enable deployment through deployment stages https://github.com/Qovery/terraform-provider-qovery/pull/180

The purpose of this change is to allow the deployment of services through deployment stages.

Before this change, every service (application / database / container) was deployed sequentially using a state attribute inside the terraform file, e.g:

resource "qovery_application" "app" {
#[...]
   state = "RUNNING"
}

The following points must require your attention:

• create deployment stages to order services deployments using a qovery_deployment_stage resource
• pilot the whole environment deployment using a qovery_deployment resource
• the state present in each service resources has been removed

Deployment Stage resource

This resource is not mandatory. If no deployment stage is created, services will be deployed using default natural stages: databases -> jobs -> containers -> applications

Deployment stage resource allows to set its order through move_after and move_before attributes (optional)

resource "qovery_deployment_stage" "stage_1" {
  environment_id = qovery_environment.environment.id
  name           = "Deployment Stage 1" 
  description    = "some deployment stage"
}

resource "qovery_deployment_stage" "stage_2" {
  environment_id = qovery_environment.environment.id
  name           = "Deployment Stage 2"
  description    = "some deployment stage"
  move_after     = qovery_deployment_stage.stage_1.id
}

A deployment stage can then be linked to a service, e.g:

resource "qovery_application" "app" {
#[...]

   deployment_stage_id = qovery_deployment_stage.stage_1.id
}

Deployment resource

Services are now deployed using the deployment_resource

• desired_state is similar to the state attribute we used in service resources, it can be one of the following values: RUNNING , STOPPED, RESTARTED
• version is used to force terraform to retrigger a deployment even if the desired_state hasn't changed.
  E.g, in the following scenario:
  • you have already applied with desired_state equal to RUNNING
  • you want to redeploy your services
  • manually set version in your qovery_deployment resource

ℹ️ version is a UUID, you can use external lib such as hashicorp/random to generate random values

terraform {
  required_providers {
    random = {
      source = "hashicorp/random"
      version = "3.4.3"
    }
  }
}

#[...]

resource "random_uuid" "test" {
}

resource "qovery_deployment" "my_deployment" {
  environment_id = qovery_environment.env.id

  desired_state  = "RUNNING"
  version        = random_uuid.test.result

  depends_on = [qovery_application.app, qovery_container.container, qovery_database.database]
}

⚠️ State attribute in service resources

the state attribute is now removed so it must not be present on the services resources.
It concerns the following resources: qovery_application, qovery_container and qovery_database

Remove hardcoded cluster instance types

What's Changed

• fix: Update container resource documentation https://github.com/Qovery/terraform-provider-qovery/pull/171

What's Changed

• fix: Use container registry config only if defined https://github.com/Qovery/terraform-provider-qovery/pull/170

What's Changed

• fix: Do not redeploy an application that has already deployed where desired status is 'STOPPED' https://github.com/Qovery/terraform-provider-qovery/pull/164

What's Changed

• fix: Update application with existing storage https://github.com/Qovery/terraform-provider-qovery/pull/161

What's Changed

• feat: Use entrypoint & arguments in git application https://github.com/Qovery/terraform-provider-qovery/pull/156

What's Changed

• chore: Use /redeploy instead of /restart endpoint https://github.com/Qovery/terraform-provider-qovery/pull/154