VM - Specifikace kontejneru pro integraci #301
Labels
No Label
app-basic
app-ckan
app-crisiscleanup
app-cts
app-decidim
app-dhis2
app-frontlinesms
app-gnuhealth
app-kanboard
app-mifosx
app-motech
app-odoo
app-opendatakit
app-pandora
app-sahana
app-seeddms
app-sigmah
app-taarifa
app-ushahidi
critical
CZ
documentation
Doing
enhancement
GMaps
info
Mapbox
needinfo
new-app
OSM
performance
QGIS
regression
suggestion
To Do
upstream
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Spotter-Cluster/Spotter-VM#301
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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é.
Detaily funkce distribučního a balíkovacího systému jsem před chvílí vymačkal do Spotter-Cluster/Spotter-Cluster#290 (comment) .
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.
changed milestone to %4
closed
changed milestone to %3