Multiple projects on a single server

[mrfelna]

Would just like to know the proper/intended way(s) to setup multiple Farcry 7 projects on the same server, both for production and development.

At the moment, this is the only way I know that works:

Farcry at C:\Farcry\ (for instance)

Global mappings
[CF] /Farcry --> C:\FarCry
[CF&IIS/Apache] /Webtop --> C;\FarCry\core\webtop\

Project A
Webroot at C:\FarCry\projects\ProjectA\www
URL: http://projectA.server/
Webtop: http://projectA.server/webtop/

Project B
Webroot at C:\FarCry\projects\ProjectB\www
URL: http://projectB.server/
Webtop: http://projectB.server/webtop/

Is there a setup where:

a) webtops can be shared?

Blocking access to the webtop for a specific host or domain

We often set up publishing platforms with a separate URL for admin or contributors.

For example, admin.magicalunicorn.com for admin and www.magicalunicorn.com for the general public

I’m not even sure how to set that up

b) server resources can be shared? (this is a long shot )

c) for development, using just a single domain for all projects (i.e. subdirectory deployment if this still works? https://farcry.jira.com/wiki/display/FCDEV60/Deployment+Configurations)

[jeff]

[CF] /Farcry --> C:\FarCry\

You don’t need to use a CF mapping (I don’t for any of my client websites or dev environment). Just create a web mapping (IIS/Apache) called “/farcry” and point it to the folder where the farcry core & plugins folders sit. This will make it easier to support different versions of FarCry for different projects (especially helpful when you have different clients using different FC versions).

c) for development, using just a single domain for all projects (i.e. subdirectory deployment if this still works?

I suggest using multiple domains in your dev environment to replicate what you’re doing in production. Sure you can do a single domain setup for dev, but you’re going to have a difficult time managing files between dev and production because they place many of the files in different locations. For dev what what most developers do is create a fake domain locally on the dev machine by editing the hosts file (works on both PC and Mac).

Example: If my production project is www.mysite.org I create a local fake domain called local.website.org. Some developers like to use the format www.website.local - I prefer the latter for a little more flexibility, but whatever format you choose will work fine. Doing this will allow you to easily replicate your production environment and the only customization will be in your local web server (pointing it to the fake domain rather than the real domain). The other way I find it comes in handy is when I want to run custom javascript tracking code, but only in production. In the code I wrap the javascript in a condition that looks for “local.” as the prefix of the domain.

b) server resources can be shared? (this is a long shot )

Not sure what you mean by this question. Can you clarify?

[mrfelna]

You don’t need to use a CF mapping

I was worried about accessing files above the webroot and the ColdFusion mapping works just as well

This will make it easier to support different versions of FarCry for different projects

How?

I suggest using multiple domains in your dev environment to replicate what you’re doing in production.

That’s what I do for my primary projects, but for experimenting, creating projects to reproduce bugs/test changes it’s a bit annoying to alter hosts for each new one. The idea being that with a shared webtop and subdomains, projects could be created much faster as only a datasource would need to be setup. The webserver, url, railo/lucee contexts would work for any number of test/experimental projects.

Not sure what you mean by this question

Server memory etc. E.g. in each project we have various common farcry functions in the application scope. I was wondering if there was any benefit to sharing access but like I said - long shot

[jeff]

How?

If you use a CF mapping, then you’re locked to that version of FarCry on that server. If you use a web mapping to the farcry root folder for each project, then you can use a different flavor of FarCry for different scenarios/clients (probably only helpful in dev environment). You are welcome to use a CF mapping if you prefer. It won’t break anything.

The idea being that with a shared webtop and subdomains, projects could be created much faster as only a datasource would need to be setup.

Unfortunately FarCry doesn’t offer this. Funnily enough, this was one of my very first requests back in 2003/2004. But FarCry is just not built that way.

Server memory etc. E.g. in each project we have various common farcry functions in the application scope. I was wondering if there was any benefit to sharing access but like I said - long shot

Unfortunately you cannot share resources. FarCry caches data in the application scope and each project uses its own application scope.

[justincarter]

When we deploy multiple apps on the same server we usually keep the directory structures separate because it gives us more flexibility over which version of core and which version of plugins are used by each app. It’s also a more robust way to deploy your apps because an update to core or a plugin for one app won’t accidentally break another app.

So your applications on the file system might look something like;

/sites/appA
/sites/appB
/sites/appC

and for each application;

/sites/appA                    -- /farcry "mapping"
/sites/appA/core
/sites/appA/core/webtop        -- /webtop "mapping"
/sites/appA/plugins/googleud
/sites/appA/projects/appA
/sites/appA/projects/appA/www  -- webroot

CF mappings affect the entire server so for CF we’d generally use an Alias (in Apache) or a Virtual Directory (in IIS) instead which can be configured per application.

In Railo/Lucee mappings can be per web context so we don’t have to worry about this when setting up multiple sites (and the mappings are required in this case – in CF the connector has some magic that allows Alias/Virtual Directories to be picked up and used as mappings).

To answer your questions:

a) webtops can be shared?

We have a few clients that run multiple sites from a single database/application, but this really only works when you’ve got a whole bunch of sites that re-use the same design, minus some logo and colour changes (i.e. the code base is actually identical). They still log on to each site using different domains though, so the webtop isn’t really “shared” even though it’s the same application.

b) server resources can be shared? (this is a long shot )

The only common thing I can think of in terms of sharing resources is Perm Gen space, perhaps if all your apps were mapped to the same copy of core then there could be some small benefit, but probably not enough to bother with – I wouldn’t recommend it

c) for development, using just a single domain for all projects (i.e. subdirectory deployment if this still works? https://farcry.jira.com/wiki/display/FCDEV60/Deployment+Configurations)

We’re thinking of retiring the “directory deployment” option in the next major version of FarCry Core, mostly because we haven’t needed or wanted to use this type of deployment for many years and a refactor of the application startup is in order, and removing support for this could simplify a few things.

If you need to have multiple apps that live in different “directories” but are all served from the same domain I’d recommend something like Varnish of nginx for proxying the requests, it’ll give you more flexibility and also the opportunity to use caching as well.

The alternative directory structure which shares core and plugins might look like this;

/sites/farcy                     -- /farcry "mapping"
/sites/farcry/core
/sites/farcry/core/webtop        -- /webtop "mapping"
/sites/farcry/plugins/googleud
/sites/farcry/projects/appA
/sites/farcry/projects/appA/www  -- webroot appA
/sites/farcry/projects/appB
/sites/farcry/projects/appB/www  -- webroot appB

However as I said above, this is a much more restrictive way to deploy your apps because you are locking yourself into using the exact same version of core and plugins, and a core or plugin upgrade might be OK for one app but accidentally break another app. I would try to avoid this scenario and go with the method I described at the top of this post