Comment by hardwaresofton | Hacker News Reader

Comment by hardwaresofton | Hacker News Reader

LXC+LXD is one of the most undervalued container technologies out there. It can do a lot of cool things (like live migration via criu), and is IMO more production ready than Docker ever was.

For those wondering about the distinction between "system" containers and "app" containers, the difference is user namespacing -- I think we should stop using the naming difference but instead go with specifying that the containers "full user name spacing". User namespacing is the "magic sauce" for projects like Podman and a related project Buildah which builds images without root privileges -- the combination of user namespaces and FUSE.

BTW for those wondering if container orchestrators like Kubernetes will be shaken by this -- they very likely won't. Kubernetes has sidestepped this problem by introducing and relying on RuntimeClass[0], which allows you to swap out the runtime that's running underneath kubernetes. In fact, there is already a shim being worked on[1].

[EDIT] - While I'm here talking about container tech, please check out containerd[2]. It's been my runtime of choice for a very long time, has been very well maintained, and received many of the really advanced features first (ex. untrusted runtimes). IMO it should be the default container runtime of k8s.

[0]: https://kubernetes.io/docs/concepts/containers/runtime-class...

[1]: https://github.com/automaticserver/lxe

[2]: https://github.com/containerd

I'm curious as to how you get your images built. I'd love to remove the over reliance on docker in my team, but the sticking point seems to be building and storing images. I know that Kubernetes can run with different runtimes, and that docker images can be oci compliant, but it's a hard sell to ask everyone to try something different in production when they do everything else with docker. Do you have a workflow that could help with that sort of thing?

Bazel can natively build images without Docker.

Bazel has many other benefits too like creating a full dependency build graph and fully reproductible builds.

https://bazel.build/

https://github.com/bazelbuild/rules_docker

Both your solution, Bazel, and that of the neighboring comment, Gitlab, involve way too many parts you don't necessarily want or need. I'm not going to rewrite my build process (which is generally a thankless job with very low customer ROI) just to build container images :-)

Same story for Gitlab, nobody's going to migrate from Github or Bitbucket just to get container images builds.

I build my images for private & professional projects in Gitlab CI and I use the provided free registry.

The biggest downside to my set up is that I can't say I have enterprise-level security. Getting it nailed down properly requires the use of tools like TUF/Notary[0] & signed-image aware container repositories like Harbor[1] and a deployment gate mechanism like Portieris[2]. That's a lot of complexity to tack on.

Just a note -- Docker already runs containerd underneath via a shim[3]

If you're relying on docker-specific features then by all means it makes sense to continue using docker but if you're just looking for a thing to quietly run your containers (or power your kubernetes cluster), containerd should probably be that thing. It's all of the building and none of the extra stuff that docker the company is trying to do/become.

[0]: https://github.com/theupdateframework/notary

[1]: https://github.com/goharbor/harbor

[2]: https://github.com/IBM/portieris

[3]: https://groups.google.com/forum/#!topic/docker-dev/zaZFlvIx1...

cri-o and containerd run standard docker images seamlessly. They're mostly drop-in replacements for dockerd. So even if you're using standard dockerd at build time, that's perfectly fine.

Things like buildah, kaniko, img, and whatnot can build standard Dockerfiles fine and push to standard docker registries. I don't have much experience with them though.

I believe ContainerD is the default on Google Kubernetes Engine (GKE)

Didn't know this but this is great news -- last I heard it was experimental[0].

[0]: https://cloud.google.com/blog/products/containers-kubernetes...

Reply on news.ycombinator.com