﻿1
00:00:01,110 --> 00:00:02,860
‫-: Dans cette vidéo, nous

2
00:00:02,860 --> 00:00:05,780
‫allons faire une dernière configuration spécifique à Heroku qui

3
00:00:05,780 --> 00:00:08,047
‫consiste à répondre à un soi-disant

4
00:00:08,047 --> 00:00:10,770
‫"signal de terme malade" qu'Heroku émet de temps

5
00:00:10,770 --> 00:00:12,023
‫en temps.

6
00:00:13,670 --> 00:00:16,300
‫Ainsi, un dyno Heroku, et encore une

7
00:00:16,300 --> 00:00:19,460
‫fois, un dyno n'est qu'un nom qu'Heroku utilise pour

8
00:00:19,460 --> 00:00:21,540
‫désigner essentiellement un conteneur dans

9
00:00:21,540 --> 00:00:23,230
‫lequel votre application s'exécute

10
00:00:23,230 --> 00:00:26,820
‫afin que ces dynos redémarrent toutes les 24 heures afin

11
00:00:26,820 --> 00:00:29,930
‫de maintenir votre application dans un état sain.

12
00:00:29,930 --> 00:00:32,930
‫D'accord? Et la façon

13
00:00:32,930 --> 00:00:36,060
‫dont Heroku le fait est d'envoyer le soi-disant

14
00:00:36,060 --> 00:00:38,577
‫"signal de terme malade" à notre application

15
00:00:38,577 --> 00:00:41,640
‫de note, et l'application s'arrêtera alors fondamentalement immédiatement.

16
00:00:41,640 --> 00:00:44,680
‫Très bien? Maintenant, le problème avec

17
00:00:44,680 --> 00:00:46,830
‫ceci est que l'arrêt peut être très brusque.

18
00:00:46,830 --> 00:00:50,020
‫Cela peut donc laisser les demandes en

19
00:00:50,020 --> 00:00:51,930
‫cours de traitement en

20
00:00:51,930 --> 00:00:53,730
‫suspens, ce qui

21
00:00:53,730 --> 00:00:55,789
‫n'est donc pas idéal.

22
00:00:55,789 --> 00:00:58,830
‫Donc, fondamentalement, c'est ce qui se passe également

23
00:00:58,830 --> 00:01:01,623
‫lorsqu'il y a un rejet non géré.

24
00:01:02,850 --> 00:01:05,024
‫Donc, ici, dans notre serveur, point

25
00:01:05,024 --> 00:01:07,320
‫JS, rappelez-vous comment nous arrêtons gracieusement le

26
00:01:07,320 --> 00:01:09,700
‫serveur chaque fois qu'il y avait un

27
00:01:09,700 --> 00:01:12,690
‫rejet non géré. Très bien?

28
00:01:12,690 --> 00:01:13,990
‫Alors maintenant, nous allons

29
00:01:13,990 --> 00:01:16,240
‫faire quelque chose de très similaire lorsque nous recevrons

30
00:01:16,240 --> 00:01:20,310
‫le "signal de fin de maladie". Très bien? Disons donc que traiter

31
00:01:22,410 --> 00:01:23,690
‫le point

32
00:01:26,870 --> 00:01:29,660
‫sur le terme de maladie, et donc fondamentalement,

33
00:01:29,660 --> 00:01:32,300
‫le terme de maladie n'est vraiment qu'un

34
00:01:32,300 --> 00:01:35,160
‫événement qui peut être émis et que notre application

35
00:01:35,160 --> 00:01:36,700
‫reçoit et peut ensuite répondre.

36
00:01:36,700 --> 00:01:40,383
‫Donc exactement comme le rejet non géré. À droite?

37
00:01:41,430 --> 00:01:43,293
‫Maintenant, ici, nous n'avons pas d'erreur,

38
00:01:46,210 --> 00:01:47,760
‫et faisons donc un journal

39
00:01:48,720 --> 00:01:50,250
‫de la console ici

40
00:01:52,130 --> 00:01:53,713
‫ainsi que le terme malade reçu.

41
00:01:56,200 --> 00:02:00,520
‫Arrêt gracieusement.

42
00:02:00,520 --> 00:02:02,820
‫Et ajoutons quelques emoji ici juste

43
00:02:02,820 --> 00:02:05,400
‫pour le faire ressortir dans notre console parmi

44
00:02:05,400 --> 00:02:07,823
‫tous ces journaux que nous avons là-bas.

45
00:02:09,580 --> 00:02:11,980
‫Très bien, et

46
00:02:11,980 --> 00:02:14,700
‫maintenant faisons l'arrêt gracieux, qui consiste

47
00:02:14,700 --> 00:02:17,173
‫essentiellement à fermer le serveur.

48
00:02:21,650 --> 00:02:25,270
‫Cela fermera donc essentiellement le serveur, mais avant cela,

49
00:02:25,270 --> 00:02:27,150
‫traitera toujours toutes les demandes

