Helo! Mae llawer o offer awtomeiddio cŵl wedi'u rhyddhau yn ddiweddar ar gyfer adeiladu delweddau Docker a'u defnyddio i Kubernetes. Yn hyn o beth, penderfynais chwarae o gwmpas gyda Gitlab, sut i astudio ei alluoedd ac, wrth gwrs, sefydlu piblinell.

Ysbrydolwyd y wefan hon gan kubernetes.io, sy'n cael ei gynhyrchu o codau ffynhonnell yn awtomatig, ac ar gyfer pob cais tynnu a anfonir, mae'r robot yn cynhyrchu fersiwn rhagolwg o'r wefan yn awtomatig gyda'ch newidiadau ac yn darparu dolen i'w gweld.

Ceisiais adeiladu proses debyg o'r dechrau, ond wedi'i hadeiladu'n llwyr ar Gitlab CI ac offer rhad ac am ddim yr oeddwn yn arfer eu defnyddio i ddefnyddio cymwysiadau i Kubernetes. Heddiw, byddaf o'r diwedd yn dweud mwy wrthych amdanynt.

Bydd yr erthygl yn ymdrin ag offer fel:
Hugo, qbec, kaniko, git-crypt и GitLab CI gyda chreu amgylcheddau deinamig.

Cynnwys

1. Dod i adnabod Hugo
2. Paratoi'r Dockerfile
3. Dod i adnabod kaniko
4. Rhagymadrodd i qbec
5. Ceisio Gitlab-redwr gyda Kubernetes-ysgutor
6. Defnyddio siartiau Helm gyda qbec
7. Cyflwyniad i git-crypt
8. Creu delwedd blwch offer
9. Ein piblinell a'n cydosodiad cyntaf o ddelweddau trwy dagiau
10. Defnyddio awtomeiddio
11. Arteffactau a chynulliad wrth wthio i feistr
12. Amgylcheddau deinamig
13. Adolygu Apps

1. Dod i adnabod Hugo

Fel enghraifft o'n prosiect, byddwn yn ceisio creu gwefan cyhoeddi dogfennaeth wedi'i hadeiladu ar Hugo. Mae Hugo yn gynhyrchydd cynnwys statig.

I'r rhai nad ydynt yn gyfarwydd â generaduron sefydlog, dywedaf ychydig mwy wrthych amdanynt. Yn wahanol i beiriannau gwefan arferol gyda chronfa ddata a rhyw fath o php, sydd, ar gais y defnyddiwr, yn cynhyrchu tudalennau ar y hedfan, mae generaduron sefydlog yn cael eu trefnu ychydig yn wahanol. Maent yn caniatáu ichi gymryd y cod ffynhonnell, fel arfer set o ffeiliau yn Markdown markup a thempledi thema, yna eu crynhoi i mewn i safle cwbl orffenedig.

Hynny yw, yn yr allbwn fe gewch strwythur cyfeiriadur a set o ffeiliau html a gynhyrchir y gallwch eu huwchlwytho i unrhyw westeiwr rhad a chael gwefan weithio.

Gallwch chi osod Hugo yn lleol a rhoi cynnig arni:

Cychwyn y wefan newydd:

hugo new site docs.example.org

Ac ar yr un pryd y storfa git:

cd docs.example.org
git init

Hyd yn hyn, mae ein gwefan yn newydd ac er mwyn i rywbeth ymddangos arno, yn gyntaf mae angen i ni gysylltu thema, dim ond set o dempledi a rheolau gosod ar gyfer cynhyrchu ein gwefan yw thema.

Fel thema byddwn yn defnyddio Dysgu, sydd, yn fy marn i, yn fwyaf addas ar gyfer safle gyda dogfennaeth.

Hoffwn roi sylw arbennig i'r ffaith nad oes angen i ni gadw'r ffeiliau thema yn ystorfa ein prosiect, yn lle hynny gallwn ei gysylltu gan ddefnyddio is-fodiwl git:

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

Felly, dim ond ffeiliau sy'n ymwneud yn uniongyrchol â'n prosiect fydd yn ein cadwrfa, a bydd y thema gysylltiedig yn parhau i fod yn ddolen i ystorfa benodol ac ymrwymiad ynddi, hynny yw, gellir ei thynnu o'r ffynhonnell wreiddiol bob amser a pheidiwch â bod ofn. o newidiadau anghydnaws.

Gadewch i ni drwsio'r ffurfwedd config.toml:

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

Eisoes ar y cam hwn, gallwch chi redeg:

hugo server

Ac yn y cyfeiriad http://localhost:1313/ gwiriwch ein gwefan sydd newydd ei chreu, mae'r holl newidiadau a wneir yn y cyfeiriadur yn diweddaru'r dudalen agored yn y porwr yn awtomatig, yn gyfleus iawn!

Gadewch i ni geisio creu tudalen deitl yn cynnwys/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

Ciplun o'r dudalen sydd newydd ei chreu

I gynhyrchu gwefan, rhedwch:

hugo

Cynnwys cyfeiriadur cyhoeddus / a bydd yn eich safle.
Ie, gyda llaw, gadewch i ni ddod ag ef i mewn ar unwaith .gitnore:

echo /public > .gitignore

Peidiwch ag anghofio ymrwymo ein newidiadau:

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

2. Paratoi'r Dockerfile

Mae'n bryd diffinio strwythur ein cadwrfa. Fel arfer rwy'n defnyddio rhywbeth fel:

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

• ffeiliau doc/ - yn cynnwys cyfeiriaduron gyda Dockerfiles a phopeth sydd ei angen i adeiladu ein delweddau docwr.
• defnyddio / - yn cynnwys cyfeiriaduron ar gyfer defnyddio ein cymwysiadau yn Kubernetes

Felly, byddwn yn creu ein Dockerfile cyntaf ar hyd y ffordd dockerfiles/gwefan/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" ]

Fel y gwelwch, mae'r Dockerfile yn cynnwys dau O, gelwir y posibilrwydd hwn adeiladu aml-gam ac yn eich galluogi i eithrio popeth diangen o ddelwedd terfynol y docwr.
Felly, bydd y ddelwedd derfynol yn cynnwys yn unig tywyllhttpd (gweinydd HTTP ysgafn) a cyhoeddus / - cynnwys ein gwefan a gynhyrchir yn statig.

Peidiwch ag anghofio ymrwymo ein newidiadau:

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

3. Dod i adnabod kaniko

Fel adeiladwr delweddau docwyr, penderfynais ddefnyddio kaniko, gan nad oes angen daemon docwr arno i weithio, a gellir cynnal y cynulliad ei hun ar unrhyw beiriant a storio'r storfa yn uniongyrchol yn y gofrestrfa, a thrwy hynny gael gwared ar yr angen i gael storfa barhaus lawn.

I adeiladu'r ddelwedd, rhedwch y cynhwysydd gyda ysgutor kaniko a phasio'r cyd-destun adeiladu presennol iddo, gallwch ei wneud yn lleol, trwy docwr:

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

Lle registry.gitlab.com/kvaps/docs.example.org/website - enw eich delwedd docwr, ar ôl ei adeiladu bydd yn cael ei lansio'n awtomatig yn y gofrestr docwr.

Paramedr --cache yn caniatáu ichi storio haenau yn y gofrestrfa docwyr, ar gyfer yr enghraifft a roddir byddant yn cael eu storio ynddo registry.gitlab.com/kvaps/docs.example.org/website/cache, ond gallwch chi nodi llwybr arall gyda'r paramedr --cache-repo.

Sgrinlun o gofrestrfa docwyr

4. Rhagymadrodd qbec

Qbec yn offeryn lleoli sy'n eich galluogi i ddisgrifio'ch maniffestau cais yn ddatganiadol a'u defnyddio i Kubernetes. Mae defnyddio Jsonnet fel y brif gystrawen yn ei gwneud hi'n hawdd iawn disgrifio'r gwahaniaethau ar gyfer amgylcheddau lluosog, ac mae hefyd bron yn gyfan gwbl yn dileu ailadrodd cod.

Gall hyn fod yn arbennig o wir mewn achosion lle mae angen i chi ddefnyddio cymhwysiad mewn sawl clwstwr gyda pharamedrau gwahanol ac eisiau eu disgrifio'n ddatganiadol yn Git.

Mae Qbec hefyd yn caniatáu ichi wneud siartiau Helm trwy basio'r paramedrau angenrheidiol iddynt ac yna gweithredu arnynt yn yr un modd ag amlygiadau rheolaidd, gan gynnwys y gallu i gymhwyso treigladau amrywiol iddynt, ac mae hyn, yn ei dro, yn dileu'r angen i ddefnyddio ChartMuseum. Hynny yw, gallwch storio a rendr siartiau yn uniongyrchol o git, lle maent yn perthyn.

Fel y dywedais o'r blaen, byddwn yn storio'r holl leoliadau yn y cyfeiriadur defnyddio /:

mkdir deploy
cd deploy

Gadewch i ni gychwyn ein cais cyntaf:

qbec init website
cd website

Nawr mae strwythur ein cais yn edrych fel hyn:

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

edrych ar y ffeil qbec.yaml:

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

Yma mae gennym ddiddordeb yn bennaf sbec.amgylcheddau, Mae qbec eisoes wedi creu'r amgylchedd rhagosodedig i ni ac wedi cymryd cyfeiriad y gweinydd a gofod enw o'n kubeconfig cyfredol.
Nawr wrth anfon i diofyn amgylchedd, bydd qbec bob amser yn defnyddio i'r clwstwr Kubernetes penodedig yn unig ac i'r gofod enwau penodedig, h.y. nid oes yn rhaid i chi newid rhwng cyd-destunau a gofodau enwau mwyach er mwyn defnyddio.
Os oes angen, gallwch chi bob amser ddiweddaru'r gosodiadau yn y ffeil hon.

Disgrifir eich holl amgylcheddau yn qbec.yaml, ac yn y ffeil params.libsonnet, sy'n dweud lle mae angen i chi gymryd y paramedrau ar eu cyfer.

Nesaf gwelwn ddau gyfeiriadur:

• cydrannau / - bydd pob maniffest ar gyfer ein cais yn cael ei storio yma, gellir eu disgrifio yn jsonnet ac mewn ffeiliau yaml rheolaidd
• amgylcheddau/ - yma byddwn yn disgrifio'r holl newidynnau (paramedrau) ar gyfer ein hamgylcheddau.

Yn ddiofyn mae gennym ddwy ffeil:

• amgylcheddau/base.libsonnet - bydd yn cynnwys paramedrau cyffredin ar gyfer pob amgylchedd
• amgylcheddau/diofyn.libsonnet - yn cynnwys paramedrau wedi'u hailddiffinio ar gyfer yr amgylchedd diofyn

gadewch i ni agor amgylcheddau/base.libsonnet ac ychwanegu paramedrau ar gyfer ein cydran gyntaf yno:

{
  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',
    },
  },
}

Gadewch i ni hefyd greu ein cydran gyntaf cydrannau/gwefan.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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

Yn y ffeil hon, fe wnaethom ddisgrifio tri endid Kubernetes ar unwaith, sef: Defnyddio, Gwasanaeth и Mynd i mewn. Os dymunir, gallem eu symud i wahanol gydrannau, ond ar hyn o bryd, mae un yn ddigon i ni.

cystrawen jsonnet yn debyg iawn i json rheolaidd, mewn egwyddor, mae json rheolaidd eisoes yn jsonnet dilys, felly ar y dechrau efallai y bydd yn haws i chi ddefnyddio gwasanaethau ar-lein fel yaml2json i drosi eich yaml arferol i json, neu os nad yw eich cydrannau yn cynnwys unrhyw newidynnau, yna gellir eu disgrifio ar ffurf yaml rheolaidd.

Wrth weithio gyda jsonnet Rwy'n eich cynghori'n gryf i osod ategyn ar gyfer eich golygydd

Er enghraifft, mae yna ategyn ar gyfer vim vim-jsonnet, sy'n troi ar amlygu cystrawen ac yn gweithredu'n awtomatig jsonnet fmt ar bob arbediad (mae angen gosod jsonnet).

Mae popeth yn barod, nawr gallwn ni ddechrau'r defnydd:

I weld beth gawson ni, gadewch i ni redeg:

qbec show default

Yn yr allbwn, fe welwch yr amlygiadau yaml wedi'u rendro a fydd yn cael eu cymhwyso i'r clwstwr rhagosodedig.

Gwych, gwnewch gais nawr:

qbec apply default

Ar yr allbwn fe welwch bob amser beth fydd yn cael ei wneud yn eich clwstwr, bydd qbec yn gofyn ichi dderbyn y newidiadau trwy deipio y gallwch gadarnhau eich bwriadau.

Wedi'i wneud nawr mae ein ap wedi'i ddefnyddio!

Os gwneir newidiadau, gallwch bob amser redeg:

qbec diff default

i weld sut y bydd y newidiadau hyn yn effeithio ar y defnydd presennol

Peidiwch ag anghofio ymrwymo ein newidiadau:

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

5. Rhowch gynnig ar Gitlab-runner gyda Kubernetes-ysgutor

