Somebody mentions to me that “struggles” may be a big word for such a small problem, and that mentioning Nulecule in the same breath may not be fair at all.
That person, Joe Brockmeier, is correct, and I hereby pledge to buy him a beer — as I know Joe loves beer — does FOSDEM work for you Joe?
My earlier blog post did not give you any insight on what, how or why I struggled with Nulecule, nor whether the struggle is with Nulecule specifically or orchestrating too many containers with few too many micro-services as a whole.
My Nulecule application is Kolab — the full application suite. It depends on a number of other applications which are principally valid Nulecule applications in their own right. Examples include MongoDB, MariaDB, PostgreSQL, HAProxy, 389 Directory Services, FreeIPA, and such and so forth.
Some of these have existing Docker images. Nulecule applications are available for some of these, or are easily made in to Nulecule applications. Some are slightly harder to encapsulate however, and I’ll take one example to illustrate the point; 389 Directory Server.
Complex and Custom: 389 DS
A default 389 Directory Server installation falls just short of what Kolab requires or desires to become fully and properly functional;
- Schema extensions provide additional functionality,
- Anonymous binds should not be allowed,
- ACLs should be more restrictive,
- Better passwords should be allowed than only 7-bit ones,
- Access logging is I/O intensive and less important than Audit logging,
- Additional indexes on attributes included in the schema extensions need to be created,
- Service- and Administration accounts and roles need to be created.
To facilitate this particular form of setting up 389 Directory Server, we currently ship our own version of /usr/share/data/dirsrv/template.ldif, in which we substitute some values during initial startup.
With these specifics, how would I first create a generic Nulecule application for 389 Directory Server and then extend it? This is a philosophical question I think deserves answering but probably requires a lot of deliberation.
Multiple Instances of a Nulecule Application
In another area of my application suite, 6 of my micro-services require a database — MariaDB. The challenge here is three-fold;
Atomicapp collects the configuration data required for the Nulecule applications by application graph name only, and the position of the application in the graph is discarded. This is to say that application A and B both requiring application C would have one combined configuration section for the application C, which is then to be utilized for both A and B.
Furthermore, the Nulecule application for MariaDB (the case in point) creates pods and services all of them named “mariadb” — but there can be only one (per namespace). The creation of the second pod or service will fail. I would use ‘generateName’ for the pod and service name, but that is not currently supported. Therefore, this restriction applies to all Nulecule applications and not just MariaDB. My way to work around this restriction for now, is to fork off mariadb-centos7-atomicapp and substitute its id and name parameters.
The third part of the problem is the level of customization that may be recommended for a MariaDB service; the maximum size of allowed packets, the use of one file per table in InnoDB, buffer sizes, cache sizes, etc., etc. An external Nulecule application should come with the best run-time defaults, and allow for a level of customization by the consuming application. Frankly, the same goes for the 389 Directory Server application I talked about earlier — it would just function differently.
Focus on Priorities
I’m relatively new to both the Atomic and Nulecule development communities, despite spending time with a select group of people in Red Hat’s Westford offices last year, so I can only say so much.
A number of the conversations on mailing lists and IRC and in meetings today evolve around integrating atomicapp’s and atomic’s command-line interfaces, whether or not Nulecule applications should or have to ship atomicapp code themselves. These are not unimportant topics and may very well need to be addressed sooner rather than later, or risk they become a sink-hole we later need to climb out of. Fair enough.
However, these topics dominate the conversation. It seems a disproportionate amount of resources is being spent on them, whereas we lack persistent volume configuration for Nulecule applications, duplicate specifications, settings and configuration items, and lack proper support to deploy most things more complex than a web service with a database — which is not to say it is completely impossible, it’s just needlessly difficult.
I believe the best way it can be made easier to develop and deploy Nulecule applications is to walk people through in clearly articulated, documented show-cases of example applications, every one slightly more complex than the last one. Part of the ramp-up cost is to learn about setting up the necessary systems and how to do anything not already an example. I will probably get more involved in these topics to support my team of developers when the time is right.