5 ms·
This is pretty neat. Since a new server is launched for every preview, it would be cool if the packaging used cloud-init vs docker-compose. If containers are
by moondev 6y ago
This is pretty neat.
Since a new server is launched for every preview, it would be cool if the packaging used cloud-init vs docker-compose.
If containers are a focus perhaps you could support k8s deployment/svc manifests and compose via something like https://github.com/kubernetes/kompose https://github.com/kubernetes/kompose
For k8s you could quickly launch a single node cluster with kind
- crohr 6y ago> Since a new server is launched for every preview, it would be cool if the packaging used cloud-init vs docker-compose. Actually the way it works now is that you keep the same server for the duration of a PR / branch. This means faster redeploys since the docker cache is there, and you don’t lose your demo data on every redeploy. Cloud-init is used for the initial setup of docker and compose, but then the code sync happens through sending the app tarball from GitHub to the server and refreshing the compose. We thought about mono-node k8s, but found that removing one abstraction layer would be better for now. Thanks for your comment!