Chat Logs

  1. phalethbye bye blue
  2. phalethwb blue, I'll deploy theanswerisc blog onto podman today, just to test the stability
  3. bluethx phaleth
  4. bluealright, so it's podman inside nspawn or vice versa or what?
  5. bluejust remember, I don't plan on using podman at all in the long run. per customer will be kvm, inside customer will be nspawn
  6. phalethoh, ok, sounds like I should do more reading of archwiki
  7. bluebasically the ideal is, we'll be having barebones, then we put kvm on it
  8. blueevery customer (=namespace) gets put in one kvm (or several, but it's only ever one customer per kvm)
  9. bluea barebones can have unlimited number of kvm spaces or whatever the term is
  10. bluekvm ensures proper separation
  11. bluewithin a kvm space, we use nspawn to separate all the machines
  12. blueso take dreamreal: if his user is dreamreal, he gets a kvm space. within that, he could have many repos, with many apps. all of them run within his space (or several spaces, depending on the size/number of apps)
  13. blueso he can never access the nspawn machines within another kvm space
  14. phalethok, but it could happen that if he deploys many apps to one kvm then one of them could get compromised and all the other apps could get hacked
  15. phalethwhy? cause nspawn containers run as root, that's why I'm messing around with rootless podman these days
  16. phalethI mean the isolation will prolly not be perfect, but any extra isolation is good
  17. phalethalso we will be able to use podman-compose, which is very very nice
  18. blueisn't there rootless nspawn?
  19. blueI think the limitation was creating networks, for that you need root privileges
  20. blueanyway podman is probably not great isolation either. if you really want perfect isolation we need kvm
  21. bluehow about one kvm per repo, will that be enough?
  22. blueI guess no, since if your test app is compromised someone could compromise your prod app
  23. phalethI'll just update the theanswerisc deployment today and so you can read it, for sure I'll try rootless nspawn too, but nspawn is such an underdocumented tech so I don't know, but I'll try
  24. bluecoo
  25. bluebtw phaleth, did you look into this? https://katacontainers.io/
  26. nevetKata Containers - Open Source Container Runtime Software
  27. bluedefinitely big red flag there that it's written in rust
  28. phalethyeah, noticed that several months ago, but didn't try that
  29. blueyou did try firecracker, right
  30. phalethnope, firecracker has memory issues, I'm willing to go with qemu/kvm
  31. bluefor that we'd need a dedi though
  32. blueI mean, it's likely our own vps runs in kvm
  33. phalethit does, contabo does not hide the fact they use qemu/kvm
  34. phalethfirecracker is also written in rust
  35. blueI think kvm should be enough, but obviously an overkill per app
  36. blueso the question becomes at what boundary level do you use it
  37. blueper customer, you said is too broad
  38. phalethI think nspawn and podman is a good solution, just need to avoid the use of root user like I do in all these mariadb containers
  39. bluebut why both?
  40. bluethey're competing products
  41. phalethcustomer -> project(s) -> machine(s) for builds/deployments... builds/deployments are linked together via one table as stack layers
  42. phalethcontainers within containers are done to gain more isolation, nothing is as perfect as a VM, but for containers there's non need for dedis
  43. phalethalso I think crun and pasta are really great, maybe later on we could consider podman within podman
  44. phalethboth rootless
  45. blueoki, I'll let you be the master of that
  46. blueas long as we fget proper security I don't really care how it's done
  47. phalethyeah, I'm not so inclined towards nspawn anymore cause of security, but I'll try if it can run rootless containers
  48. phalethalways assume the tech will be changing anyway, maybe katacontainers will win the game in few years
  49. blueya
  50. phalethrootless and also distroless are the buzzwords nowadays, also nspawn is heavily dependent on systemd which means the bottom layer of each container is huge and that will add up
  51. blueya
  52. bluephaleth: what about one dedi + several kvms (one per customer) + firecrackers inside kvm
  53. blueor is that still the memory issue
  54. phalethyeah, you can try fly again if you want to, the way they deal with OOMs related to firecracker is that they auto restart these microvms, no clue how they deploy postgres, prolly somehow differently
  55. phaleththe good think about nspawn container is that one can run anything on it
  56. bluemaybe we should just have a mixed security model, free customers share dedis, premiums are fully separated, get their own dedi + potentially kvm + nspawn
  57. bluethe ultimate security win is one dedi per customer, but it's also the most expensive
  58. phalethyeah, I think that's a good opportunity for marketing, having these shared vs. dedicated terms in the portfolio
  59. phalethalso not everybody will need dynamic apps with dbs behind them, if it's just a static site we can deploy it to a freebsd server where the only thing needed is a piece of nginx config
  60. phalethI mean there are already lots of services like that, but still
  61. blueua
  62. blueya
  63. phalethanother cool thing about podman is that it runs on freebsd, while nspawn is linux only
  64. blueI mean if you prefer podman, let's do it. I'm not sold on nspawn
  65. blueI just don't want to mix a thousand different technologies because in the end we need an abstraction API over them, we can't do it manually, and every one of them means the abstraction layer gets more complex
  66. bluedoes podman have a nice http-based API like docker?
  67. bluemaybe that solves our need to create an abstraction around calls to nspawn
  68. blueI wouldn't mind that, that would be great, would save me a lot of headache
  69. phalethyeah, I'd also like to use haproxy APIs
  70. phalethpodman does have docker compatible API https://medium.com/@pingkunga/how-to-enable-remote-api-in-podman-e32cede96309
  71. bluethat would be cool: in that case, the podman machien for repopack.com would use this API for management, that's amazing, no?
  72. blueI'm gonna try to install podman here locally and activate the API, so I can develop against it
  73. phalethyeah, it's great
  74. phalethI'd like to mess around with freebsd later on again, but now I'll be slowly introducing podman into the setup we already have
  75. blueok
  76. bluephaleth: I installed podman & ran a rootless container on it, lovely!
  77. phalethyeah, very simple
  78. bluepodman run -d --name hello-http --rm \ -p 127.0.0.1:8080:8080 \ docker.io/hashicorp/http-echo:latest \ -listen=:8080 -text="hello world"
  79. bluephaleth: ^ will start a new test container you can test with
  80. blue`podman stop hello-http` to kill it
  81. blueyou might need to remove the \
  82. blueit was a multiline command
  83. bluepodman run -d --name hello-http --rm -p 127.0.0.1:8080:8080 docker.io/hashicorp/http-echo:latest -listen=:8080 -text="hello world"
  84. blue^
  85. bluephaleth: systemctl --user enable --now podman.socket
  86. bluecheck that it worked: `systemctl --user status podman.socket --no-pager`
  87. blueshould say `Active: active (listening)`
  88. phalethon the vps?
  89. bluesure.. it'd be scoped to your user anyway, so no harm
  90. bluecurl --silent --unix-socket "$XDG_RUNTIME_DIR/podman/podman.sock" http://d/_ping
  91. blueshould say `OK`
  92. phalethyou can try this image ghcr.io/ammnt/freenginx:latest, it's a very hardened one
  93. bluealso try this
  94. bluecurl --silent --unix-socket "$XDG_RUNTIME_DIR/podman/podman.sock" http://d/v1.0.0/libpod/info | jq
  95. blue"version": {
  96. blue "APIVersion": "5.8.0",
  97. blue "GoVersion": "go1.26.0-X:nodwarf5",
  98. blue "Version": "5.8.0",
  99. blue "GitCommit": "07efc23e05c3d9aa15a0f30d57194737bfc4b6b1",
  100. blue "BuiltTime": "Sun Feb 22 22:45:50 2026",
  101. blue "Built": 1771796750,
  102. blue "OsArch": "linux/amd64",
  103. blue "Os": "linux"
  104. blue }
  105. blueit's written in go, hurrah!
  106. bluethis is amazing phaleth
  107. bluethis is exactly what we needed
  108. phalethyeah, only the crucial components to podman are written in C, crun and pasta
  109. bluephaleth: what'st he idea here? customer=user, podman runs in the context of the user?
  110. phalethyeah
  111. phalethI'd still do orgs already, but we said we will not do orgs
  112. blueyes, I meant orgs
  113. blueuser=org
  114. phalethorg can have multiple users
  115. blueyes but the podman would run under the org user?
  116. blueanywayt we can nail down the particulars later
  117. phalethyeah, for now just have orgs and users tables with 1:1 relationship
  118. phaleththis image works with podman docker.io/library/nginx:alpine-slim and it's only 5.46 MB
  119. bluecool
  120. bluephaleth: https://gitea.repopack.app/repopack/website
  121. bluecan you check if this works for you locally?
  122. blueclone repo & npm install & npx primate
  123. bluethis assumes you have podman running under your user
  124. phalethyeah, I'll try
  125. blueif all goes well, localhost:6161/networks should show networks, localhost:6161/containers should show containers
  126. blueif you don't have any containers running, just try the command earlier that creates an echo server
  127. phalethyou could add all that usage instructions into a README
  128. blueI could, but this will be fast changing. you won't see the networks or containers like that, directly anymore
  129. phalethI get Not Found error on both of those pages
  130. bluecurl --silent --unix-socket "$XDG_RUNTIME_DIR/podman/podman.sock" http://d/v5.8.0/libpod/containers/json | jq
  131. bluedoes this work? (Your version might be different)
  132. phalethnope, that curl call return nothing
  133. phalethI guess I was supposed to enable the API
  134. bluecurl --silent --unix-socket "$XDG_RUNTIME_DIR/podman/podman.sock" http://d/v1.0.0/libpod/info | jq
  135. bluewhat about this?
  136. blueyeah, I don't think your API is working
  137. blue14:08 < blue> phaleth: systemctl --user enable --now podman.socket
  138. blue14:08 < blue> check that it worked: `systemctl --user status podman.socket --no-pager`
  139. blue14:09 < blue> should say `Active: active (listening)`
  140. phalethyeah, you could add at least that to the README as that should not change
  141. phalethok, now I see the default network on the networks page
  142. phalethand no containers on the containers page since I just installed podman
  143. blueyes
  144. bluevery good
  145. phalethyeah, but not very self explorable
  146. blueyes
  147. blueI'm experimenting as we speak, so I haven't got to document much yet
  148. bluethe main question is if it reliably works for you, on another machine
  149. blueand we answered it now
  150. phalethyup
  151. phalethnotice the shell changing here https://images4.imagebam.com/da/99/f3/ME1B56O7_o.png
  152. phalethroot -> non-root -> root -> non-root
  153. blueyes