WEBVTT

00:00:00.000 --> 00:00:03.880
ברוכים הבאים לפרק נוסף של פמיני ידע של מייקרוסופט, כאן ב-M365FM.

00:00:04.000 --> 00:00:05.700
אני המנחה שלכם, מרקו פיטרז.

00:00:05.820 --> 00:00:08.300
אתם פורסים משאבי Azure באמצעות לחיצות בפורטל.

00:00:08.440 --> 00:00:10.280
זה עובד מצוין, עד שזה מפסיק לעבוד.

00:00:10.400 --> 00:00:13.060
אז צריך לעשות זאת שוב, אבל אתם לא זוכרים בדיוק מה בחרתם.

00:00:13.160 --> 00:00:16.100
אתם צריכים להעביר את זה לחבר צוות, והוא לא מצליח לעקוב אחרי הצעדים שלכם.

00:00:16.240 --> 00:00:18.500
בקרת גרסאות, אין מה לבצע לו, קומיט.

00:00:18.680 --> 00:00:20.500
זו הבעיה שאנחנו הולכים לפתור היום.

00:00:20.500 --> 00:00:27.440
בסוף הפרק הזה, תבינו מה זה תשתית כקוד, ISC, למה בייספ קיים, ואיך הוא הופך פריסות ב-Azure לפשוטות ואמינות יותר.

00:00:27.620 --> 00:00:31.620
נתחיל בבעיה, אחר כך בפתרון, ולבסוף בדוגמה מעשית שתוכלו לעקוב אחריה.

00:00:31.740 --> 00:00:33.920
קחו את הקפה שלכם ובואו נצלול פנימה.

00:00:34.080 --> 00:00:37.380
בעיית הפורטל, מלכודת הלחיצה על הפריסה, מרגישה מהירה.

00:00:37.500 --> 00:00:40.420
אתם נכנסים, ממלאים תופס, לוחצים על יצירה, וסיימתם.

00:00:40.420 --> 00:00:44.140
אבל מה קורה כשצריך לעשות זאת שוב עם אותן הגדרות, אזור ומוסכמות שמות?

00:00:44.200 --> 00:00:47.940
אתם חייבים לזכור כל דבר שבחרתם, ושם דברים מתחילים להשתבש.

00:00:48.060 --> 00:00:52.560
פריסה ידנית פירושה תוצאות לא עקביות, טעויות אנוש וחוסר בתיעוד ביקורת.

00:00:52.660 --> 00:00:54.140
הנה דוגמה מהעולם האמיתי.

00:00:54.320 --> 00:00:57.400
מי שהוא בצוות שלכם יוצר משאב עם הגדרות שונות במקצת.

00:00:57.560 --> 00:00:59.540
עכשיו יש לכם שתי סביבות שלא תואמות.

00:00:59.720 --> 00:01:02.840
אחת עובדת, השנייה לא, ובהצלחה בניסיון להבין למה.

00:01:02.840 --> 00:01:04.520
ואז יש את בעיית התיעוד.

00:01:04.620 --> 00:01:10.500
תשתית כמסמך וורד, או גרוע מכך, סרטון יוטיוב שהוקלט לפני שישה חודשים כשהפורטל נראה אחרת לגמרי.

00:01:10.640 --> 00:01:13.540
תכונות זזות, תפריטים משתנים, אפשרויות חדשות מופיעות.

00:01:13.660 --> 00:01:18.000
ישבתי עם מנהל מוצר מצוות הפורטל של Azure, והוא אמר שהם משחררים תכונות חדשות פעמיים ביום.

00:01:18.140 --> 00:01:18.940
פעמיים ביום.

00:01:19.140 --> 00:01:21.700
מסמך הוורד שלכם מיושן עוד לפני שסיימתם לכתוב אותו.

00:01:21.820 --> 00:01:22.520
הנה העניין.

00:01:22.700 --> 00:01:24.220
לחיצות עובדות מצוין ללמידה.

00:01:24.220 --> 00:01:25.660
זה נכשל בסביבת ייצור.

00:01:25.800 --> 00:01:26.640
אז מה החלופה?

00:01:26.760 --> 00:01:30.560
אתם כותבים קובץ שמתאר מה אתם רוצים, ואז אומרים לאז'ר לבנות אותו.

00:01:30.720 --> 00:01:31.820
מה זה תשתית כקוד?

00:01:31.940 --> 00:01:36.840
תשתית כקוד פירושה ניהול הגדרות הענן שלכם באמצעות קוד במקום לחיצות בפורטל אינטרנט.

00:01:37.020 --> 00:01:38.260
הנה הרעיון המרכזי.

00:01:38.400 --> 00:01:40.540
אתם כותבים קובץ שמתאר את התשתית שלכם.

00:01:40.540 --> 00:01:47.700
הקובץ הזה נמצא במאגר שלכם, ואתם יכולים לבצע לו בקרת גרסאות, לבדוק אותו בפול רכווסט, ולהריץ אותו שוב מחר כדי לקבל את אותה תוצאה.

00:01:47.820 --> 00:01:50.300
יש כאן מונח מפתח, דקלרטיבי, הצהרתי.

00:01:50.460 --> 00:01:53.160
זה אומר שאתם מתארים מה אתם רוצים, לא איך לבנות את זה.

00:01:53.300 --> 00:01:58.240
אתם לא אומרים לאז'ר קודם ליצור קבוצת משאבים, אחר כך להוסיף חשבון נחסון, ואז להגדיר רשת.

