אחרי שעשינו Logout וLogin מחדש למכונה, נריץ את הפקודה הבאה כדי לוודא שההתקנה בוצעה בהצלחה
gradle --version
זהו, ככה קל.
[aviv@localhost ~]$ gradle --version
Welcome to Gradle 6.0.1!
Here are the highlights of this release:
- Substantial improvements in dependency management, including
- Publishing Gradle Module Metadata in addition to pom.xml
- Advanced control of transitive versions
- Support for optional features and dependencies
- Rules to tweak published metadata
- Support for Java 13
- Faster incremental Java and Groovy compilation
- New Zinc compiler for Scala
- VS2019 support
- Support for Gradle Enterprise plugin 3.0
For more details see https://docs.gradle.org/6.0.1/release-notes.html
------------------------------------------------------------
Gradle 6.0.1
------------------------------------------------------------
Build time: 2019-11-18 20:25:01 UTC
Revision: fad121066a68c4701acd362daf4287a7c309a0f5
Kotlin: 1.3.50
Groovy: 2.5.8
Ant: Apache Ant(TM) version 1.10.7 compiled on September 1 2019
JVM: 1.8.0_232 (Oracle Corporation 25.232-b09)
OS: Linux 3.10.0-1062.9.1.el7.x86_64 amd64
כדי להתקין את Graddle Wrapper נריץ את הפקודות הבאות:
cd ~/
mkdir my-project
cd my-project
gradle wrapper
./gradlew build
קוברנטיס מאפשר לנו ליצור Virtual Network שפועל בכל הקלסטר שלנו, כל Pod בקלסטר מקבל כתובת IP ייחודית ויכול לתקשר עם כל pod אחר בקלסטר – גם במיקרה שהPod רץ בNode אחר.
לאחר מכן נריץ את הפקודה הבאה כדי לקבל רשימה של הPODS שלנו כולל כתובת הIP שלהם:
kubectl get pods -o wide
בשלב האחרון ננסה להריץ CURL מתוך הbusybox שלנו לכתובת הIP של הפודים האחרים שלנו, כאשר את ה00.00.00.00 אנו נחליף בכתובת הIP של הפוד אליו אתה רוצים לבצע את הCURL. הפקודה kubectl exec busybox בעצם מריצה את הcurl 00.00.00.00 בתוך POD הbusybox שלנו.
kubectl exec busybox -- curl 00.00.00.00
במידה והצלחנו לבצע CURL וקיבלנו את עמוד הדיפולט של Nginx זה בעצם מוכיח, שPODS יכולים לתקשר בניהם, גם אם הם ממוקמים בNodes אחר ושההתקנה של Flannel בוצעה בהצלחה.
לאפשר לקונטיינרים לתקשר בניהם כאשר הם נמצאים בNODES שונים
למנוע כפילות של כתובת IP זהה בין דוקרים שממוקמים בNODES שונים
כשמחליפים קונטיינר – הוא בדרכ יקבל כתובת IP חדשה שזה מצב שאנו לא תמיד מעוניינים בו.
היחידה הקטנה ביותר בקוברנטיס נקראת POD, הPOD יכול להכיל קונטיינר אחד או קבוצה של קונטיינרים. כל הקויינטנרים שנמצאים באותו POD יקבלו את אותה כתובת IP, וכל POD שממוקם בקלסטר יקבל כתובת IP ייחודית באותו IP SPACE.
כל הקונטיינרים יכולים לתקשר עם קונטיינרים אחרים ללא NAT.
כתובת הIP שהקונטיינר מזהה ככתובת IP ששייכת לו היא אותה כתובת IP שהקונטיינרים האחרים רואים כשייכת להם.
הNetwork Overlay אחראי על חלוקת כתובת הIP. הEtcd הוא Key-Value דאטאבייס לאובייקטים של קוברנטיס הKubelet הוא הסרביס של קוברנטיס שרץ על כל הנודים בקלסטר – גם במאסטר וגם בWORKERS.
קוברנטיס כולל רכיבים שונים שעובדים ביחד ומאפשרים את תפקודו של הקוברנטיס קלסטר. כדי לראות את כל הPODS שאחראים על תפקודו של הקוברנטיס שלנו נריץ את הפקודה הבאה:
kubectl get pods -n kube-system
כל POD שמופיע לנו הוא בעצם POD שמריץ בתוכו רכיב שקשור לקוברנטיס עצמו. הרכיבים העיקריים הם:
kube-apiserver זהו הAPI הראשי של קוברנטיס. הוא מבוסס REST. למשל הפקודה שהרצנו מקודם – kubectl get pods מבצעת למעשה פנייה לAPI.
etcd מנהל את נושא המידע – סטורג של הקלסטר. לא מדובר בסטורג' שמאחסן בתוכו את האתר את הקבצים שלנו למשל, מדובר בסטורג שמחזיק את הדאטא שקשור לכמה PODS רצים כרגע, NODES, איזה כתובת IP יש לכל אחד וכו – כל המידע שדרוש לקוברנטיס בשביל לנהל ולהחזיק את הקלסטר שלנו. במידה ויש לנו יותר מMASTER אחד, etcd ידאג שהדאטא הזה יהיה מסונכרן בין כל הMasters שלנו.
kube-controller-manager מאחד בתוכו רכיבים שונים לחבילה אחת. הוא מחזיק בתוכו את כל השירותים והספריות הדרושות לקוברנטיס. אם אנו מתייחסים ל jube-apiserver כפרונט של קוברנטיס, אזי ה kube-controller-manager הוא למעשה הבקאנד של קוברנטיס.
kube-scheduler אחראי על יצירת הPODS, מתי להריץ אותם, מתי לכבות אותם, באיזה Node עצמאי להריץ אותם וכו.
kube-proxy כל NODE זקוק לkube-proxy שלנו, הוא אחראי על התקשורת בין הNODES השונים על ידי הוספת כללי Firewall. כאשר POD בNODE X צריך לדבר עם POD שממוקם בNODE Y חייב להיות ROUTE וRULE שמאפשר את זה.
kubelet הAGENT שמריץ את הקונטיינרים שלנו בכל NODE. הוא בעצם המתווך בין הAPI של קוברנטיס לדוקר. (Docker במקרה שלנו, אגב קוברנטיס תומך לא רק בדוקר). הוא רץ כSERVICE ולא כPOD (כי הוא אחראי למעשה על הרצת הקונטיינר) ולכן הוא לא מופיע לנו ברשימת הPODS. כדי לראות אותו נריץ את הפקודה:
באחד המדריכים, יצרנו קוברנטיס קלסטר עם 3 Nodes, כל Node הוא בעצם שרת/מכונה שמריץ קונטיינרים (Pod).
לכל קוברנטיס קלסטר חייב להיות לפחות Node אחד שהוא יהיה הNode המנהל – הוא מריץ בתוכו את הKubernetes API ואת שאר כלי הניהול של קוברנטיס, שאר הNodes מכונים Workers.
Pods הוא היחידה הבסיסית ביותר של קוברנטיס. כל Pod מורכב מקונטיינר אחד או יותר (בדרכ יש קונטיינר אחד בכל POD אבל ניתן שיהיה יותר מקונטיינר אחד), כתובת IP בתוך הקוברנטיס קלסטר ואיחסון (Storage). כל Pod אחד או יותר יוצרים ביחד Node. קלסטר מורכב מNode אחד או יותר.
כשאנחנו מפעילים Pod, קוברנטיס בעצם מתזמן – Schedules Pod שיריץ אותו. הPod יריץ את כל הקונטיינטרים שם חלק מאותו Pod.
כדי ליצור POD, אנו משתמשים בקובץ YAML שמכיל את הפרטים של אותו POD. לדוגמא, אם נירצה ליצור POD שמריץ קונטיינר Nginx ניצור קובץ בשם ourtamlefilename.yaml לדוגמא עם הפרטים הבאים:
מכונה = Node לשם ההדגמה אנו ניצור kubernetes קלסטר שמורכב מ3 מכונות , 2 מכונות שיהיו הNODES ומכונה אחת שתהיה הNode Master שלנו. לשרת המסטר שלנו נקרא k8master , לשרת NODE הראשון נקרא k8node1 ולשני k8node2 ההפצה שבחרתי לעבוד איתה בהדגמה היא Ubuntu 18 LTS
בMASTER שלנו אנו נתקין: * Docker * Kubeadm * Kubelet * Kubectl * Control Plane
אחרי כמה דקות, נקבל פלט שמכיל את הפקודה אותה אני נצטרך להריץ אחכ בכל Node שלנו על מנת שהוא יוכל להצטרף לקלסטר. חשוב לשמור את הפקודה ואת הטוקן – כי בלעדיו לא תוכלו לצרף Nodes לCluster שלכם. במקרה שלי הפלט שהתקבל הוא
אחרי שהרצנו את הפקודה ב2 השרתים (ייתכן ותתבקשו להוסיף sudo) נריץ בשרת הMaster שלנו (k8master) שוב את הפקודה הבאה:
user@servername:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
servername1.serverdomain.com NotReady master 10m v1.12.7
servername2.serverdomain.com NotReady <none> 40s v1.12.7
servername3.serverdomain.com NotReady <none> 85s v1.12.7
ושימו לב שהפעם המסטר שלנו מזהה את 2 השרתים האחרים, כולם עדיין בסטטוס של NotReady.
השלב החמישי: הגדרות רשת עם Flannel
לקריאה מקדימה על networking בקוברנטיס:
בכל 3 המכונות (Nodes) – כולל מכונת הMaster שלנו נריץ את הפקודות הבאות
echo "net.bridge.bridge-nf-call-iptables=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
kubeadm הוא כלי שמאפשר אוטומציה של חלק גדול של יצירת קלסטר, בתכלס – הופך את העבודה שלנו ביצירת קלסטר להרבה יותר קלה.
מה זה kubelet?
kubelet הוא שירות (Agent) שרץ בכל קוניינר שקיים בכל Node שלנו, כל שרת שיריץ קונטיינר זקוק לשירות kubelet.
מה זה kubectl?
kubectl הוא כלי command line שמאפשר לנו לתקשר עם הקלסטר (Cluster) שלנו ולנהל אותו.
על מנת להתקין את השירותים הנל, נריץ את הפקודות הבאות: (אני בחרתי להתקין את גירסת 1.12.7-00 , בהתאם לצורך שלכם – ייתכן ואתם תירצו להתקין גירסה אחרת. שימו לב, במידה ותיבחרו להתקין גירסה מתקדמת יותר, עקבו אחרי ההוראות הנוספות בלינק הזה, הדבר העיקרי הוא שגירסאות מתקדמות יותר לא יעבדו טוב במידה ומוגדר לכם שטח SWAP במערכת ההפעלה, לכן יש קודם לבטל את הSWAP.)
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat << EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet=1.12.7-00 kubeadm=1.12.7-00 kubectl=1.12.7-00
sudo apt-mark hold kubelet kubeadm kubectl
ולאחר מכן נוודא שההתקנה הצליחה על ידי הפקודה הבאה:
תמיד רציתם ממשק GUI שתוכלו לנהל באמצעות את הדוקרים שלכם ואת Docker Swarm? אז תכירו את Portainer!
בעיקרון כמעט כל מה שאתם יכולים לעשות דרך הDocker Command Line אתם יכולים לעשות באמצעות Portainer והבונוס שPortainer בגירסה הקהילתית שלו הוא חינמי לחלוטין
Portainer למעשה הוא קונטיינר בעצמו, לכן ניצור לו קונטיינר שיוכל לרוץ עליו.
הדבר הראשון שנעשה הוא ליצור Volume לPortainer, נריץ את הפקודה:
בשורה הזאת אנו מגדירים לקונטיינר שלנו את הVolume הראשון שלו שהוא בעצם חיבור הSocket לשרת DOCKER שלנו.
-v /var/run/docker.sock:/var/run/docker.sock \
שימו לב לשורה הזאת
v portainer_data:/data portainer/portainer
שבה בעצם אנו מגדירים לקונטיינר לעשות שימוש בVolume שיצרנו בשבילו. את זה אנחנו עושים בשביל לוודא שהתוכן של הקונטיינר שלנו יהיה persistence. כמו כן, אנו חושפים את פורט 9000 בקונטיינר של Portainer לפורט 8080 במחשב שלנו (או בשרת DOCKER).
נריץ את הפקודה הבאה כדי לראות את הקונטיינרים שלנו
docker container ls
ניכנס לכתובת: http://localhost:8080 (במידה ואנו במחשב הפיתוח שלנו) או לכתובת הIP הציבורית של שרת הDocker שלנו ונקבל את המסך בו אנו צריכים להגדיר שם משתמש וסיסמא לפאנל של Portainer
בדוגמה שלנו אנו משתמשים בשרת לוקאלי, לכן נבחר באפשרות Local ונלחץ על Connect.
והרי לנו מסך הבית של Portainer שכבר מציג לנו את שרת הDocker הלוקלאי שלנו
נלחץ לדוגמה על שרת הדוקר הלוקאלי שלנו ונקבל מידע מהיר
כאן אנו רואים כמה קונטיינרים יש לנו בשרת, IMAGES, רשתות, Volumes ועוד. לחיצה על כל אחת מהאפשרות תוביל למידע ואפשרויות נוספות.
כדי ליצור קונטיינר חדש לדוגמה, נלחץ על Containers
ובמסך הבא נלחץ על Add Container
ומשם נוכל ליצור את הקונטיינר שלנו. ממליץ לכם לחקור את כל האפשרויות המדהימות שPortainer נותן לנו ליצירה וניהול. מדובר בלי נוח ומומלץ בחום!
הטריגרים בCodeCommit הם למעשה הייתרון המשמעותית ביותר לשימוש בCodeCommit לניהול הקוד שלנו לעומת שירותים כגון GitHub, GitLab, BitBucket וכו.
טריגרים מאפשרים לנו לבצע פעולות בצורה אוטומטיות כאשר קרה EVENT מסויים בקוד ריפו שלנו ולמעשה הם מופעלים בתגובה לאירועים שקורים בקוד שלנו. לדוגמה, כאשר מישהו דחף (GIT PUSH) שינויים לקוד, או כאשר נוצר(או נמחק) Branch (או (GIT TAG) חדש ועוד נוכל אנחנו והצוות שלנו או כל מי שנירצה לקבל על כך התראה.
דוגמאות:
* יצירת BRANCH חדש יכולה להפעיל טריגר SNS topic על מנת להודיע לכל האנשים הרלוונטיים בצוות שלנו שנוצר Branch חדש כדי שהחברים שלנו יידעו שכדאי להם לעשות git pull למחשב הפיתוח שלהם.
שירותים לדוגמה שהטריגרים יכולים להפעיל עבורנו:
* פונקציות למבדה (Lambada Functions) – וואו, כאן ניתן לעשות כבר דברים מדהימים! * SNS – AWS Simple Notification Service (שליחת הודעה בדואל, SMS וכו), אחד הייתרונות בחיבור לSNS הוא שזה מאפשר לנו להתחבר למעשה לכל השירותים אליהם SNS מתחבר כמו AWS SQS לדוגמה (Aws Simple Queue Service)