forked from jpetazzo/container.training
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathkube.html
6250 lines (3806 loc) · 159 KB
/
kube.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>Introduction à la formation Kubernetes </title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<link rel="stylesheet" href="workshop.css">
</head>
<body>
<!--
<div style="position: absolute; left: 20%; right: 20%; top: 30%;">
<h1 style="font-size: 3em;">Loading ...</h1>
The slides should show up here. If they don't, it might be
because you are accessing this file directly from your filesystem.
It needs to be served from a web server. You can try this:
<pre>
docker-compose up -d
open http://localhost:8888/workshop.html # on MacOS
xdg-open http://localhost:8888/workshop.html # on Linux
</pre>
Once the slides are loaded, this notice disappears when you
go full screen (e.g. by hitting "f").
</div>
-->
<textarea id="source">class: title, self-paced
Introduction à la formation Kubernetes<br/>
.nav[*Self-paced version*]
.debug[
```
M slides/kube-jour1.yml
M slides/kube-jour2.yml
M slides/logistics.md
?? slides/common/prereqs_fr.md
?? slides/kube-jour3.yml
```
These slides have been built from commit: 838480d
[common/title.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/title.md)]
---
class: title, in-person
Introduction à la formation Kubernetes<br/><br/></br>
.footnote[
**Be kind to the WiFi!**<br/>
<!-- *Use the 5G network.* -->
*Don't use your hotspot.*<br/>
*Don't stream videos or download big files during the workshop.*<br/>
*Thank you!*
**Slides: http://container.training/**
]
.debug[[common/title.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/title.md)]
---
name: toc-chapter-1
## Chapter 1
- [Vue d'ensemble de Docker](#toc-vue-densemble-de-docker)
- [Histoire des conteneurs ... et Docker](#toc-histoire-des-conteneurs--et-docker)
.debug[(auto-generated TOC)]
---
name: toc-chapter-2
## Chapter 2
- [Pre-requirements](#toc-pre-requirements)
- [Our sample application](#toc-our-sample-application)
- [Identifying bottlenecks](#toc-identifying-bottlenecks)
.debug[(auto-generated TOC)]
---
name: toc-chapter-3
## Chapter 3
- [Kubernetes concepts](#toc-kubernetes-concepts)
- [Declarative vs imperative](#toc-declarative-vs-imperative)
- [Kubernetes network model](#toc-kubernetes-network-model)
- [First contact with `kubectl`](#toc-first-contact-with-kubectl)
- [Setting up Kubernetes](#toc-setting-up-kubernetes)
- [Running our first containers on Kubernetes](#toc-running-our-first-containers-on-kubernetes)
.debug[(auto-generated TOC)]
---
name: toc-chapter-4
## Chapter 4
- [Exposing containers](#toc-exposing-containers)
- [Deploying a self-hosted registry](#toc-deploying-a-self-hosted-registry)
- [Exposing services internally](#toc-exposing-services-internally)
- [Exposing services for external access](#toc-exposing-services-for-external-access)
- [The Kubernetes dashboard](#toc-the-kubernetes-dashboard)
- [Security implications of `kubectl apply`](#toc-security-implications-of-kubectl-apply)
.debug[(auto-generated TOC)]
---
name: toc-chapter-5
## Chapter 5
- [Scaling a deployment](#toc-scaling-a-deployment)
- [Daemon sets](#toc-daemon-sets)
- [Updating a service through labels and selectors](#toc-updating-a-service-through-labels-and-selectors)
- [Rolling updates](#toc-rolling-updates)
- [Accessing logs from the CLI](#toc-accessing-logs-from-the-cli)
- [Centralized logging](#toc-centralized-logging)
- [Managing stacks with Helm](#toc-managing-stacks-with-helm)
- [Namespaces](#toc-namespaces)
- [Next steps](#toc-next-steps)
- [Links and resources](#toc-links-and-resources)
.debug[(auto-generated TOC)]
.debug[[common/toc.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/toc.md)]
---
class: pic
.interstitial[]
---
name: toc-vue-densemble-de-docker
class: title
Vue d'ensemble de Docker
.nav[
[Previous section](#toc-)
|
[Back to table of contents](#toc-chapter-1)
|
[Next section](#toc-histoire-des-conteneurs--et-docker)
]
.debug[(automatically generated title slide)]
---
# Vue d'ensemble de Docker
Dans cette partie, nous allons apprendre:
* Pourquoi les conteneurs ('elevator pitch' non-technique)
* Pourquoi les conteneurs ('elevator pitch' technique)
* Comment Docker nous aide à construire, expédier et exécuter
* L'histoire des conteneurs
Nous n'utiliserons pas Docker ni les conteneurs dans ce chapitre (pour l'instant!).
Ne vous inquiétez pas, nous y arriverons assez vite!
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
## Elevator pitch
### (pour votre manager, votre patron ...)
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
## OK ... Pourquoi le buzz autour des conteneurs?
* L'industrie du logiciel a changé
* Avant:
* applications monolithiques
* longs cycles de développement
* environnement unique
* redimensionner lentement
* À présent:
* services découplés
* améliorations rapides et itératives
* plusieurs environnements
* Élargir rapidement
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
## Le déploiement devient très complexe
* Beaucoup de piles différentes:
* langues
* cadres
* des bases
* Beaucoup de cibles différentes:
* environnements de développement individuels
* pré-production, QA, mise en scène ...
* production: sur prém, nuage, hybride
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: pic
## Le problème de déploiement
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: pic
## La matrice de l'enfer
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: pic
## Le parallèle avec l'industrie maritime
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: pic
## Conteneurs d'expédition intermodaux
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: pic
## Un nouvel écosystème d'expédition
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: pic
## Un système de conteneur d'expédition pour les applications
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: pic
## Éliminer la matrice de l'enfer
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
## Résultats
* [Dev-to-prod réduit de 9 mois à 15 minutes (ING)](
https://www.docker.com/sites/default/files/CS_ING_01.25.2015_1.pdf)
* [Temps d'intégration continue réduit de plus de 60% (BBC)](
https://www.docker.com/sites/default/files/CS_BBCNews_01.25.2015_1.pdf)
* [Déployer 100 fois par jour au lieu d'une fois par semaine (GILT)](
https://www.docker.com/sites/default/files/CS_Gilt%20Groupe_03.18.2015_0.pdf)
* [Consolidation de l'infrastructure de 70% (MetLife)](
https://www.docker.com/customers/metlife-transforms-customer-experience-legacy-and-microservices-mashup)
* [Consolidation de l'infrastructure de 60% (Intesa Sanpaolo)](
https://blog.docker.com/2017/11/intesa-sanpaolo-builds-resilient-foundation-banking-docker-enterprise-edition/)
* [14x densité d'application; 60% du centre de données existant migré en 4 mois (GE Appliances)](
https://www.docker.com/customers/ge-uses-docker-enable-self-service-their-developers)
* etc.
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
## Elevator pitch
###(pour vos collègues devs et ops)
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
## Échapper à la dépendance d'enfer
1. Écrire les instructions d'installation dans un fichier `INSTALL.txt`
2. En utilisant ce fichier, écrivez un script `install.sh` qui *vous convient*
3. Transformez ce fichier dans un `Dockerfile`, testez-le sur votre machine
4. Si le Dockerfile se construit sur votre machine, il se construira *n'importe où*
5. Réjouis-toi en évitant l'enfer de la dépendance et "ca marche sur ma machine"
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
## Développeurs et contributeurs embarqués rapidement
1. Écrire des fichiers Docker pour vos composants d'application
2. Utilisez des images pré-faites depuis le Docker Hub (mysql, redis ...)
3. Décrivez votre pile avec un fichier Compose
4. Embarquez quelqu'un avec deux commandes:
```bash
git clone ...
docker-compose up
```
Avec cela, vous pouvez créer des environnements de développement, d'intégration et d'assurance qualité en quelques minutes!
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: extra-details
## Mettre en œuvre un CI fiable facilement
1. Construire un environnement de test avec un fichier Dockerfile ou Compose
2. Pour chaque série de tests, placez un nouveau conteneur ou une nouvelle pile
3. Chaque course est maintenant dans un environnement propre
4. Aucune pollution des tests précédents
Beaucoup plus rapide et moins cher que de créer des machines virtuelles à chaque fois!
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: extra-details
## Utiliser les images de conteneur comme artefacts de construction
1. Construisez votre application depuis Dockerfiles
2. Stocker les images résultantes dans un registre
3. Garde-les pour toujours (ou aussi longtemps que nécessaire)
4. Testez ces images dans QA, CI, intégration ...
5. Exécuter les mêmes images en production
6. Quelque chose ne va pas? Retour à l'image précédente
7. Enquêter sur l'ancienne régression? L'ancienne image vous couvre!
Les images contiennent toutes les bibliothèques, dépendances, etc. nécessaires pour exécuter l'application.
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: extra-details
## Découpler "plomberie" de la logique de l'application
1. Ecrivez votre code pour vous connecter aux services nommés ("db", "api" ...)
2. Utilisez Composer pour commencer votre pile
3. Docker va configurer le résolveur DNS par conteneur pour ces noms
4. Vous pouvez maintenant redimensionner, ajouter des équilibreurs de charge, réplication ... sans changer votre code
Note: ceci n'est pas couvert dans cet atelier de niveau intro!
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: extra-details
## Qu'est-ce que Docker a apporté à la table?
### Docker avant / après
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: extra-details
## Formats et API, avant Docker
* Pas de format d'échange standardisé.
<br/>(Non, une archive tar de rootfs *n'est pas* un format!)
* Les conteneurs sont difficiles à utiliser pour les développeurs.
<br/>(Où est l'équivalent de `docker run debian`?)
* En conséquence, ils sont cachés aux utilisateurs finaux.
* Aucun composant, API ou outil réutilisable.
<br/>(Au mieux: abstractions de VM, par exemple libvirt.)
Analogie:
* Les conteneurs d'expédition ne sont pas seulement des boîtes en acier.
* Ce sont des boîtes en acier de taille standard, avec les mêmes crochets et trous.
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: extra-details
## Formats et API, après Docker
* Normaliser le format du conteneur, car les conteneurs n'étaient pas portables.
* Rendre les conteneurs faciles à utiliser pour les développeurs.
* Accent sur les composants réutilisables, API, écosystème d'outils standards.
* Amélioration des outils spécifiques ad-hoc, internes.
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: extra-details
## Expédition, avant Docker
* Expédier les paquets: deb, rpm, gem, pot, homebrew ...
* Dépendance de l'enfer.
* "Fonctionne sur ma machine."
* Déploiement de base souvent fait à partir de zéro (debootstrap ...) et peu fiable.
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: extra-details
## Expédition, après Docker
* Expédier des images de conteneur avec toutes leurs dépendances.
* Les images sont plus grandes, mais elles sont divisées en couches.
* Envoyez uniquement les couches qui ont changé.
* Enregistrer l'utilisation du disque, du réseau, de la mémoire.
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: extra-details
## Exemple
Couches:
* CentOS
* JRE
* Matou
* Dépendances
* Application JAR
* Configuration
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: extra-details
## Devs vs Ops, avant Docker
* Déposez une archive tar (ou un hash de commit) avec des instructions.
* Environnement de développement très différent de la production.
* Les Ops n'ont pas toujours un environnement de dev eux-mêmes ...
* ... et quand ils le font, cela peut différer de ceux des développeurs.
* Les opérations doivent trier les différences et le faire fonctionner ...
* ... ou rebondir vers les développeurs.
* Le code de livraison provoque des frictions et des retards.
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: extra-details
## Devs vs Ops, après Docker
* Déposer une image de conteneur ou un fichier de composition.
* Les opérations peuvent toujours exécuter cette image de conteneur.
* Les opérations peuvent toujours exécuter ce fichier de composition.
* Les opérations doivent encore s'adapter à l'environnement de prod,
mais au moins ils ont un point de référence.
* Les opérations ont des outils permettant d'utiliser la même image
en dev et prod.
* Les développeurs peuvent être autorisés à faire eux-mêmes des publications
plus facilement.
.debug[[intro/Docker_Overview_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_Overview_fr.md)]
---
class: pic
.interstitial[]
---
name: toc-histoire-des-conteneurs--et-docker
class: title
Histoire des conteneurs ... et Docker
.nav[
[Previous section](#toc-vue-densemble-de-docker)
|
[Back to table of contents](#toc-chapter-1)
|
[Next section](#toc-pre-requirements)
]
.debug[(automatically generated title slide)]
---
# Histoire des conteneurs ... et Docker
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
## Premières expérimentations
* [IBM VM/370 (1972)](https://en.wikipedia.org/wiki/VM_%28operating_system%29)
* [Linux VServers (2001)](http://www.solucorp.qc.ca/changes.hc?projet=vserver)
* [Solaris Containers (2004)](https://en.wikipedia.org/wiki/Solaris_Containers)
* [FreeBSD jails (1999)](https://www.freebsd.org/cgi/man.cgi?query=jail&sektion=8&manpath=FreeBSD+4.0-RELEASE)
Les conteneurs existent depuis *très longtemps* en effet.
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
class: pic
## L'âge du VPS (jusqu'en 2007-2008)
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
## Containers = moins cher que les VM
* Utilisateurs: fournisseurs d'hébergement.
* Audience hautement spécialisée avec une forte culture d'opérations.
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
class: pic
## La période PAAS (2008-2013)
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
## Containers = plus facile que les VM
* Je ne peux pas parler pour Heroku, mais les conteneurs étaient (l'une des) arme secrète de dotCloud
* dotCloud utilisait un PaaS, en utilisant un moteur de conteneur personnalisé.
* Ce moteur était basé sur OpenVZ (et plus tard, LXC) et AUFS.
* Il a commencé (vers 2008) comme un seul script Python.
* En 2012, le moteur avait plusieurs (10) composants Python.
<br/> (et ~ 100 autres micro-services!)
* Fin 2012, dotCloud refactorise ce moteur de conteneur.
* Le nom de code de ce projet est "Docker".
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
## Première version publique de Docker
* Mars 2013, PyCon, Santa Clara:
<br/> "Docker" est présenté au public pour la première fois.
* Il est publié avec une licence open source.
* Réactions et retours très positifs!
* L'équipe dotCloud passe progressivement au développement de Docker.
* La même année, dotCloud change de nom pour Docker.
* En 2014, l'activité PaaS est vendue.
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
## Docker premiers jours (2013-2014)
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
## Premiers utilisateurs de Docker
* Constructeurs PAAS (Flynn, Dokku, Tsuru, Deis ...)
* Utilisateurs de PAAS (ceux qui sont assez grands pour justifier la construction de leurs propres)
* Plates-formes CI
* développeurs, développeurs, développeurs, développeurs
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
## Boucle de rétroaction positive
* En 2013, la technologie sous conteneurs (cgroups, namespaces, stockage copy-on-write ...)
avait beaucoup de taches aveugles.
* La popularité croissante de Docker et des conteneurs a révélé de nombreux bugs.
* En conséquence, ces bugs ont été corrigés, ce qui a permis d'améliorer la stabilité des conteneurs.
* Tout hébergeur / fournisseur de cloud décent peut exécuter des conteneurs aujourd'hui.
* Les conteneurs deviennent un excellent outil pour déployer / déplacer des charges de travail de / sur le site / cloud.
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
## Maturité (2015-2016)
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
## Docker devient un standard de l'industrie
* Docker atteint le jalon symbolique 1.0.
* Les systèmes existants tels que Mesos et Cloud Foundry ajoutent un support Docker.
* Normalisation autour de l'OCI (Open Containers Initiative).
* D'autres moteurs de conteneurs sont développés.
* Création de la CNCF (Cloud Native Computing Foundation).
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
## Docker devient une plateforme
* Le moteur de conteneur initial est maintenant connu sous le nom de "Moteur Docker".
* D'autres outils sont ajoutés:
* Docker Compose (anciennement "Fig")
* Machine Docker
* Docker Swarm
* Kitematic
* Docker Cloud (anciennement "Tutum")
* Datacenter Docker
* etc.
* Docker Inc. lance des offres commerciales.
.debug[[intro/Docker_History_fr.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/intro/Docker_History_fr.md)]
---
class: pic
.interstitial[]
---
name: toc-pre-requirements
class: title
Pre-requirements
.nav[
[Previous section](#toc-histoire-des-conteneurs--et-docker)
|
[Back to table of contents](#toc-chapter-2)
|
[Next section](#toc-our-sample-application)
]
.debug[(automatically generated title slide)]
---
# Pre-requirements
- Be comfortable with the UNIX command line
- navigating directories
- editing files
- a little bit of bash-fu (environment variables, loops)
- Some Docker knowledge
- `docker run`, `docker ps`, `docker build`
- ideally, you know how to write a Dockerfile and build it
<br/>
(even if it's a `FROM` line and a couple of `RUN` commands)
- It's totally OK if you are not a Docker expert!
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
class: title
*Tell me and I forget.*
<br/>
*Teach me and I remember.*
<br/>
*Involve me and I learn.*
Misattributed to Benjamin Franklin
[(Probably inspired by Chinese Confucian philosopher Xunzi)](https://www.barrypopik.com/index.php/new_york_city/entry/tell_me_and_i_forget_teach_me_and_i_may_remember_involve_me_and_i_will_lear/)
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
## Hands-on sections
- The whole workshop is hands-on
- We are going to build, ship, and run containers!
- You are invited to reproduce all the demos
- All hands-on sections are clearly identified, like the gray rectangle below
.exercise[
- This is the stuff you're supposed to do!
- Go to [container.training](http://container.training/) to view these slides
- Join the chat room: In person!
<!-- ```open http://container.training/``` -->
]
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
class: in-person
## Where are we going to run our containers?
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
class: in-person, pic
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
class: in-person
## You get a cluster of cloud VMs
- Each person gets a private cluster of cloud VMs (not shared with anybody else)
- They'll remain up for the duration of the workshop
- You should have a little card with login+password+IP addresses
- You can automatically SSH from one VM to another
- The nodes have aliases: `node1`, `node2`, etc.
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
class: in-person
## Why don't we run containers locally?
- Installing that stuff can be hard on some machines
(32 bits CPU or OS... Laptops without administrator access... etc.)
- *"The whole team downloaded all these container images from the WiFi!
<br/>... and it went great!"* (Literally no-one ever)
- All you need is a computer (or even a phone or tablet!), with:
- an internet connection
- a web browser
- an SSH client
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
class: in-person
## SSH clients
- On Linux, OS X, FreeBSD... you are probably all set
- On Windows, get one of these:
- [putty](http://www.putty.org/)
- Microsoft [Win32 OpenSSH](https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH)
- [Git BASH](https://git-for-windows.github.io/)
- [MobaXterm](http://mobaxterm.mobatek.net/)
- On Android, [JuiceSSH](https://juicessh.com/)
([Play Store](https://play.google.com/store/apps/details?id=com.sonelli.juicessh))
works pretty well
- Nice-to-have: [Mosh](https://mosh.org/) instead of SSH, if your internet connection tends to lose packets
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
class: in-person, extra-details
## What is this Mosh thing?
*You don't have to use Mosh or even know about it to follow along.
<br/>
We're just telling you about it because some of us think it's cool!*
- Mosh is "the mobile shell"
- It is essentially SSH over UDP, with roaming features
- It retransmits packets quickly, so it works great even on lossy connections
(Like hotel or conference WiFi)
- It has intelligent local echo, so it works great even in high-latency connections
(Like hotel or conference WiFi)
- It supports transparent roaming when your client IP address changes
(Like when you hop from hotel to conference WiFi)
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
class: in-person, extra-details
## Using Mosh
- To install it: `(apt|yum|brew) install mosh`
- It has been pre-installed on the VMs that we are using
- To connect to a remote machine: `mosh user@host`
(It is going to establish an SSH connection, then hand off to UDP)
- It requires UDP ports to be open
(By default, it uses a UDP port between 60000 and 61000)
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
class: in-person
## Connecting to our lab environment
.exercise[
- Log into the first VM (`node1`) with your SSH client
<!--
```bash
for N in $(awk '/\Wnode/{print $2}' /etc/hosts); do
ssh -o StrictHostKeyChecking=no $N true
done
```
```bash
if which kubectl; then
kubectl get all -o name | grep -v service/kubernetes | xargs -n1 kubectl delete
fi
```
-->
- Check that you can SSH (without password) to `node2`:
```bash
ssh node2
```
- Type `exit` or `^D` to come back to `node1`
<!-- ```bash exit``` -->
]
If anything goes wrong — ask for help!
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
## Doing or re-doing the workshop on your own?
- Use something like
[Play-With-Docker](http://play-with-docker.com/) or
[Play-With-Kubernetes](https://medium.com/@marcosnils/introducing-pwk-play-with-k8s-159fcfeb787b)
Zero setup effort; but environment are short-lived and
might have limited resources
- Create your own cluster (local or cloud VMs)
Small setup effort; small cost; flexible environments
- Create a bunch of clusters for you and your friends
([instructions](https://github.com/jpetazzo/container.training/tree/master/prepare-vms))
Bigger setup effort; ideal for group training
.debug[[common/prereqs.md](https://github.com/RyaxTech/container.training.git/tree/master/slides/common/prereqs.md)]
---
class: self-paced