ניהול תוך אופטימיזציה מסייע לתפעול אמין יותר של קונטיינרים

דף הבית >> חדשות לארגונים ולעסקים >> ניהול תוך אופטימיזציה מסייע לתפעול אמין יותר של קונטיינרים
ניהול תוך אופטימיזציה מסייע לתפעול אמין יותר של קונטיינרים
מאת: אנדריאס ניב, 6.9.17, 07:10אנדריאס ניב

תוך זמן קצר תפסו טכנולוגיות קונטיינר מקום בארגוני אנטרפרייז, בעיקר עבור פיתוח ותפעול של יישומים חדשים. גורם חשוב בהגדלת חדירתם הוא ניהול עתיר ביצועים, שמאפשר שימוש יעיל ומאובטח בקונטיינרים לאורך מחזור החיים המלא. לפתרונות ניהול קונטיינרים בקוד פתוח יש יתרונות ניכרים לעומת פתרונות של יצרנים ספציפיים במונחי חדשנות, זריזות וגמישות. יישומים עסקיים בהיקף גדול מציבים דרישות גבוהות על ניהול קונטיינרים, אותן ניתן לסכם ב-7 נקודות.
 
את התכונות המרכזיות של קונטיינרי לינוקס ניתן לסכם במספר משפטים: הם אורזים קוד תוכנה ותלויות  (dependencies)חיוניות לתוך חבילה מבודדת, שרצה על אינסטנציה יחידה במערכת ההפעלה של המחשב המארח. דבר זה נעשה ישירות בחומרה פיזית או במכונה וירטואלית, ויכול להתקיים במרכז נתונים באתר הלקוח או בענן ציבורי.

קונטיינרים שונים בבירור מווירטואליזציית  Hypervisor(תוכנה להרצת וניהול מכונה וירטואלית). וירטואליזציה כרוכה בקישור מכונות וירטואליות למערכת הפעלה מלאה, מה שיוצר תקורות משמעותיות. כדי לענות לבעיה זאת, קונטיינר יישומים כבר מכיל את כל התלויות הדרושות, כמו תווכה (Middleware) וסביבת זמן ריצה. כתוצאה, קונטיינרים רבים יכולים לחלוק ביניהם שרת ליבה (Kernel) אחד של מערכת ההפעלה.

קונטיינרים מבטיחים פיתוח מהיר וחסכוני, מאחר שניתן לנייד אותם במהירות ובקלות בין ובתוך סביבות פיתוח, בחינות ותפעול. זה מאפשר לארגונים לפתור בעיות ארגוניות רבות בהן נתקלים בפרויקטי פיתוח תוכנה קונבנציונליים בהיקפים גדולים. כבר לא נדרשים עשרות תכניתנים לעבודה על יישום יחיד. במקום זאת יש צוותים קטנים המתמקדים בתת-משימות ותהליכים מסוימים, ולכן מסוגלים לעבור באופן הרבה יותר אג'ילי.

כאשר קונטיינרים מועברים לתפעול ייצור, אפשר במקרה הפשוט ביותר ליזום את הפרוצדורה בשימוש בתהליך שרת Systemd  (מערך כלים המספקים מודל מהיר וגמיש לניהול המכונה – מאתחול ואילך). 

בהפצות לינוקס נוכחיות, תהליך זה פועל כמערכת לאתחול, ניטור, וסיום תהליכים אחרים, וגם יכול לשמש עבור ניהול בסיסי של אובייקטי קונטיינר. עבור יישומים קטנים ופשוטים, Systemd עשויים להספיק. לעומת זאת, יישומים עסקיים בהיקף גדול מציבים דרישות גבוהות על ניהול קונטיינרים, אותן ניתן לסכם ב-7 נקודות:
  1. תיאום אופטימלי של משאבים ועומסי עבודה
