» google_os_config_patch_deployment

Patch deployments are configurations that individual patch jobs use to complete a patch. These configurations include instance filter, package repository settings, and a schedule.

To get more information about PatchDeployment, see:

» Example Usage - Os Config Patch Deployment Basic

resource "google_os_config_patch_deployment" "patch" {
  patch_deployment_id = "patch-deploy-inst"

  instance_filter {
    all = true
  }

  one_time_schedule {
    execute_time = "2020-10-10T10:10:10.045123456Z"
  }
}

» Example Usage - Os Config Patch Deployment Instance

data "google_compute_image" "my_image" {
  family  = "debian-9"
  project = "debian-cloud"
}

resource "google_compute_instance" "foobar" {
  name           = "patch-deploy-inst"
  machine_type   = "n1-standard-1"
  zone           = "us-central1-a"
  can_ip_forward = false
  tags           = ["foo", "bar"]

  boot_disk {
    initialize_params {
      image = data.google_compute_image.my_image.self_link
    }
  }

  network_interface {
    network = "default"
  }

  metadata = {
    foo = "bar"
  }
}

resource "google_os_config_patch_deployment" "patch" {
  patch_deployment_id = "patch-deploy-inst"

  instance_filter {
    instances = [google_compute_instance.foobar.id]
  }

  patch_config {
    yum {
      security = true
      minimal = true
      excludes = ["bash"]
    }
  }

  recurring_schedule {
    time_zone {
      id = "America/New_York"
    }

    time_of_day {
      hours = 0
      minutes = 30
      seconds = 30
      nanos = 20
    }

    monthly {
      month_day = 1
    }
  }
}

» Example Usage - Os Config Patch Deployment Full

resource "google_os_config_patch_deployment" "patch" {
  patch_deployment_id = "patch-deploy-inst"

  instance_filter {
    group_labels {
      labels = {
        env = "dev",
        app = "web"
      }
    }

    instance_name_prefixes = ["test-"]

    zones = ["us-central1-a", "us-central-1c"]
  }

  patch_config {
    reboot_config = "ALWAYS"

    apt {
      type = "DIST"
      excludes = ["python"]
    }

    yum {
      security = true
      minimal = true
      excludes = ["bash"]
    }

    goo {
      enabled = true
    }

    zypper {
      categories = ["security"]
    }

    windows_update {
      classifications = ["CRITICAL", "SECURITY", "UPDATE"]
    }

    pre_step {
      linux_exec_step_config {
        allowed_success_codes = [0,3]
        local_path = "/tmp/pre_patch_script.sh"
      }

      windows_exec_step_config {
        interpreter = "SHELL"
        allowed_success_codes = [0,2]
        local_path  = "C:\\Users\\user\\pre-patch-script.cmd"
      }
    }

    post_step {
      linux_exec_step_config {
        gcs_object {
          bucket = "my-patch-scripts"
          generation_number = "1523477886880" 
          object = "linux/post_patch_script"
        }
      }

      windows_exec_step_config {
        interpreter = "POWERSHELL"
        gcs_object {
          bucket = "my-patch-scripts"
          generation_number = "135920493447"
          object = "windows/post_patch_script.ps1"
        }
      }
    }
  }

  duration = "10s"

  recurring_schedule {
    time_zone {
      id = "America/New_York"
    }

    time_of_day {
      hours = 0
      minutes = 30
      seconds = 30
      nanos = 20
    }

    monthly {
      week_day_of_month {
        week_ordinal = -1
        day_of_week  = "TUESDAY"
      }
    }
  }

  rollout {
    mode = "ZONE_BY_ZONE"
    disruption_budget {
      fixed = 1
    }
  }
}

» Argument Reference

The following arguments are supported:

  • instance_filter - (Required) VM instances to patch. Structure is documented below.

  • patch_deployment_id - (Required) A name for the patch deployment in the project. When creating a name the following rules apply:

    • Must contain only lowercase letters, numbers, and hyphens.
    • Must start with a letter.
    • Must be between 1-63 characters.
    • Must end with a number or a letter.
    • Must be unique within the project.

The instance_filter block supports:

  • all - (Optional) Target all VM instances in the project. If true, no other criteria is permitted.

  • group_labels - (Optional) Targets VM instances matching ANY of these GroupLabels. This allows targeting of disparate groups of VM instances. Structure is documented below.

  • zones - (Optional) Targets VM instances in ANY of these zones. Leave empty to target VM instances in any zone.

  • instances - (Optional) Targets any of the VM instances specified. Instances are specified by their URI in the form zones/{{zone}}/instances/{{instance_name}}, projects/{{project_id}}/zones/{{zone}}/instances/{{instance_name}}, or https://www.googleapis.com/compute/v1/projects/{{project_id}}/zones/{{zone}}/instances/{{instance_name}}

  • instance_name_prefixes - (Optional) Targets VMs whose name starts with one of these prefixes. Similar to labels, this is another way to group VMs when targeting configs, for example prefix="prod-".