00:01:58.400 --> 00:02:02.520
במקום זאת, אתם אומרים, אני רוצה קבוצת משאבים עם חשבון נחסון ורשת המוגדרים כך.

00:02:10.540 --> 00:02:12.480
זה כמו על תוכנית בנייה לעומת בנייה ידנית.

00:02:12.580 --> 00:02:15.020
תוכנית היא ניתנת לשחזור, לשיתוף ולביקורת.

00:02:15.160 --> 00:02:17.720
תנו אותה למי שהוא אחר, והוא יבנה בדיוק את אותו הדבר.

00:02:17.880 --> 00:02:19.360
כיום, כמה כלים עושים זאת?

00:02:19.540 --> 00:02:22.020
תבניות ARM, בייספ, טרפורם, פולומי.

00:02:22.140 --> 00:02:24.420
כולם מיישמים את אותו קונספט בדרכים שונות.

00:02:24.520 --> 00:02:25.480
זו הבחנה חשובה.

00:02:25.600 --> 00:02:27.640
תשתית כקוד, IAC, היא הקונספט.

00:02:27.800 --> 00:02:29.620
בייספ הוא רק כלי אחד שמיישם אותו.

00:02:29.620 --> 00:02:30.720
אבל הנה העניין.

00:02:30.880 --> 00:02:33.680
לאז'ר יש שפת IAC כבר שנים בשם תבניות ARM.

00:02:33.860 --> 00:02:36.200
ויש סיבה לכך שמייקרוסופט בנתה אחת חדשה.

00:02:36.340 --> 00:02:37.460
בעיית תבניות ה-ARM.

00:02:37.600 --> 00:02:40.180
תבניות ARM הן פורמט העיק המקורי של Azure.

00:02:40.380 --> 00:02:42.880
אלו קבצי JSON, ויש להם יתרונות רבים.

00:02:43.060 --> 00:02:44.960
כיסוי מלא של כל משאב באז'ר,

00:02:45.220 --> 00:02:47.600
ואותו מנוע פריסה שבו היא משתמשת פנימית.

00:02:47.800 --> 00:02:51.280
אם אפשר ליצור משהו בפורטל, אפשר להגדיר אותו בתבנית ARM.

00:02:51.460 --> 00:02:52.200
אז מה הבעיה?

00:02:52.200 --> 00:02:54.880
JSON מצוין למכונות, אבל נורא לבני אדם.

00:02:55.000 --> 00:02:56.660
הרשו לי להראות לכם למה אני מתכוון.

00:02:56.820 --> 00:02:59.580
חשבון יחסון בתבנית ARM דורש כף מינוס 20 שורות קוד.

00:02:59.720 --> 00:03:02.220
אותו חשבון יחסון בביספ דורש כף מינוס 10 שורות.

00:03:02.400 --> 00:03:05.760
גרסת ה-JSON גדולה בערך פי 2, וזה רק משאב פשוט.

00:03:05.960 --> 00:03:10.200
דמיינו פריסה מלאה עם רשתות, מחשוב, מסדי נתונים וכללי הבטחה.

00:03:10.300 --> 00:03:12.480
תבנית ה-ARM הופכת לקיר של טקסט.

00:03:12.620 --> 00:03:14.720
נקודות התורפה הנפוצות צפויות מראש.

00:03:14.720 --> 00:03:16.720
סיכים חסרים, סוגריים לא תואמים,

00:03:16.900 --> 00:03:20.400
כינון מפורט מדי שמקשה להבין איפה משאב אחד נגמר והשני מתחיל.

00:03:20.520 --> 00:03:24.640
אתם מבלים יותר זמן בהיאבקות עם תחביר JSON מאשר בהגדרת התשתית שלכם.

00:03:24.780 --> 00:03:25.960
ואז ישנן התלויות.

00:03:26.160 --> 00:03:29.020
בארם, עליכם להצהיר ידנית על תלויות Depends On.

00:03:29.200 --> 00:03:33.300
אם ישב א', זקוק למשאב בית כדי שיהיה קיים קודם, עליכם לכתוב זאת במפורש.

00:03:33.440 --> 00:03:35.680
פספסתם אחד, והפריסה שלכם נכשלת.

00:03:35.800 --> 00:03:37.760
בהצלחה בלהבין איזה מהם פספסתם.

00:03:37.760 --> 00:03:41.500
אם ניסיתם אי פעם לכתוב קובץ JSON של 200 שורות ביד, זה לא כיף.

00:03:41.620 --> 00:03:42.440
אפילו לא קצת.

00:03:42.580 --> 00:03:43.820
עקומת הלמידה תלולה.

00:03:43.820 --> 00:03:46.560
חברי צוות חדשים מתקשים להבין תבניות ARM.

00:03:46.760 --> 00:03:47.960
חסם הכניסה גבוה.

00:03:48.120 --> 00:03:49.180
ומה קורה בפועל?

00:03:49.280 --> 00:03:52.260
צוותים רבים מסתיימים עם אדם אחד שמכיר את תבנית הארם.

00:03:52.420 --> 00:03:54.460
אותו אדם הופך לנקודת קשל יחידה.

00:03:54.580 --> 00:03:58.760
הם היחידים שיכולים לשנות את הפריסה והיחידים שיכולים לנפות שגיאות כשמשהו משתבש.

00:03:58.920 --> 00:03:59.780
זה לא בר קיימה.

00:03:59.780 --> 00:04:04.240
מייקרוסופט שמעה את המשוב, אז היא בנתה את בייספ כדי לפתור בדיוק את הבעיות האלה.