50
00:02:27,150 --> 00:02:29,300
‫en attente. Et c'est

51
00:02:29,300 --> 00:02:31,800
‫exactement ce que nous voulons, au

52
00:02:31,800 --> 00:02:35,820
‫lieu d'une fin très abrupte de l'application, n'est-ce pas ?

53
00:02:35,820 --> 00:02:38,310
‫Ensuite, une fois cela fait, verrouillons-le sur

54
00:02:38,310 --> 00:02:39,193
‫la console.

55
00:02:40,810 --> 00:02:42,133
‫Donc, journal des

56
00:02:43,580 --> 00:02:46,010
‫points de la console, ajoutons encore

57
00:02:47,260 --> 00:02:50,063
‫une fois un joli emoji ici, processus terminé.

58
00:02:50,950 --> 00:02:53,740
‫D'accord. Et dans ce cas

59
00:02:53,740 --> 00:02:56,654
‫ici, nous n'utilisons pas la sortie du point de

60
00:02:56,654 --> 00:02:59,940
‫processus, car le terme malade lui-même entraînera la fermeture de l'application.

61
00:02:59,940 --> 00:03:01,970
‫Nous n'avons pas besoin de le faire manuellement

62
00:03:01,970 --> 00:03:05,100
‫comme nous l'avons fait ici. Très bien?

63
00:03:05,100 --> 00:03:07,990
‫Donc, fondamentalement, le terme malade est un signal qui

64
00:03:07,990 --> 00:03:09,720
‫est utilisé pour provoquer l'arrêt

65
00:03:09,720 --> 00:03:12,430
‫complet d'un programme. C'est donc une manière

66
00:03:12,430 --> 00:03:17,430
‫très polie de demander à un programme de se terminer. D'accord?

67
00:03:17,900 --> 00:03:21,510
‫Encore une fois, nous devons implémenter cette écoute de

68
00:03:21,510 --> 00:03:23,560
‫cet événement ici, car Heroku

69
00:03:23,560 --> 00:03:25,530
‫toutes les 24 heures

70
00:03:25,530 --> 00:03:28,140
‫fermera notre application en envoyant ce signal,

71
00:03:28,140 --> 00:03:30,470
‫ou cet événement, à notre application.

72
00:03:30,470 --> 00:03:32,720
‫Et puis, nous arrêtons le processus avec élégance,

73
00:03:32,720 --> 00:03:34,882
‫en utilisant server dot close, ce qui

74
00:03:34,882 --> 00:03:37,760
‫permet à toutes les demandes en attente de continuer à

75
00:03:37,760 --> 00:03:41,090
‫être traitées jusqu'à la fin. D'accord?

76
00:03:41,090 --> 00:03:43,390
‫Alors, testons cela maintenant.

77
00:03:43,390 --> 00:03:45,190
‫Et donc ce que nous devons

78
00:03:45,190 --> 00:03:47,890
‫faire en premier est bien sûr de valider toutes

79
00:03:47,890 --> 00:03:50,000
‫ces modifications dans notre référentiel git et

80
00:03:50,000 --> 00:03:51,690
‫vous voyez qu'en ce

81
00:03:51,690 --> 00:03:53,670
‫moment nous avons trois fichiers modifiés.

82
00:03:53,670 --> 00:03:56,530
‫Nous avons donc modifié le serveur dans cette conférence

83
00:03:56,530 --> 00:03:59,340
‫et le contrôleur alt dans l'application point JS

84
00:03:59,340 --> 00:04:01,923
‫dans la dernière. À droite?

85
00:04:02,980 --> 00:04:06,050
‫Alors, ajoutons-les tous à la zone de transit

86
00:04:06,050 --> 00:04:08,850
‫git add all, puis validons réellement ces

87
00:04:09,860 --> 00:04:12,163
‫modifications dans notre référentiel.

88
00:04:14,600 --> 00:04:19,390
‫Alors éditez, Heroku, config.

89
00:04:19,390 --> 00:04:20,683
‫Appelons-le simplement ainsi.

90
00:04:21,800 --> 00:04:24,240
‫Très bien. Et maintenant,

91
00:04:24,240 --> 00:04:26,890
‫rappelez-vous comment nous redéployons fondamentalement l'application.

92
00:04:26,890 --> 00:04:28,980
‫Eh bien, c'est très facile.

93
00:04:28,980 --> 00:04:33,133
‫Branche principale de l'addendum Git push Heroku.

94
00:04:34,730 --> 00:04:37,260
‫D'accord, cela enverra maintenant

95
00:04:37,260 --> 00:04:40,300
‫essentiellement toutes les modifications à cette

96
00:04:40,300 --> 00:04:42,830
‫branche et reconstruira ensuite

97
00:04:42,830 --> 00:04:47,170
‫l'application sur Heroku et, bien sûr, la relancera également.

98
00:04:47,170 --> 00:04:49,350
‫Vous voyez donc qu'il effectue tout

