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;
Dank' al ĉi tio, Skaffold povas esti nomita unika kadro por konstrui CI/CD. Jen ekzempla laborfluo kiam vi uzas ĝin (el la projektdokumentaro):
Kiel aspektas la laboro de Skaffold ĝenerale?
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.
La kunvenita bildo estas kontrolita per ujo-strukturo-testo, etikedita kaj sendita al la Docker-Registro.
Post ĉi tio, la bildo estas deplojita - deplojita en la Kubernetes-areo.
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.
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.
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:
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.
Ĉ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:
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.