Автор Тема: Докер - архитектура  (Прочетена 1609 пъти)

remotexx

  • Участник
  • *****
  • Публикации: 354
    • Профил
Докер - архитектура
« -: Мар 13, 2017, 03:59 »
Имам няколко въпроса относно архитектурата на въпросното нещо:
(опитвам се да преценя доколко ще върши работа за бъдещи проекти)
 
Докера върви върху ОС или ОС върви върху докера - туй е въпросът?

1. Докер върви върху ОС или направо върху някакаъв хардуер (подобно VirtualBox т.е. то и това си има host/guest но госта си мисли че върви в/у реалния хардуер)

2. Независимо дали е на по-високо ниво и върви в/у ОС може ли в него да се инсталира друга ОС
т.е. по-скоро следния пример (понеже някой разправят че напр. .Net се инсталира вътре, пък аз оставам с впечатлението че ще ползва с каквото идва ОС)

напр. докер клиент под Уин7
и правя си един докер пакет (или както там се казват) в който включвам .нет8 който не върви под Уин7
какво ще се случи:
- няма да ми даде да го направя като разбере че клиента е под Уин7 (ама откъде знае, че няма да тръгне - айде .Нет е голямо може и да знае ама напр. незнаен софтуер който също няма да тръгне под Уин7, правачката на пакета статичен анализ ли прави и какво ако има несъвместим код който обаче никога няма да се изпълни)
- ще го направи но клиента няма да го приеме или ако го приеме ще откаже да го стартира (пак питане за незнаен софтуер - как ще разбере че ще гръмне преди да го стартира т.е. пак опирам до статични анализ)
- ще го приеме и стартира и ще работи (и ако не ползва нещата коиото не вървят под Уин7 ще е ок, т.е. ще гърми runtime и то само ако се ползва нещо неработещо)

3. Докера може ли да емулира нещо липсващо на ниво хардуер? Питам щото днешно време всичко е виртуално, и ще може да се обновява но само доколкото хардуера позволява т.е. Уин8,9,10 но в един момент ще изтрябват напр. AVX-512 или AVX-1024 или който там ще следващия и процесора не го поддържа а аз имам докер пакет който го ползва та докер (клиента) ще се оправи ли в тя ситуация?

4. Свястна литература по въпроса (че от официалния сайт - картинката с архитектурата не ми се изясниха 1. и 2. и 3.)
https://www.docker.com/what-container
https://containerd.io/

...и това е на първо време  ::)

П.П. Какво общо има това с microservices и трябва ли да забравим за GNU Mach/Hurd
The Docker Community offers you lots of different ways to engage with other Docker enthusiasts who share a passion for virtual containers, microservices and distributed applications.

Microservices + Monolith = The Neomonolith
https://www.reddit.com/r/programming/comments/3nuz4r/microservices_monolith_the_neomonolith/

 why not just find a complete platform that natively supports RPC from the ground up and go with MACH, HURD, or MINIX? Or go one step further and go bleeding-edge with the Plan 9 OS where the "network is the computer" and replace your entire micro-service application with a set of shell scripts? - хехех, оптимисти  8)
« Последна редакция: Мар 13, 2017, 04:32 от remotexx »
Активен

go_fire

  • Участник
  • *****
  • Публикации: 4161
  • Distribution: Дебиан Сид
  • Window Manager: ROX-Desktop / е17
  • кашик с гранатомет в танково поделение
    • Профил
    • WWW
Re: Докер - архитектура
« Отговор #1 -: Мар 13, 2017, 11:21 »
Не мога да повярвам, че аз мога да съм полезен с нещо на някого.


Всичко, което ще кажа, се отнася не само до Докер, ами до всичко, което наричат днес контейнер. По-конкретно отнася се също за доста по-простия LXC. Също така се отнася за дядо им OpenViz/Virtoozo, който ми е любим и съществува дълго прeди тези технологии да влязат официално в ядрото. Отнася се и до всички по-малко известни формати.

Докер е много лесен за разбиране, ако човек знае, какво е Юникс и какво вкараха в ядрото, като нови технологии. Дори не е необходимо, някой да му го обяснява. На мен например никой не ми го е обяснявал. Стигнах по пътя на логиката. А когато гледах докладите посветени на темата (предимно на Мариян Маринов, но не само), то само се потвърди това, до което бях стигнал сам.

=*=

Контейнерите са нищо повече от развита версия на затвор. Това, което в BSD сe нарича jail, a в Solaris е zones. Което ни връща към основите на Юникс. В Юникс всичко е file. Или поне беше. Има известно отстъпване от тази концепция. Всичко започва в една точка и като корен (а тя така се и нарича) започва да слиза надолу и все повече да се разклонява.

Съответно сигурността също се гради на този принцип — достъп до files. Сигурността зависи от това, кой, до какви files има достъп.

