สวัสดี! เมื่อเร็ว ๆ นี้ มีการเปิดตัวเครื่องมืออัตโนมัติที่ยอดเยี่ยมมากมายทั้งสำหรับการสร้างอิมเมจ Docker และสำหรับการปรับใช้กับ Kubernetes ในเรื่องนี้ ฉันตัดสินใจลองใช้ GitLab ศึกษาความสามารถของมันอย่างละเอียด และแน่นอน ตั้งค่าไปป์ไลน์

งานนี้ได้รับแรงบันดาลใจจากเว็บไซต์ kubernetes.ioซึ่งเกิดจาก ซอร์สโค้ด โดยอัตโนมัติ และสำหรับคำขอพูลแต่ละรายการที่ส่งไป หุ่นยนต์จะสร้างเวอร์ชันตัวอย่างของไซต์โดยอัตโนมัติพร้อมกับการเปลี่ยนแปลงของคุณ และจัดเตรียมลิงก์สำหรับการดู

ฉันพยายามสร้างกระบวนการที่คล้ายกันตั้งแต่เริ่มต้น แต่สร้างขึ้นทั้งหมดบน Gitlab CI และเครื่องมือฟรีที่ฉันใช้ในการปรับใช้แอปพลิเคชันกับ Kubernetes วันนี้ฉันจะบอกคุณเพิ่มเติมเกี่ยวกับพวกเขาในที่สุด

บทความนี้จะกล่าวถึงเครื่องมือต่างๆ เช่น:
ฮิวโก้, คิวเบค, คานิโกะ, git-crypt.php и GitLab CI ด้วยการสร้างสภาพแวดล้อมแบบไดนามิก

เนื้อหา

พบกับฮิวโก้
กำลังเตรียม Dockerfile
ทำความรู้จักกับคานิโกะ
ทำความรู้จักกับคิวเบค
ลองใช้ Gitlab-runner กับ Kubernetes-executor
การปรับใช้แผนภูมิ Helm ด้วย qbec
ขอแนะนำ git-crypt
การสร้างภาพกล่องเครื่องมือ
ไปป์ไลน์แรกของเราและการประกอบรูปภาพด้วยแท็ก
การปรับใช้อัตโนมัติ
สิ่งประดิษฐ์และการประกอบเมื่อกดเป็นผู้เชี่ยวชาญ
สภาพแวดล้อมแบบไดนามิก
รีวิวแอพ

1. ทำความรู้จักกับฮิวโก้

เป็นตัวอย่างโครงการของเรา เราจะพยายามสร้างไซต์เผยแพร่เอกสารที่สร้างจาก Hugo Hugo เป็นตัวสร้างเนื้อหาแบบคงที่

สำหรับผู้ที่ไม่คุ้นเคยกับเครื่องกำเนิดไฟฟ้าแบบคงที่ ฉันจะบอกคุณเพิ่มเติมเล็กน้อยเกี่ยวกับพวกเขา ต่างจากกลไกเว็บไซต์ทั่วไปที่มีฐานข้อมูลและ PHP บางตัว ซึ่งเมื่อผู้ใช้ร้องขอ จะสร้างเพจได้ทันที ตัวสร้างแบบคงที่ได้รับการออกแบบแตกต่างออกไปเล็กน้อย พวกมันอนุญาตให้คุณนำซอร์สซึ่งมักจะเป็นชุดของไฟล์ในมาร์กอัปมาร์กอัปและเทมเพลตธีม จากนั้นคอมไพล์ลงในเว็บไซต์ที่เสร็จสมบูรณ์อย่างสมบูรณ์

นั่นคือเป็นผลให้คุณจะได้รับโครงสร้างไดเร็กทอรีและชุดของไฟล์ HTML ที่สร้างขึ้นซึ่งคุณสามารถอัปโหลดไปยังโฮสติ้งราคาถูกและรับเว็บไซต์ที่ใช้งานได้

คุณสามารถติดตั้ง Hugo ในเครื่องและทดลองใช้งาน:

การเริ่มต้นไซต์ใหม่:

hugo new site docs.example.org

และในเวลาเดียวกัน ที่เก็บ git:

cd docs.example.org
git init

จนถึงตอนนี้ ไซต์ของเรายังใหม่อยู่ และเพื่อที่จะให้บางสิ่งปรากฏบนไซต์นั้น เราต้องเชื่อมต่อธีมก่อน ธีมเป็นเพียงชุดของเทมเพลตและกฎเฉพาะที่ใช้สร้างไซต์ของเรา

