Másfél éve, 5. március 2018-én a Google kiadta nyílt forráskódú projektjének első alfa-verzióját CI/CD-re. , amelynek célja az volt, hogy „egyszerű és megismételhető Kubernetes-fejlesztést” hozzon létre, hogy a fejlesztők az adminisztráció helyett a fejlesztésre összpontosíthassanak. Mi lehet érdekes a Skaffoldban? Mint kiderült, van néhány trükk, amelyek hatékony eszközzé tehetik a fejlesztők, sőt talán az üzemeltetési mérnökök számára is. Ismerkedjünk meg a projekttel és annak lehetőségeivel.
NB: A Skaffoldról egyébként röviden már beszéltünk általánosságunkban , akinek élete Kuberneteshez kötődik.
Elmélet. Cél és képességek
Tehát általánosságban elmondható, hogy a Skaffold megoldja a CI/CD ciklus automatizálásának problémáját (a build, push, deploy szakaszokban), azonnali visszajelzést adva a fejlesztőnek, pl. a későbbi kódmódosítások eredményének gyors fogadása - a Kubernetes-fürtben futó frissített alkalmazás formájában. Különböző áramkörökben is működhet (fejlesztő, színpad, gyártás...), amihez a Skaffold segít leírni a megfelelő csővezetékeket a kiépítéshez.
A Skaffold forráskódja Go-ban van írva, az ingyenes Apache License 2.0 (GitHub) alatt.
Nézzük meg a főbb funkciókat és jellemzőket. Az első a következőket tartalmazza:
- A Skaffold eszközöket kínál a CI/CD csővezetékek létrehozásához.
- Lehetővé teszi a forráskód változásainak figyelését a háttérben, és egy automatizált folyamat futtatását a kód konténerképekké való összeállítására, ezeknek a képeknek a Docker Registry-ben való közzétételére és a Kubernetes-fürtbe történő telepítésére.
- Szinkronizálja a tárolóban lévő fájlokat a tároló munkakönyvtárával.
- Automatikusan teszteli a konténerszerkezet-teszt segítségével.
- Továbbító portok.
- Beolvassa egy tárolóban futó alkalmazás naplóit.
- Segít a Java, Node.js, Python, Go nyelven írt alkalmazások hibakeresésében.
Most a funkciókról:
- Magának a Skaffoldnak nincsenek fürtoldali összetevői. Ez azt jelenti, hogy nincs szükség a Kubernetes további konfigurálására a segédprogram használatához.
- Különböző csővezetékek az Ön alkalmazásához. Ki kell terjesztenie a kódot a helyi Minikube-ra fejlesztés közben, majd színpadra vagy gyártásra? Erre a célra vannak és felhasználói konfigurációk, környezeti változók és jelzők, amelyek lehetővé teszik különböző folyamatok leírását egy alkalmazáshoz.
- CLI. Csak konzol segédprogram és konfigurációk a YAML-ben. Az interneten hivatkozásokat találhatunk alkotási kísérletekre , azonban jelenleg ez nagy valószínűséggel csak azt jelenti, hogy valakinek szüksége van rá, de nem igazán.
- Modularitás. A Skaffold nem egy önálló betakarítógép, hanem arra törekszik, hogy egyedi modulokat vagy meglévő megoldásokat használjon meghatározott feladatokhoz.
Utóbbi illusztrációja:
- Az összeszerelési szakaszban a következőket használhatja:
- docker build helyileg, fürtben a kaniko használatával vagy a Google Cloud Build segítségével;
- Bazel helyben;
- Jib Maven és Jib Gradle helyben vagy a Google Cloud Buildben;
- egyedi build szkriptek helyileg futnak. Ha egy másik (rugalmasabb/ismerősebb/...) build megoldást kell futtatnia, az a szkriptben le van írva, hogy a Skaffold elindítsa (). Ez lehetővé teszi bármilyen gyűjtő használatát, amely egy szkript segítségével hívható meg;
- A tesztelési szakaszban a már említett ;
- A telepítéshez a következők állnak rendelkezésre:
- Kubectl;
- Sisak;
- testreszab.
Ennek köszönhetően a Skaffold egyedülállónak mondható keretrendszer CI/CD építéséhez. Íme egy példa a munkafolyamat használatára (a projekt dokumentációjából):
Hogyan néz ki Skaffold munkája általánosságban?
- A segédprogram figyeli a forráskód-könyvtár változásait. Ha módosítja a fájlokat, a rendszer szinkronizálja azokat a Kubernetes-fürtben található alkalmazáscsomaggal. Lehetőleg a kép összeszerelése nélkül. Ellenkező esetben új kép kerül összeállításra.
- Az összeállított lemezképet a konténer-struktúra-teszt segítségével ellenőrzik, felcímkézik és elküldik a Docker Registry-nek.
- Ezt követően a rendszer telepíti a rendszerképet - a Kubernetes-fürtben.
- Ha az indítást a paranccsal inicializálták
skaffold dev, akkor elkezdjük fogadni a naplókat az alkalmazástól, és a Skaffold vár a változtatásokra, hogy ismételje meg az összes műveletet.
Illusztráció a Skaffold működésének főbb szakaszairól
Gyakorlat. Skaffold kipróbálása
A Skaffold használatának bemutatására egy példát veszek a következőből ... Mellesleg, Sok más példát is találhat, amelyek különféle sajátosságokat vesznek figyelembe. Minden műveletet helyben hajtok végre a Minikube-ban. A telepítés egyszerű és néhány percet vesz igénybe, és a kezdéshez szüksége lesz a kubectl-re.
Skaffold telepítése:
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.1Klónozzuk a Skaffold adattárát a szükséges példákkal:
git clone https://github.com/GoogleContainerTools/skaffold
cd skaffold/examples/microservicesEgy példát választottam két poddal, amelyek mindegyike egy kis Go alkalmazást tartalmaz. Az egyik alkalmazás a frontend (leeroy-web), amely átirányítja a kérést a második alkalmazáshoz - a háttérrendszerhez (leeroy-app). Lássuk, 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 directories, 8 filesA leeroy-app és a leeroy-web Go kódot és egyszerű Docker-fájlokat tartalmaz a kód helyi felépítéséhez:
~/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 .
Nem adom meg a jelentkezési kódot - ezt elég tudni leeroy-web elfogadja a kéréseket és meghatalmazza azokat leeroy-app. Ezért a fájlokban Deployment.yaml csak a számára van szolgáltatás app (belső útválasztáshoz). Pod port web továbbítjuk magunknak az alkalmazáshoz való gyors hozzáférés érdekében.
Úgy 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
Az összes fent említett szakasz leírása itt található. Ezen a konfiguráción kívül van még egy fájl globális beállításokkal - ~/.skaffold/config. Szerkeszthető manuálisan vagy a CLI-n keresztül - 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 jelentésbe true, amely után a Skaffold nem próbál meg képeket a távoli rendszerleíró adatbázisba tolni. Ha helyben fejleszt, akkor ezt a parancsot használhatja a képek helyi létrehozásához.
Vissza a skaffold.yaml:
- A színpadon
buildmegadjuk, hogy a képet helyben kell összegyűjtenie és mentenie. A build első futtatása után a következőket fogjuk látni:// т.к. 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.1MBMint látható, Skaffold maga címkézte fel a képeket. Mellesleg számos címkézési irányelv támogatott.
- A konfigurációban tovább van jelezve
context: ./leeroy-app/, azaz meg van adva a kontextus, amelyben a képet gyűjtik. - A telepítési szakaszban meghatározásra került, hogy a kubectl-t és a maszkot használjuk a szükséges manifesztekhez.
-
PortForward: hasonlóan ahhoz, ahogyan általában portokat továbbítunkkubectl port-forward, utasításokat adunk a Skaffoldnak a parancs meghívására. Ebben az esetben a helyi 9000-es portot a rendszer a 8080-asra továbbítja a Telepítésben a névvelleeroy-web.
Ideje elindítani skaffold dev: A csapat egy folyamatos „visszacsatolási hurkot” hoz létre, azaz. nemcsak összegyűjti és telepíti a fürtbe mindent, hanem a podok aktuális állapotáról is tájékoztat, figyeli a változásokat és frissíti a podok állapotát.
Íme az indulás eredménye skaffold dev --port-forward összeszereléskor:
Először is láthatja, hogy a gyorsítótár használatban van. Ezután az alkalmazás összeállítása, üzembe helyezése és a portok továbbítása megtörténik. Mivel meghatározott --port-forward, Skaffold továbbította a portot ide web, ahogy kérték, de itt app saját belátása szerint dobta (a legközelebbi szabadot választotta). Ezt követően kapjuk meg az első naplókat az alkalmazásoktól.
Nézzük meg, működik-e?
~/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!!!
A fájl módosítása leeroy-app/app.go - eltelik 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!!!
Ugyanakkor maga a Skaffold ugyanazt jelenítette meg a konzolon, mint korábban, egy pont kivételével: csak kigurult leeroy-app, és nem egyszerre.
Több gyakorlás
Azt is érdemes megemlíteni, hogy új projekt létrehozásakor a Skaffold konfigurációi a paranccsal indíthatók. init, ami nagyon kényelmes. Ezenkívül több konfigurációt is írhat: hajtsa végre a fejlesztést az alapértelmezett konfiguráción, majd terjessze ki a színpadra a paranccsal run (ugyanaz a folyamat, mint dev, csak nem figyeli a változásokat), másik konfiguráció használatával.
A katacodán van Egy példával még könnyebb. De kínál egy kész homokozót Kubernetes-szel, egy alkalmazást és Skaffoldot. Kiváló lehetőség, ha szeretné saját maga is kipróbálni az alapokat.
A Skaffold egyik lehetséges felhasználási esete a fejlesztés egy távoli fürtön történő végrehajtása. Nem mindenki érzi kényelmesen a saját hardverén futtatni a Minikube-ot, majd kiteríteni az alkalmazást, és elvárni, hogy megfelelően működjön... Ebben az esetben a Skaffold tökéletesen megoldja a problémát, amit például a Reddit mérnökei is megerősíthetnek, hiszen mi is már megbeszélték a blogunkban.
És a Weaveworks-től találhat példát egy gyártási folyamat létrehozására.
Következtetés
A Skaffold egy kényelmes eszköz olyan csővezetékek építéséhez, amelyek magukban foglalják az alkalmazások Kubernetes számára történő bevezetését, és elsősorban a fejlesztési igényekre összpontosítanak. Meglehetősen egyszerűvé teszi egy „rövid” folyamat létrehozását, amely figyelembe veszi a fejlesztő alapvető igényeit, de ha kívánja, nagyobb folyamatokat is szervezhet. A Skaffold CI/CD folyamatokban való használatának egyik egyértelmű példája ilyen 10 mikroszolgáltatásból a Kubernetes, a gRPC, az Istio és az OpenCensus Tracing képességeit használva.
A Skaffoldnak már közel 8000 csillaga van a GitHubon, a Google fejlesztette, és része a – Általánosságban elmondható, hogy jelenleg minden okunk megvan azt hinni, hogy a projekt boldogan fog fejlődni.
PS
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
Forrás: will.com