00:04:04.340 --> 00:04:05.200
מה זה בייספ?

00:04:05.320 --> 00:04:06.760
אז מה זה בעצם בייספ?

00:04:06.760 --> 00:04:11.140
זו שפה שנועדה לפריסת משאבי Azure, וביסודה היא מהדר Transpire.

00:04:11.320 --> 00:04:14.000
אתם כותבים בבייספ וזה מתכמפל לג'סון של ARM.

00:04:14.200 --> 00:04:17.040
אותו מנוע מאחורי הקלעים, אבל דרך כתיבה הרבה יותר נקייה.

00:04:17.160 --> 00:04:19.480
והשם בייספ הוא למעשה ARM מאוית לאחור.

00:04:19.640 --> 00:04:20.040
בייספ.

00:04:20.180 --> 00:04:20.500
ARM.

00:04:20.740 --> 00:04:22.520
בדיחה פנימית קטנה של מייקרוסופט.

00:04:22.520 --> 00:04:24.560
אבל ברגע שרואים את זה בפעולה, זה הגיוני.

00:04:24.680 --> 00:04:26.780
בייספ יושב על גבי ARM במקום להחליף אותו.

00:04:26.900 --> 00:04:28.860
מקבלים את אותה עוצמה עם תחביר פשוט יותר.

00:04:28.860 --> 00:04:31.180
בייספ לא מחליף את ARM, הוא נבנה על גביו.

00:04:31.300 --> 00:04:33.740
כל מה שאפשר לעשות עם ARM, אפשר לעשות עם בייספ.

00:04:33.900 --> 00:04:37.240
כל סוג משאב, כל גרסת API, כל אפשרות קונפיגורציה הכל שם.

00:04:37.360 --> 00:04:39.060
ההבדל היחיד הוא איך שכותבים את זה.

00:04:39.220 --> 00:04:40.440
התחביר הרבה יותר נקי.

00:04:40.600 --> 00:04:44.000
בלי מרכאות סביב שמות מאפיינים, בלי פסיקים בין מאפיינים, בלי סוגריים למעקב.

00:04:44.140 --> 00:04:45.080
זה פשוט פשוט יותר.

00:04:45.080 --> 00:04:47.220
הישבו בין שתי הגרסאות זו לצד זו.

00:04:47.320 --> 00:04:50.120
גרסת הג'סון של ARM לחשבון יחסון מלאה ברעש.

00:04:50.120 --> 00:04:52.700
מרכאות, פסיקים, סוגריים, כינון.

00:04:52.900 --> 00:04:55.780
גרסת הבייספ מכילה את אותו מידע, אבל היא קריאה.

00:04:55.940 --> 00:05:01.060
אפשר להסתכל עליה ולהבין מיד מה היא עושה בלי לעבור דרך שכבות של תחביר ג'ייסן.

00:05:01.280 --> 00:05:03.980
שיפור אחד גדול הוא הסקה אוטומטית של תלויות.

00:05:04.200 --> 00:05:06.740
ב-ARM צריך להצהיר ידנית על דיפנזון.

00:05:06.740 --> 00:05:12.360
אבל בבייספ, אם משאב א' מפנה למשאב בית, המערכת מבינה את התלות באופן אוטומטי.

00:05:12.480 --> 00:05:13.540
לא צריך לכתוב את זה.

00:05:13.720 --> 00:05:16.680
זה פשוט עובד, וזה לבדו חוסך שעות של ניפוי שגיאות.

00:05:16.860 --> 00:05:18.620
מודולים הם נדבך משמעותי נוסף.

00:05:18.760 --> 00:05:23.020
ניתן לפרק את התשתית לחלקים קטנים וניתנים לשימוש חוזר ולשתף אותם בין פרויקטים.

00:05:23.180 --> 00:05:26.080
צוות אחד בונה מודול, תקשורת וצוות אחר משתמש בו.

00:05:26.220 --> 00:05:28.440
אין צורך להמציא את הגלגל בכל פעם מחדש.

00:05:28.440 --> 00:05:32.460
פרמטרים ומשתנים מאפשרים להגדיר את הכלטים פעם אחת ולהשתמש בהם בכל מקום.

00:05:32.620 --> 00:05:35.400
סוף לחיפוש והחלפה של ערכים מקובעים, hardcoded.

00:05:35.400 --> 00:05:40.340
ואינטרפולציית מחרוזות אומרת שאפשר לכתוב קידום את איחסון במקום פונקציות שרשור מורכבות.

00:05:40.480 --> 00:05:43.420
הכלים הם סיבה נוספת לכך שכל כך נעים לעבוד עם בייספ.

00:05:43.580 --> 00:05:47.980
התוסף לבי אס קוד מעניק אינטליסנס, הדגשת תחביר ובדיקת שגיאות בזמן אמת.

00:05:48.120 --> 00:05:51.280
בחינות, זה אחד מתוספי השפה הטובים ביותר בווי אס קוד.

00:05:51.280 --> 00:05:53.720
מתחילים להקליד וזה מציע מה בא בהמשך.

00:05:53.820 --> 00:05:55.680
עושים טעות וזה מטריע עליה מיד.

00:05:55.680 --> 00:05:59.400
לא צריך לחכות שהפריסה תיקשל כדי לגלות ששכחת פסיק.

00:05:59.680 --> 00:06:01.080
אז איך זה נראה בפועל?

00:06:01.260 --> 00:06:03.380
בואו נראה במה בייספ שונה מ-ARM.

00:06:03.540 --> 00:06:05.720
בייספ מול ARM, מה בעצם ההבדל?

