ახლა თქვენ შეგიძლიათ შექმნათ Docker სურათები werf-ში ჩვეულებრივი Dockerfile-ის გამოყენებით

Სჯობს გვიან, ვიდრე არასდროს. ან როგორ თითქმის დავუშვით სერიოზული შეცდომა, როდესაც არ გვქონდა რეგულარული Dockerfiles-ის მხარდაჭერა აპლიკაციის სურათების შესაქმნელად.

ჩვენ ვისაუბრებთ ვერფ — GitOps პროგრამა, რომელიც ინტეგრირდება ნებისმიერ CI/CD სისტემასთან და უზრუნველყოფს აპლიკაციის მთელი სასიცოცხლო ციკლის მართვას, რაც საშუალებას აძლევს:

• შეაგროვოს და გამოაქვეყნოს სურათები,
• განათავსეთ აპლიკაციები Kubernetes-ში,
• წაშალეთ გამოუყენებელი სურათები სპეციალური პოლიტიკის გამოყენებით.

პროექტის ფილოსოფია არის დაბალი დონის ხელსაწყოების შეგროვება ერთიან ერთიან სისტემაში, რომელიც DevOps ინჟინრებს აძლევს აპლიკაციებზე კონტროლს. თუ შესაძლებელია, გამოყენებული უნდა იქნეს არსებული კომუნალური საშუალებები (როგორიცაა Helm და Docker). თუ პრობლემის გადაწყვეტა არ არის, ჩვენ შეგვიძლია შევქმნათ და მხარი დავუჭიროთ ამისთვის საჭირო ყველაფერს.

ფონი: თქვენი საკუთარი სურათების კოლექციონერი

ასე მოხდა გამოსახულების კოლექციონერთან werf-ში: ჩვეულებრივი Dockerfile ჩვენთვის საკმარისი არ იყო. თუ გადავხედავთ პროექტის ისტორიას, ეს პრობლემა უკვე გამოჩნდა werf-ის პირველ ვერსიებში (მაშინ ჯერ კიდევ ცნობილია როგორც dapp).

დოკერის სურათებში აპლიკაციების შესაქმნელად ხელსაწყოს შექმნისას ჩვენ სწრაფად მივხვდით, რომ Dockerfile არ იყო შესაფერისი ჩვენთვის ზოგიერთი ძალიან კონკრეტული ამოცანებისთვის:

1. ტიპიური მცირე ვებ აპლიკაციების აგების საჭიროება შემდეგი სტანდარტული სქემის მიხედვით:
   • სისტემის მასშტაბით აპლიკაციების დამოკიდებულების დაყენება,
   • დააინსტალირეთ აპლიკაციების დამოკიდებულების ბიბლიოთეკების ნაკრები,
   • აქტივების შეგროვება,
   • და რაც მთავარია, სურათზე კოდის განახლება სწრაფად და ეფექტურად.
2. როდესაც ცვლილებები ხდება პროექტის ფაილებში, მშენებელმა სწრაფად უნდა შექმნას ახალი ფენა შეცვლილ ფაილებზე პაჩის გამოყენებით.
3. თუ გარკვეული ფაილები შეიცვალა, მაშინ აუცილებელია შესაბამისი დამოკიდებული ეტაპის აღდგენა.

დღეს ჩვენს კოლექციონერს ბევრი სხვა შესაძლებლობა აქვს, მაგრამ ეს იყო საწყისი სურვილები და მოთხოვნილებები.

ზოგადად, ორჯერ დაფიქრების გარეშე, შევიარაღდით იმ პროგრამირების ენით, რომელსაც ვიყენებდით (იხილეთ ქვემოთ) და გაემართა განსახორციელებლად საკუთარი DSL! მიზნებიდან გამომდინარე, განზრახული იყო აწყობის პროცესის ეტაპობრივად აღწერა და ამ ეტაპების დამოკიდებულების განსაზღვრა ფაილებზე. და შეავსო იგი საკუთარი კოლექციონერი, რომელმაც DSL გადააქცია საბოლოო მიზნად - აწყობილ სურათად. თავიდან DSL იყო Ruby-ში, მაგრამ როგორც გადასვლა გოლანგზე — ჩვენი კოლექციონერის კონფიგურაციის აღწერა დაიწყო YAML ფაილში.

