Uživatel:Keny/ Kontejnery

Stránka byla naposledy editována 20.6.2024

ToDo Keny (diskuse) 19. 6. 2024, 14:57 (CEST) To, že vidíte tento text, je to signálem, že se na tomhle článku stále pracuje a text není ve finální verzi

Kontejner (angl. container), je výraz ze středověké angličtiny, který vznikl kombinací podstatného jména „obsah” (angl. contain) s příponou -er, zájmenem určujícím kde se nachází (= uvnitř).

Sám o sobě výraz „kontejner” nespecifikuje o jaký obsah se jedná, ani jak vypadá, či jaké má vlastnosti. V češtině takové slovo není. Významově nejblíž k němu má „pouzdro”, nebo též „nádoba” – předměty, které rovněž mohou něco obsahovat, ale tím, že jsou spojeny s konkrétní podobou, naznačují formu obsahu. Např. nádoba patří mezi duté předměty, vhodné k uložení tekutého obsahu – láhev, hrnec, sud, atp. Kdežto účelem pouzdra je chránit obsah před poškozením.

To jak vypadá kontejner, je dáno kontextem. Sám o sobě žádnou konkrétní podobu nemá, což z něj dělá ideální IT výraz pro zapouzdřený operační systém. Umístit lze do něj cokoliv, klidně i další kontejnery. Ale všechny dohromady nemohou pojmout víc obsahu, než pojme ten, do kterého je vloženy.

Co se děje či neděje v kontejneru, nemusí být navenek zjevné – podobně jako u nádoby. U ní též nezáleží na tom, je-li uvnitř tekutina, nebo něco sypkého. U nádoby ovšem záleží také na jejím účelu, o kterém vypovídá přídavné jméno. Např. u kvasné nádoby, se může měnit za spoluúčasti živých organizmů (kvasinek) původní obsah (cukr) na jiný (alkohol + CO2). Ale u zásobnice – nádoby používané v minulosti ke dlouhodobému uskladnění obilí – bylo naopak velmi důležité, aby ani při dlouhodobém uložení neproběhly u zrna nežádoucí změny. Muselo si uchovat schopnost klíčení, aby se dalo využít jako osivo i po letech neúrody a také v ní nesmělo plesnivět, aby zůstalo poživatelné až do nové úrody.

V případě kontejnerové virtualizace, se tyto kontejnery dělí o přidělené prostředky kontejneru ve kterém se nachází. Žádný kontejner, který je součástí jiného kontejneru, tedy nemůže získat víc prostoru a výpočetní kapacity, než než má k dispozici. Názorným příkladem je Matrjoška (tradiční ruská dřevěná hračka). Každá co je uvnitř jiné, je menší a menší. Pokud bychom jich chtěli najednou umístit víc, museli bychom zvolit takovou velikost, aby se dovnitř vešly.

Systém, běžící v rámci kontejneru, se navenek tváří stejně jako kresba, kterou na Matrjošce vidíme. Pokud by ta větší byla vyrobena z průhledného materiálu, viděli bychom – skrze nepomalovaná místa – kresbu té, co je uvnitř.

Kontejnerové stacky a sendviče

Při plné virtualizaci se pracuje s tzv. obrazem disku – „image” což mohou být data vykopírovaná 1:1 z fyzického blokového zařízení utilitou dd 1:1 do datového souboru, který se do virtuálu zpropaguje jako virtuální disk. Používá se u něj stejná tabulka rozdělení diskových oddílů, souborové systémy, a s daty se zachází úplně stejně jako by šlo o fyzické zařízení.

Jádro vidí systémový disk coby kompaktní hromadu datových souborů. Soubor:sandwich.png

U kontejnerové virtualizace ale není nutné emulovat blokové zařízení. Aplikace, která pracuje s obsahem kontejneru využívá služeb hostitele. Nestará se o to, odkud bere, ani kam posílá data, které se ukládají do souboru.

Nemá nejmenší tušení o tom, kolikátou datovou vrstvu matlá na „obraz” který vidí.

Vrstvy

Vrstva (angl. Layer), abstraktní pojem stejně jako kontejner, zastupuje vždy něco, co leží na něčem, resp. nad něčím. Na to jak vypadá má vliv to, je-li základem transparentní (průhledný) materiál, nebo ne.

Je-li neprůhledný, je pro povrchový vzhled podstatné jen to co je nahoře, bez ohledu na to, kolik vrstev na sobě leží, protože ta horní zakryje vše co bude pod ní.

