tuto1: orthograf
This commit is contained in:
parent
d8d9365a4b
commit
dfbca22549
@ -16,7 +16,7 @@ monitoring, d'un simple :
|
||||
</div>
|
||||
|
||||
Vous intégrerez les trois images (`influxdb`, `chronograf` et `telegraf`),
|
||||
mettrez en place les *volumes* et *networks* nécessaire au bon fonctionnement
|
||||
mettrez en place les *volumes* et *networks* nécessaires au bon fonctionnement
|
||||
de la stack.
|
||||
|
||||
Le résultat final attendu doit permettre d'afficher dans `chronograf` l'hôte
|
||||
@ -41,8 +41,11 @@ et exclusivement à celle-ci que vous devez envoyer vos rendus. Tout rendu
|
||||
envoyé à une autre adresse et/ou non signé et/ou reçu après la correction ne
|
||||
sera pas pris en compte.
|
||||
|
||||
En cas de doute, [une interface](https://virli.nemunai.re/rendus/) et une API
|
||||
sont disponibles pour consulter l'état de votre rendu.
|
||||
|
||||
Par ailleurs, n'oubliez pas de répondre à
|
||||
[l'évaluation du cours](https://virli.nemunai.re/quiz/3).
|
||||
[l'évaluation du cours](https://virli.nemunai.re/quiz/11).
|
||||
|
||||
|
||||
Tarball
|
||||
@ -84,7 +87,7 @@ distinct.
|
||||
Une version récente de [Thunderbird](https://www.thunderbird.net/fr/) vous
|
||||
permettra d'envoyer des courriels signés. Si vous n'avez qu'une version
|
||||
ancienne, l'extension [Enigmail](https://enigmail.net) est très bien réputée
|
||||
pour signer ses mails depuis Thunderbird. Bien entendu de nombreuses autres
|
||||
pour signer ses mails depuis Thunderbird. Bien entendu, de nombreuses autres
|
||||
solutions sont disponibles.
|
||||
|
||||
Utilisez le service automatique <signcheck@nemunai.re> pour savoir si votre
|
||||
|
@ -20,5 +20,5 @@ abstract: |
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||
votre clef et n'hésitez pas à [faire signer la
|
||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
@ -21,5 +21,5 @@ abstract: |
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||
votre clef et n'hésitez pas à [faire signer la
|
||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
@ -20,5 +20,5 @@ abstract: |
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||
votre clef et n'hésitez pas à [faire signer la
|
||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
@ -19,5 +19,5 @@ abstract: |
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||
votre clef et n'hésitez pas à [faire signer la
|
||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
@ -20,5 +20,5 @@ abstract: |
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||
votre clef et n'hésitez pas à [faire signer la
|
||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
@ -44,9 +44,9 @@ fonctionnalités de Docker.
|
||||
Cette section énumère la liste des services (ou conteneurs) qui seront gérés
|
||||
par `docker-compose`.
|
||||
|
||||
Il peuvent dépendre d'une image à construire localement, dans ce cas ils auront
|
||||
un fils `build`. Ou ils peuvent utiliser une image déjà existante, dans ce cas
|
||||
ils auront un fils `image`.
|
||||
Ils peuvent dépendre d'une image à construire localement, dans ce cas ils
|
||||
auront un fils `build`. Ou ils peuvent utiliser une image déjà existante, dans
|
||||
ce cas ils auront un fils `image`.
|
||||
|
||||
Les autres fils sont les paramètres classiques que l'on va passer à `docker
|
||||
run`.
|
||||
@ -86,8 +86,8 @@ l'emplacement à partager :
|
||||
Cette section est le pendant de la commandes `docker network`.
|
||||
|
||||
Par défaut, Docker relie tous les conteneurs sur un bridge et fait du NAT pour
|
||||
que les conteneur puisse accéder à l'Internet. Mais ce n'est pas le seul mode
|
||||
possible !
|
||||
que les conteneurs puissent accéder à l'Internet. Mais ce n'est pas le seul
|
||||
mode possible !
|
||||
|
||||
De la même manière que pour les `volumes`, cette section déclare les réseaux
|
||||
qui pourront être utilisés par les `services`. On pourrait donc avoir :
|
||||
@ -105,7 +105,7 @@ networks:
|
||||
|
||||
Le driver `host` réutilise la pile réseau de la machine hôte. Le conteneur
|
||||
pourra donc directement accéder au réseau, sans NAT et sans redirection de
|
||||
port. Les ports alloués par le conteneur ne devront pas entrer en conflits avec
|
||||
port. Les ports alloués par le conteneur ne devront pas entrer en conflit avec
|
||||
les ports ouverts par la machine hôte.
|
||||
|
||||
|
||||
@ -122,7 +122,7 @@ un backup de base de données.
|
||||
|
||||
#### Driver `bridge`
|
||||
|
||||
Le driver `bridge` crée un nouveau bridge qui sera partagée entre tous les
|
||||
Le driver `bridge` crée un nouveau bridge qui sera partagé entre tous les
|
||||
conteneurs qui la référencent.
|
||||
|
||||
Avec cette configuration, les conteneurs ont accès à une résolution DNS des
|
||||
|
@ -9,29 +9,29 @@ conteneurs manuellement, de la même manière que nous avons pu le faire avec
|
||||
l'interface d'administration du FIC et MySQL.
|
||||
|
||||
|
||||
## Conteneur central : la base de données
|
||||
## Conteneur central : la base de données
|
||||
|
||||
Le premier conteneur qui doit être lancé est la base de données orientée séries
|
||||
temporelles :
|
||||
temporelles :
|
||||
[InfluxDB](https://www.influxdata.com/time-series-platform/influxdb/).
|
||||
En effet, tous les autres conteneurs ont besoin de cette base de données pour
|
||||
fonctionner correctement\ : il serait impossible à *Chronograf* d'afficher les
|
||||
fonctionner correctement\ : il serait impossible à *Chronograf* d'afficher les
|
||||
données sans base de données, tout comme *Telegraf* ne pourrait écrire les
|
||||
métriques dans une base de données à l'arrêt.
|
||||
|
||||
Afin d'interagir avec les données, InfluxDB expose une
|
||||
[API REST](https://fr.wikipedia.org/wiki/Representational_state_transfer)
|
||||
sur le port 8086. Pour éviter d'avoir plus de configuration à réaliser, nous
|
||||
allons tâcher d'utiliser ce même port pour tester localement :
|
||||
allons tâcher d'utiliser ce même port pour tester localement :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container run -p 8086:8086 -d --name mytsdb influxdb
|
||||
docker container run -p 8086:8086 -d --name mytsdb influxdb:1.8
|
||||
```
|
||||
</div>
|
||||
|
||||
Comme il s'agit d'une API REST, nous pouvons vérifier le bon fonctionnement de
|
||||
notre base de données en appelant :
|
||||
notre base de données en appelant :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
@ -41,8 +41,18 @@ notre base de données en appelant :
|
||||
```
|
||||
</div>
|
||||
|
||||
Notez que comme nous avons lancé le conteneur en mode détaché (option `-d`),
|
||||
nous ne voyons pas les logs qui sont écrits par le daemon. Pour les voir, il
|
||||
faut utiliser la commande `docker container logs` :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container logs mytsdb
|
||||
```
|
||||
</div>
|
||||
|
||||
Si votre influxdb répond, vous pouvez vous y connecter en utilisant directement
|
||||
le client fourni :
|
||||
le client officiel (le binaire s'appelle `influx`) :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
@ -60,27 +70,63 @@ _internal
|
||||
Si vous aussi vous voyez la table `_internal`, bravo ! vous pouvez passer à la
|
||||
suite.
|
||||
|
||||
Notez que comme nous avons lancé le conteneur en mode détaché (option `-d`),
|
||||
nous ne voyons pas les logs qui sont écrits par le daemon. Pour les voir, il
|
||||
faut utiliser la commande `docker container logs` :
|
||||
#### Mais quelle était cette commande magique ? {-}
|
||||
|
||||
Oui, prenons quelques minutes pour l'analyser ...
|
||||
|
||||
L'option `--link` permet de lier deux conteneurs. Ici nous souhaitons lancer un
|
||||
nouveau conteneur pour notre client, en ayant un accès réseau au conteneur
|
||||
`mytsdb` que nous avons créé juste avant. L'option `--link` prend en argument
|
||||
le nom d'un conteneur en cours d'exécution (ici `mytsdb`, nom que l'on a
|
||||
attribué à notre conteneur exécutant la base de données influxdb via l'option
|
||||
`--name`), après les `:`, on précise le nom d'hôte que l'on souhaite attribuer
|
||||
à cette liaison, au sein de notre nouveau conteneur.
|
||||
|
||||
`influx -host influxdb` que nous avons placé après le nom de l'image,
|
||||
correspond à la première commande que l'on va exécuter dans notre conteneur, à
|
||||
la place du daemon `influxdb`. Ici nous voulons exécuter le client, il
|
||||
s'appelle `influx`, auquel nous ajoutons le nom de l'hôte dans lequel nous
|
||||
souhaitons nous connecter : grâce à l'option `--link`, le nom d'hôte à utiliser
|
||||
est `influxdb`.
|
||||
|
||||
L'option `--link` peut être particulièrement intéressante lorsque l'on souhaite
|
||||
sauvegarder une base, car en plus de définir un nom d'hôte, cette option fait
|
||||
hériter le nouveau conteneur des variables d'environnement du conteneur
|
||||
auquel elle est liée : on a donc accès aux `$MYSQL_USER`,
|
||||
`$MYSQL_PASSWORD`, ...
|
||||
|
||||
On aurait aussi pu créer un réseau entre nos deux conteneurs (via `docker
|
||||
network`), ou bien encore, on aurait pu exécuter notre client `influx`
|
||||
directement dans le conteneur de sa base de données :
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
docker container logs mytsdb
|
||||
42sh$ docker container exec mytsdb influx -execute "show databases"
|
||||
name: databases
|
||||
name
|
||||
---------------
|
||||
_internal
|
||||
```
|
||||
</div>
|
||||
|
||||
Dans ce dernier exemple, nous n'avons pas besoin de préciser l'hôte, car
|
||||
`influx` va tenter `localhost` par défaut, et puisque nous lançons la commande
|
||||
dans notre conteneur `mytsdb`, il s'agit bien du conteneur où s'exécute
|
||||
localement `influxdb`.
|
||||
|
||||
\hspace{2em}**Exercice :** Ajoutez à la ligne de commande de lancement du
|
||||
conteneur les bon(s) volume(s) qui permettront de ne pas perdre les données
|
||||
d'influxDB si nous devions redémarrer le conteneur. Aidez-vous pour cela de la
|
||||
[documentation du conteneur](https://hub.docker.com/_/influxdb).
|
||||
|
||||
#### Exercice : {-}
|
||||
|
||||
Ajoutez à la ligne de commande de lancement du conteneur les bon(s) volume(s)
|
||||
qui permettront de ne pas perdre les données d'influxDB si nous devions
|
||||
redémarrer le conteneur. Aidez-vous pour cela de la [documentation du
|
||||
conteneur](https://hub.docker.com/_/influxdb).
|
||||
|
||||
|
||||
## Collecter les données locales
|
||||
|
||||
Tentons maintenant de remplir notre base de données avec les métriques du
|
||||
système. Pour cela, on commence par télécharger *Telegraf* :
|
||||
système. Pour cela, on commence par télécharger *Telegraf* :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
@ -89,7 +135,7 @@ tar xzv -C /tmp
|
||||
```
|
||||
</div>
|
||||
|
||||
Puis, lançons *Telegraf* :
|
||||
Puis, lançons *Telegraf* :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
@ -98,17 +144,18 @@ cd /tmp/telegraf
|
||||
```
|
||||
</div>
|
||||
|
||||
**Remarque :** La configuration par défaut va collecter les données de la
|
||||
machine locale et les envoyer sur le serveur situé à
|
||||
<http://localhost:8086>. Ici, cela fonctionne parce que l'on a fait en sorte de
|
||||
rediriger le port de notre conteneur sur notre machine locale (option `-p`).
|
||||
#### Remarque : {-}
|
||||
|
||||
Et observons ensuite :
|
||||
La configuration par défaut va collecter les données de la machine locale et
|
||||
les envoyer sur le serveur situé à <http://localhost:8086>. Ici, cela
|
||||
fonctionne parce que l'on a fait en sorte de rediriger le port de notre
|
||||
conteneur sur notre machine locale (option `-p`).
|
||||
|
||||
Et observons ensuite :
|
||||
|
||||
<div lang="en-US">
|
||||
```bash
|
||||
42sh$ docker container run --rm -it --link mytsdb:influxdb --entrypoint "/usr/bin/influx" \
|
||||
influxdb -host influxdb
|
||||
42sh$ docker container run --rm -it --link mytsdb:zelda influxdb:1.8 influx -host zelda
|
||||
InfluxDB shell version: 1.8.9
|
||||
> show databases
|
||||
name: databases
|
||||
@ -135,13 +182,15 @@ system
|
||||
```
|
||||
</div>
|
||||
|
||||
La nouvelle base a donc bien été créé et tant que nous laissons *Telegraf*
|
||||
La nouvelle base a donc bien été créée et tant que nous laissons *Telegraf*
|
||||
lancé, celui-ci va régulièrement envoyer des métriques de cette machine.
|
||||
|
||||
|
||||
## Afficher les données collectées
|
||||
|
||||
**Exercice :** À vous de jouer pour lancer le conteneur
|
||||
#### Exercice : {-}
|
||||
|
||||
À vous de jouer pour lancer le conteneur
|
||||
[*Chronograf*](https://store.docker.com/images/chronograf).
|
||||
|
||||
L'interface de *Chronograf* est disponible sur le port 8888.
|
||||
@ -149,9 +198,11 @@ L'interface de *Chronograf* est disponible sur le port 8888.
|
||||
Consultez la [documentation du conteneur](https://hub.docker.com/_/chronograf)
|
||||
si besoin.
|
||||
|
||||
**Attention :** la page d'accueil est vide au démarrage, pour savoir si vous avez
|
||||
réussi, rendez-vous sous l'onglet *Hosts*, le nom de votre machine devrait y
|
||||
apparaître. En cliquant dessus vous obtiendrez des graphiques similaires à ceux
|
||||
ci-dessous :
|
||||
#### Attention : {-}
|
||||
|
||||
la page d'accueil est vide au démarrage, pour savoir si vous avez réussi,
|
||||
rendez-vous sous l'onglet *Hosts*, le nom de votre machine devrait y
|
||||
apparaître. En cliquant dessus, vous obtiendrez des graphiques similaires à
|
||||
ceux ci-dessous :
|
||||
|
||||
![Résultat obtenu](chronograf_latest.png)
|
||||
|
@ -1,4 +1,7 @@
|
||||
## Limiter les ressources
|
||||
\newpage
|
||||
|
||||
Limiter les ressources
|
||||
======================
|
||||
|
||||
Lorsque l'on gère un environnement de production, on souhaite bien
|
||||
évidemment éviter tout déni de service autant que possible. Ou
|
||||
@ -31,11 +34,10 @@ Ainsi, lorsque la machine n'est pas chargée, que le processeur n'a pas
|
||||
constamment du travail à effectuer, l'ordonnanceur ne va pas empêcher
|
||||
une tâche très consommatrice en puissance de calcul de s'exécuter.
|
||||
|
||||
Par contre, sous une forte charge, si l'on défini que notre conteneur
|
||||
exécutant un cpuburn ne peut pas utiliser plus de 50% des ressources
|
||||
de la machine, ce pourcentage ne pourra effectivement pas être
|
||||
dépassé, l'ordonnanceur privilégiant alors les autres processus du
|
||||
système.
|
||||
Par contre, sous une forte charge, si l'on définit que notre conteneur
|
||||
exécutant un cpuburn ne peut pas utiliser plus de 50% des ressources de la
|
||||
machine, ce pourcentage ne pourra effectivement pas être dépassé,
|
||||
l'ordonnanceur privilégiant alors les autres processus du système.
|
||||
|
||||
Par défaut, le taux maximal (1024 = 100%) d'utilisation CPU est donné
|
||||
aux nouveaux conteneurs, on peut le réduire en utilisant l'option
|
||||
@ -46,7 +48,7 @@ aux nouveaux conteneurs, on peut le réduire en utilisant l'option
|
||||
|
||||
En plus des dénis de service, on peut également vouloir se protéger
|
||||
contre des attaques provenant des conteneurs eux-mêmes. On n'est pas à
|
||||
l'abri d'une vulnérabilité dans un des services exécuté dans un
|
||||
l'abri d'une vulnérabilité dans un des services exécutés dans un
|
||||
conteneur. Plusieurs mécanismes sont mis en place pour accroître la
|
||||
difficulté du rebond.
|
||||
|
||||
@ -66,12 +68,12 @@ capabilities.
|
||||
|
||||
### seccomp
|
||||
|
||||
Si les capabilities sont un regroupement grossiers de fonctionnalités
|
||||
Si les capabilities sont un regroupement grossier de fonctionnalités
|
||||
du noyau, seccomp est un filtre que l'on peut définir pour chaque
|
||||
appel système. Liste blanche, liste noire, tout est possible.
|
||||
|
||||
Docker filtre notamment tous les appels systèmes qui pourraient
|
||||
débordés à l'extérieur du conteneur : il n'est par exemple pas
|
||||
déborder à l'extérieur du conteneur : il n'est par exemple pas
|
||||
possible de changer l'heure dans un conteneur, car il n'y a
|
||||
aujourd'hui aucun mécanisme pour isoler les visions des dates d'un
|
||||
conteneur à l'autre.
|
||||
|
@ -6,7 +6,8 @@ Mise en place
|
||||
Dans la première partie du TP, nous avons installé l'environnement Docker
|
||||
principal, qui inclut le client, le daemon et toute sa machinerie. Mais le
|
||||
projet Docker propose de nombreuses autres ressources, souvent directement
|
||||
trouvée dans les usages de la communauté, et parfois même approprié par Docker.
|
||||
trouvées dans les usages de la communauté, et parfois même appropriées par
|
||||
Docker.
|
||||
|
||||
|
||||
## `docker-compose`
|
||||
|
@ -20,5 +20,5 @@ abstract: |
|
||||
clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
|
||||
faire signer votre clef et n'hésitez pas à [faire signer la
|
||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
@ -16,7 +16,7 @@ l'option `--rm`.
|
||||
|
||||
## Conteneurs
|
||||
|
||||
Nous pouvons afficher l'ensemble des conteneurs, quelque soit leur état (en
|
||||
Nous pouvons afficher l'ensemble des conteneurs, quel que soit leur état (en
|
||||
cours d'exécution, arrêtés,\ ...) avec la commande suivante :
|
||||
|
||||
<div lang="en-US">
|
||||
|
@ -93,7 +93,7 @@ docker container logs 0123456789abcdef
|
||||
Maintenant que nous avons un clone de <https://you.p0m.fr/>, nous voulons
|
||||
absolument un clone de <https://food.p0m.fr/> !
|
||||
|
||||
Il s'agit du même service, mais ce n'est pas les mêmes images.
|
||||
Il s'agit du même service, mais ce ne sont pas les mêmes images.
|
||||
|
||||
On ne peut pas utiliser le même port sur la machine hôte, mais pour le reste,
|
||||
il s'agit des mêmes options\ :
|
||||
@ -158,5 +158,5 @@ docker container stop 0123456789abcdef
|
||||
</div>
|
||||
|
||||
Maintenant, si l'on relance un conteneur `youp0m`, il aura perdu toutes les
|
||||
magnifiques images que l'on aura ajouté. Nous allons voir dans la partie
|
||||
magnifiques images que l'on aura ajoutées. Nous allons voir dans la partie
|
||||
suivante comment rendre les données persistantes entre deux lancements.
|
||||
|
@ -5,9 +5,9 @@ Lier les conteneurs
|
||||
|
||||
Lorsque l'on gère des services un peu plus complexes qu'un simple gestionnaire
|
||||
d'images, on a souvent besoin de faire communiquer plusieurs services
|
||||
entre-eux.
|
||||
entre eux.
|
||||
|
||||
Notre premier service, `youp0m`, utilisais le système de fichiers pour stocker
|
||||
Notre premier service, `youp0m`, utilisait le système de fichiers pour stocker
|
||||
ses données, mais la plupart des applications réclament un serveur de base de
|
||||
données.
|
||||
|
||||
@ -62,10 +62,10 @@ Pour changer le réseau principal joint par le conteneur, utiliser l'option
|
||||
|
||||
### Le réseau `host`
|
||||
|
||||
En utilisant ce réseau, vous abandonnez tout isolation sur cette partie du
|
||||
En utilisant ce réseau, vous abandonnez toute isolation sur cette partie du
|
||||
conteneur et partagez donc avec l'hôte toute sa pile IP. Cela signifie, entre
|
||||
autre, que les ports que vous chercherez à allouer dans le conteneur devront
|
||||
être disponibles dans la pile de l'hôte et également que tout port allouer sera
|
||||
autres, que les ports que vous chercherez à allouer dans le conteneur devront
|
||||
être disponibles dans la pile de l'hôte et également que tout port alloué sera
|
||||
directement accessible, sans avoir à utiliser l'option `-p` du `run`.
|
||||
|
||||
|
||||
@ -145,7 +145,7 @@ http://localhost:12345/
|
||||
|
||||
### Entrer dans un conteneur en cours d'exécution
|
||||
|
||||
Dans certaines circonstances, les journaux ne sont pas suffisant pour déboguer
|
||||
Dans certaines circonstances, les journaux ne sont pas suffisants pour déboguer
|
||||
correctement l'exécution d'un conteneur.
|
||||
|
||||
En réalisant l'exercice, vous serez sans doute confronté à des comportements
|
||||
|
@ -19,5 +19,5 @@ abstract: |
|
||||
clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re)
|
||||
faire signer votre clef et n'hésitez pas à [faire signer la
|
||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
@ -103,7 +103,7 @@ autre conteneur.
|
||||
|
||||
Les volumes sont des espaces détachés des conteneurs, particulièrement utiles
|
||||
pour mettre à jour ou relancer un conteneur, sans perdre les données. Un autre
|
||||
intérêt, est de pouvoir partager des fichiers entre plusieurs conteneurs.
|
||||
intérêt est de pouvoir partager des fichiers entre plusieurs conteneurs.
|
||||
|
||||
Il est ainsi parfaitement possible de lancer deux conteneurs qui partagent le
|
||||
même volume :
|
||||
@ -115,7 +115,7 @@ docker container run -d --mount source=prod_youp0m,target=/images -p 8081:8080 n
|
||||
```
|
||||
</div>
|
||||
|
||||
Dans cet exemple, l'ajout d'une image dans un conteneur, l'ajoutera également
|
||||
Dans cet exemple, l'ajout d'une image dans un conteneur l'ajoutera également
|
||||
dans le second.
|
||||
|
||||
Un exemple plus intéressant serait sur une architecture de micro-services
|
||||
|
@ -21,7 +21,7 @@ chaque commande `docker` tapée est passée au deamon dans la machine virtuelle.
|
||||
`DOCKER_HOST` ou de passer le paramètre `-H` suivi de l'URL de la socket à
|
||||
`docker`. Voir aussi : <https://docs.docker.com/machine/overview/>
|
||||
|
||||
Commençons par planter le décors, en détaillant les principaux mécanismes de
|
||||
Commençons par planter le décor, en détaillant les principaux mécanismes de
|
||||
Docker.
|
||||
|
||||
|
||||
|
@ -19,6 +19,6 @@ abstract: |
|
||||
électroniques, vous devrez m'envoyer vos rendus signés avec votre
|
||||
clef PGP. Pensez à
|
||||
[me](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96)
|
||||
faire signer votre clef et n'hésitez pas à [faire signer votre
|
||||
clef](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
faire signer votre clef et n'hésitez pas à [faire signer la
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
@ -19,6 +19,6 @@ abstract: |
|
||||
électroniques, vous devrez m'envoyer vos rendus signés avec votre
|
||||
clef PGP. Pensez à
|
||||
[me](https://pgp.mit.edu/pks/lookup?op=vindex&search=0x842807A84573CC96)
|
||||
faire signer votre clef et n'hésitez pas à [faire signer votre
|
||||
clef](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
faire signer votre clef et n'hésitez pas à [faire signer la
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
@ -19,5 +19,5 @@ abstract: |
|
||||
vous devrez m'envoyer vos rendus signés avec votre clef PGP. Pensez à
|
||||
[me](https://keys.openpgp.org/search?q=nemunaire%40nemunai.re) faire signer
|
||||
votre clef et n'hésitez pas à [faire signer la
|
||||
votre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
vôtre](https://www.meetup.com/fr/Paris-certification-de-cles-PGP-et-CAcert/).
|
||||
...
|
||||
|
Loading…
Reference in New Issue
Block a user