สำหรับธีมที่เราจะใช้ เรียนซึ่งในความคิดของฉัน เหมาะอย่างยิ่งสำหรับไซต์เอกสาร

ฉันอยากจะให้ความสนใจเป็นพิเศษกับความจริงที่ว่าเราไม่จำเป็นต้องบันทึกไฟล์ธีมในพื้นที่เก็บข้อมูลของโครงการของเรา แต่เราสามารถเชื่อมต่อมันโดยใช้ คอมไพล์โมดูลย่อย:

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

ดังนั้นพื้นที่เก็บข้อมูลของเราจะมีเฉพาะไฟล์ที่เกี่ยวข้องโดยตรงกับโครงการของเราและธีมที่เชื่อมต่อจะยังคงเป็นลิงก์ไปยังพื้นที่เก็บข้อมูลเฉพาะและคอมมิตในนั้น กล่าวคือ สามารถดึงมาจากแหล่งดั้งเดิมได้ตลอดเวลาและไม่ต้องกลัว การเปลี่ยนแปลงที่เข้ากันไม่ได้

มาแก้ไขการกำหนดค่ากัน config.toml:

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

ในขั้นตอนนี้คุณสามารถดำเนินการได้:

hugo server

และตามที่อยู่ http://localhost:1313/ ตรวจสอบเว็บไซต์ที่สร้างขึ้นใหม่ของเรา การเปลี่ยนแปลงทั้งหมดที่ทำในไดเรกทอรีจะอัปเดตหน้าที่เปิดในเบราว์เซอร์โดยอัตโนมัติ สะดวกมาก!

มาลองสร้างใบปะหน้ากันเถอะ เนื้อหา/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

ภาพหน้าจอของเพจที่สร้างขึ้นใหม่

หากต้องการสร้างไซต์ เพียงเรียกใช้:

hugo

เนื้อหาไดเร็กทอรี สาธารณะ/ และจะเป็นเว็บไซต์ของคุณ
ใช่แล้ว มาเพิ่มกันทันที .gitignore:

echo /public > .gitignore

อย่าลืมยอมรับการเปลี่ยนแปลงของเรา:

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

2. การเตรียม Dockerfile

ถึงเวลากำหนดโครงสร้างของพื้นที่เก็บข้อมูลของเราแล้ว ฉันมักจะใช้สิ่งที่ชอบ:

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

นักเทียบท่าไฟล์/ — มีไดเร็กทอรีที่มี Dockerfiles และทุกสิ่งที่จำเป็นสำหรับการสร้างอิมเมจ Docker ของเรา
ปรับใช้/ — มีไดเร็กทอรีสำหรับการปรับใช้แอปพลิเคชันของเรากับ Kubernetes

ดังนั้นเราจะสร้าง Dockerfile แรกของเราตามเส้นทาง dockerfiles/เว็บไซต์/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 มีสองตัว จากโอกาสนี้เรียกว่า การสร้างแบบหลายขั้นตอน และช่วยให้คุณสามารถแยกทุกสิ่งที่ไม่จำเป็นออกจากอิมเมจ Docker สุดท้ายได้
ดังนั้นภาพสุดท้ายก็จะมีเพียง darkhttpd (เซิร์ฟเวอร์ HTTP แบบไลท์เวท) และ สาธารณะ/ — เนื้อหาของเว็บไซต์ที่สร้างขึ้นแบบคงที่ของเรา

อย่าลืมยอมรับการเปลี่ยนแปลงของเรา:

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

3.ทำความรู้จักกับคานิโกะ

ในฐานะนักสร้างอิมเมจนักเทียบท่า ฉันตัดสินใจใช้ คานิโกะเนื่องจากการดำเนินการไม่ต้องใช้ docker daemon และสร้างเองได้บนเครื่องใดก็ได้และสามารถจัดเก็บแคชไว้ในรีจิสทรีได้โดยตรง จึงช่วยลดความจำเป็นในการจัดเก็บข้อมูลถาวรแบบเต็มรูปแบบ

หากต้องการสร้างอิมเมจ เพียงเรียกใช้คอนเทนเนอร์ด้วย ผู้ดำเนินการคานิโกะ และส่งผ่านบริบทการสร้างปัจจุบัน ซึ่งสามารถทำได้ในเครื่องผ่านนักเทียบท่า:

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