The group_labels block supports:

  • labels - (Required) Compute Engine instance labels that must be present for a VM instance to be targeted by this filter

  • description - (Optional) Description of the patch deployment. Length of the description is limited to 1024 characters.

  • patch_config - (Optional) Patch configuration that is applied. Structure is documented below.

  • duration - (Optional) Duration of the patch. After the duration ends, the patch times out. A duration in seconds with up to nine fractional digits, terminated by 's'. Example: "3.5s"

  • one_time_schedule - (Optional) Schedule a one-time execution. Structure is documented below.

  • recurring_schedule - (Optional) Schedule recurring executions. Structure is documented below.

  • rollout - (Optional) Rollout strategy of the patch job. Structure is documented below.

  • project - (Optional) The ID of the project in which the resource belongs. If it is not provided, the provider project is used.

The patch_config block supports:

  • reboot_config - (Optional) Post-patch reboot settings. Possible values are DEFAULT, ALWAYS, and NEVER.

  • apt - (Optional) Apt update settings. Use this setting to override the default apt patch rules. Structure is documented below.

  • yum - (Optional) Yum update settings. Use this setting to override the default yum patch rules. Structure is documented below.

  • goo - (Optional) goo update settings. Use this setting to override the default goo patch rules. Structure is documented below.

  • zypper - (Optional) zypper update settings. Use this setting to override the default zypper patch rules. Structure is documented below.

  • windows_update - (Optional) Windows update settings. Use this setting to override the default Windows patch rules. Structure is documented below.

  • pre_step - (Optional) The ExecStep to run before the patch update. Structure is documented below.

  • post_step - (Optional) The ExecStep to run after the patch update. Structure is documented below.

The apt block supports:

  • type - (Optional) By changing the type to DIST, the patching is performed using apt-get dist-upgrade instead. Possible values are DIST and UPGRADE.

  • excludes - (Optional) List of packages to exclude from update. These packages will be excluded.

  • exclusive_packages - (Optional) An exclusive list of packages to be updated. These are the only packages that will be updated. If these packages are not installed, they will be ignored. This field cannot be specified with any other patch configuration fields.

The yum block supports:

  • security - (Optional) Adds the --security flag to yum update. Not supported on all platforms.

  • minimal - (Optional) Will cause patch to run yum update-minimal instead.

  • excludes - (Optional) List of packages to exclude from update. These packages will be excluded.

  • exclusive_packages - (Optional) An exclusive list of packages to be updated. These are the only packages that will be updated. If these packages are not installed, they will be ignored. This field cannot be specified with any other patch configuration fields.

The goo block supports:

  • enabled - (Required) goo update settings. Use this setting to override the default goo patch rules.

The zypper block supports:

  • with_optional - (Optional) Adds the --with-optional flag to zypper patch.

  • with_update - (Optional) Adds the --with-update flag, to zypper patch.

  • categories - (Optional) Install only patches with these categories. Common categories include security, recommended, and feature.

  • severities - (Optional) Install only patches with these severities. Common severities include critical, important, moderate, and low.

  • excludes - (Optional) List of packages to exclude from update.

  • exclusive_patches - (Optional) An exclusive list of patches to be updated. These are the only patches that will be installed using 'zypper patch patch:' command. This field must not be used with any other patch configuration fields.

The windows_update block supports:

  • classifications - (Optional) Only apply updates of these windows update classifications. If empty, all updates are applied. Each value may be one of CRITICAL, SECURITY, DEFINITION, DRIVER, FEATURE_PACK, SERVICE_PACK, TOOL, UPDATE_ROLLUP, and UPDATE.

  • excludes - (Optional) List of KBs to exclude from update.

  • exclusive_patches - (Optional) An exclusive list of kbs to be updated. These are the only patches that will be updated. This field must not be used with other patch configurations.

The pre_step block supports:

  • linux_exec_step_config - (Optional) The ExecStepConfig for all Linux VMs targeted by the PatchJob. Structure is documented below.

  • windows_exec_step_config - (Optional) The ExecStepConfig for all Windows VMs targeted by the PatchJob. Structure is documented below.