Tan yn ddiweddar, dim ond rheolaidd rydw i wedi'i ddefnyddio gitlab-redwr ar beiriant a baratowyd ymlaen llaw (cynhwysydd LXC) gyda ysgutor cragen neu docwr. I ddechrau, roedd gennym nifer o'r rhedwyr hyn wedi'u diffinio'n fyd-eang yn ein gitlab. Fe wnaethon nhw adeiladu delweddau docwyr ar gyfer pob prosiect.

Ond fel y dangosodd arfer, nid yr opsiwn hwn yw'r mwyaf delfrydol, o ran ymarferoldeb ac o ran diogelwch. Mae'n llawer gwell ac yn ideolegol gywir i gael rhedwyr ar wahân ar gyfer pob prosiect, a hyd yn oed ar gyfer pob amgylchedd.

Yn ffodus, nid yw hyn yn broblem o gwbl, oherwydd nawr byddwn yn defnyddio gitlab-redwr yn uniongyrchol fel rhan o'n prosiect yn Kubernetes.

Mae Gitlab yn darparu siart helm parod ar gyfer lleoli rhedwr gitlab i Kubernetes. Felly y cyfan sydd angen i chi ei wybod yw tocyn cofrestru ar gyfer ein prosiect yn Gosodiadau -> CI / CD -> Rhedwyr a'i drosglwyddo i lyw:

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

Ble:

• https://gitlab.com yw cyfeiriad eich gweinydd Gitlab.
• yga8y-jdCusVDn_t4Wxc - tocyn cofrestru ar gyfer eich prosiect.
• rbac.create=gwir - yn rhoi'r nifer angenrheidiol o freintiau i'r rhedwr allu creu codennau i gyflawni ein tasgau gan ddefnyddio kubernetes-ysgutor.

Os gwneir popeth yn gywir, dylech weld y rhedwr cofrestredig yn yr adran Rhedwyr, yng ngosodiadau eich prosiect.

Sgrinlun o'r rhedwr ychwanegol

A yw mor syml â hynny? - ydy, mae mor syml â hynny! Dim mwy o drafferth gyda chofrestru rhedwyr â llaw, o hyn ymlaen bydd rhedwyr yn cael eu creu a'u dinistrio'n awtomatig.

6. Defnyddio siartiau Helm gyda QBEC

Ers i ni benderfynu ystyried gitlab-redwr rhan o'n prosiect, mae'n bryd ei ddisgrifio yn ein cadwrfa Git.

Gallem ei ddisgrifio fel cydran ar wahân wefan, ond yn y dyfodol rydym yn bwriadu defnyddio gwahanol gopïau wefan yn aml iawn, yn wahanol gitlab-redwr, a fydd yn cael ei ddefnyddio unwaith yn unig fesul clwstwr Kubernetes. Felly gadewch i ni gychwyn cais ar wahân ar ei gyfer:

cd deploy
qbec init gitlab-runner
cd gitlab-runner

Y tro hwn ni fyddwn yn disgrifio endidau Kubernetes â llaw, ond yn cymryd siart Helm parod. Un o fanteision qbec yw'r gallu i rendro siartiau Helm yn uniongyrchol o ystorfa Git.

Gadewch i ni ei alluogi gan ddefnyddio is-fodiwl git:

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

Nawr bod y cyfeiriadur gwerthwr/gitlab-rhedwr yn cynnwys ein cadwrfa gyda siart ar gyfer rhedwr gitlab.

Gellir cysylltu storfeydd eraill mewn ffordd debyg, er enghraifft, yr ystorfa gyfan â siartiau swyddogol https://github.com/helm/charts

Gadewch i ni ddisgrifio'r gydran cydrannau/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,
  }
)

Y ddadl gyntaf i ehanguHelmTemplate rydym yn pasio'r llwybr i'r siart, felly params.values, yr ydym yn ei gymryd o baramedrau'r amgylchedd, yna daw'r gwrthrych gyda

• nameTemplate - enw rhyddhau
• gofod enwau - gofod enwau wedi'i basio i'r llyw
• y Ffeil hon - paramedr gofynnol sy'n pasio'r llwybr i'r ffeil gyfredol
• air am air - yn dangos gorchymyn templed helm gyda phob dadl wrth rendro siart

Nawr, gadewch i ni ddisgrifio'r paramedrau ar gyfer ein cydran yn amgylcheddau/base.libsonnet:

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

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

Talu sylw rhedwrRegistrationToken rydym yn nôl o ffeil allanol cyfrinachau/base.libsonnet, gadewch i ni ei greu:

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

