How to shrink your Docker images.

Docker Images, everyone says smaller is better but how do you do this but still maintain functionality and debugging ability? Well, here is how I did it.

Preflight Resources:

Docker Multi-stage building: https://docs.docker.com/develop/develop-images/multistage-build/#name-your-build-stages

Google Distroless Images: https://github.com/GoogleCloudPlatform/distroless/blob/master/examples/nodejs/Dockerfile

Docker-Puppeteer-Jest (Headless Chrome + Jest testing image): https://hub.docker.com/r/davidjeddy/docker_puppeteer_jest/

What we need to do:

Here is where we start, a 800Mb+ size image just to run headless Chrome and Jest. Ouch.

So lets apply the multi-stage build paradigm and use the Google Distroless NodeJs Image:

Now we rebuild the image using the `build . -t davidjeddy/docker_puppeteer_jest` command and we end up with a ~ 400MB images. 50% Savings!

Now remove the old busted and bloated image `docker rmi davidjeddy/docker_puppeteer_jest`. 

Usage:

Run the image command as normal and observe the same expected output as before. Unfortunately for the example project herein more work is needed as the original image did not keep dependences within the app dir.

TL;DR:

After building your service image, make an addition step that plops it into a distroless base image. Boosh, easy win.

Any interesting new angle on an old adage.

The saying ‘people don’t leave jobs, they leave their boss’ has been around for years. Herein Christie Lindor goes one step further and focuses on how organizations fail there employees. Remember, being employed at an organization is a two way deal. You offer your time , effort, and skill in exchange for monetary compensation. As long as the organization needs those things from you the organization continues to compensate. But what happens when the organization fails to delivery the non-tangible requirements?

PEOPLE DO NOT QUIT COMPANIES, MANAGERS, OR LEADERS – THEY QUIT ORGANIZATIONAL CULTURES. HERE’S WHY.

Vacation so soon(tm)…

I’ll be out of communication starting Friday till about the 5th of July. Taking a much needed vacation. Might be able to put in some time on a library or two while flying; but for the most part. I’ll be comms off.

See you happy people when I get back!

ComposerCat (beta)

(Preface: I am a full supporter of CLI tools, UI tools are nice but should not be depended on for day-to-day workflow).

Came across this interesting UI tool from NomadPHP‘s weekly mailer. ComposerCat. It visually displays the contents of Composers composer.json and installed packaged. It’s in beta but looks to do everything it says on the tin. Check it out.

Always plan on something going wrong…

Anyone who has sat through the process managing a project know, whole heartedly as a fact, no matter how much something is planned and scheduled something else will always go wrong. Believing this as fact one should never, ever, plan a time line or effort estimation based around everything working as planned. Planned and working are so far removed from each other the relationship is vague at best. No matter how many times we build the same CRUD application or data pipeline, or CI/CD process; always leave yourself some buffer time to correct unforeseen issues.

As a general guideline the less I know about a requested change the higher my effort estimation; almost geometrically. As an example:

  • 80 hours to write a single data object CRUD UI
  • 40 hours to write a single data object CRUD UI  with defined fields & validation
  • 20 hours to write a single data object CRUD UI  with defined fields, validation, and user story documentation
  • 8 hours to write a single data object CRUD UI  with defined fields, validation, user story documentation, and visual mock ups of the expected UX

Now at some point I hit a floor where effectiveness just simply keep up with the continued reduction in effort. But at that low of an effort estimate we are basically wizards doing magic as far as non code people are concerned.

Some people will  responded with ‘but estimates that high scare away clients’; This is very true and factual. However, my response is this: do you really want to work with a client who has not clear answer or concepts of what the results of the effort should be? Think `moving goal posts` but not having a goal post to begin with.

TL;DR: Always buffer your estimates, even if you know everything that needs to be done.

A little fun with gource

Every year my employer has a holiday party. This past year I rendered out all the projects we had worked on and put them in a loop on the big screen. The video renderer we used is called gource. Here is the gourcing of the current project.

 

Edit: So youtube is being…well Youtube and keeps deleting the video. Guess I’ll try again later :S. Still have it here so maybe twitch or something else.