The linux_exec_step_config block supports:

  • allowed_success_codes - (Optional) Defaults to [0]. A list of possible return values that the execution can return to indicate a success.

  • interpreter - (Optional) The script interpreter to use to run the script. If no interpreter is specified the script will be executed directly, which will likely only succeed for scripts with shebang lines. Possible values are SHELL and POWERSHELL.

  • local_path - (Optional) An absolute path to the executable on the VM.

  • gcs_object - (Optional) A Cloud Storage object containing the executable. Structure is documented below.

The gcs_object block supports:

  • bucket - (Required) Bucket of the Cloud Storage object.

  • object - (Required) Name of the Cloud Storage object.

  • generation_number - (Required) Generation number of the Cloud Storage object. This is used to ensure that the ExecStep specified by this PatchJob does not change.

The windows_exec_step_config block supports:

  • allowed_success_codes - (Optional) Defaults to [0]. A list of possible return values that the execution can return to indicate a success.

  • interpreter - (Optional) The script interpreter to use to run the script. If no interpreter is specified the script will be executed directly, which will likely only succeed for scripts with shebang lines. Possible values are SHELL and POWERSHELL.

  • local_path - (Optional) An absolute path to the executable on the VM.

  • gcs_object - (Optional) A Cloud Storage object containing the executable. Structure is documented below.

The gcs_object block supports:

  • bucket - (Required) Bucket of the Cloud Storage object.

  • object - (Required) Name of the Cloud Storage object.

  • generation_number - (Required) Generation number of the Cloud Storage object. This is used to ensure that the ExecStep specified by this PatchJob does not change.

The post_step block supports:

  • linux_exec_step_config - (Optional) The ExecStepConfig for all Linux VMs targeted by the PatchJob. Structure is documented below.

  • windows_exec_step_config - (Optional) The ExecStepConfig for all Windows VMs targeted by the PatchJob. Structure is documented below.

The linux_exec_step_config block supports:

  • allowed_success_codes - (Optional) Defaults to [0]. A list of possible return values that the execution can return to indicate a success.

  • interpreter - (Optional) The script interpreter to use to run the script. If no interpreter is specified the script will be executed directly, which will likely only succeed for scripts with shebang lines. Possible values are SHELL and POWERSHELL.

  • local_path - (Optional) An absolute path to the executable on the VM.

  • gcs_object - (Optional) A Cloud Storage object containing the executable. Structure is documented below.

The gcs_object block supports:

  • bucket - (Required) Bucket of the Cloud Storage object.

  • object - (Required) Name of the Cloud Storage object.

  • generation_number - (Required) Generation number of the Cloud Storage object. This is used to ensure that the ExecStep specified by this PatchJob does not change.

The windows_exec_step_config block supports:

  • allowed_success_codes - (Optional) Defaults to [0]. A list of possible return values that the execution can return to indicate a success.

  • interpreter - (Optional) The script interpreter to use to run the script. If no interpreter is specified the script will be executed directly, which will likely only succeed for scripts with shebang lines. Possible values are SHELL and POWERSHELL.

  • local_path - (Optional) An absolute path to the executable on the VM.

  • gcs_object - (Optional) A Cloud Storage object containing the executable. Structure is documented below.

The gcs_object block supports:

  • bucket - (Required) Bucket of the Cloud Storage object.

  • object - (Required) Name of the Cloud Storage object.

  • generation_number - (Required) Generation number of the Cloud Storage object. This is used to ensure that the ExecStep specified by this PatchJob does not change.

The one_time_schedule block supports:

  • execute_time - (Required) The desired patch job execution time. A timestamp in RFC3339 UTC "Zulu" format, accurate to nanoseconds. Example: "2014-10-02T15:01:23.045123456Z".

The recurring_schedule block supports:

  • time_zone - (Required) Defines the time zone that timeOfDay is relative to. The rules for daylight saving time are determined by the chosen time zone. Structure is documented below.

  • start_time - (Optional) The time that the recurring schedule becomes effective. Defaults to createTime of the patch deployment. A timestamp in RFC3339 UTC "Zulu" format, accurate to nanoseconds. Example: "2014-10-02T15:01:23.045123456Z".

  • end_time - (Optional) The end time at which a recurring patch deployment schedule is no longer active. A timestamp in RFC3339 UTC "Zulu" format, accurate to nanoseconds. Example: "2014-10-02T15:01:23.045123456Z".

  • time_of_day - (Required) Time of the day to run a recurring deployment. Structure is documented below.

  • last_execute_time - The time the last patch job ran successfully. A timestamp in RFC3339 UTC "Zulu" format, accurate to nanoseconds. Example: "2014-10-02T15:01:23.045123456Z".

  • next_execute_time - The time the next patch job is scheduled to run. A timestamp in RFC3339 UTC "Zulu" format, accurate to nanoseconds. Example: "2014-10-02T15:01:23.045123456Z".

  • weekly - (Optional) Schedule with weekly executions. Structure is documented below.

  • monthly - (Optional) Schedule with monthly executions. Structure is documented below.

