2020 done
This commit is contained in:
parent
fafac06b23
commit
a75f4b43b7
25 changed files with 113 additions and 2498 deletions
Binary file not shown.
|
|
@ -1,220 +0,0 @@
|
|||
[file]
|
||||
1-docker's basis.pdf
|
||||
[skip]
|
||||
4,5,6,7,8,10,11,12,13,18,21,22,23,29,30,36,37,38,
|
||||
[end_user_slide]
|
||||
22
|
||||
[notes]
|
||||
### 1
|
||||
Après la piscine, on reste dans un thème aquatique, puisqu'on va parler de Docker aujourd'hui !
|
||||
|
||||
Sondage de repérage
|
||||
|
||||
* Qui a déjà entendu parlé de Docker ?
|
||||
* Qui a déjà utilisé au moins une fois ?
|
||||
* Est-ce que certain l'utilisent tous les jours ou presque ?
|
||||
|
||||
C'est vrai qu'une fois compris les principes, peut plus s'en passer.
|
||||
|
||||
* qqn déjà essayé un autre programme de virli ?
|
||||
|
||||
Pour les autres,
|
||||
on va p-e commencer par expliquer ce que c'est, la virli.### 2
|
||||
Déjà, la virtualisation ...
|
||||
|
||||
* La virtualisation classique
|
||||
|
||||
** gros serveur répondre pic de trafic quotidient, passe son temps à rien faire hors de ce pic => besoin d'optim
|
||||
** Déploiement fastidieux de services concurrent (ex. un serveur web) :
|
||||
- partager le port = partager la config
|
||||
- reverse proxy : ok tant que c'est deux soft différents
|
||||
- installation en parallèle de deux versions différentes hasardeuses et complexe
|
||||
|
||||
** Création du principe de machine virtuelle
|
||||
- émulation du matériel
|
||||
- gain en terme de sécu
|
||||
|
||||
** Aidé des instructions de virtualisation
|
||||
- le matériel reste émulé, mais prends des raccourcis lorsque supporté par l'hôte et l'invité (virtio)
|
||||
### 3
|
||||
* Quelles sont les grandes étapes de boot d'une machine moderne ?
|
||||
ground PS_ON, reset CPU, bootloader (BIOS/UEFI), chargeur d'amorce (GRUB, ...), noyau de l'OS, espace utilisateur (init, systemd, ...), daemons et applications utilisateur (logind, Xorg, ...)
|
||||
|
||||
* différences avec une machine virtuelle
|
||||
- création d'un espace d'adressage
|
||||
- vmenter
|
||||
|
||||
* Optimisation du reboot ?
|
||||
|
||||
* Pas encore très léger comme virtualisation
|
||||
on veut pas vraiment des multiples noyaux et système, simplement pour un daemon qui écoute sur une autre IP
|
||||
|
||||
* Virtualisation légère : le noyau peut isoler des systèmes différents
|
||||
- On a plus que l'espace utilisateur à recharger
|
||||
- Plein de technos font ça : OpenVZ, LXC, ...
|
||||
DEMO LXC VPS
|
||||
|
||||
* C'est mieux, mais on a encore des éléments inutiles : cron, init, ...
|
||||
=> Et si on lançait uniquement notre deamon ?
|
||||
DEMO docker owncloud, telegraf/graphana/... SRS FIC ?
|
||||
|
||||
* pub pour les cours 3 et 4 sur Linux Internals : NS + cg
|
||||
### 4
|
||||
* Scheduling simplifié
|
||||
* RAM mieux utilisée
|
||||
|
||||
- kernel unique
|
||||
- libc partagées
|
||||
- cache de fichiers unique (s'adapte à l'espace restant)
|
||||
### 5
|
||||
* Acteurs historiques
|
||||
- Zones Solaris
|
||||
- Jails BSD
|
||||
- OpenVZ
|
||||
|
||||
* Arnaques
|
||||
- Docker4mac
|
||||
- Docker4windows
|
||||
Microsoft Hyper-V
|
||||
Windows 10 Pro 64 bits
|
||||
|
||||
* En développement/test
|
||||
- Windows Containers
|
||||
Windows Server 2016
|
||||
Windows 10 Anniversary Edition
|
||||
### 6
|
||||
Questions ?
|
||||
### 7
|
||||
DAEMON
|
||||
* REST API
|
||||
* qui gère des Docker objects
|
||||
- images, conteneurs, services
|
||||
- réseaux, nœux de cluster
|
||||
- volumes
|
||||
* local registry
|
||||
* containerd/runc
|
||||
|
||||
CLIENT
|
||||
|
||||
Open Container Initiative
|
||||
|
||||
Docker hub/store
|
||||
### 8
|
||||
Image
|
||||
* Modèle en lecture seule
|
||||
* utilisé pour pour créer les conteneurs
|
||||
|
||||
Conteneur
|
||||
* Instance d'une image
|
||||
* isolé de tout de base, on règle après ce que l'on souhaite partager (réseau, stockage, ...)
|
||||
|
||||
Services
|
||||
* groupe de conteneurs qui forme une application
|
||||
### 9
|
||||
Démo
|
||||
|
||||
docker run touch /toto
|
||||
voir que dans un autre docker run, ls / ne montre pas foo
|
||||
### 10
|
||||
Commence par regarder en local si on a pas l'image
|
||||
|
||||
Ensuite il va interroger son registre par défaut, sans configuration, il s'agit du Docker Store.
|
||||
|
||||
Si l'on désucre le nom du conteneur, on obtient ce chemin
|
||||
|
||||
Le but de Docker étant de récupérer un fichier manifests
|
||||
|
||||
|
||||
On utilise la forme complètement quand on a un registre privé
|
||||
### 11
|
||||
Parler de l'ancienne syntaxe toujours d'actualité, mais beaucoup plus documentée
|
||||
### 12
|
||||
Démo
|
||||
|
||||
docker image ls
|
||||
docker image rm
|
||||
|
||||
docker container ls
|
||||
docker container rm
|
||||
docker container create
|
||||
### 13
|
||||
Comment fait-on pour créer une image ?
|
||||
|
||||
On va pouvoir créer une image (qui pourra donc servir de modèle pour créer d'autre cntr) à partir d'un conteneur que l'on décidera de figer à un instant donné.
|
||||
|
||||
=> docker commit
|
||||
|
||||
On indique lors du commit le conteneur à figer ainsi que lenom de l'image que l'on souhaite créer.### 14
|
||||
* CoW
|
||||
* layers/couches (docker image history IMAGE)
|
||||
* unionfs
|
||||
### 15
|
||||
Maintenant, comment faire en sorte que deux conteneur puissent se parler ?
|
||||
|
||||
On commence par lancer deux cntrs. et l'on demande explicitement à ce que le compteur nous expose son port 80.
|
||||
--
|
||||
On crée ensuite un objet Docker network, dans lequel on vient placer nos deux conteneurs.
|
||||
Ils peuvent alors se parler.
|
||||
--
|
||||
Mieux encore, un serveur DNS permet de résoudre le nom des conteneurs dans ce réseau, pour simplifier la configuration.
|
||||
|
||||
Si trop de temps :
|
||||
docker container run -P nginx
|
||||
docker container ls
|
||||
docker container port $ID
|
||||
go with firefox
|
||||
### 16
|
||||
On utilisé juste avant docker commit pour créer une nouvelle image à partir d'un conteneur. Mais on peut aussi utiliser ce qu'on appel des Dockerfile.
|
||||
|
||||
- fichier texte
|
||||
- instructions de base : FROM, RUN, COPY, CMD
|
||||
|
||||
DEMO hello srs 1
|
||||
|
||||
- passage du contexte au daemon
|
||||
- .dockerignore
|
||||
|
||||
- cache de construction
|
||||
|
||||
- bonnes pratiques à propos des installs :
|
||||
- minimise le nombre de couches
|
||||
faire la part des choses entre relecture/maintenabilité et nombre de couches
|
||||
### 17
|
||||
Dockerfile hello srs
|
||||
|
||||
À propos du linkage statique vs. dynamique
|
||||
### 18
|
||||
chaque ligne est exécutée dans un conteneur distinct
|
||||
les commandes ne servent qu'à modifier le système de fichier
|
||||
on ne peut pas lancer un programme, il sera fermé avec le conteneur
|
||||
|
||||
- bonnes pratiques à propos des installs :
|
||||
- pas d'upgrade
|
||||
- on clean les couches
|
||||
### 19
|
||||
Lorsqu'on a besoin de compiler un programme avant de le mettre dans un conteneur, pas besoin d'inclure le compilateur !
|
||||
### 20
|
||||
|
||||
|
||||
* volumes : une couche simple
|
||||
* bind mounts : partagés avec l'hôte
|
||||
|
||||
* volume-from : partage de volumes entre conteneurs
|
||||
|
||||
* tmpfs mounts : non persistant, uniquement dans la mémoire de l'hôte
|
||||
### 21
|
||||
Questions ?
|
||||
|
||||
- limiter les ressources
|
||||
- arrêter un conteneur
|
||||
- commandes détachées du terminal (-d) + docker logs
|
||||
### 22
|
||||
* Questionnaire sur Epitaf sur les notions de cours + recherches perso (pour éviter un partiel)
|
||||
* Demandez pour un partage de flux intéressants, d'articles cools sur le sujet, ...
|
||||
|
||||
* Rendus des exercices du TP + projet complémentaire par mail
|
||||
- signature PGP
|
||||
|
||||
* Correction au début du prochain cours => limite du rendu
|
||||
|
||||
* Sondage de satisfaction à la fin du cours : notez vos feedbacks !
|
||||
Binary file not shown.
|
|
@ -1,146 +0,0 @@
|
|||
[file]
|
||||
2-docker advanced.pdf
|
||||
[skip]
|
||||
8,11,12,13,14,17,18,21,23,24,
|
||||
[notes]
|
||||
### 1
|
||||
Bonjour, aujourd'hui, on va continuer de découvrir Docker, et plus particulièrement : ce qui touche à l'orchestration.
|
||||
|
||||
Ça va, vous vous en êtes sorti avec le petit projet ?
|
||||
|
||||
C'est le dernier cours que l'on va faire sur Docker, donc le projet est un peu plus long.### 2
|
||||
Normalement, vous aviez des questions de cours à préparer sur Epitaf, on fera sans et on trouvera une solution pour la prochaine fois.
|
||||
|
||||
Du coup, peut-être que je vais donner plein de réponses durant ce cours, vous avez bien fait de venir y assister !
|
||||
|
||||
Commençons par faire un point sur les signatures PGP ....### 3
|
||||
Quelques statistiques qui parlent d'elles-même : seulement 7 d'entre-vous ont réussi à envoyer un mail sans se tromper. Bravo !
|
||||
|
||||
2 d'entre vous ne comprennent pas le fonctionnement des bi-clefs.
|
||||
=> pour signer, on chiffre un condensat du mail avec ... ? clef privée, pour que n'importe qui possédant la clef publique puisse faire l'op inverse
|
||||
=> pour chiffrer, on chiffre la clef de chiffrement symét. avec ... ? clef pub. du destinataire, car seule la clef privée pourra le déchiffrer.
|
||||
|
||||
Quels sont les algo qui fonctionnent comme ça ? RSA, et puis ?
|
||||
=> ECDSA, ED25519, ...
|
||||
|
||||
À propos de RSA, qui peut m'expliquer la vulnérabilité découverte lundi ?
|
||||
ROCA, Infineon, nitrokey 4, carte d'identitée estonienne, ...
|
||||
=====
|
||||
|
||||
Sylvio, qui m'a envoyé son certificat de révocation, à quoi ça sert un certif de révocation ?### 4
|
||||
Vous avez globalement tous eu du mal à partager votre clef publique.
|
||||
|
||||
Le plus simple était sans doute de l'envoyer sur un serveur de clef...### 5
|
||||
Si vous aimez la sécurité, venez rencontrer des gens dans les cryptoparties !
|
||||
|
||||
La prochaine chez Mozilla est annuelle, sur inscription et va ameuter beaucoup de monde.
|
||||
|
||||
Tous les mois, aux Halles, on parle sécurité informatique pendant 1h, en signant les gens qui viennent que ce soit PGP ou CAcert
|
||||
|
||||
Et plein d'autres événements organise souvent en parallèle des KSP### 6
|
||||
Est-ce que vous voulez savoir comment on signe une clef PGP ?
|
||||
|
||||
C'est un réseau de confiance, vous êtes entièrement responsable de la manière dont vous gérez votre réseau.
|
||||
Vous pouvez signer n'importe qui sans faire de vérification.
|
||||
Ce qui importe, c'est la confiance qu'on accorde aux gens que l'on signe. Est-ce que l'on souhaite leur accorder notre confiance pour étendre notre réseau ou pas ?
|
||||
|
||||
Une signature, ça se fait toujours en face à face. Avec une ou deux pièces d'identitées dont on sait valider l'authenticité.
|
||||
|
||||
Lorsque l'on valide la clef sur sa machine, il faut vérifier chaque chiffre de l'empreinte.
|
||||
|
||||
Les bonnes pratiques veulent que l'on renvoie la clef signée à son propriétaire qui choisi de publier ou non la signature.
|
||||
|
||||
Problème des métadonnées : cela expose nos connaissances### 7
|
||||
Il y avait une question sur Epitaf pourtant sur le nombre de couches que possédait votre image web server.
|
||||
|
||||
Ici donc, 4.
|
||||
|
||||
Comment on peut afficher explicitement le nombre de couches ?### 8
|
||||
Une autre question qui était posée :
|
||||
Est-ce que c'est mieux en haut où en bas ?
|
||||
|
||||
1 RUN = 1 couche
|
||||
|
||||
FROM plus précis en haut : ça a plus de chance de perdurer dans le temps
|
||||
|
||||
RUN inutile en bas, car la suppression ne supprimera pas les fichiers des couches précédentes### 9
|
||||
Est-ce que certains d'entre vous ont creusé pour savoir comment effectuer une action privilégiée sans être root, uniquement via Docker ?
|
||||
|
||||
--privileged
|
||||
|
||||
monté un volume de la racine et chroot dedans
|
||||
|
||||
utiliser le réseau de l'hote pour changer les interfaces
|
||||
|
||||
s'ajouter quelques capabilities sympa (on y reviendra la semaine prochaine)
|
||||
|
||||
seccomp : mécanisme de filtrage des syscall :
|
||||
- soit liste blanche,
|
||||
- soit liste noire.
|
||||
|
||||
Par défaut Docker : retire beaucoup de capabilities et limite les appels système, en particulier aux mécanismes qui ne sont pas isolés.### 10
|
||||
DEMO nanosleep### 11
|
||||
Pendant qu'on parle sécu, avez-vous regardé comment limiter l'usage CPU ou RAM avec Docker ?
|
||||
|
||||
CPU shares, n'est actif que si le CPU est à 100%, dans ce cas, le conteneur ne pourra s'en octroyer que la moitié au maximum par rapport aux autres processus.
|
||||
|
||||
Memory, facile, on peut aussi l'appliquer à la swap dans les versions récentes du noyau
|
||||
|
||||
PID limit, noyau récent aussi, on fait un test ?!
|
||||
### 12
|
||||
DEMO fork-bomb controlé### 13
|
||||
Voici le script qu'il fallait écrire, en gros, pour lancer owncloud
|
||||
|
||||
On crée un volume pour la base de données
|
||||
On lance la base de données avec ce volume et le pass root dans l'env
|
||||
|
||||
On crée un volume pour les données owncloud (dit dans le readme du cntr)
|
||||
On lance le conteneur lié au mysql => il hérite de l'env
|
||||
|
||||
Enfin, on fait un coup de docker inspect, format template Golang et voilà
|
||||
|
||||
=====
|
||||
|
||||
Je parlais de docker-compose, vous avez jeté un œil du coup ? c'est le sujet du TP aujourd'hui !
|
||||
|
||||
Voilà à quoi ça ressemble donc. on déclare des services, en YAML, et on les décrits : quels images, comment les builds, quelle politique de restart appliquer, quels ports exposer, comment les lier
|
||||
|
||||
DEMO un vrai ....### 14
|
||||
Image
|
||||
* modèle en lecture seule
|
||||
* utilisé pour créer des conteneurs
|
||||
|
||||
Conteneur
|
||||
* instance d'une image
|
||||
* isolé de tout de base, on règle après ce que l'on souhaite partager (réseau, stockage, ...)
|
||||
|
||||
Tâche (à partir d'un cluster)
|
||||
* une instance d'une image qui tourne pour un conteneur
|
||||
* propriétés très similaire aux conteneurs
|
||||
|
||||
Service (à partir d'un cluster)
|
||||
* un groupe de tâches partageant la même image
|
||||
|
||||
Stack (à partir d'un cluster)
|
||||
* un groupe de services, différents, formant un projet avec tous ses composants.### 15
|
||||
De plus en plus de nos jours, on a besoin de faire de l'orchestration :
|
||||
- bcp de serveur
|
||||
- bcp de conteneur
|
||||
aux carac. différentes
|
||||
=> certain + RAM, d'autre + CPU, + disque, ...
|
||||
|
||||
Faire la répartition à la main, n'est plus possible.
|
||||
|
||||
Mesos, Nomad, Kubernetes, Swarm, ...
|
||||
|
||||
Pendant le TP, on va passer un peu de temps sur Swarm.
|
||||
|
||||
À savoir qu'actuellement:
|
||||
Les bases de données ça se clusterise pas bien pour l'instant.### 16
|
||||
Dockerfile hello srs
|
||||
|
||||
À propos du linkage statique vs. dynamique### 17
|
||||
### 18
|
||||
C'est parti pour le TP !
|
||||
|
||||
Parler un peu des serveurs du FIC ?
|
||||
Binary file not shown.
|
|
@ -1,4 +0,0 @@
|
|||
[file]
|
||||
4-linux internals.pdf
|
||||
[skip]
|
||||
5,8,9,10,11,12,14,
|
||||
Loading…
Add table
Add a link
Reference in a new issue