ที่ไหน register.gitlab.com/kvaps/docs.example.org/เว็บไซต์ — ชื่อของอิมเมจนักเทียบท่าของคุณ หลังจากสร้างแล้ว มันจะถูกเปิดใช้งานโดยอัตโนมัติในรีจิสทรีนักเทียบท่า

พารามิเตอร์ --แคช อนุญาตให้คุณแคชเลเยอร์ในรีจิสทรีนักเทียบท่า ตัวอย่างเช่น เลเยอร์เหล่านั้นจะถูกบันทึกไว้ register.gitlab.com/kvaps/docs.example.org/เว็บไซต์/cacheแต่คุณสามารถระบุเส้นทางอื่นได้โดยใช้พารามิเตอร์ --แคช-repo.

ภาพหน้าจอของ docker-registry

4. ทำความรู้จักกับคิวเบค

คิวเบค เป็นเครื่องมือการปรับใช้ที่ช่วยให้คุณอธิบายรายการแอปพลิเคชันของคุณอย่างชัดเจนและปรับใช้กับ 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: {}

ที่นี่เราสนใจเป็นหลัก ข้อมูลจำเพาะสภาพแวดล้อมqbec ได้สร้างสภาพแวดล้อมเริ่มต้นให้เราแล้ว และรับที่อยู่เซิร์ฟเวอร์ รวมถึงเนมสเปซจาก kubeconfig ปัจจุบันของเรา
ตอนนี้เมื่อปรับใช้กับ ผิดนัด qbec จะปรับใช้เฉพาะกับคลัสเตอร์ Kubernetes ที่ระบุและกับเนมสเปซที่ระบุเสมอ นั่นคือคุณไม่จำเป็นต้องสลับระหว่างบริบทและเนมสเปซอีกต่อไปเพื่อดำเนินการปรับใช้
หากจำเป็น คุณสามารถอัปเดตการตั้งค่าในไฟล์นี้ได้ตลอดเวลา

สภาพแวดล้อมทั้งหมดของคุณอธิบายไว้ใน qbec.yamlและในไฟล์ params.libsonnetโดยที่มันบอกว่าจะรับพารามิเตอร์ได้จากที่ไหน

ต่อไปเราจะเห็นสองไดเรกทอรี:

ส่วนประกอบ / — รายการทั้งหมดสำหรับแอปพลิเคชันของเราจะถูกเก็บไว้ที่นี่ ซึ่งสามารถอธิบายได้ทั้งในไฟล์ jsonnet และ yaml ปกติ
สิ่งแวดล้อม/ — ที่นี่เราจะอธิบายตัวแปร (พารามิเตอร์) ทั้งหมดสำหรับสภาพแวดล้อมของเรา

โดยค่าเริ่มต้น เรามีสองไฟล์:

สภาพแวดล้อม/base.libsonnet - จะมีพารามิเตอร์ทั่วไปสำหรับทุกสภาพแวดล้อม
สภาพแวดล้อม/default.libsonnet — มีพารามิเตอร์ที่ถูกแทนที่สำหรับสภาพแวดล้อม ผิดนัด

มาเปิดกันเถอะ สภาพแวดล้อม/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',
    },
  },
}

มาสร้างองค์ประกอบแรกของเรากัน ส่วนประกอบ/เว็บไซต์.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 สามรายการพร้อมกัน ได้แก่: การใช้งาน, Service и สิทธิในการเข้า. หากเราต้องการ เราสามารถรวมพวกมันไว้ในส่วนประกอบต่างๆ ได้ แต่ในขั้นตอนนี้ ส่วนประกอบหนึ่งจะเพียงพอสำหรับเรา

วากยสัมพันธ์ jsonnet.jsonnet คล้ายกับ json ทั่วไปมาก โดยหลักการแล้ว json ปกติเป็น jsonnet ที่ถูกต้องอยู่แล้ว ดังนั้นในตอนแรกคุณอาจใช้บริการออนไลน์เช่น yaml2json เพื่อแปลง yaml ปกติของคุณเป็น json หรือหากส่วนประกอบของคุณไม่มีตัวแปรใดๆ ก็สามารถอธิบายได้ในรูปแบบของ yaml ปกติ

เมื่อได้ร่วมงานกับ jsonnet.jsonnet ฉันขอแนะนำให้ติดตั้งปลั๊กอินสำหรับโปรแกรมแก้ไขของคุณ

