CI/CD ჯაჭვის შექმნა და Docker-თან მუშაობის ავტომატიზაცია

ჩემი პირველი საიტები 90-იანი წლების ბოლოს დავწერე. მაშინ ძალიან ადვილი იყო მათი მუშა მდგომარეობაში მოყვანა. იყო Apache სერვერი ზოგიერთ საერთო ჰოსტინგზე, თქვენ შეგეძლოთ შეხვიდეთ ამ სერვერზე FTP-ის საშუალებით მსგავსი რამის დაწერით ftp://ftp.example.com. შემდეგ თქვენ უნდა შეიყვანოთ თქვენი სახელი და პაროლი და ატვირთოთ ფაილები სერვერზე. სხვადასხვა დრო იყო, მაშინ ყველაფერი უფრო მარტივი იყო, ვიდრე ახლა.

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

ჩემი პირადი პროექტისთვის მქონდა სპეციალური კონფიგურაცია. და ვიცოდი, რომ მჭირდებოდა საიტის წარმოებაში განლაგების შესაძლებლობა მხოლოდ ერთი მოქმედების შესრულებით: კოდის დაწერა ფილიალში master GitHub-ზე. გარდა ამისა, ვიცოდი, რომ ჩემი პატარა ვებ აპლიკაციის მუშაობის უზრუნველსაყოფად, არ მინდოდა მემართა უზარმაზარი Kubernetes კლასტერი, ან გამომეყენებინა Docker Swarm ტექნოლოგია, ან შემენარჩუნებინა სერვერების ფლოტი პოდებით, აგენტებით და სხვა სხვაობით. სირთულეები. იმისთვის, რომ მიმეღწია მიზნის მიღწევა, რომ მუშაობა მაქსიმალურად გაადვილებულიყო, დამჭირდა CI/CD-ის გაცნობა.

თუ თქვენ გაქვთ მცირე პროექტი (ამ შემთხვევაში, Node.js პროექტი) და გსურთ იცოდეთ როგორ მოახდინოთ ამ პროექტის განლაგების ავტომატიზაცია, იმავდროულად დარწმუნდით, რომ ის რაც ინახება საცავში ზუსტად ემთხვევა იმას, რაც მუშაობს წარმოებაში, მაშინ მე ფიქრობთ, რომ დაგაინტერესებთ ეს სტატია.

წინაპირობები

ამ სტატიის მკითხველს უნდა ჰქონდეს საბაზისო გაგება ბრძანების ხაზისა და Bash სკრიპტების დაწერის შესახებ. გარდა ამისა, მას დასჭირდება ანგარიშები ტრევის CI и დოკერის ცენტრი.

მიზნები

მე არ ვიტყვი, რომ ამ სტატიას უპირობოდ შეიძლება ეწოდოს "ტუტორიალი". ეს უფრო მეტად არის დოკუმენტი, რომელშიც მე ვსაუბრობ იმაზე, რაც ვისწავლე და აღვწერ იმ პროცესს, რომელიც მე ვარგა ტესტირებისა და კოდის წარმოებაში განსათავსებლად, რომელიც შესრულებულია ერთი ავტომატური პასით.

ეს არის ის, რაც ჩემი სამუშაო პროცესი დასრულდა.

ნებისმიერი საცავის ფილიალში განთავსებული კოდისთვის, გარდა master, ხორციელდება შემდეგი მოქმედებები:

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

მხოლოდ კოდისთვის, რომელიც შედის master, შესრულებულია შემდეგი:

• ყველაფერი ზემოთ ნახსენები, პლუს...
• დოკერის სურათის შექმნა მიმდინარე კოდზე, პარამეტრებზე და გარემოზე დაყრდნობით.
• სურათის განლაგება Docker Hub-ზე.
• კავშირი წარმოების სერვერთან.
• სურათის ატვირთვა Docker Hub-დან სერვერზე.
• მიმდინარე კონტეინერის გაჩერება და ახალი სურათის საფუძველზე ახლის დაწყება.

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

რა არის CI/CD?

აბრევიატურა CI/CD ნიშნავს "უწყვეტი ინტეგრაცია/უწყვეტი განლაგება".

▍ უწყვეტი ინტეგრაცია

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

▍ უწყვეტი განლაგება

