Агляд Skaffold для распрацоўкі пад Kubernetes

Паўтара гады назад, 5 сакавіка 2018, кампанія Google выпусціла першую альфа-версію свайго Open Source-праекта для CI/CD пад назовам Скафот, Мэтай якога стала стварэнне «простай і ўзнаўляльнай распрацоўкі пад Kubernetes», каб распрацоўшчыкі маглі сфакусавацца менавіта на распрацоўцы, а не на адміністраванні. Чым можа быць цікавы Skaffold? Як аказалася, у яго ёсць некалькі козыраў у рукаве, дзякуючы якім ён можа стаць моцнай прыладай для распрацоўніка, а можа – і інжынера па эксплуатацыі. Пазнаёмімся з праектам і яго магчымасцямі.

NB: Дарэчы, мы ўжо расказвалі сцісла пра Skaffold у нашым агульным. аглядзе інструментаў для распрацоўшчыкаў, жыццё якіх звязана з Kubernetes.

Тэорыя. Прызначэнне і магчымасці

Такім чынам, калі казаць увогуле, то Skaffold вырашае задачу аўтаматызацыі цыклу CI/CD (на стадыях build, push, deploy), прапануючы распрацоўніку аператыўную зваротную сувязь, г.зн. магчымасць хутка атрымліваць вынік чарговых змен кода - у выглядзе абноўленага прыкладання, які працуе ў кластары Kubernetes. А працаваць яно можа ў розных контурах (dev, stage, production…), для чаго Skaffold дапамагае апісваць адпаведныя пайплайны для выкату.

Зыходны код Skaffold напісаны на мове Go, распаўсюджваецца на ўмовах свабоднай ліцэнзіі Apache License 2.0 (GitHub).

Разгледзім асноўныя функцыі і асаблівасці. Да першых можна аднесці наступныя:

• Skaffold прапануе інструментар для стварэння CI/CD-пайплайнаў.
• Дазваляе ў фонавым рэжыме сачыць за зменамі ў зыходным кодзе і запускаць аўтаматызаваны працэс зборкі кода ў вобразы кантэйнераў, публікацыі гэтых вобразаў у Docker Registry і іх дэплою ў кластар Kubernetes.
• Сінхранізуе файлы ў рэпазітары з працоўным каталогам у кантэйнеры.
• Аўтаматычна тэсціруе з дапамогай container-structure-test.
• Пракідвае парты.
• Чытае логі прыкладання, запушчанага ў кантэйнеры.
• Дапамагае ў адладцы дадаткаў, напісаных на Java, Node.js, Python, Go.

Зараз – пра асаблівасці:

• У самога Skaffold няма кампанентаў на баку кластара. Гэта значыць дадаткова настройваць Kubernetes для выкарыстання гэтай утыліты не патрабуецца.
• Розныя пайплайны для вашага прыкладання. Трэба выкочваць код у лакальны Minikube, пакуль ведзяце распрацоўку, а пасля – на stage або production? Для гэтага прадугледжаны профілі і карыстацкія канфігурацыі, зменныя асяроддзі і сцягі, што дазваляюць апісваць розныя пайплайны для аднаго прыкладання.
• CLI. Толькі кансольная ўтыліта і канфігурацыі ў YAML. У сетцы можна знайсці згадванні спроб стварэння эксперыментальнага GUI, Аднак на дадзены момант гэта хутчэй толькі азначае, што ён камусьці патрэбен, але не вельмі.
• модульнасць. Skaffold не з'яўляецца самастойным камбайнам, а імкнецца выкарыстоўваць асобныя модулі ці ўжо існуючыя рашэнні для канкрэтных задач.

Ілюстрацыя апошняга:

• На стадыі зборкі можна выкарыстоўваць:
  • docker build лакальна, у кластары з дапамогай kaniko ці ў Google Cloud Build;
  • Bazel лакальна;
  • Jib Maven і Jib Gradle лакальна ці ў Google Cloud Build;
  • кастамныя build-скрыпты, якія запускаюцца лакальна. Калі вам трэба запускаць іншае (больш гнуткае/звыклае/…) ​​рашэнне для зборкі, яно апісваецца ў скрыпце, каб Skaffold запускаў менавіта яго (прыклад з дакументацыі). Гэта дазваляе выкарыстоўваць увогуле любы зборшчык, які можна выклікаць з дапамогай скрыпту;
