
Преди година и половина, на 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. В интернет можете да намерите препратки към опити за създаване , но в момента това най-вероятно просто означава, че някой има нужда от него, но не наистина.
- Модулност. Skaffold не е самостоятелен комбайн, а се стреми да използва отделни модули или съществуващи решения за конкретни задачи.
Илюстрация на последното:
- На етапа на сглобяване можете да използвате:
- изграждане на docker локално, в клъстер с помощта на kaniko или в Google Cloud Build;
- Bazel локално;
- Jib Maven и Jib Gradle локално или в Google Cloud Build;
- персонализираните скриптове за изграждане се изпълняват локално. Ако трябва да стартирате друго (по-гъвкаво/познато/...) решение за компилация, то е описано в скрипта, така че Skaffold да го стартира (). Това ви позволява да използвате всеки колектор, който може да бъде извикан с помощта на скрипт;
- На етапа на тестване вече споменатите ;
- За внедряване се предоставя следното:
- Kubectl;
- Шлем;
- персонализирайте.
Благодарение на това Skaffold може да се нарече уникален рамка за изграждане на CI/CD. Ето примерен работен процес при използването му (от документацията на проекта):

Как изглежда най-общо работата на Скафолд?
- Помощната програма следи промените в директорията на изходния код. Ако се правят модификации на файловете, те се синхронизират с модула на приложението в клъстера Kubernetes. Ако е възможно, без повторно сглобяване на изображението. В противен случай се сглобява ново изображение.
- Сглобеното изображение се проверява с помощта на контейнер-структура-тест, маркира се и се изпраща в регистъра на Docker.
- След това изображението се разгръща - разгръща се в клъстера Kubernetes.
- Ако стартирането е инициализирано с помощта на командата
skaffold dev, тогава започваме да получаваме регистрационни файлове от приложението и Skaffold чака промени, за да повтори всички действия отново.

Илюстрация на основните етапи на операция Skaffold
Практикувайте. Опитвам Skaffold
За да демонстрирам използването на Skaffold, ще взема пример от . Между другото, Можете да намерите много други примери, които отчитат различни специфики. Ще извършвам всички действия локално в 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 и е част от — като цяло, в момента има всички основания да се смята, че проектът ще се развива щастливо завинаги.
PS
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «".
Източник: www.habr.com
