ສະບາຍດີ! ບໍ່ດົນມານີ້, ເຄື່ອງມືອັດຕະໂນມັດທີ່ເຢັນຫຼາຍໄດ້ຖືກປ່ອຍອອກມາທັງສໍາລັບການສ້າງຮູບພາບ Docker ແລະສໍາລັບການນໍາໃຊ້ກັບ Kubernetes. ໃນເລື່ອງນີ້, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈທີ່ຈະຫລິ້ນກັບ GitLab, ສຶກສາຄວາມສາມາດຂອງມັນຢ່າງລະອຽດແລະ, ແນ່ນອນ, ສ້າງຕັ້ງທໍ່.

ວຽກງານນີ້ໄດ້ຮັບການດົນໃຈຈາກເວັບໄຊທ໌ kubernetes.io, ເຊິ່ງແມ່ນຜະລິດຈາກ ລະຫັດແຫຼ່ງ ອັດຕະໂນມັດ, ແລະສໍາລັບແຕ່ລະຄໍາຮ້ອງຂໍສະນຸກເກີທີ່ສົ່ງ, ຫຸ່ນຍົນອັດຕະໂນມັດສ້າງສະບັບສະແດງຕົວຢ່າງຂອງເວັບໄຊທ໌ທີ່ມີການປ່ຽນແປງຂອງທ່ານແລະສະຫນອງການເຊື່ອມຕໍ່ສໍາລັບການເບິ່ງ.

ຂ້ອຍພະຍາຍາມສ້າງຂະບວນການທີ່ຄ້າຍຄືກັນຕັ້ງແຕ່ເລີ່ມຕົ້ນ, ແຕ່ກໍ່ສ້າງທັງຫມົດໃນ Gitlab CI ແລະເຄື່ອງມືຟຣີທີ່ຂ້ອຍເຄີຍໃຊ້ເພື່ອນໍາໄປໃຊ້ກັບ Kubernetes. ມື້ນີ້ໃນທີ່ສຸດຂ້ອຍຈະບອກເຈົ້າເພີ່ມເຕີມກ່ຽວກັບພວກມັນ.

ບົດຄວາມຈະສົນທະນາກ່ຽວກັບເຄື່ອງມືເຊັ່ນ:
Hugo, qbec, ຄານິໂກ, git-crypt и GitLab CI ກັບການສ້າງສະພາບແວດລ້ອມແບບເຄື່ອນໄຫວ.

ເນື້ອໃນ

1. ພົບກັບ Hugo
2. ກຳລັງກະກຽມ Dockerfile
3. ຮູ້ຈັກກັບ kaniko
4. ຮູ້ຈັກກັບ qbec
5. ພະຍາຍາມ Gitlab-runner ກັບ Kubernetes-executor
6. ນຳໃຊ້ຕາຕະລາງ Helm ກັບ qbec
7. ແນະນຳ git-crypt
8. ການສ້າງຮູບພາບກ່ອງເຄື່ອງມື
9. ທໍ່ທໍາອິດຂອງພວກເຮົາແລະການປະກອບຮູບພາບໂດຍ tags
10. ການນຳໃຊ້ອັດຕະໂນມັດ
11. ປອມແລະການປະກອບໃນເວລາທີ່ຊຸກຍູ້ໃຫ້ແມ່ບົດ
12. ສະພາບແວດລ້ອມແບບເຄື່ອນໄຫວ
13. ກວດເບິ່ງແອັບ

1. ຮູ້ຈັກກັບ Hugo

ເປັນຕົວຢ່າງຂອງໂຄງການຂອງພວກເຮົາ, ພວກເຮົາຈະພະຍາຍາມສ້າງສະຖານທີ່ເຜີຍແຜ່ເອກະສານທີ່ສ້າງຂຶ້ນໃນ Hugo. Hugo ແມ່ນຜູ້ສ້າງເນື້ອຫາຄົງທີ່.

ສໍາລັບຜູ້ທີ່ບໍ່ຄຸ້ນເຄີຍກັບເຄື່ອງກໍາເນີດໄຟຟ້າສະຖິດ, ຂ້າພະເຈົ້າຈະບອກທ່ານຕື່ມອີກເລັກນ້ອຍກ່ຽວກັບພວກມັນ. ບໍ່ເຫມືອນກັບເຄື່ອງຈັກເວັບໄຊທ໌ທໍາມະດາທີ່ມີຖານຂໍ້ມູນແລະບາງ PHP, ເຊິ່ງ, ເມື່ອຖືກຮ້ອງຂໍໂດຍຜູ້ໃຊ້, ການສ້າງຫນ້າເວັບຕ່າງໆ, ເຄື່ອງສ້າງແບບຄົງທີ່ໄດ້ຖືກອອກແບບແຕກຕ່າງກັນເລັກນ້ອຍ. ພວກເຂົາເຈົ້າອະນຸຍາດໃຫ້ທ່ານເອົາແຫຼ່ງຂໍ້ມູນ, ປົກກະຕິແລ້ວຊຸດຂອງໄຟລ໌ໃນ Markdown markup ແລະຮູບແບບຫົວຂໍ້, ຫຼັງຈາກນັ້ນລວບລວມໃຫ້ເຂົາເຈົ້າເຂົ້າໄປໃນເວັບໄຊທ໌ສໍາເລັດສົມບູນ.