• На стадыі тэсціравання падтрымліваецца ўжо згаданы container-structure-test;
• Для дэплою прадугледжаны:
  • Kubectl;
  • Helm;
  • kustomize.

Дзякуючы гэтаму Skaffold можна назваць своеасаблівым фрэймворкам для пабудовы CI/CD. Вось прыклад працоўнага працэсу пры ім выкарыстанні (з дакументацыі праекту):

Як у агульных рысах выглядае праца Skaffold?

1. Утыліта сочыць за зменамі ў дырэкторыі з зыходным кодам. Калі ў файлы ўносяцца мадыфікацыі, яны сінхранізуюцца з pod'ом прыкладанні ў кластары Kubernetes. Калі гэта магчыма - без паўторнай зборкі выявы. У іншым выпадку - збіраецца новы вобраз.
2. Сабраная выява правяраецца з дапамогай container-structure-test, тэгуецца і адпраўляецца ў Docker Registry.
3. Пасля гэтага выява деплоится - разгортваецца ў кластары Kubernetes.
4. Калі запуск быў ініцыялізаваны з дапамогай каманды skaffold dev, то мы пачынаем атрымліваць логі ад прыкладання, а Skaffold чакае змен, каб паўтарыць усе дзеянні нанова.

Ілюстрацыя асноўных этапаў працы Skaffold

Практыка. Спрабуем Skaffold

Для дэманстрацыі выкарыстання Skaffold вазьму прыклад з GitHub-рэпазітара праекта. Дарэчы, там жа можна знайсці і мноства іншых прыкладаў, якія ўлічваюць розную спецыфіку. Усе дзеянні буду выконваць лакальна ў Minikube. Ўстаноўка простая і зойме некалькі хвілін, а для пачатку працы спатрэбіцца kubectl.

Усталюем 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

Склануем сабе рэпазітар Skaffold'a з патрэбнымі прыкладамі:

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

Я абраў прыклад з двума pod'амі, кожны з якіх утрымоўвае па адным маленькім дадатку на Go. Адно прыкладанне - фронтэнд (leeroy-web), які перанакіроўвае запыт на другое прыкладанне - бэкенд (leeroy-app). Паглядзім, як гэта выглядае:

~/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 і leeroy-web утрымоўваюць код на Go і простыя Dockerfiles для лакальнай зборкі гэтага самага кода:

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

Код прыкладанняў прыводзіць не буду - дастаткова ведаць, што leeroy-web прымае запыты і праксіруе іх на leeroy-app. Таму ў файлах Deployment.yaml існуе Service толькі для app (для ўнутранай маршрутызацыі). Порт pod'а web мы будзем пракідваць сабе для хуткага доступу да дадатку.

як выглядае 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

Тут апісваюцца ўсе стадыі, згаданыя вышэй. Акрамя гэтага канфіга ёсць і файл з глабальнымі наладамі. ~/.skaffold/config. Яго можна рэдагаваць уручную ці праз CLI — напрыклад, так:

skaffold config set --global local-cluster true

Гэтая каманда ўсталюе глабальную зменную local-cluster у значэнне true, пасля чаго Skaffold не будзе спрабаваць за'push'іць выявы ў выдалены рэестр. Калі вы вядзеце распрацоўку лакальна, можна скарыстацца гэтай камандай, каб складаць выявы гэтак жа лакальна.

вернемся да skaffold.yaml:

• На стадыі build мы паказваем, што сабраць і захаваць выяву трэба лакальна. Пасля таго, як упершыню запусціцца зборка, убачым наступнае:

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

  Як відаць, Skaffold самастойна пратэгаваў выявы. Дарэчы, падтрымліваецца некалькі палітык тэгавання.

• Далей у канфізе пазначана context: ./leeroy-app/, г.зн. зададзены кантэкст, у якім збіраецца выява.
• На стадыі дэплою вызначаецца, што выкарыстоўваць будзем kubectl і маску для патрэбных маніфэстаў.
• PortForward: аналагічна таму, як мы звычайна пракідваем парты з дапамогай kubectl port-forward, даем інструкцыі Skaffold для выкліку гэтай каманды. У дадзеным выпадку – лакальны порт 9000 пракідваецца на 8080 у Deployment'е з імем leeroy-web.

