I’m brand-new to elixir and functional programming languages – where should I post a project synopsis as I’m looking for community feedback on the best ways to proceed?
I really like what I see with the Phoenix elixir platform I feel it can standardize development and deployment however I’m looking for some input on the below project.
RabbitMQ - Client/Messenger
Postgres
Redis – May not be needed as I heard Erlang ships with a cache.
Elixir/Phonix/Erlang
Desirable functionality includes…
continuous improvement at the hardware platform level. thus keeping the codebase all in one spot and just changing how it’s deployed to specific hardware devices.
a way to incorporate SSH tunnels via external server ( not sure which open-source tool to use for this – ideas welcome? ) to be used for SSH logins, sscreen casting and other external ports.
ability to have device find other devices that are similar and determine which one is the server.
Automatically load chrome or WebKit into kiosk mode on startup along with launching the Phoenix/elixir web framework And connecting to a local Web server.
ability to check for upgrades that may be off-site. If a new update is found to update and potentially restart.
I’ve seen the nerves project, as I tried to install it from the set of docs I found it’s a bit out of date. is nerves keeping up with existing Phoenix elixir erlang releases? or is nerves not even the right fit for this?
I have used and Ansible (Python) to configure low-level systems that are platform-independent. It works well and is very consistent but I’m looking at level up if possible.
Depending on what you want to use this for, it may not be required for the same reason Redis may not be.
Distillery can create distributable release packages for you.
Elixir comes with ssh (client and server) support built in, so you can allow ssh connections directly to your running Elixir application. It’s actually part of OTP itself, but there are some nice Elixir libs built on it such as esshd for server functionality and sshex / sshkit for client side. Or you can use the lower-level OTP ssh application directly if you wish.
Service discovery … not really enough details here to help you, I’m afraid. e.g. how “the server” is defined (locality? functionality? are they statically addressable or is addressing of the servers also dynamic, …?)
That sounds like a job for e.g. systemd to manage, along with some user-proofing of the UI to prevent user exit, navigation etc. Hard to suggest what may be an optimal solution there without understanding a lot more about your project …
It t depends on what sort of access you have to the targets. But having targets check for new releases published $SOMEWHERE and install them “hot” is pretty easy to do.
It’s last release was only 26 days ago. It’s certainly active and maintained! It doesn’t rely on the latest and greatest Elixir (minimum version is 1.4) but you can certainly modify that yourself and bump the requirements.
Sounds like you are trying to make a client-facing device with restricted access. Nerves is more focused on embedded / IoT-type devices. So perhaps not, as you’ll want to be bringing up a GUI as well …
If it’s any reassurance, the product I’ve worked on for the last year or so (deployed and in production for more than 8 months now) has a lot of similarities to what you’re looking at. It’s an Elixir/Phoenix/Angular application running on kiosk hardware (so, a touchscreen panel with a “regular” computer built-in) with chromium running in kiosk mode. Local data is stored in a postgres instance running on the box. Data is synced between the kiosk and a central service (and to other kiosks in the location) using essentially an ad-hoc combination of REST apis and websockets (something like RabbitMQ would probably be a good deal better here).
We haven’t used Nerves for this, in small part because our hardware is essentially a regular x86 computer, and in large part because we were in a hurry when initially developing this and felt like sticking to a “normal” distribution (and not taking extra time to get familiar with buildroot and the rest of the nerve ecosystem) was the right corner to cut. Nerves has come a long way in the last year, I think, so it’s probably worth taking a long look at, especially if your hardware is more on the “small computer” side of things.
We use saltstack to manage this infrastructure, I’m sure something like ansible would work just as well.
I do believe it’s possible, though I don’t think it’s necessarily a great fit for our particular system. If the “central service” was co-located with the kiosks on the same network it would probably be just fine. In our system though, we have a number of different installations in different geographical locations, while our “central service” sits in our own data center, and we can’t guarantee the reliability of the network between the two.
I’m not sure if it’s officially documented anywhere, but I believe it’s sort of “common knowledge” that standard distributed erlang works best within a single data center, and doesn’t necessarily scale into the many hundreds or thousands of nodes [1].
Since our kiosks work in an “offline first” mode, regular old HTTP requests to do the actual syncing of data (the websockets stuff is more just status/diagnostic info) are a fairly reliable method that has the benefit of everyone on the team understanding how they’re supposed to work. As I mentioned in my earlier comment, we were pretty tightly constrained for time when we initially developed the system, so the “familiarity” factor also counted for a lot there.
If we revisit our syncing system at some point in the future, I’d definitely spend time looking at systems like RabbitMQ as well as some of the newer exciting stuff people are working on like lasp/partisan.
