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:
- DCTM 7.3 PostgreSQL with Docker install guide
- Full docker CS7.3 PostgreSQL + D2 4.7 installation guide
There are also two interesting things:
- 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 🙂
- 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 3ba6af536629112fcc006ad68e280222c44b1ed73e2be34d7379f04e3f753c76 [root@rhel73docker01 ~]#
actually, it is also required to map log directory and directories, containing dfc.properties and dfc.keystore files (dfc.config.dir and dfc.data.dir), 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 dfc.data.dir outside of container (surprisingly, EMC implemented that in case of D2, though the values of dfc.data.dir 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:
- it seems that Docker experiences difficulties with NFS-volumes
- it is a challenge to add new volume to the running Docker container
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.