99
00:04:49,350 --> 00:04:51,900
‫ce processus qu'il a effectué lorsque nous avons

100
00:04:51,900 --> 00:04:54,490
‫déployé l'application pour la première fois à chaque

101
00:04:54,490 --> 00:04:57,120
‫fois que nous déployons l'application une autre fois.

102
00:04:57,120 --> 00:05:00,712
‫Et maintenant c'est fait. Et donc, afin de tester

103
00:05:00,712 --> 00:05:04,070
‫ce que nous venons de faire ici, redémarrons en gros

104
00:05:04,070 --> 00:05:06,390
‫manuellement l'application. Et donc

105
00:05:06,390 --> 00:05:08,663
‫cela enverra également le terme malade

106
00:05:08,663 --> 00:05:12,320
‫à l'application et devrait déclencher tout ce qui se passe

107
00:05:12,320 --> 00:05:14,980
‫ici. D'accord ? Commençons donc par

108
00:05:14,980 --> 00:05:18,520
‫jeter un œil à tous nos dynos, c'est donc quelque chose

109
00:05:18,520 --> 00:05:21,510
‫que nous n'avons pas encore fait, c'est donc Heroku PS

110
00:05:23,340 --> 00:05:25,220
‫et donc vous voyez que nous

111
00:05:25,220 --> 00:05:30,010
‫avons ici ce seul dyno web gratuit. D'accord?

112
00:05:30,010 --> 00:05:32,560
‫Qui s'exécute, ou fondamentalement, qui commence

113
00:05:32,560 --> 00:05:35,390
‫en utilisant la commande de démarrage MPM, comme

114
00:05:35,390 --> 00:05:38,300
‫je l'ai mentionné dans l'une des vidéos précédentes.

115
00:05:38,300 --> 00:05:41,530
‫Bon, maintenant ce que nous pouvons

116
00:05:41,530 --> 00:05:46,530
‫faire pour redémarrer, c'est très simplement Heroku PS et redémarrer.

117
00:05:49,890 --> 00:05:52,850
‫Donc ce n'était pas correct je pense.

118
00:05:52,850 --> 00:05:56,340
‫Maintenant, ça devrait l'être, et c'est fait.

119
00:05:56,340 --> 00:05:59,360
‫Alors, jetons maintenant un œil

120
00:05:59,360 --> 00:06:04,150
‫aux journaux qui sont Heroku logs dash dash tail.

121
00:06:06,940 --> 00:06:10,410
‫Très bien, donc et

122
00:06:10,410 --> 00:06:11,420
‫voilà.

123
00:06:11,420 --> 00:06:15,260
‫En venant de notre application, nous voyons le terme de maladie

124
00:06:15,260 --> 00:06:17,533
‫reçu, puis traitons les verrous terminés.

125
00:06:18,370 --> 00:06:19,940
‫Très bien, et vous voyez

126
00:06:19,940 --> 00:06:22,170
‫qu'après cela, démarrez le processus avec la

127
00:06:22,170 --> 00:06:23,723
‫commande NPM start.

128
00:06:24,980 --> 00:06:27,250
‫Très bien, et c'est donc le

129
00:06:27,250 --> 00:06:30,020
‫serveur de note point JS comme nous l'avons

130
00:06:30,020 --> 00:06:34,120
‫spécifié, et maintenant l'application s'exécute sur le port 57 deux six sept.

131
00:06:34,120 --> 00:06:36,310
‫Et rappelez-vous comment j'ai dit plus tôt qu'en

132
00:06:36,310 --> 00:06:37,650
‫gros Heroku exécute son

133
00:06:37,650 --> 00:06:40,930
‫application sur un port aléatoire. Et donc celui-ci est

134
00:06:40,930 --> 00:06:43,790
‫cela. Très bien? Super!

135
00:06:43,790 --> 00:06:46,850
‫Alors sortons de ça, nettoyons ça, et

136
00:06:46,850 --> 00:06:49,040
‫avec ça, nous terminons en

137
00:06:49,040 --> 00:06:52,720
‫fait tous les trucs de configuration Heroku dans notre application.

138
00:06:52,720 --> 00:06:56,140
‫Fantastique. Maintenant, il ne reste plus

139
00:06:56,140 --> 00:06:57,890
‫que deux choses à faire,

140
00:06:57,890 --> 00:07:01,129
‫à savoir implémenter quelque chose appelé CORS, ou Cross

141
00:07:01,129 --> 00:07:04,330
‫Origin Resource Sharing, puis terminer les paiements Stripe à

142
00:07:04,330 --> 00:07:07,470
‫l'aide de webhooks. Alors rappelez-vous comment j'ai promis

143
00:07:07,470 --> 00:07:09,890
‫de mettre en œuvre celui-ci un peu plus tard,

144
00:07:09,890 --> 00:07:12,990
‫et nous le ferons donc au cours des deux prochaines conférences.

145
00:07:12,990 --> 00:07:16,073
‫Très bien? Alors à bientôt dans une seconde.