Самы час запусціць skaffold dev: каманда створыць «цыкл зваротнай сувязі», які працягваецца, г.зн. не толькі збярэ ўсё і задэплоіруе ў кластар, але і раскажа пра стан pod'аў у дадзены момант, будзе сачыць за зменамі і абнаўляць стан pod'аў.

Вось вынік запуску skaffold dev --port-forward пры паўторнай зборцы:

Па-першае, бачна, што выкарыстоўваецца кэш. Далей - дадатак збіраецца, дэплоі, пракідваюцца парты. Паколькі пазначаны --port-forward, Skaffold пракінуў порт да web, як яго прасілі, а вось app ён пракінуў па ўласным меркаванні (выбраў бліжэйшы вольны). Пасля гэтага мы атрымліваем першыя логі ад прыкладанняў.

Праверым працаздольнасць?

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

Мадыфікуем файл leeroy-app/app.go - праходзіць некалькі секунд… і:

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

Пры гэтым сам Skaffold вывеў у кансоль тое ж самае, што і раней, за выключэннем аднаго моманту: ён выкаціў толькі leeroy-app, а не ўсё адразу.

Больш практыкі

Варта згадаць і тое, што пры стварэнні новага праекту канфігі для Skaffold можна за'bootstrap'іць з дапамогай каманды init, што вельмі зручна. Да таго ж, можна напісаць некалькі канфігаў: весці распрацоўку на канфігу па змаўчанні, пасля чаго выкаціцца на stage камандай run (той жа працэс, што і dev, толькі не сочыць за зменамі), скарыстаўшыся іншым канфігам.

На katacoda ёсць кіраўніцтва з прыкладам яшчэ прасцей. Затое там прапануецца ўжо гатовая пясочніца з Kubernetes, дадаткам і Skaffold. Выдатны варыянт, калі вам цікава самастойна паспрабаваць самыя асновы.

Адзін з магчымых варыянтаў выкарыстання Skaffold – вядзенне распрацоўкі на выдаленым кластары. Не ўсім зручна запускаць Minikube на ўласным жалезе, пасля чаго выкочваць прыкладанне і чакаць яго адэкватнага функцыянавання… У такім разе Skaffold выдатна вырашае пастаўленую задачу, што могуць пацвердзіць, напрыклад, інжынеры Reddit, пра што мы ўжо распавядаў у нашым блогу.

А ў гэтай публікацыі ад Weaveworks можна знайсці прыклад стварэння пайплайну для production.

Заключэнне

Skaffold - зручны інструмент для пабудовы пайплайнаў, якія маюць на ўвазе выкат прыкладанняў у Kubernetes і арыентаваных у першую чаргу на патрэбы распрацоўкі. З ім даволі проста ствараць кароткі пайплайн, які ўлічвае асноўныя запатрабаванні распрацоўніка, аднак пры жаданні можна арганізоўваць і больш маштабныя працэсы. У якасці аднаго з навочных прыкладаў ужывання Skaffold у CI/CD-працэсах прыводзіцца такі тэставы праект з 10 мікрасэрвісаў, якія выкарыстоўваюць магчымасці Kubernetes, gRPC, Istio і OpenCensus Tracing.

Skaffold ужо атрымаў амаль 8000+ зорак на GitHub, распрацоўваецца Google і ўваходзіць у склад GoogleContainerTools - Увогуле, на дадзены момант ёсць усе падставы меркаваць, што праект будзе развівацца доўга і шчасліва.

PS

Чытайце таксама ў нашым блогу:

• «Інструменты для распрацоўшчыкаў прыкладанняў, якія запускаюцца ў Kubernetes»;
• «werf – наш інструмент для CI/CD у Kubernetes (агляд і відэа даклада)»;
• «Garden v0.10.0: Вашаму наўтбуку не патрэбен Kubernetes»;
• «Kubernetes tips & tricks: аб лакальнай распрацоўцы і Telepresence.

Крыніца: habr.com