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

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

ניסיתי לבנות תהליך דומה מאפס, אבל בנוי כולו על Gitlab CI וכלים חינמיים שבהם אני רגיל להשתמש כדי לפרוס יישומים ל-Kubernetes. היום סוף סוף אספר לכם יותר עליהם.

המאמר ידון בכלים כגון:
הוגו, qbec, קאניקו, git-crypt и GitLab CI עם יצירת סביבות דינמיות.

תוֹכֶן

1. הכירו את הוגו
2. הכנת ה-Dockerfile
3. היכרות עם קניקו
4. היכרות עם qbec
5. מנסה Gitlab-ranner עם Kubernetes-executor
6. פריסת תרשימי Helm עם qbec
7. היכרות עם git-crypt
8. יצירת תמונת ארגז כלים
9. הצינור הראשון שלנו והרכבת תמונות לפי תגים
10. אוטומציה של פריסה
11. חפצים והרכבה בעת דחיפה למאסטר
12. סביבות דינמיות
13. סקור אפליקציות

1. היכרות עם הוגו

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

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

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

אתה יכול להתקין את הוגו באופן מקומי ולנסות את זה:

אתחול אתר חדש:

hugo new site docs.example.org

ובאותו הזמן מאגר git:

cd docs.example.org
git init

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

לנושא בו נשתמש ללמוד, שלדעתי מתאים באופן מושלם לאתר תיעוד.

ברצוני להקדיש תשומת לב מיוחדת לעובדה שאיננו צריכים לשמור את קבצי ערכת הנושא במאגר של הפרויקט שלנו; במקום זאת, אנו יכולים פשוט לחבר אותו באמצעות תת מודול git:

git submodule add https://github.com/matcornic/hugo-theme-learn themes/learn

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

בוא נתקן את התצורה config.toml:

baseURL = "http://docs.example.org/"
languageCode = "en-us"
title = "My Docs Site"
theme = "learn"

כבר בשלב זה ניתן להריץ:

hugo server

ובכתובת http://localhost:1313/ בדוק את האתר החדש שלנו שנוצר, כל השינויים שנעשו בספרייה מעדכנים אוטומטית את הדף הפתוח בדפדפן, מאוד נוח!

בואו ננסה ליצור דף שער ב content/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

צילום מסך של הדף החדש שנוצר

כדי ליצור אתר, פשוט הפעל:

hugo

תוכן המדריך ציבורי / ויהיה אתר האינטרנט שלך.
כן, אגב, מיד נוסיף את זה .גניטור:

echo /public > .gitignore

אל תשכח לבצע את השינויים שלנו:

git add .
git commit -m "New site created"

2. הכנת ה-Dockerfile

הגיע הזמן להגדיר את מבנה המאגר שלנו. אני בדרך כלל משתמש במשהו כמו:

.
├── deploy
│   ├── app1
│   └── app2
└── dockerfiles
    ├── image1
    └── image2

• dockerfiles/ - מכיל ספריות עם Dockerfiles וכל הדרוש לבניית תמונות Docker שלנו.
• לפרוס/ - מכיל ספריות לפריסת היישומים שלנו ל-Kubernetes

לפיכך, ניצור את ה-Dockerfile הראשון שלנו לאורך הנתיב dockerfiles/website/Dockerfile

FROM alpine:3.11 as builder
ARG HUGO_VERSION=0.62.0
RUN wget -O- https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz -C /usr/local/bin
ADD . /src
RUN hugo -s /src

FROM alpine:3.11
RUN apk add --no-cache darkhttpd
COPY --from=builder /src/public /var/www
ENTRYPOINT [ "/usr/bin/darkhttpd" ]
CMD [ "/var/www" ]

כפי שאתה יכול לשים לב, Dockerfile מכיל שניים מן, תכונה זו נקראת בנייה רב שלבית ומאפשר לך לא לכלול כל מיותר מתמונת הדוקר הסופית.
לפיכך, התמונה הסופית תכיל רק darkhttpd (שרת HTTP קל משקל) ו ציבורי / - התוכן של אתר האינטרנט שלנו שנוצר באופן סטטי.

אל תשכח לבצע את השינויים שלנו:

git add dockerfiles/website
git commit -m "Add Dockerfile for website"

3. היכרות עם קניקו

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

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

