This looks super cool and useful! I really like the idea of an open source replicated.
I've been through the docs and could find if there's a way to deploy a git repo, or a tar file, that contains the docker compose file instead if copy pasting. What about env variables?
Also couldn't find how you specify the endpoint(s) of an app. Does the agent just calls `docker compose up` or is there a way to specify the command(s) that should be executed during installation, upgrade, etc.
The customer portal is a great idea. It's not clear though, if the customer portal is enabled for a deployment and the customer can manage their deployment (eg, update to new version), would the isv not be able to do that from the vendor portal? Is it all or nothing when it comes to client self-service?
Thanks, great stuff I look forward to trying it out!
> I've been through the docs and could find if there's a way to deploy a git repo, or a tar file, that contains the docker compose file instead if copy pasting.
We are currently developing a GitHub Action utilizing our SDK to upload latest releases (and provide paths to the docker-compose file).
> What about env variables?
These are high up in our backlog and we are looking for initial partners to specify them with. We thought about using end-to-end encryption for env variables.
What would be an example for an endpoint?
> `docker compose up`
Yes currently this all what the agent does. We assume that most applications handle upgrades inside their applications and not on an infrastructure level. Do you have an exact upgrade case in mind?
Regarding the vendor and the customer portal, we want to enable both options. A deployment can either be managed by the vendor or by the customer. Some customers want to control when they want to perform upgrades and set certain variables or helm values themselves. In other cases it is fine if the ISV does all the management.
This is also what might be configurable in the future.
Thanks again, let us know if you know how can improve Distr. All feedback is welcome.
I'm a big fan of the trend of on-premise deployable software standardizing on Kubernetes/Helm as a deployment method. From my perspective as an external freelancers it provides a nice hand-off point to the internal IT/devops team.
Looking forward to trying this out on future projects!
----
I'm wondering how this relates to the glasskube package manager? Obviously you just launched, and maybe you are still in the discover phase, but is the general idea that this is the enterprisey incarnation of the glasskube ideas, and that it will over time gain similar features as the existing glasskube?
Good question, the Glasskube package manager is an alternative to Helm. As Distr is the management / distribution layer the layer connecting the deployment target to the ISV. On the deployment target the software gets installed via docker-compose, Helm or - in future - with the Glasskube Package Manager. The features don't really overlap they complement each other.
This looks super cool and useful! I really like the idea of an open source replicated.
I've been through the docs and could find if there's a way to deploy a git repo, or a tar file, that contains the docker compose file instead if copy pasting. What about env variables?
Also couldn't find how you specify the endpoint(s) of an app. Does the agent just calls `docker compose up` or is there a way to specify the command(s) that should be executed during installation, upgrade, etc.
The customer portal is a great idea. It's not clear though, if the customer portal is enabled for a deployment and the customer can manage their deployment (eg, update to new version), would the isv not be able to do that from the vendor portal? Is it all or nothing when it comes to client self-service?
Thanks, great stuff I look forward to trying it out!
Thanks!
> I've been through the docs and could find if there's a way to deploy a git repo, or a tar file, that contains the docker compose file instead if copy pasting.
We are currently developing a GitHub Action utilizing our SDK to upload latest releases (and provide paths to the docker-compose file).
> What about env variables?
These are high up in our backlog and we are looking for initial partners to specify them with. We thought about using end-to-end encryption for env variables.
What would be an example for an endpoint?
> `docker compose up` Yes currently this all what the agent does. We assume that most applications handle upgrades inside their applications and not on an infrastructure level. Do you have an exact upgrade case in mind?
Regarding the vendor and the customer portal, we want to enable both options. A deployment can either be managed by the vendor or by the customer. Some customers want to control when they want to perform upgrades and set certain variables or helm values themselves. In other cases it is fine if the ISV does all the management.
This is also what might be configurable in the future.
Thanks again, let us know if you know how can improve Distr. All feedback is welcome.
Very cool!
I'm a big fan of the trend of on-premise deployable software standardizing on Kubernetes/Helm as a deployment method. From my perspective as an external freelancers it provides a nice hand-off point to the internal IT/devops team.
Looking forward to trying this out on future projects!
----
I'm wondering how this relates to the glasskube package manager? Obviously you just launched, and maybe you are still in the discover phase, but is the general idea that this is the enterprisey incarnation of the glasskube ideas, and that it will over time gain similar features as the existing glasskube?
Good question, the Glasskube package manager is an alternative to Helm. As Distr is the management / distribution layer the layer connecting the deployment target to the ISV. On the deployment target the software gets installed via docker-compose, Helm or - in future - with the Glasskube Package Manager. The features don't really overlap they complement each other.
Wow. Very impressed, going to look into this.
Thanks, let us know what you think!