4 ms·
Ultimately these are the same challenges you face using any other method of deployment. You still need to build and push artefacts from CI, orchestrate their ex
by matthewmacleod 3y ago
Ultimately these are the same challenges you face using any other method of deployment. You still need to build and push artefacts from CI, orchestrate their execution, and ensure your dependencies are secure. Containers really just standardise that, at the expense of some bloat.
Keeping it simple is what matters. At the base level you can treat a container very much like a single binary if you want to - build it, SCP it to a server, and add a systemd unit to run it. But you have the advantage (and some costs) of mostly isolating yourself from the runtime environment.
The orchestration frameworks are where I start to get itchy about complexity and would definitely put that process off as long as possible.
- fulafel 3y agoThe things I listed are additional things, they don't replace what you need to do anyway. You could be deploying your Go binary or Clojure JAR on that vm/vps, or you build additional complexity on setting up & terraform authoring your registry and it's setup, making it accessible from GH actions, scanning container base images for vulnerabilities, jumping hoops to debug it because it's in a container, etc. Using containers without a registry feels like a iffy middle ground. You lose the standard workflows and can't use it on container native platforms.. But maybe it makes sense sometimes. It has upsides too, sure.