უწყვეტი განლაგება არის კოდის ხშირი, ავტომატური განლაგება წარმოებაში. CI/CD აკრონიმის მეორე ნაწილი ზოგჯერ იწერება როგორც „უწყვეტი მიწოდება“. ეს ძირითადად იგივეა, რაც „უწყვეტი განლაგება“, მაგრამ „უწყვეტი მიწოდება“ გულისხმობს ცვლილებების ხელით დადასტურების აუცილებლობას პროექტის განლაგების პროცესის დაწყებამდე.

ნაცნობობა

აპლიკაციას, რომელსაც ვიყენებდი ამ ყველაფრის შესასწავლად, ჰქვია TakeNote. ეს არის ვებ პროექტი, რომელზეც მე ვმუშაობ, შექმნილია ჩანაწერების გასაკეთებლად. თავიდან ვცადე JAMStack-პროექტი, ან უბრალოდ წინა ვერსია სერვერის გარეშე, რათა ისარგებლოს სტანდარტული ჰოსტინგის და პროექტის განლაგების შესაძლებლობებით, რომელსაც ის გთავაზობთ Netlify. აპლიკაციის სირთულის მატებასთან ერთად, მე მჭირდებოდა მისი სერვერის ნაწილის შექმნა, რაც იმას ნიშნავდა, რომ მე უნდა ჩამომეყალიბებინა ჩემი საკუთარი სტრატეგია ავტომატური ინტეგრაციისა და პროექტის ავტომატური განლაგებისთვის.

ჩემს შემთხვევაში, აპლიკაცია არის Express სერვერი, რომელიც მუშაობს Node.js გარემოში, ემსახურება ერთგვერდიან React აპლიკაციას და მხარს უჭერს უსაფრთხო სერვერის API-ს. ეს არქიტექტურა მიჰყვება სტრატეგიას, რომელიც გვხვდება მოცემული სრული სტეკის ავტორიზაციის სახელმძღვანელო.

გავმართე კონსულტაცია მეგობარი, რომელიც ავტომატიზაციის ექსპერტია და ვკითხე, რა მჭირდებოდა, რომ ყველაფერი ისე მუშაობდეს, როგორც მე მინდოდა. მან მომცა იდეა იმის შესახებ, თუ როგორი უნდა იყოს ავტომატური სამუშაო პროცესი, რომელიც აღწერილია ამ სტატიის მიზნების განყოფილებაში. ამ მიზნების ქონა ნიშნავდა, რომ მჭირდებოდა გამეგო Docker-ის გამოყენება.

docker

Docker არის ინსტრუმენტი, რომელიც კონტეინერიზაციის ტექნოლოგიის წყალობით, საშუალებას აძლევს აპლიკაციებს ადვილად განაწილდეს, განლაგდეს და იმუშაოს იმავე გარემოში, მაშინაც კი, თუ თავად Docker პლატფორმა მუშაობს სხვადასხვა გარემოში. პირველ რიგში, მე მჭირდებოდა Docker ბრძანების ხაზის ხელსაწყოების (CLI) ხელში ჩაგდება. ინსტრუქცია Docker ინსტალაციის სახელმძღვანელოს არ შეიძლება ეწოდოს ძალიან მკაფიო და გასაგები, მაგრამ მისგან შეგიძლიათ გაიგოთ, რომ პირველი ინსტალაციის ნაბიჯის გადასადგმელად, თქვენ უნდა ჩამოტვირთოთ Docker Desktop (Mac ან Windows-ისთვის).

Docker Hub დაახლოებით იგივეა, რაც GitHub git საცავებისთვის, ან რეესტრისთვის npm JavaScript პაკეტებისთვის. ეს არის ონლაინ საცავი Docker სურათებისთვის. ეს არის ის, რასაც Docker Desktop უკავშირდება.

ასე რომ, იმისათვის, რომ დაიწყოთ Docker, თქვენ უნდა გააკეთოთ ორი რამ:

• უცნობია დოკერის სამუშაო მაგიდა.
• დარეგისტრირდით დოკერის ცენტრი.

ამის შემდეგ შეგიძლიათ შეამოწმოთ მუშაობს თუ არა Docker CLI შემდეგი ბრძანების გაშვებით Docker ვერსიის შესამოწმებლად:

docker -v

შემდეგი, შედით Docker Hub-ში თქვენი მომხმარებლის სახელისა და პაროლის შეყვანით, როდესაც გკითხავთ:

docker login

დოკერის გამოსაყენებლად, თქვენ უნდა გესმოდეთ სურათების და კონტეინერების ცნებები.

▍ სურათები

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

# Вывод сведений обо всех образах
docker images

ეს ბრძანება გამოსცემს ცხრილს შემდეგი სათაურით:

REPOSITORY     TAG     IMAGE ID     CREATED     SIZE
---

შემდეგ განვიხილავთ ბრძანებების რამდენიმე მაგალითს იმავე ფორმატში - ჯერ არის ბრძანება კომენტარით, შემდეგ კი მაგალითი იმისა, თუ რისი გამოტანა შეუძლია.

▍კონტეინერები

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

# Перечисление всех контейнеров
docker ps -a
CONTAINER ID     IMAGE     COMMAND     CREATED     STATUS     PORTS     NAMES
---

▍ ტეგები

ტეგი არის სურათის კონკრეტული ვერსიის მითითება.

▍ Docker ბრძანებების სწრაფი მითითება

აქ მოცემულია რამდენიმე ხშირად გამოყენებული Docker ბრძანების მიმოხილვა.

გუნდი

კონტექსტი

ეფექტი

დოკერის აშენება

გამოსახულება

სურათის აგება Dockerfile-დან

დოკერის ტეგი

გამოსახულება

სურათის მონიშვნა

docker სურათები

გამოსახულება

სურათების ჩამონათვალი

დოკერის გაშვება

კონტეინერი

კონტეინერის გაშვება გამოსახულების საფუძველზე

დოკერ ბიძგი

გამოსახულება

სურათის ატვირთვა რეესტრში

დოკერის მოზიდვა

გამოსახულება

სურათის ჩატვირთვა რეესტრიდან

დოკერი პს

კონტეინერი

კონტეინერების ჩამონათვალი

დოკერის სისტემის ქლიავი

სურათი/კონტეინერი

გამოუყენებელი კონტეინერების და სურათების ამოღება

▍დოკერფაილი

მე ვიცი, როგორ გავუშვა საწარმოო აპლიკაცია ადგილობრივად. მე მაქვს Webpack კონფიგურაცია, რომელიც შექმნილია მზა React აპლიკაციის შესაქმნელად. შემდეგი, მე მაქვს ბრძანება, რომელიც იწყებს Node.js-ზე დაფუძნებულ სერვერს პორტზე 5000. ეს ასე გამოიყურება:

npm i         # установка зависимостей
npm run build # сборка React-приложения
npm run start # запуск Node-сервера

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

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

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

• FROM — ეს ბრძანება იწყებს ფაილს. იგი განსაზღვრავს საბაზისო სურათს, რომელზედაც აგებულია კონტეინერი.
• კოპირება — ფაილების კოპირება ადგილობრივი წყაროდან კონტეინერში.
• WORKDIR — სამუშაო დირექტორიას დაყენება შემდეგი ბრძანებებისთვის.
• RUN - გაუშვით ბრძანებები.
• გამოაშკარავება - პორტის პარამეტრები.
• ᲨᲔᲡᲕᲚᲘᲡ ᲬᲔᲠᲢᲘᲚᲘ — აღსასრულებელი ბრძანების მითითება.

Dockerfile შეიძლება ასე გამოიყურებოდეს:

# Загрузить базовый образ
FROM node:12-alpine

# Скопировать файлы из текущей директории в директорию app/
COPY . app/

# Использовать app/ в роли рабочей директории
WORKDIR app/

# Установить зависимости (команда npm ci похожа npm i, но используется для автоматизированных сборок)
RUN npm ci --only-production

# Собрать клиентское React-приложение для продакшна
RUN npm run build

# Прослушивать указанный порт
EXPOSE 5000

# Запустить Node-сервер
ENTRYPOINT npm run start

თქვენ მიერ არჩეული საბაზისო სურათიდან გამომდინარე, შეიძლება დაგჭირდეთ დამატებითი დამოკიდებულებების დაყენება. ფაქტია, რომ ზოგიერთი ძირითადი სურათი (როგორიცაა Node Alpine Linux) იქმნება იმ მიზნით, რომ ისინი მაქსიმალურად კომპაქტური იყოს. შედეგად, მათ შეიძლება არ ჰქონდეთ ზოგიერთი პროგრამა, რომელსაც თქვენ მოელით.