Použijeme-li ale transparentní materiál, na který budeme malovat neprůhlednými barvami. Bude mít na výsledný vzhled vliv každá vrstva. Nejenom ta co leží nahoře. A výsledkem je iluzorní obraz, který bude jiný, pokud dáme na sebe více vrstev v jiném pořadí. A to je princip sendviče.

Soubor transparentních vrstev, u kterého nelze měnit pořadí, protože je vyšší vrstva závislá na tom co je pod ní, je tzv. stoh vrstev (angl. stack). Když jejich pořadí obrátíme, spadne – stejně jak obloha z chlebíčku. Ale sendvič (angl. sandwich) má svůj chutný obsah mezi dvěma chleby, takže ho můžeme obracet jak chceme a pořadí jeho vrstev libovolně měnit.

Pro ilustraci jsem vytvořil schematický obrázek, na kterém chci demonstrovat, proč je sendvič lepší nežli stack.

Při popisu použiju následující konvenci – 1-4 pořadí obrázků zdola nahoru, R (vpravo – right), L (vlevo - left).

Soubor:sandwich-scheme.png

Obrázek 1L představuje to, jak vidí souborový systém aplikace v kontejneru.

Ten se ale ve skutečnosti skládá z více vrstev. V tomto případě jsem pro vizualizaci rozdílů použil tří barev. V zelené vrstvě G (green) na pozici 1R , jsou soubory ze staré distribuce. Na obrázku 2L vidíme, co by měl kontejner k dispozici, pokud bychom mu nabídli jen tuto vrstvu.

V modré vrstvě B (blue), jsou soubory distribuce nové, aktualizované. Na obrázku 3L vidíme, že se toho docela dost mění. Ale co se nemění, jsou konfigurační soubory, které jsou klíčové, proto jsou v samostatné vrstvě žluté Y (yellow), spolu se soubory, které se musí v kontejneru vyskytovat vždy!

Jak je zřejmé z obrázku na pozici 4R, z hlediska objemu dat tahle vrstva není velká, ovšem pokud bychom do kontejneru poslali jenom tu, systém by nefungoval, poněvadž by postrádal většinu z toho co potřebuje k životu.

Pokud překryjeme starou vrstvu G novou vrstvou B, vypadá to schematicky stejně jako na obrázku 3R a přidáme-li navrch vrstvu Y, získáme hotový sendvič G-B-Y (na pozici 5R), který můžeme podávat do kontejneru i na klientské stanice.

Ale co když se ukáže aktualizovaná verze distribučního software problémová? U stacku by nezbylo nic jiného, než se vrátit k původní sestavě G-Y a chybějící aplikace z distribuce nové doinstalovat zvlášť tak jak je naznačeno na obrázku 2R.

U sendviče není problém. Stačí minutka a servírujeme sendvič B-G-Y. Mohli bychom ho také obrátit celý vzhůru nohama, ovšem pak bychom „přeplácli” své konfigurační soubory jejich distribučními verzemi a dopadlo by to jako na obrázku 5L, což je stav, který pravděpodobně nikdo nechce.

Změnou pořadí vrstev sestavených sendviče lze kouzlit.

• Můžeme kombinovat několik konfiguračních vrstev a „servírovat” víceméně identický systém do různých lokalit.
• Můžeme kombinovat několik aplikačních vrstev a provozovat souběžně starší verze aplikací novějšími.
• Můžeme kombinovat specializované vrstvy, specifické pro různé nasazení. Např. podle HW vybavení strojů.
• Můžeme nahrazovat starší verzi distribuce novější, a tím zachovat přístup k distribučním aplikacím, které byly z novější verze distribuce vyřazeny kvůli nesplněným závislostem.

Atd. atd.

Architektura procesoru

Procesor, neboli CPU (z angl. Central Processing Unit – centrální výpočetní jednotka) je elektronický obvod, složený z velkého množství miniaturních elektronických součástek (převážně tranzistorů) umístěných na křemíkové destičce, který zpracovává informace (instrukce) přeložené do strojového kódu.

Instrukce strojového kódu vychází z konstrukce CPU. Jsou-li CPU různých výrobců schopny zpracovávat stejný přeložený strojový kód, ač se jinak konstrukčně liší, hovoříme o tom, že mají stejnou architekturu.

První mikropočítače, které se začaly objevovat v domácnostech od konce 70. let, používaly 8-bitové procesory. Atari (1979) – MOS 6502, ZX81 (1981) který záhy nahradil slavnější Sinclar ZX Spektrum (1982) – Zilog Z80A, Commodore 64 (1982) – MOS 6510.

i386

