Преглед на Skaffold за разработка под Kubernetes

Проведени е 5 март 2018 г., когато Google пусна първата alpha версия на своя проект с отворен код за CI/CD, наречен Skaffold, чиято цел беше да създаде "опростена и възпроизводима разработка под 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 с нужните примери:

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 директории, 8 файла

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 на стойността истинно, след което 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 в деплоймента с името 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 можете да намерите пример за създаване на пайплайн за производствени нужди.

Заключение

Skaffold е удобен инструмент за изграждане на пайплайни, които предвиждат разгръщане на приложения в Kubernetes и са насочени предимно към нуждите на разработката. С него е доста лесно да се създаде „кратък“ пайплайн, който отчита основните потребности на разработчиците, но при желание могат да се организират и по-широки процеси. Като един от нагледните примери за приложение на Skaffold в CI/CD процесите се представя такова тестов проект от 10 микросервиза, използващи функционалността на Kubernetes, gRPC, Istio и OpenCensus Tracing.

Skaffold вече е получил почти 8000+ звездички в GitHub, разработва се от Google и е част от GoogleContainerTools — в общи линии, в момента има всички основания да се смята, че проектът ще се развива дълго и щастливо.

P.S.

Прочетете също в нашия блог:

• «Инструменти за разработчици на приложения, работещи в Kubernetes»;
• «werf — нашият инструмент за CI/CD в Kubernetes (преглед и видео доклад)»;
• «Garden v0.10.0: Вашият лаптоп не се нуждае от Kubernetes»;
• «Kubernetes съвети и трикове: за локална разработка и Telepresence».

Източник: habr.com