00:06:05.900 --> 00:06:09.500
בואו נדבר על מה באמת שונה כשכותבים בבייספ במקום ב-ARM.json.

00:06:09.720 --> 00:06:11.700
גודל הקובץ הוא הבדל מובן מאליו.

00:06:11.700 --> 00:06:15.540
קבצי בייספ הם בערך חצי מהגודל של תבניות ARM מקבילות.

00:06:15.720 --> 00:06:16.380
זו לא הגזמה.

00:06:16.520 --> 00:06:19.760
אתם מסירים את כל המרכאות, הפסיקים, הסוגריים והטקסט המיותר,

00:06:19.940 --> 00:06:21.380
ומה שנשאר זה רק הגדרת התשתית.

00:06:21.480 --> 00:06:23.140
חצי מכמות הקוד, אותה תוצאה.

00:06:23.260 --> 00:06:24.900
קריאות נובעת מכך באופן טבעי.

00:06:25.020 --> 00:06:28.160
פחות שורות, מבנה נקי יותר, וקל יותר להבנה במבט חטוף.

00:06:28.320 --> 00:06:31.460
כשפותחים קובץ בייספ, אפשר לסרוק אותו ולהבין מה נפרס.

00:06:31.460 --> 00:06:36.040
עם ARM.json צריך לעבור דרך שכבות של כינון לפני שמוצאים את הגדרת המשאב בפועל.

00:06:36.120 --> 00:06:38.040
תלויות הן דרך מצוינת לחסוך זמן.

00:06:38.200 --> 00:06:40.440
בערם, אתם מצהירים ידנית על Depends On.

00:06:40.600 --> 00:06:42.720
פספסתם אחד, והפריסה שלכם תיקשל.

00:06:42.900 --> 00:06:46.880
בביספ, עם משאב א', מתייחס למשאב בית, המערכת מטפלת בזה אוטומטית.

00:06:47.060 --> 00:06:49.560
היא מוסיפה את התלות כשהיא עוברת הידור לערם.json.

00:06:49.720 --> 00:06:51.800
אתם לא צריכים לחשוב על זה, זה פשוט עובד.

00:06:51.920 --> 00:06:53.880
וזה לבדו חוסך שעות של איתור בגים.

00:06:53.880 --> 00:06:55.700
מודולים הם הבדל מרכזי נוסף.

00:06:55.820 --> 00:06:58.380
בערם היו תבניות מקוננות, אבל היה קשה לעבוד איתן.

00:06:58.500 --> 00:07:01.060
קבצים נפרדים, קישור מורכב, קשה לנהל גרסאות.

00:07:01.220 --> 00:07:05.060
בביספ יש מודולים שהם נקיים יותר, ניתנים לניהול גרסאות וניתנים לשימוש חוזר.

00:07:05.180 --> 00:07:09.160
מגדירים מודול פעם אחת, מפרסמים אותו לרישום ומתייחסים אליו מכל מקום.

00:07:09.320 --> 00:07:11.340
אותו מודול, אותה הגדרה בכל פעם.

00:07:11.520 --> 00:07:13.420
תהליך הפריסה עצמו זהה לחלוטין.

00:07:13.420 --> 00:07:16.920
בייספ עובר הידור לערם.json, ואז Azure Resource Manager פורס אותו.

00:07:17.040 --> 00:07:18.800
אותו מנוע, אותו צינור, פייפליין.

00:07:18.940 --> 00:07:22.660
אתם לא צריכים לשנות את תהליך הפריסה שלכם, רק את הדרך שבה אתם כותבים את התבניות.

00:07:22.840 --> 00:07:26.840
What If היא תכונה שקיימת טכנית בארם, אבל בייספ הופך אותה להרבה יותר נגישה.

00:07:26.980 --> 00:07:31.740
אפשר להציג תצוגה המקדימה של שינויים לפני הפריסה ולראות בדיוק מה ייווצר, ישונה או ימחק.

00:07:31.860 --> 00:07:33.560
בלי הפתעות, בלי מחיקות בטעות.

00:07:33.560 --> 00:07:36.960
מריצים את What If, בודקים את הפלט, ואם זה נראה נכון, פורסים.

00:07:37.080 --> 00:07:39.220
עקומת הלמידה היא תכום שבו בייספ בולט.

00:07:39.220 --> 00:07:41.480
ARM-JSON מניח שאתם יודעים מה אתם עושים.

00:07:41.600 --> 00:07:43.320
הוא מיועד למכונות, לא לבני אדם.

00:07:43.480 --> 00:07:44.780
בייספ מיועד למתחילים.

00:07:44.920 --> 00:07:46.960
תחביר אינטואיטיבי, כלי עבודה שמדריכים אתכם.

00:07:47.100 --> 00:07:49.900
אפשר ללמוד אותו אחר הצהריים ולהיות פרודוקטיביים עד סוף השבוע.

00:07:50.040 --> 00:07:52.620
מייקרוסופט הפכה את בייספ לחוויית הכתיבה המומלצת.

00:07:52.620 --> 00:07:55.380
כל התכונות והשיפורים החדשים מכוונים לבייספ קודם.

00:07:55.380 --> 00:07:57.840
תבניות ARM עדיין עובדות והן לא הולכות להיעלם,

00:07:57.960 --> 00:07:59.560
אבל כנראה שלא כדאי לכם לכתוב חדשות.

00:07:59.680 --> 00:08:02.500
אם אתם מתחילים פרויקט חדש היום, בייספ היא הדרך הנכונה.

