Skaffold áttekintése Kubernetes fejlesztéshez

Másfél évvel ezelőtt, 2018. március 5-én a Google bemutatta első alfa verzióját CI/CD open source projektjének, amelynek neve Skaffold, és célja az volt, hogy „egyszerű és reprodukálható fejlesztést biztosítson Kubernetes alatt”, hogy a fejlesztők a fejlesztésre koncentrálhassanak, ne pedig az adminisztrációra. Miben lehet érdekes a Skaffold? Kiderült, hogy van több ásza a tarsolyában, ami erős eszközzé teheti a fejlesztők, sőt, az üzemeltetők számára is. Ismerkedjünk meg a projekttel és annak lehetőségeivel.

NB: Egyébként már röviden írtunk a Skaffoldról az általános fejlesztői eszközökről szóló áttekintőnkben, amelyek élete a Kuberneteshez kapcsolódik.

Elmélet. Célok és lehetőségek

Ha általános értelemben beszélünk, a Skaffold a CI/CD ciklus automatizálásával foglalkozik (a build, push, deploy szakaszokban), azzal, hogy azonnali visszajelzést biztosít a fejlesztőknek, azaz lehetőséget ad a kód legutóbbi változtatásainak gyors eredményének megtekintésére - mint egy frissített alkalmazást, amely a Kubernetes klaszterében fut. Emellett különféle környezetekben (dev, stage, production...) is tud működni, amire a Skaffold segít a megfelelő kiadási folyamatok leírásában.

A Skaffold forráskódja Go nyelven íródott, terjesztésre kerül Apache License 2.0 szabad licenc alapján (GitHub).

Nézzük meg a fő funkciókat és jellemzőket. Az első a következő:

• A Skaffold eszköztárat kínál CI/CD pipline-ok létrehozásához.
• Lehetővé teszi, hogy a háttérben nyomon kövesse a forráskód változásait és automatikusan végrehajtsa a kód építési folyamatát konténer imázsokká, ezeket az imázsokat publikálja a Docker Registry-be és telepíti a Kubernetes klaszterbe.
• Szinkronizálja a fájlokat a tárolóban lévő munkakönyvtárral.
• Automatikusan tesztel a container-structure-test segítségével.
• Portokat irányít át.
• Olvassa a konténerben futó alkalmazás naplóit.
• Segít a Java, Node.js, Python, Go nyelven írt alkalmazások hibakeresésében.

Most pedig a jellemzőkről:

• A Skaffoldnak nincsenek komponensei a klaszter oldalán. Tehát nem szükséges a Kubernetes beállítása ehhez az eszközhöz.
• Különböző munkafolyamatok az alkalmazásához. Szeretné bevezetni a kódot a helyi Minikube-ba, miközben fejleszt, majd pedig a stádiumba vagy a termelésbe? Erre vannak megoldások. profilok és felhasználói konfigurációk, környezeti változók és kapcsolók, amelyek lehetővé teszik különböző pipeline-ok leírását egy alkalmazáshoz.
• CLI. Csak parancssori eszköz és YAML konfigurációk. Az interneten találhatók említések a kísérleti GUI-ról,de jelenleg inkább azt jelenti, hogy valakinek szüksége van rá, de nem igazán.
• Modularitás. A Skaffold nem önálló kombájn, hanem arra törekszik, hogy különálló modulokat vagy már meglévő megoldásokat használjon konkrét feladatokhoz.

Az utolsó példája:

• A build fázisban használható:
  • docker build helyben, klaszterben a kaniko segítségével vagy a Google Cloud Build-en;
  • Bazel helyben;
  • Jib Maven és Jib Gradle helyben vagy a Google Cloud Build-en;
  • egyedi build-szkriptek, amelyeket helyben futtatnak. Ha más (rugalmasabb/szokásos/…) build megoldást kell futtatnia, azt a szkripten belül leírja, hogy a Skaffold éppen azt indítsa () engedélyezni kell a). Ez lehetővé teszi bármilyen build eszköz használatát, amelyet szkripten keresztül hívhatnak meg;
• A tesztelési fázisban támogatott már említett container-structure-test;
• A telepítéshez az alábbiak állnak rendelkezésre:
  • Kubectl;
  • Helm;
  • kustomize.