בניגוד לתוכנה מונוליטית סטנדרטית או לפתרון מותאם ללקוח או למשימה ספציפיים, יישום מבוסס קונטיינר מורכב ממספר רכיבים עצמאיים הפועלים הדדית. כל אחד מרכיבים אינדיבידואליים אלה וקשריהם אחד עם האחר, חייבים להילקח בחשבון בפתרון ניהול קונטיינרים.

המורכבות גוברת עוד יותר אם צוות ה-IT פועל בתפיסת ה-DevOps, שמבוססת על קישור בין פיתוח ופעילויות IT.

תזמון קונטיינרים נדרש כדי לבצע את המעבר משלב הפיתוח לתפעול חי. בין השאר, נבחן אופן ביזור קונטיינרים ברחבי תשתיות מטרה, ואיזה משאבים זמינים עבורם במערכות הקיימות. אלה יכולים להיות שרתים במרכז נתונים באתר הלקוח, אך גם שרתים בענן ציבורי או אפילו מספר עננים ציבוריים כמו Amazon Web Services (AWS), Google Cloud, ו- Microsoft Azure. המטרה של תזמון קונטיינרים היא להבטיח ניצול אופטימלי של משאבי מחשוב זמינים, כגון עוצמת עיבוד, זיכרון, SSDs, ונפחי דיסק קשיח ורשת.

עסקים, שמפתחים יישומי קונטיינר, מתכננים לעתים קרובות, שיישומים אלה ירוצו בענן ציבורי - אם לא מיד אז לפחות במועד מאוחר יותר. בהיבט זה מפתחים רותמים את יתרונות הקונטיינרים, שיוצרים הפשטה (abstraction) מהתשתית שבבסיס. זה אומר, שאין זה משנה לקונטיינר היכן הוא רץ – בין אם ישירות בשרת, בסביבה וירטואלית או בענן ציבורי.

כתוצאה, פתרון ניהול הקונטיינר חייב לאפשר העברה של קונטיינרי-יישום בכל דרך בין מרכז הנתונים באתר הארגון וענן ציבורי אחד או יותר. כיום, רק מספר קטן של משתמשים הטמיעו ארכיטקטורה זו, שחוצה מרכז נתונים וחוצה ענן. עם זאת, רבים מתכוננים ללכת בעקבותיהם בקרוב.
  1. ניהול מחזור חיים
פתרון ניהול קונטיינרים לא צריך רק לאתחל קונטיינרים ולהבטיח ניצולת משאבים אופטימלית – זו המשימה של תזמון הקונטיינרים. הוא צריך גם לנטר תפעול תקין, לזהות ולתקן תקלות בשלב מוקדם ולהבטיח זמינות. הדבר כולל גם אתחול מחדש של קונטיינר, שהפסיק לפעול בשרת הנוכחי מסיבה כלשהי, או העברתו, אם נדרש, לשרת אחר במרכז הנתונים באתר או בענן ציבורי.

לשם כך גם יכולים מפתחים לספק בחינה פשוטה, לדוגמא, כזו המבצעת בדיקה חיצונית כדי לקבוע האם הקונטיינר פועל כהלכה. פתרון ניהול הקונטיינר מקבל מבחן זה כפרמטר של קלט, ואז יכול לבדוק במרווחי זמן, שנקבעים מראש, האם הקונטיינר עדיין מבצע את השירות שלו עפ"י הכוונה.

בשלב זה גם שימושיות מאוד פונקציות עבור בדיקות מקיפות יותר של תקינות קונטיינרים, והקביעה איזה מפתחים יכולים לשלב אותן ישירות לתוך היישום שלהם בצורת ממשקי תכנות (APIs).

זה אפשרי, לדוגמא, בשימוש בתוכנת ניהול API, שמאפשרת למנהלי תשתית לנהל את מחזור חיי קונטיינר האפליקציה, החל מהקצאה ותצורה ועד לניהול תוכנה. במקום בו APIs משתלבים ישירות לתוך פלטפורמת יישום קונטיינר, ולכן גם לתוך פתרון ניהול וגישה מבחוץ נחסמת, ניתן להשיג גם עמידה בדרישות רגולציה וציות בשימוש בתצורה זאת.
  1. אבטחה
