Καθώς τα δοχεία Docker χρησιμοποιούνται ευρύτερα, τα μειονεκτήματά τους καθίστανται επίσης πιο ξεκάθαρα. Πώς, για παράδειγμα, μεταφέρετε ένα τρέχον κοντέινερ μαζί με τα δεδομένα του σε έναν άλλο διακομιστή και διατηρείτε τα δεδομένα του στη διαδικασία; Συνήθως, δεν το κάνετε.
Το ClusterHQ, μια εκκίνηση που ιδρύθηκε εν μέρει από βασικούς συνεργάτες του κινητήρα δικτύου Python Twisted, έχει μια προτεινόμενη λύση. Το Flocker, ένας διαχειριστής όγκου δεδομένων ανοιχτού κώδικα (Apache) για εφαρμογές Dockerized που βρίσκεται τώρα στην κυκλοφορία του 1.0, επιτρέπει τον όγκο δεδομένων (γνωστά και ως σύνολο δεδομένων) να συσχετίζονται με κοντέινερ και να μετακινούνται μαζί τους.
Διατηρώντας τα όλα μαζί
Το Flocker ομαδοποιεί κοντέινερ και σύνολα δεδομένων, διασφαλίζοντας ότι κινούνται μαζί κάθε φορά που μια εφαρμογή Dockerized τερματίζεται μεταξύ κεντρικών υπολογιστών σε ένα συγκεκριμένο σύμπλεγμα. Ο μόνος περιορισμός είναι ότι η αποθήκευση για τα δεδομένα πρέπει να παρέχεται από ένα κοινόχρηστο πίσω μέρος αποθήκευσης προσβάσιμο σε όλους τους κόμβους του συμπλέγματος.
Προς το παρόν υποστηρίζονται μόνο μερικοί τύποι back end, κυρίως προσανατολισμένοι στο cloud, Amazon EBS, Rackspace Cloud Block Storage και EMC ScaleIO. Υποστηρίζεται επίσης χώρος αποθήκευσης που βασίζεται σε ZFS, αν και μόνο μέσω ενός back end που είναι επί του παρόντος πειραματικό.
"Οτιδήποτε θα χρησιμοποιούσατε το VMware vMotion", δήλωσε ο Mark Davis, Διευθύνων Σύμβουλος του ClusterHQ, "είναι οι ίδιοι λόγοι για τους οποίους μπορεί να θέλετε να μετακινήσετε ένα κοντέινερ. Και αν ένα κοντέινερ έχει δεδομένα σε αυτό, χρειάζεστε κάτι σαν το Flocker."
Τούτου λεχθέντος, ένα τεράστιο χαρακτηριστικό του vMotion - ζωντανή μετεγκατάσταση εφαρμογών που εκτελούνται - δεν υπάρχει ακόμη αρκετά στο Flocker. Οι μετεγκαταστάσεις του είναι "ελάχιστος χρόνος διακοπής" και όχι μηδενικός χρόνος διακοπής, που σημαίνει ότι υπάρχει ένα μικρό παράθυρο μη διαθεσιμότητας κατά τη διαδικασία μετεγκατάστασης. Ο Luke Marsden, CTO και συνιδρυτής της ClusterHQ, δήλωσε σε ένα τηλεφώνημα ότι ο χρόνος διακοπής "εξαρτάται από την ταχύτητα με την οποία το πίσω άκρο μπορεί να έχει έναν όγκο να αποσυνδεθεί από ένα VM και να συνδεθεί με ένα άλλο VM. Αλλά ενδιαφερόμαστε πολύ για ελαχιστοποιώντας αυτό το χρόνο διακοπής. "
Το ClusterHQ έχει ήδη πειραματικά χαρακτηριστικά για να επιταχύνει τη διαδικασία μέσω στιγμιότυπων όγκου, αν και το πίσω μέρος πρέπει να υποστηρίζει στιγμιότυπα για να είναι βιώσιμο.
Λείπουν κομμάτια του Docker
Το Docker έχει παραδοσιακά συνεργαστεί με δεδομένα μέσω όγκων δεδομένων, αλλά έρχονται με τους δικούς τους περιορισμούς. Η μη αυτόματη αντιγραφή δεδομένων μεταξύ κοντέινερ δεν είναι ακόμα απλή (φέρεται να διορθώνεται στο Docker 1.7), αλλά ο μεγαλύτερος τοίχος παραμένει η κακή κατάσταση διαχείρισης για δεδομένα που κοινοποιούνται από κοντέινερ Docker που εκτελούνται σε διαφορετικές τοποθεσίες.
Μια τρέχουσα πρόταση για το Docker περιλαμβάνει τη διάθεση ενός νέου τύπου αποθήκευσης σε κοντέινερ, όπου τρίτα μέρη μπορούν να παρέχουν προγράμματα οδήγησης συσκευών για τους δικούς τους τύπους αποθήκευσης. Εάν εφαρμοζόταν ένα τέτοιο χαρακτηριστικό, δεν θα ήταν δύσκολο για το ClusterHQ να επεξεργαστεί εκ νέου την υποστήριξή του μέσω της αρχιτεκτονικής plug-in back-end του συνόλου δεδομένων - και να συνεχίσει ένα βήμα μπροστά από ό, τι η λειτουργία μεταφέρεται στον πυρήνα του Docker με την πάροδο του χρόνου.
