1
00:00:01,110 --> 00:00:02,860
‫-: In diesem Video

2
00:00:02,860 --> 00:00:05,780
‫werden wir eine letzte Heroku-spezifische Konfiguration vornehmen,

3
00:00:05,780 --> 00:00:08,047
‫die auf ein sogenanntes "Krankheitssignal"

4
00:00:08,047 --> 00:00:10,770
‫reagieren soll, das Heroku von Zeit zu

5
00:00:10,770 --> 00:00:12,023
‫Zeit aussendet.

6
00:00:13,670 --> 00:00:16,300
‫Ein Heroku-Dyno, und wieder ein Dyno, ist

7
00:00:16,300 --> 00:00:19,460
‫nur ein Name, den Heroku im Grunde für

8
00:00:19,460 --> 00:00:21,540
‫einen Container verwendet, in dem

9
00:00:21,540 --> 00:00:23,230
‫Ihre Anwendung ausgeführt wird,

10
00:00:23,230 --> 00:00:26,820
‫sodass diese Dynos alle 24 Stunden neu gestartet werden, um

11
00:00:26,820 --> 00:00:29,930
‫Ihre App in einem fehlerfreien Zustand zu halten.

12
00:00:29,930 --> 00:00:32,930
‫Okay? Und Heroku

13
00:00:32,930 --> 00:00:36,060
‫macht dies, indem es das sogenannte "Krankheitssignal"

14
00:00:36,060 --> 00:00:38,577
‫an unsere Notizanwendung sendet, und die

15
00:00:38,577 --> 00:00:41,640
‫Anwendung wird dann im Grunde sofort heruntergefahren.

16
00:00:41,640 --> 00:00:44,680
‫Gut? Das Problem dabei ist,

17
00:00:44,680 --> 00:00:46,830
‫dass das Herunterfahren sehr abrupt erfolgen kann.

18
00:00:46,830 --> 00:00:50,020
‫Das kann dann Anfragen, die gerade bearbeitet

19
00:00:50,020 --> 00:00:51,930
‫werden, quasi in der

20
00:00:51,930 --> 00:00:53,730
‫Luft hängen lassen,

21
00:00:53,730 --> 00:00:55,789
‫und das ist nicht optimal.

22
00:00:55,789 --> 00:00:58,830
‫Das passiert im Grunde auch, wenn

23
00:00:58,830 --> 00:01:01,623
‫es eine unbehandelte Ablehnung gibt.

24
00:01:02,850 --> 00:01:05,024
‫Erinnern Sie sich also hier in unserem

25
00:01:05,024 --> 00:01:07,320
‫Server, dot JS, daran, wie wir den

26
00:01:07,320 --> 00:01:09,700
‫Server tatsächlich ordnungsgemäß heruntergefahren haben, wenn es eine

27
00:01:09,700 --> 00:01:12,690
‫nicht behandelte Ablehnung gab. Gut?

28
00:01:12,690 --> 00:01:13,990
‫Also werden wir

29
00:01:13,990 --> 00:01:16,240
‫jetzt etwas ganz Ähnliches machen, wenn

30
00:01:16,240 --> 00:01:20,310
‫wir das "Krankheitssignal" erhalten. Gut? Sagen wir also

31
00:01:22,410 --> 00:01:23,690
‫Prozesspunkt bei

32
00:01:26,870 --> 00:01:29,660
‫Krankheit, und im Grunde ist die Krankheit

33
00:01:29,660 --> 00:01:32,300
‫im Grunde nur ein Ereignis, das gesendet

34
00:01:32,300 --> 00:01:35,160
‫werden kann und das unsere Anwendung empfängt

35
00:01:35,160 --> 00:01:36,700
‫und darauf reagieren kann.

36
00:01:36,700 --> 00:01:40,383
‫Also genau wie die unbehandelte Ablehnung. Rechts?

