Multiple devices, single Application

Product support
1

Hi, we have an app running on different devices (ie: nuc, pi, jetson) we different Dockerfiles. Is there a way to have different types of devices on a single application or alternatively being able to use separate dockerfiles per device and pushing to different remotes.

The dockerfile.template is not appropriate as we aren’t using some of the resin.io base images.

Thanks!

5

Hello,
At the moment each application is tied to a specific device type. I guess that you could add multiple remotes to your git repo, each pointing to a different resin application. Or alternatively, you could maintain multiple branches with your separate Dockerfiles. In any case, we have internally tagged your message with a feature request for applications with mixed device types.

6

Thanks @izavits

7

Another quick thought on this thread is that if you use the same %%RESIN-MACHINE-NAME%% vocabulary in your base image catalog, then you could use FROM brice/%%RESIN-MACHINE-NAME%%-whatever in a dockerfile.template

15

Hi @brice, one more thing, you can create Dockerfile variants that can be specific to specific devices types and can exists next to each other in your code. This is using the device type 's slug, or the architecture, and priorities are observed by the builder in order of specificness.

For example, if you want one for the NUC, you could have

  • Dockerfile.intel-nuc (most specific, extension same as %%RESIN-MACHINE-NAME%% would be in a template)
  • Dockerfile.amd64 (architecture level, extension same as %%RESIN-ARCH%% would be in your template)
  • Dockerfile.template (least specific, captures all device types, and can use e.g. those above template variables)

So in your case you could have Dockerfile.intel-nuc, plus Dockerfile.raspberry-pi (or .raspberry-pi2, or .raspberrypi3 depending on which Pi you mean), and Dockerfile.jetson-tx2, next to each other, and you could push the same repo to the 3 different applications (maintaining the three different git remotes).

Our documentation is a bit sparse on this, but we are trying to gather things in a non-confusing way. An example of this being used (on the architecture level) you can see in our Multicontainer Getting Started project, the haproxy service: https://github.com/resin-io-projects/multicontainer-getting-started/tree/master/haproxy

Let us know how does it work if you try it out!

17

awesome thanks @imrehg didn’t know about the file naming convention for different devices :+1:

18

Once you’ve defined different container names for different architectures, you then run into this problem - can’t use the resin variables in the docker-compose file: Multicontainer docker-compose.yml & resin environment variables

Any thoughts on that would be appreciated.

19

@jgentes replied in that thread. Please note, those are not environment variables but Dockerfile template variables.

21

Hi,

Just a quick update on this, while applications with mixed architectures are not yet supported, we figured you’d still be interested to know that resin.io application now support different device types in the same application, as long as they share the same architecture. For example, you could have an application with both Raspberry Pi 3 and BeagleBone Black devices, as they both use an ARMv7 processor.

For reference, you can find the relevant documentation section here.

Let us know if you have any questions or feedback!

Best,
Kostas

22

@lekkas thanks for the update – are there still plans to support mixed architectures in the future?

I’m looking to run Raspberry Pi 3 B+ and Raspberry Pi Zero W devices in the same applications.

Thanks,
Will

25

Hi @wlisac, it is quite likely we will have mixed architectures in the future, but it’s not the immediate future, somewhat further down the line. It needs a few things ironed out and some decent-sized changes to our backend to work properly.

In the meantime, have to use 2 separate applications for the the Zero and the Pi3

28

Hi @wlisac, it is quite likely we will have mixed architectures in the future, but it’s not the immediate future, somewhat further down the line. It needs a few things ironed out and some decent-sized changes to our backend to work properly.
In the meantime, have to use 2 separate applications for the the Zero and the Pi3

1 Like