Docker challenge

This blogpost is a follow-up for Think soberly. Is it hard? blogpost – that time it was unclear what ECM was going to do with docker (though, I was suspecting that nothing good would happen), so there was nothing to discuss, now EMC has released something and we are able to discuss pros and cons of their “solution”. It is also worth noting following blogposts related to impartial user experience:

There are also two interesting things:

  1. All this Docker stuff somehow relates to DevOps activities, and I used to be a DevOps from 2005 to 2008 – long before it became a mainstream 🙂
  2. Linux Containers are not something new or extraordinary – I already mentioned that in Docker and Documentum. Part I blogpost – just a couple of guys decided to promote this concept to a mainstream and created OOTB solution

So, why containers?

There is only one correct answer for this question: we have a lot of similar configuration items and want to automate their maintenance routines, moreover, we do think that maintenance overhead introduced by containers won’t exceed overheads introduced by other techniques. The problem is there is no clear boundary when containers are good and when they are harm, but it is important to understand that containerized environment is not a goal – it is an instrument. Let’s elaborate this point.

Imagine we are a hosting provider and we host a lot of php (potentially insecure) websites, and our goals are:

  • provide resources to customers according to their plan
  • provide enough flexibility to customers, e.g. customers are able to configure http-server
  • isolate customers from each other
  • do not use virtualisation due to overheads

Is it a Docker case? For sure yes!

Now, imagine that we are a software development company and our goal is to automate SDLC routines, for example, we want to test our product against different versions (and implementations) of third-party software, moreover, we want to test both releases and patches/hotfixes.

Is it a Docker case? For sure yes! Moreover, I pursue this case only.

Again, imagine that we are a software development company and our goal is to provide demo-version of our software for potential customers, i.e. we are interested that any potential customer might be able to evaluate our software immediately without reading tons of useless manuals.

Is it a Docker case? I’m not sure – I would prefer to build virtual machine for sober customers and docker image for geeks – just to follow a mainstream 🙂

Now, imagine that we are a customer, and have spent last money for Documentum, we have production environment and, may be, a test/uat environment.

Is it a Docker case? For sure not!

Now, about official Documentum Docker images

What EMC is doing is nailing screws using hammer 🙂 They understand neither applicability of Docker, nor the technology. Let’s provide some examples.

Below is a part of Alvaro’s blogpost:

Note, that it does not fit to a one screen and seems to be incomplete and wrong, due to following considerations:

  • “Docker image with Documentum Administrator” sounds completely ridiculous – apache tomcat perfectly fits “containerization concept” and the only correct way to run java-application inside Docker container is:
    [root@rhel73docker01 ~]# docker run -d -h webtop68dev01 \
    > -v /u01/distr/webtop-6.8-0000.0286.war:/usr/local/tomcat/webapps/webtop.war:ro \
    > tomcat:8.0
    [root@rhel73docker01 ~]# 

    actually, it is also required to map log directory and directories, containing and dfc.keystore files (dfc.config.dir and, but the whole idea, I believe, is absolutely clear – just one shell command to run a container

  • it is absolutely not clear how to manage this Docker image in distributed environment: EMC has written some bootstrap procedure, where I need to setup DOCBROKER_IP and DOCBROKER_PORT parameters, what am I supposed to do when I have multiple content servers? It is absolutely clear that I should place the contents of dfc.config.dir and outside of container (surprisingly, EMC implemented that in case of D2, though the values of and dfc.tokenstorage.dir parameters in Alvaro’s blogpost seem to be wrong)

As regards to Content Server, there is nothing to discuss thoroughly – their scripts are a mess. The only thing I want to discuss in this context is an applicability of Docker containers for Content Server.

I do believe that new technologies must accumulate previously received knowledge and best practices, for example, in case of Content Server I do think that the best storage option is a NAS appliance with 1-2Tb volumes, unfortunately, it seems that Docker engine experiences difficulties with such setup:

Summarising two previous issues it gets clear that if I want to implement my best practices I need manage NFS-volumes inside Docker container(s), yes, it is possible, but requires to run extra services inside container (rpcbind, portmapper, rpc.statd and rpc.lockd), which, no doubts, complicates my environment. But the problem here is not a fact that I have found an extremely specific case which does not fit Docker environment well (I can provide more), the problem is that EMC didn’t find/describe it – all what we have is a set of smelling shell scripts which do “something” and customers are supposed to guess what those scripts do and what will work and what will not.

Docker and Documentum. Part III

If my memory serves me right, last time I promised to demonstrate how it is possible to maintain networking in Docker environment, but didn’t keep that promise. Actually, I realised that using any kind of external tools to maintain networking in Docker environment is completely impractical and decided to wait for native support of “static” ip-address assignments in Docker. And finally, Docker team released this capability in 1.10. Cool.

If you are going to use Docker it is good idea to consider following suggestions:

Surprisingly, Documentum installer 7.2 does not support Oracle XE (latest Oracle XE version is, lowest Oracle version supported by Documentum installer 7.2 is, hopefully, I was able to manage this mistake.