ນັ້ນແມ່ນ, ດັ່ງນັ້ນ, ທ່ານຈະໄດ້ຮັບໂຄງສ້າງໄດເລກະທໍລີແລະຊຸດຂອງໄຟລ໌ HTML ທີ່ສ້າງຂຶ້ນ, ເຊິ່ງທ່ານພຽງແຕ່ສາມາດອັບໂຫລດໄປຍັງໂຮດຕິ້ງທີ່ມີລາຄາຖືກແລະໄດ້ຮັບເວັບໄຊທ໌ທີ່ເຮັດວຽກ.

ທ່ານສາມາດຕິດຕັ້ງ Hugo ຢູ່ໃນທ້ອງຖິ່ນແລະລອງມັນອອກ:

ກຳລັງເລີ່ມຕົ້ນເວັບໄຊໃໝ່:

hugo new site docs.example.org

ແລະໃນເວລາດຽວກັນ git repository:

cd docs.example.org
git init

ມາຮອດປະຈຸ, ເວັບໄຊທ໌ຂອງພວກເຮົາແມ່ນ pristine ແລະເພື່ອໃຫ້ບາງສິ່ງບາງຢ່າງປາກົດຢູ່ໃນມັນ, ທໍາອິດພວກເຮົາຈໍາເປັນຕ້ອງເຊື່ອມຕໍ່ຫົວຂໍ້ໃດຫນຶ່ງ; ຫົວຂໍ້ແມ່ນພຽງແຕ່ຊຸດຂອງແມ່ແບບແລະກົດລະບຽບທີ່ກໍານົດໂດຍເວັບໄຊທ໌ຂອງພວກເຮົາຖືກສ້າງຂຶ້ນ.

ສໍາລັບຫົວຂໍ້ທີ່ພວກເຮົາຈະໃຊ້ ຮຽນຮູ້, ເຊິ່ງ, ໃນຄວາມຄິດເຫັນຂອງຂ້າພະເຈົ້າ, ແມ່ນເຫມາະສົມຢ່າງສົມບູນສໍາລັບສະຖານທີ່ເອກະສານ.

ຂ້າພະເຈົ້າຢາກຈະເອົາໃຈໃສ່ເປັນພິເສດຕໍ່ຄວາມຈິງທີ່ວ່າພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງບັນທຶກໄຟລ໌ຫົວຂໍ້ໃນ repository ໂຄງການຂອງພວກເຮົາ; ແທນທີ່ຈະ, ພວກເຮົາສາມາດເຊື່ອມຕໍ່ມັນໂດຍໃຊ້. git ໂມດູນຍ່ອຍ:

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

ດັ່ງນັ້ນ, repository ຂອງພວກເຮົາຈະມີພຽງແຕ່ໄຟລ໌ທີ່ກ່ຽວຂ້ອງໂດຍກົງກັບໂຄງການຂອງພວກເຮົາ, ແລະຫົວຂໍ້ທີ່ເຊື່ອມຕໍ່ຈະຍັງຄົງເປັນການເຊື່ອມຕໍ່ກັບ repository ສະເພາະແລະຄໍາຫມັ້ນສັນຍາໃນມັນ, ນັ້ນແມ່ນ, ມັນສະເຫມີສາມາດດຶງຈາກແຫຼ່ງຕົ້ນສະບັບແລະບໍ່ຕ້ອງຢ້ານ. ການປ່ຽນແປງທີ່ບໍ່ເຂົ້າກັນໄດ້.

ໃຫ້ແກ້ໄຂການຕັ້ງຄ່າ 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

ມັນເປັນເວລາທີ່ຈະກໍານົດໂຄງສ້າງຂອງ repository ຂອງພວກເຮົາ. ຂ້ອຍມັກຈະໃຊ້ບາງຢ່າງເຊັ່ນ:

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

• dockerfiles/ — ມີລາຍການທີ່ມີ 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. ຮູ້ຈັກກັບ kaniko

ໃນຖານະເປັນຜູ້ສ້າງຮູບພາບ docker, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈໃຊ້ ຄານິໂກ, ເນື່ອງຈາກວ່າການດໍາເນີນງານຂອງມັນບໍ່ຈໍາເປັນຕ້ອງມີ docker daemon, ແລະການກໍ່ສ້າງຕົວມັນເອງສາມາດດໍາເນີນການໄດ້ໃນເຄື່ອງໃດກໍ່ຕາມແລະ cache ສາມາດຖືກເກັບໄວ້ໂດຍກົງໃນລີຈິດຊີ, ດັ່ງນັ້ນການກໍາຈັດຄວາມຕ້ອງການທີ່ຈະມີການເກັບຮັກສາຄົງທີ່ເຕັມຮູບແບບ.

ເພື່ອສ້າງຮູບພາບ, ພຽງແຕ່ດໍາເນີນການບັນຈຸກັບ kaniko ປະຕິບັດ ແລະຜ່ານມັນໃນສະພາບການກໍ່ສ້າງໃນປະຈຸບັນ; ນີ້ຍັງສາມາດເຮັດໄດ້ໃນທ້ອງຖິ່ນ, ຜ່ານ 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​.

Parameter --cache ອະນຸຍາດໃຫ້ທ່ານສາມາດ cache ຊັ້ນໃນ docker registry; ສໍາລັບການຍົກຕົວຢ່າງ, ເຂົາເຈົ້າຈະຖືກບັນທຶກໄວ້ໃນ registry.gitlab.com/kvaps/docs.example.org/website/cache, ແຕ່ທ່ານສາມາດລະບຸເສັ້ນທາງອື່ນໂດຍໃຊ້ພາລາມິເຕີ --cache-repo.

ພາບຫນ້າຈໍຂອງ docker-registry

4. ຮູ້ຈັກ qbec

