InterSystems and containers

Question

Question

Dmitry Maslennikov · Nov 24, 2016

#Containerization #Continuous Integration #Docker #System Administration #Caché

Just curious how many companies use in their work Docker containers, I mean not only with InterSystems products. And if such companies exist, which of them uses docker and doesn't use it for InterSystems products by some reasons. What are the reasons? For companies which already uses InterSystems in containers, how do you use it? Development environment, testing or even in production ?

And if you don't use but thought about it, what are the reasons which stop you.

As for me, I've been using InterSystems Caché inside a Docker container in some different cases:

To test new FieldTest version, without installation. Just to build and run, quite easy.
In development, for open source projects, or in my current company. I have not used it in production, our project are not ready for production yet. But I'm already using docker for testing and building our application with Gitlab-ci.

Discussion (2)0

Log in or sign up to continue

Timur Safin · Nov 24, 2016

Docker is cool way to deploy and use versioned application, but, IMVHO, it's only applicable for the case when you have single executable or single script, which sets up environment and invoke you for some particular functionality. Like run particular version of compiler for build scenario. Or run continious integration scenario. Or run web front-end environment.

1 function - 1 container with 1 interactive executable is easy to convert to Docker. But not Cache, which is inherently multi-process. Luca has done a great thing in his https://hub.docker.com/r/zrml/intersystems-cachedb/ Docker container where he has wrappee whole environment (including control daemon, write daemon, journal daemon, etc) in 1 handy Docker container whith single entry point implemnted in Go as ccontainrmain but this is , hmm, ... not very effecient way to use Docker.

Containers is all about density of CPU/disk resources, and all the beauty of Docker is based upon the simplicity to run multiple user at the single host. Given this way of packing Cache' configuration to the single container (each user run whole set of Cache' control processes) you will get the worst scalability.

It would be much, much bettrer, if there would be 2 kinds of Cache' docker containers (ran via Swarm for example) where ther would be single control container, and multiple users containers (each connecting to their separate port and separate namespace). But, today, with current security implementation, there would be big, big problem - each user would be seeing whole configuration, which is kind of unexpected in the case of docker container hosting.

Once, these security issues could be resolved there would be effeciet way to host Cache' under docker, but not before.

1 0

score 2 · Answer 1 · 2016-11-24T08:11:08-05:00

Mostly disagree with your opinion. Docker is a good way for microservices, and docker it is not just one container, in most cases, you should use a bunch of them, each as a different service. And in this case, good way to control all this service is docker-compose. You can split your application into some different parts, database, frontend, and some other services.

And I don't see any problems, in such way, when InterSystems inside one container, with application's database. And the power of docker is you can run multiple copies of the container, at once, when it will be needed. I see only one problem here, is separated global buffer, it means that it used not efficiently. Can you give an example different way with the different database server? I've tried some of the databases, in a container, and they work in the same way.

Each container with InterSystems inside, and one our service inside. And I don't see any troubles here, even in security. Your way it is a bad way, it is like add a new layer with docker, like container (Application) inside another container (Caché), too complicated.