topic Re: Moving files to production environment - Resolving url in Alfresco Archive

Moving files to production environment - Resolving url

guhann — Wed, 18 Jul 2007 11:28:36 GMT

Hi,Now i have my files ready. I dont have a clear idea about moving the files to the production enivornment/deployment process.I just want this cms application to be used by editors, the website content should be viewable to the public in some url like http://www.src.ukIn sandbox im getting this url

Re: Moving files to production environment - Resolving url

kvc — Wed, 18 Jul 2007 20:55:54 GMT

The virtualization server and it's dynamically-assigned URLs (to create preview contexts for your site / app) are not intended to be used in the run-time environment. They are for use in the authoring server only.

In 2.0.1 Enterprise, a snapshot of Staging in a Web Project can be deployed to a remote Alfresco server (or many) which serve as your run-time content delivery repository. This run-time server could be mapped as a network drive, which your app resources (code and content) served directly off CIFS, or, in the more typical case, your app code fetched via CIFS but content sourced via APIs from the Alfresco repository.

In 2.1.0 Community RC2 (target this Friday), we introduce the compatible notion of deployment of a specified set of directories to one or more file-servers. In 2.1.0 RC2, your application code (and perhaps certain large file types like videos) are to be deployed to the file-system for use by your app server, with the web project content deployed to the run-time repo (which is now indexed for search). In 2.1.0 Community then, you can also separate your app tier from the Alfresco repo tier from Alfresco's own underlying DB tier.

In either case, the system is designed to support any run-time environment (even non-Java ones like PHP, which, although not supported by the virt server for dynamic in-context preview and requiring hand configuration of separate preview environments for each sandbox, can still be fully managed, deployed, and hosted from Alfresco). And in that run-time environment, however you wish to name your map your site URLs should be entirely up to you.

We'll be providing a primer for this along with our 2.1.0 Enterprise release some weeks after our upcoming RC2 Community build.

Kevin

Re: Moving files to production environment - Resolving url

guhann — Fri, 20 Jul 2007 06:43:21 GMT

Hi Kevin,

Thanks for that… My understanding is that the cds pages are launched in a separte server like apache(and we provide url of our wish).

For the content management part we need to map the alfresco repository(AVM) with that apache folder structure, so that changes done in alfresco will get reflected in the apache folders and the files are served from webserver apache.

Is that correct?

Regards,
Guhan N

Re: Moving files to production environment - Resolving url

kvc — Fri, 20 Jul 2007 10:19:13 GMT

Guhann:

Yes, the directory structure contained within your web project should correspond to the directory structure you wish to sit under your run-time web server.

Now, the pre-pending path we have while those assets are in alfresco (the path to the web project and sandbox and root directory) get "thrown-away" when you push using our FS deployment mechanism. You map your root dir to any remote dir, and for all intents and purposes, anyone looking at your run-time environment wouldn't even suspect that Alfresco managed and deployed those assets at all.

Kevin

Re: Moving files to production environment - Resolving url

guhann — Fri, 20 Jul 2007 12:24:10 GMT

Thanks…

in apache webserver conf/httpd file if i change the below path

DocumentRoot "C:/Program Files/Apache Software Foundation/Apache2.2/htdocs"

to the path where im having the CIFS shared avm repository then it will work perfectly?
ie.) "z:/AVM/DATA……"

Re: Moving files to production environment - Resolving url

guhann — Fri, 20 Jul 2007 12:56:52 GMT

Hi kevin,

I tried that … i can't able to start the apache webserver if i change the directory to remote directory like "z:/ROOT" . Is that possible to set the root directory like z:/ROOT i.e)other than the apache webserver directories?

i have my apache webserver directory under c:/programfiles/apache…..

Regards,
Guhan N

Re: Moving files to production environment - Resolving url

guhann — Wed, 25 Jul 2007 12:27:42 GMT

can anyone help me on this???

setting up the root directory…………… how should i use the url there
whether need to mention the machinename / mapped drive(Z:/) is enough…

It's not at all working for me…..

Re: Moving files to production environment - Resolving url

jcox — Thu, 26 Jul 2007 06:10:39 GMT

guhann,

If you want to serve content directly from an Alfresco repository,
it's very easy to present a pretty-looking URL to the
outside world for a particular sandbox using Apache 2's
reverse proxy feature.

For example, suppose we have a sandbox for the user alice
within the web project "mysite", which is hosted by a virt server
on port 8180 of a machine who's IP address is 192.168.1.5.

Normally, you'd access it via your browser using URL looking something like this:

http://alice.mysite.www--sandbox.192-168-1-5.ip.alfrescodemo.net:8180/

Instead though, suppose we what this to appear to the outside world as:

http://example.com/

All you'd need to do is set up Apache2 as a reverse proxy
on example.com that fetches its real data from the virt server.
On example.com, your Apache2 config would look like this:


ProxyRequests off
ProxyPass           /  http://alice.mysite.www--sandbox.192-168-1-5.ip.alfrescodemo.net:8180/
ProxyPassReverse    /  http://alice.mysite.www--sandbox.192-168-1-5.ip.alfrescodemo.net:8180/
‍‍‍‍‍

Now, suppose a user in the outside world goes to:

http://example.com/moo/cow.html

What happens is Apache 2 on example.com fetches data from:

http://alice.mysite.www--sandbox.192-168-1-5.ip.alfrescodemo.net:8180/moo/cow.html

That data is then served back to the user.
The idea is that you can hide a backend server (i.e.: the virt server)
behind a front end (i.e.: apache2), and the end user's browser will
never know. Thus you can make the URLs look however you wish.

Typically, you'd do this for staging sandbox, not a user sandbox,
so instead our config might look more like this in the real world:


ProxyRequests off
ProxyPass           /  http://mysite.www--sandbox.192-168-1-5.ip.alfrescodemo.net:8180/
ProxyPassReverse    /  http://mysite.www--sandbox.192-168-1-5.ip.alfrescodemo.net:8180/
‍‍‍‍‍

Once you get your mind around configuring Apache2,
there's a lot of power here!

Cheers!
-Jon

PS:
I'll put this in the virtualization server FAQ.

Re: Moving files to production environment - Resolving url

guhann — Thu, 26 Jul 2007 09:39:37 GMT

Thanks for that……………

It works great !!

in httpd file i removed the comments for the below proxy modules,

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so

and added reverse proxy as u mentioned above…

Everything is working fine. Hope i can go with this logic itself in production instead of using CIFS. Any suggestions/advice to share with this?

Re: Moving files to production environment - Resolving url

jcox — Thu, 26 Jul 2007 16:38:37 GMT

Guhann,

Thanks for the feedback !

The thing you've got to assess for yourself is performance and scalability.
There are many ways to measure this, and many different kinds of load
your site might experience depending upon the nature of your content,
and the pattern of use experienced by the site. Some sites are very
bandwidth heavy, some demand more CPU and/or memory, some tend
to get more bursts of activity from users than others, and so on.

Here are some things to consider:

HTTP caches can make a dramatic difference

Be sure you understand caching in HTTP.
Apache2 has mod_cache but there are alternatives.
Use URLs consistently (i.e.: same content == same url, when possible)
Avoid replacing files on update when contents have not changed.
Prefer GET over POST (some caches don't store POST responses)
Limit cookie use to dynamic pages
Avoid embedding user info in URLs

Horizontal scaling. For example, see: mod_backhand
The features/performance trade-off of using AVM versus deploying to native file system
Separation of development environment from live environment

The last two points are probably worth discussing in more detail.
While serving content directly out of an Alfresco AVM instance will offer
you a wider set of features, nothing is going to beat the performance
of deploying your webapp to a native file system and serving content
directly off of that (e.g.: on UNIX, an ext3 file system, on NT, NTFS).

Whether you want to serve content out of the AVM directly
or off of a native file system, I strongly advise you to make
your entire live/customer-facing infrastructure totally independent
of the one you're using for development (by that I mean machines,
processes, databases, disks, and ideally different subnet too).
The idea here is to make it so no matter how hard users or developers
pound on things, no matter what security issues arise, what network
traffic is generated, or what sort of maintenance/upgrade/reboot
shenanigans are necessary from time to time, doing something
to one system does not effect the other in any way.

If you are going to serve content directly out of the AVM, caching
might be more important.    There are so many variables when it
comes to this stuff that the best advice is to test with a realistic
load, measure, tune, and experiment with the many options available
to you.   Once you've done that, throw your system some curve-balls
such as alternating periods of quiescence and high load, long sustained
periods of activity, lots of simultaneous requests, fewer but heavy
requests, and so forth.

A lot of how paranoid you've got to be depends on the sheer scale
of what you are doing, the audience you're serving, and your site's
technical & business requirements. Therefore, I can't really provide
"one size fits all" advice, but hopefully the ideas I've discussed here
are still interesting & useful.

Let me know how it goes.

     Cheers,
     -Jon