In many industries (e.g. medical, energy, aeronautics) companies must produce products that can also be installed in environments where no internet connectivity is available/permitted. These same products however, are also often installed in places where they can leverage cloud (OnDemand) capabilities. If IoT-Edge ist to be applicable for such products, it must (by design) provide for:
1. Installation from download or USB-stick including configuration via config file or local API (as did Edge V1)
2. Provide and abstraction layer to the external communication (as was done via Edge V1 Modules) enabling a configurable routing to use OnPremises endpoits (REST) or OnDemand endpoints (e.g. via IoT-Hub), also via a restrictive corporate proxy (only https:443 permitted)

3. Long-term operation in the above (1. and 2.) context without the necessity of cloud connectivity.

The above 3 features wouls allow hybrid-environment product developers to use IoT-Edge as a single-source sollution.

I am sure that this scenario comprises (or will soon comprise) many thousands of product companies.

Our customer has a requirement to run multiple instances of the runtime on a single machine to isolate multiple process workflow and edge lifecycle on a single piece of hardware.

I have confirmed that this is not supported, due to the following issues:
1. iotedgectl setup will copy the –config-file to /ProgramData/azure-iot-edge overwriting the last setup call.
2. iotedgectl start will create a new docker network that is bound to the config file in ProgramData.

There is currently no workaround for RPI profile devices, but for devices that can support VMs – the runtime can be installed on a VM.

Ideally, the implementation of this follows a pattern like docker so I could run something like

iotedgectl setup edge1 –config config.json
iotedgectl start edge1
iotedgectl stop edge1
iotedgectl restart edge1
etc.

And a mapping of IoT Edge named instances to config files are stored in ProgramData.

The iotedge_1.0.0-1 _amd64.deb package required libssl1.0.0 but Debian 9 does not provide the libssl 1.0.0 package.
So, please use libssl 1.0.2 or libssl 1.1.0 instead of libssl 1.0.0.

# dpkg --info iotedge_1.0.0-1_amd64.deb
new debian package, version 2.0.
size 2962854 bytes: control archive=2857 bytes.
91 bytes, 4 lines conffiles
760 bytes, 17 lines control
936 bytes, 14 lines md5sums
6272 bytes, 158 lines * postinst #!/bin/sh
1586 bytes, 57 lines * postrm #!/bin/sh
1548 bytes, 65 lines * preinst #!/bin/sh
391 bytes, 25 lines * prerm #!/bin/sh
Package: iotedge
Version: 1.0.0-1
Architecture: amd64
Maintainer: Azure IoT Edge Devs
Installed-Size: 15319
Depends: init-system-helpers (>= 1.18~), libc6 (>= 2.18), libgcc1 (>= 1:4.2), libssl1.0.0 (>= 1.0.2~beta3), adduser, ca-certificates, hostname, libiothsm, sed
Section: admin
Priority: extra
Multi-Arch: foreign
Homepage: https://github.com/azure/iot-edge
Description: Azure IoT Edge Security Daemon

There are two challenges that should not exist when developing custom Node.JS modules for IoT Edge:

1) Not being able to access the values in process.env without writing them programmatically into the JSON file that is passed to the instantiation of a gateway seems completely avoidable. Since, the azure-iot-gateway uses it's own Node.JS runtime, I understand why this is not happening right now but all env variables should be passed on to the individual modules themselves automatically by the azure-iot-gateway.

2) The custom modules do not easily allow for any asynchronous tasks to be performed. This is the biggest problem I having. Part of the problem here is that the individual module runtimes are still using Node.JS version 6.x.x so we are missing out on the enhanced abilities of the latest LTS Node.JS version for handing asynchronous tasks. The main issue with the edge modules I would like to see improved is the ability to perform tasks like connection to external services asynchronously within the "create" phase of a module and making sure all the connections return before the "start" phase takes place. This could be achieve be allowing the "create" phase of an edge module to return a promise. For example, this is simplified, but something like this is what I am looking to return during the "create" phase:

return createContainer()
.then((res) => true)
.catch((err) => false)

The inability to do the following is forcing me to handle all my asynchronous connection tasks in the main index.js file before the gateway starts which leads to poor programming standards because connecting to those services logically should not belong in the index.js file.

Overall, I am liking what I am seeing but under the current implementation and the two problems I have listed, it is difficult to split the edge modules into small individual files. Normally, I split my node modules into a structure like /modules/person/index.js, /modules/person/storage.js, etc. The use case for me today is that I need one of my modules to connect to azure storage before the module starts and given the two problems above I have no way to separate the main logic of the edge module from the logic behind azure storage and for handling the initialization of storage containers before the module starts.

We are using a Raspberry Pi Zero W for a large-scale IoT sensor rollout. Our plan is to use IoT Edge on Raspbian (Linux) to run our Python software on the devices and leverage the IoT hub to deploy our code via modules to our devices. We also want to use the IoT hub Device Provisioning Service to further automate the rollout of newly added devices. The goal is to make this scalable to 1.000 devices as a Proof of Concept, and in a production phase scale up to 50.000-100.000 devices.

We've tried to follow the tutorial by Microsoft to run auto-provisioning-service:
https://docs.microsoft.com/en-us/azure/iot-edge/how-to-auto-provision-simulated-device-linux

When this didn't work we opened a Github ticket:
https://github.com/MicrosoftDocs/azure-docs/issues/11420#issuecomment-404443272

There it was mentioned that IoT Edge needs to support X.509 certificates for this to be possible, since the Raspberry Pi does not have a TPM chip on board. That's why we are requesting to support X.509 certificates for IoT Edge and the DPS.