ตัวอย่างเช่นมีปลั๊กอินสำหรับเป็นกลุ่ม vim-jsonnetซึ่งจะเปิดการเน้นไวยากรณ์และดำเนินการโดยอัตโนมัติ jsonnet เอฟเอ็มที ทุกครั้งที่คุณบันทึก (ต้องติดตั้ง 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-runner กับ Kubernetes-executor

จนกระทั่งเมื่อเร็ว ๆ นี้ฉันใช้เพียงปกติเท่านั้น gitlab-runner บนเครื่องที่เตรียมไว้ล่วงหน้า (คอนเทนเนอร์ LXC) พร้อมเชลล์หรือนักเทียบท่า ในตอนแรก เรามีนักวิ่งหลายรายที่ได้รับการกำหนดไว้ทั่วโลกใน gitlab ของเรา พวกเขารวบรวมอิมเมจนักเทียบท่าสำหรับทุกโปรเจ็กต์

แต่ดังที่แสดงให้เห็นในทางปฏิบัติแล้ว ตัวเลือกนี้ไม่ใช่อุดมคติที่สุดทั้งในแง่ของการใช้งานจริงและความปลอดภัย จะดีกว่ามากและถูกต้องตามหลักอุดมคติมากที่จะมีนักวิ่งแยกกันปรับใช้สำหรับแต่ละโครงการ หรือแม้แต่สำหรับแต่ละสภาพแวดล้อม

โชคดีที่นี่ไม่ใช่ปัญหาเลย เนื่องจากตอนนี้เราจะปรับใช้แล้ว gitlab-runner โดยตรงซึ่งเป็นส่วนหนึ่งของโครงการของเราใน 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-runner ส่วนหนึ่งของโปรเจ็กต์ของเรา ถึงเวลาอธิบายมันในพื้นที่เก็บข้อมูล Git ของเราแล้ว

เราสามารถอธิบายได้ว่าเป็นองค์ประกอบที่แยกจากกัน เว็บไซต์แต่ในอนาคตเราวางแผนที่จะปรับใช้สำเนาที่แตกต่างกัน เว็บไซต์ บ่อยมากไม่เหมือน gitlab-runnerซึ่งจะปรับใช้เพียงครั้งเดียวต่อคลัสเตอร์ Kubernetes เรามาเริ่มต้นแอปพลิเคชันแยกต่างหากกัน:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

ครั้งนี้เราจะไม่อธิบายเอนทิตี Kubernetes ด้วยตนเอง แต่จะใช้แผนภูมิ Helm สำเร็จรูป ข้อดีอย่างหนึ่งของ qbec คือความสามารถในการเรนเดอร์แผนภูมิ Helm ได้โดยตรงจากที่เก็บ Git

มาเชื่อมต่อโดยใช้ git submodule:

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

ตอนนี้ไดเรกทอรี ผู้ขาย / gitlab-runner เรามีพื้นที่เก็บข้อมูลพร้อมแผนภูมิสำหรับ 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,
  }
)

อาร์กิวเมนต์แรกที่ ขยายHelmTemplate เราผ่านเส้นทางไปยังแผนภูมิแล้ว params.valuesซึ่งเรานำมาจากพารามิเตอร์สภาพแวดล้อม จากนั้นจึงนำออบเจ็กต์มาด้วย

ชื่อเทมเพลต - ชื่อการเปิดตัว
namespace - เนมสเปซถูกถ่ายโอนไปยังผู้ถือหางเสือเรือ
ไฟล์นี้ — พารามิเตอร์ที่จำเป็นซึ่งส่งผ่านเส้นทางไปยังไฟล์ปัจจุบัน
ละเอียด - แสดงคำสั่ง แม่แบบหางเสือ พร้อมข้อโต้แย้งทั้งหมดเมื่อแสดงแผนภูมิ

ตอนนี้เรามาอธิบายพารามิเตอร์สำหรับส่วนประกอบของเรากันดีกว่า สภาพแวดล้อม/base.libsonnet:

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

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

หมายเหตุ โทเค็นการลงทะเบียนนักวิ่ง เรานำมาจากไฟล์ภายนอก ความลับ/base.libsonnetมาสร้างมันกันเถอะ:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

ตรวจสอบว่าทุกอย่างใช้งานได้หรือไม่:

qbec show default

