Skaffold-ის მიმოხილვა Kubernetes-ის განვითარებისთვის

წელიწადნახევრის წინ, 5 წლის 2018 მარტს, Google-მა გამოუშვა თავისი ღია კოდის პროექტის პირველი ალფა ვერსია CI/CD-ისთვის ე.წ. ხარაჩო, რომლის მიზანი იყო შექმნა "მარტივი და განმეორებადი Kubernetes განვითარების", რათა დეველოპერებს შეეძლოთ ფოკუსირება განვითარებაზე და არა ადმინისტრირებაზე. რა შეიძლება იყოს საინტერესო Skaffold-ის შესახებ? როგორც ირკვევა, მას აქვს რამდენიმე ხრიკი, რაც მას შეუძლია მძლავრ ინსტრუმენტად აქციოს დეველოპერებისთვის და შესაძლოა ოპერაციების ინჟინრისთვისაც კი. გავეცნოთ პროექტს და მის შესაძლებლობებს.

NB: სხვათა შორის, სკაფოლდზე უკვე მოკლედ ვისაუბრეთ ჩვენს გენერალში დეველოპერის ინსტრუმენტების მიმოხილვა, რომლის ცხოვრებაც კუბერნეტესს უკავშირდება.

თეორია. მიზანი და შესაძლებლობები

ასე რომ, ზოგადად რომ ვთქვათ, Skaffold წყვეტს CI/CD ციკლის ავტომატიზაციის პრობლემას (აშენების, დაყენების, განლაგების ეტაპებზე), სთავაზობს დეველოპერს სწრაფ გამოხმაურებას, ე.ი. კოდის შემდგომი ცვლილებების შედეგის სწრაფად მიღების შესაძლებლობა - განახლებული აპლიკაციის სახით, რომელიც მუშაობს Kubernetes კლასტერში. და მას შეუძლია იმუშაოს სხვადასხვა სქემებში (dev, stage, production...), რისთვისაც Skaffold ეხმარება აღწერს შესაბამისი მილსადენების გაშვებას.

Skaffold-ის წყაროს კოდი იწერება Go-ში, ვრცელდება უფასო Apache ლიცენზიით 2.0 (GitHub).

განვიხილოთ ძირითადი ფუნქციები და მახასიათებლები. პირველი მოიცავს შემდეგს:

• Skaffold გთავაზობთ ინსტრუმენტებს CI/CD მილსადენების შესაქმნელად.
• საშუალებას გაძლევთ თვალყური ადევნოთ წყაროს კოდის ცვლილებებს ფონზე და განახორციელოთ კოდის კონტეინერების სურათებში შეკრების ავტომატური პროცესი, გამოაქვეყნოთ ეს სურათები Docker Registry-ში და განათავსოთ ისინი Kubernetes კლასტერში.
• ახდენს საცავში არსებული ფაილების სინქრონიზაციას კონტეინერში არსებულ სამუშაო დირექტორიასთან.
• ავტომატური ტესტირება კონტეინერის სტრუქტურის ტესტის გამოყენებით.
• გადამისამართების პორტები.
• კითხულობს კონტეინერში გაშვებული აპლიკაციის ჟურნალებს.
• ეხმარება Java, Node.js, Python, Go-ში დაწერილი აპლიკაციების გამართვაში.

ახლა მახასიათებლების შესახებ:

• თავად სკაფოლდს არ აქვს კასეტური გვერდითი კომპონენტები. ანუ, არ არის საჭირო Kubernetes-ის შემდგომი კონფიგურაცია ამ პროგრამის გამოსაყენებლად.
• სხვადასხვა მილსადენები თქვენი განაცხადისთვის. გჭირდებათ კოდის გავრცელება ადგილობრივ Minikube-ში განვითარების პროცესში, შემდეგ კი სცენაზე ან წარმოებაზე? ამ მიზნით არსებობს პროფილები და მომხმარებლის კონფიგურაციები, გარემოს ცვლადები და დროშები, რომლებიც საშუალებას გაძლევთ აღწეროთ სხვადასხვა მილსადენები ერთი აპლიკაციისთვის.
• CLI. მხოლოდ კონსოლის უტილიტა და კონფიგურაციები YAML-ში. ინტერნეტში შეგიძლიათ იპოვოთ ცნობები შექმნის მცდელობებზე ექსპერიმენტული GUIთუმცა, ამ მომენტში ეს დიდი ალბათობით მხოლოდ იმას ნიშნავს, რომ ვიღაცას სჭირდება ის, მაგრამ სინამდვილეში არა.
• მოდულურობა. Skaffold არ არის დამოუკიდებელი კომბაინი, მაგრამ მიზნად ისახავს გამოიყენოს ინდივიდუალური მოდულები ან არსებული გადაწყვეტილებები კონკრეტული ამოცანებისთვის.

ამ უკანასკნელის ილუსტრაცია:

• შეკრების ეტაპზე შეგიძლიათ გამოიყენოთ:
  • docker build ადგილობრივად, კლასტერში kaniko-ს გამოყენებით ან Google Cloud Build-ში;
  • ბაზელი ადგილობრივად;
  • Jib Maven და Jib Gradle ადგილობრივად ან Google Cloud Build-ში;
  • მორგებული აშენების სკრიპტები ადგილობრივად მუშაობს. თუ გჭირდებათ სხვა (უფრო მოქნილი/ნაცნობი/...) build გადაწყვეტის გაშვება, ის აღწერილია სკრიპტში ისე, რომ Skaffold-მა გაუშვას იგი (მაგალითი დოკუმენტაციიდან). ეს საშუალებას გაძლევთ გამოიყენოთ ნებისმიერი კოლექტორი, რომელიც შეიძლება გამოიძახოთ სკრიპტის გამოყენებით;
• ტესტირების ეტაპზე უკვე ნახსენები კონტეინერი-სტრუქტურა-ტესტი;
• განლაგებისთვის მოცემულია შემდეგი:
  • Kubectl;
  • ჩაფხუტი;
  • მორგება.

ამის წყალობით, Skaffold-ს შეიძლება ეწოდოს უნიკალური ჩარჩო CI/CD ასაშენებლად. აქ არის სამუშაო პროცესის მაგალითი მისი გამოყენებისას (პროექტის დოკუმენტაციიდან):

როგორ გამოიყურება სკაფოლდის ნამუშევარი ზოგადად?

1. პროგრამა აკონტროლებს ცვლილებებს წყაროს კოდის დირექტორიაში. თუ ფაილებში ცვლილებები განხორციელდება, ისინი სინქრონიზდება Kubernetes კლასტერში აპლიკაციის პოდთან. თუ შესაძლებელია, სურათის ხელახლა შეკრების გარეშე. წინააღმდეგ შემთხვევაში, ახალი სურათი იკრიბება.
2. აწყობილი სურათი მოწმდება კონტეინერის სტრუქტურის ტესტის გამოყენებით, მონიშნულია და იგზავნება დოკერის რეესტრში.
3. ამის შემდეგ, გამოსახულება განლაგებულია - განლაგებულია Kubernetes კლასტერში.
4. თუ გაშვება მოხდა ბრძანების გამოყენებით skaffold dev, შემდეგ ვიწყებთ ჟურნალების მიღებას აპლიკაციიდან და Skaffold ელოდება ცვლილებებს, რათა ხელახლა გაიმეოროს ყველა მოქმედება.

Skaffold-ის მუშაობის ძირითადი ეტაპების ილუსტრაცია

ივარჯიშე. ცდილობს Skaffold

Skaffold-ის გამოყენების დემონსტრირებისთვის მაგალითს მოვიყვან GitHub პროექტის საცავი... Ჰო მართლა, იმავე ადგილას თქვენ შეგიძლიათ იპოვოთ მრავალი სხვა მაგალითი, რომელიც ითვალისწინებს სხვადასხვა სპეციფიკას. მინიკუბეში ლოკალურად შევასრულებ ყველა მოქმედებას. ინსტალაცია მარტივია და რამდენიმე წუთს იღებს, დასაწყებად კი დაგჭირდებათ 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 აპლიკაციას. ერთ-ერთი აპლიკაცია არის frontend (leeroy-web), რომელიც გადამისამართებს მოთხოვნას მეორე აპლიკაციაში - backend (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 ჩვენ ვაზუსტებთ, რომ თქვენ უნდა შეაგროვოთ და შეინახოთ სურათი ადგილობრივად. მას შემდეგ, რაც 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

  როგორც ხედავთ, სკაფოლდმა თავად მონიშნა სურათები. სხვათა შორის, თეგის რამდენიმე პოლიტიკა მხარდაჭერილია.

• შემდგომ კონფიგურაციაში მითითებულია context: ./leeroy-app/, ე.ი. კონტექსტი, რომელშიც სურათი გროვდება, მითითებულია.
• განლაგების ეტაპზე დადგენილია, რომ გამოვიყენებთ კუბექტლს და ნიღაბს საჭირო მანიფესტებისთვის.
• PortForward: მსგავსია, თუ როგორ ვაგზავნით ჩვეულებრივ პორტებს kubectl port-forward, ჩვენ ინსტრუქციას ვაძლევთ Skaffold-ს ამ ბრძანების გამოძახების მიზნით. ამ შემთხვევაში, ადგილობრივი პორტი 9000 გადაგზავნილია 8080-ზე Deployment-ში სახელით leeroy-web.

გაშვების დროა skaffold dev: გუნდი შექმნის მიმდინარე „უკუკავშირის ციკლს“, ე.ი. ის არა მხოლოდ შეაგროვებს ყველაფერს და განათავსებს მას კლასტერში, არამედ მოგიყვებათ ამჟამინდელი ჯირკვლის მდგომარეობის შესახებ, მონიტორინგს გაუწევს ცვლილებებს და განაახლებს პოდების მდგომარეობას.

აქ არის გაშვების შედეგი skaffold dev --port-forward ხელახლა შეკრებისას:

პირველი, თქვენ ხედავთ, რომ ქეში გამოიყენება. შემდეგი, აპლიკაცია იკრიბება, განლაგებულია და პორტები გადაგზავნილია. მას შემდეგ, რაც მითითებულია --port-forwardსკაფოლდმა გადააგზავნა პორტი 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