И още, когато са го измисляли преди почти 40 год., професорите в Бъркли са си рекли — а не може ли на потребителя да му създадем „пясъчник“ — цяла ОС вътре в нашата. И понеже всичко е file, достъп до file и имаме корен [root], то се оказало, че не съществува нищо по-лесно от това. Просто преместваме този корен и вътре слагаме, каквото искаме.

В ГНУ/Линукс това се прави чрез командата chroot. Това е съкращение от change root directory [промяна на кореновия каталог]. Има го като системно извикване, има го и като потребителска команда. Съответно информацията за него е в ръководства 2 (System calls (functions provided by the kernel) и изненада… 8 (защото System administration commands (usually only for root). Да и аз се изненадах, че не е в едно, сега като проверявах, но си е логично.

Тук е неприятния момент, че в ядрото Линукс не е реализирано добре с цел възможно най-голяма съвместимост. Има реализирана сигурна реализация, но тя поради същата причина никога няма да влезе в ядрото.

Затова приеми chroot по-скоро като обещание на потребителя да е приличен, отколкото като механизъм за сигурност, защото не е. Или пък пакетирай ядрото си с нещата на дъртото гуро Брад Спендлър (в Дебиан и Ред Хат дори ги има). Но както казах, сигурност означава ограничения. Ако вземеш grsec ще се сблъскаш челно в много стени. Много неща ще станат невъзможни.

И тук се появяват няколко въпроса. Добре де — аз лесно ще му сменя корена, лесно ще му дам само php и mysql да речем, ама какво става с ресурсите? Той все още може да ми изпие всичко налично на машината дори само малко неща да съм му дал. И втория въпрос, който се появява — хубаво съм му сменил корена, дал съм му,  каквото иска и го лъжа, че цялата машина е негова, ама какво правим с Init? Той може да е само един и винаги с номер 0. Няма друг.

Сега сигурно тези въпроси са ти много странни. На кой му пука???

Работата е там, че исторически ядрото Линукс дължи своето израстване на компаниите предлагащи домуване и изобщо намесени в бизнеса в паяжината. Без тях няма Линукс. Те вземат всички решения от почти първия ден до завинаги.

На тях им пука. Искат да продават повече, от колкото имат и го правят, от както са се пръкнали. Не е ли измама? Измама е. Но няма закон против нея и ще си съществува  винаги.

Поради тази причина в началото на века се зароди OpenVZ. Проблема му е, че е руски и няма як гръб. Затова трябваше нещо ново.

И така в ядрото се появиха две нови технологии. Първата се нарича пространства от имена. Сиреч вече можеш да имаш, каквито си искаш номерации на процеси и те няма да се бъркат никак по между си. Това е решението на проблема с петте хиляди процеса с номер 0 (process id 0). Има и други неща, които могат да се именуват, но това е най-важното.

Другата технология има много имена, но условно можем да я наречем „Граница“. Това е начина да кажеш на ядрото — искам този процес да има толкова памет, толкова ядра, толкова процесорно време, толкова дисково пространство и т.н.

Както казахме всичко е file, включително pid и ppid. А пък ядрото Линукс монтира едни фалшиви файлови системи (/proc и /sys) през, които можеш директно да си говориш с него. Последното е нестандартно. Няма друго ядро, което го поддържа. Има „аналози“, но те са по-трудни за работа от обикновена ФС. Поради тази причина да се направят „условни граници“ в ядрото е детска игра.

Малко по-сложно е от към професора. Той е една извънредно сложна джаджа, която има хиляди особености и съответно стотици ограничения, които могат да се сложат, но не работят, както някой си мисли, че трябва. Специално в тая част си трябва четене, като за едно цяло следване.

Е като сложим на едно място смяната на корена, пространствата от имена и границите, то получаваме това, което днес наричат контейнер, а си е добрата стара тъмница с допълнителни ограничения.

Остава единствено да се добави удобна, конфигурационна абстракция и евентуално архивен формат (по подобие на tar или io). Второто не е задължително.

=*=

Нищо по-малко не са и нищо повече — механизъм за регулация на ресурси в традициите на Юникс.

Предполагам, че веднага изникна и ограничението. Има нещо, което стои в процеса на зареждане преди инициализацията и преди частта от нея с вдигане на абстракцията за ФС. И двете са предхождани и повелявани от ядрото.

То не може да се симулира. Не може да се смени. Винаги е то и винаги в конкретната си версия. Всичко друго е по избор. Не можеш да имаш друга ОС и не можеш да имаш друг тип хардуер. Можеш да имаш различна дистрибуция (цялата без ядро), ако желаеш и можеш да сложиш всякакви ограничения, но върху тази конкретна апаратура. DDR5 може да е по-бавен или малко и от DRAM (това е преди SD), но си остава DDR5.

=*=

Въпрос е защо виртуализация и контейнери се споменават заедно, като нямат нищо общо? Ами първо има инструменти като например Vargand, които могат да се използват за настройка и на двете. Също така — много отдалеч погледнато тъмницата прилича на виртуализация. Но това са просто оправдания. Истината е, че това е нищо повече от маркетинг, който се прилага на шефовете да купуват. Те така или иначе не разбират от нищо, но думата виртуализация вече им е набита от VMWare и компания, та я ползват за реклама.

Иначе и симулацията на апаратура не е някаква ядрена физика. Правил го е самия Уилям Гейтс Трети още през седемдесетте. Но на всеобща мода излезе мъничко преди контейнерите. И двете винаги са се ползвали, но никога не е било толкова масово, защото и паяжината никога не е била толкова голяма като бизнес, колкото е сега.
Активен

В $por4e2 e истината  ;)

***

Aко даваха стипендия за най-глупави, щях да съм човека с най-много Mини Kупъри

***

Reborn since 1998 || 15.09.2007 totally М$ free && conscience clear

go_fire

  • Участник
  • *****
  • Публикации: 4161
  • Distribution: Дебиан Сид
  • Window Manager: ROX-Desktop / е17
  • кашик с гранатомет в танково поделение
    • Профил
    • WWW
Re: Докер - архитектура
« Отговор #2 -: Мар 13, 2017, 11:23 »
Забравих да кажа, че на 64-битово ядро може да се сложи 32-битово обкръжение, дори в някой случай е за предпочитане. Ядрото си остава 64-битово, но всичко друго може да не е. Може би съм счел, че е подразбиращо се. Нищо, сега го добавям.
Активен

В $por4e2 e истината  ;)