37
00:01:41,430 --> 00:01:43,293
‫Jetzt haben wir hier keinen Fehler,

38
00:01:46,210 --> 00:01:47,760
‫und lassen Sie uns

39
00:01:48,720 --> 00:01:50,250
‫hier tatsächlich ein

40
00:01:52,130 --> 00:01:53,713
‫Konsolenprotokoll erstellen, sowie Krankschreibung erhalten.

41
00:01:56,200 --> 00:02:00,520
‫Anmutig herunterfahren.

42
00:02:00,520 --> 00:02:02,820
‫Und fügen wir hier einige Emojis

43
00:02:02,820 --> 00:02:05,400
‫hinzu, um sie in unserer Konsole unter all

44
00:02:05,400 --> 00:02:07,823
‫diesen Protokollen hervorzuheben, die wir dort haben.

45
00:02:09,580 --> 00:02:11,980
‫In Ordnung, und jetzt machen

46
00:02:11,980 --> 00:02:14,700
‫wir das ordnungsgemäße Herunterfahren, das im Grunde

47
00:02:14,700 --> 00:02:17,173
‫nur dazu dient, den Server zu schließen.

48
00:02:21,650 --> 00:02:25,270
‫Dadurch wird der Server im Grunde geschlossen, aber davor

49
00:02:25,270 --> 00:02:27,150
‫werden noch alle ausstehenden

50
00:02:27,150 --> 00:02:29,300
‫Anfragen bearbeitet. Und

51
00:02:29,300 --> 00:02:31,800
‫genau das wollen wir, anstatt

52
00:02:31,800 --> 00:02:35,820
‫eine ganz abrupte Beendigung der Bewerbung, oder?

53
00:02:35,820 --> 00:02:38,310
‫Wenn das erledigt ist, sperren wir das an

54
00:02:38,310 --> 00:02:39,193
‫die Konsole.

55
00:02:40,810 --> 00:02:42,133
‫Also Konsolen-Punkteprotokoll,

56
00:02:43,580 --> 00:02:46,010
‫fügen wir wieder ein

57
00:02:47,260 --> 00:02:50,063
‫nettes Emoji hier hinzu Prozess beendet.

58
00:02:50,950 --> 00:02:53,740
‫Okay. Und in diesem Fall

59
00:02:53,740 --> 00:02:56,654
‫verwenden wir hier nicht den Prozess dot exit, da

60
00:02:56,654 --> 00:02:59,940
‫der Krankheitstermin selbst dazu führt, dass die Anwendung geschlossen wird.

61
00:02:59,940 --> 00:03:01,970
‫Wir müssen es nicht manuell tun, wie wir

62
00:03:01,970 --> 00:03:05,100
‫es hier oben getan haben. Gut?

63
00:03:05,100 --> 00:03:07,990
‫Im Grunde ist Krankschreibung ein Signal, das verwendet wird, um

64
00:03:07,990 --> 00:03:09,720
‫zu bewirken, dass ein Programm wirklich

65
00:03:09,720 --> 00:03:12,430
‫nicht mehr läuft. Es ist also eine

66
00:03:12,430 --> 00:03:17,430
‫sehr höfliche Art, ein Programm zum Beenden aufzufordern. Okay?

67
00:03:17,900 --> 00:03:21,510
‫Auch hier müssen wir dieses Abhören dieses Ereignisses hier

68
00:03:21,510 --> 00:03:23,560
‫implementieren, da Heroku alle 24

69
00:03:23,560 --> 00:03:25,530
‫Stunden unsere Anwendung

70
00:03:25,530 --> 00:03:28,140
‫herunterfährt, indem es dieses Signal oder

71
00:03:28,140 --> 00:03:30,470
‫dieses Ereignis an unsere Anwendung sendet.

72
00:03:30,470 --> 00:03:32,720
‫Und so beenden wir den Prozess

73
00:03:32,720 --> 00:03:34,882
‫ordnungsgemäß, indem wir server dot close