Qbec ເປັນເຄື່ອງມືໃນການນຳໃຊ້ທີ່ອະນຸຍາດໃຫ້ທ່ານອະທິບາຍຢ່າງຈະແຈ້ງກ່ຽວກັບຄໍາຮ້ອງສະຫມັກຂອງທ່ານ manifests ແລະນໍາໄປໃຊ້ກັບ Kubernetes. ການນໍາໃຊ້ Jsonnet ເປັນ syntax ຕົ້ນຕໍຊ່ວຍໃຫ້ທ່ານເຮັດໃຫ້ຄໍາອະທິບາຍຂອງຄວາມແຕກຕ່າງໃນຫຼາຍສະພາບແວດລ້ອມງ່າຍດາຍ, ແລະຍັງເກືອບຫມົດການລົບລ້າງການຊ້ໍາກັນຂອງລະຫັດ.

ນີ້ສາມາດເປັນຄວາມຈິງໂດຍສະເພາະໃນກໍລະນີທີ່ທ່ານຈໍາເປັນຕ້ອງໃຊ້ແອັບພລິເຄຊັນໃຫ້ກັບຫຼາຍໆກຸ່ມທີ່ມີພາລາມິເຕີທີ່ແຕກຕ່າງກັນແລະຕ້ອງການອະທິບາຍຢ່າງຈະແຈ້ງໃນ Git.

Qbec ຍັງອະນຸຍາດໃຫ້ທ່ານສາມາດສະແດງຕາຕະລາງ Helm ໂດຍການຖ່າຍທອດໃຫ້ເຂົາເຈົ້າມີພາລາມິເຕີທີ່ຈໍາເປັນແລະຫຼັງຈາກນັ້ນດໍາເນີນການໃຫ້ເຂົາເຈົ້າໃນລັກສະນະດຽວກັນກັບ manifests ປົກກະຕິ, ລວມທັງທ່ານສາມາດສະຫມັກຂໍເອົາການກາຍພັນຕ່າງໆໃຫ້ເຂົາເຈົ້າ, ແລະນີ້, ແລະເຮັດໃຫ້ການ, ອະນຸຍາດໃຫ້ທ່ານສາມາດກໍາຈັດຄວາມຕ້ອງການ. ໃຊ້ 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. ສະພາບແວດລ້ອມ, qbec ໄດ້ສ້າງສະພາບແວດລ້ອມເລີ່ມຕົ້ນສໍາລັບພວກເຮົາແລ້ວແລະເອົາທີ່ຢູ່ຂອງເຄື່ອງແມ່ຂ່າຍ, ເຊັ່ນດຽວກັນກັບ namespace ຈາກ kubeconfig ໃນປັດຈຸບັນຂອງພວກເຮົາ.
ໃນປັດຈຸບັນໃນເວລາທີ່ deploy ກັບ Default ສະພາບແວດລ້ອມ, qbec ສະເຫມີຈະປະຕິບັດພຽງແຕ່ກັບກຸ່ມ Kubernetes ທີ່ລະບຸໄວ້ແລະກັບ namespace ທີ່ລະບຸ, ນັ້ນແມ່ນ, ທ່ານບໍ່ຈໍາເປັນຕ້ອງປ່ຽນລະຫວ່າງບໍລິບົດແລະ namespaces ເພື່ອປະຕິບັດການນໍາໃຊ້.
ຖ້າຈໍາເປັນ, ທ່ານສາມາດອັບເດດການຕັ້ງຄ່າໃນໄຟລ໌ນີ້ໄດ້ຕະຫຼອດເວລາ.

ສະພາບແວດລ້ອມທັງໝົດຂອງເຈົ້າຖືກອະທິບາຍໄວ້ໃນ qbec.yaml, ແລະໃນໄຟລ໌ params.libsonnet, ບ່ອນທີ່ມັນບອກວ່າບ່ອນໃດທີ່ຈະໄດ້ຮັບພາລາມິເຕີສໍາລັບພວກເຂົາ.

ຕໍ່ໄປພວກເຮົາເບິ່ງສອງໄດເລກະທໍລີ:

• ອົງປະກອບ/ — manifests ທັງ​ຫມົດ​ສໍາ​ລັບ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂອງ​ພວກ​ເຮົາ​ຈະ​ໄດ້​ຮັບ​ການ​ເກັບ​ຮັກ​ສາ​ໄວ້​ຢູ່​ທີ່​ນີ້​; ພວກ​ເຂົາ​ເຈົ້າ​ສາ​ມາດ​ໄດ້​ຮັບ​ການ​ອະ​ທິ​ບາຍ​ທັງ​ໃນ​ໄຟລ​໌ jsonnet ແລະ yaml ປົກ​ກະ​ຕິ
• ສະພາບແວດລ້ອມ/ — ໃນ​ທີ່​ນີ້​ພວກ​ເຮົາ​ຈະ​ອະ​ທິ​ບາຍ​ຕົວ​ແປ​ທັງ​ຫມົດ (ຕົວ​ກໍາ​ນົດ​) ສໍາ​ລັບ​ສະ​ພາບ​ແວດ​ລ້ອມ​ຂອງ​ພວກ​ເຮົາ​.

ໂດຍຄ່າເລີ່ມຕົ້ນພວກເຮົາມີສອງໄຟລ໌:

• ສະພາບແວດລ້ອມ/base.libsonnet - ມັນຈະມີຕົວກໍານົດການທົ່ວໄປສໍາລັບສະພາບແວດລ້ອມທັງຫມົດ
• ສະພາບແວດລ້ອມ/default.libsonnet — ປະ​ກອບ​ດ້ວຍ​ຕົວ​ກໍາ​ນົດ​ການ overridden ສໍາ​ລັບ​ສິ່ງ​ແວດ​ລ້ອມ​ Default

