User:Jlo: Difference between revisions
m (add links to future studies) |
No edit summary |
||
| Line 28: | Line 28: | ||
* the network. done locally | * the network. done locally | ||
* the app layer. done via a webinterface; commited to a server and download by the box at each boot. | * the app layer. done via a webinterface; commited to a server and download by the box at each boot. | ||
The advantage of such architecture are: | |||
* power failure resilient as the system runs from ram<br/>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<br/>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<br/>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) | |||
Revision as of 10:27, 10 June 2017
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 boxes managed with salt stack (about 100 of those with a mix of Wheezy and Jessie).
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 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 advantage 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)