Create Dockerfile

[trivialkettle]

No description provided.

[arobenko]

Sorry, I'm reluctant to add something to the code base I'm personally not ready to maintain.

[trivialkettle]

Can I do anything to enable you to maintain it?

[arobenko]

I guess such docker files are something more personal than generic. I don't think they belong to the repository.
I can understand submitting docker files as bug reports to reproduce some build failures that are not visible in github actions, but not as part of official sources. If you need them, it's better if you create your personal repository for the purpose and just use CommsChampion Ecosystem in your build scripts as you wish. If you think such repo is going to be useful for other developers, we can think of bringing it under the umbrella of the CommsChampion Ecosystem organization in the future to make it official.

Also "prepare_externals" scripts are there to help me during development, they are not part of official build process. I would recommend using cc.cmake instead to build any project from the CommsChampion Ecosystem, it will automatically bring all the dependencies that you need.

[trivialkettle]

A lot of projects provide a official Dockerfile and a docker imaged uploaded to docker hub (you can browse official images here). This simplifies the project deployment, since you don't need to build it by hand or have a machine with the correct dependencies. Also it's easier to integrate it in a docker based deployment. An official image has the charm, that you only need to trust one person (the developer) and not someone else (the docker image provider) to to provide frequent updates and don't mess with the code.

Also "prepare_externals" scripts are there to help me during development, they are not part of official build process. I would recommend using cc.cmake instead to build any project from the CommsChampion Ecosystem, it will automatically bring all the dependencies that you need.

I will have a look at this.

[trivialkettle]

I updated the Dockerfile to use cc_cmake.

You can build it using

docker build . -t mqttsn-gateway

I don't know if it is possible, but if you could publish the binaries from github actions, I could just download them into a ubuntu docker image.

[arobenko]

While I understand your reasoning and see the appeal, I'm still reluctant to make it a part of this repository. Here is why:

• The primary deliverables of the CommsChampion Ecosystem are libraries, the provided applications are more or less examples of how to use the libraries. Their main purpose is to be a reference code on how to use the library.
• The provided default configuration for the example application happen to work for your use case just by a happenstance. Forcing its usage in the docker image is quite "narrow".
• I'm personaly quite infrequent docker user and know very little about the docker ecosystem and infrastructure. I use it on vary rare occasions just to perform builds on older OSes with older toolchains that don't work in the more modern environment. As the result, in future releases I will definitely forget to update the Dockerfile.
• The primary clientele of the CommsChampion Ecosystem is embedded systems, for which I provide package management as separate projects (buildroot, yocto, there is even vcpkg support). These package managers allow platform specific build as well as runtime customizations.

With all said above I can envision possible future docker support as a separate project, say cc.docker, which will provide and manage Dockerfiles for various possible "solutions". It can chase after and accumulate the releases of other CommsChampion Ecosystem projects and have it's own releases, similar to the cc.cmake. It can also have multiple scripts to upload the configurations to the docker hub manually or via github actions if needed. When it's in a separate project I can have someone else with more docker knowledge and experience to maintain and look after it. If it's going to be under the umbrella of the commschamp organization, then it's still going to be "official" rather than third party builds.

As a side note, I see you enforce build with C++20 standard, while the "official" default build is C++17, (C++20 and C++23 builds are supported just for the source code quality and easy possible future upgrade). Why such enforcing should be in the "official" docker file for the gateway application? You see, there are lots of nuances that you try to enforce on others by creating a single "official" Dockerfile. What about the client applications of pub/sub? Are there any docker files for them? It can get cluttered very fast.

[trivialkettle]

Hi,
I get you points and can feel your trouble if you are not that familiar with docker.

