Code Monkey home page Code Monkey logo

aws-greengrass-docker's Introduction

Running AWS IoT Greengrass V2 in a Docker Container

Overview

AWS IoT Greengrass can run in a Docker container. You can use the Dockerfile in this package to build a container image that runs on x86_64 platforms.

This guide will show you how to:

  • Build a Docker image from the Dockerfile for Amazon Linux 2 x86_64.
  • Run an Amazon Linux Docker image containing AWS IoT Greengrass V2.
  • Use docker-compose to build and run AWS IoT Greengrass V2 in the Docker container.
  • The Docker image supports Mac OSX, and Linux as Docker host platforms to run the Greengrass core software.

Prerequisites

  • Mac OSX or Linux host computer running Docker and Docker Compose (optional).
  • The Docker installation (version 18.09 or later) can be found here.
  • The Docker Compose installation (version 1.22 or later) can be found here. Docker for Mac OS and Docker Toolbox include Compose, so those platforms don't need a separate Compose installation. Note: You must have version 1.22 or later because init support is required.

Running AWS IoT Greengrass in a Docker Container

The following steps show how to build the Docker image from the Dockerfile and configure AWS IoT Greengrass to run in a Docker container.

Note: If you have docker-compose installed, you can simply run docker-compose up --build from the unzipped directory for a quick build and basic installation, without device provisioning.

Step 1. Build the AWS IoT Greengrass Docker Image

On Linux or Mac OSX

1.1 Download and decompress the aws-greengrass-docker-<GREENGRASS_VERSION> package.

1.2 In a terminal, run the following commands in the location where you decompressed the aws-greengrass-docker-<GREENGRASS_VERSION> package.

cd ~/Downloads/aws-greengrass-docker-<GREENGRASS_VERSION>
sudo docker build -t "x86_64/aws-iot-greengrass:<GREENGRASS_VERSION>" ./

1.2.1 If you want to cross-build for a different platform, aarch64 for example.

cd ~/Downloads/aws-greengrass-docker-<GREENGRASS_VERSION>
sudo docker build --platform <platform> -t "aws-iot-greengrasss:<GREENGRASS_VERSION>" ./

<platform> can be linux/aarch64 for example. See Docker docs for more information.

Docker CLI v20.10.13 or greater is required to support this.

1.2.2 If you have docker-compose installed, you can run the following commands instead:

cd ~/Downloads/aws-greengrass-docker-<GREENGRASS_VERSION>
docker-compose -f docker-compose.yml build        
  • Note: If you want to provision the device upon startup for cloud deployments, you will need to add the following lines to your docker-compose file to mount your AWS credentials into the container to be picked up at /root/.aws/credentials . Ensure that the :ro suffix is present at the end of the command to ensure read-only access. (This will build image use long-term credentials from an IAM user)

    environment:  
     - PROVISION=true
    volumes:  
     - /path/to/credential/directory/:/root/.aws/:ro
    
  • WARNING: We strongly recommend removing this credential file from your host after the initial setup, as further authorization will be handled by the Greengrass Token Exchange Service using X.509 certificates. For more information, see how Greengrass interacts with AWS services .

  • If you would like to override any of the default configuration options or use your own config file to start Greengrass, specify those environment variables in the environment section as well. If you wish to use your own init config file, you must mount it to the directory you specify in the INIT_CONFIG environment variable, as well as mounting any extra files (e.g. custom certificates) you refer to in the init config file.
    Please see the installer documentation for configuration options and behavior.

1.3 Verify that the Greengrass Docker image was built.

docker images  
REPOSITORY                          TAG                 	IMAGE ID            CREATED             SIZE
x86-64/aws-iot-greengrass           <GREENGRASS_VERSION>	3f152d6707c8        17 seconds ago      695MB

Step 2. Run the Docker Container

On Linux or Mac OSX

2.1 In the terminal, run the following command to run the container in interactive mode in the foreground:

docker run --init -it --name aws-iot-greengrass \  
x86_64/aws-iot-greengrass:<GREENGRASS_VERSION>
  • Replace -it with -d to run this container in the background in detached mode.

  • Note: If you would like to provision your device for cloud deployments one of the following to retrieve credentials and make them available to the AWS IoT Greengrass Core software installer

    2.1.1 Use long-term credentials from an IAM user: Use the following lines in the above command to mount your AWS credentials into the container to be picked up at /root/.aws/credentials. Ensure that the :ro suffix is present at the end of the command to ensure read-only access.

     -e PROVISION=true \  
     -v /path/to/credential/directory/:/root/.aws/:ro \  
    
    • WARNING: We strongly recommend removing this credential file from your host after the initial setup, as further authorization will be handled by the Greengrass Token Exchange Service using X.509 certificates. For more information, see how Greengrass interacts with AWS services .

    2.1.2 (Recommended) Use temporary security credentials from an IAM role: Use the following lines in the above command to provide the access key ID, secret access key, and session token from an IAM role that you assume for the container. For more information about how to retrieve these credentials, see Requesting temporary security credentials in the IAM User Guide.

     -e PROVISION=true \  
     -e AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE \  
     -e AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \  
     -e AWS_SESSION_TOKEN=AQoDYXdzEJr1K...o5OytwEXAMPLE= \  
    

    2.1.3 Use long-term security credentials from an IAM user: Use the following lines in the above command to provide the access key ID and secret access key from an IAM user that you assume for the container. For more information about how to retrieve these credentials, see Use long-term credentials from an IAM user in the Greengrass Developer Guide.

     -e PROVISION=true \
     -e AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE \
     -e AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
    
  • If you would like to override any of the default configuration options or use your own config file to start Greengrass, specify those environment variables in the environment section as well. If you wish to use your own init config file, you must mount it to the directory you specify in the INIT_CONFIG environment variable, as well as mounting any extra files (e.g. custom certificates) you refer to in the init config file.
    Please see the installer documentation for configuration options and behavior.

2.1.1 If you have docker-compose installed, you can run the following commands instead:

cd ~/Downloads/aws-greengrass-docker-<GREENGRASS_VERSION>
docker-compose -f docker-compose.yml up  

2.2 The output should look like this example:

Running Greengrass with the following options: -Droot=/greengrass/v2 -Dlog.store=FILE -Dlog.level= -jar /opt/greengrassv2/lib/Greengrass.jar --provision true --deploy-dev-tools false --aws-region us-east-1 --start false  
Installing Greengrass for the first time...  
...  
...  
Launching Nucleus...  
Launched Nucleus successfully.  

Debugging the Docker Container

To debug issues with the container, you can persist the runtime logs or attach an interactive shell.

Persist Greengrass Runtime Logs outside the Greengrass Docker Container

You can run the AWS IoT Greengrass Docker container after bind-mounting the /greengrass/v2/logs directory to persist logs even after the container has exited or is removed. Alternatively, you can omit the --rm flag and use docker cp to copy the logs back from the container after it exits.

Attach an Interactive Shell to the Greengrass Docker Container

You can attach an interactive shell to a running AWS IoT Greengrass Docker container. This can help you to investigate the state of the Greengrass Docker container.
Either use docker attach or run the following command in the terminal.

docker exec -it container-name sh -c "YOUR_COMMAND > /proc/1/fd/1"  
  • This ensures that all output is redirected to PID 1 and will show up in the docker logs.

Stopping the Docker Container

To stop the AWS IoT Greengrass Docker Container, press Ctrl+C in your terminal (interactive mode) or run docker stop or docker-compose stop (detached mode).

This action will send SIGTERM to the Greengrass process to gracefully shut down down the Greengrass process and all subprocesses that were started. The Docker container is initialized with the docker-init executable as process PID 1, which helps in removing any leftover zombie processes. For more information, see the Docker documentation for init.

You may use docker start or docker-compose start to restart a stopped container.

Removing the Docker Container

If you have not specified the --rm flag in your docker run command, your container will remain in the STOPPED state on your host. Use docker rm or docker-compose down to remove your container.

aws-greengrass-docker's People

Contributors

abanthiy avatar amazon-auto avatar avipinku avatar deadprogram avatar doublechuang avatar jie0917 avatar kucnavya avatar mikedombo avatar ricciardi-adrien avatar tutugreen avatar xsahban avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

aws-greengrass-docker's Issues

components didn't install correctly via INIT_CONFIG configuration

Describe the bug
Components didn't deployed with use of INIT_CONFIG file

To Reproduce

  1. Docker image was build from Dockerfile in this repo GREENGRASS_RELEASE_VERSION=2.10.3

  2. Docker run command:

docker run --rm --init -d --name greengrass-test \
 -v /home/user/IOT/config:/tmp/config/:ro \
 -e INIT_CONFIG=/tmp/config/config.yaml \
 --env-file .env \
 -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY -e AWS_SESSION_TOKEN=$AWS_SESSION_TOKEN \
 -p 8883 greengrass:3
  1. .env file