หากทุกอย่างเป็นไปตามลำดับ เราก็สามารถลบ Release ที่ปรับใช้ก่อนหน้านี้ผ่าน 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 นั้นไม่ปลอดภัยใช่ไหม? ดังนั้นเราจึงจำเป็นต้องเข้ารหัสอย่างเหมาะสม

โดยปกติแล้ว เพื่อประโยชน์ของตัวแปรตัวเดียว สิ่งนี้อาจไม่สมเหตุสมผลเสมอไป คุณสามารถโอนความลับไปที่ คิวเบค และผ่านตัวแปรสภาพแวดล้อมของระบบ CI ของคุณ
แต่เป็นที่น่าสังเกตว่ายังมีโครงการที่ซับซ้อนกว่าซึ่งสามารถเก็บความลับได้อีกมากมายการถ่ายโอนทั้งหมดผ่านตัวแปรสภาพแวดล้อมจะยากมาก

ยิ่งไปกว่านั้น ในกรณีนี้ ฉันไม่สามารถบอกคุณเกี่ยวกับเครื่องมือที่ยอดเยี่ยมเช่นนี้ได้ git-crypt.php.

git-crypt.php นอกจากนี้ยังสะดวกตรงที่ช่วยให้คุณสามารถบันทึกประวัติความลับทั้งหมด รวมถึงเปรียบเทียบ ผสาน และแก้ไขข้อขัดแย้งในลักษณะเดียวกับที่เราคุ้นเคยในกรณีของ Git

สิ่งแรกหลังการติดตั้ง git-crypt.php เราจำเป็นต้องสร้างคีย์สำหรับพื้นที่เก็บข้อมูลของเรา:

git crypt init

หากคุณมีคีย์ PGP คุณสามารถเพิ่มตัวเองเป็นผู้ทำงานร่วมกันสำหรับโปรเจ็กต์นี้ได้ทันที:

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

วิธีนี้ทำให้คุณสามารถถอดรหัสที่เก็บนี้ได้ตลอดเวลาโดยใช้คีย์ส่วนตัวของคุณ

หากคุณไม่มีคีย์ PGP และไม่ได้คาดหวังไว้ คุณสามารถดำเนินการด้วยวิธีอื่นและส่งออกคีย์โปรเจ็กต์ได้:

git crypt export-key /path/to/keyfile

ดังนั้นใครก็ตามที่มีการส่งออก ไฟล์คีย์ จะสามารถถอดรหัสพื้นที่เก็บข้อมูลของคุณได้

ถึงเวลาสร้างความลับแรกของเราแล้ว
ฉันขอเตือนคุณว่าเรายังอยู่ในไดเรกทอรี ปรับใช้/gitlab-runner/โดยที่เรามีไดเร็กทอรี ความลับ/มาเข้ารหัสไฟล์ทั้งหมดในนั้นกันดีกว่า เพื่อที่เราจะสร้างไฟล์ขึ้นมา ความลับ/.gitattributes โดยมีเนื้อหาดังนี้

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

ดังที่เห็นได้จากเนื้อหา ไฟล์ทั้งหมดถูกปกปิด * จะถูกขับผ่านไป git-crypt.phpยกเว้นส่วนใหญ่ .gitattributes

เราสามารถตรวจสอบสิ่งนี้ได้โดยการรัน:

git crypt status -e

ผลลัพธ์จะเป็นรายการไฟล์ทั้งหมดในพื้นที่เก็บข้อมูลที่เปิดใช้งานการเข้ารหัส

เพียงเท่านี้ เราก็สามารถดำเนินการเปลี่ยนแปลงได้อย่างปลอดภัยแล้ว:

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

หากต้องการบล็อกพื้นที่เก็บข้อมูล เพียงเรียกใช้:

git crypt lock

และทันทีที่ไฟล์ที่เข้ารหัสทั้งหมดจะกลายเป็นไบนารี่จะไม่สามารถอ่านได้
หากต้องการถอดรหัสที่เก็บ ให้รัน:

git crypt unlock

8. สร้างภาพกล่องเครื่องมือ

อิมเมจกล่องเครื่องมือคือรูปภาพที่มีเครื่องมือทั้งหมดที่เราจะใช้เพื่อปรับใช้โปรเจ็กต์ของเรา Gitlab runner จะใช้มันเพื่อดำเนินงานการปรับใช้งานทั่วไป

ทุกอย่างเป็นเรื่องง่ายที่นี่ มาสร้างใหม่กันเถอะ dockerfiles/กล่องเครื่องมือ/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

