Sorry for the delayed response, I was preparing the example as the answer is slightly more involved.
In the tedge-demo-container project, we have recently added an example which matches what you’re asking.
But first a bit of of background on the initial goals of the tedge-demo-container repo. This repo was aimed at reducing the reliance on raspberry pi when users just want to explore thin-edge.io. We wanted to provide an environment which mirrored a debian based operating system, with all of the dependencies which are normally found on a full Debian installation, this included Systemd. The goal was not to create a “slim” container, but to create a containerized “device”.
However, we’ve added a new example recently which goes in the direction of a real “containerized” thin-edge.io setup.
Have a look at the alpine-s6 folder in the tedge-demo-container project for the example you’re looking for.
The alpine-s6 example uses two containers:
- mosquitto container (using custom entrypoint script)
- alpine image running thin-edge.io components and talks with the mosquitto hosted in the other container.
Now I must admit the setup is not yet perfect, but we are getting close. The sections below describes each of the containers used in the setup, and a few key points about them.
mosquitto container
The mosquitto container is slightly tricky as there needs to be some initialization before the mosquitto process starts up, though the exactly handling depends on your use-case, but it should give you an idea of one way to solve it, and you can adjust it to your needs.
But the key point of the mosquitto container is:
- the bridge file/configuration and bridge certificates must be created before the mosquitto process starts
There are different ways to fulfill this requirement, and the solution generally depends on how you plan on injecting the device’s certificate into the container.
The example in the repository uses a customer entrypoint to solve this problem by blocking the startup of the mosquitto process until the device’s certificate and bridge configuration has been configured. This makes sure that when the mosquitto process starts up, it has all the information it needs to make a successful cloud connection.
thin-edge.io container
The thin-edge.io container uses a light weight and container friendly init system called s6-overlay. This init system applies the “one container, one function” mindset (not “one container, one process”). This means that this container actually runs multiple processes in the same container, however since s6-overlay was designed from the ground up to work in containers, it plays nicely with environment variables, logging and container start/stop/restart commands.
You can check out the custom mosquitto-entrypoint.sh to see for yourself what is going on.
The container uses an external mosquitto client (communicating over the tedge docker network) to reach the mosquitto mqtt broker (running in the other container). You don’t need to run tedge connect c8y in this container, that is reserved for the mosquitto container.
Currently the container must a shared volume with the mosquitto container to gain read access to the public device certificate (as the certificate’s common name is the device’s identity when communicating with the cloud). Though this requirement will be removed in the future when this information will be made available via the MQTT interface.
Summary
Though it must be noted that extra configuration may be required to get some of the other features to work. For example, if you want to use the log file retrieval functionality, then you need to also make sure the thin-edge.io container has access to the filesystem where the logs are stored. You can achieve this by sharing volumes with the container. The normal container best practice rules also apply, so you should not do any state manipulation inside the container itself (e.g. don’t install additional applications/services in the containers at runtime, instead add them to your container definition via the Dockerfile).