New post
AllAccepted answers
Luca Ravazzolo · Oct 7, 2016

Hi Ryan,

as an extra comment:

Yes, what you describe is absolutely possible and we have customers actually doing that.

Things may vary depending on your work processes. There are complexities to overcome, however, containers are very flexible and a great help in development, testing, demo & training stages as you're already picking up yourself.

For production purposes I would suggest looking into a microservices architecture, however, a more traditional, legacy or monolith approach is not precluded either.

Luca Ravazzolo · Oct 7, 2016

Hi Prasad,

Deleting the install dir after having it copied has already bloated the FS so you won't be able to shrink it because for every command Docker creates a new FS layer.

The best strategy is to run a single command and within it perform your delete. It will help.  My personal opinion is that we should provide discrete components and "pullable" resources but that's another story.

The other thing to notice is that pulling the distribution via http/ftp vs copying it also helps.

Try something like

RUN yum -y install tar hostname net-tools \
  && curl -o ${INT_F_NAME} ftp://myftpserver/distrib/CacheDB/${DIST_VER}.${DIST_BUILD}/${DIST_NAME}.tar.gz \
  && tar zxf ${INT_F_NAME} \
  && cd ${DIST_NAME} \
  && useradd cacheusr \
  && ./cinstall_silent \
  && cd ..; rm -fr ${DIST_NAME} \
  && rm ${INT_F_NAME}\
  && ccontrol stop $ISC_PACKAGE_INSTANCENAME quietly

--

 

HTH

Luca Ravazzolo · Jun 16, 2016

FWIW this is a huge chapter and we are not even mentioning global mapping or SLM (subscript level mapping), how dynamic you might want to be with it and what kind of elasticity you are after (scaling out and back in). You might find that ECP is not really your friend right here and right now given your cloud-based requirements. ECP is however extremely good for what it was created to do. 

--

To answer your question, I worked with Terraform that allows you to create any infrastructure on just about any IaaS cloud. You can then finely customise your nodes by injecting any script you may want. No need for any other configuration management (CM) tool. It has variables interpolation so it knows to wait to get the info it needs after resources are created etc. etc.

HTH

Luca Ravazzolo · Jun 16, 2016

1) if they are DevOps engineers they don't do things manually. It's an axiom. :-)

2) the issue IMO is not so much which tool one needs to pick -you mention Ansible, but understand the requirements of the architecture.

3) it's not so much the numbers of nodes -although important, but the fact that the software needs to be much more dynamic and provide clear APIs that one can call. With a static architecture the monolith lives on ;)

4) one very important fact when working in the cloud is networking: you may not know in advance some facts like IP addresses. In general apps use discovery services to find things out. This is the part we need to grow and provide more "dynamicity". You can, however, adapt and evolve via ZSTART and tell the cluster who you are and you you're after.

5) I was playing with this few days ago and because of the lack of API I had to create one of those horrible scripts with <CR> redirection, blind options selections etc. ;) - Not the most robust solution for Dev or Ops engineers ;)

HTH in your endeavour Timur

Luca Ravazzolo · May 20, 2016

Hi Francis

if you just want to test things, develop or even go into production without all these issues, why not give Docker containers a try?

You'll never be pulling your hair again for these type of issues. You container comes installed (Dockerfile); you just spin it up and when you're done you just dispose of it.

However, you'll have other hair-pulling moments for other things but by then you'll be so deep into DevOps, learning and collaboration that you won't notice it :-)

Seriously, though, it's a great technology for some perfectly fitting use cases, even production if you embrace microservices and you'll be able to run a CentOS, RH, SUSE or Ubuntu container on your Debian Jessie without a glitch.

HTH

Luca Ravazzolo · May 17, 2016

Thanks for sharing the code Tani.

IMO I think these type of monitoring should be done directly from the core Caché like from sensors in SYSMONMGR and should be provided by the system. I'm hoping to open source SAM (System Alerting and Monitoring) soon as it was demoed last year. The idea was to have a plug-&-play component to drop on all instances to monitor and an appliance that would gather those warnings and alerts.

Luca Ravazzolo · Mar 25, 2016

@dmitry thanks for the pull request; great idea; all merged now.

On the article you're working on: we hope you can share it once translated into English so that a wider audience can benefit from your precious work. Depending on how you spin up containers there are a couple of critical areas I'd like you to describe so that we can all learn from each other experiences here:

  1. Data Volumes
    • Containers are ephemeral and although we can mount host volumes we need to think ahead
      • What do those volume-drivers offer us? (See Rancher Convoy, Flocker & EMC Rex-Ray, etc.)
      • How integrated are they with the underline FS or SAN? (think snapshots, replication etc.)
  2. Networking
    • if you have more than one node it's tough to get containers to communicate so you'll have to run an overlay network.
      • my two favourites are (a) Weave.works, (b) project Calico and (c) flannel by the CoreOS guys.

 

Both the above aspects are fundamental to have a production system.

Let us know how you get on. Hope to see you in Phoenix.

Luca Ravazzolo · Mar 24, 2016

@Dimitri, first of all, you don't have to use ccontainermain, you can script your own solution. It's just a quick-start utility. Caché ccontrol -as the name implies, is the database image control process and does many things. None of them are concerned with keeping the container alive which is not -by definition, a Linux distribution.

InterSystems has been testing and running its QD testing suites against Docker containers from the 2nd quarter of 2015. Stating that we support Docker containers means that we support our platform in this environment. However, there are MANY gotchas and anybody interested in "containerizing" their app or more to the point, switching to a micro-service architecture,  should approach it as a new platform.

Luca Ravazzolo · Mar 17, 2016

The subject made me smile :) "service"
 

Shouldn't we wrap the above method and expose these services via a RESTful "service" API and even encapsulate the inside system Caché ObjectScript API we have with such "service"?

So the above would look something like:

GET /server/system/v1/services

and then of course you'd have all the other methods implemented...