Avqustun 10-da Slurmda başladı , burada biz onu tamamilə təhlil edirik - əsas abstraksiyalardan şəbəkə parametrlərinə qədər.
Bu yazıda Docker-in tarixi və onun əsas abstraksiyaları haqqında danışacağıq: Image, Cli, Dockerfile. Mühazirə yeni başlayanlar üçün nəzərdə tutulub, ona görə də təcrübəli istifadəçilər üçün maraqlı olmayacaq. Qan, əlavə və ya dərin daldırma olmayacaq. Ən əsasları.
Docker nədir
Vikipediyadan Docker-in tərifinə baxaq.
Docker, konteynerləşdirilmiş mühitlərdə tətbiqlərin yerləşdirilməsi və idarə edilməsini avtomatlaşdırmaq üçün proqramdır.
Bu tərifdən heç nə aydın deyil. Xüsusilə "konteynerləşdirməni dəstəkləyən mühitlərdə" nə demək olduğu aydın deyil. Bunu öyrənmək üçün keçmişə qayıdaq. Şərti olaraq “Monolit Dövrü” adlandırdığım dövrdən başlayaq.
Monolit dövrü
Monolit dövr 2000-ci illərin əvvəlləridir, bütün tətbiqlər monolit idi, bir dəstə asılılıq var idi. İnkişaf çox vaxt apardı. Eyni zamanda, serverlər çox deyildi, biz hamımız onları adlarına görə tanıyırdıq və onlara nəzarət edirdik. Belə gülməli bir müqayisə var:
Ev heyvanları ev heyvanlarıdır. Monolit erada biz serverlərimizə ev heyvanları kimi yanaşırdıq, onlara qulluq edirdik və toz ləkələrini sovururduq. Və daha yaxşı resurs idarə etmək üçün virtuallaşdırmadan istifadə etdik: bir server götürdük və onu bir neçə virtual maşına kəsdik və bununla da ətraf mühitin təcrid olunmasını təmin etdik.
Hipervizora əsaslanan virtuallaşdırma sistemləri
Yəqin ki, hər kəs virtuallaşdırma sistemləri haqqında eşitmişdir: VMware, VirtualBox, Hyper-V, Qemu KVM və s. Onlar proqramların izolyasiyasını və resursların idarə edilməsini təmin edir, lakin onların çatışmazlıqları da var. Virtualizasiya etmək üçün sizə hipervizor lazımdır. Hipervisor isə resurs yüküdür. Və virtual maşının özü ümumiyyətlə bütöv bir böyükdür - əməliyyat sistemi, Nginx, Apache və bəlkə də MySQL ehtiva edən ağır bir şəkil. Şəkil böyükdür və virtual maşın işləmək üçün əlverişsizdir. Nəticədə, virtual maşınlarla işləmək yavaş ola bilər. Bu problemi həll etmək üçün kernel səviyyəsində virtuallaşdırma sistemləri yaradılmışdır.
Kernel səviyyəli virtuallaşdırma sistemləri
Kernel səviyyəli virtuallaşdırma OpenVZ, Systemd-nspawn, LXC sistemləri tərəfindən dəstəklənir. Belə virtuallaşdırmanın parlaq nümunəsi LXC-dir (Linux Konteynerləri).
LXC, Linux əməliyyat sisteminin birdən çox təcrid olunmuş nümunələrini bir qovşaqda işə salmaq üçün əməliyyat sistemi səviyyəsində virtuallaşdırma sistemidir. LXC virtual maşınlardan istifadə etmir, lakin öz proses sahəsi və şəbəkə yığını ilə virtual mühit yaradır.
Əsasən LXC konteynerlər yaradır. Virtual maşınlar və konteynerlər arasında fərq nədir?
Konteyner prosesləri təcrid etmək üçün uyğun deyil: nüvə səviyyəsində virtuallaşdırma sistemlərində boşluqlar aşkar edilir ki, bu da onların konteynerdən hosta keçməsinə imkan verir. Buna görə də, bir şeyi təcrid etmək lazımdırsa, virtual maşından istifadə etmək daha yaxşıdır.
Virtuallaşdırma və konteynerləşdirmə arasındakı fərqləri diaqramda görmək olar.
Aparat hipervizorları, OS-nin üstündə hipervizorlar və konteynerlər var.
Həqiqətən bir şeyi təcrid etmək istəyirsinizsə, hardware hipervizorları əladır. Çünki yaddaş səhifələri və prosessorlar səviyyəsində təcrid etmək mümkündür.
Bir proqram olaraq hipervizorlar var, konteynerlər də var və onlar haqqında daha ətraflı danışacağıq. Konteynerləşdirmə sistemlərində hipervizor yoxdur, lakin konteynerləri yaradan və idarə edən Konteyner Mühərriki var. Bu şey daha yüngüldür, buna görə də nüvə ilə işləmək səbəbindən daha az yük var və ya ümumiyyətlə yoxdur.
Kernel səviyyəsində konteynerləşdirmə üçün nə istifadə olunur
Digər proseslərdən təcrid olunmuş konteyner yaratmağa imkan verən əsas texnologiyalar Ad məkanları və İdarəetmə Qruplarıdır.
Ad məkanları: PID, Şəbəkə, Mount və İstifadəçi. Daha çox var, lakin başa düşmək asanlığı üçün bunlara diqqət yetirəcəyik.
PID Ad məkanı prosesləri məhdudlaşdırır. Məsələn, biz PID Ad məkanı yaratdıqda və orada bir proses yerləşdirdikdə, o, PID 1 ilə olur. Adətən sistemlərdə PID 1 systemd və ya init olur. Müvafiq olaraq, bir prosesi yeni bir ad sahəsinə yerləşdirdiyimiz zaman, o da PID 1 alır.
Networking Namespace sizə şəbəkəni məhdudlaşdırmağa/təcrid etməyə və öz interfeyslərinizi içəridə yerləşdirməyə imkan verir. Mount fayl sistemi məhdudiyyətidir. İstifadəçi - istifadəçilərə məhdudiyyət.
Nəzarət Qrupları: Yaddaş, CPU, IOPS, Şəbəkə - cəmi 12 parametr. Əks halda onlara Cgroups (“C-qrupları”) da deyilir.
Nəzarət Qrupları konteyner üçün resursları idarə edir. Nəzarət Qrupları vasitəsilə deyə bilərik ki, konteyner müəyyən miqdarda resurs istehlak etməməlidir.
Konteynerləşdirmənin tam işləməsi üçün əlavə texnologiyalardan istifadə olunur: İmkanlar, Kopyalama-yazma və s.
Qabiliyyətlər, bir prosesə nəyi edə biləcəyini və edə bilməyəcəyini söylədiyimiz zamandır. Kernel səviyyəsində bunlar sadəcə olaraq bir çox parametrləri olan bitmaplardır. Məsələn, kök istifadəçi tam imtiyazlara malikdir və hər şeyi edə bilər. Vaxt serveri sistem vaxtını dəyişə bilər: onun Time Capsule-də imkanları var, vəssalam. İmtiyazlardan istifadə edərək, proseslər üçün məhdudiyyətləri çevik şəkildə konfiqurasiya edə və bununla da özünüzü qoruya bilərsiniz.
Copy-on-write sistemi bizə Docker təsvirləri ilə işləməyə və onlardan daha səmərəli istifadə etməyə imkan verir.
Docker-in hazırda Cgroups v2 ilə uyğunluq problemləri var, ona görə də bu məqalə xüsusi olaraq Cgroups v1-ə yönəlib.
Ancaq tarixə qayıdaq.
Virtuallaşdırma sistemləri nüvə səviyyəsində meydana çıxdıqda, onlar fəal şəkildə istifadə olunmağa başladılar. Hipervisordakı yerüstü yük yox oldu, lakin bəzi problemlər qaldı:
- böyük şəkillər: əməliyyat sistemini, kitabxanaları, bir dəstə müxtəlif proqram təminatını eyni OpenVZ-ə itələyirlər və nəticədə görüntü hələ də olduqca böyük olur;
- Qablaşdırma və çatdırılma üçün normal standart yoxdur, ona görə də asılılıq problemi qalır. İki kod parçasının eyni kitabxanadan istifadə etdiyi, lakin fərqli versiyaları olan vəziyyətlər var. Onların arasında münaqişə ola bilər.
Bütün bu problemləri həll etmək üçün növbəti dövr gəldi.
Konteyner dövrü
Konteynerlər dövrü gələndə onlarla işləməyin fəlsəfəsi dəyişdi:
- Bir proses - bir konteyner.
- Prosesin ehtiyac duyduğu bütün asılılıqları konteynerinə çatdırırıq. Bunun üçün monolitlərin mikroservislərə kəsilməsi tələb olunur.
- Şəkil nə qədər kiçik olsa, bir o qədər yaxşıdır - mümkün zəifliklər daha azdır, daha tez yayılır və s.
- Nümunələr efemer olur.
Ev heyvanları və mal-qara haqqında dediklərimi xatırlayın? Əvvəllər instansiyalar ev heyvanlarına bənzəyirdisə, indi mal-qara kimi olublar. Əvvəllər monolit var idi - bir tətbiq. İndi 100 mikroservis, 100 konteynerdir. Bəzi qablarda 2-3 replika ola bilər. Hər konteynerə nəzarət etmək bizim üçün daha az əhəmiyyət kəsb edir. Bizim üçün daha vacib olan xidmətin özünün mövcudluğudur: bu konteynerlər dəsti nə edir. Bu, monitorinqə yanaşmaları dəyişir.
2014-2015-ci illərdə Docker inkişaf etdi - indi danışacağımız texnologiya.
Docker fəlsəfəni və standartlaşdırılmış tətbiq qablaşdırmasını dəyişdi. Docker-dən istifadə edərək biz proqram paketini paketləyə, depoya göndərə, oradan yükləyə və yerləşdirə bilərik.
Biz lazım olan hər şeyi Docker konteynerinə qoyuruq, beləliklə, asılılıq problemi həll olunur. Docker təkrar istehsala zəmanət verir. Düşünürəm ki, bir çox insanlar təkrarolunmazlıqla qarşılaşıb: hər şey sizin üçün işləyir, siz onu istehsala itələyirsiniz və orada işləməyi dayandırır. Docker ilə bu problem aradan qalxır. Docker konteyneriniz işə başlayırsa və lazım olanı edirsə, o zaman yüksək ehtimalla istehsala başlayacaq və orada da eyni şeyi edəcək.
Baş üstü ilə bağlı təxribat
Yerüstü xərclərlə bağlı həmişə mübahisələr olur. Bəzi insanlar Docker-in əlavə yük daşımadığına inanırlar, çünki o, Linux nüvəsini və konteynerləşdirmə üçün lazım olan bütün prosesləri istifadə edir. Məsələn, "Əgər Docker-in yuxarıda olduğunu söyləsəniz, Linux nüvəsi yuxarıdadır."
Digər tərəfdən, əgər daha dərinə getsəniz, Docker-də həqiqətən də bir neçə şey var ki, onların uzanması ilə üst-üstə düşdüyünü söyləmək olar.
Birincisi PID ad sahəsidir. Prosesi ad məkanında yerləşdirdiyimiz zaman ona PID 1 təyin olunur. Eyni zamanda, bu proses konteynerdən kənarda host ad məkanında yerləşən başqa bir PID-ə malikdir. Məsələn, biz Nginx-i konteynerdə işə saldıq, o, PID 1 (master proses) oldu. Hostda isə PID 12623 var. Bunun nə qədər yük olduğunu söyləmək çətindir.
İkinci şey Cgroups. Cgroups-u yaddaşa görə götürək, yəni konteynerin yaddaşını məhdudlaşdırmaq qabiliyyəti. Aktivləşdirildikdə, sayğaclar və yaddaş uçotu aktivləşdirilir: kernel neçə səhifənin ayrıldığını və bu konteyner üçün hələ də neçəsinin boş olduğunu başa düşməlidir. Bu, ola bilsin ki, əlavə xərcdir, amma bunun performansa necə təsir etdiyinə dair heç bir dəqiq araşdırma görməmişəm. Mən özüm də görmədim ki, Docker-də işləyən proqram birdən-birə performansında kəskin itki ilə üzləşdi.
Və performans haqqında daha bir qeyd. Bəzi nüvə parametrləri hostdan konteynerə ötürülür. Xüsusilə, bəzi şəbəkə parametrləri. Buna görə də, Docker-də yüksək performanslı bir şeyi, məsələn, şəbəkədən aktiv istifadə edəcək bir şeyi işə salmaq istəyirsinizsə, onda ən azı bu parametrləri tənzimləməlisiniz. Bəzi nf_conntrack, məsələn.
Docker konsepsiyası haqqında
Docker bir neçə komponentdən ibarətdir:
- Docker Daemon eyni Konteyner Mühərrikidir; konteynerləri işə salır.
- Docker CII Docker idarəetmə proqramıdır.
- Dockerfile - təsvirin necə qurulacağına dair təlimatlar.
- Şəkil — konteynerin yuvarlandığı şəkil.
- Konteyner.
- Docker reyestri bir şəkil anbarıdır.
Sxematik olaraq belə görünür:
Docker demonu Docker_host üzərində işləyir və konteynerləri işə salır. Əmrləri göndərən bir Müştəri var: təsviri qurun, şəkli yükləyin, konteyneri işə salın. Docker demon reyestrinə gedir və onları icra edir. Docker müştəri həm yerli (Unix yuvasına) həm də uzaq hostdan TCP vasitəsilə daxil ola bilər.
Gəlin hər bir komponenti nəzərdən keçirək.
Docker demonu - bu server hissəsidir, host maşında işləyir: şəkilləri yükləyir və onlardan konteynerləri işə salır, konteynerlər arasında şəbəkə yaradır, logları toplayır. Biz “şəkil yaradın” deyəndə, cin də bunu edir.
Docker CLI — Docker müştəri hissəsi, demonla işləmək üçün konsol yardım proqramı. Yenə deyirəm, o, təkcə yerli deyil, həm də şəbəkə üzərində işləyə bilər.
Əsas əmrlər:
docker ps - hazırda Docker hostunda işləyən konteynerləri göstərin.
docker images - yerli olaraq endirilmiş şəkilləri göstərin.
docker search <> - reyestrdə şəkil axtarın.
docker pull <> - reyestrdən maşına şəkil yükləyin.
docker qurmaq < > - şəkli toplayın.
docker run <> - konteyneri işə salın.
docker rm <> - konteyneri çıxarın.
docker logs <> - konteyner qeydləri
docker start/stop/restart <> - konteynerlə işləmək
Bu əmrləri mənimsəyirsinizsə və onlardan istifadə etməkdə əminsinizsə, özünüzü Docker-də istifadəçi səviyyəsində 70% təcrübəli hesab edin.
Docker faylı - şəkil yaratmaq üçün təlimatlar. Demək olar ki, hər bir təlimat əmri yeni bir təbəqədir. Bir nümunəyə baxaq.
Dockerfile belə görünür: solda əmrlər, sağda arqumentlər. Burada olan hər bir əmr (və ümumiyyətlə Dockerfile-də yazılmışdır) Şəkildə yeni təbəqə yaradır.
Hətta sol tərəfə baxsanız, nə baş verdiyini təxminən başa düşə bilərsiniz. Biz deyirik: "bizim üçün bir qovluq yaradın" - bu bir təbəqədir. “Qovluğu işlək et” başqa bir təbəqədir və s. Qatlı tort həyatı asanlaşdırır. Başqa bir Dockerfile yaratsam və sonuncu sətirdə nəyisə dəyişdirsəm - “python” “main.py”dən başqa bir şey işlədirəm və ya başqa fayldan asılılıqlar quraşdırıram - onda əvvəlki təbəqələr keş kimi yenidən istifadə olunacaq.
təsvir - bu konteyner qablaşdırmasıdır; qablar şəkildən işə salınır. Docker-ə paket meneceri nöqteyi-nəzərindən baxsaq (sanki biz deb və ya rpm paketləri ilə işləyirik), onda görüntü mahiyyətcə rpm paketidir. Yum install vasitəsilə biz proqramı quraşdıra, silə, depoda tapıb yükləyə bilərik. Burada da təxminən eynidir: konteynerlər şəkildən işə salınır, onlar Docker reyestrində saxlanılır (yum-a bənzər, repozitoriyada) və hər bir təsvirdə SHA-256 hash, ad və etiket var.
Şəkil Dockerfile təlimatlarına uyğun olaraq qurulur. Dockerfile-dən hər bir təlimat yeni bir təbəqə yaradır. Qatları təkrar istifadə etmək olar.
Docker reyestri Docker təsvir deposudur. ƏS-ə bənzər olaraq, Docker ictimai standart reyestrinə malikdir - dockerhub. Lakin siz öz repozitorunuzu, öz Docker reyestrinizi yarada bilərsiniz.
Konteyner - təsvirdən nə başlayır. Dockerfile-dəki təlimatlara uyğun olaraq bir şəkil qurduq, sonra onu bu şəkildən işə saldıq. Bu konteyner digər konteynerlərdən təcrid olunub və tətbiqin işləməsi üçün lazım olan hər şeyi ehtiva etməlidir. Bu halda, bir konteyner - bir proses. Elə olur ki, iki proses etməlisən, lakin bu, Docker ideologiyasına bir qədər ziddir.
"Bir konteyner, bir proses" tələbi PID Ad Məkanı ilə bağlıdır. PID 1 ilə bir proses Namespace-də başlayanda, birdən ölərsə, bütün konteyner də ölür. Əgər orada iki proses gedirsə: biri sağdır, digəri ölüdürsə, konteyner hələ də yaşamağa davam edəcək. Ancaq bu, Ən Yaxşı Təcrübələr məsələsidir, biz onlar haqqında digər materiallarda danışacağıq.
Kursun xüsusiyyətlərini və tam proqramını daha ətraflı öyrənmək üçün linkə daxil olun: “.
Müəllif: Marcel Ibraev, sertifikatlı Kubernetes administratoru, Southbridge-də təcrübə mühəndisi, Slurm kurslarının spikeri və inkişaf etdiricisi.
Mənbə: www.habr.com