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

Преди година и половина, на 5 март 2018 г., Google пусна първата алфа версия на своя проект с отворен код за CI/CD, наречен Скеле, чиято цел беше да създаде „проста и повторяема разработка на Kubernetes“, така че разработчиците да могат да се съсредоточат върху разработката, а не върху администрирането. Какво може да е интересно за Skaffold? Както се оказва, той има няколко трика в ръкава си, които могат да го направят мощен инструмент за разработчика и може би дори за оперативния инженер. Нека се запознаем с проекта и неговите възможности.

NB: Между другото, вече говорихме накратко за Skaffold в нашия общ преглед на инструментите за разработчици, чийто живот е свързан с Kubernetes.

Теория. Предназначение и възможности

Така че, най-общо казано, Skaffold решава проблема с автоматизирането на цикъла CI/CD (на етапите на изграждане, натискане, внедряване), като предлага на разработчиците бърза обратна връзка, т.е. възможност за бързо получаване на резултата от последващи промени в кода - под формата на актуализирано приложение, работещо в клъстера Kubernetes. И може да работи в различни схеми (dev, stage, production...), за които Skaffold помага да се опишат съответните тръбопроводи за внедряване.

Изходният код на Skaffold е написан на Go, разпространява се от под безплатния лиценз Apache 2.0 (GitHub).

Нека да разгледаме основните функции и характеристики. Първите включват следното:

• Skaffold предлага инструменти за създаване на CI/CD тръбопроводи.
• Позволява ви да наблюдавате промените в изходния код във фонов режим и да изпълнявате автоматизиран процес на сглобяване на код в изображения на контейнери, публикуване на тези изображения в регистъра на Docker и внедряването им в клъстера на Kubernetes.
• Синхронизира файловете в хранилището с работната директория в контейнера.
• Автоматично тества с помощта на контейнер-структура-тест.
• Препраща портове.
• Чете регистрационните файлове на приложение, работещо в контейнер.
• Помага при отстраняване на грешки в приложения, написани на Java, Node.js, Python, Go.

Сега за характеристиките:

• Самият Skaffold няма компоненти от страната на клъстера. Това означава, че няма нужда от допълнително конфигуриране на Kubernetes за използване на тази помощна програма.
• Различни тръбопроводи за вашето приложение. Трябва ли да внедрите кода в местния Minikube, докато разработвате, и след това да го поставите на етап или в производство? За тази цел има профили и потребителски конфигурации, променливи на средата и флагове, които ви позволяват да описвате различни конвейери за едно приложение.
• CLI. Само конзолна помощна програма и конфигурации в YAML. В интернет можете да намерите препратки към опити за създаване експериментален GUI, но в момента това най-вероятно просто означава, че някой има нужда от него, но не наистина.
• Модулност. Skaffold не е самостоятелен комбайн, а се стреми да използва отделни модули или съществуващи решения за конкретни задачи.

Илюстрация на последното:

• На етапа на сглобяване можете да използвате:
  • изграждане на docker локално, в клъстер с помощта на kaniko или в Google Cloud Build;
  • Bazel локално;
  • Jib Maven и Jib Gradle локално или в Google Cloud Build;
  • персонализираните скриптове за изграждане се изпълняват локално. Ако трябва да стартирате друго (по-гъвкаво/познато/...) решение за компилация, то е описано в скрипта, така че Skaffold да го стартира (пример от документацията). Това ви позволява да използвате всеки колектор, който може да бъде извикан с помощта на скрипт;
• На етапа на тестване вече споменатите контейнер-структура-тест;
• За внедряване се предоставя следното:
  • Kubectl;
  • Шлем;
  • персонализирайте.

Благодарение на това Skaffold може да се нарече уникален рамка за изграждане на CI/CD. Ето примерен работен процес при използването му (от документацията на проекта):

Как изглежда най-общо работата на Скафолд?

1. Помощната програма следи промените в директорията на изходния код. Ако се правят модификации на файловете, те се синхронизират с модула на приложението в клъстера Kubernetes. Ако е възможно, без повторно сглобяване на изображението. В противен случай се сглобява ново изображение.
2. Сглобеното изображение се проверява с помощта на контейнер-структура-тест, маркира се и се изпраща в регистъра на Docker.
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

Избрах пример с две подове, всяка съдържаща по едно малко приложение 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 има услуга само за app (за вътрешно маршрутизиране). Под порт 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 няма да се опитва да изпраща изображения към отдалечения регистър. Ако разработвате локално, можете да използвате тази команда за изграждане на изображения локално.

Обратно към 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: Екипът ще създаде постоянен „примка за обратна връзка“, т.е. не само ще събере всичко и ще го разположи в клъстера, но също така ще ви разкаже за състоянието на подовете в момента, ще наблюдава промените и ще актуализира състоянието на подовете.

Ето резултата от стартирането 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 могат да бъдат стартирани с помощта на командата init, което е много удобно. Освен това можете да напишете няколко конфигурации: да извършите разработка на конфигурацията по подразбиране и след това да я разгърнете на етап с командата run (същият процес като dev, просто не следи промените), използвайки различна конфигурация.

На катакода има ръководство Още по-лесно е с пример. Но предлага готов пясъчник с Kubernetes, приложение и Skaffold. Страхотен вариант, ако се интересувате сами да изпробвате самите основи.

Един възможен случай на използване на Skaffold е провеждането на разработка на отдалечен клъстер. Не всеки се чувства удобно да стартира Minikube на собствения си хардуер, след което да пусне приложението и да очаква да функционира адекватно... В този случай Skaffold решава проблема перфектно, което може да бъде потвърдено например от инженерите на Reddit, както имаме вече обсъдени писали в нашия блог.

И в тази публикация от Weaveworks можете да намерите пример за създаване на конвейер за производство.

Заключение

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: относно местното развитие и телеприсъствието".

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