Hacker News Reader

Comment by matteuan | Hacker News Reader

The author addressed exactly this type of comment. I don't see the real difference in complexity of maintaining 12+ bash scripts instead of the same number of Docker files. And for the deployment, the alternative given by the author is using fat binary.

View on HN

Docker file produces what basically is a software package with all the required dependencies. Deploy it to some Docker host and it will most likely run. It will run on a developer laptop, a VM or in K8s/Mesos/Nomad cluster. Add some docker compose files and you'll be able to run your whole service locally with all the external dependencies if you think that's a good idea. Extra bonus is... target system requires Docker daemon only. So no extra work to support Ruby/Java/Go/Python runtimes.

Alternatively you can go and package tar files. Or create Debian/Red Hat/Nix/whatnot compatible packages and manage dependencies via a package manager. You can go with Snap or Flatpak to achieve ~ the same. However Docker images produced by the said Docker files will most likely just run on any of the said OSes with no or little additional work and probably on the OSX and Windows too. And people will be pretty happy that running docker build $some_opts will (likely) give them a working app/(micro)service and that they don't have to mess with $some_packaging_system to rebuild and test stuff locally. So I guess Docker files provide some extra flexibility even if the maintenance burden is matched to the one required for maintaining bash scripts.

> I don't see the real difference in complexity of maintaining 12+ bash scripts instead of the same number of Docker files.

With respect, I have to assume your experience is either in an ecosystem with really strongly-established best practices for bash (and someone with the job of enforcing said practices) or your organization has no more than two or three people maintaining those dozen-plus bash scripts (and is on its way to a headache when two of those people retire at the same time and your org tries to on-board someone new to read those scripts).

You judge "with respect" my experience instead of answering to the argument. So why is it easier with Docker?

Because a Docker config makes it hard to accidentally wipe your filesystem instead of building a Docker image. Shell scripts make that less difficult (and any solution using shell to do something similar to Docker will have a bespoke layer of in-house code that should be correct but will require maintenance by your team to make sure nobody makes a change that turns it into a filesystem-eater).

It is easier because you can actually build that functionality locally with a docker container to test it out.

This is coming from someone that spent 10+ years maintaining a build system that was a mix of makefiles and shell scripts. It can be done but I don't know if it should.

Well-written ksh/bash is extremely light-weight, flexible, concise and easy to maintain. Changing shell or OS would be the headache, but easily outweighted by gains if used for the right jobs.

Unfortunately, maintaining it requires somebody who is familiar with ksh or bash, and they are tools with Byzantine syntax by modern aesthetics. They're also more firepower than needed for the problem domain of building and maintaining deployments---they have features one doesn't need and require library support for key features in the deployment problem domain.

You can code a deployment solution in c++ also, but it's not recommended.

Reply on news.ycombinator.com