***

Aко даваха стипендия за най-глупави, щях да съм човека с най-много Mини Kупъри

***

Reborn since 1998 || 15.09.2007 totally М$ free && conscience clear

jet

  • Участник
  • *****
  • Публикации: 1093
  • Distribution: debian sid
  • Window Manager: kde
    • Профил
Re: Докер - архитектура
« Отговор #3 -: Мар 13, 2017, 13:51 »
Не знам за Уиндоус контейнерите.

Поиграй си в Линукс и може би ще ти светне:

apt-get install lxc

lxc-create -t ubuntu -n moeto_ubuntu
lxc-create -t ubunty -n drugo_ubuntu
lxc-create -t debian -n moeto_deb

lxc-list
lxc-start -n moeto_ubuntu

Първия контейнер отнема към една минута - сваля си пакетчета.
Следващите обаче ги прави за 3сек.
Теслата е как да организираш мрежата.
« Последна редакция: Мар 13, 2017, 13:53 от jet »
Активен

"Guy who put "logout" in tiny text right next to "restart", also in tiny text, in Windows Server 2012, making every logout of production systems a test in fine motor skills. I'd really like to speak to that person for a few minutes"

go_fire

  • Участник
  • *****
  • Публикации: 4161
  • Distribution: Дебиан Сид
  • Window Manager: ROX-Desktop / е17
  • кашик с гранатомет в танково поделение
    • Профил
    • WWW
Re: Докер - архитектура
« Отговор #4 -: Мар 13, 2017, 14:15 »
Ами това в 10 не е нищо различно. Те миналата година си направиха своя версия на µLinux. Сиреч то работи като услуга към ядрото на Шиндош, което е технология на повече от 15 год. Сега просто идва от тях. Първо пуснаха bash. После пуснаха цялото Убунту. Като нарочно не пуснаха XWindows, за да не си правят сами конкуренция. Всичко това го направиха, защото има много които разработват за сървъри под ГНУ/Линукс.  И искат да го правят под Шиндош. Старата песен на нов глас.

Та технологии като контейнерите и „плоските“ пакети много добре им влизат, защото това си е шиндоширане в пълна степен (особено второто).


п.п. Туко що видях допълнение към основното питане. Мискро-услуги е „нов“ начин а изграждане на приложения в паяжината. Вече не е едно монолитно цяло. Има отделни процеси, които да отговарят за всяко конкретно нещо. Например искаш да пратиш писмо. Интернет-навигатора праща заявка (примерно REST), а оттатък това, което слуша, знае да викне точно определен код, който да свърши тая работа. Това е много удобно, защото може нещата да са писани на различни езици. А освен това е донякъде и в идеологията на Юникс. Микро-услугата прави само едно нещо и го прави добре. Ако не, може да се замени с друга на друг език, която прави нещото по друг начин;

