האם דוקר הוא צעצוע או לא? או שזה עדיין נכון?

שלום לכולם!

אני מאוד רוצה להגיע ישר לנושא, אבל יהיה נכון יותר לספר קצת על הסיפור שלי:

כניסה

אני מתכנת עם ניסיון בפיתוח יישומי עמוד בודד בחזית, scala/java ו-nodejs בשרת.

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

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

סיבות לשימוש

למה השתמשתי בדוקר? כנראה מהסיבות הבאות:

• השקת מסד נתונים, 99% מהיישומים משתמשים בהם
• הפעלת nginx עבור הפצת חזית והעברת פרוקסי ל-backend
• אתה יכול לארוז את היישום בתמונת docker, כך היישום שלי יעבוד בכל מקום בו קיים docker, בעיית ההפצה נפתרת מיד
• גילוי שירות מהקופסה, אתה יכול ליצור מיקרו-שירותים, כל מיכל (מחובר לרשת משותפת) יכול להגיע בקלות לאחר באמצעות כינוי, נוח מאוד
• כיף ליצור מיכל ו"לשחק" בו.

מה שאני תמיד לא אוהב בדוקר:

• כדי שהאפליקציה שלי תעבוד, אני צריך את Docker עצמו בשרת. למה אני צריך את זה אם האפליקציות שלי פועלות על jre או nodejs והסביבה עבורם כבר נמצאת בשרת?
• אם אני רוצה להפעיל את התמונה (הפרטית) שלי הבנויה מקומית על שרת מרוחק, אז אני צריך מאגר docker משלי, אני צריך שהרישום יעבוד איפשהו ואני צריך גם להגדיר https, כי docker cli עובד רק על https. אה לעזאזל... יש אפשרויות, כמובן, לשמור את התמונה באופן מקומי באמצעות docker save ופשוט לשלוח את התמונה דרך scp... אבל זה הרבה תנועות גוף. וחוץ מזה, זה נראה כמו פתרון "קביים" עד להופעת המאגר שלך
• docker-compose. זה נחוץ רק כדי להפעיל מכולות. זה הכל. הוא לא יכול לעשות שום דבר אחר. Docker-compose יש חבורה של גרסאות של הקבצים שלו, תחביר משלו. לא משנה כמה זה הצהרתי, אני לא רוצה לקרוא את התיעוד שלהם. אני לא אצטרך את זה בשום מקום אחר.
• כשעובדים בצוות, רוב האנשים כותבים Dockerfile בצורה מאוד עקומה, לא מבינים איך הוא מאוחסן במטמון, מוסיפים את כל מה שהם צריכים ולא צריכים לתמונה, יורשים מתמונות שאינן ב- Dockerhub או מאגר פרטי, יוצרים כמה docker-compose קבצים עם מסדי נתונים ושום דבר לא ממשיך. יחד עם זאת, המפתחים מצהירים בגאווה ש-Docker זה מגניב, הכל עובד עבורם מקומית, ו-HR כותב במשרה הפנויה: "אנחנו משתמשים ב-Docker ואנחנו צריכים מועמד עם ניסיון עבודה כזה".
• אני כל הזמן רדוף על ידי מחשבות על העלאת הכל ב-Docker: postgresql, kafka, redis. חבל שלא הכל עובד בקונטיינרים, לא הכל קל להגדיר ולהפעיל. זה נתמך על ידי מפתחי צד שלישי, ולא על ידי הספקים עצמם. ודרך אגב, מיד נשאלת השאלה: הספקים לא דואגים לתחזק את המוצרים שלהם ב-Docker, למה זה, אולי הם יודעים משהו?
• תמיד מתעוררת השאלה לגבי התמדה של נתוני מיכל. ואז אתה חושב, האם עלי לעלות את ספריית המארח או ליצור אמצעי אחסון או ליצור מיכל נתונים שהוא כעת deprecated? אם אני מעלה ספרייה, אז אני צריך לוודא שה-uid וה-gid של המשתמש בקונטיינר תואמים לזה של המשתמש שהפעיל את הקונטיינר, אחרת הקבצים שנוצרו על ידי הקונטיינר ייווצרו עם זכויות שורש. אם אני משתמש volume אז הנתונים פשוט ייווצרו בחלק /usr/* ויהיה אותו סיפור עם uid ו-gid כמו במקרה הראשון. אם אתה משיק רכיב של צד שלישי, עליך לקרוא את התיעוד ולחפש את התשובה לשאלה: "באיזה ספריות מכילות כותב הרכיב קבצים?"

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

היכרות עם Ansible

לאחרונה (לפני שלושה חודשים), עבדתי עם צוות DevOps, שכמעט לכל אחד מהם היה גישה שלילית כלפי Docker. מסיבות:

• docker כללים iptables (למרות שאתה יכול להשבית את זה ב-daemon.json)
• docker הוא באגי ואנחנו לא נריץ אותו בייצור
• אם docker daemon קורס, אז כל הקונטיינרים עם התשתית קורסים בהתאם
• לא צריך דוקר
• למה docker אם יש Ansible ומכונות וירטואליות

באותה עבודה התוודעתי לכלי נוסף - Ansible. שמעתי על זה פעם, אבל לא ניסיתי לכתוב ספרי משחק משלי. ועכשיו התחלתי לכתוב את המשימות שלי ואז החזון שלי השתנה לחלוטין! כי הבנתי: ל-Ansible יש מודולים להפעלת אותם קונטיינרים, בניית תמונות, רשתות וכו', וניתן להפעיל קונטיינרים לא רק מקומית, אלא גם בשרתים מרוחקים! ההנאה שלי לא ידעה גבול - מצאתי כלי NORMAL וזרקתי את קבצי ה-Makefile ו-docker-compose שלי, הם הוחלפו במשימות yaml. הקוד צומצם על ידי שימוש במבנים כמו loop, when, וכו '

Docker להפעלת רכיבי צד שלישי כגון מסדי נתונים

לאחרונה התוודעתי למנהרות ssh. התברר שקל מאוד "להעביר" את היציאה של שרת מרוחק לפורט מקומי. השרת המרוחק יכול להיות מכונה בענן או מכונה וירטואלית הפועלת ב-VirtualBox. אם אני או עמיתי צריכים מסד נתונים (או רכיב אחר של צד שלישי), נוכל פשוט להפעיל את השרת עם הרכיב הזה ולכבות אותו כשאין צורך בשרת. העברת יציאות נותנת את אותו אפקט כמו מסד נתונים הפועל במיכל docker.

פקודה זו מעבירה את היציאה המקומית שלי לשרת מרוחק שמריץ postgresql:

ssh -L 9000:localhost:5432 [מוגן בדוא"ל]

שימוש בשרת מרוחק פותר את הבעיה בפיתוח צוות. שרת כזה יכול לשמש כמה מפתחים בו זמנית; הם לא צריכים להיות מסוגלים להגדיר postgresql, להבין את Docker ומורכבויות אחרות. בשרת מרוחק, ניתן להתקין את אותו מסד נתונים ב-Docker עצמו, אם קשה להתקין גרסה ספציפית. כל מה שמפתחים צריכים הוא לספק גישת ssh!

לאחרונה קראתי שמנהרות SSH הן פונקציונליות מוגבלת של VPN רגיל! אתה יכול פשוט להתקין OpenVPN או יישומי VPN אחרים, להגדיר את התשתית ולתת אותה למפתחים לשימוש. זה כל כך מגניב!

למרבה המזל, AWS, GoogleCloud ואחרים נותנים לך שנה של שימוש בחינם, אז השתמש בהם! הם זולים אם מכבים אותם כאשר אינם בשימוש. תמיד תהיתי למה אני צריך שרת מרוחק כמו gcloud, נראה שמצאתי אותם.

בתור מכונה וירטואלית מקומית, אתה יכול להשתמש באותו Alpine, שנמצא בשימוש פעיל במכולות docker. ובכן, או הפצות קלות אחרות כדי להפוך את המכונה לאתחל מהר יותר.

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

קצת על תמונות דוקר והפצה

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

האם ראית איפה מפתחי תוכנה מעבירים את המוצרים שלהם רק בתמונת docker?
התוצאה של רוב המוצרים היא קבצים בינאריים עבור פלטפורמה ספציפית; הם פשוט מתווספים לתמונת docker, אשר עוברת בירושה מהפלטפורמה הרצויה. האם אי פעם תהיתם מדוע יש כל כך הרבה תמונות דומות ב- dockerhub? הזן nginx למשל, תראה 100500 תמונות מאנשים שונים. האנשים האלה לא פיתחו את nginx בעצמם, הם פשוט הוסיפו nginx רשמי לתמונת ה-Docker שלהם ותבלו אותה בתצורות משלהם לנוחות השקת קונטיינרים.

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

בשורה התחתונה: אני לא צריך את הרישום של docker, אני אשתמש בסוג של S3 או רק אחסון קבצים כמו google drive/dropbox

דוקר ב-CI

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

חברות אלה משתמשות ב-docker בשרתים שלהן שבהם פועל תהליך ה-CI. שאלה: למה אתה צריך לבנות פרויקטים בקונטיינר docker בשרתים שלך? למה לא פשוט להכין סביבה ל-build, למשל, לכתוב ספר הפעלה של Ansible שיתקין את הגרסאות הדרושות של nodejs, php, jdk, להעתיק מפתחות ssh וכו' לשרת בו יתבצע ה-build?

עכשיו אני מבין שזה יורה לעצמי ברגל, כי דוקר לא מביא שום רווח עם הבידוד שלו. בעיות שנתקלתי בהן עם CI ב- docker:

• שוב אתה צריך תמונת docker כדי לבנות. אתה צריך לחפש תמונה או לכתוב dockerfile משלך.
• 90% שאתה צריך להעביר כמה מפתחות ssh, נתונים סודיים שאתה לא רוצה לכתוב לתמונת docker.
• המיכל נוצר ומת, כל המטמונים הולכים לאיבוד יחד איתו. ה-build הבא יוריד מחדש את כל התלות בפרויקט, וזה גוזל זמן ולא יעיל, וזמן זה כסף.

מפתחים לא בונים פרויקטים בקונטיינרים של docker (פעם הייתי מעריץ כזה, באמת, אני מרחם על עצמי בעבר xD). ב-java אפשר לקבל כמה גרסאות ולשנות אותן בפקודה אחת לזו שאתם צריכים עכשיו. זה אותו דבר ב-nodejs, יש nvm.

פלט

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

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

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

אם אתה עדיין מחליט להשתמש ב-docker, אז:

• להיות זהירים ביותר
• אל תכריח מפתחים להשתמש ב-docker
• התאם את השימוש בו במקום אחד, אל תפיץ אותו בכל המאגרים של Dockefile ו-docker-compose

נ.ב.:

• לאחרונה נתקלתי אוֹרֵז והם אומרים שזה עובד טוב מאוד עם Ansible ומאפשר לך לאחד את תהליך בניית התמונות (כולל תמונת docker)
• גם על דוקר, מאמר מעניין

תודה שקראתם, מאחל לכם החלטות שקופות בענייניכם וימי עבודה פוריים!

מקור: www.habr.com