[mapguide-users] RES: Mapguide and the Cloud

[liglio.pessoal at nexxa.com.br]

Hi Mark,

 

3) Mapguide configuration (data, layers, maps, etc.) is retrieved and stored in a repo (this can be done via REST calls to the mapagent API).

This Repo is a File System node where you store Mapguide Data and point to in the serverconfig.ini ?

 

6) User authentication is done external to Mapguide (Azure active-directory or the cloud’s user system), and relevant information is passed through via headers or an auth tokens.

Can you explain a little more?

 

a. Once a route between user and server is made, all activity for that user session is stored on one server.

If this server is terminated, like an auto-scaling, the mapguide session is lost, or when you say “one server” you store sessions in one single server apart?

 

Liglio

 

De: mapguide-users <mapguide-users-bounces at lists.osgeo.org> Em nome de mark volz
Enviada em: segunda-feira, 4 de outubro de 2021 19:54
Para: MapGuide Users Mail List <mapguide-users at lists.osgeo.org>
Assunto: Re: [mapguide-users] Mapguide and the Cloud

 

Hi Liglio,

 

As per Jackie’s post, you could use MapGuide’s native load balancer, but I prefer to use the native load balancers on the cloud environment.

 

I have deployed Mapguide on AWS, Google, Azure and Oracle clouds with the same basic model, with slight changes if my client wants to go down the containerisation route (Docker/Kubernetes). 

 

The requirements for the model I use are:

1.	Data is stored in a database or on a shared storage device, i.e. S3 bucket on AWS.
2.	All custom code is managed via repository, typically git.
3.	Mapguide configuration (data, layers, maps, etc.) is retrieved and stored in a repo (this can be done via REST calls to the mapagent API).
4.	All development (code and config) work is done on the location machine and published to the repo.
5.	Server deployment is done via scripts or an automation engine like Jenkins.
6.	User authentication is done external to Mapguide (Azure active-directory or the cloud’s user system), and relevant information is passed through via headers or an auth tokens.

 

The non-containerised environment architecture is;

1.	Cloud load balancer with sticky IP enable

a.	Once a route between user and server is made, all activity for that user session is stored on one server.
b.	The load balancer triggers and controls the authentication for the user against the Security service (Azure AD, etc.) and passes on the relevant info to the Mapguide server.

2.	Multiple MapGuide instances (could be anywhere from 1 to 100)

a.	The Mapguide instances have identical code, configuration, and data. Hence the need for items 1 to 5 on the requirements.

b.	Based on the user data passed through from the load balancer, you can auto-create the relevant Mapguide user session and details.
c.	Depending on your requirements, you can create functionality-based users (author, read-only, etc.) or named accounts linked to Mapguide user groups.

 

Let me know if you require more information.

 

Mark

 
 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapguide-users/attachments/20211006/f75f5843/attachment.html>