docker run -ti --rm 
  -v $PWD:/workspace 
  -v ~/.docker/config.json:/kaniko/.docker/config.json:ro 
  gcr.io/kaniko-project/executor:v0.15.0 
  --cache 
  --dockerfile=dockerfiles/website/Dockerfile 
  --destination=registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1

שם registry.gitlab.com/kvaps/docs.example.org/website - שם תמונת ה- Docker שלך; לאחר הבנייה, היא תושק אוטומטית ל- Docker Registry.

פרמטר --מטמון מאפשר לך לשמור שכבות במטמון ברישום docker; עבור הדוגמה שניתנה, הן יישמרו ב registry.gitlab.com/kvaps/docs.example.org/website/cache, אבל אתה יכול לציין נתיב אחר באמצעות הפרמטר --cache-repo.

צילום מסך של docker-registry

4. היכרות עם qbec

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

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

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

כפי שאמרתי קודם, נאחסן את כל הפריסות בספרייה לפרוס/:

mkdir deploy
cd deploy

בואו נתחיל את האפליקציה הראשונה שלנו:

qbec init website
cd website

כעת המבנה של האפליקציה שלנו נראה כך:

.
├── components
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
└── qbec.yaml

בואו נסתכל על הקובץ qbec.yaml:

apiVersion: qbec.io/v1alpha1
kind: App
metadata:
  name: website
spec:
  environments:
    default:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443
  vars: {}

כאן אנחנו מתעניינים בעיקר spec.environments, qbec כבר יצרה עבורנו סביבת ברירת מחדל ולקחה את כתובת השרת, כמו גם את מרחב השמות מה-kubeconfig הנוכחי שלנו.
כעת בעת פריסה ל ברירת מחדל סביבת, qbec תמיד יפרוס רק לאשכול Kubernetes שצוין ולמרחב השמות שצוין, כלומר, אינך צריך עוד לעבור בין הקשרים ומרחבי שמות כדי לפרוס.
במידת הצורך, תמיד תוכל לעדכן את ההגדרות בקובץ זה.

כל הסביבות שלך מתוארות ב qbec.yaml, ובקובץ params.libsonnet, שם כתוב היכן ניתן להשיג את הפרמטרים עבורם.

לאחר מכן אנו רואים שתי ספריות:

• רכיבים / - כל המניפסטים עבור האפליקציה שלנו יאוחסנו כאן; ניתן לתאר אותם הן בקבצי jsonnet והן בקבצי yaml רגילים
• סביבות/ - כאן נתאר את כל המשתנים (פרמטרים) עבור הסביבות שלנו.

כברירת מחדל יש לנו שני קבצים:

• environments/base.libsonnet - הוא יכיל פרמטרים משותפים לכל הסביבות
• environments/default.libsonnet - מכיל פרמטרים שנדחקו עבור הסביבה ברירת מחדל

בואו נפתח environments/base.libsonnet והוסיפו פרמטרים עבור הרכיב הראשון שלנו שם:

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1',
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

בואו גם ניצור את הרכיב הראשון שלנו רכיבים/website.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.website;