п.п.п. И в момента микро-услугите могат да се изпълняват от shell. Причината да не се прави е, защото командният интерпретатор е много бавно нещо. Той е направен за удобсто, не за програмиране. План 9 няма много общо в случая. План 9 е обикновено доразвиване на идеите от Юникс. Извън това представлява един протокол, към който всичко се връзва. Можем да го разгледаме и от ГНУ/Линукс. Тук имаме няколко прозоръчни управителя, които го ползват. Например при мен отдавна си играя с w9wm и wmii, които са най-известните от тях. Що се отнася до RPC, има десетки реализации за ГНУ/Линукс. Има ги от десетки години. Например триклетия dbus е нищо повече от това. Легендарната (и не по-малко проклета) CORBA също. Митичния dcop от КДЕ 3  — пак. И в ядрото дори има. Нищо ново и нищо револючционно. Uber с TChanell не са открили топлата вода.
« Последна редакция: Мар 13, 2017, 14:36 от go_fire »
Активен

В $por4e2 e истината  ;)

***

Aко даваха стипендия за най-глупави, щях да съм човека с най-много Mини Kупъри

***

Reborn since 1998 || 15.09.2007 totally М$ free && conscience clear

deant01

  • Участник
  • *****
  • Публикации: 175
  • Distribution: Debian/sid
  • Window Manager: Gnome 3
    • Профил
Re: Докер - архитектура
« Отговор #5 -: Мар 13, 2017, 16:42 »
Имам няколко въпроса относно архитектурата на въпросното нещо:
(опитвам се да преценя доколко ще върши работа за бъдещи проекти)
 
Докера върви върху ОС или ОС върви върху докера - туй е въпросът?

1. Докер върви върху ОС или направо върху някакаъв хардуер (подобно VirtualBox т.е. то и това си има host/guest но госта си мисли че върви в/у реалния хардуер)

Докера върви върху ОС. Както всяка друга програма пусната на ОС, той е един обикновен процес вътре. Това, което е различното от ВиртуалнактаКутия, е че госта може да бъде САМО линукс и той ЗНАЕ, че върви в докер, заради подръжките вътре в ядрото. Т.е. ядрото на домакина директно се ползва като ядро на госта, откъдето идва премахването на нуждата  госта да има нужда от драйвери за желязото. Т.е. ядрото на домакина поема всички тези функции и сервира всичко наготово на госта.

2. Независимо дали е на по-високо ниво и върви в/у ОС може ли в него да се инсталира друга ОС
т.е. по-скоро следния пример (понеже някой разправят че напр. .Net се инсталира вътре, пък аз оставам с впечатлението че ще ползва с каквото идва ОС)

В самият докер има мини дистрибуция. Много от тях са на Убунту, други са на дебиан, трети са на Алпайн (много дребни). Това, което представлява контейнера е един узерланд+основните системни пакети + пакетен мениджър. От там нататък ти може да го доразвиеш, като примерно му сложиш един постфикс+спамд+клам+амавис+др., правиш му твоите настройки, които знаеш че си работят, както ти искаш и си го архивираш като личен контейнер. След това имаш Х машини на брой, които искаш да бъдат мейл сървъри и го пускаш на всички тея машини, като правиш минимални промени за да пасне на това място.
Специялно за .Net не знам, но за Mono не е проблем.



напр. докер клиент под Уин7

Мисля, че няма докер клиент за У7

и правя си един докер пакет (или както там се казват) в който включвам .нет8 който не върви под Уин7
какво ще се случи:
- няма да ми даде да го направя като разбере че клиента е под Уин7 (ама откъде знае, че няма да тръгне - айде .Нет е голямо може и да знае ама напр. незнаен софтуер който също няма да тръгне под Уин7, правачката на пакета статичен анализ ли прави и какво ако има несъвместим код който обаче никога няма да се изпълни)
- ще го направи но клиента няма да го приеме или ако го приеме ще откаже да го стартира (пак питане за незнаен софтуер - как ще разбере че ще гръмне преди да го стартира т.е. пак опирам до статични анализ)
- ще го приеме и стартира и ще работи (и ако не ползва нещата коиото не вървят под Уин7 ще е ок, т.е. ще гърми runtime и то само ако се ползва нещо неработещо)

Всичко по горе за Вин7 няма как да стане, защото: 1. Контейнера е ЗАДЪЛЖИТЕЛНО да ползва ядро линукс..2 Домакина е задължително с ядро линукс, което под Вин10 е с тая новата модерната емулация, а под БСД е пак с няква емулация на линукс мисля.


3. Докера може ли да емулира нещо липсващо на ниво хардуер? Питам щото днешно време всичко е виртуално, и ще може да се обновява но само доколкото хардуера позволява т.е. Уин8,9,10 но в един момент ще изтрябват напр. AVX-512 или AVX-1024 или който там ще следващия и процесора не го поддържа а аз имам докер пакет който го ползва та докер (клиента) ще се оправи ли в тя ситуация?

