2019 - TechSense

קצת על Jenkins Pipelines

Jenkins Piplines הם שילוב של פלאגינים של ג'נקינס שעוזרים לנו לממש Continuous Delivery בג'נקינס.

Pipline הוא תהליך אוטומטי שלוקח את קוד המקור שלנו דרך ה"Pipline" – עד לפרודקשין. בדרכ נממש בו לפחות 3 שלבים (STAGES),
Build, Test , Deploy.

קובץ הpipline נקרא Jenkinsfile ואנו שומרים אותו במערכת הSource Control שלנו ביחד עם קוד האפלקציה שלנו.

כדי ליצור Pipline חדש, כל שאנו צריכים לעשות הוא ליצור קובץ Jenkinsfile ולהוסיף אותו לGIT ריפו שלנו, לאחר מכן כשאנו יוצרים פרויקט ג'נקינס חדש – נבחר הפעם פרויקט מסוג Pipline או Multibranch Pipline.

דוגמה לpipline מסוג Declarative שלא עושה כלום מלבד ECHO של 3 השלבים (Stages):

pipeline {
    agent any 
    stages {
        stage('Build') { 
            steps {
                echo 'Building...' 
            }
        }
        stage('Test') { 
            steps {
                echo 'Testing...' 
            }
        }
        stage('Deploy') { 
            steps {
                echo 'Deploying!' 
            }
        }
    }
}

כל שלב או תהליך (STAGE) מכיל בתוכו "צעדים" (STEPS), לדוגמה צעד ראשון: להריץ פקודה מסויימת, צעד שני: להעתיק את הקבצים לשרת, צעד שלישי: לאתחל את APACHE.

לקריאה נוספת:
1. איך להתקין Jenkins בCentOS7
2. יצירת Jenkins Job פשוט שמושך קבצים מGIT
3. על Jenkins וWebHooks – עדכון אוטומטי כאשר מתבצע שינוי בקוד בריפו שלנו
4. קצת על Jenkins Pipelines
5. התקנת DOCKER בJenkins

על Jenkins וWebHooks – עדכון אוטומטי כאשר מתבצע שינוי בקוד בריפו שלנו

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

השלבים:

יצירת Access Token בחשבון הגיטאהב שלנו עם הרשאות לקרוא ולכתוב לWebHooks + הוספת שרת גיטאהב לJenkins על מנת שינהל עבורנו WEBHOOKS בגיטאהב.
יצירת Jenkins Job מתאים.
הגדרת הWEBHOOK בגיט רפו שלנו.

יצירת Access Token

