Tā kā Docker konteineri tiek izmantoti plašāk, kļūst skaidrāki arī to trūkumi. Kā, piemēram, varat migrēt darbojošos konteineru kopā ar tā datiem uz citu serveri un saglabāt tā datus procesā? Parasti jūs to nedarāt.
ClusterHQ, startēšanai, kuru daļēji dibinājuši Python Twisted tīkla dzinēja galvenie līdzstrādnieki, ir piedāvāts risinājums. Flocker, Dockerized lietojumprogrammu atvērtā pirmkoda (Apache) datu apjoma pārvaldnieks, kas tagad ir pieejams 1.0 laidienā, ļauj datu apjomus (jeb datu kopas) saistīt ar konteineriem un pārvietot ar tiem.
Turot to visu kopā
Flocker apvieno konteinerus un datu kopas, nodrošinot, ka tie pārvietojas kopā ikreiz, kad Dockerized lietojumprogramma tiek pārslēgta starp saimēm noteiktā klasterī. Vienīgais ierobežojums ir tāds, ka datu krātuve jānodrošina koplietojamas krātuves aizmugurē, kas ir pieejama visiem klastera mezgliem.
Šobrīd tiek atbalstīti tikai daži glabāšanas aizmugures veidi, galvenokārt orientēti uz mākoņiem: Amazon EBS, Rackspace Cloud Block Storage un EMC ScaleIO. Tiek atbalstīta arī uz ZFS balstīta krātuve, kaut arī tikai ar aizmuguri, kas pašlaik ir eksperimentāla.
"Viss, kam izmantojat VMware vMotion," teica ClusterHQ izpilddirektors Marks Deiviss, "ir tie paši iemesli, kāpēc jūs varētu vēlēties pārvietot konteineru apkārt. Un, ja konteinerā ir dati, jums ir nepieciešams kaut kas līdzīgs Flocker."
Tas nozīmē, ka viena vMotion iezīme - darbojošos lietotņu tiešā migrācija - vēl nav īsti Flocker. Tā migrācija ir "minimāls dīkstāves laiks", nevis nulle dīkstāves, kas nozīmē, ka migrācijas procesā ir mazs nepieejamības logs. Luke Marsden, CTO un ClusterHQ līdzdibinātājs, telefona zvanā paziņoja, ka dīkstāves laiks ir "atkarīgs no ātruma, ar kādu aizmugures gala skaļums var tikt atdalīts no viena VM un piestiprināts pie cita VM. Bet mūs ļoti interesē samazinot dīkstāvi. "
ClusterHQ jau ir eksperimentālas funkcijas, lai paātrinātu procesu, izmantojot apjoma momentuzņēmumus, lai gan aizmugurē ir jāatbalsta momentuzņēmumi, lai tas būtu dzīvotspējīgs.
Trūkstoši dokera gabali
Docker tradicionāli ir strādājis ar datiem, izmantojot datu apjomus, taču tiem ir savi ierobežojumi. Datu manuāla kopēšana starp konteineriem joprojām nav vienkārša (tas, iespējams, ir fiksēts Docker 1.7 versijā), taču lielākā siena joprojām ir slikta datu pārvaldības pakāpe datiem, kurus koplieto Docker konteineri, kas darbojas dažādās vietās.
Viens no pašreizējiem Docker priekšlikumiem paredz jauna veida krātuves pieejamību konteineriem, kur trešās personas var nodrošināt ierīču draiverus saviem krātuvju veidiem. Ja šāda funkcija tiktu ieviesta, ClusterHQ nebūtu grūti pārstrādāt atbalstu, izmantojot datu kopas aizmugures spraudņu arhitektūru - un laika gaitā spert soli priekšā jebkurai funkcionalitātei, kas tiek iekļauta paša Docker kodolā.