00:08:02.660 --> 00:08:05.180
שלוש שורות של בייספ כדי לפרוס קבוצת משאבים.

00:08:05.360 --> 00:08:06.240
רק שלוש שורות.

00:08:06.320 --> 00:08:08.860
ה-ARM-JSON המקביל הוא בערך 15 שורות.

00:08:08.860 --> 00:08:12.080
אותה תוצאה, אותה פריסה, אבל אחד קריא והשני רועש.

00:08:12.220 --> 00:08:13.540
עכשיו, אולי אתם תוהים.

00:08:13.720 --> 00:08:14.600
מה לגבי טראפורם?

00:08:14.760 --> 00:08:16.800
האם עליי ללמוד בייספ או טראפורם?

00:08:16.800 --> 00:08:19.220
בייספ מול טראפורם, במי כדאי להשתמש?

00:08:19.400 --> 00:08:21.640
ברוכים השווים ל-Microsoft Knowledge Nuggets.

00:08:21.800 --> 00:08:24.580
אני מרקו פיטרס, והיום נטפל בשאלה שחוזרת על עצמה.

00:08:24.760 --> 00:08:25.960
בייספ או טראפורם?

00:08:26.140 --> 00:08:26.980
בואו נפרק את זה.

00:08:27.120 --> 00:08:28.740
טראפורם עובד על פני עננים מרובים.

00:08:28.740 --> 00:08:32.300
אפשר להשתמש בו עבור Azure, AWS, GCP, או אפילו שלושתם יחד.

00:08:32.420 --> 00:08:34.820
בייספ, לעומת זאת, בנוי עבור Azure בלבד.

00:08:34.940 --> 00:08:37.060
ההבדל המהותי הזה משפיע על כל השאר.

00:08:37.060 --> 00:08:40.600
אם אתם עובדים על פני מספר עננים, טראפורם הוא הדרך הנכונה.

00:08:40.780 --> 00:08:44.920
לומדים שפה אחת, כלי אחד, תהליך עבודה אחד, וזה עובד בכל מקום.

00:08:45.060 --> 00:08:48.680
אבל, אם אתם עובדים בעיקר ב-Azure, לבייספ יש שתרונות משמעותיים.

00:08:48.680 --> 00:08:49.960
הנה הראשון שבהם.

00:08:50.080 --> 00:08:52.180
אין קובץ מצב, State File, לניהול.

00:08:52.300 --> 00:08:56.020
טראפורם שומר קובץ מצב שעוקב אחר מה שהוא פורס, וזה קובץ קריטי.

00:08:56.140 --> 00:08:59.180
אם הוא משתבש או יוצא מסמכרון, יש לכם בעיה רצינית.

00:08:59.180 --> 00:09:02.600
אתם חייבים להכסן אותו בצורה מאובטחת, לגבות ולנהל גישה.

00:09:02.740 --> 00:09:07.480
בייספ מדבר ישירות עם Azure Resource Manager, בודק מה קיים ומזהה הבדלים.

00:09:07.700 --> 00:09:11.060
ללא קובץ מצב, אין בעיות סמכרון ואין סיכון לשיבוש.

00:09:11.060 --> 00:09:13.340
יתרון שני, תמיכה מהיום הראשון.

00:09:13.500 --> 00:09:18.080
כשמייקרוסופט משחררת תכונת Azure חדשה, בייספ תומך בה מידית באותו יום.

00:09:18.240 --> 00:09:22.560
טראפורם צריך לחכות לעדכון ספק, שלעיתים מהיר ולעיתים לוקח שבועות.

00:09:22.560 --> 00:09:26.420
אם אתם צריכים להשתמש בתכונה חדשה מיד, בייספ הוא האופציה היחידה.

00:09:26.540 --> 00:09:28.500
שלישית, הוא נבנה על ידי צוות Azure.

00:09:28.700 --> 00:09:33.460
הכלים, האינטליסנס, הודעות השגיאה, כולם מתוכננים סביב איך ש-Azure עובד.

00:09:33.460 --> 00:09:37.980
כשכותבים בבייספ, משתמשים בשפה שמבינה את משאבי Azure באופן טבעי.

00:09:38.080 --> 00:09:42.020
היא יודעת אילו מאפיינים נדרשים, אילו ערכים תקפים ואילו תלויות קיימות.

00:09:42.120 --> 00:09:45.000
קשה לשכפל אינטגרציה עמוקה כזו עם כלי צד שלישי.

00:09:45.160 --> 00:09:46.640
אפשר גם להשתמש בשניהם.

00:09:46.640 --> 00:09:51.480
ארגונים רבים משתמשים בבייספ עבור פלטפורמה ולנדינג זונס ובארפורם לאומשים רב ענניים.

00:09:51.620 --> 00:09:52.800
הם לא מוציאים זה את זה.

00:09:52.980 --> 00:09:55.140
אפשר לבחור את הכלי הנכון לכל משימה.

00:09:55.280 --> 00:09:56.380
התשובה הכנה היא זו.

00:09:56.380 --> 00:09:59.700
עבור לימוד Azure באופן ספציפי, לבייספ יש פחות חלקים נעים.

00:09:59.820 --> 00:10:01.460
זה מסלול פשוט יותר כשמתחילים.

00:10:01.640 --> 00:10:04.640
לא צריך ללמוד על קבצי מצב, ספקים או הגדרות back-end.

00:10:04.780 --> 00:10:08.140
מתקינים את Azure CLI, פותחים את VS Code ומתחילים לכתוב.

