What's coming in 9.1
-
Wanted to point out that 'Community packages' can be non-free (as in real money) as well. Many service providers have requested this, but automation of the purchase/discovery and related workflow is outside the scope of Cloudron. The package publisher can keep docker images private, and the end user just needs to set up a private docker registry to use the package (I guess the packager can create a docker registry API token per paying user or something like that).
-
I'm curious how the implementation for the community packages will look like. Are you saying you will monitor a manifest file and inside of the manifest would be a container tag, and when the manifest or the tag changes the app will be updated with this?
The custom app build and deploy functionality sounds quite neat. Since you mention it will be cli driven I suppose it is the responsiblity for the person running the cli to make sure that the right branch/tag is checked out?
-
Wanted to point out that 'Community packages' can be non-free (as in real money) as well. Many service providers have requested this, but automation of the purchase/discovery and related workflow is outside the scope of Cloudron. The package publisher can keep docker images private, and the end user just needs to set up a private docker registry to use the package (I guess the packager can create a docker registry API token per paying user or something like that).
-
@girish hey does this include databases containers like Postgress, MySQl, Mongodb, sql server etc? or databases still works as an addon? We need standalone database containers.
-
Hello @DualOSWinWiz
Yes you can also run custom apps that are just databases.@james said in What's coming in 9.1:
Hello @DualOSWinWiz
Yes you can also run custom apps that are just databases.So this meant their will be a port mapping facility as well great i dont know if its already their. I am anxious to see how backups and restore will handle the active connection to database.
-
Congratz Team Cloudron
Is there an approximate timeline for 9.1?The Custom app build & deploy + Community packages are something that the majority of us have been looking forward to for a long time
-
Congratz Team Cloudron
Is there an approximate timeline for 9.1?The Custom app build & deploy + Community packages are something that the majority of us have been looking forward to for a long time
@creative567145 in the meantime, give ccai a try
-
@james said in What's coming in 9.1:
Hello @DualOSWinWiz
Yes you can also run custom apps that are just databases.So this meant their will be a port mapping facility as well great i dont know if its already their. I am anxious to see how backups and restore will handle the active connection to database.
Hello @dualoswinwiz
@DualOSWinWiz said in What's coming in 9.1:
So this meant their will be a port mapping facility as well great i dont know if its already their. I am anxious to see how backups and restore will handle the active connection to database.
This needs to be addressed by custom app packager.
-
N nebulon referenced this topic
-
I'm curious how the implementation for the community packages will look like. Are you saying you will monitor a manifest file and inside of the manifest would be a container tag, and when the manifest or the tag changes the app will be updated with this?
The custom app build and deploy functionality sounds quite neat. Since you mention it will be cli driven I suppose it is the responsiblity for the person running the cli to make sure that the right branch/tag is checked out?
For the custom app build and deploy -
cloudron installuploads the package's source and there is a docker build running on the server. The source is part of the app backup. This means that when you restore back , it can rebuild from the source pacakge at that point in time and deploy it again. The design requires Dockerfiles to work reliably since the images are not "backed up" .Wanted to check if anyone had a concern that builds can be done on the server? For example, in theory, a build of some mega package can affect the existing apps. Should this feature be opt-in? Of course, every switch and configuration setting adds complexity.
Community packages - the plan here is to have a file called
CloudronVersions.json(or maybeCloudronVersions.json.gz). This is an array of "version" -> "manifest with dockerImage" mapping. This is how it is stored in the database in cloudron.io also. There will be a CLI commandcloudron versions add,cloudron versions publishetc to update that file (there is already acloudron appstoresubcommand, so this new one will loosely mirror that). This system allows: Listing versions of package, going back to old version, checking for new versions etc. Manifest is also saved per version allowing you to have icon/changelog/description/screenshots etc which is version specific. This single file has to be publicly hosted somewhere and doesn't need to be part of the package repo (though I imagine it would be).UI wise, there will be a button to "Install package" and you give a CloudronVersions.json URL and that's it.
Community "app store" - this is a listing of community packages. currently, not planned for. I think we need the above two stable to see if we need this. For a start, we can maintain a page somewhere which has all the community apps. Either here in the forum or the cloudron.io website or somewhere else . Ideally, this has to be self-editing/self-managed and shouldn't require cloudron.io team to add/edit stuff. Open to ideas.
-
G girish referenced this topic
-
For the custom app build and deploy -
cloudron installuploads the package's source and there is a docker build running on the server. The source is part of the app backup. This means that when you restore back , it can rebuild from the source pacakge at that point in time and deploy it again. The design requires Dockerfiles to work reliably since the images are not "backed up" .Wanted to check if anyone had a concern that builds can be done on the server? For example, in theory, a build of some mega package can affect the existing apps. Should this feature be opt-in? Of course, every switch and configuration setting adds complexity.
Community packages - the plan here is to have a file called
CloudronVersions.json(or maybeCloudronVersions.json.gz). This is an array of "version" -> "manifest with dockerImage" mapping. This is how it is stored in the database in cloudron.io also. There will be a CLI commandcloudron versions add,cloudron versions publishetc to update that file (there is already acloudron appstoresubcommand, so this new one will loosely mirror that). This system allows: Listing versions of package, going back to old version, checking for new versions etc. Manifest is also saved per version allowing you to have icon/changelog/description/screenshots etc which is version specific. This single file has to be publicly hosted somewhere and doesn't need to be part of the package repo (though I imagine it would be).UI wise, there will be a button to "Install package" and you give a CloudronVersions.json URL and that's it.
Community "app store" - this is a listing of community packages. currently, not planned for. I think we need the above two stable to see if we need this. For a start, we can maintain a page somewhere which has all the community apps. Either here in the forum or the cloudron.io website or somewhere else . Ideally, this has to be self-editing/self-managed and shouldn't require cloudron.io team to add/edit stuff. Open to ideas.
-
For the custom app build and deploy -
cloudron installuploads the package's source and there is a docker build running on the server. The source is part of the app backup. This means that when you restore back , it can rebuild from the source pacakge at that point in time and deploy it again. The design requires Dockerfiles to work reliably since the images are not "backed up" .Wanted to check if anyone had a concern that builds can be done on the server? For example, in theory, a build of some mega package can affect the existing apps. Should this feature be opt-in? Of course, every switch and configuration setting adds complexity.
Community packages - the plan here is to have a file called
CloudronVersions.json(or maybeCloudronVersions.json.gz). This is an array of "version" -> "manifest with dockerImage" mapping. This is how it is stored in the database in cloudron.io also. There will be a CLI commandcloudron versions add,cloudron versions publishetc to update that file (there is already acloudron appstoresubcommand, so this new one will loosely mirror that). This system allows: Listing versions of package, going back to old version, checking for new versions etc. Manifest is also saved per version allowing you to have icon/changelog/description/screenshots etc which is version specific. This single file has to be publicly hosted somewhere and doesn't need to be part of the package repo (though I imagine it would be).UI wise, there will be a button to "Install package" and you give a CloudronVersions.json URL and that's it.
Community "app store" - this is a listing of community packages. currently, not planned for. I think we need the above two stable to see if we need this. For a start, we can maintain a page somewhere which has all the community apps. Either here in the forum or the cloudron.io website or somewhere else . Ideally, this has to be self-editing/self-managed and shouldn't require cloudron.io team to add/edit stuff. Open to ideas.
@girish said in What's coming in 9.1:
The design requires Dockerfiles to work reliably since the images are not "backed up" .
I think for reliability it would probably be easier to backup the docker images instead of counting on well written Dockerfiles. But on the other hand even for these apps I would think the Cloudron base image will be used most commonly, so the chaos might be minimal.
Personally I would then rather use the community packages where I can have a pre built docker image that i can (more) easily deploy to Cloudron.
-
@girish said in What's coming in 9.1:
The design requires Dockerfiles to work reliably since the images are not "backed up" .
I think for reliability it would probably be easier to backup the docker images instead of counting on well written Dockerfiles. But on the other hand even for these apps I would think the Cloudron base image will be used most commonly, so the chaos might be minimal.
Personally I would then rather use the community packages where I can have a pre built docker image that i can (more) easily deploy to Cloudron.
@fbartels I should clarify further. The two features are for different use cases.
The custom app deployment was primarily to help people writing and deploy their own custom apps. There are many who are forking packages and adding some minor patches (because we don't allow customizations with readonly fs). This new mechanism will help people build+deploy easily. This does not require CloudronVersions.json. Only implemented in CLI. I think the CLI workflow gives the right messaging that they have to keep it updated themselves.
The community package always has a docker image associated and requires CloudronVersions.json. It was for people who want to share their packages with others and provide updates.
There is no plan to give a source URL in the UI and "build" from source. While technically possible, don't want people to expect "builds", "deployments" etc like a code deploy/PaaS. It's something for the future, if a use case exists.
Hope that clarifies!