КОнтейнера не ползва процесорните флагове директно. Не му е работа. Тая функция се поема от ядрото на домакина, контейнера е отделен процес или отделна програмка, която ползва ресурсите предоставени от кернела на домакина. Докера виртуализацията е само куриер между основния процес в контейнера (примерно постфикс) и кернела на домакина, който единствено изолира същия този процес от останалата система.


4. Свястна литература по въпроса (че от официалния сайт - картинката с архитектурата не ми се изясниха 1. и 2. и 3.)
https://www.docker.com/what-container
https://containerd.io/

...и това е на първо време  ::)

П.П. Какво общо има това с microservices и трябва ли да забравим за GNU Mach/Hurd

За жалост при толкова системи в джунглата Хърд няма шанс да се развие като нещо различно от фън проект. Не трябва да го забравяме, но трябва да знаем, че времето след което ще стане готов за реална употреба клони към + безкрайност.
Нещо подобно се случва и с любимото ми NetBSD. Просто с годините ще изчезне.


The Docker Community offers you lots of different ways to engage with other Docker enthusiasts who share a passion for virtual containers, microservices and distributed applications.

Microservices + Monolith = The Neomonolith
https://www.reddit.com/r/programming/comments/3nuz4r/microservices_monolith_the_neomonolith/

 why not just find a complete platform that natively supports RPC from the ground up and go with MACH, HURD, or MINIX? Or go one step further and go bleeding-edge with the Plan 9 OS where the "network is the computer" and replace your entire micro-service application with a set of shell scripts? - хехех, оптимисти  8)


И накрая - това е моето виждане по въпроса, като признавам, че съм засягал само повърхността на докер. Не претендирам, че всичко съм разбрал правилно или/и съм успял да ти го предам правилно. Моля и за други мнения по въпроса, както и критика, ама бъдете по-нежни:)
« Последна редакция: Мар 13, 2017, 18:58 от deant01 »
Активен

Ripples of paradox spread out across the sea of causality.

go_fire

  • Участник
  • *****
  • Публикации: 4161
  • Distribution: Дебиан Сид
  • Window Manager: ROX-Desktop / е17
  • кашик с гранатомет в танково поделение
    • Профил
    • WWW
Re: Докер - архитектура
« Отговор #6 -: Мар 13, 2017, 17:49 »
Няма нужда да сме груби ☺ Пък и не сме някакви гении та да можем да си го позволим.

Мога да те поздравя, че си понаучил някакви неща за Docker. Но като цяло не си разбрал, какво е това контейнер. Няма ядро на и под, над, около, вътре в Докера.

Просто прочети първото ми мнение в темата. Реално погледнато през ucLinux (µLinux) можеш да си пуснеш контейнери на всички Шиндоши с ядра New Tecknology. Досовските не стават. Обаче да сглобиш такова ядро сам си е бая зор. Поне аз не съм чувал някой, който да го е автоматизирал. Затова реално само 10.

И не си прав, че:

Цитат
Както всяка друга програма пусната на ОС, той е един обикновен процес вътре.

В случая с Docker е вярно. Врно е и в 999,999999‰ от случайте. Но не е винаги. Например Xen е технология, която се пуска преди ядрото. В този смисъл, всичко което е архитектура 8*86 също има код изпълняван преди и под ядрото. Той ни е познат като BIOS. А отделно пък в самите професори по тая архитектура има един друг код, който се изпълнява дори под равнището на BIOS. Това е защото те отдавна не са 8*86, а само симулират такива.

Затова ядрото хич не е най-ниското равнище на изпълним код. То е поредната абстракция въведена за удобство. Би трябвало да помниш, че едно време си купувахме компютри, които нямаха ОС, а единствено интерпретатор на BASIC. Гъзарите имаха платка за Паскал, ама бяха ужасяващо скъпи и трудно се намираха.
Активен

В $por4e2 e истината  ;)

***

Aко даваха стипендия за най-глупави, щях да съм човека с най-много Mини Kупъри

***

Reborn since 1998 || 15.09.2007 totally М$ free && conscience clear

deant01

  • Участник
  • *****
  • Публикации: 175
  • Distribution: Debian/sid
  • Window Manager: Gnome 3
    • Профил
Re: Докер - архитектура
« Отговор #7 -: Мар 13, 2017, 18:32 »
Благодаря за меката критика, но наистина яко съм се заблудил за кернелите. В контейнера няма кернели, а докер осигурява достъп на контейнера до домакинския кернел. Т.е. моите обеснения по-горе са малко грешни. Т.е. контенера представлява изолиран userland + libs + packet manager. Може би е по разбираемо на английски (цитат от форума на докер.ком):

