Revizio de Skaffold por evoluo de Kubernetes

Revizio de Skaffold por evoluo de Kubernetes

Antaŭ jaro kaj duono, la 5-an de marto 2018, Guglo publikigis la unuan alfa-version de sia Malfermfonta projekto por CI/KD nomita Skafodo, kies celo estis krei "simplan kaj ripeteblan Kubernetes-evoluon" tiel ke programistoj povus temigi evoluon prefere ol administrado. Kio povus esti interesa pri Skaffold? Kiel ĝi rezultas, ĝi havas kelkajn lertaĵojn en la maniko, kiuj povas igi ĝin potenca ilo por la programisto, kaj eble eĉ la operacia inĝeniero. Ni konatiĝu kun la projekto kaj ĝiaj kapabloj.

NB: Cetere, pri Skaffold ni jam mallonge parolis en nia generalo revizio de programiloj, kies vivoj estas ligitaj kun Kubernetes.

Teorio. Celo kaj kapabloj

Do, ĝenerale parolante, Skaffold solvas la problemon de aŭtomatigo de la CI/KD-ciklo (ĉe la konstruo, puŝo, deploji stadioj), proponante al la programisto promptan retrosciigon, t.e. la kapablo rapide ricevi la rezulton de postaj kodŝanĝoj - en la formo de ĝisdatigita aplikaĵo funkcianta en la Kubernetes-areo. Kaj ĝi povas funkcii en malsamaj cirkvitoj (dev, scenejo, produktado...), por kiuj Skaffold helpas priskribi la respondajn duktoj por lanĉo.

La fontkodo de Skaffold estas skribita en Go, distribuita de sub la senpaga Apache License 2.0 (GitHub).

Ni rigardu la ĉefajn funkciojn kaj funkciojn. La unuaj inkluzivas la jenajn:

  • Skaffold ofertas ilojn por krei CI/KD-duktojn.
  • Permesas al vi kontroli ŝanĝojn en la fontkodo en la fono kaj ruli aŭtomatan procezon kunmeti kodon en ujajn bildojn, publikigante ĉi tiujn bildojn en la Docker-Registro kaj disfaldi ilin al la Kubernetes-areo.
  • Sinkronigas dosierojn en la deponejo kun la labordosierujo en la ujo.
  • Aŭtomate provas uzante ujo-strukturo-testo.
  • Antaŭen havenoj.
  • Legas la protokolojn de aplikaĵo kuranta en ujo.
  • Helpas en sencimigaj aplikaĵoj skribitaj en Java, Node.js, Python, Go.

Nun pri la funkcioj:

  • Skaffold mem havas neniujn aret-flankajn komponentojn. Tio estas, ne necesas plu agordi Kubernetes por uzi ĉi tiun ilon.
  • Malsamaj duktoj por via apliko. Ĉu vi bezonas ruliĝi la kodon al loka Minikube dum vi disvolvas, kaj poste enscenigi aŭ produktadon? Tiucele ekzistas profiloj kaj uzantkonfiguracioj, mediovariabloj kaj flagoj, kiuj permesas vin priskribi malsamajn duktojn por unu aplikaĵo.
  • CLI. Nur konzola utileco kaj agordoj en YAML. En la Interreto vi povas trovi referencojn al provoj krei eksperimenta GUI, tamen, nuntempe ĉi tio plej verŝajne signifas nur, ke iu bezonas lin, sed ne vere.
  • Modulareco. Skaffold ne estas memstara rikoltmaŝino, sed strebas uzi individuajn modulojn aŭ ekzistantajn solvojn por specifaj taskoj.

Ilustraĵo de ĉi-lasta:

  • En la munta stadio vi povas uzi:
    • docker konstruo loke, en areto uzante kaniko aŭ en Google Cloud Build;
    • Bazel loke;
    • Jib Maven kaj Jib Gradle loke aŭ en Google Cloud Build;
    • kutimaj konstruaj skriptoj funkcias loke. Se vi bezonas ruli alian (pli flekseblan/konatan/...) konstruan solvon, ĝi estas priskribita en la skripto por ke Skaffold lanĉu ĝin (ekzemplo de dokumentado). Ĉi tio ebligas al vi uzi ajnan kolektanton, kiu povas esti vokita per skripto;
  • En la prova stadio, la jam menciita ujo-strukturo-testo;
  • Por deplojo la jenaj estas provizitaj:
    • Kubectl;
    • Helmo;
    • personecigi.

Dank' al ĉi tio, Skaffold povas esti nomita unika kadro por konstrui CI/CD. Jen ekzempla laborfluo kiam vi uzas ĝin (el la projektdokumentaro):

Revizio de Skaffold por evoluo de Kubernetes

