Slides orchestration done
This commit is contained in:
parent
db807385fc
commit
8d4dd97e36
BIN
slides/2-docker advanced.odp
Normal file
BIN
slides/2-docker advanced.odp
Normal file
Binary file not shown.
146
slides/2-docker advanced.pdfpc
Normal file
146
slides/2-docker advanced.pdfpc
Normal file
@ -0,0 +1,146 @@
|
|||||||
|
[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 ?
|
Loading…
Reference in New Issue
Block a user