AWS_REGION=eu-central-1
PROVISION=true
COMPONENT_DEFAULT_USER=ggc_user:ggc_group
INIT_CONFIG=config.yaml
TES_ROLE_ALIAS_NAME=TokenExchangeRoleAlias
DEPLOY_DEV_TOOLS=true
THING_NAME=test-thing
THING_GROUP_NAME=thing-group1
TES_ROLE_NAME=TokenExchangeRole
LOG_LEVEL=INFO
  1. Content of config file:
  aws.greengrass.Cli:
    componentType: "PLUGIN"
    configuration:
      AuthorizedPosixGroups: null
      AuthorizedWindowsGroups: null
    dependencies:
    - "aws.greengrass.Nucleus:SOFT"
    version: "2.11.0"
  aws.greengrass.clientdevices.Auth:
    componentType: "PLUGIN"
    configuration:
      ca_type: null
      certificateAuthority:
        caType: null
      deviceGroups:
        definitions:
          AllPermissiveDeviceGroup:
            policyName: "AllPermissivePolicy"
            selectionRule: "thingName: *"
        formatVersion: "2021-03-05"
        policies:
          AllPermissivePolicy:
            AllowAll:
              operations:
              - "*"
              resources:
              - "*"
              statementDescription: "Allow client devices to perform all actions."
      metrics: {}
      security: {}
      startupTimeoutSeconds: "120"
    version: "2.4.3"
  aws.greengrass.clientdevices.mqtt.Bridge:
    componentType: "PLUGIN"
    configuration:
      mqttTopicMapping:
        CloudDeleteShadowNameMapping:
          source: "IotCore"
          target: "LocalMqtt"
          topic: "$aws/things/+/shadow/name/+/delete/+"
        CloudGetJobIdsMapping:
          source: "IotCore"
          target: "LocalMqtt"
          topic: "$aws/things/+/jobs/+/get/+"
        CloudGetJobsMapping:
          source: "IotCore"
          target: "LocalMqtt"
          topic: "$aws/things/+/jobs/get/+"
        CloudGetShadowNameMapping:
          source: "IotCore"
          target: "LocalMqtt"
          topic: "$aws/things/+/shadow/name/+/get/+"
        CloudNotifyJobsMapping:
          source: "IotCore"
          target: "LocalMqtt"
          topic: "$aws/things/+/jobs/notify"
        CloudNotifyNextJobsMapping:
          source: "IotCore"
          target: "LocalMqtt"
          topic: "$aws/things/+/jobs/notify-next"
        CloudUpdateJobsMapping:
          source: "IotCore"
          target: "LocalMqtt"
          topic: "$aws/things/+/jobs/+/update/+"
        CloudUpdateShadowNameMapping:
          source: "IotCore"
          target: "LocalMqtt"
          topic: "$aws/things/+/shadow/name/+/update/+"
        DeleteShadowNameMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "$aws/things/+/shadow/name/+/delete"
        EventsMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "$aws/rules/events_bi_rule/+"
        FaultsMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "$aws/rules/faults_bi_rule/+"
        GetJobIdsMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "$aws/things/+/jobs/+/get"
        GetJobsMappingMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "$aws/things/+/jobs/get"
        GetShadowNameMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "$aws/things/+/shadow/name/+/get"
        MetricsMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "$aws/rules/metrics_bi_rule/+"
        PropertiesMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "$aws/rules/properties_bi_rule/+"
        StartNextJobsMappingMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "$aws/things/+/jobs/start-next"
        TelemetryNameMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "dt/iotagent/#"
        UpdateJobsMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "$aws/things/+/jobs/+/update"
        UpdateShadowNameMapping:
          source: "LocalMqtt"
          target: "IotCore"
          topic: "$aws/things/+/shadow/name/+/update"
      startupTimeoutSeconds: "120"
    dependencies:
    - "aws.greengrass.clientdevices.Auth:HARD"
    lifecycle:
      startup:
        timeout: "120"
    version: "2.2.6"
  aws.greengrass.clientdevices.mqtt.Moquette:
    componentType: "PLUGIN"
    configuration:
      moquette:
        host: "0.0.0.0"
        netty.mqtt.message_size: "131072"
        ssl_port: "8883"
      netty.channel.read.limit: 524288
      netty.channel.write.limit: 524288
      startupTimeoutSeconds: "120"
    dependencies:
    - "aws.greengrass.clientdevices.Auth:HARD"
    lifecycle:
      startup:
        timeout: "120"
    version: "2.3.3"
  aws.greengrass.LocalDebugConsole:
    componentType: "PLUGIN"
    configuration:
      bindHostname: "0.0.0.0"
      httpsEnabled: "false"
      port: "1441"
      websocketPort: "1442"
    dependencies:
    - "aws.greengrass.Cli:SOFT"
    - "aws.greengrass.Nucleus:SOFT"
    lifecycle: {}
    version: "2.3.1"
  aws.greengrass.Nucleus:
    componentType: "NUCLEUS"
    configuration:
      awsRegion: "eu-central-1"
      componentStoreMaxSizeBytes: "10000000000"
      deploymentPollingFrequencySeconds: "15"
      envStage: "prod"
      fleetStatus:
        periodicStatusPublishIntervalSeconds: 86400
      greengrassDataPlaneEndpoint: ""
      greengrassDataPlanePort: "8443"
      mqtt:
        spooler: {}
      networkProxy:
        proxy: {}
      platformOverride: {}
      runWithDefault:
        posixUser: "ggc_user:ggc_group"
      telemetry: {}
    previousVersion: "2.11.0"
    version: "2.11.0"