[
  {
    apiVersion: 'apps/v1',
    kind: 'Deployment',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      replicas: params.replicas,
      selector: {
        matchLabels: {
          app: params.name,
        },
      },
      template: {
        metadata: {
          labels: { app: params.name },
        },
        spec: {
          containers: [
            {
              name: 'darkhttpd',
              image: params.image,
              ports: [
                {
                  containerPort: params.containerPort,
                },
              ],
            },
          ],
          nodeSelector: params.nodeSelector,
          tolerations: params.tolerations,
          imagePullSecrets: [{ name: 'regsecret' }],
        },
      },
    },
  },
  {
    apiVersion: 'v1',
    kind: 'Service',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      selector: {
        app: params.name,
      },
      ports: [
        {
          port: params.servicePort,
          targetPort: params.containerPort,
        },
      ],
    },
  },
  {
    apiVersion: 'extensions/v1beta1',
    kind: 'Ingress',
    metadata: {
      annotations: {
        'kubernetes.io/ingress.class': params.ingressClass,
      },
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      rules: [
        {
          host: params.domain,
          http: {
            paths: [
              {
                backend: {
                  serviceName: params.name,
                  servicePort: params.servicePort,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

בקובץ זה תיארנו שלוש ישויות Kubernetes בבת אחת, אלה הן: פְּרִיסָה, שֵׁרוּת и Ingress. אם היינו רוצים, יכולנו להכניס אותם למרכיבים שונים, אבל בשלב זה אחד יספיק לנו.

תחביר jsonnet דומה מאוד ל-json הרגיל, באופן עקרוני, json הרגיל כבר תקף ל-jsonnet, כך שבהתחלה אולי יהיה לך קל יותר להשתמש בשירותים מקוונים כמו yaml2json כדי להמיר את ה-yaml הרגיל שלך ל-json, או, אם הרכיבים שלך אינם מכילים משתנים כלשהם, ניתן לתאר אותם בצורה של yaml רגיל.

כשעובדים עם jsonnet אני ממליץ בחום להתקין תוסף עבור העורך שלך

לדוגמה, יש תוסף עבור vim vim-jsonnet, אשר מפעיל את הדגשת תחביר ומבצע אוטומטית jsonnet fmt בכל פעם שאתה שומר (דורש מותקן jsonnet).

הכל מוכן, עכשיו אנחנו יכולים להתחיל לפרוס:

כדי לראות מה יש לנו, בואו נרוץ:

qbec show default

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

נהדר, עכשיו החל:

qbec apply default

בפלט תמיד תראה מה ייעשה באשכול שלך, qbec תבקש ממך להסכים לשינויים על ידי הקלדה y תוכל לאשר את כוונותיך.

האפליקציה שלנו מוכנה ופריסה!

אם תבצע שינויים, אתה תמיד יכול לעשות:

qbec diff default

כדי לראות כיצד שינויים אלה ישפיעו על הפריסה הנוכחית

אל תשכח לבצע את השינויים שלנו:

cd ../..
git add deploy/website
git commit -m "Add deploy for website"

5. מנסה את Gitlab-ranner עם Kubernetes-executor

עד לאחרונה השתמשתי רק ברגיל gitlab-ranner על מכונה מוכנה מראש (מיכל LXC) עם מעטפת או docker-executor. בתחילה, היו לנו כמה רצים כאלה שהוגדרו ברחבי העולם ב-gitlab שלנו. הם אספו תמונות דוקר עבור כל הפרויקטים.

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

למרבה המזל, זו אינה בעיה כלל, שכן כעת אנו נפרוס gitlab-ranner ישירות כחלק מהפרויקט שלנו ממש ב-Kubernetes.

Gitlab מספק תרשים הגה מוכן לפריסת gitlab-runner ל-Kubernetes. אז כל מה שאתה צריך לעשות זה לברר אסימון רישום עבור הפרויקט שלנו ב הגדרות -> CI / CD -> רצים והעבירו אותו להגה:

helm repo add gitlab https://charts.gitlab.io

helm install gitlab-runner 
  --set gitlabUrl=https://gitlab.com 
  --set runnerRegistrationToken=yga8y-jdCusVDn_t4Wxc 
  --set rbac.create=true 
  gitlab/gitlab-runner

איפה:

• https://gitlab.com - הכתובת של שרת Gitlab שלך.
• yga8y-jdCusVDn_t4Wxc - אסימון רישום עבור הפרויקט שלך.
• rbac.create=true - מספק לרץ את כמות ההרשאות הדרושה כדי להיות מסוגל ליצור פודים לביצוע המשימות שלנו באמצעות kubernetes-executor.

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

צילום מסך של הרץ שנוסף

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

6. פרוס תרשימי Helm עם QBEC

מאז החלטנו לשקול gitlab-ranner חלק מהפרויקט שלנו, הגיע הזמן לתאר אותו במאגר Git שלנו.

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

cd deploy
qbec init gitlab-runner
cd gitlab-runner

הפעם לא נתאר ישויות Kubernetes באופן ידני, אלא ניקח תרשים Helm מוכן. אחד היתרונות של qbec הוא היכולת להציג תרשימי Helm ישירות ממאגר Git.

בואו נחבר אותו באמצעות תת-מודול git:

git submodule add https://gitlab.com/gitlab-org/charts/gitlab-runner vendor/gitlab-runner

עכשיו הספרייה ספק/gitlab-ranner יש לנו מאגר עם תרשים עבור gitlab-runner.

באופן דומה, ניתן לחבר מאגרים אחרים, למשל, את כל המאגר עם תרשימים רשמיים https://github.com/helm/charts

בואו נתאר את הרכיב רכיבים/gitlab-runner.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.gitlabRunner;

std.native('expandHelmTemplate')(
  '../vendor/gitlab-runner',
  params.values,
  {
    nameTemplate: params.name,
    namespace: env.namespace,
    thisFile: std.thisFile,
    verbose: true,
  }
)

הטיעון הראשון ל expandHelmTemplate אז נעביר את השביל לתרשים params.values, שאנו לוקחים מפרמטרי הסביבה, ואז מגיע האובייקט איתו

• nameTemplate - כותרת ההפצה
• מרחב שמות - מרחב השמות הועבר להגה
• הקובץ הזה - פרמטר נדרש המעביר את הנתיב לקובץ הנוכחי
• מִלוּלִי - מציג את הפקודה תבנית הגה עם כל הטיעונים בעת עיבוד התרשים

כעת נתאר את הפרמטרים עבור הרכיב שלנו ב environments/base.libsonnet:

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
      },
    },
  },
}

שים לב runnerRegistrationToken אנחנו לוקחים מקובץ חיצוני secrets/base.libsonnet, בואו ניצור אותו:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

בוא נבדוק אם הכל עובד:

qbec show default

אם הכל תקין, אז נוכל למחוק את המהדורה שנפרסה בעבר דרך Helm:

helm uninstall gitlab-runner

ופרוס אותו באותו אופן, אבל דרך qbec:

qbec apply default

7. מבוא ל-git-crypt

Git-crypt הוא כלי המאפשר לך להגדיר הצפנה שקופה עבור המאגר שלך.

כרגע, מבנה הספריות שלנו עבור gitlab-runner נראה כך:

.
├── components
│   ├── gitlab-runner.jsonnet
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
├── qbec.yaml
├── secrets
│   └── base.libsonnet
└── vendor
    └── gitlab-runner (submodule)

אבל אחסון סודות ב-Git זה לא בטוח, נכון? אז אנחנו צריכים להצפין אותם כראוי.

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

יתר על כן, במקרה זה לא אוכל לספר לך על כלי נפלא כמו git-crypt.

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

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

git crypt init

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

git-crypt add-gpg-user [email protected]

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

אם אין לך מפתח PGP ואינך מצפה לו, אז אתה יכול ללכת בדרך אחרת ולייצא את מפתח הפרויקט:

git crypt export-key /path/to/keyfile

לפיכך, כל מי שיש לו מיוצא קובץ מפתח יוכל לפענח את המאגר שלך.

הגיע הזמן להגדיר את הסוד הראשון שלנו.
הרשו לי להזכיר לכם שאנחנו עדיין במדריך deploy/gitlab-runner/, שבו יש לנו ספרייה סודות/, בואו נצפין את כל הקבצים בו, לשם כך ניצור קובץ secrets/gitattributes עם התוכן הבא:

* filter=git-crypt diff=git-crypt
.gitattributes !filter !diff

כפי שניתן לראות מהתוכן, כל הקבצים מכוסים * יוסע דרך git-crypt, חוץ מהרוב תכונות

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

git crypt status -e

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

זה הכל, עכשיו אנחנו יכולים לבצע את השינויים שלנו בבטחה:

cd ../..
git add .
git commit -m "Add deploy for gitlab-runner"

כדי לחסום מאגר, פשוט הרץ:

git crypt lock

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

git crypt unlock

8. צור תמונת ארגז כלים

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

הכל פשוט כאן, בואו ניצור אחד חדש dockerfiles/toolbox/Dockerfile עם התוכן הבא:

FROM alpine:3.11

RUN apk add --no-cache git git-crypt

RUN QBEC_VER=0.10.3 
 && wget -O- https://github.com/splunk/qbec/releases/download/v${QBEC_VER}/qbec-linux-amd64.tar.gz 
     | tar -C /tmp -xzf - 
 && mv /tmp/qbec /tmp/jsonnet-qbec /usr/local/bin/

RUN KUBECTL_VER=1.17.0 
 && wget -O /usr/local/bin/kubectl 
      https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VER}/bin/linux/amd64/kubectl 
 && chmod +x /usr/local/bin/kubectl

RUN HELM_VER=3.0.2 
 && wget -O- https://get.helm.sh/helm-v${HELM_VER}-linux-amd64.tar.gz 
     | tar -C /tmp -zxf - 
 && mv /tmp/linux-amd64/helm /usr/local/bin/helm

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

כמו כן, על מנת להיות מסוגלים לתקשר עם Kubernetes ולפרוס אליו, עלינו להגדיר תפקיד עבור הפודים שנוצרו על ידי gitlab-runner.

כדי לעשות זאת, בוא נלך לספרייה עם gitlab-runner:

cd deploy/gitlab-runner

ולהוסיף רכיב חדש רכיבים/rbac.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.rbac;

[
  {
    apiVersion: 'v1',
    kind: 'ServiceAccount',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'Role',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    rules: [
      {
        apiGroups: [
          '*',
        ],
        resources: [
          '*',
        ],
        verbs: [
          '*',
        ],
      },
    ],
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'RoleBinding',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    roleRef: {
      apiGroup: 'rbac.authorization.k8s.io',
      kind: 'Role',
      name: params.name,
    },
    subjects: [
      {
        kind: 'ServiceAccount',
        name: params.name,
        namespace: env.namespace,
      },
    ],
  },
]

נתאר גם את הפרמטרים החדשים ב environments/base.libsonnet, שנראה כעת כך:

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
        runners: {
          serviceAccountName: $.components.rbac.name,
          image: 'registry.gitlab.com/kvaps/docs.example.org/toolbox:v0.0.1',
        },
      },
    },
    rbac: {
      name: 'gitlab-runner-deploy',
    },
  },
}

