End of Week 1 - Day 4
This commit is contained in:
@@ -1,81 +1,85 @@
|
||||
# 02.2.2 Questionnaire + Correction sur La containérisation
|
||||
# Exos
|
||||
|
||||
Les réponses entre guillements anglais "" sont des corrections.
|
||||
|
||||
## 02.2.2 Questionnaire + Correction sur La containérisation
|
||||
|
||||
1. La virtualisation classique embarque un noyau complet ainsi que les couches micro-logiciels et divers pilotes. Un conteneur n'embarque que la partie applicative et repose sur un noyau principal de la machine hôte
|
||||
2. LXC embarque des conteneurs complets, avec kernels, sorte de VM légèrement allégée et plus flexible. Docker conteneurise à l'ancienne
|
||||
3. KVM et
|
||||
4. LXC, Virt-Manager (LibVirt) et
|
||||
5.
|
||||
3. "cgroups et namespaces"
|
||||
4. En dur : Librairie C, kernel linux supérieur à 3.8. Recommandé : libcap, libapparmor, libselinux, libseccomp, libgnutls, liblua, python3-dev
|
||||
5. libcap (to allow for capability drops), libapparmor (to set a different apparmor profile for the container), libselinux (to set a different selinux context for the container), libseccomp (to set a seccomp policy for the container), libgnutls (for various checksumming), liblua (for the LUA binding), python3-dev (for the python3 binding)
|
||||
6. Non, Docker a son propre démon
|
||||
7. Une version désuette de
|
||||
8. Oui. sudo lxc-copy avec l'option --snapshot
|
||||
9.
|
||||
10.
|
||||
11.
|
||||
12.
|
||||
13.
|
||||
7. "Extension de LXC qui apporte des fonctions avancées comme gestion à distance et snapshot"
|
||||
8. Oui. sudo lxc-copy avec l'option --snapshot / "lxc-snapshot"
|
||||
9. "lxc network attach-profile PROFIL RESEAU"
|
||||
10. lxc-cgroup -n NOM_CONTENEUR cpuset.cpus "0,1" #Limite l'usage du conteneur aux coeurs 0 et 1
|
||||
11. lxc-cgroup -n NOM_CONTENEUR memory.limit_in_bytes "8000" #Does 1MB
|
||||
12. "Oui, si le conteneur est éteint, en SCP via SSH"
|
||||
13. "Non, sauf avec des outils tiers pas très fiables"
|
||||
14. /var/lib/lxc/
|
||||
15. /var/lib/lxc/NomDuConteneur/config
|
||||
|
||||
# Infrastructure Avancée . 02.1.2 Virtualiser des machines
|
||||
## Infrastructure Avancée . 02.1.2 Virtualiser des machines
|
||||
|
||||
1. Installer un système d'exploitation complet sans avoir à géré l'hébergement machine par machine
|
||||
2. Virtualisation complète, conteneurisation, émulation
|
||||
1. Installer un système d'exploitation complet sans avoir à gérer l'hébergement machine par machine "et isolée du système"
|
||||
2. Virtualisation complète, "para-virtualisation, et isolation"
|
||||
3. Ca dépend de ce qu'on recherche. Maintenant la plus "perfomante" au sens gourmandise matérielle, c'est la conteneurisation
|
||||
4. Virtualiser c'est porter un SE sur une grosse bécane. Emulation c'est "convertir" une architecture matérielle (processeur) en temps réel pour l'adapter à une autre archi
|
||||
4. Virtualiser c'est porter un SE sur une grosse bécane. Emulation c'est "convertir" une architecture matérielle (processeur) pour l'adapter à une autre archi
|
||||
5. Le mieux c'est une couche d'abstraction genre QEMU pour émuler
|
||||
6. Mode NAT configuré en sortie routeur (plus standard), mode pont (plus simple), mode Switch interne derrière un VLAN/routeur (plus sécurisé)
|
||||
7. Oracle c'est gratuit mais limité si on veut professionnaliser l'infra. VMWare c'est payant et devenu de la merde
|
||||
8. KVM
|
||||
9.
|
||||
10.
|
||||
11. Lance une VM avec KVM activé, le disque virtuel "ubuntudisquedur" attaché, une image .iso d'ubuntu en option de boot principale, avec deux interfaces réseaux et pas d'option ACPI
|
||||
8. "virsh (virtual shell)"
|
||||
9. "Le groupe Virtualization Host"
|
||||
10. "vboxdrv, solution obsoilète"
|
||||
11. Lance une VM avec KVM activé, le disque virtuel 'ubuntudisquedur' attaché, une image .iso d'ubuntu en option de boot principale, "1024MB de RAM," avec deux interfaces réseaux et pas d'option ACPI
|
||||
12. vboxmanage
|
||||
13. gérer plus nativement des déploiements de VM par script sur des serveurs neufs et sans paquets installés
|
||||
14. COW
|
||||
13. Gérer plus nativement des déploiements de VM par script sur des serveurs neufs et sans paquets installés / "contrôle total au plus bas-niveau possible"
|
||||
14. "RAW"
|
||||
15. QCOW2
|
||||
16. Oui mais c'est chaud
|
||||
17. Oui, avec qemu-img convert
|
||||
18.
|
||||
19.
|
||||
20.
|
||||
18. "cpu-checker"
|
||||
19. "kvm-ok"
|
||||
20. "Xen, VMWare, Hyper-V"
|
||||
21. Hyper-V
|
||||
22. Hyperviseur de type 1 (et pas 2 comme on pourrait le croire)
|
||||
23. ESXi c'est du type 1 bare-metal, Workstation du type 2
|
||||
24.
|
||||
25.
|
||||
24. "Oui, ESXi est compatible AMD et ARM"
|
||||
25. "Client graphique permettant la gestion d'un seul hôte ESXi"
|
||||
26. Passthrough
|
||||
27. Hyperviseur type 1 basé sur un Debian fortement modifié, open-source et gratuit
|
||||
28. .vhdx, historiquement .vhd
|
||||
29. Ouaiiiiiiiiiis
|
||||
30.
|
||||
29. "Non"
|
||||
30. "On peut utiliser Linux Virtual Manager (interface bureau), ou Cockpit (interface web)"
|
||||
|
||||
# Questionnaire 02. Les différents types d_infrastructure avancées
|
||||
## Questionnaire 02. Les différents types d_infrastructure avancées
|
||||
|
||||
1. Spine-Leaf,
|
||||
2. Infra hybride
|
||||
1. "Centralisée (tout le contenu au même endroit), distribuée (), hybride ()."
|
||||
2. "Infra distribuée"
|
||||
3. Les +, de la résilience, les -, des configs en plus à faire pour rester en sécurité
|
||||
4.
|
||||
5.
|
||||
6.
|
||||
4. "La couche leaf"
|
||||
5. "Elle est évolutive et permet une communication de paquet très rapide, ce qui est idéal pour une infrastructure centralisée/un datacenter"
|
||||
6. "Le middleware est un logiciel intermédiaire se trouvant entre client lourd et machine finale. Il peut se trouver sur une machine client ou intermédiaire dédiée, ou même le serveur final, et parfois sur les trois."
|
||||
7. Network Access Storage. En anglais dans le texte
|
||||
8. Non. Sécurité + RGPD
|
||||
9.
|
||||
9. "Unité de stockage à distance, 'Logicial Unit in Network' car n'importe quelle techno peut se cacher derrière."
|
||||
10. SAN, Storage Area Network
|
||||
11.
|
||||
11. "On utilise le nom de 'fabric'"
|
||||
12. Bah, pas forcément... si les données doivent être cloisonnées, c'est un usage pertinent. Au pire on peut ouvrir le SAN pour plus de ressources si besoin
|
||||
13. Moins de latence, moins de déconnexions = moins de corruption dans les transferts
|
||||
14.
|
||||
15.
|
||||
14. "Couche coeur réseau, couche Agrégation, couche Accès"
|
||||
15. "Le trafic ne va plus être optimisé et devra passer par plus d'appareils qu'il était autrefois nécessaire"
|
||||
|
||||
# Questionnaire et correction 01. Introductions aux Infrastructures Avancées
|
||||
## Questionnaire et correction 01. Introductions aux Infrastructures Avancées
|
||||
|
||||
1. ??? Genre l'archi AMD64, les transistors nanométriques, le PCI-E génération 5, la fibre optique, le protocole Wireguard... comment ça ?
|
||||
2. ?????? et bien, multiplier la résilience, les facilités de déploiement, réduire les besoins en gestion matérielle... comment ça ?
|
||||
3. ????????? Gain de productivité à gérer un seul hébergeur, centralisation des factures, interconnexion facilitées dans un VPC donné... comment ça ?
|
||||
4. Le public veut moins attendre et pardonne moins les interruptions de service
|
||||
5. Méthode 1,2,3 et ensuite avoir des CDN locaux réduit la latence en régional
|
||||
6. Bah, la nôtre. C'est encore en usage
|
||||
7. Bah encore maintenant, surtout en TPE/PME. Même en ETI
|
||||
8. Plutôt notre décennie cette fois. Le on-premise disparaît peu à peu face aux envies de "couper les coûts" en virant les admin sys maison
|
||||
6. "Années 50-60"
|
||||
7. "Années 80"
|
||||
8. "Années 2000"
|
||||
9. La prince elle a dit que le stockage, maintenant, ça coûte pas cher
|
||||
10.
|
||||
10. "Le fait de place les données d'un SI au plus proche du client, à l'extrémité du réseau étendu"
|
||||
Reference in New Issue
Block a user