• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Developer Edition
Sorry, if I'm asking a lot of questions, I'm currently actively testing your product as long as I have free time, so I don't wait too much before jumping to the forum Smile

Here are some small frustrations : having only access via the Portainer interface, we have no way to customise or at least understand how it is running into the host layer.

Do you have any plan to publish on GitHub the host firmware ?  This way, the developer can have a good understanding and perhaps build a customer image based on the mainstream version.
Well Vince,

for Docker the software portainer.io offers a RESTful API next to the GUI you current see as front end and works as a Docker gateway also. You can take control of full Docker function API if you want.

A desription you find here https://gist.github.com/deviantony/77026...8d41bc42f8. This is for the stable API of versions > 1.14.x. Today we use portainer 1.12.4 which has a slightly different API. I have made a simple HTTP flow with Http Nodes in Node-RED to deploy container from remote.

No there are no plans to publish the source code.

You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

I didn't work with the NetPi very much so far, but I like to double Vince's request, as even with the few experiments I did, I can agree that, as a developer, one would really like to have access to the host system as it could possibly significantly lower debugging time.

Beside the proposed opening of the sources, maybe another approach could be to provide "dev-firmware" that allows SSH access. Having that, we could at least check out the system configuration. E.g. by being able to inspect the Docker configuration, it would become obvious why certain "features" are not available on the NetPi.

Surely, this would bear the risk that such a firmware will finally be put into the field - which would be bad, security wise. Not sure how you could circumvent that... Maybe such a firmware could be made only available to "registered developers/partners" who agreed to ensure not to distribute such a firmware into the field. Moreover, each downloaded firmware would be "customized" to contain a fingerprint of that user. With something like that, you'd at least be able to pin-point to the misbehaving developer. Another approach could be to automatically shutdown such a dev-firmware after, let's say, 3 days. Although, I'm not sure how to do this in a way that it can't be hacked...
=> These are just brainstorming ideas...
Well, netPI is not and will not be a development platform for containers. It is a Docker host only and we keep going with the strategy to offer a secure device where open features of Docker are definitively disabled, else an application in the container can get root rights of the host system and install a SSH connection for example to it which we don't want.

This strategy is of course only possible because netPI is compatible with the RPi3. This is an open system at nearly no cost (30EUR) and is THE development platform for netPI containers. Also we tell everybody not to buy a netPI, but a Raspberry Pi 3 instead first and to check if a software can be containerized and is working on RPi3 before using it on a netPI.

If you still want to insist to use netPI as a container development platform a use of the container https://hub.docker.com/r/hilschernetpi/n...vironment/ my be helpful. It is a containerized Docker (so Docker in Docker) and you can use the Docker CLI in this container. But still you can get access to the Docker Host socket on netPI with it.


You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

Just an idea...
Can you provide an installation script or Raspi3 equivalent image, so we can test on the "same" host environment into a Raspi3?

If I'm back to my concrete issue, and perhaps let's assume the root cause it perhaps into the NetPi Host docker config ( which I don't claim , don't get me wrong Smile ) , making myself the installation into Raspi with standard Raspbian and docker, perhaps I won't be able to reproduce the same environment as the NetPi, and won"t reproduce the issue there...

Anyway, I appreciate the reactivity of Armin, he's taking questions seriously and provide very detailed answers, thanks for this!

I personally don't mind having no access to host sources, I will test on Raspi3 the same containers, and if I cannot reproduce the issue, perhaps the usage I plan isn't fitting the product. I recall, I'm not a professional into industrial environment ( my real job is product manager into telecom / IoT ) , so I cannot be taken as a good reference case user. My usage is more putting to the edge the product, which I still believe has very good potential into home automation projects too.

Perhaps I didn't see it, or I read too much about docker these days, but isn't there a guide into this site about how to setup the "dev" environment into the Raspi3 (user manual perhaps)? ... if not, perhaps an article into the forum with some guidelines / steps will be useful for early adopters.

keep going, I'm hurry to test the last built Smile
This is an easy one.

Watch this forum post: https://www.netiot.com/forum/?tx_typo3fo...4044df8045
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

I also apologize for insisting on this and want to assure to that what Hilscher and especially you, Armin, are doing here, is really amazing!

I may have missed the point, but I'm still under the impression that the answers didn't help to solve the underlaying issue so far. Here's roughly how I see the situation we are faced with:

- NetPi uses Yocto - we don't have much information about what packages are installed and especially we don't know how they're configured. I.e. the content of the /etc/* is hidden to us. Therefore, we also don't know how NetPi has setup Docker, but we do know that it's not using the default config, as you've told us (e.g. we can't access all the /dev devices)

- RPi3 is usually installed with Raspian, I think this is also what Hilscher suggests (If I remember correctly from memory!). And I think we are meant to install a "vanilla" Docker into it. Therefore, this setup will use the "default config", allowing full access to /dev, etc.

=> If the above is more or less correct, then I claim that we are NOT able to run Docker containers on RPi3 under the same conditions as on NetPi, unless Hilscher makes at least the Docker configuration public. Or did I miss something?

(I first thought that the netPI-container-build-environment image may create such an environment, but I was not able to spot any special 'Docker config' while inspecting https://github.com/Hilscher/netPI-contai...Dockerfile. Did I miss something?)
Yes you miss one important thing.

Docker relies on the Linux Kernel only and the function set it is providing. This is why Docker works on Raspbian Jessie or Raspbian Stretch with Kernel 4.9 all the same as on our Yocto kernel 4.9.

Raspbian = Kernel + Applications. But Docker don't care about all the applications and commands etc. that is provided by Raspbian. With Docker the applications are added in the container.

And again, we use 100% the same source of Docker as used in Raspbian (current version 17.06.xx) except that "priviledge" mode has been restricted by us and also volume bind mapping.

Docker needs no specific configuration setting. If you install Docker on a RPi3 like described here https://www.raspberrypi.org/blog/docker-...pberry-pi/, you have 100% the same setting like on netPI.

The image you are referencing installs Docker in a Docker container inclusive the Raspbian OS application layer. So you get the feeling as if you run Docker on a RPI3, but since it is containerized you cannot deploy and run the containers since you can't map the volume /run/var/docker.sock socket interface of the Docker interface of the host. For this use a RPi3, then you can do everything with it.

You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

172 Wrote:as you've told us (e.g. we can't access all the /dev devices)

This is not correct.

I told you that you cannot map drive devices in general. So mapping the SD card host system image and the bootloader located on /dev/mmcblk0 you cannot map. All other devices can be mapped as on a standard RPi3. There is no need to neither read or write this part of the SD card. In the coming image we will allow mapping also all storage devices that are of type USB ... except drive /dev/mmclbk0 still.

This restriction is not realized with some Docker config settings as you supposed ... since we compile Docker with our Yocto project ourselves from its git hub project we modified the source code. Else you have not chance to realize such modifications.

And still there is no need to know which applications are running next to Docker on netPI. Your world are the containers only. One thing in addition. If you remove from all our netPI Docker examples on Docker Hub the cross compile section for compiling ARM code then Docker Hub would compile x86 code during the automatic build process... and believe me using Kernel 4.9 on any Intel or AMD platform these container would run all the same as on netPI. Cause it is a matter of the Kernel.

You never fail until you stop trying.“, Albert Einstein (1879 - 1955)


Forum Jump:

Users browsing this thread: 1 Guest(s)