ארכיון DevOps

התקנת קוברנטיס

לשם ההדגמה נעבוד עם 3 מכונות וירטואליות, לראשון נקרא k8node1, לשני k8node2 ולשלישי שהוא ישמש כמסטר שלנו נקרא k8master.
3 המכונות האלו מריצות CentOs7.

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

sudo su

על מנת לקבל הרשאות ROOT.

לשם ההדגמה , אנו נבטל את SELinux – שימו לב, לא לעשות את זה בפרודקשיין, זה בשביל להקל על ההדגמה בלבד.

setenforce 0
sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux

בשלב הבא אנו נפעיל את br_netfilter כדי לאפשר תקשורת בין הקלסטרים שלנו, הפקודה בעצם מאפשרת לקוברנטיס לבצע שינויים בIPTABLES.

modprobe br_netfilter
echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables

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

swapoff -a

בנוסף, אנחנו צריכים לערוך את הקובץ fstab, כצעד ראשון נבצע "גיבוי" לקובץ המקורי על ידי הפקודה:

cp /etc/fstab /etc/fstab.orig

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

nano /etc/fstab

ונוסיף # לפני השורה הבאה:

/root/swap swap swap sw 0 0

כך שנקבל את השורה הבאה במקום

#/root/swap swap swap sw 0 0

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

 yum install -y yum-utils device-mapper-persistent-data lvm2

 yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

 yum install -y docker-ce

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

 sed -i '/^ExecStart/ s/$/ --exec-opt native.cgroupdriver=systemd/' /usr/lib/systemd/system/docker.service 

 systemctl daemon-reload

 systemctl enable docker --now

אחרי שסיימנו, נוספיף את הריפו של קוברנטיס על ידי הרצה של הפקודה הבאה:

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
   https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

ומייד לאחר מכן נתקין

 yum install -y kubelet kubeadm kubectl

וכמובן לא נשכח להפעיל אותו

systemctl enable kubelet
systemctl start docker.service

שימו לב! את הפקודות הבאות נריץ רק בשרת המסטר שלנו

kubeadm init --pod-network-cidr=10.244.0.0/16

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

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 172.31.37.95:6443 --token 9mplpv.oxlntc0gz9iukdm3 \
    --discovery-token-ca-cert-hash sha256:429959040fbf2743d9dc2ed67045548057ee2ae4781b5253143d8f93dca3bd0d

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

kubeadm join 172.31.37.95:6443 --token 9mplpv.oxlntc0gz9iukdm3 \
    --discovery-token-ca-cert-hash sha256:429959040fbf2743d9dc2ed67045548057ee2ae4781b5253143d8f93dca3bd0d

לאחר שסיימנו נקיש exit כדי לצאת ממצב ROOT ונריץ את הפקודות הבאות:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

בנוסף נעשה דפלוי לפנל שלנו:

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

ונבדוק את הסטטוס של הקלסטר על ידי הפקודה

kubectl get pods --all-namespaces

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

kubeadm join 172.31.37.95:6443 --token 9mplpv.oxlntc0gz9iukdm3 \
    --discovery-token-ca-cert-hash sha256:429959040fbf2743d9dc2ed67045548057ee2ae4781b5253143d8f93dca3bd0d

ולאחר מכן כשנריץ את הפקודה kubectk get nodes במסטר, אנו אמורים לראות את הנודים האחרים שלנו.

Kubernetes Deployments הוא "כלי" שמאפשר לנו להפוך את תהליך יצירת הPODS שלנו לאוטומטי, אנו מגדירים את המצב (STATE) שאנו מעוניינים שהPOD שלנו יהיה בו, והקלסטר יידאג ליצור, לנהל ולשמור את המצב (STATE) שביקשנו.

דוגמאות לשימוש בDeployment

Scaling
מאפשר לבנו לבחור את מספר הרפליקציות שאנו מעוניינים שהDeployment ייצור לאפלקציה ספציפית. בנוסף ליצירת מס הרפלקציות שביקשנו, הDeployment יוודא שהרפלקציות שלנו יהיו מחולקות בצורה מאוזנת בין הNodes שלנו בשביל זמינות (Availability)

