[Geoserver-users] Geoserver to Ruby on Rails

GeoServer GeoServer User
1

Hello Everyone,

This isn’t necessarily a Geoserver question, but I am hoping to get some advice from this group on what tools and tips will make this work. I have a web application that consumes wms produced by Geoserver. Currently we have a large number of layers and view that connect directly to the PostGIS database. Generally speaking our applications using Ruby on Rails for connecting to the database.

As the database changes the applications reflect these changes. We have three ruby environments (demo, staging, live) each with multiple database, which may or may not be serving the active application. I want to abstract out the connection logic when defining a layers/view so that and when they are when created they look to the environment not the actual database. Is anyone doing something like this and can offer some ideas.

···

David Haynes, Ph.D.
Research Associate Terra Populus
Minnesota Population Center
612-626-3933
www.terrapop.org

2

Hi David,
     I am not sure I quite understood your use case, but here's an idea:

     You may point you datasources to a local host address defined in /etc/hosts (for example: "geoserverdatabase"), preferably one that is not resolvable by your internal dns.
     To change between demo/staging/live db servers, you just have to change the address that your "geoserverdatabase" server points to in /etc/hosts, without changes to your application code or geoserver configuration.
     I have just tested this here and it works.

Best,
Daniel

Em 18/08/2016 18:37, David Haynes II escreveu:

Hello Everyone,

This isn't necessarily a Geoserver question, but I am hoping to get some advice from this group on what tools and tips will make this work. I have a web application that consumes wms produced by Geoserver. Currently we have a large number of layers and view that connect directly to the PostGIS database. Generally speaking our applications using Ruby on Rails for connecting to the database.

As the database changes the applications reflect these changes. We have three ruby environments (demo, staging, live) each with multiple database, which may or may not be serving the active application. I want to abstract out the connection logic when defining a layers/view so that and when they are when created they look to the environment not the actual database. Is anyone doing something like this and can offer some ideas.

--
David Haynes, Ph.D.
Research Associate Terra Populus
Minnesota Population Center
612-626-3933
www.terrapop.org <http://www.terrapop.org>

------------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

3

Thanks Daniel, that’s not exactly what I am looking for does this clear it up?

We have an instance of GeoServer that serves up layers through a particular database. That database is also used, primarily, by another application (this other application might be thought of as the ‘owner’ of the database). This other application employs an A/B set of databases. That is, we build database A, and point our application and GeoServer at this database. In the mean time, we are working on data updates, meta data changes and the like in our B database. When we are comfortable with where B is at, we point our application and GeoServer at the B database.

Is there a way to dynamically have GeoServer “lookup” it’s connection information? We’re looking to have GeoServer automatically pickup that the application is now using “B” and appropriately switch over itself to using “B”

···

On Fri, Aug 19, 2016 at 8:13 AM, Daniel Araujo Miranda <miranda.dam@anonymised.com…> wrote:

Hi David,
I am not sure I quite understood your use case, but here’s an idea:

You may point you datasources to a local host address defined in /etc/hosts (for example: “geoserverdatabase”), preferably one that is not resolvable by your internal dns.
To change between demo/staging/live db servers, you just have to change the address that your “geoserverdatabase” server points to in /etc/hosts, without changes to your application code or geoserver configuration.
I have just tested this here and it works.

Best,
Daniel

Em 18/08/2016 18:37, David Haynes II escreveu:

Hello Everyone,

This isn’t necessarily a Geoserver question, but I am hoping to get some advice from this group on what tools and tips will make this work. I have a web application that consumes wms produced by Geoserver. Currently we have a large number of layers and view that connect directly to the PostGIS database. Generally speaking our applications using Ruby on Rails for connecting to the database.

As the database changes the applications reflect these changes. We have three ruby environments (demo, staging, live) each with multiple database, which may or may not be serving the active application. I want to abstract out the connection logic when defining a layers/view so that and when they are when created they look to the environment not the actual database. Is anyone doing something like this and can offer some ideas.

–
David Haynes, Ph.D.
Research Associate Terra Populus
Minnesota Population Center
612-626-3933
www.terrapop.org <http://www.terrapop.org>