▍კონტეინერის აგება, მონიშვნა და გაშვება

კონტეინერის ლოკალური აწყობა და გაშვება ხდება მას შემდეგ, რაც გვაქვს Dockerfile, ამოცანები საკმაოდ მარტივია. სანამ სურათს Docker Hub-ზე გადააყენებთ, თქვენ უნდა შეამოწმოთ იგი ადგილობრივად.

▍შეკრება

ჯერ უნდა შეაგროვოთ გამოსახულება, სახელის და, სურვილისამებრ, ტეგის მითითებით (თუ ტეგი არ არის მითითებული, სისტემა ავტომატურად მიანიჭებს ტეგს სურათს latest).

# Сборка образа
docker build -t <image>:<tag> .

ამ ბრძანების გაშვების შემდეგ, შეგიძლიათ უყუროთ Docker-ის სურათს.

Sending build context to Docker daemon   2.88MB
Step 1/9 : FROM node:12-alpine
 ---> ...выполнение этапов сборки...
Successfully built 123456789123
Successfully tagged <image>:<tag>

მშენებლობას შეიძლება რამდენიმე წუთი დასჭირდეს - ეს ყველაფერი დამოკიდებულია იმაზე, თუ რამდენი დამოკიდებულება გაქვთ. მშენებლობის დასრულების შემდეგ, შეგიძლიათ გაუშვათ ბრძანება docker images და შეხედეთ თქვენი ახალი სურათის აღწერას.

REPOSITORY          TAG               IMAGE ID            CREATED              SIZE
<image>             latest            123456789123        About a minute ago   x.xxGB

▍გაშვება

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

# Запуск с использованием локального порта 5000 и порта контейнера 5000
docker run -p 5000:5000 <image>:<tag>

ახლა, როდესაც კონტეინერი შეიქმნა და მუშაობს, შეგიძლიათ გამოიყენოთ ბრძანება docker ps დაათვალიერეთ ინფორმაცია ამ კონტეინერის შესახებ (ან შეგიძლიათ გამოიყენოთ ბრძანება docker ps -a, რომელიც აჩვენებს ინფორმაციას ყველა კონტეინერზე და არა მხოლოდ გაშვებულზე).

CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                      PORTS                    NAMES
987654321234        <image>             "/bin/sh -c 'npm run…"   6 seconds ago        Up 6 seconds                0.0.0.0:5000->5000/tcp   stoic_darwin

თუ ახლა გადადით მისამართზე localhost:5000 — შეგიძლიათ ნახოთ გაშვებული აპლიკაციის გვერდი, რომელიც ზუსტად ისე გამოიყურება, როგორც საწარმოო გარემოში გაშვებული აპლიკაციის გვერდი.

▍ მონიშვნა და გამოქვეყნება

იმისათვის, რომ გამოვიყენოთ ერთ-ერთი შექმნილი სურათი წარმოების სერვერზე, ჩვენ უნდა შევძლოთ ამ სურათის ჩამოტვირთვა Docker Hub-დან. ეს ნიშნავს, რომ თქვენ ჯერ უნდა შექმნათ საცავი პროექტისთვის Docker Hub-ზე. ამის შემდეგ გვექნება ადგილი, სადაც შეგვიძლია გამოვაგზავნოთ სურათი. სურათს უნდა დაერქვას სახელი ისე, რომ მისი სახელი დაიწყოს ჩვენი Docker Hub მომხმარებლის სახელით. ამას უნდა მოჰყვეს საცავის სახელი. ნებისმიერი ტეგი შეიძლება განთავსდეს სახელის ბოლოს. ქვემოთ მოცემულია ამ სქემის გამოყენებით სურათების დასახელების მაგალითი.

ახლა თქვენ შეგიძლიათ შექმნათ სურათი ახალი სახელით და გაუშვათ ბრძანება docker push Docker Hub-ის საცავში გადასატანად.

docker build -t <username>/<repository>:<tag> .
docker tag <username>/<repository>:<tag> <username>/<repository>:latest
docker push <username>/<repository>:<tag>

# На практике это может выглядеть, например, так:
docker build -t user/app:v1.0.0 .
docker tag user/app:v1.0.0 user/app:latest
docker push user/app:v1.0.0

