AllAccepted answers
Luca Ravazzolo · Dec 8, 2016

Ha... there was another question on MS-Windows support :)

Given the Docker engine dependency on the Linux Kernel, the dependencies or support of the various Linux FS and that the September announcement was just for a GA version on Win server 2016, I would not waste my time right now.

Spin up a Linux node on your private or public cloud and just enjoy the speed and lightness of containers. :)

HTH

Luca Ravazzolo · Dec 8, 2016

Thanks @Dmitry; perfect.

@Andrew: as you can appreciate Docker containers can be very suitable for just about any use case when you want to embrace infrastructure-as-code and, even better, immutable infrastructure. Of course, we are already talking about automation, provisioning, deployment process and, in many cases, DevOps and why-not? Microservices.

It's typically a full package that one embraces as soon as she/he tip-toe into any of the above areas. Why? Because cloud computing (off-prem and on-prem) is about a "modus operandi" that  is, agility and lowering the TCO of an app (which typically it's its running lifespan).

There are many considerations and gotchas. We are working at improving the experience for those choosing this technology.

HTH

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.