อย่างที่คุณเห็น ในภาพนี้ เราติดตั้งยูทิลิตี้ทั้งหมดที่เราใช้ในการปรับใช้แอปพลิเคชันของเรา เราไม่ต้องการมันที่นี่เว้นแต่ Kubectlแต่คุณอาจต้องการลองใช้งานในระหว่างขั้นตอนการตั้งค่าไปป์ไลน์

นอกจากนี้ เพื่อให้สามารถสื่อสารกับ 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,
      },
    ],
  },
]

เราจะอธิบายพารามิเตอร์ใหม่ด้วย สภาพแวดล้อม/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',
    },
  },
}

หมายเหตุ $.ส่วนประกอบ.rbac.name อ้างถึง ชื่อ สำหรับส่วนประกอบ อาร์แบค

มาดูกันว่ามีอะไรเปลี่ยนแปลงบ้าง:

qbec diff default

และใช้การเปลี่ยนแปลงของเรากับ Kubernetes:

qbec apply default

นอกจากนี้อย่าลืมยอมรับการเปลี่ยนแปลงของเรากับคอมไพล์:

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และมาดูไปป์ไลน์แรกของเรากัน:

ภาพหน้าจอของไปป์ไลน์แรก

คุณควรให้ความสนใจกับความจริงที่ว่าการประกอบด้วยแท็กนั้นเหมาะสำหรับการสร้างอิมเมจนักเทียบท่า แต่ไม่เหมาะสำหรับการปรับใช้แอปพลิเคชันกับ Kubernetes เนื่องจากแท็กใหม่สามารถกำหนดให้กับคอมมิตเก่าได้ ในกรณีนี้ การเริ่มต้นไปป์ไลน์สำหรับแท็กเหล่านั้นจะนำไปสู่การปรับใช้เวอร์ชันเก่า

เพื่อแก้ไขปัญหานี้ โดยปกติแล้วการสร้างอิมเมจนักเทียบท่าจะเชื่อมโยงกับแท็ก และการปรับใช้แอปพลิเคชันกับสาขา เจ้านายรูปภาพที่รวบรวมในเวอร์ชันใดมีฮาร์ดโค้ด นี่คือที่ที่คุณสามารถเริ่มต้นการย้อนกลับด้วยการย้อนกลับแบบง่ายๆ เจ้านาย-สาขา

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 บางส่วน/แอป — ช่วยให้คุณสามารถกำหนดไดเร็กทอรีของแอปพลิเคชันเฉพาะได้
--force:k8s-บริบท __incluster__ - นี่คือตัวแปรวิเศษที่บอกว่าการปรับใช้จะเกิดขึ้นในคลัสเตอร์เดียวกันกับที่ gtilab-runner กำลังทำงานอยู่ นี่เป็นสิ่งจำเป็นเพราะมิฉะนั้น qbec จะพยายามค้นหาเซิร์ฟเวอร์ Kubernetes ที่เหมาะสมใน kubeconfig ของคุณ
--รอ — บังคับให้ qbec รอจนกว่าทรัพยากรที่สร้างขึ้นจะเข้าสู่สถานะ Ready จากนั้นจึงออกด้วยรหัสทางออกที่สำเร็จ
-ใช่ - เพียงปิดการใช้งานเชลล์แบบโต้ตอบ คุณแน่ใจไหม? เมื่อนำไปใช้งาน

อย่าลืมยอมรับการเปลี่ยนแปลงของเรา:

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

และหลังจากนั้น git push เราจะดูว่าแอปพลิเคชันของเราถูกปรับใช้อย่างไร:

ภาพหน้าจอของไปป์ไลน์ที่สอง

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"

โปรดทราบว่าเราได้เพิ่มเธรด เจ้านาย к refs สำหรับงาน build_เว็บไซต์ และตอนนี้เราใช้ $CI_COMMIT_REF_NAME แทน $CI_COMMIT_TAGนั่นคือเราถูกปลดออกจากแท็กใน Git แล้ว และตอนนี้เราจะพุชอิมเมจที่มีชื่อของสาขาคอมมิตที่เริ่มต้นไปป์ไลน์ เป็นที่น่าสังเกตว่าสิ่งนี้จะทำงานร่วมกับแท็กด้วยซึ่งจะช่วยให้เราบันทึกสแนปชอตของไซต์ด้วยเวอร์ชันเฉพาะในรีจิสทรีนักเทียบท่า