თუ ყველაფერი კარგად წავა, სურათი ხელმისაწვდომი იქნება Docker Hub-ზე და მისი მარტივად ატვირთვა სერვერზე ან სხვა დეველოპერებზე გადატანა იქნება შესაძლებელი.

შემდეგი ნაბიჯები

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

• CI ინსტრუმენტის დაყენება კოდის ტესტირებისა და განლაგებისთვის.
• წარმოების სერვერის დაყენება ისე, რომ მან შეძლოს ჩვენი კოდის ჩამოტვირთვა და გაშვება.

ჩვენს შემთხვევაში, ჩვენ ვიყენებთ ტრევის CI. როგორც სერვერი - DitigalOcean.

უნდა აღინიშნოს, რომ აქ შეგიძლიათ ისარგებლოთ სერვისების სხვა კომბინაციით. მაგალითად, Travis CI-ის ნაცვლად, შეგიძლიათ გამოიყენოთ CircleCI ან Github Actions. და ნაცვლად DigitalOcean - AWS ან Linode.

ჩვენ გადავწყვიტეთ მუშაობა Travis CI-თან და მე უკვე მაქვს რაღაც კონფიგურირებული ამ სერვისში. ამიტომ, ახლა მოკლედ ვისაუბრებ იმაზე, თუ როგორ მოვამზადოთ იგი სამუშაოდ.

ტრევის CI

Travis CI არის კოდის ტესტირებისა და განლაგების ინსტრუმენტი. მე არ მსურს Travis CI-ის დაყენების სირთულეებში შემოსვლა, რადგან თითოეული პროექტი უნიკალურია და ეს დიდ სარგებელს არ მოიტანს. მაგრამ მე გავაშუქებ საფუძვლებს, რომ დაიწყოთ, თუ გადაწყვეტთ გამოიყენოთ Travis CI. აირჩევთ თუ არა Travis CI-ს, CircleCI-ს, Jenkins-ს თუ სხვა რამეს, მსგავსი კონფიგურაციის მეთოდები ყველგან იქნება გამოყენებული.

Travis CI-ის დასაწყებად გადადით საიტის პროექტი და შექმენით ანგარიში. შემდეგ გააერთიანეთ Travis CI თქვენს GitHub ანგარიშთან. სისტემის დაყენებისას, თქვენ უნდა მიუთითოთ საცავი, რომლითაც გსურთ მუშაობის ავტომატიზაცია და მასზე წვდომის ჩართვა. (მე ვიყენებ GitHub-ს, მაგრამ დარწმუნებული ვარ, რომ Travis CI-ს შეუძლია ინტეგრირება BitBucket-თან და GitLab-თან და სხვა მსგავს სერვისებთან).

ყოველ ჯერზე Travis CI-ის გაშვებისას, სერვერი იხსნება, რომელიც ასრულებს კონფიგურაციის ფაილში მითითებულ ბრძანებებს, მათ შორის შესაბამისი საცავის ფილიალების განლაგებას.

▍სამუშაო ცხოვრების ციკლი

გამოიძახა Travis CI კონფიგურაციის ფაილი .travis.yml და ინახება პროექტის root დირექტორიაში, მხარს უჭერს მოვლენების კონცეფციას ცხოვრების ციკლი დავალებები. ეს მოვლენები ჩამოთვლილია იმ თანმიმდევრობით, რომლითაც ისინი ხდება:

• apt addons
• cache components
• before_install
• install
• before_script
• script
• before_cache
• after_success или after_failure
• before_deploy
• deploy
• after_deploy
• after_script

▍ ტესტირება

კონფიგურაციის ფაილში ვაპირებ ადგილობრივი Travis CI სერვერის კონფიგურაციას. მე ავირჩიე Node 12 ენად და ვუთხარი სისტემას, დაეყენებინა Docker-ის გამოსაყენებლად საჭირო დამოკიდებულებები.

