[Update] Installer (et exploiter) Docker sur des architectures « non supportées » (Raspbian/Intel 32 bits)

Publié le par admin

[Update] Docker natif sur la dernière version de Jessie

Suite au dernier Update de Raspbian  (Release date: 2016-02-09) docker s’installe d’un simple apt-get install docker.io

Limitations constatées (par rapport à la version Hypriot) :

Disparition du -f pour le build

Impossible de spécifier le Dockerfile de cette manière

<code>

docker build -t favela/lampbase:1.0.0   -f ./lampbase.dockerFile   .

</code>

Obliger de créer un fichier Dockerfile (avec un D majuscule) et de la copier dans un répertoire (ex : lampbase)

<code>

docker build   -t favela/lampbase:1.0.0  ./lampbase/

</code>

Un simple docker pull resin/rpi-raspbian:jessie plante (trove pas le endpoint) : je repars donc sur la version Hypriot.

 

Docker ne supporte que les architectures 64 bits.

Cela est fort dommage car cela nous prive de nombreuses target de test et/ou d’exploitation.

Heureusement il existe des initiatives pour porter Docker vers des architectures autres :

Debian Intel  32 bits


apt-get update

apt-get install docker.io

Plus qu’à tester (en root) avec un « docker ps  »

Raspbian (Raspberry Pi)

  • La team Hypriot a réalisé un formidable travail de portage de docker sur Raspbian.
  • Téléchargez le .deb à l’adresse suivante partie « Hypriot Docker Debian Packages for Raspberry Pi »
  • Puis un simple

dpkg -i package_name.deb

 

Et cela fonctionne même sur un simple Raspberry Pi Zero !

PS : je n’ai testé que sur Debian Jessie pas sur Wheezy.

PS2 : le service docker n’est pas lancé au boot,  pensez à le lancer avant vos tests.


service docker start &amp;amp;amp;amp;&amp;amp;amp;amp; service docker status

Ubuntu ARM



apt-get install docker.io

 

Attention au bon choix de vos machines docker

  • Attention : les images Docker récupérées sur le hub docker sont en majorité des images Intel 64bits : donc incompatibles avec nos target de test.
  • Pensez à bien vérifier la compatibilité de vos images.

Des test à la Prod

  • Si vos dockerfiles sont bien écris , le passage d’une plate-forme de test à une prod 64 bits ne devrait pas poser de problème (en restanbt sur le même type de distribution évidement, par exemple d’une Raspbian à une Debian) : seul le FROM devra être changé.

 

UFDBGuard : Time-Based ACLs et Default ACL

Publié le par admin

Ajouter une règle de plage horaire

UFDBGuard propose une gestion des horaires (voir page 36 de leur manuel).

On peut, grace à cette ACL, appliquer (ou non) des politique de blocage/ouverture sur des catégories de domaines/Expressions…

Par exemple : bloquer le sport et les sites de rencontre  aux heures de bureau mais les ouvrir en dehors.

La doc est très claire quant on utilise des ACL multiples mais mais ne signale pas que ce type d’ ACL n’est pas compatible avec l’ACL défaut.

 

Exemple d’ACL ne fonctionnant pas

 


time free-time {
weekly * 12:00-13:30
}


# define web content access rights
acl {

default outside free-time {
pass !porn !sport !dating any
}else{
pass !porn any
}
}

Un coup d’oeil dans les log vous montrera que UFDBGuard est en « FATAL ERROR » à chaque fois qu’il est sollicité.

Il semblerait qu’il soit impossible d’associer une ACL Time à Default. Bien dommage quant on n’a pas besoin d’avoir une policy (basée sur IP, groupe…) .

On va donc devoir créer une policy (qui soit toujours vraix) pour court-circuiter default.

Pour ma part j’ai créer une policy sur ma plage IP (car je sais qu’elle sera toujours vrai).
Je suis sur une plage 172.16.x.x


time free-time {
weekly * 12:00-13:30
}

src blacklistsrc {
ip 172.16.0.0/16
}

# define web content access rights
acl {
blacklistsrc outside free-time
{
pass !porn !sport !dating any
}
else
{
pass !porn any
}
default {
pass any
}
}

Avec une ACL « non default » tout fonctionne correctement.

Plusieurs plages horaire de pause ?


time free-time {
weekly *        12:00-13:30
weekly *        16:00-16:30
weekly thu,fri  11:30-12:00
}