User:Jlo: Difference between revisions

From Alpine Linux
(Created page with "I was User:Jch but I forgot my passwd and the email used to suscribe is not valid anymore...")
 
mNo edit summary
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
I was [[User:Jch]] but I forgot my passwd and the email used to suscribe is not valid anymore...
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.<br/>
We are building a network of embedded devices controlling hardware stuff.<br/>
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.<br/>
To upgrade would just to rsync the normally read-only SSD and reboot.
To achieve this with AlpineLinux, one has to:
*    deploy [[User:Jlo/java8|Oracle Java 7 with glibc]]
*    deploy [[User:Jlo/java8|Oracle Java 8 with glibc]]
*    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/network|network drivers]] (eth, usb-eth, wlan, 3g, lte)
*    deploy [[User:Jlo/usb|USB drivers]]
*    rewrite [[User:Jlo/init|init scripts]]
*    prepare a [[User:Jlo/image|custom image]] with every needed packages locally present in disk repo
*    adapt [[User:Jlo/packages|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<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)
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:

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...

See also Replacing Debian Jessie with Alpine remotely