ძველი კონფიგურაცია dapp-ისთვის Ruby-ში

მიმდინარე კონფიგურაცია werf-ისთვის YAML-ზე

დროთა განმავლობაში შეიცვალა კოლექტორის მექანიზმიც. თავდაპირველად, ჩვენ უბრალოდ შევქმენით დროებითი Dockerfile on fly ჩვენი კონფიგურაციიდან, შემდეგ კი დავიწყეთ შეკრების ინსტრუქციების გაშვება დროებით კონტეინერებში და ჩადენა.

NB: ამ დროისთვის ჩვენი კოლექციონერი, რომელიც მუშაობს საკუთარი კონფიგურაციით (YAML-ში) და ჰქვია Stapel collector, უკვე საკმაოდ მძლავრ ინსტრუმენტად ჩამოყალიბდა. მისი დეტალური აღწერა იმსახურებს ცალკეულ სტატიებს და ძირითადი დეტალები შეგიძლიათ იხილოთ აქ დოკუმენტაცია.

პრობლემის გაცნობიერება

მაგრამ ჩვენ მივხვდით და არა მაშინვე, რომ ერთი შეცდომა დავუშვით: ჩვენ არ დავამატეთ უნარი სურათების შექმნა სტანდარტული Dockerfile-ის საშუალებით და დააკავშირეთ ისინი აპლიკაციების მართვის ერთსა და იმავე ინფრასტრუქტურაში (მაგ. შეაგროვეთ სურათები, განათავსეთ და გაასუფთავეთ ისინი). როგორ შეიძლებოდა Kubernetes-ში განლაგების ინსტრუმენტის შექმნა და Dockerfile-ის მხარდაჭერის არ განხორციელება, ე.ი. პროექტების უმეტესობის სურათების აღწერის სტანდარტული გზა?..

ამ კითხვაზე პასუხის ნაცვლად, ჩვენ გთავაზობთ გამოსავალს. რა მოხდება, თუ უკვე გაქვთ Dockerfile (ან Dockerfiles-ის ნაკრები) და გსურთ გამოიყენოთ werf?

NB: სხვათა შორის, რატომ გინდათ გამოიყენოთ werf? ძირითადი მახასიათებლები შემდეგია:

• აპლიკაციის მართვის სრული ციკლი გამოსახულების გაწმენდის ჩათვლით;
• რამდენიმე სურათის ერთდროულად შეკრების მართვის შესაძლებლობა ერთი კონფიგურაციიდან;
• გაუმჯობესებული განლაგების პროცესი Helm-თან თავსებადი სქემებისთვის.

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

ასე რომ, თუ ადრე შემოგთავაზებთ Dockerfile-ის გადაწერას ჩვენს კონფიგურაციაში, ახლა ჩვენ სიამოვნებით ვიტყვით: "მოდით, Werf-მა შექმნას თქვენი Dockerfiles!"

როგორ გამოვიყენოთ?

ამ ფუნქციის სრული განხორციელება გამოჩნდა გამოშვებაში werf v1.0.3-beta.1. ზოგადი პრინციპი მარტივია: მომხმარებელი ადგენს გზას არსებული Dockerfile-ისკენ werf კონფიგურაციაში და შემდეგ აწარმოებს ბრძანებას werf build... და ეს არის - werf შეკრებს გამოსახულებას. მოდით შევხედოთ აბსტრაქტულ მაგალითს.

შემდეგი გამოვაცხადოთ Dockerfile პროექტის ძირში:

FROM ubuntu:18.04
RUN echo Building ...

და გამოვაცხადებთ werf.yamlრომელიც იყენებს ამას Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

ყველა! მარცხენა გაუშვით werf build:

გარდა ამისა, შეგიძლიათ განაცხადოთ შემდეგი werf.yaml ერთდროულად რამდენიმე სურათის შექმნა სხვადასხვა Dockerfiles-დან:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

