Note
To read more on how to deploy plgd hub to Kubernetes using helm chart, continue here.
There are multiple ways how to start using / testing the plgd hub on your own infrastructure. If you’re just trying to get in touch with this IoT framework, go back to Control device remotely tutorial and use our free try.plgd.cloud instance. In case you want to get in touch with the system localy and you have the Docker installed, use our plgd hub #Bundle.
To read more on how to deploy plgd hub to Kubernetes using helm chart, continue here.
Bundle deployment hosts core plgd hub services with mocked OAuth Server in a single Docker image. All services which hosts the gRPC or HTTP API are proxied through the NGINX with configurable NGINX_PORT and FQDN. Client application used in the Control device remotely works also with the bundle.
Bundle version of plgd services should be used only for simple testing and development purposes. Performance evaluations, production environment or other sensitive deployments should deploy plgd services using the plgd HELM chart.
To deploy and access plgd hub on your local PC using bundle, run single command:
docker run -d --name plgd -p 443:443 -p 5683:5683 -p 5684:5684 ghcr.io/plgd-dev/hub/bundle:latest
After couple of seconds your plgd hub will become available. The plgd dashboard can be opened in your browser at https://localhost/.
Note that bundle issues it’s own self-signed certificate which needs to be accepted in the browser.
The plgd hub doesn’t work without OAuth Server. To not require developers not interested in sharing bundle instances with other users, a simple OAuth2.0 Mock Server is included in the bundle. Authentication to the plgd is therefore not required, and the test user is automatically logged in. The same applies also to device connections; in case you’re using the bundle, devices connecting to the CoAP Gateway can use random/static onboarding code as it’s not verified. Onboarding of devices is therefore much simpler.
OAuth Server which is part of the plgd is only for testing and development purposes. For the production, integration of the plgd with the external OAuth2.0 server is required.
443. This port might be already occupied by other process, e.g. Skype. Default port can be changed by environment variable -e NGINX_PORT=8443. Please be aware that the port needs to be exposed from the container -> -p 443:443 needs to be changed to match a new port, e.g. -p 8443:8443./data path. Run the container with -v $PWD/vol/plgd/data:/data to be able to analyze the logs in case of an issue.plgd makes it simpler to build a successful IoT initiative – to create a proof of concept, evaluate, optimize, and scale.
