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 <[email protected]> Em nome de mark volz
Enviada em: segunda-feira, 4 de outubro de 2021 19:54
Para: MapGuide Users Mail List <[email protected]>
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

 
 




_______________________________________________
mapguide-users mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/mapguide-users

Reply via email to