2

In theory the idea of an iterative method of container configuration really appeals to me. In practice, I'm having a difficult time making it work, particularly in the rootless ecosystem of podman/buildah.

I'm beginning get the feeling that podman/buildah is not the best container dev stack for debian derived linux distros. For one, apt doesn't support dnf's '--installroot' option/directive. I've attempted to use debootstrap with buildah's 'scratch', but w/ no success... i.e., I'm getting a 'Cannot install into target' error.

I should say that I succeeded in cobbling together a simple pod with containers running NGINX, postgres, and served, a c++ library that I used a basis for building a small app for brokering database bound post requests from a web front-end. The problem is it's a kludge, with the main sticking point being the served-based c++ app. Between compilation and runtime dependencies, I'm unsure of the best approach to take; needless to say, my current approach is not working.

I would appreciate any and all hints from experienced practitioners who use rootless container solutions on debian-based distros, esp. if you're rolling your own c++ microservices: I'd really like to know your strategy for doing configurations. Many thanks in advance.

user10756
  • 63
  • 4

1 Answers1

0

I found this insight from a y-combinator user useful to think about:

I could very well be wrong but Podman seems to have missed the time-frame of opportunity. It was always a knife fight between Red Hat and Docker with regard to tooling. Red Hat wanting to own the toolchain for containers so they didn't have to deal with, and so they could box out, competitors like (now basically defunct) Docker Enterprise. I've taken a look at podman from time to time over the years but it seems like it's just never formalized, never been polished and almost always has been sub-par in execution. On this list the builds and container control are things that I've run across. I guess - what's the point? The rootless argument leaned on so heavily is pretty much gone, the quality of Podman hasn't (seemingly) improved and now IBM owns Red Hat (subjective, but a viable concern/consideration given what's recently happened with CentOS).

You're more than safe leveraging Docker and buildkit (when and where needed). Quite honestly, given the relatively poor execution of Red Hat with these tools over the years, I don't see the point. I'm sure there are some niche use cases for Podman/Buildah, but overall it just seems to come up as an agenda more than an exponentially better product at this point. Red Hat could have made things better, instead they just created a distraction and worked against the broader effort in the container ecosystem.

For full context, please see the following thread: https://news.ycombinator.com/item?id=26101608

user10756
  • 63
  • 4
  • From the same thread: "The only excuse is some Red Hat folks seems to practice C++ hating as some kind of religion." Who knew? LOL... – user10756 Jan 21 '22 at 00:39
  • Compared to GCC's official image on Docker this is small: https://hub.docker.com/r/frolvlad/alpine-gxx. Which is to say, the best I was able to do (before I threw in the towel) was a ~2G image w/ Served and BOOST... – user10756 Jan 21 '22 at 02:56
  • This guy is onto something: https://stackoverflow.com/questions/52727239/how-to-compile-a-c-application-using-static-opencv-libraries-within-docker – user10756 Jan 27 '22 at 08:13