בתפריט ההגדרות של הגיטאהב שלכם (https://g ithub.com/settings/profile) ליחצו בתפריט על "Developer Settings" – ואז על "Personal access tokens"
https://github.com/settings/tokens

לאחר מכן ליחצו על "Generate New Token".
בטופס שקיבלנו נמלא את הפרטים, בNOTE אני כתבתי "Jenkins Test" ובהרשאות יש לסמן "admin:repo_hook"

ואז נילחץ על הכפתור הירוק "Generate Token".

נעתיק את הAPI KEY שקיבלנו – אנו ניצטרך אותו כאשר נגדיר את הJOB בJenkins.
בתפריט הJenkins שלנו נלחץ על "Manage Jenkins"

ואז נלחץ על "Configure System"

נגלול למטה עד שנגיע ל"GitHub Servers" ונמלא את הפרטים.

נלחץ על "Add" שליד "Credentials" ובתפריט דרופדאון של הKIND נבחר SECRET KEY. בSECRET נדביק את הAPI KEY שקיבלנו. בID אני הזנתי github_key ובתיאור נזין מה שנוח לנו. במקרה שלי הזנתי GitHub Key

לאחר שסיימנו נלחץ על Add. ואז נסמן V ליד "Manage hooks". כמו כן בדרופ דאון של ה"Credentials" נסמן את הקי החדש שהוספנו שקראתי לו "GitHub Key"

נלחץ על הכפתור "Test Connection" כדי לוודא שהכל פועל כשורה, במיקרה שלי קיבלתי בחזרה: Credentials verified for user avivronen, rate limit: 4998

נלחץ על SAVE.

סיימנו את השלב הראשון, עכשיו שרת הJENKINS שלנו יכול לתקשר ישירות עם GITHUB וליצור ולנהל עבורנו WEBHOOKS.

שלב 2 – יצירת Jenkins Job

ניצור ג'וב חדש לפי השלבים שרשומים כאן, רק שהפעם, בגיטריפו נזין גיט ריפו שלנו שיש לנו הרשאות אליה, במיקרה שלי: "https://github.com/avivronen/php-docs-hello-world" (הריפו הזה זה פורק של הריפו שהשתמשנו בו במדריך הקודם) ובנוסף נסמן V ליד "GitHub hook trigger for GITScm polling". ונלחץ על SAVE.

שלב 3: הגדרת WEBHOOK בריפו שלנו.

נחזור לריפו שלנו בגיטאהב, נלחץ על SETTINGS, ואז נלחץ על Web hooks.
ושימו לב, שכבר עכשיו תוכלו לראות את הWEBHOOK שנוצר אוטומטית על ידי הJENKIN שלנו.
ברגע שתעשו COMMIT לריפו שלכם, הBUILD בגנקינס ירוץ אוטומטית. בהצלחה!

יצירת Jenkins Job פשוט שמושך קבצים מGIT

במקרה שלי, כדי שהJOB יוכל למשוך את הקבצים מGIT הייתי צריך להתקין בשרת את ..גיט..על ידי הפקודה הפשוטה

sudo yum install git

בתפריט הצדדי נבחר ב"New Item"

נבחר שם לJOB שלנו (במקרה שלי "demojob"), ובאפשרויות נבחר Freestyle Project

באפשרות Source Code Managment נבחר בGIT

ב "Repository URL" נזין את הכתובת

https://github.com/Azure-Samples/php-docs-hello-world.git

את הBranch נשאיר בMaster.

לאחר שסיימנו נלחץ על "Save".

אם נלחץ בתפריט הצדדי על "Build Now" , הJOB ירוץ ולאחר שיסיים במידה ונקליד את 2 הפקודות הבאות בשרת שלנו:


cd /var/lib/jenkins/workspace/demojob
ls -la

נוכל לראות שאכן הJOB משך בהצלחה את הקבצים מהGIT REPO והם נמצאים בתיקייה של הJOB.

total 16
drwxr-xr-x. 3 jenkins jenkins   85 Dec 23 11:32 .
drwxr-xr-x. 3 jenkins jenkins   21 Dec 23 11:32 ..
drwxr-xr-x. 8 jenkins jenkins  162 Dec 23 11:32 .git
-rw-r--r--. 1 jenkins jenkins  251 Dec 23 11:32 .gitignore
-rw-r--r--. 1 jenkins jenkins   28 Dec 23 11:32 index.php
-rw-r--r--. 1 jenkins jenkins 1183 Dec 23 11:32 LICENSE
-rw-r--r--. 1 jenkins jenkins  684 Dec 23 11:32 README.md

מצאתם טעות? הערות? שאלות? הסתדרתם? נתקעתם? כתבו לי בתגובות!

איך להתקין Jenkins בCentOS7

בדוגמא הנל, אני עובד כroot אך ורק משיקולי נוחות של סביבת בדיקה זמנית ולוקאלית, מומלץ לעבוד עם משתמש רגיל ולבקש הרשאות root על ידי sudo.

נריץ את הפקודות הבאות:

בשלב הראשון עלינו להתקין את Java SDK

yum install java-1.8.0-openjdk

נוכל לוודא את ההתקנה על ידי הפקודה

java -version

הפלט של הפקודה הנל אמור להראות כך:

[root@localhost ~]# java -version
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (build 1.8.0_232-b09)
OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)

נוסיף את הריפו של ג'נקינס:

sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo
sudo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key

ולאחר מכן נוכל להתקין את ג'נקינס:

sudo yum install jenkins

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

sudo systemctl enable jenkins
sudo systemctl start jenkins

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

firewall-cmd --permanent --new-service=jenkins
firewall-cmd --permanent --service=jenkins --set-short="Jenkins Service Ports"
firewall-cmd --permanent --service=jenkins --set-description="Jenkins service firewalld port exceptions"
firewall-cmd --permanent --service=jenkins --add-port=8080/tcp
firewall-cmd --permanent --add-service=jenkins
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload

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

כדי לקבל את קוד האימות נריץ את הפקודה:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

נעקוב אחרי המשך ההוראות – וסיימנו. ככה פשוט.

מדריך התקנה באתר ג'נקינס הרשמי: https://jenkins.io/doc/book/installing/
מדריך התקנה בגנקינס WIKI להפצות רד הט: https://wiki.jenkins.io/display/JENKINS/Installing+Jenkins+on+Red+Hat+distributions

