DOCSEARCHbyAlgolia
Submit Docs

EdgeX Foundry Go Implementation

repository·main·Indexed 23 days ago

https://github.com/edgexfoundry/edgex-go

Go implementation of EdgeX Foundry microservices, providing build, containerization, and bootstrapping logic for the open-source IoT edge computing framework. Includes documentation for the Command Service, security utilities like secrets-config, security-secretstore-setup, and security-proxy-setup, as well as token providers such as SPIFFE and security-file-token-provider.

Tokens
38.3K
Snippets
89
Records
179
Agent score
81%

What's inside edgex-go

  1. What is the EdgeX Foundry Core Data Service?

    main
    The Core Data service provides a centralized persistence facility for data readings collected by devices and sensors. It allows device services to store sensor and device data locally on the edge system (such as a gateway) until the data can be moved 'north' to enterprise and cloud systems.

  2. What is the EdgeX Foundry Command Service?

    main

    The Command Service acts as a conduit for other services to trigger actions on devices or sensors through their managing device services. It provides an API to retrieve lists of available commands for all devices or for a specific device.

    Commands are categorized into two groups:

    • Gets: Issued to a device/sensor to retrieve the current value of a particular attribute (e.g., current temperature from a thermostat or the on/off status of a light).
    • Puts: Issued to a device/sensor to change its current state or status (e.g., setting a motor's speed in RPMs or adjusting a dimmer light's brightness).

  3. What is the EdgeX Foundry Core Keeper Service?

    main
    Core Keeper is a lightweight configuration and registry service designed to replace Consul within the EdgeX architecture. It leverages Redis as its persistent data store and implements configuration and registry abstractions by utilizing the go-mod-configuration and go-mod-registry modules.

  4. What is the security-proxy-setup container?

    main

    The security-proxy-setup container is used to configure the NGINX reverse proxy and contains a copy of the secrets-config utility.

    Note for users migrating from EdgeX 3.0 or earlier: The security-proxy-setup binary that previously configured the Kong reverse proxy has been removed in favor of this NGINX-based approach.

  5. What is the Core Metadata Service

    main

    The Core Metadata Service is responsible for retaining and providing access to knowledge about devices and sensors connected to EdgeX.

    Key responsibilities include:

    • Managing information about connected devices and sensors (type, organization of reported data, and command capabilities).
    • Managing configuration metadata used by other gateway services, such as cleanup schedules and hardware configuration (e.g., Wi-Fi connection info, MQTT queues).

    Note: Non-device metadata may be stored in different databases or managed by other services depending on the specific implementation.

  6. Access EdgeX when security components are enabled

    main

    Starting with the Fuji release, enhanced security features are enabled by default, managed by Security-secretstore-setup and Security-proxy-setup.

    Note: In the Ireland release, security-secrets-setup is no longer an internal service because service-to-service communication does not run in TLS by default within a single box.

    When security is enabled, you must follow these rules:

    1. Access Tokens: You must create an access token and associate every REST request with it.
    2. Proxy Access: Exported external ports (e.g., 59880, 59881) are inaccessible. All REST requests must be routed through the proxy, which redirects them to individual microservices on your behalf.

    Refer to SECURITY.md for specific steps on token creation and usage.

  8. Install and Deploy Core Keeper via Docker

    main

    You can containerize Core Keeper using the included Dockerfile. Before building the image, you must run make prepare to update dependencies.

    Prerequisites:

    • Docker must be installed on your system.

    Execution Steps:

    1. Build the Docker image using make.
    2. Create a container from the image (requires specifying a name and network).
    3. Start the container.

    Note: EdgeX recommends using Docker Compose for managing containers, networks, and dependencies instead of manual Docker commands.

    cd $GOPATH/src
go get github.com/edgexfoundry/edgex-go
cd $GOPATH/src/github.com/edgexfoundry/edgex-go
# To create the Docker image
sudo make docker_core_keeper
# To create a container from the image
sudo docker create --name "[DOCKER_CONTAINER_NAME]" --network "[DOCKER_NETWORK]" [DOCKER_IMAGE_NAME]
# To run the container
sudo docker start [DOCKER_CONTAINER_NAME]

  9. Install and build EdgeX as native Go binaries

    main

    EdgeX is organized as Go Modules.

    Prerequisites

    • Go Runtime: Target version is v1.18.x. Minimum supported version is v1.18.x.

    Installation

    You can clone the repository and build directly:

    git clone git@github.com:edgexfoundry/edgex-go.git
cd edgex-go
make build

    Alternatively, if you prefer using $GOPATH:

    GO111MODULE=on && export GO111MODULE
go get github.com/edgexfoundry/edgex-go
cd $GOPATH/src/github.com/edgexfoundry/edgex-go
make build

  10. Override default Redis ACL configuration for debugging

    main

    The security-bootstrapper service's configureRedis function generates an ACL configuration file for the Redis default user named edgex_redis_acl.conf. If you need to test different ACL rules (e.g., enabling dangerous commands like INFO, MONITOR, BGSAVE, or FLUSHDB for debugging), you can override the built-in behavior using one of two methods:

    Method 1: Use a custom Redis configuration file

    You can provide your own redis.conf that points to a different ACL file name.

    1. Create a custom ACL file (e.g., developer-acl.conf) containing your desired rules. Use the + directive to add commands. Note: You must still use the {{.HashedRedisPwd}} placeholder so the password can be dynamically populated from the Vault secretstore. Example rule:
      user default on allkeys +@all -@dangerous #_{{.HashedRedisPwd}}_ +INFO +MONITOR +BGSAVE +FLUSHDB
    2. Update your redis.conf to point to this new file.
    3. Modify the database service in your docker-compose file to use your custom config file in the entrypoint script:
      exec /usr/local/bin/docker-entrypoint.sh redis-server developer_redis.conf

    Method 2: Modify the existing ACL file directly

    If you have the necessary permissions to update the file, you can modify edgex_redis_acl.conf directly. After making changes, use the Redis ACL LOAD or ACL SAVE commands to apply and persist the new rules.

  11. Install and Deploy Command Service natively

    main

    To run the Command Service as a native binary, you must first ensure ZeroMQ is installed on your system.

    Note: ZeroMQ setup is not supported on Windows platforms.

    Follow these steps to fetch the code, prepare dependencies, build, and execute the microservice:

    cd $GOPATH/src
go get github.com/edgexfoundry/edgex-go
cd $GOPATH/src/github.com/edgexfoundry/edgex-go
# pull the 3rd party / vendor packages
make prepare
# build the microservice
make core-command
# get to the command microservice executable
cd cmd/core-command
# run the microservice (may require other dependent services to run correctly)
./core-command