The time_zone block supports:

  • id - (Required) IANA Time Zone Database time zone, e.g. "America/New_York".

  • version - (Optional) IANA Time Zone Database version number, e.g. "2019a".

The time_of_day block supports:

  • hours - (Optional) Hours of day in 24 hour format. Should be from 0 to 23. An API may choose to allow the value "24:00:00" for scenarios like business closing time.

  • minutes - (Optional) Minutes of hour of day. Must be from 0 to 59.

  • seconds - (Optional) Seconds of minutes of the time. Must normally be from 0 to 59. An API may allow the value 60 if it allows leap-seconds.

  • nanos - (Optional) Fractions of seconds in nanoseconds. Must be from 0 to 999,999,999.

The weekly block supports:

  • day_of_week - (Required) IANA Time Zone Database time zone, e.g. "America/New_York". Possible values are MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, and SUNDAY.

The monthly block supports:

  • week_day_of_month - (Optional) Week day in a month. Structure is documented below.

  • month_day - (Optional) One day of the month. 1-31 indicates the 1st to the 31st day. -1 indicates the last day of the month. Months without the target day will be skipped. For example, a schedule to run "every month on the 31st" will not run in February, April, June, etc.

The week_day_of_month block supports:

  • week_ordinal - (Required) Week number in a month. 1-4 indicates the 1st to 4th week of the month. -1 indicates the last week of the month.

  • day_of_week - (Required) A day of the week. Possible values are MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY, and SUNDAY.

The rollout block supports:

  • mode - (Required) Mode of the patch rollout. Possible values are ZONE_BY_ZONE and CONCURRENT_ZONES.

  • disruption_budget - (Required) The maximum number (or percentage) of VMs per zone to disrupt at any given moment. The number of VMs calculated from multiplying the percentage by the total number of VMs in a zone is rounded up. During patching, a VM is considered disrupted from the time the agent is notified to begin until patching has completed. This disruption time includes the time to complete reboot and any post-patch steps. A VM contributes to the disruption budget if its patching operation fails either when applying the patches, running pre or post patch steps, or if it fails to respond with a success notification before timing out. VMs that are not running or do not have an active agent do not count toward this disruption budget. For zone-by-zone rollouts, if the disruption budget in a zone is exceeded, the patch job stops, because continuing to the next zone requires completion of the patch process in the previous zone. For example, if the disruption budget has a fixed value of 10, and 8 VMs fail to patch in the current zone, the patch job continues to patch 2 VMs at a time until the zone is completed. When that zone is completed successfully, patching begins with 10 VMs at a time in the next zone. If 10 VMs in the next zone fail to patch, the patch job stops. Structure is documented below.

The disruption_budget block supports:

  • fixed - (Optional) Specifies a fixed value.

  • percentage - (Optional) Specifies the relative value defined as a percentage, which will be multiplied by a reference value.

» Attributes Reference

In addition to the arguments listed above, the following computed attributes are exported:

  • id - an identifier for the resource with format {{name}}

  • name - Unique name for the patch deployment resource in a project. The patch deployment name is in the form: projects/{project_id}/patchDeployments/{patchDeploymentId}.

  • create_time - Time the patch deployment was created. Timestamp is in RFC3339 text format. A timestamp in RFC3339 UTC "Zulu" format, accurate to nanoseconds. Example: "2014-10-02T15:01:23.045123456Z".

  • update_time - Time the patch deployment was last updated. Timestamp is in RFC3339 text format. A timestamp in RFC3339 UTC "Zulu" format, accurate to nanoseconds. Example: "2014-10-02T15:01:23.045123456Z".

  • last_execute_time - The last time a patch job was started by this deployment. Timestamp is in RFC3339 text format. A timestamp in RFC3339 UTC "Zulu" format, accurate to nanoseconds. Example: "2014-10-02T15:01:23.045123456Z".

» Timeouts

This resource provides the following Timeouts configuration options:

  • create - Default is 4 minutes.
  • delete - Default is 4 minutes.

» Import

PatchDeployment can be imported using any of these accepted formats:

$ terraform import google_os_config_patch_deployment.default projects/{{project}}/patchDeployments/{{name}}
$ terraform import google_os_config_patch_deployment.default {{project}}/{{name}}
$ terraform import google_os_config_patch_deployment.default {{name}}

» User Project Overrides

This resource supports User Project Overrides.