ככל שקונטיינרי יישומים הופכים לנפוצים יותר ויותר בעסקים, הדבר מציב אתגרי אבטחת IT ספציפיים. כדי לענות על כך יש להטמיע אמצעי אבטחה בסיסיים כחלק של ניהול קונטיינר.

המטרה כאן היא להבטיח אבטחת אימג'ים של קונטיינר ותכניו לאורך מחזור החיים המלא.  לדוגמא, בעת יצירת אימג'ים של קונטיינר חשוב, שייעשה שימוש רק בתוכן, שניתן לסמוך עליו, שניתן לקבוע בקלות את המקור של כל הרכיבים והספריות באימג'ים של קונטיינר, שנעשה שימוש בסביבות מבודדות, ושמתבצעות באופן סדיר סריקות אבטחה.

מלכתחילה חייב להיות ניהול תפקידים וזכויות עבור קונטיינרים המשובץ בפתרון הניהול שלהם. כלי הניהול יכול במצב זה להשתמש בפתרונות מבוססי ,LDAP שכבר קיימים בארגון.

תחילה מגדירים איזה משתמשים רשאים עפ"י תפקידיהם לבצע איזה פעילויות הקשורות לקונטיינר. שנית, חובה להגדיר את הפעולות, שקונטיינר רשאי לבצע. בהיבט זה הטווח נע מבידוד מלא עד לזכויות שורש, כאשר קונטיינר מקבל גישה לקונטיינרים אחרים ולמערכת ההפעלה של השרת. עם זאת, זהו היוצא מן הכלל ולא הכלל.

אישור בצורת חתימה דיגיטלית משפר את רמת האבטחה ומבהיר מי יצר את אובייקט הקונטיינר, לאיזו מטרה, ומתי.
ניתן לסכם אסטרטגיית אבטחה כללת כך:
  • כל הרכיבים צריכים להיות ממקורות מהימנים.
  • צריך להיות ברור, שסטטוס האבטחה שלהם עדכני ולא עבר שינוי ללא הרשאה.
  • כשכבה נוספת יש להשתמש ב-SELInux במארחי הקונטיינרים, כדי להגן על קונטיינרים פעילים מהמחשב המארח (Host) ואחד מהאחר. SELinux מבודדת את הקונטיינרים ומאשרת גישה רק למשאבים הנחוצים.
תאורטית, ברחבי הגבולות החיצוניים של הקונטיינר, יכול תוכן זדוני לחדור מאובייקט קונטיינר אחד לבא אחריו ולבסוף אפילו למארח הקונטיינרים. לכל תהליך, שרץ בהקשר של קונטיינר, יש גישה ל-Kernel של מארח הקונטיינרים, ללא כל צעדי אבטחה ישירים נוספים.

בתרחיש של המקרה הגרוע ביותר, תוקף עלול  לנצל פרצה בתוכנה הרצה בתוך הקונטיינר. אם הוא גם מוצא פרצה ב-Kernel של לינוקס, הוא יבצע בהצלחה את הקפיצה למארח הקונטיינרים. הדבר עלול לסכן גם את כל תהליכי הקונטיינר האחרים במארח זה. כצעד מניעה, מארח הקונטיינר חייב לכן לעבור בקביעות עדכונים בשימוש בעדכוני האבטחה האחרונים.
  1. גילוי שירות (Service Discovery)
