[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Kolab / Complex Distributed Application in OpenShift


Please allow me to briefly introduce myself and the product development I'm involved with / responsible for;

My name is Jeroen van Meeuwen and I am the Systems Architect for Kolab Systems -- the ISV for the Open Source groupware solution & collaboration suite Kolab. Long story short, Kolab Systems is involved with a push for ISV partners in the Enterprise ecosystem to get involved in the adoption and further development of Container-based Distributed Applications.

Kolab Groupware consists of a long series of "micro-services", which differentiates it from most other applications (I have so far found to be on board the containing micro-services wagon). To illustrate but a few aspects, there's about 8 separate end-point web-services, and some 19 other micro-services (ranging from SMTP on port 25 to ManageSieve on port 4190, and sometimes the same service with a different role, such as "inbound", "internal" and "outbound" mail exchangers).

For your reference, I have attached a diagram of what I currently think the connection model between containers might look like -- translating traditional virtualization using guests almost 1:1.

While I am new to OpenShift, I realize that it may not necessarily be geared towards running this sort of application or application suite (in this way), and/or not all my questions have ready-to-go answers to run with. I am therefore currently focussing on OpenShift v3, which is where I believe most of your focus is as well, so that should (you consider) OpenShift be able to serve the use-case, we can collaborate in development of the necessary pieces that may be lacking or insufficiently suitable, if any.

In an initial attempt to containerize Kolab Groupware, using the all-in-one OpenShift v3 deployment depicted in [1], I've run in to a number of problems/questions/challenges I would appreciate some insight on -- in order of priority;

== LDAP ==

For obvious reasons, Kolab Groupware is dependent on a centralized authentication and authorization database -- preferably LDAP, and preferably 389 or Red Hat Directory Services at that, possibly (Free)IPA.

Either service's setup procedure depends on an FQDN that resolves forwards and backwards, yet Docker containers normally have a hostname without a domain name space (the hostname being the container ID, specifying the -h option on the command-line sets the hostname).

As far as I'm aware, it is not possible to set a domain name space in OpenShift, and it's not possible to set a container's FQDN in OpenShift either. From where I'm sitting, having gotten only as far as this, this prevents Directory Services from being deployed as part of an OpenShift v2 cartridge / v3 template.

== Storage Persistence ==

The life-cycle of a single container being of such a relatively short period of time, I'm looking to manage a level of storage persistence; volumes such as /srv/{dirsrv,mysql,imap} come to mind.

In a regular Docker environment, this has required me to create a "data-only container", which is then to separately be attached to each container (a cycled container gets a new container ID). I currently do something like this from a scratched Docker container environment:

# Initialize the data container from a data-only image:

	docker run -i --name kolab_ldap_data -t kolab/ldap-data

# Use that (named) data container:

	docker run --volumes-from kolab_ldap_data --name kolab_ldap \
		-h ldap.example.org -t kolab/ldap

I'm not sure how this translates to OpenShift (v3), as while I have found that the persistence layer is provided through an OPENSHIFT_DATA_DIR environment variable pointing to some persistent storage (right?), it seems to not translate to a mount-point or static container-local filesystem hierarchy I can consistently refer to from within the container (it would be /home/$magic/someplace/ rather than /srv/dirsrv/)?

== Inclusion of Other Cartridges / Templates ==

How would I specify that a micro-service (in my cartridge (v2) or template (v3)) requires another micro-service (that may better be provided by a third-party cartridge/template)?

Case in point #1: While I'm perfectly willing to entertain supporting various database technologies, I would rather choose one of the existing Cartridges / Templates if/when they are/become available.

When 5 out of 8 "micro-services" (separate end-point web-services in this case) require database services for caching and user preferences, and would (in an optimal scenario) use the same database rather than different ones, how would I go about specifying each "micro-service" requires a database service yet end up with the one database service for all to consume?

Case in point #2, slightly different: Should "RHDS" become available as a micro-service in OpenShift, how might third party application(s) (suites) be able to utilize such micro-service when LDAP schema extensions need to be loaded?

== Run-time Configuration / Dependencies ==

In a Cyrus IMAP discrete Murder topology, frontends receive the client's connections, and backends hold the IMAP mailboxes. When a new mailbox is created, the frontend depends on a configured 'serverlist' to establish what backend the new mailbox may be created on -- different policies describing the conditions under which to select the one or another backend exist.

In this way, the list of servers, all hostnames or FQDNs of backends, is a run-time and therefore dynamic list of servers. There are various other places where configuration is dependent on the run-time environment details, however most of these include the types of option value to the groupware solution I'm not necessarily required to entertain (yet).

I've yet failed to understand how this type of orchestration would be performed in OpenShift / Kubernetes.

Please don't hesitate to ask for more information where needed,

Thank you for listening and thanks in advance for your insights,

Kind regards,

Jeroen van Meeuwen

[1] https://blog.openshift.com/openshift-v3-deep-dive-docker-kubernetes/

Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +41 79 951 9003
w: http://www.kolabsys.com

pgp: 9342 BF08

Attachment: graphviz-1a2ffb297f47e6d9e7f04578bad417fa781b2592.png
Description: PNG image

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]