Self-Healing
כשאחד מהPODS שלנו נהרס,או נמחק בטעות, הDeployment ירים אחד חדש במקומו מיידית. אם הגדרתי שאני מעוניין ב6 רפליקציות למערכת שלי, ומחקתי בטעות רפליקה – הDeployment יידאג להרים רפליקה חדשה במקום.

Rolling Updates
בעזרת Deployment, אנו יכולים להחליף/לשנות IMAGE של קונטיינר, הDeployment יחליף קונטיינרים קיימים בגירסה החדשה בשלבים, הסיבה שאנו מעוניינים בכך היא שאם אנו נעשה דפלוי לאפלקציה החדשה שלנו בבת אחת – יהיה זמן מסויים של אי זמינות של המערכת, כאשר אנו עושים את הדפלוי בשלבים – החלפה של IMAGE בזה אחר זה אין לנו מצב של אי זמינות. כשיש לנו גירסה חדשה לאפלקציה שלנו ואנו רוצים לעשות לה דפלוי – אנו נעשה שימוש בDeployment.

הקובץ YAML הבא (נקרא לו example.yaml) למשל, מציין שאנו מעוניינים ב6 רפליקות, ובקונטיינר (במקרה שלנו קונטיינר אחד בלבד) בשם nginx שיריץ …nginx (במקרה שלנו 1.15.4).

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

כדי להפעיל את הדפלוימנט שיצרנו נריץ את הפקודה הבאה

kubectl create -f example.yaml

ונקבל בחזרה שורה שאומרת:
deployment.apps/nginx-deployment created

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

kubectl get deployments

ונקבל במיקרה שלי:

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 6 6 6 6 30s

כדי לקבל מידע נוסף על דפלוימנט ספציפי נריץ את הפקודה הבאה , שימו לב שהפקודה צריכה להכיל את שם הדפלוימנט שאנו מעוניינים לקבל מידע נוסף לגביו, במיקרה שלנו nginx-deployment

kubectl describe deployment nginx-deployment

ועכשיו אנו רואים פרטים מלאים, כמו פורטים, סוג הIMAGE וכו.

אגב, אם נריץ את הפקודה

kubectl get pods

במיקרה שלנו אנו ניראה שיש 6 PODS שרצים (כיון שביקשנו 6 רפליקות).

NAME READY STATUS RESTARTS AGE
nginx-deployment-d55b94fd-8qbrs 1/1 Running 0 100s
nginx-deployment-d55b94fd-9rc4t 1/1 Running 0 100s
nginx-deployment-d55b94fd-dj4lx 1/1 Running 0 100s
nginx-deployment-d55b94fd-g278x 1/1 Running 0 100s
nginx-deployment-d55b94fd-kp4v6 1/1 Running 0 100s
nginx-deployment-d55b94fd-pvq87 1/1 Running 0 100s

אם נמחוק אחד מהPOD שלנו , על ידי הפקודה
kubectl delete nginx-deployment-d55b94fd-8qbrs למשל
אנו ניראה שPOD חדש נוצר במקומו כמעט מיידית כיון שדרשנו שיהיו לנו 6 רפליקות.
ונוכיח את זה על ידי הרצת הפקודה kubectl get pods שוב, ובמיקרה שלי הפלט שהתקבל הוא

nginx-deployment-d55b94fd-9rc4t 1/1 Running 0 2m15s
nginx-deployment-d55b94fd-dj4lx 1/1 Running 0 2m15s
nginx-deployment-d55b94fd-g278x 1/1 Running 0 2m15s
nginx-deployment-d55b94fd-kp4v6 1/1 Running 0 2m15s
nginx-deployment-d55b94fd-pvq87 1/1 Running 0 2m15s
nginx-deployment-d55b94fd-rnnjz 1/1 Running 0 9s

כאשר ניתן לראות שהPOD האחרון נוצר לפני 9 שניות על מנת להחליף את הPOD שמחקתי, לעומת האחרים שנוצרו לפני 2 דקות.

הגדרה וקונפיגורציה של CodeDeploy

