On Friday, August 11, 2017 at 8:10:38 AM UTC-4, Walter Lee Davis wrote:
>
>
> > On Aug 11, 2017, at 2:34 AM, Colin Law <cla...@gmail.com <javascript:>> 
> wrote: 
> > 
> > On 10 August 2017 at 13:36, fugee ohu <fuge...@gmail.com <javascript:>> 
> wrote: 
> >> 
> >> 
> >> On Thursday, August 10, 2017 at 3:01:06 AM UTC-4, Colin Law wrote: 
> >>> 
> >>> On 10 August 2017 at 07:50, fugee ohu <fuge...@gmail.com> wrote: 
> >>>> One of my apps drives the others and stores pictures that the others 
> use 
> >>>> Both apps are on the same server How do i build a link to the image 
> on 
> >>>> the 
> >>>> other app? 
> >>> 
> >>> You could use image_tag possibly. 
> >>> 
> >>> Colin 
> >> 
> >> 
> >> how do i get above / ? 
> > 
> > Good point, you will have to arrange the upload to save to a location 
> > visible to both servers, or accessible via another server, and do the 
> > download link manually. 
> > 
> > Colin 
>
> There's many ways to get this to work, and depending on how your server(s) 
> is/are architected, some are more elegant than others. 
>
> In one application I built, there are three separate VPS hosts: database, 
> admin, and public. Admin and public have the same NFS share mounted to each 
> of them, with admin able to write to it, and public only able to read from 
> it. The NFS share is defined in my file upload gem (Dragonfly) as the place 
> where files are written. Dragonfly is somewhat unique in how it manages 
> files (everything is proxied through a Rack app, never hosted directly 
> through Apache/Nginx) so this means I don't have to have that NFS directory 
> in the app's public/system/whatever path. But even if I wanted to allow 
> direct httpd hosting of uploaded images, I could do that through the Apache 
> configuration file, by aliasing a folder from /mount/nfs/share/whatever 
> into public/system/images, for example. 
> https://httpd.apache.org/docs/2.4/urlmapping.html#outside 
>
> So that's an extreme example, brought about by having these apps on 
> different (quasi-physical) servers. If you were hosting them on different 
> virtual hosts on the same server (real or virtual), then your task is a lot 
> simpler. Forget about the NFS mounts, and just configure your Web server to 
> include the same directory, as above, and ensure that only one app is 
> writing into that folder, and both are sharing a single database, so that 
> the apps don't get confused. 
>
> And I've completely overlooked S3 (or any of its various clones), which is 
> sort of a giant share-point in the sky. If you use Fog or another cloud 
> storage adapter, you can treat S3 as you would a local folder, and two or 
> more servers can be configured to use the same S3 "bucket" at the same 
> time. With UUID primary keys, you don't even need to coordinate the 
> databases. 
>
> As far as building a link goes, my apps assume that only one app is doing 
> the writing, and the other one is read-only, so they share a database. 
> Building a link is in the normal Rails manner, based on an ID. But if you 
> had two independent apps that didn't share anything, you would need to 
> build a bridge between them. One could advertise the images it has 
> available through an API, and the other could use that API to periodically 
> update a local cache of what images are available, for example, and what 
> their addresses are, and use those directly. You would build an image tag 
> with the src set to //other.host.dom/path/to/image.jpg rather than 
> pretending it was on your local server. 
>
> In the end, your solution will depend entirely on what your needs are. In 
> my example above, I needed to support a team of editors, who could write 
> things and add metadata to them and approve them, and a largish audience 
> who were read-only on the things that were complete and "published". You 
> might get some more focused solutions for your problem if you can 
> articulate why you have separated these concerns. 
>
> Walter 
>
 
 Different virtual hosts on the same server I need to symlink or set 
something in nginx.conf?

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-talk/7a0aa835-14ba-465b-aa53-b2f8fb60d906%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to