User:Jlo: Difference between revisions
No edit summary |
mNo edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
The main app is written for Oracle Java8 and running in Apache/Karaf environment. | 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 | 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.<br/> | 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.<br/> | ||
| Line 14: | Line 14: | ||
To achieve this with AlpineLinux, one has to: | To achieve this with AlpineLinux, one has to: | ||
* deploy [[User:Jlo/ | * deploy [[User:Jlo/java8|Oracle Java 7 with glibc]] | ||
* deploy [[User:Jlo/java8|Oracle Java 8 with glibc]] | * deploy [[User:Jlo/java8|Oracle Java 8 with glibc]] | ||
* deploy [[User:Jlo/python27|python2.7 with needed libs]] | * deploy [[User:Jlo/python27|python2.7 with needed libs]] | ||
* deploy [[User:Jlo/python3|python3 with needed libs]] | |||
* deploy [[User:Jlo/watchdog|hardware watchdog]] | * deploy [[User:Jlo/watchdog|hardware watchdog]] | ||
* deploy [[User:Jlo/network|network drivers]] (eth, usb-eth, wlan, 3g, lte) | * deploy [[User:Jlo/network|network drivers]] (eth, usb-eth, wlan, 3g, lte) | ||
| Line 29: | Line 30: | ||
* 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 | The advantages 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 | * 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 | ||
| Line 35: | Line 36: | ||
* 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) | * 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) | * 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<br/>(but it is the same situation for any distro) | |||
* some used packages are distributed as deb only (from artifactory between others)<br/>will need to script part of the CI towards apk generation...<br/>will need to check every deb to see if sources are available... | |||
---- | |||
See also [[User:Jlo/Replacing_Debian_Jessie_with_Alpine_remotely|Replacing Debian Jessie with Alpine remotely]] | |||
Latest revision as of 07:00, 20 September 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 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...