VM - Specifikace kontejneru pro integraci #301

New Issue

2018-10-04T10:07:26+02:00

Podhorecky commented

2018-10-04 10:07:26 +02:00

(Migrated from git.spotter.cz)

Dotaz: pomohlo by mít závazné parametry nebo rozsahy parametrů kontejneru, který by se dal integrovat do VM?

Šlo by tím umožnit rychlejší (teoreticky snadnější) integraci různých SW-kontejnerů do blízkosti jiných kontejnerů? Navrhnout pravidla. Možná nějaké doporučení na vnitřní strukturu, porty pro vnější komunikaci, očekávané nastavení od ostatních kontejnerů, od VM , ...? Podobně jako u kubernetes? https://kubernetes.io/docs/setup/minikube/ Na K. jsem se kdysi ptal, tehdy jsem si myslel, že to je privátní Google sw, pak už jsme se k tomu nevrátili, ...

Samozřejmě řešme co je koncepčně možné a integrovatelné.

Dotaz: pomohlo by mít závazné parametry nebo rozsahy parametrů kontejneru, který by se dal integrovat do VM? Šlo by tím umožnit rychlejší (teoreticky snadnější) integraci různých SW-kontejnerů do blízkosti jiných kontejnerů? Navrhnout pravidla. Možná nějaké doporučení na vnitřní strukturu, porty pro vnější komunikaci, očekávané nastavení od ostatních kontejnerů, od VM , ...? Podobně jako u kubernetes? https://kubernetes.io/docs/setup/minikube/ Na K. jsem se kdysi ptal, tehdy jsem si myslel, že to je privátní Google sw, pak už jsme se k tomu nevrátili, ... Samozřejmě řešme co je koncepčně možné a integrovatelné.

Disassembler commented

2018-10-06 10:08:28 +02:00

(Migrated from git.spotter.cz)

Detaily funkce distribučního a balíkovacího systému jsem před chvílí vymačkal do https://git.spotter.cz/Spotter-Cluster/Spotter-Cluster/issues/290#note_1868 .

Co se týká nějakých konkrétních záležitostí, které musí splňovat samotný aplikační kontejner, napadá mě teď akorát že aplikace musí být přístupná na portu 8080. Jinak si drtivou většinu integračních záležitostí řeší VM manager sám nebo mu jsou předhozeny v konfiguracích při instalaci balíku (přidělování adres, závislosti mezi kontejnery atd.), takže většina požadavků, které musí maintainer řešit nejsou pro kontejner nebo aplikaci samotnou, jako spíš pro způsob instalace a integrace do vnitřního prostředí VM (metadata, konfigurace mountů, stop/start skripty atd.). Možná budou ještě nějaké další požadavky, které si neuvědomuji, protože je beru jako samozřejmost. Popřemýšlím nad tím při výrobě dokumentace.

Kubernetes je tzv. orchestrátor. To je pro naše účely, stejně jako většina Dockeru, zbytečné. Takové věci se hodí, kdybychom chtěli mít cloud model. Orchestrator se pak napíchne na jednotlivé hostitele a kontejnery a můžeme vesele nasázet dvacet instancí Sahany, každou pro jednu NGO. My ale pracujeme s konceptem, kdy máme jednotlivá aplikační prostředí ucelená a pouze v jediné kopii na jedné VM. Konceptuálně to tedy spíš připomíná hypervizor a jednotlivé VM než orchestrátor a jednotlivé aplikace.

Detaily funkce distribučního a balíkovacího systému jsem před chvílí vymačkal do https://git.spotter.cz/Spotter-Cluster/Spotter-Cluster/issues/290#note_1868 . Co se týká nějakých konkrétních záležitostí, které musí splňovat samotný aplikační kontejner, napadá mě teď akorát že aplikace musí být přístupná na portu 8080. Jinak si drtivou většinu integračních záležitostí řeší VM manager sám nebo mu jsou předhozeny v konfiguracích při instalaci balíku (přidělování adres, závislosti mezi kontejnery atd.), takže většina požadavků, které musí maintainer řešit nejsou pro kontejner nebo aplikaci samotnou, jako spíš pro způsob instalace a integrace do vnitřního prostředí VM (metadata, konfigurace mountů, stop/start skripty atd.). Možná budou ještě nějaké další požadavky, které si neuvědomuji, protože je beru jako samozřejmost. Popřemýšlím nad tím při výrobě dokumentace. Kubernetes je tzv. *orchestrátor*. To je pro naše účely, stejně jako většina Dockeru, zbytečné. Takové věci se hodí, kdybychom chtěli mít cloud model. Orchestrator se pak napíchne na jednotlivé hostitele a kontejnery a můžeme vesele nasázet dvacet instancí Sahany, každou pro jednu NGO. My ale pracujeme s konceptem, kdy máme jednotlivá aplikační prostředí ucelená a pouze v jediné kopii na jedné VM. Konceptuálně to tedy spíš připomíná hypervizor a jednotlivé VM než orchestrátor a jednotlivé aplikace.

Podhorecky commented

2018-10-15 11:14:16 +02:00

(Migrated from git.spotter.cz)

changed milestone to %4

Podhorecky commented

2019-04-15 01:06:59 +02:00

(Migrated from git.spotter.cz)

closed

Podhorecky commented

2019-04-15 01:21:31 +02:00

(Migrated from git.spotter.cz)

changed milestone to %3

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Disassembler/Spotter-VM#301