User:Jlo
I was User:Jch but I forgot my passwd and the email used to suscribe is not valid anymore...
I'm today senior system architect at some startup.
We are building a network of embedded devices controlling hardware stuff.
I'm stepping it as the product is transitioning from prototype phase to industrial phase.
The main app is written for Oracle Java8 and running in Apache/Karaf environment.
The proto was done with Debian Jessie boxes managed with salt stack (about 100).
I would like to see the boxes running AL in run-from-ram mode pulling the apkovl tarball (or at least some tarball to be applied in the /etc/local.d sequence) from a remote server somewhere in the cloud.
To upgrade would just to rsync the normally read-only SSD and reboot.
To achieve this with AlpineLinux, one has to:
- deploy Oracle Java 7 with glibc
- deploy Oracle Java 8 with glibc
- deploy python2.7 with needed libs
- deploy python3 with needed libs
- deploy hardware watchdog
- deploy network drivers (eth, usb-eth, wlan, 3g, lte)
- deploy USB drivers
- rewrite init scripts
- prepare a custom image with every needed packages locally present in disk repo
- adapt custom packages from deb to apk ones
To configure a box is done in two parts:
- the network. done locally
- the app layer. done via a webinterface; commited to a server and download by the box at each boot.
The advantages of such architecture are:
- power failure resilient as the system runs from ram
The only PoF here is when an upgrade of the read-only medium is done - boxes use a pull mechanism to stay up-to-date ensuring the right version at any next reboot
This protect us against out-of-sync boxes arraising often with push architecture (salt, ansible, ...) - the two steps boot sequence allows us to temporary take control over a box for maintenance with a totally different setup
and as we always keep an ssh access via the VPN, we can force that anytime we want (hardware watchdog being our friend here) - easy to reproduce in VM for testing (including load tests)
Disadvantages are:
- need own repo with access control to distribute Oracle Java internally without breach of license
(but it is the same situation for any distro) - some used packages are distributed as deb only (from artifactory between others)
will need to script part of the CI towards apk generation...
will need to check every deb to see if sources are available...