00:10:08.280 --> 00:10:09.340
מספיק עם התיאוריה.

00:10:09.500 --> 00:10:11.820
בואו נדבר על מה שבאמת צריך כדי להתחיל.

00:10:12.040 --> 00:10:12.600
מתחילים.

00:10:12.780 --> 00:10:13.840
מה שבאמת צריך.

00:10:14.000 --> 00:10:15.660
צריך שני דברים כדי להתחיל.

00:10:15.800 --> 00:10:18.640
Azure CLI והרחבת בייספ עבור VS Code.

00:10:18.860 --> 00:10:19.380
זה הכל.

00:10:19.380 --> 00:10:22.500
אין צורך בהתקנת בייספ-CLI נפרד ואין כלים נוספים להגדרה.

00:10:22.620 --> 00:10:24.560
Azure CLI מגיע עם בייספ מובנה.

00:10:24.660 --> 00:10:26.500
התקנת Azure CLI היא פשוטה למדי.

00:10:26.640 --> 00:10:28.020
עברו למסמכי מייקרוסופט.

00:10:28.180 --> 00:10:30.460
מצאו את דף ההתקנה עבור מערכת ההפעלה שלכם.

00:10:30.580 --> 00:10:32.260
אם אתם במק, זו פקודה אחת.

00:10:32.480 --> 00:10:33.960
brew-install Azure CLI.

00:10:33.960 --> 00:10:35.920
בווינדוס יש מתקין MSI.

00:10:36.060 --> 00:10:37.520
הורידו, הריצו וזהו.

00:10:37.640 --> 00:10:39.920
זה עובד גם בליוקס דרך מנהל החבילות שלכם.

00:10:40.060 --> 00:10:43.340
ברגע שזה מותקן, הריצו S-Version כדי לוודא שהכל עובד.

00:10:43.340 --> 00:10:47.120
אתם אמורים לראות את גרסת Azure CLI וגם את גרסת הבספ ברשימה.

00:10:47.200 --> 00:10:51.340
עכשיו, פיתחו את VS Code, עברו ללוח ההרחבות בצד שמאל וחפשו בייספ.

00:10:51.520 --> 00:10:54.880
התקינו את זו של Microsoft, לא של צד שלישי, את הרשמי.

00:10:54.980 --> 00:10:56.720
אתם באמת צריכים את ההרחבה הזו.

00:10:56.720 --> 00:11:00.140
היא מעניקה לכם IntelliSense שמציע מאפייני משאבים בזמן ההקלדה,

00:11:00.360 --> 00:11:03.680
מדגיש תחביר כדי לזהות שגיאות במבט חטוף ובודק טעויות בזמן אמת.

00:11:03.840 --> 00:11:07.680
תראו קווים גליים אדומים מתחת לכל מה שלא תקין עוד לפני שתנסו לבצע פריסה.

00:11:07.800 --> 00:11:12.740
בחינות, זו אחת מהרחבות השפה הטובות ביותר ב-VS Code וחלק גדול מהסיבה שביספ כל כך נעים לעבודה.

00:11:12.900 --> 00:11:15.540
עכשיו, צרו קובץ חדש וקראו לו Main, Bicep.

00:11:15.700 --> 00:11:18.460
הרחבת ה-VS Code הזו מורה לביספ להפעיל את ההרחבה.

00:11:26.720 --> 00:11:32.060
ראשית, מגדירים את טווח היד כמנוי, ואז מגדירים את המשאב, קבוצת משאבים עם שם ומיקום.

00:11:32.240 --> 00:11:33.580
זה הכל, שלוש שורות.

00:11:33.740 --> 00:11:38.020
השבו זאת ל-Arm.json המקביל, שזה בערך 15 שורות של סוגריים וגרשים.

00:11:38.220 --> 00:11:40.620
כדי לפרוס, משתמשים ב-Azure CLI.

00:11:40.760 --> 00:11:44.780
מכיוון שאתם פורסים בטווח המנוי, הפקודה היא S-Deployment Sub-Create.

00:11:44.960 --> 00:11:48.640
אתם מעבירים מיקום עבור מתא נתוני הפריסה ומפנים לקובץ ה-Bicep שלכם.

00:11:48.640 --> 00:11:51.500
זו הדרך בשורת הפקודה, אבל יש גם חוויה מודרכת.

00:11:51.500 --> 00:11:55.420
ב-VS Code, לחצו לחיצה ימנית על קובץ ה-Bicep ובחרו Deploy Bicep File.

00:11:55.620 --> 00:11:57.420
זה מלווה אתכם לאורך כל התהליך.

00:11:57.600 --> 00:12:04.200
זה מבקש שם לפריסה, לבחור את המנוי שלכם, ליצור או לבחור קבוצת משאבים, ושואל אם יש לכם קובץ פרמטרים.

00:12:04.380 --> 00:12:05.880
אתם אומרים לא, וזה פורס.

00:12:06.040 --> 00:12:08.040
התוצאה מופיעה בפורטל האז'ר שלכם.

00:12:08.220 --> 00:12:11.320
זההלי לחיצות בפורטל, אבל עכשיו יש לכם קובץ שניתן לעשות בו שימוש חוזר.

00:12:11.320 --> 00:12:14.880
אתם יכולים להוסיף אותו למאגר שלכם, לשתף עם הצוות ולהריץ שוב מחר.

00:12:15.000 --> 00:12:16.500
וכאן מגיע החלק הקסום.

00:12:16.660 --> 00:12:18.980
הריצו את אותה פריסה שוב וראו מה קורה.