ყველაფერი რაც ჩამოთვლილია .travis.yml, შესრულდება, როდესაც ყველა pull მოთხოვნა განხორციელდება საცავის ყველა ფილიალში, თუ სხვა რამ არ არის მითითებული. ეს არის სასარგებლო ფუნქცია, რადგან ეს ნიშნავს, რომ ჩვენ შეგვიძლია შევამოწმოთ ყველა კოდი, რომელიც შედის საცავში. ეს გაცნობებთ, არის თუ არა კოდი მზად ფილიალში ჩასაწერად. masterდა დაარღვევს თუ არა ეს პროექტის მშენებლობის პროცესს. ამ გლობალურ კონფიგურაციაში მე ყველაფერს ვაინსტალირებ ადგილობრივად, ვმართავ Webpack dev სერვერს ფონზე (ეს არის ჩემი სამუშაო პროცესის მახასიათებელი) და ვაწარმოებ ტესტებს.

თუ გსურთ, რომ თქვენს საცავში გამოჩნდეს სამკერდე ნიშნები, რომლებიც მიუთითებს ტესტის დაფარვის შესახებ, აქ შეგიძლიათ იპოვოთ მოკლე ინსტრუქციები Jest-ის, Travis CI-ისა და კომბინეზონების გამოყენების შესახებ ამ ინფორმაციის შეგროვებისა და ჩვენების მიზნით.

ასე რომ, აქ არის ფაილის შინაარსი .travis.yml:

# Установить язык
language: node_js

# Установить версию Node.js
node_js:
  - '12'

services:
  # Использовать командную строку Docker
  - docker

install:
  # Установить зависимости для тестов
  - npm ci

before_script:
  # Запустить сервер и клиент для тестов
  - npm run dev &

script:
  # Запустить тесты
  - npm run test

აქ მთავრდება მოქმედებები, რომლებიც შესრულებულია საცავის ყველა ფილიალისთვის და pull-მოთხოვნებისთვის.

▍ განლაგება

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

deploy:
  # Собрать Docker-контейнер и отправить его на Docker Hub
  provider: script
  script: bash deploy.sh
  on:
    branch: master

განლაგების სკრიპტი წყვეტს ორ პრობლემას:

• შექმენით, მონიშნეთ და გაგზავნეთ სურათი Docker Hub-ში CI ინსტრუმენტის გამოყენებით (ჩვენს შემთხვევაში, Travis CI).
• სურათის სერვერზე ჩატვირთვა, ძველი კონტეინერის გაჩერება და ახლის გაშვება (ჩვენს შემთხვევაში, სერვერი მუშაობს DigitalOcean პლატფორმაზე).

პირველ რიგში, თქვენ უნდა დააყენოთ ავტომატური პროცესი სურათის შექმნის, მონიშვნისა და Docker Hub-ზე გადასატანად. ეს ყველაფერი ძალიან ჰგავს იმას, რაც ჩვენ უკვე გავაკეთეთ ხელით, გარდა იმისა, რომ გვჭირდება სტრატეგია სურათებისთვის უნიკალური ტეგების მინიჭებისთვის და შესვლის ავტომატიზაციისთვის. გამიჭირდა განლაგების სკრიპტის ზოგიერთი დეტალი, როგორიცაა მონიშვნის სტრატეგია, შესვლა, SSH გასაღების კოდირება, SSH კავშირის დამყარება. მაგრამ საბედნიეროდ, ჩემი მეგობარი ბიჭი ძალიან კარგად ერკვევა ბაშთან, ისევე როგორც ბევრ სხვა რამეში. ის დამეხმარა ამ სცენარის დაწერაში.

ასე რომ, სკრიპტის პირველი ნაწილი არის სურათის ატვირთვა Docker Hub-ზე. ამის გაკეთება საკმაოდ მარტივია. თეგირების სქემა, რომელიც მე გამოვიყენე, მოიცავს git hash-ისა და git tag-ის გაერთიანებას, თუ ასეთი არსებობს. ეს უზრუნველყოფს, რომ ტეგი უნიკალურია და აადვილებს ასამბლეის იდენტიფიცირებას, რომელზეც ის დაფუძნებულია. DOCKER_USERNAME и DOCKER_PASSWORD არის მომხმარებლის გარემოს ცვლადები, რომელთა დაყენება შესაძლებელია Travis CI ინტერფეისის გამოყენებით. Travis CI ავტომატურად დაამუშავებს სენსიტიურ მონაცემებს, რათა ის არასწორ ხელში არ მოხვდეს.

აქ არის სცენარის პირველი ნაწილი deploy.sh.

#!/bin/sh
set -e # Остановить скрипт при наличии ошибок

IMAGE="<username>/<repository>"                             # Образ Docker
GIT_VERSION=$(git describe --always --abbrev --tags --long) # Git-хэш и теги