Docker uses host OS kernel, there is no custom or additional kernel inside container. All containers which run on a machine are sharing this "host" kernel.

https://superuser.com/questions/889472/docker-containers-have-their-own-kernel-or-not


П.П.
Позволих си да променя първия си коментар, за да е малко по-точен, както за ОП-а, така и за по лесно намиране от следващи хора търсещи информация.
« Последна редакция: Мар 13, 2017, 19:00 от deant01 »
Активен

Ripples of paradox spread out across the sea of causality.

pennywise

  • Гост
Re: Докер - архитектура
« Отговор #8 -: Мар 13, 2017, 19:09 »
Да дам и моите 2 стотинки по темата, ако помогнат да си изчистиш понятието, по-скоро относно практическа работа отколкото теоретична. Другите вече са казали, че използва кернела на хост-а (нямам идея как работи в Уиндоус). Поради това използва доста по-малък ресурс от други типове виртуализация (то и не се води точно виртуализация).

Аз мисля за Докер както е модерно сега да се казва IaC (infrastructure as code).
Различното от другите виртуализации е, че е мислен за един сървиз на контейнер, или ако си свикнал да слагаш всичко на една виртуална машина, тук препоръчително е да се използва отделен контейнер за всеки сървиз (микросървиси).

Горното обаче налага да се ползват допълнителни докер-инструменти като docker-compose, swarm - те могат да съберат всички контейнери/сървиси на едно място(по-скоро да помогнат с по-леснта комунакация м/у контейнерите и с менажирането им). Има и нещо като лимитация, защото всеки контейнер може да изпълнява само една команда/процес при старт.
Естествено може да се набуха всичко на едно място и да ползваш нещо като supervisord да пусне останалите процеси, но по-добре да се ползва по начина който е замислен - дали ти върши работа така е друг въпрос.

В общи линии е нещо като система за контрол на версиите (GIT, SVN), можеш да билдваш локално образи, които след това да се push-ват към докер хъб (почти както код към github/git). Също така можеш да използвап готови образи от там (пак аналогия с git и git clone ).

Всичко това има доста предимства и недостатъци, и зависи за какво искаш да ги използваш, може и да се окажат неподходящи.

Доста е различно и според мен е най-добре да отделиш 2-3 часа да се пробваш да пуснеш приложение на LAMP/LEMP или с каквото имаш повече опит, но е добре да е от няколко сървиса/контейнера.

Аз лично гледах един леко дразнещ тип не мога да се сетя как се казваше курса, но мога да ти го пратя по-късно днес на лично. Само, че е доста стар вече ~2 години, и може би е по-добре да потърсиш нещо в торент тракерите или Udemy. Според мен един курс + документацията е достатъчна, но налага да се отделят няколко часа.
Активен

remotexx

  • Участник
  • *****
  • Публикации: 354
    • Профил
Re: Докер - архитектура
« Отговор #9 -: Мар 13, 2017, 21:18 »
Благодаря на всички отзовали се.
Общо взето както се очакваше колкото хора толкова мнения - това е нормално де...

Ще дам още малко информация (нарочно я пропуснах отначало, да не повлияе на изясняването по принцип на нещата)

1. Има версия и за Уин - https://www.docker.com/docker-windows
но има още и Docker CE for AWS, и Docker CE for Azure  8)

2. Понеже очаквах подобен 'разнобой' се надявах поне за насоки към правилната/подходяща литература, понеже като с всяко ново нещо бъка с бози (в стил for dummies, for 24 hrs etc.)

3. Примера беше с уин за да е по-абстрактен и заради 4.

4. Опитвам се да сравня - сега-засега Виртулка спрямо Докер откъм непрекъсваемост (или поне мин.) на процеса когато се наложи обновяване я на ОС (я на .Нет/Моно и каквото още се сетите), защото рано или късно се налага заради някой бъг напр. да се обнови .Нет ама понякога и ОС а някой ден ще се наложи нова ОС т.е. ъпгрейд щото напр. да кажем има .Нет за Уин98 ама излиза .Нет 4 и опа от Уин7 нагоре - докера ще спаси ли положението - затова малко неподготвен се изказах - ще може ли докер клиент (за Уин98 - знам че няма това е само пример) да стартира пакет направен вътре с .Нет4/Уин7/8/10 (явно от по-нов докер, предполагам новите ще са обратно съвместими с по-стари версии)

Сега разбирам че това е невъзможно, от тая гледна точка виртулаката е по-добре, т.е. правиш нова и стартираш в нея приложението в клъстер - новото със старото и после се убива старото т.е. целта е непрекъсваемост на процеса особ. когато се наложи обновяване (ОС, пакет и пр.)