Geoserver-users mailing list
Geoserver-users@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–

David Haynes, Ph.D.
Research Associate Terra Populus
Minnesota Population Center
612-626-3933
www.terrapop.org

4

On 19-08-16 16:25, David Haynes II wrote:

Thanks Daniel, that's not exactly what I am looking for does this clear
it up?

We have an instance of GeoServer that serves up layers through a
particular database. That database is also used, primarily, by another
application (this other application might be thought of as the 'owner'
of the database). This other application employs an A/B set of
databases. That is, we build database A, and point our application and
GeoServer at this database. In the mean time, we are working on data
updates, meta data changes and the like in our B database. When we are
comfortable with where B is at, we point our application and GeoServer
at the B database.

Is there a way to dynamically have GeoServer "lookup" it's connection
information? We're looking to have GeoServer automatically pickup that
the application is now using "B" and appropriately switch over itself to
using "B"

JNDI comes to mind, but I think geoserver initializes the connections during startup so a geoserver restart would probably be necessary, while pointing your application to another database seems manual you could probably switch over the connection behind the JNDI lookup as well; it depends on your servlet container how dynamic ths actually is; it may need to be restarted as well.

On Fri, Aug 19, 2016 at 8:13 AM, Daniel Araujo Miranda
<miranda.dam@anonymised.com <mailto:miranda.dam@anonymised.com>> wrote:

    Hi David,
        I am not sure I quite understood your use case, but here's an idea:

        You may point you datasources to a local host address defined in
    /etc/hosts (for example: "geoserverdatabase"), preferably one that
    is not resolvable by your internal dns.
        To change between demo/staging/live db servers, you just have to
    change the address that your "geoserverdatabase" server points to in
    /etc/hosts, without changes to your application code or geoserver
    configuration.
        I have just tested this here and it works.

    Best,
    Daniel

    Em 18/08/2016 18:37, David Haynes II escreveu:

        Hello Everyone,

        This isn't necessarily a Geoserver question, but I am hoping to
        get some advice from this group on what tools and tips will make
        this work. I have a web application that consumes wms produced
        by Geoserver. Currently we have a large number of layers and
        view that connect directly to the PostGIS database. Generally
        speaking our applications using Ruby on Rails for connecting to
        the database.

        As the database changes the applications reflect these changes.
        We have three ruby environments (demo, staging, live) each with
        multiple database, which may or may not be serving the active
        application. I want to abstract out the connection logic when
        defining a layers/view so that and when they are when created
        they look to the environment not the actual database. Is anyone
        doing something like this and can offer some ideas.

        --
        David Haynes, Ph.D.
        Research Associate Terra Populus
        Minnesota Population Center
        612-626-3933 <tel:612-626-3933>
        www.terrapop.org <http://www.terrapop.org> <http://www.terrapop.org>

        ------------------------------------------------------------------------------

        _______________________________________________
        Geoserver-users mailing list
        Geoserver-users@lists.sourceforge.net
        <mailto:Geoserver-users@lists.sourceforge.net>
        https://lists.sourceforge.net/lists/listinfo/geoserver-users
        <https://lists.sourceforge.net/lists/listinfo/geoserver-users&gt;

--
David Haynes, Ph.D.
Research Associate Terra Populus
Minnesota Population Center
612-626-3933
www.terrapop.org <http://www.terrapop.org>

------------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

5

In my test I also restarted geoserver to be able to use the new /etc/hosts, Mark says a restart is probably necessary using JNDI too.

If restarting is a given, a script may be inserted in the container initialization to alter the datastore xml to lookup the correct database and point it to the correct one.

The container inicialization is made at some file like /etc/init.d/tomcat8 or /etc/systemd/system/xxxxxxxx.service in case your container is initialized using systemd.

I do not like the idea of restarting geoserver frequently. In my case it has taken up to 7 minutes. I can think of the following approaches:

1. Do the lookup only in the web application and the Ruby backend. Publish everything in geoserver in different workspaces (workspaceA and workspaceB, for example) and let the applications decide (by querying the database, an environment variable, etc.) from which workspace they will pull the data.
That way you do not have to reconfigure or restart geoserver and I can envision near to zero downtime when transitioning.
The disavantage is that you have to mirror configuration changes in two workspaces at the same time.

2. Have a job running as a daemon to watch this "variable" (database, environment, config file, etc.) and automate the geoserver switch. That can be done by stopping the service and directly editing the datastore xml configuration or by using the more civilized REST interface. I have not tested if changing a datasource database address using REST has immediate effects, but I assume it does.
This approach should also have negligible downtime if REST behaves as assumed, with the disadvantage that you have to develop, test and maintain that daemon.

3. Change the datasource database manually every time you change databases using the geoserver web interface.

Best regards,
--Daniel

Em 19/08/2016 12:42, Mark Prins escreveu:

On 19-08-16 16:25, David Haynes II wrote:

Thanks Daniel, that's not exactly what I am looking for does this clear
it up?

We have an instance of GeoServer that serves up layers through a
particular database. That database is also used, primarily, by another
application (this other application might be thought of as the 'owner'
of the database). This other application employs an A/B set of
databases. That is, we build database A, and point our application and
GeoServer at this database. In the mean time, we are working on data
updates, meta data changes and the like in our B database. When we are
comfortable with where B is at, we point our application and GeoServer
at the B database.

Is there a way to dynamically have GeoServer "lookup" it's connection
information? We're looking to have GeoServer automatically pickup that
the application is now using "B" and appropriately switch over itself to
using "B"

JNDI comes to mind, but I think geoserver initializes the connections
during startup so a geoserver restart would probably be necessary, while
pointing your application to another database seems manual you could
probably switch over the connection behind the JNDI lookup as well; it
depends on your servlet container how dynamic ths actually is; it may
need to be restarted as well.

On Fri, Aug 19, 2016 at 8:13 AM, Daniel Araujo Miranda
<miranda.dam@anonymised.com <mailto:miranda.dam@anonymised.com>> wrote:

     Hi David,
         I am not sure I quite understood your use case, but here's an idea:

         You may point you datasources to a local host address defined in
     /etc/hosts (for example: "geoserverdatabase"), preferably one that
     is not resolvable by your internal dns.
         To change between demo/staging/live db servers, you just have to
     change the address that your "geoserverdatabase" server points to in
     /etc/hosts, without changes to your application code or geoserver
     configuration.
         I have just tested this here and it works.

     Best,
     Daniel

     Em 18/08/2016 18:37, David Haynes II escreveu:

         Hello Everyone,

         This isn't necessarily a Geoserver question, but I am hoping to
         get some advice from this group on what tools and tips will make
         this work. I have a web application that consumes wms produced
         by Geoserver. Currently we have a large number of layers and
         view that connect directly to the PostGIS database. Generally
         speaking our applications using Ruby on Rails for connecting to
         the database.

         As the database changes the applications reflect these changes.
         We have three ruby environments (demo, staging, live) each with
         multiple database, which may or may not be serving the active
         application. I want to abstract out the connection logic when
         defining a layers/view so that and when they are when created
         they look to the environment not the actual database. Is anyone
         doing something like this and can offer some ideas.

         --
         David Haynes, Ph.D.
         Research Associate Terra Populus
         Minnesota Population Center
         612-626-3933 <tel:612-626-3933>
         www.terrapop.org <http://www.terrapop.org> <http://www.terrapop.org>

         ------------------------------------------------------------------------------

         _______________________________________________
         Geoserver-users mailing list
         Geoserver-users@lists.sourceforge.net
         <mailto:Geoserver-users@lists.sourceforge.net>
         https://lists.sourceforge.net/lists/listinfo/geoserver-users
         <https://lists.sourceforge.net/lists/listinfo/geoserver-users&gt;

--
David Haynes, Ph.D.
Research Associate Terra Populus
Minnesota Population Center
612-626-3933
www.terrapop.org <http://www.terrapop.org>

------------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------------------------------------------------------
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users