Ennek köszönhetően a Skaffold egyfajta CI/CD keretrendszernek tekinthető,. Íme egy példa a munkafolyamatról a használatakor (a projekt dokumentációjából):

Hogyan néz ki általánosságban a Skaffold működése?

1. Az eszköz figyeli a forráskód könyvtárban bekövetkező változásokat. Ha a fájlokban módosításokat végeznek, azokat szinkronizálják az alkalmazás pod-jával a Kubernetes klaszterben. Ha lehetséges – újraépítés nélkül. Ellenkező esetben új képet építenek.
2. Az elkészült képet container-structure-test segítségével ellenőrzik, címkézik és feltöltik a Docker Registry-be.
3. Ezután a képet telepítik – kiterjesztik a Kubernetes klaszterben.
4. Ha a futtatást a skaffold devparanccsal indították, akkor elkezdjük megkapni az alkalmazás naplóit, és a Skaffold várja a változásokat, hogy az összes műveletet újra elvégezze.

A Skaffold munkafolyamatának főbb lépései

Gyakorlati rész. Próbáljuk ki a Skaffoldot.

A Skaffold használatának bemutatásához egy példát hozok a projekt GitHub-tárházából,. Egyébként, ott is számos más példát is találhat, amelyek különböző sajátosságokat figyelembe vesznek. Az összes műveletet helyben fogom végrehajtani a Minikube-ban. A telepítés egyszerű és néhány percet vesz igénybe, és a kezdéshez a kubectl-re lesz szükség.

Telepítsük a Skaffoldot:

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

Klónozzuk a szükséges példákkal rendelkező Skaffold tárolót:

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

A példát választottam, amely két pod-ból áll, mindkettő egy-egy kis Go alkalmazást tartalmaz. Az egyik alkalmazás a frontend (leeroy-web), amely átirányítja a kéréseket a másik alkalmazásra, a backendre (leeroy-app). Nézzük meg, hogyan néz ki:

~/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 könyvtár, 8 fájl

leeroy-app és leeroy-web tartalmaz egy Go kódot és egyszerű Dockerfile-okat ezen kód lokális fordításához:

~/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 .

A programok kódját nem mutatom be — elegendő tudni, hogy leeroy-web kéri a kéréseket, és továbbítja őket a leeroy-app. Ezért a fájlokban Deployment.yaml csak a app számára van Service (belső útvonalkezeléshez). A pod portját szolgáltatás szeretne hozzáférni egy mi magunknak továbbítjuk a gyors hozzáférés érdekében az alkalmazáshoz.

Hogyan néz ki 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

Itt minden említett szakasz le van írva. Ezen a config-on kívül van egy globális beállítások fájl is — ~/ski/.skaffold/config. Ezt manuálisan vagy CLI-n keresztül is szerkeszthetjük — például így:

skaffold config set --global local-cluster true

Ez a parancs beállítja a globális változót local-cluster az értékre igaz, így a Skaffold nem fogja megpróbálni a képeket távoli tárolóba pusholni. Ha lokálisan fejlesztesz, ezt a parancsot használhatod, hogy a képeket szintén helyben tárold.

Térjünk vissza a skaffold.yaml:

• Szakaszhoz, ahol megadjuk, hogy a képet helyben kell összegyűjteni és tárolni. Miután először elindítottuk az építést, a következőket látjuk: build Ahogy látható, a Skaffold automatikusan megcímkézte a képeket. Egyébként több címkézési politika is támogatott.

  // т.к. 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

  A konfigurációban pedig a következő van megadva:

• context: ./leeroy-app/ , azaz meg van határozva a kontextus, amelyben a képet összegyűjtik., tehát van egy kontextus, amelyben a képet létrehozzák.
• A telepítési szakaszban meghatározásra kerül, hogy a kubectl-t és a szükséges manifesztusokhoz tartozó maszkot fogjuk használni.
• PortForward: hasonlóan ahhoz, ahogyan általában portokat irányítunk át kubectl port-forward, utasításokat adunk a Skaffoldnak ezen parancs meghívására. Ebben az esetben a helyi 9000-es port átirányításra kerül a 8080-ra az alábbi névvel rendelkező Deploymentben: leeroy-web.

