An idea to extend Tiki Manager and maybe as an addition to Tiki Manager within Tiki
Tiki Manager changes its role to a config management tool which enables Tiki Users to control versions, instances, domains and related infrastructure of the environment.
Isn't Tiki a CMS?
Yes, but it's already capable of applying configs via profiles based on YAML and the recent integration with Virtualmin lead to the integration of Tiki Manager into Tiki as a Package. And utilizing its version control, permission system etc., it's plausible to extend it towards a no-code app and SaaS utility. It could revolutionize the approach of how Tiki instances and related services are managed.
Why
Controlling multiple Tiki instances and the related environment via a integrated feature seems the next logical step and will help to shift towards a data driven no-code app builder framework based on 12 factor-app principles.
Defining tiki-manager services (like in docker-compose) and create reproducable sets of configurations is important for scalablility and ease of maintenance.
As Tiki already has a YAML parser and uses this Format for profiles it would be natural to use YAML to define tiki "services" via its API (as far as I understand the Kanban board already utilize this but via code base) by saving Tiki-Manager Configs in Yaml and be able to apply profiles, tiki system configs and settings etc through this mechanism.
But why stop there? Tiki (via Tiki-Manager) could also utilize its API capabilities and the YAMLs to spin off virtualmin, lxd-container, docker/docker-compose or/and kubernetes services in a collaborative manner with fully integration of all tiki features.
This will ultimetively lead towards a Tiki SaaS capable of controlling multiple sites, utilizing multiple virtualization technologies (docker/docker-compose, kubernetes, virtualmin) and from this adding countless applications in endless combinations. For example we could mix docker/docker-compose based search-engine instance on port xy with a virtualmin based webserver and a lxc container running an isolated sub-service.
How
Extending the config format wih a meta level above the docker/docker-compose, virtualmin, kubernetes or lxc config like so (stub)
Tiki Config Yaml MetaService: --WikiSuite: ----sub-service: ------vírtualmin: --------with email: ----------email-host-param=xy ----------ports --------other virtualmin params ------docker/docker-compose --------Top lvl original docker/docker-compose-compose ------kubernetes ------lxc
Short term
Using those config files to create and manage tiki-manager cofigurations with virtualmin and adding later other "targets" like docker-compose will add flexibility to the tiki infrastructure management.
For that to happen we need to check how the YAML parser can be made aware of the extra "levels" and to trigger the according api's
Example docker-compose.yml for mautic (my mautic)
Contains all required settings to run behind reverse proxy and getting SSL. By optionally defining multiple external networks (here it is named webproxy) we can isolate stacks from each other.
version: '3' services: mauticdb: image: percona/percona-server:5.7 container_name: mauticdb volumes: - mysql_data:/var/lib/mysql environment: - MYSQL_ROOT_PASSWORD=mypasswd - ADMIN_EMAIL=webmaster@domain.tld - PUBLIC_URL=subdomain.domain.tld - VIRTUAL_HOST=subdomain.domain.tld - LETSENCRYPT_HOST=subdomain.domain.tld - LETSENCRYPT_EMAIL=webmaster@domain.tld command: --character-set-server=utf8mb4 --collation-server=utf8mb4_general_ci mautic: image: mautic/mautic:latest container_name: mautic links: - mauticdb:mysql depends_on: - mauticdb volumes: - mautic_data:/var/www/html environment: - MAUTIC_DB_HOST=mauticdb - MYSQL_PORT_3306_TCP=3309 - MAUTIC_DB_USER=root - MAUTIC_DB_PASSWORD=mypasswd - MAUTIC_DB_NAME=mautic - MAUTIC_RUN_CRON_JOBS=true volumes: mysql_data: driver: local mautic_data: driver: local networks: default: external: name: webproxy
Example docker run command (my portainer instance)
RUN command containing all required settings to run behind automated reverse proxy and getting automatically SSL certs via letsencrypt.
docker run --name initboxportainer -d --net webproxy --ip 172.18.0.222 \ -e "VIRTUAL_HOST=subdomain.domain.tld" \ -e "VIRTUAL_NETWORK=webproxy" \ -e "VIRTUAL_PORT=9000" \ -e "LETSENCRYPT_HOST=subdomain.domain.tld" \ -e "LETSENCRYPT_EMAIL=webmaster@domain.tld" \ -p 127.0.0.1:9000:9000 -v /var/run/docker.sock:/var/run/docker.sock --restart always portainer/portainer-ce:2.11.0
Portainer (inspiration)
Portainer acts like an example implementation. Portainer utilizes kubernetes and docker/docker-compose APIs and wraps a GUI arround those.
Nice thingy is the portainer agent which exposes the APIs on remote machines towards the local gui.
The Templates are great for easy stack deployment.
https://www.portainer.io/
https://docs.portainer.io/v/ce-2.11/api/examples
https://github.com/portainer/templates
References:
https://linuxcontainers.org/lxd/docs/master/preseed/ and partial API doc
https://www.virtualmin.com/documentation/developer/http/ (Sales-Pipeline uses a different one/ a wrapper?)
Maybe of interest for service discovery
https://github.com/willdurand/Negotiation
Content Negotiation: for versions and relations