Gadewch i ni wirio a yw popeth yn gweithio:

qbec show default

os yw popeth mewn trefn, yna gallwn gael gwared ar y rhai a ddefnyddiwyd yn gynharach trwy ryddhau Helm:

helm uninstall gitlab-runner

a'i defnyddio, ond trwy qbec:

qbec apply default

7. Cyflwyniad i git-crypt

git-crypt yn offeryn sy'n eich galluogi i sefydlu amgryptio tryloyw ar gyfer eich ystorfa.

Ar hyn o bryd, mae ein strwythur cyfeiriadur ar gyfer rhedwr gitlab yn edrych fel hyn:

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

Ond nid yw storio cyfrinachau yn Git yn ddiogel, ynte? Felly mae angen i ni eu hamgryptio'n iawn.

Fel arfer er mwyn un newidyn nid yw bob amser yn gwneud synnwyr. Gallwch drosglwyddo cyfrinachau i qbec a thrwy newidynnau amgylcheddol eich system CI.
Ond mae'n werth nodi bod yna hefyd brosiectau mwy cymhleth a all gynnwys llawer mwy o gyfrinachau, bydd yn anodd iawn eu trosglwyddo i gyd trwy newidynnau amgylchedd.

Yn ogystal, yn yr achos hwn, ni fyddwn yn gallu dweud wrthych am offeryn mor wych â git-crypt.

git-crypt Mae hefyd yn gyfleus gan ei fod yn caniatáu ichi achub holl hanes cyfrinachau, yn ogystal â chymharu, uno a datrys gwrthdaro yn yr un modd ag yr oeddem yn arfer ei wneud yn achos Git.

Y peth cyntaf ar ôl ei osod git-crypt mae angen i ni gynhyrchu allweddi ar gyfer ein cadwrfa:

git crypt init

Os oes gennych allwedd PGP, yna gallwch chi ychwanegu eich hun ar unwaith fel cydweithredwr ar gyfer y prosiect hwn:

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

Fel hyn gallwch chi bob amser ddadgryptio'r ystorfa hon gan ddefnyddio'ch allwedd breifat.

Os nad oes gennych allwedd PGP ac nad oes disgwyl i chi wneud hynny, yna gallwch fynd y ffordd arall ac allforio allwedd y prosiect:

git crypt export-key /path/to/keyfile

Felly, unrhyw un sy'n meddu ar allforio ffeil bysell yn gallu dadgryptio eich ystorfa.

Mae'n bryd sefydlu ein cyfrinach gyntaf.
Gadewch i mi eich atgoffa ein bod yn dal yn y cyfeiriadur defnyddio/gitlab-rhedwr/lle mae gennym gyfeiriadur cyfrinachau/, gadewch i ni amgryptio'r holl ffeiliau ynddo, ar gyfer hyn byddwn yn creu ffeil cyfrinachau/.gitattributes gyda chynnwys fel hyn:

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

Fel y gwelir o'r cynnwys, pob ffeil gan mwgwd * bydd yn rhedeg drwodd git-crypt, ac eithrio y .gitabriodau

Gallwn wirio hyn trwy redeg:

git crypt status -e

Yn yr allbwn, rydyn ni'n cael rhestr o'r holl ffeiliau yn y storfa y mae amgryptio wedi'i alluogi ar ei chyfer

Dyna ni, nawr gallwn ymrwymo ein newidiadau yn ddiogel:

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

Er mwyn rhwystro'r ystorfa, mae'n ddigon i weithredu:

git crypt lock

ac ar unwaith bydd pob ffeil amgryptio yn troi yn rhywbeth deuaidd, bydd yn amhosibl eu darllen.
I ddadgryptio'r ystorfa, rhedwch:

git crypt unlock

8. Creu delwedd blwch offer

Mae delwedd blwch offer yn ddelwedd gyda'r holl offer y byddwn yn eu defnyddio i ddefnyddio ein prosiect. Bydd yn cael ei ddefnyddio gan y rhedwr gitlab i gyflawni tasgau defnyddio nodweddiadol.

Mae popeth yn syml yma, rydyn ni'n creu un newydd dockerfiles/toolbox/Dockerfile gyda chynnwys fel hyn:

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

Fel y gallwch weld, yn y ddelwedd hon rydym yn gosod yr holl gyfleustodau a ddefnyddiwyd gennym i ddefnyddio ein rhaglen. Nid oes angen i ni yma oni bai ciwctl, ond efallai y byddwch am chwarae o gwmpas ag ef wrth sefydlu'r biblinell.