בשימוש בטכנולוגיות ותהליכים כמו מיקרו-שירותים (Microsevices), קונטיינרים ו-DevOPs, מסוגלים גופי IT להגיב במהירות ובגמישות לדרישות עסקיות חדשות. הדרישות המקדימות לכך מסופקות ע"י תפיסת ארכיטקטורות המיקרו-שירותים: היישומים מפוצלים למיקרו-שירותים קטנים, שמקושרים ביניהם באופן רופף וארוזים כקונטיינר בשרתים בתוך הארגון או ממוקמים בענן.

מאחר שמעצם מהותם קונטיינרים הם דינמיים ולא קבועים במיקומם, ופתרון ניהול הקונטיינרים ממקם אותם בהתאם לנדרש, אי אפשר להבטיח, שקונטיינר יחיד או אפילו קבוצה של קונטיינרים קשורים, יפעלו תמיד בשרת אחד מסוים. לכן חובה. שלפתרון ניהול הקונטיינרים תהיינה זמינות פונקציות גילוי שירות. כך, שניתן יהיה לאתר ע"י שירותים אחרים גם קונטיינרים משויכים, ללא חשיבות לכך, האם הם באתר או רצים בענן ציבורי.
  1. הרחבת יישומים ותשתיות
כאשר מדובר בגידול (Scaling) – תהליך, שייתמך ע"י מערכת ניהול הקונטיינרים – יש 2 סוגים שונים:
  • הרחבה של אינסטנציות קונטיינר עם היישום עצמו: לדוגמא, במקרה של עומס שיא, חובה להבטיח, שאדמיניסטרטור, שמשתמש בפתרון ניהול קונטיינרים, יוכל להפעיל ידנית מספר גדול של אינסטנציות קונטיינר כדי לתת מענה לצרכים נוכחיים. להשגת גידול דינמי יתאים מנגנון אוטומטי העובד עם מדדים מאוחסנים. בהיבט זה, האדמיניסטרטורים יכולים להגדיר, שאם יש עומס על CPU מסוים, יש חריגה מנפחי האחסון, או מתרחשים אירועים ספציפיים, יתחילו לפעול מספר אינסטנציות קונטיינר נוספות, שתיקבענה מראש.
  • הגדלה של תשתית הקונטיינר: בהיבט זה חובה, שיתאפשר ליישומים הרצים בפלטפורמת קונטיינר להתרחב למאות אינסטנציות. לדוגמא, ע"י הרחקת פלטפורמת הקונטיינרים לענן ציבורי. זה הרבה יותר מורכב מאשר להתחיל קונטיינרים חדשים בשרתים.
  1. אספקת אחסון Persistent
להשקת מיקרו-שירותים בארכיטקטורות יישומים יש גם השפעה על הקצאה של נפחי אחסון. במהלך אריזה ופריסה, אחסון צריך להיות מסופק כמיקרו-שירות ארוז בקונטיינר ולהפוך לאחסון טבעי (Native) של קונטיינר. המשמעות היא, שהניהול של אחסון Persistent (לדוגמא דיסקים קשיחים וכונני פלאש) עבור קונטיינר יישומים הוא גם משימה עבור פתרו ניהול הקונטיינרים.

לדוגמא, בשימוש ב-Red Hat OpenShift Container Platrform, יכולים אדמיניסטרטורים לספק קונטיינרי יישומים ואחסון קונטיינר Persistent, שמנהל את מסגרת התיאום (Orchestration) Kubennetes. מסגרת Kubernetes Persistent Uolume (PV) מקצה מאגר של קונטיינרי יישומים, שרצים על שרתים מבוזרים, עם אחסון Persistent. בשימוש ב-Persitent Volume Claims (PVCs), מפתחים מסוגלים לבקש משאבי PV בלי צורך במידע נרחב על תשתית האחסון, שביסוד המערכת.

אחסון קונטיינר טבעי, שמנוהל בשימוש בפתרון ניהול קונטיינרים, צריך לתמוך בהקצאה הדינמית של סוגי אחסון שונים כבלוק, קובץ ואובייקט, ואחסון רב-שכבתי דרך תוויות איכות שירות (Qality-of-service labels).