дотук - предимиства и недостатъци: (така ги виждам аз нещата)
+Докер е по-добре откъм deployment не се налага да се бориш със зависимости напр. .Нет3.5 обаче ОС има .Нет4 който е валиден заместител но ако се ползва нещо по-нестандартно или се очаква повечение стриктно 3.5 и почва да гърми.. докато в докера ще си пърпори под .Нет (айде Моно) 3.5 баш както си му е редът
-обаче ако както се оказва докера върви под ОС - рано или късно идва ред на обновяване и на ОС т.е. не за инсталирана/та вътре в пакетите и тук идва цялото объркване - докера хем има вътрешна ОС хем и външна - та дотук поне ми се изясни че все пак работи под ОС и не е като ВМ
 т.е. то и под ВМ го има този проблем ама е по-надолу по трасето напр. ВМ в. 5.1.16 r113841  8) ще си подкара Уин7,8,10,11.. и т.н. докато новата ОС не поиска ресурс/хардуер който ВМ няама, не поддържа, не може да задели или не може да емулира (знам че не е емулатор)
та ВМ може да издъжи много повече нови версии на ОС докато докера (щом госта се линква директно към ядрото на домакина) явно е тясно свързан т.е. ако се обнови ОС на сървъра/външната ще трябва да се сменят и всички докер пакети вътре

А на втория по важност въпрос още нямам отговор - как и кога се разбира /при правенето или при стартирането или може и никога да не се разбере ако не се случи/ дали това което е вътре (в пакет) ще върви под това което е отвън (ОС домакин). Дотук само разбрах че (май) не може да има домакин/Уин с гост/Линукс щом е само тънка обвивка и директно се правят извиквания между двете ядра (макар че и двете уж трябва да са POSIX съвместими  >:D)

Все пак ще трябва да намеря свястна литература по въпроса...
и литература за микро сервизи/услуги, че и те не са ми ясни - напр. data scraper - от гледна точка на клиента това си е 1 единствена услуга ама аз мога да го разглеждам като 2 микро услуги напр. 1) сваляне на страницата 2) извличане на информацията, но (както казваше сенсей Йода - винаги има по-голяма риба)
и тези 2 мога да ги заделя на по още 2 напр. пращане на заявка и получаване на отговор/уеб страница и т.н. до безкрай т.е. докато 1 микро услуга ми е един оператор на избрания език за програмиране - то и за това ще трябва да се чете (барем по дефиниция какво се включва в една микро услуга)


П.П. Знам че аз неправилно подхождам към въпроса и не му е това основната цел на докера, ама още се опитвам да я разбера, затова литература ако може - ама само ако сте я изчели и ви се струва солидна, защото не си струва да го изуча из основи само за да преценя че не ми върши работа, ако става ще се чете.. няма как - докато стигна до асемблера (или машинния език) // ееех лесно им е на компютрите и с 1 език се оправят само)

П.П.П. Та аз изхождам откъм обратната страна - имаме блейд сървър който през някаква /пара/ виртуализация се вижда като напр. някакъв брой стандартни копм./процесори напр. Intel Xeon E5-2697V4 което в общия случай може и да няма нищо общо с реалния хардуер/блейд, но като такъв се вижда. Върху това нещо вървят някакви виртуалки и в тях някакви приложения. Това ми бе изходната постановка - и сега вътре ОС ще издържи няколко версии на приложението после ще се наложи обновявне на ОС /това май докера няма да го преживее, не и без обновяване на самия докер/ и накрая ще се наложи обновяване и на виртуалките но до известно време напр. представяне като по-нов Xeon процесор ще спаси положението т.е. ще си карат със стария блейд ...знам че няма нищо вечно.
Активен

remotexx

  • Участник
  • *****
  • Публикации: 354
    • Профил
Re: Докер - архитектура
« Отговор #10 -: Мар 13, 2017, 21:36 »
Ей сега ми дойде една друга идея - А може ли един докер пакет да се премести от един докер клиент към друг както си работи вътре без прекъсване и без да разбере че е преместен? за простота приемаме че всичко е еднакво (ОС домакин, ОС клиент, докер домакин, докер клиент) но на различни машини (е има жица между тях де)

Доколкото разбрах докер също се състои от две части - една която прави (и може би и менажерира) пакетите и друга т.нар. докер-клиент който само ги изпълнява, т.е. значи е възможна следната ситуация?
ОС домакин Уин10, докер домакин (не знам версии ама напр.) в. 5, докер клиент (напр.) в. 4, ОС гост Уин7
т.е. това би трябвало да работи - Уин10 ядрото поддържа (в т.нар. compatibility mode) Уин7
тук единствено остава допускането че докер правещата_пакети_част в.5 ще може да направи пакет за докер клиент в.4 т.е. по-стара... питам щото от гл.т. на приложението в пакета единственото нещо което може да нолжи спиране на работа е обновяването на докер-клиента и явно, че докер -сървъра (не знам и аз как да го нарека вече) мисля ще може да се обновява по-често (дотолкова доколкото още може да прави пакети съвместими с по старата версия) ..не съм много сигурен обаче (от всичко изчетено досега може да са твърдо свързани една с друга двете му части, а това е което се опитвам да избегна)