שים לב $.components.rbac.name מתייחס ל שם עבור רכיב rbac

בוא נבדוק מה השתנה:

qbec diff default

והחל את השינויים שלנו על Kubernetes:

qbec apply default

כמו כן, אל תשכח לבצע את השינויים שלנו ב-git:

cd ../..
git add dockerfiles/toolbox
git commit -m "Add Dockerfile for toolbox"
git add deploy/gitlab-runner
git commit -m "Configure gitlab-runner to use toolbox"

9. הצינור הראשון שלנו והרכבה של תמונות לפי תגים

בשורש הפרויקט ניצור .gitlab-ci.yml עם התוכן הבא:

.build_docker_image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug-v0.15.0
    entrypoint: [""]
  before_script:
    - echo "{"auths":{"$CI_REGISTRY":{"username":"$CI_REGISTRY_USER","password":"$CI_REGISTRY_PASSWORD"}}}" > /kaniko/.docker/config.json

build_toolbox:
  extends: .build_docker_image
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR/dockerfiles/toolbox --dockerfile $CI_PROJECT_DIR/dockerfiles/toolbox/Dockerfile --destination $CI_REGISTRY_IMAGE/toolbox:$CI_COMMIT_TAG
  only:
    refs:
      - tags

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_TAG
  only:
    refs:
      - tags

