Module types

Source
Expand description

Data structures used by operation inputs/outputs.

Modules§

builders
Builders
error
Error types that AWS OpsWorks can respond with.

Structs§

AgentVersion

Describes an agent version.

App

A description of the app.

AutoScalingThresholds

Describes a load-based auto scaling upscaling or downscaling threshold configuration, which specifies when OpsWorks Stacks starts or stops load-based instances.

BlockDeviceMapping

Describes a block device mapping. This data type maps directly to the Amazon EC2 BlockDeviceMapping data type.

ChefConfiguration

Describes the Chef configuration.

CloudWatchLogsConfiguration

Describes the Amazon CloudWatch Logs configuration for a layer.

CloudWatchLogsLogStream

Describes the CloudWatch Logs configuration for a layer. For detailed information about members of this data type, see the CloudWatch Logs Agent Reference.

Command

Describes a command.

DataSource

Describes an app's data source.

Deployment

Describes a deployment of a stack or app.

DeploymentCommand

Used to specify a stack or deployment command.

EbsBlockDevice

Describes an Amazon EBS volume. This data type maps directly to the Amazon EC2 EbsBlockDevice data type.

EcsCluster

Describes a registered Amazon ECS cluster.

ElasticIp

Describes an Elastic IP address.

ElasticLoadBalancer

Describes an Elastic Load Balancing instance.

EnvironmentVariable

Represents an app's environment variable.

Instance

Describes an instance.

InstanceIdentity

Contains a description of an Amazon EC2 instance from the Amazon EC2 metadata service. For more information, see Instance Metadata and User Data.

InstancesCount

Describes how many instances a stack has for each status.

Layer

Describes a layer.

LifecycleEventConfiguration

Specifies the lifecycle event configuration

LoadBasedAutoScalingConfiguration

Describes a layer's load-based auto scaling configuration.

OperatingSystem

Describes supported operating systems in OpsWorks Stacks.

OperatingSystemConfigurationManager

A block that contains information about the configuration manager (Chef) and the versions of the configuration manager that are supported for an operating system.

Permission

Describes stack or user permissions.

RaidArray

Describes an instance's RAID array.

RdsDbInstance

Describes an Amazon RDS instance.

Recipes

OpsWorks Stacks supports five lifecycle events: setup, configuration, deploy, undeploy, and shutdown. For each layer, OpsWorks Stacks runs a set of standard recipes for each event. In addition, you can provide custom recipes for any or all layers and events. OpsWorks Stacks runs custom event recipes after the standard recipes. LayerCustomRecipes specifies the custom recipes for a particular layer to be run in response to each of the five events.

To specify a recipe, use the cookbook's directory name in the repository followed by two colons and the recipe name, which is the recipe's file name without the .rb extension. For example: phpapp2::dbsetup specifies the dbsetup.rb recipe in the repository's phpapp2 folder.

ReportedOs

A registered instance's reported operating system.

SelfUserProfile

Describes a user's SSH information.

ServiceError

Describes an OpsWorks Stacks service error.

ShutdownEventConfiguration

The Shutdown event configuration.

Source

Contains the information required to retrieve an app or cookbook from a repository. For more information, see Creating Apps or Custom Recipes and Cookbooks.

SslConfiguration

Describes an app's SSL configuration.

Stack

Describes a stack.

StackConfigurationManager

Describes the configuration manager.

StackSummary

Summarizes the number of layers, instances, and apps in a stack.

TemporaryCredential

Contains the data needed by RDP clients such as the Microsoft Remote Desktop Connection to log in to the instance.

TimeBasedAutoScalingConfiguration

Describes an instance's time-based auto scaling configuration.

UserProfile

Describes a user's SSH information.

Volume

Describes an instance's Amazon EBS volume.

VolumeConfiguration

Describes an Amazon EBS volume configuration.

WeeklyAutoScalingSchedule

Describes a time-based instance's auto scaling schedule. The schedule consists of a set of key-value pairs.

  • The key is the time period (a UTC hour) and must be an integer from 0 - 23.

  • The value indicates whether the instance should be online or offline for the specified period, and must be set to "on" or "off"

The default setting for all time periods is off, so you use the following parameters primarily to specify the online periods. You don't have to explicitly specify offline periods unless you want to change an online period to an offline period.

The following example specifies that the instance should be online for four hours, from UTC 1200 - 1600. It will be off for the remainder of the day.

{ "12":"on", "13":"on", "14":"on", "15":"on" }

Enums§

AppAttributesKeys
When writing a match expression against AppAttributesKeys, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
AppType
When writing a match expression against AppType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
Architecture
When writing a match expression against Architecture, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
AutoScalingType
When writing a match expression against AutoScalingType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
CloudWatchLogsEncoding
When writing a match expression against CloudWatchLogsEncoding, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
CloudWatchLogsInitialPosition
When writing a match expression against CloudWatchLogsInitialPosition, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
CloudWatchLogsTimeZone
When writing a match expression against CloudWatchLogsTimeZone, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
DeploymentCommandName
When writing a match expression against DeploymentCommandName, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
LayerAttributesKeys
When writing a match expression against LayerAttributesKeys, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
LayerType
When writing a match expression against LayerType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
RootDeviceType
When writing a match expression against RootDeviceType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
SourceType
When writing a match expression against SourceType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
StackAttributesKeys
When writing a match expression against StackAttributesKeys, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
VirtualizationType
When writing a match expression against VirtualizationType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
VolumeType
When writing a match expression against VolumeType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.