เมื่อชื่อของแท็กนักเทียบท่าสำหรับเว็บไซต์เวอร์ชันใหม่ไม่สามารถเปลี่ยนแปลงได้ เรายังคงต้องอธิบายการเปลี่ยนแปลงใน Kubernetes ไม่เช่นนั้นจะไม่ปรับใช้แอปพลิเคชันใหม่จากอิมเมจใหม่ เนื่องจากจะไม่สังเกตเห็นการเปลี่ยนแปลงใด ๆ ใน รายการปรับใช้

ตัวเลือก —vm:ext-str ย่อย =”$DIGEST” สำหรับ qbec - อนุญาตให้คุณส่งตัวแปรภายนอกไปยัง jsonnet เราต้องการให้ปรับใช้ซ้ำในคลัสเตอร์พร้อมกับแอปพลิเคชันของเราแต่ละรุ่น เราไม่สามารถใช้ชื่อแท็กได้อีกต่อไป ซึ่งขณะนี้ไม่สามารถเปลี่ยนแปลงได้ เนื่องจากเราจำเป็นต้องเชื่อมโยงกับเวอร์ชันเฉพาะของรูปภาพและทริกเกอร์การปรับใช้เมื่อมีการเปลี่ยนแปลง

ที่นี่เราจะได้รับความช่วยเหลือจากความสามารถของ Kaniko ในการบันทึกภาพสรุปลงในไฟล์ (ตัวเลือก --ไดเจสต์ไฟล์)
จากนั้นเราจะถ่ายโอนไฟล์นี้และอ่านในขณะที่ปรับใช้

มาอัปเดตพารามิเตอร์ของเรากันดีกว่า ปรับใช้/เว็บไซต์/สภาพแวดล้อม/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',
    },
  },
}

เสร็จแล้ว ตกลงใดๆ ได้เลย เจ้านาย เริ่มต้นการสร้างอิมเมจนักเทียบท่าสำหรับ เว็บไซต์แล้วปรับใช้กับ Kubernetes

อย่าลืมยอมรับการเปลี่ยนแปลงของเรา:

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

เราจะตรวจสอบในภายหลัง git push เราควรเห็นสิ่งนี้:

ภาพหน้าจอของไปป์ไลน์สำหรับต้นแบบ

โดยหลักการแล้ว เราไม่จำเป็นต้องปรับใช้ 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/**/*

การเปลี่ยนแปลง จะช่วยให้คุณสามารถติดตามการเปลี่ยนแปลงใน ปรับใช้/gitlab-runner/ และจะทริกเกอร์งานของเราก็ต่อเมื่อมี

อย่าลืมยอมรับการเปลี่ยนแปลงของเรา:

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

git push, นั่นดีกว่า:

ภาพหน้าจอของไปป์ไลน์ที่อัปเดต

12. สภาพแวดล้อมแบบไดนามิก

ถึงเวลาแล้วที่จะต้องกระจายไปป์ไลน์ของเราด้วยสภาพแวดล้อมแบบไดนามิก

ก่อนอื่นมาอัพเดทงานกันก่อน build_เว็บไซต์ ของเรา .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:
  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"

ซึ่งจะช่วยให้ Gitlab สามารถเชื่อมโยงงานด้วยได้ แยง สภาพแวดล้อมและแสดงลิงก์ที่ถูกต้อง

ตอนนี้ขอเพิ่มงานอีกสองงาน:

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: --app-แท็ก — ช่วยให้คุณสามารถแท็กแอปพลิเคชันเวอร์ชันที่ปรับใช้และทำงานภายในแท็กนี้เท่านั้น เมื่อสร้างและทำลายทรัพยากรใน Kubernetes qbec จะทำงานเฉพาะกับทรัพยากรเหล่านั้นเท่านั้น
ด้วยวิธีนี้ เราไม่สามารถสร้างสภาพแวดล้อมแยกต่างหากสำหรับการตรวจสอบแต่ละครั้งได้ แต่เพียงนำสภาพแวดล้อมเดิมกลับมาใช้ใหม่

ที่นี่เราก็ใช้เช่นกัน qbec ใช้การตรวจสอบแทน qbec ใช้ค่าเริ่มต้น - นี่คือช่วงเวลาที่เราจะพยายามอธิบายความแตกต่างสำหรับสภาพแวดล้อมของเรา (ตรวจสอบและค่าเริ่มต้น):