Kiel aspektas la laboro de Skaffold ĝenerale?

  1. La ilo monitoras ŝanĝojn en la fontkoda dosierujo. Se modifoj estas faritaj al la dosieroj, ili estas sinkronigitaj kun la aplikaĵo en la Kubernetes-grupo. Se eble, sen remunti la bildon. Alie, nova bildo estas kunvenita.
  2. La kunvenita bildo estas kontrolita per ujo-strukturo-testo, etikedita kaj sendita al la Docker-Registro.
  3. Post ĉi tio, la bildo estas deplojita - deplojita en la Kubernetes-areo.
  4. Se la lanĉo estis pravigita per la komando skaffold dev, tiam ni komencas ricevi protokolojn de la aplikaĵo, kaj Skaffold atendas ŝanĝojn por ripeti ĉiujn agojn denove.

Revizio de Skaffold por evoluo de Kubernetes
Ilustraĵo de la ĉefaj stadioj de Skaffold-operacio

Praktiko. Provante Skaffold

Por pruvi la uzon de Skaffold, mi prenos ekzemplon el Projekta deponejo de GitHub... Parenteze, tie Vi povas trovi multajn aliajn ekzemplojn, kiuj konsideras diversajn specifaĵojn. Mi faros ĉiujn agojn loke en Minikube. Instalado estas simpla kaj daŭras kelkajn minutojn, kaj vi bezonos kubectl por komenci.

Instalu Skaffold:

curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64
chmod +x skaffold
sudo mv skaffold /usr/local/bin
skaffold version
v0.37.1

Ni klonu la deponejon de Skaffold kun la necesaj ekzemploj:

git clone https://github.com/GoogleContainerTools/skaffold
cd skaffold/examples/microservices

Mi elektis ekzemplon kun du balgoj, ĉiu enhavanta unu malgrandan Go-aplikaĵon. Unu aplikaĵo estas la fasado (leeroy-web), kiu redirektas la peton al la dua aplikaĵo - la backend (leeroy-app). Ni vidu kiel ĝi aspektas:

~/skaffold/examples/microservices # tree
.
├── leeroy-app
│   ├── app.go
│   ├── Dockerfile
│   └── kubernetes
│       └── deployment.yaml
├── leeroy-web
│   ├── Dockerfile
│   ├── kubernetes
│   │   └── deployment.yaml
│   └── web.go
├── README.adoc
└── skaffold.yaml
 
4 directories, 8 files

leeroy-app kaj leeroy-web enhavas Go-kodon kaj simplajn Dockerfiles por konstrui ĉi tiun kodon loke:

~/skaffold/examples/microservices # cat leeroy-app/Dockerfile
FROM golang:1.12.9-alpine3.10 as builder
COPY app.go .
RUN go build -o /app .
 
FROM alpine:3.10
CMD ["./app"]
COPY --from=builder /app .

Mi ne donos la aplikaĵkodon - sufiĉas scii tion leeroy-web akceptas petojn kaj prokuras ilin al leeroy-app. Tial en la dosieroj Deployment.yaml ekzistas Servo nur por app (por interna vojigo). Pod haveno web ni plusendos ĝin al ni mem por rapida aliro al la aplikaĵo.

Kiel ĝi aspektas skaffold.yaml:

~/skaffold/examples/microservices # cat skaffold.yaml
apiVersion: skaffold/v1beta13
kind: Config
build:
  artifacts:
    - image: leeroy-web
      context: ./leeroy-web/
    - image: leeroy-app
      context: ./leeroy-app/