Hefyd, er mwyn gallu cyfathrebu â Kubernetes a'i ddefnyddio, mae angen i ni sefydlu rôl ar gyfer y codennau a gynhyrchir gan gitlab-runner.

I wneud hyn, ewch i'r cyfeiriadur gyda gitlab-runner'om:

cd deploy/gitlab-runner

ac ychwanegu cydran newydd cydrannau/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,
      },
    ],
  },
]

Rydym hefyd yn disgrifio'r paramedrau newydd yn amgylcheddau/base.libsonnet, sydd bellach yn edrych fel hyn:

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',
    },
  },
}

Talu sylw $.components.rbac.enw yn cyfeirio at enw ar gyfer cydran rbac

Gadewch i ni wirio beth sydd wedi newid:

qbec diff default

a chymhwyso ein newidiadau i Kubernetes:

qbec apply default

Hefyd, peidiwch ag anghofio ymrwymo ein newidiadau i 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. Ein piblinell gyntaf a chydosod delweddau trwy dagiau

Wrth wraidd y prosiect y byddwn yn ei greu .gitlab-ci.yml gyda chynnwys fel hyn:

.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

Sylwch ein bod yn defnyddio GIT_SUBMODULE_STRATEGY : normal ar gyfer y swyddi hynny lle mae angen cychwyn is-fodiwlau yn benodol cyn eu gweithredu.

Peidiwch ag anghofio ymrwymo ein newidiadau:

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

Rwy'n credu y gallwch chi ei alw'n fersiwn yn ddiogel v0.0.1 ac ychwanegu tag:

git tag v0.0.1

Byddwn yn hongian tagiau pryd bynnag y bydd angen i ni ryddhau fersiwn newydd. Bydd tagiau mewn delweddau Docker yn cael eu mapio i dagiau Git. Bydd pob gwthio gyda thag newydd yn cychwyn lluniad delwedd gyda'r tag hwnnw.

Gadewch i ni ei wneud gwthio git --tags, ac edrychwch ar ein piblinell gyntaf:

Ciplun o'r biblinell gyntaf

Mae'n werth nodi bod adeiladau sy'n seiliedig ar dagiau yn dda ar gyfer adeiladu delweddau docwyr, ond nid ar gyfer defnyddio cais i Kubernetes. Gan y gellir hefyd neilltuo tagiau newydd i hen ymrwymiadau, yn yr achos hwn, bydd cychwyn y biblinell ar eu cyfer yn arwain at ddefnyddio'r hen fersiwn.

I ddatrys y broblem hon, mae adeiladu delweddau docwyr fel arfer yn gysylltiedig â thagiau, a lleoli'r cymhwysiad i'r gangen meistr, lle mae'r fersiynau o'r delweddau a gasglwyd wedi'u codio â chod caled. Yn yr achos hwn, gallwch gychwyn dychwelyd gyda dychweliad syml meistr-canghennau.

10. Defnyddio awtomeiddio

Er mwyn i Gitlab-redwr ddadgryptio ein cyfrinachau, mae angen i ni allforio allwedd y storfa a'i ychwanegu at ein newidynnau amgylchedd CI:

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

byddwn yn arbed y llinyn canlyniadol yn Gitlab, ar gyfer hyn byddwn yn mynd i osodiadau ein prosiect:
Gosodiadau —> CI / CD —> Newidynnau

A chreu newidyn newydd:

math
allweddol
Gwerth
Wedi'i warchod
Mwgwd
Cwmpas

File
GITCRYPT_KEY
<your string>
true (ar adeg hyfforddi, gallwch chi false)
true
All environments

Ciplun o'r newidyn ychwanegol

Nawr, gadewch i ni ddiweddaru ein .gitlab-ci.yml ychwanegu ato:

.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

Yma rydym wedi galluogi rhai opsiynau newydd ar gyfer qbec:

• --gwraidd rhai/app - yn caniatáu ichi ddiffinio cyfeiriadur cymhwysiad penodol
• --rym:k8s-cyd-destun __cynhwysiant__ - mae hwn yn newidyn hud sy'n dweud y bydd y gosodiad yn digwydd yn yr un clwstwr lle mae gtilab-runner yn rhedeg. Mae hyn yn angenrheidiol, fel arall bydd qbec yn ceisio dod o hyd i weinydd Kubernetes addas yn eich kubeconfig
• -aros - gorfodi qbec i aros nes bod yr adnoddau y mae'n eu creu yn mynd i'r cyflwr Parod a dim ond wedyn yn cwblhau gyda chod ymadael llwyddiannus.
• -oes - dim ond yn analluogi'r gragen ryngweithiol Wyt ti'n siwr? yn ystod lleoli.