Expected behavior
Some components files appear in /greengrass/v2/bin and /greengrass/v2/packages folders

Actual behavior
Folders /greengrass/v2/bin and /greengrass/v2/packages(with subfolders) are empty
Auto-provisioning works and services: part of effectiveConfig.yaml a same as config.yaml

greengrass-cli dont start inside docker container

Describe the bug

greengrass-cli can't start inside docker container

user@host:# docker exec -it greengrass-cli
OCI runtime exec failed: exec failed: unable to start container process: exec: "greengrass-cli": executable file not found in $PATH: unknown

according to documentation https://docs.aws.amazon.com/greengrass/v2/developerguide/install-gg-cli.html
DEPLOY_DEV_TOOLS=true
PROVISION=true
should be enough for greengrass-cli installation but it wasn't installed

To Reproduce

Docker run command:

docker run --rm --init -d --name greengrass-test \
 -v /home/user/IOT/config:/tmp/config/:ro \
 --env-file .env \
 -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY -e AWS_SESSION_TOKEN=$AWS_SESSION_TOKEN \
 -p 8883 greengrass:3

Content of .env file:

GGC_ROOT_PATH=/greengrass/v2
AWS_REGION=eu-central-1
PROVISION=true
COMPONENT_DEFAULT_USER=ggc_user:ggc_group
TES_ROLE_ALIAS_NAME=TokenExchangeRoleAlias
DEPLOY_DEV_TOOLS=true
THING_NAME=test-thing
THING_GROUP_NAME=thing-group1
TES_ROLE_NAME=TokenExchangeRole
LOG_LEVEL=DEBUG

Expected behavior
Run commands via
docker exec -it greengrass-cli

Docker Inspect and Logs
No new records in /greengrass/v2/logs/greengrass.log

Environment
GREENGRASS_RELEASE_VERSION=2.10.3

`greengrass_entrypoint.sh` wrong test instruction

Describe the bug
Running the container as explained in the README prints the following error and provisioning cannot be done:

/greengrass-entrypoint.sh: 19: [: true: unexpected operator

To Reproduce
Steps to reproduce the behavior. If possible, provide a minimal amount of code that causes the bug.

Running the container as explained in the README, passing -e PROVISION=true to docker run

Expected behavior

Should be working. The fix is simple, replace == with = since == is not supported by all shells and is not portable (see https://www.shellscript.sh/test.html)

Actual behavior

Does not work

Screenshots
If applicable, add screenshots to help explain your problem.

Docker Inspect and Logs
If available, add docker_container.log and docker_inspect.json.

Environment

  • OS: [e.g. Ubuntu 20.04]
  • JDK version:
  • Greengrass version
  • Docker version
  • Docker image version
  • docker-compose version
  • Output of uname -a
  • Output of cat /etc/os-release or its equivalent

Additional context
Add any other context about the problem here.

Missing line break in README

Instructions under item 1.2.1 of the README state the following modifications to docker-compose.yml:

environment:  
 - PROVISION=truevolumes:
 - /path/to/credential/directory/:/root/.aws/:ro

There seems to be a missing line break after true.

Provide instructions to build for `aarch64`

Feature Description
Provide instructions to build the container image for aarch64

Use Case
To run this container on ARM machines, and on Mac M1 without the need of an emulator

  • ๐Ÿ‘‹ I may be able to implement this feature request
  • โš ๏ธ This feature might incur a breaking change

Unable to launch nodejs lambdas (could not read process state file)

Describe the bug
Python lambdas work just fine. However whenever I'm using a nodejs lambda I get the following error.

`2022-06-23T02:51:03.346Z [INFO] (Copier) smarthub-greengrass-nodejs: Startup script exited. {exitCode=1, serviceInstance=1, serviceName=smarthub-greengrass-nodejs, currentState=STARTING}

2022-06-23T02:51:03.352Z [INFO] (pool-2-thread-16) smarthub-greengrass-nodejs: shell-runner-start. {scriptName=services.smarthub-greengrass-nodejs.lifecycle.shutdown.script, serviceInstance=1, serviceName=smarthub-greengrass-nodejs, currentState=BROKEN, command=["/greengrass/v2/packages/artifacts/aws.greengrass.LambdaLauncher/2.0.10/lambda-..."]}

2022-06-23T02:51:03.387Z [WARN] (Copier) smarthub-greengrass-nodejs: stderr. 2022/06/23 02:51:03 could not read process state file /greengrass/v2/work/smarthub-greengrass-nodejs/work/worker/P7QmJu--20Asa2ep8zLcZYL4TPTGKRFtbfWy1UYUcsM/state.json: open /greengrass/v2/work/smarthub-greengrass-nodejs/work/worker/P7QmJu--20Asa2ep8zLcZYL4TPTGKRFtbfWy1UYUcsM/state.json: no such file or directory. {scriptName=services.smarthub-greengrass-nodejs.lifecycle.shutdown.script, serviceInstance=1, serviceName=smarthub-greengrass-nodejs, currentState=BROKEN}
`

To Reproduce
Follow these steps to launch greengrass via docker (https://docs.aws.amazon.com/greengrass/v2/developerguide/run-greengrass-docker-automatic-provisioning.html)

Once you have the docker container running from the docker-compose file provision a nodejs12.x lambda component.

{ "lambdaExecutionParameters": { "EnvironmentVariables": {} }, "containerParams": { "memorySize": 16000, "mountROSysfs": false, "volumes": {}, "devices": {} }, "containerMode": "NoContainer", "timeoutInSeconds": 3, "maxInstancesCount": 100, "inputPayloadEncodingType": "json", "maxQueueSize": 1000, "pinned": false, "maxIdleTimeInSeconds": 60, "statusTimeoutInSeconds": 60, "pubsubTopics": { "0": { "topic": "cloud", "type": "IOT_CORE" } } }

Send a message to the topic

Get error.

Expected behavior
lambda should run

Actual behavior
lambda fails to run with error posted above.

Environment
GREENGRASS_RELEASE_VERSION=2.5.3

AWS IoT Greengrass 2.2.0 Release

Describe the bug
Current release only supports AWS IoT Greengrass 2.1.0, the latest released version of Greengrass is 2.2.0

To Reproduce
Download main branch and build.

Expected behavior
I download from main branch and build. At that point I have a container file for 2.2.0.

Actual behavior
Greengrass 2.1.0 is build and used.

Screenshots
n/a

Docker Inspect and Logs
n/a

Environment

  • OS:
  • JDK version:
  • Greengrass version
  • Docker version
  • Docker image version
  • docker-compose version
  • Output of uname -a
  • Output of cat /etc/os-release or its equivalent

Additional context

  • An authoritative has file for the Greengrass 2.2.0.zip file is needed
  • A complete series of tests should be performed before release

Enable provisioning via Environment Variables

Feature Description
Provisioning Greengrass V2 locally without docker is possible when the AWS credentials (Access key ID and Secret Access Key) as well as the configured default region are exposed via environment variables.
This is useful when working with tools like aws-vault, which expose AWS credentials and region via environment variables.

Use Case
Be able to retrieve AWS credentials from a secret store and configured default region via aws-vault and provision Greengrass V2 in docker using temporary credentials.

Proposed Solution
Introduce new environment variables:

  • AWS_REGION
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY
  • AWS_SESSION_TOKEN

In addition to retrieving credentials only from a mounted config-file, also check if there are environment variables (AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN) exposed and use those.

The priority to use either the config file or environment variables first for provisioning, doesn't matter for me.

Make sure to unset the secret environment variables when provisioning is finished for security reasons (same behavior as when provisioning locally aws-vault exec <PROFILENAME> -- java -jar ... Greengrass.jar).

When running the container, the docker run- or the docker-compose up-command need to incorporate the variables:

docker run -e โ€œAWS_REGION=${AWS_REGION}โ€ -e "AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}" -e "AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}" -e "AWS_SESSION_TOKEN=${AWS_SESSION_TOKEN}"...

or

services:
  greengrass:
    environment:
      - AWS_REGION=$AWS_REGION
      - AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      - AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      - AWS_SESSION_TOKEN=$AWS_SESSION_TOKEN

The docker run- or docker-compose up-command then needs to be wrapped with aws-vault:

aws-vault exec <PROFILE> -- docker run ...
aws-vault exec <PROFILE> -- docker-compose up

Other

  • ๐Ÿ‘‹ I may be able to implement this feature request
  • โš ๏ธ This feature might incur a breaking change

Standardize on Apache 2.0 license

Feature Description
Standardize licensing on Apache 2.0

Use Case
Simplifying corporate approval to use AWS Greengrass

Proposed Solution
Either switch the license for aws-greengrass-docker from the MIT license to Apache 2.0 or dual license the component

Other

  • โš ๏ธ This feature might incur a breaking change

Greengrass container IPv6 addressing

Describe the bug
We created our custom provisioning plugins
https://docs.aws.amazon.com/greengrass/v2/developerguide/develop-custom-provisioning-plugins.html
and use it via TRUSTED_PLUGIN key during greengrass container start

We exposed port for plugin invoke and discovered that it was exposed on IPv6 addressing.
Output of netstat inside greengrass container:

bash-4.2# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp6 0 0 127.0.0.1:8090 :::* LISTEN 58/java

Expected behavior
IPv4 addresing

Actual behavior
IPv6 addressing

Additional context
Can it be controlled via greengrass code?
Do you have some options?

error: "unary operator expected" error returned from greengrass-entrypoint.sh

Describe the bug

When trying to docker run the locally built container, the bash script used for the ENTRYPOINT in the Dockerfile displays the following error in the output:

Nucleus start set to false, exiting...
/greengrass-entrypoint.sh: line 91: [: =: unary operator expected

To Reproduce
After building the container, executing docker run with that container results in the above error.

Expected behavior
For docker run to be able to succeed.

Actual behavior
Tell us what actually happened.

The container started, but did not correctly connect to AWS as expected to provision a new device.

Screenshots
If applicable, add screenshots to help explain your problem.

Docker Inspect and Logs
If available, add docker_container.log and docker_inspect.json.

Environment

  • OS: [e.g. Ubuntu 20.04]
    macOS Sonoma 14.5

  • JDK version:
    unknown

  • Greengrass version
    latest main branch from repo.

  • Docker version
    Docker Desltop for macOS 4.30.0

  • Docker image version

  • docker-compose version - n/a

  • Output of uname -a:
    Darwin Rons-MacBook-Pro.local 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64

  • Output of cat /etc/os-release or its equivalent

Additional context
Add any other context about the problem here.

None

Modified `/etc/sudoers` is not persisted across restarts

Describe the bug
In order to run components as other users, Greengrass needs specific sudo permission. The greengrass-entrypoint.sh script modified the /etc/sudoers file to add the right permission, but this is only performed the first time the container is started on a empty GGC_ROOT folder.

To Reproduce
Run the container once. Check the /etc/sudoers file -> it is correct.
Stop the container. Start the container again with the same mounted volumes (/etc is not mounted externally, and it is not possible to do so)
Check the /etc/sudoers file -> it contains root ALL=(ALL) ALL

Expected behavior
/etc/sudoers should have the right content upon container restarts

Actual behavior
/etc/sudoers has wrong content upon container restart

Screenshots
If applicable, add screenshots to help explain your problem.

Docker Inspect and Logs
If available, add docker_container.log and docker_inspect.json.

Environment

  • OS: [e.g. Ubuntu 20.04]
  • JDK version:
  • Greengrass version
  • Docker version
  • Docker image version
  • docker-compose version
  • Output of uname -a
  • Output of cat /etc/os-release or its equivalent

Additional context
Add any other context about the problem here.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.