74
00:03:34,882 --> 00:03:37,760
‫verwenden, wodurch alle ausstehenden Anfragen bis zum Ende

75
00:03:37,760 --> 00:03:41,090
‫verarbeitet werden können. Okay?

76
00:03:41,090 --> 00:03:43,390
‫Also, lassen Sie uns das jetzt tatsächlich testen.

77
00:03:43,390 --> 00:03:45,190
‫Was wir also zuerst tun

78
00:03:45,190 --> 00:03:47,890
‫müssen, ist natürlich alle diese Änderungen in unser

79
00:03:47,890 --> 00:03:50,000
‫Git-Repository zu übertragen und Sie sehen,

80
00:03:50,000 --> 00:03:51,690
‫dass wir im

81
00:03:51,690 --> 00:03:53,670
‫Moment drei geänderte Dateien haben.

82
00:03:53,670 --> 00:03:56,530
‫Also haben wir in dieser Vorlesung den Server

83
00:03:56,530 --> 00:03:59,340
‫und in der letzten den Alt-Controller in App

84
00:03:59,340 --> 00:04:01,923
‫dot JS modifiziert. Rechts?

85
00:04:02,980 --> 00:04:06,050
‫Also, fügen wir sie alle zum Staging-Bereich git

86
00:04:06,050 --> 00:04:08,850
‫add all hinzu und übertragen diese Änderungen

87
00:04:09,860 --> 00:04:12,163
‫dann wirklich in unser Repository.

88
00:04:14,600 --> 00:04:19,390
‫Also edit, Heroku, config.

89
00:04:19,390 --> 00:04:20,683
‫Nennen wir es einfach so.

90
00:04:21,800 --> 00:04:24,240
‫Gut. Und jetzt denken Sie

91
00:04:24,240 --> 00:04:26,890
‫daran, wie wir die Anwendung im Grunde neu bereitstellen.

92
00:04:26,890 --> 00:04:28,980
‫Nun, das ist ganz einfach.

93
00:04:28,980 --> 00:04:33,133
‫Git push Heroku Addendum Master Branch.

94
00:04:34,730 --> 00:04:37,260
‫Okay, das schickt nun im

95
00:04:37,260 --> 00:04:40,300
‫Grunde alle Änderungen an diesen Branch und

96
00:04:40,300 --> 00:04:42,830
‫baut dann die Anwendung

97
00:04:42,830 --> 00:04:47,170
‫auf Heroku neu auf und startet sie natürlich auch neu.

98
00:04:47,170 --> 00:04:49,350
‫Sie sehen also, dass es

99
00:04:49,350 --> 00:04:51,900
‫all diesen Prozess wie bei der ersten

100
00:04:51,900 --> 00:04:54,490
‫Bereitstellung der Anwendung jedes Mal neu durchführt,

101
00:04:54,490 --> 00:04:57,120
‫wenn wir die Anwendung ein weiteres Mal bereitstellen.

102
00:04:57,120 --> 00:05:00,712
‫Und jetzt ist das erledigt. Um zu testen, was wir

103
00:05:00,712 --> 00:05:04,070
‫gerade hier gemacht haben, starten wir die Anwendung im Grunde

104
00:05:04,070 --> 00:05:06,390
‫manuell neu. Und damit

105
00:05:06,390 --> 00:05:08,663
‫wird dann auch das Krankschreiben an

106
00:05:08,663 --> 00:05:12,320
‫die App gesendet und sollte auslösen was auch immer

107
00:05:12,320 --> 00:05:14,980
‫hier passiert Okay? Beginnen wir also

108
00:05:14,980 --> 00:05:18,520
‫mit einem Blick auf all unsere Prüfstände, das haben wir

109
00:05:18,520 --> 00:05:21,510
‫noch nicht gemacht, das ist Heroku PS und