יתר על כן, אחסון Persitent משפר את חווית המשתמש בתפעול של יישומי Stateful ו-Stateless. לכן, קל יותר למנהלים לנהל ולהשתמש, להקצת אחסון עבור יישומים. בשימוש באחסון קונטיינר טבעי נהנות יחידות IT מארכיטקטורה מוגדרת-תוכנה עתירת סקלאביליות, אותה ניתן להטמיע במרכז נתונים באתר הלקוח או בעננים ציבוריים, ובמקרים רבים תהיה יותר חסכונית מפתרונות אחסון מסורתיים מבוססי-חומרה או פתרונות ענן טהורים מבוססי-ענן.
  1. פתרונות קוד פתוח מציעים פוטנציאל גדול יותר במונחי חדשנות
טכנולוגיות קונטיינר, במיוחד קונטיינרי לינוקס, התפתחו תוך מספר קטן של שנים ממוצר נישה והפכו למגמה פופולרית במרחב.

קונטיינרי לינוקס המבוססים על פורמט Docker נתמכים ע"י חברת IT מובילות רבות, החל מאמזון, גוגל ו-HPE, דרך יבמ, מיקרוסופט ורד האט. לכן, נוצר סטנדרט תעשייה אותו מעריכים גם ארגוני אנטרפרייז בכל המגזרים, שמשתמשים בקונטיינרי לינוקס עבור פיתוח.

במיוחד מפני שמשתמשים ויצרני תוכנה כה רבים עושים שימוש בקונטיינרי לינוקס, התפתח שוק דינמי מאוד העוקב אחרי העקרונות של תוכנת קוד פתוח. יותר ויותר ארגונים מאמצים ארכיטקטורת מיקרו-שירותים ומספקים יישומים מבוססי-קונטיינר. זה יוצר דרישת חדשות, שיש להטמיע אותן מהר ככל האפשר בצורת תפקודית חדשה. דבר זה לא היה מתאפשר תוך שימוש במודל של קוד סגור ועם ספק תוכנה יחיד בלבד. אותו דבר נכון גם לפתרונות ניהול קונטיינרים.

לפי Github, כ-1,000 מפתחים מחברות המספקות תוכנה ולקוחותיהם עובדים על פרויקט הקוד הפתוח Kubernetes, שיוצר את הבסיס לניהול קונטיינרים בפתרונות רבים. בעת אספקת מהדורות חדשות, חדשנות מתרחשת הרבה יותר מהר מאשר עם תוכנה קניינית, בה סבבי מהדורות של 12 עד 18 חודשים הם הנורמה, לעומת 3 חודשים ל-Kubernetes. לכן, לפתרונות ניהול קונטיינרים בקוד פתוח יש יתרונות ניכרים לעומת פתרונות של יצרנים ספציפיים במונחי חדשנות, זריזות וגמישות.
 
מאת: אנדריאס ניב, ספטמבר 2017.
 ארכיטקט ראשי לתחום השירותים הפיננסיים ברד האט
 
קונטיינרים



 
 
Bookmark and Share


 

לוח מודעות
מחפשים הגנה מושלמת על הגלישה הניידת והנייחת ועל הפרטיות מפני כל תוקף? הפתרון הזול והטוב בעולם - כאן.

לוח אירועים וכנסים של עולם ההיי-טק - כאן.

מחפש מחקרים? מאות מחקרים עדכניים מהשנה האחרונה מצויים כאן

מחפש תוכנות חופשיות? תוכל למצוא משחקיםתוכנות לפרטיים ותוכנות לעסקיםתוכנות לצילום ותמונות, הכל בחינם.


מעוניין לבנות ולתפעל אתר אישי או עסקי מקצועי? לחץ כאן.


 




לוח האירועים המלא לגולשים מצוי כאן.

28-29/10/19 - Smart Mobility Summit 2019 