და ბოლოს, ის ასევე მხარს უჭერს დამატებითი build პარამეტრების გადაცემას, როგორიცაა --build-arg и --add-host - werf კონფიგურაციის საშუალებით. Dockerfile სურათის კონფიგურაციის სრული აღწერა ხელმისაწვდომია აქ დოკუმენტაციის გვერდი.

როგორ მუშაობს იგი?

აშენების პროცესში, Docker-ში ადგილობრივი ფენების სტანდარტული ქეში ფუნქციონირებს. თუმცა, მთავარია ისიც აერთიანებს Dockerfile კონფიგურაციას მის ინფრასტრუქტურაში. Რას ნიშნავს ეს?

1. Dockerfile-დან აგებული თითოეული სურათი შედგება ერთი ეტაპისგან, რომელსაც ეწოდება dockerfile (შეგიძლიათ წაიკითხოთ მეტი რა ეტაპებია werf-ში აქ).
2. სცენისთვის dockerfile werf ითვლის ხელმოწერას, რომელიც დამოკიდებულია Dockerfile კონფიგურაციის შინაარსზე. როდესაც Dockerfile-ის კონფიგურაცია იცვლება, იცვლება ეტაპის ხელმოწერა dockerfile და werf იწყებს ამ ეტაპის აღდგენას ახალი Dockerfile კონფიგურაციით. თუ ხელმოწერა არ იცვლება, მაშინ werf იღებს სურათს ქეშიდან (დამატებითი დეტალები werf-ში ხელმოწერების გამოყენების შესახებ იყო აღწერილი ამ მოხსენებას).
3. შემდეგი, შეგროვებული სურათები შეიძლება გამოქვეყნდეს ბრძანებით werf publish (ან werf build-and-publish) და გამოიყენეთ იგი Kubernetes-ში განლაგებისთვის. Docker Registry-ში გამოქვეყნებული სურათები გაიწმინდება სტანდარტული werf-ის გასუფთავების ხელსაწყოების გამოყენებით, ე.ი. ძველი სურათები (N დღეზე ძველი), სურათები, რომლებიც დაკავშირებულია არარსებულ Git ფილიალებთან და სხვა წესები ავტომატურად გაიწმინდება.

დამატებითი დეტალები აქ აღწერილი პუნქტების შესახებ შეგიძლიათ იხილოთ დოკუმენტაციაში:

• გამოცემის პროცესი;
• ინტეგრაცია Kubernetes-ის განლაგების პროცესთან;
• დასუფთავების პროცესი.

შენიშვნები და სიფრთხილის ზომები

1. გარე URL არ არის მხარდაჭერილი ADD-ში

ამჟამად არ არის მხარდაჭერილი დირექტივაში გარე URL-ის გამოყენება ADD. Werf არ დაიწყებს აღდგენას, როდესაც შეიცვლება რესურსი მითითებულ URL-ზე. ჩვენ მალე ვგეგმავთ ამ ფუნქციის დამატებას.

2. თქვენ არ შეგიძლიათ .git-ის დამატება სურათზე

ზოგადად რომ ვთქვათ, დირექტორიას დამატება .git სურათზე - მანკიერი ცუდი პრაქტიკა და აი რატომ:

1. თუ .git რჩება საბოლოო იმიჯში, ეს არღვევს პრინციპებს 12 ფაქტორიანი აპლიკაცია: ვინაიდან საბოლოო სურათი უნდა იყოს მიბმული ერთ კომიტთან, ამის გაკეთება შეუძლებელი უნდა იყოს git checkout თვითნებური ჩადენა.
2. .git ზრდის სურათის ზომას (საცავი შეიძლება იყოს დიდი იმის გამო, რომ მას ერთხელ დაემატა დიდი ფაილები და შემდეგ წაიშალა). სამუშაო ხის ზომა, რომელიც დაკავშირებულია მხოლოდ კონკრეტულ დავალებასთან, არ იქნება დამოკიდებული Git-ში ოპერაციების ისტორიაზე. ამ შემთხვევაში, დამატება და შემდგომი მოცილება .git საბოლოო სურათიდან არ იმუშავებს: სურათი მაინც შეიძენს დამატებით ფენას - ასე მუშაობს Docker.
3. Docker-ს შეუძლია წამოიწყოს არასაჭირო რეკონსტრუქცია, მაშინაც კი, თუ ერთი და იგივე კომიტი შენდება, მაგრამ სხვადასხვა სამუშაო ხეებიდან. მაგალითად, GitLab ქმნის ცალკეულ კლონირებულ დირექტორიაში /home/gitlab-runner/builds/HASH/[0-N]/yourproject როდესაც პარალელური შეკრება ჩართულია. დამატებითი ხელახალი შეკრება იქნება იმის გამო, რომ დირექტორია .git განსხვავებულია ერთი და იგივე საცავის სხვადასხვა კლონირებულ ვერსიებში, თუნდაც ერთი და იგივე commit აგებული.