00:12:19.260 --> 00:12:20.800
הכוח של אידמפוטנטיות.

00:12:21.000 --> 00:12:22.680
זה העניין לגבי הרצת פריסות.

00:12:22.840 --> 00:12:25.640
אתם רוצים להיות מסוגלים להריץ אותן שוב ושוב מבלי לשבור כלום.

00:12:25.820 --> 00:12:27.800
זה בדיוק מה שאידמפוטנטיות מעניקה לכם.

00:12:27.960 --> 00:12:31.160
בפעם הראשונה שמריצים את קובץ ה-Bicep הוא יוצר את קבוצת המשאבים,

00:12:31.160 --> 00:12:32.800
אך בפעם השנייה שום דבר לא קורה.

00:12:32.960 --> 00:12:34.800
ללא שגיאה, ללא כפילות, כלום.

00:12:35.000 --> 00:12:39.760
Bicep בודק מה כבר קיים באז'ר, משווה זאת למה שביקשתם, וקובע שאין מה לשנות.

00:12:39.940 --> 00:12:43.920
הוא לא ניסה ליצור קבוצת משאבים חדשה, והוא לא הציג שגיאה שהיא כבר קיימת.

00:12:44.120 --> 00:12:47.060
הוא פשוט אישר שהמצב הנוכחי תואם למצב הרצוי.

00:12:47.200 --> 00:12:50.000
חישבו על זה כמו הרצת git סטטוס במאגר נקי.

00:12:50.120 --> 00:12:50.840
אין מה לעשות.

00:12:51.020 --> 00:12:52.900
הכל כבר בדיוק כפי שהוא צריך להיות.

00:12:52.900 --> 00:12:54.900
זהו הכוח של תשתית קקוד.

00:12:54.900 --> 00:12:59.000
ניתן להריץ את הפריסה שוב ושוב, ולהגיע לאותה תוצאה בכל פעם מחדש.

00:12:59.140 --> 00:13:00.580
ללא הפתעות, ללא סטיות.

00:13:00.820 --> 00:13:03.140
אתם יודעים בדיוק מה פרוס כי הקובץ אומר זאת.

00:13:03.300 --> 00:13:05.580
הקובץ הופך למקור האמת היחיד שלכם.

00:13:05.760 --> 00:13:07.860
לעולם לא תצטרכו לטהות אם זכרתם הגדרה,

00:13:08.080 --> 00:13:10.180
להתמודד אם בעיית הזה עובד אצלי במחשב,

00:13:10.320 --> 00:13:13.060
או לחטט בפורטל Azure כדי לבדוק אם מי שהוא שינה משהו.

00:13:13.220 --> 00:13:14.820
הקובץ אומר לכם מה נמצא שם.

00:13:14.820 --> 00:13:18.100
אם ברצונכם לשנות משהו, אתם משנים את הקובץ ופורסים מחדש.

00:13:18.100 --> 00:13:20.840
אם ברצונכם לאמת, אתם מריצים את הפריסה שוב,

00:13:21.040 --> 00:13:22.320
והיא מאשרת שהכל תואם.

00:13:22.460 --> 00:13:24.440
כך בונים ביטחון בתשתית שלכם.

00:13:24.620 --> 00:13:26.000
הקובץ הוא מקור האמת.

00:13:26.200 --> 00:13:28.220
לא הזיכרון שלכם, לא מסמך וורד,

00:13:28.400 --> 00:13:30.960
לא סרטון יוטיוב מלפני חצי שנה, אלא הקובץ.

00:13:31.100 --> 00:13:33.960
אז איפה בייספ משתלב בתמונה הגדולה של Azure?

00:13:34.160 --> 00:13:36.420
התמונה הגדולה, איפה בייספ משתלב?

00:13:36.600 --> 00:13:39.720
בייספ חי בתוך המערכת האקולוגית של Azure Resource Manager.

00:13:39.720 --> 00:13:40.900
זה לא כלי נפרד.

00:13:40.900 --> 00:13:44.660
רבים חושבים כך, אבל למעשה זו פשוט דרך טובה יותר לכתוב תבניות ARM.

00:13:44.840 --> 00:13:46.560
מתחת למכסה המנוע, זה עדיין ARM.

00:13:46.740 --> 00:13:48.840
אותו מנוע פריסה, אותו API, הכל אותו דבר.

00:13:49.000 --> 00:13:50.760
ההבדל היחיד הוא איך שכותבים את זה.

00:13:50.880 --> 00:13:52.960
ומכיוון שבייספ עובר קומפילציה ל-ARM,

00:13:53.160 --> 00:13:55.060
כל מה שעובד עם ARM עובד עם בייספ.

00:13:55.160 --> 00:13:57.560
Azure Policy עוכף ציות על הפריסות שלכם.

00:13:57.720 --> 00:13:59.700
RBSC שולט במי יכול לפרוס מה.

00:13:59.840 --> 00:14:02.320
Cost Management עוקב אחר ההוצאות על המשאבים שלכם.

00:14:02.320 --> 00:14:06.140
Azure DevOps ו-Github Actions פורסים את קבצי הבייספ שלכם דרך צינורות עיבוד.

00:14:06.260 --> 00:14:09.320
הכל עובד בצורה מושלמת כי בייספ מייצר ג'ייסן בטקן ARM.

00:14:09.480 --> 00:14:10.940
אתם לא מאבדים כלום במעבר.

00:14:11.120 --> 00:14:12.740
למעשה, אתם מרוויחים בהירות.