ເປີດໃຫ້ ສະພາບແວດລ້ອມ/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',
    },
  },
}

ໃຫ້ສ້າງອົງປະກອບທໍາອິດຂອງພວກເຮົາ components/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. ຖ້າພວກເຮົາຕ້ອງການ, ພວກເຮົາສາມາດເອົາພວກມັນເຂົ້າໄປໃນອົງປະກອບທີ່ແຕກຕ່າງກັນ, ແຕ່ໃນຂັ້ນຕອນນີ້ຫນຶ່ງຈະພຽງພໍສໍາລັບພວກເຮົາ.

syntax jsonnet ແມ່ນຄ້າຍຄືກັນກັບ json ປົກກະຕິ, ໃນຫຼັກການ, json ປົກກະຕິແມ່ນ jsonnet ທີ່ຖືກຕ້ອງແລ້ວ, ດັ່ງນັ້ນໃນຕອນທໍາອິດມັນອາດຈະງ່າຍຂຶ້ນສໍາລັບທ່ານທີ່ຈະໃຊ້ບໍລິການອອນໄລນ໌ເຊັ່ນ: yaml2json ເພື່ອປ່ຽນ yaml ປົກກະຕິຂອງທ່ານເປັນ json, ຫຼື, ຖ້າອົງປະກອບຂອງທ່ານບໍ່ມີຕົວແປໃດໆ, ຫຼັງຈາກນັ້ນພວກມັນສາມາດຖືກອະທິບາຍໃນຮູບແບບຂອງ yaml ປົກກະຕິ.

ເມື່ອເຮັດວຽກກັບ jsonnet ຂ້າພະເຈົ້າຂໍແນະນໍາໃຫ້ຕິດຕັ້ງ plugin ສໍາລັບບັນນາທິການຂອງທ່ານ

ຕົວຢ່າງ, ມີ plugin ສໍາລັບ vim vim-jsonnet, ເຊິ່ງເປີດການເນັ້ນໄວຍະກອນແລະດໍາເນີນການອັດຕະໂນມັດ jsonnet fmt ທຸກໆຄັ້ງທີ່ທ່ານບັນທຶກ (ຕ້ອງຕິດຕັ້ງ jsonnet).

ທຸກຢ່າງພ້ອມແລ້ວ, ດຽວນີ້ພວກເຮົາສາມາດເລີ່ມນຳໃຊ້ໄດ້:

ເພື່ອເບິ່ງສິ່ງທີ່ພວກເຮົາໄດ້ຮັບ, ໃຫ້ດໍາເນີນການ:

qbec show default

ຢູ່ທີ່ຜົນຜະລິດ, ທ່ານຈະເຫັນ yaml manifests ທີ່ສະແດງຜົນທີ່ຈະຖືກນໍາໃຊ້ກັບກຸ່ມເລີ່ມຕົ້ນ.

ດີຫຼາຍ, ດຽວນີ້ນຳໃຊ້:

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 container) ທີ່ມີ shell ຫຼື docker-executor. ໃນເບື້ອງຕົ້ນ, ພວກເຮົາມີນັກແລ່ນປະເພດນີ້ຈໍານວນຫນຶ່ງທີ່ກໍານົດໃນທົ່ວໂລກຢູ່ໃນ gitlab ຂອງພວກເຮົາ. ພວກເຂົາເຈົ້າເກັບກໍາຮູບພາບ docker ສໍາລັບໂຄງການທັງຫມົດ.

ແຕ່ເປັນການປະຕິບັດໄດ້ສະແດງໃຫ້ເຫັນ, ທາງເລືອກນີ້ບໍ່ແມ່ນທີ່ເຫມາະສົມທີ່ສຸດ, ທັງໃນແງ່ຂອງການປະຕິບັດແລະຄວາມປອດໄພ. ມັນເປັນການດີກວ່າແລະມີອຸດົມການທີ່ຖືກຕ້ອງກວ່າທີ່ຈະມີນັກແລ່ນແຍກຕ່າງຫາກທີ່ຖືກນໍາໃຊ້ສໍາລັບແຕ່ລະໂຄງການ, ຫຼືແມ້ກະທັ້ງສໍາລັບແຕ່ລະສະພາບແວດລ້ອມ.

ໂຊກດີ, ນີ້ບໍ່ແມ່ນບັນຫາທັງຫມົດ, ນັບຕັ້ງແຕ່ນີ້ພວກເຮົາຈະນໍາໃຊ້ gitlab-runner ເປັນສ່ວນຫນຶ່ງຂອງໂຄງການຂອງພວກເຮົາໂດຍກົງໃນ Kubernetes.

Gitlab ສະຫນອງຕາຕະລາງຫມວກກັນກະທົບທີ່ກຽມພ້ອມສໍາລັບການນໍາໃຊ້ gitlab-runner ກັບ Kubernetes. ດັ່ງນັ້ນທັງຫມົດທີ່ທ່ານຈໍາເປັນຕ້ອງເຮັດແມ່ນຊອກຫາ token ລົງທະບຽນ ສໍາລັບໂຄງການຂອງພວກເຮົາໃນ ການຕັ້ງຄ່າ -> CI / CD -> Runners ແລະ​ຜ່ານ​ມັນ​ເປັນ​ຜູ້​ປົກ​ຄອງ​:

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=ຈິງ — ໃຫ້ນັກແລ່ນຈໍານວນສິດທິພິເສດທີ່ຈໍາເປັນເພື່ອສາມາດສ້າງຝັກເພື່ອປະຕິບັດວຽກງານຂອງພວກເຮົາໂດຍໃຊ້ kubernetes-executor.

