New Feature Idea - Container as a service (podman)

### The required feature described as a wish

Before jumping into this - I am recommending podman over docker due to licensing concerns based on my understanding - which could be limited.

This idea below can potentially solve the "Database as a Service" which is a highly desired feature...

As a user of Cloudstack and a small IaaS provider I often feel stuck when I want to simply create new containers for myself or my clients. I know I can go into my ubuntu and easily create it, but I feel we can do it better within Cloudstack. I want to provide my users with ability to manage (create, update, delete, change config etc) containers from the Cloudstack UI directly.
I know we have CKS available, but smaller teams or customers do not have the skills or staff to do things Kubernetes and the admin effort behind it.

I imagine the service working like the below along with how we can make this happen with small development:

1. On default UI the user will see a left hand side menu called "Containers". On going into this, the user can see a list of all existing containers with ability to start, stop, delete, update etc. There is a button "Add Container" on top right.
2. There is a second menu item that says "Manage Volumes" for data persistence (potentially other ones too such as registry credential manager, Key Value pairs for environment variables, Network, etc.). The user MUST create one Default Volume that can be used for container data storage. This is used as a default mount on all container VMs
3. The Volume Mount can be the NFS Mounts that are powered by the Shared FileSystems NFS service - to make sure the data is persisted. We have to force the user to create appropriate volumes to start with for data persistence so we can effectively manage server resources. This may mean that the container list needs to be curated?? not 100% sure on my thought here..
4. When a user clicks on Add container they see various items text boxes: Container Name, Image, registry credential, **RESOURCE LIMIT**, Volume Mount, Port mapping, custom commands etc. We perhaps need a setting on/off for "Persist Data" which can tell us whether a container can be removed when shutdown. The LOGS MUST be stored and available as a default.
5. When a user specifies all these items, behind the scene cloudstack does the follwing:
- Check to see if an existing Container VM is running and has enough available capacity. If not, Create a hidden VM with pre-defined minimum size (maybe a global config setting) OR the RESOURCE LIMIT specified earlier.
- The Container VM is hidden away from user and not visible in the Instances list
- Spin up the Container
- port forward the ports to the VM ports (there will need to be some intelligence here as if someone spins up two mysql server container then they will have to live on separate hosts due to same port 3306)
- Container is listed in the "Containers" area.

6. Container Actions:

- When a container is stopped, the podman stop my-container is issued. If a VM does not have any running containers, the VM can spin down after pre-set timelimit (from global config).
- If the "Persist data" is off, then issue podman rm my-container (but it still listed as a Container in our list).
- On starting a container the first check should be if there is any Container VM is already running and has the capacity available (spec of VM minus running Container resource limits). If yes, use the existing VM. if not start VM first and then start the container.
- For Containers that have "Persist Data" option, the VM and container should stay associated and we should not spin up that specific container on new VM as it will cause IP changes. NFS gets mounted for podman directly in yaml
- Update container should allow to update resource limits, and apply podman update --memory 512m my-container etc
- Upgrade version option should do a docker pull, stop, rm, and restart the container with exact same option settings as before
- Remove container should stop, rm and remove from container list

7. Usage tracking:

- Upon creation, start, stop of container
- Upon change of container memory, cpu etc.
- Persist data volume tracking
- Data usage for non-persist data volumes
- container logs

Empieza revisando la UI y las APIs existentes de CloudStack para el ciclo de vida de las VM, los sistemas de archivos NFS compartidos y el seguimiento del uso. Compara esas capacidades con los requisitos propuestos para contenedores, volúmenes, networking, persistencia y uso. Se considerará terminado cuando exista un alcance acordado e implementable, con un comportamiento del ciclo de vida y criterios de aceptación definidos.

Escrito por el modelo de indexación a partir del texto del issue.