Integrate Podman's "Pods" feature (along with support Podman API to begin with)

[ZepsiZola]

Currently, panel solutions like Pterodactyl and Pelican manage server containers individually, each with isolated resource limits and network configurations. However, this approach has several limitations, particularly in flexibility, efficiency, and security, affecting both shared-host providers and their customers.

Having recently transitioned several projects from Docker to Podman, I've observed substantial advantages offered by Podman, especially its ability to deploy "Pods". Docker's main advantage over Podman, currently, is it's popularity and it's resulting accessibility and "user-friendliness", but this advantage becomes irrelevant in this context, where the end-user manages containers through the web-panel rather than actually fiddling with compose.yml or kube.yml files. Everything should "just work", for them in the panel regardless of what container runtime Wings is deploying with. Given this fact, utilising Podman's API in the software is a no-brainer, considering how much more you can do with it, namely "Pods". Also needless to say, rootlessness is a huge benefit as well (in-fact I feel it is also very necessary for security to allow users to deploy rootless containers as opposed to rootful containers), but I shall not be discussing that in this post.

Podman's Pods

Pods, as utilized by Podman, group multiple containers into a unified environment. Containers within a Pod communicate over localhost, effectively simulating a single machine. And you can configure which of the Pod's internal ports you want to expose onto the host, allowing you to fully and simply isolate services inside an environment. This architecture presents several key benefits...

Flexible Resource Management

Pods allow collective resource allocation, including RAM, CPU, and storage, to multiple containers simultaneously. For example, a customer could receive a Pod with resource limits such as 20GB RAM, 1200% CPU, and 1TB disk space. Within these constraints, users could freely deploy and manage various server-containers such as databases, proxies, game-servers, web-servers, and experimental setups without needing separate subscriptions for each new container they create. They can even experiment by adding a miscellaneous or test-server, and if they decide they don't want it permanently part of their setup, they can simply turn that server off and/or delete it. Additionally, customers can still assign individual container limits if desired. And a customer upgrading their setup is as easy as adjusting their subscription to make use of higher resource-limits.

Enhanced Security and Isolation

Currently, there are two ways to allow network configurations on a service: 1. Have all customer containers on the same bridge network, which is very insecure as customers could maliciously access eachother's backend servers (e.g. They could packet-spoof other customers' backend servers on a Minecraft BungeeCord network-setup). 2. To ensure higher security, shared-hosts sometimes resort to running multiple instances of Wings software on one machine to isolate customer networks. So currently you have to choose between something insecure, or something innefficient in order to accommodate for network-setups. Pods take the advantage of both those solutions with zero of the disadvantages by providing secure isolation between customer environments without requiring multiple software instances. Customers gain secure, dedicated network environments without added complexity or security risks.

An example of the network-setup of a Pod:

• Example IP of host-machine: 204.62.198.61
• Pod config: -p 25565:25565.
  • So the host's port 25565 is mapped to the pod's internal port 25565.
• Velocity proxy-server container bound to 0.0.0.0:25565 within the Pod
• PaperMC backend-server container bound to 127.0.0.1:25566 and 127.0.0.1:25567 within the Pod.

Explanation: A player can join the server by connecting to 204.62.198.61:25565. The backend-servers are completely inaccessible to not only the public but also other containers under the same Wings instance, so the threat of packet-spoofing is neutralised even when customers have a poorly configured network setup. No firewall-rules are even needed to block access to the backend ports, as they are already isolated within the Pod, which brings up another advantage of Pods, each user has access to the full spectrum of ports within the pod, while only taking up 1 port on the host (in the case of a network-setup with one proxy and no web-servers or externally-facing databases). So, as demonstrated, utilising Pods is secure and, not to mention, much easier to set up than the current solution for the equivalent amount of security (multiple Wings instances).

Improved User Experience

Implementing Pods would give customers enhanced control and ease-of-use. Users could flexibly allocate resources within their Pods and quickly adjust their infrastructure according to their needs, all within a straightforward web interface. This approach significantly simplifies administration and scaling, providing clear cost-transparency for the customer. Customers would need only one flexible subscription rather than multiple separate subscriptions (in the case of a multi-server container network setup), making upgrades seamless and straightforward.

Minimal Resource Overhead

Pods have a negligible resource footprint, typically consuming memory in the KiB range. Consequently, adopting Pods would have minimal impact on overall system performance. Even standard (non-network-setup) customers could benefit from Pods, making it straightforward for providers to upgrade users from the default single-server-container-setup to network-setups by simply adjusting resource-limits (e.g. Just set the customer's Pod's container-limit from 1 to unlimited and increase their RAM and CPU resource-limits to accommodate).

Flexible Deployment Model