ຖ້າທຸກສິ່ງທຸກຢ່າງຖືກເຮັດຢ່າງຖືກຕ້ອງ, ທ່ານຄວນເຫັນນັກແລ່ນທີ່ລົງທະບຽນຢູ່ໃນພາກ Runners, ໃນການຕັ້ງຄ່າໂຄງການຂອງທ່ານ.

ພາບໜ້າຈໍຂອງນັກແລ່ນທີ່ເພີ່ມເຂົ້າມາ

ມັນງ່າຍດາຍບໍ? - ແມ່ນ​ແລ້ວ​, ມັນ​ງ່າຍ​ດາຍ​ທີ່​! ບໍ່ຫຍຸ້ງຍາກກັບການລົງທະບຽນນັກແລ່ນດ້ວຍຕົນເອງ, ຈາກນີ້ໄປນັກແລ່ນຈະຖືກສ້າງ ແລະທໍາລາຍອັດຕະໂນມັດ.

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.

ໃນລັກສະນະທີ່ຄ້າຍຄືກັນ, ທ່ານສາມາດເຊື່ອມຕໍ່ repositories ອື່ນໆ, ສໍາລັບການຍົກຕົວຢ່າງ, repository ທັງຫມົດທີ່ມີຕາຕະລາງຢ່າງເປັນທາງການ. https://github.com/helm/charts

ໃຫ້ອະທິບາຍອົງປະກອບ components/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 — 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,
      },
    },
  },
}

ຈ່າຍເອົາໃຈໃສ່ runnerRegistrationToken ພວກເຮົາເອົາຈາກໄຟລ໌ພາຍນອກ ຄວາມລັບ/base.libsonnet, ໃຫ້​ເຮົາ​ສ້າງ​ມັນ​:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

ໃຫ້ກວດເບິ່ງວ່າທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ:

qbec show default

ຖ້າທຸກສິ່ງທຸກຢ່າງຢູ່ໃນລໍາດັບ, ພວກເຮົາສາມາດລຶບການປ່ອຍທີ່ຖືກນໍາໃຊ້ຜ່ານມາຂອງພວກເຮົາຜ່ານ Helm:

helm uninstall gitlab-runner

ແລະ ນຳ ໃຊ້ມັນດ້ວຍວິທີດຽວກັນ, ແຕ່ຜ່ານ qbec:

qbec apply default

7. ການແນະນໍາກ່ຽວກັບ git-crypt

Git-crypt ເປັນເຄື່ອງມືທີ່ອະນຸຍາດໃຫ້ທ່ານສາມາດຕັ້ງຄ່າການເຂົ້າລະຫັດໂປ່ງໃສສໍາລັບ repository ຂອງທ່ານ.

ໃນປັດຈຸບັນ, ໂຄງສ້າງໄດເລກະທໍລີຂອງພວກເຮົາສໍາລັບ 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 ພວກເຮົາຈໍາເປັນຕ້ອງສ້າງລະຫັດສໍາລັບ repository ຂອງພວກເຮົາ:

git crypt init

ຖ້າທ່ານມີກະແຈ PGP, ຫຼັງຈາກນັ້ນທ່ານສາມາດເພີ່ມຕົວທ່ານເອງເປັນຜູ້ຮ່ວມມືສໍາລັບໂຄງການນີ້:

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

ດ້ວຍວິທີນີ້, ທ່ານສາມາດຖອດລະຫັດບ່ອນເກັບຂໍ້ມູນນີ້ໂດຍໃຊ້ກະແຈສ່ວນຕົວຂອງທ່ານໄດ້ຕະຫຼອດເວລາ.

ຖ້າທ່ານບໍ່ມີກະແຈ PGP ແລະບໍ່ໄດ້ຄາດຫວັງ, ທ່ານສາມາດໄປທາງອື່ນແລະສົ່ງອອກກະແຈໂຄງການ:

git crypt export-key /path/to/keyfile

ດັ່ງນັ້ນ, ໃຜກໍ່ຕາມທີ່ມີການສົ່ງອອກ ໄຟລ໌ຄີ ຈະສາມາດຖອດລະຫັດ repository ຂອງທ່ານໄດ້.

ມັນເຖິງເວລາທີ່ຈະຕັ້ງຄວາມລັບທໍາອິດຂອງພວກເຮົາ.
ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າພວກເຮົາຍັງຢູ່ໃນບັນຊີລາຍການ deploy/gitlab-runner/, ບ່ອນທີ່ພວກເຮົາມີໄດເລກະທໍລີ ຄວາມລັບ/, ໃຫ້ເຂົ້າລະຫັດໄຟລ໌ທັງຫມົດໃນມັນ, ສໍາລັບນີ້ພວກເຮົາຈະສ້າງໄຟລ໌ ຄວາມລັບ/.gitattributes ໂດຍ​ມີ​ເນື້ອ​ໃນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

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

ດັ່ງທີ່ເຫັນໄດ້ຈາກເນື້ອຫາ, ໄຟລ໌ທັງຫມົດແມ່ນຫນ້າກາກ * ຈະຖືກຂັບຜ່ານ git-crypt, ຍົກເວັ້ນຫຼາຍທີ່ສຸດ .gitattributes

ພວກເຮົາສາມາດກວດສອບນີ້ໂດຍການແລ່ນ:

git crypt status -e

ຜົນໄດ້ຮັບຈະເປັນບັນຊີລາຍຊື່ຂອງໄຟລ໌ທັງຫມົດໃນ repository ສໍາລັບການເຂົ້າລະຫັດຖືກເປີດໃຊ້

