Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue106:c_c [2016/03/09 10:45] – frangi
+++ issue106:c_c [2016/04/18 14:00] (Version actuelle) – créée andre_domenech
@@ Ligne 1: / Ligne 1: @@
-===== 1 =====
+**After having set up my intel NUC (see last month’s article for more information), I started using NGINX and Apache to serve my in-progress web projects. However, setting up various virtual hosts, managing it, and a complicated series of dependencies, had me abandon that plan relatively quickly. Instead, I switched to Vagrant for a few projects. Unfortunately, while setting up a Vagrant system is pretty quick, it’s also heavier than it needs to be resource-wise. Instead, I looked into Docker. This month, I’d like to cover what Docker is, and how I’ve set it up to manage my various web projects.**
-**
-Near the end of January, I was informed that a local retailer would be receiving a shipment of NUC6i5SYH (the i5 Skylake NUC with a 2.5” drive bay). So I promptly ordered one with 16GB of DDR4 RAM, a 256GB m.2 drive, and waited semi-patiently for it to arrive. In this month’s article, I want to cover what I’m using it for, my thoughts on it, and Linux support for Skylake.
-Purpose
+Après avoir installé mon NUC Intel (pour plus d'informations, voir l'article du mois dernier), j'ai commencé à utiliser NGINX et Apache comme serveur de mes projets Internet en cours de développement. Toutefois, installer différents hôtes virtuels et les gérer avec un ensemble de dépendances compliquées, m'ont assez rapidement incité à abandonner cette méthode. À la place, je suis passé à Vagrant pour quelques projets. Malheureusement, alors que l'installation d'un système Vagrant est assez rapide, il est bien plus lourd que nécessaire en ce qui concerne les ressources. J'ai donc envisagé Docker. Ce mois-ci, je vais parler de ce qu'est Docker et de comment je l'ai paramétré pour gérer mes différents projets Web.
-I ordered the taller model for the 2.5” drive, since I own a few spare drives, in case I need more storage space down the line. The goal is for this to become an “always-on” PC. It hosts a DNS for my internal network, a PXE boot server (for network booting ISOs), and will soon run NGINX + Apache. In order to help with my development work, it is now also hosting my Git repositories, which I can clone and keep up to date from other devices. But that’s not all! I have a 3TB MyBook external USB drive that I keep my larger files on. When I got the NUC, I reformatted it into btrfs, and shared it as a samba share on my network, meaning I can just simply log into the network and download whatever Linux ISO I may need for a virtual machine, or access my design asset library.
+**What is Docker?
-And, finally, I’ve also set it up with AwesomeWM (and GNOME3) for my desktop usage. It’s currently powering two monitors, and provides PulseAudio loopback for passing my PS4 audio through my PC speakers.
+Docker is a way of creating virtualized containers for running software and services. The main difference between Docker and Vagrant is that Docker shares the base of the virtualization with all containers. So while Vagrant creates a standalone full-fledged VM, Docker instead creates a VM that uses a shared kernel between all VMs, and is based on LXC.
-I realize what some of you are probably thinking: “Can it do all of that?”. The answer (so far at least) is: Yes! I’m probably just as surprised as anyone else - I firmly expected to have to cut back on my list of uses for it. The only point where it fails currently is running GNOME3, as there are some Intel driver bugs for Skylake graphics (which required me to disable hardware acceleration). Knowing the Linux community though, the bugs will probably be fixed sooner rather than later.
+While it’s difficult to explain the difference between Vagrant and Docker in layman’s terms (as much of the differences are in the details), there are some simple things to note. For example, Docker is generally faster to start up, and less resource intensive (as it shares some of the host’s kernel).
-**
-**
+It does have to run on a Linux machine, but there are tools offered by Docker to easily set it up on Windows or Mac (using a base virtual machine to supply the linux kernel).**
-The Setup
-• 1 x Intel NUC6i5SYH
+Qu'est-ce que Docker ?
-• 2 x 16GB Kingston HyperX Impact DDR4 SO-DIMM C13 2133 K2
-• 1 x M.2 Samsung 850 EVO Basic 250GB SSD
-• Running ArchLinux (64 Bit).
-Peripherals:
+Docker est une façon de créer des conteneurs virtualisés pour faire tourner des logiciels et des services. La grande différence entre Docker et Vagrant est que Docker partage la base de la virtualisation avec tous les conteneurs. Ainsi, alors que Vagrant crée une véritable VM (machine virtuelle) indépendante, Docker crée à la place une VM qui utilise un noyau commun partagé par toutes les autres VM et basé sur LXC.
-• Anker 7-Port USB 3.0 HUB, connecting:
-• Keyboard & Mouse
-• MyBook 3TB
-• USB surround sound audio card
-I chose ArchLinux because I love the Arch User Repository, and it’s been my distribution of choice for many years. However, Ubuntu (or any other distribution) should offer much the same experience. Maybe with slightly fewer bugs (as Arch is a rolling release).
+Alors qu'il est difficile d'expliquer la différence entre Vagrant et Docker en termes simples (l'essentiel des différences réside dans les détails), on peut relever certaines choses. Par exemple, que Docker démarre généralement plus rapidement et consomme moins de ressources (puisqu'il partage le noyau de l'hôte).
-**
+Il doit fonctionner sur une machine Linux, mais Docker fournit des outils pour s'installer facilement sous Windows ou Mac (en utilisant une machine virtuelle de base qui fournit le noyau Linux).
-===== 2 =====
-**
-My Thoughts
-Overall, this device is pretty much what I expected. It’s quiet, quick, and graphically powerful enough to do everything I want (when the drivers work, at least). Not to mention small. Looking at the numbers doesn’t do it justice. It’s only about 2% wider/deeper than the coasters I keep on my desk, and the height (SYH model is 48mm, and SYK is 32mm) is really not that noticeable. Personally, if I was going to mount it to something thin using the vesa mount, I would take the SYK model. If you want to use the mount on something else (under a desk, on a wall, etc.) I think you’d be fine with either. That isn’t to say that I think the mount wouldn’t work with the taller model, I just find it may look odd, or make some smaller monitors too back-heavy.
+**Setup
-For anyone concerned about noise - during the UEFI screen, the fans spin at full blast. To me, it’s no louder than a loud 3.5” mechanical drive. The moment the OS starts, the fans spin down, and almost everything on my desk is louder than the NUC. My external drive is by far the loudest device on my desk now (but even that is easily overpowered by even just quiet music over my speakers).
+Docker containers can be assigned to various virtual networks, can expose ports, can run off specific images, and can share folders/files between the host and the guest. My current system is as follows:
+• Custom network (called “webnet”)
+• One Docker container running HAProxy, and exposing port 80. Also includes a static IP on webnet.
+• Multiple docker containers running the nickistre/ubuntu-lamp image, and sharing a host folder with the guest at /var/www/html (default Apache folder). Each has a static IP on the webnet network, but doesn’t expose any ports (as communication is funneled through HAProxy).
-Nice bonus: The NUC comes with a world plug, meaning it has connectors on the universal power supply that should work anywhere in the world.
+I have set up dnsmasq with a catch-all DNS entry for all subdomains of home.lan. These get forwarded to the local machine at port 80 (which is, in turn, passed to the docker HAProxy machine). HAProxy is then used to check which subdomain it is, and (if configured) points it to the correct docker container’s static IP.
-**
-**
+To illustrate (pelican is a static site generator): pelican.home.lan points to 192.168.1.16 (local machine) via dnsmasq. Once the request arrives, HAProxy checks the configuration file, and then passes the request through to 172.18.0.4:80 (the docker instance running my pelican site). If HAProxy doesn’t have an entry for the domain, it just ends at 172.18.0.2 (the HAProxy machine).**
-Enough of the good - most people are probably interested in what it’s lacking. I don’t feel like the port options on the NUC are bad - I do feel like without a hub of some sort, you may run into issues (or simply not have any plugs free for thumb drives). That being said, I always prefer having a hub that I can position closer to me for ease of use (and they aren’t terribly expensive). That being said, there is one port I would have liked to have on the NUC. A USB Type-C Thunderbolt connector. According to rumor, the Skull Canyon model (core i7 model) should have one. Whether this is the case or not, we will have to wait and see. However, with the advent of type-c monitors with USB hubs and integrated power passthrough, it does seem like an odd omission to make. Especially for a device you could technically mount on the back of a monitor, and with type-c, you could reduce the cable clutter immensely.
-I’m sure some people would have preferred to see something besides a mini-displayport plug next to the HDMI. However, as someone who has owned and used a MacBook, I’ve grown accustomed to those adapters (not to mention having plenty lying around).
+Installation
-Lastly, design: I would have preferred the A/C adapter plug to be on the bottom edge of the device, instead of the top. However, based on the layout of the internals (and the mounting capabilities), I’m not sure this would have been possible.
+Docker peut être affecté à différents réseaux virtuels, « exposer » des ports, faire tourner des images spécifiques, et partager des fichiers ou dossiers avec l'hôte et les invités. Ma configuration actuelle est :
-**
+• Un réseau privé (appelé « webnet »).
+• Un conteneur Docker utilisant HAProxy et « exposant » le port 80. Il inclut également une IP statique sur webnet.
+• De nombreux conteneurs Docker utilisant l'image nickistre/Ubuntu-lamp et partageant avec les invités un dossier hôte à /var/www/html (le dossier d'Apache par défaut). Chacun d'eux dispose d'une IP statique sur le réseau webnet, mais n'expose aucun port (puisque les communications passent par HAProxy).
+J'ai installé un dnsmasq avec une entrée DNS attrape-tout pour tous les sous-domaines de home.lan. Ils sont ensuite redirigés vers la machine locale au port 80 (qui à son tour le passe au HAProxy de la machine Docker). HAProxy vérifie alors de quel domaine il s'agit et, s'il est configuré, le renvoie vers l'IP statique du conteneur Docker correspondant.
-**
+Pour illustrer (pelican est un générateur de sites statiques) : pelican.home.lan pointe vers 192.168.1.16 (machine locale) au travers de dnmasq. Une fois que la requête arrive, HAProxy vérifie le fichier de configuration et envoie la requête à 172.18.0.4:80 (l'instance de Docker dans laquelle tourne le site pelican). Si HAProxy ne connaît pas le domaine, il s'arrête simplement à 172.18.0.2 (la machine du HAProxy).
-The last negative thing I have to say about this setup isn’t really a knock at the device itself. Driver support. I realize that the Skylake processors are new, and as such, you can’t expect everything to run perfectly. That being said, having hardware acceleration enabled in the drivers currently causes my 4.4.1-2 kernel to crash. Not X, but the kernel itself. I’ve tried the 3 different acceleration methods (sna, uxa, and glamor), as well as disabling DRI (3d acceleration). I even tried to just enable DRI2. Nothing has completely solved the problem. Disabling 3d acceleration helped delay the crash, but it still occurred. Same with all the typical kernel boot options (intel_iommu=igfx_off, etc). Disabling all acceleration (recommended in the ArchLinux Wiki) has resulted in a usable system - but did require me to switch to AwesomeWM, as GNOME3 was slow (thanks to the integrated effects). Not a big deal for me (as I like AwesomeWM as well), but still slightly frustrating. This is especially so, because I hadn’t had any issues using the previous kernel 4.3.3-3. While I could theoretically roll back to the last kernel, there were plenty of other updates, and it would become a dependency nightmare. For a possible fix, read on.
-Prior to publishing, I was able to find a fix that appears to work. Adding the kernel boot parameter i915.enable_rc6=0 seems to have solved the stability issues. It does disable powersaving in the i915 drivers, ensuring that the CPU is always running in high performance mode. However, I imagine this step will be necessary only temporarily, until the drivers handle the power states better. I’m leaving the original paragraph in place, for anyone who may be facing similar issues.
+**What first?
-**
-===== 3 =====
+First, you’ll need to create the network you want to use.
-**
-Summary:
-Pro
+docker network create --subnet=172.18.0.0/16 webnet
-Quiet
-Powerful/Fast
-Light and small
-World power supply
-Con
+This creates a new network called webnet, with a possible IP range of 172.18.0.0 to 172.168.255.254. I won’t go into the specifics of the format used here. If you want to use a different IP range, just adjust the 172.18 part - it’s unlikely you’ll ever need more than 65534 possible addresses for Docker containers. I chose 172.18 because the default docker IP range (which is dynamically allocated in the default network) is 172.17. That way, I should be able to always tell that the IP corresponds to docker. Do not choose the same IP range as your actual local network (typically 192.168).
-No USB Type-C
-Positioning of A/C port
-Mini-Displayport (con for some)
-Overall, I’m extremely happy with the NUC. The driver issues are unfortunate, but don’t really impact my main use-cases (as I could just as easily run it as a headless server). Basically, my list of Pros, while quantity-wise are equal with the cons, I give much more weight and importance to the pro list. The port gripes on the Con list are really not that big of a deal to me, and the drivers should improve as time goes on. Not to mention the fact that it had actually been working better previously.
+The reason why we need the custom network, is simply because the default networks from docker don’t allow assigning static IPs.**
-**
-**
+Par où commencer ?
-Cost
-I did not mention cost in this review at all. This is largely for two reasons:
+Il faut d'abord créer le réseau que l'on souhaite utiliser.
-• Availability - the devices and hardware are pretty new, and as such, you may be limited in where to find it. This can impact the cost/ability to find bargains.
-• I chose the best performance/quality hardware I could find for a reasonable price (as I had a lot I wanted to do with it). Bargain hunters could easily find cheaper combinations. I.e. using DDR3L memory instead of DDR4.
-Bottom Line
+docker network create --subnet=172.18.0.0/16 webnet
-Yes, I would recommend it. Caveat: However, only to those who have done their research. Be it into the best distribution for Skylake, or the best model for your purposes (and which hardware to choose). This is not the perfect device for everyone, but if you have a perfect use for it, the NUC is an excellent choice.
+Cela crée un nouveau réseau appelé webnet avec des adresses IP allant de 172.18.0.0 jusqu'à 172.168.255.254. Je ne vais pas entrer dans les particularités du format utilisé ici. Si vous voulez utiliser une plage différente d'IP, modifiez simplement la partie 172.18 – il est peu probable que vous ayez jamais besoin de plus de 65 534 adresses possibles pour des conteneurs Docker. J'ai choisi 172.18 parce que la plage par défaut des IP docker (qui est allouée dynamiquement dans le réseau par défaut) est 172.17. Ainsi, je serai toujours capable de dire que l'IP correspond à Docker. Ne choisissez pas la même plage d'IP que votre réseau réel (typiquement 192.168).
+La raison pour laquelle nous avons besoin d'un réseau particulier vient simplement du fait que le réseau par défaut de Docker ne permet pas  d'affecter des IP statiques.
+**How do I go about creating my machines?
+The standard docker command will pretty much always be the same.
+docker run -d -v {SHARE} --net webnet --ip 172.18.0.X --name {NAME} {IMAGE}
+What it does:
+• ‘docker run’ fires up a container.
+• -d detaches the created container (otherwise all output from the container is automatically printed to the terminal, and closing the terminal will close the docker instance).
+• -v {SHARE} - specifies the shared folder, in the format /local/path:/remote/path. For example: -v /home/lswest/web/pelican:/var/www/html
+• --net webnet - configures which network the container should use.
+• --ip 172.18.0.X - this is the static IP I’m assigning. I like to keep them in a basic order, in order to make adding HAProxy entries easier. If you chose a different IP range in the step above, adjust accordingly.
+• --name {name} - this is the name the docker instance will be known as. For example --name pelican. This can be used in the docker start/stop/restart/rm commands, and appears in the listing of docker ps.
+• {IMAGE} - this is the image to use for the base of the container. I like the nickistre/ubuntu-lamp image, which contains Ubuntu 14.04 and LAMP. There are other images (such as ArchLinux), but since my Digital Ocean servers typically run on Ubuntu, I stuck as close as possible to the real-world environment. The HAProxy image I use is HAProxy:1.5 (official HAProxy image, version 1.5).**
+Comment s'y prendre pour créer mes machines ?
+La commande standard de Docker sera toujours à peu près la même.
+docker run -d -v {SHARE} --net webnet --ip 172.18.0.X --name {NAME} {IMAGE}
+Ce qu'elle fait :
+• « docker run » crée un conteneur.
+• -d détache le conteneur créé (sinon toutes les sorties du conteneur seront automatiquement envoyées vers le terminal et la fermeture du terminal fermera l'instance de docker).
+• -v{SHARE} donne l'adresse du dossier partagé sous la forme /local/path:/remote/path. Par exemple : -v /home/lswest/web/pelican:/var/www/html.
+• --net webnet configure le réseau que doit utiliser le conteneur.
+• --ip 172.18.0.X il s'agit de l'IP statique que je donne. J'aime les avoir bien organisés de façon à rendre plus facile l'ajout d'entrées au HAProxy. Si vous choisissez une plage différente dans cette étape, adaptez en conséquence.
+• --name{name} c'est le nom sous lequel l'instance du docker sera reconnue. Par exemple -–namepelican. On peut l'utiliser dans les commandes start/stop/restart/rm et il apparaît dans la liste de docker ps.
+• {IMAGE} il s'agit de l'image à utiliser comme base du conteneur. J'aime l'image nickistre/Ubuntu-lamp qui contient Ubuntu 14.04 et LAMP. Il existe d'autres images (telles que ArchLinux) mais, puisque mes serveurs Digital Ocean tournent habituellement sous Ubuntu, j'essaie de rester aussi proche que possible de l'environnement réel. L'image du HAProxy que j'utilise est HAProxy:1.5 (l'image officielle de HAProxy, version 1.5)
+**In the case of the HAProxy image (which should be created first), the command will look like this:
+docker run -d -v ~/docker-config/haproxy/haproxy:/usr/local/etc/haproxy/haproxy.cfg:ro --net webnet --ip 172.18.0.2 -p 80:80 --name proxy haproxy:1.5
+Main differences:
+• -p 80:80 - exposes the guest port 80 to the host port 80 (so visiting 172.18.0.2 in a web browser should spit out the typical 503 error from HAProxy).
+• -v - in the command above, I just like the actual HAProxy.cfg file into the location for the config for HAProxy. NOTE: editing this file with some text editors (such as vim) will result in HAProxy not accepting the changes. This is due to the inode changing. To fix, just restart the machine with ‘docker restart proxy’. Nano appears to avoid this problem.**
+Dans le cas de l'image du HAProxy (qui devrait être créée en premier), la commande ressemblera à cela :
+config/haproxy/haproxy:/usr/local/etc/haproxy/haproxy.cfg:ro --net webnet –ip 172.18.0.2 -p 80:80  --name proxy haproxy:1.5
+Différences principales :
+• -p 80:80 expose le port invité 80 au port hôte 80 (donc en allant à l'adresse 172.18.0.2 à l'aide d'un navigateur, HAProxy devrait renvoyer une erreur 503)
+• -v dans la commande ci-dessus, j'aime bien avoir le fichier de configuration HAProxy original à l'endroit prévu pour la configuration du HAProxy. NOTE : si vous éditez ce fichier avec un éditeur de texte quelconque (tel que vim), HAProxy n'acceptera pas les changements. C'est dû à un changement d'inode [Ndt : fichier d'index]. Pour corriger, redémarrer simplement la machine avec « docker restart proxy ». Il semblerait que l'usage de Nano évite ce problème.
+**Autostarting
+If you want the docker containers to always run (after crashing, reboots, or restarts), you can add --restart=always to the run command. This must be done when creating the container - so if you’ve already created one, you’ll need to stop it, remove it (rm), and then recreate it.
+Does this work for only port 80?
+The settings for the HAProxy container should never need to change (during docker run). However, if you want to point a domain to, for example, a NodeJS application running on 8000, just adjust the IP in the HAProxy configuration (see below). For example, 172.18.0.6:8000.**
+Démarrage automatique
+Si vous voulez que les conteneurs Docker soient toujours en fonction (après un crash, un redémarrage du système ou de session), vous pouvez ajouter –restart=always à la commande run. Ceci doit être fait à la création du conteneur. Donc, si vous en avez déjà créé un, vous devez l'arrêter, l'effacer (rm) et le recréer.
+Cela ne fonctionne-t-il que pour le port 80 ?
+Les réglages du HAProxy ne devraient jamais changer (pendant le fonctionnement de Docker). Toutefois, si vous voulez pointer un domaine particulier, par exemple, une application NodeJS tournant sur le 8000, réglez simplement l'adresse IP dans la configuration du HAProxy (voir ci-dessous). Par exemple, 172.18.0.6:8000.
+**HAProxy Config
+I’ve saved an example of my configuration here: http://pastebin.com/1M5DMkF3
+Basically, adding new containers is as simple as copying the acl line (#33), the use_backend line (#36), and the backend block (#39-43). Be sure to keep increasing the index numbers (host_test1 would become host_test2, etc.). And give each backend a unique name (and adjust the IP!).**
+Configuration du HAProxy
+J'ai sauvegardé un exemple de ma configuration ici : http://pastebin.com/1M5DMkF3
+Pratiquement, pour ajouter de nouveaux conteneurs on n'a qu'à copier la ligne acl (#33), la ligne use_backend (#36) et le bloc backend (#39-43). Assurez-vous de l'incrémentation des numéros d'étiquettes (host-test1 devient host-test2, etc.). Et donnez à chaque backend un nom unique (et réglez bien l'IP !).
+**How do I make a wildcard dnsmasq entry?
+You can add a single line to your dnsmasq.conf file (typically found at /etc/dnsmasq.conf). It looks like this:
+address=/home.lan/192.168.1.16
+Replace the IP with your own, and the home.lan portion with the domain you’d like (minus any subdomains - so instead of www.google.com, it would be google.com). Note, also, that using a real domain here isn’t a good idea, as any requests will be directed to your local machine. So if using google, you’ll never reach the Google homepage again. Hence why I use home.lan.**
+Comment faire une entrée générique pour DNSMASQ ?
+Vous pouvez ajouter une simple ligne à votre fichier dnsmasq.conf (que vous trouverez normalement à /etc/dnmasq.conf). Ça ressemble à ça :
+address=/home.lan/192.168.1.16
+Remplacez l'IP par la vôtre et la partie home.lan avec le domaine de votre choix (sans les sous-domaines, ainsi, à la place de www.google.com, il faudra mettre google.com). Notez également qu'il est préférable de ne pas utiliser ici un nom de domaine existant car toute requête sera redirigée vers votre machine locale. Ainsi, si vous utilisez google, il ne vous sera plus possible d'atteindre la page d'accueil de Google. C'est pour cela que j'utilise home.lan.
+**I hope this article was helpful to anyone wondering about Docker, who has been looking for a better way to host local projects while in development. If you have any questions, or want to share a docker trick of your own, feel free to email me at lswest34+fcm@gmail.com.**
+J'espère que cet article sera utile à ceux qui veulent en savoir un peu plus sur Docker ou ceux qui cherchent une meilleure façon d'héberger des projets locaux en phase de développement. Pour quelque question que ce soit, ou si vous voulez partager vos propres astuces de Docker, n'hésitez pas à m'envoyer un courriel à : lswest34+fcm@gmail.com.
+**Further Reading
+https://en.wikipedia.org/wiki/LXC
+LXC
+https://www.quora.com/What-is-the-difference-between-Docker-and-Vagrant-When-should-you-use-each-one
+Docker VS Vagrant
+https://www.docker.com/enterprise
+Docker**
+Pour aller plus loin
+https://en.wikipedia.org/wiki/LXC
+LXC
+https://www.quora.com/What-is-the-difference-between-Docker-and-Vagrant-When-should-you-use-each-one
+Comparaison entre Docker et Vagrant
+https://www.docker.com/enterprise
+Docker
-I hope this review/article has been useful to some. If there’s anyone out there who feels overwhelmed by choices and what hardware to select for their NUC - don’t worry. I imagine as time goes on, manufacturers will start marking their hardware as “works with NUC”, or retailers will simply start recommending the correct hardware. Barring that, download the product brief from Intel for your model, and compare the specs (especially voltages) on the device. If you have questions or comments (or a fix for the intel drivers!), let me know at lswest34+fcm@gmail.com.
-**