Peidiwch ag anghofio ymrwymo ein newidiadau:

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

Ac ar ôl gwthio git byddwn yn gweld sut y defnyddiwyd ein ceisiadau:

Ciplun o'r ail biblinell

11. Arteffactau a chynulliad wrth wthio i feistr

Fel arfer, mae'r camau uchod yn ddigon i adeiladu a darparu bron unrhyw ficrowasanaeth, ond nid ydym am ychwanegu tag bob tro y bydd angen i ni ddiweddaru'r wefan. Felly, byddwn yn mynd mewn ffordd fwy deinamig ac yn sefydlu lleoliad crynhoad yn y brif gangen.

Mae'r syniad yn syml: yn awr y ddelwedd ein wefan yn cael ei ailadeiladu bob tro y byddwch yn gwthio i meistr, ac yna ei ddefnyddio'n awtomatig i Kubernetes.

Gadewch i ni ddiweddaru'r ddwy swydd hyn yn ein .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"

Sylwch ein bod wedi ychwanegu cangen meistr к refs am swydd adeiladu_gwefan a defnyddiwn yn awr $CI_COMMIT_REF_NAME yn hytrach na $CI_COMMIT_TAG, hynny yw, rydym yn cael gwared ar y tagiau yn Git ac yn awr byddwn yn gwthio'r ddelwedd gydag enw'r gangen ymrwymo a gychwynnodd eich piblinell. Mae'n werth nodi y bydd hyn hefyd yn gweithio gyda thagiau, a fydd yn caniatáu inni arbed cipluniau o'r wefan gyda fersiwn benodol yn y gofrestr docwyr.

Pan all enw'r tag docwr ar gyfer y fersiwn newydd o'r wefan fod heb ei newid, mae'n rhaid i ni ddisgrifio'r newidiadau ar gyfer Kubernetes o hyd, fel arall ni fydd yn adleoli'r cais o'r ddelwedd newydd, gan na fydd yn sylwi ar unrhyw newidiadau yn y maniffest lleoli.

Opsiwn --vm:ext-str crynhoad="$DIGEST" ar gyfer qbec - yn caniatáu ichi drosglwyddo newidyn allanol i jsonnet. Rydym am i'n cais gael ei adleoli yn y clwstwr gyda phob datganiad. Ni allwn ddefnyddio enw'r tag bellach, na ellir ei newid bellach, gan fod angen i ni rwymo i fersiwn benodol o'r ddelwedd a sbarduno'r defnydd pan fydd yn newid.

Yma, bydd gallu Kaniko i gadw crynhoad y ddelwedd i ffeil yn ein helpu (opsiwn --digest-ffeil)
Yna byddwn yn trosglwyddo'r ffeil hon ac yn ei darllen ar adeg ei defnyddio.

Gadewch i ni ddiweddaru'r paramedrau ar gyfer ein deploy/website/environments/base.libsonnet a fydd nawr yn edrych fel hyn:

{
  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',
    },
  },
}

Wedi'i wneud, nawr unrhyw ymrwymo i mewn meistr yn cychwyn adeiladu delwedd y docwr ar gyfer wefan, ac yna ei ddefnyddio i Kubernetes.

Peidiwch ag anghofio ymrwymo ein newidiadau:

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

Gwiriwch ef ar ôl gwthio git dylem weld rhywbeth fel hyn:

Ciplun piblinell ar gyfer meistr

Mewn egwyddor, nid oes angen i ni ail-leoli rhedwr gitlab gyda phob gwthio, oni bai, wrth gwrs, nad oes dim wedi newid yn ei ffurfweddiad, gadewch i ni drwsio hyn yn .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/**/*

newidiadau yn cadw golwg ar newidiadau yn defnyddio/gitlab-rhedwr/ a bydd yn sbarduno ein swydd dim ond os oes rhai

Peidiwch ag anghofio ymrwymo ein newidiadau:

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

gwthio git, mae hynny'n well:

Sgrinlun o'r biblinell wedi'i diweddaru

12. amgylcheddau deinamig

Mae'n bryd arallgyfeirio ein piblinellau gydag amgylcheddau deinamig.