# Сборка и тегирование образа
docker build -t ${IMAGE}:${GIT_VERSION} .
docker tag ${IMAGE}:${GIT_VERSION} ${IMAGE}:latest

# Вход в Docker Hub и выгрузка образа
echo "${DOCKER_PASSWORD}" | docker login -u "${DOCKER_USERNAME}" --password-stdin
docker push ${IMAGE}:${GIT_VERSION}

რა იქნება სკრიპტის მეორე ნაწილი, მთლიანად დამოკიდებულია იმაზე, თუ რომელ ჰოსტს იყენებთ და როგორ არის ორგანიზებული მასთან კავშირი. ჩემს შემთხვევაში, რადგან ვიყენებ Digital Ocean-ს, ვიყენებ ბრძანებებს სერვერთან დასაკავშირებლად დოქტლ. AWS-თან მუშაობისას გამოყენებული იქნება პროგრამა aws, და ასე შემდეგ.

სერვერის დაყენება არ იყო განსაკუთრებით რთული. ასე რომ, მე დავაყენე წვეთი ბაზის გამოსახულების საფუძველზე. უნდა აღინიშნოს, რომ ჩემს მიერ არჩეული სისტემა მოითხოვს Docker-ის ერთჯერადი ხელით ინსტალაციას და Docker-ის ერთჯერადი ხელით გაშვებას. მე გამოვიყენე Ubuntu 18.04 Docker-ის დასაყენებლად, ასე რომ, თუ თქვენ ასევე იყენებთ Ubuntu-ს იგივეს გასაკეთებლად, შეგიძლიათ უბრალოდ მიჰყვეთ ამ მარტივი სახელმძღვანელო.

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

• ჩვენ უნდა ვიპოვოთ კონტეინერი, რომელიც ამჟამად მუშაობს და გავაჩეროთ იგი.
• შემდეგ თქვენ უნდა გაუშვათ ახალი კონტეინერი ფონზე.
• თქვენ უნდა დააყენოთ სერვერის ლოკალური პორტი 80 - ეს საშუალებას მოგცემთ შეხვიდეთ საიტზე ისეთი მისამართით, როგორიცაა example.com, პორტის მითითების გარეშე, ვიდრე მსგავსი მისამართის გამოყენებით example.com:5000.
• და ბოლოს, თქვენ უნდა წაშალოთ ყველა ძველი კონტეინერი და სურათი.

აქ არის სცენარის გაგრძელება.

# Найти ID работающего контейнера
CONTAINER_ID=$(docker ps | grep takenote | cut -d" " -f1)

# Остановить старый контейнер, запустить новый, очистить систему
docker stop ${CONTAINER_ID}
docker run --restart unless-stopped -d -p 80:5000 ${IMAGE}:${GIT_VERSION}
docker system prune -a -f

ზოგიერთი რამ, რასაც ყურადღება უნდა მიაქციოთ

შესაძლებელია, რომ როდესაც თქვენ დაუკავშირდებით სერვერს SSH-ის მეშვეობით Travis CI-დან, იხილავთ გაფრთხილებას, რომელიც ხელს შეგიშლით ინსტალაციის გაგრძელებაში, რადგან სისტემა დაელოდება მომხმარებლის პასუხს.

The authenticity of host '<hostname> (<IP address>)' can't be established.
RSA key fingerprint is <key fingerprint>.
Are you sure you want to continue connecting (yes/no)?

გავიგე, რომ სიმებიანი კლავიშის დაშიფვრა შესაძლებელია base64-ში, რათა შეინახოს ის ისე, რომ მოხერხებულად და საიმედოდ იმუშაოს. ინსტალაციის ეტაპზე შეგიძლიათ საჯარო გასაღების გაშიფვრა და ფაილში ჩაწერა known_hosts ზემოაღნიშნული შეცდომისგან თავის დასაღწევად.

echo <public key> | base64 # выводит <публичный ключ, закодированный в base64>

პრაქტიკაში, ეს ბრძანება შეიძლება ასე გამოიყურებოდეს:

echo "123.45.67.89 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== [email protected]" | base64

და აი, რას აწარმოებს ის - base64 კოდირებული სტრიქონი:

MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQwMVFyYVRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==

აქ არის ზემოთ ნახსენები ბრძანება