มาเพิ่มกันเถอะ ทบทวน สิ่งแวดล้อมใน ปรับใช้/เว็บไซต์/qbec.yaml

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

แล้วเราจะประกาศใน ปรับใช้/เว็บไซต์/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

และจดพารามิเตอร์ที่กำหนดเองไว้ ปรับใช้/เว็บไซต์/สภาพแวดล้อม/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 กันดีกว่า หยุด_ทบทวนมันจะถูกทริกเกอร์เมื่อมีการลบสาขา และเพื่อให้ gitlab ไม่พยายามชำระเงินก็จะถูกใช้งาน GIT_STRATEGY: ไม่มีต่อมาเราก็โคลน เจ้านาย- แยกสาขาและลบบทวิจารณ์ผ่านมัน
มันสับสนเล็กน้อย แต่ฉันยังไม่พบวิธีที่สวยงามกว่านี้
อีกทางเลือกหนึ่งคือปรับใช้แต่ละรีวิวกับเนมสเปซของโรงแรม ซึ่งสามารถรื้อทิ้งทั้งหมดได้เสมอ

อย่าลืมยอมรับการเปลี่ยนแปลงของเรา:

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

git push, ทดสอบ git checkout -b, การทดสอบต้นกำเนิดของ git push, ตรวจสอบ:

ภาพหน้าจอของสภาพแวดล้อมที่สร้างขึ้นใน Gitlab

ทุกอย่างใช้งานได้เหรอ? - เยี่ยมมาก ลบสาขาทดสอบของเรา: git checkout master, git push origin: ทดสอบเราตรวจสอบว่างานการลบสภาพแวดล้อมทำงานโดยไม่มีข้อผิดพลาด

ฉันต้องการชี้แจงทันทีว่านักพัฒนาคนใดในโครงการสามารถสร้างสาขาได้ เขาก็สามารถเปลี่ยนได้เช่นกัน .gitlab-ci.yml ไฟล์และการเข้าถึงตัวแปรลับ
ดังนั้นจึงขอแนะนำอย่างยิ่งให้อนุญาตให้ใช้กับสาขาที่ได้รับการป้องกันเท่านั้น เช่น ใน เจ้านายหรือสร้างชุดตัวแปรแยกกันสำหรับแต่ละสภาพแวดล้อม

13. ตรวจสอบแอป

รีวิวแอพ นี่คือคุณลักษณะ GitLab ที่ช่วยให้คุณสามารถเพิ่มปุ่มสำหรับแต่ละไฟล์ในพื้นที่เก็บข้อมูลเพื่อดูได้อย่างรวดเร็วในสภาพแวดล้อมที่ปรับใช้

เพื่อให้ปุ่มเหล่านี้ปรากฏขึ้น คุณต้องสร้างไฟล์ .gitlab/เส้นทาง-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"

git pushและตรวจสอบ:

ภาพหน้าจอของปุ่มรีวิวแอป

งานเสร็จแล้ว!

แหล่งที่มาของโครงการ:

บน Gitlab: https://gitlab.com/kvaps/docs.example.org
บน GitHub: https://github.com/kvaps/docs.example.org

ขอบคุณสำหรับความสนใจของคุณ ฉันหวังว่าคุณจะชอบมัน

ที่มา: will.com

ลองใช้เครื่องมือใหม่สำหรับสร้างและปรับใช้อัตโนมัติใน Kubernetes

เนื้อหา

1. ทำความรู้จักกับฮิวโก้

2. การเตรียม Dockerfile

3.ทำความรู้จักกับคานิโกะ

4. ทำความรู้จักกับคิวเบค

5. ลองใช้ Gitlab-runner กับ Kubernetes-executor

6. ปรับใช้แผนภูมิ Helm ด้วย QBEC

7. รู้เบื้องต้นเกี่ยวกับ git-crypt

8. สร้างภาพกล่องเครื่องมือ

9. ไปป์ไลน์แรกของเราและประกอบรูปภาพด้วยแท็ก

10. ระบบอัตโนมัติของการปรับใช้

11. สิ่งประดิษฐ์และการประกอบเมื่อกดให้เป็นต้นแบบ

12. สภาพแวดล้อมแบบไดนามิก

13. ตรวจสอบแอป

งานเสร็จแล้ว!

เพิ่มความคิดเห็น ยกเลิกการตอบ