110
00:05:23,340 --> 00:05:25,220
‫ihr seht also, dass wir

111
00:05:25,220 --> 00:05:30,010
‫hier diesen einen kostenlosen Web-Prüfstand haben. Okay?

112
00:05:30,010 --> 00:05:32,560
‫Was läuft, oder im Grunde,

113
00:05:32,560 --> 00:05:35,390
‫was mit dem MPM-Startbefehl startet, wie ich

114
00:05:35,390 --> 00:05:38,300
‫in einem der vorherigen Videos erwähnt habe.

115
00:05:38,300 --> 00:05:41,530
‫Okay, was wir jetzt tun können,

116
00:05:41,530 --> 00:05:46,530
‫um neu zu starten, ist ganz einfach Heroku PS und Neustart.

117
00:05:49,890 --> 00:05:52,850
‫Also war es meiner Meinung nach nicht richtig.

118
00:05:52,850 --> 00:05:56,340
‫Jetzt sollte es sein, und das ist getan.

119
00:05:56,340 --> 00:05:59,360
‫Werfen wir nun einen Blick auf

120
00:05:59,360 --> 00:06:04,150
‫die Protokolle, bei denen es sich um Heroku-Protokolle Dash Dash Tail handelt.

121
00:06:06,940 --> 00:06:10,410
‫Alles klar, und hier ist

122
00:06:10,410 --> 00:06:11,420
‫es.

123
00:06:11,420 --> 00:06:15,260
‫Von unserer App kommend sehen wir die erhaltene Krankschreibung

124
00:06:15,260 --> 00:06:17,533
‫und verarbeiten dann beendete Sperren.

125
00:06:18,370 --> 00:06:19,940
‫Alles klar, und Sie sehen,

126
00:06:19,940 --> 00:06:22,170
‫dass danach der Prozess mit dem Befehl

127
00:06:22,170 --> 00:06:23,723
‫NPM start gestartet wird.

128
00:06:24,980 --> 00:06:27,250
‫In Ordnung, und das ist

129
00:06:27,250 --> 00:06:30,020
‫Serverpunkt JS, genau wie wir es angegeben haben,

130
00:06:30,020 --> 00:06:34,120
‫und jetzt läuft die App auf Port 57 zwei sechs sieben.

131
00:06:34,120 --> 00:06:36,310
‫Denken Sie also daran, wie ich vorhin gesagt habe,

132
00:06:36,310 --> 00:06:37,650
‫dass Heroku seine App

133
00:06:37,650 --> 00:06:40,930
‫im Grunde auf einem zufälligen Port ausführt. Und so ist das

134
00:06:40,930 --> 00:06:43,790
‫hier. Gut? Groß!

135
00:06:43,790 --> 00:06:46,850
‫Beenden wir das, bereinigen wir dies,

136
00:06:46,850 --> 00:06:49,040
‫und damit packen

137
00:06:49,040 --> 00:06:52,720
‫wir tatsächlich alle Heroku-Konfigurationssachen in unsere Anwendung ein.

138
00:06:52,720 --> 00:06:56,140
‫Fantastisch. Jetzt bleiben nur noch

139
00:06:56,140 --> 00:06:57,890
‫zwei Dinge übrig, nämlich

140
00:06:57,890 --> 00:07:01,129
‫etwas namens CORS oder Cross Origin Resource Sharing

141
00:07:01,129 --> 00:07:04,330
‫zu implementieren und dann auch die Stripe-Zahlungen mit

142
00:07:04,330 --> 00:07:07,470
‫Webhooks abzuschließen. Denken Sie also daran,

143
00:07:07,470 --> 00:07:09,890
‫wie ich versprochen habe, das etwas später umzusetzen,

144
00:07:09,890 --> 00:07:12,990
‫und das werden wir in den nächsten beiden Vorlesungen tun.

145
00:07:12,990 --> 00:07:16,073
‫Gut? Also bis dann in einer Sekunde.