שימו לב שאנו משתמשים GIT_SUBMODULE_STRATEGY: רגיל עבור אותן עבודות שבהן אתה צריך לאתחל במפורש תת-מודולים לפני ביצוע.

אל תשכח לבצע את השינויים שלנו:

git add .gitlab-ci.yml
git commit -m "Automate docker build"

אני חושב שאנחנו יכולים לקרוא לזה בבטחה גרסה v0.0.1 והוסיפו את התגית:

git tag v0.0.1

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

בוא נעשה את זה git push --tags, ובואו נסתכל על הצינור הראשון שלנו:

צילום מסך של הצינור הראשון

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

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

10. אוטומציה של פריסה

כדי ש-Gitlab-runner יפענח את הסודות שלנו, נצטרך לייצא את מפתח המאגר ולהוסיף אותו למשתני סביבת ה-CI שלנו:

git crypt export-key /tmp/docs-repo.key
base64 -w0 /tmp/docs-repo.key; echo

נשמור את השורה המתקבלת ב-Gitlab; לשם כך, הבה נעבור להגדרות הפרויקט שלנו:
הגדרות -> CI / CD -> משתנים

ובואו ניצור משתנה חדש:

סוּג
מפתח
ערך
מוּגָן
מוּסוֶה
היקף

File
GITCRYPT_KEY
<your string>
true (במהלך האימון אתה יכול false)
true
All environments