מצאתם טעות? הערות? שאלות? הסתדרתם? נתקעתם? כתבו לי בתגובות!

מה זה Gradle Build?

Gradle Build מוגדר בקובץ בשם build.gradle (בשפת גרובי או קוטלין) שממוקם בתיקיית הROOT של הפרויקט.
על ידי הפקודה:

gradle init

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

כל gradle build מוגדר בעצם מ"משימות" – gradle tasks. כדי להריץ "משימה" ספציפית נריץ את הקוד הבא (בהנחה ושם המשימה שלנו הוא "sampletask1"

./gradlew sampletask1

קובץ הbuild.gradle שלנו בעצם אמור להכיל את כל המשימות שזמינות לפרויקט שלנו.

בדוגמה הבאה למשל ניצור "משימה" שקוראים לה "sampletask1" שכל מה שהיא עושה זה להדפיס את המילה "ישראל"

task sampletask1 {
  println 'Israel'
}

ניתן בנוסף להגדיר משימות שתלויות – Dependencies – במשימות אחרות, לדוגמה נוכל להגדיר 2 משימות, האחת בשם task1 והשנייה בשם task2 כאשר task2 תלויה במשימה task1, דהיינו המשימה task1 תהיה חייבת לרוץ ולהצליח לפני המשימה task2.

בנוסף לGradle יש המון תוספים – plugins שיכולים לעזור לנו בהמון מצבים, את התוספים אפשר לכלול בקובץ build.gradle שלנו , לדוגמה על ידי השורות הבאות

plugins {
 id "<plugin id here>" version "<plugin version here">
}

קובץ build לדוגמה:


/*
 * This file was generated by the Gradle 'init' task.
 *
 * This is a general purpose Gradle build.
 * Learn how to create Gradle builds at https://guides.gradle.org/creating-new-gradle-builds
 */

task sayIsrael << {
 println 'Israel'
}

task task2 {
 println 'task task2 is here'
}

הקובץ מכיל 2 משימות, האחת בשם sayIsrael שמדפיסה Israel ומשימה שנייה בשם task2 שמדפיסה 'task task2 is here'

אם נריץ את הפקודה:

./gradlew sayIsrael

נקבל

[aviv@localhost test1]$ ./gradlew sayIsrael

> Configure project :
Israel
task task2 is here

BUILD SUCCESSFUL in 1s

וכשנריץ

./gradlew task2

נקבל:

[aviv@localhost test1]$ ./gradlew task2

> Configure project :
Israel
task task2 is here

BUILD SUCCESSFUL in 1s

כשנוסיף לקובץ בילד שלנו לדוגמה את השורה
sayIsrael.dependsOn task2
ונריץ שוב את המשימה sayIsrael נקבל הפעם

[aviv@localhost test1]$ ./gradlew -q sayIsrael
Israel
task task2 is here

למרות שהרצנו לכאורה רק את המשימה sayIsrael.

מצאתם טעות? הערות? שאלות? הסתדרתם? נתקעתם? כתבו לי בתגובות!

להמשיך לקרוא

איך להתקין Gradle בCentos7

נריץ את הפקודות הבאות:

cd ~/
wget -O ~/gradle-bin.zip https://services.gradle.org/distributions/gradle-6.0.1-bin.zip
sudo yum -y install unzip java-1.8.0-openjdk
sudo mkdir /opt/gradle
sudo unzip -d /opt/gradle/ ~/gradle-bin.zip

נערוך את הקובץ gradle.sh על ידי הפקודה הבאה:

sudo nano /etc/profile.d/gradle.sh

ונכתוב לקובץ את השורה הבאה:

export PATH=$PATH:/opt/gradle/gradle-6.0.1/bin

ניתן הרשאות מתאימות לקובץ gradle.sh

sudo chmod 755 /etc/profile.d/gradle.sh

אחרי שעשינו 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

לאתר Gradle
https://gradle.org/

מצאתם טעות? הערות? שאלות? הסתדרתם? נתקעתם? כתבו לי בתגובות!

להמשיך לקרוא

Networking בקוברנטיס – איך Pods מדברים בניהם – מבט בסיסי

לקריאה מקדימה:
* קצת על קוברנטיס
* מה זה Node וקלסטרינג בקוברנטיס
* מה זה POD?
* איך ליצור קוברנטיס קלסטר בסיסי בקלות?

קוברנטיס מאפשר לנו ליצור Virtual Network שפועל בכל הקלסטר שלנו, כל Pod בקלסטר מקבל כתובת IP ייחודית ויכול לתקשר עם כל pod אחר בקלסטר – גם במיקרה שהPod רץ בNode אחר.

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

הקובץ Yaml הבא יוצר לדוגמה 3 Pods (להלן 3 רפליקות), כאשר כל POD יריץ קונטיינר (Docker) של Nginx

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

אנו ניצור POD נוסף שיריץ busybox , באמצעותו נוכל לבדוק את הקישוריות שלנו בין הPODS השונים (נשתמש בCURL).

apiVersion: v1
kind: Pod
metadata:
  name: avivbusybox
spec:
  containers:
  - name: avivbusybox
    image: radial/busyboxplus:curl
    args:
    - sleep
    - "2000"

לאחר מכן נריץ את הפקודה הבאה כדי לקבל רשימה של ה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 בוצעה בהצלחה.

לקריאה נוספת:
* הגדרות רשת עם Flannel
* https://kubernetes.io/docs/concepts/cluster-administration/networking/
* https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/
* https://github.com/coreos/flannel

מצאתם טעות? הערות? שאלות? הסתדרתם? נתקעתם? כתבו לי בתגובות!

קצת על קוברנטיס (Kubernetes)

קוברנטיס הוא כלי לאוטומטציה וניהול של קונטיינרים.

ההיררכיה בקוברנטיס היא:
Cluster – > Node – > Pod

למה אנחנו צריכים אותו?

לאפשר לקונטיינרים לתקשר בניהם כאשר הם נמצאים ב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. כדי לראות אותו נריץ את הפקודה:

sudo systemctl status kubelet

מצאתם טעות? הערות? שאלות? הסתדרתם? נתקעתם? כתבו לי בתגובות!

מה זה Node וקלסטרינג בקוברנטיס

באחד המדריכים, יצרנו קוברנטיס קלסטר עם 3 Nodes, כל Node הוא בעצם שרת/מכונה שמריץ קונטיינרים (Pod).

לכל קוברנטיס קלסטר חייב להיות לפחות Node אחד שהוא יהיה הNode המנהל – הוא מריץ בתוכו את הKubernetes API ואת שאר כלי הניהול של קוברנטיס, שאר הNodes מכונים Workers.

כל Node מורכב מPod אחד או יותר.

כדי לראות את רשימת הNodes שלנו נריץ את הפקודה הבאה:

kubectl get nodes

כדי לקבל פרטים נוספים על Node ספציפי נריץ את הפקודה הבאה:

kubectl describe node $our_node_name

כאשר $our_node_name מייצג את שם הNode הספציפי.

מה זה Kubernetes Pod?

יצירת kubernetes קלסטר בסיסי בקלות

מצאתם טעות? הערות? שאלות? הסתדרתם? נתקעתם? כתבו לי בתגובות!

מה זה Kubernetes Pod?

Pods הוא היחידה הבסיסית ביותר של קוברנטיס. כל Pod מורכב מקונטיינר אחד או יותר (בדרכ יש קונטיינר אחד בכל POD אבל ניתן שיהיה יותר מקונטיינר אחד), כתובת IP בתוך הקוברנטיס קלסטר ואיחסון (Storage).
כל Pod אחד או יותר יוצרים ביחד Node. קלסטר מורכב מNode אחד או יותר.

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

כדי ליצור POD, אנו משתמשים בקובץ YAML שמכיל את הפרטים של אותו POD.
לדוגמא, אם נירצה ליצור POD שמריץ קונטיינר Nginx ניצור קובץ בשם ourtamlefilename.yaml לדוגמא עם הפרטים הבאים:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx

בקובץ הנל, אנו בעצם מבקשים ליצור POD בשם nginx, ובנוסף מבקשים לבנות בו דוקר קונטיינר בשם nginx כאשר אנו מציינים לדוקר להשתמש בimage של nginx.

ואז נריץ את הפקודה

kubectl create -f ouryamlfilename.yaml

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

cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
EOF

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

כדי לראות את כל הPods הקיימים שלנו נריץ את הפקודה

kubectl get pods

וכדי לראות פרטים נוספים אודות POD נריץ את הפקודה הבאה כאשר במקרה שלנו nginx זהו שם הPod שלנו

kubectl describe pod nginx

למחיקת הPOD שלנו נשתמש בפקודה הבאה:

kubectl delete pod nginx

מצאתם טעות? הערות? שאלות? הסתדרתם? נתקעתם? כתבו לי בתגובות!