install:
  - echo < публичный ключ, закодированный в base64> | base64 -d >> $HOME/.ssh/known_hosts

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

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

doctl compute ssh <droplet> --ssh-command "все команды будут здесь && здесь"

TLS/SSL და დატვირთვის ბალანსირება

მას შემდეგ რაც გავაკეთე ყველაფერი, რაც ზემოთ იყო ნახსენები, ბოლო პრობლემა, რაც დამხვდა იყო ის, რომ სერვერს არ ჰქონდა SSL. მას შემდეგ, რაც მე ვიყენებ Node.js სერვერს, იძულების მიზნით მუშაობა საპირისპირო პროქსი Nginx და Let's Encrypt, თქვენ ბევრი რამის გაკეთება გჭირდებათ.

მე ნამდვილად არ მინდოდა მთელი ამ SSL კონფიგურაციის ხელით გაკეთება, ამიტომ უბრალოდ შევქმენი დატვირთვის ბალანსერი და ჩავწერე მისი დეტალები DNS-ში. მაგალითად, DigitalOcean-ის შემთხვევაში, დატვირთვის ბალანსერზე ავტომატური განახლების ხელმოწერილი სერტიფიკატის შექმნა მარტივი, უფასო და სწრაფი პროცედურაა. ამ მიდგომას აქვს დამატებითი სარგებელი, რომ ის ძალიან აადვილებს SSL-ის დაყენებას მრავალ სერვერზე, რომელიც მუშაობს დატვირთვის ბალანსერის უკან, საჭიროების შემთხვევაში. ეს საშუალებას აძლევს თავად სერვერებს საერთოდ არ "იფიქრონ" SSL-ზე, მაგრამ ამავე დროს გამოიყენონ პორტი, როგორც ყოველთვის. 80. ასე რომ, SSL-ის დაყენება დატვირთვის ბალანსერზე ბევრად უფრო ადვილი და მოსახერხებელია, ვიდრე SSL-ის დაყენების ალტერნატიული მეთოდები.

ახლა თქვენ შეგიძლიათ დახუროთ ყველა პორტი სერვერზე, რომელიც იღებს შემომავალ კავშირებს - გარდა პორტისა 80, გამოიყენება დატვირთვის ბალანსერთან და პორტთან კომუნიკაციისთვის 22 SSH-სთვის. შედეგად, სერვერზე პირდაპირ წვდომის მცდელობა ამ ორის გარდა სხვა პორტებზე ვერ მოხერხდება.

შედეგები

მას შემდეგ რაც გავაკეთე ყველაფერი, რაზეც ამ მასალაში ვისაუბრე, არც Docker პლატფორმა და არც ავტომატური CI/CD ჯაჭვების კონცეფციები აღარ შემაშინებდა. მე შევძელი უწყვეტი ინტეგრაციის ჯაჭვის დაყენება, რომლის დროსაც კოდის ტესტირება ხდება წარმოებაში შესვლამდე და კოდი ავტომატურად განლაგდება სერვერზე. ეს ყველაფერი ჩემთვის ჯერ კიდევ შედარებით ახალია და დარწმუნებული ვარ, არსებობს გზები, რომ გავაუმჯობესო ჩემი ავტომატური სამუშაო ნაკადი და გავხადო ის უფრო ეფექტური. ასე რომ, თუ თქვენ გაქვთ რაიმე იდეა ამ საკითხთან დაკავშირებით, გთხოვთ შემატყობინოთ. me ვიცი. იმედი მაქვს, რომ ეს სტატია დაგეხმარა თქვენს მცდელობებში. მინდა მჯეროდეს, რომ მისი წაკითხვის შემდეგ თქვენ ისწავლეთ იმდენი, რამდენიც მე ვისწავლე ყველაფრის გარჩევისას, რაზეც მასში ვისაუბრე.

PS ჩვენს ბაზარი არის სურათი docker, რომლის დაყენება შესაძლებელია ერთი დაწკაპუნებით. კონტეინერების მუშაობის შემოწმება შეგიძლიათ აქ VPS. ყველა ახალ კლიენტს ეძლევა 3 დღიანი ტესტირება უფასოდ.

ძვირფასო მკითხველს! იყენებთ CI/CD ტექნოლოგიებს თქვენს პროექტებში?

წყარო: www.habr.com