Use page bundles for multilingual articles
All checks were successful
continuous-integration/drone/push Build is passing
Before Width: | Height: | Size: 220 KiB After Width: | Height: | Size: 220 KiB |
@ -28,7 +28,7 @@ In fact, for many years, one could almost think that for an advertising company,
|
||||
But one day, an advertising engineer had an idea: if we could know what kind of person is searching, we would be able to send them directly to the most appropriate site.
|
||||
A few developments later, here is what the biggest data vacuum cleaner you can imagine was:
|
||||
|
||||
![The GMail interface](/post/self-hosting/gmail.png)
|
||||
![The GMail interface](gmail.png)
|
||||
|
||||
Contacts, message contents, order forms, newsletters, ... This is how to subtly direct someone to one site rather than another.
|
||||
This is very good when we are in a hurry, but instead of opening us up to the world in general, it locks us into an information bubble.
|
@ -24,7 +24,7 @@ This is possible because the router regularly transmits information about the su
|
||||
|
||||
For our experiment, let's take the following lab:
|
||||
|
||||
![The basic infrastructure that we will use for our experiments](/post/use-additional-ipv6-blocks-from-isp/lab.png)
|
||||
![The basic infrastructure that we will use for our experiments](lab.png)
|
||||
|
||||
We have all our equipment connected to the box and a series of virtual machines hosted on one of the network machines.
|
||||
|
||||
@ -42,7 +42,7 @@ The main interest of this segmentation would be to avoid that all this little wo
|
||||
|
||||
We could therefore want to segment our network like this:
|
||||
|
||||
![Example of segmentation by splitting the /64 block into two /65 blocks](/post/use-additional-ipv6-blocks-from-isp/lab-segmente.png)
|
||||
![Example of segmentation by splitting the /64 block into two /65 blocks](lab-segmente.png)
|
||||
|
||||
We would reserve half of the /64 block for real network equipment and allocate the other half to our virtual machines located on a server/Raspberry Pi.
|
||||
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
Before Width: | Height: | Size: 90 KiB After Width: | Height: | Size: 90 KiB |
Before Width: | Height: | Size: 86 KiB After Width: | Height: | Size: 86 KiB |
@ -15,7 +15,7 @@ In fact, for the same reason we saw in [the introductory article]({{< relref "us
|
||||
|
||||
The same phenomenon can be observed with IPv4: each container has an IPv4 in a subnet separate from the one in which our host machine is located.
|
||||
|
||||
![Illustration of a classic IPv4 home network](/post/use-ipv6-in-docker/common-network-with-docker.png)
|
||||
![Illustration of a classic IPv4 home network](common-network-with-docker.png)
|
||||
|
||||
In order for the containers to have access to the Internet under these conditions, in IPv4 NAT is implemented:
|
||||
|
||||
@ -72,7 +72,7 @@ On the Freebox, the window for setting additional prefixes is in "Paramètres de
|
||||
|
||||
It looks like this:
|
||||
|
||||
![Freebox IPv6 prefix delegation settings window](/post/use-ipv6-in-docker/freebox-ipv6-refix-delegation.png)
|
||||
![Freebox IPv6 prefix delegation settings window](freebox-ipv6-refix-delegation.png)
|
||||
|
||||
Always leave the first field empty, otherwise the box will not offer you IPv6 on the main network.
|
||||
|
||||
@ -85,7 +85,7 @@ That's all! The hardest part is over. Now let's see the Docker configuration.
|
||||
|
||||
We will not use the range to which our machine is connected. We are going to use a whole /64 range, the one for which we have given the local IP of our machine to the box.
|
||||
|
||||
![Our prefix delegation correctly set up on the Freebox](/post/use-ipv6-in-docker/freebox-ipv6-delegation-filled.png)
|
||||
![Our prefix delegation correctly set up on the Freebox](freebox-ipv6-delegation-filled.png)
|
||||
|
||||
According to the previous screenshot, our configuration file `/etc/docker/daemon.json` should look like:
|
||||
|
@ -28,7 +28,7 @@ D'ailleurs, pendant de longues années, on aurait presque pu penser que pour une
|
||||
Mais un jour, un ingénieur publicitaire a eu une idée : si on pouvait savoir quel genre d'individu fait une recherche, on serait capable de l'envoyer directement vers le site le plus approprié.
|
||||
Quelques développements plus tard, voici ce que fût le plus grand aspirateur de données que l'on puisse imaginer :
|
||||
|
||||
![L'interface de GMail](/post/self-hosting/gmail.png)
|
||||
![L'interface de GMail](gmail.png)
|
||||
|
||||
Contacts, contenus des messages, bons de commandes, newsletters, ... Voilà comment orienter subtilement quelqu'un vers un site plutôt qu'un autre.
|
||||
C'est très bien lorsqu'on est pressé, mais au lieu de nous ouvrir sur le monde en général, cela nous enferme au contraire dans une bulle informative.
|
@ -24,7 +24,7 @@ Cela est possible car le routeur émet régulièrement les informations du sous-
|
||||
|
||||
Pour notre expérience, prenons le lab suivant :
|
||||
|
||||
![L´infrastructure de base qui va nous servir à faire nos expérimentations](/post/use-additional-ipv6-blocks-from-isp/lab.png)
|
||||
![L´infrastructure de base qui va nous servir à faire nos expérimentations](lab.png)
|
||||
|
||||
Nous avons tous nos équipements reliés à la box et une série de machines virtuelles hébergées sur l'une des machines du réseau.
|
||||
|
||||
@ -42,7 +42,7 @@ L'intérêt principal de cette segmentation serait d'éviter que tout ce petit m
|
||||
|
||||
On pourrait donc vouloir segmenter son réseau comme cela :
|
||||
|
||||
![Exemple de segmentation par le partage du bloc /64 en deux blocs /65](/post/use-additional-ipv6-blocks-from-isp/lab-segmente.png)
|
||||
![Exemple de segmentation par le partage du bloc /64 en deux blocs /65](lab-segmente.png)
|
||||
|
||||
On réserverait la moitié du bloc /64 aux équipements réels du réseau et on attribuerait l'autre moitié à nos machines virtuelles situées sur un serveur/Raspberry Pi.
|
||||
|
@ -15,7 +15,7 @@ En fait, pour la même raison que nous avons vu dans [l'article introductif]({{<
|
||||
|
||||
On observe d'ailleurs le même phénomène avec l'IPv4 : chaque conteneur dispose d'une IPv4 dans un sous-réseau distinct de celui dans lequel se trouve notre machine hôte.
|
||||
|
||||
![Illustration d´un réseau domestique IPv4 classique](/post/use-ipv6-in-docker/common-network-with-docker.png)
|
||||
![Illustration d´un réseau domestique IPv4 classique](common-network-with-docker.png)
|
||||
|
||||
Pour que les conteneurs aient accès à Internet dans ces conditions, en IPv4 du NAT est mis en œuvre :
|
||||
|
||||
@ -72,7 +72,7 @@ Sur les Freebox, la fenêtre de paramétrage des préfixes supplémentaires se t
|
||||
|
||||
Cela ressemble à ça :
|
||||
|
||||
![Fenêtre de paramétrage de la délégation de préfixe IPv6 de la Freebox](/post/use-ipv6-in-docker/freebox-ipv6-prefix-delegation.png)
|
||||
![Fenêtre de paramétrage de la délégation de préfixe IPv6 de la Freebox](freebox-ipv6-prefix-delegation.png)
|
||||
|
||||
Laissez toujours le 1ᵉʳ champ vide, sans quoi la box ne vous proposera plus d'IPv6 sur le réseau principal.
|
||||
|
||||
@ -85,7 +85,7 @@ C'est tout ! Le plus dur est passé. Voyons maintenant la configuration de Docke
|
||||
|
||||
Nous n'allons pas utiliser la plage à laquelle notre machine est connectée. Nous allons utiliser toute une plage /64, celle pour laquelle on a donné l'IP locale de notre machine à la box.
|
||||
|
||||
![Notre délégation de préfixe correctement paramétrée sur la Freebox](/post/use-ipv6-in-docker/freebox-ipv6-delegation-filled.png)
|
||||
![Notre délégation de préfixe correctement paramétrée sur la Freebox](freebox-ipv6-delegation-filled.png)
|
||||
|
||||
Selon la capture d'écran précédente, notre fichier de configuration `/etc/docker/daemon.json` devrait ressembler à :
|
||||
|