Reputation: 3
I am using kepware to collect data and send it to AWS greengrass IoT Core. I deploy my project with serverless and the plugin serverless-plugin-greengrass
. Here a part of my serverless file:
[...]
functions:
opcuaPubSub:
description: Lambda function for get data from kepware.
handler: src.opcua_pub_sub.handler
greengrass:
subscriptions:
- target: cloud
subject: topic/opcua
custom:
output:
file: stack.json
pythonRequirements:
usePipenv: true
greengrass:
autoDeploy: true
groupId: ${env:GROUP_ID}
defaults:
pinned: true
memorySize: 262144
encodingType: json
plugins:
- serverless-python-requirements
- serverless-stack-output
- serverless-pseudo-parameters
- serverless-plugin-greengrass
But I cann't remove the stack with serverless. When I run: serverless remove --stage xxx
I have the following error :
Greengrass: Execute reset for group id xxxxx-xxxx-xxxx-xxxx...
Serverless Error ---------------------------------------
That deployment type is not valid. Please specify one of the following types: {NewDeployment,Redeployment}.
I don't understand because 'serverless' is expecting NewDeployment or Redeployment, but what I would like is to remove the stack. I tried to reset deployement of the greengrass group before run: 'serverless remove...', with the command aws greengrass reset-deployments --group-id $GROUP_ID
but I obtain the same error. If I delete manually the stack in cloudformation console, it's work my group greengrass will be deleted.
(I run serverless remove --stage xxx when I want to change branch in gitlab-ci).
Someone knows why I can not remove this stack with serverless ?
Upvotes: 0
Views: 227
Reputation: 961
Let's divide your problem into three parts.
I have a similar setup running for last 6-9 months. I did not use serverless
alone to achieve all of these.
Rather, I used
serverless
for #1
serverless & cloudformation
for #2
ci/cd pipelines with aws cli
for #3
I prefer this approach due to the fact it allowed me to maintain 'static unchanging' resources and 'dynamically changing' resources next to each other in a mono-repo, yet handle them with care. E.g. you create Greengrass Group once, but you will end up adding/removing Subscriptions to various Topics at a later point in time (multiple times).
TL; DR
#1 serverless
Limit it to deploying / re-deploying Lambdas with source code packages and dependency injection etc.
#2 serverless & cloudformation
is where I define AWS::Greengrass::FunctionDefinition
and AWS::Greengrass::SubscriptionDefinition
resources and grab these resources as a part of when I want to create a new Greengrass group definition.
#3 ci/cd pipelines with aws cli
is where i call it as 'Flash Greengrass Device' (involves 2 steps, see below). They almost everytime works.
# Retrieve Service Role Arn & grant exclusive permissions to Greengrass to use this role.
echo "Associating Greengrass Service Role to AWS Account.."
export GGG_ROLE_NAME=`aws2 cloudformation list-stack-resources --stack-name XXX | jq ".StackResourceSummaries[].PhysicalResourceId" --raw-output | grep YYY`
export GGG_ROLE_ARN=`aws2 iam get-role --role-name $GGG_ROLE_NAME | jq ".Role.Arn" --raw-output`
aws2 greengrass associate-service-role-to-account --role-arn $GGG_ROLE_ARN --region $AWS_DEFAULT_REGION
# Get Group ID, Group Version & Flash it!
export GGG_ID=`aws2 greengrass list-groups --query "Groups[?Name=='XXX']" | jq ".[0].Id" --raw-output`
export GGG_VERSION_ID=`aws2 greengrass list-groups --query "Groups[?Name=='XXX']" | jq ".[0].LatestVersion" --raw-output`
export GGG_DEPL_ID=`aws2 greengrass create-deployment --group-id $GGG_ID --group-version-id $GGG_VERSION_ID --deployment-type NewDeployment | jq ".DeploymentId" --raw-output`
export GGG_DEPL_STATUS=`aws2 greengrass get-deployment-status --deployment-id $GGG_DEPL_ID --group-id GGG_ID | jq ".DeploymentStatus" --raw-output`
Cheers!
Upvotes: 0