ນັ້ນແມ່ນທັງໝົດ, ດຽວນີ້ພວກເຮົາສາມາດເຮັດການປ່ຽນແປງຂອງພວກເຮົາໄດ້ຢ່າງປອດໄພ:

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

ເພື່ອບລັອກບ່ອນເກັບມ້ຽນ, ພຽງແຕ່ດໍາເນີນການ:

git crypt lock

ແລະທັນທີທຸກໄຟລ໌ທີ່ຖືກເຂົ້າລະຫັດຈະປ່ຽນເປັນສອງອັນ, ມັນຈະເປັນໄປບໍ່ໄດ້ທີ່ຈະອ່ານພວກມັນ.
ເພື່ອຖອດລະຫັດ repository, ດໍາເນີນການ:

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

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ໃນຮູບນີ້, ພວກເຮົາຕິດຕັ້ງອຸປະກອນຕ່າງໆທີ່ພວກເຮົາໃຊ້ເພື່ອປະຕິບັດຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ. ພວກເຮົາບໍ່ຕ້ອງການມັນຢູ່ທີ່ນີ້ເວັ້ນເສຍແຕ່ kubectl, ແຕ່ທ່ານອາດຈະຕ້ອງການຫຼິ້ນກັບມັນໃນລະຫວ່າງໄລຍະການຕິດຕັ້ງທໍ່.

ນອກຈາກນັ້ນ, ເພື່ອໃຫ້ສາມາດສື່ສານກັບ Kubernetes ແລະນໍາໃຊ້ກັບມັນ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ກໍານົດບົດບາດສໍາລັບ pods ທີ່ສ້າງຂຶ້ນໂດຍ gitlab-runner.

ເພື່ອເຮັດສິ່ງນີ້, ໃຫ້ໄປທີ່ໄດເລກະທໍລີກັບ gitlab-runner:

cd deploy/gitlab-runner

ແລະເພີ່ມອົງປະກອບໃຫມ່ components/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',
    },
  },
}

ຈ່າຍເອົາໃຈໃສ່ $.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. ທໍ່ທໍາອິດຂອງພວກເຮົາແລະປະກອບຮູບພາບໂດຍ tags

ຢູ່ຮາກຂອງໂຄງການທີ່ພວກເຮົາຈະສ້າງ .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: ປົກກະຕິ ສໍາລັບວຽກເຫຼົ່ານັ້ນທີ່ທ່ານຈໍາເປັນຕ້ອງເລີ່ມຕົ້ນ submodules ຢ່າງຊັດເຈນກ່ອນທີ່ຈະປະຕິບັດ.

ຢ່າລືມເຮັດການປ່ຽນແປງຂອງພວກເຮົາ:

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

ຂ້າພະເຈົ້າຄິດວ່າພວກເຮົາສາມາດໂທຫາສະບັບນີ້ຢ່າງປອດໄພ v0.0.1 ແລະເພີ່ມແທັກ:

git tag v0.0.1

ພວກເຮົາຈະເພີ່ມແທັກທຸກຄັ້ງທີ່ພວກເຮົາຕ້ອງການອອກເວີຊັນໃໝ່. ແທັກໃນຮູບພາບ Docker ຈະຖືກຜູກມັດກັບແທັກ Git. ແຕ່ລະການຊຸກຍູ້ທີ່ມີແທັກໃຫມ່ຈະເລີ່ມຕົ້ນການສ້າງຮູບພາບທີ່ມີແທັກນີ້.

ໃຫ້ເຮັດມັນ git push --tags, ແລະໃຫ້ເບິ່ງທໍ່ທໍາອິດຂອງພວກເຮົາ:

ພາບຫນ້າຈໍຂອງທໍ່ທໍາອິດ

ມັນເປັນມູນຄ່າທີ່ຈະດຶງດູດຄວາມສົນໃຈຂອງທ່ານຕໍ່ກັບຄວາມຈິງທີ່ວ່າການປະກອບໂດຍ tags ແມ່ນເຫມາະສົມສໍາລັບການສ້າງຮູບພາບ docker, ແຕ່ບໍ່ເຫມາະສົມສໍາລັບການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກກັບ Kubernetes. ເນື່ອງຈາກແທໍກໃຫມ່ສາມາດຖືກມອບຫມາຍໃຫ້ກັບຄໍາຫມັ້ນສັນຍາເກົ່າ, ໃນກໍລະນີນີ້, ການເລີ່ມຕົ້ນທໍ່ສໍາລັບພວກມັນຈະນໍາໄປສູ່ການນໍາໃຊ້ສະບັບເກົ່າ.

ເພື່ອແກ້ໄຂບັນຫານີ້, ປົກກະຕິແລ້ວການສ້າງຮູບພາບ docker ແມ່ນຜູກມັດກັບ tags, ແລະການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກກັບສາຂາ. ຕົ້ນສະບັບ, ໃນສະບັບຂອງຮູບພາບທີ່ເກັບກໍາແມ່ນ hardcoded. ນີ້ແມ່ນບ່ອນທີ່ທ່ານສາມາດເລີ່ມຕົ້ນການກັບຄືນດ້ວຍການກັບຄືນແບບງ່າຍດາຍ ຕົ້ນສະບັບ- ສາຂາ.

10. ອັດຕະໂນມັດຂອງການປະຕິບັດ

ເພື່ອໃຫ້ Gitlab-runner ຖອດລະຫັດຄວາມລັບຂອງພວກເຮົາ, ພວກເຮົາຈະຕ້ອງສົ່ງອອກລະຫັດ repository ແລະເພີ່ມມັນໃສ່ຕົວແປສະພາບແວດລ້ອມ CI ຂອງພວກເຮົາ:

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

