Mən 90-cı illərin sonunda ilk veb saytlarımı yaratdım. O zaman onları işə salmaq çox asan idi. Ümumi hostinqdə bir Apache serveri var idi, bu serverə FTP ilə daxil olmaq üçün brauzer ünvan çubuğuna belə bir şey yazmaq kifayət edirdi ftp://ftp.example.com. Sonra istifadəçi adı və parolu daxil edib faylları serverə yükləmək lazım idi. O dövrlər daha asan idi, hər şey indi olduğundan daha sadə idi.
Son iki onillik ərzində hər şey xeyli dəyişdi. Veb saytlar daha mürəkkəb oldu, istehsalda buraxmazdan əvvəl onları toplamaq lazım idi. Tək bir server əvəzinə, yük balanslaşdırıcılarla işləyən bir çox server gündəlik hala gəldi, versiya nəzarət sistemlərinin istifadəsi isə adi bir şey oldu.
Şəxsi layihəm üçün özəl bir konfiqurasiya var idi. Və mən bilirdim ki, kodu yalnız bir əməliyyatla istehsalda yerləşdirməyə ehtiyacım var: kodu master GitHub-dakı bir budağa yazmaq. Bundan əlavə, mən bilirdim ki, kiçik veb tətbiqimin işləməsini təmin etmək üçün böyük Kubernetes klasterini idarə etmək, Docker Swarm texnologiyasından istifadə etmək və ya podlar, agentlər və digər mürəkkəbliklərlə server parkını dəstəkləmək istəmirəm. İşimi maksimum dərəcədə sadələşdirmək məqsədinə nail olmaq üçün CI/CD ilə tanış olmalı oldum.
Kiçik bir layihəniz varsa (bizim halımızda, Node.js layihəsi nəzərdə tutulur) və bu layihənin yayımını avtomatlaşdırmanın yollarını öyrənmək istəyirsinizsə, eyni zamanda repositordakıların istehsalda çalışanlarla tam uyğun gəlməsini istəyirsinizsə, bu məqalə sizi maraqlandıra bilər.
Əvvəlki tələblər
Bu məqalənin oxuyucusunun komandalar xəttindən istifadə etmək və Bash skriptləri yazma sahəsində əsas biliklərə sahib olduğu gözlənilir. Həmçinin, ona və .
Məqsədlər
Bu məqaləni mütləq "öyrədici bələdçi" adlandırmağımı deməzdim. Bu, daha çox öyrəndiklərimi paylaşdığım və kodu istehsalda bir avtomatlaşdırılmış proseslə yerləşdirmək üçün istifadə etdiyim prosesi təsvir etdiyim bir sənəddir.
Nəticədə iş prosesi belə oldu.
Repositordakı hər hansı bir budağa göndərilən kod üçün, masterbu addımlar atılır:
- Travis CI-də layihənin yığılması başladılır.
- Bütün modul, inteqrasiya və tam sınaqlar yerinə yetirilir.
Yalnız masterbudağına düşən kod üçün, aşağıdakı baş verir:
- Yuxarıda qeyd olunanlar, plus…
- Mövcud koda, parametrlərə və mühitə əsaslanan Docker imicinin yığılması.
- Docker Hub-da imicin yerləşdirilməsi.
- İstehsal serverinə qoşulma.
- Docker Hub-dan serverə imici yükləmə.
- Mövcud konteynerin dayandırılması və yeni imicə əsaslanan yeni konteynerin işə salınması.
Docker haqqında, imiclər və konteynerlər barədə heç bir şey bilirsinizsə — narahat olmayın. Mən sizə hər şeyi izah edəcəyəm.
CI/CD nədir?
CI/CD abbreviaturası "davamlı inteqrasiya / davamlı yerləşdirmə" olaraq tərcümə olunur.
▍Davamlı inteqrasiya
Davamlı inteqrasiya — proqramçılar proyektin əsas kod anbarına (adətən, qovluğa) commit edərkən baş verən bir prosesdir. master). Kodun keyfiyyəti avtomatlaşdırılmış testlərin aparılması ilə təmin edilir.
▍Davamlı yerləşdirmə
Davamlı yerləşdirmə — kodu istehsalda tez-tez avtomatlaşdırılmış şəkildə yerləşdirməkdir. CI/CD abbreviaturasının ikinci hissəsi bəzən "davamlı çatdırılma" ("continuous delivery") olaraq da açıqlanır. Bu, əsasən, "davamlı yerləşdirmə" ilə eynidir, ancaq "davamlı çatdırılma" dəyişikliklərin yerləşdirilməsi prosesini başlamaq üçün əl ilə təsdiq edilməsini tələb edir.
Başlamaq
Mən bunun hamısını öyrəndiyim tətbiq, adlanır. Bu — qeydlər aparmaq üçün nəzərdə tutulmuş veb layihədir. Əvvəlcə mən - layihə və ya yalnız serversiz frontend tətbiqi yaratmağa çalışdım, bununla birgə tərəfindən təqdim edilən standart yerləşdirmə və yerləşdirmə imkanlarından istifadə etmək üçün.
Layihənin mürəkkəbliyi artdıqca, mən onun server tərəfini də yaratmalı oldum, bu da mənim üçün proyektin avtomatlaşdırılmış inteqrasiya və yerləşdirmə strategiyasını formalaşdırmağı tələb edirdi. bu
tam yumşaq autentifikasiya bələdçisi. bir dostumla görüşdüm, o, avtomatlaşma üzrə mütəxəssisdir, və ona lazım olan hər şeyi necə etməli olduğum barədə soruşdum. O, bu məqalənin "Məqsədlər" bölməsində ətraflı yazılmış avtomatlaşdırılmış iş prosesi ilə bağlı məsləhət verdi. Belə məqsədlər qoymağım, Docker-dan necə istifadə edəcəyimi anlamağım lazım olduğunu göstərdi.
Docker
Docker — konteyner texnologiyası sayəsində tətbiqləri asanlıqla yaymağa, habelə eyni mühitdə yerləşdirmək və işə salmaq üçün bir vasitədir, hətta Docker platforması fərqli mühitlərdə işləsə belə. Başlamaq üçün mənə Docker CLI alətləri lazımdır. Docker-in quraşdırılması çox aydın və başa düşülən deyil, lakin ilk quraşdırma addımı olaraq Docker Desktop-u (Mac və ya Windows üçün) yükləmək lazım olduğunu öyrənmək mümkündür.
Docker Hub – təxminən bununla eynidir git depozitləri üçün, yaxud JavaScript paketləri üçün. Bu, Docker obrazları üçün onlayn depozitdir. Məhz buraya Docker Desktop qoşulur.
Beləliklə, Docker ilə işləməyə başlamaq üçün iki şey etmək lazımdır:
- Quraşdırın .
- Docker Hub-da qeydiyyatdan keçin .
Bundan sonra, Docker versiyasını yoxlamaq üçün aşağıdakı əmri icra edərək Docker CLI-nin işlədiyini yoxlaya bilərsiniz:
docker -vSonra, sizdən soruşulduqda Docker Hub-a daxil olun, istifadəçi adınızı və şifrənizi daxil edin:
docker loginDocker-dan istifadə etmək üçün şəkil və konteyner anlayışlarını başa düşməlisiniz.
▍Şəkillər
Şəkil – konteynerin qurulması üçün təlimatları özündə saxlayan bir növ plan. Bu, dəyişməz bir fayl sistemi və tətbiqetmə konfiqurasiyalarının görüntüsüdür. İnkişaf etdiricilər şəkillərini asanlıqla paylaşa bilərlər.
# Вывод сведений обо всех образах
docker imagesBu əmr aşağıdakı başlıqla bir cədvəl çıxaracaq:
REPOSITORY TAG IMAGE ID CREATED SIZE
---Daha sonra, bəzi əmr nümunələrini eyni formatda nəzərdən keçirəcəyik – əvvəlcə əmr, ardından isə onun çıxara biləcəyi nümunə.
▍Konteynerlər
Konteyner – tətbiqi icra etmək üçün lazım olan hər şeyi özündə saxlayan icra paketidir. Belə yanaşma ilə tətbiq hər zaman eyni şəkildə işləyəcək, infrastrukturdan asılı olmayaraq: izolyasiya edilmiş mühitdə və eyni mühitdə. Burada söhbət eyni şəkilin fərqli mühitlərdə işə salınan nüsxələri haqqındadır.
# Перечисление всех контейнеров
docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
---▍Etiketlər
Etiket – bir şəkilin konkret versiyasına işarədir.
▍Docker əmrləri üzrə qısa bələdçi
Budur, tez-tez istifadə olunan bəzi Docker əmrlərinin icmalı.
Əmr
Kontekst
Fəaliyyət
Şəkil
Dockerfile-dan şəkil yaratmaq
Şəkil
Şəkilin etiketlənməsi
Şəkil
Şəkillərin siyahısını çıxarmaq
Konteyner
Şəkil əsasında konteynerin işə salınması
Şəkil
Şəkilin depozitə göndərilməsi
Şəkil
Depozitdən şəkilin yüklənməsi
Konteyner
Konteynerlərin siyahısını çıxarmaq
Şəkil/Konteyner
İstifadə olunmayan konteynerlərin və şəkillərin silinməsi
▍Dockerfile faylı
Mən yerli mühitdə istehsal üçün tətbiqi işə salmağı bilirəm. Mənim React tətbiqi üçün hazırlanmış bir Webpack konfiqurasiyam var. Sonra, portda Node.js-a əsaslanan serveri işə salan bir əmr var 5000. Bu belə görünür:
npm i # asılılıqları quraşdırmaq
npm run build # React tətbiqini qurmaq
npm run start # Node serverini işə salmaqQeyd etmək lazımdır ki, bu material üçün bir nümunə tətbiqim yoxdur. Lakin burada, eksperimentlər üçün sadə bir Node tətbiqi də uyğundur.
Konteynerdən istifadə etmək üçün Docker-a təlimat verməlisiniz. Bu, adlanan bir fayl vasitəsilə edilir. Dockerfile, layihənin kök dizinində olan. Bu fayl, əvvəlcə, olduqca anlaşılmaz görünsə də, içindəki məlumatlar, xüsusi əmrlərlə, iş mühitinin konfiqurasiyasına bənzər bir şeyi təsvir edir. Budur, bunlardan bəziləri:
— Bu əmr faylı başlayır. Burada, konteynerin təsis edildiyi əsas görüntü göstərilir.
- COPY
- WORKDIR
- RUN
- EXPOSE
- ENTRYPOINT
- bunun kimi görünə bilər:
Dockerfile Seçilmiş əsas görüntüdən asılı olaraq, əlavə asılılıqları qura bilmək lazımdır. Bəzi əsas görüntülər (məsələn, Node Alpine Linux) mümkün qədər kompakt olma məqsədilə yaradılmışdır. Nəticədə, gözlədiyiniz bəzi proqramlar onlarda olmaya bilər.
# Загрузить базовый образ
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▍Konteynerin yığılması, etiketlənməsi və işə salınması
Yerli konteynerin yığılması və işə salınması — bizdə var olduğuna görə
, vəzifələr olduqca sadədir. Docker Hub-a görüntünü göndərmədən əvvəl, onu yerli olaraq test etmək lazımdır. Dockerfile▍Yığma
Əvvəlcə yığmaq lazımdır
, adını göstərəcəyik və, istəyə bağlı olaraq, etiket (əgər etiket təyin edilməsə, sistem görüntüyə avtomatik olaraq bir etiket təyin edəcək) Bu əmr yerinə yetirildikdən sonra, Docker-in görüntü yığımı necə həyata keçirdiyini görmək mümkündür. latest).
# Сборка образа
docker build -t <image>:<tag> .Təqdim edilən yığma kontekstini Docker daemon-a göndərir 2.88MB Adım 1/9 : FROM node:12-alpine ---> ...yığma mərhələlərinin icrası... Başarıyla 123456789123 quraşdırılmışdır Başarıyla etiketlənmişdir <image>:<tag>
Yığma bir neçə dəqiqə çəkə bilər — burası asılılıqlarınızın sayından asılıdır. Yığma tamamlandıqdan sonra, əmrini icra edə bilərsiniz və yeni görüntünüz haqqında məlumatlara baxa bilərsiniz. docker images REPOSITORY TAG IMAGE ID CREATED SIZE <image> latest 123456789123 Təxminən bir dəqiqə əvvəl x.xxGB
▍İşə salmaGörüntü yaradıldı. Bu, onun əsasında konteyneri işə salmağın mümkün olduğunu göstərir. Mən, konteynerdə çalışan tətbiqə müraciət etmək imkanımın olmasını istəyirəm, buna görə də
localhost:5000 , mən, cütün sol tərəfindənövbəti əmrində qurdum 5000:5000 . Sağ tərəfində konteynerin portu var. 5000İndi, konteyner yaradılıb və işə salındıqdan sonra, bir komutundan istifadə edərək
# Запуск с использованием локального порта 5000 и порта контейнера 5000
docker run -p 5000:5000 <image>:<tag> bu konteyner haqqında məlumatlara baxa bilərsiniz (ya da yalnız işlək olanları deyil, bütün konteynerlər haqqında məlumat verən docker ps docker ps -a komutundan istifadə edə bilərsiniz).CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 987654321234 <image> "\/bin\/sh -c 'npm run…" 6 saniyə əvvəl 6 saniyədir 0.0.0.0:5000->5000\/tcp stoic_darwin
İndi bu ünvanı ziyarət etsəniz Если перейти теперь по адресу , mən, cütün sol tərəfində — bir istehsal mühitində işləyən tətbiqin səhifəsi ilə tamamilə eyni görünən işləyən tətbiqin səhifəsini görə biləcəksiniz.
▍Etiketin təyini və dərc edilməsi
İstehsal serverində yaradılmış image-lərdən biri ilə istifadə etmək üçün əvvəlcə Docker Hub-da layihə üçün bir depo yaradılmalıdır. Bu, ilkin olaraq image-i göndərmək üçün bir yerin yaradılması deməkdir. Image adını istifadəçi adınızla başlayaraq, depo adını izləyərək adlandırmalısınız. Adın sonunda hər hansı bir etiket yerləşə bilər. Aşağıda bu sxemə görə image adlandırılması üçün bir nümunə göstərilir.
İndi image-i yeni adı ilə yığmaq və docker push onu Docker Hub depozinə göndərmək üçün əmr icra etmək mümkündür.
docker build -t \/ : .
docker tag \/ : \/ :latest
docker push \/ :
# Praktikada bu, məsələn, belə görünə bilər:
docker build -t user\/app:v1.0.0 .
docker tag user\/app:v1.0.0 user\/app:latest
docker push user\/app:v1.0.0Hər şey düzgün keçərsə, image Docker Hub-da əlçatan olacaq və onu serverə yükləmək və ya digər inkişaf etdiricilərə ötürmək asan olacaq.
Növbəti addımlar
İndiyə qədər Docker konteyneri şəklində tətbiqin yerli olaraq işlədiyinə əmin olmuşuq. Konteyneri Docker Hub-a yükləmişik. Bütün bunlar, məqsədimizə doğru çox irəlilədiyimizi bildirir. İndi iki məsələyə daha aydınlıq gətirmək lazımdır:
- Kodu test etmək və yaymaq üçün CI alətinin tənzimlənməsi.
- İstehsal serverinin, kodumuzu yükləyib işə sala bilməsi üçün tənzimlənməsi.
Bizim vəziyyətimizdə CI/CD həlli kimi istifadə olunur Server kimi — .
Burada başqa servislərin kombinasiyasının da istifadə oluna biləcəyini qeyd etmək lazımdır. Məsələn, Travis CI yerinə CircleCI və ya Github Actions istifadə etmək mümkündür. DigitalOcean yerinə isə AWS və ya Linode seçə bilərsiniz.
Biz Travis CI ilə işləməyi qərara aldıq və bu servisdə artıq bir şeylər qurulub. Buna görə indi onu işə hazırlamaq üçün qısa məlumat verəcəyəm.
Travis CI
Travis CI, kodun test edilməsi və yayılması üçün bir alətdir. Travis CI-nin təyin edilməsinin incəliklərinə girmək istəmirəm, çünki hər bir layihə unikal olduğu üçün bu, əhəmiyyətli olmaz. Amma sizə Travis CI ilə işləməyə başlamağa imkan verəcək əsaslar haqqında danışacağam. Hansısa birini seçsəniz — Travis CI, CircleCI, Jenkins və ya başqa bir şey, bənzər tənzimləmə metodları tətbiq olunacaq.
Travis CI ilə işləməyə başlamaq üçün və bir hesab yaradın. Sonra Travis CI-ni GitHub hesabınızla inteqrasiya edin. Sistem konfiqurasiyası zamanı avtomatlaşdırmaq istədiyiniz repositoriyanı göstərməli və ona giriş icazəsi verməlisiniz. (Mən GitHub-dan istifadə edirəm, amma əminəm ki, Travis CI BitBucket, GitLab və digər oxşar xidmətlərlə də inteqrasiya edilə bilər).
Hər dəfə Travis CI işə başladıqda, konfiqurasiya faylında göstərilən komandaları icra edən server işə salınır, bu da repositoriyanın müvafiq şöbələrinin yerləşdirilməsini də əhatə edir.
▍Tapşırığın həyat dövrü
Travis CI konfiqurasiya faylı, .travis.yml və layihənin kök qovluğunda saxlanılır, hadisə anlayışını dəstəkləyir. tapşırıq. Budur, baş verən bu hadisələrin sırası:
apt addonscache componentsbefore_installinstallbefore_script: - $PSVersionTable.PSVersion - dotnet --version - nuget help | select-string Versionscriptbefore_cacheafter_success və ya after_failurebefore_deploydeployafter_deployafter_script
▍Test etmək
Mən konfiqurasiya faylında lokal Travis CI serverini quraşdıracağam. Dil olaraq Node 12 versiyasını seçdim və sistemə Docker-dan istifadə üçün lazım olan asılılıqları quraşdırmağı göstərdim.
Aşağıda göstərilən hər şey, əgər başqa cür göstərilməyibsə, repositoriyanın bütün şöbələri üzrə bütün pull requestlərdə icra olunacaq. Bu faydalı bir xüsusiyyətdir, çünki repositoriyaya daxil olan bütün kodu sınaqdan keçirmək imkanı tanıyır. Bu, kodun həqiqətən .travis.ymlşöbəsinə yazmağa hazır olub-olmadığını bilmək və layihənin tərkib prosesini pozmayacağından əmin olmaq üçün vacibdir. Bu qlobal konfiqurasiyada hər şeyi lokal olaraq quraşdırıram, Webpack inkişaf etdirici serverini fon da işlədərək (bu mənim iş axınımın bir xüsusiyyətidir) və testləri icra edirəm. masterƏgər repositoriyanızda testlərin kodu örtmə məlumatları ilə göstəricilərin çıxmasını istəyirsinizsə,
Jest, Travis CI və Coveralls-dan istifadə edərək bu məlumatların yığılması və çıxarılması üçün qısa bir təlimat tapa bilərsiniz. Beləliklə, faylın məzmunu:
Burada repositoriyanın bütün şöbələri və pull requestlər üçün icra olunan tədbirlər başa çatır. .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▍Yerləşdirmə
Bütün avtomatlaşdırılmış testlərin uğurla tamamlandığı fərziyyəsi ilə, biz kodu istehsal serverinə yerləşdirmək imkanı əldə edə bilərik. Biz bunu yalnız
şöbəsindən olan kod üçün etmək istədiyimiz üçün, yerləşdirmə konfiqurasiyasında sistemə müvafiq göstərişlər veririk. Öz layihənizdə müzakirə edəcəyimiz koddan istifadə etməyə çalışmazdan əvvəl, yerləşdirmə üçün çağırılan real bir skripte sahib olmalısınız. masterdeploy: # Docker konteynerini yığmaq və onu Docker Hub-a göndərmək provider: script script: bash deploy.sh on: branch: master
Yerləşdirmə skripti iki məsələnin həlli ilə məşğuldur:CI vasitəsilə (bizim halda Travis CI) görüntüyü yığmaq, etiketləmək və Docker Hub-a göndərmək.
- Сборка, тегирование и отправка образа на Docker Hub средствами CI-инструмента (в нашем случае это Travis CI).
- Obrazı serverə yükləmək, köhnə konteyneri dayandırmaq və yenisini başlatmaq (bu halda server DigitalOcean platformasında işləyir).
Əvvəlcə avtomatik tikinti, etiketləmə və Docker Hub-a obraz göndərilməsi üçün prosesi tənzimləmək lazımdır. Bu, artıq əl ilə etdiyimiz işlərə çox bənzəyir, yeganə fərq, burada bizə obrazlara unikal etiketlər təyin etmə strategiyası və sistemə avtomatlaşdırılmış giriş lazımdır. Mənim bəzi ətraf mühit dəyişənləri ilə bağlı çətinliklərim oldu, məsələn, etiketləmə strategiyası, daxil olma, SSH açarlarının kodlaşdırılması, SSH bağlantısının qurulması. Amma xoşbəxtlikdən, dostum bash ilə yaxşı işləyir, həmçinin bir çox digər şeylərlə. O, bu skripti yazmağa kömək etdi.
Beləliklə, skriptin birinci hissəsi Docker Hub-a obraz göndərməkdir. Bunu etmək olduqca asandır. İstifadə etdiyim etiketləmə sxemi, git hash’-ini və varsa git etiketini bir araya gətirməyi nəzərdə tutur. Bu, unikal etiketin yaradılmasına və bazaya əsaslandığı tikintinin müəyyən edilməsini asanlaşdırır. DOCKER_USERNAME və DOCKER_PASSWORD — bunlar Travis CI interfeysi vasitəsilə təyin edilə bilən istifadəçi ətraf mühit dəyişənləridir. Travis CI avtomatik olaraq gizli məlumatları qoruyacaq ki, onlar başqalarının əlinə keçməsin.
Budur, skriptin birinci hissəsi 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} Skriptin ikinci hissəsi, istifadə etdiyiniz hostingdən və onunla olan bağlantının necə təşkil edildiyindən tam asılıdır. Mənim halımda, Digital Ocean istifadə edirəm, serverə qoşulmaq üçün komandalar istifadə olunur. . AWS ilə işləyərkən aws, və s.
Serverin işini qurmaq çox çətin olmadı. Beləliklə, mən əsas obraz əsasında bir droplet qurdum. Qeyd etmək lazımdır ki, seçdiyim sistem Docker-in bir dəfəlik əl ilə quraşdırılmasını və bir dəfəlik əl ilə işə salınmasını tələb edir. Docker-i quraşdırmaq üçün mən Ubuntu 18.04-dən istifadə etdim, belə ki, siz də Ubuntu istifadə edirsinizsə, eyni şeyi etmək üçün sadəcə sadə bələdçiyə riayət edə bilərsiniz.
Burada xidmət üçün konkret komandalar haqqında danışmıram, çünki bu aspekt müxtəlif hallarda çox dəyişə bilər. Mən yalnız SSH vasitəsilə serverə qoşulduqdan sonra fachılan ümumi fəaliyyət planını təqdim edəcəyəm:
- Hazırda işlətdiyiniz konteyneri tapmalı və dayandırmalısınız.
- Daha sonra yeni konteyneri fonunda başlatmalısınız.
- Siz serverin lokal portunu müəyyən etməlisiniz
80— bu, saytaexample.comgiriş etməyə imkan verəcək, portu göstərmədən, blok istifadə etmədənexample.com:5000. - Və nəhayət, bütün eski konteynerləri və obrazları silməlisiniz.
Budur, skriptin davamı.
# Найти 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 -fDiqqət yetirilməli bəzi şeylər var.
Bəlkə siz Travis CI-dən SSH ilə serverə qoşulanda, davam etməyə imkan verməyəcək bir xəbərdarlıq görərsiniz, çünki sistem istifadəçinin reaksiyasını gözləyəcək.
Host '<hostname> (<IP address>)'un etibarı təsdiqlənə bilmir.
RSA açar açar izi <key fingerprint>dir.
Davam etmək istəyirsinizmi (bəli/xeyr)? Mən başa düşdüm ki, simli açarı base64-ə kodlaşdırmaq mümkündür ki, onu beləcə rahat və etibarlı şəkildə işlətmək olar. Quraşdırma mərhələsində, siz ictimai açarı dekod edə və onu fayla yaza bilərsiniz. known_hosts yuxarıda təsvir olunan xətadan qurtulmaq üçün.
echo <public key> | base64 # <base64-ə kodlanmış ictimai açarı> çıxarırPraktikada bu əmr belə görünə bilər:
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== you@example.com" | base64Və bu, almış olduğunuz nəticənin görünüşüdür — base64 kodlamasında bir sətir:
MTIzLjQ1LjY3Ljg5IHNzaC1yc2EgQUFBQUIzTnphQzF5YzJFQUFBQUJJd0FBQVFFQWtsT1Vwa0RIcmZIWTE3U2JybVRJcE5MVEdLOVRqb20vQldEU1UKR1BsK25hZnpsSERUWVc3aGRJNHlaNWV3MThKSDRKVzlqYmhVRnJ2aVF6TTd4bEVMRVZmNGg5bEZYNVFWa2JQcHBTd2cwY2RhMwpQYnY3a09kSi9NVHlCbFdYRkNSK0hBbzNGWFJpdEJxeGlYMW5LaFhwSEFac01jaUxxOFY2UmpzTkFRd2RzZE1GdlNsVksvN1hBCnQzRmFvSm9Bc25jTTFROXg1KzNWMFd3NjgvZUlGbWIxenVVRmxqUUpLcHJyWDg4WHlwTkR2allOYnk2dncvUGIwcndlcnQvRW4KbVorQVc0T1pQblRQSTg5WlBtVk1MdWF5ckQyY0U4NlovaWw4YitndzNyMysxbkthdG1Ja2puMnNvMWQw MVJyYXRsTXFWU3NieApOclJGaTl3cmYrTTdRPT0geW91QGV4YW1wbGUuY29tCg==Yuxarıda qeyd olunan əmr
install:
- echo <base64-ə kodlanmış ictimai açar> | base64 -d >> $HOME/.ssh/known_hostsEyni yanaşmanı, serverə qoşulma zamanı, sizə lazım ola bilən özəl açar üçün də tətbiq edə bilərsiniz. Açarla işləyərkən, onu Travis CI-nin ətraf mühit dəyişənində təhlükəsiz saxlayaraq heç bir yerdə açılmamasını təmin etməlisiniz.
Dikkat etməli olduğunuz başqa bir şey, bütün yayım skriptini tək bir sətir şəklində çalışdırmalı olmağınızdır, məsələn — doctlBu bəzi əlavə səylər tələb edə bilər.
doctl compute ssh <droplet> --ssh-command "bütün komandalar burada && burada"TLS/SSL və yük balanslaşdırılması
Yuxarıdakıları etdikdən sonra, qarşıma çıxan son problem serverin SSL-nin olmaması oldu. Node.js serverindən istifadə etdiyim üçün Nginx-in geri proxy-si və Let’s Encrypt ilə, bir qədər işləməli oldum.
Mən bu SSL konfiqurasiyalarını əl ilə həyata keçirmək istəmədim, ona görə də yalnız balanslaşdırıcı yaratdım və onun məlumatlarını DNS-ə yazdım. Məsələn, DigitalOcean-da, balanslaşdırıcıda avtomatik yenilənən öz-özünə imzalanan sertifikat yaratmaq asan, pulsuz və sürətli bir prosedurdir. Bu yanaşmanın əlavə bir üstünlüyü var ki, bununla balanslaşdırıcının arxasında fəaliyyət göstərən çox sayda serverdə SSL-i çox asanlıqla qurmaq mümkündür. Bu, serverlərin SSL-dən tamamilə “narahat olmamasına” imkan tanıyır, lakin hələ də adətən portu istifadə edirlər. 80. Beləliklə, balanslaşdırıcıda SSL konfiqurasiya etmək alternativ SSL konfiqurasiya metodlarından xeyli asandır və daha rahatdır.
İndi serverdə bütün daxil olan əlaqələri qəbul edən portları bağlamaq olar — yalnız balanslaşdırıcı ilə əlaqə üçün istifadə olunan portu 80, və SSH üçün portu 22 tərk etmək şərtilə. Nəticədə, serverə birbaşa müraciət cəhdləri, bu iki portdan başqa, uğursuz olacaq.
Yekunlar
Mən bu materialda danışdığım hər şeyi etdikdən sonra, nə Docker platforması, nə də avtomatlaşdırılmış CI/CD zəncirləri məni qorxutmadı. Kodun istehsala daxil olmadan əvvəl sınaqdan keçirildiyi və serverə avtomatik yerləşdirildiyi davamlı inteqrasiya zəncirini qurmağı bacardım. Bütün bunlar mənim üçün hələ də nisbətən yenidir və mən əminəm ki, avtomatlaşdırılmış iş prosesimi daha da yaxşılaşdırmağın və effektivləşdirməyin yolları var. Beləliklə, əgər bu mövzuda fikirləriniz varsa — mənə bildirin. Ümid edirəm ki, bu məqalə işlərinizdə sizə kömək etdi. Oxuduqda, mənim bu mətləblər haqqında başa düşdüyüm qədər bilik əldə etdiyinizə inanmaq istəyirəm.
P.S. Bizim bir imicə malikdir , bir kliklə quraşdırılır. Siz konteynerlərin işini -da yoxlaya bilərsiniz. Bütün yeni müştərilərə 3 gün pulsuz sınaq verilir.
Hörmətli oxucular! Siz layihələrinizdə CI/CD texnologiyalarından istifadə edirsiniz?
Mənbə: habr.com