Itt az ideje elindítani skaffold dev: a parancs létrehoz egy folyamatos "visszajelzési ciklust", azaz nemcsak összegyűjti az összeset és telepíti a klaszterbe, hanem tájékoztat a podok aktuális állapotáról, figyeli a változásokat és frissíti a podok állapotát.

Íme az indítás eredménye skaffold dev --port-forward újraépítéskor:

Először is, látható, hogy a cache használatban van. Ezt követően - az alkalmazás építése, telepítése, portok átirányítása történik. Mivel meg lett adva a --port-forward, a Skaffold átirányította a portot, ahogy azt kérték tőle, de magától szolgáltatás szeretne hozzáférni egya legközelebbi szabad portot választotta. Ezt követően kapjuk meg az első naplókat az alkalmazásoktól. app Ellenőrizzük a működést?

~\/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!!!

Módosítjuk a fájlt

leeroy-app\/app.go — eltelt néhány másodperc… és: ~\/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!!!

A Skaffold pedig a konzolra ugyanazt a kimenetet adta, mint korábban, egyetlen kivétellel: csak a

, és nem mind egyszerre. leeroy-appTöbb gyakorlat

Érdemes megemlíteni, hogy új projekt létrehozásakor a Skaffold konfigurációit a következő parancs segítségével tudjuk "bootstrap"-olni,

ami nagyon hasznos. Ráadásul több konfigurációt is írhatunk: a szokásos konfiguráción dolgozhat, majd a "stage" parancs kiadásával átválthat egy másik konfigurációra. init(ugyanaz a folyamat, mint a a "run" opcióval indul el. , csak nem figyeli a változásokat), egy másik konfiguráció használatával. devA katacodán található

még egyszerűbb példával. Ugyanakkor egy kész példahelyet kínál Kubernetes, alkalmazás és Skaffold használatával. Remek választás, ha önállóan szeretné kipróbálni az alapokat. a kézikönyvet a példa még egyszerűbb. De ott már egy kész homokozót kínálnak Kubernetes-szel, egy alkalmazással és Skaffold-dal. Remek lehetőség, ha önállóan szeretné kipróbálni az alapokat.

Az egyik lehetséges alkalmazási módja a Skaffold-nak a távoli klaszteren való fejlesztés. Nem mindenki számára kényelmes a Minikube saját hardveren való futtatása, majd az alkalmazás telepítése és annak megfelelő működésének várása... Ilyen esetben a Skaffold remekül megoldja a felmerült feladatot, amit például a Reddit mérnökei is megerősíthetnek. írták a blogunkban olvashat.

És a cikkünkben A Weaveworks-től található egy példa a gyártási pipeline létrehozására.

Zárás

A Skaffold egy praktikus eszköz a pipeline-ok felépítésére, amelyeket az alkalmazások Kubernetes-be való telepítése érdekében hoztak létre, elsősorban a fejlesztés igényeit figyelembe véve. Egyszerűen létrehozhatók "rövid" pipeline-ok, amelyek figyelembe veszik a fejlesztő alapvető igényeit, de szükség esetén nagyobb folyamatok is szervezhetők. A Skaffold CI/CD folyamatokban való alkalmazásának egyik szemléletes példájaként említést nyer ilyen a tesztprojektről 10 mikroszolgáltatással, amelyek kihasználják a Kubernetes, gRPC, Istio és OpenCensus Tracing funkcióit.

A Skaffold már majdnem 8000+ csillagot kapott a GitHub-on, a Google fejleszti, és része a GoogleContainerTools-nak. Alapvetően jelenleg minden okunk megvan arra, hogy azt gondoljuk, a projekt hosszú és boldog jövő előtt áll.

P.S.

Olvasson további információkat a blogunkban:

• «Kubernetes 1.14: a legfontosabb újítások áttekintése»;
• «werf — az eszközünk CI/CD-hez Kubernetes-ben (áttekintés és a beszámoló videója)»;
• «Garden v0.10.0: A laptopodnak nincs szüksége Kubernetesre»;
• «Kubernetes tippek és trükkök: helyi fejlesztés és Telepresence».

Forrás: habr.com