Create GeoServer Instance

[ktjaco]

I am the Geospatial Specialist that now has access to the Geomatics PostgreSQL database. In addition, we will also need a GeoServer instance to test the database connection with the Geomatics PostgreSQL database and additional databases for the purpose of disseminating geospatial datasets.

For initial testing/development purposes a D4 v3 instance may serve our purpose.

D4 v3 https://azure.microsoft.com/en-ca/pricing/details/virtual-machines/linux/ Operating system: Linux CPU: 4 RAM: 16 GiB

There are also mature Docker containers that exist for GeoServer. https://hub.docker.com/r/kartoza/geoserver/

[sylus]

@blairdrummond, @brendangadd let me know when want me to look at this.

[blairdrummond]

Looks like they have a chart too

https://github.com/kartoza/charts

We're chatting now and might want to throw this in a geospatial namespace? (Up to you guys, but thinking might be easier to give the geo folks access this way)

[ktjaco]

@sylus @brendangadd @blairdrummond

I now have my geospatial datasets in the PostgreSQL/PostGIS database, so I am ready to test the database connectivity in GeoServer when it is stood up.

I'm working on a Dockerfile in a repository here, which downloads the data and imports it into the database all in one go, but I don't think the Dockerfile necessary to move forward with deploying GeoServer.

[blairdrummond]

@brendangadd Do we have a timeline on when this might be prioritized?

[blairdrummond]

@sylus

https://github.com/kartoza/charts

^ There's the chart

[blairdrummond]

Also

https://hub.docker.com/r/kartoza/geoserver/

[sylus]

So you mean this?

https://github.com/kartoza/charts/tree/main/charts/geoserver/v0.3.1 https://github.com/kartoza/docker-geoserver/blob/master/Dockerfile

Namespace: geospatial Active Directory Group: DAaaS Managed PostgreSQL: Created but you will need to run query sql "CREATE EXTENSION ...."

We will probably need to run the container from the develop branch due to the reported vulnerabilities:

https://github.com/kartoza/docker-geoserver/issues/209

[sylus]

@zachomedia I am guessing don't enable Istio in the geospatial namespace at the moment since will likely introduce problems?

[zachomedia]

@sylus If that is the helm chart, then I think enabling Istio should be ok as it doesn't look complicated service wise. We have the ServiceEntry already for this database (I will add to terraform)

[sylus]

Sigh i was hoping wouldn't say that but fine.

[ktjaco]

@sylus

Is it possible for you to use this Dockerfile?

https://github.com/ktjaco/daaas-geospatial/blob/master/dockerfiles/Dockerfile

It uses kartoza/geoserver but has additional extensions needed for proof of concept.

[sylus]

It looks like your calling from 2.18 which still has the security vulnerabilities mentioned in https://github.com/kartoza/docker-geoserver/issues/209 ?

I think that is my only concern.

[ktjaco]

@sylus

Thanks for pointing that out. Is this an issue with GeoServer version 2.18 in general or the kartoza image specifically?

I think the next best bet with GeoServer images may be from geosolutionsit.

https://hub.docker.com/r/geosolutionsit/geoserver

[sylus]

Hey @ktjaco there is a fix in the develop branch for geoserver so think we just need to use that till he does a release.

[ktjaco]

@sylus

Sounds good!

So pulling from kartoza/geoserver:latest should be fine then?

https://github.com/ktjaco/daaas-geospatial/blob/master/dockerfiles/Dockerfile

[brendangadd]

@ktjaco Please build your candidate image, scan with Trivy, and verify that the vulnerabilities have been addressed.

@sylus needs a compliant image before he can set this up for you. He's indicating that you may need to incorporate fixes currently only present in the develop branch to resolve the security issues.

[ktjaco]

@brendangadd

I've tested the Dockerfile in the develop branch.

https://github.com/ktjaco/docker-geoserver/blob/develop/Dockerfile

There are still critical vulnerabilities but it seems like they are only related to Python. Is it ok to proceed with this? Attached is my Trivy output.

trivy.txt

[brendangadd]

@ktjaco I don't think @sylus is going to deploy any image into the cluster that reports critical severity vulnerabilities, no matter the library. You'll probably need to update the flagged libraries, which will hopefully be easy enough for the Python 3.7 libs.

I'm a little concerned to see Python 2.x libs in there...

[ktjaco]

@brendangadd A lot of the same errors occurred even with upgrading to Python3.7.3. I tried other GeoServer docker images and there were even more critical errors. I'm not sure what other options we have other than completely removing Python (I don't think it is critical for the proof of concept - hopefully there aren't bugs with GeoServer because of that), or building a new image completely from scratch and seeing where that leads us.

[brendangadd]

@ktjaco I don't know anything about GeoServer and whether or not it has actual dependencies on Python. Some things to consider:

• Python 3.7.10 looks to be the latest security patch for minor version 7.
• Some of these issues could be addressed by the base image; are you using the latest stable version?
• If your base image is totally up-to-date and Trivy still complains about Python 2.x then removal is probably a good option.

[ktjaco]

@brendangadd @sylus

I think I may have come up with a solution that may suffice. I remove Python2 and Python3.7 and install Python3.9.2 from source. After the docker build Trivy returns 0 critical vulnerabilities.

Here is the Dockerfile and Trivy output: https://github.com/ktjaco/docker-geoserver/blob/develop/Dockerfile

trivy-geoserver.txt

[chuckbelisle]

@brendangadd @zachomedia, I just met with the Geo startup and Kent was asking what would be the next step for him to have his image available in the aaw cluster.

Thanks!

[brendangadd]

@sylus You able to unblock @ktjaco?

[sylus]

This will be done Tuesday night after my french exam @ktjaco

[ktjaco]

Startup 5 (Geospatial Platform) now has their own Azure resource group. We are currently implementing GeoServer and PostgreSQL instances on that resource group.

[sylus]

@ktjaco ok but just make sure you use our CIS benchmarked PostgreSQL cause you won't be allowed to launch a non secured one and it will be removed if isn't the ATO'd one by IT Security.

All managed databases need to use the approved terraform module but it is pretty easy to use so shouldn't be too hard and most of the hard work is done:

https://github.com/canada-ca-terraform-modules/terraform-azurerm-postgresql

This is internal in the out GitLab but the above is the public mirror

[sylus]

@ktjaco

I'll remove your geospatial deployment that I manually deployed last night.

However we will still keep the Helm chart and push up that work so nothing is lost :)

Sorry it took so long but I have been working 18-20 hours day to get some priority projets done so only got time over the last few days to finalize.

I'd still love for you to review and look at the helm chart though ^_^

Thanks so much :D

[sylus]

Helm Chart: https://github.com/StatCan/charts/tree/master/stable/geoserver GeoServer CI/CD: https://github.com/StatCan/geoserver https://geoserver.covid.cloud.statcan.ca/geoserver https://geoserver.covid.cloud.statcan.ca (tomcat)