и последно как стои въпроса със 32/64 бита при докера (естествено нямам предивид 32 отвън 64 вътре)
тук май е съществената разлика докер-ВМ, преполагам под докера ще върви през текущото 64 бита ядро 64 ползвайки напр. WoW (Windows over Windows) за 32 битови извиквания към ядрото (64 бит) докато напр. ВиртуалБокс ми заделя едно ядро 64 бит и в него си пуска native 32 битова ОС (която си го вижда като 32 битово) и няма междинни слоеве които уж са същите ама не са - няма някой дето поне веднъж да е пускал compatibility mode и да не му е тръгвало приложение.
« Последна редакция: Мар 13, 2017, 21:54 от remotexx »
Активен

deant01

  • Участник
  • *****
  • Публикации: 175
  • Distribution: Debian/sid
  • Window Manager: Gnome 3
    • Профил
« Последна редакция: Мар 13, 2017, 21:47 от deant01 »
Активен

Ripples of paradox spread out across the sea of causality.

deant01

  • Участник
  • *****
  • Публикации: 175
  • Distribution: Debian/sid
  • Window Manager: Gnome 3
    • Профил
Re: Докер - архитектура
« Отговор #12 -: Мар 13, 2017, 21:55 »
Ей сега ми дойде една друга идея - А може ли един докер пакет да се премести от един докер клиент към друг както си работи вътре без прекъсване и без да разбере че е преместен? за простота приемаме че всичко е еднакво (ОС домакин, ОС клиент, докер домакин, докер клиент) но на различни машини (е има жица между тях де)

Доколкото разбрах докер също се състои от две части - една която прави (и може би и менажерира) пакетите и друга т.нар. докер-клиент който само ги изпълнява, т.е. значи е възможна следната ситуация?
ОС домакин Уин10, докер домакин (не знам версии ама напр.) в. 5, докер клиент (напр.) в. 4, ОС гост Уин7
т.е. това би трябвало да работи - Уин10 ядрото поддържа (в т.нар. compatibility mode) Уин7
тук единствено остава допускането че докер правещата_пакети_част в.5 ще може да направи пакет за докер клиент в.4 т.е. по-стара... питам щото от гл.т. на приложението в пакета единственото нещо което може да нолжи спиране на работа е обновяването на докер-клиента и явно, че докер -сървъра (не знам и аз как да го нарека вече) мисля ще може да се обновява по-често (дотолкова доколкото още може да прави пакети съвместими с по старата версия) ..не съм много сигурен обаче (от всичко изчетено досега може да са твърдо свързани една с друга двете му части, а това е което се опитвам да избегна)

всъщност има доста видеота в тубата... ето един специално за Вин контейнер - https://www.youtube.com/watch?v=CE9StJpb2ZY
Активен

Ripples of paradox spread out across the sea of causality.

4096bits

  • Участник
  • *****
  • Публикации: 1897
    • Профил
Re: Докер - архитектура
« Отговор #13 -: Мар 13, 2017, 21:56 »
Не го знаех това за Xen. Винаги съм се чудел, как може да се пусне виртуалката преди изобщо да зареди системата, а самата система да е през вм. Много гадорийки могат да се направят така.
Активен

"As they say in Mexico 'dosvidaniya'. That makes two vidaniyas."

remotexx

  • Участник
  • *****
  • Публикации: 354
    • Профил
Re: Докер - архитектура
« Отговор #14 -: Мар 13, 2017, 21:59 »
https://blog.docker.com/2016/09/build-your-first-docker-windows-server-container/
Мдам - препоръчват виртуалка и в нея докера, което малко обезмисля усилията ми да мина само на едното или само на другото (то при мен е да мина от едното на другото)
..ама и аз така ги виждам нещата

Благодаря за информацията.

П.П. Само да поясня (понеже и аз се подведох в началото, аз ползвам Уиндоус само за пример)
Windows-native Docker Engine directly (that is, not using “Docker for Windows”)
т.е. Windows-native Docker Engine почва от Уин Сървър 2016 и нагоре но това НЕ Е "Docker for Windows" който почва от Уин10 и нагоре
https://docs.docker.com/docker-for-windows/install/#what-to-know-before-you-install
The current version of Docker for Windows runs on 64bit Windows 10 Pro, Enterprise and Education (1511 November update, Build 10586 or later)

и иска Hyper-V и ти прецаква VirtualBox  :o
« Последна редакция: Мар 13, 2017, 22:07 от remotexx »
Активен