ბოლო პუნქტს ასევე აქვს შედეგები werf-ის გამოყენებისას. Werf მოითხოვს ჩაშენებული ქეშის არსებობას ზოგიერთი ბრძანების გაშვებისას (მაგ. werf deploy). როდესაც ეს ბრძანებები გაშვებულია, werf ითვლის სტადიის ხელმოწერებს მითითებული სურათებისთვის werf.yaml, და ისინი უნდა იყოს ასამბლეის ქეშში - წინააღმდეგ შემთხვევაში ბრძანება ვერ გააგრძელებს მუშაობას. თუ სასცენო ხელმოწერა დამოკიდებულია შინაარსზე .git, მაშინ მივიღებთ ქეშს, რომელიც არასტაბილურია შეუსაბამო ფაილებში ცვლილებების მიმართ და werf ვერ აპატიებს ასეთ უგულებელყოფას (დამატებითი ინფორმაციისთვის იხ. დოკუმენტაცია).

ზოგადად, მხოლოდ გარკვეული საჭირო ფაილების დამატება ინსტრუქციის მეშვეობით ADD ნებისმიერ შემთხვევაში ზრდის ნაწერის ეფექტურობასა და სანდოობას Dockerfileდა ასევე აუმჯობესებს ამისთვის შეგროვებული ქეშის სტაბილურობას Dockerfile, Git-ში შეუსაბამო ცვლილებებზე.

სულ

ჩვენი საწყისი გზა კონკრეტული საჭიროებისთვის საკუთარი მშენებლის დასაწერად რთული, პატიოსანი და პირდაპირი იყო: სტანდარტული Dockerfile-ის თავზე ხელჯოხების გამოყენების ნაცვლად, ჩვენ დავწერეთ ჩვენი გამოსავალი მორგებული სინტაქსით. და ამას თავისი უპირატესობები ჰქონდა: Stapel-ის კოლექციონერი შესანიშნავად უმკლავდება თავის დავალებას.

თუმცა, ჩვენი საკუთარი მშენებლის დაწერის პროცესში, ჩვენ მხედველობიდან დავკარგეთ არსებული Dockerfiles-ის მხარდაჭერა. ეს ხარვეზი ახლა გამოსწორებულია და მომავალში ჩვენ ვგეგმავთ Dockerfile-ის მხარდაჭერის განვითარებას ჩვენს მორგებულ Stapel-ის შემქმნელთან ერთად განაწილებული ასამბლეის და კუბერნეტის გამოყენებით შეკრებისთვის (ანუ აწყობა მორბენალებზე Kubernetes-ში, როგორც ეს ხდება kaniko-ში).

ასე რომ, თუ თქვენ მოულოდნელად გაქვთ რამდენიმე Dockerfiles ირგვლივ... სცადეთ ვერფ!

PS თემაზე დოკუმენტაციის სია

• სახელმძღვანელო სწრაფი დაწყებისთვის;
• dockerfile შემქმნელის კონფიგურაციები;
• ეტაპების მოწყობილობა werf-ში;
• სურათის გამოქვეყნების პროცესი;
• ინტეგრაცია Kubernetes-ის განლაგების პროცესთან;
• დასუფთავების პროცესი;
• Stapel builder, როგორც Dockerfile-ის ალტერნატივა.

წაიკითხეთ ასევე ჩვენს ბლოგში: ”werf - ჩვენი ინსტრუმენტი CI / CD-სთვის Kubernetes-ში (მიმოხილვა და ვიდეო ანგარიში)".

წყარო: www.habr.com