צילום מסך של המשתנה שנוסף

עכשיו בואו נעדכן את שלנו .gitlab-ci.yml מוסיף לו:

.deploy_qbec_app:
  stage: deploy
  only:
    refs:
      - master

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes

deploy_website:
  extends: .deploy_qbec_app
  script:
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes

כאן אפשרנו מספר אפשרויות חדשות עבור qbec:

• --root some/app — מאפשר לך לקבוע את הספרייה של יישום ספציפי
• --force:k8s-context __incluster__ - זהו משתנה קסם שאומר שהפריסה תתרחש באותו אשכול בו פועל gtilab-runner. זה הכרחי כי אחרת qbec ינסה למצוא שרת Kubernetes מתאים ב-kubeconfig שלך
• --לַחֲכוֹת - מאלץ את qbec להמתין עד שהמשאבים שהיא יוצרת יכנסו למצב Ready ורק אז לצאת עם קוד יציאה מוצלח.
• -כן - פשוט משבית את המעטפת האינטראקטיבית האם אתה בטוח? כאשר נפרס.

אל תשכח לבצע את השינויים שלנו:

git add .gitlab-ci.yml
git commit -m "Automate deploy"

ואחרי דחיפת גיט נראה כיצד היישומים שלנו נפרסו:

צילום מסך של הצינור השני

11. חפצים והרכבה בעת דחיפה למאסטר

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

הרעיון פשוט: עכשיו התמונה שלנו אתר אינטרנט ייבנה מחדש בכל פעם שתיכנס פנימה אב, ולאחר מכן לפרוס אוטומטית ל-Kubernetes.

בואו נעדכן את שתי המשרות הללו אצלנו .gitlab-ci.yml:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/
  only:
    refs:
      - master
      - tags

deploy_website:
  extends: .deploy_qbec_app
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

שימו לב שהוספנו שרשור אב к שופטים לעבודות build_website ואנחנו משתמשים עכשיו $CI_COMMIT_REF_NAME במקום $CI_COMMIT_TAG, כלומר, אנחנו מנותקים מתגיות ב-Git ועכשיו נדחוף תמונה עם שם סניף ה-commit שאתחל את ה-pipeline. ראוי לציין שזה יעבוד גם עם תגיות, שיאפשרו לנו לשמור צילומי מצב של אתר עם גרסה ספציפית ב-docer-registry.

כאשר השם של תג docker עבור גרסה חדשה של האתר יכול להיות ללא שינוי, עדיין עלינו לתאר את השינויים ב- Kubernetes, אחרת הוא פשוט לא יפרוס מחדש את האפליקציה מהתמונה החדשה, מכיוון שהוא לא יבחין בשינויים בפריסה לְהַפְגִין.

אפשרות —vm:ext-str digest="$DIGEST" עבור qbec - מאפשר להעביר משתנה חיצוני ל-jsonnet. אנחנו רוצים שהוא ייפרס מחדש באשכול עם כל מהדורה של האפליקציה שלנו. אנחנו כבר לא יכולים להשתמש בשם התג, שכעת יכול להיות בלתי ניתן לשינוי, מכיוון שאנחנו צריכים להיות קשורים לגרסה ספציפית של התמונה ולהפעיל את הפריסה כשהיא משתנה.

כאן ניעזר ביכולת של קניקו לשמור תמונת תקציר לקובץ (אפשרות --digest-file)
לאחר מכן נעביר את הקובץ הזה ונקרא אותו בזמן הפריסה.

בואו נעדכן את הפרמטרים שלנו deploy/website/environments/base.libsonnet שיראה כעת כך:

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website@' + std.extVar('digest'),
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

סיים, עכשיו כל התחייבות אב מאתחל את הבנייה של תמונת docker עבור אתר אינטרנט, ולאחר מכן לפרוס אותו ל-Kubernetes.

אל תשכח לבצע את השינויים שלנו:

git add .
git commit -m "Configure dynamic build"

נבדוק מאוחר יותר דחיפת גיט אנחנו צריכים לראות משהו כזה:

צילום מסך של הצינור למאסטר

באופן עקרוני, אנחנו לא צריכים לפרוס מחדש את gitlab-runner עם כל דחיפה, אלא אם כן, כמובן, שום דבר לא השתנה בתצורה שלו, בואו נתקן את זה ב .gitlab-ci.yml:

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes
  only:
    changes:
      - deploy/gitlab-runner/**/*