00:14:12.920 --> 00:14:15.600
מייקרוסופט בנתה מערכת אקולוגית שלמה סביב בייספ.

00:14:15.780 --> 00:14:17.360
Azure Verified Modules או AVM,

00:14:17.440 --> 00:14:21.240
הן ספריות מנוהלות של מודולי בייספ וטרפורם שעומדות בשיטות העבודה המומלצות.

00:14:21.340 --> 00:14:23.000
אתם לא חייבים לכתוב הכל מאפס.

00:14:23.000 --> 00:14:26.800
ניתן להשתמש במודולים מוכנים מראש לדפוסים נפוצים כמו רשתות וירטואליות,

00:14:26.980 --> 00:14:28.520
חשבונות איחסון ושירותי אפליקציה.

00:14:28.640 --> 00:14:32.080
הם נבדקים, מתוחזקים ומיושרים עם ה-Well-Architected Framework.

00:14:32.240 --> 00:14:36.980
ה-Cloud Adoption Framework כולל מימושי עזר של בייספ עבור ארכיטקטורות ארגוניות סטנדרטיות.

00:14:37.180 --> 00:14:40.260
אם אתם בונים לנדינג זון, יש תבנית בייספ מוכנה לכך.

00:14:40.400 --> 00:14:43.860
Deployment Stacks מעניקים לכם ניהול מחזור חיים עבור קבוצות של משאבים.

00:14:43.860 --> 00:14:47.580
ניתן לפרוס ערמה, סטאק, ואם תסירו משאב מקובץ הבייספ שלכם,

00:14:47.760 --> 00:14:51.060
הערמה תוכל לנקות אותו עבורכם, או להגן עליו ממחיקה מקרית.

00:14:51.180 --> 00:14:51.980
אתם מחליטים.

00:14:52.160 --> 00:14:57.740
ה-Core System ממשיך לצמוח עם עוד מודולים, כלים טובים יותר ואינטגרציה עמוקה עם AI ו-G-Thub Copilot.

00:14:57.880 --> 00:15:02.260
ניתן לתאר מה אתם רוצים בשפה פשוטה, וקופילות ייצר את קוד הבייספ עבורכם.

00:15:02.420 --> 00:15:06.320
מייקרוסופט ממשיכה להשקיע בבייספ כחוויית העריכה העיקרית עבור Azure.

00:15:06.320 --> 00:15:09.040
לכן, פיצ'רים חדשים מכוונים קודם כל לבייספ.

00:15:09.180 --> 00:15:12.060
תבניות ARM עדיין עובדות, אבל החדשנות קורית בבייספ.

00:15:12.140 --> 00:15:13.500
אז, הנה השורה התחתונה.

00:15:13.660 --> 00:15:17.520
אם אתם עובדים באז'ר, בייספ הוא הצעד הטבעי הבא מעבר ללחיצות בפורטל.

00:15:17.640 --> 00:15:20.380
אתם לא צריכים ללמוד טראפורם או לשלוט בג'סון של ARM.

00:15:20.560 --> 00:15:26.300
מתקינים שני דברים, כותבים כמה שורות קוד, ואתם פורסים תשתית שניתן לחזור עליה, מבוקרת גרסאות ואמינה.

00:15:26.300 --> 00:15:29.120
הרשו לי להשאיר אתכם עם משהו פרקטי שניתן לעשות היום.

00:15:29.260 --> 00:15:34.380
אז עכשיו אתם יודעים מה זה תשתית כקוד, IC, למה בייספ קיים, ואיך הוא הופך פריסות באז'ר לפשוטות יותר.

00:15:34.560 --> 00:15:35.720
הנה הנקודה העיקרית.

00:15:35.900 --> 00:15:37.640
בייספ הוא לא מערכת פריסה שונה.

00:15:37.840 --> 00:15:40.980
זו דרך טובה יותר לכתוב את אותן תבניות ARM שהייתם כותבים בכל מקרה,

00:15:41.180 --> 00:15:44.160
תוך שימוש באותו מנוע ו-Azure Resource Manager מאחורי הקלעים,

00:15:44.340 --> 00:15:46.400
רק בשפה שבני אדם באמת יכולים לקרוא ולכתוב.

00:15:46.540 --> 00:15:47.700
הנה אתגר בשבילכם.

00:15:47.700 --> 00:15:51.520
צרו קובץ מיין, בייספ, פרסו קבוצת משאבים, והריצו את הפריסה פעמיים.

00:15:51.720 --> 00:15:53.240
ראו איך זה עובד בשתי הפעמים.

00:15:53.440 --> 00:15:57.380
בפעם הראשונה הוא יוצר את המשאב, ובפעם השנייה הוא מאשר ששום דבר לא השתנה.

00:15:57.540 --> 00:16:01.700
זה הרגע שבו זה, קליק, כשמבינים שלעולם לא תחזרו ללחוץ סתם בפורטל.

00:16:01.900 --> 00:16:02.660
זה הבסיס.

00:16:02.900 --> 00:16:07.920
מכאן תוכלו להוסיף חשבונות תכסון, רשתות וירטואליות ושירותי אפליקציה באותו דפוס.

00:16:08.100 --> 00:16:10.460
כתבו קובץ, פרסו אותו, הריצו אותו שוב.

00:16:17.700 --> 00:16:18.980
הם יודו לכם על כך.

00:16:19.140 --> 00:16:25.620
הרשמו בפלטפורמת הפודקאסט המועדפת עליכם, ובפרק הבא נתקדם עם בייספ ונפרוס משאבים אמיתיים עם מאפיינים אמיתיים.