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

Bắt đầu bằng cách xem xét UI và APIs hiện có của CloudStack cho vòng đời VM, các hệ thống tệp NFS dùng chung và việc theo dõi mức sử dụng. So sánh các khả năng đó với những yêu cầu được đề xuất về container, volume, networking, tính bền vững và mức sử dụng. Công việc được xem là hoàn tất khi có một phạm vi đã được thống nhất và có thể triển khai, với hành vi vòng đời và các tiêu chí nghiệm thu được xác định.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.