שינויים יאפשר לך לעקוב אחר שינויים ב deploy/gitlab-runner/ ויפעיל את העבודה שלנו רק אם יהיו כאלה

אל תשכח לבצע את השינויים שלנו:

git add .gitlab-ci.yml
git commit -m "Reduce gitlab-runner deploy"

דחיפת גיט, זה יותר טוב:

צילום מסך של הצינור המעודכן

12. סביבות דינמיות

הגיע הזמן לגוון את הצינור שלנו עם סביבות דינמיות.

ראשית, בואו נעדכן את העבודה build_website אצלנו .gitlab-ci.yml, הסרת הבלוק ממנו רק, שיאלץ את Gitlab להפעיל אותו בכל התחייבות לכל סניף:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/

לאחר מכן עדכן את העבודה deploy_website, הוסף שם בלוק סביבה:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

זה יאפשר לגיטלאב לשייך את המשרה לְדַרבֵּן הסביבה ולהציג את הקישור הנכון אליה.

כעת נוסיף עוד שתי משרות:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

deploy_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: http://$CI_ENVIRONMENT_SLUG.docs.example.org
    on_stop: stop_review
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply review --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  only:
    refs:
    - branches
  except:
    refs:
      - master

stop_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  stage: deploy
  before_script:
    - git clone "$CI_REPOSITORY_URL" master
    - cd master
  script:
    - qbec delete review --root deploy/website --force:k8s-context __incluster__ --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  variables:
    GIT_STRATEGY: none
  only:
    refs:
    - branches
  except:
    refs:
      - master
  when: manual

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

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

כאן אנו משתמשים גם qbec להחיל סקירה, במקום qbec להחיל ברירת מחדל - זה בדיוק הרגע שבו ננסה לתאר את ההבדלים בסביבות שלנו (סקירה וברירת מחדל):

הוסף סקירה סביבה ב deploy/website/qbec.yaml

spec:
  environments:
    review:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443

אז נכריז על זה deploy/website/params.libsonnet:

local env = std.extVar('qbec.io/env');
local paramsMap = {
  _: import './environments/base.libsonnet',
  default: import './environments/default.libsonnet',
  review: import './environments/review.libsonnet',
};

if std.objectHas(paramsMap, env) then paramsMap[env] else error 'environment ' + env + ' not defined in ' + std.thisFile

ורשום את הפרמטרים המותאמים אישית עבורו deploy/website/environments/review.libsonnet:

// this file has the param overrides for the default environment
local base = import './base.libsonnet';
local slug = std.extVar('qbec.io/tag');
local subdomain = std.extVar('subdomain');

base {
  components+: {
    website+: {
      name: 'example-docs-' + slug,
      domain: subdomain + '.docs.example.org',
    },
  },
}

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

אל תשכח לבצע את השינויים שלנו:

git add .
git commit -m "Enable automatic review"

דחיפת גיט, git checkout -b test, בדיקת מקור git push, חשבון:

צילום מסך של סביבות שנוצרו ב-Gitlab

הכל עובד? - מעולה, מחק את סניף הבדיקה שלנו: מאסטר לקופות, git push origin :test, אנו בודקים שעבודות מחיקת הסביבה עבדו ללא שגיאות.

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

13. סקירת אפליקציות

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

כדי שהלחצנים האלה יופיעו, עליך ליצור קובץ .gitlab/route-map.yml ותאר את כל התמורות הנתיבים בו; במקרה שלנו זה יהיה פשוט מאוד:

# Indices
- source: /content/(.+?)_index.(md|html)/ 
  public: '1'

# Pages
- source: /content/(.+?).(md|html)/ 
  public: '1/'

אל תשכח לבצע את השינויים שלנו:

git add .gitlab/
git commit -m "Enable review apps"

דחיפת גיט, ולבדוק:

צילום מסך של כפתור ה-Review App

העבודה בוצעה!

מקורות הפרויקט:

• ב- Gitlab: https://gitlab.com/kvaps/docs.example.org
• ב-GitHub: https://github.com/kvaps/docs.example.org

תודה על תשומת הלב, אני מקווה שאהבת

מקור: www.habr.com