ພວກເຮົາຈະບັນທຶກເສັ້ນຜົນໄດ້ຮັບໃນ Gitlab; ເພື່ອເຮັດສິ່ງນີ້, ໃຫ້ໄປທີ່ການຕັ້ງຄ່າໂຄງການຂອງພວກເຮົາ:
ການຕັ້ງຄ່າ -> CI / CD -> ຕົວແປ

ແລະຂໍໃຫ້ສ້າງຕົວແປໃຫມ່:

ປະເພດ
ທີ່ສໍາຄັນ
ມູນຄ່າ
ປົກປ້ອງ
Masked
ຂອບເຂດ

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 ບາງ / app — ອະ​ນຸ​ຍາດ​ໃຫ້​ທ່ານ​ເພື່ອ​ກໍາ​ນົດ​ລະ​ບົບ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​
• --force:k8s-context __incluster__ - ນີ້ແມ່ນຕົວແປ magic ທີ່ບອກວ່າ deployment ຈະເກີດຂຶ້ນໃນ cluster ດຽວກັນທີ່ gtilab-runner ແລ່ນຢູ່. ນີ້ແມ່ນສິ່ງຈໍາເປັນເພາະວ່າຖ້າບໍ່ດັ່ງນັ້ນ qbec ຈະພະຍາຍາມຊອກຫາເຄື່ອງແມ່ຂ່າຍ Kubernetes ທີ່ເຫມາະສົມໃນ kubeconfig ຂອງທ່ານ
• --ລໍຖ້າ — ບັງຄັບ qbec ໃຫ້ລໍຖ້າຈົນກ່ວາຊັບພະຍາກອນທີ່ມັນສ້າງເຂົ້າໄປໃນສະຖານະ Ready ແລະພຽງແຕ່ຫຼັງຈາກນັ້ນອອກດ້ວຍ exit-code ສໍາເລັດ.
• — ແມ່ນ​ແລ້ວ - ພຽງແຕ່ປິດການທໍາງານຂອງແກະການໂຕ້ຕອບ ເຈົ້າ​ແນ່​ໃຈ​ບໍ່? ເມື່ອຖືກນຳໃຊ້.

ຢ່າລືມເຮັດການປ່ຽນແປງຂອງພວກເຮົາ:

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

ແລະຫຼັງຈາກ git ຊຸກຍູ້ ພວກ​ເຮົາ​ຈະ​ເຫັນ​ວ່າ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂອງ​ພວກ​ເຮົາ​ໄດ້​ຮັບ​ການ​ນໍາ​ໃຊ້​:

ພາບຫນ້າຈໍຂອງທໍ່ທີສອງ

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, ນັ້ນແມ່ນ, ພວກເຮົາຖືກ untied ຈາກ tags ໃນ Git ແລະໃນປັດຈຸບັນພວກເຮົາຈະຍູ້ຮູບພາບທີ່ມີຊື່ຂອງສາຂາຄໍາຫມັ້ນສັນຍາທີ່ເລີ່ມຕົ້ນທໍ່. ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່ານີ້ຍັງຈະເຮັດວຽກກັບ tags, ເຊິ່ງຈະຊ່ວຍໃຫ້ພວກເຮົາສາມາດບັນທຶກພາບລວມຂອງເວັບໄຊທ໌ທີ່ມີສະບັບສະເພາະໃນ docker-registry.

ເມື່ອຊື່ຂອງແທໍກ docker ສໍາລັບເວັບໄຊທ໌ຮຸ່ນໃຫມ່ບໍ່ສາມາດປ່ຽນແປງໄດ້, ພວກເຮົາຍັງຕ້ອງອະທິບາຍການປ່ຽນແປງຂອງ Kubernetes, ຖ້າບໍ່ດັ່ງນັ້ນມັນຈະບໍ່ນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກຄືນໃຫມ່ຈາກຮູບພາບໃຫມ່, ເພາະວ່າມັນຈະບໍ່ສັງເກດເຫັນການປ່ຽນແປງໃດໆໃນ manifest ການ​ນໍາ​ໃຊ້​.

ທາງເລືອກ —vm:ext-str digest=”$DIGEST” ສໍາລັບ qbec - ອະນຸຍາດໃຫ້ທ່ານຜ່ານຕົວແປພາຍນອກໄປຫາ jsonnet. ພວກເຮົາຕ້ອງການໃຫ້ມັນຖືກນໍາມາໃຊ້ຄືນໃນກຸ່ມກັບແຕ່ລະການປ່ອຍແອັບພລິເຄຊັນຂອງພວກເຮົາ. ພວກເຮົາບໍ່ສາມາດໃຊ້ຊື່ແທັກໄດ້ອີກຕໍ່ໄປ, ເຊິ່ງຕອນນີ້ບໍ່ສາມາດປ່ຽນແປງໄດ້, ເພາະວ່າພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຜູກມັດກັບຮູບພາບສະບັບສະເພາະ ແລະ ກະຕຸ້ນການນຳໃຊ້ເມື່ອມັນປ່ຽນແປງ.