17-24/11/19 - שבוע היזמות העולמי 2019  

17-21/11/19 - Oracle Week 

3/12/19 - ועידת ההייטק החרדי 2019  

4/12/19 -  GO Mobile #8 

11/12/19 - Next Case  

12/2/20 - Teleco 2020

 

הכי ניצפים 

דירוג הסמאטרפונים הטובים ביותר בעולם לספטמבר 2019 עפ"י Business Insider - כאן

תאגיד השידור - "עלינו". איך עשו עלינו סיבוב והשאירו את אגרת הטלוויזיה - כאן

כל מה שלא מספרים לכם בתחום "השוק הסיטונאי" - פרק א': בזק - כאן

כל מה שלא מספרים לכם בתחום "השוק הסיטונאי" - פרק ג' - ההפסד הצרכני - כאן

כמה מפסידים בביצועים של הפס הרחב במעבר ל"שוק הסיטונאי"? - הרבה - כאן

למה מבלבלים את המוח לציבור בנושא המכונה "שוק סיטונאי"? - כאן

למה בכלל צריך להחליף / לרכוש נתב במעבר ל"שוק סיטונאי"? - כאן

איך אני יודע כמה מגהרץ יש בחיבור LTE? מי ספק הסלולר המהיר בישראל? - כאן

חשיפת המחדל המדהים המוסתר מהציבור של הרס רשתות הסלולר - כאן

חשיפת מה שאילנה דיין לא פרסמה ב"ערוץ 2" על תעלולי השר משה כחלון - כאן

איך רבע מיליון לקוחות נפלו בפח ועברו להסדר המכונה בטעות "שוק סיטונאי" - כאן

ההגנה המושלמת על הגלישה ניידת והנייחת ועל הפרטיות מפני כל תוקף - כאן

מבחן דרך: חיבור VPN - האם זו ההגנה המושלמת על הגלישה ועל הפרטיות? - כאן

המשך חשיפת הבלוף ששמו "מהפיכת הסלולר" ואיך מסרסים את הנתונים לציבור - כאן

סיכום ביקור בסיליקון ואלי - למה 3 הגדולות משקיעות ומפתחות באותם תחומים - כאן

