Johno2518 Posted August 9 Share Posted August 9 In moving forward, Invision should release a Docker Container image (via a registry of course) in addition to or instead of zip files. I would imagine the preference would be for a Linux container only. This keeps everything simple and consistent. If add-ons are required then they can be downloaded and "installed" to persistent storage attached to the container or someone can build ontop of the official release. I would think this is the approach Invision have taken for deployment/maintenance of the Cloud offering and so it would simplify and align the classic offering. asd937 1 Link to comment Share on other sites More sharing options...
Marc Posted August 9 Share Posted August 9 19 minutes ago, Johno2518 said: would think this is the approach Invision have taken for deployment/maintenance of the Cloud offering and so it would simplify and align the classic offering. Good guess, but nope 🙂 Ryan Ashbrook, AlexWebsites and asd937 1 1 1 Link to comment Share on other sites More sharing options...
Johno2518 Posted August 19 Author Share Posted August 19 On 8/9/2024 at 7:51 PM, Marc said: Good guess, but nope 🙂 What are the show stoppers? Link to comment Share on other sites More sharing options...
Marc Posted August 19 Share Posted August 19 42 minutes ago, Johno2518 said: What are the show stoppers? What are the show stoppers for what? Im not sure what you are asking here Link to comment Share on other sites More sharing options...
Johno2518 Posted September 3 Author Share Posted September 3 On 8/19/2024 at 9:20 PM, Marc said: What are the show stoppers for what? Im not sure what you are asking here What are the show stoppers or considerations for not using container images? Link to comment Share on other sites More sharing options...
Marc Posted September 3 Share Posted September 3 6 hours ago, Johno2518 said: What are the show stoppers or considerations for not using container images? I'm not sure I said that there are show stoppers for not using container images. What I said is its not how our cloud platform works. In fact a cloud site is actually implemented quite differently to that of a traditionally hosted platform Its worth noting, that when looking at feedback and suggestions, there has to be a value add for us to make such changes. In the case of this, it would be quite a large change to our current methods of deployment, for quite little payback. This isnt to say that a decision has been made not to (that would not be mine to make). I'm just saying its not quite as simple as saying "This hasn't been implemented because there are showstopping issues that stop us from doing so". Most suggestions are perfectly doable, its just most dont make sense to do within the scope and vision of our platform. Link to comment Share on other sites More sharing options...
Johno2518 Posted Thursday at 12:36 AM Author Share Posted Thursday at 12:36 AM I think there is varying definitions of traditional platforms. To me traditional is standing up infra to host the application. The modern approach is to use containers which removes the issues of what to include or not and how it's hosted. Spin up a container with required parameters and it's up and running - no need to think about which PHP version is needed, which Apache version or NGINX or whatever is needed etc. I would think this would be of significant value considering this is one reason Invision doesn't support the product on Windows/IIS - understandable you don't want to support a myriad of different platforms and configurations which is one thing containers address. I'd also think this add's a ton of value to the cloud offering. When you say "vision of the platform" - part of that is how to modernise the deployment and upgrade/rollback experience and it would be good to know what options have been considered and why certain things have been ruled out because it gives us insight into what Invision is thinking about it's product and services. Link to comment Share on other sites More sharing options...
Marc Posted Thursday at 07:14 AM Share Posted Thursday at 07:14 AM 6 hours ago, Johno2518 said: I would think this would be of significant value considering this is one reason Invision doesn't support the product on Windows/IIS - understandable you don't want to support a myriad of different platforms and configurations which is one thing containers address. I'd also think this add's a ton of value to the cloud offering. As with the above assumption on how our cloud platform works, this is also incorrect. We dont actually support any environment. We support the product, and state the following Quote Our software works with all modern web servers (Apache, nginx, lighttpd, etc.) that can support secure versions of PHP (with GD, mbstring and all default extensions) and MySQL. The added line related to windows server is in absolutely no way at all related to how its set up. Its related to the fact we have seen on many occasions issues when people are using IIS. Usually surrounding things like permissions etc, but often related to the underlying server setup. Not necessarily just IIS. Quote I'd also think this add's a ton of value to the cloud offering. I have to admit to being a little confused as to why you believe this to be the case? We don't "spin up" a new box when someone creates a new cloud instance. Its essentially just an account. While it will have it owns files (things that people have uploaded) and its own data, it doesn't necessarily mean it will have its own instance of the software. You are thinking of this in terms of an installation that is done on self hosted, and cloud just doesn't work in that manner in any way. 6 hours ago, Johno2518 said: When you say "vision of the platform" - part of that is how to modernise the deployment and upgrade/rollback experience and it would be good to know what options have been considered and why certain things have been ruled out because it gives us insight into what Invision is thinking about it's product and services. We are not likely to get into the decisions made on a daily basis for each items we decide on. Its simply not feesable. We have too many things we make decisions on daily. However I can put this into some context for you by asking you a simple question. If in your job, whatever that happens to be, you could do something that would add nothing at all in terms of value as a company. Would you do it? The reality is, the 'self-hosted' product is a shrinking market. We have made changes to the licensing to ensure that its viable for the immediate future for our customers. But we need to be selective over what we spend development time on, and things such as these are not really of huge value. Note again, it's not a decision that I would personally make. However I'm giving you the reasoning why its probably unlikely. G17 Media 1 Link to comment Share on other sites More sharing options...
G17 Media Posted Friday at 05:58 PM Share Posted Friday at 05:58 PM (edited) On 9/3/2024 at 1:37 AM, Johno2518 said: What are the show stoppers or considerations for not using container images? IPS won't do this because their cloud system doesn't work like this. However, we actually locally maintain our own Docker "master image" which has all of our custom apps and tweaks to IPS - as well as custom written ability to automatically upgrade (e.g. automatic database and IPS formatted application upgrades) as well as automatically install for testing branches etc. It doesn't actually require any changes to IPS' core code (at least for v4 😆), so you can definitely hire a developer or work on doing the same in-house if you want a serviceable Docker image. IPS give us the software, it's up to us how we chose to install/deploy/configure it. Edited Friday at 05:59 PM by G17 Media Nathan Explosion, Marc, Daniel F and 2 others 5 Link to comment Share on other sites More sharing options...
Recommended Posts