ໃນທີ່ນີ້ພວກເຮົາຈະໄດ້ຮັບການຊ່ວຍໂດຍຄວາມສາມາດຂອງ Kaniko ເພື່ອບັນທຶກຮູບພາບຍ່ອຍເຂົ້າໄປໃນໄຟລ໌ (ທາງເລືອກ --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"

ພວກເຮົາຈະກວດສອບພາຍຫຼັງ git ຊຸກຍູ້ ພວກເຮົາຄວນຈະເຫັນບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

ພາບຫນ້າຈໍຂອງທໍ່ສໍາລັບແມ່ບົດ

ໃນຫຼັກການ, ພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງໃຊ້ 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"

git ຊຸກຍູ້, ມັນດີກວ່າ:

ພາບໜ້າຈໍຂອງທໍ່ທີ່ອັບເດດແລ້ວ

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"

ນີ້ຈະຊ່ວຍໃຫ້ 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-tag — ມັນອະນຸຍາດໃຫ້ທ່ານແທັກເວີຊັນທີ່ນຳໃຊ້ຂອງແອັບພລິເຄຊັນ ແລະເຮັດວຽກພາຍໃນແທັກນີ້ເທົ່ານັ້ນ; ເມື່ອສ້າງ ແລະທຳລາຍຊັບພະຍາກອນໃນ 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',
    },
  },
}

ຂໍໃຫ້ພິຈາລະນາເບິ່ງວຽກທີ່ໃກ້ຊິດ stop_review, ມັນຈະຖືກກະຕຸ້ນເມື່ອສາຂາຖືກລຶບແລະເພື່ອໃຫ້ gitlab ບໍ່ພະຍາຍາມຈ່າຍເງິນມັນຖືກນໍາໃຊ້. GIT_STRATEGY: ບໍ່ມີ, ຕໍ່ມາພວກເຮົາ clone ຕົ້ນສະບັບ- ສາຂາແລະລົບການທົບທວນຄືນໂດຍຜ່ານມັນ.
ມັນສັບສົນເລັກນ້ອຍ, ແຕ່ຂ້ອຍບໍ່ພົບວິທີທີ່ສວຍງາມກວ່ານີ້.
ທາງ​ເລືອກ​ອື່ນ​ຈະ​ເປັນ​ການ​ນຳ​ໃຊ້​ການ​ທົບ​ທວນ​ຄືນ​ແຕ່​ລະ​ອັນ​ໄປ​ຫາ​ບ່ອນ​ຕັ້ງ​ຊື່​ຂອງ​ໂຮງ​ແຮມ, ເຊິ່ງ​ສາ​ມາດ​ຖືກ​ລົບ​ລ້າງ​ທັງ​ໝົດ.

ຢ່າລືມເຮັດການປ່ຽນແປງຂອງພວກເຮົາ:

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

git ຊຸກຍູ້, git checkout -b ການທົດສອບ, git push ການທົດສອບຕົ້ນກໍາເນີດ, ກວດເບິ່ງ:

ພາບໜ້າຈໍຂອງສະພາບແວດລ້ອມທີ່ສ້າງຂຶ້ນໃນ Gitlab

ທຸກຢ່າງເຮັດວຽກບໍ? - ດີຫຼາຍ, ລຶບສາຂາທົດສອບຂອງພວກເຮົາ: git checkout ຕົ້ນສະບັບ, git push ຕົ້ນກໍາເນີດ: ການທົດສອບ, ພວກເຮົາກວດເບິ່ງວ່າວຽກການລຶບສະພາບແວດລ້ອມເຮັດວຽກໂດຍບໍ່ມີຂໍ້ຜິດພາດ.

ໃນທີ່ນີ້ຂ້າພະເຈົ້າຢາກຈະໃຫ້ຄວາມກະຈ່າງແຈ້ງທັນທີວ່າຜູ້ພັດທະນາໃດໆໃນໂຄງການສາມາດສ້າງສາຂາ, ລາວຍັງສາມາດປ່ຽນແປງໄດ້ .gitlab-ci.yml ໄຟລ໌ແລະເຂົ້າເຖິງຕົວແປລັບ.
ດັ່ງນັ້ນ, ມັນແມ່ນແນະນໍາໃຫ້ຢ່າງແຂງແຮງທີ່ຈະອະນຸຍາດໃຫ້ນໍາໃຊ້ຂອງເຂົາເຈົ້າພຽງແຕ່ສໍາລັບສາຂາປ້ອງກັນ, ສໍາລັບການຍົກຕົວຢ່າງໃນ ຕົ້ນສະບັບ, ຫຼືສ້າງຊຸດຕົວແປແຍກຕ່າງຫາກສໍາລັບແຕ່ລະສະພາບແວດລ້ອມ.

13. ກວດເບິ່ງແອັບ

ກວດເບິ່ງແອັບ ນີ້ແມ່ນຄຸນສົມບັດ GitLab ທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດເພີ່ມປຸ່ມສໍາລັບແຕ່ລະໄຟລ໌ໃນ repository ເພື່ອເບິ່ງມັນຢ່າງໄວວາໃນສະພາບແວດລ້ອມທີ່ຖືກນໍາໃຊ້.

ເພື່ອໃຫ້ປຸ່ມເຫຼົ່ານີ້ປາກົດ, ທ່ານຈໍາເປັນຕ້ອງສ້າງໄຟລ໌ .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"

git ຊຸກຍູ້, ແລະກວດເບິ່ງ:

ພາບໜ້າຈໍຂອງປຸ່ມທົບທວນແອັບ

ວຽກສຳເລັດແລ້ວ!

ແຫຼ່ງໂຄງການ:

• ໃນ Gitlab: https://gitlab.com/kvaps/docs.example.org
• ໃນ GitHub: https://github.com/kvaps/docs.example.org

ຂອບໃຈສໍາລັບຄວາມສົນໃຈຂອງເຈົ້າ, ຂ້ອຍຫວັງວ່າເຈົ້າຈະມັກມັນ

ແຫຼ່ງຂໍ້ມູນ: www.habr.com