However the example mqttsn gateway still works better than than the only other maintained mqttsn-gateway I found (https://github.com/eclipse/paho.mqtt-sn.embedded-c) and it would be a shame if it is not used / disappears into oblivion.

The provided default configuration for the example application happen to work for your use case just by a happenstance. Forcing its usage in the docker image is quite "narrow".

The usage is not forced, I just copy the default config, so that at least a config is available and the gateway starts out of the box. It's pretty easy to change:

docker run -it -v $(pwd)/my_config,conf:/usr/local/etc/cc_mqttsn_gateway/cc_mqttsn_gateway.conf mqttsn-gateway:latest

or mount it somewhere else and pass -c <path to config> to the gateway.

I see you enforce build with C++20 standard

Yes, that's my mistake, somehow I thought the docs say c++20. I am gonna fix this.

Why such enforcing should be in the "official" docker file for the gateway application?

I am not exactly sure what you mean, I think the docker image contains the program built with the recommended build settings. Since one docker image should only contain one service, there is no side-effect to other programs.

What about the client applications of pub/sub?

I took a look at the official mosquitto broker image, and noticed that they include the client programs like mosquitto_sub and mosquitto_pub into the image. The clients could be added to the mqttsn-gateway image as well.

With all said above I can envision possible future docker support as a separate project, say cc.docker, which will provide and manage Dockerfiles for various possible "solutions".

That seems like an interesting architecture, but I would be more than fine with it.

[arobenko]

To the best of my very shallow understanding of the docker ecosystem is that you can create a bootable image which you start and get a console within it, or specify command to be executed right away. I wasn't aware of the ability to change the arguments to the command.

Is there a way to specify a full custom command line in the docker invocation arguments to be executed when image is up? If yes, then maybe a full "CommsChampion Ecosystem" (just the apps without the "tools" related projects) should be provided as a docker image and the user can invoke that image with any command he/she likes.

Anyway if you're up to it, maybe you can create such a project in your personal space (use the cc.cmake as a repo for all your possible builds) with proper README of how to use it. If we're both happy with how it looks like and works, then maybe we can move it to the the commschamp organization and you'll be assigned as a main developer there.

[trivialkettle]

There are two ways to set the start command from a Dockerfile.

1. ENTRYPOINT
2. CMD

They both play hand in hand and you can also override both in docker run, see: https://docs.docker.com/reference/cli/docker/container/run/

docker container run [OPTIONS] IMAGE [COMMAND] [ARG...]

To run ls -l in debian image I can just pass it as COMMAND and ARG::

docker run -it --rm debian:bookworm-slim ls -l

or set the entrypoint to ls and pass -l as COMMAND:

docker run -it --entrypoint=ls debian:bookworm-slim -l

As you can see, I can pass ls -l to the image as command (after the image) or override the entrypoint of the image to ls and pass the cli arguments for ls as command (after the image). So it is pretty much everything customizable during docker run`.

Is there a way to specify a full custom command line in the docker invocation arguments to be executed when image is up? If yes, then maybe a full "CommsChampion Ecosystem"

Yes:

docker run -it --rm comms-champion cc-mqttsn-gateway -c <path> 

docker run -it --rm comms-champion cc-app-foo -xyz 

[trivialkettle]

then maybe a full "CommsChampion Ecosystem" (just the apps without the "tools" related projects) should be provided as a docker image and the user can invoke that image with any command he/she likes.

I thought about this and reread

• https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/
• https://docs.docker.com/get-started/docker-overview/

IMO all apps should get their own container, to keep image size small. Nethertheless we could start like this and see how big the image gets. What apps would like to see in the image?

[arobenko]

For starters I suggest creating two different containers "apps" and "tools". Please use "develop" branch of the cc.cmake project for now.

Apps Container

• Use config/AllApps.cmake configuration.
• It will build all client applications from the "cc.X.libs" projects, including the gateway application.
• Consider removing all contents of the <install_dir>/include folder as well as removing static libraries from the <install_dir>/lib after the build to reduce size.
• You may also consider passing the -DBUILD_SHARED_LIBS=ON to the cmake to force building shared instead of static libraries to reduce the image size.
• Install boost libraries before the build.

Tools Container

• config/AllTools.cmake configuration.
• It will build the CommsChampion Tools and all the available plugins. I use this tools quite often to observe the exchanged messages of the protocol, library for which I'm implementing.
• Consider removing all contents of the <install_dir>/include folder to reduce size.
• Use "cc_view" application to start.
• Install Qt5 (or Qt6 with extra -DOPT_QT_MAJOR_VERSION=6 cmake option) libraries before the build.