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