Separating the data from the code for Azure Web Site hosting

[davidebbo]

I'd like to play around with a different way of hosting Ghost in a Windows Azure Web Site (compared to what's discussed in #830). In the model I'm envisioning:

• The code would live in a shared folder instead of being part of the site files. That folder would be readonly. This would include both the core code and the npm packages. This folder would be managed by Azure as a sort of 'Gallery' code base.
• The data would live in the site files. This would include the DB, themes, and whatever else can be considered 'user state'.

Some of the benefits of this model:

1. Site creation is much faster since only the starter data files need to be created.
2. Site cold start time is faster because the shared drive (where all the code lives) is much faster than the site drive. In Azure, the site drive is mounted on blob storage, and it's much slower than a regular drive.
3. User disk space doesn't get eaten up by code files.
4. If a user looks at the site file (e.g. with FTP), there is no chance that they can mistakenly mess up the code.
5. The site can potentially be updated to a newer Ghost version without touching any user files. All it takes is to point the code to a newer version (configurable).

One obvious drawback is that the user loses the ability to tweak the core logic, but my take is that only a very small number of users want to do that, and those who do can always deploy the 'old fashion' way.

Question: how easily can I tweak Ghost to configure where it writes all its data files?

[gotdibbs]

I think @ErisDS is going to need to weigh in on this one, but my initial thoughts are:

• I like the general idea of increased performance and a "safety net" around the core code.
• It's worth noting Ghost supports more than just SQLite3 for a DB, so if you wanted to, you could just hook it up to MySQL in Azure. Wouldn't that leave just themes as the only "unguarded" piece of user state?
• How exactly would the code folder be marked read-only? Would this not prevent Ghost from being able to update itself?
• I think its generally accepted that we won't make significant architecture changes that are only required to support one host. Therefore the changes in general would need to provide more benefit than just "it makes things in Azure work better" or would have to be minimally intrusive.
• At the very least, I can't imagine a configuration setting for the Content folder being a bad idea, and I would imagine it would be fairly simple. Would the suggested change for Azure just involve pointing Ghost to another UNC path? Or is there more involved than that to go across the storage boundaries you mention in Azure?

[davidebbo]

This should not entail any significant architectural changes. It's pretty much just allowing the path to the data folder to be configurable (via config file and/or environment variable). There wouldn't be anything Azure specific. Also, if Ghost creates any log files, we'd need to make sure that it doesn't try to write them in the readonly folder.

How the folder would be readonly: it would be based on our new Site Extension mechanism, which allows some pre-installed bits to affect the site.

Would it prevent self-update: yes, in this model update would be done differently, in a more centralized fashion.

[ErisDS]

At the very least, I can't imagine a configuration setting for the Content folder being a bad idea, and I would imagine it would be fairly simple. Would the suggested change for Azure just involve pointing Ghost to another UNC path? Or is there more involved than that to go across the storage boundaries you mention in Azure?

It's not a bad idea at all, and in fact it would be good to make these things configurable for the benefit of many different setups and I raised an issue to do it #1364 (it's a general issue, nothing to do with Azure).

I don't think there is anything else required in order to do what is described here, so I'm not sure whether we need to keep this issue open?

[gotdibbs]

I still have a concern about breaking our built-in auto-update functionality by going this route with Azure, but I think the only change that would need to be made at the moment is in fact covered by the issue you reference @ErisDS

[ErisDS]

Going to close this in favour of #1364

[davidebbo]

Sounds good, thanks Hannah!