- Le plus récent
- Le plus de votes
- La plupart des commentaires
Posting the resolution to this after working with AWS support to identify the root cause. Hoping this helps somebody in the future that runs into the same issue.
Root cause:
A component needs to access the ipc.socket file on the Greengrass Core to use IPC functionality. The Greengrass v2 documentation explains how to provide this file to a Docker component by mounting the Greengrass Core root folder in the component’s container (https://docs.aws.amazon.com/greengrass/v2/developerguide/run-docker-container.html#docker-container-ipc). However, this only appears to work when Greengrass Core is installed directly on the server (not in a Docker container). When Greengrass Core is run in a Docker container, the documented method to provide the ipc.socket file to the component attempts to provide the file from the host machine's file system rather than the file on the Greengrass Core Docker container. This causes the component's IPC connection to fail since it does not have access to the ipc.socket file it needs from the Greengrass Core container.
Solution:
We need to make sure that the component has access to the ipc.socket file on the Docker container running the Greengrass Core. One way to achieve this is through creating a Docker volume for the Greengrass Core root folder that other Docker containers can access and mount. Below are the steps I used to do this.
-
Create a docker volume.
Example: docker volume create gg-core-root -
Mount the gg-core-root volume to the Greengrass core root folder when running the Greengrass Core Docker container. This will allow components to access the ipc.socket file in the Core root folder through the gg-core-root volume.
Example: sudo docker run --rm --init -it --name aws-iot-greengrass-manual -v ${PWD}/greengrass-v2-config:/tmp/config/:ro -v ${PWD}/greengrass-v2-certs:/tmp/certs:ro -v gg-core-root:/greengrass/v2 -v /var/run/docker.sock:/var/run/docker.sock --env-file .env -p 443 amazon/aws-iot-greengrass:latest -
In the component’s recipe file, mount the gg-core-root volume when the component is run
Example: docker run --rm --privileged -v gg-core-root:/greengrass/v2 -e AWS_REGION=$AWS_REGION -e SVCUID=$SVCUID -e AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT=$AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT -e AWS_CONTAINER_AUTHORIZATION_TOKEN=$AWS_CONTAINER_AUTHORIZATION_TOKEN -e AWS_CONTAINER_CREDENTIALS_FULL_URI=$AWS_CONTAINER_CREDENTIALS_FULL_URI <container_name>
Hi,
I am also running GreenGrass in a docker container with a mounted volume. A solution for the case where you would like to have bind mount for your GreenGrass data is also possible.
My docker-compose.yml file for the greengrass service looks like this:
version: '3.9'
services:
greengrass:
init: true
privileged: true
image: public.ecr.aws/aws-iot-greengrass/aws-iot-greengrass-v2:2.5.3-0
environment:
- GGC_ROOT_PATH=/greengrass/v2
- HOST_GREENGRASS_IPC_SOCKET=$GREENGRASS_MOUNT_PATH/ipc.socket
volumes:
- ./credentials/:/root/.aws/:ro
- $GREENGRASS_MOUNT_PATH:/greengrass/v2/
Where GREENGRASS_MOUNT_PATH environment variable is where the greengrass data is bind-mounted. In the cases where GreenGrass is run in a Docker container, where the host and the GreenGrass share the same docker host and GreenGrass runs Docker containers of its own, on should approach the volumes from the perspective of the host. In those cases, when one would like to mount the ipc.socket, the volume path should be given with respect to the host, not the greengrass container itself.
Assuming that nucleus creates the ipc socket under /greengrass/v2/ipc.socket, the correct mounting would be with docker option
-v HOST_GREENGRASS_IPC_SOCKET:/greengrass/v2/ipc.socket.
That would look like in a docker-compose file as:
version: '3.9'
services:
pubsub_test:
image: <some image to run>
privileged: true
volumes:
- HOST_GREENGRASS_IPC_SOCKET:/greengrass/v2/ipc.socket
environment:
- SVCUID
- AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT
Alternatively, you could mount the ipc socket in a custom path in the container you are running by setting both the env variable AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT that is passed down to the container and the bind mount path at the same time, which would look like:
version: '3.9'
services:
pubsub_test:
image: <some image to run>
privileged: true
volumes:
- HOST_GREENGRASS_IPC_SOCKET:$SOME_CUSTOM_IPC_SOCKET_PATH
environment:
- SVCUID
- AWS_GG_NUCLEUS_DOMAIN_SOCKET_FILEPATH_FOR_COMPONENT=$SOME_CUSTOM_IPC_SOCKET_PATH
Contenus pertinents
- demandé il y a un an
- demandé il y a 6 mois
- demandé il y a un mois
AWS OFFICIELA mis à jour il y a un an- AWS OFFICIELA mis à jour il y a 10 mois
