A bad bargain - fewer builds, greater uncertainty

In  my last post, I described Syncing from GitLab to Docker Host Volume to ensure that the correct set of configuration files were read on startup.

What I didn't explain was that I don't actually recommend this approach.

Did it work?

Yes, it did.

Yes, we were able to control and distribute the configuration in such a way that we could track changes and say what configuration had been used to start each container.

So what was wrong?

In a word, complexity - we made life unnecessarily complicated for ourselves.  It would have been far simpler to have built a new image for each change to the set of configuration files, and then published the image in a repository (public or private).

What we were saving ourselves with the syncing approach was the effort of building a new image with each change.  But building a new image isn't that much effort, and can be automated in any case.

Fewer images doesn't give any significant saving in terms of storage either.  With multiple versions of the same image the additional storage used is only what you need to store the delta - in this case the differences between the files in the config directory.

The advantage of building the image each time is that you have much greater certainty of what configuration a running container is using, since it is baked into the container.

If it were me, I'd much rather have a repository containing more images, with the configuration as fixed as possible.  Any configuration information that does need to be defined at container startup should be done through environment variables, and written to the log straight away.

Fundamentally we traded off certainty in configuration for "less effort" building containers.  Except the "less effort" approach actually involved additional effort to set up the syncing approach, and means a more complicated system to maintain.

So why did we use the syncing approach?  Because that's what the customer had set their hearts on.

And yes, it worked - in a POC.

I'll be very interested to see if they keep this model in production.

Comments

Post a Comment

Popular posts from this blog

Wot no FDK?

Writing Serverless Functions in a New Language Background Fn Project  is an open - source, Docker based, cloud native serverless platform .  You can run it in any environment that supports Docker.  Oracle Functions is based on Fn Project. If you want to have a play with Fn before reading the rest of this post, I recommend the " Quick Start " guide. One of the great strengths of Fn Project is that it is open. When other serverless platforms (that shall remain nameless) restricted you to JavaScript / Node plus maybe a couple of others, Fn offered an FDK for Ruby (for those who prefer elegance and beauty in their code). This was a major factor in me getting involved with the project, and becoming a contributor to the Ruby FDK. In addition to Ruby, Fn offers a number of other FDKs: Go, Java, Python, Node and .NET Core. But beyond that, Fn has always been open to additional language runtimes.  If your code can run in a Docker container, then (in principle) it can run as an Fn fun
Read more

The Case of the Vanishing Dockerfile

If your serverless platform is Oracle Functions or the open source  Fn Project that it is based on, you may have wondered exactly how a function image gets built for one of the standard runtimes. One clue is that if you're watching closely you may see a Dockerfile  a p pear briefly, then vanish during the build process. The Fn CLI will create the Dockerfile for the runtime, build the function and then delete it once the build has completed. You can see the steps of the docker build by running  fn build  or  fn deploy  with the  --verbose  flag specified: $ fn build --verbose [14:57:34] Building image fra.ocir.io/oraseemeatechse/crush157/dummy:0.0.1 FN_REGISTRY: fra.ocir.io/oraseemeatechse/crush157 Current Context: default Sending build context to Docker daemon 14.34kB Step 1/11 : FROM fnproject/fn-java-fdk-build:jdk11-1.0.108 as build-stage ---> e3c33b854f29 Step 2/11 : WORKDIR /function ---> Using cache ---> c0bcff391281
Read more

Honey I Shrunk The Container

Image
(or how I found out about microcontainers and why I think you should use them) Context About 18 months ago I was asked to help an ISV partner who wanted to migrate their product to cloud. At the time they had a very traditional software industry business model - sell the customer a license to run their software, along with a subscription for ongoing support. However they wanted to be able to move to a SaaS model where the customer would consume their software as a service running in the cloud. Their stack consisted of: a Ruby on Rails application Postgres Redis Their initial attempt at creating a SaaS offering had been to run this as a set of VMs on top of IaaS. While the software ran just fine, they soon saw that this approach wasn't going to give them a successful SaaS business. If any part of the application were experiencing high demand, the only way to scale it was to start another instance of the whole application . Since they were packaging the applic
Read more