Once implemented, providers could maintain their current business-model by defaulting each container into an individual Pod (one container per Pod) or not utilising Pods at all, since it is possible to have Pods coexist with regular containers on the same host. Alternatively, providers could leverage the new functionality to offer customers Pods capable of housing multiple containers, with the resource limit applied at the Pod level. Customers could upgrade resource limits as required, providing easy scalability for the customer's setup should they ever feel the need to have multiple services. Furthermore when customers graduate to wanting network-setups, they are less likely to leave the shared-host for their own dedicated-machine or VM. They'll be more likely to stay with the service. I know that I actually left my shared-host as a client due to upgrading to a self-administered network-setup hosted on a dedicated-linux-machine I rented from OVH. I knew nothing about Linux when I made that switch and I had to learn a lot.

Integrating Pods into existing panel software would require significant effort:

• The panel codebase would likely need substantial reworking to integrate directly with Podman's API.
• New functionalities must be developed for creating, managing, and administrating Pods. As in, entirely new pages and menus on the panel itself, although they'd be very similar to the "Nodes" and "Servers" UI.
• Ensuring compatibility and seamless operation alongside existing Docker support will require careful planning and execution.

Even with all this considered, I feel that integrating and making use of Podman's features is the next step up for this software since it will allow for a new level of complexity, flexibility, and ease-of-use that is just not possible with Docker, and probably never will be. Currently, a big issue I see with Pelican and Pterodactyl software is that the panel sort-of just assumes that a user isn't setting up a network. It just assumes that whatever you're setting up is just a single game-server. This is probably because that was the original aim of the devs when they created Pterodactyl. I know it is actually possible to execute a network-setup, I have done it, but it is clear that the current solutions are band-aid solutions compared to what we really should be doing. Nowadays, high-quality game-servers aren't just one game-server, they are a network of services connected to one-another, and if you want to encourage those types of setups to utilise Pelican, we'd have to implement something like Pods in order to allow users to freely create network-setups to their own desires without worrying too much about security and multiple subscriptions and such.

Conclusion

Incorporating Podman Pods is the next logical evolution of this Panel software. This integration would significantly improve resource management, security, flexibility, and overall user experience, enabling providers to deliver superior, customizable services while empowering customers to have greater control and flexibility over their infrastructure, all the while ensuring that both shared-host and customer needn't worry too much about security due to the inherent security benefits of Pods. Furthermore, it would allow shared-hosts to have better customer retention for those customers who want to upgrade their setup and are reluctant to learn all the stuff that goes along with hosting services on dedicated hardware, such as becoming proficient with all sorts of Linux concepts and related tools.

Extra context about Podman

I actually was able to execute an entirely Podman-based Pterodactyl+Wings setup with Ptero and Wings both containerized and Wings deploying Podman containers. Considering I did this with Podman even though the application exclusively makes use of Docker API, I'm certain that it shouldn't be a huge undertaking to natively implement Podman's API since it's likely very similar to Docker's API with added features. I haven't done this with Pelican+Wings yet, but as Pelican is a fork, I'm pretty sure it must be a very similar process. The biggest hurdle I see is the introduction of the "Pods" feature into the panel, which would require some restructuring of the project, I think. Overall Podman is very similar to Docker as an application. All the commands are essentially the same. One thing I will say is that podman-compose is not as capable as people say. It doesn't always interpret docker-compose.yml files properly, most times due to differences between rootful Docker networking and rootless Podman networking. Personally I just don't deal with compose.yml files with Podman. I just manually create the setup and then save the setup configuration to a kube.yml with podman kube generate > kube.yml and then re-run the configuration with podman play kube.yml. Another thing I will say is that even just natively supporting Podman without even adding Pods functionality will still be a step-up in terms of ease-of-setup for people like me who do not want to run Docker.

Another thing I will say is that Docker sucks. Why does it need to run everything as root? Who's idea was that? Billion-dollar software and by default it asks you to run even the most innocuous services as root. You literally have to use sudo in order to do "Hello World" in Docker. Before you say "just add the user to the 'docker' group", doing that is a huge security flaw that essentially gives that user an easy privilege escalation exploit. Also, it's a billion-dollar software and it doesn't even natively support Pods. It just wants you to have bridge networks for everything. Podman is pretty much just superior to Docker in every way aside from it's lack of popularity. I forsee a time in the future where it rivals or even overtakes Docker due to Docker's flaws and lack of features in comparison to Podman, so integrating Podman into Pelican is also a step in that direction.

[Alexander-Evans-Moncloa]

Great idea, flexible resource management would be a gamechanger.

[zaxlofful]

Can you share your setup for Podman Pterodactyl/Pelican Panel/Wings?

I would like to test this myself!

[Messaiga]

Can you share your setup for Podman Pterodactyl/Pelican Panel/Wings?

I would like to test this myself!

Me too please! I'm looking into doing this myself so I can deploy from my development setup to my server using the kubernetes yaml.

[ZepsiZola]

Were you guys able to get it working? I thought about making a guide but it's been over a year and it's not really fresh in my memory anymore

[zaxlofful]

@ZepsiZola : Nope, I would still love to get any insight that you have!