שלמה פילבר (עד לאחרונה מנכ"ל משרד התקשורת) - עד מדינה? הצחקתם אותי! - כאן

"יש אפליה בחקירה"? חשיפה: למה השר משה כחלון לא נחקר עד היום? - כאן

חשיפת חשד לשחיתות הדומה לזו של "תיק 4000" אך בתחום הסלולר - כאן

חשיפת ההונאה הגדולה שהובילה לכך שמוצרי התקשורת יקרים יותר בישראל - כאן

בלעדי לקוראי האתר: 1 ש"ח ליום שיחות וגלישה ללא הגבלה בחו"ל... - כאן

חשיפת מה שלא רוצים  שתדעו בעניין פריסת אנלימיטד (בניחוח בלתי נסבל) - כאן

חשיפה: איוב קרא אישר לקבוצת סלקום בדיוק מה שביבי אישר ל-Yes ולבזק - כאן

האם השר איוב קרא היה צריך בכלל לחתום על האישור, שנתן לקבוצת סלקום? - כאן

האם ביבי וקרא קבלו בכלל תמורה עבור ההטבות הרגולטוריות שנתנו לסלקום? - כאן

המסמכים בנושא בזק-Yes (תיק 4000) מוכיחים "תפירת תיק" לאיש הלא נכון! - כאן

עובדות ומסמכים המוסתרים מהציבור: האם ביבי כשר תקשורת עזר לקב' בזק? - כאן

מה מקור ה-Fake News שהביא לתפירת תיק לביבי והעלמת החשודים הנכונים - כאן

אחת הרגליים של "תיק 4000 התפור" התמוטטה היום בניצחון (כפול) של בזק - כאן

איך כתבות מפנקות הפכו לפתע לטובת הנאה שהיא מיסודות עבירת השוחד? - כאן

שערוריית הקנס הענק על בזק וחשיפת "תעודת הביטוח" של נתניהו בתיק 4000 - כאן

תיק 5000: סלקום - IBC לא תפרוס סיבים ותרכב על גב הרכוש הפרטי של בזק - כאן

ערוץ 20: "תיק תפור": אבי וייס חושף את מחדלי "תיק 4000" - כאן

התבלבלתם: גיא פלד הפך את כחלון, גבאי ואילת לחשודים המרכזיים בתיק 4000 - כאן

פצצות בתיק 4000: האם היו בכלל התנגדויות למיזוג בזק-יס? - כאן

נמצא מסמר נוסף בארון הקבורה של תיק 4000 התפור - כאן

נחשפה עוד עובדה חשובה בדרך אל ההלוויה של תיק 4000 - כאן

תיק 4000 לא הושלם: האם היועמ"ש קיבל את כל המידע הנחוץ לחקר האמת? - כאן

תיק 4000: גם תקנות התקשורת התומכות בגרסת נתניהו לא נכללו בחקירה - כאן

חשיפת שקרים נוספים בתיק 4000: הטעיית הציבור נמשכת ללא הרף - כאן

תיק 4000: נחוצה ועדת חקירה ממלכתית לגבי "אישום" שר התקשורת - נתניהו - כאן

תיק 4000: חשיפת "דבר ראשון" בעניין היועמ"ש - היבטים חמורים חדשים - כאן

תיק 4000: היועמ"ש לממשלה אישר "מיזוג" בזק-יס. צריך ועדת חקירה ממלכתית - כאן

אוסף הטעויות בתיק 4000: "אני מאשים" - לא חתרו כלל לגילוי המאת - כאן

שערוריית תיק 4000: איך יש 2 גרסאות שונות של כתב החשדות של היועמ"ש? - כאן

ערוץ 20: אבי וייס חשף טענות שגויות בכתב החשדות נגד רוה"מ בתיק 4000 - כאן

תיק 4000: חשיפת מסמך נוסף שיסייע גם הוא לחיסול תיק 4000 התפור - כאן

ערוץ 20: אבי וייס ואלי ציפורי חשפו שקרי הפרקליטות לגבי ההדלפות בתיק 4000 - כאן

תיק 4000: מתי מדוע ואיך הוא הפך מ"תיק בזק" ל"תיק תפור" ומחורר? - כאן

הספינים והשקרים בתיק 4000 חזרו. הם חלק מניסיון הפיכה שלטונית שיש לחקור - כאן

סודות ושקרים בפרקליטות והיועמ"ש: מי היה ב"ניגוד עיניינים" בתיק 4000? - כאן

תיק 4000 יושלך לפח האשפה של ההיסטוריה עקב חקירה רשלנית ללא מסמכים - כאן

תיק 4000: מסמר נוסף ענק לארון הקבורה שלו (פרי חשיפה של אלי ציפורי) - כאן

תיק 4000: בעיות זיכרון, חקירה משובשת ושקרים המכוונים להפיכה שלטונית! - כאן

חשיפות חדשות בעקבות הדלפת עדויות שלמה פילבר - "עד המדינה" בתיק 4000 - כאן






 
זרקור חברות
 
פורטינט
 
NORDVPN
 
Telecom Expert
 
טלקום אקספרטס
 
NordVPN
 
עדן אימון עסקי
 
כמה זה? השוואת מחירים
 
PIXABAY
 
Telecom Experts
 
טלי וייס
 
 
Slideshare Linkedin Twitter
Youtube Instagram Facebook
Google+ live Zappix
Bitly Vimeo Pinterest
אנדרואידאנדרואיד-ברקוד אפל ברקודאפל

 
  מהירות גלישה Your IP שירותנט
לייבסיטי - בניית אתרים