deploy:
  kubectl:
    manifests:
      - ./leeroy-web/kubernetes/*
      - ./leeroy-app/kubernetes/*
portForward:
  - resourceType: deployment
    resourceName: leeroy-web
    port: 8080
    localPort: 9000

Ĉiuj supre menciitaj etapoj estas priskribitaj ĉi tie. Krom ĉi tiu agordo, ekzistas ankaŭ dosiero kun tutmondaj agordoj - ~/.skaffold/config. Ĝi povas esti redaktita permane aŭ per la CLI - ekzemple jene:

skaffold config set --global local-cluster true

Ĉi tiu komando starigos la tutmondan variablon local-cluster en signifon true, post kio Skaffold ne provos puŝi bildojn al la fora registro. Se vi disvolvas loke, vi povas uzi ĉi tiun komandon por konstrui bildojn loke.

Reen al skaffold.yaml:

  • Sur la scenejo build ni precizigas, ke vi devas kolekti kaj konservi la bildon loke. Post kiam la konstruo funkcias por la unua fojo, ni vidos la jenon:
    // т.к. Minikube создает кластер в отдельной виртуальной машине,
    // придется проникнуть внутрь, чтобы найти образы
    # minikube ssh
    $ docker images
    REPOSITORY                                TAG                                                                IMAGE ID            CREATED             SIZE 
    leeroy-app                                7d55a50803590b2ff62e47e6f240723451f3ef6f8c89aeb83b34e661aa287d2e   7d55a5080359        4 hours ago         13MB 
    leeroy-app                                v0.37.1-171-g0270a0c-dirty                                         7d55a5080359        4 hours ago         13MB
    leeroy-web                                5063bfb29d984db1ff70661f17d6efcc5537f2bbe6aa6907004ad1ab38879681   5063bfb29d98        5 hours ago         13.1MB
    leeroy-web                                v0.37.1-171-g0270a0c-dirty                                         5063bfb29d98        5 hours ago         13.1MB

    Kiel vi povas vidi, Skaffold etikedis la bildojn mem. Cetere, pluraj etikedpolitikoj estas subtenataj.

  • Plue en la agordo ĝi estas indikita context: ./leeroy-app/, t.e. la kunteksto en kiu la bildo estas kolektita estas precizigita.
  • En la deploja stadio, estas determinite, ke ni uzos kubectl kaj maskon por la necesaj manifestoj.
  • PortForward: simila al kiel ni kutime plusendas havenojn uzante kubectl port-forward, ni donas instrukciojn al Skaffold por voki ĉi tiun komandon. En ĉi tiu kazo, loka haveno 9000 estas plusendita al 8080 en Deployment kun la nomo leeroy-web.

Estas tempo por lanĉi skaffold dev: La teamo kreos daŭrantan "religbuklon", t.e. ĝi ne nur kolektos ĉion kaj deplojos ĝin al la areto, sed ankaŭ rakontos al vi pri la stato de la podoj nuntempe, monitoros ŝanĝojn kaj ĝisdatigos la staton de la podoj.

Jen la rezulto de la lanĉo skaffold dev --port-forward kiam oni remuntas:

Revizio de Skaffold por evoluo de Kubernetes

Unue, vi povas vidi, ke la kaŝmemoro estas uzata. Poste, la aplikaĵo estas kunvenita, deplojita, kaj havenoj estas plusenditaj. Ekde specifita --port-forward, Skaffold plusendis la havenon al web, kiel oni demandis lin, sed app li ĵetis laŭ sia bontrovo (elektis la plej proksiman liberan). Post ĉi tio, ni ricevas la unuajn protokolojn de la aplikaĵoj.

Ni kontrolu ĉu ĝi funkcias?

~/skaffold/examples/microservices # kubectl get po
NAME                          READY   STATUS    RESTARTS   AGE
leeroy-app-6998dfcc95-2nxvf   1/1     Running   0          103s
leeroy-web-69f7d47c9d-5ff77   1/1     Running   0          103s
~/skaffold/examples/microservices # curl localhost:9000
leeroooooy app!!!

Modifante la dosieron leeroy-app/app.go — pasas kelkaj sekundoj... kaj:

~/skaffold/examples/microservices # kubectl get po
NAME                          READY   STATUS    RESTARTS   AGE
leeroy-app-ffd79d986-l6nwp    1/1     Running   0          11s
leeroy-web-69f7d47c9d-5ff77   1/1     Running   0          4m59s
~/skaffold/examples/microservices # curl localhost:9000
leeroooooy Habr!!!

Samtempe, Skaffold mem montris la saman aĵon en la konzolo kiel antaŭe, kun la escepto de unu punkto: ĝi nur ruliĝis leeroy-app, kaj ne ĉiuj samtempe.

Pli da praktiko

Ankaŭ menciindas, ke kiam oni kreas novan projekton, agordoj por Skaffold povas esti startigitaj per la komando. init, kio estas tre oportuna. Krome, vi povas skribi plurajn agordojn: faru disvolviĝon sur la defaŭlta agordo, kaj poste ruliĝi al scenejo per la komando. run (sama procezo kiel dev, simple ne kontrolas ŝanĝojn), uzante malsaman agordon.

Sur katacoda estas gvidado Estas eĉ pli facile kun ekzemplo. Sed ĝi ofertas pretan sablokeston kun Kubernetes, aplikaĵo kaj Skaffold. Bonega opcio se vi interesiĝas provi mem la bazaĵojn.

Unu ebla uzkazo por Skaffold estas fari evoluon sur fora areto. Ne ĉiuj komfortas ruli Minikube per sia propra aparataro, poste ruli la aplikaĵon kaj atendi, ke ĝi funkcios adekvate... En ĉi tiu kazo, Skaffold perfekte solvas la problemon, kio povas esti konfirmita, ekzemple, de Reddit-inĝenieroj, kiel ni havas. jam diskutita skribis en nia blogo.

Kaj en ĉi tiu publikigado de Weaveworks vi povas trovi ekzemplon pri kreado de dukto por produktado.

konkludo

Skaffold estas oportuna ilo por konstrui duktoj, kiuj implikas lanĉi aplikaĵojn al Kubernetes kaj ĉefe koncentriĝas pri evoluaj bezonoj. Ĝi sufiĉe facilas krei "mallongan" dukton, kiu konsideras la bazajn bezonojn de la programisto, sed se vi volas, vi povas organizi pli grandajn procezojn. Kiel unu el la klaraj ekzemploj de uzado de Skaffold en CI/KD-procezoj estas donita tia prova projekto de 10 mikroservoj uzante la kapablojn de Kubernetes, gRPC, Istio kaj OpenCensus Tracing.

Skaffold jam havas preskaŭ 8000+ stelojn en GitHub, estas evoluigita de Google kaj estas parto de Google ContainerTools — ĝenerale, nuntempe ekzistas ĉiuj kialoj por kredi, ke la projekto disvolviĝos feliĉe por ĉiam.

PS

Legu ankaŭ en nia blogo:

fonto: www.habr.com

Aldoni komenton