As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Este tópico fornece AppSpec arquivos de exemplo para uma implantação AWS Lambda e EC2 /On-Premises.
Tópicos
AppSpec Exemplo de arquivo para uma implantação do Amazon ECS
Aqui está um exemplo de um AppSpec arquivo escrito em YAML para implantar um serviço Amazon ECS.
version: 0.0
Resources:
- TargetService:
Type: AWS::ECS::Service
Properties:
TaskDefinition: "arn:aws:ecs:us-east-1:111222333444:task-definition/my-task-definition-family-name:1"
LoadBalancerInfo:
ContainerName: "SampleApplicationName"
ContainerPort: 80
# Optional properties
PlatformVersion: "LATEST"
NetworkConfiguration:
AwsvpcConfiguration:
Subnets: ["subnet-1234abcd","subnet-5678abcd"]
SecurityGroups: ["sg-12345678"]
AssignPublicIp: "ENABLED"
CapacityProviderStrategy:
- Base: 1
CapacityProvider: "FARGATE_SPOT"
Weight: 2
- Base: 0
CapacityProvider: "FARGATE"
Weight: 1
Hooks:
- BeforeInstall: "LambdaFunctionToValidateBeforeInstall"
- AfterInstall: "LambdaFunctionToValidateAfterInstall"
- AfterAllowTestTraffic: "LambdaFunctionToValidateAfterTestTrafficStarts"
- BeforeAllowTraffic: "LambdaFunctionToValidateBeforeAllowingProductionTraffic"
- AfterAllowTraffic: "LambdaFunctionToValidateAfterAllowingProductionTraffic"
Aqui está uma versão do exemplo anterior escrito em JSON.
{
"version": 0.0,
"Resources": [
{
"TargetService": {
"Type": "AWS::ECS::Service",
"Properties": {
"TaskDefinition": "arn:aws:ecs:us-east-1:111222333444:task-definition/my-task-definition-family-name:1",
"LoadBalancerInfo": {
"ContainerName": "SampleApplicationName",
"ContainerPort": 80
},
"PlatformVersion": "LATEST",
"NetworkConfiguration": {
"AwsvpcConfiguration": {
"Subnets": [
"subnet-1234abcd",
"subnet-5678abcd"
],
"SecurityGroups": [
"sg-12345678"
],
"AssignPublicIp": "ENABLED"
}
},
"CapacityProviderStrategy": [
{
"Base" : 1,
"CapacityProvider" : "FARGATE_SPOT",
"Weight" : 2
},
{
"Base" : 0,
"CapacityProvider" : "FARGATE",
"Weight" : 1
}
]
}
}
}
],
"Hooks": [
{
"BeforeInstall": "LambdaFunctionToValidateBeforeInstall"
},
{
"AfterInstall": "LambdaFunctionToValidateAfterInstall"
},
{
"AfterAllowTestTraffic": "LambdaFunctionToValidateAfterTestTrafficStarts"
},
{
"BeforeAllowTraffic": "LambdaFunctionToValidateBeforeAllowingProductionTraffic"
},
{
"AfterAllowTraffic": "LambdaFunctionToValidateAfterAllowingProductionTraffic"
}
]
}
Veja a seguir a sequência de eventos durante a implantação:
-
Antes que o aplicativo do Amazon ECS atualizado seja instalado no conjunto de tarefas de substituição, a função do Lambda chamada
LambdaFunctionToValidateBeforeInstall
é executada. -
Depois que o aplicativo do Amazon ECS atualizado seja instalado no conjunto de tarefas de substituição, mas antes que ele receba tráfego, a função do Lambda chamada
LambdaFunctionToValidateAfterInstall
é executada. -
Depois que o aplicativo do Amazon ECS no conjunto de tarefas de substituição começar a receber tráfego do receptor de teste, a função do Lambda chamada
LambdaFunctionToValidateAfterTestTrafficStarts
será executada. Essa função provavelmente executa testes de validação para determinar se a implantação continua. Se você não especificar um listener de teste no seu grupo de implantação, este gancho será ignorado. -
Depois que todos os testes de validação no hook
AfterAllowTestTraffic
forem concluídos, e antes que o tráfego de produção seja fornecido para o aplicativo do Amazon ECS atualizado, a função do Lambda chamadaLambdaFunctionToValidateBeforeAllowingProductionTraffic
é executada. -
Depois que o tráfego de produção for fornecido para o aplicativo do Amazon ECS atualizado no conjunto de tarefas de substituição, a função do Lambda chamada
LambdaFunctionToValidateAfterAllowingProductionTraffic
é executada.
As funções do Lambda que são executadas durante qualquer hook podem executar testes de validação ou coletar métricas de tráfego.
AppSpec Exemplo de arquivo para uma implantação do AWS Lambda
Aqui está um exemplo de um AppSpec arquivo escrito em YAML para implantar uma versão da função Lambda.
version: 0.0
Resources:
- myLambdaFunction:
Type: AWS::Lambda::Function
Properties:
Name: "myLambdaFunction"
Alias: "myLambdaFunctionAlias"
CurrentVersion: "1"
TargetVersion: "2"
Hooks:
- BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift"
- AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift"
Aqui está uma versão do exemplo anterior escrito em JSON.
{
"version": 0.0,
"Resources": [{
"myLambdaFunction": {
"Type": "AWS::Lambda::Function",
"Properties": {
"Name": "myLambdaFunction",
"Alias": "myLambdaFunctionAlias",
"CurrentVersion": "1",
"TargetVersion": "2"
}
}
}],
"Hooks": [{
"BeforeAllowTraffic": "LambdaFunctionToValidateBeforeTrafficShift"
},
{
"AfterAllowTraffic": "LambdaFunctionToValidateAfterTrafficShift"
}
]
}
Veja a seguir a sequência de eventos durante a implantação:
-
Antes de deslocar o tráfego da versão 1 de uma função do Lambda chamada
myLambdaFunction
para a versão 2, execute uma função do Lambda chamadaLambdaFunctionToValidateBeforeTrafficShift
que comprova que a implantação está pronta para iniciar o deslocamento do tráfego. -
Se
LambdaFunctionToValidateBeforeTrafficShift
retornou um código de saída de 0 (êxito), comece a deslocar tráfego para a versão 2 damyLambdaFunction
. A configuração de implantação para esta implantação determina a taxa em que o tráfego é deslocado. -
Após o deslocamento do tráfego da versão 1 de uma função do Lambda chamada
myLambdaFunction
para a versão 2 for concluído, execute uma função do Lambda chamadaLambdaFunctionToValidateAfterTrafficShift
que comprova que a implantação foi concluída com êxito.
AppSpec Exemplo de arquivo para uma implantação EC2 /On-Premises
Aqui está um exemplo de um AppSpec arquivo para uma implantação local em uma instância Amazon Linux, Ubuntu Server ou RHEL.
nota
As implantações em instâncias do Windows Server não oferecem suporte ao elemento runas
. Se você estiver implantando em instâncias do Windows Server, não o inclua em seu AppSpec arquivo.
version: 0.0
os: linux
files:
- source: Config/config.txt
destination: /webapps/Config
- source: source
destination: /webapps/myApp
hooks:
BeforeInstall:
- location: Scripts/UnzipResourceBundle.sh
- location: Scripts/UnzipDataBundle.sh
AfterInstall:
- location: Scripts/RunResourceTests.sh
timeout: 180
ApplicationStart:
- location: Scripts/RunFunctionalTests.sh
timeout: 3600
ValidateService:
- location: Scripts/MonitorService.sh
timeout: 3600
runas: codedeployuser
Para uma instância do Windows Server, mude os: linux
para os: windows
. Além disso, você deve qualificar completamente os caminhos de destination
(por exemplo, c:\temp\webapps\Config
e c:\temp\webapps\myApp
). Não inclua o elemento runas
.
Veja a seguir a sequência de eventos durante a implantação:
-
Execute o script localizado em
Scripts/UnzipResourceBundle.sh
. -
Se o script anterior retornou um código de saída de 0 (êxito), execute o script localizado em
Scripts/UnzipDataBundle.sh
. -
Copie o arquivo do caminho
Config/config.txt
para o caminho/webapps/Config/config.txt
. -
Copie recursivamente todos os arquivos no diretório
source
para o diretório/webapps/myApp
. -
Execute o script localizado em
Scripts/RunResourceTests.sh
com um tempo limite de 180 segundos (3 minutos). -
Execute o script localizado em
Scripts/RunFunctionalTests.sh
com um tempo limite de 3600 segundos (1 hora). -
Execute o script localizado em
Scripts/MonitorService.sh
como o usuáriocodedeploy
com um tempo limite de 3600 segundos (1 hora).