Обзор на Skaffold за разработка под Kubernetes

Половин година преди, на 5 март 2018 г., компания Google издаде първата алфа версия на своя проект с отворен код за 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 на стойност 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 може да намерите пример за създаване на пайплайн за продукция.

Заключение

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