Good day, @simos proffered the information that clustering is up and coming in the thread “Start container from container dir” - - - so I followed the link to read (and hopefully understand!).
Under the heading - - ‘Interactively’ is the following:
“You can now join further nodes to the cluster. Note however that these nodes should be brand new LXD instances, or alternatively you should clear them up before joining, since any existing data on them will be lost.”
Hopefully questions are not overly premature!
Reading the above it seems to me that I cannot set up a cluster from existing containers.
Please advise.
(Logic flow here: if I could create clusters from pre-existing containers then I could have a group of containers who either can be grouped into, or not, a cluster. This (my thinking at least) would promote having a cluster of x containers which together might form a LAPP server but if I wanted to add another container that had a functioning Nginx server that I could transform that cluster into a higher volume handler. Further I could have a couple different ‘servers’ (grouped containers) setup and shift the add in Nginx server into or out of the clusters as demand required. Colvoluted, perhaps, but my projects here are steadily growing more complex and so I’m always exploring the fringes of ‘what’s possible’ - - rueful grin!)
I’ll let Stephane say the final word, but here’s my take.
Regarding turning an existing LXD instance with running containers into a new node of a cluster, you’re reading is correct: it’s not currently possible. You can however create a brand new LXD instance, join a cluster as empty node, and use “lxc copy” or “lxc move” to migrate your existing containers to the new node.
Regarding having different clusters for different classes of containers (that you referenced as ‘servers’ or ‘grouped containers’), if we ever get that feature it would make more sense to introduce the concept of “service” in a LXD cluster. You’d have only one cluster for all your containers, regardless of the service they are meant to be part of, and LXD would let you define those services in the model as first-class citizens (e.g. initially it could be as simplistic as having a custom “service tag” attached to each container. As a matter of fact, you can actually already implement such bookkeeping externally, using the “lxc config” command line client or the LXD REST API (you can already attach custom config key/value pairs to a container, which you can use to add matadata such a “service” tag).
In any case, the scope of LXD clustering at this stage is not so much becoming a container orchestrator, but rather to let you interact with a pool of per-machine LXD instances as if they were a single LXD instance, with added value in terms of administration convenience and fault tolerance. Full blown orchestration features would get into Kubernetes territory, which for now is not a goal.
From what I remember of the initial design doc, it stated that we wouldn’t allow non-empty LXD servers to join a cluster as merging existing entries with the cluster would be rather difficult.
It however did allow (and might have directly mention) that the first cluster member would be able to retain all its containers and configuration as there is no such merging problems in that case, it should just be a couple of DB updates to turn a standalone node into the first member of a cluster.