שימו לב! המאמר עדיין לא גמור ורק חלק מהשלבים הרלוונטים מפורטים ומוסברים בו.

אנו צריכים ליצור משתמש IAM (משתמש Non-admin) עם פוליסת CodeDeploy על מנת לאפשר לו לנהל את כל מה שקשור לCodeDeploy. לחילופין אנו יכולים לשדך את הפוליסה ל"קבוצה" ולשייך את המשתמש שיצרנו לאותה קבוצה.
יצירת Instance Profile – מאפשר לנו לתת גישה לקוד רפוסיטי שלנו לEC2.
יצירת Service Role – יאפשר לCodeDeploy להתקשר עם שירותים נוספים של AWS
התקנת AWS CLI (מומלץ)

בשלב הראשון ניצור משתמש IAM חדש בשם MyCodeDeployUser

על מנת ליצור פוליסה מתאימה, נלחץ על AMI ואז של Policies.שם נלחץ על Create Policy

ואז נבחר באופציה CodeDeploy ונבחר את הפוליסה בשם "AWSCodeDeployFullAccess" או פוליסה אחרת שמתאימה לנו בהתאם לצורך.

לאחר מכן אנו צריכים להצמיד את הפוליסה למשתמש שאנו מעוניינים שיהיו לו את כל ההרשאות הקשורות לניהול CodeDeploy. נעשה זאת על ידי בחירת המשתמש MyCodeDeployUser תחת משתמשי הIAM שלנו ואז נלחץ על הוספת הרשאות. (בתמונה שם הפוליסה הוא MyCodeDeployPolicy אבל אצלכם שם הפוליסה יהיה AwsCodeDeployFullAccess

הגדרת Service Role מתאים לEC2

ניגש לIAM ואז לRoles, ואז נלחץ על Create Role.
ברשימת השירותים נבחר את השירות CodeDeploy וב Use Case נבחר "CodeDeploy"

ניתן שם לRole ונקרא לו CodeDeployServiceRole

מה זה CodeDeploy

CodeDeploy הוא שירות של AWS שמאפשר לנו להפוך את תהליך הDeployment שלנו לאוטומטי.

ייתרונות:
* Scale – ניתן לעשות דפלוי לשרת אחד או לאלפי שרתים ביחד
* שליטה – מאפשר לנו לקבל עדכונים ודוחות עם מידע לגבי מתי ומה דפלויד למערכת.
* צימצום זמן הDown Time שלנו – מאפשר שיטות דפלוי שונות כמו Rolling Updates ועוד.
* ניתן לעשות שימוש בCodeDeploy בכל שפה או טכנולוגיה – בתנאי שהקוד מנוהל במנוע מסוג GIT כמו CodeCommit לדוגמה או שהקוד שלנו יושב בS3
* ניתן לעשות דפלוי לשרתי EC2, לקונטיינרים או לSERVERLESS

למה אנחנו יכולים לעשות דפלוי?
* כמובן לקוד שלנו
* פונקציות Lambada
* סקריפטים
* קבצי מולטימדיה
ועוד…

התקנת DOCKER בJenkins

על מנת שJENKINS יוכל לעשות דפלוי לאפלקציות בקונטיינרים (Containerized app), אנו צריכים להתקין את DOCKER על השרת שעליו רץ הג'נקינס שלנו.

בשלב הראשון נתקין את DOCKER ונפעיל את השירות

sudo yum -y install docker
sudo systemctl start docker
sudo systemctl enable docker

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

sudo groupadd docker
sudo usermod -aG docker jenkins

נפעיל מחדש את השירות JENKINS ואת DOCKER

sudo systemctl restart jenkins
sudo systemctl restart docker

זהו, ככה פשוט.

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

קצת על 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.

על 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.

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

להמשיך לקרוא

קטגוריה: DevOps

התקנת קוברנטיס

קצת על Kubernetes Deployments

הגדרה וקונפיגורציה של CodeDeploy

מה זה CodeDeploy

התקנת DOCKER בJenkins

קצת על Jenkins Pipelines

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

השלבים:

יצירת Access Token

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

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

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

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

מה זה Gradle Build?