Do prvních produkčních PC, vyráběných do roku 1981 použila firma IBM 16-bitové procesory firmy Intel (Intel 8086 a od roku 1982 Intel 80286). A prvním procesorem, u něhož byla délka registrů zdvojnásobena na 32-bit byl Intel 80386, vyráběný od roku 1986. Na architektuře tohoto procesoru – i386 – začal vývoj linuxového jádra. A protože od téhle architektury byly odvozeny i další, výkonnější procesory dostala jméno x86

amd64

Na 64 bitovou délku registru přešla jako první fa. AMD – odtud amd64 – ale instrukční sada zůstala beze změn, takže se název architektury rozšířil na x86_64

Pro vývoj CPU této architektury byla významná honba za co nejvyšším výpočetním výkonem CPU, kterí nebrala ohled na energetickou spotřebu. Ale u mobilních zařízení a velkých datacentrech, jejichž expanze začala s nástupem internetu a mobilního internetového připojení kolem roku 2000 se začaly víc a víc uplatňovat procesory ARM, které sice byly z hlediska výkonu slabší, než procesory odvozené od architektury x86 a amd64, ale v poměru výkon/spotřeba výhodnější.

arm64

Zlomový okamžik přišel v roce 2020, kdy fa. Apple představila notebooky MacBook Air a MacBook Pro s 64-bitovým procesorem M1 architektury ARM, který nabídnul srovnatelný výpočetní výkon a jako bonus mnohem delší výdrž na baterii než kterýkoliv jiný konkurenční stroj.

Emulátory a binární překladače

Emulátor je software, který dokáže simultánně překládat a posílat ke zpracování do fyzického CPU instrukce strojového kódu určené původně pro CPU jiné architektury.

Mac OS na x86_64 – Rosetta

Takový překladač si nechala vyvinout od fy. Transitive Corporation fa. Apple, která ve svých strojích původně používala procesory PowerPC (architektura ppc), když se rozhodla od roku 2006 přejít na tehdy výkonnější procesory Intel (achitektura x86_64). Binární emulátor, který pro starší software překládal instrukce určené původně pro PowerPC tak, aby jim rozuměl Intel dostal název Rosetta a byl používán od roku 2006 (Mac OS X 10.4.4 Tiger) až do roku 2011 (Mac OS X 10.6.8 Lion).

Mac OS na arm64 – Rosetta 2

Novějších verze už ho nepotřebovaly, ale od roku 2020 kdy Apple začal nabízet stroje s ARM64 procesorem M1, se stal binární překladač (tentokrát instrukcí určených pro CPU architektury x86_64) opět součástí operačního systému Mac OS, pod názvem Rosetta 2. Od Mac OS Ventura v.13 lze přes něj spouštět i linuxové binárky a od Mac OS Sequoia v.15 umí emulovat také AVX2 instrukce novějších procesorů fy. Intel.

x86 – Bochs

Prvním a nejstarším emulátorem na architektuře x86 je Bochs, vyvíjený od roku 1994 – původně jako komerční aplikace. V březnu 2000 jej odkoupila forma MandrakeSoft, která ho uvolnila jako open source. Později se objevily další, protože umožnily dál používat software, který byl původně vytvořen pro již zastaralé, méně výkonné architektury.

QEMU

V linuxovém prostředí existuje celá řada emulátorů. Nejpoužívanější je nejspíš QEMU, které umožňuje emulovat nejenom CPU, ale také hardware. Emulace pochopitelně snižuje celkový výkon, ale to obvykle nevadí, protože se emulace QEMU využívá především k vývoji software pro systémy, které by samy o sobě svým výkonem CPU nároky vývojového prostředí neutáhly.

ARM

Procesory architektury ARM se začaly prosazovat v širším měřítku od roku 2012 kdy britská nadace Raspberry Pi Foundation, aby podpořila výuku informatiky ve školách, zafinancovala vývoj malého, laciného jednodeskového počítače, pro který mohli studenti psát aplikacem jejichž prostřednictvím se daly ovládat různá domácí elektronická zařízení (např. mikrovlnná trouba, automatická pračka, aj.) Osazen byl 32-bitovým ARM procesorem BCM2835 od firmy Broadcom.

Nástup Raspberry Pi iniciovalo vývoj linuxových emulátorů architektury x86 na architektuře ARM.

Box64

64-bitový ARM procesor se na těchto deskách používá až od roku 2020 – první bylo Raspberry Pi 4 Pro, se SoC typu BCM2711 – ARM Cortex-A72

FEX-emu

Byl inspirován aplikací Rosetta 2