4 ms·

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 producti

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/#upgrading-runtimeclass-from-alpha-to-beta https://kubernetes.io/docs/concepts/containers/runtime-class... [1]: https://github.com/automaticserver/lxe https://github.com/automaticserver/lxe [2]: https://github.com/containerd https://github.com/containerd

scaryclam 7y ago
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?
- wikibob 7y ago
  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://bazel.build/ https://github.com/bazelbuild/rules_docker https://github.com/bazelbuild/rules_docker
  - oblio 7y ago
    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.
- hardwaresofton 7y ago
  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 https://github.com/theupdateframework/notary [1]: https://github.com/goharbor/harbor https://github.com/goharbor/harbor [2]: https://github.com/IBM/portieris https://github.com/IBM/portieris [3]: https://groups.google.com/forum/#!topic/docker-dev/zaZFlvIx1_k https://groups.google.com/forum/#!topic/docker-dev/zaZFlvIx1...
- paulfurtado 7y ago
  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.
wikibob 7y ago
I believe ContainerD is the default on Google Kubernetes Engine (GKE)
- hardwaresofton 7y ago
  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/containerd-available-for-beta-testing-in-google-kubernetes-engine https://cloud.google.com/blog/products/containers-kubernetes...
_seemethere 7y ago
containerd is also the default container runtime for docker as well. when you do a `docker run` it just calls out to containerd now to launch your container.

scaryclam 7y ago

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?

wikibob 7y ago
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://bazel.build/ https://github.com/bazelbuild/rules_docker https://github.com/bazelbuild/rules_docker
- oblio 7y ago
  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.
hardwaresofton 7y ago
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 https://github.com/theupdateframework/notary [1]: https://github.com/goharbor/harbor https://github.com/goharbor/harbor [2]: https://github.com/IBM/portieris https://github.com/IBM/portieris [3]: https://groups.google.com/forum/#!topic/docker-dev/zaZFlvIx1_k https://groups.google.com/forum/#!topic/docker-dev/zaZFlvIx1...
paulfurtado 7y ago
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.

wikibob 7y ago

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

hardwaresofton 7y ago
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/containerd-available-for-beta-testing-in-google-kubernetes-engine https://cloud.google.com/blog/products/containers-kubernetes...

_seemethere 7y ago

containerd is also the default container runtime for docker as well. when you do a `docker run` it just calls out to containerd now to launch your container.