Yn gyntaf, gadewch i ni ddiweddaru'r swydd adeiladu_gwefan yn ein .gitlab-ci.yml, tynnu'r bloc ohono yn unig, a fydd yn gorfodi Gitlab i'w sbarduno ar unrhyw ymrwymiad i unrhyw gangen:

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/

Yna diweddarwch y swydd gwefan_defnyddio, ychwanegu bloc yno amgylchedd:

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"

Bydd hyn yn caniatáu i Gitlab gysylltu'r swydd â hi prod amgylchedd ac arddangos y cyswllt cywir iddo.

Nawr, gadewch i ni ychwanegu dwy swydd arall:

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

Byddant yn cael eu sbarduno gan wthio i unrhyw ganghennau ac eithrio meistr a byddant yn defnyddio fersiwn rhagolwg o'r wefan.

Rydym yn gweld opsiwn newydd ar gyfer qbec: --app-tag - mae'n caniatáu ichi dagio fersiynau wedi'u defnyddio o'r rhaglen a gweithio o fewn y tag hwn yn unig; wrth greu a dinistrio adnoddau yn Kubernetes, dim ond arnynt y bydd qbec yn gweithredu.
Felly, ni allwn greu amgylchedd ar wahân ar gyfer pob adolygiad, ond yn syml ailddefnyddio'r un un.

Yma rydym hefyd yn defnyddio qbec cais adolygiad, yn lle qbec cymhwyso rhagosodedig - dyma'r union foment pan fyddwn yn ceisio disgrifio'r gwahaniaethau ar gyfer ein hamgylcheddau (adolygiad a rhagosodiad):

Gadewch i ni ychwanegu adolygu amgylchedd yn defnyddio/gwefan/qbec.yaml

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

Yna rydym yn ei ddatgan i mewn defnyddio/gwefan/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

Ac ysgrifennu paramedrau arfer ar ei gyfer yn defnyddio/gwefan/amgylcheddau/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',
    },
  },
}

Gadewch i ni hefyd edrych yn agosach ar y swydd stop_adolygiad, bydd yn cael ei sbarduno pan fydd y gangen yn cael ei thynnu ac fel nad yw gitlab yn ceisio til yn cael ei ddefnyddio GIT_STRATEGY : dim, yn ddiweddarach rydym yn clonio meistr-cangen a dileu adolygiad drwyddo.
Ychydig yn ddryslyd, ond nid wyf eto wedi dod o hyd i ffordd fwy prydferth.
Opsiwn arall fyddai defnyddio pob adolygiad i ofod enw gwesty, y gellir ei ddymchwel yn ei gyfanrwydd bob amser.

Peidiwch ag anghofio ymrwymo ein newidiadau:

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

gwthio git, git siec -b prawf, prawf tarddiad gwthio git, gwirio:

Sgrinlun o amgylcheddau a grëwyd yn Gitlab

Mae popeth yn gweithio? - gwych, dileu ein cangen prawf: meistr til git, tarddiad gwthio git: prawf, rydym yn gwirio bod y swyddi ar gyfer dileu'r amgylchedd yn gweithio heb wallau.

Yma rwyf am egluro ar unwaith y gall unrhyw ddatblygwr yn y prosiect greu canghennau, gall hefyd newid .gitlab-ci.yml ffeil a chyrchu newidynnau cyfrinachol.
Felly, argymhellir yn gryf caniatáu eu defnyddio ar gyfer canghennau gwarchodedig yn unig, er enghraifft yn meistr, neu greu set ar wahân o newidynnau ar gyfer pob amgylchedd.

13 Adolygu Apiau

Adolygu Apps mae hon yn nodwedd gitlab sy'n eich galluogi i ychwanegu botwm ar gyfer pob ffeil yn yr ystorfa i'w gweld yn gyflym yn yr amgylchedd a ddefnyddir.

Er mwyn i'r botymau hyn ymddangos, mae angen i chi greu ffeil .gitlab/route-map.yml a disgrifiwch ynddo holl drawsnewidiadau'r llwybrau, yn ein hachos ni bydd yn syml iawn:

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

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

Peidiwch ag anghofio ymrwymo ein newidiadau:

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

gwthio git, a gwirio:

Ciplun o'r botwm Adolygu App

Mae'r swydd wedi'i chwblhau!

Ffynonellau prosiect:

• ar gitlab: https://gitlab.com/kvaps/docs.example.org
• ar GitHub: https://github.com/kvaps/docs.example.org

Diolch am eich sylw, gobeithio eich bod wedi ei hoffi

Ffynhonnell: hab.com